4 ms·

I don't think we should have stuck with something like SysVinit, there's definitely room for improvement, but saying "it's either SysVinit or systemd" is a fals

I don't think we should have stuck with something like SysVinit, there's definitely room for improvement, but saying "it's either SysVinit or systemd" is a false dichotomy. If I was approaching building an init system I'd make a better language for writing init scripts than bash, some kind of interpreter that processes mostly declarative init files, sets things up, and then exits. An incremental improvement that works with existing systems instead of putting a whole bunch of new (generally un-audited) code into PID 1, with all the security implications that implies. Redhat may contribute the majority of the work but they're also very good at positioning themselves so that outsiders can't really contribute any work, or get any independently developed standards implemented.

AsyncAwait 6y ago
> If I was approaching building an init system I'd make a better language for writing init scripts than bash, some kind of interpreter that processes mostly declarative init file Guess what systemd does? > sets things up, and then exits And that's the crux of the issue isn't it? Because on modern systems, things need setting up and tearing down all the time.
- traverseda 6y ago
  > things need setting up and tearing down all the time. Well not really, that's an artifact of systemd's over-engineered design. There's nothing stopping you from tearing something down from an init script or doing more complicated dependency management using the CLI as your RPC mechanism (but red hat needed a reason to use their in-house RPC mechanism). Honestly something like systemd could be pretty reasonable if it wasn't created with the express intent of "combating fragmentation". Not that there aren't a whole bunch of technical and architectural issues with it, but still.
  - AsyncAwait 6y ago
    > There's nothing stopping you from tearing something down from an init script Except most init scripts I've seen are rather brittle and only "work" if the PID dance is exactly as the author predicted, are not declarative and hard to debug. I don't want to go back to init scripts, for all systemd's faults, the past was worse. Using the CLI as my RPC mechanism etc. just sounds like I should spend a bunch of time doing work that systemd can do a better job of managing for me.
soraminazuki 6y ago
How can people replace SysVinit without "doing their own take on EEE"? Your alternative approach is still not going to be compatible with SysVinit either, not to mention it being strikingly similar to systemd.
- welterde 6y ago
  Archlinux had their own non-sysvinit system (which went away in favor of systemd) as does voidlinux (runit based) and alpine (OpenRC) today. The problem is less the init system itself, but applications that depend on a specific init system [1] (gnome used to be a major source of contention in that regard). [1] https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
  - soraminazuki 6y ago
    Is applications depending on systemd particularly a bad thing? If we don't want applications to use non-SysVinit features, we might as well keep using SysVinit.
    - na85 6y ago
      Why should my window manager dictate what programs are allowed to start it?
      - AsyncAwait 6y ago
        For the same reason every piece of software 'dictates' its dependencies.
    - welterde 6y ago
      If you don't care about portability at all.. (regardless if it's just within linux or to *BSD). And like I already mentioned in my previous post.. there are other alternatives around than just SysV-init..
  - Valmar 6y ago

AsyncAwait 6y ago

> If I was approaching building an init system I'd make a better language for writing init scripts than bash, some kind of interpreter that processes mostly declarative init file Guess what systemd does? > sets things up, and then exits And that's the crux of the issue isn't it? Because on modern systems, things need setting up and tearing down all the time.

traverseda 6y ago
> things need setting up and tearing down all the time. Well not really, that's an artifact of systemd's over-engineered design. There's nothing stopping you from tearing something down from an init script or doing more complicated dependency management using the CLI as your RPC mechanism (but red hat needed a reason to use their in-house RPC mechanism). Honestly something like systemd could be pretty reasonable if it wasn't created with the express intent of "combating fragmentation". Not that there aren't a whole bunch of technical and architectural issues with it, but still.
- AsyncAwait 6y ago
  > There's nothing stopping you from tearing something down from an init script Except most init scripts I've seen are rather brittle and only "work" if the PID dance is exactly as the author predicted, are not declarative and hard to debug. I don't want to go back to init scripts, for all systemd's faults, the past was worse. Using the CLI as my RPC mechanism etc. just sounds like I should spend a bunch of time doing work that systemd can do a better job of managing for me.

soraminazuki 6y ago

How can people replace SysVinit without "doing their own take on EEE"? Your alternative approach is still not going to be compatible with SysVinit either, not to mention it being strikingly similar to systemd.

welterde 6y ago
Archlinux had their own non-sysvinit system (which went away in favor of systemd) as does voidlinux (runit based) and alpine (OpenRC) today. The problem is less the init system itself, but applications that depend on a specific init system [1] (gnome used to be a major source of contention in that regard). [1] https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
- soraminazuki 6y ago
  Is applications depending on systemd particularly a bad thing? If we don't want applications to use non-SysVinit features, we might as well keep using SysVinit.
  - na85 6y ago
    Why should my window manager dictate what programs are allowed to start it?
    - AsyncAwait 6y ago
      For the same reason every piece of software 'dictates' its dependencies.
  - welterde 6y ago
    If you don't care about portability at all.. (regardless if it's just within linux or to *BSD). And like I already mentioned in my previous post.. there are other alternatives around than just SysV-init..
- Valmar 6y ago