Linux distros without systemd

Full disclosure: I'm a systemd skeptic.

The problem is basically that Linux used to be about choice (choose your distro! choose your DE! choose your shell! choose your browser!) but now that it's become big business, large corporations like Red Hat (developer of systemd) have transformed the evolution of Linux from a bottom-up consensus system to a top-down "we develop all the stuff you use and now it all uses our stuff so now you do too" approach. It's _very_ hard for me to build a system without systemd; I can use a niche Linux distro, I can use a BSD, or I can hack another init system (etc.) in myself. None of those are satisfying, I think for obvious reasons.

systemd is not well written, and it is not well designed. Its style and architecture are inconsistent. Parsing is mixed with validation and business logic. The types of CVEs its generated show that there was no coherent thought put into input validation, fuzzing, taint analysis, and so on. The effects of those flaws (your whole system crashes, etc.) show that failure strategies were never considered. And if all that sounds like overkill to you, maybe it is! But I can tell you that these techniques and design strategies are employed by experts to build software that must be robust, like software that controls medical equipment or transportation control systems. We know how to build software that works and that mitigates failures. Looking at systemd's code, it's clear they used none of that knowledge. And that, combined with its sprawling control over my system, makes me not want it on my machines.

I actually really like systemd's service files, and the functionality it provides. I like the ability to express dependencies clearly, the fine-grained control over server restart behavior, and a ton of other systemd features. I'm also very happy to see it replace cron.

What I _do not_ like are:

  - systemd-resolved
  - systemd-networkd
  - systemd taking over disk mounts
  - systemctl
  - unit files spread out all over the place
  - mandatory journald
  - mandatory dbus
  - only works on Linux
  - pushing the BSDs farther towards being obsolete

I'm very glad to see sysv-init on the way out, personally. I think systemd unit files are a huge improvement, and greatly improve standardization and init quality. But that doesn't intrinsically mean that the systemd project is doing the right thing.

I'm a big fan of systemd.

Comprehensive, well organized, reliable, powerful.

It makes a consistent service from what was an evolutionary hotchpotch of stuff.

Whatever it is that the haters hate, I don't get.

No, that's not explicit. That's a few instances of "like launchd". Where M. Poettering actually is explicit about inspiration, xe writes the words:

> we took a lot of inspiration from Upstart's code-base

... which they actually did and continued to do, from observation. There were significant discussions amongst the systemd people involving the way that things worked with Upstart, including (for just three examples out of the many over the years) having to work like Upstart with respect to putting the X server on the first KVT, Upstart's handling of SIGPWR to process #1, and eliminating /dev/initctl because it was not really utilized in Upstart.

* https://news.ycombinator.com/item?id=12772915

* https://lists.freedesktop.org/archives/systemd-devel/2016-Ju...

* https://lists.freedesktop.org/archives/systemd-devel/2015-Se...

In comparison, there was almost zero similar consideration of launchd. The idea that launchd inspired systemd is a myth, not borne out by what M. Poettering explicitly wrote was the inspiration nor borne out by the evidence of what the systemd people did down the years.

I have way too many cases of systemd startup items hanging with their timeout for no good reason.

Worse, my most complicated high-uptime machine usually does not shut down in a reasonable time. Systemd says "waiting for session user cracauer" (something like it) for whatever reason. It also hung on undoing swapspace, when that swapspace was a custom stack of block layers. I don't need swapspace to be "shut down". It went into 20 minutes something always stating another timeout when one expired. I mean, WTF?

The problem here is that I had to do an unclean shutdown on that machine (reset button) multiple times, and that I really can't have.

This also illustrates a point I have been making about Linux and the BSDs from day one: When the BSDs boot or shut down the keyboard is connected to the rc scripts. You can do Control-C for SIGINT and Control-\ for SIGQUIT, The latter makes everybody in the stack leave a coredump on disk.

Now, compare these two:

1) in BSD when there is a startup or shutdown item taking too long or hanging I can abort that single item and I can later debug what was going on with the coredumps.

2) on a Linux system with systemd I cannot "cut through" startup or shutdown items I don't want to wait for, and there is no way to debug any of that if the machine doesn't actually come up completely, or if thing happen at shutdown. The only interaction I can conduct is the reset button.

To add insult to injury, systemd also hides a lot of error messages that would traditionally be dumped on the console, and instead of giving me that error message systemd captures it and print on the screen instructions how to get that error message (which usually are longer than the error message was, WTF?). Instructions that I cannot follow because somebody detached my keyboard, and because I will never be in that machine in an up state while that context is available.

This also invalidates the point that systemd could be one platform that you learn once and then use on a wide basis. The debugging abilities are nowhere close to adequate, so you have to learn by try-n-error.