9 ms·

So long as this isn't to make way for Redhat's vision of systemd as the base system, I shrug.

by alrs 11y ago

vezzy-fnord 11y ago
LSB is actually somewhat to blame for prolonging sysvinit's lifespan, in its specification of standard initscript functions (which ultimately were seldom used and laughable compared to /etc/rc.subr in BSD-land) and the awkward dependency headers that required a preprocessor like insserv(8) to scan them. systemd as base system will certainly happen, regardless.
- duncan_bayne 11y ago
  :(
- AdmiralACK 11y ago
  I, and many others, prefer sysvinit over systemd, which I consider overly bloaty and not in-line with the unix philosophy of 'do one thing and do it well'. It's far too involved in the overall systems where, now, some desktop environments require it? That's absolute crap.
  - cakes 11y ago
    Though I'm not going to say I really care for sysvinit - I prefer it to systemd as well. Every interaction I've had with systemd just ends up confusing me until I either successfully get it work _somehow_ outside of logic I can actually comprehend or giving up entirely. A lot of people I know have had similar experiences.
    - stephen_g 11y ago
      Interesting perspective. My experience has been the complete opposite - writing unit scripts used to be a real pain, but systemd unit files take two minutes and just work every time. My machines start much faster with systemd too, which is a nice side effect.
    - deckard1 11y ago
      I used to be on the fence. I knew I hated journald with a passion. But for systemd, the last straw was trying to mount a USB drive one day. I would do "mount", and nothing was mounted. I looked through the logs and noticed it was being unmounted on mount. What the fuck, right? Turns out, a prior unmount of a USB stick killed some service that systemd runs. So systemd thinks the service is dead, which means it should not be mounted, which means it keeps umounting the damn thing. Totally braindead. That's also when I learned systemd was running an entire virtual fstab layer. Because, you know, /etc/fstab just isn't good enough anymore.
      - sandGorgon 11y ago
        This is actually a good thing. You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine. It did not make the correct decision, but the infrastructure is there. I would file a bug on systemd mentioning this behavior. But I like the fact that that my usb wifi card will not screw my system.
        mrob 11y ago
        I don't want intelligent tools. The smarter the tool the more difficult it is to fix when it inevitably breaks. The intelligence might save a few minutes every so often, but the failures can cost hours, and at a time when you might urgently need things to work correctly. Predictability is more valuable.
        weland 11y ago
        > You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine. What was intelligent about that? I don't need intelligent tools, I need tools that do what I say! That's why they're tools, damn it!
      - bkor 11y ago
        This sounds very strange. Could you add a bit more detail. Which service crashed? Same service that caused the unmount? Any log messages?
  - simoncion 11y ago
    > I, and many others, prefer sysvinit over systemd... Do you prefer sysvrc over -say- OpenRC, Upstart, runit, etc, etc?
  - _delirium 11y ago
    > not in-line with the unix philosophy of 'do one thing and do it well' I'm not sure how you could, with a straight face, claim that sysvinit fits this description. It does many things, none of them particularly well.
    - na85 11y ago
      Replacing a bad system (sysvinit) with another bad system (systemd) is just change for change's sake.
      - throwaway2048 11y ago
        ah yes, the old "everything must be perfect before we are allowed to change anything" scree. The only thing this accomplishes is ensuring no progress is made, ever.
        vezzy-fnord 11y ago
        Well, in fairness, systemd isn't really a matter of changing sysvinit. It's changing the entire low-level userspace, so there's a lot more one can object to, in principle.
  - vezzy-fnord 11y ago
    I don't know of many people who actually liked sysvinit. It's mostly apathy due to its low surface (though actually sysvinit is still monolithic and overly coupled compared to members of the daemontools family like runit or s6). It's a red herring, anyway. People have been replacing classic BSD and SysV initialization schemes since 1992 [1], but systemd was the first to penetrate the scene quite massively for a plethora of reasons that no one can seem to agree on. [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
    - ewzimm 11y ago
      Responses to software seem to follow patterns. Sysvinit is basically Windows XP. People hated it for its lack of sophistication until it got replaced by Vista with its enhanced permissions, which people found inconvenient because they required slightly different interactions, and then XP became, if not good, at least the best in existence. Systemd will eventually be replaced by a minor revision which addresses the main complaints of the vocal minority, and then when NeoUpstart establishes dominance despite a massive list of bugs, systemd will rise to immaculate status and everyone will brag about how they used it before it was cool.
      - rodgerd 11y ago
        > Sysvinit is basically Windows XP. Honestly that's unfair to XP/Windows Server 2003 which had much better supervisor capability than sysvinit provides.
        togusa 11y ago
        To be fair NT4 had a better service management story in 1996.
        JdeBP 11y ago
        And it would be interesting to see how much of that it took from VMS.
- beedogs 11y ago
  > systemd as base system will certainly happen, regardless. That's really a shame. Systemd is almost comically bad.
  - sanderjd 11y ago
    Has someone made a resource where noobs like me can go and read about why systemd is "almost comically bad" in a succinct fashion? I've seen a lot of political stuff, and a lot of claims that sysvinit ain't broke so we shouldn't fix it (which makes little sense to me), but haven't seen a good resource discussing technical merits, or the lack thereof.
    - vezzy-fnord 11y ago
      Ugh. I could probably do it, but in all honesty, the "debate" has been so spoiled that I doubt anyone would take it seriously. My relatively technical article about FreeBSD and launchd (which had only one error about where plists were parsed, a relatively minor gripe in the text) was near-universally misunderstood and derailed by commentators who went on rants tangential to what I actually discussed. Same with my init history article. But, if enough people want to, maybe I'll bite the bullet. Not sure if I'd like to subject myself to it, but I think I might end up writing a rather long treatise if there's demand and I do go with it.
      - chris_wot 11y ago
        I'd be interested :-)
      - insulanian 11y ago
        Bring it on!
      - throwaway7767 11y ago
        I'd also be interested. I kinda like systemd as far as I've tried it, but as you say, the discussion around it is just inane. I'm sure there are valid complaints buried in there, and you seem to be a reasonable sort about these things. There are other pages out there claiming to be neutral overviews, but they generally just take a neutral tone while rehashing the same long-debunked myths and spreading FUD. The specific thing I like about systemd is the init replacement. It's just so much better! Automatically tracking daemon child processes, even detached ones. Supporting all the different modes daemons work, so I don't need to write yet another damn clean-up-all-the-children function in a SysVinit script. It's wonderful. But systemd is a lot more than an init system and I don't really have strongly formed opinions on those.
rmdoss 11y ago
I am still to find a sys admin that likes systemd. On the other hand, developers seem to enjoy it quite a bit. That's what happens when you have developers developing for themselves, not for sys admins (the end users of their work).
- tene 11y ago
  I've been a sys admin for ten years. I like systemd.
- SEJeff 11y ago
  I've managed Unix and Linux systems for over 10 years. I prefer systemd based systems where possible. Hit me up offline (email is in the resume linked in my profile) for technical reasons if you care.
  - euyyn 11y ago
    Why not explain them here? It's probably interesting for a lot of people.
    - XorNot 11y ago
      Unit files are simple to write, and make incorporating new custom processes even simpler (does it log to stdout? It'll log to journald and then syslog perfectly fine). Process management is built in and sophisticated (restarts, timeouts, conditions, limits etc.). The dependency system is amazing for ensuring your system fails sensibly: I can link mountpoints to processes, and easily guarantee that a mail daemon only runs when its network mount is ready, and then make it also shutdown if that mount goes away for any reason. This is huge for self-documenting infrastructure - you can ensure that even manual intervention in the system won't leave it in a weird state, and the why is all right there.
  - click170 11y ago
    Please don't take this conversation offline, share your thoughts here instead. Taking a conversation that started in public offline when there is an expressed interest in this very thread just doesn't follow.

So long as this isn't to make way for Redhat's vision of systemd as the base system, I shrug.

by alrs 11y ago

So long as this isn't to make way for Redhat's vision of systemd as the base system, I shrug.

LSB is actually somewhat to blame for prolonging sysvinit's lifespan, in its specification of standard initscript functions (which ultimately were seldom used and laughable compared to /etc/rc.subr in BSD-land) and the awkward dependency headers that required a preprocessor like insserv(8) to scan them. systemd as base system will certainly happen, regardless.

duncan_bayne 11y ago
:(
AdmiralACK 11y ago
I, and many others, prefer sysvinit over systemd, which I consider overly bloaty and not in-line with the unix philosophy of 'do one thing and do it well'. It's far too involved in the overall systems where, now, some desktop environments require it? That's absolute crap.
- cakes 11y ago
  Though I'm not going to say I really care for sysvinit - I prefer it to systemd as well. Every interaction I've had with systemd just ends up confusing me until I either successfully get it work _somehow_ outside of logic I can actually comprehend or giving up entirely. A lot of people I know have had similar experiences.
  - stephen_g 11y ago
    Interesting perspective. My experience has been the complete opposite - writing unit scripts used to be a real pain, but systemd unit files take two minutes and just work every time. My machines start much faster with systemd too, which is a nice side effect.
  - deckard1 11y ago
    I used to be on the fence. I knew I hated journald with a passion. But for systemd, the last straw was trying to mount a USB drive one day. I would do "mount", and nothing was mounted. I looked through the logs and noticed it was being unmounted on mount. What the fuck, right? Turns out, a prior unmount of a USB stick killed some service that systemd runs. So systemd thinks the service is dead, which means it should not be mounted, which means it keeps umounting the damn thing. Totally braindead. That's also when I learned systemd was running an entire virtual fstab layer. Because, you know, /etc/fstab just isn't good enough anymore.
    - sandGorgon 11y ago
      This is actually a good thing. You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine. It did not make the correct decision, but the infrastructure is there. I would file a bug on systemd mentioning this behavior. But I like the fact that that my usb wifi card will not screw my system.
      - mrob 11y ago
        I don't want intelligent tools. The smarter the tool the more difficult it is to fix when it inevitably breaks. The intelligence might save a few minutes every so often, but the failures can cost hours, and at a time when you might urgently need things to work correctly. Predictability is more valuable.
      - weland 11y ago
        > You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine. What was intelligent about that? I don't need intelligent tools, I need tools that do what I say! That's why they're tools, damn it!
    - bkor 11y ago
      This sounds very strange. Could you add a bit more detail. Which service crashed? Same service that caused the unmount? Any log messages?
- simoncion 11y ago
  > I, and many others, prefer sysvinit over systemd... Do you prefer sysvrc over -say- OpenRC, Upstart, runit, etc, etc?
- _delirium 11y ago
  > not in-line with the unix philosophy of 'do one thing and do it well' I'm not sure how you could, with a straight face, claim that sysvinit fits this description. It does many things, none of them particularly well.
  - na85 11y ago
    Replacing a bad system (sysvinit) with another bad system (systemd) is just change for change's sake.
    - throwaway2048 11y ago
      ah yes, the old "everything must be perfect before we are allowed to change anything" scree. The only thing this accomplishes is ensuring no progress is made, ever.
      - vezzy-fnord 11y ago
        Well, in fairness, systemd isn't really a matter of changing sysvinit. It's changing the entire low-level userspace, so there's a lot more one can object to, in principle.
- vezzy-fnord 11y ago
  I don't know of many people who actually liked sysvinit. It's mostly apathy due to its low surface (though actually sysvinit is still monolithic and overly coupled compared to members of the daemontools family like runit or s6). It's a red herring, anyway. People have been replacing classic BSD and SysV initialization schemes since 1992 [1], but systemd was the first to penetrate the scene quite massively for a plethora of reasons that no one can seem to agree on. [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
  - ewzimm 11y ago
    Responses to software seem to follow patterns. Sysvinit is basically Windows XP. People hated it for its lack of sophistication until it got replaced by Vista with its enhanced permissions, which people found inconvenient because they required slightly different interactions, and then XP became, if not good, at least the best in existence. Systemd will eventually be replaced by a minor revision which addresses the main complaints of the vocal minority, and then when NeoUpstart establishes dominance despite a massive list of bugs, systemd will rise to immaculate status and everyone will brag about how they used it before it was cool.
    - rodgerd 11y ago
      > Sysvinit is basically Windows XP. Honestly that's unfair to XP/Windows Server 2003 which had much better supervisor capability than sysvinit provides.
      - togusa 11y ago
        To be fair NT4 had a better service management story in 1996.
        JdeBP 11y ago
        And it would be interesting to see how much of that it took from VMS.
beedogs 11y ago
> systemd as base system will certainly happen, regardless. That's really a shame. Systemd is almost comically bad.
- sanderjd 11y ago
  Has someone made a resource where noobs like me can go and read about why systemd is "almost comically bad" in a succinct fashion? I've seen a lot of political stuff, and a lot of claims that sysvinit ain't broke so we shouldn't fix it (which makes little sense to me), but haven't seen a good resource discussing technical merits, or the lack thereof.
  - vezzy-fnord 11y ago
    Ugh. I could probably do it, but in all honesty, the "debate" has been so spoiled that I doubt anyone would take it seriously. My relatively technical article about FreeBSD and launchd (which had only one error about where plists were parsed, a relatively minor gripe in the text) was near-universally misunderstood and derailed by commentators who went on rants tangential to what I actually discussed. Same with my init history article. But, if enough people want to, maybe I'll bite the bullet. Not sure if I'd like to subject myself to it, but I think I might end up writing a rather long treatise if there's demand and I do go with it.
    - chris_wot 11y ago
      I'd be interested :-)
    - insulanian 11y ago
      Bring it on!
    - throwaway7767 11y ago
      I'd also be interested. I kinda like systemd as far as I've tried it, but as you say, the discussion around it is just inane. I'm sure there are valid complaints buried in there, and you seem to be a reasonable sort about these things. There are other pages out there claiming to be neutral overviews, but they generally just take a neutral tone while rehashing the same long-debunked myths and spreading FUD. The specific thing I like about systemd is the init replacement. It's just so much better! Automatically tracking daemon child processes, even detached ones. Supporting all the different modes daemons work, so I don't need to write yet another damn clean-up-all-the-children function in a SysVinit script. It's wonderful. But systemd is a lot more than an init system and I don't really have strongly formed opinions on those.

rmdoss 11y ago

I am still to find a sys admin that likes systemd. On the other hand, developers seem to enjoy it quite a bit. That's what happens when you have developers developing for themselves, not for sys admins (the end users of their work).

tene 11y ago
I've been a sys admin for ten years. I like systemd.
SEJeff 11y ago
I've managed Unix and Linux systems for over 10 years. I prefer systemd based systems where possible. Hit me up offline (email is in the resume linked in my profile) for technical reasons if you care.
- euyyn 11y ago
  Why not explain them here? It's probably interesting for a lot of people.
  - XorNot 11y ago
    Unit files are simple to write, and make incorporating new custom processes even simpler (does it log to stdout? It'll log to journald and then syslog perfectly fine). Process management is built in and sophisticated (restarts, timeouts, conditions, limits etc.). The dependency system is amazing for ensuring your system fails sensibly: I can link mountpoints to processes, and easily guarantee that a mail daemon only runs when its network mount is ready, and then make it also shutdown if that mount goes away for any reason. This is huge for self-documenting infrastructure - you can ensure that even manual intervention in the system won't leave it in a weird state, and the why is all right there.
- click170 11y ago
  Please don't take this conversation offline, share your thoughts here instead. Taking a conversation that started in public offline when there is an expressed interest in this very thread just doesn't follow.