The “good old days” of unencrypted Internet, where everyone could see your cookies, are no longer acceptable; the same is true of X11.
With X11, if you copy a password from your manager, you must assume all running apps now know it and transmitted it to a malicious server. There’s no way to tell.
With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.
With X11, everything displayed on the screen is compromised. Also, all inputs, keyboard and otherwise.
With Wayland, each app only sees their own pixels.
With X11, screen locking is pure hackery that doesn’t always protect the locked pixels and… login password.
Traditionally, you are meant to trust that process boundaries on Linux are sacredly secure, which is why Spectre was a big deal. But in practice, that is only true under Wayland.
https://www.freedesktop.org/software/XDevConf/x-security-wal...
In Wayland, you make the extension, then you patch every compositor, every toolkit and every application.
In X11, you make the extension, then you patch the X server, Xlib, XCB, every window manager, every toolkit, and every application.
With Wayland, it is only transmitted upon pasting, and only done directly from the copier app to the paster app.
Can you elaborate?
This sounds implausible, wishful thinking since key bindings are managed by individual applications. Whoever holds the clipboard must trust the application that claims to have received a paste command from the user. I don't see anything that could prevent spoofing without just blocking clipboard access entirely or making the usability a lot worse.
In Wayland, the compositor has special standing. For instance, KWin will only allow the currently active window to paste.
There is more information here: https://phabricator.kde.org/T4449#192501
At a meta level, this is probably the most frustrating thing about Wayland: all of its benefits could be realized in the X context itself, even the getting rid of legacy baggage (deprecate parts of the protocol leading up to the definition of an X12).
People actively chose not to do this and instead delayed progress by at least a decade.
Ideally, Wayland would have just served as a tech demo to guide the evolution of X. But as a community, we give too much credit to people working on shiny new things.
”With Wayland, each app only sees their own pixels.”
Out of curiosity, if this is true, how are screenshots / screen recorders implemented? Do they require some special permissions? And if this is the case, why wouldn’t any app be able to acquire these special permissions?
There are solutions to this, which allow finer grained access to screen recording in future, but there are a couple of competing standards right now.
I don't care if xorg runs as root and I don't need to run an instance of xorg per application I simply install software from trusted sources and haven't managed to get malware between 2003 and now. I also didn't have issues with tearing in 2003 and I don't now.
Generally speaking QT and GTK and other toolkits must concern themselves with the details of X others concern themselves with QT or GTK as they would under wayland. It is extremely likely that all players in the overall ecosystem who never had to specifically worry about X in many years have had more issues, work, and tears from wayland development than they would have had for the remainder of the next century with X.
This is nearly entirely about presenting a saner stable base to improve the work for a tiny number of people actually developing the graphics stack in Linux to build upon and unfortunately they made poor design decisions at the start that have led to it taking 12 years and still not being ready for prime time in some ways.
After doing the necessary research to understand the topic you could construct another post about the shortcomings of X that is actually factually correct but it would still be beside the point. Wayland would still be a poor work that squandered a lot of the opportunity of a clean slate despite its authors being in perhaps the best position possible to do so. In 20 years Linux if it exists on the desktop will be a weird opaque overengineered system that works when it works and is impossible for an end user to understand why it is misbehaving when it doesn't.
On the bright side due to package management the windows solution of pave over the install and start over could probably be configured to automatically reinstall all your software for you!
The X server is maxed out, or as a core maintainer said, you can only apply this many lipstick to a pig. It is fundamentally broken. But the X api is not, it will be supported forever in terms of XWayland. Which is a net win, we get proper graphics, and apps will be backward compatible.
The Wayland developers disagree with you:
https://wayland.freedesktop.org/faq.html#heading_toc_j_5
"It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X."
They themselves say they could have fixed X. They just didn't want to. And now they've predictably just made a new mess.
Breaking user's applications isn't actually a virtue.
Just watch it.
Take the whole part about "X terrible IPC" and slow startup time as an example. It's portrayed as if slow startup time is an inherent flaw of X due to blocking IPC calls. However he forgot to mention, that non-blocking calls had been there for years and big projects like Qt were using them exclusively instead of the blocking Xlib calls. Then he goes on to say that Chromium's startup time is so slow because at minimum it waits half a second for replies from the X server. So let's get some current numbers on a T420s for starting up Chromium and immediately closing it:
Weston + Chromium (Wayland mode): 731.3 ms ± 39.4 ms
Sway + Chromium (Wayland mode): 688.2 ms ± 22.7 ms
Sway + Chromium (XWayland): 667.2 ms ± 16.6 ms
X.org + i3 + Chromium: 661.3ms ± 17.2 msSo either his numbers don't apply anymore and X.org is not a bottleneck anymore, or Wayland became a similar bottleneck, or his numbers never made sense in the first place, especially since he never bechmarked the Wayland part.
Edit: On GNOME Shell Chromium also starts slightly faster with X.org with 0.6 - 0.7s and > 0.7s in Wayland mode.
*updated benchmark results with the actual results from hyperfine (10 runs each)
The whole point of the talk was that when a compositor is used (which should absolutely be used because with increasing resolutions tearing will just get more visible), X has pretty much a useless role in the whole situation. That is, you’ve got yourself an architectural problem. Which is no surprise, X had been here forever. But maybe it should no longer the be the abstraction we build our graphics on.
So it doesn't seem to have any significant influence either.
You're not using TCP for local X, it's all Unix domain sockets and SHM. Hard to get any faster on Linux.
One could certainly implement feature emulation to preserve backward compatibility with evolving hardware. Or just deprecate feature, X over network was pretty much broken for a long time.
Not saying Wayland isn't an improvement over X but a lot of supposed limitations of X are often misrepresented and exaggerated.
> Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.
This may seem like it's irrelevant for the user. It isn't. Lots of things us users want are much easier and more attractive for developers to add to the clean slate design that is Wayland.
For example: When I switched, an unexpected bonus I experienced was that my touchpad's behavior got orders of magnitude better. So I googled around a bit, and it turns out that almost all touchpad improvements just happen to occur on Wayland because the people who are interested in that aren't interested in wading through the X swamp in order to implement their stuff. (I mean, have you looked at the X code? Oh dear, oh dear, it's a daunting thing!)
This is something I don't understand about Wayland. How is it possible that something that is supposed to be much easier and more attractive for developers after TEN+ years of development still has so many issues ?
I see it as a “failing” of the bazaar way of development, linux can’t just say we now use this API. So there is an inherent not enough user on the new API to bother porting, and due to not enough user it is not as streamlined/stable, and you have a vicious circle. But I have to say the issues with wayland are heavily overstated, and I think it is out of this cycle, and is getting quite a bit of steam.
I am quite sure that there is something wrong with your system if your X clients run through the IP stack by default.
I'm running Openbox/Xubuntu on a 4K monitor, doing some awesome equivalent-of-4-monitors work, then playing all the steam games I want with the Proton and the decent AMD GPU, all under X. "Font size is a little weird sometimes" is my only gripe?
Put differently, I understand "hacking around the issue" criticism in theory -- but if you applied that sort of purity to, say, web programming -- step one would be, okay, first get rid of Javascript, an idea that I really do like in theory, but I know it's not happening.
I've never even had a reason to want to run it.
But I'm sure it'll be great, any day now.
It just seems Wayland's combination of technical requirements and political entanglements make it a sort of Zeno's Project, doomed to asymptotically approach peoples' expectations and desires, but never reach them.
So? The same has been the case for desktop Linux in general, for 2 decades.
Some of us have been running Linux desktops for over two decades. Nothing more fun than setting Modelines manually for your VESA card:
Wine sucked and there was less software existed but it was perfectly possible to do the normal tasks one did with a computer.
Edit: I guess it was a 486 in a 386 motherboard. Windows was definitely slower at 75MHz than Linux at 25MHz though:
http://ps-2.kev009.com/sandy55/Interposer/386_upgrade.html#R...
Linux Desktop is Great. Wayland is still in the process of becoming great (I think it's making good progress too)
Reference: https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPl...
And also perfectly possible with X11 because the pitch information is exposed via the Xrandr extention
> Problem: tearing, solvable with double buffering, maybe.
Solved since ages. Just enable Tearfree in your Xorg.conf. That also shows how great X11 really is. It allows you the choice to turn it on or off. Because Tearfree comes at a cost of latency.
> Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.
OpneBSD solved that two decades ago. Also it perfectly possible on Linux to run X11 as non-Root.
> Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program.
This is a feature not a bug. The security paradigm is blacklisting (which means sandboxing untrusted apps) instead of whitelising (which means locking everything up and only allow the compositor to do stuff). Since the vast majority of Software on FOSS system is trusted X11 is the far superior solution here.
> Problem: Xorg is a network system, meaning it is very inefficient.
X11 runs even on 386's and beats Wayland in every performance metric, especially latency. After 13 years of development only some compositors come close to X11's performance.
> Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features.
Backwards compatibility is a major feature even 40 year old Software runs on current Xorg which is an impressive feat. As for the "hardware features": DRI3 uses the exact same buffer sharing mechanism as the major Wayland compositors do. Wayland offers zero advantage in exploited Hardware features. On the contrary X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.
> Overall, wayland is a good clean slate, it’s been in development a long time.
It is a clean slate, but a very bad one. The wrong philosophy ("every frame is perfect") and the wrong abstractions ("everything in the universe is a buffer made of RGB values") make it a major step backwards in computer graphics on Unix/Linux.
Only the "Windows" kind of scaling where the app works in non-scaled, real pixels and does everything by itself. Not the "Apple" kind of scaling that Wayland supports, where you have logical pixels backed by 2x/3x/… the physical pixels. (Like many things Apple does, this was invented for good reasons. Positioning a window to be on both a 1x and a 2x monitor just works with that kind of scaling, without the app ever having to consider the displays it touches.)
> Solved since ages. Just enable Tearfree in your Xorg.conf.
That's a driver-specific hack that kinda maybe works sometimes. Sometimes you need to juggle compositor options combined with that and nothing works anyway.
> X11 runs even on 386's and beats Wayland in every performance metric, especially latency.
Any composited X11 desktop is slower than a Wayland one, with the Xorg server acting as a bloated IPC broker in between the compositor and the client.
Yeah, you can get really low latency if you just don't composite at all. Go back to Windows 95 if you think that's acceptable :)
> X11 is capable of using hardware layers that has the effect that you can smoothly move your mouse even on heavy load and OOM events. Wayland still completely craps out in that regard.
I'm sure pretty much all production Wayland compositors use the cursor layer. wlroots for sure does. (But I don't think it's a big deal under heavy load, there the problem is the display server even processing the mouse events at all first.)
Weston goes further and can use HW layers for actual surface compositing when possible. wlroots is going to gain that power soon-ish with libliftoff.
> The wrong philosophy ("every frame is perfect")
Again, feel free to use Windows 95.
For anyone used to current commercial desktop and mobile UIs, any imperfect frames are unacceptable, artifacts like tearing make your system look like a complete joke. Apple computers didn't show imperfect frames since the early early 2000s PowerPC era. Not matching that is a complete shame.
This is not fractional scaling. Fractional scaling has to be done by the application itself (even on Wayland).
> That's a driver-specific hack
It is not a hack. It is a solution and a very good one because DDX drivers can make use of vendor specific 2D acceleration and therefore achieve much better latency with the tearfree option on X11 than Wayland ever will where everything runs through the 3D pipeline by default.
> Any composited X11 desktop is slower than a Wayland one
If you enable Tearfree you don't need a compositor if the driver works properly. Of course X11 compositors with fancy blur effects have bad performance. I always turn them off.
> Go back to Windows 95 if you think that's acceptable :)
Why don't you switch to Android? Android already does everything that Wayland fans want and better.
> I'm sure pretty much all production Wayland compositors use the cursor layer.
I get severe mouse stuttering on high CPU or GPU load. A problem that was solved on X11 20 years ago. I have no idea what wlroots really does but it does it definitely wrong.
> Go back to Windows 95 if you think that's acceptable :)
The value of X11 is the ecosystem and platform it provides. If you want Linux with a compositor switch to Android. There you also have your sandboxing and whatnot. Don't turn the Linux Desktop into a Phone OS. As Desktop OS I genuinely prefer Windows 95 over Android.
> Apple computers didn't show imperfect frames since the early early 2000s PowerPC era.
Ever used OS X on those? They are barely usable because of severe lag and stuttering. But yeah the frames were so perfect that most people decided to switch back to MacOS 9 to do real work.
No, fractional is handled by applications just rendering at 2x and getting downscaled to 1.5x or whatever.
Yeah, the "Windows" way looks sharper on fractional, but the "Apple" downscaling is easier to handle and it looks fine – there were iPhones that did everything like that.
> DDX drivers can make use of vendor specific 2D acceleration
Ah, I remember Intel's various native 2D accelerations (UXA, SNA) – each with its own unique horrific bugs (artifacts all over the screen, all text turning into junk), all eventually sorta deprecated in favor of glamor (OpenGL) with the generic modesetting driver.
There's not much to 2D accelerate with modern applications that all do their own rendering. Compositing acceleration is possible in a vendor-agnostic way via KMS planes and we'll have that in wlroots.
> Ever used OS X on those? They are barely usable because of severe lag and stuttering.
I have an iBook G4 :) Leopard runs perfectly smoothly. Yeah, the very first generation of hardware when OS X was just introduced wasn't ready. The next one was.
It's even more fun when your realize no GPU in the last decade has shipped 2D acceleration capabilities. Wayland uses 3D acceleration because that's what GPUs offer, because that's what the other platforms exclusively offer now.
This is absolutely not a good solution. Even if you audited all your software enough to consider it trusted (which is unlikely if you're not a purist - see IDEs, browsers, widevine, Docker ...), it does not guarantee anything is secure. Anything that receives input from the outside might be vulnerable to an RCE. If you're running it under a different user or in a jail, the impact is limited - unless it can access your X server, in which case it can simply log everything you type and escalate.
Jailing an app is basically impossible under X. Yes, you can use Zephyr, but you're not going to be able to watch a video there and you're WM integration is going to be miserable as well. And realistically you'd really need to jail most apps.
X11 might work for a lot of things, but blacklisting is absolutely not a superior approach.
Indeed. But looking at the state of the average Wayland compositor right now I trust all of my X11 software more than I trust Wayland. Especially when X11 and most clients have been battle tested for up to 35 years.
Besides that, you can also use Xpra for sandboxing which has better desktop integration.
Mostly the issues could be hacked around. But let’s be absolutely clear with this: it is hacking around the issue.
Problem: tearing, solvable with double buffering, maybe.
Problem: Xorg runs as root, solvable, there’s ways of making your user have direct control of the frame buffer device.
Problem: Xorg is a network system, and a porous one, meaning it’s possible to intercept keystrokes from any running program. Solvable by running a mini X11 instance for each program.
Problem: Xorg is a network system, meaning it is very inefficient. (Imagine using TCP to talk to your SSD)
Problem: Xorg needs to be backwards compatible, so it can’t dig much into hardware features. Especially as the client may not be on the same machine as the server.
Overall, wayland is a good clean slate, it’s been in development a long time. X11 has major warts and they are hard to clear out.