Replacing Systemd with OpenRC in Debian

Original Article ↗ Hacker News Discussion ↗

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.