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 <pe...@pwduffy.org.uk> 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@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng