Linux From Scratch Ditches SysVinit After 15 Years of Dual Support

Linux From Scratch (LFS), the venerable project that teaches users how to build their own Linux distribution from source code, has announced it will no longer support the traditional SysVinit init system in future releases. This marks the end of a 15-year period where LFS maintained dual support for both SysVinit and systemd, a decision driven by practical constraints rather than philosophical preferences.

The Burden of Dual Maintenance

The announcement, made by Bruce Dubbs, highlights the unsustainable workload facing the all-volunteer LFS team. With 88 packages in LFS and over 1000 in Beyond Linux From Scratch (BLFS), the volume of upstream changes has become overwhelming. During the current release cycle alone, there have been 70 commits to LFS and 1155 commits to BLFS.

Each package update requires verification for both init systems, and the entire package set must be checked for each init system when preparing releases. This duplication of effort has stretched the volunteer team beyond its capacity, especially as systemd adoption continues to grow across the Linux ecosystem.

The systemd Lock-in Problem

Beyond the workload concerns, the LFS team faces a technical reality: major desktop environments are increasingly dependent on systemd-specific functionality. GNOME already requires systemd features, and KDE Plasma is following suit. These aren't merely preferences but hard dependencies baked into the build systems and runtime requirements of these environments.

While alternative init systems like OpenRC could theoretically fill the gap, they would still face the same maintenance burden and wouldn't address the fundamental issue of systemd-specific features becoming standard across the Linux desktop landscape.

What This Means for LFS Users

Existing LFS/BLFS 12.4 System V books will remain available, and users can continue building older versions of packages using those instructions. However, these older versions won't receive the same testing and verification from LFS editors that newer releases will get.

The next major release, LFS/BLFS 13.0, targets a March 1st release date and will focus exclusively on systemd support. This represents a significant shift for a project that has historically prided itself on teaching users about the inner workings of Linux systems.

The Educational Trade-off

Dubbs expressed personal disappointment with the decision, noting that understanding the boot process is fundamental to learning how a Linux system works. The contrast between systemd's 1,678 C files plus many data files and System V's 22 C files plus about 50 short bash scripts illustrates the complexity gap.

While systemd provides many capabilities that System V lacks, the educational value of understanding a simpler, more transparent boot process is being lost. This trade-off between practical maintenance and educational purity reflects broader tensions in the Linux community as systemd becomes increasingly dominant.

The Broader Context

The LFS decision mirrors trends across the Linux ecosystem. Major distributions like Debian, Ubuntu, and Fedora have long since standardized on systemd, and even traditionally conservative distributions are following suit. The systemd adoption rate has reached a point where maintaining alternatives is becoming increasingly difficult for volunteer-driven projects.

For users who still prefer SysVinit or other init systems, the LFS books provide a valuable reference for building older package versions, but the future of Linux system building appears firmly systemd-centric. This shift represents not just a technical change but an educational one, as the next generation of Linux builders will primarily learn the systemd way of doing things.

The end of SysVinit support in LFS marks another milestone in Linux's evolution from a collection of interchangeable components to a more integrated system where certain choices become increasingly difficult to avoid. For a project dedicated to teaching users how their systems work, this represents both a practical necessity and a philosophical compromise.