5 ms·

Honest question, is your opinion that we should have been stuck with something like SysVinit just so it's more convenient for the BSDs, while the likes of RedHa

Honest question, is your opinion that we should have been stuck with something like SysVinit just so it's more convenient for the BSDs, while the likes of RedHat contribute the majority of the work? And if yes, can you point to an example of *BSD doing something similar while pushing their platform forward?

traverseda 6y ago
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
simias 6y ago
This is a loaded way to frame the question, some of us were just fine being "stuck" with SysVinit. I try not to get dragged into systemd flamewars because life is too short but it's disingenuous to claim that before systemd init systems were some kind of inescapable hellscape. I administrate multiple systemd-based linux distros, FreeBSD servers and buildroot-based embedded systems and I can tell you that systemd still gets in my way regularly while the sh-based init systems tend to Just Work and are very simple to understand and maintain. Of course I know that a big reason is that I'm very familiar with un*x system administration and the gotchas of shell scripting while systemd is probably more approachable for somebody who doesn't want to learn arcane knowledge about chmod and file locking and setuid and symbolic links but I think that explains why there's still so much pushback against systemd all these years later: people who care about init systems know enough about them that systemd feels over-engineered and unnecessarily complex while not bringing a lot to the table. Never once in the past years of running systemd have I thought "oh man, I sure am glad I'm using systemd and not an old SysV/BSD init system!". Not a single time. I did have multiple occurrences of systemd breaking stuff after an update though.
- AsyncAwait 6y ago
  > systemd still gets in my way regularly while the sh-based init systems tend to Just Work For me systemd based systems allow me to have declarative, portable unit files where init scripts don't. They allow me to reliably monitor and restart services, they shut things down properly instead of just force killing as many init scripts end up doing. I instantly know how to manage most major distros now that systemd's common among all of them, have no hesitation of writing a proper service file even for minor tasks and I get a ton of functionality 'for free' too. Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic. If your experience differs there's still plenty of non-systemd choices out there. They're not as prevalent as systemd ones, but that's because the people who sit down and actually write the code we all use find the services systemd provides valuable.
  - simias 6y ago
    Arguing that the advantage of systemd is portability is rather bold! And even if portability was the point I'm not sure I see the big deal. Writing an RC script from scratch if the software you use doesn't provide it is generally trivial. The vast majority of the time you wouldn't have to do that anyway as it ships with your OS's packages anyway. Sure, systemd might be "tidier" with its standard APIs and whatnot but it's also a lot more complicated and opaque than a bunch of shell scripts running one after an other. And if you're serious about sysadmin you'll have to learn shell scripting one day or the other anyway. >Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic. They're non-portable, that much is true but so is systemd, that's a weak argument. If everybody had adopted FreeBSD-style init it would be equally as portable, it's a self-fulfilling prophecy. With that logic we should just all ditch un*x and start running Windows since most people already use that anyway. The rest is nonsense. It's poor quality, non-consistent and non-deterministic if you write them that way. Sure, shell scripts being turing-complete opens the door to a lot of nonsense if people go wild and gives more latitude for very sloppy code but it doesn't have to be that way. >the people who sit down and actually write the code we all use find the services systemd provides valuable Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch. I'm sure many of them use it because that's what's available. I wrote a bunch of systemd unit files myself, I assure you that it wasn't meant as an endorsement. Besides it's only one side of the equation. Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them. I'm sure many software maintainers would prefer if everybody ran the same OS on the same hardware with the same use cases but that's not how the real world works.
ori_b 6y ago
> Honest question, is your opinion that we should have been stuck with something like SysVinit just so it's more convenient for the BSDs, BSD init is far better than Sysv. Adopting it would have been a step forward. There are also other init systems that are better designed, like openrc or runit.
- AsyncAwait 6y ago
  > There are also other init systems that are better designed, like openrc or runit. OpenRC is practically speaking a thin wrapper around SysVinit, not much of an upgrade if you ask me.

traverseda 6y ago

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

simias 6y ago

This is a loaded way to frame the question, some of us were just fine being "stuck" with SysVinit. I try not to get dragged into systemd flamewars because life is too short but it's disingenuous to claim that before systemd init systems were some kind of inescapable hellscape. I administrate multiple systemd-based linux distros, FreeBSD servers and buildroot-based embedded systems and I can tell you that systemd still gets in my way regularly while the sh-based init systems tend to Just Work and are very simple to understand and maintain. Of course I know that a big reason is that I'm very familiar with un*x system administration and the gotchas of shell scripting while systemd is probably more approachable for somebody who doesn't want to learn arcane knowledge about chmod and file locking and setuid and symbolic links but I think that explains why there's still so much pushback against systemd all these years later: people who care about init systems know enough about them that systemd feels over-engineered and unnecessarily complex while not bringing a lot to the table. Never once in the past years of running systemd have I thought "oh man, I sure am glad I'm using systemd and not an old SysV/BSD init system!". Not a single time. I did have multiple occurrences of systemd breaking stuff after an update though.

AsyncAwait 6y ago
> systemd still gets in my way regularly while the sh-based init systems tend to Just Work For me systemd based systems allow me to have declarative, portable unit files where init scripts don't. They allow me to reliably monitor and restart services, they shut things down properly instead of just force killing as many init scripts end up doing. I instantly know how to manage most major distros now that systemd's common among all of them, have no hesitation of writing a proper service file even for minor tasks and I get a ton of functionality 'for free' too. Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic. If your experience differs there's still plenty of non-systemd choices out there. They're not as prevalent as systemd ones, but that's because the people who sit down and actually write the code we all use find the services systemd provides valuable.
- simias 6y ago
  Arguing that the advantage of systemd is portability is rather bold! And even if portability was the point I'm not sure I see the big deal. Writing an RC script from scratch if the software you use doesn't provide it is generally trivial. The vast majority of the time you wouldn't have to do that anyway as it ships with your OS's packages anyway. Sure, systemd might be "tidier" with its standard APIs and whatnot but it's also a lot more complicated and opaque than a bunch of shell scripts running one after an other. And if you're serious about sysadmin you'll have to learn shell scripting one day or the other anyway. >Init scripts were always a poor-quality mess, non-portable among systems, non-consistent, non-deterministic. They're non-portable, that much is true but so is systemd, that's a weak argument. If everybody had adopted FreeBSD-style init it would be equally as portable, it's a self-fulfilling prophecy. With that logic we should just all ditch un*x and start running Windows since most people already use that anyway. The rest is nonsense. It's poor quality, non-consistent and non-deterministic if you write them that way. Sure, shell scripts being turing-complete opens the door to a lot of nonsense if people go wild and gives more latitude for very sloppy code but it doesn't have to be that way. >the people who sit down and actually write the code we all use find the services systemd provides valuable Systemd has been pushed down everybody's throat for a while now, saying retroactively that people use it because they find it valuable is a bit of a stretch. I'm sure many of them use it because that's what's available. I wrote a bunch of systemd unit files myself, I assure you that it wasn't meant as an endorsement. Besides it's only one side of the equation. Maybe it's nicer for the people writing the unit files, doesn't mean that it's a good thing for people actually having to use them. I'm sure many software maintainers would prefer if everybody ran the same OS on the same hardware with the same use cases but that's not how the real world works.

ori_b 6y ago

> Honest question, is your opinion that we should have been stuck with something like SysVinit just so it's more convenient for the BSDs, BSD init is far better than Sysv. Adopting it would have been a step forward. There are also other init systems that are better designed, like openrc or runit.

AsyncAwait 6y ago
> There are also other init systems that are better designed, like openrc or runit. OpenRC is practically speaking a thin wrapper around SysVinit, not much of an upgrade if you ask me.