Comment by actionfromafar
3 months ago
Exactly, for some values of "good enough". (Unfortunately IMNSHO) Systemd cannot be toppled by all-out assault. It must be subverted. Looking forward to reimplementations and/or shims which provide the Systemd API but are reimplementations.
Something like Wine, where in the analogy systemd is the Microsoft Win32 API and we want to be able to run systemd "enabled" software on something else. Or at least re-compile it.
Wine also started with an incredible amount of stubs which did nothing, but that was often enough for many programs to work anyway.
> 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.
2 replies →
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!
1 reply →
Yeah. Exactly. It's also how Wayland and Pipewire managed to win: by being backwards compatible with X and Pulseaudio, while also overcoming their shortcomings.
The problem is that if the only complaint with systemd is that it's too complex, any backwards compatible alternative will necessarily be as complex as systemd + the new thing (at least in terms of complexity of interface).
If there are actual technical deficiencies of systemd, then sure, maybe such a backwards compatible alternative might be in order.
Also, everything expands in time. Wine may have started out with many stubs, but now we're at the point of implementing Windows-y APIs in the kernel with the sole goal of improving wine performance (NTSYNC).
> The problem is that if the only complaint with systemd is that it's too complex
As I understand it, that isn't the only, nor even the main, complaint with systemd. On the contrary, the main complaint with systemd is that, like strangler vine (kudzu?), it's spreading everywhere, taking over functions that it originally had nothing to do with, and forcing ever more unrelated things to adapt to systemd -- thereby making them much less portable away from systemd; to something that doesn't use it.
It's like the old debate about "BTW, you should call it GNU/Linux, because..." is sooo yesterday: Nowadays it's systemd/Linux -- and well on its way to becoming systemd-OS, with the kernel a mere afterthought, soon to be if not replaced at least easily replacable. Sure, that may not bother you or most systemd fans, but one can't help wonder: Do you even realise that this is what you're condoning, or even actively advocating? Maybe it would bother you, if you realised it.
(Also, the whole "strangler vine" thing, when deliberately applied, used to have a name: "Embrace, Extend, Extinguish". Now, I can't really swear that it is being deliberately applied here... But do we really dare to blithely assume it's just a coincidence that the creator of systemd so naturally found a home at the company the expression was coined for?)
Subversion is key. Remember when "performance" was the key reason for moving to systemd (scripts are sooo slow). To subvert, you need some lever and the chink in the armor to break in.