4 ms·

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

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.

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.