Us Wayland skeptics were always right.
Again -- I know I'm old, but it still boggles my mind how accepting LINUX people became of breaking backward compatibility in this situation. Like, the opposite of that was our whole thing.
Us Wayland skeptics were always right.
Again -- I know I'm old, but it still boggles my mind how accepting LINUX people became of breaking backward compatibility in this situation. Like, the opposite of that was our whole thing.
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.
That says a lot about the state of those two projects.
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.
>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.
[0] https://lists.freedesktop.org/archives/wayland-devel/2014-Ma...
You are right that we can't force wayland dev work on x11 -- all I ask is don't push their new work as default.
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.
https://blog.netbsd.org/tnf/entry/x_org_on_netbsd_the [search "PowerPC"]
Some old X11 coders still work on it, or make suggestions to improve it.
https://lists.x.org/archives/xorg/2024-April/061644.html
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.
> 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.
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.
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.
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?
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
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.