Almost nothing you've said here is correct.

The Unix philosophy has very little to do with desktop fragmentation and everything to do with the fact that unlike macos and windows: it's not that commercial an endeavor. A common employer is a main reason many work on someone else's ideas when they can just work on their own ideas.

Even when there are commercialization efforts: investment and adoption circular. The challenges are much much bigger than just the desktop fragmentation.

See: ChromeOS. Investment can solve these problems.

Similarly, Fuchsia is a much bigger effort about the future of operating systems and not about just desktop environment quirkiness. Again, they have ChromeOS for that.

Don't get me wrong, I agree this all hurts Linux adoption, and as a user I wish it were different.

Everything I said is the brutal, hard, evergreen truth.

> The Unix philosophy has very little to do with desktop fragmentation and everything to do with the fact that unlike macos and windows: it's not that commercial an endeavor. A common employer is a main reason many work on someone else's ideas when they can just work on their own ideas.

It is part of the in-fighting, which contributes to the whole desktop fragmentation issues, distro forks and chaos around it and its frankly an unsolvable disaster.

The whole debating between system components such as systemd vs init.d, X11 vs Wayland, Pulseaudio vs Portaudio vs Pipewire have further contributed to the alternatives of alternatives desktop fragmentation and it is a tug of war between UNIX philosophy greybeards and other devs attempting to solve the fragmentation for years. Due to this failure of consensus: No app developer can 'define Linux support' and cater to all desktop Linux users 100% of the time, unlike Windows, and macOS.

> See: ChromeOS. Investment can solve these problems.

Only for Google. They already have learned from the mistakes of these distros and are going to replace it with Fuchsia. ChromeOS is still a mostly closed-source system despite using a Linux kernel, just exactly like Android still is, which isn't the same thing as the chaos you see in many open-source full Linux distros.

> Similarly, Fuchsia is a much bigger effort about the future of operating systems and not about just desktop environment quirkiness. Again, they have ChromeOS for that.

Hence why Google is replacing ChromeOS with Fuchsia, which includes and avoids all of the above.

> Everything I said is the brutal, hard, evergreen truth.

Hey, I'm not here defending any of the desktop chaos or waving the whole: "but atleast choice is good!" flag. I just disagree with your attribution of everything to "the unix philosophy" and then snowballing that into Fuchsia.

I just think convergence is the exception not the norm for FOSS and this was more true before then now. That's less about "the unix philosophy" and more that only companies come with referees who pay you to converge and polish.

I don't think the problem is the Unix philosophy, which has to do with building focused components ("do one thing only and do it well") that are interoperable with each other (e.g., Unix pipes). While it's hard to apply Unix pipes to GUIs, component-based GUIs have been explored (e.g., Smalltalk environments where everything is an object and thus composability is built-in, Plan 9 [the acme editor is a great example of how an IDE can be composed from smaller programs], OpenDoc, Microsoft's OLE, COM, and ActiveX technologies, and even KParts and Bonobo in KDE and GNOME, respectively).

I think the problems with the Linux desktop are as follows:

1. Think of the sheer size of modern desktops. Think of the large amounts of code that are in the Xorg, GNOME, and KDE code bases. Building a large desktop system that is as feature complete as Windows or macOS will take millions of lines of code when developed using conventional programming languages and tools. This is not a single programmer's weekend project. Even a small team of programmers will need a considerable amount of time building something usable.

A counterargument to this, though, is the STEPS project by Alan Kay's Viewpoints Research Institute (http://worrydream.com/refs/Kay%20-%20STEPS%202012%20Progress...). The researchers were able to implement an entire desktop operating system in just 20,000 lines of code. Perhaps by using the lessons drawn from STEPS it may be possible for one programmer or a small team of programmers to build a high-quality Linux desktop in a short amount of time. In fact, reducing the size and complexity of Linux desktops may lead to a better situation for Linux desktop users.

2. It is difficult to impose a singular vision on something as large and complex as a desktop using bazaar-style development patterns. It's one thing to build a clone of Unix this way; Unix's userland is a collection of disparate tools anyway, and Unix was already a well-studied design by the time the GNU project started. It's another thing, however, to build a brand new environment in this manner. It's no wonder that the best desktop ever to be built on top of Unix, NeXTSTEP and its descendants, was a commercial project led by Steve Jobs.

3. Big software projects require large amounts of resources. Windows and macOS has these resources. The server-side open source ecosystem has many well-funded projects, including the Linux kernel itself. But GNOME and KDE never had this level of investment. This is true of application software as well. Consider the resources devoted to the development of Microsoft Office and the Adobe Creative Suite, and compare that to LibreOffice, the GIMP, and Inkscape. On the flipside, consider how GNU/Linux (the Linux kernel + GNU utilities) successfully competed against proprietary Unices, to the point that some users of proprietary Unix systems downloaded GNU tools because they liked them better than the tools that came with the system. I believe this is one of the key benefits of small, composable tools.

4. Fragmentation may hurt adoption. On one hand more choice theoretically means that it's easier for users to choose a desktop that best fits their needs. On the other hand, fragmentation in an environment where resources are already scarce means sifting through an ecosystem of half-baked, incomplete desktops instead of having fewer but complete desktops. In addition, developers have to decide which technologies to target. If I'm using an existing toolkit, do I pick Qt, GTK, or something else like Electron? Do I target Wayland or X11?

5. In my opinion, churn has also hurt adoption. Sometimes churn is necessary, but this doesn't minimize the disruption for both users and programmers. I still remember the KDE 3 -> KDE 4 and the GNOME 2 -> GNOME 3 transitions and how disruptive they were. I also felt they harmed adoption at a critical time for the Linux desktop. By comparison, Microsoft has bent over backwards to preserve backwards compatibility. Apple is more willing to make disruptive changes, but these disruptive changes usually have a clear benefit (for example, the transition from Mac OS 9 to Mac OS X with all of the modern features the latter had), and Apple tries hard to minimize the impact of these disruptions for both users and programmers.

I think the solution to this problem is for the community to adapt to the realities of open source software development with its constrained resources compared to commercial development, and build small, composable software tools that don't require large armies of developers to maintain, preferably in high-level programming languages or even (taking a page from STEPS) domain-specific languages. No one desktop is going to satisfy all users, but smaller, more modular tools are easier to deal with than large monoliths. "If you don't like it, change the code; it's open source" isn't much of a solution when you're staring down hundreds of thousands of lines of C++, but if the desktop were something more akin to Squeak Smalltalk, it would be easier to change it to fit one's liking, even without express support for customization.