Except that it has barelly improved beyond CLI and daemons, still thinks terminals are the only hardware, everything else that matters isn't part of it, not even more modern networking protocols that aren't exposed in socket configurations.
The S3 API is a really good example of the “OSS only becomes dominant when development slows down” principle. As a friend of mine who has had to support a lot of local blob storage says, “On the gates of hell are emblazoned — S3 compatible.”
That's generally where open standards come from. You document an existing technology and then get independent implementations.
Unix was proprietary technology. POSIX is an open standard.
Even when the standard comes at the same time as the first implementation, it's usually because the first implementer wrote the standard -- there has to be one implementation before there are two.
Alongside a cloud shell, which yeah, we now have a VT100 running on a browser window.
There is a reason why there are USENIX papers on the loss of POSIX relevance.
Those things are a different level of abstraction. The cloud API is making POSIX system calls under the hood, which would allow the implementation of the cloud API to be ported to different POSIX-compatible systems (if anybody cared to).
> There is a reason why there are USENIX papers on the loss of POSIX relevance.
The main reason POSIX is less relevant is that everybody is using Linux and the point of POSIX was to create compatibility between all the different versions of proprietary Unix that have since fallen out of use.
Security and asynchronous servers are also hardly implemented with raw POSIX APIs.
POSIX also doesn't have anything to say about hypervisors, containers, kubernetes infrastructure, or unikernels.
Nor it says anything about infrastructure written in Go, Java, .NET, Rust, C++.
It's the same API. Some of the calls have OS-specific flags that can be passed as options. The way this often goes is that the flag then gets added to a future version of the standard.
> POSIX also doesn't have anything to say about hypervisors, containers, kubernetes infrastructure, or unikernels.
You keep listing different layers of abstraction. When the host goes to open the disk image file for the guest, pretty good chance it's using open(2) etc.
> Nor it says anything about infrastructure written in Go, Java, .NET, Rust, C++.
It's extremely common for C++ code to use C system calls directly, or thin wrappers around them, e.g. to have a socket class that calls close(2) in the destructor. Likewise for other languages:
https://docs.rs/posix-socket/latest/posix_socket/
You can say this "isn't POSIX" because the POSIX standard describes using it in C, but meanwhile the same library implementation and anything using it would be able to run on any POSIX system.
While POSIX was state of the art when it was invented, it shouldn't be today.
Lots of research was thrown in recycle bin because "Hey, we have POSIX, why reinvent the wheel?", up to the point that nobody wants to do operating systems research today, because they don't want their hard work to get thrown into the same recycle bin.
I think that people who invented POSIX were innovators and have they live today, they would come with a totally new paradigm, more fit to today's needs and knowledge.