← Back to articles
News· 5 min read

systemd: the controversy that divided the Linux community

Terminal showing code on screen evoking the boot process of a Linux system
Foto: panumas nikhomkhai · Pexels

Few pieces of software have stirred up as much passion and as much anger as systemd. To some it is the component that finally modernized how Linux boots. To others, a sprawling beast that swallowed half the operating system and trampled the UNIX philosophy on its way. If you have ever watched a forum thread catch fire the moment someone typed that word, this article explains where all the noise comes from, without taking sides.

What systemd actually is

Terminal editing a systemd service unit file with nano to be run by systemctl
A systemd service unit file, the declarative format that systemctl manages at boot. · Imagen: Thelichprince / CC BY-SA 4.0 · Wikimedia Commons

systemd is both an init system and a service manager for Linux. The init is the first process the kernel starts, the famous PID 1, and from there it brings everything else to life: networking, disks, background services, user sessions. For decades that job belonged to SysV init, which relied on a collection of shell scripts run one after another, in strict order.

systemd changed that model. Instead of sequential scripts, it uses declarative configuration files called unit files, written in a simple format, and it starts services in parallel while respecting their dependencies. The project came from Lennart Poettering and Kay Sievers, both working at Red Hat at the time. Poettering introduced it in April 2010 through a blog post titled “Rethinking PID 1,” where he proposed reimagining from scratch how a modern operating system should boot.

Why it was adopted so quickly

Screenshot of systemd-cgtop showing resource usage of services managed by systemd
systemd-cgtop shows services and their resource usage in real time, relying on the kernel cgroups. · Imagen: Software: systemd developers Screenshot: VulcanSphere / LGPL · Wikimedia Commons

The advantages its supporters point to are concrete and, for the most part, measurable:

  • Faster boot times, thanks to parallel service startup and socket-based activation (a service can sit “asleep” until something actually needs it).
  • Unified management through a single command, systemctl, to start, stop, enable, or check the status of any service.
  • Centralized logging via journald, which collects and structures system logs in one place.
  • Solid handling of dependencies and processes, leaning on the kernel’s cgroups to supervise and contain what is running.

These strengths won over Fedora first, which in 2011 became the first major distribution to enable systemd by default. openSUSE and Arch Linux followed, and the decisive leap came with Red Hat Enterprise Linux 7 in June 2014, which made it the standard init across the enterprise world. Ubuntu adopted it in the end too and dropped its own Upstart system.

The earthquake in Debian

The case of Debian deserves its own chapter, because that is where the controversy peaked. The project’s Technical Committee debated for months, between 2013 and 2014, over which init should be the default in Debian 8 “jessie.” On the table were systemd, Upstart, OpenRC, and the veteran sysVinit. In February 2014, the committee voted in favor of systemd.

The decision was so charged that several prominent developers, including members of the committee itself and the maintainer of the systemd package, resigned from their posts over the stress and pressure of those disputes. Few episodes in recent free software history have left so many scars.

Why it sparks so much debate

If systemd is so fast and convenient, where does the pushback come from. The criticisms are not frivolous, and they are worth understanding:

  • It breaks the UNIX philosophy. The traditional maxim, “do one thing and do it well,” clashes with a systemd that has steadily absorbed jobs once handled by separate, independent programs: logging, networking, sessions, DNS resolution, time zones, and more.
  • It is large and centralized. By concentrating so many responsibilities in a single project, a very important part of the system comes to depend on it. That worries anyone who values modularity and the ability to swap out components.
  • Coupling. Many packages end up assuming systemd is present, which makes living without it harder even when you want to.

Its defenders reply that this integration is exactly what brings coherence and stability, and that comparing internal components against a rule from the 1970s is debatable. At its core, the argument is as much philosophical as it is technical.

The alternatives and the resistance

Default Xfce desktop of Devuan 5 Daedalus, the distribution born as a Debian fork without systemd
Devuan, a Debian fork born out of the controversy, offers sysVinit, runit or OpenRC instead of systemd. · Imagen: Dyne.org foundation / GPL · Wikimedia Commons

Adoption was not universal, and out of that tension came projects built around life without systemd. The most symbolic is Devuan, a fork of Debian announced in late 2014 whose first stable release arrived in May 2017, with sysVinit, runit, or OpenRC as alternatives. Other options for those who prefer a different road:

  • MX Linux, which can boot with sysVinit and only uses systemd-shim where needed.
  • Void Linux, built from scratch around the minimalist runit.
  • Gentoo, which keeps OpenRC as a first-class option.
  • Slackware, faithful for years to a classic BSD-style init scheme.

There is no single correct answer. systemd won the battle for mainstream adoption because it solved real service-management problems on modern, complex systems, and today it is the de facto standard. But the community that champions simplicity, modularity, and freedom of choice is still very much alive, and that is one of the great virtues of free software: there is always another door left open.