I know about uselessd - I suspect that it was reading about it that
planted the seed for the "init-wrapper" idea - that of limiting
systemd's power without systemd even being aware that it was being
limited.

I've not got far in thinking this through in terms of details - I
assumed that it would be impossible to implement in a practical sense,
and anyway the idea was just too crazy to be taken seriously. If I did
contemplate doing it, first thoughts would be on the lines of modified
libraries which would pre-empt existing ones.

I agree that the value of this would increase substantially if the
abstraction/glue layer was viewed as a general init system
monitoring/controlling/auditing facility - it did occur to me that it
would be a way of distilling out the best of all the init systems to
which it was exposed.

Just supposing that this led anywhere, I certainly wouldn't propose
proactively keeping the systemd team updated re. progress. Obviously,
given that it would presumably be an open-source project, they'll find
out anyway - but if they can't see the obvious win-win from making
systemd optional, they're not going to see the benefits of a project
which could conceivably control and limit systemd's power and influence
(both in terms of individual systems and the linux community as a
whole).

Thinking about systemd, and choosing whether to do what it asked and
what to report back, the image which kept coming to mind (can't imagine
why ;) ) was that of a convicted gangster controlling the mob from a
prison cell - but he or she is completely at the mercy of feedback
received, and has no way of knowing what is actually taking place.
(There's a brilliant moment in "The Taking of Pelham 123". They're
trying to get the money to the subway station before any more hostages
get shot, and aren't going to make the deadline. Garber, the train
dispatcher, suddenly realises that the crooks can't know what's
happening on the surface, and tells them that the money's arrived before
it actually does.)

On Thu, 2020-05-21 at 14:09 -0400, Steve Litt wrote:
> On Thu, 21 May 2020 10:59:15 +0100
> Peter Duffy <peter@???> wrote:
>
> > I think that the thing that I found tantalising was the idea of
> > sniffing what systemd tried to do, and then deciding whether or not
> > to do it,
>
> Many have tried this. Web search "uselessd".
>
> But your suggestion becomes much more valuable if expressed as
> "sniffing what each init system tried to do, and then deciding whether
> or not to do it".
>
> * Busybox init
> * Epoch
> * OpenRC
> * Runit
> * s6 (plus s6-rc)
> * Suckess init plus [daemontools | runit | s6]
> * systemd
> * sysvinit
>
> > and what responses to send back to systemd.
>
> If you mean the daemon reports back to the process supervisor success
> or failure, s6 has that now, in a much simpler form than systemd's
> dbus-centered bizarro. And such reporting isn't all that necessary
> because the admin can roll his own tests.
>
> If you mean do this research and report the research results back to
> the systemd project, I'm not interested in helping systemd, and systemd
> isn't interested in anything making them more interoperative.
>
> SteveT
>

> Steve Litt 
> May 2020 featured book: Troubleshooting Techniques
>      of the Successful Technologist
> http://www.troubleshooters.com/techniques
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng