People love parroting the meme of "Unix is old therefore it must be bad, we need something newer and modern, redesigned from the ground up" but it's always hard

People love parroting the meme of "Unix is old therefore it must be bad, we need something newer and modern, redesigned from the ground up" but it's always hard to get a concrete proposal from these folks. This article does a lot of hand waving about what's wrong with Unix and what would be better. For example, the part about how it would be nice to assume data exists in main memory, instead of accessing it through the filesystem? That's existed for nearly 40 years, it's called mmap, and every modern operating system implements it. You can trivially write a wrapper that automatically mmaps opened files if you want, but creating a MAP_FILE memory mapping is one of the easiest things you can do in C. Likewise the stuff about how IPC, sockets, and shared memory assume that a resource is only going to be shared between two programs. The whole statement is weird because all of those things can be used by more than two programs, and it's not clear what the author means by saying they're designed for a single receiver/sender. The Berkeley sockets API is admittedly a bit intimidating at first but that's because it covers a lot of functionality that people actually need. It can handle UDP sockets, TCP sockets, but also other protocols and more exotic things like netlink sockets, sctp sockets, and can be extended to things like John Ousterhout's proposal about replacing TCP, as evidenced by the fact that John Ousterhout actually implemented Homa on Linux. Using shared memory on Unix isn't exactly simple but that's because it's doing something complicated. When multiple processes want to share memory there needs to be some coordination to establish what needs to be mapped, to grant privileges, etc. The SysV shared memory APIs suck but on Linux things are much better now with the memfd system calls. And the vast majority of people who need things like sockets or shared memory are going to be writing code in a higher level language anyway, using libraries that abstract the low level details. The article implies that it's a problem that people need to use these abstractions in the first place, but it seems asinine to me when there isn't an actual proposal of how things would be better, and the hand waving completely ignores things like the fact that realistically low-level C APIs are needed to have any hope of writing interfaces that can be accessed by multiple languages. Furthermore the design of Unix allows new system calls to be added. If you have an idea for something that is way better than sockets you're free to implement it and add new system calls for it. This is exactly why there are many ways to do the same thing on Linux (e.g. establish shared memory regions), because people come up with new and better ideas and the ones that are actually performant, useful, and secure are the ones that get merged and added to Linux. Maybe there really are some brilliant ideas for new ways of doing things that need a ground-up redesign and can't be bolted onto Unix, but if that's the case people should be able to clearly elucidate what those ideas are and WHY they won't work with Unix. One final thing I'll say about Unix is that for all its warts, it's very fast. This is a point that's been made a million times before, e.g. in "Worse Is Better" and "The UNIX Hater's Handbook". There have been lots of interesting alternatives to Unix developed, but the reason none of them have taken traction is that at the end of the day no one wants to use something that is newer, less well known, less well tested, and significantly slower. Plan9 and Fuchsia are cool, but they are much slower than Linux and it's not clear if it's really possible to fix them. Users want their computer to run quickly, they want their phone to run quickly, and they want good battery life. Big companies want their applications to run quickly and spend as little on hardware as possible. All of these things mean that pretty much any Unix alternative is a non-starter unless it is at least close to the performance of existing Unix implementations, including Linux and macOS I suppose. A big explanation of the success of Unix has been that it has co-evolved alongside modern hardware. It's hard to do something that is radically different and takes advantage of modern hardware when you're writing a general purpose operating system (there are absolutely exceptions though for operating systems serving niche use cases).