Wayland: “Move fast and break things” as a moral imperative
rentry.co
rentry.co
> However, Xorg code can be secure! Just look at xscreensaver,
I am rubbed the wrong way by this, because it sounds a lot like “just don’t make mistakes!” — if there’s any way to crash xscreensaver, that is a potential security issue...
This has happened before: https://github.com/linuxmint/cinnamon-screensaver/issues/354
[1] https://www.jwz.org/xscreensaver/toolkits.html
[2] https://www.jwz.org/blog/2015/04/i-told-you-so-again/
(open these links in a new tab or by copy-pasting the URL)
... and I now realize this was done intentionally. Shame on me.
The name “Drew Default” was not lost on me either.
AFAIK, nobody has done any performance analysis on wlroots, so nobody knows whether they are efficient or not.
They are "fast enough" for most people, so nobody has felt the need to look into this either.
Wayland has been a nightmare to support, and supporting it usually means having a bunch of wlroots-specific, kwin-specific, and gnome-specific code, and just forgetting about weston, the so called reference implementation.
Certain distros have switched to wayland as the "default" desktop without upgrading application software to link against wayland, and we are now getting bug reports from distro users that are specific to xwayland.
Sway is the most standards-compliant compositor, but I can't expect users to install it when something is broken on gnome 3. A lot of application software was ported to gnome 3 specifically, using gnome-specific protocols, so switching back to Xorg is sometimes easier than switching from gnome to sway.
This is not normal. This is as close to an abusive relationship as it gets.
Everywhere:
- Barrier does not work
On KDE Plasma (openSUSE Tumbleweed):
- Thunderbird often flickers a lot, rendering it unusable
- apps like cheese or kamoso to access the webcam don't work correctly
- selection paste now works after years of waiting, but is not shared between GTK and KDE apps
- X apps are other slightly blurry when witch scaling DPIs
On Phosh on the PinePhone (Mobian):
- VNC does not work. It works on Gnome because it is implemented in Gnome's compositor, but back luck, not in Phosh. Each Wayland compositor has to implement this. So there is nothing like scrcpy on Android that I know of on GNU/Linux phones yet, which would come for almost free with X11.
Each feature has to be implemented by each compositor. But then it may take years because people rightly seek to build standards that can make it work between all the compositors.
And I still rely on X11 for network display of apps, even between two Wayland systems (though it's not an issue for me, but it is a bummer because we can probably do better than this).
It seems Wayland works well if you use Gnome and that you don't need anything slightly fancy. It still does not have this "this will work no doubt" feeling that I have with X11.
I'm very careful with apps I run and install on my machine. This security-first design is honorable but gets in my way with seemingly no benefits for me.
I've been really blown away by how much snappier it feels - not sure if it's the wayland, gnome or btrs etc changes but I'm a very happy user.
As a side note it's also the first clean install I've done on that laptop where I haven't encountered pain with the nouveau drivers
Where did you get that data? Nvidia doesn't even have that kind of market share (Intel absolutely rules there).
It might be machine learning stuff which heavily leans into nvidia hardware
In general, the market share (as in GPUs sold, in total, for all systems, not just Linux) was around 70% Intel, 17% Nvidia and 13% AMD. This was before GPUs turned into inobtaniums, so I guess Nvidia and AMD didn't improve their positions much.
Yes, there are ML guys on the Linux side, but that could be compensated by gamers on the Windows side, so I assume that if anything, Windows would have more share of Nvidia than Linux. Miners don't really care for desktop.
There is a place where Nvidia achieved significant share - it has 70% in Steam hardware survey. That is to be expected, gamers are heavily biased towards Nvidia.
I wonder what would be the current situation though if Canonical would have chosen to invest in Wayland in the first place and Google would have chosen Wayland for its Chromebooks.
Things have been moving at a much faster pace lately and I would expect things to mature as Ubuntu is switching to Wayland by default, Chrome and Electron are landing a wayland backend.
Interestingly enough many people use it from day to day without any problem. Screenshots, screenshare works with pipewire, it is even superior to the old way. Chrome does support Wayland now, and even electron apps do, so basically all the old problems are solved.
But just to add a bit of content on why does the article hold no water:
> Even on the supported platforms it comes with a substantial burden on build requirements, calling for 10× to 100× or more RAM, CPU time, and power usage.
Completely false. While there is the old but true “wayland is a protocol not an implementation” adage, the protocol itself imposes very few requirements, in effect making wayland implementations more efficient than X. Did the “author” check the actual requirements of the x server process plus the window manager? Like, the window manager under X barely does any work. And it is not an accident that Wayland is used in embedded software instead of X — eg. some car displays do use Wayland with great success.
Also, the whole part about climate change and throwing away computers that I guess tries to build on the false statement that Wayland is more resource hungry is just pure emotional cry for some technical content the author fails to provide.
Re the security “claims”: xcb is yet again not a complete compositor written from scratch. Compare apples to oranges. And no, X is fundamentally insecure. It is possible to achieve security in x by nesting instances but there were other technical problems already with x making it unsuitable as a base for anything display related. And Wayland doesn’t solve security itself, it is a required, but not sufficient part of it (namely client isolation). And XWayland exists for a very good reason: it is exactly what is needed, a backward compatible and secure shim for using the litany of existing software on top of an actually performant and secure base.
EDIT: it is a verbatim copy of one of Drew’s articles, just with Rust replaced with Wayland. Now I see at least why it makes absolutely no sense whatsoever.
Well, it appears that his and only his name leapt to your mind as a figure known for upsetting people. He's in a class of his own for stepping on toes.
No questioning his chops as a developer and general net positive contribution to the Linux ecosystem; but it has been a two-forward one-backwards journey.
I agree gnome Wayland was shipped too early in Fedora and Ubuntu, but it's a very smooth experience today.
Or maybe this was for app development? In that case I agree supporting Wayland exclusively isn't a good move today. But if you write an app you should really get QT, GTK, SDL or similar to do windowing for you.
Here's what a desktop looks like without server-side decorations: https://i.redd.it/nj4y50dcbza11.png . It's stupid. There's no excuse for not offering a default "look and feel" of windows for your users.
As an app developer, my choice is to ship a whole third-party library just to draw those things, or have a rectangle without borders show up in your user's computers.
They cannot be closed with server decorations either; if the client doesn't process the even queue and ignores WM_DELETE_WINDOW, it doesn't matter who paints the decoration.
> for the compositor to find out if an application is unresponsive or not literally means solving the halting problem.
Not in Wayland; if the client doesn't process events, the compositor knows that. It is just a matter of deciding on timeout value and then letting the user know (mutter does that, for example).
---
However, client side decorations ho have much more severe implications beyond estetic. For starters, with server decorations, you cannot guarantee frame-perfect synchronization of decoration and client area painting; with client decorations, you can, the same process does it.
It sucks that GNOME's world view on the issue is a push back for other projects.
Windows is CSD AFAIK, but when the app is not responding it will draw decorations for it. That's one of the many benefits of supporting it.
i.e. https://answers.microsoft.com/en-us/windows/forum/windows_7-...
Yes, switching is causing issues and some chafing, but no one questions the fact that it is the way forward.
I do receive Xorg updates from time to time on Arch, so I don't think it is unmaintained. It don't get any new features as far as I can tell, but for some this is a good thing. I don't like a display server that moves fast and breaks my system.
Will you never want HDR, colorspace support, and whichever feature is next? Even if that is somehow the case, I would think most people aren't software archivists.
For the record, I do actually work on the analysis and processing of hdr and multi- and hyper-spectral images. Using 8 bit rgb colors on my monitor is still alright, and I'm very happy with X (and I would probably still be happy with wayland, I really don't care).
Yes, yes, people who actually worked on X didn't like it already. But the total amount of work of fixing the issues via Wayland is surely larger than the amount of work fixing them via X would have been.
Going with Wayland wasn't a good engineering decision, but it was probably a good social decision.
But since you raised it: your description is quite misleading. One person proposed Wayland. Some others (who happened to be already unhappy with X) thought it was a good idea. Most of them were or are involved in Xorg directly or indirectly. But the development of Wayland was not some upfront decision by X developers.
And then they just stated a fact "oh, see, no one wants to maintain Xorg" as if they didn't know. This atmosphere of faux surprise is what I didn't like at the time. Also the unwillingness to publish a step-by-step guide of "how to make a release" with simultaneous unwillingness to make releases. I bet if there appeared an actor actually willing to take up maintainership of Xorg, that actor would be actively smeared, gatekept and bottlenecked to death by the current Xorg gatekeepers because Xorg dying and their crippled darling taking over is their dream.
Wayland isn't perfect. However the competition is X which is effortlessly surpassed at a design level. Building up the scar tissue will come in time and the practical issues will be solved by hook or crook.
It is easy to have sympathy for the people who have working X setups and are inconvenienced by change. However, there is a desperate drought of people with the know-how and willingness to work with X and the linux graphics stack has well and truly moved on.
I strongly disagree. Wayland makes the wrong abstractions and does not offer vital functionality usually needed on a Desktop system. As a result every Toolkit/Compositor has to implement that additional functionality itself and most of the time it is incompatible to the competitor for no apparent reason. X might be old and has accumulated a lot of cruft over time (which is excusable for software that is almost 40 years in use) but is genuinely superior at the design level.
As an exercise I recommend to write a native universal applicable Wayland application that takes screenshots.
And Wayland supports plenty of formats for bitmaps, not sure about what you mean by your “wrong abstraction” thing. The only requirement is that both the client and server should know the given format, but there is proper “hand-shaking” about it.
On one level for some applications you want "every frame is recent" and can tolerate some glitches as trade off for not having perfect frames. Also displays have different pitch values, subpixel arrangements, color spaces, etc. A line from A to B might look completely different on different monitors. By offering only RGB arrays as abstraction Wayland pushes the the need for care of those differences down to clients which is a mistake.
On another level a Desktop system in general is much more than a bunch of bitmaps blittet together. Applications need to interact and such functionality has to be tightly integrated into the compositor with standardized protocols otherwise it will be impossible to have such functionality. As example I recomment implementing a native Wayland client that takes screenshots and works on every compositor (Impossible because something as essential as taking screen dumps is not even part of the core protocol).
There are protocols to circumvent frame syncing for the rare case it is needed, so it is solved.
And as I already said, it doesn’t offer only RGB arrays as abstraction. Yeah, color management can be made better (there is ongoing work regarding that), but the protocol is extendable so it’s more of a when question, not an if. And it’s not like X solved it.
And about the screenshot: the problem here is that they want to create a good API for that. It should be pipewire-based in the opinion of gnome devs, and wayland based in case of wlroots. The actual problem is more difficult than “dump all the pixels”. And even if no agreement happens, the protocol allows for querying available protocols so a cross-DE screenshot app is entirely possible.
People will certainly loathe, The Replacement and the replacers are certainly quite arrogant and makes new mistakes, but The Old One and the old ones even more so. Toes are stepped, epic forum threads are written. But in the end The Replacement ends up as the dominant solution and others maybe limp to catch up, maybe not.
After a decade or two, a New Implementation appears that finally learns from the mistakes of both The Old One and The Replacement. Users have gotten what they need, rejoice!
Ok I’m not a dev but I certainly enjoy Wayland as a user.
But in case you just have a very fast computer/smallish resolution and don’t notice tearing, try to watch a video in full screen. This basic functionality doesn’t work with native X, without additional tweaking (like hardware level frame syncing, etc)
I assume the full window content is visible when dragging, not just a border rectangle as sometimes happens when the compositor is disabled.
Also, not everybody notices it, just like not everybody notices text with bad kerning or individual instruments and percussion elements in a song.
Honestly, I couldn't care less. But then again, I'm extremely picky about bad kerning, bad font hinting, and bad antialiasing. And I could start caring about this also... So now I hate you for ruining my life even more! Fortunately, I never move windows around so I guess I'm still safe with Xorg.
What is this "Wayland toolchain" and where are its tens of millions of lines of code exactly?
For comparison SDLs wayland backend implementation is like <10k lines of code: https://github.com/libsdl-org/SDL/tree/main/src/video/waylan...
As it stands, though, it's probably not feasible to actually ship a game with Wayland support using SDL due to the potential support issues from people not running in fullscreen mode being stuck with a window that can't be moved, minimized or closed in the usual way.
> Wayland ostensibly supports several dozen extensions, but only the GNOME-blessed extensions can be reasonably expected to work.
Instead of actual protocol extensions it seems like the author is talking about desktop tools. “only the GNOME-blessed extensions can be reasonably expected to work” oh GNOME and nowhere else, because GNOME has a pretty loose relationship with standards. Meanwhile the rest of the ecosystem is unifying behind wlroots.
> I can assure you that it’s a nightmare. Creating a new compositor would be a hellish experience. Ask any distribution packager who works with Wayland to share their horror stories — they have many.
Distribution packagers try to make compositors? Maybe they should take a look at wlroots.
> Even on the supported platforms it comes with a substantial burden on build requirements, calling for 10× to 100× or more RAM, CPU time, and power usage.
Obviously not. Some sessions on GPU acceleration being available nowadays, but that’s not a new development. The GNOME Wayland session has been demonstrated to be faster than the X session (many years ago on a Raspberry Pi).
> Novel hardware which addresses issues like microcode and open hardware, like POWER9 and RISC-V, are also suffering under Wayland’s mainstream-or-bust regime.
Why? What does “mainstream-or-bust”? Probably not the protocol maintainers’ tendency to compromise on things to make Wayland not appealing to average users (ha).
> Anyone left behind is forced to use the legacy Xorg codebase you’ve abandoned, which is much worse for their security than the hypothetical bugs you’re trying to save them from.
Xorg, by design and historical growth, is insecure. That said security fixes will of course continue to be shipped (I don’t say this with any internal knowledge of Xorg maintainable, only trust in the FOSS ecosystem). Of course, the user base is still huge.
> Rewriting your code in Wayland is always going to introduce new bugs, including security bugs, that wouldn’t be there if you just maintained the Xorg code. Maybe there are undiscovered bugs lurking in your Xorg codebase, but as your codebase ages under continuous maintenance, that number will only shrink.
Xorg is insecure. Not because of bugs, but because of features people rely on.
> Those of us who work with such systems, we feel like the Wayland community has put its thumbs into its collective ears, sung “la la la” to our problems, and proceeded to stomp all over the software ecosystem like a toddler playing “Godzilla” with their Lego, all the while yelling at us old fogies for being old and fogey.
I agree. I consider ”Out of scope” to be the unofficial Wayland motto.
The summary at the end is a beautiful soup of contradictions.
> Slow down the protocol
It’s already fairly slow.
> write a specification
That’s what a protocol is, isn’t it?
> focus on improving your protocol extensions
By that do you mean adding more? I thought the protocol was developing too quickly?
> support more Xorg programs
The charitable interpretation is that it means “support more Xorg use cases”, which is completely valid. The way it’s said would also allow for the interpretation that the author hasn’t understood what Wayland is and wants X APIs added.
> work on performance, stability, and accessibility
The protocol allows for very high performance. If individual compositors are inefficient, please talk to their maintainers. This isn’t an issue with Wayland in general. Same deal with stability. The compositor I use (wayfire) is super stable. Unfortunately I can’t comment much on accessibility other than that I know that Linux has historically been pretty bad in this area.
> Invest more in third-party implementations like wlroots.
With it defining the third compositor type besides KDE and GNOME I think wlroots is seeing an healthy amount of investment. What’s going too slowly for my taste is the standardization and adoption of wlroots protocols by other compositors (will GNOME ever care about what other people are doing? Will they stay incompatible forever?).
> Your ecosystem has real problems that affect real people. It’s time to stop ignoring them.
I completely agree. The “out of scope” meme may have been holding Wayland back. We need much more standardization, akin to the XDG standards. There’s still a lot to do.
Original comment is below: --
I don't use linux on the desktop, so I don't have any horse in this race. But this article is just plain bad. I've heard often that wayland breaks things, but the author should actually refer to something instead of just saying "yeah it breaks things". The article only spawned questions that it doesn't answer.
> Wayland ostensibly supports several dozen extensions, but only the GNOME-blessed extensions can be reasonably expected to work.
What does GNOME-blessed mean here? Why would QT or anyone else care for what GNOME blesses? What extensions don't work because "GNOME didn't bless it"?
> As someone who has tried to use Wayland (and failed) for even a tier-two platform, I can assure you that it’s a nightmare. Creating a new compositor would be a hellish experience.
Why? This is just a statement without any source or proof. Makes it kinda hard to verify.
> Ask any distribution packager who works with Wayland to share their horror stories — they have many.
Same here. I don't know any distribution packager, so I can't ask. And the article just says "yeah it's bad" without telling how it is bad.
> Switching to Wayland breaks things for anyone who steps even a toe out of the norm of GNOME/KDE/wlroots on Linux.
What breaks? What is the norm? Without any references these are just words without meaning.
> Rewrite-it-in-Wayland has become a moral imperative.
Sure, I'm not deep into the linux-desktop game, but I frequent HN everyday, so I think I should've read this somewhere before. Who really says "Rewrite it in Wayland"? (And not "support wayland, too")
> Novel hardware which addresses issues like microcode and open hardware, like POWER9 and RISC-V, are also suffering under Wayland’s mainstream-or-bust regime.
I really don't undertand wh novel hardware is suffering from Wayland.
> Just look at xscreensaver, which I guarantee you has fewer bugs than, say, gnome-screensaver.
gnome-screensaver has been abandoned for years (https://gitlab.gnome.org/Archive/gnome-screensaver) and probably doesn't support Wayland. So the point here is "some software that uses Xorg is safe, other software is not", which ... yeah. Some software is good, some software is bad. Doesn't tell anything about Wayland/Xorg.
I think the article has some valid points. Especially the part about the complexity in the third-last paragraph (if it's true, which I cannot verify here because the article doesn't show anything). But the biggest part of the article smells so bad that it's hard to take the whole article seriously.