What about openrc?
https://wiki.gentoo.org/wiki/Comparison_of_init_systems
What's up with the words words words
Why systemd is winning the init wars and other things aren't
11–20 of 158 posts
Re: Why systemd is winning the init wars and other things aren't
#12This seems like a solution in search of a problem.
Yes, restarting broken/dead processes is handy, but this is not the job of init.
I can't wait to run regedit.py to fix my broken box...
Re: Why systemd is winning the init wars and other things aren't
#13"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that ty…
systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handle logging. It's frustrating to try to start a service and be unable to, and not know why because a message dumped to stderr went to /dev/null. I've been in this boat before and it's not fun.
Smart people at Red Hat spent a long time thinking about the problems faced by a modern init system. They looked at what had already been done, including the Mac init system, upstart, and the Solaris init system, and came up with something cool for Linux. I think it's sad that so many people are attacking this.
Anyway, nobody is forcing you to use anything. You can use Slackware or even one of the BSDs if you don't want systemd.
Re: Why systemd is winning the init wars and other things aren't
#14"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that ty…
> Why do the anti-choice people refuse to recognize that other people might have different requirements.
Go build your own LFS systems if you want ultimate choice. You don't get to force upstream authors (who like systemd) and distribution developers (who like systemd) to do what you want.
> I'm sticking with what already works.
sysvinit works only if you combine incredibly low expectations with a bad case of Stockholm syndrome.
Re: Why systemd is winning the init wars and other things aren't
#15"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that ty…
systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handl…
> I'm not sure what you mean by "disconnecting from dbus,"
dbus is a dependency of systemd itself, not just of the services that require it.
Re: Why systemd is winning the init wars and other things aren't
#16This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd. There's a little piece of insight which seems to escape many: there is no serious technical reason why…
runit seems to have been designed to be able to replace init: http://smarden.org/runit/replaceinit.html
Re: Why systemd is winning the init wars and other things aren't
#17This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd. There's a little piece of insight which seems to escape many: there is no serious technical reason why…
runit seems to have been designed to be able to replace init: http://smarden.org/runit/replaceinit.html
It's possible, but it's not designed to. It was designed to run under init, as a daemontools clone. Explained further here: http://smarden.org/pape/djb/daemontools/noinit.html
"In contrary to Richard Gooch, I suggest not to implement service dependencies and runlevel handling in the Unix process no 1, /sbin/init, keep it small and simple, that is why I wrote the runit package"
Re: Why systemd is winning the init wars and other things aren't
#18"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that ty…
systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handl…
There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting.
Even sysV init works this way. The current sysV init is very simple -- the invocation complexity lives in /etc/rc and the related rc.d scripts which operate as subprocesses.
"Smart people" is a silly thing to say. We're all smart people and sometimes smart people make poor technical decisions. Let the matter lay upon its technical merit, not upon empty platitudes.
Re: Why systemd is winning the init wars and other things aren't
#19This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd. There's a little piece of insight which seems to escape many: there is no serious technical reason why…
The article specifically says what you're saying: I don't think any of them have really been developed with replacing SysV init in Linux distributions or elsewhere as a goal. DJB daemontools certainly wasn't
Systemd is winning this war because it created the war, by conflicting with sysv init.
Upstart predates Systemd, systemd just has more traction.
Re: Why systemd is winning the init wars and other things aren't
#20The same way any other crap (such as Windows, Java, PHP, NodeJS, Docker - you name it) wins - its winning is due to a "catchy meme" about it, which triggers an automatic, ignorant snap-judgement of an unsophisticated consumer.
Look, with Java you don't have to think about hardware and OS - a greatest meme ever (and you have to pay for tons of hardware because Java = waste). NodeJS - you could code server-side apps the very same way you write stupid web-pages (without any deep knowledge) - great meme. With Docker no sysadmins are required, and an underlying operating system is just viewed an abstract "container" for an app (they you will pay to "experts" who would spend weeks analyzing why your crap is so slow and unpredictable in production). With systemd you don't have to understand the subtleties, and it is run with Docker. Yay!
The list could be too long.