I don't understand where anyone is getting this impression from, that describes the opposite of my experience with systemd. The authors publish stability guarantees, and they have done so for several years: https://systemd.io/PORTABILITY_AND_STABILITY/
But for some reason, the authors occasionally say something that feels completely out of place for the project. They fix important stuff eventually, but sometimes it gets confusing to watch them discuss it.
The "Invalid username runs a service as root" bug is a good example of something that they didn't seem to take seriously. But it's fixed now.
Also, PulseAudio. Pulse is good. It's not that great and was deployed before it's ready on some distros. The whole Pulse/Jack split that is only just now being fixed was annoying.
Some people might still judge Poettering based on 10yo bugs in Pulse rollout?
I think the duct tape and string feeling comes from the obsession with smallness and modularity and people trying to make "Linux not be like windows".
Half the FOSS scene WANTS things to be taped together because their main thing is random tinkering.
Again, I didn't want my comment to start a heated discussion about systemd, but inevitably that happens. If I had praised it someone else would have come along to tell me how much it sucks (I don't think it sucks, personally, I just have issues with its current development process).
https://bugs.freedesktop.org/show_bug.cgi?id=76935#c10
----- Adding "hacks" but not testing to ensure said hacks don't cause issues:
Lennart Poettering 2014-02-21 13:49:25 UTC
To make this work we'd need a patch, as nobody of us tests this.
Comment 3 Michael Shigorin 2014-04-04 06:30:57 UTC
Hope all of you either test all the combinations or do not break at will those you don't have the time and inclination to test, at least in system-wide components that are not specific to systemd, while pushing the latter hard.
Comment 4 Lennart Poettering 2014-04-04 14:56:43 UTC
Well, cgroups-less kernels are explicitly not supported by systemd. However we added some hacks to allow it to boot to a certain degree even if a lot of things will not work correctly afterwards. In this mode when you boot you will actually get a warning on screen and bootup is delayed by 10s to make sure the user understands this.
Now, this mode recently broke, and it will segfault early on. I am happy to take a patch to 'fix' this again, but I will not work on this as i dont run kernels like this, and as mentioned its not really supported anyway...
Another option is to simply be honest amd stop supporting in entirely, and refuse booting completely. And I figure this is what I will eventually do if nobody cares enough to send me a patch to fix that segfault.
This is why I don't like to talk about systemd on any internet forum; it always leads to people like you ready to attack any position around the subject, and me having to defend a position I don't even hold (I don't think systemd sucks, I think its developers could do better though). I am done with this thread.
The core dependency principles around targets, services and startup does not see a lot of change, so this concern is not really realistic. You'll see more of this around the supporting utilities (networkd, resolved, and so on).
In fairness, quite often I've found this is often a case of exposing existing brokenness rather than creating new problems, but it doesn't make it any more comfortable when it happens.
Hopefully this guide will stay up to date given the "move fast, break things, wontfix" approach the systemd authors currently have with the project.