Live data from Hacker News

PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

phoronix.com

121–130 of 193 posts

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#121
post #41

Earlier quoted context omitted.

I agree that the comments in this thread are uselessly snarky and uncivil, but Lennart Poettering is not just a single person who wrote software people don't like. PulseAudio has, deservedly or otherwise, been the face of audio issues in desktop Linux for coming on two decades now, and the tumultuous changeover to systemd as very nearly the mandatory init system for Linux left a sour taste for many long-time users.

The biggest problem with systemd is that it broke with so many "established practices" and philosophies of a lot of distributions and iirc it took a while for generators to appear that automagically integrate old-school sysvinit scripts into systemd, meaning an awful lot of work for distributions to recreate unit files with sometimes decades of history buried in the old init scripts. Additionally, its overhaul of log…

I gather that there is a spectrum of views regarding LP, but I'm in the "thanks for making this mess relatively uniform" camp.

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#122
post #61

Earlier quoted context omitted.

Might be worth pondering what Poettering and Red Hat did that make people hate their work so much, and to make Poettering uniquely infamous in the open source world. No-one's upset with the creators of dozens of other init systems and audio daemons, including ones that are pretty bad, and even ones that were promoted by major distro vendors.

I don't see any real evidence people hate their work. Some people do, but it's not like, an overflowing toilet or wet socks that almost everyone hates. I personally wouldn't touch a non-systemd system if I didn't have to. The thing they did to piss people off was breaking with UNIX tradition and not prioritizing simplicity. This makes them hated by enthusiasts, tinkerers, people who don't trust tech, etc, and loved o…

I'm actually strongly in favor of someone coming in and replacing a bunch of the bike-shedding horseshit in Linux with some "no, it's this way, period, live with it" if only to make distributing software for Linux less crazy-making.

I just think Poettering's (and, more generally, Red Hat's) taste is really bad, so I wish it weren't him(/them). Possibly when they finally achieve Systemd/Linux and the entire stack atop the kernel is stuff Red Hat likes & directs it'll all be worth it, I dunno.

FWIW I also haven't much cared for a lot of Ubuntu's attempts to steer the direction of Linux—they've just lost so badly at every attempt, that it hardly matters.

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#123
Here's documentation about the old SysVInit "system" of cobbled together hacks: https://wiki.archlinux.org/title/SysVinit#Writing_rc.d_scrip... Note the missing features, which I would call dealbreakers: - How do I know if a daemon is running? What if you several "copies" of the same daemon, like multiple OpenVPN connections? - How do you test if your cron script runs with the correct environment variables when it runs at 4AM? How can you test it with the same environment that will be set at 4AM, if you can only run it only on the interactive bash shell? - Say you want to change an environment variable from a daemon shipped by your distro. Are you sure you included all " and ' on your arbitrary shell program pretending to be configuration? Can you lint your change or do you just pray, reboot and get an emergency shell? - Freaking dependencies. Parallel startup? Making your webserver automatically wait for the NFS mounts? Make you sshd not wait for NFS mounts? Make sure your sshd starts even if NFS fails, so that you can actually reboot the machine remotely?

Here's how this can be done with SystemD, it's all supported and it works: https://wiki.archlinux.org/title/Systemd#Writing_unit_files

I'm not talking about spherical cows, just basic server administration problems. Don't get me started on laptops...

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#124

Earlier quoted context omitted.

> There's an obvious joke there :p > But I think it's reasonably clear that I wasn't saying they were trying to build a moat around desktop linux, but around those enterprise offerings. One part of that is making their init system the defacto standard. Frankly, no, it was not, or I wouldn't have written that. Those "enterprise offerings" have zero interaction with Pulse outside of some edge cases in SPICE for VDI. Th…

I don't think we're going to reach and real agreements here, a lot of these things are going to be subjective. I think there's a certain amount of "if everyone around you is an asshole maybe you're actually an asshole" but I doubt I'm going to be changing anyone's minds today. That being said there is a bit of hard data, this post nicely shows gnome contributions over time, as less and less non-redhat developer contr…

> I don't think we're going to reach and real agreements here, a lot of these things are going to be subjective. I think there's a certain amount of "if everyone around you is an asshole maybe you're actually an asshole" but I doubt I'm going to be changing anyone's minds today.

I don't think we'll reach any real agreements either, but I also don't think it's all that subjective. We could say my perspective is skewed from being "behind the curtain" for a decade, but it's equally true that I'm dramatically more informed about the economics and realities of open source contributions due to it.

Redhat was (and likely still is) a collection of engineers who are passionate about open source, and get paid to work on it. For a long, long time Redhat paid below the market average. It was not a place you went right out of college. It was a place where people who really gave a damn about open source went because the money was enough, and they got to work on something they felt was actually making software better.

It wasn't some corporate machine, it wasn't particularly profit-driven, and it definitely wasn't somewhere where the engineers wanted to push some corporate vision of how Linux should be. As of maybe 2017 or 2018, we started hiring more "new grads" and pivoting more to cloud workloads (outside of what Openstack already had), but the fundamentals didn't really change.

The perception of what Redhat is/was and what they actually were/are? is very different. It wasn't a perfect place, and the best ideas didn't always win, but at least you always felt like you could voice them, and you never felt like you were railroading a project to build a "moat" around some business model. Good projects got a lot of developer/admin/ops mindshare, and those dominated the market, so you should write good software which people will like/use. It wasn't complex.

One of the things which I miss the most (outside of being surrounded by people who were passionate about software ethics) is QA -- Redhat's QA is, in no small part, what has kept software quality high.

> That being said there is a bit of hard data, this post nicely shows gnome contributions over time, as less and less non-redhat developer contribute.

> https://hpjansson.org/blag/2020/12/16/on-the-graying-of-gnom...

> Now I'm sure you have a dozen explanations lined up for why that might be the case, most of them involving how good redhat is and how they're a bastion of light all that, which sure I have no way to definitively prove that there's any malfeasance going on.

Try not to turn people into strawmen.

The likely explanation is that GNOME has gotten much more complex and harder to contribute to, and the divide for new contributors to meaningfully fix bugs or add features has gotten wider as GNOME3 has stabilized (and bloated a bit). There's a clear pike just before 3.0, and it kinda declines after that, but some of the other major contributors (Ximian, Collabora, arguably Sun) aren't players anymore.

The other missing piece of data here is that, outside of the kernel (which gets a ton of contributions from hardware vendors submitting code to support their own stuff), you'd find the contribution ratio to be shockingly similar. glibc, openssl, and a number of other core projects are also more Redhat than not.

That doesn't mean they're trying to control the ecosystem. It means that, yes, it contributes to the company's bottom line, but you shouldn't assume that the contributions have a motive any more sinister than any other contributor.

GNOME's image problem is the same as GNOME's image problem always was, but we really haven't been talking about that. I'm not trying to defend Redhat or call you an asshole, but the amount of commits Redhat makes to open source projects all over is not subjective, that they get those commits upstreamed into projects they do not control is not subjective, etc.

Don't let your personal opinion about Lennart color what Redhat engineers do for open source or to paint all of them with the same "corporate peon building a 'moat' brush" (which also doesn't describe Lennart).

You don't agree with some of the decisions the communities made. That's fine. That's open source, too. It doesn't mean that you're right and Redhat is some Benedict Arnold scheming for control.

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#125
post #25

Earlier quoted context omitted.

I've been using linux for decades and by far -- by a HUGE margin -- PulseAudio has been the most annoying and broken thing I had to use. I'm still baffled by how something as basic as audio output can be eternally fragile in linux! And before you say you might have quirky hardware: my daily laptop is a Lenovo X1 Carbon 7th gen. Now (since 2021) I use PipeWire and tbh do not know to what extent pulseaudio codebase is…

> I'm still baffled by how something as basic as audio output can be eternally fragile in linux 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 n…

It is probably the driver that leads to have pulse audio use 10% of the CPU of a quadcore when doing nothing / not playing any media?

Also, probably the driver that regularly confuse it's inputs and outputs settings...

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#126
post #81
post #69

Earlier quoted context omitted.

No one is forced to use it - you can always switch distro. I also use hyperbole as a rhetoric instrument but in text seldom works.

At work you may not have that choice, especially since all the most-used (so, best supported) distros are deep into systemd now, or if you have a distro that you otherwise like but that has switched to systemd. It's possible to prefer something over alternatives but still think it's worse than it used to be, or could be better, or to very much dislike one part of it. Again, much like Windows and other MS products. Pe…

> well technically they could quit their jobs instead, so they didn't really have to

There are jobs which force you to use Linux, and SystemD in particular? Where do I sign up?

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#127
post #97

Earlier quoted context omitted.

Things which talk to the systemd dbus endpoints to add/stop/create/manipulate units are systemd-blahblah. This isn't that confusing. If it dynamically creates systemd units or sets their properties (systemd-homed, systemd-networkd, systemd-resolved) using the dbus endpoints, it's systemd-something. If it uses systemd libraries and lives in the systemd repo because it shares baseline docde, it's systemd-something. sys…

> Things which talk to the systemd dbus endpoints to add/stop/create/manipulate units are systemd-blahblah. This isn't that confusing. It is because systemd confuses what should be split concepts into one big overarching thing. 'org.freedesktop.systemd1' (the actual systemd init D-Bus interface) somehow is still implied that it is vital to the entire systemd-something ecosystem while it's not really. A example being…

This looks like a good first contribution.

hostnamectl DOES talk to sd_dbus, which DOES require systemd, which DOES require being PID1, and this message only pops up if you're in a container without the full subsystem running, access to the right cgroups, etc.

The naming is simply part of how dbus structures things, not to say that it's not part of it. I'm sure that, in retrospect, they wish they would have used "org.systemd...", but hindsight is 20/20.

If there's a scenario other than container without the right mounts/etc where this can come up, you should file a bug. If there isn't, you could see if you can submit a patch to improve the message.

It's not an indication that systemd confuses concepts. Its can indication that a) dbus is kinda shit, and b) I doubt if the systemd mapped out hypothetical dbus names 5 years in the future.

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#128

Earlier quoted context omitted.

It's very trivial to bypass those: just delete the packages off your system. Of course this means your system now won't boot, and you must expend effort to deploy a replacement. That's the actual non-trivial part. There's nothing the systemd developers can do to make that any easier for you, unless you expect them to suddenly start developing two or more init systems for some rather unclear reasons. If the problem is…

OK so in some hypothetical sense it's fine, but in practice it's a pain in the ass to avoid. So let's go with I dislike systemd in practice .

I still don't know what point you're trying to make though. To me this is like if you said "in a hypothetical sense planes are fine because you can buy a private jet, but in practice it's a pain because you know I have to fly in a crowded coach seat". Like, ok, sure, that's technically true, but still no one is going to donate you a private jet. If you had another hypothetical replacement and you could afford to spend all this time switching the company servers over and training everyone else to use it then maybe you could do something, but you don't, and the systemd developers could not help you with that even if they wanted to. What do you want anyone to do about it?

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#129
post #77

Earlier quoted context omitted.

When his employer uses politics to try to coerce others into using that "free & gratis" software it can leave a bit of a bitter taste in your mouth. It's not that something like pulseaudio is bad so we can just ignore it, it's that pulseaudio is bad because because redhat funds a lot of gnome stuff gnome won't really work unless you use pulseaudio, and since you use gnome you now have to use systemd. If pulseaudio ju…

Desktop Linux is not Red Hat's core business and it hasn't been for a long, long time. Way before pulse or systemd. 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 firs…

Things like systemd suffer from the xkcd traffic engineer syndrome:

https://xkcd.com/277/

Same thing with cars that were designed in the 1960s before we had to worry about things like emissions and crash safety.

Sysvinit is great up until you have a use case that it winds up sucking for. Most people don't hit that problem, or don't realize that their high level problem (correctly handling something being hotswapped probably) requires better integration than that.

They're also pissing and moaning without any solution that addresses all the requirements, and just use "Desktop" and "Enterprise" like they're slurs rather than what should be tablestakes.

And I wrote some truly awful code 10 years ago dealing with an abstraction layer built over the dozen different service managers than existed back then (upstart, runit, etc, etc). I'm quite happy that my code turned out to all be ultimately quite useless overdesign in retrospect and systemd just took over everything. It was a mess back then.

Re: PulseAudio and Systemd Creator, Lennart Poettering, Reportedly Leaves Red Hat

#130

Earlier quoted context omitted.

OK so in some hypothetical sense it's fine, but in practice it's a pain in the ass to avoid. So let's go with I dislike systemd in practice .

I still don't know what point you're trying to make though. To me this is like if you said "in a hypothetical sense planes are fine because you can buy a private jet, but in practice it's a pain because you know I have to fly in a crowded coach seat". Like, ok, sure, that's technically true, but still no one is going to donate you a private jet. If you had another hypothetical replacement and you could afford to spen…

To quote myself:

> 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)

Post reply on HN