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.
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.
There will be stumbling blocks as with any new technology, especially one that interrelates with so many systems but Waylands core architecture seems to be solid.
Personally, I’m still using I3 and don’t see many immediate benefits to switching over to Sway (the Wayland fork of I3). I am cheering Wayland on though and making the switch is somewhere on my todo list. What other path forward is there for desktop Linux?
Minor clarification: Sway is an i3-compatible wayland compositor written from scratch, not a fork.
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Someone is trying to get multi-touch support merged, but is waiting for a review.
If everything that uses X11 today can be used on top of XWayland without any modification and without performance loss, this means that a lot of pressure stemming from the need to switch to speaking Wayland instead of X11 is lifted in a certain sense.
Or am I missing something?
Oh it absolutely is. The entire design of X11 is broken and a barrier to how applications & drivers actually work.
There's a reason that literally everyone else switched away from an X11-style model to a Wayland-style one. That is, MacOS, Windows & Android are all Wayland-style compositor designs. This was the major transition that Microsoft did from Windows XP to Windows Vista.
This is part of the reason that things like video playback in browsers on Linux is just awful. What browsers (or really any modern UI stack) want is just a system compositor that speaks buffers and transactions. Transactions are important to synchronize composition changes and content changes - for example, when you scroll a webpage with a video in it. It's better for power if the video is in a system composition layer, as then it can use a hardware overlay plane instead of being GPU composited (reduces power consumption). But then you need the browsers updated rendering of the scroll position to be synchronized with that composition update. This type of capability is standard on all major platforms at this point.
You can do this everywhere, except on X11. Possibly doable with extensions, but at that point your "extensions" are "completely change everything about the base X11 design & promises" as X11's base design & promises specifically don't provide anything like this.
X11's fundamental design is completely wrong & backwards. That's why a clean slate is necessary. Yes this migration is painful (see Windows Vista), but if it was actually pushed it would be a short term pain and the ecosystem would come out the other side healthier than it started (see Windows 7)
And why do you think you have sufficient knowledge on the topic to assume that? I do assume you have not read the source code of the X server, isn’t it a bit “cocky” to state such a statement, which is in opposition to what the actual X maintainers say, who actually created wayland? It’s not like a project from nothing, it was created with the shortcomings of X in mind.
[citation needed]
Secondly, this isn't the first time I've had people point to this same video. It doesn't actually say what you claim it says. It says the creator of Wayland worked on X (though actually his core focus was DRI2, which btw, is not X), and the one individual speaker in that video worked on X a long time ago (specifically his focus was on keyboard input).
Their claim is more "X is redundant" than "X is hopeless". They're wrong, of course, the video makes absurd claims like "nobody uses core X11". Maybe they don't since they work in niches, but in the real world, plenty of people do... and that's the part of the X server nobody actually complains about. Even Wayland are perfectly OK with that part! (See retaining it in XWayland. When these wayland devs complain about Xorg their focus is usually on the driver side. Well, hate to break it to them, drivers are always ugly. See the link we're commenting on, if Wayland actually works on all the devices Xorg works on, it'll be just as ugly.)
Also, there have been another HN post with “X is abadonware” or similarly titled, which was written by another X maintainer. But feel free to check the mailing list as well looking at activity.
I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless.
But even if you do, the compositor only does one job: layer graphics. Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc. Wayland either fragments this (saying it is all the compositor's problem or punts it to dbus or something), or ignores it (they feel about useful things the way I feel about compositors), and will likely reinvent it eventually anyway.
And btw, what about X is unnecessarily complicated? I love the way the presenter claims the specs are impossible but I managed to implement them and so did a bunch of other people. So apparently it isn't actually that hard. and btw they aren't actually all that different than similar functionality in different operating systems, aside from things like asynchronous chunking... which is a good thing, since you don't want to block your UI event loop anyway! So it is what good programs ought to be already doing.
Have you tried watching a video in full screen?
> But even if you do, the compositor only does one job: layer graphics
Yes, and this small little detail is not solved by X, but Wayland.
> Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc.
And it will live on in the form of XWayland. And I do dislike needlessly dropping backward compatibility, X’s APIs are globally broadcasted, and can’t really be retrofitted to an only server-client communication, so it makes sense to “reinvent” it.
> I love the way the presenter claims the specs are impossible but I managed to implement them
What part of it? I doubt you included the now removed printer part and the million other things the X developers had to cut out with hard work. And as I said, XWayland is made explicitly for this high level API of X, it is not going anywhere.
And I’m not sure what you mean by asynchronous chunking. You mean tearing? You do have to synchronize somewhere.
Nah, I've actually never used a computer since 1995. What is this "yoo-tubes" thing all the kids are talking about nowadays anyway?
You do realize that X applications can use DRI too right? And vsync when they swap buffers? This is trivially easy.
The only time I've ever seen glitches is if I tweak a couple config options with the intention of causing it, run a poorly-behaving program, and then resize it rapidly up and down. That'll cause a flicker.
> X’s APIs are globally broadcasted
No, they're not. I imagine you must think thinking of one client deliberately selecting the input of another client's window, which is allowed (unless the client is untrusted, e.g. an application from a `ssh -X` session - yes, X does support "untrusted" connections and restricts their access, and has since like 2007), but that's still not broadcast per se; you only receive a copy of the message if you specifically requested it.
> What part of it?
Drag and drop, clipboard, docking, window manager hints; here I was referring to the extension specs used for IPC with the X server.
And it is really pretty cool what you can do with this. If you run two applications on separate computers, you can drag and drop stuff between them and it just works.
That's the asynchronous chunking I referred to, again this was in the context of "unnecessarily complicated IPC". There's a size limit and acknowledgement protocol in transferring things like drops and pastes and your program is never supposed to block on those cases, rather go back to the full event loop. This is a bit more complicated to program, but it has several benefits, even on non-network cases (like say pasting a gigabyte on a Windows box) - you can stay responsive to the user while working in the background, show progress bars and cancel buttons, etc.
(Now if you're on the same machine btw the spec says to optimize some of these things and, for example, transfer a filename instead of file contents and let them read it themselves. The youtube video is half-correct when he says X isn't network transparent. Actually, a surprising amount of things are, like you can often run (old-style) OpenGL programs on remote hosts even if the author didn't plan on that! But if you want best results, you do need to have local machine optimization branches. If local machine, use shared memory instead of buffer transfers. If local machine, send file name instead of contents on drop event. Stuff like that. I also personally do things like if remote machine, disable mouse motion events unless a button is held down, just so save on bandwidth, though of course that's not a big deal anymore, but the core protocol does make that trivially easy to do!)
wrt tearing - which again I virtually never see on X (I have to go out of my way to trigger it!) so I really don't know why people complain about that so much - again you can vsync easily with glx and double buffer easily in any program. There's even a XSync extension you can use to help with these, even across clients: https://www.x.org/releases/X11R7.6/doc/libXext/synclib.html (note the date on that: 1991. It isn't like this stuff is new.)
Also, regarding network transparency. As you note, most apps are no longer network transparent, and remote window streaming can be much better solved with modern compressions/encoding. It doesn’t have to be part of the core protocol, the latter should only concern itself with displaying rectangles on the screen. Everything else can be built on top of it.
Also, while in itself not a good argument, both MacOS and windows use a compositor since forever.
This is always the case when there is some widely used legacy tech, but it shouldn't stop us from trying to move forward, or we'll never get better things.
I've personally switched to using wayland on my main laptop and am very happy with it. I was using X before and was getting incredibly bad screen tearing when using i3, I tried every recommendation I could find (double buffering, running a compositor, etc) and nothing helped, but Sway on wayland fixed it for me and its been running flawlessly for the last 9 months. I have no plans of going back to X anytime. The only thing I use X for is playing Windows games with Proton (which this HW acceleration change might even fix, if the laptop had an nvidia gpu, but alas, it does not).
Wayland means moving backwards. It has the complete wrong philosophy and abstractions. If "sway" runs flawlessly for you you are not doing much with your computer at all. I can't work without my fine tuned synaptics driver configuration and without my over the years grown and perfected scripts using xdotool, dmenu, xsel, xcape, xcalib and many other tiny but useful x-tools.
> fine tuned synaptics driver configuration
My touchpad, touchscreen and apple magic trackpad work great for me, so this isn't a problem for me.
If message boards like HN are where you're getting this impression, just beware of sample bias. Remember that everyone on Fedora and/or KDE has been running wayland for literal years. That is a lot of users, and not enough complaints to make them consider reverting.
Fwiw here's my counter anecdata:
I'm on arch with swaywm, meaning my system is in no way "out of the box". I have gone back to X from time to time, and... it drives me crazy. Everything is blurry, it takes an hour off my battery time, and it FEELS laggy and unresponsive. Oh, and the experience of installing anything involves 5 extra packages (automatically included, at least) to work around X stuff. God help you if you want to configure an input method; it goes through AT LEAST 2 layers. For some input methods (touchscreens, i'm looking at you), you have brittle hacks like one layer is just reading the debug log of another. Anyway every settings change you make requires restarting your whole WM, and probably fiddling with several 3rd party tools to understand and make it easier... no thanks.
Even when I could only screen share between xwayland apps, and I really tried to go back, I couldn't stomach it. The wayland experience for me is just so much better across so many dimensions. I can only imagine what it's like for my friends who use OOTB setups and aren't even aware they're on Wayland.
A conservative rewrite, that amends those things experience has shown were mistakes but were always retained for compatibility, is rare, since the impulse to rewrite is revolutionary in nature. A rewrite is treated as an opportunity to remake the world in a new image (with a new set of mistakes to uncover).
It needn't be a prompt users will quickly be prompted to click yes to it could easily be an option in settings or at communicated at install time.
Wayland is a necessary part of security, but not sufficient.
Linux only grants permission to keyboard/mouse events to root or to display “owner”, which is the one who requested it on a given tty.
* Using ptrace(2) to hook into your running processes and grabbing key data that way
* Adding a LD_PRELOAD around your application launcher (via your .bashrc or some other auto-exec script) to have it intercept key events for your application
* Downloading and mounting a FUSE filesystem image with the /dev/input device nodes owned by your user ID instead of root.
* Use one of the multitude of privilege-escalation CVEs on the Linux desktop to gain root, and keylog you that way [1].
Come back when you understand the problem.
[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+privi...
How does X help here?
That there exist SELinux plugins does not mean that XACE itself depends on it. Like, try reading the actual documentation instead of regurgitating FUD: https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv...
It's also outside the scope of a desktop environment or window manager to ship plugins to the X server. Hence another reason why they had to go with a new protocol that makes it easier to implement their own server...
I stopped reading at this point. If you're not going to read the documentation, then you can kindly go crawl back under your rock on /r/linuxmasterrace.
Yes people could develop new plugins that integrate with some other security mechanism, but they haven't, in part because the hooks are so out of date, and in part because, you know, that requires building another security mechanism. The access hooks are not a security mechanism, they allow you to integrate with some external MAC.
Second, it ended a pile of hacks upon hacks.
Those two reasons have to be added on top of the other benefits of Wayland (or any other modern re-arch of X).
I have read of the supposed benefits of Wayland, but from what I can percieve, the cons (too numerous to mention, but mostly breaking a billion useful things that X has had for some time) seem to out weigh the pro. Yes, the pro. Fractional scaling.
I don't like actively cheering for something to fail, but I really don't get it. X11 is in no way broken enough to justify such a huge change, and I'm concerned that the KDEs and Gnomes of the world are going to ramrod the thing through regardless.