5 ms·

> the monoculture created by systemd systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, bu

> the monoculture created by systemd systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, but I will happily post it again: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/ https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Such a thing doesn't happen if the thing offered isn't an improvement over what was before. As a matter of fact, this doesn't even happen if the thing offered is only a small improvement. We have seen this time and time again in Programmig languages: Exciting, clever new things that offer real advantages vanishing into obscurity because while they were better, they were not better by a large enough margin. Diversity is great if it offers advantages. Different kinds of RDBMS are a good example. Different kinds of shells. Rust being there as a C alternative, Go being there as a Java alternative, Julia as a possible Python alternative, WASM instead of JS. All great. But keeping something mainstream just because its different, adds no value. People can and do still use other init systems, but I am very glad I no longer have to wrestle 400-line sh init scripts on my production servers.

Nasreddin_Hodja 5y ago
> systemd became the de-facto default init sys because Distro Maintainers have chosen it. Because they were forced to choose it due to vendorlock and many other projects became dependent on systemd. Unsystemding everything would be very expensive. Same problem will be with snap and flatpak.
- awrmc 5y ago
  There aren't actually any projects dependent on systemd in any significant capacity. I don't know where that myth comes from but it's not true. Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.
  - Nasreddin_Hodja 5y ago
    I heard that Gnome is dependent on systemd now. > Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager. Those are even worse than tarball bundles. Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Centralized delivery is outmoded, future is decentralized distributed distribution. Both package managers deprive me of control over my system. I don't like the aggressiveness with which these projects are enforced. When Let's Encrypt switched to Spat as the only official distribution of their tool, I had to switch to alternative tool acme.sh instead of installing bloated snapd on my server.
    - awrmc 5y ago
      >I heard that Gnome is dependent on systemd now. Under some circumstances (not all), GNOME has a dependency on logind. If you're in one of those circumstances, you can use elogind as a drop-in replacement. That's far from having a dependency on systemd. >Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Both package managers deprive me of control over my system. I don't think snap lets you deploy your own repository, but for Flatpak this is very very wrong. Check here: https://docs.flatpak.org/en/latest/hosting-a-repository.html https://docs.flatpak.org/en/latest/hosting-a-repository.html
posix_me_less 5y ago
> Such a thing doesn't happen if the thing offered isn't an improvement over what was before. It does happen sometimes. GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. And improvement is subjective. Maybe systemd made maintainers' lives better. But it also introduced big nasty software full of bugs that discourages hacking by users. Many users consider that a deterioration of the Linux ecosystem. I'll take wrestling a bug in a 400-line shell script to wrestling a bug in the systemd C code and compiling my fixed version.
- awrmc 5y ago
  >GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. Are we thinking of the same thing? GTK3 had a much better theming system, new widgets, support for high DPI displays, improved rendering, support for animations, and a lot of other things. GNOME 3 had a much more streamlined design too. You may not have liked them but there were plenty of new features to offer. >I'll take wrestling a bug in a 400-line shell script to wrestling a bug in the systemd C code and compiling my fixed version. I wouldn't, once you fix the bug in the C code it's fixed for everything. The bugs in the shell scripts keep needing to be fixed over and over again, because copying code around in shell scripts is really common. There is also a line to be drawn where low-level code should be written in C and I think this is well past that line. Service script code is usually privileged and runs as root so the utility of making it hackable seems pretty small. I expect you'd agree running bash scripts inside the kernel is a bad idea too.
  - posix_me_less 5y ago
    That was mostly feature expansion. I meant improvement of existing workflows. Maybe high DPI would count. I didn't have high DPI monitor back then, but those who did maybe were pleased. Fixing a bug in shell script, even if 30 times, is still much easier than downloading, understanding modifying and compiling and deploying 4000 files and 1.6 million lines of systemd C code. There is an obvious cost/benefit factor here. If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational. Not with the ever-expanding pile of prototype-level software we got. I'm not reading that code, not even for money.

Nasreddin_Hodja 5y ago

> systemd became the de-facto default init sys because Distro Maintainers have chosen it. Because they were forced to choose it due to vendorlock and many other projects became dependent on systemd. Unsystemding everything would be very expensive. Same problem will be with snap and flatpak.

awrmc 5y ago
There aren't actually any projects dependent on systemd in any significant capacity. I don't know where that myth comes from but it's not true. Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager.
- Nasreddin_Hodja 5y ago
  I heard that Gnome is dependent on systemd now. > Snap and flatpak are essentially just package managers, I can't see why you would expect those to be worse than any other package manager. Those are even worse than tarball bundles. Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Centralized delivery is outmoded, future is decentralized distributed distribution. Both package managers deprive me of control over my system. I don't like the aggressiveness with which these projects are enforced. When Let's Encrypt switched to Spat as the only official distribution of their tool, I had to switch to alternative tool acme.sh instead of installing bloated snapd on my server.
  - awrmc 5y ago
    >I heard that Gnome is dependent on systemd now. Under some circumstances (not all), GNOME has a dependency on logind. If you're in one of those circumstances, you can use elogind as a drop-in replacement. That's far from having a dependency on systemd. >Main purpose of both overengineered projects is to tie users to vendor's services (snapcraft, flathub, e.t.c.). Both package managers deprive me of control over my system. I don't think snap lets you deploy your own repository, but for Flatpak this is very very wrong. Check here: https://docs.flatpak.org/en/latest/hosting-a-repository.html https://docs.flatpak.org/en/latest/hosting-a-repository.html

posix_me_less 5y ago

> Such a thing doesn't happen if the thing offered isn't an improvement over what was before. It does happen sometimes. GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. And improvement is subjective. Maybe systemd made maintainers' lives better. But it also introduced big nasty software full of bugs that discourages hacking by users. Many users consider that a deterioration of the Linux ecosystem. I'll take wrestling a bug in a 400-line shell script to wrestling a bug in the systemd C code and compiling my fixed version.

awrmc 5y ago
>GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted. Are we thinking of the same thing? GTK3 had a much better theming system, new widgets, support for high DPI displays, improved rendering, support for animations, and a lot of other things. GNOME 3 had a much more streamlined design too. You may not have liked them but there were plenty of new features to offer. >I'll take wrestling a bug in a 400-line shell script to wrestling a bug in the systemd C code and compiling my fixed version. I wouldn't, once you fix the bug in the C code it's fixed for everything. The bugs in the shell scripts keep needing to be fixed over and over again, because copying code around in shell scripts is really common. There is also a line to be drawn where low-level code should be written in C and I think this is well past that line. Service script code is usually privileged and runs as root so the utility of making it hackable seems pretty small. I expect you'd agree running bash scripts inside the kernel is a bad idea too.
- posix_me_less 5y ago
  That was mostly feature expansion. I meant improvement of existing workflows. Maybe high DPI would count. I didn't have high DPI monitor back then, but those who did maybe were pleased. Fixing a bug in shell script, even if 30 times, is still much easier than downloading, understanding modifying and compiling and deploying 4000 files and 1.6 million lines of systemd C code. There is an obvious cost/benefit factor here. If systemd fixed just init and basic service management in correct and minimalistic way, maybe fixing its C code here and there by power users would be rational. Not with the ever-expanding pile of prototype-level software we got. I'm not reading that code, not even for money.