Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
"What if we replace POSIX" is an interesting question. I keep coming back to SerenityOS [0] when I think about this topic, a C++ based (hobby) OS that has a POSIX compatible API but also more modern wrappers around common functionality.
Exposing system APIs like ErrorOr (like the Rust Result or the Maybe monad) resolves an entire class of bugs (take fork/kill/-1 as an example [1]) as well as ambiguity like "do I check the return value for the reason, or do I check the magical errno variable?". Dropping general OS compatibility also allows for other changes, like object oriented interaction with the GUI system and other system libraries instead of relying on having the namespacing happen in the name of a function call.
I know SerenityOS won't ever replace any operating system we use today, but it's a nice demonstration of the API features we could all be using.
Sometimes I wish Windows' APIs were more POSIX-like, but Win32 has some pretty useful functions built right into the OS that you'd need to introduce DLL/dependency hell/static compilation for if you're trying to stick to POSIX only APIs. Think common concepts like "the clipboard" or "the current resolution of a display" without needing to link to a library or access a file like /dev/fb0 (is there a /dev/fb1? when do you use it?).
Mobile platforms (Android, iOS) with special lifecycles also allow for things like "the app resumes where you left off" and "the app suspends to disk when the system is under load" natively without requiring developers to build their own save/restore state mechanisms. Imagine having to build a system like that on your average Linux desktop with mere POSIX APIs, you'd go crazy with the complexity required.
Perhaps what programs runnong on Unix-based operating systems really need is a wrapper around POSIX and its low-level implications. GTK and Qt provide many such APIs for free, for example, including stuff like networking and other I/O. GTK comes with its annoying particularities (CSD, and all the other GNOME decisions) and Qt licenses are either VERY free or VERY expensive, making them incompatible with other projects.
With the Linux space transitioning from SystemV+ALSA/Pulse+X11 to systemd+PipeWire+Wayland, perhaps the space is ripe for a new, more modern wrapper library for native languages.
[0]: https://github.com/SerenityOS/serenity
[1]: When fork() fails, the call returns a negative number. When you try to kill() a PID of -1, you kill every process your current UID has the permission to kill. Programs failing to fork, shutting down, and killing what they thought was a fork()ed process can accidentally end up killing all the open applications for a user.
Alternatives? While I somewhat agree with some points presented in the article, the POSIX model is beautiful in its simplicity. As a good demonstration, just take a look at Zeal 8-bit OS. It has a simplistic, Unix-inspired API [1], which is very elegant, especially considering the fact that the OS targets Z80 CPU with just 64 kB of RAM.
[1] https://github.com/Zeal8bit/Zeal-8-bit-OS#user-space