PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat (opens in new tab)

This is, fundamentally, a gross misunderstanding or misrepresentation of the way that open source works in general, and of the way Red Hat-employed developers in particular interacted with the ecosystem.

I was in the engineering side in various positions for nearly a decade. The policy was upstream first. Open source first. If you think that the engineers at Red Hat didn't care about open source, or that anyone WANTED to invest god knows how many man hours into trying to create a sane experience from scratch, you're badly mistaken.

Pulse was optional in gnome-settings-dameon for a long time, and the primary reason it's deeply integrated now is because people LIKED IT (the horror!), since it finally solved a bunch of problems with Linux audio, and the dbus backend made stuff like "media keys work out of the box" seamless.

Similarly, GNOME has a dominant place in the market because... people liked it. It's market competition. GNOME had/has a place in Red Hat as the de-facto user experience for Fedora, and Fedora's principal role is user experience testing/feedback for the next version of RHEL, at all levels of the system, but the number of users who are gonna run Fedora without a shell is low.

Principally, a lot of Red Hat's engineers ran (and probably run) Fedora as a development workstation, though there was a fair amount of Gentoo, Arch, Slack, and others.

The only reason why there's a perception that "non-Red Hat stakeholders didn't matter" is because the vast majority of community users weren't submitting patches, and the other big vendors (SuSE, Canonical) were working on other DEs (KDE, Unity) which only shared parts. EndlessOS and other projects were GNOME because... it worked.

Pulse and systemd came into being because better solutions did not, despite a bunch of effort. I've used Linux since the 90s. ALSA was better than OSS, but it had enough thorny edges that JACK still had to be a thing (and still is, for audio engineering). Pipewire is an iterative improvement on Pulse. Audio will never be done.

OpenRC, Upstart, sysvinit, runit, and others were all terrible in various ways. The sheer existence of stuff like supervisord speaks to the existence of that. If I'm going to bet, it's always safe that whatever "booo systemd" person I'm speaking with has never actually had to maintain, troubleshoot, add features to, or otherwise work with pre-systemd init systems in any meaningful way.

Red Hat's business is consulting (or at least that's what "platform" is, discounting OpenShift, but "platform" had been stagnant in revenue for a bit, which precipitated the buyout). It is not selling Linux. It is getting paid to help companies make Linux work for them so they can save money in other places.

It is in writing features which make Linux better because some customer needs/wants it and has a bag of money, but not the in-house expertise to write it.

It is not desktop Linux, and it hasn't been since RHEL3 (or maybe before that). Any argument predicated on that is built on quicksand. Don't make a Texas sharpshooter fallacy.

You have (had) a bunch of very smart people who were very passionate about open source working in Linux every day, at a company with an "upstream-first" policy. They were actively working with/against desktop Linux user experience at airports, at home, on newer laptops, trying to get on Bluejeans calls, etc. It should not be surprising that they also saw problems and wrote solutions, which the gratis marketplace liked enough that they have widespread adoption.

You can personally dislike those technologies, but condemning their existence is just a different way of saying "I don't like open source when ideas I don't like succeed".

What we really need is for people to propose alternatives to systemD that address its purported use cases while removing some of the needless complexity it introduces, and restoring the primacy of general mechanisms over hacked-together policy. This has happened with some components, e.g. elogind but not really as a comprehensive effort.

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.

Funny how his detractors spend more time on jokes than on shipping a better init daemon.

I also use hyperbole as a rhetoric instrument but in text seldom works.

End of story.

People getting mad because they are "forced" to use a free software system? That's the fan-fiction from the peanut gallery.

My recollections of Linux audio issues are more from the days when one thing might want to use OSS and another ALSA and you might have to fiddle around and enable software mixing in some ALSA configuration files to get non-exclusive sound to work. And then some issues right around when Pulse first started to be a thing. But really it's been a "Just Works" for me for years and years.

Yeah, broken drivers.

You see, before pulseaudio came along, audio drivers were barely used and needed to be tuned for each use case. Most drivers barely implemented ALSA, almost none correctly. If you wanted fancy features (say; software input mixing, so that more than just one application can actually output sound) you needed to invest a lot of time.

By making all these fancy features (and more) more easily available, pulseaudio exposed all these bugs in the drivers.

And of course it got flak for that because the first software layer the user is confronted with is blamed if something's not working.

But actually - just as systemd - pulseaudio is a marvelous piece of code. That today we can get to an even higher level with PipeWire is to large degrees only possible because of pulseaudio.

Lennart Poettering is one of the most creative and influential system-space developers that Linux has. It's a shame that he's so maltreated by the peanut gallery.

I do remember when PulseAudio seemed to be the source of many problems, but this was over a decade ago.

One of the big problems is that the Linux audio stack is built out of components that rely on assumptions about the next lower level of the stack that are often untrue. You might assume that your audio hardware has a volume control, assume it can perform mixing, assume it doesn't change configuration, assume there's only one user, assume (or want to assume) it has a specific sample rate, etc. PulseAudio papers over this stuff and deals with permissions, so your applications can actually work.

If you have sufficiently boring PC hardware and sufficiently boring use cases, the audio will just kind of work anyway, without PulseAudio.

Linux audio has more than its fair share of problems in the stack, but in my experience, PulseAudio is more of a solver of problems and less of a source of problems.

Have fun routing audio from one stream to one device and another stream to a different device on Windows or macos!

systemd-homed, systemd-nspawn as isolation, and the rest of his ideas aren't being held back because they're controversial, it's because OStree/Atomic "lost" more or less the instant Red Hat purchased CoreOS and they didn't need to build their own de-novo k8s compute distro (parts of OStree lived on in CoreOS and are there as a testbed for immutable images for trusted computing in kiosks/appliances/VDI).

systemd-homed, using systemd-nspawn for management, and the rest go directly against the investments which have been made in [fedora-]toolbox, rootless podman, and flatpak. At the time that I left (~2 years ago), "Openshift is the new platform" was the phrase of the day, which means podman "won".

Red Hat/IBM (via the container toolkit, rootless podman, etc) is/was primarily invested in a growth sector, which desktop/server Linux is/was not, and the Container Development Kit, rootless podman, and the rest are direct mechanisms to get containers sold on k8s and openshift.

Lennart's passion projects are great for Linux, and maybe better ideas than Flatpak and Snap. They don't have a business case inside Redhat, though, and there's only so long that even a principal consulting engineer can essentially spend his time on research projects.

I would guess that he wanted to put more effort into an overhaul of CoreOS/OSTree and try to "unify" it with flatpak somehow to get back to "one Linux" instead of split distros for different cases, didn't get traction, and decided to go somewhere he could work on a passion project.