It feels like the broad Unix API is being used less these days
A few years ago I wrote about how the practical Unix API is broader than system calls and how the value locked up in the broad Unix API made it pretty durable. I still believe that in one way, but at the same time I've wound up feeling that a lot of modern software development and deployment practices are causing the broad Unix API to be less and less used and useful. What I'm specifically thinking about here is containers.
If you're logging in to a Unix machine and using it, elements of
the broad Unix API like $HOME
and /tmp
matter to you. But for
a container (or for deploying a container), they often don't.
Containers deliberately ask much less of the host than the broad
Unix API (that's one of their features), and to the extent that software
inside a container uses the broad API, it's using a sham version
that was custom assembled for it. My impression is that some of
this shift is social, in attitudes about how container-ized software
should be put together and what it should use and assume. To put
it one way, I don't think it would be seen as a good thing to use
a bunch of shell scripts in a container. Containers aren't general
purpose Unix systems and people don't write software for them as if
they were.
Right now I don't think this is a significant force in the parts of the broad Unix world that I notice, one big enough to be changing Unix as a whole. There are plenty of people still running and deploying traditional Unix systems (including us), and then putting software straight onto such systems (without containers). These people are all using the broad Unix API and exerting a quiet pressure on software to still support (and use) it, instead of requiring containers or at least some emulation of them (although you can find software that really doesn't want to be deployed 'simply', ie outside a container).
One part of this is likely that Unix remains more than Linux, although not everyone really believes this. Right now containers are fairly strongly tied to Linux for various reasons, so if you write container-only software you're implicitly writing Linux only software. My impression is that many open source projects aren't willing to tie themselves down like this.
Of course, there's also a lot of Unix software that isn't the sort of thing you put in containers in the first place, or at least not in conventional containers (Linux has Flatpaks and Snaps for more interactive applications, but they're not very popular). This software is using the broad Unix API when it arranges to install manpages, support files, and so on in the standard locations. It can also sometimes take advantage of standard services and standard integrations with other software (for example Certbot and other Let's Encrypt automation, which cooperate with various daemons to give them TLS certificates).
Comments on this page:
|
|