> x is not actively maintained any longer. And wayland is >10years old.
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.
Software is never complete. And even if it was the world around it moves on.
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.
There's some basic software that can be seen as tools and sometimes are even called as such. They are like a hammer and while it might be cool for some people to have a hammer that has WiFi, Internet and a small 4k screen included (so that you can watch netflix), many don't like that additional functionality and all they really need and want is a hammer.
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).
This is at least somewhat circular logic. The arrival of Wayland is a big contributor to killing people's motivation for further development of X. Had Wayland not arrived, somebody might have well been inclined to solve problems in X instead.
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.
The use of "arrived" was precisely to abstract from this sub-discussion.
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.
Doesn't change my point: Wayland is not some truth revealed that had been bestowed upon the developers who then seen the truth and went away from X. The set of people working on Xorg and Wayland was overlapping so much, that work on Wayland stole (took away, diverted, see thesaurus if my choice of words grates on you) cognitive resources needed to maintain Xorg.
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.
I think we're largely in agreement. I just got the impression that you treated X developers as a homogenous group who all think that what happened was the best thing. That's not the case.
If X isn't actively developed anymore, it's because wayland has sucked up the remaining developer resources I guess. Apart from a very brief episode in late 90's I'm not into X development so I'm not in a position to have an opinion, but I'm having trouble with "the way forward" argument, considering we're already long past peak-desktop. I'm more concerned with the precious few desktop apps we have (towards which there were nearly no additions in the past decade) and loss of niche apps due to additional Wayland porting, integration, QA efforts put on developers of said apps, which realistically might spell the end for many extant desktop apps.
If all of GNOME/KDE/wlroots work under wayland, isn't that pretty good? Three implementations might be good enough to ensure the wayland protocol is sufficiently independent of the implementations?
there are many electron-based applications (like VsCode) as well as wt least one important Java Swing application: IntelliJ.
Both kind of applications, electron and Java Swing, were facing severe issues on wayland when I tried it a year ago on sway.
Nope, it’s “Drew Default”. Since the first paragraph demonstrates a pretty grave misunderstanding of what Wayland actually is I’m going to assume it’s not the developer of the most popular Wayland compositor library.
It's rather sobering that wayland still has substantial issues more than a decade after work on it has started. This leaves me wondering whether aggressively evolving Xorg would have been a better choice. Maybe Xorg security wouldn't have been fixed completely that way. But almost 15 years later it hasn't been fixed at all - wayland hasn't arrived.
Yeah I've been running Wayland on my desktop since quite a while now. There were minor issues when Fedora made the switch to wayland as default, but since at least a year i haven't had a problem that switching to xorg would fix.
- 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.
Yeah me too, works flawlessly on my laptop. On my main PC the non-GTK apps go glitchy after resume so I'm back with xorg, but Wayland is very nearly there.
Good for you, but that's merely anecdotal evidence. From the limited data that is available, it appears that more than half of the desktop Linux installations run nvidia GPUs. Wayland is pretty much out on those. And the rest needs to run a distribution that supports wayland and activate it. So wayland simply hasn't reached its goal of replacing Xorg by a long shot.
Wayland Gnome (and plasma) runs on nvidia gpus as well. But the fact is, linux, the kernel doesn’t support nvidia cards without proprietary blobs, hardly anything to do with Wayland.
I also had doubts but there are statistics (arguably not representative) that seem to confirm this: https://pkgstats.archlinux.de/fun (See GPU drivers and add(might not be the best idea, I know) the nvidia numbers...)
It might be machine learning stuff which heavily leans into nvidia hardware
Just adding them all goes way beyond 100%, so it really is not the best idea.
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.
Wayland is there, but it's always gonna be a step by step approach. Overall it's already in a really good shape. On quite old computers, it's performing quite better than xorg for me.
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.
What are the substantial issues? The “article” fails to mention anything concrete (guess the reason for that).
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.
I have a lot of disagreements about things said here. For example, I suspect wlroots based compositors are not particularly inefficient, therefore I’m not sure I strongly agree with the ewaste issue. GNOME 3 doesn’t seem particularly lightweight either way; most low end devices would not be running GNOME and KDE to begin with. Also, wlroots is listed alongside GNOME and KDE, but it is a library or framework for Wayland compositors. It’s an ecosystem of compositors. wlroots is basically a logical conclusion of Wayland’s different approach versus X; since the DE/WM is the compositor, it makes sense to make the common display server components into a library, the same way you would hope GNOME and KDE would not reimplement Xorg (though the lower surface area of Wayland and shared components like libinput and libwayland make it more tenable that they do in fact implement their own Wayland compositors largely from scratch.)
> 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 is not xscreensaver though. This is important because jwz, xscreensaver's author, has written about this at length [1,2]. He was very careful to make the core of xscreensaver as small as possible to avoid crashes.
True, and certainly a fair distinction. Perhaps I should say that a vulnerability of this nature - involving an xscreensaver fork - has occurred in practice.
It can actually be avoided on X11 if you're willing to make the screensaver an integral part of the desktop environment. The way KDE has done it since the KDE 4 era at least is by doing the actual screen locking in ksmserver and having the unlock screen and password entry dialog as a seperate process. This has two effects: crashing the password entry dialog or the screensaver will not unlock the desktop, and if you do somehow manage to crash ksmserver the session will immediately terminate, because ksmserver exiting for any reason is how X decides that the session is over. This is a bit like Wayland's solution, except with much less potentially buggy and crashy code in the process responsible for locking the desktop.
The Referer header can't die soon enough. Or HN could implement rel=noreferrer (at least on links to this website) or the relevant CSPs. Or jwz stop doing this redirection but I don't see this happening.
Replace "Rewrite-it-in-Wayland has become a moral imperative. " with Rewrite-it-in-Rust (for example) and many of the "arguments" immediately apply. E.g. "You could also code in C without bugs!"
... and I now realize this was done intentionally. Shame on me.
I was picking up on the intentional irony, but it also has me confused. I was not able to pick up on if this piece was purely parody, partly parody, or just drawing parallels to support arguments...
The name “Drew Default” was not lost on me either.
This seems to have been downvoted. If someone knows of any performance analysis of wlroots, with a per frame analysis of perf, please go ahead and share it.
A big assumption, but I think you use X with a compositor, which will have no tearing as well. Eg gnome and plasma does use compositors by default.
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)
Drag a light color window (empty textpad) with a mouse very rapidly left and right across the dark desktop. You should see the tearing if you don't use a compositor. Tearing looks like the window is made of two unaligned halfs (top half and bottom half). With a compositor, the window is always perceived in one whole piece.
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.
so, this is it. Yes, I do have tearing, especially visible on very large windows. It's a sort of frame refresh glitch, isn't it?
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.
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.
This is complete tragedy for user like me, who can't stand window decorations and see no use for it. This lack of coherent look and feel seems as very backwards step to visual smog. Thanks but no thanks.
The lack of server side window decorations has much more severe implications beyond aesthetics. Unresponsive applications can not be closed by clicking the X button. And for the compositor to find out if an application is unresponsive or not literally means solving the halting problem.
> Unresponsive applications can not be closed by clicking the X button.
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.
Strictly speaking, Wayland doesn't need it. The connection is always unix socket, so it is easy to find out the pid on the other end, reliably, without relying on well behaved client setting up things correctly.
I generally like CSD, but I think SSD support should be a standard. But I just wonder about a side solution: wouldn't it be possible to do a CSD wrapper app for apps not rendering their own decorations? It would be a proxy Wayland compositor, that would push out windows with decorations. It could even support XDG-Decoration. Of course it is not a perfect solution, because then packager or desktop environment would have to decide if to wrap the command invocation with this proxy compositor. It probably could be done with two .desktop files one with the wrapper and OnlyShowIn=GNOME and the other without it with NotShowIn=GNOME.
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.
Windows is sort of a hybrid. The close/minimize/maximize buttons, border, and background blur are rendered by the server (the background blur on Vista and windows 7 couldn't possibly be rendered by the client), but I think the window caption is rendered by the application.
macOS uses client-side decorations in its windowing system, and doesn’t have this issue with inconsistency. Maybe the problem is not in the design of the compositor?
Cocoa (and most Wayland compositors) have default decoration. Gnome does not. That's left to app makers to do it. The issue is not the design of the compositor, just the lack of a default decoration.
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.
The biggest problem of Wayland is that it has the wrong philosophy ("Every frame is perfect") and the wrong abstractions ("Everything in the universe is an array with RGB values"). If your foundations are flawed like that no "slowing down", "specification writing" or "focusing on improving your protocol" as suggested in the article will help. You are doomed from the start. What remains is a very expensive and cumbersome way of blitting bitmaps.
? Philosophy-wise, I don’t see how having “most frames are perfect” any better. We are talking about a soft-real time compositor whose only purpose is putting correct images to the monitor(s).
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.
The Philosophy is completely wrong on many levels.
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).
> 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.
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.
It'll take another Poettering to bring Linux well-working VFR, HDR and good color-management. The same cycle of Pulseaudio and systemd is repeated.
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!
The problem with SDL's Wayland backend is that, as I understand it, you won't get any window decorations on common Wayland compositors like the Gnome one because Gnome expects every app to implement the window decorations itself (and the expected way to do this is by dragging in the entirety of Gtk, even if you're not using any of the other functionality of the toolkit). It looks like SDL are working on some kind of solution but it doesn't seem to be ready yet.
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.
Just forget about this “article”. It’s the same old “hate on something I have no idea about, but if I write a blog post than it will sound authentic”… Which is unfortunately very common with the cargo hating on some linux technologies like Wayland, anything even looked at by Poettering and the like, or even firefox.
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.
Does anyone know how the NVIDIA situation with wlroots is now? I've heard NVIDIA is _finally_ supporting DMA-BUF instead of only their fundamentally different EGL streams, so I wonder if it's actually functional now.
This piece is more philosophical than practical; it doesn't raise very many (any?) specific issues.
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.
> However the competition is X which is effortlessly surpassed at a design level.
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.
EDIT: I've only seen that this article is a parody after I've submitted this comment. It makes the comment kinda pointless, but the parody should somehow include that it is a parody (and actually link to the article it is a parody of). Some arguments in my comment seem to also apply to Drews original post, but not all (mostly because he links the platform support in the beginning, providing a source for the hardware/stepping out of the norm-thing).
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.
This article should probably be marked as a parody somehow, it seems that most people in this thread does not know that it is a clear parody of one of Drew DeVault's articles in particular: https://drewdevault.com/2021/02/09/Rust-move-fast-and-break-...
Thanks for pointing this out. It seemed like a parody of something about Rust, but the effort put into applying it against Wayland was enough to fool me into thinking it might be genuine.
This appears to be an attempt at trolling or bait (“Drew Default”) but I’ll bite to not let some claims go uncontested (I also like spewing my opinion on Wayland everywhere).
> 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.
This is the first time I made a throwaway account, not because I care about my karma, but because I don't want wayland devs and distro maintainers to trace this back to me or the projects I contribute to.
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 the first time I made a throwaway account, not because I care about my karma, but because I don't want wayland devs and distro maintainers to trace this back to me or the projects I contribute to.
This is not normal. This is as close to an abusive relationship as it gets.
100 comments
[ 2.5 ms ] story [ 173 ms ] threadYes, 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.
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.
> 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.
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.
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-...
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.
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!
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.
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.
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.
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.
> 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 compo...
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.