Comment by danudey
3 months ago
> Looking forward to reimplementations and/or shims which provide the Systemd API but are reimplementations.
We've seen the launch of GNU's systemd equivalent, which seems to introduce more complexity to the simplest levels and is more difficult for users to understand and configure. Given that every service file is its own erlang program/DSL/whatever, understanding erlang is critical to being able to write or reason about service files.
In essence, it seems to be trying to re-implement what systemd does, but badly.
Reimplementing systemd's API but using other discrete components would also be a bad idea. The biggest reason systemd took off is that it's all the tools a system needs, built in a way that they work well together and can be interacted with and configured consistently. Providing systemd-compatible replacement shim APIs would mean trying to tie a dozen (or more) discrete OSS projects, each with their own philosophies, developers, licenses, goals, etc. together, generating their config files consistently, and trying to mush all that together in a way that doesn't make things vastly more complex than what systemd already provides.
In short: the reason systemd is successful is that it got rid of a giant mess of unrelated or overlapping services and replaced it with something simple, coherent, and functional, built out of components that you can (in most cases) choose to use or not. Most people who hate systemd seem to hate it for largely ideological reasons ("it's too big!") and are more interested in solving those ideological problems at the expense of practical solutions to real user issues. I've yet to see someone argue against systemd because it's bad for end users; only because they don't like the way that it provides benefits for users.
It could mean that, but it could start much simpler. Instead of trying to implement the whole API surface and behaviour, focus on a single consumer i.e. a single program which today depends on systemd.
Shim out enough for it to at least run in some capacity on something which does not have systemd.
Go from there.
Do you have examples of what you suggest, 'a single program which today depends on systemd' which would make sense to decouple from systemd?
The amount of work that a project would require over the long-term would be pretty substantial, so I assume that there are a lot of these things which you would suggest fixing over time to be rid of systemd, but I'm not certain what the end benefit of this work would be. Interested to hear more.
Gentoo has a little list¹, along with suggestions for modifications. Instead of modifying the programs, one could experiment with a shim library and leave the program code unmodified to see if that's a viable path towards portability. The end benefit would be portability to systems lacking systemd proper.
(Now, the importance of portability is a separate question. If you want systemd to "eat the world" it's even a negative value.)
1: https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
1 reply →
You'll find that there are very few such programs. This shouldn't be all that surprising, because most programs do not care what process started them or where stdout is logged.
The most prominent dependency on systemd components is Gnome on logind, which already has a shim.
Go for it!
I might, but I have way more opinions on various topics than stamina to do something about all of them, I'm afraid. :-)