With limited resources, sometimes practicality needs to win. Kudos to Bruce for putting aside his (valid) feelings on the subject and doing what is best for the team and community overall.

I am looking forward to UnixFromScratch and Year of Unix on the desktop as Linux more and more sells itself out to the overstuffed software virus that is System D.

https://github.com/systemd/systemd/tree/main/src/core doesn't look like 1678 C files to me.

On 01 March 2026 the next versions of LFS and BLFS will not include SysVinit instructions a.k.a. ''support''.

SysVinit has been seen by some people in the post-systemd world as some sort of mystifying mashup concocted by sadists, yet I've found that when it is explained well, it is clear and human-friendly, with easy uptake by newcomers. I echo that this decision is a pity.

sysv is garbage tho. If unix philosophy is "make it do one thing and do it well", it doesn't do the one thing it is supposed to do well.

I dislike overloading systemd with tools that are not related to running services but systemd does the "run services" (and auxiliary stuff like "make sure mount service uses is up before it is started" or "restart it if it dies" and hundred other things that are very service or use-case specific) very, very well and I used maybe 4 different alternatives across last 20 years

I don't have a dog in this fight but I find it funny that the anti-systemd crowd hates it because it doesn't "follow the Unix philosophy", but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)

And on the other hand, I have no sympathy for the Unix philosophy. I value results, not dogma, and managing servers with systemd is far more pleasant than managing servers with sysvinit was. When a tool improves my sysadmin life as much as systemd has, I couldn't care less if it violates some purity rule to do so.

If you want to learn the system from scratch, the best way will be writing your own little init system from scratch, so you can understand how the boot sequence works. And as you make use of more and more of the advanced features of Linux, your init system will get more and more complex, and will start to resemble systemd.

If you only learn about sysvinit and stop there, you are missing large parts of how a modern Linux distro boots and manages services.

I would think people who use LFS are doing it for the learning experience and not necessarily for a daily driver OS.

Maybe? When I did LFS/BLFS I opted for an i3-gaps setup with a compositor and some other eye candy, and had a lot of fun tinkering. I suppose some folks might want the experience of building an entire DE from source, but that seems like a bit much.

This decision means that no testing of SysVinit will be done in future LFS and BLFS versions. The onus will be on the experimenter each time, but my hope is that a body of advice and best practices will accumulate online in lieu of having a ''works out of the book'' SysVinit solution.

Didn't you find though that systemd was just a black box? I was hoping to learn more about it as well- and I did manage to get a fully baked LFS CLI system up and running, and it was just like "ok install systemd..." and now... it just goes.

Sysv at least gave you a peak under the covers when you used it, and while it may have given people headaches and lacked some functionality, was IMHO simple to understand. Of course the entire spaghetti of scripts was hard to understand in terms of making sense of all the dependencies, but it felt a lot less like magic than systemd does.

If we look on LFS for its academic merit, I'm saddened that key historical elements of Unix/Linux design are being left behind, much like closing down a wing of a laboratory or museum and telling students that they'll need to whip up their own material to fill in those gaps.

SysV was this weird blind spot for many years. I remember installing daemontools on the OpenBSD server my office ran on because it was nicer to work with, and thinking that the Linux world would switch to avoid losing that particular feature war with Windows.

Almost wonder if this kind of thing will be an impetus for GNU Hurd to get more momentum. I saw an update recently that they're now finally properly supporting 64bit and sounds like there's active dev going on there again.

It apparently uses SysVInit

I wonder if the impetus behind the (terrible) monolithic design of systemd was to force standardization across distros. The choice was more political than technical.

If different choices were available for init, DNS resolver, service control manager, volume manager, etc... we would adversely contribute to the schizo distro landscape the people holding the money bags are actively trying to get away from.

With systemd it's an all-or-nothing deal. You get the good with the bad, but all distros shit the bed in the same, deterministic way.

Not even Windows does this. There is no "systemd" equivalent. Yes, Windows ships as a single OS—as do the BSDs—but all the components were developed separately.

If all they wanted was a service control manager, there were many (better) options already in existence they could have used.

OpenRC on Gentoo works great. I have a full bleeding edge Wayland KDE Plasma with Pipewire setup that I game on.

OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things.

There are growing pains. https://bugs.gentoo.org/936123

Especially when upstream hard requires systemd. More annoying when there's no real reason for it.

But there is a way forward and I highly recommend people try to build software to work without systemd before assuming it's always there.

Try Alpine? It's not designed to be a "desktop" OS but it functions well as one. I find it easy enough to wrap my head around the whole thing, and it uses OpenRC by default.

I always dreaded trying to create a service with bash-based init scripts. Not only did it involve rolling a heck of a lot yourself (the thing you were running was generally expected to do the double-fork hack itself and otherwise do 'well behaved daemon' things), it varied significantly from distro to distro, and I was never confident I actually got it right (and indeed, I often saw cases where it had most definitely gone wrong). Whereas systemd has a pretty trivial interface for running most anything and having some confidence it'll actually work right (in part because it can actually enforce things, like actually killing every process that's part of a service instead of kind of hoping that killing whats in the PIDfile is sufficient).

Yes, much better. The original intro blog post goes into detail: https://0pointer.de/blog/projects/systemd.html