Replacing Systemd with OpenRC in Debian

Original Article ↗ Hacker News Discussion ↗

Linux users are revisiting long‑running tensions around system initialization, comparing Debian’s default systemd stack with alternatives like OpenRC, Devuan, Gentoo, Alpine and Void. Supporters of systemd highlight its unified service management, richer features, and reduced fragmentation, while critics object to its growing scope, complexity, tight coupling with desktop environments, and recent moves like optional age‑verification metadata. Many agree that having viable competitors and non‑systemd distros remains important, but differ on whether the practical benefits of standardization outweigh the risks of an emerging monoculture.

Why replace systemd / need for competition

  • Many argue systemd has become too dominant, creating a de facto monoculture and making alternatives hard to deploy.
  • Concerns: dependency sprawl into many low-level components, accidental complexity, and maintainers being dismissive of compatibility issues.
  • Others respond that systemd works well for them, solves longstanding init problems, and that serious alternatives are still incomplete or niche.

Technical comparisons: systemd vs OpenRC and other inits

  • OpenRC is presented as a lightweight service manager with dependency ordering, supervision (supervise-daemon), parallel startup, and cgroup integration.
  • Some note that systemd’s unit files and OpenRC service files are structurally quite similar for basic cases.
  • There is debate over whether shell-based init scripts are inherently fragile versus systemd’s declarative, binary-driven approach.

Debian, Devuan, and distro choices

  • Historical context: Debian evaluated systemd, Upstart, and OpenRC; OpenRC was seen as underdeveloped in Debian at decision time.
  • Debian initially supported multiple init systems but later standardized on systemd due to maintenance burden.
  • Devuan is mentioned as “Debian without systemd,” but differs from simply swapping init on stock Debian (separate repos, patches).
  • Some argue a distro should pick one init; “choice” should happen at the distro level, not inside each distro.

Systemd’s scope and “OS-ification”

  • Systemd now covers init, logging, networking, bootloader, partition autodiscovery, installers, container-style features, etc.
  • Supporters like the coherent, integrated “OS layer” and unified APIs that simplify tooling like Cockpit.
  • Critics see this as overreach, risking lock-in and making it harder to swap components.

Immutable systems and control

  • Discussion of systemd-based immutable stacks and a company focused on locked-down “amutable” systems.
  • Some see immutable, centrally controlled systems as beneficial for vendors (e.g., consoles, consumer devices).
  • Others fear these mechanisms, once standardized at init/OS level, could aid user lockout or exclusion of non-systemd distros, especially if combined with secure boot policies.

Age verification / privacy concerns

  • A planned age/DoB field in systemd sparks strong reactions.
  • Critics see it as enabling “age sniffing,” aligning with intrusive laws and data collection; intent to comply with regulation is viewed suspiciously.
  • Defenders note it is an optional metadata field, can be compiled out or left unset, and may avoid each service re-implementing its own mechanism.
  • Disagreement over whether developers should comply with such laws, ignore them, or actively resist as test cases.

Usability, reliability, and bugs

  • Some report systemd as robust and feature-complete for years, especially compared to classic SysV.
  • Others recount serious past bugs (e.g., shutdown races via D-Bus, journald data loss, CPU spikes, supervision incompatibilities) and view them as design flaws, not mere implementation mistakes.
  • There is acknowledgement that both sysv-style init and systemd have broken production systems; systemd’s much larger codebase is seen by some as a bigger “attack surface” for bugs.

Fragmentation vs standardization

  • Pro-systemd voices emphasize reduced distro fragmentation, improved cross-distro consistency, and easier packaging.
  • Anti-monoculture voices value diversity (Gentoo, Alpine, Void, Devuan) and worry when desktops (GNOME/KDE) or tooling quietly assume systemd.
  • Some note POSIX once aimed to smooth portability, but modern desktops and deep system integration need more than POSIX alone.

Alternatives and “plan B” distros

  • Gentoo + OpenRC, Alpine (with OpenRC), Void, and other supervision-inspired systems are cited as viable non-systemd options.
  • Alpine is reported to work fine as a desktop (e.g., with i3 or KDE), especially on low-power hardware.
  • Tools exist to convert systemd units to other formats, but maintaining semantic compatibility is considered non-trivial.

Meta: culture, politics, and law

  • Thread touches on distrust of corporate influence (Red Hat/IBM, large tech) and fear that their incentives diverge from privacy-focused users.
  • There’s debate over whether to fight bad laws via politics, via courts, or via technical non-cooperation.
  • Some characterize systemd criticism as emotional or quasi-tribal; others argue they’re responding to real technical and governance issues.