Systemd – for better or worse

Systemd hopes to simplify the growing number of processes across Linux distributions. It’s a worthy goal, but things are never that simple...

The average Linux user can be forgiven for being mystified by the passion and anger that surround the arguments over systemd, which aims to replace the traditional init daemon and shell scripts that initialise a Linux installation. Shell scripts are the tried and trusted method by which the Linux kernel is instructed on the options for its startup processes, and are seen by many sysadmins as ‘the Unix way’ of doing things. Scripts can be changed at will and the kernel doesn’t need a reboot.

Times change. As Linux has become more popular the number of subsystems and processes have multiplied and diversified. Some make conflicting demands on the kernel. A mobile or embedded device has very different expectations to a dedicated server and each implementation has its own demands. Some of the controversies surrounding systemd have come into focus because the Gnome developers have seen an integrated startup procedure as essential to the wellbeing of future implementations of Gnome. Similar arguments apply to Wayland and other subsystems.

Most developers are agreed that a tidier, more consistent and faster boot time for Linux is desirable. Systemd hopes to simplify and regularise the configuration of the growing number of subsystems and processes across Linux distributions. The hope is that this will make life easier for everybody – developers, distributions, device manufacturers and Linux administrators. Of course, it’s not that easy.

Rather than minimising the number of processes it controls systemd has become, in the words of one sceptical LWN commenter, “init system, device manager, login manager, cron, DNS resolver, console terminal emulator, package manager, kitchen sink, slopbucket, API breaker.” The complaint is that systemd is monolithic, and monolithic control systems with one point of failure have never been the Unix, or Linux, way of doing things. This is the kind of issue that has dogged Microsoft operating systems, where the failure of one process can bring down the whole system. Patrick Volkerding, Slackware developer, puts it succinctly:

“I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I’m guessing that’s what most Slackware users prefer too. I don’t spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc, all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well.”

Changes in the Linux community are often dogged by controversy, sometimes justified, sometimes not, as Gnome and Wayland developers have discovered in recent times. Kernel developers have joined in on both sides of the argument. Most distributions have opted for systemd, among them Debian and Ubuntu, which, in any case, had been using its own startup procedure. Debian’s choice of systemd as the default option for startup was put to a democratic vote, and sysvinit remains an option. Nonetheless, a group of Debian Developers, styling themselves the Veteran Unix Admins, have announced a fork of Debian to be known as Devuan. Devuan will be Debian without systemd, and the developers’ unlikely ambition is to replicate the Debian development and maintenance environment from scratch.

Free software communities hope to be open and democratic. Some are more so than others. Debian developers are known for their willingness to down tools in defence of the principles that keep their community together. Developers are passionate about right and wrong ways of doing things and technical differences sometimes spill over into personal animosity and hyperbole. Antagonists on both sides of the argument become entrenched and harden their positions, and it becomes more difficult to disentangle the real issues from the imagined and personal, and just as difficult to find a compromise.

Most developers know when a piece of software has reached the end of its useful life. Gnome had to be rationalised because the bits had begun to fall apart at the seams. X was 20 years out of date and entirely dysfunctional, and in an increasingly complex world of conflicting subsystems and processes, a new ignition system was required for the Linux kernel. The alternatives may be imperfect, but time and refinement will tell whether the right decisions have been made.