If the problem is that your employer has required you to only use packages supported by some vendor, that's a different problem and it extends to a lot of other things besides systemd. For some perspective you might want to go talk to some people who still have to use COBOL at work...
> Between Red Hat's maneuvering and Poettering's choices, though, it's not trivial to avoid them.
I'm just explaining why some people dislike Poettering's work, while typically having no strong opinions about the careers of every single other author of init and sound daemons, whether or not they like the software. It's a combo of 1) disagreeing with their choices and methods, and 2) the fact that those choices and methods have made his stuff much harder to avoid than the alternatives. That is why people don't like him (and, indeed, probably the main reason so many people know his name at all)
That doesn't follow unless you consider "developing a software that becomes popular" to be a method or a choice. Again, I don't know what you expect them to do or what other choice you expect them to make. Should they have suddenly quit once it was clear that it was going to become popular? What good would something like that do?
>That is why people don't like him (and, indeed, probably the main reason so many people know his name at all)
This also doesn't follow, it doesn't make sense and is extremely unprofessional. It isn't good for anyone's mental health to hold grudges like this. In order to attempt to have an unbiased view, you have to be able to separate the work from the person. Though I realize asking for this is probably an unwinnable battle in open source. Now that he doesn't work for Red Hat anymore it will be interesting to see people keep trying to blame both him and Red Hat for this.
THIS doesn't make sense unless you consider that to be the only thing that happened.
If it had been, this story would never have made HN in the first place.
Sure, noone will be as angry at a Paint-clone’s maintainer because, well just use something else. But it is not trivial in case of non-trivial problems like booting and audio, both requiring some standard IPC communication besides the inherent complexity of the program itself.
It is actually very hard to say in reality whether some other product would have been better.
The more users software has, more issues there will be. If there is ”de facto” way to play audio, all conversation focues on this ”de facto” way. It has been also kinda first of its kind in this scale. PipeWire might work well now, but they had excellent example what to not do or how to do otherwise.
Personally I'm happy with systemd these days - it has a steep learning curve but once you get how to write them and how dependency ordering works, it's just a breeze.
If there is one thing the Linux ecoysystem desperately needs if it ever wants to be a serious challenger on the desktop, it's standardization for software vendors... and slowly but surely, life gets easier, in no small part thanks to systemd.