I find it fascinating that the author managed to avoid using the word “security”, although that specific concern shapes most of the discussion about Wayland and its protocols/extensions.
Making it possible for accessibility tools to read the content of other windows? Keyloggers!
Edit: Poe’s Law: this was a sarcastic comment. My belief is that Wayland’s security model, combined with what @crazyloglad calls “Policy before Mechanism”, leads to a net negative when it comes to the usability of Linux desktop environments.
Untrusted programs are chivalrous and would never, for instance, add their own Wayland binaries to $PATH so the user runs a version with changes, or replace other programs the user runs with patched versions, or proxy the entire session through a local VNC/waypipe/etc, or impersonate sudo on the command-line, or access the user’s files directly (definitely not web browser cookies, passwords and ssh keys). Wayland is an effective location for securing the user against programs they are running.
It is true that if a malicious program is able to set $PATH for you, it has already won. And Wayland doesn’t do anything to stop that.
That is why Wayland itself does not make for a secure desktop, you need more parts. Most importantly, application sandboxing. An untrusted program - and this does not have to be “random binary you got on the internet”, it could be a FOSS application faithfully installed via your trusted package manager that just happens to play fast and loose with memory safety - should not have full access to e.g. your home directory, and possibly also not to the internet.
And this is indeed where the Linux desktop is moving with things like flatpak.
In a world where desktop apps all run unsandboxed, Wayland’s security properties are indeed useless. But in a world of sandboxed desktop apps, every window sharing an X server with which they can do almost anything is an Achilles’ heel.
In a world where desktop apps all run unsandboxed, Wayland’s security properties are indeed useless. But in a world of sandboxed desktop apps, every window sharing an X server with which they can do almost anything is an Achilles’ heel.
No, it’s misleading to say Wayland would have an advantage here. In a possible world where you run every app sandboxed then Wayland’s “security properties” are still a bad solution.
You would have two options in such a world:
(1) Implement the security in a complicated component, the display server (wayland/xorg/etc).
… or …
(2) Implement the security in a smaller, simpler proxy program that sits between the display server and the fully sandboxed app.
In one you have a small, controlled API; the other you have a sprawling complex API. One requires vast amounts of effort to fix design problems with, the other can be thrown away (or competitors written) for far less cost. One is much more feasible to be evaluated by external parties. Etc.
In a world where desktop apps all run unsandboxed, Wayland’s security properties are indeed useless. But in a world of sandboxed desktop apps, every window sharing an X server with which they can do almost anything is an Achilles’ heel.
But in a world in which sandbox desktop apps need to poke holes through Wayland’s and the sandbox’s security model just to perform the functions that users expect from them (e.g., extensions, portals), Wayland’s security models turns into a burden.
But in a world in which sandbox desktop apps need to poke holes through Wayland’s and the sandbox’s security model just to perform the functions that users expect from them (e.g., extensions, portals), Wayland’s security models turns into a burden.
Portals don’t undermine the sandboxing, though. Like, the file picker portal gives access to exactly the files chosen by the user, so the sandboxing gets to do its job just fine.
But in a world in which sandbox desktop apps need to poke holes through Wayland’s and the sandbox’s security model just to perform the functions that users expect from them (e.g., extensions, portals), Wayland’s security models turns into a burden.
Portals don’t undermine the sandboxing, though. Like, the file picker portal gives access to exactly the files chosen by the user, so the sandboxing gets to do its job just fine.
Portals like Account, ScreenCast, Input Capture and Clipboard open quite wide holes in Wayland’s and the sandbox’s security model. But they exist because users want them, just like the kind of (unsafe under certain circumstances) features that the article describes.
I wrote a response to this 4 years ago that i still think holds water. https://www.divergent-desktop.org/blog/2020/10/29/improving-x/ - The follow up has been finished for about as long as well, but there is no point to poke any further. It is more entertaining just watching the different factions gaslight eachother about things that was spelled out in the Readme.md of the first commit.
I’ve personally received >= 1 directed messages every month in the mailbox for the last 3 years boiling down to ‘GNOME is stubborn as to CSDs vs SSDs otherwise things would be great’. Some of the grievances in the tenstral blog are an extension to that very tiresome debate. This is an axiomatic decision, pick one and stick to it or there will be infinite complexity to pay. Kristian (the designer) picked. He defended it vigorously in mailing lists and on IRC and … ultimately left.
Slightly more generic but it actually latches into the blog: The Wayland design as proposed, with the scope, as proposed, would have been an ‘on par’ competitor to SurfaceFlinger. For that domain in that point of time it made perfect sense. Had “the powers that be” committed to such a thing at the time it would have actually been an interesting battle for that domain. As for the 2013+ resurrection trying to massage it into an actual X11 replacement? No. They have repeated the same conflict-laiden faux passes that stagnated X11 – lacking the guiding hand of someone like Keith Packard who snuck things into XPRESENT later which highlighted Wayland flaws in a brilliant way, but .. he ultimately left.
Wayland is a complete farce undeserving of the “protocol” honorific. At best its ‘extensibility’ as a protocol turned out no stronger than any first year data-communications student discovering “TLV’ (Tag, Length, Value) with a free-for-all-no-commitment as to how you interpret ‘Tag’. As a software engineering endeavour it is a marriage, don’t expect a set of specs to implement in a domain so slow moving that it is gathering moss but rather enjoy scraping gitlab, mailing lists, irc channels and whatnot for any idea of what is actually expected of you.
Going back to the linked response, there is this thing at the end:
“Take the perspective of a client developer chasing after the tumbleweed of ‘protocols’ drifting around and try to answer ‘what am I supposed to implement and use’? To me it looked like like a Picasso painting of ill-fitting- and internally conflicted ideas. Let this continue a few cycles more and X11 will look clean and balanced by comparison. Someone should propose a desktop icon protocol for the sake of it, then again, someone probably already has.”
It actually took until XDC2023 to reach that stage, but thankfully we also then get an incompatible ‘icon’ protocol for the window to not go with it. That some will implement. Others will fail to care about.
The only thing that matters still is the ongoing power grab that is continuing apace.
Wayland lets your own solipsist thiefdoms expand towards the horizon, while trying to save embedded from the Android expanse.
solipsist = self-serving egotism
Surely egos can’t be the only motivation? They’re a convenient contributor, but is there money or potential money for people if wayland is adopted more?
And how would wayland provide competition to Android in ways that Xorg wouldn’t? All I can think of is colour depth support, but I’m not intimately familiar.
It’s the conflict resolution default for each of the many fractions that lead to this whole ‘what even does Wayland define?’ that I meant as the ‘ego’ here.
“Fine you don’t want to support server-side decorations just because the designer said that they are a bad fit for the design?, Well WE will add another protocol object that OUR tools will assume will be there and work and be the only thing that we actually support.” Repeat ad nauseum for every single feature from ‘sharing buffers from server to client’ to ’can we set the background image?”.
There is group benefit still in calling themselves ‘Wayland’ compositors for the whole ‘it runs on billions of device!!’ like appeal to popularity (of course the implementation in Tizen doesn’t run anything others would call Wayland) but there is so little actual shared infrastructure that the distance between HTTP and FTP is smaller than that of Mutter to EFL.
there is so little actual shared infrastructure that the distance between HTTP and FTP is smaller than that of Mutter to EFL.
That’s really interesting to know, I didn’t realise the wayland ecosystem was so fractured. I had heard that there were differences between compositors but not by that much.
(Alas you missed a good opportunity for comparing the distance between FTP and FTP)
There is group benefit still in calling themselves ‘Wayland’ compositors for the whole ‘it runs on billions of device!!’ like appeal to popularity
Appealing to popularity is another form of ego.
So you don’t think there is money or potential money for anyone if wayland is adopted more? I feel like I might be naive if I assume money isn’t involved – Fedora has changed to wayland by default, big DEs now support it, but it’s still worse and doesn’t look like it will ever be better?
(Alas you missed a good opportunity for comparing the distance between FTP and FTP)
Doh! To be fair this is the endgame for any protocol that gets to live in the wild for a bit without having their chains yanked every now and then. Compare the distance between say Xterm and Terminology on the ‘emulated target’ level.
So you don’t think there is money or potential money for anyone if wayland is adopted more? I feel like I might be naive if I assume money isn’t involved – Fedora has changed to wayland by default, big DEs now support it, but it’s still worse and doesn’t look like it will ever be better?
There’s money of course but it’s not the money from collaboration, the “Wayland” part of it is mostly irrelevant. It’s controlling the entire vertical in the Android playbook style. The Wayland transition is a way to do that in what remains of the ‘free’ desktop. Does that matter competition wise versus say what can be achieved with yet another non-western fork of Android or the ‘more virtualization, more cloud’ angle Microsoft is pushing? It seems the previous carved out niche of IVI is closing down coming cycles.
Great write up. Nice to see clear use cases and reasoning for things that are missing. Also kudos to the author for trying to do something about the missing parts.
Similarly, a protocol to save & restore window positions was already proposed in 2018, 6 years ago now, but it has still not been agreed upon
I’ve been tinkering with an old Mac recently and this was something early Mac OS did really well. Kinda embarrassing that it wasn’t part of the original Wayland protocols.
I’m not sure why it belongs in the display server. On macOS, window positions are stored in user defaults. There’s some goo that you can use with Cocoa Bindings to make this persist automatically (I think it’s the default for non-document windows created in XCode).
The display server is involved on more recent macOS because the OS will kill apps when you’re low on memory and you haven’t used them for a while. The display server takes ownership of the app’s windows and keeps their frame buffers around so that the app can relaunch and reclaim ownership when it restarts. This is also used to give the illusion that all of your apps are running when you reboot.
The well runs much deeper than that. It turns out that building Ontologies is hard. Doing it spread out over 3-4 different communication channels over a very long period of time does not make it easier.
There are about 3 (4 but one that should not be mentioned) ways of ‘positioning windows’.
First way: the wl_output object describes which parts of the main coordinate space are mapped to something and to which outputs your surfaces are attached and detached. So you know ‘sortof’ where your windows are but not precisely. You also have no direct way of reanchoring a surface within the anchor. Instead that is supposed to be goverened by a ‘shell’ object, nowadays mainly xdg-shell, but there are others.
XDG-Shell defines popups, but if you are creative enough anything can be a popup. Popups can have positioners. The specification for that is deliciously complicated to avoid saying ‘put this thing here’ and instead go ‘please position this popup relative to these other objects sortof within this region but if you need to reposition it gravitate towards…’.
Second way: Xorg-wayland (often called Xwayland but hey, 98.6% is still the same Xorg code) has a peculiar design. If one would create a wl-x11-shell object that translates Xorgs internal window hierarchy to that of X11 one could say, re-use existing window managers and not piss away a few thousand hours of developer effort reimplementing i3. This did not happen. Thankfully reimplementing the same old tired thing again and again is what FOSS does best.
Instead there is a sneaky little atom, WL_SURFACE_ID that Xorg-wayland tags mapped surfaces with. Then the Wayland ‘compositor’ is supposed to write their own X11 Window Manager that translates and moves Wayland windows around according to X11 rules if that atom is set. So someone creative could just sneak in the IDs to their Wayland surfaces that way and reposition according to the old rules.
Third way: We have this little rascal: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_subcompositor . This has been there from the start and is necessary to deal with things like decorations (libdecor injects these) as that was, by design, the client’s responsibility UNLESS >>insert flamewar<< but also getting mixed colour space ‘windows’ like videos with subtitles to not burn your CPU doing colour space conversions.
wl_subsurface has “wl_subsurface::set_position - reposition the sub-surface”. So what’s stopping you from say, creating a fully transparent, output sized ‘surface’ and then put all your windows as subsurfaces and move them around according to your heart’s desires? Nothing (except most subsurface implementations are inconsistent and incompatible with eachother but that is someone else’s problem and what does even synched or unsynched and what happens to input coordinates on a scaled output and…). It turns out that is what winewayland.dll decided to do. That might not turn out great.
But the toolkit and application are the only things that knows, for example, that this window corresponds to this specific document. Being able to reopen documents in the same location each time is essential for spatial memory, how are you supposed to do that with Wayland?
This may seem like a small obstacle to a user, but to a developer, who wants to position a menu in a second window over a UI item like a popup button, its a blocker.
They do not know the difference and also do not want to deal with these details – even though they may be programmers as well, the real goal is not to fiddle with the display server, but to get to a scientific result somehow.
I wasn’t shocked to see that the author was supporting scientists and running into these issues. I’m familiar with a bunch of scientific software packages that use the big complex multi-window paradigm the author talks about.
Research computing support is a fun and maddening experience because much of the time, your customers are very technically sophisticated people, who may be writing thousands of lines of code themselves… who simultaneously don’t care about computers or software and sometimes view them as an annoyance, similar to a microscope that occasionally misbehaves. And therefore are willing to do the wildest things and take the most bizarre shortcuts to achieve their results.
the other day I was in a hospital waiting room, i wanted to crop a pdf for reasons… I installed and ran a Qt powered KDE pdf cutter on my home linux box over tailscale in like… <10 min. It just worked. ssh -X on an arm mac to an intel linux box. X has been working like that for me since 1998, and if anything it’s way faster now (assuming a good network).
What does wayland give me now or tomorrow, and how could it ever support as wide a breadth as the extant X ecosystem?
Running multiple monitors at different DPIs in a coherent way is basically the one thing. It’s not quite as impossible on X as they claim it is, but it would be a pretty grievous hack. Apps just deal with coordinates differently on the two systems, and Wayland’s way is more flexible.
Everything else I’ve seen is pretty spurious. It’s either “our way is just so much more modern!” or it’s “X doesn’t do that and never will! (Why?) Because we’re all working on Wayland.” Software is like that, particularly in the open-source world. There are fads, and once people decide that something has run its course, it becomes a self-fulfilling prophecy.
Running multiple monitors at different DPIs in a coherent way is basically the one thing.
I’ve been doing this in X for a while now, it is very simple and works fine, for applications written to support it (so there’s no automagic scale for legacy clients, but tbh I don’t want that anyway since it almost invariably looks awful anyway). xrandr describes regions of the screen associated with each monitor. You set a property that sets scale factor. Application does the rest - this is more-or-less how per monitor dpi version 2 works on Windows too, it isn’t some “hack”, but rather the best solution settled on after they tried a lot of other things. Wayland’s experimental fractional scaling protocol also does it this way, dropping their previous approach.
My big complaint with X is just that nobody has standardized the property. So my lib does it one way, Qt does it another, gtk…. just doesn’t because gtk doesn’t want to. But interestingly, there is an X extension in the works from the Wayland people that might finally standardize on it in the name of interop w/ the new wayland protocol! lol. And their solution? A global root window property showing the monitor scale factors, same thing easy to do (and frankly the obvious solution) since day one after they spent years saying it was “fundamentally impossible”.
It is not a fundamental limitation to Xorg. In fact it can be slightly better than the “looking over the shoulder of Win/OSX copying the approach but not understanding the legacy or history of the problem that scale factors added to the mix” Xorg had printer support as those are a substantial part of the evolution of the problem space. Printers were/are the highest-DPI slowest “framerate” around with very different colour spaces. It is not a new problem at all. Last(?) thing Keith published were PoC patches adding scaling attributes per window that worked.
The better approach is to move the Xft.dpi atom from being in the root to being per window and check it on configure events, set a presentation DPI ATOM back as a signal to indicate that the client can do density-aware rasterisation and the rest can be done server side. Any average vector engine can take HDPI,VDPI as input and spit out draw commands or a rasterized buffer, Font size expressed in PT reflects the real world “this is my readable comfort size”. The rest is high school math.
The misdirect of “oh but we want a window to look good stretched across multiple mixed DPI displays” is more in the ballpark of “play dumb games, win dumb prizes” though again, the abstractions in DDX allows you to do that. Nothing in the Wayland approach fundamentally solves that and the problem re-appears when you have displays with other varying properties, whether that is e-Ink, lenticular, laser projectors or HDR with different tech/specs.
The actual problem are in three places - 1. Xorg-modeset, is a monster and all sympathies for any engineer that tries to do anything with it. 2. The other is the politics around Xlib/Xcb. This is partly what gives me a whiff of a scent of IBM.RH having a competitive intelligence team playing on offence right now (It is a billions-of-dollars endeavour, of course they have several and some are bored). 3. MESA.
Maintaining all of Xorg and reducing the DDXes to basically “Xorg-wayland” is from what I can tell a salaried position (O.Fourdan) and much of MESA surely is. If you would try and pick up the reigns of Xorg-modeset to draft new releases of that, expect slow moving procedure and red tape resistance to the eventually necessary changes needed in support libs and toolkits. The idea of doing that on your own dime requires strikes me as unappealing to say the least.
The MESA thing is where workarounds that fix games for the idiosyncrasies of Wayland will accumulate, while not doing the same for Xorg-yourhostilefork. Over time this will be really draining to work with, there is a lot of “visible code but secret sauce” hidden inside that thing, just as there is with nvidia blobs.
The misdirect of “oh but we want a window to look good stretched across multiple mixed DPI displays” is more in the ballpark of “play dumb games, win dumb prizes”
I do want this, though I don’t really understand why it’s hard. Toolkits over worked with all have some variation of an abstraction that is ‘draw this rectangle of your view in this graphics context’. The graphics context is the thing that knows about DPI (and colour spaces and so on) and so the only thing that the window server should need to tell you is ‘this rectangle of your window has these settings’ and then the toolkit can just draw the rectangles that are on different displays with a graphics context that matches those settings. It’s mildly annoying for compositing toolkits because they can’t reuse cached textures during drag events across different-dpi monitors, but I fundamentally don’t care about performance while moving a window that spans displays: if it works at all that’s nice, if it works fast that’s nicer.
It’s one of those “Why is it hard with an unaligned instruction across page boundaries” type of problems. There is a set for which this is easy, say low-cost-low-refresh-shallow-buffer clipped viewport software rendering which, as you say, just slide the viewport and reraster/compose based on sink-provided properties.
For hardware acceleration and games especially there is a whole can of earthworm jims in there. Buffer queues run deep (“in-scanout, queued for scanout, target frontbuffer, target backbuffer, …) render passes are expensive (see one of those “what goes into a frame” breakdowns), memory of the right type and encoding scarce and content is increasingly specialised for the properties of that one display from subchannel bias and level of detail all the way to foveated rendering. Just deviations in synch, nevermind slew rate adjustments with VRR, can easily nudge you into thrashing and inconsistent frame delivery (jitter, judder) as the “signal” for the one display is sampled at a different rate than the other.
What I’d personally want (and have for my stuff but toolkits ruin all the fun) is to retain a primary uncomposed “ideal” surface and let me request different representations of that at mildly or wildly different content states with the controls for seeking, etc. formalised on the IPC level. With that as a requirement in your pipeline, requesting another viewport comes by default.
There’s a lot of negative-on-Wayland posts lately, so in case it’s helpful to people considering switching: I recently switched from x11+i3 to wayland+sway about a week ago, so far my list of things that don’t work:
Some tray icons don’t have a right-click context menu. Sounds like this is partially a sway issue, since there are workarounds on other wm’s but the fix has been stagnant: https://github.com/swaywm/sway/pull/6249
Global hotkeys don’t work without focusing the receiving window (e.g. push to speak on Discord etc). This is a property of Wayland’s security design (prevent all apps from becoming keyloggers), so either global hotkeys need to be managed by the window manager (via forwarding), or there’s a generalized xdg-desktop-portal solution that was merged not long ago but has not been implemented widely yet: https://github.com/flatpak/xdg-desktop-portal/issues/624
Idle detection has been imperfect while gaming, I need to dig into this but I just disable swayidle temporarily as a workaround.
Everything else works great!
I ultimately want to migrate off of sway, but I mainly started there because the migration from i3 has been extremely easy (99% of my config was compatible). Thinking of playing with River soon, might be fun to write some zig.
This isn’t necessarily a reply specifically to you, and if your setup works for you, fantastic, I envy you, but every time someone posts their experience, it always reminds me of people talking about moving to linux in the early 2000s: “Oh yeah, it’s great. I don’t have wifi and I can’t play two audio sources at once without a workaround, but it’s perfect other than that.” Wayland has its advantages, some of which I’m sorely wanting, but for something that I’ve been getting told is ready for use for like a decade, it really seems to be lacking a lot of features to be set as the default.
I never liked that meme, it ignores the million things I can do with my Linux setup that is impossible to do elsewhere. Yes, it sometimes takes more effort, but most of the effort pays dividends for the rest of my life (especially since I’ve switched to NixOS where I avoid stateful side effects that are ultimately lost so that the declarative configs survive system upgrades).
I don’t think anyone has ever tried to sell Linux as something that requires zero effort and zero learning, and frankly any operating system that did try to sell it as that was lying. Yes, even macOS required adapting and getting used to.
There’s something to be said about putting effort into something because we get proportional value in return. I certainly feel that way, but I never felt that way when I used Windows. No amount of reformatting and reinstalling helped me feel like I was actually coming out ahead.
Many of the things I like most about “Linux” are actually unique features of the X Window System…
That is totally fair, and exactly what I like about open source. :) I have no doubt that there will be a forked version of X11 that is maintained for all the eons to come.
That doesn’t seem likely right now. Xorg already has the issue of people not wanting to maintain it today. If the current maintainers are abandoning the project, why wouldn’t the interested parties join right now? They wouldn’t need to fork the project, but literally say “I’m interested in maintaining this”.
Xorg is plenty maintained right now. This is just a myth. When you open a bug, you get a same-day reply, there’s things merged into it on a regular basis. There’s even new features coming out pretty regularly, including new extensions in 2023. Half of them are related to Wayland interop… but the other half aren’t.
The thing that hasn’t come for a while is a formal numbered release. I guess the person who did packaging quit.
There’s a big difference between taking over an existing project (with all the baggage that comes with it) versus making a fork and trying something new with it. Also some people don’t act until they have to.
To be clear I was a Linux on the desktop zealot in 98, 99, etc but after the intel macs came out I’ve been mac first and ssh to linux later. I did comment here because sometimes I ssh -X to a linux box, but oddly 3 things wreck me about Linux these days which have little to do with the compositor or whatever it’s called.
No cross app + terminal keyboard shortcut for copy paste. Last I checked a command-C command-V equivalent simply doesn’t exist in linux. So you ctrl-shift-c and ctrl-c depending on the window you have focused and pray you never ctrl-c an important running command in a terminal. It’s like having a fire extinguisher (pull key interface) next to grenades (pull key) mentally.
mouse accel, absolutely not the way I like it and I can’t get it to work the way I want
generally same-same keyboard shortcuts and user interface, and they haven’t changed much since the year 2000. I suppose I could be using WindowMaker still but I didn’t love it in 99.
At any rate, thanks for your contributions (<3 ssh-chat), I think you are doing Linux the right way, I just don’t have the time to maintain that sort of setup beyond a few boxes to ssh to.
I don’t have much good to say about X-forwarding over ssh, this was always a half-working system. But overall, it sounds like you just want a more polished and batteries-included desktop manager like KDE/Gnome, or a distro like Pop!_OS (haven’t tried it myself but hear good things).
You can remap your copy key to be ctrl+shift+c everywhere if you prefer, or use the middle-click buffer, or some terminals even let you remap ctrl+c if you prefer. I’m pretty sure KDE and Konsole lets you do this, but I generally use i3/sway/alacritty. Hasn’t been an issue for me, but I use focus-follows-cursor with a tiling manager so it’s a bit different.
There has been tons of work on libinput the last few years, personally my trackpad works about as well as my macbook’s did now. Wayland compositors get even further control over these things if you’re into that.
KDE’s hotkey management has been ahead of every other OS since probably the early 2000’s.
I don’t mean that there’s any shame in using what works for you, especially if it makes you happy.
We make time for the things that matter to us. If it doesn’t matter to you, then I can understand that you don’t have time for it. Just don’t let past impressions keep you from enjoying today’s progress. :)
yea perhaps with QMK I could map cmd to Ctrl-Shift but the lack of overarching zero question cmd-C works (minus VMs and forwarded X apps, which I rarely use)
Ugh, if I hadn’t compiled it by hand in a vain attempt at multitouch (+GNOME or +KDE either) I’d believe. I want to. That was probably 1-2 years ago tho.
Absolutely, part of me thinks that in 10-20 years from now KDE will be the last open DE standing from this era. <3 it.
Somehow I’ve gotten used to window obscuration and the normal windowing metaphor, i’ve tried ratpoison and i3 but never for more than a few minutes before I figured I could use my limited memory for something other than shortcuts. It still amazes me how much better the base installed Linux distro (pick a distro) is from the startx days, but yea I’ll dip my toe again sometime.
It’s realistic. I could write a list of “things work, apart from …” for all 3 major systems I’m using. They’re still useful in case you want to know the situation on the other side.
For example: Yeah, MacOS mostly works for me, with some annoyances like issues with sleep, dtrace being broken for the last 2 years, filesystem freezing when browsing huge directories, bad latency on audio devices, inability to change Bluetooth codecs, smartcard login not working after sleep, … Yeah, Windows mostly works for me, with some annoyances like active sleep being completely broken, no config for dock mode, no package manager, no reasonable package format, lack of client SMB share configuration, no built in support for extra filesystems, no self-describing configuration, …
And I’m being told they’re production ready for decades now! If you don’t have your list of remaining annoying/broken/unfinished things in your favourite / most-used system, you likely haven’t used it hard enough ;)
That’s not a similar case though, is it? Wayland is not a rewrite that can be a destination for gradual changes from Xorg. It’s a massive architecture shift that changes the basic assumptions of how the system works. This is more like writing NFS when FTP already existed.
Which case? He mentions various cases. The post makes a general point about rewriting large codebases with the intention of doing everything better this time.
Wayland is not a rewrite that can be a destination for gradual changes from Xorg.
Perhaps it should have been.
It’s a massive architecture shift that changes the basic assumptions of how the system works.
You can’t advertise a new solution as a drop-in replacement when much of the previously existing functionality is now broken or unsupported due to the pursuit of abstract architectural purity. They can challenge whatever assumptions they want, but if the end-user faces endless breakage across the board, none of that matters. The problem is when architectural beauty has a higher priority than user concerns, because the point of software is to provide value to the user, not to delight software architects. Many Open Source projects exhibit this problem because people like creating beautiful abstract designs in their spare time and there is no (financial) incentive to get it right for the user.
Yes, the post is about rewrites, rather than redesigns - as in cleanups that mostly do the same thing. Wayland is not a drop in replacement and wasn’t intended to be. Xwayland exists exactly because a compatibility layer is needed.
Even for the example of Juno with architectural changes, he mentions things were moved around and cleaned up. That’s not what Wayland does - it explicitly changes how things work, because the authors don’t believe the in the previous way of doing things, rather than just the code.
I find it fascinating that the author managed to avoid using the word “security”, although that specific concern shapes most of the discussion about Wayland and its protocols/extensions.
Allowing applications to set their icon at runtime? They could impersonate another application!
Giving applications a way to choose where to place themselves? Clickjacking! User tracking!
Making it possible for accessibility tools to read the content of other windows? Keyloggers!
Edit: Poe’s Law: this was a sarcastic comment. My belief is that Wayland’s security model, combined with what @crazyloglad calls “Policy before Mechanism”, leads to a net negative when it comes to the usability of Linux desktop environments.
Thank goodness Wayland is here to protect us from the bourgeois excesses of accessibility accommodations.
Untrusted programs are chivalrous and would never, for instance, add their own Wayland binaries to $PATH so the user runs a version with changes, or replace other programs the user runs with patched versions, or proxy the entire session through a local VNC/waypipe/etc, or impersonate sudo on the command-line, or access the user’s files directly (definitely not web browser cookies, passwords and ssh keys). Wayland is an effective location for securing the user against programs they are running.
It is true that if a malicious program is able to set $PATH for you, it has already won. And Wayland doesn’t do anything to stop that.
That is why Wayland itself does not make for a secure desktop, you need more parts. Most importantly, application sandboxing. An untrusted program - and this does not have to be “random binary you got on the internet”, it could be a FOSS application faithfully installed via your trusted package manager that just happens to play fast and loose with memory safety - should not have full access to e.g. your home directory, and possibly also not to the internet. And this is indeed where the Linux desktop is moving with things like flatpak.
In a world where desktop apps all run unsandboxed, Wayland’s security properties are indeed useless. But in a world of sandboxed desktop apps, every window sharing an X server with which they can do almost anything is an Achilles’ heel.
No, it’s misleading to say Wayland would have an advantage here. In a possible world where you run every app sandboxed then Wayland’s “security properties” are still a bad solution.
You would have two options in such a world:
(1) Implement the security in a complicated component, the display server (wayland/xorg/etc).
… or …
(2) Implement the security in a smaller, simpler proxy program that sits between the display server and the fully sandboxed app.
In one you have a small, controlled API; the other you have a sprawling complex API. One requires vast amounts of effort to fix design problems with, the other can be thrown away (or competitors written) for far less cost. One is much more feasible to be evaluated by external parties. Etc.
But in a world in which sandbox desktop apps need to poke holes through Wayland’s and the sandbox’s security model just to perform the functions that users expect from them (e.g., extensions, portals), Wayland’s security models turns into a burden.
Portals don’t undermine the sandboxing, though. Like, the file picker portal gives access to exactly the files chosen by the user, so the sandboxing gets to do its job just fine.
Portals like Account, ScreenCast, Input Capture and Clipboard open quite wide holes in Wayland’s and the sandbox’s security model. But they exist because users want them, just like the kind of (unsafe under certain circumstances) features that the article describes.
I wrote a response to this 4 years ago that i still think holds water. https://www.divergent-desktop.org/blog/2020/10/29/improving-x/ - The follow up has been finished for about as long as well, but there is no point to poke any further. It is more entertaining just watching the different factions gaslight eachother about things that was spelled out in the Readme.md of the first commit.
I also wrote two articles to troll the ‘desktop icon’ eventuality problem space earlier than that: the entry level https://arcan-fe.com/2019/05/07/another-low-level-arcan-client-a-tray-icon-handler and the follow-up : https://arcan-fe.com/2019/10/30/interfacing-with-a-stream-deck-device/ (they’re not at this stage yet).
I’ve personally received >= 1 directed messages every month in the mailbox for the last 3 years boiling down to ‘GNOME is stubborn as to CSDs vs SSDs otherwise things would be great’. Some of the grievances in the tenstral blog are an extension to that very tiresome debate. This is an axiomatic decision, pick one and stick to it or there will be infinite complexity to pay. Kristian (the designer) picked. He defended it vigorously in mailing lists and on IRC and … ultimately left.
Slightly more generic but it actually latches into the blog: The Wayland design as proposed, with the scope, as proposed, would have been an ‘on par’ competitor to SurfaceFlinger. For that domain in that point of time it made perfect sense. Had “the powers that be” committed to such a thing at the time it would have actually been an interesting battle for that domain. As for the 2013+ resurrection trying to massage it into an actual X11 replacement? No. They have repeated the same conflict-laiden faux passes that stagnated X11 – lacking the guiding hand of someone like Keith Packard who snuck things into XPRESENT later which highlighted Wayland flaws in a brilliant way, but .. he ultimately left.
Wayland is a complete farce undeserving of the “protocol” honorific. At best its ‘extensibility’ as a protocol turned out no stronger than any first year data-communications student discovering “TLV’ (Tag, Length, Value) with a free-for-all-no-commitment as to how you interpret ‘Tag’. As a software engineering endeavour it is a marriage, don’t expect a set of specs to implement in a domain so slow moving that it is gathering moss but rather enjoy scraping gitlab, mailing lists, irc channels and whatnot for any idea of what is actually expected of you.
Going back to the linked response, there is this thing at the end:
“Take the perspective of a client developer chasing after the tumbleweed of ‘protocols’ drifting around and try to answer ‘what am I supposed to implement and use’? To me it looked like like a Picasso painting of ill-fitting- and internally conflicted ideas. Let this continue a few cycles more and X11 will look clean and balanced by comparison. Someone should propose a desktop icon protocol for the sake of it, then again, someone probably already has.”
It actually took until XDC2023 to reach that stage, but thankfully we also then get an incompatible ‘icon’ protocol for the window to not go with it. That some will implement. Others will fail to care about.
The only thing that matters still is the ongoing power grab that is continuing apace.
From your linked article:
solipsist = self-serving egotism
Surely egos can’t be the only motivation? They’re a convenient contributor, but is there money or potential money for people if wayland is adopted more?
And how would wayland provide competition to Android in ways that Xorg wouldn’t? All I can think of is colour depth support, but I’m not intimately familiar.
It’s the conflict resolution default for each of the many fractions that lead to this whole ‘what even does Wayland define?’ that I meant as the ‘ego’ here.
“Fine you don’t want to support server-side decorations just because the designer said that they are a bad fit for the design?, Well WE will add another protocol object that OUR tools will assume will be there and work and be the only thing that we actually support.” Repeat ad nauseum for every single feature from ‘sharing buffers from server to client’ to ’can we set the background image?”.
There is group benefit still in calling themselves ‘Wayland’ compositors for the whole ‘it runs on billions of device!!’ like appeal to popularity (of course the implementation in Tizen doesn’t run anything others would call Wayland) but there is so little actual shared infrastructure that the distance between HTTP and FTP is smaller than that of Mutter to EFL.
That sounds like a mess :|
That’s really interesting to know, I didn’t realise the wayland ecosystem was so fractured. I had heard that there were differences between compositors but not by that much.
(Alas you missed a good opportunity for comparing the distance between FTP and FTP)
Appealing to popularity is another form of ego.
So you don’t think there is money or potential money for anyone if wayland is adopted more? I feel like I might be naive if I assume money isn’t involved – Fedora has changed to wayland by default, big DEs now support it, but it’s still worse and doesn’t look like it will ever be better?
Doh! To be fair this is the endgame for any protocol that gets to live in the wild for a bit without having their chains yanked every now and then. Compare the distance between say Xterm and Terminology on the ‘emulated target’ level.
There’s money of course but it’s not the money from collaboration, the “Wayland” part of it is mostly irrelevant. It’s controlling the entire vertical in the Android playbook style. The Wayland transition is a way to do that in what remains of the ‘free’ desktop. Does that matter competition wise versus say what can be achieved with yet another non-western fork of Android or the ‘more virtualization, more cloud’ angle Microsoft is pushing? It seems the previous carved out niche of IVI is closing down coming cycles.
Great write up. Nice to see clear use cases and reasoning for things that are missing. Also kudos to the author for trying to do something about the missing parts.
I’ve been tinkering with an old Mac recently and this was something early Mac OS did really well. Kinda embarrassing that it wasn’t part of the original Wayland protocols.
I’m not sure why it belongs in the display server. On macOS, window positions are stored in user defaults. There’s some goo that you can use with Cocoa Bindings to make this persist automatically (I think it’s the default for non-document windows created in XCode).
The display server is involved on more recent macOS because the OS will kill apps when you’re low on memory and you haven’t used them for a while. The display server takes ownership of the app’s windows and keeps their frame buffers around so that the app can relaunch and reclaim ownership when it restarts. This is also used to give the illusion that all of your apps are running when you reboot.
A fair point. I suppose it’s more of a toolkit responsibility.
The problem is that the toolkit is also not able to set the window position.
The well runs much deeper than that. It turns out that building Ontologies is hard. Doing it spread out over 3-4 different communication channels over a very long period of time does not make it easier.
There are about 3 (4 but one that should not be mentioned) ways of ‘positioning windows’.
First way: the wl_output object describes which parts of the main coordinate space are mapped to something and to which outputs your surfaces are attached and detached. So you know ‘sortof’ where your windows are but not precisely. You also have no direct way of reanchoring a surface within the anchor. Instead that is supposed to be goverened by a ‘shell’ object, nowadays mainly xdg-shell, but there are others.
XDG-Shell defines popups, but if you are creative enough anything can be a popup. Popups can have positioners. The specification for that is deliciously complicated to avoid saying ‘put this thing here’ and instead go ‘please position this popup relative to these other objects sortof within this region but if you need to reposition it gravitate towards…’.
Second way: Xorg-wayland (often called Xwayland but hey, 98.6% is still the same Xorg code) has a peculiar design. If one would create a wl-x11-shell object that translates Xorgs internal window hierarchy to that of X11 one could say, re-use existing window managers and not piss away a few thousand hours of developer effort reimplementing i3. This did not happen. Thankfully reimplementing the same old tired thing again and again is what FOSS does best.
Instead there is a sneaky little atom, WL_SURFACE_ID that Xorg-wayland tags mapped surfaces with. Then the Wayland ‘compositor’ is supposed to write their own X11 Window Manager that translates and moves Wayland windows around according to X11 rules if that atom is set. So someone creative could just sneak in the IDs to their Wayland surfaces that way and reposition according to the old rules.
Third way: We have this little rascal: https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_subcompositor . This has been there from the start and is necessary to deal with things like decorations (libdecor injects these) as that was, by design, the client’s responsibility UNLESS >>insert flamewar<< but also getting mixed colour space ‘windows’ like videos with subtitles to not burn your CPU doing colour space conversions.
wl_subsurface has “wl_subsurface::set_position - reposition the sub-surface”. So what’s stopping you from say, creating a fully transparent, output sized ‘surface’ and then put all your windows as subsurfaces and move them around according to your heart’s desires? Nothing (except most subsurface implementations are inconsistent and incompatible with eachother but that is someone else’s problem and what does even synched or unsynched and what happens to input coordinates on a scaled output and…). It turns out that is what winewayland.dll decided to do. That might not turn out great.
But the toolkit and application are the only things that knows, for example, that this window corresponds to this specific document. Being able to reopen documents in the same location each time is essential for spatial memory, how are you supposed to do that with Wayland?
This may seem like a small obstacle to a user, but to a developer, who wants to position a menu in a second window over a UI item like a popup button, its a blocker.
tldr; stick with X11 or move to Arcan.
I wasn’t shocked to see that the author was supporting scientists and running into these issues. I’m familiar with a bunch of scientific software packages that use the big complex multi-window paradigm the author talks about.
Research computing support is a fun and maddening experience because much of the time, your customers are very technically sophisticated people, who may be writing thousands of lines of code themselves… who simultaneously don’t care about computers or software and sometimes view them as an annoyance, similar to a microscope that occasionally misbehaves. And therefore are willing to do the wildest things and take the most bizarre shortcuts to achieve their results.
the other day I was in a hospital waiting room, i wanted to crop a pdf for reasons… I installed and ran a Qt powered KDE pdf cutter on my home linux box over tailscale in like… <10 min. It just worked. ssh -X on an arm mac to an intel linux box. X has been working like that for me since 1998, and if anything it’s way faster now (assuming a good network).
What does wayland give me now or tomorrow, and how could it ever support as wide a breadth as the extant X ecosystem?
Running multiple monitors at different DPIs in a coherent way is basically the one thing. It’s not quite as impossible on X as they claim it is, but it would be a pretty grievous hack. Apps just deal with coordinates differently on the two systems, and Wayland’s way is more flexible.
Everything else I’ve seen is pretty spurious. It’s either “our way is just so much more modern!” or it’s “X doesn’t do that and never will! (Why?) Because we’re all working on Wayland.” Software is like that, particularly in the open-source world. There are fads, and once people decide that something has run its course, it becomes a self-fulfilling prophecy.
I’ve been doing this in X for a while now, it is very simple and works fine, for applications written to support it (so there’s no automagic scale for legacy clients, but tbh I don’t want that anyway since it almost invariably looks awful anyway). xrandr describes regions of the screen associated with each monitor. You set a property that sets scale factor. Application does the rest - this is more-or-less how per monitor dpi version 2 works on Windows too, it isn’t some “hack”, but rather the best solution settled on after they tried a lot of other things. Wayland’s experimental fractional scaling protocol also does it this way, dropping their previous approach.
My big complaint with X is just that nobody has standardized the property. So my lib does it one way, Qt does it another, gtk…. just doesn’t because gtk doesn’t want to. But interestingly, there is an X extension in the works from the Wayland people that might finally standardize on it in the name of interop w/ the new wayland protocol! lol. And their solution? A global root window property showing the monitor scale factors, same thing easy to do (and frankly the obvious solution) since day one after they spent years saying it was “fundamentally impossible”.
It is not a fundamental limitation to Xorg. In fact it can be slightly better than the “looking over the shoulder of Win/OSX copying the approach but not understanding the legacy or history of the problem that scale factors added to the mix” Xorg had printer support as those are a substantial part of the evolution of the problem space. Printers were/are the highest-DPI slowest “framerate” around with very different colour spaces. It is not a new problem at all. Last(?) thing Keith published were PoC patches adding scaling attributes per window that worked.
The better approach is to move the Xft.dpi atom from being in the root to being per window and check it on configure events, set a presentation DPI ATOM back as a signal to indicate that the client can do density-aware rasterisation and the rest can be done server side. Any average vector engine can take HDPI,VDPI as input and spit out draw commands or a rasterized buffer, Font size expressed in PT reflects the real world “this is my readable comfort size”. The rest is high school math.
The misdirect of “oh but we want a window to look good stretched across multiple mixed DPI displays” is more in the ballpark of “play dumb games, win dumb prizes” though again, the abstractions in DDX allows you to do that. Nothing in the Wayland approach fundamentally solves that and the problem re-appears when you have displays with other varying properties, whether that is e-Ink, lenticular, laser projectors or HDR with different tech/specs.
The actual problem are in three places - 1. Xorg-modeset, is a monster and all sympathies for any engineer that tries to do anything with it. 2. The other is the politics around Xlib/Xcb. This is partly what gives me a whiff of a scent of IBM.RH having a competitive intelligence team playing on offence right now (It is a billions-of-dollars endeavour, of course they have several and some are bored). 3. MESA.
Maintaining all of Xorg and reducing the DDXes to basically “Xorg-wayland” is from what I can tell a salaried position (O.Fourdan) and much of MESA surely is. If you would try and pick up the reigns of Xorg-modeset to draft new releases of that, expect slow moving procedure and red tape resistance to the eventually necessary changes needed in support libs and toolkits. The idea of doing that on your own dime requires strikes me as unappealing to say the least.
The MESA thing is where workarounds that fix games for the idiosyncrasies of Wayland will accumulate, while not doing the same for Xorg-yourhostilefork. Over time this will be really draining to work with, there is a lot of “visible code but secret sauce” hidden inside that thing, just as there is with nvidia blobs.
I do want this, though I don’t really understand why it’s hard. Toolkits over worked with all have some variation of an abstraction that is ‘draw this rectangle of your view in this graphics context’. The graphics context is the thing that knows about DPI (and colour spaces and so on) and so the only thing that the window server should need to tell you is ‘this rectangle of your window has these settings’ and then the toolkit can just draw the rectangles that are on different displays with a graphics context that matches those settings. It’s mildly annoying for compositing toolkits because they can’t reuse cached textures during drag events across different-dpi monitors, but I fundamentally don’t care about performance while moving a window that spans displays: if it works at all that’s nice, if it works fast that’s nicer.
It’s one of those “Why is it hard with an unaligned instruction across page boundaries” type of problems. There is a set for which this is easy, say low-cost-low-refresh-shallow-buffer clipped viewport software rendering which, as you say, just slide the viewport and reraster/compose based on sink-provided properties.
For hardware acceleration and games especially there is a whole can of earthworm jims in there. Buffer queues run deep (“in-scanout, queued for scanout, target frontbuffer, target backbuffer, …) render passes are expensive (see one of those “what goes into a frame” breakdowns), memory of the right type and encoding scarce and content is increasingly specialised for the properties of that one display from subchannel bias and level of detail all the way to foveated rendering. Just deviations in synch, nevermind slew rate adjustments with VRR, can easily nudge you into thrashing and inconsistent frame delivery (jitter, judder) as the “signal” for the one display is sampled at a different rate than the other.
What I’d personally want (and have for my stuff but toolkits ruin all the fun) is to retain a primary uncomposed “ideal” surface and let me request different representations of that at mildly or wildly different content states with the controls for seeking, etc. formalised on the IPC level. With that as a requirement in your pipeline, requesting another viewport comes by default.
There’s a lot of negative-on-Wayland posts lately, so in case it’s helpful to people considering switching: I recently switched from x11+i3 to wayland+sway about a week ago, so far my list of things that don’t work:
xdg-desktop-portalsolution that was merged not long ago but has not been implemented widely yet: https://github.com/flatpak/xdg-desktop-portal/issues/624swayidletemporarily as a workaround.Everything else works great!
I ultimately want to migrate off of sway, but I mainly started there because the migration from i3 has been extremely easy (99% of my config was compatible). Thinking of playing with River soon, might be fun to write some zig.
This isn’t necessarily a reply specifically to you, and if your setup works for you, fantastic, I envy you, but every time someone posts their experience, it always reminds me of people talking about moving to linux in the early 2000s: “Oh yeah, it’s great. I don’t have wifi and I can’t play two audio sources at once without a workaround, but it’s perfect other than that.” Wayland has its advantages, some of which I’m sorely wanting, but for something that I’ve been getting told is ready for use for like a decade, it really seems to be lacking a lot of features to be set as the default.
I never liked that meme, it ignores the million things I can do with my Linux setup that is impossible to do elsewhere. Yes, it sometimes takes more effort, but most of the effort pays dividends for the rest of my life (especially since I’ve switched to NixOS where I avoid stateful side effects that are ultimately lost so that the declarative configs survive system upgrades).
I don’t think anyone has ever tried to sell Linux as something that requires zero effort and zero learning, and frankly any operating system that did try to sell it as that was lying. Yes, even macOS required adapting and getting used to.
There’s something to be said about putting effort into something because we get proportional value in return. I certainly feel that way, but I never felt that way when I used Windows. No amount of reformatting and reinstalling helped me feel like I was actually coming out ahead.
Many of the things I like most about “Linux” are actually unique features of the X Window System…
That is totally fair, and exactly what I like about open source. :) I have no doubt that there will be a forked version of X11 that is maintained for all the eons to come.
That doesn’t seem likely right now. Xorg already has the issue of people not wanting to maintain it today. If the current maintainers are abandoning the project, why wouldn’t the interested parties join right now? They wouldn’t need to fork the project, but literally say “I’m interested in maintaining this”.
Xorg is plenty maintained right now. This is just a myth. When you open a bug, you get a same-day reply, there’s things merged into it on a regular basis. There’s even new features coming out pretty regularly, including new extensions in 2023. Half of them are related to Wayland interop… but the other half aren’t.
The thing that hasn’t come for a while is a formal numbered release. I guess the person who did packaging quit.
We’ll see, I suppose.
There’s a big difference between taking over an existing project (with all the baggage that comes with it) versus making a fork and trying something new with it. Also some people don’t act until they have to.
To be clear I was a Linux on the desktop zealot in 98, 99, etc but after the intel macs came out I’ve been mac first and ssh to linux later. I did comment here because sometimes I ssh -X to a linux box, but oddly 3 things wreck me about Linux these days which have little to do with the compositor or whatever it’s called.
At any rate, thanks for your contributions (<3 ssh-chat), I think you are doing Linux the right way, I just don’t have the time to maintain that sort of setup beyond a few boxes to ssh to.
I don’t have much good to say about X-forwarding over ssh, this was always a half-working system. But overall, it sounds like you just want a more polished and batteries-included desktop manager like KDE/Gnome, or a distro like Pop!_OS (haven’t tried it myself but hear good things).
I don’t mean that there’s any shame in using what works for you, especially if it makes you happy.
We make time for the things that matter to us. If it doesn’t matter to you, then I can understand that you don’t have time for it. Just don’t let past impressions keep you from enjoying today’s progress. :)
Somehow I’ve gotten used to window obscuration and the normal windowing metaphor, i’ve tried ratpoison and i3 but never for more than a few minutes before I figured I could use my limited memory for something other than shortcuts. It still amazes me how much better the base installed Linux distro (pick a distro) is from the
startxdays, but yea I’ll dip my toe again sometime.It’s realistic. I could write a list of “things work, apart from …” for all 3 major systems I’m using. They’re still useful in case you want to know the situation on the other side.
For example: Yeah, MacOS mostly works for me, with some annoyances like issues with sleep, dtrace being broken for the last 2 years, filesystem freezing when browsing huge directories, bad latency on audio devices, inability to change Bluetooth codecs, smartcard login not working after sleep, … Yeah, Windows mostly works for me, with some annoyances like active sleep being completely broken, no config for dock mode, no package manager, no reasonable package format, lack of client SMB share configuration, no built in support for extra filesystems, no self-describing configuration, …
And I’m being told they’re production ready for decades now! If you don’t have your list of remaining annoying/broken/unfinished things in your favourite / most-used system, you likely haven’t used it hard enough ;)
Wayland seems to be a textbook case of Joel Spolsky’s famous essay Things You Should Never Do.
That’s not a similar case though, is it? Wayland is not a rewrite that can be a destination for gradual changes from Xorg. It’s a massive architecture shift that changes the basic assumptions of how the system works. This is more like writing NFS when FTP already existed.
Which case? He mentions various cases. The post makes a general point about rewriting large codebases with the intention of doing everything better this time.
Perhaps it should have been.
You can’t advertise a new solution as a drop-in replacement when much of the previously existing functionality is now broken or unsupported due to the pursuit of abstract architectural purity. They can challenge whatever assumptions they want, but if the end-user faces endless breakage across the board, none of that matters. The problem is when architectural beauty has a higher priority than user concerns, because the point of software is to provide value to the user, not to delight software architects. Many Open Source projects exhibit this problem because people like creating beautiful abstract designs in their spare time and there is no (financial) incentive to get it right for the user.
Yes, the post is about rewrites, rather than redesigns - as in cleanups that mostly do the same thing. Wayland is not a drop in replacement and wasn’t intended to be. Xwayland exists exactly because a compatibility layer is needed.
Even for the example of Juno with architectural changes, he mentions things were moved around and cleaned up. That’s not what Wayland does - it explicitly changes how things work, because the authors don’t believe the in the previous way of doing things, rather than just the code.
It’s more like writing SMB when NFS has existed for 40 years, in an alternate universe.
I guess my brain is now conditioned to scream “GPT” at me..