With each new Java release the previous one becomes instantly unsupported (meaning that it receives no security updates), unless you pay Oracle (or another vendor). So you are forced to update if you want security updates (or run only LTS releases, or pay a vendor).
Your blog isn't loading at the moment, so I'm not entirely sure what you mean here, but...
> capsicum is after the fact
After the fact in what sense? The program enters capability mode before touching any arguments or doing I/O. You have to set things up before enter capability mode because you can't escape out of it afterwards.
> it does nothing about syscalls
It does quite a lot about syscalls, in that it blocks or limits most of them. As the man page says: "Access to system calls in capability mode is restricted: some system calls requiring global namespace access are unavailable, while others are constrained."
In capability mode, you can use specific syscalls that operate on file descriptors, which limits the program to the specific capabilities it has been granted, e.g. pdkill(2) which is like kill(2) except you can only signal processes for which you have a process descriptor.
Just as another point of comparison, FreeBSD's version seems somewhere in-between. It also enables a Capsicum sandbox before processing any data, akin to what the OpenBSD version does with pledge.
Is this functionality accessible from sandboxed processes? That would make a remote hole much more dangerous when one is found, anyway. The CVE seems to concern SysV semaphores and the pledge(2) man page doesn't seem to mention those.
"The International Workingmen's Association (IWA), commonly known as the First International [...] was founded in 1864 [...] The preparatory Address of English to French Workmen, drafted by trade union leader George Odger, articulated the need for international cooperation to prevent the importation of foreign workers to break strikes:
A fraternity of peoples is highly necessary for the cause of labour, for we find that whenever we attempt to better our social condition by reducing the hours of toil, or by raising the price of labour, our employers threaten us with bringing over Frenchmen, Germans, Belgians and others to do our work at a reduced rate of wages [...]"
Isn't this just quantization with extra steps? Can converting the text to an image really be a better way to lossily compress it? (Not that I have any idea what I'm talking about on this topic.)
Alright, let's say the author is right and low-level radiation exposure is not harmful. Then... what? If a little radiation is not harmful, then we should be more relaxed about radiation, deregulate it and allow companies to contaminate our living spaces? Is that why the argument is being made?
But as the article mentions, in those Taiwanese flats there were large variations in radiation levels in different spots in the building. If we allow radioactive contamination everywhere, will it be neatly spread out at harmless levels? How would you know? What if you happen to ingest traces of the harmlessly radioactive material now surrounding you?
So websites can now nag users to allow access to the root of their local disk and then read all their files and settings, all their SSH keys and other passwords?
From what I gather from the docs [1], this API gives you a FileSystemDirectoryHandle object, and then you just call getDirectoryHandle() on that to recursively read the the entire filesystem. The spec [2] has some vague suggestions about blacklisting certain particularly sensitive files, which doesn't seem reassuring.
What happens when the data contains the record or field separator characters?
I suppose you could document that it's unsupported, and just drop or reject such values, but then the system couldn't be used to handle test data for such systems, for example.
So does Java provide an API for continuations or just the virtual threads hidden behind the threading API? You can't use threads to wait for something on the UI thread (which is why e.g. SwingWorker exists), but you can with await.
What's wrong with what .NET did with threads? Having async tasks sharing the GUI thread seems like a nice feature. Will we be able to use virtual threads and structured concurrency with Swing, e.g. to wait for a background task in an event listener?
The problem the article is describing seems to have little to do with open source. There were GitHub repositories that had links added in their READMEs to a zip file containing compiled binaries.
GitHub is not a curated software repository. It's essentially no different from some random stranger linking to some binaries on a forum. (There are communities that seem to have no concerns about running unknown binaries from strangers in forum threads, but I wouldn't recommend it.)
The vendors are never going to give you control over your computer no matter what vision they try to sell you on. The whole point, from their perspective, is to use their control of your computer to gain more control over you, which they hope to then exploit for profit.