GTK 5 might drop X11 support
theregister.com
theregister.com
I really want to see Wayland move forward and succeed, but there are so few companies injecting money on it, they get to dictate how things move. Red Hat is one of the main contributors, and they only seem to care about Gnome working on Wayland (as much as I don't like their direction, I can't really blame them for following it, it just sucks that I don't like the product they're developing). The landscape is extremely fragmented and everybody who is not on the Gnome garden will suffer a lot.
I really wish some other non-Gnome-favoring company would find a reason to dump a lot more money into Wayland and help move it forward in the not-only-gnome-favorable path. This is not a thing that will move forward without full-time workers. X has always had a lot of paid people contributing to it.
That is, if IBM doesn't decide to throw a bigger wrench at the problem.
As a Sway user, I haven't noticed anything that works on Gnome but not Sway, except for stuff like Zoom, which hasn't, until recently, used the portals.
xdg-desktop-portal itself originates from Flatpak[3], which makes me think it's more like to related to Canonical/Ubuntu rather than being something RH drove.
[1] https://github.com/emersion/xdg-desktop-portal-wlr https://news.ycombinator.com/item?id=32008412 (2 pts, 30 min ago)
My understanding is most of the work is, deliberately, not in Wayland itself. In fact if you read feature and bug discussion between users and Wayland devs, it kinda seems like Wayland doesn't do much at all and has no interest in doing more.
I haven't looked into it, but wouldn't be a bit surprised if RH had a hand in that architectural decision. Definitely makes it harder to compete with Gnome.
If you want to make it easier to develop alternatives to GNOME, it would be best to start putting more reusable features into libraries, and getting all desktops (including GNOME) to use them. That way you have a common baseline that everyone can depend on. That may seem counter-intuitive but it is the only way, libraries provide implementations and it is actually the implementations themselves that are the important part to users, not anything that upstream is doing. The simplest example is something like Mesa. All the Wayland servers want to support hardware acceleration, so they all implement the relevant extensions, and then they're able to support applications that talk using the Mesa libraries.
> So they focus only on the small subset of things that every desktop agrees on
It's the old "but I can't do screenshots or screen sharing" again. The desktop may agree on this, but 90% of the users are like "I don't care, just make it work" - and by catering to what desktops agree on and completely ignoring things that at least some good percentage of every desktop will use, they kinda made a mess. It might be an architecturally superior mess but not even the people who have been tinkering with their Linux boxes for 20 years seem enthusiastic about wayland. Not everyone wants to first implement features in their window manager of choice.
I don't know what this refers to. The screenshots and screensharing are done through the xdg portal and pipewire. That's as "standard" as something across desktops can be, but like I said it just is done in a separate library/daemon rather than being in wayland upstream. You don't need to really implement anything in your window manager of choice if you already have support for those, you just use pipewire. They all agree on it. The implementations haven't ignored this, you're telling me I didn't get to the right conclusion but your conclusion is to just keep barking up the wrong tree and hope they change their mind, when they have even less incentive to do that now because the feature is already implemented elsewhere in a much better way.
>but not even the people who have been tinkering with their Linux boxes for 20 years seem enthusiastic about wayland
I don't consider this to be a problem. The tinkerers get most excited when you hand them something with a giant config file (e.g. xorg.conf) with every option under the sun that they can tweak and watch it fall apart. Most upstream maintainers I've talked to would very much like to get rid of these giant config files because they are completely untestable and unmaintainable. The tinkerers cannot have their cake and eat it too.
Honest question. Why? Or, what are you hoping will be different if this occurs as opposed to the current status quo?
The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) https://www.youtube.com/watch?v=RIctzAQOe44
It's just a shame it was made into something that is even more fragmented than X11 due to it being even less than what X11 tries to be. So much got undefined by the protocol and left as something to be solved by the Compositor, and we don't have an universal compositor.
And it's not like companies are throwing money at X11 either: progress is not happening there.
I guess I don't see why software that's been around for a few years longer than I've been alive, and has never really caused me much headache needs to be replaced with software that is an immature and in many ways, a worse offering.
I see people talking about screen tearing, but X11 supports vsync on most video cards, so I really don't quite get where that's coming from.
Wayland, IIUC, makes tear-free drawing inevitable.
(Regardless, I haven't seen screen tearing on X11 in... close to a decade? More? I don't care if that's the case only because it's "possible", and not because it's "inevitable". Who cares? It works fine.)
I'm far more annoyed by the added input delay and sluggishness from vsync. I want frames on the screen as fast as possible.
There is no way to ship a full X11 replacement in one go, especially not in a bazaar-style platform.
This is actually OT because this is about GTK, which is a fine toolkit even if it's not C++. It has binding for most languages.
Forking something and keeping it in a past state isnt really as useful as some think. See OpenOffice vs LibreOffice for example.
That fork of GNOME with a Win9x-style UI exists: it's called Cinnamon.
It's OK and it's quite popular. It's a lot more customisable and versatile than GNOME's own GNOME-Classic or GNOME-Flashback sessions, but it's still really quite clunky compared to, say, MATE or Xfce.
If GNOME-Classic or GNOME-Flashback worked a little better, so that one could rearrange panels and add/move/remove controls and so on, I suspect that there would be no need for MATE to exist.
I personally find Xfce to support more of the customisations I personally want (such as a vertical taskbar with horizontal rows of components and controls) than MATE, or KDE come to that.
Wayland, for me, delivers nothing I really want. I read about variable refresh rates, HiDPI support, smooth flicker-free animations and so on, but I don't actually want or need any of those things. I don't get flicker or tearing as it is, and X.11 does all I need: seamless multihead support with 3D acceleration, and so on. I frankly prefer a minimum of animations and fades and so on.
The stuff from comments about screen capture not working reliably does not inspire much confidence. I remember X11 taking decades to fix rough edges and surely don't want to go over it again.
Much like IPv6, it seems to be real old now, still not adopted and not really working, definitely not hip anymore.
This has changed.
As a daily Wayland user, the only thing that Wayland can't do is networked sessions, and I have never needed that.
> suggested Wayland
Ubuntu slated it for default in 22.04, but reverted due to a bug. I expect them to try again during the next release. If you want to try it then it's typically selected in the login manager.
> don't want to go over it again
Or don't try it, the grandparent comment was talking about "hate" not "disinterest".
My practical engineering analysis says that people will be forced to choose between abandoning working X software and foregoing new Wayland packages.
For example when one workflow critical app adopts GTK 5 (assuming it does not support X) and another workflow critical app remains X based.
And apps will remain X based because all the effort of porting to Wayland is chores not features.
Wayland doesn’t add import functionality to applications.
Indeed breaking the client-server idiom is a functional regression.
As is breaking Linux and Wayland is a breaking change because backward compatibility and/or reliable automated tooling to port complex applications is too much work for Wayland’s developers.
Who like most of those affected, are not getting paid Faang wages to work on deep pocketed well resourced teams.
Breaking applications makes it Python3 on steroids in terms of generating tidal waves of compatibility efforts.
But frankly, we can’t just put our heads in the sand and use 30 years old technology when it doesn’t map well to the underlying hardware. How else could such a transition ever happen otherwise?
I saw Wayland was inevitable.
I worried about dealing with the complexity it added to my existing workflows.
I thought "fuck this" and switched back to Windows after almost a decade of Linux.
Now I don't think about Wayland v X unless I want to.
That's not the way everyone can solve their problems.
And certainly not the way everyone should.
It's just what works on my machine.
Bonus, Windows has a more robust security model than X, so hence solves the same issues as Wayland.
YMMV.
And sent my desktop searches to Google.
Or maybe it was Duck Duck Go.
Which is Bing.
Same as Microsoft does.
My decision was practical.
Linux was a local minimum for me.
For my creative pursuits, Windows simply has less friction.
For example, my photography workflow used a Linux program called rapidphotodownloader.
One day toward the end, it stopped working.
I spent a non-trivial but not extreme amount of time figuring out why.
Turns out, the developer had hard coded window managers into the configuration file with the latest update (and the software nags every time there is an update and because it is Python with access with substantial file system privileges security is a concern).
Anyway, my Linux workflow used Xmonad which wasn't in the list of popular window managers the developer considered.
And because the software wasn't generous in what it accepted, it just broke.
I value stable tooling.
And after nearly a decade with Linux, I debugged the problem, changed the configuration file and felt a sense of accomplishment.
But what I really wanted to do was get my pictures off an SD card so I could do photography...editing, printing, and maybe sharing on social media.
If I was into filing bug reports, I would have let the developer know.
But I'm not.
Not that I am a selfish prick - at least I don't think I am - who doesn't "give back to the community."
It's that there is no community there that I am a part of...at least there's no more community there for me than there is a hammer community to which I ought to give feedback about hammers.
For many many things, digital tools are a mostly solved problem. Downloading files from and SD card and renaming them is a long solved problem...Windows Xcopy has been around since the NT days.
https://docs.microsoft.com/en-us/windows-server/administrati...
So I wrote a .bat file to store the configuration I wanted...just as I did in the old days.
Because a general purpose computer is a general purpose computer and operating systems are mostly fungible.
There just isn't enough time in my day to have strong emotional bonds to one and hate for another.
YMMV.
Gtk on X11 does not expose any X11 to the programmer, so I really don't know what this is supposed to mean.
The design of gtk is to separate the rendering in the GDK layer. Prior versions ran on Win32 without application changes.
That's how you can get it on X11 or Wayland without changing applications. Wayland didn't exist when this design choice was made, but has benefited from that choice. Imo rather than a liability, this is what good design looks like for such a library.
To provide the same API for such a broad set of underlying technology, you necessarily have to shoehorn a few things to make them fit. That doesn't make the API bad. It's awesome that applications don't have to do this on their own!
Not everyone can necessarily notice it. Some of us are unlucky enough to get headaches from it.
The Wayland thread a few days ago[1] made me want to try Wayland again. I've tried once a year or so for ages, but it had been a while. So I logged out, switched to Wayland and logged back in.
To my surprise, things looked like they worked. No rendering artifacts like last time, YouTube even played fairly smooth. Sure it wasn't as snappy as Xorg, but hey.
A day later I tried to play some video files from my Samba share on my NAS. I use SMPlayer since it can handle smb:// links. However this time it didn't start playing. I checked the logs, and I could see it complained about not having the correct credentials to the share, NT_SOMETHING_SOMETHING.
So I messed around trying to re-authenticate the share, different users etc. Nothing worked. I could view images just fine, but the videos just wouldn't play.
Looking at the SMPlayer logs I noticed something that struck me as odd. After the NT_SOMETHIG_SOMETHING error, there was mention of a Wayland authentication error...
So I logged back out, selected Xorg, logged back in and boom, video played like nothing had happened.
I'm just a user. I don't wanna dig into why the hell Wayland has anything to do with Samba share authentication. I just want my computer to work.
This October it's the 10 year anniversary of Wayland 1.0... maybe in another 10 it'll actually work for a mere mortal like me.
Blame SMPlayer being buggy, I play videos from smb shares in Wayland and nothing breaks because it's a bloody desktop compositor, not your network stack.
The misinformation surrounding Wayland is just astounding.
And as a user, that's all I care about.
edit: This time might be SMPlayer, last time was perhaps Firefox, and so on. I've tried Wayland at least once a year for ages, and every single time I have to go back because something is broken.
But sure, it could be anything. All I know is if I select Xorg on the login screen things just work, and when I select Wayland things don't.
>Looking at the SMPlayer logs I noticed something that struck me as odd. After the NT_SOMETHIG_SOMETHING error, there was mention of a Wayland authentication error...
>So I logged back out, selected Xorg, logged back in and boom, video played like nothing had happened.
>I'm just a user. I don't wanna dig into why the hell Wayland has anything to do with Samba share authentication. I just want my computer to work.
A recent upstream Linux kernel update broke certain SMB shares, if you are using Arch (or something else that closely follows upstream), its probably that.
Did you start using Linux last month? Because I have flicker-free, nicely-animated experience on X for years. Granted it's not experience that everyone has, but it's not fault of X, it's bad drivers or low power hardware. Wayland only brought forced vsync.
GTK4 is actually trash that ruined font rendering because GNOME developers felt so.
That was a reasonable hack 18 years ago but a fully composited desktop is table stakes in 2022.
This isn't an intrinsic problem with Wayland—I'm just not aware of anyone making a compositor that can recover or restart yet. I'll be excited to try out any that people write.
Of all the things I care about this might be at the very bottom of the list. If that's the best reason people can come up with to give up my DE and decent performance for all the X11 apps I use than I'm sorry but I won't ever be using Wayland.
Therefore, as you say, there's no incentive for the GNOME developers to support X11, and the devs are free to say "Use GNOME on wayland, implement an X11 backend for GNOME/GTK yourself, or don't use GNOME" which, in practice, boils down to "Use GNOME on Wayland, or don't use GNOME" and is, effectively, a fiat to use Wayland if you want to continue using newer versions of GNOME.
I also didn't intend this to be judgemental; GNOME is almost certainly the most complete desktop environment for linux. I personally use KDE as my desktop, but most applications I use are not part of KDE (or even built using Qt). Conversely, a typical desktop user could probably get by using just GNOME applications (plus maybe libre-office for opening MS documents that can't be handled within GNOME). IMO a large part of what makes this possible is by being judicious in what is supported.
No, the parent comment is wrong. There is no "vertical integration" or control. It's just an open source project. If anyone was interested in maintaining the X11 support, it would happen, or at minimum it would happen in a fork, but there is currently nobody.
If someone is worrying about other parts suffering, they should start contributing now. I doubt this will happen though, nobody has turned up over the past several years, which is exactly why they consider dropping it. Honestly I think most developers who even bother with GTK4 are probably fully on board with wayland, the ones who aren't are still trying to use GTK2 and GTK3.
Ok, I get what you're saying, but this is not different from looking at GNOME 2 (which only ran on X11) and saying they declared a fiat that you have to use X11. Any project gets to pick its dependencies.
Did I miss an announcement or something? Last time I checked X was not deprecated.
How would you even deprecate a protocol? Is HTTP/1.1 also deprecated?
SSLv2 and SSLv3 are surely deprecated protocols, no?
Apparently.
>> Last time I checked X was not deprecated.
Well now you know. Feel free to check again.
I generally use Gnome on my Linux laptop. I often find myself switching it to be Gnome on X rather than Gnome on Wayland. This isn't based on any explicit preference (I genuinely don't care), but I usually encounter some glitchiness that goes away when I take Wayland out of the picture.
People sure like to hate on change. Rather odd for a forum about disruptive startups.
Might be worth thinking about where Wayland was 5 years ago, and where it is now, and where it will be in 5-10 years. That's basically what the conversation was about.
but such comparisons will always have shortcomings.
For what it's worth, screensharing works fine for me. I use it with Zoom and Mattermost (webrtc). Are you on an old version? I'm on 1.18 I think (Debian 11)
Screen-recording is still a bit cringe. The builtin Gnome tool is OK, but a bit clunky. I miss Kazam.
Distros are facing a way harder decision on Wayland to make on your behalf, especially as Wayland starts to support some use cases fully while still not hitting others.
Like once I was reading that a product I was an engineer on got a huge contract that I absolutely would have known about and would have been on call for. Remember that a lot of reg stories are banking on the idea that anyone who actually knows better won't break their NDA to inform the public.
This is precisely why I tend to festoon my articles with links, as citations.
In the specialist world of desktop Linux, a lot of the stuff about rival toolkits and display servers is well-known and understood.
For the vast majority of people who work with computers, using Windows or macOS on the desktop and Linux only on servers if that, then this stuff is largely unknown. I try to bridge the gap by providing some context and explanation of what's going on, what it means, what it might lead to and so on.
Actually, from my own personal career history, even people working with Linux on the desktop often don't know much of this stuff. If they know enough to have a preferred distro and desktop, many people look no further.
It's a holiday in the USA, meaning little news from there, and for 2 days where I live in Czechia. It's a slow news time of year. That's why. :-)
Every attempt to do the switch (sometimes forced by bad decisions of distributions) broke essential functionality without any workarounds, so I had to switch back to X11 eventually. I expect this to happen again if I give it another try - be it 1 or 10 years from now.
So I'm sorry, but Wayland is not for me.
I'm using Fedora 36 and everything that I can think of works well.
But if Wayland folks think that having two external displays and screen sharing is an esoteric workflow, I know that my decision was correct.
For what it worth, Wayland has really good externel screen support (mixed-DPI even), so it is likely just a not-yet-supported feature, nothing inherently problematic.
that one works better with wayland than with x11. Especially if the monitors are different dpi.
Multiple external displays works MILES better on wayland - I can set proper scaling ratios set on each screen, which is basically a requirement for a modern laptop with external monitors. No more "This window opened on my laptop screen and will be HUGE on the external monitors because the laptop was scaled for hidpi and the externals aren't". Now the issue is just limited to apps running in x-wayland, and I have close to zero apps that I care about running in x-wayland these days.
Further - I get much more consistent external display output with Wayland. I plug the monitor in and it "just fucking works"tm.
Screen sharing is a pain on basically every modern system - you're letting one application monitor and consume the output on another. Allowing this by default and with no user prompt is a fucking nightmare (and as much as people bitch about "but mah screen sharing!" - there's an equally vocal push from the "but mah system security!" crowd). Wayland struggled here for a bit, but it seems like covid finally pushed the right buttons to get this knocked out in most of the DEs I've used. All the major sharing platforms now seem to work - Slack/Discord/Zoom/Chrome/etc... Including sharing multiple displays now.
So basically - fucking no one thinks this: "But if Wayland folks think that having two external displays and screen sharing is an esoteric workflow"
Mutter is still buggy on Nvidia but I believe KDE should work fine these days unless you're on a distro that doesn't have recent drivers.
With nouveau, it works for up to a minute before freezing and locking the GPU.
I'm not so sure whether this is an nvidia issue or an SDDM issue.
I think external displays in general had problems, but I don't remember many details. I had problems with my docking station under Wayland, scaling options that didn't work. And there was an issue when trying to re-order attached screens with the corresponding Gnome tool.
I think this was on Ubuntu in 2018 or 2019, when they started giving you Wayland by default. But they soon learned that it just wasn't ready yet.
Granted, some of those problems might have been caused by Gnome tools or Ubuntu or maybe even hardware drivers. But all of them were gone immediately once I switched back to X.
But does it also work with multiple external displays? Because it worked on a single screen for me back then, too.
I tried hard to love Wayland but it's just not there yet. I hope it will be sooner, debugging why my keyboard stopped working because a C header file changed slightly in a semi-unrelated package upgrade is very not fun, and yet that's the best there is.
No idea what Wayland has to do with Samba but I'm back to running Xorg yet again.
But that will be the problem, someday: if Wayland ever becomes the primary windowing system to target on Linux, I would expect some things might disappear. Like maybe Steam for X11 stops being a thing. Maybe Mozilla stops releasing an X11 version of Firefox. That would suck. But I do expect I still have at least another decade before that becomes a concern.
Also, this is only for GTK 5, so by the time that even comes out (years) and apps switch to it, we could see widespread wayland support in BSD
There really is no problem with this move.
Yes and no. The GTK developers have stated that GTK now exists for GNOME. Other non-GNOME uses of GTK work through coincidence, and won't be supported or considered as they evolve the GNOME platform. We can already see this with the removal of several features from GTK4 (that were present in GTK3). GTK5 will just be more of the same, and will leave more non-GNOME people behind.
Sure, apps won't have to move from GTK3 or GTK4 to GTK5, but some will. And will someone step up to fork and maintain GTK3 and/or GTK4 when the GTK developers are focused on GTK5 and don't care about the older versions anymore?
Alternatively, maybe we'll see a new toolkit start to gain prominence. After all, GTK5 is many years away, and GTK5-only apps are even further out. There's plenty of time for something new to take the stage. Maybe a Rust-based toolkit will become popular enough to be considered on similarly-equal footing to GTK and Qt. (Certainly the non-Rust binding story would have to be really good for this to be viable, as I can't imagine all those C, C++, Python, etc. devs who use GTK to all become Rust developers.) That would be my hope, but we'll see. There's a lot of time for this to unfold.
I don't know where you heard this, but it's not at all true. This is actually the complete opposite of what they did in GTK4. A lot of the features that were removed were actually GNOME specific features that were simply moved into libadwaita, the thinking was that anyone building a platform on GTK4 can create their own library and put the themes/widgets they want there. Elementary OS also did exactly this with libgranite. The rest of your comment stems from this false assumption, so I think you can retract it.
The libadwaita stuff is also super weird and IMO implemented poorly, and in a way that basically says "if you aren't using GNOME we don't care about you". Want to run an app that uses libadwaita outside of GNOME? Sure, but expect it to look completely out of place since it won't use your desktop theme.
Yes, they were, that is the opposite of what actually happened. The real rationale is explained in the libadwaita release announcement: https://adrienplazas.com/blog/2021/03/31/introducing-libadwa...
>and one of my recent projects simply cannot be built with GTK4 due to features that were removed
Yes, they also deprecated/removed some features that were just broken or not so useful. That's not a GNOME issue.
>the second and third paragraphs still hold
This is just my prediction from looking at some of the existing Rust libraries: There will not be any viable toolkit for general use written in pure Rust. To do so would require a giant investment. If it ever happened, any interested party would want it to be cross-platform because Rust is primarily used as a cross-platform language. And because of that, at best it would become a poor approximation of Qt without any of the benefits. The closest I could ever see conceivably happening would be some WASM-based thing that you can then deploy inside Electron. And I say this as someone who rather dislikes C++ and (in theory) prefers Rust.
>and if GTK5 does eventually drop X11 support, I certainly wouldn't bother with it... unless of course somehow X11 actually disappears.
I don't know why you wouldn't bother with it. The code will probably not ever completely disappear, but X11 itself has already been obsolete for a number of years.
>Want to run an app that uses libadwaita outside of GNOME? Sure, but expect it to look completely out of place since it won't use your desktop theme.
I don't see how this is even a problem. The point of the GNOME app is to follow the GNOME HIG and design patterns. The point of libadwaita is to provide prefab implementations of the GNOME HIG. You can't make an app that follows two design styles at the same time. Like, think about this. Motif or KDE apps also don't look anything like GNOME apps and they look out of place. Windows apps also look completely out of place on GNOME if you run them in Wine, etc. On an open platform nobody can enforce a certain look for any applications. Eventually they will all look weird and out of place somewhere.
Is there any combination of these various X11, Wayland, Gnome etc. things that "just work", and if it does, why isn't everyone liking and using it?
that's pretty much what the latest Ubuntu LTS or Fedora release is. And I think most people are using it, but they're just silent about it. I think the linux community just has some uniquely vocal folks on the other end.
Yes. You got a wonderful set of tools as a result of all the work and time folks put into X.
The problem is that the folks doing most of the lifting in this space right now, the ones still giving their free time and effort, have decided that they'd rather be developing Wayland (it's not all of them, X is still kicking, but it's a lot of them).
You, as a user of the free software produced by real people putting in time and effort, absolutely don't get to bitch about "Loss of choice is a loss" when what you're really saying is "I'd like to force the people working on wayland to continue working on X, because it's beneficial to me".
First, this is unacceptable language. Don't talk to me like that.
Second,
> what you're really saying is "I'd like to force the people working on wayland to continue working on X, because it's beneficial to me".
I never said such. Don't put words in my mouth.
The fragmentation and alternatives of alternatives mess of the Linux Desktop has turned it into a giant contraption full of inconsistency and tons of unnecessary in-fighting between a bunch of devs due to UNIX philosophy or a desktop that simply just works.
It is not early days anymore and it has been over 20 years and the Linux Desktop still has the same problems already present today and is a solution in search of an (already solved) problem at this point.
No wonder that explains why Google was so fed up with desktop Linux they decided to replace it with their own OS (Fuchsia).
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.
> 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.
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 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.