I don't trust Poetteringware. Poettering's team has a record of foisting technology on users, resulting in the need for e.g. the Devuan fork. I wish this work were being done by just about any other team than Poettering's.
They have been developing software, that enough people have deemed useful to include it in their distributions. Some have disagreed, and have made other choices. No one was forced to do anything, there have been no "foisting" and the "need" for Devuan is a subjective opinion.
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.
He definitely isn't perfect but this sounds like quite the feat in Open Source.
*PulseAudio was simply broken but it's not the fault of the author distros picked up aplha-quality software
Someone made a decision, others didn't like it so forked. Sounds like open source is working exactly as it should?
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.
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.
Highly inaccurate
FTFY
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.
Projects merged changes because they wanted them, not because their goodwill was abused to make them merge anything. People got systemd on their OSes because they chose OSes whose developers chose to move to systemd.
It's not like Lennart comes to your home with a gun if you install OpenBSD.
The ramifications of those technical choices on the software ecosystem are so well understood [0], that there is no point in discussing "their own merits" in a vacuum.
What's most relevant to my professional and waning hobbyist interests are the shape and trajectory of the software ecosystem as a whole. To talk about systemd without talking about how it's developers interact with the software ecosystem is to talk about nothing.
[0] I graduated before systemd was a glint in Pottering's eye, but we somehow still covered it in school. Not only coupling vs cohesion in the abstract, but also how various design decisions (including init system arguments of old!) interacted with the ebb and flow of unix-like OS evolution.
They can't. GNU was a political project from day 1, with explicitly political goals; the unix-like design is for political, not technical, reasons.
> Projects merged changes because they wanted them, not because their goodwill was abused to make them merge anything.
Citation needed. If you maintain a widely-used open-source project there's a pretty strong social norm/pressure to merge contributions that don't have anything obviously wrong with them, even if the functionality they implement is something you don't actually want or need.
> People got systemd on their OSes because they chose OSes whose developers chose to move to systemd.
Because they chose OSes whose non-technical leadership chose to move to systemd, in violation of the project constitution, and then had the rump technical committee rubber-stamp it once the principled technical leadership had resigned in disgust and the decision was already a fait accompli, the way I remember it.
> It's not like Lennart comes to your home with a gun if you install OpenBSD.
Some will rob you with a six-gun, and some with a fountain pen. No, Lennart won't hack into your computer with an SSH exploit, but he'll get the software you're using (like Gnome) to push updates that stop it working on your computer, and so the end result ends up much the same.
Please don't fan this flame.
systemd has everything and a kitchen sink, it is a big blob of software.
Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing that made me question sanity of distro maintainers and author of two worse pieces of software: pulseaudio and systemd. (I was very surprised that it was the same person).
Also brittle and unreliable. Every distribution needed custom-made init.d script, incompatible with every other distribution. No, thanks.
> systemd has everything and a kitchen sink, it is a big blob of software.
You can still pick and choose. Systemd is an umbrella project.
> Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver
systemd-resolved is exactly one of the things that you can pick and choose.
> was the final thing that made me question sanity of distro maintainers
And there are good reasons for that:
1) /etc/resolv.conf cannot be extended; you cannot express all the configuration that is needed for resolver today (e.g. per subnet zones) or dynamic enough (user-managed network links that go up and down).
2) applications are not supposed to use resolv.conf directly anyway; if they do, they are broken. The local nss config may be such, that they won't be able to find all hostnames, or the above mentioned per subnet zones, which they won't be able to resolve. Hence, they are supposed to use libc, which does the right thing. Even golang runtime respects this and thunks into libc for nss.
Maybe conceptually simple, but far from it in terms of reliability, predictability and ease-of-use.
> Finding out why the heck my resolv.conf contains some 127.0.0.x entry and not the real nameserver was the final thing [...]
So you read the comment at the top of the file and that made you question someone's sanity?