It sounds like what you're really trying to recreate is the Software Tools movement from 50 years ago, where there was a push to port the UNIX/BTL utilities to the widest possible variety of systems to establish a common programming and data manipulation environment. It was arguably successful in getting good ports available just about anywhere, evolving into GNU, etc., but it never really reached its apotheosis. That style of clear, easy-to-read-and-write software was still largely killed off by a few big industry players pushing a narrative that "enterprise" has to mean relational databases and distributed objects. It would be FASCINATING if AI coding agents are the force that brings it back.

Well, there it is, the dumbest thing I'll read on the internet all week.

Most of the engineering in Linux revolves around efficiently managing hardware interfaces to build up higher-level primitives, upon which your browser builds even higher-level primitives, that you want to use to simulate an x86 and attached devices, so you can start the process again? Somewhere (everywhere), hardware engineers are weeping. I'll bet you can't name a single advantage such a system would have over cloud hosting or a local Docker instance.

Even worse, you want this so your cloud-hosted imaginary friend can boil a medium-sized pond while taking the joyful bits of software development away from you, all for the enrichment of some of the most ethically-challenged members of the human race, and the fawning investors who keep tossing other people's capital at them? Our species has perhaps jumped the shark.

It's a fair amount of extra work, but in a hot loop it's sometimes worth it. "You can often solve correctness problems (tricky corner cases) by adding an extra layer of indirection. You can solve any performance problem by removing a layer of indirection."

If I wanted to put up with software where every time I encounter a bug, I either have no way at all to report it, or perhaps a "reporting" channel but little likelihood of convincing the developers that this thing that matters to me is worthy of attention among all of their competing priorities, then I might as well just use Microsoft products. And frankly, I'd rather run my genitals though an electric cheese grater.

If you really mean "C/C++, but with the sharp pointy bits filed down," then I fail to see what it adds over MISRA.

The bottom line is that we've had "clarity-first" languages for decades; the reason they're not more widely used is not simply that no one has tried this, nor that programmers appreciate murky code.

https://en.wikipedia.org/wiki/Double_Irish_arrangement

So from that standpoint, immigrants are a /better/ economic deal for the public than children are. At the end of the day, though, it shouldn't matter where people were born if they're contributing to society, and the grandparent post is 100% correct that the whole debate is stupid.

Anyway, "full control over your keys" isn't the issue, it's the way that normalization of this kind of attestation will enable corporations and governments to infringe on traditional freedoms and privacy. People in an autocratic state "have full control over" their identity papers, too.

The real purpose of restrict is to allow the compiler to cache a value that may be used many times in a loop (in memcpy(), each byte/word is used only once) in a register at the start of the loop, and not have to worry about repeatedly reaching back to memory to re-retrieve it because it might have been modified as a side effect of the loop body.

Right, because every executive who pursued offshore manufacturing was thinking, "gosh, how can I deliver even lower prices and better value to my customers?", and not "OK, we've shown the market will pay $X for product Y, how can I cut my costs and free up more money for bonuses and cocaine?"

Graphs of price indices (aside from a few sectors such as electronics where it was the core technology that improved, not labor efficiency) and wages over the last 50 years clearly show that the bulk of any offshoring savings were not passed along to consumers or front-line workers.

If anyone doesn't think all of that is going to happen again on a massive scale as companies embrace GenAI, HAHAHAHAHAHAHA. AI will change a lot of things, but it won't fix human nature.

Caches aren't quite as mix-and-match, but they can still internally manage different temporal versions of a cache line, as well as (hopefully) mask the fact that a write to DRAM from one core isn't an atomic operation instantly visible to all other cores.

Practice is always more complicated than theory.

But that method doesn't necessarily have to be "something like O_DIRECT", which turns into a composition/complexity nightmare all for the sake of preserving the traditional open()/write()/close() interface. If you're really that concerned about performance, it's probably better to use an API that reflects the OS-level view of your data, as Linus pointed out in this ancient (2002!) thread:

https://yarchive.net/comp/linux/o_direct.html

Or, as noted in the 2007 thread that someone else linked above, at least posix_fadvise() lets the user specify a definite extent for the uncached region, which is invaluable information for the block and FS layers but not usually communicated at the time of open().

I think it's quite reasonable to consider the real problem to be the user code that after 20 years hasn't managed to migrate to something more sophisticated than open(O_DIRECT), rather than Linux's ability to handle every single cache invalidation corner case in every possible composition of block device wrappers. It really is a poorly-thought-out API from the OS implementor's perspective, even if at first seemingly simple and welcoming to an unsophisticated user.

It seems like bcachefs would benefit from parallel development spirals, where unproven code is guarded by experimental flags and recommended only for users who are prepared to monitor and apply patches outside of the main kernel release cycle, while the default configuration of the mainline version goes through a more thorough test and validation process and more rarely sees "surprise" breakage.

It certainly appears that Linus can't tell the difference between your new feature introductions and your maintenance fixes, and that should trigger some self-reflection. He clearly couldn't let all of the thousands of different kernel components operate in the style you seem to prefer for bacachefs.