On Wed, 17 Oct 2018 08:54:11 -0500
Daniel Taylor <random@???> wrote:

> On 10/17/18 8:14 AM, Edward Bartolo wrote:
> > Why doesn't Devuan edit sysvinit to use systemd's unit files instead
> > of scripts? That would bypass the entire problem. Those who want to
> > stick to scripts can always direct sysvinit to use scripts instead.
> > An edit/patch would aim to make sysvinit recognise unit files and
> > run scripts when instructed to.
> >
> > Before I get a barrage of smart-ass replies like 'You do not
> > understand', yes, I know, it is EASIER SAID than DONE. Everything
> > technical is like that, unfortunately.
>
> Well, it _is_ a non-trivial project.
>
> The way things are going I am becoming convinced that the proper
> course of attack is to reimplement all the systemd functions in the
> Unix paradigm. Too many developers are embracing systemd and it's
> getting harder to keep a functional Linux system without it.

I'm not reproducing your results of functional Linux difficulties. I've
heard udev will now deliberately sabotage systems not using systemd as
PID1, but don't we have vdev and eudev? I'm personally running the
runit init system, and so far it works perfectly with every daemon
except the very, very few that provide no way to run the program in the
foreground. Your assertion gets traction on Gnome, and to a lesser
extent KDE and xfce. But there are so many good WM/DEs (Window
Manager/Desktop Environment) that foregoing those three WM/DEs is no
problem at all.

About reimplementing the systemd functions: Most of them are either
marketing buzz or attempts to make systemd irreplaceable. How often do
you use "socket activation?" What's wrong with xinetd if you still want
to use that ancient paradigm left over from when you had to count every
byte and process?

Multiseating? When's the last time you had serial cables to monitors?
We have much more efficient Gigabit Eternet.

Cgroups? There are other ways to do Cgroups without systemd, and a lot
of systemd's buzz for using cgroups is available in runit, which has
the finish script to clean up, and the finish script for process A can
stop process b, c and d if that's desired. There's almost nothing
*needed* that systemd can do that runit can't do, except lock your OS
in a "no replaceable parts shield.

Fast boot? Unless the system is a television or a container that's
constantly going up and down, who cares? Besides, s6 offers parallel
startup, so it can produce pretty darn fast boots.

The systemd standard for daemons reporting their "upness"? Runit and s6
enable you to make the test of your choice to determine another
daemon's functionality, without relying on what's returned from the
other daemon (which may be wrong).

>
> Sometimes the only way out is through.
>

And sometimes you're already in the right place, and the best move is
nothing. Systemd is nowhere near a done deal. Right now, on the
Debian-User mailing list, Debianers are discussing various ways to keep
using Debian with sysvinit, and some are even considering additional
init systems beyond the false choice of systemd vs sysvinit.

SteveT

Steve Litt
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz