# re: systemd-free
by pjvm
27-03-2023
log entry #4

Recently, I've read two posts about systemd-free distros:

=> //lesogorov.site/glogs/2303/Is-SystemD-free-really-for-me.gmi one by
Lesogorov
=> //gemini.hitchhiker-linux.org/gemlog/re_systemd-free.gmi one by JeanG3nie

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.

## from systemd hate...
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.

## ... to s6 joy
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.
=> https://skarnet.org/software/s6/ page for s6 on skarnet.org

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.
=> https://skarnet.com/projects/service-manager.html 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.
=> https://github.com/leahneukirchen/leahutils leahutils repository on github

### example: "cool little life hack"
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.

## sidenote on Artix
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:
=> https://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html
"Systemd: the biggest fallacies" (in particular: fallacies 1, 10, 11 and
arguably 3)

<2> A phrase borrowed from skarnet, the author of s6:
=> https://skarnet.org/software/systemd.html "A word about systemd"
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):
=> https://skarnet.org/lists/supervision/0422.html Post by Laurent Bercot on
the "supervision" mailing list

You are viewing proxied material from soviet.circumlunar.space. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.