A wrapper, which can be written as a shell script itself, would look for dependency information in the init scripts, probably in a comment or perhaps in a variable. When the wrapper runs, it checks the status of any required init scripts which share the same first line, using the functionality built into each init script. If they are all running then it fires off the daemon and exits. Else, it blocks if it is critical or not if it is optional, and either way it loops and waits for deps for a decent amount of time. If it is critical the boot process is interrupted, if it is optional then something else happens (script-dependent.) Dependency information could also be stored in a variable in a config file (e.g. in /etc/default) and when not present, the daemon can be treated as critical and blocking. All the other elements of the system remain unchanged, down to symlinks establishing daemon launch order. This requires changes only to init scripts, and even then only for daemons which are expected to launch in parallel. Is there some obvious reason why this wouldn't work?

What was wrong with log analysis tools? One can bang them out with perl in a minute or two.

No, it really isn't. Process creation is cheap on Unix, and the shell will not only be cached during boot, but one or more copies of it will be present in memory at all times. Running the shell hundreds of times today is a triviality compared to running the shell dozens of times on Unix machines from the 1980s, on which that was in fact not a big deal, because process creation is cheap on Unix. This is just not a real consideration for any modern system, especially given the plethora of lightweight shells available for low-memory or otherwise limited systems.

This is really the argument that something new was needed, but frankly, it would have been simple enough to handle this without a whole new init system. A shell script wrapper would probably have done this job. Some distributions are already recording dependencies in init scripts; sequence information would be simple enough to add. If this is the best argument for systemd, and so far as I can tell it is that, then it's a really crap argument.

It should be relatively simple to create tools to permit systemd to automagically support normal Unixlike config files.

The truth is that nobody but Ubuntu has ever really tried for the mainstream desktop, and they have serious flaws involving ignoring their users; Microsoft and Apple already fill that niche.

I might actually take some effort to spoof my user-agent if it eliminates 5-more. You know, because "modern" Google assumes that my 1680-pixel wide display can't show me all the top-level options. So it makes up for that by showing the 5 most recently used options, and then "more". Where the fuck did Maps go? Oh. It's under "more" now because I haven't used maps for a while. But at least I can pretend to be on a phone even though I've got 1680 horizontal pixels. I always wanted the imaginary creatures in my living room to think that I was on a cool new tiny phone with a tiny little screen, instead of a boring old laptop driving an external display.

Uh, systemd works just fine on Gentoo, though openrc comes pre-installed at this point.

SystemD works just fine on Gentoo whether you use Gnome 3 or not. It is just a required dependency if you run Gnome 3 since that is the direction Gnome is moving in.

As long as people take care of OpenRC I'm sure that will always be an option. I wouldn't be surprised if at some point the install tarballs stop bundling sysvinit/openrc - much as they do not bundle cron, syslog, or even a kernel, leaving the choice of what sysvinit to install up to the user.

This suffers a bit from the "everybody in the world would agree with me if they only understood everything as well as I do" school of thought...

It is entirely possible that they understand the counter-arguments, but simply do not agree with them.

Systemd supports both:
1. Running as PID 1 in a container using a separate process namespace (which is at least as good as running in a chroot).
2. Running as non-root - you can use it to manage your own services under your own uid.

What are you going to be tracing in the init system anyway?

And if you want to stop a container, snapshot it, and restart it, you would definitely prefer that this operation takes place in about 100ms and not in 30 seconds. PID 1 doesn't just run after disks spin up and the POST completes.

You missed a bunch of other features, like native support for namespaces/containers, or not leaving orphans lying around when a service stops, which would certainly be interest to somebody running a server.

Uh, tell me how to adjust an init.d script such that:
1. You add support for running the daemon with an ionice level which was missing from the original script.
AND
2. The next distro upgrade won't blow your changes away, and you won't have to manually re-combine your changes with their new init script which adds some new feature yours lacks?

With systemd you just stick a drop-in in /etc and it will only override that one setting in the default unit - and there is no file collision. That's the beauty of declarative programming.

Gentoo already supports systemd - that webpage is a year old and wasn't a great comparison at the time it was created (and systemd was already available on Gentoo back then). SystemD on Gentoo is old news already - about the only thing left is to strip sysvinit out of the default install and have use user pick whatever implementation they prefer (much as they already pick kernels, cron, syslog, etc implementations). The whole point of Gentoo is to try to leave the choice up to the user and at this point you'd be hard-pressed to find software on Gentoo that doesn't work about as well on both OpenRC and SystemD.

Just install the "Classic Theme Restorer" add-on and Firefox is as usable as it was before.

That is why I am still on 12.17. Works well and does get security updates occasionally. For the very few pages that do not work, I can always use FF.

What kinds of morons use IE, regardless of version? Masochists? Or is this some subtle form of "I am dumb and proud about it!"-movement?

I want to search, as long as that works (and Google has not very good search anyways, just the largest database), I don't care one bit.