A community resource for Linux users who believe in simplicity, transparency, and process 1 as it was meant to be. No monoliths. No dbus sockets disguised as init systems. Just Unix.
An init system should start processes, supervise them, and stop them. Not manage DNS, log daemons, network configuration, login sessions, time synchronization, and device events under a single monolithic binary with 1.4 million lines of code.
Service management should be auditable by any user with a text editor and basic shell skills. Shell scripts are documentation. Binary unit files compiled into journal logs are not. Your init should never require a PhD to debug.
When core desktop components refuse to run without a specific init system, that is not a technical constraint. That is a political decision. We oppose software that uses infrastructure-level coupling as a mechanism for ecosystem lock-in.
The Linux ecosystem's defining strength has always been the freedom to compose your own system. An operating system that forecloses on that freedom, silently, through tight integration and missing fallbacks, has betrayed its users.
We acknowledge that Red Hat engineers produce real work. We also acknowledge that no single corporation should hold de facto veto power over the architecture of a free operating system used by hundreds of millions of people.
runit, OpenRC, s6, dinit, SysVinit — these are not protest projects. They are production-grade, battle-tested, and running in datacenters, embedded systems, and desktops right now. The argument that there is no alternative is simply false.
"Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
Every distribution listed here ships without systemd as the default init. Tier 1 means fully committed, systemd-free by design. Tier 2 means rolling or active with strong alternative-init support. Tier 3 means niche, minimal, or purpose-specific. Tier 4 means legacy, inactive, or in transition.
Independent, rolling-release. Born without systemd. Ships runit as PID 1 with no opt-out. XBPS package manager. Musl or glibc. The gold standard.
The Debian fork that refused. Born from the Debian systemd controversy of 2014. Full Debian compatibility minus the monolith. Multiple init choices.
Musl-based, minimal, fast. The dominant init-free choice for containers. OpenRC with a clean service model. Ships in millions of Docker images worldwide.
Arch without systemd. Rolling, pacman-based, familiar. Your choice of four init systems at install time. The most accessible entry point for Arch users.
Source-based, compile-everything. OpenRC is the default. USE flags give granular control. Systemd is optional and isolated. The ultimate composable platform.
New-generation independent distro. LLVM-only toolchain, BSD userland tools, dinit as init. A fresh philosophical take built from first principles.
The oldest surviving Linux distribution. Never adopted systemd. Patrick Volkerding has never wavered. A living monument to the original Unix tradition.
Purely functional, reproducible, transactional. Uses GNU Shepherd as init, written in Guile Scheme. The most philosophically rigorous free software distro in existence.
Daniel Robbins' fork of Gentoo. Source-based, OpenRC native. Optimized builds, ego package manager, git-based portage. A refined Gentoo alternative.
Minimalist, BSD-influenced. Predates the systemd era philosophically. Port-based package management, hand-crafted system. For users who prefer to build by hand.
Extreme minimalism as a design principle. Shell-based package manager, zero unnecessary software. If you can't understand every line of your system, KISS tells you to keep reading.
Arch-based, s6 native. Built by a single developer with radical commitment to the s6 supervision suite. Ideologically pure, technically demanding. Not for the faint-hearted.
FSF-endorsed, 100% free software Arch fork. Replaces all proprietary components, defaults to OpenRC. For users who treat software freedom as non-negotiable.
FSF-endorsed, long-term stable, Arch-based with Debian influences. Transitioning toward a BSD base. Systemd-free and libre to the core.
Debian Stable via antiX. SysVinit by default. Excellent hardware support, polished tools, consistently at the top of DistroWatch. A solid everyday choice.
Lightweight Debian-based. Explicitly anti-systemd by philosophy. Breathes life into old hardware. The ideological and technical backbone behind MX Linux.
Long-running rolling release, RPM-based. Has never migrated to systemd. Community-driven since 2003. A quiet, reliable alternative for desktop users.
Debian-based with Enlightenment desktop. One of the longest-running independent distros. SysVinit default. Known for its unique aesthetic and polish.
Lightweight, web-centric desktop distro. Switched to a Devuan base, inheriting SysVinit by default. Accessible for new users who want a fast, clean desktop.
French-origin, from-scratch distro. Cards package manager. SysVinit native. Built with simplicity and independence from the major distro families in mind.
Under 20MB. Runs entirely in RAM. BusyBox init. No packaging overhead, no bloat of any kind. Used in embedded systems, rescue environments, and extreme minimalism experiments.
Linux for routers and embedded devices. Custom procd init system, BusyBox userland, musl libc. Runs on hundreds of millions of devices. systemd would never fit.
30MB live system. Entirely self-contained. BusyBox init and userland. Runs from RAM on machines with as little as 192MB. Extreme but functional.
Radically reimagined filesystem hierarchy. Each program lives in its own directory tree. SysVinit. An architectural experiment that asks fundamental questions about how Linux should be organized.
FSF-approved, fully libre, from-scratch distro using GNU Shepherd. Extreme commitment to software freedom. Minimal user base but maximal philosophical integrity.
Research-grade, musl-based, built from scratch using a minimal toolchain. sinit as init. Built to be studied as much as used. Radical simplicity as a research goal.
Independent, source-based, runit native. CRUX-inspired port system. Small community, strong philosophy. Systemd never considered.
Debian-based but systemd-free in default configuration. Uses OpenRC, NX Desktop on KDE. Unusual combination of modern UX ambition and traditional init philosophy.
The original Dylan Araps project. Abandoned in 2021 by its creator. Community forks continue. Listed as a historical reference for one of the most philosophically pure distros ever made.
Obscure independent distro with a custom init system (31init). Very small community. Included as a data point in the diversity of init experimentation happening outside the mainstream.
KISS-inspired, stripped to absolute minimum. Development activity is sparse. Documented here as a representative of the ultra-minimalist init tradition.
Gentoo-based, Italian-origin, OpenRC default. Small active community. A niche alternative within the Gentoo ecosystem.
This is not a flame war. These are documented architectural decisions, real CVEs, confirmed privacy issues, and citations from engineers and researchers who have studied systemd's design in depth. Read the evidence and decide for yourself.
Architectural critique
The Unix philosophy — articulated at Bell Labs in 1978 — states that programs should do one thing well, cooperate through standard interfaces, and handle text streams as a universal medium. systemd violates all three principles simultaneously.
As of 2024, the systemd project encompasses: an init daemon, a service manager, a login manager (logind), a DNS resolver (systemd-resolved), a time synchronization daemon (systemd-timesyncd), a network manager (systemd-networkd), a bootloader (systemd-boot), a home directory manager (systemd-homed), a credential manager, a container manager (systemd-nspawn), a journal binary log system (journald), a device manager (udev, absorbed in 2012), and a cryptography layer for encrypted storage. These are not plugins. They are deeply coupled components sharing internal APIs, dbus interfaces, and cgroup hierarchies.
The result is a system where a vulnerability in DNS resolution can affect the process supervisor, where a log parsing bug crashes PID 1, and where auditing any single component requires understanding the entire codebase. This is not engineering. It is empire-building.
Documented behavior, not speculation
systemd-resolved, the DNS resolver component introduced as part of systemd's expanding scope, has a hardcoded fallback mechanism compiled into the binary at build time. When no DNS server is configured or the configured server is unreachable, systemd-resolved silently redirects all DNS queries to external public servers — historically Google's 8.8.8.8 and 8.8.4.4, more recently Cloudflare and Quad9.
The problem is not the fallback itself. The problem is the silence. A user running a privacy-conscious setup — with a local DNS resolver, a VPN, or a custom resolver pointed at a non-logging server — may be entirely unaware that systemd is leaking every hostname they resolve to a third-party commercial server during transient network states: reconnections, DHCP renewals, VPN handshakes.
systemd-resolved compiled with FallbackDNS=8.8.8.8 8.8.4.4 as a build-time default. All DNS queries leak to Google during network transitions without user knowledge or consent. Reported across Ubuntu (LP#1449001), Debian (Bug#761658), and the systemd GitHub tracker (Issue #8782).
systemd-timesyncd ships with time.google.com as a compiled-in default NTP server. Your machine sends time synchronization requests — and thus your IP address and approximate location — to Google infrastructure, even when you have not configured any Google services.
systemd-resolved enables LLMNR (Link-Local Multicast Name Resolution) and mDNS by default. Both protocols broadcast hostname resolution queries on the local network segment, potentially leaking internal hostnames, service names, and network topology to other machines on the same LAN.
Selected CVEs — not an exhaustive list
A monolithic codebase means a larger attack surface. When a DNS parser, a log daemon, and a privilege management layer all share the same process hierarchy as PID 1, a vulnerability in any one of them has system-wide implications. The following are real, documented CVEs — not theoretical concerns.
Three vulnerabilities in systemd-journald discovered by Qualys Research. CVE-2018-16864 and 16865 allowed local privilege escalation via stack clash. CVE-2018-16866 allowed out-of-bounds memory reads exposing process data. Because journald runs as a privileged system service, exploitation could lead to full root compromise.
A local attacker able to mount a filesystem on a sufficiently long path could trigger an uncontrolled alloca() call in systemd, exhausting the stack and crashing the entire system. Because systemd is PID 1, its crash brings down the whole operating system. Reported by Qualys, rated Important by Red Hat.
A specially crafted DNS response could cause an out-of-bounds write in systemd-resolved, potentially allowing remote code execution. This vulnerability exists because systemd chose to implement its own DNS client rather than using a well-audited library — a direct consequence of its scope expansion into network management.
A specially crafted DHCP FORCERENEW packet could cause systemd-networkd to accept a spoofed DHCP ACK, allowing an attacker on the local network to reconfigure the victim's network settings, redirect traffic, or cause denial of service.
systemd failed to set LESSSECURE=1 when invoking less as a pager for systemctl status. When run via sudo on a small terminal, less launches as root and allows shell escape, granting full privilege escalation. A trivially exploitable local privilege escalation requiring no special access.
Three separate vulnerabilities in systemd 253 allowed an attacker to modify, truncate, or hide messages in sealed journal logs while the integrity check reported no errors. The systemd team's initial response was to deny these were security vulnerabilities — a position later revised under pressure.
Who controls the infrastructure of Linux?
systemd is developed primarily by Red Hat engineers. Lennart Poettering, its original author, was a Red Hat employee from systemd's inception until 2022, when he moved to Microsoft. The project's primary maintainer Zbigniew Jędrzejewski-Szmek is also a Red Hat employee. This is not a conspiracy. It is a structural fact with real consequences.
When the project that serves as PID 1 for the majority of Linux distributions is controlled by a single corporation's engineering priorities, the entire Linux ecosystem inherits that corporation's architectural decisions. GNOME's dependency on logind, NetworkManager's integration with systemd-networkd, and PulseAudio's replacement by PipeWire — which also integrates deeply with systemd session management — are not accidents. They are the result of a coordinated architectural vision that happens to originate from a single corporate entity.
This is not about Red Hat being malicious. It is about the structural danger of monoculture. When Lennart Poettering wrote in 2010 that he wanted to enforce systemd adoption across the ecosystem, he was being transparent about the goal. The question is whether the Linux community should accept a situation where a single company's engineers effectively control the init layer, the session layer, the network layer, the log layer, and the boot layer of the operating system.
journald and the death of auditability
Logs are the mechanism by which a system administrator understands what their system is doing. For four decades, Unix logs have been plain text files. Any editor opens them. Any grep searches them. Any awk processes them. They survive system crashes because they are written to disk as text. They are portable, archivable, and readable on any machine without special tooling.
systemd-journald replaces this with a binary format readable only via journalctl. When journald itself crashes — as it has, due to multiple documented bugs — it can corrupt the log database, destroying the very records needed to diagnose the crash. The tool required to read your logs is part of the same codebase that generates your logs, managed by the same process tree that manages your system. This is not a design choice. It is a circular dependency that eliminates the independence of the audit trail.
On a systemd-free system using runit or OpenRC, your logs are in /var/log, in plain text, right now. No daemon required to read them. No binary format to corrupt. No journalctl --rotate to memorize. Just files.
Production incidents caused by systemd
A systemd upgrade caused a widespread production outage at Datadog. The incident, documented by Pragmatic Engineer, resulted in an estimated $5 million in losses and affected customers globally. The root cause was a behavioral change in a systemd update that broke process supervision in a way that was not caught by Datadog's testing infrastructure — because systemd's behavior is sufficiently opaque that such changes are difficult to detect before deployment.
Publication of systemd 237-3ubuntu10.54 to Ubuntu's bionic-security pocket caused a widespread Azure outage in which affected instances could no longer resolve DNS queries, breaking networking entirely. The update, intended as a security fix, introduced a regression in systemd-resolved that was not caught before release. Thousands of cloud instances were affected.
A zero-length message sent to systemd's notification socket caused PID 1 to enter an infinite pause() loop, completely freezing the system. No new services could be started or stopped. SSH and login commands hung for 30+ seconds. Rebooting required a hard reset. The vulnerability required no special privileges — any local user could execute it with a single shell command.
| Feature | runit | OpenRC | s6 | dinit | systemd |
|---|---|---|---|---|---|
| Codebase size | ~7k lines | ~30k lines | ~40k lines | ~25k lines | 1.4M+ lines |
| Service definition format | Shell scripts | Shell scripts | execline / shell | Text config | Binary-compiled units |
| Process supervision | Native | Via external tool | Native | Native | Built-in but opaque |
| Binary log format | No | No | No | No | Yes (journald) |
| Boots without dbus | Yes | Yes | Yes | Yes | Partially |
| PID 1 scope | Init only | Init only | Init + supervision | Init + supervision | Init + logging + DNS + network + login + ... |
| musl libc compatible | Yes | Yes | Yes | Yes | Limited |
| Parallel service startup | Via supervision trees | Yes | Yes | Yes | Yes |
A technical, philosophical, and political case against the init that ate Linux. 12 sections. CVE analysis, governance critique, Unix philosophy, and the alternatives that work.
From ISO selection (glibc vs musl) to first boot. XBPS basics, runit service management, and post-install configuration.
How run, finish, and log scripts work. Dependency ordering, supervision trees, and converting systemd unit files to runit format.
Step-by-step in-place migration. No reinstall required. Choose OpenRC or runit. Preserve your packages, dotfiles, and sanity.
For Debian users who want the familiar ecosystem without the monolith. APT, familiar tools, SysVinit or OpenRC as init.
rc-update, rc-service, runlevels, and service configuration. The complete reference for Alpine, Gentoo, Artix, and Devuan users.