Next.js Hacker News
Linux From Scratch ends SysVinit support
89 points by cf100clunk 8 hours ago | 130 comments
  • cf100clunk
    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.''

    • nine_k
      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.

      • binkHN
        I use runit on my production workstation and don't think about it; it just works.
      • p_ing
        > but it has little relation to the Unix design

        It's more like Windows! /duck

        • its_magic
          I have been saying for years that Microsoft would eventually deprecate WinNT and switch Windows over to a Linux foundation. Things seem to be slowly but continually moving in that direction.
          • p_ing
            Makes no sense to dump a superior kernel and executive for Linux.

            The Win32 layer is the issue, not the underbelly.

    • clintfred
      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.
      • its_magic
        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

      • adastra22
        How is this best? It defeats the whole point. I’m going to stop recommending LFS to people wanting to learn about this stuff.
        • spijdar
          Learn about what stuff? Linux? System V UNIX?

          I haven't done LFS since my tweens (and I'm almost 30 now), but I remember the sysvinit portion amounted to, past building and installing the init binary, downloading and extracting a bunch of shell scripts into the target directory and following some instructions for creating the right symlinks.

          Obviously, you can go and check out the init scripts (or any other individual part of LFS) as closely as you wish, and it is easier to "see" than systemd. But I strongly protest that sysvinit is either "Linux" (in that it constitutes a critical part of "understanding Linux" nor that it's really that understandable.

          But setting aside all of that, and even setting aside the practical reasons given (maintenance burden), when the majority of "Linux" in the wild is based on systemd, if one wanted to do "Linux From Scratch" and get an idea of how an OS like Debian or Fedora works, you would want to build and install systemd from source.

          • adastra22
            For me, Linux From Scratch is not about compiling linux from scratch, but on building up an entire Linux distro from the ground up, understanding how every piece fits together.

            Doing it via systemd is like drawing a big black box, writing LINUX on the side, and calling it a day.

            • rcxdude
              You are necessarily working with very big blocks when you're doing this, anyway. You don't do a deep dive on a whole bunch of other topics in LFS, because otherwise the scope would become too big.
        • csb6
          "best" meaning the best decision the LFS team can make given their limited, unpaid time and resources. They feel maintaining guides for two parallel init systems is unsustainable even though they would prefer not to have systemd as the only option.
          • its_magic
            The actual best decision would be to stick with his principles and make LFS be sysvinit-only instead, with zero fucks given about Gnome/KDE if they refuse to play ball.

            I for one will not be strong armed into systemd or any other tech. If KDE makes it impossible for me to run without systemd, it goes into the trash bin. I will just install Trinity (KDE3) and be done with it. (Gnome deserves no consideration whatsoever.)

    • raggi
      https://github.com/systemd/systemd/tree/main/src/core doesn't look like 1678 C files to me.
      • cientifico
        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.

        • ktm5j
          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.

          • josephg
            > 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

            • ktm5j
              LFS is full of packages that fit your description of a black box. It shows you how to compile and configure packages, but I don't remember them diving into the code internals of a single one.

              I understand not wanting to shift from something that is wholly explainable to something that isn't, but it's not the end of the world.

              • josephg
                No, its not the end of the world. And I agree, LFS isn't going to be the best resource for learning how a compiler works or cron or ntp. But the init process & systemd is so core to linux. I can certainly see the argument that they should be part of the "from scratch" parts.
                • ktm5j
                  You still build it from scratch (meaning you compile from source).. they don't dive into Linux code internals either.

                  They still explain what an init system is for and how to use it.

          • adastra22
            The whole point of LFS is to understand how the thing works.
      • cf100clunk
        In what way was Bruce incorrect, your one link excepted?
        • raggi
          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.
          • cf100clunk
            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.
            • rcxdude
              IIRC the mandatory components are the init system, udev, dbus, and journald. Journald is probably the most otherwise-optional feeling one (udev and dbus are both pretty critical for anything linux regardless), though you can put it into a passthrough mode so you don't have to deal with its log format if you don't want. Everything else is optional.
    • soldoutcold
      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.
      • procone
        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.

        • Brian_K_White
          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.

        • mirashii
          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.
          • user3939382
            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!
        • lagniappe
          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.
        • adastra22
          My experience, and the common experience I’ve read, is the exact opposite. Run scripts worked. They always worked. They were simple. I’ve run into so many difficulties with systemd, on the other hand. I gave up managing my own server as a result.
        • chucky_z
          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.
          • fragmede
            Funny you should mention CentOS, which it outlived.
        • cf100clunk
          OP here. I was hoping we could avoid the interminable, infernal discussion of systemd vis-a-vis emotional states.
        • themafia
          > 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.

      • molticrystal
        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.

        • cf100clunk
          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.
          • fragmede
            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?
            • cf100clunk
              Bear in mind that the entire purpose of systemd is to replace a huge amount of previous system administration solutions in a fashion that is centralized and automated, and not in need of as much human intervention as previous init systems. For copious examples, look through these comments and the huge number of previous HN threads on this huge topic. That is my answer.
  • eikenberry
    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.
    • cf100clunk
      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.
      • onraglanroad
        Yes, it's like asking students to actually produce something themselves.

        What a horrific thought.

        • cf100clunk
          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.
      • ktm5j
        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.

        • dTal
          Is it? What's the connection between systemd and having a desktop?
      • nine_k
        Certain things should only be taught as a warning. SysV init is one of them.
        • cf100clunk
          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.
          • nine_k
            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).
    • acdha
      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.
  • antonyh
    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.

    • hparadiz
      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.

    • tokyobreakfast
      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.

      • bryanlarsen
        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.

        • bsimpson
          systemd-boot competes with grub
          • bryanlarsen
            Even better example, I don't think systemd-boot is broadly adopted yet although there are certainly some distributions that use it.
          • 5G_activated
            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
            • fragmede
              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?
              • bryanlarsen
                Nobody complains about a very wide variety of only vaguely related utilities being in the Gnu coreutils tree.
                • Foxboron
                  Nor the 20 or so odd reimplementations of various filesystem drivers and LUKS encryption in the grub2 tree.

                  But, who is counting?

              • 5G_activated
                so its a marketing problem, irregardless of whether it's in systemd's tree because the systemd maintainers want to maintain it in-tree
    • razighter777
      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.

      • cyberax
        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.

        • nomel
          5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.
          • cyberax
            They're already reported. And ignored. Have you _seen_ the systemd issue backlog?

            The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored.

            The remote FS detection also came up multiple times, and the maintainers don't care.

            • nomel
              > and the maintainers don't care.

              I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report.

              This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.

              • cyberax
                The problem here is more fundamental.

                Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because."

                I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy.

                I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local").

                I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.

                • dTal
                  This is one example of a more general complaint about systemd and related projects: they force policy, rather than simply providing mechanisms.

                  I recently did a deep dive on my laptop because I was curious about an oddity - the /sys file to change my screen backlight (aside, why /sys and not /dev anyway?) was writable only by root - yet any desktop shell running as my user had no problem reacting to brightness hotkeys. I wondered, how did this privilege escalation work? Where was the policy, and what property of my user account granted it the right to do this?

                  It turns out the answer is that the desktop shells are firing off a dbus request to org.freedesktop.login1, which is caught by systemd-logind - or elogind in my case, since I do not care for systemd. A login manager seemed an odd place for screen brightness privilege escalation, but hey if it works whatever - it seemed like logind functioned as a sort of miscellaneous grab bag of vaguely console-related stuff. Generally speaking, it consults polkit rules to determine whether a user is allowed to do a thing.

                  Not screen brightness, though. No polkit rules. Nothing in pkaction. logind was unilaterally consenting to change the brightness on my behalf. And on what grounds? It wasn't documented anywhere so I had to check the source code, where I found a slew of hardcoded criteria that mostly revolve around physical presence at the machine. Want to change screen brightness over ssh? Oh but why would you ever want to do that? Hope you have root access, you weirdo.

                  I removed elogind. A few odds and ends broke. But nobody tells me what to do with my machine.

    • Fwirt
      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.
    • cmrdporcupine
      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

      • cf100clunk
        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.
      • antonyh
        I've heard of Hurd, but never felt tempted to try it. That could be an interesting option.
        • raggi
          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.
      • tokyobreakfast
        Did they finally add USB support?
      • frumplestlatz
        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.

    • josteink
      > 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.

      • Timon3
        > Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.

        Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else?

        [0]: see discussion & linked issues in the announcement https://news.ycombinator.com/item?id=44199502

        • josteink
          I’m talking about that developer, yes. And I’m sure there’s more to the story than just ABI compatibility.

          He wanted X11 to thrive. Freedesktop however has a goal for Wayland ultimately to replace X11, right? X11 should die. This is not hyperbole. It’s a stated goal.

          So I think there’s more to the story than the simplified ABI aspect often mentioned here on HN.

          Also Gnome killing X11 support is real.

          So is KDE backing down on BSD-support.

          These are facts, not opinions.

    • its_ubuntu2
      [flagged]
      • cf100clunk
        I see this was your first HN contribution and you didn't post any links, so maybe that's what they were thinking?
        • its_ubuntu2
          Links? To what? "First contribution"? I'm not new around here.

          (If anyone is wondering what he's referring to--I said that I was mystified why my post would be immediately downvoted.)

          Let's try again, much shorter this time:

          I am releasing a distro soon that is right up your alley. SEE MY PROFILE for info.

  • smartmic
    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.
    • cf100clunk
      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.
      • acdha
        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.
      • raverbashing
        "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

    • PunchyHamster
      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

      • cf100clunk
        I don't see how this relates to removing SysVinit support from LFS. Choice is good.
        • reppap
          Are you entitled to the LFS developers time? They build the system they get to make into what they want.
        • preisschild
          That "choice" still has to be maintained. And why spend effort when you can do the same things + more with systemd?
          • cf100clunk
            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.
            • PunchyHamster
              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

    • nialv7
      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.

      • wiml
        > 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.

    • tapoxi
      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)
    • bigstrat2003
      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.
  • JCattheATM
    > 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.

  • greatgib
    The proof in the end that SystemD is a cancer in the Linux ecosystem. Officially it is just a stack and you can decide to use another one if you don't like it. Unofficially RedHat money ensured that other critical stacks will depend heavily on it so that you can't easily swap without replacing the whole ecosystem.
  • 0xbadcafebee
    > packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd

    So drop them. There are other desktops that are faster, simpler, more stable, and aren't hard-coded to make Linux worse. Has everyone forgotten the design principles that made Linux good in the first place? Tightly coupling your software into other software is simply bad design. At some point you need to eat the cost of a looser abstraction to make your system less fragile, easier to reason about, and more compatible.

  • cjk
    Man. I'd really rather they did the inverse: drop systemd and only maintain the SysV versions of the materials, even if that means dropping GNOME/etc., because I think understanding the Linux init process is far more important than making any specific desktop environment available.
  • spudlyo
    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.
    • cf100clunk
      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.
    • kevstev
      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.

      • nomel
        > "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.

        • kevstev
          Yeah- but LFS didn't really expose you to that or really teach you much about Systemd internals. Here is the page on it: https://www.linuxfromscratch.org/lfs/view/systemd/chapter09/...

          The only other page that covers it is how to compile it and it install it (make configure, make, make install essentially- with a bunch of flags).

          It kind of touches upon a few commands that will let you know what its doing and how to get it started, but from this page you don't learn much about how it works.

          In fact, one of my takeaways from LFS was that I already kind of knew how a linux system starts... and what I really wanted to learn was how the devices are discovered and configured upon startup to be used, and that is pretty much all done in the black box that is SystemD.

  • mid-kid
    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.

  • byte_0
    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.
    • rcxdude
      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).
    • 0xbadcafebee
      One is not better than the other because they exist to solve different problems. Are sandals technically better than snowshoes?
    • IshKebab
      Yes, much better. The original intro blog post goes into detail: https://0pointer.de/blog/projects/systemd.html
  • tmtvl
    Kind of related: The Great Debian Init Debate <https://aaonline.fr/search.php?search&criteria[sequenceId-is...>
  • abhisek
    LFS. Brings back so many painful memories. But then, learned so much.
  • haunter
    So this will be the final SysVinit version https://www.linuxfromscratch.org/lfs/downloads/12.4/
  • ErroneousBosh
    "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.

  • SockThief
    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.
  • 1vuio0pswjnm7
    What does "support" mean
    • cf100clunk
      On 01 March 2026 the next versions of LFS and BLFS will not include SysVinit instructions a.k.a. ''support''.
    • zxcvasd
      [dead]
  • wormius
    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

  • WhereIsTheTruth
    Just rename Linux to SystemD OS at this point..
    • mhurron
      Excuse me, that's GNU/SystemD/Linux.
      • SAI_Peregrinus
        You joke, but it's a decent comparison. Both GNU and SystemD are projects with a bunch of miscellaneous tools with excessively strong coupling. In GNU's case that's the various userland tools relying on glibc. Both are used in the majority of Linux distros, and while there are distros without them they're not particularly mainstream. Many tools expect their options & custom ways of working, e.g. huge numbers of shell scripts are BASH-specific and need GNU coreutils instead of being portable POSIX shell scripts. Both make developers' lives easier compared to the lowest-common-denominator required by POSIX, which makes sense because POSIX is intended to be a common subset of functionality found across different UNIX OSes.

        It's not a perfect equivalence, of course, SystemD diverges more from other UNIXes than GNU does.

  • jmclnx
    >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 ?

    • cf100clunk
      I would think people who use LFS are doing it for the learning experience and not necessarily for a daily driver OS.
    • spudlyo
      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.