''As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important.
Runit is 5474 SLOCs. Most source files are shorter than 100 lines. Works like a charm. Implements an init system; does not replace DNS, syslog, inetd, or anything else.
Systemd, by construction, is a set of Unix-replacing daemons. An ideal embedded system setup is kernel, systemd, and the containers it runs (even without podman). This makes sense, especially given the Red Hat's line of business, but it has little relation to the Unix design, or to learning how to do things from scratch.
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 will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software. It is built starting from LFS in 2019, and now consists of over 1,500 packages, cross compiling to x86-32/64, powerpc32/64, and others if I had hardware to test. It's built entirely from shell scripts which are clean, organized, and easy to read.
I need help to get the system ready for release in 60-90 days. In particular, I need a fast build system, as my current 12+ year old workstation is too slow. Alpha/beta testers are welcome too. Anyone who wants to help in some way or hear more details, please get in touch:
Well to be fair, you don't need to understand how SystemD is built to know how to use it. Unit files are pretty easy to wrap your head around, it took me a while to adjust but I dig it now.
To make an analogy: another part of LFS is building a compiler toolchain. You don't need to understand GCC internals to know how to do that.
> Well to be fair, you don't need to understand how SystemD is built to know how to use it.
The attitude that you don't need to learn what is inside the magic black box is exactly the kind of thing LFS is pushing against. UNIX traditionally was a "worse is better" system, where its seen as better design to have a simple system that you can understand the internals of even if that simplicity leads to bugs. Simple systems that fit the needs of the users can evolve into complex systems that fit the needs of users. But you (arguably) can't start with a complex system that people don't use and get users.
If anyone hasn't read the full Worse Is Better article before, its your lucky day:
he is counting every c file in the systemd _repository_ which houses multiple projects, libraries and daemons. he equates that to the c file count for a single init. it's a disingenuous comparison. systemd-init is a small slice of the code in the systemd repository.
I'm guessing he shares my belief that systemd-init cannot exist in the wild on its own, correct? When you want a teacup, you have to get the whole 12 place dinner set.
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.
I can absolutely say that I've never had a showstopping problem with sysv. That is about 30 years as a unix & linux admin and developer.
The whole point of sysv is the components are too small and too simple to make it possible for "showstoppers". Each component, including init, does so little that there is no room for it to do something wrong that you as the end user at run-time don't have the final power to both diagnose and address. And to do so in a approximately infinite different ways that the original authors never had to try to think up and account for ahead of time.
You have god power to see into the workings, and modify them, 50 years later in some crazy new context that the original authors never imagined. Which is exactly why they did it that way, not by accident nor because it was cave man times and they would invent fancier wheels later.
You're tired of hearing complaints? People still complain because the problem did not go away. I'm tired of still having to live with the fact that all the major distros bought in to this crap and by now a lot of individual packages don't even pretend to support any other option, and my choices are now to eat this crap or go off and live in some totally unsupported hut in the wilderness.
You can just go on suffering the intolerable boring complaints as far as I'm concerned until you grow some consideration for anyone else to earn some for yourself.
Equally tiring is the “it works for me so stop complaining” replies, which do nothing to stop the complaints but do increase the probability of arguments. Want the complaint posts to stop? Suggesting that they’re in some way invalid is not the way.
Yeah, it’s so tiresome that other people have a philosophy different from mine which seems to have prevailed for now. Like ok so sorry. Systemd on linux is the worst of both worlds imho which apparently according to GP to which I’m progressively less entitled. I like NetBSD and its rc init and config system. Oh no systemd sore winners incoming!
Imagine that, people on the internet disagreeing. I've had both sysv and sysd crap in my cheerios. The thing I appreciated about sysv was that it stayed in its lane and didn't want to keep branching out into new parts of the system. Sysvinit never proposed something like homed.
I understand where you’re coming from but early systemd with both ubuntu and centos was a fucking mess. It’s good now but goddamn it was painful and the hate is 100% justified.
While I'll ignore the System D hyperbole, your point about Unix has merit.
I think the *BSD are also good, at least from an educational standpoint, with their relative simplicity and low system requirements. Since there is a lot of integration making a from scratch distro might take less material, but it could be supplemented with more in depth/sysadmin exploration.
From an education standpoint for those who really, really want to understand, the *BSD init and SysVinit systems require direct human administration. You break it, you fix it. Then, and only then, does learning systemd's ''then something happens behind the curtain'' type of automation make sense. If the student decides that one is more suitable than the other(s), they've done so from an enlightened vantage point.
I thought systemd was fairly straightforwards, even if it does too many different things for my tastes. What's an example of it doing a too much magic behind the curtain thing?
SysV init was the overengineered cousin to BSD init and I never liked it. Easily my least favorite of all init systems I've worked with over the last 30 years. On the flip side, daemontools or maybe runit were my favorites. Lots of good options for init/supervision tooling over the years and SysV was not among them.
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.
> As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files.
However the reasoning they provide makes sense.. It's hard to build a Linux system with a desktop these days without Sysd.
If the students have been well trained, they should be trusted to experiment. If the course curriculum demands that they produce something themselves yet does not educate them on doing so, that's horrific.
Back in the day, system run levels were seen as desirable. SysVinit went in on that concept to the max. So, if the concept of run levels isn't clear to the student beforehand, the init system for making it happen would therefore be mystifying and maybe even inscrutible.
Runlevels may be an interesting idea (e.g. the single-user maintenance level). But a bunch of shell scripts, each complex enough to support different commands, sort-of-declare dependencies, etc, is not such a great idea. A Makefile describing runlevels and service dependencies would be a cleaner design (not necessarily a nicer implementation).
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.
All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future, or at least a linux distro from the list here https://nosystemd.org/ - probably Gentoo. Nothing to stop me, absolutely nothing at all. I just need a few days free to backup/wipe/reinstall/reconfigure/restore_data and I'll be good. Better make that a few weeks. Maybe on my next machine build. It's not easy, but I build machines for long term use.
As for Linux from Scratch - This is something that's been on my radar, but without the part I'm truly interested in (learning more about SysV) then I'm less inclined to bother. I don't buy the reason of Gnome/KDE - isn't LfS all about the basics of the distro than building a fully fledged system? If it's the foundation for the other courses, but it still feels weak that it's so guided by a future GUI requirement for systemd when it's talking about building web servers and the like in a 500Mb or less as the motivation.
What practical problems do you run into with systemd?
All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic".
But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems.
People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap.
Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts.
Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.
Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound.
But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup.
To give you concrete examples:
1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts.
2. Except that you can, but only if you use the /etc/fstab compat.
3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device.
4. Systemd has separate behaviors for network and local filesystems.
5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!!
6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching.
7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1.
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.
and grub is a rotting pile while systemd-boot is a simple boot entry multiplexer that rides off the kernel's capability of being run as an EFI executable, it just happens to live in systemd's tree. not a good example
It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?
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.
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.
> All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future
Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.
Popular desktop environments are increasingly depending on Linux-only things. KDE has officially removed support for FreeBSD in Plasma login manager (because of logind dependency).
Gnome 50 plans to obsolete X11 completely.
If you want that simple, bright future of yours, you’ll have to fight/work for it.
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.
Others have been reminding us of the *BSD init systems, and I remind that SysVinit is not going away from Linux while projects like Devuan and others continue. GNU Hurd is another other-than-systemd learning opportunity.
hurd init is a lot like systemd architecturally, it just gets to use kernel provided ipc rather than having to manage its own. if your objection to systemd is its architecture you don't want anything to do with hurd.
I would somewhat doubt it; the negative aspects of Mach’s design are a technical albatross around the neck of any kernel.
Apple has had to invest reams of engineering effort in mitigating Mach’s performance and security issues in XNU; systemd dissatisfaction alone seems unlikely to shift the needle towards Hurd.
It's a pity. It's also a step back from valuing the Unix philosophy, which has its merits, especially for those with a "learning the system from scratch" mindset. Sorry, but I have no sympathy for systemd.
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.
It’s not just explaining but whether you have to support it on more than one distribution/version or handle edge cases. For a simple learning exercise, it can be easier to start with but even in the 90s it was notably behind, say, Windows NT 3 in a lot of ways which matter.
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
Clearly there are lots of people who don't want something that does what you say systemd does. Bravo that choice is out there, but what a pity that LFS does not seem to have the resources to test future versions for SysVinit.
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.
That's the point on which people differ. Even if we take as given that rc/svinit/runit/etc is not good enough (and I don't think that's been established), there are lots of directions you can go from there, with systemd just one of them.
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.
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)
That's funny, I did LFS a few years ago and specifically chose the systemd version so I could better understand it. I don't think this is a huge deal, I believe the older versions of the document that include SysVinit will still be available for a long time to come, and people who want it will figure out how to muddle through. If at some point in the future things diverge to such a point where that that becomes untenable, someone will step up and document how it is to be accomplished.
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.
> "ok install systemd..." and now... it just goes.
I believe it's `systemctl list-unit-files` to see all the config that's executed, included by the distro, and then if you want to see the whole hierarchy `systemd-analyze dot | dot -Tpng -o stuff.png`
To me, seems much easier to understand what's actually going on, and one of the benefits of config as data rather than config as scripts.
> Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files.
Systemd is basically the Windowsfication of Linux. I'm always surprised by the people that champion it who also used to shit on Windows with the registry or whatever.
I was considering forking the base book and maintaining it, as I have kept an eye and occassionally built the project over the years (I use it a lot for package management/bootstrapping/cross compilation experiments), but it appears there already is one: https://lists.linuxfromscratch.org/sympa/arc/lfs-dev/2026-02...
I believe maintaining the base book is the most important part, BLFS has some really good hints but a very significant amount of packages have few differences, collecting these in a separate hints file or similar would help a bit, at least for things that don't hard-depend on systemd like gnome.
From a completely technical standpoint, is systemd really better than SysVInit? I ask this question in good faith. I have used both and had no problems with either, although for personal preference, I am more traditional and favor SysVInit.
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).
Wow this is sad. If any distro keeps the old ways around it should be LFS or Slackware I would think. And maybe Gentoo.
I'm honestly worried about the forces pushing systemd in Linux spoiling the BSD ecosystem. And I'm worried that the BSDs do not have enough people to forge alternatives and will have to go along with the systemdification of everything. sigh
*Note, I ended up on Cachy, which is systemd, so I'm not some pure virtue signaler. I'm a dirty hypocrite :P
"The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd that are not in System V."
I remember LFS from way back in the day.
What do we all think the overlap between LFS users and Gnome or KDE users is? I think it's pretty small.
I hate it when a website assumes the language I'm speaking based on my IP. There is no apparent way to change it as well. It's just lazy and hostile design in my opinion.
>The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd
Do people who really uses LFS even want GNOME or KDE on their system ?
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 is a mindblower. To quote Bruce Dubbs:
''As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important.
However, the decision needs to be made.''
Runit is 5474 SLOCs. Most source files are shorter than 100 lines. Works like a charm. Implements an init system; does not replace DNS, syslog, inetd, or anything else.
Systemd, by construction, is a set of Unix-replacing daemons. An ideal embedded system setup is kernel, systemd, and the containers it runs (even without podman). This makes sense, especially given the Red Hat's line of business, but it has little relation to the Unix design, or to learning how to do things from scratch.
I use runit on my production workstation and don't think about it; it just works.
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.
How is this best? It defeats the whole point. I’m going to stop recommending LFS to people wanting to learn about this stuff.
I disagree.
I will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software. It is built starting from LFS in 2019, and now consists of over 1,500 packages, cross compiling to x86-32/64, powerpc32/64, and others if I had hardware to test. It's built entirely from shell scripts which are clean, organized, and easy to read.
I need help to get the system ready for release in 60-90 days. In particular, I need a fast build system, as my current 12+ year old workstation is too slow. Alpha/beta testers are welcome too. Anyone who wants to help in some way or hear more details, please get in touch:
domain: killthe.net
user: dave
How did you get GTK3/4 to work without dbus?
So, devuan?
https://github.com/systemd/systemd/tree/main/src/core doesn't look like 1678 C files to me.
Github says 2.8k files when selecting c (including headers...) https://github.com/search?q=repo%3Asystemd%2Fsystemd++langua...
If the project is even split in different parts that you need to understand... already makes the point.
Well to be fair, you don't need to understand how SystemD is built to know how to use it. Unit files are pretty easy to wrap your head around, it took me a while to adjust but I dig it now.
To make an analogy: another part of LFS is building a compiler toolchain. You don't need to understand GCC internals to know how to do that.
> Well to be fair, you don't need to understand how SystemD is built to know how to use it.
The attitude that you don't need to learn what is inside the magic black box is exactly the kind of thing LFS is pushing against. UNIX traditionally was a "worse is better" system, where its seen as better design to have a simple system that you can understand the internals of even if that simplicity leads to bugs. Simple systems that fit the needs of the users can evolve into complex systems that fit the needs of users. But you (arguably) can't start with a complex system that people don't use and get users.
If anyone hasn't read the full Worse Is Better article before, its your lucky day:
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
In what way was Bruce incorrect, your one link excepted?
he is counting every c file in the systemd _repository_ which houses multiple projects, libraries and daemons. he equates that to the c file count for a single init. it's a disingenuous comparison. systemd-init is a small slice of the code in the systemd repository.
I'm guessing he shares my belief that systemd-init cannot exist in the wild on its own, correct? When you want a teacup, you have to get the whole 12 place dinner set.
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.
I know this is a bit tongue in cheek, but the systemd hate is so old and tiresome at this point.
I need my systems to work. Not once in my career have I experienced a showstopping issue with systemd. I cannot say the same for sysV.
I can absolutely say that I've never had a showstopping problem with sysv. That is about 30 years as a unix & linux admin and developer.
The whole point of sysv is the components are too small and too simple to make it possible for "showstoppers". Each component, including init, does so little that there is no room for it to do something wrong that you as the end user at run-time don't have the final power to both diagnose and address. And to do so in a approximately infinite different ways that the original authors never had to try to think up and account for ahead of time.
You have god power to see into the workings, and modify them, 50 years later in some crazy new context that the original authors never imagined. Which is exactly why they did it that way, not by accident nor because it was cave man times and they would invent fancier wheels later.
You're tired of hearing complaints? People still complain because the problem did not go away. I'm tired of still having to live with the fact that all the major distros bought in to this crap and by now a lot of individual packages don't even pretend to support any other option, and my choices are now to eat this crap or go off and live in some totally unsupported hut in the wilderness.
You can just go on suffering the intolerable boring complaints as far as I'm concerned until you grow some consideration for anyone else to earn some for yourself.
Equally tiring is the “it works for me so stop complaining” replies, which do nothing to stop the complaints but do increase the probability of arguments. Want the complaint posts to stop? Suggesting that they’re in some way invalid is not the way.
Yeah, it’s so tiresome that other people have a philosophy different from mine which seems to have prevailed for now. Like ok so sorry. Systemd on linux is the worst of both worlds imho which apparently according to GP to which I’m progressively less entitled. I like NetBSD and its rc init and config system. Oh no systemd sore winners incoming!
Imagine that, people on the internet disagreeing. I've had both sysv and sysd crap in my cheerios. The thing I appreciated about sysv was that it stayed in its lane and didn't want to keep branching out into new parts of the system. Sysvinit never proposed something like homed.
I understand where you’re coming from but early systemd with both ubuntu and centos was a fucking mess. It’s good now but goddamn it was painful and the hate is 100% justified.
Funny you should mention CentOS, which it outlived.
OP here. I was hoping we could avoid the interminable, infernal discussion of systemd vis-a-vis emotional states.
> Not once in my career have I experienced a showstopping issue with systemd. I cannot say the same for sysV.
I have had both ruin days for me. In particular the "hold down" when it detects service flapping has caused issues in both.
I use runit now. It's been rock solid on dozens of systems for more than a decade.
While I'll ignore the System D hyperbole, your point about Unix has merit.
I think the *BSD are also good, at least from an educational standpoint, with their relative simplicity and low system requirements. Since there is a lot of integration making a from scratch distro might take less material, but it could be supplemented with more in depth/sysadmin exploration.
From an education standpoint for those who really, really want to understand, the *BSD init and SysVinit systems require direct human administration. You break it, you fix it. Then, and only then, does learning systemd's ''then something happens behind the curtain'' type of automation make sense. If the student decides that one is more suitable than the other(s), they've done so from an enlightened vantage point.
I thought systemd was fairly straightforwards, even if it does too many different things for my tastes. What's an example of it doing a too much magic behind the curtain thing?
SysV init was the overengineered cousin to BSD init and I never liked it. Easily my least favorite of all init systems I've worked with over the last 30 years. On the flip side, daemontools or maybe runit were my favorites. Lots of good options for init/supervision tooling over the years and SysV was not among them.
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.
From the announcement, it saddens them too:
> As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files.
However the reasoning they provide makes sense.. It's hard to build a Linux system with a desktop these days without Sysd.
Yes, it's like asking students to actually produce something themselves.
What a horrific thought.
If the students have been well trained, they should be trusted to experiment. If the course curriculum demands that they produce something themselves yet does not educate them on doing so, that's horrific.
Certain things should only be taught as a warning. SysV init is one of them.
Back in the day, system run levels were seen as desirable. SysVinit went in on that concept to the max. So, if the concept of run levels isn't clear to the student beforehand, the init system for making it happen would therefore be mystifying and maybe even inscrutible.
Runlevels may be an interesting idea (e.g. the single-user maintenance level). But a bunch of shell scripts, each complex enough to support different commands, sort-of-declare dependencies, etc, is not such a great idea. A Makefile describing runlevels and service dependencies would be a cleaner design (not necessarily a nicer implementation).
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.
All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future, or at least a linux distro from the list here https://nosystemd.org/ - probably Gentoo. Nothing to stop me, absolutely nothing at all. I just need a few days free to backup/wipe/reinstall/reconfigure/restore_data and I'll be good. Better make that a few weeks. Maybe on my next machine build. It's not easy, but I build machines for long term use.
As for Linux from Scratch - This is something that's been on my radar, but without the part I'm truly interested in (learning more about SysV) then I'm less inclined to bother. I don't buy the reason of Gnome/KDE - isn't LfS all about the basics of the distro than building a fully fledged system? If it's the foundation for the other courses, but it still feels weak that it's so guided by a future GUI requirement for systemd when it's talking about building web servers and the like in a 500Mb or less as the motivation.
What practical problems do you run into with systemd?
All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic".
But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems.
People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap.
Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts.
Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.
Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound.
But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup.
To give you concrete examples:
1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts.
2. Except that you can, but only if you use the /etc/fstab compat.
3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device.
4. Systemd has separate behaviors for network and local filesystems.
5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!!
6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching.
7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1.
I can go on for a looooong time.
5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.
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.
systemd is not a monolith, and distros make different choices on what portions of systemd they which to ship and enable by default.
For example, not all distros ship and use systemd-resolved by default, to choose from your list.
systemd-boot competes with grub
and grub is a rotting pile while systemd-boot is a simple boot entry multiplexer that rides off the kernel's capability of being run as an EFI executable, it just happens to live in systemd's tree. not a good example
It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?
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.
> All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future
Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.
Popular desktop environments are increasingly depending on Linux-only things. KDE has officially removed support for FreeBSD in Plasma login manager (because of logind dependency).
Gnome 50 plans to obsolete X11 completely.
If you want that simple, bright future of yours, you’ll have to fight/work for it.
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
Others have been reminding us of the *BSD init systems, and I remind that SysVinit is not going away from Linux while projects like Devuan and others continue. GNU Hurd is another other-than-systemd learning opportunity.
I've heard of Hurd, but never felt tempted to try it. That could be an interesting option.
hurd init is a lot like systemd architecturally, it just gets to use kernel provided ipc rather than having to manage its own. if your objection to systemd is its architecture you don't want anything to do with hurd.
Did they finally add USB support?
I would somewhat doubt it; the negative aspects of Mach’s design are a technical albatross around the neck of any kernel.
Apple has had to invest reams of engineering effort in mitigating Mach’s performance and security issues in XNU; systemd dissatisfaction alone seems unlikely to shift the needle towards Hurd.
[delayed]
It's a pity. It's also a step back from valuing the Unix philosophy, which has its merits, especially for those with a "learning the system from scratch" mindset. Sorry, but I have no sympathy for systemd.
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.
It’s not just explaining but whether you have to support it on more than one distribution/version or handle edge cases. For a simple learning exercise, it can be easier to start with but even in the 90s it was notably behind, say, Windows NT 3 in a lot of ways which matter.
"When it's explained well" is the keyword
I'm not a systemD fan but SysV is not without its quirks and weirdness and foot guns
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 see how this relates to removing SysVinit support from LFS. Choice is good.
Are you entitled to the LFS developers time? They build the system they get to make into what they want.
That "choice" still has to be maintained. And why spend effort when you can do the same things + more with systemd?
Clearly there are lots of people who don't want something that does what you say systemd does. Bravo that choice is out there, but what a pity that LFS does not seem to have the resources to test future versions for SysVinit.
you can fork it and do it.
But frankly if goal is to learn people about how Linux works, having SysV there is opposite to that goal
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.
> and will start to resemble systemd
That's the point on which people differ. Even if we take as given that rc/svinit/runit/etc is not good enough (and I don't think that's been established), there are lots of directions you can go from there, with systemd just one of them.
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.
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)
That's funny, I did LFS a few years ago and specifically chose the systemd version so I could better understand it. I don't think this is a huge deal, I believe the older versions of the document that include SysVinit will still be available for a long time to come, and people who want it will figure out how to muddle through. If at some point in the future things diverge to such a point where that that becomes untenable, someone will step up and document how it is to be accomplished.
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.
> "ok install systemd..." and now... it just goes.
I believe it's `systemctl list-unit-files` to see all the config that's executed, included by the distro, and then if you want to see the whole hierarchy `systemd-analyze dot | dot -Tpng -o stuff.png`
To me, seems much easier to understand what's actually going on, and one of the benefits of config as data rather than config as scripts.
> Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files.
Systemd is basically the Windowsfication of Linux. I'm always surprised by the people that champion it who also used to shit on Windows with the registry or whatever.
Cognitive dissonance is a hell of a thing.
I was considering forking the base book and maintaining it, as I have kept an eye and occassionally built the project over the years (I use it a lot for package management/bootstrapping/cross compilation experiments), but it appears there already is one: https://lists.linuxfromscratch.org/sympa/arc/lfs-dev/2026-02...
I believe maintaining the base book is the most important part, BLFS has some really good hints but a very significant amount of packages have few differences, collecting these in a separate hints file or similar would help a bit, at least for things that don't hard-depend on systemd like gnome.
LFS. Brings back so many painful memories. But then, learned so much.
From a completely technical standpoint, is systemd really better than SysVInit? I ask this question in good faith. I have used both and had no problems with either, although for personal preference, I am more traditional and favor SysVInit.
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
Wow this is sad. If any distro keeps the old ways around it should be LFS or Slackware I would think. And maybe Gentoo.
I'm honestly worried about the forces pushing systemd in Linux spoiling the BSD ecosystem. And I'm worried that the BSDs do not have enough people to forge alternatives and will have to go along with the systemdification of everything. sigh
*Note, I ended up on Cachy, which is systemd, so I'm not some pure virtue signaler. I'm a dirty hypocrite :P
So this will be the final SysVinit version https://www.linuxfromscratch.org/lfs/downloads/12.4/
"The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd that are not in System V."
I remember LFS from way back in the day.
What do we all think the overlap between LFS users and Gnome or KDE users is? I think it's pretty small.
I hate it when a website assumes the language I'm speaking based on my IP. There is no apparent way to change it as well. It's just lazy and hostile design in my opinion.
What does "support" mean
On 01 March 2026 the next versions of LFS and BLFS will not include SysVinit instructions a.k.a. ''support''.
>The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd
Do people who really uses LFS even want GNOME or KDE on their system ?
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.
Just rename Linux to SystemD OS at this point..
Excuse me, that's GNU/SystemD/Linux.