Why systemd is still divisive after all these years

Write a better one.

"Be the change that you wish to see in the world."- Gandhi (maybe)

I get that not all people want to use the whole systemd family of tools, but comparing line counts like this is ridiculous and unproductive.

The UNIX philosophy is theoretically "do one thing and do it well", but in practice means "create small, composable pieces which can be used together or separately to accomplish what you need."

"systemd" the project is certainly huge and all-encompassing, but you could say the same thing about GNOME, the GNU project, or even GCC itself. The systemd project, however, is divided up into a ton of smaller components, all of which are relatively easy to understand in isolation and which almost universally have clear interoperations with each other.

Case in point: systemd ships two components, systemd-networkd and systemd-resolved. I typically reconfigure my systems to use these, as I find the documentation simple to understand and the config file easy to write by hand, even from memory. Compare this to, say, netplan, which I've never actually googled a full list of options for.

That said, both of them are optional, and Ubuntu 16.04 for example used systemd in what was apparently as few places as possible, notably not using systemd-networkd or systemd-resolved. They were easy to enable and use, but they were by no means necessary.

LIkewise, systemd ships systemd-machined, a framework for creating "machines", which are containerized systems which operate like virtualized systems, with their own copy of (probably) systemd running inside.

The systemd tools, like systemctl and journalctl, can interact directly with these machines, meaning that you can use the same tools on the same command-lines to access what is effectively a "containerized" system's logs in the same way that you would locally. Likewise, systemd-networkd has configuration to automatically bring up their network configs as soon as they're created, without having to do anything manually. Again, it's not shipped by default and definitely not enabled by default.

In this way, I would say that systemd actually embodies the so-called "UNIX philosophy", by creating a bunch of separate daemons and systems, all of which can work well together but few of which are inherently required by each other. It also adds a ton of functionality which is effectively impossible to add to existing init.d systems in any maintainable way (like spawning processes in their own cgroups and namespaces, creating ephemeral users with arbitrary UIDs for those processes, creating private /tmp directories for individual services, adding bind mounts, restricting syscalls, mounting the root filesystem read only, and so on.

In essence, systemd gives you all the tools you need to build up whatever system management you want, but if you just want "execute this binary, which will not fork, and keep it running" then you can do that too, without any of those extra features getting in the way.

I'd start by adding an optional priority number to each unit, which if supplied would form an ordering that units were always executed in. A unit having the priority number should also be less likely to be chosen for dropping, as they'd likely to be distribution-supplied units that were better debugged. This would make it much easier to narrow down the source of a logical conflict, and drop sensible units.

That only addresses the one gripe I brought up as an example though, and not the general pattern. For instance another issue I've run into is this automagical hacks that parse fstab crypttab etc and make units at boot time, while not actually supporting all the customary options of those files.

In general it feels like if systemd were written in a modern language, traditional distribution responsibilities (eg initrd/cryptoroot) could have been comprehensively replaced. But instead they bit off more than they could chew in C, so completeness and elegance were cast aside, and we're left with a hodgepodge of the old and new systems.

Who gets the work done wins, even if it isn't the best solution.