9 ms·

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 th

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.

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.