Systemd is both good and bad.

The good part is that it allows for parallel service startup, which means that your system gets up and running (and serving useful work) faster. It understands the service dependency graph and thus the service start order and what can be done simultaneously. It also, in theory anyway, makes life a little easier for the authors of what I'll call "service software" (read: daemons and servers): need a privileged resource? Describe it to systemd, that will then acquire it for you and hand it to your unprivileged service software. That's nifty, aids privilege separation, namespace sandboxing a la containers, etc.

But systemd is also terrible. In an extremely un-Unix-like manner, it consolidates an enormous number of disparate functions into a single monolithic piece of software. It uses ersatz data formats that are abjectly horrible. It uses binary logging, which means that one cannot use the full complement of Unix text filters to inspect logs. It does all sorts of stuff behind the scenes (manipulating filesystems, for example) in ways that are obscured and opaque to system administrators, let alone programmers; this can have surprising results (ask Ron Minnich about systemd-related data loss). It has complete disregard, and indeed, contempt for the Unix philosophy.

What's interesting (to me, anyway), is how few people care about the deficiencies. This suggests a pretty fundamental shift in how people use Unix-like systems, and Linux in particular: for _most_ users, it has become a commoditized vessel for running other interesting software, but not what we historically think of as "Unix". Sure, a lot of people still live at the command line, but that's no longer the primary focus of interaction. Our machines are now either all-singing, all-dancing multimedia workstations where the sole user is in a web browser most of the time, in which case the underlying system is just a detail, they're server-class machines that are running some workload, but not something that's interactive, or embedded devices that are black boxes.

Much of Unix's early evolution and thus architecture and philosophy, came from addressing a set of problems that people had in a historical context that, one could argue, aren't that relevant anymore. A hierarchical filesystem in a global namespace, pipelines facilitating chaining of filters for interactive use, a simple but weak permissions model, unstructured text as a universal interchange format, terminal-oriented text editors.... All of these were fine on shared multiuser interactive machines, but do they matter as much now? If the nexus of interaction is a web browser, who cares whether I can grep a log file? If I just want my bluetooth headphones and USB camera to work for an online meeting, how that stuff is put together under the hood isn't that interesting to me. In short, the Unix philosophy is becoming less and less relevant as a new generation of users and programmers put different demands on systems. Linux is _probably_ the most prevalent kernel in the world, but most places its used it's hidden from view. In that context, something like systemd actually makes some amount of sense.

Perhaps I've mentioned this story before: a former colleague at Google was writing a shell script to figure something out. It wasn't working. Really, what he wanted was basically a `grep -q` and an `if` statement, but he'd written a complicated mess with shell functions that tried to "return" the exit status of the processes they ran: his shell script was written more like a Python program. I rewrote it for him in half-a-dozen or so lines (down from 30 or 40) and talked about Unix for a minute, the philosophy, etc. At the end of my monologue extolling the virtues of our style of computing, he looked at me blankly and said something along the lines of, "yeah. I think that time has passed and people just don't conceptualize problems that way anymore." I was sad, but is it any wonder that the kids reach for Python before a shell script these days? We aren't teaching, yes, but moreover they don't want to learn because the problems they're trying to solve are different. We need to accept and internalize that and think hard about how the tools we use can be brought to bear on the problems that are relevant _now_, not 30 years ago.

It does beg the question: is a Unix-style kernel still the appropriate foundation for this style of computing? Why are we still using this system: is it because of its intrinsic power and versatility, or because of inertia? Systemd, containers, etc, all suggest that our models are inadequate.

        - Dan C.