On 28.07.23 14:33, Federico via Dng wrote:

> Aside from the huge effect it would have through IT policy legislation,
> for average users like me who handle libre software but are zero level
> in programming and use, how can the invitation to use Devuan be spread?
> What more can be done? Are there any chances? Thank you in advance for
> your gentle reply,

IMHO we should start solving one of the underlying technical problems:

1. Service management (whether init scripts or unit files) still is a
    major problem for upstreams, distros and operators. There's also a
    strong tendency of upstreams wanting to provide some sane defaults
    for service startups, or even don't like distros doing any teaks
    here. Just had that topic w/ containerd folks, few days ago.

    https://github.com/containerd/containerd/pull/8924

    Systemd indeed has a good point here, since it's quite uniform on all
    systemd-based distros, so it's easy for upstreams providing unit
    files.

2. Status reporting: some services indeed have good reasons for wanting
    to report back some ready state to the supervisor. We're yet lacking
    an standard protocol for that, so upstreams just using sd_notify().

    Same for cases where listen sockets shall be opened by the supervisor
    and passed to the daemon. The idea itself isn't bad at all. We're
    just lacking a sane standard interface, that's trivial to implement
    for any supervisor

3. Most upstreams are understaffed and lacking deeper knowledge on the
    whole topic, so they just don't know anything better than using
    systemd legacy. Ergo: we need to help them by providing patches.

    In recent days, I've mainlined several patches to containerd, incl.
    fully systemd free build flag. And I'll continue so for the layers
    above (eg. mobdy, k8s, ...)

Bottom line: just advocating yet another distros (that's what devuan is
in the eyes of most people out there) won't help. And just telling
"don't use any systemd stuff" neither. They just lacking the background
for understanding what's the problem in the first place, and systemd
indeed solves several problems *for them*.

So, what we really should do is providing *good* and *generic* solutions
of these practical problems, that don't create any vendor lock-in's,
like systemd does.


--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