Devuan progress report

Systemd is orders of magnitude more complex than it needs to be.

If you compare systemd with the hodgepodge of stuff it replaces, it is a lot less complex than the sum total of the various bits that need to come together to do the same thing. For example, in systemd there is a unified and reasonably sane format for configuration files, as opposed to the wild zoo of file formats, no two of which are the same, that the traditional setup uses. In addition, systemd has robust facilities to separate configuration defaults provided by the distribution from local customisations – which is something that the traditional setup doesn't address at all, but which is well worth a reasonable amount of “complexity”. If anything, the traditional setup usually sidesteps that sort of thing by off-loading it to the shell, which in itself is a fairly complex piece of engineering (especially if, as in many distributions, it is the Bourne-again shell), and this leads to setups that, being procedural rather than declarative as in systemd, are harder to maintain and more difficult to update as well as generally less featureful – if you want any fancy stuff you get to implement it yourself (and to figure out how to maintain it in a sustainable manner in the face of distribution updates), and that again increases complexity because other people need to figure out exactly what you have done, instead of relying on the common and well-documented infrastructure afforded by systemd.

Generally, in systemd, the components work together a lot better than in the traditional setup. In the traditional setup, a basic facility like the launching of service processes is implemented in half a dozen different ways depending on whether it is init doing the launching (via /etc/inittab or an init script), (x)inetd, cron, or at, where systemd basically does it one way, with the same configuration options everywhere, and much less superfluous duplication of code.

The traditional setup looks less complex because much of the complexity is pushed into the service processes. For example, with System-V init, a process like Apache or BIND is responsible for its own “daemonisation” – it needs to go through an intricate song-and-dance routine to ensure that it is a direct child of PID 1, all its standard I/O channels are closed, etc. The code to do this is basically reinvented over and over again in every daemon, with different features and configuration methods. Systemd reasonably offers this as part of the basic infrastructure so the authors of service processes no longer need to reinvent the wheel, and systemd affords lots of very powerful resource management and security options that the authors of service processes usually do not bother to implement at all. Putting them all into systemd ensures that this infrastructure is audited, debugged, and documented a lot better than if it is left to the implementers of individual background services, and any bugs can be fixed once in one place.

To sum up, “systemd is way too complex” is a short-sighted argument that neglects the fact that pulling common basic functionality out into the underlying infrastructure may make that infrastructure somewhat more complex but will often considerably simplify the rest of the system. There is a reason why, e.g., the C library includes routines like “printf()”, which is a very complex and versatile function that few if any programs use to its full extent, but which would otherwise have to be reinvented in an incompatible (and probably buggy) manner by any program that wanted to do formatted output. Systemd is, at first sight, more complex than something like System-V init, which can afford to be very simple because it does basically nothing. Systemd is not more complex than the mess of things it replaces, which includes components like inetd, cron, and loads of non-standardised distribution-specific bits and pieces that work together more by accident than by design.

Systemd is many orders of magnitude simpler (in code, in management) than the half-baked mess of traditional "solutions" around sysvinit, cron, xinetd et al with their collection of shell scripts requiring a slew of user-level tools like grep (which thus bring their own vulnerabilities into the fold). Yes, systemd in itself is more complex than any one of the basic tools, but you have to consider the whole. That a small group of self-proclaimed Veteran Unix Sysadmins are virulently opposed to systemd doesn't diminish the fact that all large Linux distributions took it up as default in a remarkably short time (they are used in their day-to-day work building the exact same distributions by veteran sysadmins, who certainly have a voice in those kind of decisions) and which are being gratefully accepted by droves of users all around the world.