You haven't even mentioned which wayland compositor you are using.
Which is one of the biggest problems with Wayland - there isn't just one Wayland but Gnome Wayland and KDE Wayland and wlroots-based Wayland and Gamescope Wayland. What functionality is available and working and using which API varies between all of these. This includes really basic things like window decorations.
This is different from X where the core functionality is common because everyone usees X.org. If all the Wayland compositors agreed on how thing should work then multiple implementations would be much less of a problem. But they don't or at lest take ages until all but one of the NIH protocol extensions get abandoned. Some of this protocol extension zoo is hidden by applications and toolkits implementing multiple variants but even if you no longer see it as an end user this is still a cost because time spent on dealing with Gnome or KDE bs is time not spent on more useful things.
Yes this. If you use gnome or kde you probably will have no issue with the transition to Wayland. If you use any other window manager then the transition will be painful because there's a bunch of things that don't simply map over from x WMs to Wayland compositors.
I just did this switch and found it incredibly frustrating. Simple things like, "I would like to be able to log out and return to my greeter" don't just work like they do in x.org, and it is dependent on which compositor you use.
That is not what I said, please don't misquote me. I said:
> [things] don't _just_ work like they do in x.org
Maybe it wasn't clear in my post above so let me clarify. A lot of thing "just work" in x.org and don't in wayland compositors. That is the complaint. That things which were easy are now hard.
No I don't. X11 works perfectly well for me. Wayland doesn't. Until I can migrate without issue, I'll be sticking with what works. If it gets to a point where Linux becomes unusable for me, I'll just move to an OS that works. Linux isn't the only game in town. Boo hoo.
No, they didn't explicitly say they tried X11 "on the same OS". You can assume that, but it's not explicitly stated in the context. It might as well be experiences on different OSs/instances. OP needs to clarify.
And from my experience, there's distros that work better with X11 which is why they ship with it out of the box instead of Wayland(like Mint, EndeavourOS and Kubuntu), and ones that work better on Wayland out of the box, like Ubuntu and Fedora.
> because time spent on dealing with Gnome or KDE bs is time not spent on more useful things.
The entire reason there's time spent on dealing with Gnome vs KDE vs other bs is that everyone wants to build and customize their own desktop. But hey, it's OSS, freedom of choice and you're free to do it but I doubt window decorations will add very much to the overhead of all those different desktops.
It's the same issue with the "W3C is just a standard." Rather than making the lives of web developers and users easier by just basing every web browser on Chromium we have to deal with caniuse, polyfills, nonstandard extensions. Basic features like tab sharing are implemented by Google's NIH cast protocol. There's no such thing as a website anymore there's Chrome apps, Firefox apps, and Safari apps. More time is spent wrangling webpack then doing actual web development.
The tearing situation has also recently improved [1,2,3] in X.org, including your cited use case of multiple, rotated monitors, and even if you are not using a compositor, although these improvements are only present in the latest master branch and aren't in any release and thus not shipped by most Linux distributions. I'm sure that the argument could be made about how Wayland still solves the tearing problem more optimally, and I think you should stick with Wayland if you are happy with it, but the tearing situation has improved dramatically on the X side of things since Wayland as well.
On the fractional scaling side, precisely Wayland's advantage is that it works much better there than in Xorg.
Regarding the rest, I run an Nvidia laptop under Wayland since early 2022 and it's been working flawlessly. It's true that I'm using one of the cleanest, most forward thinking distros out there: Fedora. On Ubuntu it had way more issues than on Fedora, though.
Ubuntu and Nvidia are difficult. We have a Linux work station and attempt to get an Nvidia card working (drivers anyway) failed. Its was confusing and even those with more skill/experience couldn't make it work. PopOS (which is a fork of Ubuntu) with Nvidia ended up working for us. Though I'm not sure if its X or Wayland.
I guess that’s a good way to think of Federora, forward looking. I always liked it for other reasons, but they do have just the right amount of forward focus. Ubuntu has a very different community to try and satisfy, so has to move slower.
My past experiences with SuSE, Fedora, and Red Hat, RPM distributions, eventually experienced a corrupt repository that in each case took hours to fix. That's when I settled on Ubuntu in 2006 and haven't looked back.
I heard bad things about RPM before, but that was long ago. To be honest, I think by 2006 most issues were already over, and YUM was mostly on par with APT. Don't know what might happen in your specific case.
The key point your missing is that you're not using wayland. You're using a wayland. Each wayland is very different from the others in terms of features because they aren't implemented internally as a wayland standard, each wayland picks and choses between various external libs to try to reach normal desktop feature parity for things like keyboard/mouse/input device support (ie, the libei wars: some waylands use it, some hate it and never will).
There's no such thing as "wayland". There are only various different waylands. A person can have an experience with X11, there's standard reference features all X have. But your experience with a single wayland doesn't really give you knowledge of how waylands work (or don't work).
I literally cannot get Wayland working. Everything is broken. It's slow, the fractional scaling doesn't work, full screening apps like vlc or games turn off my monitors, the distro installer crashes, playing a youtube video makes my laptop heat up like crazy, one time a display change made my laptop's screen flicker so hard that it persisted after I restored the settings, another time it turned my monitor's bright red and white respectively.
This is on fresh installs of Ubuntu 22.04 and 23.10.
X11 with XFCE and i3 with picom works perfectly. It's blazing fast, has no tearing, never crashes, uses next to no resources, has no bugs and runs everything. I even use ddccontrol to change my external monitor's brightness.
I noticed all sorts of horrible breakage in Ubuntu (including LTS updates) over the last 3-5 years (I gave up on it in the 20.* days for anything except VMs / docker containers) Examples included DNS taking 5 seconds to resolve each host, the syslog fiasco, systemd flat out not working, etc, etc.
Maybe that's what they're referring to?
(At this point, I'm looking for anything that's stable and still uses a normal init + x11, FWIW. I wouldn't consider Fedora, since it's owned by IBM, and Red Hat's new business model under them is "systematically violate the GPL and see if we can get away from it".)
Outside of using Wayland, do you do much 3D rendering?
The symptoms you describe almost sound like a dying 3D graphics card (or 3D graphics card with misconfigured drivers). I wonder if Wayland is requiring the 3D layer to do its compositing and other window engines don't?
Wayland compositors will happily use gpu 3d engine, if it is available. Otherwise, they will do their job with Mesa's software rendering.
They also accept dma-buf handles from clients, so if other software on the system does use gpu, the compositor has somehow to do its composition, and zero-copy if possible.
Really? I can’t help but notice that nobody is describing X as if it hasn’t improved since XFree86 in the 90s so perhaps it is possible for technical professionals to update their understanding?
You seem to be seeing a confrontational message where I didn't mean one. Yes I'm sure you could find some old posts complaining about X that would illustrate the same phenomenon. My point is pretty much exactly that. Fast forward the next 5-10 years and we might all be on Wayland but they blew their first impression and that's delaying adoption.
It sounded like a but of a misdirected excuse: if someone is still complaining about Wayland now based on an initial experience half a decade ago, wouldn’t the first step be getting up to speed with the current state? When I read that I was reminded of how many Linux users had issues with things like mode lines back in the day, and that was a non-issue only a few years later.
The problem is 20 years ago you had to use XFree86 if you wanted graphical output in Linux, there was no other choice, so you had to put up with it no matter the craziness.
Now X.org works fine for the majority of users, so for them (/raises hand) it is very hard to see the value proposition of switching to Wayland, especially if prior attempts were less than successful.
The fact that X11 development has stalled might be a plus for those that just want a stable system, are used to the limitations and don't need new features.
We will migrate eventually, likely at next distro upgrade, but there is no hurry.
You also didn't have much choice; XFree86 is what everyone used and it more or less the only realistic option.
Also doesn't help some people have been rather aggressively banging the Wayland drum for a long time now in a way that quite a few people find rather unpleasant. About half a year ago someone told me I "need" to switch to Wayland because programs will drop X11 support "any time now", all with a sense of glee. A quick search on https://hn.algolia.com with "Wayland by:username" showed they have been telling people that for about 7 or 8 years. Clearly that hasn't happened, so... And when they started banging this Wayland drum so aggressively there really WERE actual problems. Textbook "toxic fanboy" stuff. At some point people start filtering this sort of stuff out.
The first time I really looked in to Wayland was when "I'm tired of this anti-Wayland horseshit" article took off, which starts by comparing "anti-Wayland activism" (something which doesn't really exist as an organised force) with "anti-vaxxers, flat earthers, 9/11 truthers", dismisses anything that disagrees as "lies", and is generally just a stupid rant with a number of fairly obvious factual inaccuracies. To say this rather put me off from Wayland would be an understatement.
I'm not holding you responsible for any of that of course, nor am I saying this is representative of people interested in Wayland as a whole, but at the same time ... I do think Wayland has burned a lot of goodwill with stuff like that, and that people voted that stupid insulting conspiratorial rant to the frontpage did no one any favours – it's not just a single person who wrote that article, it's the hundreds of people who voted on it, and some of whom defended it.
> XFree86 is what everyone used and it more or less the only realistic option.
Not really; in the 90s, there were many X servers, each implementing a different set of extensions. Not just for other Unices, even for Linux, you could purchase a proprietary ones.
For XFree86, it was a monolith, that you had to compile for a specific chipset. Distributions shipped with many binaries, each intended for a specific graphic card and the installer symlinked the right one for you. It was only later, that XFree86 became modular and everyone converged on it.
That's what I mean with "more or less", and they were all more or less compatible and was mostly a "Vim vs. Emacs" type situation, not a "plz rewrite your entire stack"-type situation. That's really the key difference here.
> You only get one chance to make a good first impression
There plenty of chances to make good non-first impressions though.
I used to check periodically whether Wayland works better than X for me, until it does one day, and I switched.
Not everybody hold on to the shadow of a bad first impression. It’s unfair when subject to another human being, and irrational when subject to a product.
I wonder if you asked people their feelings about 1) Wayland, and 2) systemd, whether or not sentiment would be highly correlated. My first impression of both was when I had a problem.
I just setup wayland a couple months ago, so everything should be pretty recent, and couldn't ever get screen sharing to work. It's discord electron, which I think is having some weird interaction with xwayland, but I only researched it for a bit before deciding it wasn't worth it.
Games though can be a nightmare, a recent nvidia driver seems to have created stuttering across all games using X to varying degrees. (downgrading the driver fixes the issue)
> Games though can be a nightmare, a recent nvidia driver seems to have created stuttering across all games using X to varying degrees. (downgrading the driver fixes the issue)
On ubuntu (Kubuntu really), and as a gamer, I've seen no issues with nVidia on X, both native Linux and Steam Proton games rock on.
I think the place you get into trouble is when you try and DIY the config. I'm using Fedora and everything works perfectly out of the box. But when I was using arch and was trying out Sway (i3 + wayland) I was constantly running into issues.
Odd, I use Arch (well, EndeavourOS) with Sway and have experienced no problems. Quite on the contrary, my setup with a high-DPI laptop + external monitors is far nicer with Wayland than with X.
What you gain is that programs render at the native resolution of both displays. In terms of appearance, it looks noticeably clearer, since no downsampling or upsampling necessary. But the nicest thing is that it just works — I don’t need to configure any settings to prevent windows from being displayed unreadably small or gigantically large.
Screen tearing is the big pain of X11 in my experience. Most things work fine, but watching videos or playing games is a terrible experience when dealing with constant screen tears.
I tried a bunch of different configs and was able to minimize them significantly, but they were still there.
Out of curiosity, what distro do you run. I'm running Wayland pretty seamlessly right now on Ubuntu: it's not a distro I would normally choose but I cycled through 3 others before "giving in" & going to Canonical. Hardware aside, there's also a lot to be said for sticking to the mainstream software-wise; though it's certainly an oddity for me to be so limited with software-choice in the Linux world.
You probably need an Nvidia graphics card. That was the source of all my problems when I first tried it. I dumped that shit and been using Intel graphics and Wayland (sway) happily since 2019.
Any ATI/AMD graphics card too old to use amdgpu has the same problem. I have two machines using the "radeon" driver and Wayland had so many issues on them as well.
Someone on HN pointed me at setting LIBGL_ALWAYS_SOFTWARE=true which makes it stable on my "radeon" driver GPUs at the cost of some performance (e.g. moving a window that is playing video causes the entire screen to freeze only while the window is moving). That should make it pretty stable with any KMS driver (though the nouveau module still crashes on me every 10 days of uptime or so; I've never been able to figure that one out).
I always point out that all of the issues I run into with Wayland on ATI/AMD GPUs also happen with hardware-compositing on X, but I can turn compositing on X off since it's optional, but, as the figures in TFA suggest, it's a core part of Wayland. I think one minor thing that has put so many people (or at least me) off of Wayland is how many issues are dismissed as "your GPU driver is broken." Well I can't write a GPU driver, and Xorg works better with a broken GPU driver than Wayland does.
My several years old laptop with an Intel P530 runs Wayland with zero issues, to the point where I can't tell you when I switched because it was zero drama. Maybe about a year ago? There was one feature in plasma that I needed to wait on before switching, but I don't even remember which one it was.
Source? Regardless, even if VLC or a version of VLC is broken in some configuration, it's not universally broken on wayland.
I have been using it on Wayland for multiple years (some of that might be through XWayland, I don't think all of it, but I'm not sure).
I feel like the debate between Wayland and X always bring more a general discussion about technology refactoring and modularity.
To me be, the big question is not why freedesktop.org or redhat is doing all of this, they're a company and they have their needs.
It is why distro maintainers have chosen to adopt those technologies(systemd,Wayland, others?), not that those options are especially bad but to me,but they really look like a clear bifurcation from the modularity and customization we used to see on the distro world.
I remember the mid 2000 and early 2010, when computing was still cultivating this cool image from the animations of Mac os Leopard and the aero style of Vista and the leader above all in the form compiz crowning Linux from far.
In the talks around Wayland vs X, the maneer Wayland proponent(not only its developer and also any linux user) dismisses critics of missing feature because 15 years later they're still not standardized or lack of composabilty between windowing and compositing is a stark contrast with the way we used to talk about free and open source software at the turn of the millennium.
We used to defend customizability and a certain form of freedom.
Sure X11 lack security and should be replaced by something that works better.
The Wayland shortcoming are defended in the name of security is some kind PR speak I wouldn't think I'd see in the linux world years ago.
It comes as particularly bitter as other closed platform from wich we used to hear a lot corporate speak still allow apps to do more things with their own windows that Wayland does.
The fact that the same organization hosts flatpack but has not vision of how to use the capability model for Wayland really poses questions on the vision.
All in all, I wonder if things would have went more smoothly and in greater general agreement if those 15 years+ were spend make Linux work like plan 9.
Wayland is still customizable, and x11 isn't going away. If you want to trade in security and maintenance for features and capabilities, nobody will try to stop you. In that sense, distributions still don't hold much power over the user besides what they present as default.
> The fact that the same organization hosts flatpack but has not vision of how to use the capability model for Wayland really poses questions on the vision.
I disagree, and I'm a staunch GNOME skeptic myself. Flatpak and Wayland were both built as extensible systems from the start, and GNOME's implementation of both technologies is just one interpretation of the protocol. KDE is a good mirror example; their Wayland implementation exposes many features completely unavailable on x11, and their Flatpak permissions are integrated right in the Settings app.
Personally I don't like GNOME's approach to the desktop anymore, and I refuse to defend most of their more opinionated decisions. Those choices have a minimal impact on desktop Linux outside of GNOME though, and it more feels like Red Hat is displacing the amount of work put into keeping legacy systems alive.
Yes, technically nothing prevents someone to make a customizable Wayland compositor.
You’re taking about KDE and I agree that it is certainly one of the most customizable Wayland desktops we have.
What I deplore is that those customization have not made their way into at least an extension of Wayland.
And as you say, hopefully I can still use X11 when needed but I wish the more modern option would carry everything I need.
Wayland feels more customizable and modular to me, in that it is a set of protocols and optional extensions with multiple implementations instead of one server (Xorg) to rule them all. This feels much more in the Linuxy/FOSSy mindset to me.
In fact, many, many people complain about the multitude of wayland implementations as fracturing and a division of work.
I'm not saying that I don't see the benefits of all building on a single server, but I can't say a bazaar-style development of multiple implementations and protocol extensions feels at all corporate.
Also funny that you say it's about customizability, having a bunch of implementations of the wayland standard seems more customizable than having the one X server.
I suffer from the limitations of both X11 and Wayland. Some things work in one and not the other, it's a trade off. In Wayland I can use different scaling for each monitor (in exchange for a LOT of RAM). But in X11 I can use Barrier to share my mouse / keyboard with my other computer. So I use one when I have a second monitor and have to restart my session when I use a second computer :'(
It will be fixed on some Waylands with libei, but it will never be fixed on other waylands that find libei distasteful (like sway). And that's the waylands in a nutshell: many different things, never "wayland" always "waylands".
libei looks useful. But IDK why libei is necessary to run Barrier with Wayland?
For client systems, couldn't there just be a virtual /dev/input/XYZ that Barrier forwards events through
And for host systems, it looks like xev only logs input events when the window is focused.
Is xeyes still broken on Wayland, and how to fix it so that it would work with Barrier?
With Barrier, when the mouse cursor reaches a screen boundary, the keyboard and mouse input are then passed to a different X session on another box until the cursor again crosses a screen boundary rule.
> For client systems, couldn't there just be a virtual /dev/input/XYZ that Barrier forwards events through
You seem to be asking for kernel thing, not something Wayland. But let's assume you wanted a protocol on top of Wayland to do this:
Why can't arbitrary Wayland clients always see the mouse pointer, snoop on the keyboard, and inject keypresses? Because of security, by design.
Why is it taking a bunch of work to provide that capability in an access-controlled way? Because it's a bunch of work. For example, quoting libei: "However, the events are distinguishable inside the compositor to allow for fine-grained access control on which events may be emulated and when emulation is permitted."
Wayland won't work well on non-Linux systems, and this is intentional. So, for the foreseeable feature, it can't replace X because its developers don't care.
Ah yes, sway, the one of the waylands that refuses to add support for complex mouse/keyboard and alternate input devices. https://github.com/swaywm/wlroots/issues/2378 . You've been running a wayland, not wayland, because there is no "wayland": only many different waylands.
> You've been running a wayland, not wayland, because there is no "wayland": only many different waylands.
I am aware, that is why I specified which compositor I am running. The comment I replied to said (emphasis mine) "*Wayland* won't work well on non-Linux systems" which is clearly false. To put it into another context: only a subset of C programs run on windows, but it would be silly to claim C won't work on windows.
As for the bug report you linked, the response seems quite reasonable:
> We already have Wayland protocols for input emulation. I think libei should add support for those.
Since standardized protocols exist, why should every compositor have to integrate this library instead of the library integrating support for the standardized protocols?
What standardized protocol? Each wayland makes a different choice. That's the problem. And yeah, I guess I can't say this is a sway issue, their choice is reasonable enough. But it highlights how reasonable actions in a broken system like the waylands can cause problems. They're not doing anything "wrong" and neither are the waylands using libei (all the mouse/keyboard sharing programs target libei, maybe in the future some can target whatever sway comes up with). But it does lead to things not working across waylands. Whereas in X things do work no matter what X implementation you use.
That totally misses the point. How about running Wayland on systems that a non-negligible number of people use, like Macs? Or even an enormous number of people, like Windows?
They use RDP RAIL (RDP-for-a-single-window) on top of Weston, and then the resulting surfaces are managed by the DWM.
Which is actually an interesting approach; linux native compositors should "steal" that idea and implement it too. It could lead to RemoteApp-alike for Linux.
They do, yes. Nobody will prevent anyone trying to port Wayland compositors, either. If that's your itch, feel free to go for it.
But the Wayland compositor authors will steer their software to run effectively on Linux. If that means it is difficult to port to Windows or Mac (whether because they miss dma-buf, or demand something that the native platform won't provide to non-system process), so be it.
Since when did Windows or Macs ever have great window managers?
If you just ran a web browser directly on the hardware (or native window system in full screen mode) instead of bothering with non-great X11 or Wayland or Windows or Mac window systems, then you could write great window managers using open standards that ran identically across Linux, Mac, and Windows, plus mobile and VR devices too.
I doubt that. Most of the WMs available for Linux are way more capable than their standard counterparts. There's a rich diversity of UXs available on the platform. Hopefully their ideas won't die with them if they get left behind by Wayland.
> That fragmentation is one of the reasons why in the end you get an Electron app.
How so? I run Electron apps all the time. They behave like any other app.
> Most people don't want to spend hours tweaking Enlightenment themes, or keyboard shortcuts for tiled windows.
Most people don't want to run Linux. And I don't want to waste my free time experimenting with a critical desktop component.
BTW, remember those people who actually make Linux work for the rest of us? Many of them do want to do those things. It's how they got to be Linux contributors in the first place.
Indeed, because packing a browser with the application makes up for the missing pieces across all bazillion of desktop configurations, for everyone that isn't running either GNOME or KDE.
Oh do I remember, Red-Hat, Mandrake, IBM, Intel, Oracle, Google, Linaro,....
Maybe your knowledge is out of date? Afaict, most (if not all) of the differences between desktop environments have been fixed by XDG. I don't run Gnome or KDE and everything on my desktop works just fine.
It should probably be "Waylands vs. X" since each of the Waylands supports different features and libraries to try to achieve the same ends. For example, some of the waylands use an external library, libei, to be able to support features like being able to share mouse/keyboard between computers. But some waylands, like sway, are actively hostile to libei and have made a point of never supporting it. So some waylands can share mouse/keyboard and some can't.
Should it be possible to run games with Steam on Wayland with Nvidia drivers installed? Or is that some ways off while we wait for NVidia drivers to be updated?
I did give it a brief try but getting very low fps, which tells me it's probably running on CPU if I had to guess.
Secure remote in X11 is a bag on the side that requires work and integration. SSH has to explicitly transport it for you, carefully setting it up the right way. Even worse, SSH has to meddle with X11 internals to prevent your desktop session being trivially pwned by the remote.
Your prediction is probably right but it highlights what I still find to be a fundamental problem with Wayland. It's something that's very much user-facing, as it affects the behavior of desktop environments and several types of programs. It's also something that developers want because they don't want to write X applications or maintain Xorg itself.
The disconnect is developers want Wayland to replace X ASAP, while users want a smooth experience where nothing breaks due to it being Wayland, which is a high bar.
For me, Wayland remains one of the least favorite technologies I've dealt with. As a developer, I needed to port a custom Linux system to hardware that only has Wayland drivers and it was a giant pain. Wayland offers no advantage at all for that system but it broke a lot of functionality that relied on X in terms of window placement, etc. Took weeks of work to get a more complicated system that does 90% of what the previous one did, while still missing a few convenient features.
As a user, I try Wayland once in a while on one of my computers. It's improving - or more precisely, it's not Wayland itself but rather Wayland support of other software, like KDE. Earlier this year I finally worked under KDE/Wayland for a couple days with no issues, but then I again ran into some weirdness when using Unity so once again back to Xorg. What really makes Wayland hard to daily drive for me is that I have zero issues with Xorg. I don't use the things X can't do at all (fractional scaling is one I think?) so the bar for Wayland as a daily driver is admittedly a very high one, it needs to be completely free of issues because Xorg already does everything for me and Wayland's advantages are for the devs, not for me as a desktop user.
It also feels like it's improving slower than anything else has. Printing on Linux used to be a pain but now it works well. Wifi on Linux was hard to get working at some point but now it just works. Sensationally, gaming on Linux has become as easy as it is on Windows. Wayland protocols hit 1.0 in 2015 and now nine years later, it's approaching usability.
> As a developer, I needed to port a custom Linux system to hardware that only has Wayland drivers and it was a giant pain. Wayland offers no advantage at all for that system but it broke a lot of functionality that relied on X in terms of window placement, etc.
FWIW, I've had decent luck running cage ( https://www.hjdskes.nl/projects/cage/ ), then on that xwayland, and then just ignoring wayland and running X clients. The result does still have some slight quirks, but it mostly works fine.
That looks pretty similar to what I ended up with! In the end, I had Weston running a rootful fullscreen Xwayland as the only Wayland window, and then X clients within that. There were still some complications, since I also wanted to make use of some GStreamer overlays that could totally sidestep window management, and the result wasn't perfect but it worked fine.
Still, I can't help but be somewhat unhappy about how the forced use of Wayland resulted in a fair amount of work, the end result of which was running X clients anyway and trying to pretend Wayland isn't there.
My main issue with Wayland is how big of a missed opportunity it is. If you're going to introduce a massive breaking change like this to modernize the Linux desktop, the least you can do is make it an actually compelling design. Wayland was originally created to fix the parts of Xorg that made it difficult to use it for embedded devices (digital signage, car infotainment systems, etc), so the base protocol only defines enough functionality to make that use case possible. Anything more complex than that requires using a complicated patchwork of Wayland protocol extensions, some of which are specific to certain compositors and many of which duplicate the X11 protocol extensions they're intended to replace. I'd be surprised if Wayland isn't more complicated to use than X11 in a few years.
Additionally, Wayland is already showing its age. The example that first comes to mind is how events are handled. Device events are received from the kernel and placed in a 4KB buffer that clients are supposed to read from and process. If the buffer fills up without being processed (for example, if high CPU or I/O stress causes a program to get descheduled for a few seconds and the user moves his mouse over the window), the compositor will sever its connection with the program, causing it to crash. This wasn't a problem for Wayland's initial embedded use case, but if you're trying to use it on desktop with devices such as high-polling rate mice it makes it far more unstable than X11 unless you have enough system resources to guarantee that no program will ever have its event handler thread pause for any reason. See here for more information: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159
I wish that the "X11 is showing its age and should be replaced, but Wayland isn't the right option" viewpoint was more mainstream.
I don't see how a client application blocking its main event handler isn't broken? If you're going to do lots of work or blocking I/O you spin it off to another thread so UI updates will be handled without pause.
On desktop we don't have realtime scheduling. Processes can get descheduled for arbitrary amounts of time. This issue happens with well-behaved applications that don't block at all on their main event handler threads when the system is under high CPU or I/O load.
Few things are ever truly needed. Those things don't include Wayland. That doesn't mean there are reasons for it but it does mean you can't just discard the downsides.
> Xorg was complicated
And Wayland will be complicated too by the time its mature. Especially when you include all the other compontents needed to provide the same functionality as X.org
> Xorg was [...] insecure
Under what threat model? Personally I have no interest in the zero-trust model needed for proprietary app stores and would rather not pay the cost.
> the maintainers moved on to Wayland
A lot of those maintainers are employed by Red Hat and other corporations. They moved because their employers have reasons to move to Wayland - those reasons don't neccessarily matter to all users.
> Nobody else wanted to take up the mantle of maintaining an X implementation.
Isn't it a bit early to pronounce that. X is mature software. It works just fine for most people. Why would you expect someone to immediately jump at messing with it?
> Under what threat model? Personally I have no interest in the zero-trust model needed for proprietary app stores and would rather not pay the cost.
Under the threat model of websites using browser exploits to grab other data on your system?
Or under the threat model of company policy or legislation not allowing you to handle confidential information on a system that can't offer even a basic guarantee of privacy.
> Under the threat model of websites using browser exploits to grab other data on your system?
Browsers already have multiple layers of sandboxes. You can always add another one to the browser if you are paranoid.
Personally I prefer not running untrusted javascript in the first place (where I can avoid it). An exploit that gains control of the browser is already a doomsday scenario if you are using the browser for internet banking, work or anything that matters. Being able to grab the input and output of other applications is a nothingburger in comparison.
> Or under the threat model of company policy or legislation not allowing you to handle confidential information on a system that can't offer even a basic guarantee of privacy.
Those are usually fine with running countless proprietary drivers and tools with root access. So in other words it's security threater.
There are more applications than a browser that can be exploited. Seems to me a secure GUI server is better than hardening thousands of applications.
I also prefer running trusted code, but that's not an option most of the time (for varying definitions of trust)
99% of the apps I use have no business with the contents of other apps I run so why allow it? Because X11 can't do anything about it is not a valid reason.
> Or under the threat model of company policy or legislation not allowing you to handle confidential information on a system that can't offer even a basic guarantee of privacy.
Last I'd checked, Windows had the same security issues as X, so it's unlikely to come up.
X was so insecure that wayland maintainers must now work tirelessly to roughly emulate these insecurities such as taking screenshots and sharing their desktop in their new protocol.
Don't get me wrong; I don't like X, but if I had it my way we'd all be using Haiku with a Linux or BSD kernel right now.
Those aren't inherently insecurities, but the way X implemented them was quite insecure. Wayland is now having to do the heavy lifting of defining a secure protocol to implement it and migrating the entire Linux GUI ecosystem to using the new mechanisms. Also, I can take screenshots just fine on Wayland via KWin. I can't pick arbitrary 3p apps just yet but KWin's screenshotter is fine. Not sure about screen recording as I haven't needed that. VNC-style applications don't work but if you do a search you come up with sunshine+moonlight which uses Nvidia's protocol + H264 streaming.
> Those aren't inherently insecurities, but the way X implemented them was quite insecure.
In what way does X.org add any security holes to the average Linux desktop where you have programs (from a trusted package repository) which can access everything your user account can?
You get that not every program invoked on a desktop necessarily comes by that way right? But that’s not actually the core problem. I trust you can do your own research as to what the security issues are, but as a starter here’s https://www.ctrl.blog/entry/clipboard-security.html
These are very old issues and are some of the major reasons Wayland was started in the first place. May want to read up on what the problems identified by the project were when it started considering all X maintainers migrated their time and energy to Wayland.
I am well aware of what programs with access to my computer can do. That's why I use programs from sources I trust.
I have zero interest in a low trust computing model because that comes with a cost to usability and performance, especially for power users but not also for others.
I also get that most commercial software developers these days should be treated as adversaries because they will break any trust you place in them. The correct response to that should be to not use their software or to create and enforce laws to get them to behave. This is really no different to anti-social behavior outside cyberspace - we have laws and police to enforce them precisely so that we can walk the streets alone without fear and leave our homes unattended. The degree of that safety varies greatly around the world and I much prefer living in places where I don't have to have bars in front of my windows. The same applies to computers.
Eg, this completely excludes Steam. Laws aren't a good way to deal with the issue because they don't prevent damage. Try and sue some guy living in Russia.
From my understanding, the biggest problem with Nvidia cards atm is the lack of explicit sync support in Wayland, which is something that is actively being worked on by both Nvidia and others.
That said, I've been using Nvidia+Wayland+KDE on my workstation for over a year now and while there are problems, it's certainly useable.
Isn't only the transport layer of X insecure? That could be swapped out with another layer. With Wayland you have to use VNC which is fine for local networks, but not for remote ones.
My understanding is that any app which has access to X (so any windowed app) had full access to all other apps which have access. So, any app with a window can read the input from any other app on the same system, e.g. your sudo password. Or, take a screenshot of your bank info in Firefox.
The thing is a 'day 1' feature everyone hacks back in is clipboard sharing and screen share, each of which remove a decent chunk of these protections. Each essentially grants access to another apps data.
Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do.
> Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do.
No, the attack angle is either a untrusted app running in a sandbox (fatpak, snap or crosvm or qemu with wayland passtrough[1]) with only a connection to the compositor or a trusted app running in a sandbox getting exploited, any apps handling foreign data is suspect here (Web browser, mail client, pdf, office suite, etc.).
Everybody who uses web video conferencing will give their web-browser permission to record the screen. This already takes a huge chunk out of the security advantages. The advantage is not zero, but it doesn't seem to be as big of a win as one might want.
> but it doesn't seem to be as big of a win as one might want.
That's a huge win. Firefox is a mainstream product with a ton of attention. And I get it from upstream repositories, it's not something I'm compiling myself.
If I can get away with giving 2-3 apps total on my computer screen recording permissions (OBS, Firefox, maybe a screenshot tool or an accessibility client), that is a massive reduction in attack surface, that would be a very large security win.
It would be great if the primary attack vector for recording my screen was an application with decades of sandboxing efforts going into preventing untrusted code from doing things like recording my screen without my knowledge.
Great! Firefox is also the app on my computer that does by-far the best job sandboxing untrusted code. It's good for us to be running most of our untrusted code in that environment, and even better for us to be blocking untrusted operations outside of that environment.
I genuinely don't understand the issue, it's a big security win if I can close off permissions on my system and have them open just for the apps that have good sandboxing around their untrusted code. Bonus points if the app in question allows per-domain screen recording permissions, which Firefox does.
I would go so far as to say that (one of) the reasons you run 99+% of your untrusted application code in Firefox is probably because Firefox is one of the very few places on your computer where it's safe to run that code. So it's a big win if we can start pulling some of those same sandboxing ideas into the native world; maybe that makes it easier to use more native apps for some tasks. It's a big win if I can treat apps on my computer the same way that I treat a random website.
Also keep in mind that "untrusted" is not a binary state. I pretty much only run apps on my computer that I "trust", but do they need to be able to record my screen? No, and I love the possibility of not needing to worry quite as much about what happens if they get compromised.
----
There's a somewhat strange notion here that because people do everything in the browser per-app privileges don't matter. But in fact, the reason the browser's security model works and the desktop's doesn't is because the browser has per-domain privileges and permissions, and it's not that per-app permissions don't matter, it's that they do matter and the lack of them is why we centralize untrusted code into one of the few apps on our computers that has per-"app" permissions. Browser permissions work because they are granular, you can grant Zoom access to record your desktop without granting access to Facebook.
So maybe if the desktop copies that, maybe far in the future you won't need to run everything in your web browser just to feel secure. But as it stands with X11 I feel a lot more comfortable using a browser to record my screen specifically because it has privileges and permissions around that are segmented per-domain/"app". The lack of sensible security controls on the desktop is a contributing factor to why people don't use the desktop, and being able to lock that in and restrict the scope of where screen recording can happen does make me feel a lot more secure about my desktop.
> No, the attack angle is either a untrusted app running in a sandbox (f[l]atpak, snap or crosvm or qemu with wayland passtrough[1]) with only a connection to the compositor or a trusted app running in a sandbox getting exploited
Agreed. This debate is particularly frustrating because X11 vulnerabilities get brought up as an excuse for ignoring other sandboxing efforts, and then Wayland gets dismissed because of vulnerabilities when not using other sandboxing methods. You can't win!
----
Even if I'm giving my web browser full access to my computer, there are apps I want to sandbox without running them in a full VM. And there are multiple parts to this puzzle to get better security and sandboxing, but those sandboxing efforts don't work if I can't secure the most basic parts of the visual desktop. If someone is demanding perfect sandboxing before we start looking at X11, they're going to be waiting a long time because there is a limit to how much progress we can make in this area while X11 stays dominant.
And okay, sure, we're setting up clipboard access for web browsers, but I can turn that off. And then I can take advantage of flatpak, snap, qemu, whatever and I can at least get closer to actual sandboxing controls, even for non-malicious apps. And I can do partial sandboxing, which is also a good thing -- the idea that everything needs to be either fully separated from each other or have full permissions is just not a good approach to security, sometimes we partially trust things.
----
Linux security is like we're in a boat with multiple holes that are taking in water, and whenever anybody tries to plug one of the holes, critics jump out and say, "what's the point, if someone can execute apps on your machine, there's plenty of other nasty things they could do." And so you move to the other hole and somebody says, "what's the point, attackers can just record your desktop." There are multiple holes on the ship, let's start patching them.
Getting better sandboxing controls into Linux is something that is going to take time and that means we're going to be patching holes while other holes exist that we haven't gotten around to yet. There is a limit to what tools like Bubblewrap can do for a graphical app if it's hooked up to X11. And yeah, I want clipboard controls for my web browser, but also I run more apps on my computer than just a web browser, and different apps have different problems. It's not even just about exploits or malicious apps entirely, sandboxing is useful even just for setting up temporary builds or dealing with buggy code and the fact that we don't have perfect solutions shouldn't be an excuse to not improve the situation at all.
> The thing is a 'day 1' feature everyone hacks back in is clipboard sharing and screen share, each of which remove a decent chunk of these protections. Each essentially grants access to another apps data.
Oh, yes, it's very likely that Wayland will end up with the exact same vulnerabilities. It's very hard in fact to design a windowing system that allows rich interaction between apps, but still maintains per user access control (never mind actually implementing it).
There's nothing wrong with the transport layer's security, as far as I can tell. (For one thing, it's usually tunneled over SSH). The X11 security model assumes that anything with access to the screen has at least as much privilege as the user account that owns the session.
In practice, that's true (things like flatpack claim to support fake sandboxing, but whatever.)
Hypothetically, in a universe where Wayland was running on top of something other than the Linux desktop ecosystem, you could run untrusted code from bash with su, and have it talk to wayland directly, and it'd be OK. Today, you have to run it in a web browser, or using a VM with display virtualization drivers, or use any of a dozen other sandbox choices.
Those all managed to get the correct security properties under X11 because they're properly modularized. Wayland isn't, so to get this one feature, they're expecting all software to be rewritten.
ALL software was ALREADY rewritten for the web, so just use a web browser running directly on the hardware instead of bothering with X11 or Wayland or some hypothetical replacement like X12. That's just an extra useless layer that nobody needs.
A web browser is totally extensible and scriptable in JavaScript and WASM. Standards based. Excellent networking support. Streaming video. Secure sandboxing. Remote accelerated 2D and 3D graphics and GPU programming and WASM engine. Not rocket science. Off-the-shelf, well tested, open standards based solution. Problem already solved.
Why this is not the most obvious thing in the world since the Effrafax painted a mountain pink, and hasn't already been done, totally baffles me. It's as if the Linux community would much rather bicker and squabble about X11 -vs- Wayland for another 30 years than solve the problem once and for all and permanently and perfectly.
>An SEP is something we can't see, or don't see, or our brain doesn't let us see, because we think that it's somebody else's problem. That’s what SEP means. Somebody Else’s Problem. The brain just edits it out, it's like a blind spot.
>The Somebody Else's Problem field... relies on people's natural predisposition not to see anything they don't want to, weren't expecting, or can't explain. If Effrafax had painted the mountain pink and erected a cheap and simple Somebody Else’s Problem field on it, then people would have walked past the mountain, round it, even over it, and simply never have noticed that the thing was there.
I write software for web browsers for a living and I shudder at the thought of having all of my apps trapped in some bloaty, slow sandbox that's different enough from all the other bloaty and slow sandboxes to not actually support all the software it needs to run.
If I have to live on your world, I'll probably just chuck it all in and work with my hands for a living instead.
The web browser is a sandbox, and it runs as an OS process, which is a sandbox.
I think their comment means you’d be better off targeting an OS level sandbox (maybe based on OCI(?), which means a different container for each OS kernel or breaking kernel change — new docker doesn’t run on old linux as it is).
If you chose the OS level sandbox correctly, that would probably be more cpu-efficient than the web browser.
However, that’s a big “if”, since most of the linux sandbox thingies take multiple seconds to spawn a process, and multiply memory usage by 10-100x.
I guess the term "sandbox" can become overloaded. I'm not thinking of OS processes as sandboxes in this context.
> However, that’s a big “if”, since most of the linux sandbox thingies take multiple seconds to spawn a process, and multiply memory usage by 10-100x.
And this is the thing I'm not willing to accept. Well, I can tolerate excessive memory consumption depending on what I'm doing, but I refuse to entertain long boot times. It's the main reason I avoid Java apps, Flatpacks, and so on.
X11 sucks. Wayland sucks. Get rid of them both! But the browser's not going away, and it's open standards based and cross platform, and there's a huge amount of collaborative work and money and talent going into making it better and more powerful and more efficient and more secure across the entire industry and all platforms, unlike X11 and Wayland (which nobody gives a shit about outside of a few fanatical Linux desktop users), or even the Windows and Mac desktops and Android and iOS interfaces (which billions of people use every day, but are stagnant terribly designed dead-ends).
The browser is a sandbox, so why run it on top of another leaky inflexible insufficient outdated sandbox full of clumps of dehydrated urine and cat turds like X11 or Wayland, instead of directly on the hardware?
No modern desktop environment is complete without a browser, so since you're stuck with it, why not just use the browser itself as the desktop environment (or whatever user interface paradigm you choose to use), since you're never getting rid of the browser, and modern non-browser desktops aren't as flexible or powerful or extensible as a browser, and most useful applications have been ported to run in the web browser environment anyway, so they can run across many different platforms, and be easily distributed and efficiently used over the network (unlike Wayland or "modern" X11 apps).
I'm just surprised this seems to be so hard for some people to understand, in spite of the fact that I've been making the same argument for more than a decade, and provided many links to those arguments, because it seems extremely obvious and straightforward to me, and the technology is finally mature enough to pull it off.
X11 isn't a sandbox and that's fine by me. I'm not particularly interested in zero trust computing. I'm not strongly opposed to it, but in general I'm going to choose a lightweight app over a resource hog. However bad X11 is, it runs the software I want to use. That's literally my only motivation for sticking with it. Sorry if you find all this offensive.
> No modern desktop environment is complete without a browser, so since you're stuck with it, why not just use the browser itself as the desktop environment..?
Because I want to use my desktop environment as my desktop environment. I've invested time and energy optimising it for my workflow and I'd like to continue to benefit from using it.
> non-browser desktops aren't as flexible or powerful or extensible as a browser
Again, I don't know what this means. My desktop is literally programmable. As in, I can edit and recompile the source code directly. Please tell me what's more powerful than that.
> they can run across many different platforms,...
I only need my apps to run on one platform
> ...and be easily distributed and efficiently used over the network (unlike Wayland or "modern" X11 apps).
I included a lot of links to my previous posts over ten years explaining what it means in lots of detail with many different words and numerous examples and citations.
Did you read any of them? Did you read my other explanation below that I just wrote personally for your benefit? Does it make any sense to you?
Do you understand what I mean now, or do you need me to give you some more citations of other times I've written the same thing, because there are more. What was unclear, and did I leave anything out?
Do you have any more questions I haven't answered time and again and already gave you links to but you just didn't bother reading?
It's exasperating and insulting that you blithely dismiss what I wrote without saying what you disagree with or can't understand, but I promise you, it really is easy to understand and extremely obvious on its face, if you will just take the time to read what I wrote, before complaining you don't know what it means.
If you have time to complain, then you have time to read what I wrote and linked to, before complaining you don't know what it means.
If you're too busy to read, then please don't waste your and my time complaining you don't understand what you didn't bother to read.
I forgot about those links. No, I didn't look at them. I've taken a quick look now. They seem to be about X and everything that's wrong with it, which is fine, but I don't see much about browsers, and that's what I was responding to your comment about.
My experience with making an app work consistently across browsers is that it's hard work. Making it also work consistently with each OS it runs on is considerably harder. You want to guess how many times I've been asked to even consider either of those two things by a manager, let alone make them a priority? Never.
And going by my experience as a user of browser-based software, I'd say that's pretty normal across the industry.
And that's to say nothing of the fact that these apps are typically slow, cumbersome (by which I mean they throttle my CPU and drain my laptop battery), and crash no less frequently than unsafe apps written in unsafe languages like C (despite the fact that that's supposed to be impossible).
It seems to me that you want to rewrite the world in the browser. That doesn't seem very different to me from rewriting the world in Wayland. Whatever the differences between the two, they are insignificant besides the fallacy of rewriting the world.
As for the rest of your reply, I have no idea why you think I owe you however much time it would take me to read however many links you posted above. If you have something relevant to say, say it in the thread. Don't presume to leave it for me as a homework assignment.
I believe there's work ongoing to upgrade to using H264 using MS's RDP protocol rather than VNC and getting that to work under wayland. That's waaaay better than X forwarding or VNC. if I recall correctly you've also got it backwards - I seem to recall X forwarding is much worse for higher latency networks than VNC.
No, the big problem with X isn't the transport but that once a client has access to the X server it can do more or less anything it wants (including logging keyboard input and recording other windows).
And I haven't actually used it[0] but I thought waypipe was the better option for remoting?
[0] Well, successfully or recently; I'm assuming it's usable now.
From what I understand, and I’m no expert on this, X pretty much broke application sandboxing. X’s design was inherently insecure in the context of modern OS security practices.
Without claiming that X is secure: I think it’s more accurate to say that X has never cared about application isolation at all, since it wasn’t (like its contemporaries) built with that paradigm in mind.
In other words: while not originally UNIX-y, X matured in an ecosystem that idiomatically treats every userspace program as a perfect proxy for the user agent themselves. Sandboxing is a foreign (but good!) idiom that’s being bolted onto that paradigm.
I don't profess to have any deep knowledge of X11 or Wayland, but I don't understand how sandboxing can't work in X11. XWayland exists and it is either non-sandboxed (hence Wayland doesn't add any security benefit) or it is. And if it is it means that X can be sandboxed and it should be possible to run XonX sandboxes. Something like xnest.
I guess then the claim is more that no common implementation is amenable to sandboxing, and the compatibility break of a brand new protocol means they can implement it from day 1 in the way they like. Which is a lot weaker an argument, but practically speaking, it's true that no one is rushing to bolt on security features to X. To be clear I'm not realy a Wayland fan.
You certainly can build sandboxing atop X11. If you're reading using a web browser on a Linux desktop (or in a VM on a Linux desktop), then you're literally staring at an existence proof.
I guess the point is it can't be sandboxed by directly exposing X protocol messages to the sandboxed app. Although your sibling comment by gpderetta makes an excellent point. I guess they're saying no one wants to sandbox the X protocol, and breaking compatibility, proponents would claim, lets you design a sandbox friendly protocol from scratch.
> Nobody else wanted to take up the mantle of maintaining an X implementation.
This is the most surprising part to me.
Despite the volume of end-user complaints I haven't seen any developer stepping up to take over the soon-to-be deprecated X.Org Server or advertising their alternative X implementation.
Even if it remains niche like the various systemd alternatives it seems like a lot of people would be grateful.
So it actually works now? Last time I tried switch to Wayland I also had to switch from i3 to Sway which just flat out refused to run until I gave it some hilariously insane command line argument like --my-next-gpu-wont-be-nvidia, and even then just crashed.
Demanding your users buy different (expensive!) hardware is obviously a non-starter. Especially if you want to do ML. Good luck without an nvidia card.
"combine (two or more images) to make a single picture, especially electronically" ... sucks?
I can't even begin to think how you would present multiple windows to a user if you didn't composite them into a single image. Even if you are doing a 3D virtual desktop, you still have to composite the layers down to 2 single slightly offset images.
There are advantages and disadvantages to both approaches. Note that X.org is traditionally a stacking window manager but has had the compositing model bolted on for a long time now.
Compositing WM is not "versus" stacking WM. Practically all mainstream Wayland desktops are floating ("stacking") based UI paradigms, while using compositing to construct the final screen image. The wikipedia article you linked to shows examples of stacking window management on the compositing window manager page!
Are you thinking of tiling WMs? The major tiling Wayland compositors support floating windows when you want them, too.
No, from the Wiki article on stacking WMs (empahsis mine):
> A stacking window manager (also called floating window manager) is a window manager that draws and allows windows to overlap, without using a compositing algorithm. All window managers that allow the overlapping of windows but are not compositing window managers are considered stacking window managers, although it is possible that not all use exactly the same methods.
It's possible that you have another definition but for me (and it seems for Wikipedia) the distinction is that a stacking WM does not keep buffers for individual windows but instead has them draw directly into the desktop buffer (details vary, the programs themselves might not have access to the buffer but send pixmaps that get blitted there). This results in lower resource usage and fewer copies but requires programs to redraw newly exposed regions when you move a window which may result in visible artifacts when programs cannot render fast enough.
What useful discussion were you expecting from this question? All major window managers use compositing so clearly “sucks” cannot be globally true. Is there some specific problem that you have encountered?
I can run multiple monitors with one of them rotated. When I tried that with X I got lots of juddery tearing.
I can take screenshots and share my screens via video calls. But everyone says it doesn't work due to security.
I have fractional scaling and it doesn't seem to burn out my CPU or battery. Yet that's frequently listed as a disadvantage.
What do I need to do in order to make Wayland as bad as everyone says it is?