[hdjjhhvvhga]

> There is really no need to transform purely technical arguments into personal attacks. This just discourages participating into free software development.

While I agree with you in general, for some reason this particular developer tends to take decisions that have very extensive consequences and make choice extremely difficult.

[kevincox]

A developer that has been able to make tough choices and drive them well enough to get mass adoption?

He definitely isn't perfect but this sounds like quite the feat in Open Source.

[hdjjhhvvhga]

There is a huge difference between a developer who creates a superior project that everybody loves to use so it gets mass adoption and one who makes a product that gets pushed by their employer on everyone whether they want it or not. I don't want to get into details as the subject has been beaten to death but as for Systemd* there was the case of integration with graphical login that made choice difficult. Had the author been more sensitive to this issue and cooperated a bit without being stubborn we wouldn't have had Devuan and all that mess. This is exactly NOT the way to do things in open source.

*PulseAudio was simply broken but it's not the fault of the author distros picked up aplha-quality software

[growse]

> This is exactly NOT the way to do things in open source.

Someone made a decision, others didn't like it so forked. Sounds like open source is working exactly as it should?

[hdjjhhvvhga]

For applications, tools, even most libraries - yes. But this was one of the critical elements of the system and they had to fork the entire distro because the way it was done actually made the choice more limited.

[Foxboron]

>But this was one of the critical elements of the system and they had to fork the entire distro because the way it was done actually made the choice more limited.

This isn't very accurate. When Debian decided to switch to systemd, they also agreed to support other inits in the distribution.

This wasn't good enough, so Devuan itself was forked before this decision was made. The end result is that Debian had less people to support the init script alternatives. It became a self-fulfilling prophecy.

I'm confident Debian could support other inits if there was more Debian devs available to work on it. But because people left for Devuan the pool becomes smaller.

Even the last decision on inits from Debian says that the focus should not solely be on systemd.

https://lwn.net/Articles/808217/

[denton-scratch]

> they also agreed to support other inits in the distribution.

That's true, but with systemd being the only init that packages had to support. Accordingly many package maintainers choose to only support systemd.

So if you want to run Debian without systemd, you have to be prepared for your fave packages to drop support for the other inits. It follows that you can't rely on the Debian package repository. So to support a Debian-like system without systemd, you have to fork the whole repository.

[biorach]

> a product that gets pushed by their employer on everyone whether they want it or not.

Highly inaccurate

[kasabali]

> A developer that has been able to make arbitrary choices and drive them thorough his employers connections to get mass adoption

FTFY

[denton-scratch]

I didn't make a personal attack on Poettering; my objection is to the software his team produces. And I wasn't making any technical argument; I don't know enough about TPM and secure boot to do that.

My point was a political one, I guess: this is more software that runs very deep in the system, coming from a team that has a record of producing software that is hard to opt-out of.

For PulseAudio on Debian, you have to take firm steps to ensure the package manager doesn't reinstall it. Much the same goes for systemd. I assume it will be much harder to opt-out of a secure boot released by that team. I believe that's on purpose: they could have made it easier to run without those packages, if they'd wanted to. I think it's clear that they wanted the opposite.