For us it is relatively straightforward. Every release gets one single post. It always gets a title highlighting the most important change highlighting why people want to upgrade. This is followed by a short summary of which usecase is now supported by a change we did (either added feature or some enhancement). This is again followed by a detailed story on the items above and finally a granular list of security, interface changes, etc., pointing at the relevant ticket number containing for each change the full reasoning and history.
Mostly this is a manual effort on the textual bit. A PR is required to indicate whether something is worthy to be specifically mentioned in the release notes. The list of concrete changes is automated.
Oh. But that is a solved problem. The users of the library just copy the code from before the deprecation and then stick it in their codebase not to be maintained anymore. Problem solved. /s
Not sure whether this is a limitation of the scanning tooling or of the CVE format itself, it also cannot express sub packages. So if some Jackson-very-specific-module has a CVE the whole of Jackson gets marked as impacted. Same with netty.
There can be many models. One model is just to have shares expire after a certain point, the same way options do. Or undergo demurrage (a discount that grows from 0 to 100% over a decade, for instance, where the remaining % from the sale goes back to the ecosystem and is distributed as UBI to all tokenholders).
In fact, staking your shares and getting a perpetual flow of utility tokens, or selling the shares, could be a good compromise. But the shares would cease to confer voting power or dividends. The dividends would be paid out in the utility token itself. So the utility tokens might get devalued if there are too many of them, or they could be burned as transaction fees for instance, reducing their supply. There are a ton of possibilities.
Reinterpreting shares as something like a bond with a yield in the ecosystem's own currency makes things much more sustainable. Yes, the shareholders would still want the ecosystem's growth to outpace the token issuance, but also, they could just increase the fees' burn rate of tokens. But that's like extracting rents. So yes, I think eventually, shares should simply get less and less dividends over time. Look at the Miracle of Worgl and their currency undergoing demurrage, for instance.
In the ideal scenario, though, new companies would have no IPO ever, only ICO of utility tokens. Just make IPOs almost impossible to do from a regulatory point of view. It's becoming rare anyway. This would mean that early shareholders would get their returns by staking shares and receiving utility tokens which they sell to ecosystem participants (so they're incentivized to help grow the entire ecosystem, refer new customers etc.) And eventually, the market cap of the shares is totally phased out due to demurrage and the utility tokens is all that remains.
Or perhaps we go one step further by making shareholders also owners. They get to take their part (as determined by the amount of shares they possess) of the profits and equally have to cough up their part of the losses.
This would return closer to the model where you invest into a business because you believe in it.
Stop trying to reimagine stocks as crypto to try to justify a failed attempt at manifesting a problem that cryptocurrency can attempt to be a solution to.
Stop hating on crypto just because you're on HN, and consider that actual problems have grown very large with current systems. This is the problem with many HN denizens -- they keep correctly posting about problems, but then dismiss solutions out of hand because they're against the groupthink. Then 10 years later the problem is worse, but you get triggered by the word "cryptocurrency" (which by the way I didn't even say).
As a result, you totally ignore the very real problems that get bigger and bigger due to late-stage shareholder capitalism, and call it a "failed attempt to manifest" the problems.
I'm not saying this out of groupthink. If you just change the word "stocks" to "token", and don't change the fundamentals of ownership of "stocks" being basically indicated by entries in the ledger of an asset tracking company, that provides a foundation for conducting trades for financial gains at the stroke of a pen you've accomplished nothing. In the transformation to tracking the same damn thing with a block chain or crypto token, if you're providing the same abstractive benefits, you've got nothing but a change in detail, but not in kind. Tokens will be traded on info or trends as monied interest recognizes value to be squeezed out of the fact of owning a share, having voting rights/influence on operations, or claim to a flow of future value. Same shit, different wrapper, it's just a token now, and we're blowing eith bookoo power doing PoW, or creating more centralization through PoS, to process transactions that were previously accomplished with an entry in one of a handful of company's databases, and some paperwork.
So if you want to sell tokenization as not being stocks/shares by another name, tell me how you're changing the fundamentals. I buy into ventures to say, get dividends, or knowing I'll lose money, but hoping to see something manifest that I want to see that may not be profitable yet, but I want to be a part of. How does your change to tokens differ at all, from me buying shares of stock?
If you can't provide an answer to that, I continue to stand by my original statement. Unless, of course, you're being a proponent of a public database of beneficial ownership of all legal fictions. In which case you might get some interest out of me, but I guarantee you'll run into other forms of Dead on Arrival until you fix/address the whole problem around said database basically provides a map for targeting all of the top centralizations of capital, which none of those individuals will probably be okay with being the case to the degree it will be prevented through buying out political clout.
Thinking it's a good idea to abolish private ownership because of the most pathological cases is probably sawing off the branch you're sitting that keeps you away from socialism and mass starvation policies.
What I don’t get because there is LSP and BSP support. What else is needed to get support for scala 3 from an IDE? Obviously, Kotlin coming from Jetbrains will make it receive a lot more love and first class support.
For me the main takeaway of this is that you want to have automated performance tests in place combined with insights into flamegraphs by default. And especially for these kind of major language upgrade changes.
Benchmarking requires a bit of different setup than the rest of the testing, especially if you want down to the ms timings.
We have continous benchmarking of one of our tools, it's written in C++, and to get "same" results everytime we launch it on the same machine. This is far from ideal, but otherwise there be either noisy neighbours, pesky host (if it's vm), etc. etc.
One idea that we thought was what if we can run the same test on the same machine several times, and check older/newer code (or ideally through switches), and this could work for some codepaths, but not for really continous checkins.
Just wondering what folks do. I can assume what, but there is always something hidden, not well known.
I agree for measuring latency differences you want similar setups. However, by running two versions of the app concurrently on the same machine they both get impacted more or less the same by noisy neighbours. Moreover, by inspecting the flamegraph you can, manually, see these large shifts of time allocation quickly. For automatic comparison you can of course use the raw data.
In addition you can look at total cpu seconds used, memory allocation on kernel level, and specifically for the jvm at the GC metrics and allocation rate. If these numbers change significantly then you know you need to have a look.
We do run this benchmark comparison in most nightly builds and find regressions this way.
Yes, that can help with detecting how much cpu was actually used during the run. But it doesn’t influence benchmark results. Not sure how exactly to use it for doing subsequent runs and comparing final performance. Then this needs to be extrapolated to final performance in production.
Yeah, what you want to know is which change caused the slowdown, or maybe improved the performance and reasonable metric behind it (for example frame-rate for a game, or something like this).
I use jmh for micro benchmarks on any code we know is sensitive and to highlight performance differences between different implementations. (Usually keep them around but not run on CI as an archive of what we tried.)
Then we do benchmarking of the whole Java app in the container running async-profiler into pyroscope. We created a test harness for this that spins up and mocks any dependencies based on api subscription data and contracts and simulates performance.
This whole mechanism is generalised and only requires teams that create individual apps to work with contract driven testing for the test harness to function.
During and after a benchmark we also verify whether other non functionals still work as required, i.e. whether tracing is still linked to the right requests etc. This works for almost any language that we use.
They may not have learned it but being thorough in general was more of a thing. These days things are far more rushed. And I say that as a relatively young engineer.
The amount of dedication and meticulous and concentrated work I know from older engineers when I started work and that I remember from my grand fathers is something I very rarely observe these days. Neither in engineering specific fields nor in general.
And then the kicker. VW doesn’t allow the dsg with electric motor to be repaired by dealers. If something is wrong it needs to be replaced completely. At the cost of €15k (NL, 2021). The only serviceable thing is the clutch and the mechatronic.
IMHO this is something that should be regulated away as consumer unfriendly and environment unfriendly. (Not to say hostile.)
In the end I got a DSG specialist fix the problem in two hours by replacing two simple components physically. The car then spend an hour retraining the dsg.
reply