On 15.06.24 12:17, Peter Duffy wrote:

Hi,

> I guess the trouble is that people with an agenda (hidden or otherwise)
> won't listen to rational arguments.
>
> For me, it all boils down (and has always boiled down) to a single
> question. Why is systemd not optional?

That's a bit too vague, IMHO. We should be asking, what exactly shall
be optional from what, under which cirumstances ? What exactly makes it
non-optional right now ?
(continuing below ...)

This somewhat reminds me on the "independent" central banks. Independing
from whom exactly ? (certianly, from the voters and taxpayers - let that
sink in)

> It always starts me thinking about the rollout of communism in Russia
> in the early part of the 20th century. "Here's this wonderful new way
> of ordering and managing society. In fact, we think it's so wonderful
> that we won't give you the option of using anything else. If you don't
> like it, go and live somewhere else." (And we all know how that went.)

Indeed. That's a pattern we're seeing in all modern history. Even recent
years, where people were pushed to ridiculous things like putting a
cleaning rag in their mouth (scientifically proven that it doesn't help
anything against virus spreading) or becoming guinea pigs in for mass
scale genetic experiments, etc. Or totally insane religions declaring
the plant's breathing gas as "poising" (and practically declaring
breathing as poisoning act).

> I keep wondering about the possibility of forking systemd and re-
> engineering it to make it optional - so that it could be routinely
> replaced with other init systems, as the user wished.

While that might be easily replacable by other init systems, would it
that also work for replacing systemd ?

Continuing from above: the real question to ask is *what* exactly
creates the vendor lockin here. IMHO, one of the biggest problem is
other packages depending on certain features, eg. libsystemd0.

What we could do here: recognizing there is some value in having some
common interface for services talking to the supervisor (whichever one
it is) and design one that can be easily implemented by any supervisor
(and we probably had to do the actual coding).

If some people seriously going to do this, I'd be the first to join in
and make my hands dirty. But for me alone, this really isn't important
enough to invest lots of time into that - instead just patching out
systemd dependencies whenever they're crossing my ways.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@??? -- +49-151-27565287