systemd has been out for so long that I'm pretty sure we can judge it by its own merits now. As someone who maintains a few thousand servers but only uses desktop Linux on one non-primary machine, I have a lot more well-informed opinions on the trustworthiness and stability of systemd than of PulseAudio.
(And besides, my recent experience of PulseAudio has been that it's fine, and IIRC in the late '00s the primary problem with PulseAudio was that Ubuntu ran it in a non-recommended mode. I haven't actually had any problems with it recently, it just works.)
It seems like the discussion would be more informative and less flamey if we talked about systemd itself. If the team is untrustworthy, there should be numerous examples of that about systemd itself by now.
IME talking with our sysadmins face-to-face, I think a lot of the initial hostility was caused by emotional reactions like: This is different, I don't like it! (Don't get me wrong, it's a behavioral pattern that makes sense up to a point.). I think everybody I've spoken to actually ends up appreciating a lot of things about systemd. (But in these situations, I happened to be their employer, so that definitely biases the conversation even if these conversations weren't really about anything related to their job situation, specifically.)
I also get the impression that a big part of this is due to a lack of 'patterns' or easy recipes to get as much info as possible from the journal. Everybody can intuit the workings and benefits of a text file, but text files have drawbacks that are very subtle and hard to intuit at a visceral level. I think this is partially a lack of good defaults for journalctl. I think it would be better if it (by default) showed much more information and allowed users to turn off unwanted info.
Pulseaudio is definitely better at what it does than ALSA, it is not a step backwards.
My main gripe with anything from that group of people is that they refuse to play nice with others, and by extension that their code refuses to work properly with code produced by others.
[1]: https://wiki.archlinux.org/index.php/Firefox#Multimedia_play...
Pulseaudio is in the same park as SystemD today. It works as long as you don't demand too much of it and don't stray from whatever they deem to be The True Path. It is better for your simple needs. Believe me, those who have advanced professional needs don't think highly of it.
The support for this systems come from people that just use it as packaged and don't have specific needs. Which would be fine IF they weren't getting in the way when you really have specifics needs.
Even if some of the concepts are sound, execution is terrible. As the saying goes, the road to Hell is paved with good intentions.
Can you expand? I've not heard of this.
Systemd developers were like "nobody can tell us how much detail to print", until the kernel developers made clear that the boot console belongs to them and if systemd doesn't back down immediately they would take away all console access. Systemd then backed down.
Sounds like Open Source to me.
[1] Less blog spam, less click bait, better reporting.
Maybe that fits RedHat's business model.
I would challange anybody, to introduce a totally new system layer on linux with less issues.
And Pulse Audio was started by Pottering but he quickly moved on and since then it literally has nothing to do with the people who work on systemd. Blaiming him for the persistence of issues with Pulse is simply unfair and would be done if he was not called Lennart Poettering.
I am not a fan of Poettering's code or his attitude, but people have treated him exceptionally badly. He's just doing his job. If these projects were allowed to compete for mind share fairly there would be no problem. If Red Hat had made sure that Gnome could work with alternatives then there would be no problem. Pulse audio would have died a rightful death. Systemd? I suspect that it would still have succeeded.
Agreed. This is Red Hat's mentality with a lot of it's product base. Poettering and Dan Walsh come to mind with regard to the elitist attitude in their respective corners. But just wait, this is going to get worse. Now that IBM owns them they will push this agenda even harder. The new game is controlling a majority of devs in well-known or strategic projects so the overarching enterprise can push an agenda. I don't think we're seeing the teeth quite yet, but give IBM a few years and my guess is it becomes very obvious.
Don't forget Drapper
That's exactly the problem, though. You don't want all that stuff in your privileged PID 1 process. Nor blowing up your prod servers and getting in your way to even examine log files afterwards.
Which is pretty much what I blame him for.
He has a history of starting ambitious (maybe overly so) projects, doing all the fun stuff until it kinda sorta works, and then riding off into the sunset.
Now that same team is messing with system critical stuff. We know from the kernel command line debug debacle they rather see the world burn down than admit they did something wrong. They are again creating a super-complicated incomprehensible half- documented mess, that puts it tentacles everywhere. But the stakes are a lot higher.
I am not saying they are incompetent. At a low level, the code works. But at a high level, something is very wrong. Bugs can be fixed, but arrogant architecture astronauts not listening to their users, messing with core infrastructure, that's where systemd keeps failing.