Well, that's one quick way to win a few people over.
Among future items: Versions based on ReactOS, Minix3, Plan 9, and GNU/kFreeBSD
Really intriguing, but how many people have you got working on this?
Well, that's one quick way to win a few people over.
Among future items: Versions based on ReactOS, Minix3, Plan 9, and GNU/kFreeBSD
Really intriguing, but how many people have you got working on this?
As an example of the most basic improvements over classic init, here's a paper from 2001 from OpenBSD about dependency-based init with no runlevels: https://www.usenix.org/legacy/event/usenix01/freenix01/full_...
Since this is Debian-based, does "classic init" in this context mean they're using insserv? That's definitely not "classic," but it's definitely a better option IMO. If so, are they interested in helping out with maintaining insserv in Debian? It hasn't seen a maintainer upload for almost five years, and help is requested: https://bugs.debian.org/834284
The only folks I hear talking about One True Init (which will also take over completely unrelated functions, poorly) are the systemd folks.
Also, it sounds like you're unaware of the distinction, but the BSDs have never had sysvinit-style runlevels. You can kinda hack them in if you like, but there's no native notion of runlevel; you get single-user or multi-user.
With sysv, it was relatively easy to slot in a different init as the admin wanted.
A distro i have used for some time, Gobolinux, may use the sysv init binary for example. But it forgoes the usual sysv layout for one more akin to just a rc.local.
But with systemd it is systemd, and only systemd, because systemd is so "invasive".
And the real worry is when third party developers assume systemd as the default and make it hard, or resist, supporting alternatives.
Is it going to be a net gain or net loss?
(In Debian 8, systemd was made the default init system.)
It is surprising that this list does not include HURD though!
> Future Plans
> Versions based on ReactOS, Minix3, Plan 9, and GNU/kFreeBSD