7 ms·

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 le

by 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.
- frumplestlatz 8mo ago
  I would somewhat doubt it; the negative aspects of Mach’s design are a technical albatross around the neck of any kernel. Apple has had to invest reams of engineering effort in mitigating Mach’s performance and security issues in XNU; systemd dissatisfaction alone seems unlikely to shift the needle towards Hurd.
- tokyobreakfast 8mo ago
  Did they finally add USB support?
tokyobreakfast 8mo ago
I wonder if the impetus behind the (terrible) monolithic design of systemd was to force standardization across distros. The choice was more political than technical. If different choices were available for init, DNS resolver, service control manager, volume manager, etc... we would adversely contribute to the schizo distro landscape the people holding the money bags are actively trying to get away from. With systemd it's an all-or-nothing deal. You get the good with the bad, but all distros shit the bed in the same, deterministic way. Not even Windows does this. There is no "systemd" equivalent. Yes, Windows ships as a single OS—as do the BSDs—but all the components were developed separately. If all they wanted was a service control manager, there were many (better) options already in existence they could have used.
- bryanlarsen 8mo ago
  systemd is not a monolith, and distros make different choices on what portions of systemd they which to ship and enable by default. For example, not all distros ship and use systemd-resolved by default, to choose from your list.
  - bsimpson 8mo ago
    systemd-boot competes with grub
    - 5G_activated 8mo ago
      and grub is a rotting pile while systemd-boot is a simple boot entry multiplexer that rides off the kernel's capability of being run as an EFI executable, it just happens to live in systemd's tree. not a good example
      - fragmede 8mo ago
        It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?
hparadiz 8mo ago
OpenRC on Gentoo works great. I have a full bleeding edge Wayland KDE Plasma with Pipewire setup that I game on. OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things. There are growing pains. https://bugs.gentoo.org/936123 https://bugs.gentoo.org/936123 Especially when upstream hard requires systemd. More annoying when there's no real reason for it. But there is a way forward and I highly recommend people try to build software to work without systemd before assuming it's always there.
- simoncion 8mo ago
  To pile on, a minimal OpenRC service file is just as complicated as a minimal SystemD service file; that is, they're both almost-exclusively composed of key-value pairs. For instance, this is the service file for the 'rsyncd' service [0]: #!/sbin/openrc-run command="/usr/bin/rsync" command_args="--daemon ${RSYNC_OPTS}" pidfile="/var/run/${SVCNAME}.pid" depend() { use net } Like SystemD, OpenRC provides pre/post start/stop hooks that you can use to call out to other programs. Unlike SystemD if you need to make nontrivial decisions at service-status-management time, you have the option of putting your scripts or calls to other programs inline, rather than hoping that SystemD gives you the hooks you need in the places you need them and passes in the data you require. [1] [0] And if 'rsyncd' was supervised with 'supervise-daemon', you wouldn't need to specify the location of the pidfile. [1] As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does). As a less-trivial example, you can check for and warn the administrator about common service misconfigurations with the same mechanism that provides service startup and status information (as several services do).
  - xerxes901 8mo ago
    > As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does) Depending on what you want to do, a generator might be appropriate: > Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins
its_ubuntu2 8mo ago
[flagged]
- cf100clunk 8mo ago
  I see this was your first HN contribution and you didn't post any links, so maybe that's what they were thinking?
  - its_ubuntu2 8mo ago
    Links? To what? "First contribution"? I'm not new around here. (If anyone is wondering what he's referring to--I said that I was mystified why my post would be immediately downvoted.) Let's try again, much shorter this time: I am releasing a distro soon that is right up your alley. SEE MY PROFILE for info.
    - Sophira 8mo ago
      There is nothing visible on your profile[0] other than a derogatory comment about HN in your bio. If you're seeing something there, then I would advise you to look at it again when you're logged out so that you can see what others are seeing. [0] https://news.ycombinator.com/user?id=its_ubuntu2 https://news.ycombinator.com/user?id=its_ubuntu2
Fwirt 8mo ago
Try Alpine? It's not designed to be a "desktop" OS but it functions well as one. I find it easy enough to wrap my head around the whole thing, and it uses OpenRC by default.
josteink 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 Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers. Popular desktop environments are increasingly depending on Linux-only things. KDE has officially removed support for FreeBSD in Plasma login manager (because of logind dependency). Gnome 50 plans to obsolete X11 completely. If you want that simple, bright future of yours, you’ll have to fight/work for it.
- Timon3 8mo ago
  > Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers. Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else? [0]: see discussion & linked issues in the announcement https://news.ycombinator.com/item?id=44199502 https://news.ycombinator.com/item?id=44199502
  - josteink 8mo ago
    I’m talking about that developer, yes. And I’m sure there’s more to the story than just ABI compatibility. He wanted X11 to thrive. Freedesktop however has a goal for Wayland ultimately to replace X11, right? X11 should die. This is not hyperbole. It’s a stated goal. So I think there’s more to the story than the simplified ABI aspect often mentioned here on HN. Also Gnome killing X11 support is real. So is KDE backing down on BSD-support. These are facts, not opinions.
    - LeFantome 8mo ago
      > I’m sure there’s more to the story than just ABI compatibility The number one goal for the Xwayland / Xorg devs is stability. Breaking ABI compatibility is a pretty big problem if stability is your goal.
    - Timon3 8mo ago
      We don't have to guess, the PRs & history are still there. You could easily go through them and find examples of the project members being unreasonable about ABI compatibility. But of course that would destroy the narrative.
razighter777 8mo ago
What practical problems do you run into with systemd? All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic". But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems. People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap. Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts. Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.
- cyberax 8mo ago
  Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound. But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup. To give you concrete examples: 1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts. 2. Except that you can, but only if you use the /etc/fstab compat. 3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device. 4. Systemd has separate behaviors for network and local filesystems. 5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!! 6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5adfe29cd9e0d27e67c55c/src/basic/mountpoint-util.c#L235 https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching. 7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1. I can go on for a looooong time.
creatonez 8mo ago
> isn't LfS all about the basics of the distro than building a fully fledged system? Not at all, and I'm not sure why so many people have this perception. It's never been this way. LFS is the tutorial you follow to get a full GNU/Linux system. In LFS, not having a base that can theoretically support the latest desktop environments is considered a fatal bug. It's just a conventional distro but in document format. This is good for its comprehensiveness and as a way of documenting what existing Linux distros are doing, but it limits its utility as a learning aid as well as for embedded development. Most people interested in barebones Linux should instead start with a kernel and busybox and ignore most GNU packages.

by antonyh 8mo ago

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.
frumplestlatz 8mo ago
I would somewhat doubt it; the negative aspects of Mach’s design are a technical albatross around the neck of any kernel. Apple has had to invest reams of engineering effort in mitigating Mach’s performance and security issues in XNU; systemd dissatisfaction alone seems unlikely to shift the needle towards Hurd.
tokyobreakfast 8mo ago
Did they finally add USB support?

tokyobreakfast 8mo ago

I wonder if the impetus behind the (terrible) monolithic design of systemd was to force standardization across distros. The choice was more political than technical. If different choices were available for init, DNS resolver, service control manager, volume manager, etc... we would adversely contribute to the schizo distro landscape the people holding the money bags are actively trying to get away from. With systemd it's an all-or-nothing deal. You get the good with the bad, but all distros shit the bed in the same, deterministic way. Not even Windows does this. There is no "systemd" equivalent. Yes, Windows ships as a single OS—as do the BSDs—but all the components were developed separately. If all they wanted was a service control manager, there were many (better) options already in existence they could have used.

bryanlarsen 8mo ago
systemd is not a monolith, and distros make different choices on what portions of systemd they which to ship and enable by default. For example, not all distros ship and use systemd-resolved by default, to choose from your list.
- bsimpson 8mo ago
  systemd-boot competes with grub
  - 5G_activated 8mo ago
    and grub is a rotting pile while systemd-boot is a simple boot entry multiplexer that rides off the kernel's capability of being run as an EFI executable, it just happens to live in systemd's tree. not a good example
    - fragmede 8mo ago
      It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?

hparadiz 8mo ago

OpenRC on Gentoo works great. I have a full bleeding edge Wayland KDE Plasma with Pipewire setup that I game on. OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things. There are growing pains. https://bugs.gentoo.org/936123 https://bugs.gentoo.org/936123 Especially when upstream hard requires systemd. More annoying when there's no real reason for it. But there is a way forward and I highly recommend people try to build software to work without systemd before assuming it's always there.

simoncion 8mo ago
To pile on, a minimal OpenRC service file is just as complicated as a minimal SystemD service file; that is, they're both almost-exclusively composed of key-value pairs. For instance, this is the service file for the 'rsyncd' service [0]: #!/sbin/openrc-run command="/usr/bin/rsync" command_args="--daemon ${RSYNC_OPTS}" pidfile="/var/run/${SVCNAME}.pid" depend() { use net } Like SystemD, OpenRC provides pre/post start/stop hooks that you can use to call out to other programs. Unlike SystemD if you need to make nontrivial decisions at service-status-management time, you have the option of putting your scripts or calls to other programs inline, rather than hoping that SystemD gives you the hooks you need in the places you need them and passes in the data you require. [1] [0] And if 'rsyncd' was supervised with 'supervise-daemon', you wouldn't need to specify the location of the pidfile. [1] As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does). As a less-trivial example, you can check for and warn the administrator about common service misconfigurations with the same mechanism that provides service startup and status information (as several services do).
- xerxes901 8mo ago
  > As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does) Depending on what you want to do, a generator might be appropriate: > Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins

its_ubuntu2 8mo ago

[flagged]

cf100clunk 8mo ago
I see this was your first HN contribution and you didn't post any links, so maybe that's what they were thinking?
- its_ubuntu2 8mo ago
  Links? To what? "First contribution"? I'm not new around here. (If anyone is wondering what he's referring to--I said that I was mystified why my post would be immediately downvoted.) Let's try again, much shorter this time: I am releasing a distro soon that is right up your alley. SEE MY PROFILE for info.
  - Sophira 8mo ago
    There is nothing visible on your profile[0] other than a derogatory comment about HN in your bio. If you're seeing something there, then I would advise you to look at it again when you're logged out so that you can see what others are seeing. [0] https://news.ycombinator.com/user?id=its_ubuntu2 https://news.ycombinator.com/user?id=its_ubuntu2

Fwirt 8mo ago

Try Alpine? It's not designed to be a "desktop" OS but it functions well as one. I find it easy enough to wrap my head around the whole thing, and it uses OpenRC by default.

josteink 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 Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers. Popular desktop environments are increasingly depending on Linux-only things. KDE has officially removed support for FreeBSD in Plasma login manager (because of logind dependency). Gnome 50 plans to obsolete X11 completely. If you want that simple, bright future of yours, you’ll have to fight/work for it.

Timon3 8mo ago
> Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers. Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else? [0]: see discussion & linked issues in the announcement https://news.ycombinator.com/item?id=44199502 https://news.ycombinator.com/item?id=44199502
- josteink 8mo ago
  I’m talking about that developer, yes. And I’m sure there’s more to the story than just ABI compatibility. He wanted X11 to thrive. Freedesktop however has a goal for Wayland ultimately to replace X11, right? X11 should die. This is not hyperbole. It’s a stated goal. So I think there’s more to the story than the simplified ABI aspect often mentioned here on HN. Also Gnome killing X11 support is real. So is KDE backing down on BSD-support. These are facts, not opinions.
  - LeFantome 8mo ago
    > I’m sure there’s more to the story than just ABI compatibility The number one goal for the Xwayland / Xorg devs is stability. Breaking ABI compatibility is a pretty big problem if stability is your goal.
  - Timon3 8mo ago
    We don't have to guess, the PRs & history are still there. You could easily go through them and find examples of the project members being unreasonable about ABI compatibility. But of course that would destroy the narrative.

razighter777 8mo ago

What practical problems do you run into with systemd? All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic". But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems. People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap. Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts. Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.

cyberax 8mo ago
Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound. But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup. To give you concrete examples: 1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts. 2. Except that you can, but only if you use the /etc/fstab compat. 3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device. 4. Systemd has separate behaviors for network and local filesystems. 5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!! 6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5adfe29cd9e0d27e67c55c/src/basic/mountpoint-util.c#L235 https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching. 7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1. I can go on for a looooong time.

creatonez 8mo ago

> isn't LfS all about the basics of the distro than building a fully fledged system? Not at all, and I'm not sure why so many people have this perception. It's never been this way. LFS is the tutorial you follow to get a full GNU/Linux system. In LFS, not having a base that can theoretically support the latest desktop environments is considered a fatal bug. It's just a conventional distro but in document format. This is good for its comprehensiveness and as a way of documenting what existing Linux distros are doing, but it limits its utility as a learning aid as well as for embedded development. Most people interested in barebones Linux should instead start with a kernel and busybox and ignore most GNU packages.