Wayland's protocol is basically an isolation prison that requires "big DE's" and destroys choice. The protocol moves everything into one central place called the "compositor.” This machinery must provide:
- the window manager
- the hotkey daemon
- the compositing effects
- the windowing server
- screen reading tools
- screenshots
- screen casting
magnifying glass tools
global dictionary tools
etc etc etc everything.
Wayland's design makes it impossible to write a portable hotkey daemon for instance. Supposedly for "security reasons.” Wayland is a GNOME dev's dream, it kills the ability of people to control their own system. If you're actually excited for Wayland you either thoroughly misunderstand what it brings and just like it because it's new or you're a GNOME-lover who hates customization.
And don’t get me started on the security argument. If someone has arbitrary code execution on your machine, you’re already toast. I’ve yet to see an example of malware that can use xlib to read keyboard inputs on X (the supposed vulnerability Wayland was made to stop) but can’t just write some LD_PRELOAD hook to .profile or bashrc to make the compositor keylog on Wayland too. Is there a real world example where this supposedly great isolation that is easily circumventable actually prevented any security issue?
None of this is to say that X.org isn’t the accumulation of 30 years of cruft and technical debt but I don’t think Wayland is the right alternative.
Wayland forces you to move most of the logic into libraries that you can mix and match. X has this one monolithic server that nobody knows how to maintain anymore. You either use the only implementation or you live without a GUI. X destroys choice because there will only ever be one Xserver.
Is for me too on Linux. On both a variety of Intel and Nvidia GPUs. On a variety of distros. And everytime I ask around, I'm told it works for others, so it must be me. Everytime forcing X11 solves all my problems.
To be honest, last time I tried KDE on Wayland was a year ago, so perhaps it works now. Then again, so many years have passed where it turned out it didn't, that I'm not particularly keen to try.
The protocol says nothing about the compositor implementation, because it is a protocol. X11 is the same way; ICCCM and EWMH are protocols that use X11 as an IPC mechanism. There is nothing stopping you from writing a multi-process compositor swarm with all the traditional pieces broken out using an IPC channel of your choice.
The fact is, given that a compositor must necessarily handle display and input, it is much more convenient (and secure) to centralize display and input dispatch in a single process. This is also how X11 works, except it dispatches all display and output to any process that asks nicely.
There certainly are sandboxing efforts on Linux but most of them have incredibly permissive rulesets to the point where nearly every program has read/write access to everything in $HOME.
That's a temporary measure. Get the sandboxing layer in with whatever permissions are required. And then move to tightening everything / replacing permission lists with permission requests like on iOS/Android.
There are a lot of pieces that have to fall in to place and any one on its own is not useful but they will eventually build up something secure.
Maybe I'm old, but it's just stunning to me how many pro Wayland people seem to strongly miss this general point.
Whatever good things Wayland's been up to, it's been historically dismissive if not outright hostile to backward compatibility and integration, and that's not acceptable. I keep hearing, well it's what the old X people want, and I don't care.
Similarly, don't come with the goofy "It's open source so you don't have the right to criticize." False false false. That wrongly implies it's a bunch of plucky happy-go-lucky volunteers doing this out of the kindness of their hearts. Nope. It's companies with agendas and they need to do better.
I can't say whether Wayland was specifically designed for GNOME or not. There seems to be evidence that it was also designed for the use cases of mobile devices and embedded applications like in-car entertainment systems.
(Let's leave aside the fact that Nokia designed a beautiful mobile interface built on X, in-plane entertainment systems have been running on Linux and X for over a decade, and X servers were historically implemented on 286 hardware for use as dedicated X terminals.)
What I can say is Wayland was developed and promoted with a GNOME developer mentality, which is a combination of:
* We've built a solution for what we have determined to be the common use case. Why should we care about your obscure, niche use case that absolutely nobody (that matters) uses?
With a heaping side of "it's from Red Hat, so it's the standard" and "it's open source so you don't have the right to criticize". Basically, what happens when young, eager developers are given the opportunity to implement and potentially standardize core desktop features (and thus build what they think is "a better Windows" or "a better Mac") but don't have the advantage of experience of previous software designs in the Unix/Linux workstation space and their benefits and drawbacks.
If people keep staying on X11, I suspect that the next phase will be "refusal to adopt Wayland is a strong indicator of racism/misogyny/homophobia/transphobia".
The core protocol is minimal because it considers not only PCs and laptops as a target, but also smartphones and tablets (where supporting xdg-shell is usually not desired because it breaks the UI paradigm), IoT and embedded usecases. In particular, IVI (in-vehicle infotainment) was a hot area that every hardware vendor was trying to get into at the time (around 2010), including companies like Intel that contributed to the Wayland spec.
Source: I was active in KDE development around the time when the Wayland core protocol was defined, and followed the discussions on the side lines.
Then there should have been a set of core protocols, so for example, something like core-desktop. Going for the bare minimum just to be super flexible and support desktops, phones, tablets, fridges and graphics cards with RGB lighting is the typical overthinking that hurts everyone and slows adoption. Wayland was conceived in 2008, and has had paid full time devs working on it. For that, the current state is pretty pathetic.
The xdg-shell protocol is a sort of core desktop protocol. It has an opinion about everyone's favorite Wayland topic (server-side decorations), and if you have a different opinion, you need to use the xdg-decoration-unstable-v1 (as it still seems to be called) protocol. Fortunately, it seems like the Wayland desktop scene is converging on that one now.
There are still some missing pieces, but the situation isn't disastrous anymore.
Pipewire is compatible with the Pulseaudio protocol, so Pulseaudio clients work on Pipewire. In contrast, Wayland is a protocol. A Wayland-compatible compositor that also speaks something else would still be a Wayland compositor.
I think the fact that Wayland isn’t a program is a big part of the problem. The dominant Wayland compositor in use is gnome-shell, and it’s obviously extremely GNOME centric. With X11, the interaction between clients and gnome-shell was intermediated by Xorg, so, if gnome-shell wanted to support Xorg (which it did), it had to support relevant features of Xorg. Xorg supported server side decorations, so gnome-shell did too.
But gnome-shell as a Wayland compositor supports whatever set of features it likes, and clients that require additional features don’t work on GNOME, so they largely don’t get written, so there is little pressure on gnome-shell to support them. A Wayland competitor won’t help here. An alternate Wayland server that sits in front of gnome-shell might, but it would be a mess.
Ultimately the best solution would be to break GNOME’s mindshare dominance. If enough users demanded something better/different, then IT departments and sales would notice, and GNOME would need
to either catch up or get left behind.
I’ve never had any real issues with wayland. It supports high DPI, fractional scaling, and high refresh rates very well — couldn’t say the same about X!
All of my struggles with wayland were adoption. It’s a struggle to force every older electron app to use wayland via CLI flags because the authors, even big ones, haven’t bothered.
I guess there are some unsupported things — like screen control. (If you wanted to control another person’s screen over a video call, it’s unsupported in wayland.) But it also actually sandboxes a lot of things which should be (like screen control!)
Adoption would be a problem with a different system as well, unless it was fully compatible with X. Which defeats at least part of the problem wayland solves.
I can't really tell for sure, but it seems the author makes the confusion that the authors of the Wayland protocol are GNOME developers. That, of course, is not true.
Wayland has it's origins in members of the X11 developer team, and AFAIR Kristian Høgsberg is the sole author of the original protocol spec.
At present the protocols and extensions are discussed and merged by a group that, as far as I know, includes GNOME developers, but they are not in majority nor can they do as they wish overruling the other stake holders (wlroots, KDE, etc).
Now, to the main premise of the article: plenty of applications (at present) make use of client decorations vs. compositor decorations, and it can be easily experienced with Chrom[e|ium] in sway, by enabling/disabling "Use system title bar and borders".
I think the whole piece is a misinformed piece that builds on top of a faulty premise, and the author didn't bother to do minimal research before putting words to paper. I would expect more judgement on the part of the HN crowd instead of accepting it on the idea that conforms their biases towards Wayland being somehow "bad".
It’s beyond misinformation now. These same incorrect statements get made again and again. It’s an actively malicious campaign from a group of trolls spreading fud.
Red Hat has been slowly becoming more like Microsoft used to be.
I have to use RHEL at work and since RHEL 8 the desktop experience is just painful:
GNOME 3 is the only desktop offered. Our IT team hates third-party repos, so EPEL and any chance at an alternative are right out.
I tried to use GNOME 3, but I really do not understand what the designers were thinking and how they intend for it to work.
How do I minimize a window that I do not want in the foreground? There are no buttons that seem to do this without using tweaks or extensions.
When using two or more monitors, why does only one monitor switch to a different virtual desktop while the other does not?
Trying to use GNOME 3 is frustrating and I would rather use pratically anything else (Windows, MacOS, KDE, CDE, Xfce, WindowMaker, Blackbox, Fluxbox, etc.) because at least they would follow some of the last 40 years of desktop environment conventions that GNOME 3 seems to have completely discarded.
Red Hat are like Microsoft because their enterprise distro offers only one desktop? Alright. I guess macOS is Microsoft as well under that definition.
Without discussing the merits of GNOME vs others, is your company prepared to pay twice for the RHEL license if they provide official support for both GNOME and KDE? Supporting more environments doesn't come for free.
>> Red Hat are like Microsoft because their enterprise distro offers only one desktop? Alright. I guess macOS is Microsoft as well under that definition.
No, Red Hat is like Microsoft because they made the same mistakes with GNOME 3 that Microsoft made with Windows 8--they gave designers free reign to do whatever they wanted and did not listen to user feedback.
>> Without discussing the merits of GNOME vs others, is your company prepared to pay twice for the RHEL license if they provide official support for both GNOME and KDE? Supporting more environments doesn't come for free.
Probably not, but given the choice I would select KDE over GNOME 3 simply because it offers a more customizable user experience that does not require "tweaks" and "extensions" to get the desktop setup that some users want.
What's next? Removing Emacs and Vim and only offering GNOME Text Editor? Supporting more text editors doesn't come for free.
Make sure an allocation of your frustration is pointed at this.
Gnome tweaks should be a default package. Is it not in an accessible repo for RHEL?
I just switched from Pop OS to Fedora 36 on my laptop and am getting the hang of pure GNOME 3 quickly. Other than Guale not working for some reason, Vivaldi and terminal and python run just fine. Hotkeys are abundant.
>> Make sure an allocation of your frustration is pointed at this.
Agreed, but I have little control over IT policies. Third-party repos are strictly prohibited unless there is a compelling reason and they are blessed by IT.
>> Gnome tweaks should be a default package. Is it not in an accessible repo for RHEL?
Tweaks help, but it is still terrible compared to the customizations that GNOME 2 offered "in the box".
>> Don't windows in GNOME have a minimize button by default? And then you use the overview to bring the window back if you want? Am I missing something?
No. By default there are no maximize and minimize buttons. They were explicitly removed:
I stopped actively using GNOME long before 3.x was an idea. Xfce has remained consistent, performant, and beautiful. GNOME has become a victim of mismanagement, trends, and monoculture.
Remember that Ubuntu spurned GNOME for a long time because they had their own monoculture issues.
I think this is a good thing. The more tightly coupled with GNOME Wayland becomes, the more useless it will be for everybody else. X11 will remain relevant and useful for everybody who thinks the GNOME environment is crap.
For some people X is just better at the moment. I am one of these people and, honestly, Wayland has nothing to offer me but issues here and there.
So I decided to just stick with X and not bother with Wayland until at least 2023-2024, and of course I would like X to still work in the meantime and it probably will.
Are those people aware that using x11 effectively means they could just not bother with security and do everything as root, because x11 design makes it trivially easy to escalate?
You can only invoke the security argument if the software is easy to use and works flawlessly. That may not be true for everyone but I do expect the majority should switch.
I thought Xenocara was about running xserver without root, but otherwise a normal x11? Because I’m talking about something completely different: the fact that, due to x11 design, every app can do anything to any other app, which means it can just wait for you to run sudo(8) and then inject whatever keycodes into the terminal.
Ah, that. Wayland by itself doesn't prevent nothing from keylogging, you can only be sure that (in GNOME or KDE cinematic universe) keylogging by listening on X-things or the socket can be achieved only tampering with LD_PRELOAD or the kernel and not by design (unless one or some apps would redo that Xorg POF).
When Wayland was born you couldn't do anything to prevent that, now we have like 6 sandboxing/light-virtualization options for Linux, so I suspect that by containerizing applications in Xorg you could prevent them from keylogging easily. That too right now is mostly crappy and fragmented in Linux with the AppImage Snap and flatpak circus.
Of course Wayland can’t secure your kernel or rtld, but I’m pretty sure that one of its advantages is that it can at least not send a random app the password you’re typing in.
And no, I don’t think you can really do that with x11. There was Trusted X11 long time ago, but I don’t think it was practically useful - as in, maintainable and sustainable.
As far as I understand sandboxing in Linux is “70% there” - it will get there eventually, but for now the 30% hole makes it not practically useful. It’s not bad at pretending it’s doing something though, and for (many? most?) paying customers that’s enough.
X11 with a bare wm has had less jank for me than GNOME, Wayland, and all the fixings. Wayland is an effort pushed by those who want to make their desktop "more digital"[0]. Which is fine, but when what you have works and is rock solid, you tend to want to keep it around.
This is the third time I've read it, and I must be constipated because I still don't give a shit. X11 with Openbox works fine for me. Likewise for FVWM and Window Maker. Maybe you should learn to use a plain old window mangler; if you want Windows you know where to find it.
Nor will I give a shit about Wayland until OpenBSD forks it, audits it to within an inch of its miserable life, and incorporates it into its base distribution to replace Xenocara.
No one wants to.
Wayland is the successor to X11, X devs now work on Wayland.
Gnome has first party support for Wayland because the same devs also work on Gnome and Red hat.
The inconvenient truth is they are working towards a cohesive desktop experience, even supporting mobile. X11 will still be here, but you can't blame the devs for wanting to move on.
Operating systems should be designed for all humans, not just programmers. Gnome seems to be the only DE that cares about accessibility. All of your settings and extensions mean nothing to someone who needs all of their apps to work with a screen reader.
This article and these comments suck. No one wants to contribute code, just opinions. Reminds me of the systemd FUD.
You can fork, hack, make your case with Wayland, maybe it gets merged, maybe you just maintain your own fork. These criticisms by people who aren't going to contribute anyway are getting tired.
I'm seeing Thomas Dickey (xterm mantainer) and some other new people, along with Coopersmith who is a old-timer in Xorg development, slowly taking over Xorg.
I find myopic that GNOME and KDE are working towards a cohesive user computing experience starting from "one-size-fits-all widgets" and data as an afterthought. Red Hat freedesktopers aren't designing anything for all humans, they always tire themselves on some all-encompassing project then adapted for two niche use-cases that generate revenue.
But I don't care no more, I'm using Xorg and Xenocara, runit, will probably going to hack on Arcan someday.
And yet, for all the gnashing of teeth, those people never seem to appear.
Fixing X11 is basically shaving an infinite number of yaks. Wayland is the X11 developers trying to bound the problem to a finite number of yaks. They can only do this by punting everything they possibly can out of the system.
To be perfectly honest, the Wayland developers don't have an option.
Screenshots are a continual complaint--but it is by no means settled as to what entity and mechanism controls the security and permissions behind that and how. Punting window decorations to the clients is annoying--but any other choice likely means that you need a full text rendering system in your window manager. And if you want an "interesting" task, go help both the X11 and Wayland devlopers deal with all the race conditions and problems around the "simple" task of integrating with Vulkan and getting/presenting a surface and handling the swapchains (extension VK_KHR_surface, VK_KHR_swapchain, VK_KHR_xlib_surface, VK_KHR_wayland_surface)--lots of bugs exist and have since 2015. Try tackling the sequence of events around "resize"--you're in for an eye-opening experience.
Yet, even after the Wayland guys atomized this stuff, nobody in the open source software world is picking up the work. Maybe the DeadRat guys are rejecting submissions, but I suspect it's more that people simply aren't willing to grind through this stuff. It's a bunch of detailed, system-level programming with LOTS of gotchas all over the place.
Dunno. Maybe they should say that they are rewriting it in Rust. That might actually attract some people willing to put in work.
If anything, Wayland has gotten XOrg and other DEs to fix a lot of X11's shortcomings for general use. Gone are the days of having to edit xorg.conf and pray it doesn't brick your monitor.
Wayland and "an Xorg user experience that's not a disaster" came from roughly the same developers because of the same needs. Generally lots of stuff was moved out of Xorg into places where it fits better, into the Linux kernel (modesetting!), into Mesa, into application frameworks. This development is what made Wayland possible in the first place. By making large parts of Xorg obsolete, you enable a solution that trims out all the old garbage that nobody realistically needs anymore and hence nobody wants to maintain anymore.
Because the developers of window managers and desktop environments are precisely the people that benefit from foregoing backwards compatibility and getting rid of all the duct tape and zip ties that hold the modern X stack together. It is true that a duct-taped thing can work very well after sufficient iterations, but you absolutely don't want to be maintaining it.
But XWayland does nothing in the situation of a Wayland compositor not working for a user. It's just for X11 application compat, while the problems discussed here seem not that.
On my Thinkpad T60, Wayland is useless with and without GNOME. It just doesn't work, and nobody on the project gives a shit. So, instead of shelling out for a new computer when the one I have works fine, I stick with X11.
Everytime I ask for help with broken Wayland (which it is OOB across hardware and distros), I'm told it can only be me, because it works for some. Apparently Wayland is worth shilling over for some.
Forces far greater than you have decided that Wayland is the go-forward solution. Therefore, you will live in the pod, eat the bugs, and use the compositor because all the maintenance and advancement effort is behind Wayland.
Your comment is deflection and straw man. Why Wayland should support 15 years laptops? Why do you think it is reasonable to shitpost on an open source project because it refuses to bend over backwards for you?
I'm not asking for full-on 3D acceleration with vsync. Just use the fucking VESA framebuffer instead of making my laptop look like it snow crashed. People should not have to throw out otherwise working hardware because a bunch of nerds who weren't bullied enough in high school don't feel like putting in some effort.
Then use the old version of Linux that works with your hardware. Why other people should care about your ancient hardware. You can either fund work to provide support or write code yourself and see how easy it is.
I was using until recently Sandy Bridge platform, and It works fine. I am not expecting that it would be supported forever. There is a lot of performance and maintainability left on the table because of support for old devices. If anything, I wish for Linux world for more aggressive deprecation policy.
> People should not have to throw out otherwise working hardware because a bunch of nerds who weren't bullied enough in high school don't feel like putting in some effort.
You can just leave Linux community, nobody will miss you.
- the window manager - the hotkey daemon - the compositing effects - the windowing server - screen reading tools - screenshots - screen casting
magnifying glass tools global dictionary tools etc etc etc everything. Wayland's design makes it impossible to write a portable hotkey daemon for instance. Supposedly for "security reasons.” Wayland is a GNOME dev's dream, it kills the ability of people to control their own system. If you're actually excited for Wayland you either thoroughly misunderstand what it brings and just like it because it's new or you're a GNOME-lover who hates customization.
And don’t get me started on the security argument. If someone has arbitrary code execution on your machine, you’re already toast. I’ve yet to see an example of malware that can use xlib to read keyboard inputs on X (the supposed vulnerability Wayland was made to stop) but can’t just write some LD_PRELOAD hook to .profile or bashrc to make the compositor keylog on Wayland too. Is there a real world example where this supposedly great isolation that is easily circumventable actually prevented any security issue?
None of this is to say that X.org isn’t the accumulation of 30 years of cruft and technical debt but I don’t think Wayland is the right alternative.