[hackyhacky]

> If the hole is desperately needed, why would you want to fill it?

Good point. Let me rephrase: "Systemd fills a hole in the Linux ecosystem, which desperately needs to be filled." This version of the sentence is more correct and conveniently functions as a double entendre.

[j16sdiz]

systemd killed many projects and use cases along its way.

Better integration for mainstream, sure. but at the end we have less choice.

[shadowgovt]

Sometimes the end user actually suffers from too much choice.

Choice implies complexity, and there are some places less complexity is quite desirable. I still periodically, when setting up a new Linux machine, have to figure out why the audio frameworks are fighting, for example. The fact that "frameworks" is plural there makes everything harder for me, the end user.

(I compare Python and Node environment management frequently here. Python standardized the protocol for setting up an environment. Wise, better than nothing, but now I have to care whether something is using conda or poetry or some several other options I don't know. Node has npm. If there's a package, it's in npm. To setup a Node service, use npm. One thing to know, one thing to get good at, one thing to use. Environment management with Node is much easier than in Python).

[hackyhacky]

> but at the end we have less choice.

This is exactly my point: you want "diverse choices", which is fundamentally at odds with "cohesive functionality."

The article is about LSP, an imperfect standard, but nevertheless a standard. The prioritization of "choice" above all else is why the OSS world is incapable of creating standards.

> systemd killed many projects

The purpose of software is to fulfill a need. Creation of software projects is simply a side-effect of that process. It's good that systemd killed many projects, because those people who had worked on those projects can now work on a problem that hasn't already been solved.