Linux From Scratch ends SysVinit support

Original Article ↗ Hacker News Discussion ↗

Announcement & Rationale

  • LFS/BLFS will drop SysVinit instructions from the next release (March 2026); only the systemd variant will be maintained and tested.
  • Reasons cited:
    • Limited volunteer resources to maintain two init paths.
    • Desktop stacks like GNOME and soon KDE Plasma increasingly require systemd‑specific capabilities.
  • The maintainer explicitly says they dislike the decision and value SysVinit for teaching the boot process, but see no practical alternative.

Educational Goals vs Modern Reality

  • One camp argues LFS is about understanding how a system works; SysVinit’s small C codebase and shell scripts are more transparent and “Unix‑like” than thousands of systemd C files.
  • Others counter that if the goal is to learn how today’s Linux systems (Debian, Fedora, etc.) work, systemd is the relevant init to study.
  • Some say LFS never deeply explained internals of most packages anyway; you compile from source but treat many components as black boxes.
  • A few propose forks of the LFS book (or a “UnixFromScratch”) that keep SysVinit or use alternative inits for pedagogy.

Systemd vs SysVinit: Design & Philosophy

  • Pro‑systemd:
    • Unit files are simpler and more uniform than distro‑specific SysV scripts.
    • Built‑in supervision, dependency management, timers, socket activation, cgroups, sandboxing, etc. solve real problems.
    • Argue that SysVinit’s runlevels and dependency hacks are themselves poor “Unix design.”
  • Pro‑SysV / anti‑systemd:
    • Emphasize modularity, composability, and inspectable shell scripts vs a large, tightly coupled daemon suite (“SystemD” as project).
    • See systemd as “Windows‑ification”: centralizing policy, spreading into unrelated areas (homed, boot, network, logging).
    • Worry that it turns core boot behavior into a “black box” contrary to LFS’s spirit.

Reliability and Operational Experiences

  • Some report decades of trouble‑free systemd use and painful memories of fragile SysV scripts.
  • Others describe recurring production outages due to obscure systemd edge cases (especially mount and network ordering), plus a large backlog of unresolved issues.
  • Alternative inits (runit, OpenRC, daemontools, dinit) are cited as small, reliable, and closer to the Unix ideal.

Ecosystem Lock‑In and Loss of Choice

  • Strong concern that GNOME, KDE and other software hard‑require systemd, eroding the ability to choose other inits or non‑Linux Unixes.
  • Several frame LFS’s move as symbolic: a learning project admitting the ecosystem is now too entangled to support parallel init choices.
  • Others accept this as pragmatic: volunteers must follow where mainstream Linux has gone, or forks will have to carry the SysVinit torch.