This feels very right. The problem is there are few entities invested enough in Linux as a consumer platform, that have the motivation to push things forward. To make the decisions on what their "Reference" system is.
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.
Valve doesn't seem interested in doing much on the desktop, they seem to have constrained themselves (probably wisely) to working on areas directly related to their business and products.
Google is the closest with Android. They were even able to get Adobe to port photoshop which other Linux operating systems have failed to have happen.
Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible.
Android is the most Pervasive yes, but I would consider it too focused on a specific type of platform, and one that is becoming more and more closed off.
ChromeOS might be a better example, but much like android, it is also very closed off from the rest of the ecosystem.
Android doesn't succeed at what free software developers (or users) care about. The present-day reality of Android is a huge, depressing disappointment to anyone who gives a shit about software freedom.
It's a TiVo-ized spyware delivery platform, absolute riddled with (often non-removeable, often installed by entities other than the user) badware.
Android is an abject, dismal failure when it comes to very basic things like empowering users.
>Android doesn't succeed at what free software developers (or users) care about.
I disagree, unless you mean that they care about having there OS copy how UNIX worked 50 years ago.
>It's a TiVo-ized spyware delivery platform
Boiling things down to a pile of buzzwords is not productive especially when they aren't accurate.
"TiVo-ized": Android fully supports a user unlockable bootloader. Such a term doesn't even refer to the operating system, but to the device / bootloader, so it doesn't make sense to describe Android like that.
"spyware delivery": I assume this means that it includes a package manager that can install apps automatically. Several other Linux operating systems support that too. That isn't unique.
>absolute riddled with (often non-removeable, often installed by entities other than the user) badware
It is up to the vendor to pick what software they bundle with the OS. It's not inherent that "badware" has to be bundled.
Your criticisms of Android are not even with the operating system itself, but with downstream versions of it.
Ah, great! What hardware can I buy and where do I download the Android installer for it?
Android has made some very interesting technical decisions, and Linux workstations should implement something along pervasive sandboxing, for sure. The pretense that Android in itself is something anyone outside of large phone-manufacturing companies should (or are able to) deal with is a little silly.
> Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible.
I'm not sure I understand you here. What do you think other Linux distros should have done?
>What do you think other Linux distros should have done?
Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with.
> Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with.
As a common target, AOSP isn't a very good one.
AOSP ran on desktops. (Maybe it still does, haven't tried it in a while.) It was still a mobile OS, though, so it wasn't good on the desktop, but it ran.
It also uses very old kernels.
Other than the kernel, the Android UI is completely different from conventional Linux. Any Gnome or Qt app would have to be completely rewritten to support it, and would probably have to run in the JVM.
Basically, if the Linux community followed your plan, they would have to commit a huge effort to port everything to what is essentially a completely different, incompatible OS in every respect except the kernel, and their reward would be to live in subservience to the whims of Google in supporting their product which Google themselves never had enough faith in to make it a proper desktop OS. It seems that the benefit does not justify the investment.
Which is why it would benefit from people who are trying to optimize it, and extend it to offer a good desktop experience.
>It also uses very old kernels.
It's based off the latest LTS release of the kernel.
>Any Gnome or Qt app would have to be completely rewritten to support it
Which is why my comment said that distros would work on backwards compatibility to avoid such expensive work of requiring a complete rewrite amd try to make it as seamless as possible.
>and would probably have to run in the JVM
Android does not use the JVM. It has ART, the Android Runtime, but you can still use native code.
>and their reward would be to live in subservience to the whims of Google in supporting their product which Google themselves never had enough faith in to make it a proper desktop OS
The benefit is being able to reap the fruits of the billions of dollars Google's is investing into the OS. Along with compatibility with a large amount of apps. As a bonus staple Linux applications may be able to installed to some of the billion existing Android devices today. Google may not have seen the benefit of supporting the desktop, but that's where smaller players can come in to play a role in trying to focus on more niche markets where there is less possible return.
I don't think Android is a good platform for desktop usage. First the windowing system, and the IPC mechanism. They are very limited. And one of the nice aspects of desktop computing is the ability to alter it for your own purposes (something that MacOS is running away from). Meaning you extend it for some other domain, think music production, video production,... Where you want to hook it to some hardware and have the software to talk directly to the latter. Which means having access to all the ports and coding bespoke protocols. I don't think current android API allows for that.
> The distros could add new APIs could be added to expose new capabilities.
Those exist already. With Debian, Alpine, Fedora,... you can put anything on top of the kernel in the userland. Android goes with a restricted version.
It's the same with MacOS. It's Unix, but with proprietary add-ons and systems. And lately, with more restrictions.
How does those existing make Android not a good platform? I don't fully understand the point you are trying to make.
By restrictions do you mean having proper capability based security instead of letting all apps have access to everything? These restrictions are a good thing.
Limited userland and limited access to it. Sandboxing may be good, but the user may need some software that needs to escape it. Fedora Silverblue is a promising direction, but interacting with the base system is currently a pain.
90% of the problems Linux has had in the last 10 years are due to trying to unify desktop UI with mobile. This is fundamentally a mistake and it is critical to avoid it.
As far as I know Google has never accepted patches into Android, so everything has to be maintained outside the project in parallel, which helped kill it.
Google is not your friend, and they will not work with you. Android has diverged several times, and they break everyone else without caring.
Long before Android existed, they could’ve all agreed to have the same single desktop environment, UI toolkit, app packaging and distribution method, etc. And also agreed to ship drivers, even if proprietary.
Valve is maybe the closest?