On Thu, 2 Jun 2016 12:53:55 +0200
Jaromil <jaromil@???> wrote:


> however I'd really recommend to sit down a bit and watch OpenRC as it
> seems to me the best candidate to follow up sysvinit.

My opinion is quite the opposite. OpenRC is, in my opinion, pretty
similar to sysvinit. Both use "init scripts" that can grow huge and
unfathomable. I've heard that OpenRC has some kind of parallel-foo, but
for most use cases you don't care whether you boot in 2 seconds or 30
second. If OpenRC can respawn at all (without addition of
daemontools-encore or equivalent), the way to do that is severely
underdocumented.

If I were going to switch away from sysvinit, I'd do it only if the new
system were a huge improvement. I see sysvinit and OpenRC as very
similar: No need to switch from one to the other.

> One thing I
> cannot find mentioned in the soy thread is that the init system should
> be 100% compatible with existing sysvinit scripts and OpenRC seems to
> achieve that with well written and well documented code,

I think that any new init system should be 100% INcompatible with
existing sysvinit scripts. Existing sysvinit scripts are the spawn of
the devil, and provided lots of cover for the systemd fans to say
"systemd is better than sysvinit."

My opinion: If the init specification of a daemon exceeds 25 lines,
that's a problem. Many sysvinit and OpenRC daemon init specifications
are over 100 lines, especially if you take into account all the stuff
imported from the "functions" file. I never want one of those long
files darkening my door again. That's why I switched to Runit, where
most of my run scripts are less than 10 lines long, and understandable
by anyone.

Anything resembling sysvinit init scripts must die.

Another opinion: The original Epoch init system that Subsentient
criticized and now wants to make parallel is arguably the best init
system, and I wish I'd given him that feedback. First, process startup
was sequential, and in most use cases that turns out to be the best.
Screw parallelism. You *know* sequential is going to work.

Second, Epoch's process config sections are tiny: Almost always less
than 10 lines.

Third, other than the new s6-rc and systemd, Epoch was the *only* init
system that could easily and natively intermix long-run and run-once
processes.

Fourth, now that systemd exists, we can exploit systemd to
programmatically create Epoch config sections. systemd unit files
contain info which is close to a 1 to 1 correspondence with what's in
Epoch configuration units. Systemd's after this and before that and
depends on this and provides that can all be programmatically be
converted into a boot order. The resulting confs could be given to the
upstreams, or a Devuan Epoch maintainer could just test them all. And
of course in 2016 there's no shortage of systemd unit files.

Fifth, for the person manually installing an init system, Epoch is the
quickest init system to install. It's a couple hours, as opposed to
several hours for runit.

Now I REALLY wish I'd told Subsentient how much I appreciated his
sequential start Epoch. It was one in a million.

SteveT

Steve Litt
May 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21