4 ms·

Additionally, no alternative project is even providing close to the set of features that i.e. systemd or pulseaudio does, not even via modules. sysvinit for exa

Additionally, no alternative project is even providing close to the set of features that i.e. systemd or pulseaudio does, not even via modules. sysvinit for example is only an alternative to systemd the same way a SUV is an alternative to F1. (watch https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo if you don't know why)

_emacsomancer_ 7y ago
> sysvinit for example is only an alternative to systemd the same way a SUV is an alternative to F1 Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. And I would use the same car metaphor for comparisons with some of the other options, esp. runit, except with systemd in the SUV slot (e.g. my runit systems all behave themselves; my systemd systems frequently hang on reboot, often needing a REISUB).
- AsyncAwait 7y ago
  > Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. > my runit systems all behave themselves; my systemd systems frequently hang on reboot Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related), and systemd has a default 90s timer to try to wait for everything to dismount, shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that - look for 'DefaultTimeoutStopSec' in /etc/systemd/system.conf).
  - _emacsomancer_ 7y ago
    > Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. I'm not that familiar with openRC or s6 (I've played with them, but don't use them on any 'real work' systems), though my understanding is that there is a proper openrc-init being developed. I was actually thinking more of runit and shepherd, which provide their own init and daemon-management. > > my runit systems all behave themselves; my systemd systems frequently hang on reboot > Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related), This is across multiple systems, from Arch boxes, which I've hand-configured to vanilla Ubuntu boxes, and ranges in behaviour from multiple 90s timers to just hanging on completely black screen until forced to reboot. There are certainly no obvious configuration issues on any these, definitely not crypttab or the like. > shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that) But, even timers aside, runit is faster than systemd on both boot and shutdown, for similarly-configured systems. And provides (me at least) a best user-experience than systemd. runit shuts things down properly; with systemd I often have to literally 'yank the cord'.
    - AsyncAwait 7y ago
      I guess I did not explain myself properly, s6 is not actually a wrapper over sysvinit in practice, it's its own thing, like runit. But like runit it relies on bash scripts, which are not declarative and open to a wide variety in quality, just like with sysvinit. Also, runit does i.e rely on logind, which everybody forgets systemd took upon themselves as consolekit was unmaintained. Why does runit rely on systemd's work here? > runit shuts things down properly; with systemd I often have to literally 'yank the cord' I've looked at how systemd handles shutting things down vs other inits and it's just a lot more paranoid, i.e. it waits for confirmation of every single service being shut down etc. In other init systems it tends to be a case of 'send shutdown signal, assume process shuts down'. You could fault systemd for this, but it's more of an application-level issue.
  - PlutoIsAPlanet 7y ago
    if your systemd isn't able to "shut things down" quickly, that's the fault of an application not responding to a shutdown signal and systemd waiting before it kills it.
    - _emacsomancer_ 7y ago
      For the timer-issues, perhaps. But that doesn't cover the completely black screen hangs.
  - CameronNemo 7y ago
    s6 is often used with execline, a stripped down scripting language that is highly performant.

_emacsomancer_ 7y ago

> sysvinit for example is only an alternative to systemd the same way a SUV is an alternative to F1 Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. And I would use the same car metaphor for comparisons with some of the other options, esp. runit, except with systemd in the SUV slot (e.g. my runit systems all behave themselves; my systemd systems frequently hang on reboot, often needing a REISUB).

AsyncAwait 7y ago
> Perhaps. But this is the same tired old argument that ignores the existence of any other init/daemon-manager aside from systemd. Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. > my runit systems all behave themselves; my systemd systems frequently hang on reboot Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related), and systemd has a default 90s timer to try to wait for everything to dismount, shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that - look for 'DefaultTimeoutStopSec' in /etc/systemd/system.conf).
- _emacsomancer_ 7y ago
  > Do you mean openRC, s6 etc? They still all use bash scripts, (which as a result depend on the dev for quality and can vary quite a bit) vs systemd's clear, uniform service definitions. They don't provide much beyond starting services and are more like wrappers around sysvinit than anything else. I'm not that familiar with openRC or s6 (I've played with them, but don't use them on any 'real work' systems), though my understanding is that there is a proper openrc-init being developed. I was actually thinking more of runit and shepherd, which provide their own init and daemon-management. > > my runit systems all behave themselves; my systemd systems frequently hang on reboot > Every time I've seen this in practice it turned out the system was actually not configured properly, (usually crypttab or something related), This is across multiple systems, from Arch boxes, which I've hand-configured to vanilla Ubuntu boxes, and ranges in behaviour from multiple 90s timers to just hanging on completely black screen until forced to reboot. There are certainly no obvious configuration issues on any these, definitely not crypttab or the like. > shut down properly vs other init systems just yank the cord, but it seems faster, so I guess it's 'better', (in which case you can just shorten the systemd timer to like 1s and it would be even faster doing that) But, even timers aside, runit is faster than systemd on both boot and shutdown, for similarly-configured systems. And provides (me at least) a best user-experience than systemd. runit shuts things down properly; with systemd I often have to literally 'yank the cord'.
  - AsyncAwait 7y ago
    I guess I did not explain myself properly, s6 is not actually a wrapper over sysvinit in practice, it's its own thing, like runit. But like runit it relies on bash scripts, which are not declarative and open to a wide variety in quality, just like with sysvinit. Also, runit does i.e rely on logind, which everybody forgets systemd took upon themselves as consolekit was unmaintained. Why does runit rely on systemd's work here? > runit shuts things down properly; with systemd I often have to literally 'yank the cord' I've looked at how systemd handles shutting things down vs other inits and it's just a lot more paranoid, i.e. it waits for confirmation of every single service being shut down etc. In other init systems it tends to be a case of 'send shutdown signal, assume process shuts down'. You could fault systemd for this, but it's more of an application-level issue.
- PlutoIsAPlanet 7y ago
  if your systemd isn't able to "shut things down" quickly, that's the fault of an application not responding to a shutdown signal and systemd waiting before it kills it.
  - _emacsomancer_ 7y ago
    For the timer-issues, perhaps. But that doesn't cover the completely black screen hangs.
- CameronNemo 7y ago
  s6 is often used with execline, a stripped down scripting language that is highly performant.