On 10/17/18 9:08 AM, Antony Stone wrote:
> On Wednesday 17 October 2018 at 15:54:11, Daniel Taylor wrote:
>
>> I am becoming convinced that the proper course of attack is to reimplement
>> all the systemd functions in the Unix paradigm.
> a) I seriously doubt that that is possible, without effectively just re-writing
> systemd
Well, yes, that's exactly what it would take.
> b) systemd's goalposts also move sufficiently fast that it would also be a
> constant game of catch-up
Nope. Just have to implement what developers are using that isn't
already provided by existing programs.

This becomes practical as systemd already has enough penetration for
installed base to provide resistance.

>
> c) where and how would you draw the line indicating what's unacceptable about
> systemd - in other words, what exactly do you mean by "the Unix paradigm" in
> your comment above?
Split out the PID 1 stuff to just the bare minimum of what needs to be
there, organize everything else into appropriate units.

This is not a trivial project, which is why nobody has taken it on
AFAIK, but systemd must be doing something that package maintainers and
developers want. That suggests that the way to beat them is to do that,
only better.
>
>> Too many developers are embracing systemd and it's getting harder to keep a
>> functional Linux system without it.
> True, but reimplementing it in some other way sounds to me as though you're
> going to end up with the functionality we despise, just created with different
> code?
By splitting it up we can make the parts modular, so someone can have
sysvinit startup script handling or systemd modules.
The systemd stub libraries are a starting point. We can, in theory, rip
the whole damn thing apart so that sysadmins have more control of which
parts they use.

In particular, being able to toss the damn broken logging in the bit
bucket while keeping utility functions used by programs we need to use.
>
>> Sometimes the only way out is through.
> Yes, but surely not to the same destination as the entire Devuan project is
> trying to avoid?
>
>
Very much not to that destination. In particular I'm thinking that
having a fully functional set of utility functions so that we can save
work modifying packages that depend on systemd.

libaltd PROVIDES=systemd

--
Daniel Taylor