That is to say, if you were to use my definition for security then this sentence “Wayland fixes several large holes in security that X11 had.” translates directly into “Wayland removes several large features in users pockets that X11 had.”
Edit: The statement is just not the flattering slam dunk of an argument people are making it out to be.
That is the major hole in general Linux security. So many use cases in general require users to go to various markets/repos, that honestly I don’t have a lot of trust in, to solve problems that really should be been solved by the OS/distro with believed safe solutions.
It’s similar to the old, change your password every 60 days, min 20 char, 5+ special characters. Results, office covered in post it notes with passwords written on them.
Sorry, no. I and other have defined and gone into those earlier in the thread. You are simply being argumentative here. I’m not going to spend time explaining something if you are not willing to read it and be open to new information even when it’s not comfortable.
X11 isn’t all bad, but it has major and mostly unfixable problems. Those have been covered here. Wayland isn’t all good, again covered here.
I push back hard on those claiming Wayland works for most use cases, because at least here, it hasn’t worked well for anyone. My hope is those who so energetically support Wayland here will pass that info along to those that can make things better. However, just repeating talking points over and over will just get you ignored.
Id say live with what wins but since I run fedora and it keeps on winning with engineering. An AI could easy out explain your x complains cause there long long dead now.
I now have the words to describe what I was saying. If an applicatiuon has access to sockets, they likely also(it would be impossible to not) have access to e-poll. Access to e-poll exposes a ULPE. None of the proposed Wayland security “features” LAYER atop e-poll or root access, so they are all trivially defeated at the time weeks ago where this was discussed.
I’m not saying a kernel free of ULPEs is impossible, I’m saying anyone who needs this as a precondition to secure their system also owns a Bridge in Brooklyn. At this time it’s unreasonable to assume an application with access to sockets is also not root.
Note that web apps and a lot of other things don’t have socket access and also “benefit” from not being root, so it’s not like this feature of Linux doesn’t have it’s place.
… you do realize that any Linux process has access to epoll, right? With or without sockets.
Read the “Note!”
I don’t get it. I assume you’re referring to CVE-2026-46242. Just because there was a use after free bug in the kernel, doesn’t mean all other security is meaningless.
Did I say anything /close/ to that. What I said was the more that likely existence of kernel ULPEs makes securing past socket level access meaningless. It’s my understanding that every proposed Wayland/portals security concept assumes socket access. When you appropriately add root to the threat’s access list, AFAIK the proposals are all void.
So, I want to address this comment (Chesterton’s Fence) and then deal with the many unmentioned elephants in the room.
Linux developers have already decided how they’re going to deal with the Chesterton’s Fence problem: drop support for all old hardware. This is a common technique used by large corporate entities when they want to push a new feature set without dealing with legacy code. Tell everyone “you can’t use it anymore, so BUY the upgrade.” And that “buy” part is important: Linux, Rust, Wayland, et al are overwhelmingly funded by large hardware and software manufacturers who financially benefit if you are forced to upgrade.
Which leads us to why X development was killed. As many people have pointed out in this thread, X is very old. But you know what? Wayland also very old.
Age is unimportant in software: it can be re-written as many times as is necessary to bring it up to modern standards. FreeDesktop made the decision to kill X, going so far as to remove the XLibre dev’s changes, thus re-opening old bugs which had already been fixed.
If your truthful and true motivation is to kill the product due to it being unmaintainable, why would you deliberately block someone who DOES want to maintain it? For free, no less.
Well, simple again: money.
That’s not to say the transition is pointless. Wayland does fix some architectural problems with X. For example, the oft-mentioned keylogging issue. The directory which deals with sockets was moved and protected under Wayland so that apps can only access windows they should have permission to access.
But… Here’s a question. If you’re going to break support for every single X app anyway, why not just make that same change on X? Why not re-write the sockets subsystem to function more or less in a manner similar to Wayland?
Well, that’s because of the differing client-server models of the two protocols. Unlike what’s often stated online, Wayland retains the client-server divide of X, it just inverts which component has control over compositing. Under X, the client and/or compositor have control, whereas under Wayland, the protocol itself takes ultimate control. This is what’s often said to give Wayland all those nice benefits, such as reduced latency/screen tearing, better maintainability, and better security.
Let’s address each of those claims in order. Each section will have a TL;DR at the bottom.
Latency:
A recent benchmark found X has less latency except under some conditions. I’m not allowed to post links apparently, so look up “Measuring input latency on Linux: X11 vs Wayland, VRR, and DXVK.”
This makes perfect sense. X, for all its conceptual overhead, is not taking full control of the compositing process. Apps can choose which parts of the suite to include or ignore, thus dropping any code they don’t explicitly use from their compositing pipeline.
This is similar to using a sandboxing app like Flatpak containing a vanilla browser versus Chrome/Firefox with their per-tab sandbox built-in. Yes, the two-app solution has more technical overhead, but if you’re only ever going to use the browser to view local HTML files, why in the world would you even need a sandbox? That entire architecture is useless and simply bloats your Chrome tabs to 2+ gigabytes for zero benefit to your use case.
Even if you do need the sandbox, an external sandbox app could better manage memory and processor usage by virtue of the two apps needing to communicate coherently.
You see, if an app simply “does” a thing, the code which does this thing can be spaghetti. Nobody will ever notice a massive memory leak or repeated access faults, because you just cover it up with more spaghetti and move on, ignoring or deleting any bug reports to the contrary since you’ve already “patched it.”
However, if two apps must communicate, this coding modality becomes a consistent problem that pops up over and over. Downstream users of your app might even code a patch that fixes your spaghetti and send it upstream.
TL;DR: Wayland’s latency isn’t better, and even if it was, Wayland’s design philosophy quite literally discards one of the main reasons why Linux is open source. By taking control away from the app, you also remove many devs’ desire or ability to support an open ecosystem.
Screen Tearing:
This happens because the GPU’s refresh rate isn’t exactly matching your monitor’s refresh rate. What exactly about the X protocol prevents these two hardware components from communicating efficiently?
Well, Intel drivers have had a “TearFree” setting for ages. In short, the setting redirects a good chunk of the timing work away from the compositing manager and to the intel driver. It uses more memory, has more output latency (but does not affect input latency), and reduces frames per second.
Did you notice something, though? I said compositing manager. Yes, the problem was (and is) that some compositing managers aren’t up to snuff. X is just providing the framework upon which these compositing managers function. If the API is no good, somehow, thus necessitating the driver to step in, can’t X just… Patch that one part? It’s literally impossible for a protocol to be so fundamentally flawed from the top down that just that one part of the protocol can’t be changed to better facilitate a downstream component.
This is like, API coding 101. You don’t need throw out an entire API simply because one section thereof has some sort of inefficiency. Unless the physical architecture it’s built upon were to change in some fundamental way… Which I’ll discuss in the security section.
So, let me ask a serious question: why the F*** are we putting this role directly into Wayland? People talk about X being a sprawling mess of code, but here we have Wayland taking control over something a compositing manager should be doing, which necessarily means tighter integration with hardware for no tangible speed or reliability benefits. This one technical change SO dramatically increases the technical debt of the Wayland project that nobody except a large corporate-funded entity could possibly maintain it.
TL;DR: Screen tearing was and is a Linux problem. Wayland “fixed” it by acting like the Borg.
Maintainability:
Speaking of technical debt, one of Wayland’s main changes was to take ultimate control over compositing. Why, though? What benefits does this supposedly bring?
The main benefit is per-window permissions. But what does this actually mean to an end-user? Well, dramatically increased friction between apps, dramatically increased memory usage since apps need far more frameworks, dramatically increased development cycles for new GPU technologies… It goes on and on. You get the idea.
Since every window effectively becomes its own sandboxed instance at the GPU level, Wayland necessarily uses more resources than X. True, the protocol itself can appear slimmer and more efficient at first blush, but that’s because it slams all the technical deficits downstream for app developers to deal with. That’s why you have this sprawling mess of dependencies and frameworks in modern Linux. It’s almost all Wayland’s fault.
But this isn’t enough to explain the actual purpose of Wayland’s sandboxing. On an end-user PC, Linux is oodles more secure than any other OS, so adding additional sandboxing at the app level seems slightly excessive, doesn’t it? If you install malware, you’re still getting infected, because most of Linux’s app packaging regimes are themselves insecure. The whole sandboxing thing goes right out the window. Pun intended.
X could also do this same sandboxing, if the sockets subsystem was re-written to obey filesystem permissions. We could retain all the cross-app communication benefits of X without the global keylogging problem - if we just fixed that one issue.
TL;DR: Wayland’s maintainability is more straightforward, but requires more ongoing work.
Security:
Is security the problem Wayland is trying to solve with its per-window sandboxing? While it wouldn’t be trivial, managing app sandboxing on X beyond just sockets could feasibly be accomplished via the aforementioned filesystem permissions… Instead of by forcing it all into the nebulous Wayland API permissions structure, whatever that structure actually is. It’s like we’ve re-invented the wheel specifically to make it more user-hostile.
Since this is the case, we can reliably determine that Wayland’s true purpose is to enable server-side compositing. That is, you type keystrokes on your PC, they go to a server somewhere, and then your screen sees the result. Like cloud gaming, but for your whole PC. Remember: Wayland takes control over the compositing by removing all ultimate permissions from the app and compositing manager. Control rests with Wayland - and that’s supposedly the main benefit.
What corporation would need to worry about security or finances if none of your apps were on your PC? They could detect you probing their apps for vulnerabilities and ban you from using their services. They could randomly pick a day to discontinue your app contract and extort more cash from your digital wallet. Maybe you wouldn’t even notice when the money goes missing. After all, the server controls what you “see.” But this also means they also won’t need to worry about piracy or competing apps…
Because they can block all competition.
This design philosophy goes back to the increasingly bloated UEFI, which first gained Secure Boot back in the 2000s. The concept was groundbreaking: form a cryptographic boot chain from the hardware up to the OS, thus ensuring a trusted app environment.
In practice, though, the private keys defining this secure boot chain remain controlled by the hardware manufacturers to this very day. Which means malware can issue itself a public key, take control over your hardware, download a new UEFI package, and now your motherboard is permanently infected. There’s nothing you can do because now the malware controls the secure boot chain. You can replace the infected chip, but congratulations, now all your encrypted data is gone. The hardware manufacturer can also invalidate the malware’s certificate, but do you think the malware will let your PC check a revocation list? Hah!
There is one way to fix this without giving end users control over the private key, however:
A locked boot loader.
Why does nobody in open source seem to see this blatant trojan horse? We already have an entire ecosystem of mobile devices where only “approved” devices and “approved” OSes can operate “approved” apps via “approved” development kits.
Do you really f*cking think they’re not going to lock out unapproved Linux distros from PCs, too? The T2 chip is Apple’s prototype of a locked PC bootloader, and the TPM chip is Microsoft’s “final solution” to the problem of user choice and user freedom.
This isn’t some conspiracy theory. They’re ALREADY doing this. It’s literally in front of you.
Which get us back to Wayland’s sandboxing: to form a secure execution chain which only approved malware can exploit. True, Wayland also allows for more secure virtualization and multi-host systems, but if that were the main purpose, Wayland’s lead developer would not have any reason to deliberately kill X development, now would they? Such security could feasibly be implemented under X without the overbearing per-window control that is a hallmark (and touted feature) of the Wayland protocol.
As mentioned above, Wayland is more secure than X because it virtualizes apps. It’s also FAR less secure due to the manner in which it performs said virtualization. X is a unilaterally superior platform upon which to build app virtualization, except that there’s too much technical debt to reliably build an iron cage from which non-approved app developers can never escape.
No, criminals won’t be as easily able to keylog your PC with modern Wayland vs modern X, but if some nation wants to determine who is Jewish and murder them all, a digital Judenstern becomes a trivial thing to implement under Wayland. Not so under X.
TL;DR: Security for thee, but not for me.
In summation:
X is better at enabling compositing freedom and assisting with app development.
Wayland is better at implementing classical National Socialism and mass murder.
I’m not sure I follow most of this. I will say it is a huge benefit to be able to restart the window manager without tearing down the whole framebuffer and closing all the connected clients. There was an issue where Gnome’s Mutter did not have any replacement for the restart feature, this was useful to upgrade Gnome Extensions. Last time I used Gnome Wayland it was a pain-point that I needed to exit every application just to reload the Extensions.
There were underlying issues with one BeOS demo showing simultaneous videoplayback of 4+ sources on a single core CPU? My teenage self is shocked 
Wayland proponents often list all the supposed technical benefits of Wayland while X proponents list the use cases they have where it doesn’t work they don’t like how some feature functions. This is because most users either don’t know enough to contest the group who developed both protocols (FreeDesktop) or they’re under corporate contract to not speak out. The purpose of my comment is to upend that paradigm by exposing all the logical and technical faults in the design of the protocols respectively and then explain why Wayland is not a technical project, as touted by FreeDesktop, but a corporate killswitch.
Possibly a literal human-killswitch project, if we let them continue to force market share via dependency bloat. All of their claims of supposed technical superiority are at best dubious while the working group members’ actual behaviors (deliberately destroying competition, mass developer purge campaigns, deplatforming and defamation of critical news coverage) suggests the opposite: that Wayland is not superior technically, but it does serve a specific ideological purpose. That purpose being National Socialism.
Therefore, the unnaturally hard pushes for Wayland (also Secure Boot, systemd, MIT licensing, and Rust/uutils by extension), etc. appears to be for the primary purpose of enabling mass murder. Look at the first real feature implemented with this new framework: age verification. Once they have your ID tied to your PC, they’ll be able to “turn off” your right to live in the same way China controlled and killed thousands during COVID with vaccine passports. This isn’t hypothetical either; there was a case where China literally welded a building’s exits shut and the building was burned with several hundred people still inside.
So, I want to repeat myself yet again: all of this based entirely on the behavior of hardware and software manufacturers for the last 20 years, along with those they collaborate with. That now includes the free software foundations they fund. I’m only saying it now because these corporations have begun openly funding/supporting antisimetic politicians and policies. Such as, Google’s algorithmic support for pro-terror muslims on Google, AdSense, and YouTube, plus their consistent censoring of other religions, or Microsoft’s implicit support for their “worker intifada” (intifada to them meant “murder all jews”) by not firing all employees involved. This is hardly every instance; there’s too many for me to list.
Don’t ask an AI, though: they’ll tell you everything is fine, because they’re written by the same companies who support this mass murder movement.
I’ve not spoken up much about it until now. In the past, everyone would call me a conspiracy theorist - even when, in one case, I was proven correct the very next day. The person in question apologized for their words, then a week later called me “crazy.” This is the sick world we live in, so I’ve had to wait until people started dying before speaking up again. Now that people ARE dying, maybe more people will start listening?
Did this find it’s way to the wrong thread? I guess it’s sorta about what the topic here is, but I can’t place it’s meaning.
You sound like an LLM, not a criticism just an observation. “This is because” I think the cause here is just human nature or a product of basic logic/debate. Right, the people with the technical specs/docs are all suits under contract. There were some people under NDA, but my assumption is they have all been hired. I wouldn’t say that everyone else is stuck in the dark. The functional differences are all related to Linux IPC, so we have all the tools to migrate a Wayland Compositor into an X11 Server… That is Xlibre can copy anything it doesn’t have under the guise of needing it to write a Wayland Compositor.
I’m not sure there is anything more to comment on, I’ve already rejected the idea of bringing anything not germane into the conversation. Though yes, this is an example of Embrace Extend Extinguish.
Right, the people with the technical specs/docs are all suits under contract. There were some people under NDA,
Being employed, period, means you can’t speak out because they’ll fire and harass you. It has nothing to do with NDAs. You changed the subject here.
You sound like an LLM, not a criticism just an observation.
Dismissing my character, not the merits or substance of my words.
That is Xlibre can copy anything it doesn’t have under the guise of needing it to write a Wayland Compositor.
I already detailed why it cannot under the maintainability section. Major red flag: you didn’t read my comment at all, did you?
I’ve already rejected the idea of bringing anything not germane into the conversation.
So, you don’t care about the politics or the technical merits. Just to be perfectly clear, are you saying you want to protect and encourage fascism and related technical policies?
Yeah, normally a . means the end of one idea and the start of another. You don’t take criticism well, I take it. And then labeling a comment as not criticism does nothing, I see.
Yeah, I didn’t understand most of that. In both systems, for most clients under X11 and all clients under the other, Compositing is completely controlled on the other side of the Client/Server IPC. There is nothing preventing a Wayland Server from implementing Compositing the same way X11 does, just use fork() and IPC instead of System or Soft Threads. The setup could even entail the Compositor connecting as a Wayland Client and then using a protocol extention. The reverse is also true, it wouldn’t be impossible to write a Xorg Module that take over Compositing and Window Management. In both Protocols it’s impossible for Clients to tell how many processes make up the architecture behind the Socket.
What part of I only care about the Technical Merits means I don’t care about the Technical Merits? Did you drop out of Logic 101.
Criticism? You attacked me personally. I don’t care if you tell me it’s not meant as an attack when you literally do the thing.
There is nothing preventing a Wayland Server from…
Making me a sandwich. But that’s not what it’s implemented to do at present, so there’s no point talking about it from that perspective. I brought up how X11 could’ve been re-written (exactly as you just did) to point out that there was no technical reason to make this complete overhaul of the rest of the client/server model in a way which systematically locks out user choice. But that is irrelevant for today, because that’s 15 years of development work already behind us.
What part of I only care about the Technical Merits means I don’t care about the Technical Merits?
Oh, I don’t know, maybe the part where you repeatedly ignore the technical merits in favor of
Did you drop out of Logic 101.
personal attacks? That’s why I asked if your goal was to support fascism. Is it?
I want to point out, all you have to do is say “no” and you haven’t done that.
Sorry we couldn’t find common ground, our views seem aligned the difference is in the attribution. FDO may have shadowbanned me, Is Xlibre really that bad? - #313 by cheako for asking questions about vrr for HDMI only monitors. Making sure you're not a bot!
And now you’ve fallen into the trap. But I’m not going to keep pressing you on that point; I know why you’re not disavowing fascism. Because it’s an absurd thing to claim in the first place. However, not disavowing it every time it comes up when you have multiple multimillion dollar organizations questioning your alliegences - it starts to look a lot like guilt. That’s how they’re able to sway the social media machine to attack at their whim.
I’m not FDO, so my claims of you being fascist won’t go that far. Nor would I want them to.
However, do you remember the Nazis’ famous propaganda technique?
“The English follow the principle that when one lies, one should lie big, and stick to it. They keep up their lies, even at the risk of looking ridiculous.“ -Joseph Goebbels
This is FDO’s basic playbook; they did it hundreds of times over to Metux, the lead developer of XLibre. FDO not only behaves fascistically with the software they put out, but in the techniques they use to silence everyone who disagrees with them. Their entire ideological behavior runs in lockstep with national socialism.
So, you saying “I disagree” - well, you can deliberately choose to be wrong. I can’t force you to see reason. But if you’re going to be wrong anyway, you should at least focus on the technical problems I raised instead of changing the subject and attacking me over and over.
I’m reeeeeaaaly struggling keeping myself from posting a reaction gif to this “conversation”…