Meta(
    title: "Re: Systemd-free",
    summary: Some("My own thoughts and experiences with various init and supervision suites"),
    published: Some(Time(
        year: 2023,
        month: 3,
        day: 26,
        hour: 3,
        minute: 38,
        second: 4,
    )),
    tags: [
        "systemd",
        "void",
        "runit",
        "s6",
    ],
)
---
There's a recent post by Lesogorov about SystemD-free distros that's worth a read if this sort of thing interests you.
=> gemini://lesogorov.site/glogs/2303/Is-SystemD-free-really-for-me.gmi

## My own experience
I started with Linux quite a while before SystemD, ran it almost exclusively for a few years, then switched to FreeBSD for a number of years. SystemD appeared in the major distros around the time I was considering switching back to Linux (for unrelated reasons). In my first stint with Linux, I was often using distros which were anything but mainline. Puppy Linux in particular never gets enough credit for the out of the box thinking that has gone into it over the years, and system initialization is no different. Some of the unique features that distro pioneered would never have been possible with SystemD.

I was also a Slackware user, and that distro is often described as having a very "BSD" style init. This is an arguable point. Under the hood, they run plain oldschool SysV Init, but with a custom set of scripts that have always been different than what the other distros used, even prior to SystemD. They're also dramatically sympler than actual BSD init scripts.

When I came back to Linux from FreeBSD, it was to Arch. This was shortly after Arch moved to SystemD, and right during the height of the controversy. At the time, I was only mildly interested. In fact, I remember being mostly positive about the change at the time, as it was new and interesting for one. Also, after years of being on FreeBSD the speedup in boot times was immediately evident. I'm a little less keen on it now, but I've never been entirely in the "SystemD is Evil" camp.

## More recently
Around 2017 I started migrating away from using old crappy X86 desktops as home servers to a small army of Raspberry Pi's. I immediately ran into a few SystemD related issues that somewhat soured my feelings towards it.

My plan was to have use a 2TB external spinning rust drive mounted on /home as my main data store. Just adding the disks UUID to /etc/fstab brought up a consistent problem on every reboot. The heart of the issue is that SystemD was attempting to mount all disks before that disk had even finished spinning up, causing the mount to fail because the kernel didn't even know the disk existed yet. This caused you to get dropped to a prompt almost every time, which ruined my idea of being able to administer those machines over SSH because I had to be physically present to babysit the boot process. Now, back in the day distros dealt with issues like this by using ugly hacks such as adding a "sleep" command to the script to give an interface time to become available. This was never a real fix of course. But my feeling is that this sort of thing shouldn't be happening. SystemD was supposed to be more reliable, after all, not less.

I did find a workaround of course, because the Arch Wiki is amazing like that. But then I ran into another issue when a new install began showing intermittent networking issues. It seems that SystemD was by default managing my DNS, and the /etc/resolv.conf that I had purposely written was just overwritten by a symlink to a file that I can only describe as ridiculous. Now, for those who aren't old hands at this let me explain. /etc/resolv.conf is a one or two line file. Each line has an IP address for a name server. Unless you are doing something fancy like Dnssec there's no reason for it to be more complicated than that. There's also no excuse for a system to overwrite a config file that the admin has purposely placed. I had to search quite a bit for a way to turn of this particular "feature" so that I could administer my system in a way I'm used to and comfortable with. It was also what got me looking for alternatives.

I ran Artix for a while. Artix is a fork of Arch and at the time even used the Arch repositories, but with their own repositories as an overlay. I used the S6 version for about a year. It was OK, and if they'd stuck with just replacing the init system I might have stuck with it. One of the reasons I like Arch is that they deliver packages as they came from upstream, without extra customization and theming. Artix broke with that tradition, and it took a lot of work to scrub their theming from the system and get things looking the way I wanted. I never completely accomplished it, either, because I couldn't get a working dark theme in Plasma due to fonts disappearing into the background in certain places. I also discovered that their support forum has some true assholes not just in it but administering it. Then one day an update caused the boot to drop me to a prompt, and I was done.

I've since found Void. I am extremely positive about Void. It's not perfect, but it really is very good. I love that it uses Musl libc. It uses Runit for init and process supervision, which is crazy simple. I prefer S6 but they are very similar. It's also a rolling release like Arch, but with a slower release cadence. I've kept it around as a dual boot on one of my laptops, and it also runs this server.

> As an aside, Runit and S6 are both descended from Daniel J Bernstein's Daemontools process supervision suite. As such they are very similar. The biggest difference is that Runit is largely just a reimplementation of Daemontools with more modern code, while S6 brings in additional functionality such as proper dependency ordering for service startup, one shot service definitions, a standardized logging interface and a rather complete set of management tools over top. I use S6 in HitchHiker. It's great, and I wish that more distros used it.

## What about Alpine?
I've got Alpine in a VM for evaluation. I have to say, I'm totally impressed. I can see this replacing Arch as my development environment because it's actually up to date (Void lags just enough to annoy me) and it is also Musl libc based. There are a couple things I'm not entirely happy with though. I don't particularly care for BusyBox, as I've seen the code, and I'm also not entirely happy with the way packages are split. You can run `apk add docs` and it will always install the documentation packages alongside the binaries, but there isn't an equivalent for development headers. That makes the initial setup a little more painful. But the apk package manager is among the best I've seen, and there are a number of nice little value adds in the way of setup uptilities.

## The tragedy
I love that the post linked above mentioned Benno Rice's talk, the tragedy of SystemD. Benno Rice is a great speaker and if you enjoy technical talks I highly recommend that talk along with his What Unix Cost Us talk.
=> https://www.youtube.com/watch?v=9-IWMbJXoLM

Now, I don't agree with all of the conclusions in those two talks, but they are great food for though and bring up some great points. In particular, there is a tendency (particularly among the old timers) to take Unix way to seriously, with an almost religeous ferver. This is not a great tendency. I'd point out that Unix was originally brought up in large part because Ken Thompson needed an OS to run his Space Travel video game on the PDP-7. A few collaborators, notably Dennis Ritchie, who were frustrated with how large Multics had grown, chipped in and it took off. Unix grew organically. It wasn't planned, and it shows. In fact this is exactly the same criticism I levy against the C programming language, which was created in an ad-hoc manner by various people with no clear vision over a number of years. The lack of a plan shows in both projects, and it's telling that C was an offshoot of Unix.

Anyway, I don't actually hate SystemD. I am hoping that at some point in time we get something better, preferably something simpler. My biggest points of contention with it are a sort of lack of transparency. SysV Init, at least the way most distros implemented it, had a lot of drawbacks and a lot of kludges. But it was possible to wrap your head around what it was doing. I love the modern supervision suites Runit and S6. Much like SysV Init they use mostly scripts to bring the system up, they just do a better job of breaking it into manageable pieces and running things in parallel where possible. But until someone creates a more unified frontend I don't see that way catching on with the masses.

Would I recommend a non-systemD distro? Depends. If a person has a bit of experience Void makes a great server and a decent desktop. I actually think Alpine makes a great desktop, but you have to have some knowhow to bring it up. I wouldn't recomment Artix. There's a few that I haven't tried. My own project, HitchHiker, is not exactly ready for casual users because I'm not happy with the software packaging situation yet (although I'm working on this). Out of the lot I'd be most inclined to recommend Void, but probably not to just anyone.

I'm also a big proponent of people using whatever they're comfortable with. That includes SystemD. As long as it is still possible to run Linux another way I'm fine with most distros using it. In the early days one of the huge complaints was that as it swallowed up more and more functionality that became harder and harder to do, and the fear was that eventually the SystemD way would be the only way. But it's been years now and frankly that hasn't happened (although it possibly could have if not for the work that Gentoo has put in maintaining Eudev, among other things). So basically I'd have to say that all of the hysteria back in the day was just that. We still have choices, and that is a Good Thing.