6 ms·

From my point of view as an old guy who remembers the hell of init scripts, what they did was make an alternative to remembering arcane details of how each os a

From my point of view as an old guy who remembers the hell of init scripts, what they did was make an alternative to remembering arcane details of how each os and distro chose to set up their scripts. This: * made debugging a random system a lot more straight forward * made putting up software for packaging a lot easier * made customizing the start-up of a daemon a lot easier (this ties in with the first point) * made it so I didn't have to go to the guru who's only job seemed to be managing our obtuse set of init scripts that were extra baroque because order of startup really mattered. That guy I had to go to - he was an asshole an lorded his knowledge of arcana over anyone who brought him a question. I'm 90% sure he made it intentionally complex since he didn't have much skill beyond memorizing those silly facts (this is the same guy who got an entire project reassigned to me because he couldn't understand the concept of functions when I removed some extreme repetition from a python script he wrote). Most of the systemd haters remind me of this guy. I guess what you're implying is that he helped automate away dead weight and that made the leeches mad?

zozbot234 4y ago
These "simple" use cases break when you need to do anything even slightly more complex than whatever the systemD designers envisioned for the user. And if you try to submit an issue upstream, the typical response is "you're holding it wrong" or equivalent. This lack of a consistent design might be excusable when first trying to support a bunch of entirely novel use cases, but let's not pretend that it doesn't come with serious drawbacks.
- sophacles 4y ago
  I have yet to encounter something that systemd doesn't do OK or well. What is your example of something that systemd can't handle that was better handled by init scripts?
- ElectricalUnion 4y ago
  These "simple" use cases break when you need to do anything even slightly more complex than whatever the sysvinit scripts you copied envisioned. FTFY systemd might be sad but makes the simple case simple. sysvinit makes everything complex and error prone.
  - sam_lowry_ 4y ago
    sysvinit could be debugged, at least. I tried to debug a couple of systemd edge cases with Pottering, communicating over Github Issues, but he lost interest very quickly. To his, credit he is reactive until he decides the issue is not worth his time. To his discredit, he made himself into a giant bottleneck. Random systemd users can not easily understand it.
- kaba0 4y ago
  I’m sure then you can list a use-case which doesn’t work under systemd. Please do so, otherwise you are not contributing much.
the_biot 4y ago
This, and it seems like it needs repeating every time somebody brings up systemd. The SysV init scripts weren't good, they were crufty and slow, and messy when you wanted to customize something, and -- this doesn't get said enough -- used no Linux-specific features at all. Systemd was an upgrade that was sorely needed, and brought features to the init system that just didn't exist before.
shrubble 4y ago
How many different servers of non-systemd and systemd types, have you set up and managed? Where you had ultimate responsibility for the correct operation of the box and any VMs or services that it ran? The reason I ask, is that despite running many more non-systemd than systemd boxes over the past 22 years, I have had far more time taken up by systemd issues than issues with other init script systems. And that includes Solaris both sysV and SMF based.

zozbot234 4y ago

These "simple" use cases break when you need to do anything even slightly more complex than whatever the systemD designers envisioned for the user. And if you try to submit an issue upstream, the typical response is "you're holding it wrong" or equivalent. This lack of a consistent design might be excusable when first trying to support a bunch of entirely novel use cases, but let's not pretend that it doesn't come with serious drawbacks.

sophacles 4y ago
I have yet to encounter something that systemd doesn't do OK or well. What is your example of something that systemd can't handle that was better handled by init scripts?
ElectricalUnion 4y ago
These "simple" use cases break when you need to do anything even slightly more complex than whatever the sysvinit scripts you copied envisioned. FTFY systemd might be sad but makes the simple case simple. sysvinit makes everything complex and error prone.
- sam_lowry_ 4y ago
  sysvinit could be debugged, at least. I tried to debug a couple of systemd edge cases with Pottering, communicating over Github Issues, but he lost interest very quickly. To his, credit he is reactive until he decides the issue is not worth his time. To his discredit, he made himself into a giant bottleneck. Random systemd users can not easily understand it.
kaba0 4y ago
I’m sure then you can list a use-case which doesn’t work under systemd. Please do so, otherwise you are not contributing much.

the_biot 4y ago

This, and it seems like it needs repeating every time somebody brings up systemd. The SysV init scripts weren't good, they were crufty and slow, and messy when you wanted to customize something, and -- this doesn't get said enough -- used no Linux-specific features at all. Systemd was an upgrade that was sorely needed, and brought features to the init system that just didn't exist before.

shrubble 4y ago

How many different servers of non-systemd and systemd types, have you set up and managed? Where you had ultimate responsibility for the correct operation of the box and any VMs or services that it ran? The reason I ask, is that despite running many more non-systemd than systemd boxes over the past 22 years, I have had far more time taken up by systemd issues than issues with other init script systems. And that includes Solaris both sysV and SMF based.