[vertex-four]

> The main alternatives seem to be OpenRC and Upstart.

There's also outliers like nosh[0], which implements at least some of the good bits of systemd (socket activation is in there), and the ideas and general architecture are solid enough that it could be extended to implement more (device/path dependencies through udev and inotify are two that I hear people wanting). Then separate pieces of software can implement the remainder of what systemd implements (its many dbus APIs).

[0] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...

[exelius]

This debate has been raging for the better part of two years and many of these alternatives didn't exist when it started. Really though, systemd has the momentum and I don't see anything else remaining a mainstream alternative unless it just emulates systemd's functionality.

[vertex-four]

systemd's functionality isn't the issue - it's its architecture that is. An alternative bundle of software which is less strongly coupled would likely be accepted with open arms. I'd like to be able to pick what init system I want to use separately from what manages /dev and what handles my logging and what handles sessions/seats/logins.

nosh's architecture allows for that, whereas with systemd, while it amounts to 60-whatever binaries, you end up being required to run a significant amount of them in order to use any given bit of the system, and have to run systemd as PID 1 to run a fair amount of them. Why setting up kdbus, for example, can't be a separate process that doesn't depend on anything but libc and the kernel? No idea.

[exelius]

Yeah; I get the objections. More pragmatically, systemd was developed the way that it was, and for a large portion of its life there have been no credible alternatives that were objectively better.

But once systemd's behavior has become standardized, it becomes hard to change implementation details because its dependencies rely on not just what it does, but how it does the things that it does. You have to standardize on something, and it will inevitably be flawed because no system is perfect. Sysvinit is not adequate anymore (and I don't think you would disagree with that). Systemd was a solution that someone came up with, and was able to get a number of influential groups to agree to standardize on that solution.

[vertex-four]

> Sysvinit is not adequate anymore (and I don't think you would disagree with that). Systemd was a solution that someone came up with, and was able to get a number of influential groups to agree to standardize on that solution.

Absolutely. I'm just sad that the people behind the solution are making it harder and harder to replace that solution for people who'd like to, and anybody who sees the issue with that is labelled a "troll" or a "hater".

On the other hand, at least you can parse systemd unit files to convert them into whatever (nosh has a utility to do that). I think that's going to be a standard well after the Linux community diversifies from systemd. It's a fairly solid format.