New Group Threatens To Fork Debian
Yet another team of self described “veteran unix admins” and developers are planning to fork Debian if the project goes ahead with plans to replace sysvinit with systemd. Debian introduced systemd as a technical preview in Wheezy in May of last year, following Fedora and several other distributions. The threat to fork Debian reflects the increasingly heated debate surrounding a fundamental shift in system philosophy. Do one thing and do it well? Or, one daemon to rule them all?
The Wikipedia page contains a succinct explanation of systemd:
The developers of systemd aimed to replace the Linux init system inherited from UNIX System V and Berkeley Software Distribution (BSD) operating systems. Like init, systemd is a daemon that manages other daemons. All daemons, including systemd, are background processes. Systemd is the first daemon to start (during booting) and the last daemon to terminate (during shutdown).
Lennart Poettering and Kay Sievers, software engineers that initially developed systemd,1 sought to surpass the efficiency of the init daemon in several ways. They wanted to improve the software framework for expressing dependencies, to allow more processing to be done concurrently or in parallel during system booting, and to reduce the computational overhead of the shell.
Traditionally, the init daemon, process id (pid) 1, is the first daemon started by the kernel and is responsible for starting and being the parent pid for, all other daemons. This is a special responsibility, and the init code has been refined over many years. During the boot process, the init daemon reads a config file, and runs a defined series of shell scripts. The process is fairly transparent, and allows fine-grained user control. It is the loss of this control, and the potential for code bloat in systemd, that has many sysadmins concerned about the future of their favorite distribution.
To paraphrase Eric S. Raymond on the issue, we see systemd being very prone to mission creep and bloat and likely to turn into a nasty hairball over the longer term.
We like controlling the startup of the system with shell scripts that are readable, because readability grants a certain level of power and consciousness for those among us who are literate, and we believe that centralizing control services, sockets, devices, mounts, etc., all within one daemon is a slap in the face of the UNIX philosophy.
On one side, systemd allows for faster boot time, and centralized control of system level services. On the other hand, it is far more in line with the Unix philosophy to split responsibilities between several distinct services that interoperate through a standard method. If the future of systems administration is for the majority of us to grow into automation expert roles, especially when the majority of our interaction with systems in the future may very well be light-weight containers, it makes sense to keep as low level, fine grained control over the system as possible.
Beyond philosophical debates, the boycott systemd page has a list of issues that are concerning, to say the least. Binary logs and tight coupling with kernel versions are red flags to me. On the other hand, the 0pointer blog has a lengthly explanation of the how’s and why’s behind the project. Personally, I’m still undecided, but lean towards keeping with what I know in init. I also recognize how that tendency can be a handicap, and am trying to keep an open mind. Regardless of which side of the fence you come down on, the outcome of this debate is sure to have long-lasting effects on the community and the sysadmin field.