4 ms·

I'm an SRE, I've done Linux from scratch, and I've built my own alternatives to system management, including "Service Managers" and "Container runtimes" (a fuzz

I'm an SRE, I've done Linux from scratch, and I've built my own alternatives to system management, including "Service Managers" and "Container runtimes" (a fuzzy distinction if ever there was one) Systemd badly needs alternatives. Upstart was a good one, and I wish it hadn't been abandoned. It had a lot of things wrong around it, but Upstart was not all-consuming and it did the one job it was supposed to do - Keep a set of processes alive - well. Systemd is opinionated in every way, and that's fine. But it needs something out there to challenge those opinions. It needs something that will force it to evolve the way users want and not just how it's developers want. Most importantly, it needs the egos involved to be shut down.

midislack 4y ago
The alternatives all exist and work fine. Init still works great too. And if you need auto "healing" daemons and such you can even use daemontools. There are a slew of actively developed well supported alternatives you can use today. And it's not so much the opinionated nature of the systemd pushers that's obnoxious, it's the fact that the software is enormous, buggy, and insecure.
- GauntletWizard 4y ago
  Have you ever read an old init.rc? I suggest you go do so. Daemontools was a reaction to the deficiencies of systemv init, and that it was not getting updated. Initrc has always supported "Run this, and run it again if it exits". That's not quite enough for a modern init system, but it's also not far off. Upstart and systemd capture the few additional things that are necessary. It should be in init's job to run daemons. Perhaps pid 1's only job - all the one-time setup that is required should be executed by another pid1 process before daemons start at all, and then you exec into a parallel daemon runner process.
  - midislack 4y ago
    I've been a Unix user since 1990 kiddo.
    - GauntletWizard 4y ago
      I'm definitely a kid compared to the old graybeards, but I ran and developed on Linux for years and years since the late 90s - And didn't actually read init.rc until like 2014 when I was trying to debug behavior that was different on Upstart WRT terminals. Because if it's deficiencies (such as having just the one init.rc file!), init was rarely used and not much thought of.

midislack 4y ago

The alternatives all exist and work fine. Init still works great too. And if you need auto "healing" daemons and such you can even use daemontools. There are a slew of actively developed well supported alternatives you can use today. And it's not so much the opinionated nature of the systemd pushers that's obnoxious, it's the fact that the software is enormous, buggy, and insecure.

GauntletWizard 4y ago
Have you ever read an old init.rc? I suggest you go do so. Daemontools was a reaction to the deficiencies of systemv init, and that it was not getting updated. Initrc has always supported "Run this, and run it again if it exits". That's not quite enough for a modern init system, but it's also not far off. Upstart and systemd capture the few additional things that are necessary. It should be in init's job to run daemons. Perhaps pid 1's only job - all the one-time setup that is required should be executed by another pid1 process before daemons start at all, and then you exec into a parallel daemon runner process.
- midislack 4y ago
  I've been a Unix user since 1990 kiddo.
  - GauntletWizard 4y ago
    I'm definitely a kid compared to the old graybeards, but I ran and developed on Linux for years and years since the late 90s - And didn't actually read init.rc until like 2014 when I was trying to debug behavior that was different on Upstart WRT terminals. Because if it's deficiencies (such as having just the one init.rc file!), init was rarely used and not much thought of.