* On 2016 03 Jun 15:14 -0500, Joel Roth wrote:

> Steve Litt wrote:
> >    Katolaz
> > > IMHO, if and when we would like to make a change regarding init
> > > systems, that change should not be to replace sysvinit with an init
> > > system of *our* choice, but probably towards allowing users to use the
> > > non-invasive init of *their* choice.

> >
> > Yes. The user should have an easy choice of inits. What I meant was
> > that SOME init must be default, and if that default init is ever not
> > sysvinit, it should be something very different from sysvinit.
>
> e.g. something without the complex run levels and symlink farms
> of sysvinit.

I suppose I'm add, but I rather like the run levels and symlinks.
Debian hasn't historically done much with the run levels, leaving that
to the local admin, but once upon a time I put them to use. These days
I find Slackware's init to be more baroque to figure out, not that I've
done so recently.

Regardless, these are complex systems and the complexity must reside
*somewhere*. The debate seems to be whether the complexity should
reside in C source and a runtime binary file or in a shell script or in
some combination of the two. Personally, as a desktop user, I've not
needed to work with the sysvinit startup scripts in /etc/init.d/ except
to start, stop, or restart a process. I really am quite ambivalent
about the whole init debate. I've simply been turned off by the
politics employed to support systemd and the voracious appetite of its
developers to "obsolete" perfectly good projects that never asked for
obsolescence. I like a serial startup sequence as it's understandable
to me. I won't likely switch just for parallel startup.

- Nate

--

"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us