3 ms·

This does not seem to be my experience as a professional systems engineer. Nobody says it's good code, but everyone is more excited about it than sysvinit, incl

by geofft 8y ago

This does not seem to be my experience as a professional systems engineer. Nobody says it's good code, but everyone is more excited about it than sysvinit, including people who do actually know how to use grep. (Except for a small number of people who let their biases override serious technical considerations, but those people tend to be poor employees for plenty of other reasons.)

StreamBright 8y ago
Since when is the argument about systemd vs sysvinit?? How about systemd vs daemontools? How about systemd vs s6? How about systemd vs OpenRC? How about systemd vs SMF? How about systemd vs upstart? It seems that the distro maintainers (and not the users of those distros) picked the new an shiny instead of investigating what would be the best for the future of these projects and picked a crappy solution. Soon a mayhem followed and no we are dealing with DNS resolution issues because of it which where not in scope at the time when they decided the cut over. Kind of how drug dealers get new customers.
- geofft 8y ago
  The expansive scope of systemd is what people like about it. daemontools, s6, OpenRC, and SMF are much more limited in scope; upstart is also somewhat limited though it tries to do some of the same things. (SMF also doesn't exist on Linux, and I've spent a lot of time working with both upstart and systemd professionally and my conclusion is that systemd genuinely has a better design and is genuinely more robust, although there are plenty of smart people who like upstart, I'll admit.) Again, I'm just speaking to my professional experience here and saying that the argument "Nobody wants systemd" is incorrect. People want systemd. People want what systemd does. Maybe they're wrong, but that's a separate argument.
  - acdha 8y ago
    This matches my experience as well: in our devops group it's basically a weekly occurrence to have a statement like “this is much {easier,safer,more robust} when we can use systemd”. Upstart was better than SysV but it took many years to add basic functionality (e.g. setuid/setgid, console logging, etc.) and there are still problems like not being able to reliably keep a process unless you remember add things like post-stop sleep blocks.

by geofft 8y ago

StreamBright 8y ago

Since when is the argument about systemd vs sysvinit?? How about systemd vs daemontools? How about systemd vs s6? How about systemd vs OpenRC? How about systemd vs SMF? How about systemd vs upstart? It seems that the distro maintainers (and not the users of those distros) picked the new an shiny instead of investigating what would be the best for the future of these projects and picked a crappy solution. Soon a mayhem followed and no we are dealing with DNS resolution issues because of it which where not in scope at the time when they decided the cut over. Kind of how drug dealers get new customers.

geofft 8y ago
The expansive scope of systemd is what people like about it. daemontools, s6, OpenRC, and SMF are much more limited in scope; upstart is also somewhat limited though it tries to do some of the same things. (SMF also doesn't exist on Linux, and I've spent a lot of time working with both upstart and systemd professionally and my conclusion is that systemd genuinely has a better design and is genuinely more robust, although there are plenty of smart people who like upstart, I'll admit.) Again, I'm just speaking to my professional experience here and saying that the argument "Nobody wants systemd" is incorrect. People want systemd. People want what systemd does. Maybe they're wrong, but that's a separate argument.
- acdha 8y ago
  This matches my experience as well: in our devops group it's basically a weekly occurrence to have a statement like “this is much {easier,safer,more robust} when we can use systemd”. Upstart was better than SysV but it took many years to add basic functionality (e.g. setuid/setgid, console logging, etc.) and there are still problems like not being able to reliably keep a process unless you remember add things like post-stop sleep blocks.