systemd: Denial or just alternative ways?

We are surely aware about the criticism towards systemd as project. But this article should not only be focussed onto that and be therefore more oriented towards our reasoning for a system beyond using only bloated packages and frameworks. So we could now list for sure many reasons why we stay critical towards the adaption for systemd as basic init-framework, but we want to provide a complete picture.

Introduction

systemd was initially first started back in 2010 as a project to replace the conventional System V init. It was then developed further to be now a “software suite providing an array of system components for GNU/Linux”. And with this short but fitting description there is the first major issue as the project is only aiming towards GNU/Linux as basic and is very much more than a pure init-startup for the operating-system. It provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging.

As Hyperbola is created as pure lightweight system the orientation of systemd is not following the Social Contract to respect modular and lightweight design. This was announced within 2017 in a dedicated news-entry.

With the essential design-decision being just more than only init and management systemd has also included more attack surfaces and further security-issues. To be mentioned there are dereferencing null pointers (Issue 5998), or writing out of bounds, or not supporting fully qualified domain names, or giving root privileges to any user whose name begins with a number (Issue 6237). Yes, all of them solved or handled in other ways. But a big codebase of a project like systemd is staying also complete intransparent for everyone with not a big amount of time and the reaction of maintainers behind the project are also not that kind of helpful: Communication is a basic element for a good project oriented onto technical emancipation as this is the absolute basic for free culture and free, libre software on its own.

Back and forth: The role of init-systems

There are different approaches followed by the different systems and distributions. Nevertheless the key-role of an init-system is just to start the basic system and initialize the services. Afterwards it is about a supervisor to look behind the services running and removing those crashed (Broken by design: systemd) .

Again the size and the understanding of systemd in a whole is here the major point for issues: Too many components integrated, too many design-flaws within and too less transparency. Hyperbola has chosen for a reason to follow strict the Filesystem Hierarchy Standard. It would not be possible with adaption of systemd and leaving a complete mess for a structured, lightweight operating-system to follow the Unix philosophy. Therefore the conclusion to follow the Init Freedom Campaign.

Points for criticism in detail

We will never address criticism making usage of personal attacks as we conclude neither being unfair nor using false argumentation methods. Besides there are many points to be found making it further a problem to use systemd for any system with lightweight focus.

Breaking promises

“After udev is merged into the systemd tree you can still build it for usage outside of systemd systems, and we will support these builds officially. In fact, we will be supporting this for a long time” http://article.gmane.org/gmane.linux.hotplug.devel/17392

”…this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. 'Gentoo folks, this is your wakeup call.'“ http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html

“kdbus support is no longer compile-time optional … We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled.” http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html

Stability failed

“Starting with version 26 (the first version released with Fedora 15) we promise to keep a number of them stable and compatible for the future.” http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/

This stability promise was broken as one of their promises is for the export format: This is not true for version 44 of systemd for example!

Conclusion for the Hyperbola-project

With the retrospective of all the points listed here Hyperbola has the stance not to accept systemd. It is just the point that there are better alternatives fitting within the approach of a lightweight and stable context for a modern operating-system based on the essentials of the Unix philosophy. It is not a denial as we for sure just see no usecase for a so complex and also bloated piece of software to be used. Our ideal in this: We search for alternative ways as it is an an achievement of civilization that not all need to be the same but treated nevertheless with fairness and therefore in conclusion the same way!

So systemd has to persist the comparison towards other possible init-systems and in that way is for sure too big, too complex and full with flaws we don't want to accept as we would therefore need to be worried even on top of continuous upgrades for just one essential part. And even though every single point can be declared as solved or in some way older, we just don't want to use systemd as single-point for a failure as it just this simple.

Hyperbola GNU/Linux-Libre

HyperWiki