[hello_there]

What I really dislike about these debates about systemd is that usually nobody mentions the alternatives. From reading the debate I get the impression that both sysvinit and systemd have major problems, but I'm never presented with a solution. So if I'm going to be against sysvinit as well as systemd, then what should i be supporting?

[exelius]

The main alternatives seem to be OpenRC and Upstart. One of the biggest criticisms of systemd by its detractors is that it's unproven and not stable; and neither of these address that concern.

Upstart was developed by Ubuntu, which has stopped supporting it and is adopting systemd because they recognized the need to standardize on a single system. After the Debian committee voted to go with systemd, Ubuntu (being a Debian derivative) followed suit.[1]

OpenRC isn't really a replacement for sysvinit; rather it bolts on some functionality on top of sysvinit. My understanding is that OpenRC is not an incredibly mature codebase and would have needed a lot of work to come up to feature/stability parity with systemd. Because it doesn't fully replace sysvinit, it also doesn't solve all of the same problems as systemd.

[1] http://www.markshuttleworth.com/archives/1316

[jude-]

> OpenRC isn't really a replacement for sysvinit; rather it bolts on some functionality on top of sysvinit. My understanding is that OpenRC is not an incredibly mature codebase and would have needed a lot of work to come up to feature/stability parity with systemd.

It's not the goal of OpenRC to be a systemd replacement either. In fact, I don't think it's the goal of any init system to be a systemd replacement, except for uselessd (please correct me if I'm wrong).

OpenRC solves some of the bigger problems that systemd solves--namely, reliable process tracking, cleaner init scripts, user-defined targets, parallel service startup/shutdown, etc. Moreover, most of the above features are optional, and the system exposes most of its runtime state through the filesystem instead of DBus (so you can inspect it however you want with whatever tools you want). As an added bonus, it's portable.

It's really a pity that the Debian TC didn't look at it closely back during the init system vote, but to be fair, OpenRC's Debian integration was a work-in-progress at the time (I'm pleased to say it runs without problems on my Debian subnotebook).

[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.

[makomk]

You're right that OpenRC only replaces the layers above init, but that's where most of the interesting stuff happens. In a traditional sysvinit-based system, all the actual work of setting up the system, finding and running the correct init scripts, etc is done by shell scripts started by init. OpenRC replaces those shell scripts with a proper service management layer, with init's only jobs being to start OpenRC, spawn getty processes on terminals, and reap orphan processes.

[e7620]

I happen to like modern daemontools-like init systems a lot, (runit, s6) but I use various init systems depending on what I want, and that's great IMO.

The problem is that systemd is that is being forcefully pushed to all distros. For instance, by merging udev with systemd. We want to keep all the alternatives open.

[sprash]

Support sinit (http://tools.suckless.org/sinit).

Look at the source and you understand the whole system within a minute. All of it.

[papaf]

One alternative is dnsmasq.

No really. Systemd now includes a caching DNS server and DHCP. Another alternative is ntpd. No really. Systemd now includes a time daemon.

Being intellectually lazy I like to think of the alternatives as "choice" and "linux".