> 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.
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
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.
>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.
> 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.
Devuan has init-script support for the packages in its repository. So it's open to the Debian maintainers to pull the scripts in; but they only want to support one init system, understandably. And the fact that nearly all other distros have systemd as a default init, it's natural that developers and maintainers are pleased with the systemd hegemony.
I'm just sorry that Debian made the decision it did. But Debian has always been the developers and maintainers; only incidentally the users. They were entitled to make that decision, and I think their process was exemplary.
[Edit] That "exemplary" process: actually I think it shouldn't have been pushed to the technical committee. It should have been a simple general resolution from the start. But I think the result would have been the same, and I found the debates very illuminating.
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.
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.