> On 22 Aug 2023, at 01:14, Enrico Weigelt, metux IT consult <info@???> wrote:
>
> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Have you seen s6-frontend? That will be a good choice to standardise on when it’s finished.

https://skarnet.com/projects/s6/frontend/index.html

Tom