[Crysstalis]

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

[corrral]

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.

[Crysstalis]

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?

[corrral]

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)

[Crysstalis]

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

[corrral]

> That doesn't follow unless you consider "developing a software that becomes popular" to be a method or a choice.

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.

[Crysstalis]

I think that is the terminal reason for your complaint, if it was unpopular we probably also wouldn't even be talking about this.

[kaba0]

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.