Ubuntu, for all their faults, were the first to make Linux really easy to install and made it "just work." That counts for a lot. Since then, their output has been disappointing.
Part of the problem, is that "Linux/Unix culture" is very averse to coordination. When someone does try to establish a common baseline, there is inevitable pushback. The classic example is systemd, which fills a desperately needed hole in the Linux ecosystem, but is to this day criticized for being antithetical to the ethos of, I guess, gluing together an operating system with chewing gum and bits of string. The fact is that many users would rather have a pile of software that can be hand-assembled into an OS, instead of an actual cohesive, consistent platform.
So I can't blame people too much for not trying to establish standards. If OSS had created LSP, there would be 20 different incompatible variations, and they would insist "We like it this way."
There is another factor at play: different users value different things. For example, there are some people who don't like systemd, not because they are enamored with classic startup scripts, but because they take issue with systemd's design. It's not that they dislike coherent, consistent platforms: they just take disagreement with the design decisions of that particular platform. For example, I like the classic Mac OS and Jobs-era Mac OS X, but I don't like GNOME. All of these are coherent platforms, but they have different philosophies.
The difference between open source software versus proprietary software is that if users don't like the changes made to proprietary software, there choices are limited to the following:
1. Dealing with the changes even though they don't like it.
2. Sticking to an older version of the software before the changes took place (which can be difficult due to needing to deal with a changing environment and thus is only delaying the inevitable).
3. Switching to an alternative product, if available.
4. Writing an alternative product (which can be a massive undertaking).
Open source software provides additional options:
5. Fork the older version of the software. If enough people maintain this fork, then this becomes a viable alternative to the changed software.
6. Use the new version of the software, but modify it to one's liking.
This is the blessing and the curse of open source software; we have the power to make our own environments, but some software is quite labor-intensive to write, and we need to rely on other people's libraries, systems, and tools to avoid reinventing wheels, but sometimes those dependencies change in ways that we disagree with.
I think the best way to mitigate this is making software easier to develop and more modular, though inevitably there are always going to be disagreements when using dependencies that we don't directly control.
Indeed, "good" doesn't matter if the OS is a pain to use.
The Driver support issues are essentially a theological war between FOSS ideals, and mystery OEM binaries.
Most of the linux kernel code is still the driver modules, and board support packages.
The desktop options have always been a mess of forks and bodged applets to make it useful.
Ubuntu balances the purity of Debian with practical user experience (we could all write a book about UEFI shenanigans.) RedHat focuses more on hardened server use-cases.
Is it worse than Win11 ? depends what you are doing, and what people consider is the low bar for messing with users. =3
> 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.
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).
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.
Part of the problem, is that "Linux/Unix culture" is very averse to coordination. When someone does try to establish a common baseline, there is inevitable pushback. The classic example is systemd, which fills a desperately needed hole in the Linux ecosystem, but is to this day criticized for being antithetical to the ethos of, I guess, gluing together an operating system with chewing gum and bits of string. The fact is that many users would rather have a pile of software that can be hand-assembled into an OS, instead of an actual cohesive, consistent platform.
So I can't blame people too much for not trying to establish standards. If OSS had created LSP, there would be 20 different incompatible variations, and they would insist "We like it this way."
EDIT: averse, not adverse