Hacker News new | ask | show | jobs
by sianemo 1451 days ago
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.
3 comments

I don't think anyone would care (probably most of us here wouldn't even know his name) if these projects had been written and integrated such that it was trivial to avoid them in favor of alternatives. No-one who hated Upstart, say, is pissed off at the people who made it. Between Red Hat's maneuvering and Poettering's choices, though, it's not trivial to avoid them.
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 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...

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

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

But these things are inherent to the problem domain.

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.

> PulseAudio has, deservedly or otherwise, been the face of audio issues in desktop Linux for coming on two decades now

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.

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 logging broke established file-based workflows.

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.

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