It feels like the broad Unix API is being used less these days

December 28, 2020

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:

By Todd at 2020-12-29 08:47:19:

This does seem to be a thing. There's way too much value in the Unix way of things to lose it, but respect for that could erode over time. I feel similarly about desktops being replaced by locked-up, un-fiddle-with-able smartphones and tablets. I don't want to lose the ecosystem of motherboards and daughterboards and cases you can take apart without voiding a warranty.

Written on 28 December 2020.
« A little puzzle with printf() and C argument passing
A Prometheus wish: easy ways to evaluate a PromQL query at a given time »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Dec 28 23:54:46 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.