It doesn't matter who was right. It doesn't matter how wrong or broken Wayland is.
It does matter who is willing to work on code. And no one is willing to do the work on the X11 codebase that it needs.
That's it. Plain and simple.
Forking X11 and assuming Vulkan while throwing out everything else is probably pretty doable and would result in a 90% codebase reduction. However, nobody is willing to sling the code to make it happen.
Current Xorg has Glamor, using OpenGL to accelerate the 2D ops of X11. There is also Zink, OpenGL-over-Vulkan for the rare case of Vulkan without native OpenGL.
OTOH, there are people willing to add support for old hardware that probably can't run Vulkan, or even OpenGL, and sometimes they manage to upstream that code. With your "bsder" nick, the following example seems relevant.
But such initiatives lack the "new shiny bling" factor, which seems to be a must nowadays to be a "success". It's the curse of "mostly done, mostly maintenance" projects in a world where breaking ground looks better in a CV than polishing and oiling the machinery others crafted.
The problem is I guess that Xorg, a project nobody is working on, still works better than a project that is on full throttle, full of zealots, evangelists, programmers, designers, thinkers, philosophers.
That says a lot about the state of those two projects.
All that really says about these projects it what's already plainly obvious: X11 is an old project and Wayland hasn't caught up yet for every minor thing you might want it to do. X11 has more than 40 years of development behind it, it isn't easy to catch up to all the features that have been built into and on top of X in the about 8 years (at most) Wayland has been getting the majority of attention.
It's not about coders. It is about the Wayland spec itself missing features that the maintainers of the spec are bike shedding over, for example, color management and HDR.
>8 years (at most) Wayland has been getting the majority of attention.
Color management on Wayland has been discussed for over 10 years by now.[0] In fact this proposal contains code to implement color management! So it is not about code. It is about bikeshedding the spec.
This is my problem with Wayland zealots. First and foremost I want it to display windows on my laptop and my desktop and not freeze my computer on start. Then, I would like to have more than 10 frames per second when it'll finally start. Is that too much to ask? Wayland doesn't deliver these two points on my setup. Should I change my hardware to match your hardware?
Wayland development is already in progress for 15 years. And it sill fails to provide basic screen displaying capabilities. I have nothing against the technology, just against the people running the show. I think Canonical has made a mistake to cancel Mir.
On the contrary, who's willing to work on it isn't what matters either. What matters is whether the code actually does what people need it to do. Now you might very reasonably assume that having devs willing to work on Wayland would lead to that, and that nobody wanting to work on Xorg would cause it to stop working, but in reality that's just not true; Wayland has been preferred by the devs for 16 years and in 2024 is still behind Xorg in meaningful ways. They're finally close, but as someone who keeps looking for ways to make Wayland work it just isn't there.
> Forking X11 and assuming Vulkan while throwing out everything else is probably pretty doable and would result in a 90% codebase reduction. However, nobody is willing to sling the code to make it happen.
The easy way is to move to just using rootful XWayland, which lets you use the fancy new backend while keeping everything else the same. IMHO they really should have implemented that first, moved everyone to the new backend, and then if they really had to push pure Wayland do that after.
Right. So I'm probably unique in that I'm a very long time Linux user who doesn't do much coding myself.
And as such, the Wayland project is the ONLY one that ends up reliably generating the usual e.g. "WELL YOU'RE NOT ALLOWED TO HAVE AN OPINION BECAUSE YOU DONT WORK ON IT YOURSELF" type of retorts.
They're really weird because -- on one hand they're technically true. But on the other, they don't really explain why SO MUCH OTHER free/open source software doesn't have the extreme backwards compatibility breakage that this does.
Why do we get the free magic of people making great backward compatible code with other projects and so painfully not with this one? To me, THATS the interesting question, and cutting it off with WELL, YOURE NOT DOING IT SO YOUR OPINION DOESNT COUNT just is weirdly unhelpful.
> Why do we get the free magic of people making great backward compatible code with other projects and so painfully not with this one? To me, THATS the interesting question, and cutting it off with WELL, YOURE NOT DOING IT SO YOUR OPINION DOESNT COUNT just is weirdly unhelpful.
I can invert your question to: "Why is it that so many people complain so loudly about the X11/Wayland thing and yet so few step in to sling code?"
These projects are relatively old. People know what is broken in X11/Wayland; pointing that out doesn't help very much. What isn't always obvious is how to fix what is broken.
What's left to do is hard. The easy stuff has been done. The grindy but straightforward stuff has also mostly been done. So, what's left is the stuff that is both a lot of work and not at all straightforward.
Given that, what value is there is anyone that isn't bringing code?
If the problem needs a mass of work, the only thing valuable to be brought to the table is code. Alternatively, if somehow a brilliant insight got missed by a ton of experienced people, the only thing that can break the logjam and demonstrate superiority is code.
I'm no fan of Wayland and think it is very much the wrong direction. However, if I'm not willing to commit time, people or money to fix the situation, how much weight does my opinion really carry at the end of the day?
> Why do we get the free magic of people making great backward compatible code with other projects and so painfully not with this one?
And I explained what the difference is.
These projects are old and difficult. Most open source projects are neither.
There are very similar problems with open source domain-specific tools, for example (Musescore, GIMP, FreeCAD, KiCad before CERN decided to fund it, etc.).
Musescore has a nice video about how hard fixing it was and how hard it was to get to Version 3 and then trying to get it to Version 4 and how lucky they sometimes had to get:
https://www.youtube.com/watch?v=Qct6LKbneKQ
Again, though, the weirdness exists; you just mentioned a bunch of niche things (presuming that KiCad is niche, I've never heard of it, so probably)
X/Wayland ain't like that AT ALL. It's something very central to the OS, which just tends to "get taken care of."
Really, my gut is that this is about a slow subconscious shift in culture; in the beginning there were the hippies who shared everything and now GNOME et al want to be 20 devs in a trenchcoat pretending to be Steve Jobs.
> On the contrary, who's willing to work on it isn't what matters either. What matters is whether the code actually does what people need it to do.
That code doesn't write itself. It needs someone motivated to write it.
As someone who reverse engineered a video card and wrote an entire X11 driver almost 3 decades ago, I get this painfully. If I wanted it done, I had to do it myself.
Both X11 and Wayland have some fundamentally wrong architectural choices. The problem is that both X11 and Wayland are sufficiently "good enough" that the activation energy to get traction above either of them is huge. It's a gigantic pile of grunt work until you get to the fun stuff, and nobody who isn't paid money by a company can muster the motivation to overcome it. And people paid by companies are going to solve the problems they are being paid to solve and not much else.
Open source, in general, is having a problem with being stuck in "local minima". Lots of things are good enough to gain sufficient social traction that replacing them with something better is ferociously difficult. (package managers, git, dynamic libraries ... I can go on and on and on ...)
It's part of the reason why I don't try to interfere with the "Rewrite It In Rust(tm)" brigade even when I think it's a silly idea. It is now a bigger problem to corral the motivation to do something in open source than gaining the technical skill to do it.
It does matter who is willing to work on code. And no one is willing to do the work on the X11 codebase that it needs.
That's it. Plain and simple.
Forking X11 and assuming Vulkan while throwing out everything else is probably pretty doable and would result in a 90% codebase reduction. However, nobody is willing to sling the code to make it happen.