10 ms·

Linux From Scratch ends SysVinit support

225 points by cf100clunk 8mo ago

cf100clunk 8mo ago
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.''
- clintfred 8mo ago
  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 8mo ago
    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
    - ripdog 8mo ago
      So, devuan?
      - its_magic 8mo ago
        No, not even close. Totally different projects. This one is for experts only, or those who want to become experts. The type of person who has been toying with the idea of building a LFS system but doesn't really want to go through all the work and headache (and it's a ton, to build a full system.) It also supports cross compiling to other architectures, which LFS does not. This system has many powerful features like built in ccache/distcc support for the build, support for building in QEMU, etc. Eventually it will be fully sandboxed. There is a heavy emphasis on Doing Things Right according to an old school way of thinking. Everything is kept as simple as possible, yet as full featured as is practical. A major goal is to have everything documented and explained, starting with the shell scripts which build the system step by step in an easy to follow manner. No package manager currently, though a simple one is in the works which is integrated into the build scripts. It's not really needed. You just build a complete system with all packages you want installed in a single run, with your own configuration pre-loaded. This gets compressed to a tarball. Then to install, create a partition, extract the tarball, edit a few files, install the bootloader, set passwords, and go.
    - M95D 8mo ago
      How did you get GTK3/4 to work without dbus?
      - its_magic 8mo ago
        I got rid of dbus in GTK3 by patching the code so that the "accessibility bridge" (to ATK) can be disabled. GTK4 is beneath contempt and will not be supported. The system uses GTK2 wherever possible, or GTK3 when not. I will either port everything to GTK2 later or create some kind of shim library. Help wanted here. Porting back to GTK2 isn't hard, I just don't have time to work on any of that at the moment.
        M95D 8mo ago
        I'm running Gentoo without dbus and I'm stuck at gtk 3.24.34. I would love to see those patches. Your site appears to be down.
        its_magic 8mo ago
        It's just HTTP only (no SSL) and there's nothing there. ... until now! Here's some nice GTK3 patches for you: http://killthe.net/patches/gtk-3.24.43-allow-disabling-atk-bridge.patch http://killthe.net/patches/gtk-3.24.43-allow-disabling-atk-b... http://killthe.net/patches/gtk-3.24.43-allow-transparent-windows.patch http://killthe.net/patches/gtk-3.24.43-allow-transparent-win... http://killthe.net/patches/gtk-3.24.43-allow-wheel-scrolling-in-notebook.patch http://killthe.net/patches/gtk-3.24.43-allow-wheel-scrolling... http://killthe.net/patches/gtk-3.24.43-appearance-tweaks-and-fixes.patch http://killthe.net/patches/gtk-3.24.43-appearance-tweaks-and... http://killthe.net/patches/gtk-3.24.43-disable-mnemonics-delay.patch http://killthe.net/patches/gtk-3.24.43-disable-mnemonics-del... http://killthe.net/patches/gtk-3.24.43-file-chooser-tweaks.patch http://killthe.net/patches/gtk-3.24.43-file-chooser-tweaks.p... http://killthe.net/patches/gtk-3.24.43-remove-dead-key-underline.patch http://killthe.net/patches/gtk-3.24.43-remove-dead-key-under... http://killthe.net/patches/gtk-3.24.43-restore-old-context-menu.patch http://killthe.net/patches/gtk-3.24.43-restore-old-context-m... http://killthe.net/patches/gtk-3.24.43-set-default-settings.patch http://killthe.net/patches/gtk-3.24.43-set-default-settings.... http://killthe.net/patches/gtk-3.24.43-show-alternating-row-colors.patch http://killthe.net/patches/gtk-3.24.43-show-alternating-row-... Note that GTK 3.24.43 is the last version of GTK3. My system is full of patches like this to tweak, improve, and adjust things. The point is to get off the "upgrade" treadmill and focus on making things work right.
    - happymellon 8mo ago
      > I will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software. What makes you decide that these are troublesome software's? Systemd is usually argued that it is monolithic and breaks the Unix paradigm. But then you are going for X over Wayland? X is a monolithic application that breaks the Unix paradigms. Are you just picking things because they are old, or is there a reason you decided to go with this setup?
      - its_magic 8mo ago
        The difference is that the people who designed X11 were honest in their intentions. The authors of systemd, wayland, etc are not. I'll just leave it at that. (I recommend staying far away from "X11libre" also, for the same reason, with no further comment.) Monolithic stuff is OK too, where it makes sense. The kernel is monolithic. ZFS is monolithic. (Yes, this system has ZFS support. The module is built in to the kernel. In time it will support booting from ZFS also, when I finish the initrd code.) There is a clear, solid reason for everything this system is or does. I'm not a contrarian or a purist, just someone with opinions gained from long experience who is not happy with the direction mainstream Linux is headed. My system is a zen garden of bliss compared to buggy garbage like Ubuntu. Really, it's like someone added a turbo button. Ubuntu and friends are so bloated, laggy, and slow. I regularly use this system on 15-20+ year old hardware. The default window manager is Enlightenment e16. It's snappy and responsive everywhere. KDE, Xfce, etc are supported also and are noticeably peppier than on mainstream distros, just due to the lack of bloat, gazillions of daemons running in the background, etc. Out of the box, nothing runs by default. You enable only what you want. Another inviolable principle is that no application is allowed to originate or receive network traffic unless the user specifically requests it. There is ZERO network activity going on in the background. None of this steady stream of who knows what contacting who knows where that goes on with other systems. No auto update etc. No internet required or used during the system build. Python module installs do not consult the central repository or download anything. Meson or cmake does not download anything. Etc. All that's patched out and disabled. It's a distro that is meant to be forked. It's very easily done. It's a blank slate, a vanilla Linux system with subtle and tasteful improvements that is the ideal starting point to customize to your exact specifications. If you want to add in systemd and wayland, fine, I don't care, it's your system and you can build it according to your desires. People can use this platform to build their own custom OS and save themselves a ton of work vs. starting completely from scratch. It's a system that can be audited. Everything is built with shell scripts, starting with source archives and patches that are applied during the build process. It's all inspectable and the process can be understood step by step. It's a way to hit the ground running with a full featured, working system, while learning in the process. This distro will teach you what LFS would teach you, but with less of a "sheer cliff face" learning curve, letting you focus more on higher aspects of building the system while still learning the low level details in time. The build is actually overall simpler than LFS despite being way more featured, with things like Ada support. (Yes, it has GNAT.) I just found a way to do it better, and kept iterating countless times to simplify and improve to the max. Existing systems did not satisfy my requirements or standards of quality, so I just had to create a new one.
  - adastra22 8mo ago
    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 8mo ago
      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 8mo ago
        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 8mo ago
        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.
        spijdar 8mo ago
        That's what I was trying to get at -- yes, you can say that sysvinit is easier to understand than systemd, and less of a black box. But, even still, a "real Linux distribution" is full of these black boxes, especially the closer you get to being able to run "real applications". I'd argue that once you get into full desktop seat management, you add so much complexity on top of sysvinit that the difference narrows... Which is why I asked "learn about what stuff". I think if the goal is to learn about "Unix" or OS design/ideas, you're better off with a leaner, "pedagogical" OS, like xv6. If the goal is to piece together an OS and really understand each piece, I don't think you really want sysvinit. You want something closer to an /etc/rc.local that just kicks off a few daemons and hopes for the best. You can argue that sysvinit makes a better "compromise" between usability and clarity, and I'd entertain that idea, but then I think dinit is far easier to understand than sysvinit. And of course, at that point you can shave yaks till you fill the bike shed with wool. Realistically, as much as people may hate it, if you have to pick a single init to standardize on for clarity and "building an entire Linux distro from the ground up, understanding how every piece fits together", systemd is the most rational choice. It's the most representative of the ecosystem, and requires the least "extra layers" to make the "desktop layer" work.
- soldoutcold 8mo ago
  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 8mo ago
    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.
    - themafia 8mo ago
      > 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.
    - cf100clunk 8mo ago
      OP here. I was hoping we could avoid the interminable, infernal discussion of systemd vis-a-vis emotional states.
    - mirashii 8mo ago
      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 8mo ago
        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!
- raggi 8mo ago
  https://github.com/systemd/systemd/tree/main/src/core https://github.com/systemd/systemd/tree/main/src/core doesn't look like 1678 C files to me.
  - cf100clunk 8mo ago
    In what way was Bruce incorrect, your one link excepted?
    - raggi 8mo ago
      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 8mo ago
        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 8mo ago
        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.
        simoncion 8mo ago
        > ... dbus [is] pretty critical for anything linux regardless Weird. If I weren't a sicko and had OBS Studio installed on my multipurpose box [0] I'd not have dbus installed on it. dbus is generally optional; not that many packages require it. [1] [0] Two of its several purposes are video transcoding and file serving. [1] This is another area where Gentoo Linux is (sadly) one of the absolute best Linux distros out there.
- nine_k 8mo ago
  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 8mo ago
    I use runit on my production workstation and don't think about it; it just works.
    - BadBadJellyBean 8mo ago
      Same with systemd.
      - its_magic 8mo ago
        Except for all those who've accidentally blown their legs off with it, of course. Just ask the guy who bricked his motherboard due to a systemd bug where his firmware wasn't write protected and got destroyed by a 'rm -rf' command. lol
        BadBadJellyBean 8mo ago
        No software is perfect. Not sysvinit (and it's bash scripts from different vendors), nor systemd. Errors happen. At least for me systemd is a net positive.
        its_magic 8mo ago
        > No software is perfect Especially when it's a giant blob of buggy C code written by a known hack who has multiple decades' worth of history of foisting shit code upon a less than enthused public. > At least for me systemd is a net positive For the moment. Just wait until it finds a way to fuck you. It's plotting and scheming behind your back to do so as we speak. Systemd for some reason seems to uniquely be the epicenter of giant facepalm bugs like LEAVING THE SYSTEM FIRMWARE VULNERABLE TO AN RM -RF COMMAND, a situation which causes alarm to none of the systemd crowd. They just shrug if off. "What's the big deal? I don't get it," they say. I used to see the same mentality from Microsoft people back in the day. "Why would you use Linux? I don't get it. Windows is fine." It's because you lack standards. You're completely used to being surrounded by software and hardware that is Fucking Garbage. Everything is like that in your world. You're happier than a pig in shit, oblivious.
- charcircuit 8mo ago
  Linux is literally 62k C files. The amount of time you'll spend understanding how Linux works will dwarf systemd. At least when studying systemd you will be learning a more modern approach of init systems.
  - varjag 8mo ago
    Most of those files are device/fs/network drivers and various arch support. The core you need to comprehend is not that much larger than systemd.
    - its_magic 8mo ago
      Or to put it another way, systemd has grown to become so large and complex it's like a kernel unto itself.
  - deleted 8mo ago
    [deleted]
- jeroenhd 8mo ago
  I don't mind the inevitable death of System V. It's an archaic relic of the Linux era. Going systemd-only is not necessarily a good choice (though I do understand it from a practical point of view). There are other, better alternatives for System V that are smaller and more modular so you still get the Unix "feel" without the absurd complexity of interlinked shell scripts that System V relies on. I'd like to see OpenRC getting adopted in System V's place. Upstart seems to be dead (outside of ChromeOS) but it would also have sufficed. Alas, I'm not someone with the time or knowledge to maintain these tools for LFS, and unless someone else steps up to do all the hard work, we'll probably see LFS go systemd-only. That said, there's no reason to go full-fat systemd, of course.
  - cbolton 8mo ago
    I think systemd is the one to learn now if you want to learn Linux. Maybe someone can make a Unix from Scratch for people more interested in the Unix philosophy than Linux per se.
    - jeroenhd 8mo ago
      systemd is most certainly the most pragmatic service to learn, but if you're doing LFS to "learn" how a Linux system gets brought up, something lower-level may be a better idea to pick up.
      - prmoustache 8mo ago
        All this stuff is versioned anyway so if the point is learning youe can still read an old version of the book and use old versions of the repos.
    - cbmuser 8mo ago
      SysVInit on Linux isn’t true Unix though as the way it abuses runlevels to start daemons was never intended by the original designers of init.
      - roryirvine 8mo ago
- DyslexicAtheist 8mo ago
  > To me LFS is about learning how a system works. I'd just like to interject for a moment. What you're referring to as Linux, is in fact, Linux plus systemd, or as I've recently taken to calling it, Linux/systemd. Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd corelibs, systemd daemons, and vital systemd components comprising a full OS as defined by Poettering. -- https://mastodon.social/@fribbledom/116002799114521341 https://mastodon.social/@fribbledom/116002799114521341
  - bjourne 8mo ago
    This, of course, is a tongue in cheek.
  - its_magic 8mo ago
    8/10
- cbmuser 8mo ago
  SysVInit is abusing runlevel scripts for starting daemons which has always been a hack to be able to resolve dependencies between daemons. Learning Linux or Unix from scratch shouldn’t include using crude hacks.
  - its_magic 8mo ago
    I'm with you on this. SysVinit is better than systemd, but far from perfect. I don't enjoy tediously maintaining all of those symlinks, and prefer the BSD approach myself. One project on my distro is a new init that will be much, much simpler than SysV, more like BSD and without all the years of cruft.
1vuio0pswjnm7 8mo ago
What does "support" mean
- cf100clunk 8mo ago
  On 01 March 2026 the next versions of LFS and BLFS will not include SysVinit instructions a.k.a. ''support''.
- zxcvasd 8mo ago
  [dead]
smartmic 8mo ago
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 8mo ago
  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.
  - raverbashing 8mo ago
    "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
  - acdha 8mo ago
    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.
- PunchyHamster 8mo ago
  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 8mo ago
    I don't see how this relates to removing SysVinit support from LFS. Choice is good.
jmclnx 8mo ago
>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 ?
- Someone100 8mo ago
  I use Sway window manager and am more than happy to avoid those huge bloated Guiwares
- cf100clunk 8mo ago
  I would think people who use LFS are doing it for the learning experience and not necessarily for a daily driver OS.
- spudlyo 8mo ago
  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.
abhisek 8mo ago
LFS. Brings back so many painful memories. But then, learned so much.
spudlyo 8mo ago
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 8mo ago
  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 8mo ago
  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 8mo ago
    > "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 8mo ago
eikenberry 8mo ago
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 8mo ago
  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 8mo ago
    Yes, it's like asking students to actually produce something themselves. What a horrific thought.
    - cf100clunk 8mo ago
      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.
  - nine_k 8mo ago
    Certain things should only be taught as a warning. SysV init is one of them.
    - cf100clunk 8mo ago
      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.
JCattheATM 8mo ago
> 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.
- um1 8mo ago
  LFS seems to be for people who are interested in how things work. The systemd proponents come off as people who would question why you would want to to drive a manual transmission and say of course you should choose an automatic or better yet, a robot; self driving car. It would be interesting to see how those opinions line up with the uses of AI
  - ryukoposting 8mo ago
    I have owned many manual cars, but I'm fine with systemd on all my machines. Being a nerd about one thing doesn't require me to be a nerd about other things.
- tuetuopay 8mo ago
  Pedantic but systemd is inspired by MacOS launchd, not by Windows services. It has nothing akin to the registry, which even microsoft admits is a pain on windows. Oh, and usually people shit on windows for many reasons, but some of the very core features of the OS are robust and the Linux crowd could take a hint. Like, you know, the notion of service at the OS-level and not some random bash script that nohup'd a binary. Oh wait, that's what does Windows, MacOS and Linux with systemd.
  - JCattheATM 8mo ago
    I didn't say it was inspired by the registry, I just drew a comparison. In both cases you have a huge binary thing that you have to interact with through secondhand tools rather than directly.
haunter 8mo ago
So this will be the final SysVinit version https://www.linuxfromscratch.org/lfs/downloads/12.4/ https://www.linuxfromscratch.org/lfs/downloads/12.4/
antonyh 8mo ago
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/ 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.
- cmrdporcupine 8mo ago
  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
  - antonyh 8mo ago
    I've heard of Hurd, but never felt tempted to try it. That could be an interesting option.
    - raggi 8mo ago
      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.
  - cf100clunk 8mo ago
    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.
WhereIsTheTruth 8mo ago
Just rename Linux to SystemD OS at this point..
- mhurron 8mo ago
  Excuse me, that's GNU/SystemD/Linux.
  - SAI_Peregrinus 8mo ago
    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.
    - LeFantome 8mo ago
      Just call it the Red Hat Linux Platform. Both GNU (glibc, binutils, GNU utils, GCC, etc) and Systemd are primarily maintainted by them. Same with Wayland and GNOME. Red Hat defines what "Linux" is these days.
- jvreeland 8mo ago
  systemd not SystemD
  - deleted 8mo ago
    [deleted]
  - tosti 8mo ago
    systemdick
SockThief 8mo ago
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.
byte_0 8mo ago
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 8mo ago
  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).
  - bandrami 8mo ago
    Is this really that hard to type? https://github.com/openbsd/src/blob/master/etc/rc.d/watchdogd https://github.com/openbsd/src/blob/master/etc/rc.d/watchdog...
    - abenga 8mo ago
      Probably not, but it looks a hell of a lot harder to understand than a unit file.
      - bandrami 8mo ago
        Huh? Not even remotely
        deleted 8mo ago
        [deleted]
mid-kid 8mo ago
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/msg00001.html 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.
wormius 8mo ago
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
ErroneousBosh 8mo ago
"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.
0xbadcafebee 8mo ago
> 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.
greatgib 8mo ago
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.
- LeFantome 8mo ago
  The whole GNU / Red Hat platform is this way. Try switching out Glibc. You get the same "you have to use all our stuff" dependencies.
  - tosti 8mo ago
    Musl mostly works. I had more trouble taking out bash, because of all the random bashisms.
    - its_magic 8mo ago
      On my system I forked dash to create 'bolderdash.' Right now it's pretty basic, I have changed little (just did some cleanup), but I did add in a couple tweaks to enhance bash compatibility. The goal is a complete refactor, more compatibility with bash, and much better command line editing etc, while still remaining sleek and lightweight. I'm also forking musl to create 'powrlibc.' It will have a lot better glibc compatibility, as well as better optimizations and some other improvements.
  - guerrilla 8mo ago
    Switching out glibc is pretty easy compared to systemd. That's the thing peoplle don't get. systemd is seriously insidius, like a virus.
    - matteotom 8mo ago
      I've personally run Gentoo with OpenRC+glibc and OpenRC+musl on my laptop. I assure you ditching systemd was easier than ditching glibc. The OpenRC system mostly just works (tbh thanks to a lot of great work by Gentoo devs). The musl system required probably a couple dozen patches to various packages to get a basic fully working desktop (most of which were relatively straightforward, but still needed manual intervention).
tmtvl 8mo ago
Kind of related: The Great Debian Init Debate <https://aaonline.fr/search.php?search&criteria[sequenceId-is]=6512_en_Debian%20init%20case https://aaonline.fr/search.php?search&criteria[sequenceId-is...>
- listentomineral 8mo ago
  This is the absolute perfect format to read these threads. Thanks for sharing.
cjk 8mo ago
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.
sxzygz 8mo ago
Sadly is Linux is no longer what is used to be for my generation that cut their teeth having to patch kernels for basic hardware support. Linux is now effectively systemd/linux, and is attempting to become flatpak/systemd/linux through various corporate sponsored initiatives. The only thing worse, in my eyes, are people who distribute things as docker containers. The Linux distro as such is becoming an anachronism. There’s no real place to innovate without the inertia of choices made by external projects being enforced on you. I think it’s a generational change. My generation had Microsoft to contend with, and so sought certain freedoms, but this generation has walled gardens and AI to contend with, so freedom à la Microsoft seems okay and so Linux is being Windows-ified, while Windows itself becomes its own abomination.
- pjmlp 8mo ago
  I would have not bothered with Linux if Windows NT had a proper UNIX subsystem. I needed a way to avoid going to campus and fight for a DG/UX terminal. It had nothing to do with FOSS fighting.
  - jeroenhd 8mo ago
    > if Windows NT had a proper UNIX subsystem They actually did, but they made the mistake of packaging only the bare basics with it, and hiding it away as much as they could: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX https://en.wikipedia.org/wiki/Windows_Services_for_UNIX The American government added some obscure law that forced POSIX compatibility on operating systems for certain grants, so Microsoft made their business OS POSIX-compliant. In theory, nothing stopped you from downloading and installing up-to-date versions of common UNIX tools. Had Microsoft had the necessary foresight, they could've killed deverlopers' dependency on tools like Cygwin and Git Bash and Linux entirely for many pieces of software, but they were too busy trying to make Win32 the standard ABI. Funnily enough, Win32 became the standard for proprietary software on Linux (thanks to Wine+Proton) while many Unix/Linux-based tools became the norm for development, even on Windows (git, Qt). How different things could've been!
    - pjmlp 8mo ago
jupake 8mo ago
Modern mechanical engineers, to this day, learn the thermodynamics of steam engines. Not because they are living in the past, but because they are building foundation knowledge that will permeate everything they'll be doing in the future. LFS should stick to academic pedagogy, instead of trying to compete in the Linux Distro space.
- idoubtit 8mo ago
  The world is vast, and I doubt that every mechanical engineer has studied steam engines, and that it makes a difference in the end. Most modern programmers don't learn COBOL60 or Commodore BASIC. Modern mathematician very rarely study writings of Euler or Gauss; even 50 years old math books may be hard to grasp for modern students. I agree that using a simpler tool for educational purpose is useful, but since SysVinit is obsoleted almost everywhere, it made sense to drop it. LFS could have chosen a simpler init than the domain standard, like runit or s6-init.
  - its_magic 8mo ago
    "Obsolete"? Apparently you aren't paying close attention. See this GIANT argument with hundreds of comments? It seems some people believe that SysVinit is, in fact, not even close to obsolete. If Gnome/KDE can't support the init system I choose to use, then I don't choose to use their garbage software anymore.
nice_byte 8mo ago
I had stopped using linux at the start of the systemd takeover (it was not because of systemd). What I don't understand is how this has happened. I didn't care either way but everybody who did seemed to really fucking hate systemd. Then how come it became the default in so many distributions, with so much opposition from the community?
- nacozarina 8mo ago
  M$ is pushing hard and not pushing alone
- mfost 8mo ago
  Because most maintainers love it compared to Sys V scripts. In the end, users might complain about purity of things or something but the mainteners are the ones doing the work maintaining all that and end up deciding what gets used. Honestly, I'm rather outside of all that stuff and I had my share of problems with systemd issues but that's mostly because I've been using pretty old systems anyway with thus older and buggier versions of the code. And I also remember the pain it was before unit files to get those sys V scripts working correctly. From my perspective, both systems had weird bugs I had to track but systemd clearly wins on the "creating a new service" part.
- t43562 8mo ago
  Commercial interests. Linux has benefited greatly from companies adopting it and paying developers but at the same time there has been a price to pay and this kind of thing is it. Since it's all open source, I think we're reasonably ok because we don't HAVE to do what the commercial distros chose to do. The problem is if we let it become too difficult. Personally I think a thing like DBUS is needed but dbus itself is undesirable as it adds another IPC type and has no connection to the filesystem or the BSD socket interface or any of the other standard ways that interfaces can be discovered and used. It has a network effect that is not easy to avoid without accepting degradation in the UI. The more crap we end up accepting the more difficult it becomes to be a lone developer and the more the whole system will turn towards commercial interests and away from what it started out as.
egorfine 8mo ago
Why not discontinue original coreutils and original sudo while we're at it?
- guerrilla 8mo ago
  I think you're joking but they will. Eventually stystemd will consume everything and that work has already begun, quite literally.
  - egorfine 8mo ago
    They absolutely will. Even irony aside, there is no point in investing so much efforts in Rust slops without removal of the original tools.
melodyogonna 8mo ago
Has the entire industry converged on Systemd then
- guerrilla 8mo ago
  Almost. Not Alpine and a few others.
ruhith 8mo ago
[dead]
- guerrilla 8mo ago
  Exactly. Now, remember how everyone gaslit us into saying we'd always have a choice? We told you so.
sylware 8mo ago
I ended linux from scratch support a long time ago. Well I did the right thing. Everything is systemd free on my side, for my own sake. This systemd is so much a "microsoft grade bad idea". There is still interesting code patches here and there, and interesting info on brain damaged SDKs (gcc, glibc, etc). Most of the time I remove the SDK itself, basically I write a linear and brutal shell script with fine grained control on the compiler/linker. I do push down to nearly remove completely the compiler driver (a spectacular failure) namely CPP->C->ASM->O. I would like to move away from ELF too for a modern file format for dynamic libs and executable, but the "geniuses" using complex computer languages (mostly c++) for critical open source components make that a massive pain (runtime, ELF relocation requiring obsolete infrastructure, etc).
nineteen999 8mo ago
It's funny I did an LFS system of my own a couple of years ago which I coined "Head Rat" Linux. I used the SVR4 packaging system from heirloom-pkgtools (using this of a Claude port of V4 unix to x86_64 as well at the moment) for fun, and compiled up CDE on top of this to boot. I wanted to see what Linux would look like if you dressed it up as much like SVR4 as possible. I liked the result actually. It was kind of like what Sun might have done if they dumped their own kernel and switched to Linux instead. Originally it used SysVinit, and I started working getting systemd to work with it (because after several years I've come to appreciate it) - but that's the point I stopped working on Headrat - I realised if I wasn't adding SVR4 stuff and was removing it instead, it wouldn't be SVR4 enough. I don't know how I feel about it - after all I could do an LFS straight out of my head these days without referring to the LFS docs - but I do feel there is something lost when as a Linux community, we try to shove the baggage under the rug and pretend that things like SysV init didn't play a massive part in Linux's rise throughout the 90's and 00's. History is important, even if we don't like the code today and have more capable tools. But I guess SysV init is deader than dead at this point.
Someone100 8mo ago
The UNIX cancer that is systemd has spread to LFS and kiled SysVinit.Sad
nilamo 8mo ago
This seems good? LFS isn't about building Linux the way Linux was built 40 years ago. It's about learning how to do today's Linux, from scratch. Steps that lead to a radically different build from most Linux distros are therefore off the mark, and not really educational to show how a modern Linux is built. Lots of pearl clutching in here about it, tho
1vuio0pswjnm7 8mo ago
This mailing list archive page is incredibly user-hostile
mrlonglong 8mo ago
Openrc would have been a better choice.

225 points by cf100clunk 8mo ago

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.''

clintfred 8mo ago
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 8mo ago
  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
  - ripdog 8mo ago
    So, devuan?
    - its_magic 8mo ago
      No, not even close. Totally different projects. This one is for experts only, or those who want to become experts. The type of person who has been toying with the idea of building a LFS system but doesn't really want to go through all the work and headache (and it's a ton, to build a full system.) It also supports cross compiling to other architectures, which LFS does not. This system has many powerful features like built in ccache/distcc support for the build, support for building in QEMU, etc. Eventually it will be fully sandboxed. There is a heavy emphasis on Doing Things Right according to an old school way of thinking. Everything is kept as simple as possible, yet as full featured as is practical. A major goal is to have everything documented and explained, starting with the shell scripts which build the system step by step in an easy to follow manner. No package manager currently, though a simple one is in the works which is integrated into the build scripts. It's not really needed. You just build a complete system with all packages you want installed in a single run, with your own configuration pre-loaded. This gets compressed to a tarball. Then to install, create a partition, extract the tarball, edit a few files, install the bootloader, set passwords, and go.
  - M95D 8mo ago
    How did you get GTK3/4 to work without dbus?
    - its_magic 8mo ago
      I got rid of dbus in GTK3 by patching the code so that the "accessibility bridge" (to ATK) can be disabled. GTK4 is beneath contempt and will not be supported. The system uses GTK2 wherever possible, or GTK3 when not. I will either port everything to GTK2 later or create some kind of shim library. Help wanted here. Porting back to GTK2 isn't hard, I just don't have time to work on any of that at the moment.
      - M95D 8mo ago
        I'm running Gentoo without dbus and I'm stuck at gtk 3.24.34. I would love to see those patches. Your site appears to be down.
        its_magic 8mo ago
        It's just HTTP only (no SSL) and there's nothing there. ... until now! Here's some nice GTK3 patches for you: http://killthe.net/patches/gtk-3.24.43-allow-disabling-atk-bridge.patch http://killthe.net/patches/gtk-3.24.43-allow-disabling-atk-b... http://killthe.net/patches/gtk-3.24.43-allow-transparent-windows.patch http://killthe.net/patches/gtk-3.24.43-allow-transparent-win... http://killthe.net/patches/gtk-3.24.43-allow-wheel-scrolling-in-notebook.patch http://killthe.net/patches/gtk-3.24.43-allow-wheel-scrolling... http://killthe.net/patches/gtk-3.24.43-appearance-tweaks-and-fixes.patch http://killthe.net/patches/gtk-3.24.43-appearance-tweaks-and... http://killthe.net/patches/gtk-3.24.43-disable-mnemonics-delay.patch http://killthe.net/patches/gtk-3.24.43-disable-mnemonics-del... http://killthe.net/patches/gtk-3.24.43-file-chooser-tweaks.patch http://killthe.net/patches/gtk-3.24.43-file-chooser-tweaks.p... http://killthe.net/patches/gtk-3.24.43-remove-dead-key-underline.patch http://killthe.net/patches/gtk-3.24.43-remove-dead-key-under... http://killthe.net/patches/gtk-3.24.43-restore-old-context-menu.patch http://killthe.net/patches/gtk-3.24.43-restore-old-context-m... http://killthe.net/patches/gtk-3.24.43-set-default-settings.patch http://killthe.net/patches/gtk-3.24.43-set-default-settings.... http://killthe.net/patches/gtk-3.24.43-show-alternating-row-colors.patch http://killthe.net/patches/gtk-3.24.43-show-alternating-row-... Note that GTK 3.24.43 is the last version of GTK3. My system is full of patches like this to tweak, improve, and adjust things. The point is to get off the "upgrade" treadmill and focus on making things work right.
  - happymellon 8mo ago
    > I will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software. What makes you decide that these are troublesome software's? Systemd is usually argued that it is monolithic and breaks the Unix paradigm. But then you are going for X over Wayland? X is a monolithic application that breaks the Unix paradigms. Are you just picking things because they are old, or is there a reason you decided to go with this setup?
    - its_magic 8mo ago
      The difference is that the people who designed X11 were honest in their intentions. The authors of systemd, wayland, etc are not. I'll just leave it at that. (I recommend staying far away from "X11libre" also, for the same reason, with no further comment.) Monolithic stuff is OK too, where it makes sense. The kernel is monolithic. ZFS is monolithic. (Yes, this system has ZFS support. The module is built in to the kernel. In time it will support booting from ZFS also, when I finish the initrd code.) There is a clear, solid reason for everything this system is or does. I'm not a contrarian or a purist, just someone with opinions gained from long experience who is not happy with the direction mainstream Linux is headed. My system is a zen garden of bliss compared to buggy garbage like Ubuntu. Really, it's like someone added a turbo button. Ubuntu and friends are so bloated, laggy, and slow. I regularly use this system on 15-20+ year old hardware. The default window manager is Enlightenment e16. It's snappy and responsive everywhere. KDE, Xfce, etc are supported also and are noticeably peppier than on mainstream distros, just due to the lack of bloat, gazillions of daemons running in the background, etc. Out of the box, nothing runs by default. You enable only what you want. Another inviolable principle is that no application is allowed to originate or receive network traffic unless the user specifically requests it. There is ZERO network activity going on in the background. None of this steady stream of who knows what contacting who knows where that goes on with other systems. No auto update etc. No internet required or used during the system build. Python module installs do not consult the central repository or download anything. Meson or cmake does not download anything. Etc. All that's patched out and disabled. It's a distro that is meant to be forked. It's very easily done. It's a blank slate, a vanilla Linux system with subtle and tasteful improvements that is the ideal starting point to customize to your exact specifications. If you want to add in systemd and wayland, fine, I don't care, it's your system and you can build it according to your desires. People can use this platform to build their own custom OS and save themselves a ton of work vs. starting completely from scratch. It's a system that can be audited. Everything is built with shell scripts, starting with source archives and patches that are applied during the build process. It's all inspectable and the process can be understood step by step. It's a way to hit the ground running with a full featured, working system, while learning in the process. This distro will teach you what LFS would teach you, but with less of a "sheer cliff face" learning curve, letting you focus more on higher aspects of building the system while still learning the low level details in time. The build is actually overall simpler than LFS despite being way more featured, with things like Ada support. (Yes, it has GNAT.) I just found a way to do it better, and kept iterating countless times to simplify and improve to the max. Existing systems did not satisfy my requirements or standards of quality, so I just had to create a new one.
- adastra22 8mo ago
  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 8mo ago
    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 8mo ago
      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 8mo ago
        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.
        spijdar 8mo ago
        That's what I was trying to get at -- yes, you can say that sysvinit is easier to understand than systemd, and less of a black box. But, even still, a "real Linux distribution" is full of these black boxes, especially the closer you get to being able to run "real applications". I'd argue that once you get into full desktop seat management, you add so much complexity on top of sysvinit that the difference narrows... Which is why I asked "learn about what stuff". I think if the goal is to learn about "Unix" or OS design/ideas, you're better off with a leaner, "pedagogical" OS, like xv6. If the goal is to piece together an OS and really understand each piece, I don't think you really want sysvinit. You want something closer to an /etc/rc.local that just kicks off a few daemons and hopes for the best. You can argue that sysvinit makes a better "compromise" between usability and clarity, and I'd entertain that idea, but then I think dinit is far easier to understand than sysvinit. And of course, at that point you can shave yaks till you fill the bike shed with wool. Realistically, as much as people may hate it, if you have to pick a single init to standardize on for clarity and "building an entire Linux distro from the ground up, understanding how every piece fits together", systemd is the most rational choice. It's the most representative of the ecosystem, and requires the least "extra layers" to make the "desktop layer" work.
soldoutcold 8mo ago
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 8mo ago
  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.
  - themafia 8mo ago
    > 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.
  - cf100clunk 8mo ago
    OP here. I was hoping we could avoid the interminable, infernal discussion of systemd vis-a-vis emotional states.
  - mirashii 8mo ago
    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 8mo ago
      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!
raggi 8mo ago
https://github.com/systemd/systemd/tree/main/src/core https://github.com/systemd/systemd/tree/main/src/core doesn't look like 1678 C files to me.
- cf100clunk 8mo ago
  In what way was Bruce incorrect, your one link excepted?
  - raggi 8mo ago
    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 8mo ago
      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 8mo ago
        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.
        simoncion 8mo ago
        > ... dbus [is] pretty critical for anything linux regardless Weird. If I weren't a sicko and had OBS Studio installed on my multipurpose box [0] I'd not have dbus installed on it. dbus is generally optional; not that many packages require it. [1] [0] Two of its several purposes are video transcoding and file serving. [1] This is another area where Gentoo Linux is (sadly) one of the absolute best Linux distros out there.
nine_k 8mo ago
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 8mo ago
  I use runit on my production workstation and don't think about it; it just works.
  - BadBadJellyBean 8mo ago
    Same with systemd.
    - its_magic 8mo ago
      Except for all those who've accidentally blown their legs off with it, of course. Just ask the guy who bricked his motherboard due to a systemd bug where his firmware wasn't write protected and got destroyed by a 'rm -rf' command. lol
      - BadBadJellyBean 8mo ago
        No software is perfect. Not sysvinit (and it's bash scripts from different vendors), nor systemd. Errors happen. At least for me systemd is a net positive.
        its_magic 8mo ago
        > No software is perfect Especially when it's a giant blob of buggy C code written by a known hack who has multiple decades' worth of history of foisting shit code upon a less than enthused public. > At least for me systemd is a net positive For the moment. Just wait until it finds a way to fuck you. It's plotting and scheming behind your back to do so as we speak. Systemd for some reason seems to uniquely be the epicenter of giant facepalm bugs like LEAVING THE SYSTEM FIRMWARE VULNERABLE TO AN RM -RF COMMAND, a situation which causes alarm to none of the systemd crowd. They just shrug if off. "What's the big deal? I don't get it," they say. I used to see the same mentality from Microsoft people back in the day. "Why would you use Linux? I don't get it. Windows is fine." It's because you lack standards. You're completely used to being surrounded by software and hardware that is Fucking Garbage. Everything is like that in your world. You're happier than a pig in shit, oblivious.
charcircuit 8mo ago
Linux is literally 62k C files. The amount of time you'll spend understanding how Linux works will dwarf systemd. At least when studying systemd you will be learning a more modern approach of init systems.
- varjag 8mo ago
  Most of those files are device/fs/network drivers and various arch support. The core you need to comprehend is not that much larger than systemd.
  - its_magic 8mo ago
    Or to put it another way, systemd has grown to become so large and complex it's like a kernel unto itself.
- deleted 8mo ago
  [deleted]
jeroenhd 8mo ago
I don't mind the inevitable death of System V. It's an archaic relic of the Linux era. Going systemd-only is not necessarily a good choice (though I do understand it from a practical point of view). There are other, better alternatives for System V that are smaller and more modular so you still get the Unix "feel" without the absurd complexity of interlinked shell scripts that System V relies on. I'd like to see OpenRC getting adopted in System V's place. Upstart seems to be dead (outside of ChromeOS) but it would also have sufficed. Alas, I'm not someone with the time or knowledge to maintain these tools for LFS, and unless someone else steps up to do all the hard work, we'll probably see LFS go systemd-only. That said, there's no reason to go full-fat systemd, of course.
- cbolton 8mo ago
  I think systemd is the one to learn now if you want to learn Linux. Maybe someone can make a Unix from Scratch for people more interested in the Unix philosophy than Linux per se.
  - jeroenhd 8mo ago
    systemd is most certainly the most pragmatic service to learn, but if you're doing LFS to "learn" how a Linux system gets brought up, something lower-level may be a better idea to pick up.
    - prmoustache 8mo ago
      All this stuff is versioned anyway so if the point is learning youe can still read an old version of the book and use old versions of the repos.
  - cbmuser 8mo ago
    SysVInit on Linux isn’t true Unix though as the way it abuses runlevels to start daemons was never intended by the original designers of init.
    - roryirvine 8mo ago
DyslexicAtheist 8mo ago
> To me LFS is about learning how a system works. I'd just like to interject for a moment. What you're referring to as Linux, is in fact, Linux plus systemd, or as I've recently taken to calling it, Linux/systemd. Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd corelibs, systemd daemons, and vital systemd components comprising a full OS as defined by Poettering. -- https://mastodon.social/@fribbledom/116002799114521341 https://mastodon.social/@fribbledom/116002799114521341
- bjourne 8mo ago
  This, of course, is a tongue in cheek.
- its_magic 8mo ago
  8/10
cbmuser 8mo ago
SysVInit is abusing runlevel scripts for starting daemons which has always been a hack to be able to resolve dependencies between daemons. Learning Linux or Unix from scratch shouldn’t include using crude hacks.
- its_magic 8mo ago
  I'm with you on this. SysVinit is better than systemd, but far from perfect. I don't enjoy tediously maintaining all of those symlinks, and prefer the BSD approach myself. One project on my distro is a new init that will be much, much simpler than SysV, more like BSD and without all the years of cruft.

1vuio0pswjnm7 8mo ago

What does "support" mean

cf100clunk 8mo ago
On 01 March 2026 the next versions of LFS and BLFS will not include SysVinit instructions a.k.a. ''support''.
zxcvasd 8mo ago
[dead]

smartmic 8mo ago

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 8mo ago
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.
- raverbashing 8mo ago
  "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
- acdha 8mo ago
  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.
PunchyHamster 8mo ago
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 8mo ago
  I don't see how this relates to removing SysVinit support from LFS. Choice is good.

jmclnx 8mo ago

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

Someone100 8mo ago
I use Sway window manager and am more than happy to avoid those huge bloated Guiwares
cf100clunk 8mo ago
I would think people who use LFS are doing it for the learning experience and not necessarily for a daily driver OS.
spudlyo 8mo ago
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.

abhisek 8mo ago

LFS. Brings back so many painful memories. But then, learned so much.

spudlyo 8mo ago

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 8mo ago
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 8mo ago
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 8mo ago
  > "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 8mo ago

eikenberry 8mo ago

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 8mo ago
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 8mo ago
  Yes, it's like asking students to actually produce something themselves. What a horrific thought.
  - cf100clunk 8mo ago
    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.
- nine_k 8mo ago
  Certain things should only be taught as a warning. SysV init is one of them.
  - cf100clunk 8mo ago
    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.

JCattheATM 8mo ago

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

um1 8mo ago
LFS seems to be for people who are interested in how things work. The systemd proponents come off as people who would question why you would want to to drive a manual transmission and say of course you should choose an automatic or better yet, a robot; self driving car. It would be interesting to see how those opinions line up with the uses of AI
- ryukoposting 8mo ago
  I have owned many manual cars, but I'm fine with systemd on all my machines. Being a nerd about one thing doesn't require me to be a nerd about other things.
tuetuopay 8mo ago
Pedantic but systemd is inspired by MacOS launchd, not by Windows services. It has nothing akin to the registry, which even microsoft admits is a pain on windows. Oh, and usually people shit on windows for many reasons, but some of the very core features of the OS are robust and the Linux crowd could take a hint. Like, you know, the notion of service at the OS-level and not some random bash script that nohup'd a binary. Oh wait, that's what does Windows, MacOS and Linux with systemd.
- JCattheATM 8mo ago
  I didn't say it was inspired by the registry, I just drew a comparison. In both cases you have a huge binary thing that you have to interact with through secondhand tools rather than directly.

haunter 8mo ago

So this will be the final SysVinit version https://www.linuxfromscratch.org/lfs/downloads/12.4/ https://www.linuxfromscratch.org/lfs/downloads/12.4/

antonyh 8mo ago

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/ 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.

cmrdporcupine 8mo ago
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
- antonyh 8mo ago
  I've heard of Hurd, but never felt tempted to try it. That could be an interesting option.
  - raggi 8mo ago
    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.
- cf100clunk 8mo ago
  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.

WhereIsTheTruth 8mo ago

Just rename Linux to SystemD OS at this point..

mhurron 8mo ago
Excuse me, that's GNU/SystemD/Linux.
- SAI_Peregrinus 8mo ago
  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.
  - LeFantome 8mo ago
    Just call it the Red Hat Linux Platform. Both GNU (glibc, binutils, GNU utils, GCC, etc) and Systemd are primarily maintainted by them. Same with Wayland and GNOME. Red Hat defines what "Linux" is these days.
jvreeland 8mo ago
systemd not SystemD
- deleted 8mo ago
  [deleted]
- tosti 8mo ago
  systemdick

SockThief 8mo ago

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.

byte_0 8mo ago

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 8mo ago
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).
- bandrami 8mo ago
  Is this really that hard to type? https://github.com/openbsd/src/blob/master/etc/rc.d/watchdogd https://github.com/openbsd/src/blob/master/etc/rc.d/watchdog...
  - abenga 8mo ago
    Probably not, but it looks a hell of a lot harder to understand than a unit file.
    - bandrami 8mo ago
      Huh? Not even remotely
      - deleted 8mo ago
        [deleted]

mid-kid 8mo ago

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/msg00001.html 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.

wormius 8mo ago

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

ErroneousBosh 8mo ago

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

0xbadcafebee 8mo ago

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

greatgib 8mo ago

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.

LeFantome 8mo ago
The whole GNU / Red Hat platform is this way. Try switching out Glibc. You get the same "you have to use all our stuff" dependencies.
- tosti 8mo ago
  Musl mostly works. I had more trouble taking out bash, because of all the random bashisms.
  - its_magic 8mo ago
    On my system I forked dash to create 'bolderdash.' Right now it's pretty basic, I have changed little (just did some cleanup), but I did add in a couple tweaks to enhance bash compatibility. The goal is a complete refactor, more compatibility with bash, and much better command line editing etc, while still remaining sleek and lightweight. I'm also forking musl to create 'powrlibc.' It will have a lot better glibc compatibility, as well as better optimizations and some other improvements.
- guerrilla 8mo ago
  Switching out glibc is pretty easy compared to systemd. That's the thing peoplle don't get. systemd is seriously insidius, like a virus.
  - matteotom 8mo ago
    I've personally run Gentoo with OpenRC+glibc and OpenRC+musl on my laptop. I assure you ditching systemd was easier than ditching glibc. The OpenRC system mostly just works (tbh thanks to a lot of great work by Gentoo devs). The musl system required probably a couple dozen patches to various packages to get a basic fully working desktop (most of which were relatively straightforward, but still needed manual intervention).

tmtvl 8mo ago

Kind of related: The Great Debian Init Debate <https://aaonline.fr/search.php?search&criteria[sequenceId-is]=6512_en_Debian%20init%20case https://aaonline.fr/search.php?search&criteria[sequenceId-is...>

listentomineral 8mo ago
This is the absolute perfect format to read these threads. Thanks for sharing.

cjk 8mo ago

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.

sxzygz 8mo ago

Sadly is Linux is no longer what is used to be for my generation that cut their teeth having to patch kernels for basic hardware support. Linux is now effectively systemd/linux, and is attempting to become flatpak/systemd/linux through various corporate sponsored initiatives. The only thing worse, in my eyes, are people who distribute things as docker containers. The Linux distro as such is becoming an anachronism. There’s no real place to innovate without the inertia of choices made by external projects being enforced on you. I think it’s a generational change. My generation had Microsoft to contend with, and so sought certain freedoms, but this generation has walled gardens and AI to contend with, so freedom à la Microsoft seems okay and so Linux is being Windows-ified, while Windows itself becomes its own abomination.

pjmlp 8mo ago
I would have not bothered with Linux if Windows NT had a proper UNIX subsystem. I needed a way to avoid going to campus and fight for a DG/UX terminal. It had nothing to do with FOSS fighting.
- jeroenhd 8mo ago
  > if Windows NT had a proper UNIX subsystem They actually did, but they made the mistake of packaging only the bare basics with it, and hiding it away as much as they could: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX https://en.wikipedia.org/wiki/Windows_Services_for_UNIX The American government added some obscure law that forced POSIX compatibility on operating systems for certain grants, so Microsoft made their business OS POSIX-compliant. In theory, nothing stopped you from downloading and installing up-to-date versions of common UNIX tools. Had Microsoft had the necessary foresight, they could've killed deverlopers' dependency on tools like Cygwin and Git Bash and Linux entirely for many pieces of software, but they were too busy trying to make Win32 the standard ABI. Funnily enough, Win32 became the standard for proprietary software on Linux (thanks to Wine+Proton) while many Unix/Linux-based tools became the norm for development, even on Windows (git, Qt). How different things could've been!
  - pjmlp 8mo ago

jupake 8mo ago

Modern mechanical engineers, to this day, learn the thermodynamics of steam engines. Not because they are living in the past, but because they are building foundation knowledge that will permeate everything they'll be doing in the future. LFS should stick to academic pedagogy, instead of trying to compete in the Linux Distro space.

idoubtit 8mo ago
The world is vast, and I doubt that every mechanical engineer has studied steam engines, and that it makes a difference in the end. Most modern programmers don't learn COBOL60 or Commodore BASIC. Modern mathematician very rarely study writings of Euler or Gauss; even 50 years old math books may be hard to grasp for modern students. I agree that using a simpler tool for educational purpose is useful, but since SysVinit is obsoleted almost everywhere, it made sense to drop it. LFS could have chosen a simpler init than the domain standard, like runit or s6-init.
- its_magic 8mo ago
  "Obsolete"? Apparently you aren't paying close attention. See this GIANT argument with hundreds of comments? It seems some people believe that SysVinit is, in fact, not even close to obsolete. If Gnome/KDE can't support the init system I choose to use, then I don't choose to use their garbage software anymore.

nice_byte 8mo ago

I had stopped using linux at the start of the systemd takeover (it was not because of systemd). What I don't understand is how this has happened. I didn't care either way but everybody who did seemed to really fucking hate systemd. Then how come it became the default in so many distributions, with so much opposition from the community?

nacozarina 8mo ago
M$ is pushing hard and not pushing alone
mfost 8mo ago
Because most maintainers love it compared to Sys V scripts. In the end, users might complain about purity of things or something but the mainteners are the ones doing the work maintaining all that and end up deciding what gets used. Honestly, I'm rather outside of all that stuff and I had my share of problems with systemd issues but that's mostly because I've been using pretty old systems anyway with thus older and buggier versions of the code. And I also remember the pain it was before unit files to get those sys V scripts working correctly. From my perspective, both systems had weird bugs I had to track but systemd clearly wins on the "creating a new service" part.
t43562 8mo ago
Commercial interests. Linux has benefited greatly from companies adopting it and paying developers but at the same time there has been a price to pay and this kind of thing is it. Since it's all open source, I think we're reasonably ok because we don't HAVE to do what the commercial distros chose to do. The problem is if we let it become too difficult. Personally I think a thing like DBUS is needed but dbus itself is undesirable as it adds another IPC type and has no connection to the filesystem or the BSD socket interface or any of the other standard ways that interfaces can be discovered and used. It has a network effect that is not easy to avoid without accepting degradation in the UI. The more crap we end up accepting the more difficult it becomes to be a lone developer and the more the whole system will turn towards commercial interests and away from what it started out as.

egorfine 8mo ago

Why not discontinue original coreutils and original sudo while we're at it?

guerrilla 8mo ago
I think you're joking but they will. Eventually stystemd will consume everything and that work has already begun, quite literally.
- egorfine 8mo ago
  They absolutely will. Even irony aside, there is no point in investing so much efforts in Rust slops without removal of the original tools.

melodyogonna 8mo ago

Has the entire industry converged on Systemd then

guerrilla 8mo ago
Almost. Not Alpine and a few others.

ruhith 8mo ago

[dead]

guerrilla 8mo ago
Exactly. Now, remember how everyone gaslit us into saying we'd always have a choice? We told you so.

sylware 8mo ago

I ended linux from scratch support a long time ago. Well I did the right thing. Everything is systemd free on my side, for my own sake. This systemd is so much a "microsoft grade bad idea". There is still interesting code patches here and there, and interesting info on brain damaged SDKs (gcc, glibc, etc). Most of the time I remove the SDK itself, basically I write a linear and brutal shell script with fine grained control on the compiler/linker. I do push down to nearly remove completely the compiler driver (a spectacular failure) namely CPP->C->ASM->O. I would like to move away from ELF too for a modern file format for dynamic libs and executable, but the "geniuses" using complex computer languages (mostly c++) for critical open source components make that a massive pain (runtime, ELF relocation requiring obsolete infrastructure, etc).

nineteen999 8mo ago

It's funny I did an LFS system of my own a couple of years ago which I coined "Head Rat" Linux. I used the SVR4 packaging system from heirloom-pkgtools (using this of a Claude port of V4 unix to x86_64 as well at the moment) for fun, and compiled up CDE on top of this to boot. I wanted to see what Linux would look like if you dressed it up as much like SVR4 as possible. I liked the result actually. It was kind of like what Sun might have done if they dumped their own kernel and switched to Linux instead. Originally it used SysVinit, and I started working getting systemd to work with it (because after several years I've come to appreciate it) - but that's the point I stopped working on Headrat - I realised if I wasn't adding SVR4 stuff and was removing it instead, it wouldn't be SVR4 enough. I don't know how I feel about it - after all I could do an LFS straight out of my head these days without referring to the LFS docs - but I do feel there is something lost when as a Linux community, we try to shove the baggage under the rug and pretend that things like SysV init didn't play a massive part in Linux's rise throughout the 90's and 00's. History is important, even if we don't like the code today and have more capable tools. But I guess SysV init is deader than dead at this point.

Someone100 8mo ago

The UNIX cancer that is systemd has spread to LFS and kiled SysVinit.Sad

nilamo 8mo ago

This seems good? LFS isn't about building Linux the way Linux was built 40 years ago. It's about learning how to do today's Linux, from scratch. Steps that lead to a radically different build from most Linux distros are therefore off the mark, and not really educational to show how a modern Linux is built. Lots of pearl clutching in here about it, tho

1vuio0pswjnm7 8mo ago

This mailing list archive page is incredibly user-hostile

mrlonglong 8mo ago

Openrc would have been a better choice.