💾 Archived View for soviet.circumlunar.space › pjvm › commentary › 000005-systemd-free.gmi captured on 2024-02-05 at 09:53:32. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
by pjvm
27-03-2023
commentary entry #1 (#5 overall)
Recently, I've read two posts about systemd-free distros:
This seems like a good jumping-off point for some things I've been wanting to discuss. I'll start with my thoughts on systemd, as somewhat of a reply to these two posts and the talk <1> they both link to. More importantly, I want to talk about s6.
After my first encounter with systemd (which I honestly cannot remember the details of) I started reading about it, found myself quite convinced by the arguments against it, and kind of joined the "systemd is evil" camp and eventually moved to a systemd-free distro.
If I had to describe what's wrong with systemd, it would be this: its high-level design is bad, leading to unbounded project scope and making it necessary to do "more rather than less" <2> at every lower level as well, and just generally a lot of questionable or ad-hoc decisions. This leads to a very large and complex software project, which consequently has lots of bugs, and all of those bugs are in the "system layer" which other software depends on. This is a risk: there many errors in a piece of software that occupies a critical place in the system. Debating the unix philosophy is really besides the point, but at least the principle of "do one thing and do it well" prevents this mess and the resulting potential for misery.
Granted, as long as you don't try to do special things, I'm sure the likelihood of systemd screwing things up for you is small. Still, I don't think I could ever go back: if I were to use a systemd distro again, typing `systemctl` would be a frustrating experience merely because of the knowledge that this important piece of software is badly designed. Of course most software I use does lots of questionable things and the best solution is to not use computers at all, but for e.g. the web browser I can at least try to use it without thinking about all the nonsense it's doing.
The current situation, with lots of distributions supporting only systemd, and a few distributions supporting alternative init systems, saddens me a little bit. JeanG3nie points out that there was a fear with systemd that it would completely become the only option, and gladly that hasn't happened. Still, a lot of effort goes into systemd-free distros simply because systemd has positioned itself as the default.
Because it is considered the default, systemd is what the new Linux users learn, what they will become comfortable with... and it all seems rather unideal, because it is a fundamentally flawed piece of software that should hopefully, eventually, be replaced. And the cost of replacing systemd may be so high that it will just never be done, even when a user-friendly alternative is ready.
But let's turn to the positive side: the joy of s6. s6 is what I use as my init system, or more precisely: s6 is process 1 and I use s6-rc as the service manager. I really like s6 (as well as other software by Laurent Bercot, aka skarnet), for reasons that I find a bit hard to describe.
I think one of the things is what JeanG3nie calls "a sort of transparency". Simply put: with skarnet's software I can understand the design. It is very clear from the documentation what exactly a program does, and the motivation for why it works in that way tends to be very clear. I know how the software works and I feel assured that the way it works is right.
This logical design also exists in the code itself. One time I had a question about the workings of s6-tlsd, and decided it would be an interesting project to try and figure out the answer by looking at the code. In this particular case it was more difficult to understand due to the interaction boundary with bearssl, but overall I've found the code to be rather readable.
One other thing I like about s6 and related software is that they really are tools. s6, for example, is not just usable as an init system component, but can also be used on a system with a different init system to monitor a set of daemons. Then there is execline, which as a scripting language is applicable to all sorts of problems. I've found it very nice to write my own execline scripts for various things, and I think the clarity of the design is one of the contributing factors.
All that said, s6 does have one drawback: it is pretty hard to get started with it. The main thing s6 (or rather, s6-rc) still lacks is an easy user interface. Fortunately, s6-rc is an ongoing project and work is planned to first implement "s6-rc v1", which will be able to act on external events, and then implement "s6-frontend" which will provide an easier UI.
project outline: "A new service manager for Linux distributions"
This was written quite a while ago, and further updates have not yet been posted. However, from discussions in the s6 irc channel, I know that work towards s6-rc v1 is starting to pick up some speed and will eventually be completed.
Partly through s6 I've discovered other small, well-designed tool projects. One collection of tools definitely worth checking out are the "leahutils" by Leah Neukirchen. There are many useful things in that collection but I want to give a little example of an s6 service that uses snooze.
snooze is a program that waits until the next time which satisfies certain conditions, then executes a command. In combination with a supervision system, such as s6, it can replace (ana)cron.
leahutils repository on github
The following is an example of how I use s6+s6-rc, a service that I'll denote ???. Maybe you can have a guess at what the name of the service is.
In the directory /etc/s6/sv/???/ , there are two files. The first is called `type`, and it only contains one line:
longrun
The second file, called `run`, contains the run script for this service:
#!/bin/execlineb snooze -H23,0-2 -M29,59 halt -p
To make a service actually run, you have to include it in whichever "service bundle" s6-rc is configured to always start (often this is a bundle called `default`), and update your services database, for which I use a script provided by my distribution. That script compiles the service and bundle definitions into a database and puts it at the location where s6-rc is configured to look.
When I switched to a systemd-free distribution, I chose Artix, and that's what I'm still using - s6 as an option is pretty rare among distros. My system has broken a few times, but so far I've managed to fix it, so I think I can live with the instability. I've never really used Artix' forums, so I cannot directly confirm JeanG3nie's experience there, but I did use to frequent Artix' irc channel and honestly, yes, from what I've seen Artix is pretty tolerant of assholery.
<1> About "The tragedy of systemd": though the general point of "learn from it instead of staying in your contempt-culture comfort zone" is good, I think this talk is rather biased towards systemd. The notion that systemd actually contains ideas which are both valuable and new is debatable. Rice doesn't consider the idea that "system layer" software, moreso than other software, should focus on being small and correct, and repeats several arguments that were more or less debunked before, for example in:
"Systemd: the biggest fallacies" (in particular: fallacies 1, 10, 11 and arguably 3)
<2> A phrase borrowed from skarnet, the author of s6:
I might as well add a link to his other writing on systemd (though I should note: he generally tries to avoid talking about systemd, because it is unproductive):