When you're a kid, tinkering is exciting. When you turn 30, you just want your software and tools to work. Janitoring your computer is not fun when it's in the way of your actual day job.
My worry is that this has bad long term implications.
Modern computing environments aren't very good, and most of the core abstractions haven't changed / improved since the 80s. Those core abstractions have so much stuff built on top of them now that they're very difficult to change. You used to be able to make a usable operating system in a month or two if you knew what you were doing. Now a simple web browser takes 20m+ lines of code to make. Its out of the hands of anyone with less than $1bn or so to spend - and at that scale the only real contributors are big tech companies. Except for some small features like io_uring and device drivers, linux is developed as if its already feature complete.
So I worry - will we ever replace the crufty parts of POSIX[1]? Will we ever have operating systems and software that can properly take advantage of NVMe and Optane memory[2]? Will we ever have desktop computers which sandbox software by default like my phone does, so I don't have to trust every program, npm library and rust crate on my computer with my data? Will there ever be a desktop class UI library which works across all my devices, or are we doomed to waste 90% of our computer hardware keeping electron + javascript fast-ish?
I'm worried these ships have sailed, and our grandchildren are destined to inherit a computing experience of electron, + more CSS.
In the 90s people would iterate on this stuff by just hacking linux and submitting patches. Now thats really hard because of how tall we've made our mountains of code. By the time you've climbed one mountain, you're halfway through your career. I mean, how many kernel hackers out there are also good at making user interfaces? How many people with frontend experience are even capable of hacking on linux? Its impossible to improve the interfaces between our systems without a holistic understanding. And thats becoming an increasingly rare commodity.
[1] Eg fsync(), and in my opinion the filesystem abstraction as a whole.
> So I worry - will we ever replace the crufty parts of POSIX[1]?
No, probably not, as much as I would love to, because there are still people who believe that POSIX's design ideals are to be aspired to, even as the world has aged heavily around them. The POSIX model and philosophies are very outdated, but as long as people see value in the nonsense that is "everything is a file" (except for all of the ones that you can only ioctl to) or "do one thing and do it well" (except text parsing, that famously secure and not at all haunted thing apparently belongs in every app), we won't see big shifts in production OS architecture. Maybe research kernels, but those don't run PostgreSQL installs.
I don't think that has anything to do with this complacency, however.
The majority of the world is on linux. A small remaining fraction is on windows, where there is no less cruft.
Yes, there are embedded OSes (l4); ibm i&z; etc. (L4 and ibm i are actually super cool.) But those are tiny drops in the bucket and aren't replacing linux any time soon.
You are making the great-grandparent's point (with which I was agreeing). Their concern was not only the cruft built up in the POSIX API, but the many layers of abstraction and behemoths of code that depended on said cruft, making it a compatibility nightmare to ever remove. That comprises the web browser that drives chromeos's apps; the java runtime that drives android apps; the language runtimes that drive serverless apps.
IoT is even more of a niche than desktop.
And, I think you underestimate the amount of software written in c, directly against posix.
> ChromeOS and Android? POSIX APIs are not exposed to app developers. Cloud? Language runtimes and serveless make POSIX irrelevant.
The underlying POSIX filesystem is still exposed to android developers via java's File. And via the C apis too, from the sounds of things. I think its the same on iOS.
But even if you're only using posix calls indirectly through complicated database abstractions and unix sockets, you're certainly still paying a cost. Plenty of benchmarks have been made over the years showing how better APIs can yield 20+% more filesystem & TCP socket performance on linux by bypassing write() and friends. If you spend $10k on a database or application server, think about it as $2k of that hardware wasted simply due to bad kernel APIs. And I'm sure there's plenty of features postgres and sqlite don't have because their devs instead needed to spend their days in a desperate struggling to make their software work correctly, at all.
Aside from performance, in my opinion a better API would also be transactional, at the filesystem level. Aside from dramatically simplifying every database, that could also would allow collaborative editing through simple network shares. I don't even think it would be that hard to do.
> Aside from performance, in my opinion a better API would also be transactional, at the filesystem level
A better API shouldn't be a filesystem. As a strictly hierarchical system, its only virtue is that it should be easy to create sandboxes and reason about the resultant guarantees. Emphasis on 'should'; in practice, chroots are easy but very ineffective. (I believe fuchsia[0] and plan9[1] do a slightly better job of this.)
Systems based (for example) on tags and tag categories are faster, more expressive, easier to reason about, and can be constructed into arbitrary trees on the fly should the need arise. (They are thus also capable of presenting a hierarchical interface to a legacy application, so compatibility isn't an issue.)
I disagree with everything you said because your tone is just wrong. Old APIs don't remove the need for new ones. New APIs don't remove the need for old ones. The existence of one API does not prevent the existence of another API. Phrasing this as an us vs them problem will just waste your time and fail to convince everyone else. Instead of telling everyone how wrong they are you should convince them how great the new thing is.
In fact, there are special derived classes to handle file system specific semantics, if one feels inclined to do so, but that doesn't mean they work all the time, as JVM runs anywhere.
> Note that on Android, unlike Linux, there are no separate libpthread or librt libraries. That functionality is included directly in libc, which does not need to be explicitly linked against.
Better learn how much POSIX Android actually allows.
Modern computing environments aren't very good, and most of the core abstractions haven't changed / improved since the 80s. Those core abstractions have so much stuff built on top of them now that they're very difficult to change. You used to be able to make a usable operating system in a month or two if you knew what you were doing. Now a simple web browser takes 20m+ lines of code to make. Its out of the hands of anyone with less than $1bn or so to spend - and at that scale the only real contributors are big tech companies. Except for some small features like io_uring and device drivers, linux is developed as if its already feature complete.
So I worry - will we ever replace the crufty parts of POSIX[1]? Will we ever have operating systems and software that can properly take advantage of NVMe and Optane memory[2]? Will we ever have desktop computers which sandbox software by default like my phone does, so I don't have to trust every program, npm library and rust crate on my computer with my data? Will there ever be a desktop class UI library which works across all my devices, or are we doomed to waste 90% of our computer hardware keeping electron + javascript fast-ish?
I'm worried these ships have sailed, and our grandchildren are destined to inherit a computing experience of electron, + more CSS.
In the 90s people would iterate on this stuff by just hacking linux and submitting patches. Now thats really hard because of how tall we've made our mountains of code. By the time you've climbed one mountain, you're halfway through your career. I mean, how many kernel hackers out there are also good at making user interfaces? How many people with frontend experience are even capable of hacking on linux? Its impossible to improve the interfaces between our systems without a holistic understanding. And thats becoming an increasingly rare commodity.
[1] Eg fsync(), and in my opinion the filesystem abstraction as a whole.
[2] Eg https://www.usenix.org/conference/atc20/presentation/bittman