3 ms·
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 sys
by 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 agoThe 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 agoThis 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.