Personally I haven’t. While Linux is imperfect, choosing the right distro makes the rest of the experience straightforward. And with it’s whole complexity, I find Linux more user friendly than Windows. Even driver issues, broken shadow file ownership and KDE specifics only made me more confident about my choice to use Linux after I solved everything.
Honestly, what’s disappointing about sysd? I know it violates the whole does one thing principle and then the whole age bs, but overall I’ve never had anything major with it
Since “do one thing principle” is pretty abstract, I’ll give you one example of a downstream consequence.
I wanted to set up a NixOS microVM using docker sbx. Turns out, it was basically impossible (nothing is actually impossible, it just depends how much you want to modify/rebuild things).
Much of NixOS depends on systemd to manage lifecycles of this or that, but systemd only works properly if it’s the first PID, and when it runs in that mode it also wants to initialize hardware.
But the hardware is all managed by the microVM, so systemd blows up. All it needs to do is nothing, but that turns out to be very difficult to achieve.
If these were like 3 or 4 distinct utilities, there would be obvious seams where I could separate them and only activate the stuff that’s relevant to my use case. But it’s all one big ball of mud.
True, but Linux devs only have a limited amount of time. It’s far easier to take a system that can handle server-farm complexity and apply it to a single user use case, than it is to take a system meant for single users and try to scale it up to a server farm, or to maintain two separate systems.
I’m saying that complexity could easily be modularized inside SysV init, not requiring a restructuring of things like “logfiles are no longer files in /var/log”
That phrase has proven to be a source of endless headaches any time someone in charge is stupid enough to believe the person that tries to sell them that.
Systemd (along with the various add-on services that come with it on most major distros) meddles with and tends to break critical functionality quite often, except on boring systems where the needs being served happen to be handled well by systemd’s happy path(s).
If the computers you maintain fit Lennart Poettering’s idea of how to do things, then you might never notice a problem. On the other hand, if you’re responsible for systems with unusual or complex configurations, or have need of the flexibility that makes unix so very useful in the first place, then you might very well discover that systemd is a pushy, invasive, poorly considered, buggy, and in some ways just pain broken collection of software, maintained with a level of arrogance and carelessness not often matched in the unix community, and you might rightly come to despise working with it.
Sadly, my experience has been the latter. In the years since the systemd suite was adopted by Debian distros, I have been burned more times by it and spent more weeks of my life troubleshooting it than I can count any more. Because of this, I have come to resent systemd. And I know I’m not alone in this.
So, dear readers, when you see people complaining about systemd, please try not to be like the zealots out there who routinely cry “luddite” and demand proof when they encounter folks who dislike it. Try instead to remember that one size does not fit all, that some of systemd’s detractors are very skilled and reasonable people who happen to run systems that are necessarily different from your own, and have encountered problems that you have not. It has been over a decade. Some of us are tired of it, and tired of talking about it.