Nice results. It's kind of wild that the "before" behavior would be considered acceptable/shippable by anyone. That kind of jank should be a show stopper.
I have no opposition to Wayland in theory; my concerns are entirely practical and unignorable.
Then nVidia decided to switch to GBM/EGL way of doing things and it turned out everyone had incorrect assumptions...
The ecosystem slowly moves towards explicit sync now, but Nvidia was supposed to provide a driver already before that was happening and they didn't comply with platform's requirements at date, resulting in user-facing issues. With this one, they just got lucky that the consensus happens to move towards what they had already asserted.
It depends on the type of jank you're talking about. It's wholly disingenuous to characterize Wayland as janky but x11 as not - the jank inherent to x11 is what made the original Xorg developers start making Wayland in the first place. Empirically, if x11 was perfectly fine there would be no motivation to design a successor.
x11 gets the first-mover advantage of a lot of implementations and a straightforward design goal, but that's about it. It's not secure enough to recommend as a serious alternative to Mac and Windows users, and it's too slow and unopinionated to present a friendly face to new users. Features like 1:1 trackpad gestures, genuine HDR pipelines and a locked compositor framerate are all getting to the point that regular consumers expect them as default.
If you want to keep using x11, it's unlikely someone is going to take it away from you. But it's on track for depreciation and hasn't been actively developed in years. Recommending it as a panacea to new users is a bad idea.
I've been recommending it as a serious alternative for years, and it's always presented a friendly face.
> Features like 1:1 trackpad gestures, genuine HDR pipelines and a locked compositor framerate are all getting to the point that regular consumers expect them as default.
I have never heard anyone not already a Linux user comment on even one of those as a problem.
....because Windows and Mac users have not had these problems since 2006?
Those specific words are uttered by Linux users, true. However, Linux beginners _do_ notice some X11 issues, it's just that very frequently they only know "something" is off but not why they feel so.
From anecdotal experience, touchpad gestures are actually something my friend complained so YMMV. We ended up making a file in /etc/X11/xorg.conf.d/ to configure the synaptics driver. Another experience had to do with screen tearing, I helped them fix it by installing a compositor.
The security risk of X11 is theoretical, not practical. Yes, X11 programs can maliciously keylog each other, but this just isn't a thing that actually happens. And even if you do start installing random malware from the internet like a classic windows user, Wayland isn't going to prevent you from screwing yourself anyway. To actually be safe while installing and running malicious applications you need extensive sandboxing. Wayland can be one part of that sandboxing but is useless without the rest (to prevent the malware from stealing user files including credentials, using LD_PRELOAD hacks or similar to keylog other applications anyway, etc), and no distro suitable for recommending to Windows/MacOS newbs has the rest of the requisite sandboxing. The sandboxing touted by Wayland advocates is very esoteric and without all that sandboxing, a newb using Wayland has to exercise just as much caution when downloading software as if he were using X11.
A simple search leads me to this: https://github.com/anko/xkbcat
There isn't a real attack using it yet, only because attacking Desktop Linux is a really unprofitable endeavor (considering the marketshare, the ROI must be very low).
> To actually be safe while installing and running malicious applications you need extensive sandboxing
FWIW, X11 is unsandboxable unless you run a second X server on top of your current server [0]. Which is fine, but you need to consider that most, if not all sandboxing solutions on Linux that "newbs" use, like Flatpak, do not employ such technique when running sandboxed X11 applications.
The "security by default" behavior of Wayland limits the possible attack surface a lot, without requiring the end user to understand all the nitty details involved.
[0]: https://wiki.archlinux.org/title/Bubblewrap#Sandboxing_X11
This cannot be more further from the truth. Amongst the newcomers, it is rather popular nowadays for them to use Flatpak-bundled apps, especially with the rise of SteamOS (the Deck essentially) lots of Linux newcomers are in fact first exposed to Flatpak and running untrusted executables in a sandbox.
And the most prominent "untrusted executable" today to those newcomers has to be Bottles, which is a nice GUI wrapper for Wine and is sandboxed (if you enable wine-wayland, of course).
But I don't think a game purchased through steam counts as untrusted.
As compared to running untrusted programs completely naked?
>But I don't think a game purchased through steam counts as untrusted.
Bottles is there for people to run any Win32 program, not just Steam games. And I shouldn't have to tell you how many malicious Win32 programs there are.
Containerization on Linux was never intended to be a security feature for totally untrusted, malicious code. It's isolation for trusted code. If your scenario relies on securely running untrusted executables in a Linux container you are doing stupid things.
You see: If you want absolute security, for sure, go for a full-fledged VM! Or run something like QubesOS. It is a completely reasonable decision.
However, malice certainly has degrees, and the "mildly malicious" programs most likely cannot take advantage of sandbox escaping exploits. If Flatpak can stop 95% of all attacks (relative to running a program completely without sandboxing), that is already a win in my book.
But I will note again that X11 is a big hole (as in, almost a complete free-for-all) for sandbox escaping in Flatpak.
I'm done with this thread, have a nice day.
And besides that, "these threats are off in fantasy land" is an invalid defense in my opinion, considering the (quite sophisticated) XZ Utils backdoor happened not too long ago! Like I said, if such an attack towards X11 hasn't been deployed in the wild, it can only suggest such endeavor is unprofitable, not because the threats are fantastical.
If the attacker decided to backdoor an utility and make use of X11, it is most likely the backdoored utility will listen to keyboard events, read the bitmaps of other X11 clients.
And there's nothing that can stop the backdoor from doing so on X11...
Anyways, if you are saying the Wayland security policies are unneeded because there hasn't been an attack on X11 (this is the fundamental disagreement between us), consider the following: You don't install doors in your premise, because there hasn't been a case of burglary in your neighborhood?
When this is the case and there is a supply chain attack, what you think is a trusted application (and therefore not running under "WaylandX") can very well keylog you or take screenshots of your desktop without your consent.
In a deny-by-default model ala Wayland, applications will have to ask for permissions before they can do something considered to be privileged.
Are you really saying keyloggers do not exist in the wild???
> Wayland can be one part of that sandboxing but is useless without the rest
Yes but that is the point, and if you turn it the other way around X11 usually makes the rest of the sandboxing useless.
And yes, X11 makes that sandboxing useless, but that sandboxing isn't in play anyway because we're talking about noobs from Windows.
In principle I am also vulnerable to something like a RCE zero day in Firefox turning an otherwise trusty program into malware which exploits X11's open nature, but again, this sort of thing actually happening is unheard of.
I'm not superior, I'm just trying to keep a realistic grip on the threats I face. Modern security culture is fixated on what is theoretically possible, I care more about what is actually likely.
I disagree. How do you hijack interprocess communication on a Wayland device? I can tell you in very certain steps how to manipulate an x11 client but outside hijacking /dev/ I can't imagine a similar attack on Wayland.
This is not something you should ever have to do
I think your argument is about specific implementations of WM. While the argument of "I deal with X11-based WMs because it's fine when I don't care about security at all" may be valid in very narrow cases (such as air-gapped systems), the argument more generally is pretty weak.
Its not surpising that x11 based WMs, such as the almighty [awesomeWM](https://github.com/awesomeWM/awesome), have more features implemented than, for instance, [jay](https://github.com/mahkoh/jay) due to the enormous time it has had to develop (though I am _very_ excited to see `jay` develop more fully, and expect it to be well used by the more tech-savy devs).
However, some WMs in the Wayland space are doing quite well on that front. I recently had some substantial problems arise in my system which (surprisingly to me, but perhaps some are getting used to this) would have been prevented by using a memory safety language for my WM, so I have made the switch to (for better or worse) only ever consider Wayland+Rust WMs. In this space, [niri](https://github.com/YaLTeR/niri) is actually quite good, and to the point - it is developing correctly _and very quickly_. So, any issues on some WM not implementing some desired feature are quickly disappearing.
IIRC, all the major 'gateway' linux distros, such as Ubuntu or Fedora, are all on Wayland by default now - so I don't imagine x11 will stay relevant much longer.
Most legacy X11 apps in active use are actually games which tend to be fullscreen and not resized, so it wouldn't happen that often for many users.
(That said, sure, I can also respect the stance as I tend to place a premium on glitch-freeness too.)
My comment was concerned with making it abundantly clear that this glitch happened in specific scenarios and not just any and all window resizing.
Even Windows generally switches down to software rendering when resizing. And on mobile devices, nobody resizes.
No pointer warp, however, is a failure (CAD packages all have significant issues on Wayland). Lack of multilingual support/accessibility is a failure. Lack of screenshots/screencasts is a failure. Lack of support for the BSD lineages is a failure. etc.
People are still bitching up a storm because Wayland still (Pipewire does screen sharing using DBUS(!) for example) hasn't fixed basic things while DeadRat is shoving it down everybody's throat by dropping X11 support.
The Wayland devs aren't wrong about the security implications of this kind of stuff. However, they're also not giving anybody solutions, either.
One big issue is that Wayland devlopment is so slow that the entire space moved forward and destroyed a bunch of assumptions that Wayland is based around.
Not true. FreeBSD and OpenBSD have had various wlroots compositors such as Sway available for some time. e.g [1] Some people have even been experimenting with KDE-wayland on FreeBSD since 2021.
Wayland support on any OS is not binary because there is no single layer like Xorg. It's a matter of individual compositors and their components being ported to the OS, which is a matter of popularity, and the BSDs are always at a disadvantage in that respect, so they lag behind, same as other software. Nevertheless, they are definitely gaining support. Then again this distinction is only technical, for functional support new DEs/WMs would always have needed to be ported regardless of display architecture, the only case it would not is for an Xorg drop-in, which defeats the purpose.
> Lack of screenshots/screencasts is a failure.
... but there are many functional screencapture apps, and even browser support, I use this pretty much every week. I think you might be operating on out of date info. I'd highly recommend giving it another try, the Wayland ecosystem has come quite far over the last decade.
And even then you have to deal with a mix because you have to work through two different unsynced possibly broken in weird ways connections (Wayland + D-Bus).
This results in how last week I couldn't screenshare under Wayland, and had zero chances to figure it out - and to make it worse since I had some important state and no time to play with reboots, I couldn't fix it.
Multiple IPCs make the whole stuff way more complex, there is a reason why we have a big monolith as browsers and not some `curl | htmlRender | jsInterpreter` Rube Goldberg machine — the unix philosophy is not the pan ultimate design, it works in some cases and is utterly broken in others.
And Wayland did not stop requiring multiple IPCs, in fact it mandates them as several features require passing data by secondary channels, not just for Portals et al - some don't even have any described way to reliably pass the information that I have seen (like how to pass around cookie to let one application activate window of another? Or maybe the spec is such a mess that I'm looking at completely wrong place when I tried to fix ability to reliably switch between applications without extending compositor).
And yes, the architecture is more complicated in practice, otherwise it might have reached parity with what X11 did after as many years - like input method support. Unfortunately it's so broken that you have multiple versions of it in practice, it requires extra IPC in practice, and at least in my experience just does not work.
You need to have `xdg-desktop-portal-wlr` or equivalent package installed (should be depended upon by sway package really), and also the gtk one for some other stuff wlroots doesn't implement like notifications I think (don't worry it doesn't drag in all of gnome).
This is technically the only thing you should need to do beyond picking a wayland compatible screen capture program or browser - However it's possible the dbus variables are broken if you wrote your own sway config from scratch (guilty)... Depending on your OS, the default config should do this automatically, on Debian it includes /etc/sway/config.d/50-systemd-user.conf, I can't say for FreeBSD. So point is if your config omits the dbus-update-activation-environment command, you probably need to include it in your config.
TL;DR
apt install xdg-desktop-portal-{wlr,gtk}
exec dbus-update-activation-environment --systemd \
DISPLAY WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP=sway
Remember to restart sway to test this.
But they are wrong. Their security model assumes an ecosystem of untrusted apps when we already had something far superior: distributions with vetted packages.
Wayland is like bolting down your furniture because if you let in random strangers from the street they might steal your stuff. Instead of adding obstacles that make my own life harder I prefer to keep better company.
It's rare but not unheard of for someone to be able to sneak malicious code into a vetted package. It's extremely common for vetted packages to have security vulnerabilities that could be exploited.
I don't want someone who finds a vulnerability in a fart app to be able to escalate that to attack other apps on my computer.
I trust my accountant with a lot of sensitive data but I don't give them the keys to my house. I trust a friend with my house keys to water plants while I'm gone, but I don't give them the password to my bank account.
> It's rare but not unheard of for someone to be able to sneak malicious code into a vetted package. It's extremely common for vetted packages to have security vulnerabilities that could be exploited.
Ok, when is the last time you or anyone you know personally sustained any nontrivial damage because of such an event? You can make up hypotheticals to scare people all you want but the simple fact is that no, people are not actually in any more danger on their computer than they are just being alive.