FOSDEM 25: Systemd outlines its future

Since its first version, originally called "Babykit" by Kay Sievers and Lennart Poettering after the Linux Plumbers Conference 2009, Systemd has become one of the more important projects around Linux. In addition to a core team of six developers, 60 others have access to the source code with commit permissions and it is estimated that 2600 individuals have contributed to Systemd over the years.

The inspiration was not only provided by the time-honored System-V init, or rather the problems with its script-based service configuration. Ideas from Canonical's Upstart, Solaris SMF and Apple's Launchd also flowed into Systemd. In particular, one of the main goals of Systemd service management was to start services via socket activation only when required, possibly in parallel. Apple computers with OS X start up quickly – Linux should also be able to do this.

Systemd: Small footprint with dynamic libraries

The first significant lines of source code were written 15 years ago. The first executable version was released a year later. Systemd has been standard in Fedora since 2011, openSUSE and Arch Linux followed just a little later and 10 years ago Ubuntu and Debian adopted Systemd as their standard init system. An opportunity for Lennart Poettering to summarize the milestones in the development so far and the reasons why, in his opinion, Systemd has prevailed against other init systems – and sometimes harsh criticism –. A brief outlook on the tasks that Systemd wants to solve in the near future also fitted into the day, which began with a greeting to the Devuan maintainers present – one of the few Linux distributions that still prefers Open RC to Systemd.

Many points of criticism were based on misunderstandings, which, according to Poettering, is now even clearer a few years later: Systemd did not break with all UNIX principles. Systemd has not become a monolithic binary that controls the entire Linux system, but is now a collection of around 150 individual programs. Very few Linux distributions need all of them. Only Fedora Linux delivers almost all Systemd binaries fully compiled in its standard repositories. The size of all binaries is 25 megabytes. The entire Systemd collection currently consists of around 690 thousand lines of C code, which corresponds to half of the Glibc library.

However, according to Poettering, Systemd remains lean due to dependencies on other libraries. This poses a dilemma, as too many dependencies cause the overall system to grow too much. According to Poettering, there is a tendency to hand over more and more functionality to Systemd. Systemd therefore now relies on weak dependencies for extra functionality, which are only used via "dlopen()" if Systemd requests the library. Initial ramdisks and small containers, into which Systemd must continue to fit, serve as a limitation.

Outlook: Rust will come much later

One of the areas that Systemd will tackle first on Poettering's list is verifying the integrity of a Linux system at startup. This is done by measured values that are stored in a TPM-2 chip (PCRs) and compared after booting. Systemd should take care of sealing the desired measured values, for example to start a signed unified kernel image (UKI), in order to prevent any manipulation of the boot process and kernel in the meantime. Next on the to-do list is the addition of DBUS for inter-process communication with the more powerful Varlink, which turns the Systemd service into an IPC service that can output JSON for further processing.

Finally, the Systemd developers are hoping for a general move away from package-based Linux distributions towards image-based Linux systems in the style of Fedora Silverblue or Endless OS and want to supplement Systemd with tools specifically for these types of systems. For later development, the minds behind Systemd also see the promise of Rust to make memory management more robust. For example, a new component written in Rust, "systemd-zram-generator", already exists internally, but has not yet been released. In general, according to Poettering, Systemd can only really make use of Rust if it supports dynamically loadable libraries, otherwise it would actually grow into a bulky golem that no longer fits into any initial ramdisk.

(mho)