Few debates have split the Linux community as sharply as the one over the init system. Beneath a seemingly minor technicality, which program runs first when you power on your machine, sat a clash of philosophies about how an operating system should be built. This is the story of that war.
What exactly is an init system?
When the Linux kernel finishes loading, it launches a single process and assigns it process identifier PID 1. That process, the init system, is the parent of every other process: it mounts filesystems, brings up networking, starts daemons and keeps the system running until you shut it down. If it dies, the kernel panics. That is why choosing an init is no small matter. It defines how the entire machine boots, behaves and is managed.
SysV init: the old school
For decades the standard was System V init, inherited from the commercial UNIX of the 1980s. Its model was simple and predictable: a series of shell scripts run sequentially, organised into runlevels. Distributions such as Slackware kept it as a banner of simplicity.
SysV’s virtue was transparency. Anyone who could read a shell script could understand and modify the boot process. Its flaw was speed. Running scripts one after another, with no parallelism, made startup drag on as the number of services grew. In the age of SSDs and laptops expected to boot in seconds, the model started to show its age.
Upstart: Canonical’s attempt
In 2006, Canonical introduced Upstart, written by Scott James Remnant. It shipped with Ubuntu 6.10 “Edgy Eft” to replace sysvinit, and it worked differently: instead of following a rigid order, Upstart reacted to events, a mounted disk, available networking, detected hardware, and started or stopped services dynamically. The idea shortened boot times and handled hot-plugged hardware far more gracefully.
Upstart had real reach. It was the default init in Red Hat Enterprise Linux 6 and in Chrome OS. But it carried political baggage. Canonical’s Contributor License Agreement required contributors to grant the company the right to relicense their code, something much of the Debian community viewed with suspicion. That friction would eventually count against it.
systemd: the winner that divided the room
In 2010, Lennart Poettering and Kay Sievers, then at Red Hat, published a manifesto titled “Rethinking PID 1” and unveiled systemd. Their pitch was hugely ambitious: not a mere init, but an integrated suite that started services in parallel through socket activation and also handled logging, devices, networking, sessions and much more under one roof.
Adoption was swift. In May 2011, Fedora became the first major distribution to enable systemd by default, dropping Upstart. openSUSE and others followed. The decisive blow came with Debian: after a heated debate between October 2013 and February 2014, its Technical Committee voted, by a very narrow margin, to adopt systemd as the default init for Debian 8 “Jessie”. From there, Ubuntu abandoned its own Upstart and migrated to systemd in version 15.04.
Debian’s vote was so close that it left scars. A public boycott campaign was even launched in 2014, and Linus Torvalds himself voiced reservations about the attitude of some systemd developers toward users and bug reports.
The UNIX philosophy on trial
The heart of the conflict was not technical but philosophical. UNIX tradition preaches “do one thing and do it well”: small, specialised, composable tools. By absorbing functions that previously lived in separate programs, systemd seemed to go against that principle. Its defenders argued that integration brought coherence, speed and capabilities the old model simply could not match. Its critics saw a monolith concentrating too much power in a single project.
The alternatives that endure
systemd won the war among the big distributions, but it did not wipe out the competition. Several alternatives survive with loyal communities:
- OpenRC, a dependency-based init that keeps compatibility with sysvinit, is the default on Gentoo.
- runit, a lightweight process-supervision suite inspired by daemontools, is the heart of Void Linux.
- s6 and the newer dinit offer minimalist approaches for those who want fine-grained control without systemd’s footprint.
And then there is Devuan: a fork of Debian born precisely to offer the parent project’s robustness without systemd, letting you choose between sysvinit, OpenRC and runit. Its very existence proves that in the free-software world no decision is ever truly final. There will always be someone ready to pick up the code and build something else.
The init wars no longer dominate the headlines, but their legacy lives on every time your machine reaches PID 1. The diversity of options, far from being a problem, is the best guarantee that Linux will remain yours to configure exactly the way you want.