Like most other dissemination piece it starts with ‘X is bad mmkay’ then says nothing technical about Wayland, just handwavey magic and that they used a library that abstracts away the implementation details and is happy about it. Good for them.
So to add contrast.
I’ve coded system graphics since the mid 90ies. I’ve implemented X11 for proprietary actors when that was a thing, I worked on Android SurfaceFlinger. I maintain my own Xorg fork. I have dug through near all solutions in this space throughout its history for local and remote cases. I completed a Ph.D on use of networked display servers in critical infrastructure.
As polite as I can put it. Wayland is the biggest pile of shit I have had the displeasure to work with - give or take some GSM protocols and ASN1.
Back in ’08 or ‘09 when I first started following the repo, trying to figure out if it had more or less potential than the now defunct and forgotten Fresco it was a ‘meh, ok this is DirectFB like space with a dumber take on Microsoft COM’. When it reached “1.0” or alpha as it should’ve been called I implemented it from spec and landed at ‘ok, where is the rest of it?’. Big chunks were missing, and to this day, if you just follow the ‘stable’ interfaces - absolutely nothing will actually run.
Wayland missed the mark of achieving the ‘simplification of X11’ goal, but repeated all the same mistakes, and added some substantial new ones. Systemic complexity has easily doubled the last two years alone and a bad situation is now worse.
Ironically enough, Mir was substantially better in every conceivable way, but just as there was zero technical discussion had when the window of opportunity was there, you just get the usual dissent threads and infinitely many “weeell achtually it is a protocol what you mean is …” zipping past each other. There is also a boiling kettle of Internet-primed hate ready to amplify anything negative, so the interest in providing the breakdown and the references to back it up is down to about zero.
If anyone is actually interested in doing the work of mentally digging through it systemically to get an understanding from what is cooking, I suggest two points of interest to trace from.
https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 - this has been there since day one. It is hard to find a bigger alarm bell. Maybe the libffi breaking non-executble stack for a decade without anyone noticing, or ftruncate() on the keyboard map issue, or … the list is long.
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4157 - there is over 50 examples of this in wlroots git alone (I stopped manually counting). The same pattern can be found in mutter, kwin, weston, arcan-wayland. These are all exploitable LPEs. There couldn’t be a worse language than C to try and squeeze in a Java-90ies-OO style of factoryinstancemanagerfactoryfactory. Then do it completely asynch. With extremely unclear allocation semantics and client driven allocations. Then figure out that there are tons of implicit synchronisation points and there’s now an unfixable amount of race conditions.
This is a great example of the sort of thing I was complaining about in the Red Hat story: once Red Hat decides that something is The Future(tm), everyone else has to adopt it because they push so many other projects to make it the default. Even Canonical was unable to push Mir in the face of this. This isn’t done by building a consensus around the right approach and then funding engineers to implement it, it’s done by pushing everyone else to adopt whatever Red Hat engineers have decided is the thing to do.
A lot of the push for adoption of Wayland was driven by appeals to authority (‘these people have worked on X11 for 20+ years!’), rather than technical merits. I found a number of these annoying because a lot of the problems with X.org had been fixed by proprietary window servers (including some proprietary X forks!) and the people still working on X.org were the people that hadn’t fixed any of them. As with systemd, a lot of the arguments were of the form:
A has a load of problems.
B is not A, and is therefore better.
If you criticise B, you must like A, but we’ve established that A sucks and so your opinion is worthless.
The idea that someone could see a lot of flaws in X11 (or SysV init) but not automatically think that Wayland (or systemd) was the right solution to them was not a permitted opinion. I think we both agree that there are a lot of problems with X11 and that a replacement is long overdue. I won’t reiterate any of that here, because anyone who actually wants to know what’s wrong with X and what needs fixing should just read your Arcan blog (which also explains how to fix them, and even comes with code!) rather than reading things I write here.
A lot of the push for adoption of Wayland was driven by appeals to authority (‘these people have worked on X11 for 20+ years!’), rather than technical merits.
I mean if, as an application developer, or distribution maintainer want to put all your eggs in the basked that all the devs jumped out of, I don’t see who prevented you to do so.
The idea that someone could see a lot of flaws in X11 (or SysV init) but not automatically think that Wayland (or systemd) was the right solution to them was not a permitted opinion.
I mean I don’t know where you’ve been hanging out for all this time, but hating on systemd and Wayland (and, let’s not forget pulseaudio) was/is very fashionable - as maybe this very thread shows.
For me, as a user of a distribution, want to run some reasonably modern stack, the fact that it’s Xorg or Wayland based is less important than being maintained by people that know what they’re doing. I’m willing to trust them over /u/crazyloglad about which API is shit.
I mean if, as an application developer, or distribution maintainer want to put all your eggs in the basked that all the devs jumped out of, I don’t see who prevented you to do so.
You realise that, in reply to a post where I complained the anyone who sees flaws in Wayland is assumed think X11 is good, you replied by telling me I should go back to X11?
I was addressing your previous point, which is that somehow wayland was popular because some nebulous appeals to authority.
But, in fairness, I don’t understand why when you complain about both options being bad (except that from your post it’s clear that that Wayland is the worse of the two), I am not allowed to assume that you’d prefer using Xorg.
We should be able to evaluate objective reality without such terms. If you take any technical criticism as being just “hating on” something, it is hard to fix things.
maintained by people that know what they’re doing
You evaluate this by evaluating their decisions and arguments. This can be done independently of the speaker’s identity, popularity, or even tone.
In this thread, Adam, I have seen no such technical criticism. “Fractional scaling is a hack” is not a valid technical opinion despite you agreeing with it. “Wayland is the biggest pile of shit” is not a technical opinion, is a just a dude being disagreeable on the internet about other people’s work.
This is a great example of the sort of thing I was complaining about in the Red Hat story: once Red Hat decides that something is The Future(tm), everyone else has to adopt it because they push so many other projects to make it the default.
Let’s hope IBM/RedHat doesn’t decide to also reintroduce all the tricks of the 50-90ies.
A lot of the push for adoption of Wayland was driven by appeals to authority (‘these people have worked on X11 for 20+ years!’), rather than technical merits. I found a number of these annoying because a lot of the problems with X.org had been fixed by proprietary window servers (including some proprietary X forks!) and the people still working on X.org were the people that hadn’t fixed any of them.
Bingo. There is a lot to be learned from checking which prominent figures that did contribute a lot to Xorg and /quit outright, never moved on, or left Wayland early. RH is piggybacking on authority that isn’t there. DWM/Quartz managed to gradually evolve, even with the WM_MESSAGE ‘massage’ around.
I think we both agree that there are a lot of problems with X11 and that a replacement is long overdue.
Still looking forward to whatever IRL romp session where those will be vented :). Surprisingly enough, an article I have in the queue is “Bringing X along for the Ride” as there is a much better transition story to be had. Funny enough, XMir shows traces that Alan Griffiths et al. saw that as well, and a former Wayland maintainer(!) even right out said that hey, this is religious fundamentalism, what the hell?
Ironically enough, Mir was substantially better in every conceivable way
I heard this a long time ago (from a single comment on /r/linux and I think a blog post), but since then I haven’t been able to track them down. Basically all of the Mir discussion I’ve seen was about Mark Shuttleworth’s conduct towards Wayland devs, rather than any technical comparison.
I’m not sure where to find serious technical discussion on Mir, so whenever I see a comment that basically goes “Canonical’s idiotic NIH (Upstart, Snap, Mir) is…”, I don’t feel informed enough to contradict the “Mir is pointless” narrative. And if everyone else does the same, then the sentiment is amplified unchallenged.
So in all seriousness, you should write a blog post comparing Wayland and Mir. Please use small words.
Wayland missed the mark of achieving the ‘simplification of X11’ goal, but repeated all the same mistakes, and added some substantial new ones. Systemic complexity has easily doubled the last two years alone and a bad situation is now worse.
I found this particularly disappointing because several of the things Wayland aimed for – including simplifying X11 – didn’t need particularly vast efforts of innovation, there was a lot of prior art available on it, not just in alternative windowing systems like Fresco or Mir but even in a lot of X11 implementations from the ‘90s and early ‘00s. And I don’t mean academic speculation on how one might write a better display server, I mean working programs (that occasionally cost a lot of money, too, so you know they accommodated some real-life quirks – they weren’t primarily a research exercise, they were viable commercial endeavours, at least for a while).
Designing “the perfect” display server, as in, substantially advancing the frontier of our knowledge of display servers and our practice of writing them, is certainly a very difficult task. However, with all the existing literature, and all the display servers written so far, designing and implementing something substantially better than Wayland is something that a few motivated masters’ students can achieve with the right guidance. New paradigms would help; but just applying some twenty year-old lessons to existing paradigms would still take you farther than Wayland.
It certainly didn’t help that, as @david_chisnall pointed out elsewhere, the wider community was largely divided in three groups: people who followed Wayland adoption because they had no choice, people who followed the Wayland hype because it’s shiny, and people who hated Wayland because it’s new. This mostly resulted in doubling down on existing mistakes and lots of hate, with very little alternative code (Arcan notwithstanding – it’s the reason I finally sat down and started learning Lua!) produced in the process. That made the sensible middle ground of “let’s finally bury X11 but maybe not replace it with Wayland” feel like some weird hipster take.
And I don’t mean academic speculation on how one might write a better display server, I mean working programs (that occasionally cost a lot of money, too, so you know they accommodated some real-life quirks – they weren’t primarily a research exercise, they were viable commercial endeavours, at least for a while).
That is part of what is so bizarre and disrespectful of their own supposed legacy. For a simplification to work with such a strong established base, the very least you can do, basic hygiene even, is to jot down the major scenarios and throw that against whatever proposed solution you have, for extra credit, outsource that to the community “what is important to you?”. Having all the nasty requirements engineering done for you and focus on competitive intelligence is a great position to be in. That was all squandered. Checking the mailing lists and chat logs of the time, there is basically zero acknowledgement of anything outside of little ol’ X11. That’s borderline criminal neglect.
Even in its ‘too simple to work’ form they brought the arguably worst parts of X with them. Since you know the Wayland innards well enough, the ‘engagement window’ has closed and foul language has filtered others – ignoring all the inane registry/wl_compositor/wl_shell/wl_buffer/wl_surface/wl_seat foreplay what was the approach to solve the fairly common task of ‘I press a key, the program should get the codepoint(s) I intended it to generate’?.
“Well you first compile the tree of Xorg keymaps representing the rules,model,variant and options you want, serialize that into a text representation (60+KiB for a simple on), write that to a temporary file, grab the descriptor of that file, send it over a socket, have the other end read it, and reconstruct the Xkb state machine then to proceed to feed the linux kernel specific set of keycodes into it (don’t forget to add +8 to the value) and out comes your codepoint. See. Simple.
There’s even more to it, but it suffices to illustrate the point. Even here the ‘spec’ has brought in two necessary but insufficient extra ones that are about as well documented and accessible as libxcb and we have still to actually do anything with it.
Take the trope on Wayland not supporting screen sharing. “Yes it does, you just use xdg_desktop_portal and pipewire and…”. Those are of course not at all “Wayland” but two completely different IPC systems (xdg_desktop_portal being an overlay spec on D-Bus and Pipewire reinventing Gstreamer for whatever reason).
So they spent project-death amount of resources establishing how to share a buffer from a lower privileged source (client) to a mixing/blending/resampling function (compositor) – failing the basics with that from what the pixels represent (colour correctness) and when they represent what (synch). Then when someone goes “ok can I use the composited results to feed a lower privileged sink?” the response was “not our problem” and instead this hairball of a solution emerge. One that also broke what little network transparency they managed to get after 3+ years of work and a GSOC on the topic.
Funny enough, if you look at comment threads on HN/OSnews etc. and single out the ones that try to get anywhere solution wise their proposed solution either reinvents Android or repeats the same schtick that led to Wayland in the first place.
Simplicity is systemic. It is not a single component but the entire thing that gets used. This is where I think requirements engineering take on software engineering should’ve had their strongest win.
It is a pathology in FOSS to rewrite the same thing again and again in whatever tech-trend of the day and expect simpler results - sudo in Rust anyone?. At most what it does is reduce features to the set covered by the stakeholders that still have enough of a voice/care to be vocal if something was taken from them - that is reductionist.
I am worrying over an argument in my head that the “bazaar” method of software development is a) a canard and b) always leads to poor outcomes on technical measures.
They do seem to converge on a lukewarm agreeable core of least resistance and then vehemently reject adjustments to the plotted course, easy pickings for EEE practices — but it is a hard generalisation to get anywhere with.
sudo is an awful kind of program to write in C. It needs unit tests, it needs safe parsers for its complicated config language, it deals with .so plugins, it needs to be memory safe and robust to inputs.
OpenBSD guys quit in disgust and wrote doas as a reaction to sudo systemic complexity.
Wayland the protocol is actually pretty nice and well-defined. The problem is that it defines too little, so when saying “Wayland is pretty good”, this heavily depends on the compositor of choice. Every compositor has to bring around 10.000 SLOC of boilerplate and support dozens of “proprietary” (in terms of “follow the most popular compositors and libraries”, like wlroots and sway, which define quite a few custom extensions) extensions for basic stuff. Wayland itself merely is a very very thin layer for basic client- and buffer-management, because the designers were thinking of any possible case a GUI might be implemented apart from the default rectangular forms we are used to.
X may be large and dated, but at least it comes with everything you mostly need and an X window manager does not need to reinvent the wheel.
The Wayland team, in my opinion, really dropped the ball here in this regard. Wayland could have been the incubator for a proper Linux desktop with e.g. native color space support, native high-DPI, a vector-based-model (all-rendered was a step back imho), even better network transparency for fully remote-access and plenty other things that are missing in X. Instead we got this mess.
It would have been much better to keep the “freeform”-approach and allow crazy compositors/window-managers, but the burden would’ve been for the special cases to deselect certain default assumptions rather than the opposite. To give a concrete example, if your compositor/window-manager does not allow spawning a window at the top or in the center, simply ignore the request or print a warning (which might be well-reflected in a good API). With Wayland, window-placement-requests are simply not supported by default and you instead have to resort to one of the said proprietary extensions. This just leads to a horrible monoculture, as if we hadn’t learnt anything from the browser wars.
And we wouldn’t have needed standardization, just a proper foundational library by Freedesktop.org with well-defined interfaces that encourage reimplementation, if wanted, in a server-client model (i.e. the compositor/window-manager being a client to a proper server with an broad well-defined API) and not a util-library like wlroots that sits on top of a thin API. Such a reimplementation would still only be at most as complex as implementing a single bloody compositor in Wayland!
It is an antipattern that libraries like wlroots have to exist! If you replace wlroots and sway above with Webkit and Chrome, my point should become even clearer.
This is what I’d say about Wayland’s awful design. X’s biggest problem is that nobody has standardized it formally, so there’s no guarantee of compatibility between applications from different vendors. I find this particularly frustrating since it is so easy to solve! They just need to define a root window property that carries the per-monitor factors. It is very easy to implement on the toolkit level (assuming you already implemented the scaling itself, of course, which is generally true.)
Anyway, hacky fractional scaling is when you originally draw to a larger integer multiplier, then scale that back down to the requested fraction. Basically you tell the app to zoom in on itself then the compositor to zoom back. This is a big waste of computer resources and still leads to bad results - likely blurry text, undefined edges, possible loss of detail in different images (e.g. why css has image-rendering: pixelated). It is just not a very good solution,and never will be, because the compositor doesn’t know what is inside the window, so it treats it all as a big generic image. (And again, css image-rendering is there because not all images even zoom the same way!) It might be better than nothing for applications that don’t actually support scaling themselves…. sometimes. But it certainly shouldn’t be your first choice.
Yet, until last year, that was the only option Wayland offered! And even now, the better protocol is labeled as “staging”: https://wayland.app/protocols/fractional-scale-v1 with just one implementation listed. And I’m still not convinced this is actually a good solution, the text is a bit unclear (or should I say it has some blurriness and/or gaps?) on exactly how it works, but it at least looks like it’d provide the necessary information to applications.
I’ll grant that X also lets you do it poorly with legacy support or to do it better with cooperative clients, but that’s not standardized between vendors…. and Wayland, a decade after saying X is obsolete, is just now catching up to being able to say the same thing.
Could you name a couple examples? Here you just mentioned a missing feature, but “awful design” strongly hints at wrong features, or a misdirected architecture, or some technical decision that holds them back…
Well, my post here was about fractional scaling in particular, but there’s similar things in other areas too - the accessibility tools story on wayland is still not great today, text input methods still not stable, their resistance to global positioning and hotkey capture didn’t survive contact with the real world.
There’s a youtube by a Wayland evangelist that mocks X for having several extensions and client protocols, making it overcomplicated. They’d wipe the slate clean, they said. Well, now, ten years later, Wayland now has more extensions than X did at the time they made that video! And a few of them are just straight clones of X’s functionality. Perhaps they should have studied Chesterton’s Fence before knocking it down.
And this is why I call these things bad designs, including the fractional scaling approach. These things were not novel problems that arose after-the-fact (well…. ok, the approach to fractional scaling did change in Windows and X after Wayland came out, but Wayland took its sweet time even following them; ironic that the “legacy” systems were ahead of the new kid on the block for many years in supporting newer hardware and functionality). They could have investigated why X (or why Microsoft Windows, or Apple’s OS) did things the way they did and saved some iterations, learning from the past. But instead they had to learn the lessons of history the hard way. Again.
Do YOU want to sit in committee meetings, submit proposals, and write technical docs to make the situation better? I sure as hell don’t. But that’s what it would take to accomplish these improvements.
Well, I’ve never been on the freedesktop.org committee, tbh, I don’t even know how their processes work. I don’t think they actually have a formal committee, but I might as well subscribe to the xdg mailing list and see about talking to them. Subscribed right now.
But speaking of committee meetings, I do sit on several committees irl in my city’s local government, so technically my answer to this is yes, not only do I want to (I volunteered for each of these), I actually do, several times a month. Actually, comparing and contrasting my experience on formal government committees with my experience in open source…. I really prefer working with city hall than with most open source projects. If the city passes a new law, at least there’s a public hearing and some migration path to avoid breakage!
Funnily, everybody screamed at systemd for being the devil, and wayland to be the savior.
But I’m quite happy with what systemd brought to me, and I am still delaying upgrading to wayland because of all the things it broke every time I tried (steam games, secondary display, getting back from sleep mode, etc).
Wayland looks pretty nice, though I never could figure out how to get most applications to work with it. With Emacs, for example, commands that took a while lead to an error “Lost connection to Wayland compositor”. I suspect GTK4 or whatever Emacs was using missed too many ticks in some window update thread -> wayland thinks it is dead and killed it.
A month ago, with Arch, Sway & AMD GPU, I ran into the same error with any apps that hung for a few seconds. With Emacs, it was easy to replicate as I only had to save a bigger file to initiate the lsp-format.
The two missing features are two I need pretty badly. Color management is important as is getting the full range of your wide-gamut / HDR displays. …And also the Thunderbolt dock I picked up last year uses DisplayLink (ignorant that this is something I needed to check).
I tried and liked sway for 1½ years, but I had to move back to xmonad.
I’m sure Wayland is really cool, if it would work on my machine. My only Wayland exposure resulted in seeing the desktop animate with 1 frame per second, freeze the OS completely, or not start at all. So I use X.
Okay, I’m using KDE then. It has 1 FPS, but at least it kind of works, but when I check out GNOME, the GUI doesn’t even start, and requires force resetting the machine.
Not that it’s really important. X works for me, at least until I’ll buy myself a 4k monitor ;)
Like most other dissemination piece it starts with ‘X is bad mmkay’ then says nothing technical about Wayland, just handwavey magic and that they used a library that abstracts away the implementation details and is happy about it. Good for them.
So to add contrast.
I’ve coded system graphics since the mid 90ies. I’ve implemented X11 for proprietary actors when that was a thing, I worked on Android SurfaceFlinger. I maintain my own Xorg fork. I have dug through near all solutions in this space throughout its history for local and remote cases. I completed a Ph.D on use of networked display servers in critical infrastructure.
As polite as I can put it. Wayland is the biggest pile of shit I have had the displeasure to work with - give or take some GSM protocols and ASN1.
Back in ’08 or ‘09 when I first started following the repo, trying to figure out if it had more or less potential than the now defunct and forgotten Fresco it was a ‘meh, ok this is DirectFB like space with a dumber take on Microsoft COM’. When it reached “1.0” or alpha as it should’ve been called I implemented it from spec and landed at ‘ok, where is the rest of it?’. Big chunks were missing, and to this day, if you just follow the ‘stable’ interfaces - absolutely nothing will actually run.
Wayland missed the mark of achieving the ‘simplification of X11’ goal, but repeated all the same mistakes, and added some substantial new ones. Systemic complexity has easily doubled the last two years alone and a bad situation is now worse.
Ironically enough, Mir was substantially better in every conceivable way, but just as there was zero technical discussion had when the window of opportunity was there, you just get the usual dissent threads and infinitely many “weeell achtually it is a protocol what you mean is …” zipping past each other. There is also a boiling kettle of Internet-primed hate ready to amplify anything negative, so the interest in providing the breakdown and the references to back it up is down to about zero.
If anyone is actually interested in doing the work of mentally digging through it systemically to get an understanding from what is cooking, I suggest two points of interest to trace from.
https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 - this has been there since day one. It is hard to find a bigger alarm bell. Maybe the libffi breaking non-executble stack for a decade without anyone noticing, or ftruncate() on the keyboard map issue, or … the list is long.
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4157 - there is over 50 examples of this in wlroots git alone (I stopped manually counting). The same pattern can be found in mutter, kwin, weston, arcan-wayland. These are all exploitable LPEs. There couldn’t be a worse language than C to try and squeeze in a Java-90ies-OO style of factoryinstancemanagerfactoryfactory. Then do it completely asynch. With extremely unclear allocation semantics and client driven allocations. Then figure out that there are tons of implicit synchronisation points and there’s now an unfixable amount of race conditions.
This is a great example of the sort of thing I was complaining about in the Red Hat story: once Red Hat decides that something is The Future(tm), everyone else has to adopt it because they push so many other projects to make it the default. Even Canonical was unable to push Mir in the face of this. This isn’t done by building a consensus around the right approach and then funding engineers to implement it, it’s done by pushing everyone else to adopt whatever Red Hat engineers have decided is the thing to do.
A lot of the push for adoption of Wayland was driven by appeals to authority (‘these people have worked on X11 for 20+ years!’), rather than technical merits. I found a number of these annoying because a lot of the problems with X.org had been fixed by proprietary window servers (including some proprietary X forks!) and the people still working on X.org were the people that hadn’t fixed any of them. As with systemd, a lot of the arguments were of the form:
The idea that someone could see a lot of flaws in X11 (or SysV init) but not automatically think that Wayland (or systemd) was the right solution to them was not a permitted opinion. I think we both agree that there are a lot of problems with X11 and that a replacement is long overdue. I won’t reiterate any of that here, because anyone who actually wants to know what’s wrong with X and what needs fixing should just read your Arcan blog (which also explains how to fix them, and even comes with code!) rather than reading things I write here.
I mean if, as an application developer, or distribution maintainer want to put all your eggs in the basked that all the devs jumped out of, I don’t see who prevented you to do so.
I mean I don’t know where you’ve been hanging out for all this time, but hating on systemd and Wayland (and, let’s not forget pulseaudio) was/is very fashionable - as maybe this very thread shows.
For me, as a user of a distribution, want to run some reasonably modern stack, the fact that it’s Xorg or Wayland based is less important than being maintained by people that know what they’re doing. I’m willing to trust them over /u/crazyloglad about which API is shit.
You realise that, in reply to a post where I complained the anyone who sees flaws in Wayland is assumed think X11 is good, you replied by telling me I should go back to X11?
I was addressing your previous point, which is that somehow wayland was popular because some nebulous appeals to authority.
But, in fairness, I don’t understand why when you complain about both options being bad (except that from your post it’s clear that that Wayland is the worse of the two), I am not allowed to assume that you’d prefer using Xorg.
We should be able to evaluate objective reality without such terms. If you take any technical criticism as being just “hating on” something, it is hard to fix things.
You evaluate this by evaluating their decisions and arguments. This can be done independently of the speaker’s identity, popularity, or even tone.
In this thread, Adam, I have seen no such technical criticism. “Fractional scaling is a hack” is not a valid technical opinion despite you agreeing with it. “Wayland is the biggest pile of shit” is not a technical opinion, is a just a dude being disagreeable on the internet about other people’s work.
“Fractional scaling is a hack” is a quote from the OP link, referring to X’s approach, and I disagreed with it, as used in that context.
Erm, I read your post completely the opposite of that. Maybe I’m tired. Apologies for the confusion.
Let’s hope IBM/RedHat doesn’t decide to also reintroduce all the tricks of the 50-90ies.
Bingo. There is a lot to be learned from checking which prominent figures that did contribute a lot to Xorg and /quit outright, never moved on, or left Wayland early. RH is piggybacking on authority that isn’t there. DWM/Quartz managed to gradually evolve, even with the WM_MESSAGE ‘massage’ around.
Still looking forward to whatever IRL romp session where those will be vented :). Surprisingly enough, an article I have in the queue is “Bringing X along for the Ride” as there is a much better transition story to be had. Funny enough, XMir shows traces that Alan Griffiths et al. saw that as well, and a former Wayland maintainer(!) even right out said that hey, this is religious fundamentalism, what the hell?
If you make it to Cambridge, I’ll buy you a beer or n.
I heard this a long time ago (from a single comment on /r/linux and I think a blog post), but since then I haven’t been able to track them down. Basically all of the Mir discussion I’ve seen was about Mark Shuttleworth’s conduct towards Wayland devs, rather than any technical comparison.
I’m not sure where to find serious technical discussion on Mir, so whenever I see a comment that basically goes “Canonical’s idiotic NIH (Upstart, Snap, Mir) is…”, I don’t feel informed enough to contradict the “Mir is pointless” narrative. And if everyone else does the same, then the sentiment is amplified unchallenged.
So in all seriousness, you should write a blog post comparing Wayland and Mir. Please use small words.
I found this particularly disappointing because several of the things Wayland aimed for – including simplifying X11 – didn’t need particularly vast efforts of innovation, there was a lot of prior art available on it, not just in alternative windowing systems like Fresco or Mir but even in a lot of X11 implementations from the ‘90s and early ‘00s. And I don’t mean academic speculation on how one might write a better display server, I mean working programs (that occasionally cost a lot of money, too, so you know they accommodated some real-life quirks – they weren’t primarily a research exercise, they were viable commercial endeavours, at least for a while).
Designing “the perfect” display server, as in, substantially advancing the frontier of our knowledge of display servers and our practice of writing them, is certainly a very difficult task. However, with all the existing literature, and all the display servers written so far, designing and implementing something substantially better than Wayland is something that a few motivated masters’ students can achieve with the right guidance. New paradigms would help; but just applying some twenty year-old lessons to existing paradigms would still take you farther than Wayland.
It certainly didn’t help that, as @david_chisnall pointed out elsewhere, the wider community was largely divided in three groups: people who followed Wayland adoption because they had no choice, people who followed the Wayland hype because it’s shiny, and people who hated Wayland because it’s new. This mostly resulted in doubling down on existing mistakes and lots of hate, with very little alternative code (Arcan notwithstanding – it’s the reason I finally sat down and started learning Lua!) produced in the process. That made the sensible middle ground of “let’s finally bury X11 but maybe not replace it with Wayland” feel like some weird hipster take.
That is part of what is so bizarre and disrespectful of their own supposed legacy. For a simplification to work with such a strong established base, the very least you can do, basic hygiene even, is to jot down the major scenarios and throw that against whatever proposed solution you have, for extra credit, outsource that to the community “what is important to you?”. Having all the nasty requirements engineering done for you and focus on competitive intelligence is a great position to be in. That was all squandered. Checking the mailing lists and chat logs of the time, there is basically zero acknowledgement of anything outside of little ol’ X11. That’s borderline criminal neglect.
Even in its ‘too simple to work’ form they brought the arguably worst parts of X with them. Since you know the Wayland innards well enough, the ‘engagement window’ has closed and foul language has filtered others – ignoring all the inane registry/wl_compositor/wl_shell/wl_buffer/wl_surface/wl_seat foreplay what was the approach to solve the fairly common task of ‘I press a key, the program should get the codepoint(s) I intended it to generate’?.
“Well you first compile the tree of Xorg keymaps representing the rules,model,variant and options you want, serialize that into a text representation (60+KiB for a simple on), write that to a temporary file, grab the descriptor of that file, send it over a socket, have the other end read it, and reconstruct the Xkb state machine then to proceed to feed the linux kernel specific set of keycodes into it (don’t forget to add +8 to the value) and out comes your codepoint. See. Simple.
There’s even more to it, but it suffices to illustrate the point. Even here the ‘spec’ has brought in two necessary but insufficient extra ones that are about as well documented and accessible as libxcb and we have still to actually do anything with it.
Take the trope on Wayland not supporting screen sharing. “Yes it does, you just use xdg_desktop_portal and pipewire and…”. Those are of course not at all “Wayland” but two completely different IPC systems (xdg_desktop_portal being an overlay spec on D-Bus and Pipewire reinventing Gstreamer for whatever reason).
So they spent project-death amount of resources establishing how to share a buffer from a lower privileged source (client) to a mixing/blending/resampling function (compositor) – failing the basics with that from what the pixels represent (colour correctness) and when they represent what (synch). Then when someone goes “ok can I use the composited results to feed a lower privileged sink?” the response was “not our problem” and instead this hairball of a solution emerge. One that also broke what little network transparency they managed to get after 3+ years of work and a GSOC on the topic.
Funny enough, if you look at comment threads on HN/OSnews etc. and single out the ones that try to get anywhere solution wise their proposed solution either reinvents Android or repeats the same schtick that led to Wayland in the first place.
Why does it feel like every other modern project out there falls into exactly this trap? Frustrating.
Simplicity is systemic. It is not a single component but the entire thing that gets used. This is where I think requirements engineering take on software engineering should’ve had their strongest win.
It is a pathology in FOSS to rewrite the same thing again and again in whatever tech-trend of the day and expect simpler results - sudo in Rust anyone?. At most what it does is reduce features to the set covered by the stakeholders that still have enough of a voice/care to be vocal if something was taken from them - that is reductionist.
I am worrying over an argument in my head that the “bazaar” method of software development is a) a canard and b) always leads to poor outcomes on technical measures.
They do seem to converge on a lukewarm agreeable core of least resistance and then vehemently reject adjustments to the plotted course, easy pickings for EEE practices — but it is a hard generalisation to get anywhere with.
sudois an awful kind of program to write in C. It needs unit tests, it needs safe parsers for its complicated config language, it deals with .so plugins, it needs to be memory safe and robust to inputs.OpenBSD guys quit in disgust and wrote
doasas a reaction to sudo systemic complexity.I am rooting for sudo in Rust.
Wayland the protocol is actually pretty nice and well-defined. The problem is that it defines too little, so when saying “Wayland is pretty good”, this heavily depends on the compositor of choice. Every compositor has to bring around 10.000 SLOC of boilerplate and support dozens of “proprietary” (in terms of “follow the most popular compositors and libraries”, like wlroots and sway, which define quite a few custom extensions) extensions for basic stuff. Wayland itself merely is a very very thin layer for basic client- and buffer-management, because the designers were thinking of any possible case a GUI might be implemented apart from the default rectangular forms we are used to.
X may be large and dated, but at least it comes with everything you mostly need and an X window manager does not need to reinvent the wheel.
The Wayland team, in my opinion, really dropped the ball here in this regard. Wayland could have been the incubator for a proper Linux desktop with e.g. native color space support, native high-DPI, a vector-based-model (all-rendered was a step back imho), even better network transparency for fully remote-access and plenty other things that are missing in X. Instead we got this mess.
It would have been much better to keep the “freeform”-approach and allow crazy compositors/window-managers, but the burden would’ve been for the special cases to deselect certain default assumptions rather than the opposite. To give a concrete example, if your compositor/window-manager does not allow spawning a window at the top or in the center, simply ignore the request or print a warning (which might be well-reflected in a good API). With Wayland, window-placement-requests are simply not supported by default and you instead have to resort to one of the said proprietary extensions. This just leads to a horrible monoculture, as if we hadn’t learnt anything from the browser wars.
And we wouldn’t have needed standardization, just a proper foundational library by Freedesktop.org with well-defined interfaces that encourage reimplementation, if wanted, in a server-client model (i.e. the compositor/window-manager being a client to a proper server with an broad well-defined API) and not a util-library like wlroots that sits on top of a thin API. Such a reimplementation would still only be at most as complex as implementing a single bloody compositor in Wayland!
It is an antipattern that libraries like wlroots have to exist! If you replace wlroots and sway above with Webkit and Chrome, my point should become even clearer.
This is what I’d say about Wayland’s awful design. X’s biggest problem is that nobody has standardized it formally, so there’s no guarantee of compatibility between applications from different vendors. I find this particularly frustrating since it is so easy to solve! They just need to define a root window property that carries the per-monitor factors. It is very easy to implement on the toolkit level (assuming you already implemented the scaling itself, of course, which is generally true.)
Anyway, hacky fractional scaling is when you originally draw to a larger integer multiplier, then scale that back down to the requested fraction. Basically you tell the app to zoom in on itself then the compositor to zoom back. This is a big waste of computer resources and still leads to bad results - likely blurry text, undefined edges, possible loss of detail in different images (e.g. why css has image-rendering: pixelated). It is just not a very good solution,and never will be, because the compositor doesn’t know what is inside the window, so it treats it all as a big generic image. (And again, css image-rendering is there because not all images even zoom the same way!) It might be better than nothing for applications that don’t actually support scaling themselves…. sometimes. But it certainly shouldn’t be your first choice.
Yet, until last year, that was the only option Wayland offered! And even now, the better protocol is labeled as “staging”: https://wayland.app/protocols/fractional-scale-v1 with just one implementation listed. And I’m still not convinced this is actually a good solution, the text is a bit unclear (or should I say it has some blurriness and/or gaps?) on exactly how it works, but it at least looks like it’d provide the necessary information to applications.
I’ll grant that X also lets you do it poorly with legacy support or to do it better with cooperative clients, but that’s not standardized between vendors…. and Wayland, a decade after saying X is obsolete, is just now catching up to being able to say the same thing.
Could you name a couple examples? Here you just mentioned a missing feature, but “awful design” strongly hints at wrong features, or a misdirected architecture, or some technical decision that holds them back…
Well, my post here was about fractional scaling in particular, but there’s similar things in other areas too - the accessibility tools story on wayland is still not great today, text input methods still not stable, their resistance to global positioning and hotkey capture didn’t survive contact with the real world.
There’s a youtube by a Wayland evangelist that mocks X for having several extensions and client protocols, making it overcomplicated. They’d wipe the slate clean, they said. Well, now, ten years later, Wayland now has more extensions than X did at the time they made that video! And a few of them are just straight clones of X’s functionality. Perhaps they should have studied Chesterton’s Fence before knocking it down.
And this is why I call these things bad designs, including the fractional scaling approach. These things were not novel problems that arose after-the-fact (well…. ok, the approach to fractional scaling did change in Windows and X after Wayland came out, but Wayland took its sweet time even following them; ironic that the “legacy” systems were ahead of the new kid on the block for many years in supporting newer hardware and functionality). They could have investigated why X (or why Microsoft Windows, or Apple’s OS) did things the way they did and saved some iterations, learning from the past. But instead they had to learn the lessons of history the hard way. Again.
Do YOU want to sit in committee meetings, submit proposals, and write technical docs to make the situation better? I sure as hell don’t. But that’s what it would take to accomplish these improvements.
Well, I’ve never been on the freedesktop.org committee, tbh, I don’t even know how their processes work. I don’t think they actually have a formal committee, but I might as well subscribe to the xdg mailing list and see about talking to them. Subscribed right now.
But speaking of committee meetings, I do sit on several committees irl in my city’s local government, so technically my answer to this is yes, not only do I want to (I volunteered for each of these), I actually do, several times a month. Actually, comparing and contrasting my experience on formal government committees with my experience in open source…. I really prefer working with city hall than with most open source projects. If the city passes a new law, at least there’s a public hearing and some migration path to avoid breakage!
Funnily, everybody screamed at systemd for being the devil, and wayland to be the savior.
But I’m quite happy with what systemd brought to me, and I am still delaying upgrading to wayland because of all the things it broke every time I tried (steam games, secondary display, getting back from sleep mode, etc).
Wayland looks pretty nice, though I never could figure out how to get most applications to work with it. With Emacs, for example, commands that took a while lead to an error “Lost connection to Wayland compositor”. I suspect GTK4 or whatever Emacs was using missed too many ticks in some window update thread -> wayland thinks it is dead and killed it.
Was it a long time ago? Perhaps it would work under Sway/Wayland, KDE/Wayland or GNOME/Wayland on ie. Arch now?
A month ago, with Arch, Sway & AMD GPU, I ran into the same error with any apps that hung for a few seconds. With Emacs, it was easy to replicate as I only had to save a bigger file to initiate the lsp-format.
That’s a pity. Hope the issue becomes resolved soon.
https://arewewaylandyet.com
The two missing features are two I need pretty badly. Color management is important as is getting the full range of your wide-gamut / HDR displays. …And also the Thunderbolt dock I picked up last year uses DisplayLink (ignorant that this is something I needed to check).
I tried and liked sway for 1½ years, but I had to move back to xmonad.
I’m sure Wayland is really cool, if it would work on my machine. My only Wayland exposure resulted in seeing the desktop animate with 1 frame per second, freeze the OS completely, or not start at all. So I use X.
Out of curiosity, which wayland implementation was that?
I don’t even know. The one that is shipped in Ubuntu, openSUSE and ArchLinux. None of them work on my machines (desktops, laptops).
It depends on the desktop environment. For example, KDE has been shipping a very buggy one for a long time now.
Okay, I’m using KDE then. It has 1 FPS, but at least it kind of works, but when I check out GNOME, the GUI doesn’t even start, and requires force resetting the machine.
Not that it’s really important. X works for me, at least until I’ll buy myself a 4k monitor ;)