I have learned to hate this term. Sometimes it means choice other times it means different solutions to the same problem. I much rather have choice then be placed in a box.
> repeating problem in open source, it's a repeating problem for Unix
Since Open Source and Linux aka *Unix has won I fail to see your point.
The big issue was they went with their own solution and didn't add to Wayland which is something they could have done this wasn't fragmentation.
"When Mir was started we needed a mechanism for client-server communications (and Wayland wasn’t in the state it is today). We did something that worked well enough (libmirclient) and, because it’s just a small, intentionally isolated part of the whole, we could change later."
Starting Mir after and if investing on Wayland failed would have been much wiser.
"Starting deb after and if investing on rpm failed would have been much wiser" except that Debian developers already knew rpm didn't meet their needs.
But these arguments are always selectively applied to certain parties (e.g. Canonical) and not others (e.g. Red Hat).
Besides, deb/rpm is the perfect example of our failure as a community. To the end user, having both standards bring nothing. Neither are better than the other for 99% of use cases, and we ends up needing twice the tool, documentation and community effort that we should.
And because it's such pain, any languages created their own package managers. gem, pip, goget, npm...
Now we are replaying the same with flatpak/snap.
After dealing with the various walled gardens and their concomitant limitations, and after dealing with any system of linux package management, the Windows way feels like some sort of joyous escape from captivity.
I don't know what you mean, but I can make my point a little more explicit: Unix has fragmented the graphics stack in the past and it just hurt the software ecosystem for no particular benefit. In the eighties, users had to choose between mutually incompatible desktop environments. Later, users had to choose between sort-of compatible desktop environments like kde and gnome (progress!). Looking beyond desktop environments to the rest of the system, there are plenty of more specialized bits that administrators and developers (and end users, if linux can truly be said to have those) have to choose between, even though no sane person should have to care.
And that's basically fine. This kind of stuff is why desktop linux is mostly just a tool for developers and students, while the real world uses Windows, iOS, and Android for everything. It's a little inconsistent for Canonical to be fragmenting the ecosystem, however, since they (maybe I'm wrong about this?) aim to bring about The Year Of Linux On The Desktop.
> Unix has fragmented the graphics stack in the past
Yes I remember these days. We were just having different solutions to the same problem. It got settled fairly fast, but I never had the issue of I paid for this Unix and now I have to decide what display manager was going to be. Each vendor pretty much made the choice already for you.
> Later, users had to choose between sort-of compatible desktop environments like kde and gnome (progress!).
I have been a KDE guy forever, but I could always use whatever programs I wanted. They might not look decent but they all worked together with a few tiny exceptions in the early 2000s. Today I mostly use a tiled window manager but I still use KDE programs with my command line programs. I don't ever get the issue with mutliple of Desktops since that is a strong plus for people to discover what works best with their workflow.
> developers (and end users, if linux can truly be said to have those)
WHAT???? You mean the people that developed Mir????
> the real world uses Windows, iOS, and Android for everything
http://google.com is Linux, Android is Linux. MacOS is a Unix. The web is majority Linux. People use Linux everyday and I guess your one of the people that doesn't realize it or it doesn't count? But the vast majority of CPU ticks on this planet are all Linux ticks.
You keep trying to make Linux Desktop = Linux and while desktop is a part of Linux. Your mixing and matching to make a point that is inconsistent.
Well, there are a few different points here. Fragmentation messes up the desktop software ecosystem, and I started with that. This is a thread about Mir, after all.
But fragmentation is not unique to the desktop portion of the Linux world. I think the same problem of fragmentation and multiple standards creating choices no end user should have to worry about applies to the rest of Linux.
> http://google.com is Linux, Android is Linux. MacOS is a Unix. The web is majority Linux. People use Linux everyday and I guess your one of the people that doesn't realize it or it doesn't count? But the vast majority of CPU ticks on this planet are all Linux ticks.
And if you have some reason to regard that as a victory, congratulations! But to get back to the point: in most of those cases, someone has abstracted away and hidden from the user - through a lot of needlessly difficult work - the gratuitous bullshit of choosing between competing GUI environments or package managers or service managers or distributions or whatever other stupid thing Linux hasn't standardized yet.
A web user doesn't care about this stuff at all. On Android, grown-ups have dictated the direction of the platform and the whole end user experience is identical to that of a closed operating system. Ditto for iOS and MacOS.
This is all slightly interesting in light of the fact that Canonical always sort of aspired to make a more streamlined and straightforward product for users, while (debatably) operating within traditional open source development norms. Going off and doing Mir (in secret, although I don't think that's really the big deal) doesn't seem conducive to that.
Anyone framing these issues as fragmentation is using it as a buzzword. Fragmentation isn't a thing when you're comparing three things that provide meaningfully different pros and cons.
Fragmentation is an issue when it means having the same 6 solutions to the problem, all poorly implemented, compared to 3 good solutions.