Ask Slashdot: Practical Alternatives To Systemd?

First time accepted submitter systemDead (3645325) writes "I looked mostly with disinterest at Debian's decision last February to switch to systemd as the default init system for their future operating system releases. The Debian GNU/Linux distribution is, after all, famous for allowing users greater freedom to choose what system components they want to install. This appeared to be the case with the init system, given the presence of packages such as sysvinit-core, upstart, and even openrc as alternatives to systemd.

Unfortunately, while still theoretically possible, installing an alternative init system means doing without a number of useful, even essential system programs. By design, systemd appears to be a full-blown everything-including-the-kitchen-sink solution to the relatively simple problem of starting up a Unix-like system. Systemd, for example, is a hard-coded dependency for installing Network Manager, probably the most user-friendly way for a desktop Linux system to connect to a wireless or wired network. Just this week, I woke up to find out that systemd had become a dependency for running PolicyKit, the suite of programs responsible for user privileges and permissions in a typical Linux desktop.

I was able to replace Network Manager with connman, a lightweight program originally developed for mobile devices. But with systemd infecting even the PolicyKit framework, I find myself faced with a dilemma. Should I just let systemd take over my entire system, or should I retreat to my old terminal-based computing in the hope that the horde of the systemDead don't take over the Linux kernel itself?

What are your plans for working with or working around systemd? Are there any mainstream GNU/Linux distros that haven't adopted and have no plans of migrating to systemd? Or is migrating to one of the bigger BSD systems the better and more future-proof solution?"

Comments

Re:Accept, don't fight, systemd

[t_hunger]

The problem is: A *tiny* init process won't be able to offer the *exactly same* functionality. The functionality has to come from somewhere, it does not fall from the sky: Some code needs to implement it.

If you want to keep PID 1 tiny then you can implement the actual functionality in separate processes. You now have two or more process and now you need code in the tiny init process that makes sure the controlling processes are getting started (and restarted). Remember: Those daemons provide the actual functionality, so PID1 can not depend on that to start those daemons in the first place.

You need code that facilitates a communication channel between the processes. You need code to lock out processes that are not meant to talk to your tiny init process. You need a protocol that the init process speaks and that allows it to be remote-controlled. All of sudden that tiny process is no longer tiny and your architecture is much more complex than it would be otherwise.

That complexity requires you to add more code to mitigate communication failures, to synchronize data structures between all the different processes that need access to them, you need to be careful not to introduce race conditions between those processes. In the end you end up with a pretty big init process and a bunch of big and nearly equally critical daemons surrounding it. I do understand where the systemd guys come from: Keep the architecture simple, and put absolute minimum amount of code into PID1 to provide the functionality they want. That makes the overall system less complex and easier to reason about, which is good for security and robustness.

Read the code, it is actually pretty ok.