2 ms·

Agreed. Which is why I said On the other hand a certain amount of skepticism and criticism is very much in order. The problems systemd tried to address are rea

by krylon 11y ago

Agreed. Which is why I said On the other hand a certain amount of skepticism and criticism is very much in order. The problems systemd tried to address are real, and some of the ideas behind it are appealing. But the way it attempts to replace several important pieces of the system at once, and the way it is being forced on people in a "eat it or leave it"-style feels uncomfortable. Part of what made Unix what it is today is the idea to build a system that might be very far from perfect but that is easy to improve in small, incremental steps so one quickly gets a feeling for what works well and what does not.

digi_owl 11y ago
Frankly i feel that way to many sub-projects within systemd is at this point "i can rewrite this faster than get patches past the maintainers". Often with the "hilarious" outcome that problem that was solved a decade ago crops up again in the new implementation within systemd.
groovy2shoes 11y ago
Out of curiosity, what do you consider to be real problems that systemd is trying to address? (Honest question).
- krylon 11y ago
  For one thing, a method service management that does not just fire off commands but monitors services and restarts them if they fail. Also, doing this with an idea of dependencies of services. Event-based service management is interesting, too, e.g. shutting down a network service when the machine is disconnected from the network and restarts them when a connection becomes available again (think NTP, DHCP clients). Once you have an idea of how services depend on each other, you get the ability to start services in parallel for free (whether that is so useful or even a good idea is another question). Given the fact that systemd is hardly the first attempt to solve these issues (think SMF on Solaris, launchd on OS X, or the couple of attempts on GNU/Linux), I think a lot of people have felt the itch to improve on the classical SysV init.

by krylon 11y ago

digi_owl 11y ago

Frankly i feel that way to many sub-projects within systemd is at this point "i can rewrite this faster than get patches past the maintainers". Often with the "hilarious" outcome that problem that was solved a decade ago crops up again in the new implementation within systemd.

groovy2shoes 11y ago

Out of curiosity, what do you consider to be real problems that systemd is trying to address? (Honest question).

krylon 11y ago
For one thing, a method service management that does not just fire off commands but monitors services and restarts them if they fail. Also, doing this with an idea of dependencies of services. Event-based service management is interesting, too, e.g. shutting down a network service when the machine is disconnected from the network and restarts them when a connection becomes available again (think NTP, DHCP clients). Once you have an idea of how services depend on each other, you get the ability to start services in parallel for free (whether that is so useful or even a good idea is another question). Given the fact that systemd is hardly the first attempt to solve these issues (think SMF on Solaris, launchd on OS X, or the couple of attempts on GNU/Linux), I think a lot of people have felt the itch to improve on the classical SysV init.