> The author of this blog works for Red Hat though
The author of this blog has been working on critical pieces of Xorg infrastructure for a long time, he only gets paid by Red Hat.
Framing it like him (and many of the other people that do the actual work) have no agency, and that his explanation is just toeing some sort of corporate line is such a lazy critique.
I was going to say "it means a whole new class of compatibility issues with software you've been using with no problems for the last 20 years". But you pretty much covered it.
Perhaps - but Xorg had no business being the display server for so long for how objectively nonsense the code is. It’s time to pay back that billion-dollar technical debt. The technical debt of Xorg is almost like if Linux never supported anything but x86 and used emulators for all other hardware.
Example: How many people here would cringe at the thought of a WordPress site with a bunch of plugins? Xorg is objectively worse code, and has over 30 plugins on a normal desktop.
> [... WordPress bad ...] Xorg [...] has over 30 plugins on a normal desktop.
This isn't a great argument. Python has "plugins" and just calls them "C extensions". Every time someone uses Numpy, Matplotlib, Pandas, or even just "math" - that's a plugin.
Gimp has plugins. Emacs has plugins. VLC has plugins.
> The technical debt of Xorg is almost like if Linux never supported anything but x86 and used emulators for all other hardware.
It's not like that at all.
I can believe that WordPress is a bunch of gross PHP, and I can believe that nobody wants to maintain the C in Xorg, but that's about as far as your analogy holds.
And besides, Wayland is just going to package all that stuff you hate into XWayland. It's not like anyone is cleaning up the interface and removing the notion of plugins.
"Xorg has no business being the display server" in much the same way as sysvinit had no business being an init system: Sure, they're both old and clunky, but they both also work, and allow me to get stuff done.
Nobody is saying that Xorg isn't old and crap, or that it shouldn't be replaced: I remember being pretty excited when I first heard about weyland - it sounded like it was going to solve a bunch of problems.
I was excited, so I jumped on my triceratops and went over to see my friend Ug. I didn't hang out in Ug's cave very often because it was kind of messy and his sabretooth wasn't very friendly, but I'd read a thing about weyland and I was all excited.
Ug was less excited than I, he pointed out that X has been a thing for a long time, and there will be a billion assumptions about its architecture in all kinds of weird places, and switching to an entirely new thing that isn't really backwards compatible will likely cause a bunch of issues, and that there's some software out there that's targeting X, unmaintained, and still in use by people, and a bunch of this software will break. And that these wayland people will have to do a lot of thinking about all kinds of weird edge cases, like remote X sessions, multi-window applications, screensavers / lockers, windows with transparency or non-rectangular shapes, etc etc etc. He pointed out that even if you do spend a lot of time being super diligent about something like this, such a large fundamental change is still very likely to cause a bunch of weird edge cases in the real world that will break people's workflow.
My concern is more around timelines and the issues it will cause when it is forced on people, not "this is bad/unnecessary". I don't think I've ever seen anyone make that argument about X.
Some of us just want to have working systems, get stuff done, and keep using the great software we've been using for decades without problems.
I mostly just hope redhat have learned from the experiences we had with things like pulseaudio, and that they've checked whether the replacement actually works in real-world scenarios before forcing it on people this time.
Sure, but by that logic, there's nothing wrong with still using cooperative multitasking.
Eventually, everyone involved knows, it's time. And even Linux has had some major rewrites in multiple areas - don't pretend like Linux hasn't changed immensely since 1.0. Xorg though... hasn't that much...
You can use `xdpyinfo` yourself to see all the extensions you have loaded.
As for the quality of the code, all you need to do is read the discussions by Xorg maintainers about the quality of Xorg's code back when Wayland was beginning development. You will not find even one optimistic take. There was even an early attempt to fork Xorg and fix it (called X12), but it was quickly abandoned as unfixable.
Note, also, that these discussions began in 2010. More than half a decade before Flatpak or Snap. Work had begun to replace the mess before we were even talking about sandboxing.
> Xorg is objectively worse code, and has over 30 plugins on a normal desktop.
You do realize that Xorg has "plugins" since Redhat (freedesktop) took control of it. In the past, xterm, twm, etc, were part of the X server distribution.
They split it "to make maintenance easier". What they actually achived was a running target. Why is my new X server no longer loading my old fonts ?
I saw on mastodon someone is already doing that, looking at a fork. That person is also a a very good programmer. I hope they get the support they need, I would help a bit financially should the need arise.
This transition to Wayland made me appreciate the old saying "it's all over bar the screaming".
It's definitely over. No one is working on X server any more. As hardware evolves, Xorg going to break more and more. No distro (RedHat included) could avoid Wayland and expect to remain relevant. (The X client side will work for decades to come of course because of XWayland.)
Despite the inevitability of it, the screams of pain are just getting louder at time point. Every HN thread is swamped with them.
It seems to be mainly an open source affliction. Every time Firefox makes a a minor change you see the same thing, but Chrome has to do something major break UBlock Origin to get similar levels of screaming.
I really don't get the security angle. If I'm already running arbitrary code then it doesn't matter that Wayland is more "secure" than X11. It's just silly security theater, because there are plenty of other ways you can access whatever other applications are doing and interfere with them, even if the display server doesn't allow you to do that directly.
The only security benefit I see is if you're running sandboxed applications and you want to connect them to your display server, then sure, there is a benefit here, but how many people are running untrusted GUI apps in a sandbox on a desktop?
Even if you are sandboxing, you can do that with X. Just put the sandboxed app into a nested X server. Some sandboxing apps like firejail make it trivial to do this using xpra as the nested X server.
I wish Wayland had been more ambitious. Without a standard shared server that window managers can run on without implementing their own compositor, it is just duplication of effort, and a mess of incompatible ways of doing things; I suspect this was intentional to create a higher bar for "fragmentation", but what a mess. It will be even worse when Wayland on non-linux becomes a thing, since most WM/DEs with Wayland support are using Linux specific d-bus to work-around Wayland limitations.
There are real security issues with X. For example, there's not really much of a permissions system on the X protocol, which is why X tends to be configured to either deny everything but localhost or not listen on TCP at all by default.
When you allow a host to use your X display, you allow that host a crazy level of control over your system. IIUC you can do all kinds of nasty stuff with it, like getting info about other applications/windows and i think even arbitrary drawing on the screen (i.e over those other windows). You can also do stuff like snoop mouse movement and keyboard presses (i.e keylogger), and not just in your own application. As I understand, it's really pretty nasty and insecure to allow an untrusted remote machine to use your X server. It's not a good situation.
Weyland's solution does, admittedly, close this class of security issues very effectively - by just not being a remote protocol at all.
> The only security benefit I see is if you're running sandboxed applications and you want to connect them to your display server
This is a mundane and common way of doing things, now that Flatpak is common and major sandboxing bugs in most popular packages have been fixed.
Also, all major web browsers already come with their own built-in sandbox for web content, and a great deal of complexity is spent outside of this sandbox making sure the process can actually print rendered page content to the Xorg screen without also being able to take over the entire Xorg server. For many years, Firefox ignored the problem and had a sandbox that doesn't prevent an RCE from keylogging Xorg. This was only fixed in Firefox 99, but like Chrome, this implementation had to be overly complex to support Xorg, so it risks introducing new attack surface. This complexity can be eliminated by Wayland and Pipewire.
> how many people are running untrusted GUI apps in a sandbox on a desktop?
1. More and more every day - and that should be our goal. More sandboxed apps, not less. Otherwise, Linux on the desktop will never be as secure as a Mac (which has, objectively, the best desktop app permission systems available).
2. Xorg only does windows, with no sense of importance. What's the problem with that? For a long time, this meant that the Lock Screen was literally just a window, drawn on top of all your other windows. If anything crashed your Lock Screen, system was open for business. This has been heavily hacked and worked around, but it's still a potential threat. Some of the more "lightweight" distributions still use software that is vulnerable to this; because we've sure patched the hell out of that Lock Screen software to please not crash.
3. Keyloggers. More and more apps are using Electron - and shipping JavaScript and other code right to your device with a potentially obsolete browser engine. The last thing you want is some JavaScript shipped to your out-of-date Electron app that keylogs what you are doing on your entire desktop; simply because the developer misconfigured CORS or didn't use a pinned certificate or there was a middleman on your network or numerous other possibilities. On Xorg, that's completely theoretically possible. Combined with issue #2, where your Lock Screen is quite possibly just another window to be keylogged, and you start to see how things can escalate quickly.
4. Xorg is never just Xorg. Xorg, by itself, is almost unusable in 2023. You need extensions - over 30 of them built on top of Xorg, to result in a functional desktop. Sounds super secure. Even worse, Xorg has a mandate to never break userspace - so once an extension is shipped, it's there forever. As a result, many of these extensions aren't even used or tested, which is why Linux has, if I recall correctly, 4 Xorg extensions to handle a mouse with only one of them being used. There's also multiple abandoned joystick extensions. Again, sounds secure.
These are not the attributes, or traits, of a secure system that we should be proud of. It's embarrassing and the sign of hobbyist work.
There's also other issues at play:
1. Xorg is so obscenely complicated, and the code so bad, that the developers have openly remarked there are probably less than a dozen people who understand Xorg and can actually work on it. That doesn't sound like a very good long term plan.
2. Xorg is both the protocol and the implementation, which isn't how you want to do things. Normally, you want a standardized protocol; with multiple implementations of the protocol, so that the protocol can be easily adapted for the use case available. We did this with the internet, where HTTP is the protocol, and the various web browsers are the implementation. Imagine if Netscape was the protocol and the implementation combined. That sucks. With Wayland, Wayland is the protocol, but Mutter or KWin or others are the implementations. Some implementations are better than others, but that's OK. If you want to one day rewrite your compositor to take Wayland instructions and execute them in Rust, you "easily" can. On Xorg, you're reverse-engineering and mimicking behavior bug-for-bug the full stack downward.
3. There are upcoming technologies that may be exceedingly difficult, if not impossible, to build into Xorg. Like good 144hz support, or HDR. You might not care about them yet - but trying to shoehorn them into Xorg is a bridge too far.
> Secondly, Xorg only does windows, with no sense of importance. What's the problem with that? For a long time, this meant that the Lock Screen was literally just a window, drawn on top of all your other windows. If anything crashed your Lock Screen, system was open for business. This has been heavily hacked and worked around, but it's still a potential threat. Some of the more "lightweight" distributions still use software that is vulnerable to this; because we've sure patched the hell out of that Lock Screen software to please not crash.
I learned this years ago, although not in such detail, and it just blew my mind. You can even see it. I wake my laptop from sleep, my screen flickers and I see my desktop, then the lock screen paints over the top like a flasher closing his coat. It makes me cringe.
Switching to Wayland lasts about 10 minutes though before I find some breakage that prevents me from using it.
[..]"Even worse, Xorg has a mandate to never break userspace"[..]
Xorg is a major fundamental part of the "desktop" part of "Desktop Operating System
The fact that you even listed it as an "issue" with Xorg immediately disqualifies you from making any further statements on the issue
If you think that it's acceptable for a minor software update to break down potentially hundreds of not thousands of office workstations then you are quite frankly insane
By itself, it's not a bad thing. When we are shipping extensions for two-button mice in C with no automated testing, fuzzing, or security review, and no mouse has used those extensions in decades, and that until recently ran as root, that's a problem.
1. There were many very good reasons to get rid of X.
2. But Wayland made some very dubious choices, like 'multiple implementations' which will lead to very difficult to diagnose bugs. I strongly suspect the motivation was economical rather than technical.
3. Or the security model without adequate protocol support. Where the extensions aren't always compatible (see 2).
Okay, fair enough, you do have a point, even though practically right now it's mostly only theoretical considering how little sandboxing modern Linux does by default. I agree that we need more sandboxing, and then getting rid of X11 makes sense from a security perspective.
Not me, I use something far simpler when not on Linux, pledge and unveil. Linux snadboxing uses far more resources and diskspace that what OpenBSD is doing.
I wish OpenBSD had better video hardware support. That means I wish a specific vendor would stop being a d**k and open up their GPU.
I genuinely don't understand why many Wayland proponents are so eager to destroy the experience of millions of Linux users who currently depend on Xorg. It's very selfish and also decremental for the popularity of Wayland as it creates unnecessary conflict.
Yes, to me it means "avoid all Red Hat" type distros at all cost. But I already do that due to another RHEL product. But I consider Xorg removal a worse idea than that other product.
Just "terrible for desktop". I don't have any data to back it up so take it with a grain of salt, but I suspect for desktop Linux use, Ubuntu is far more prevalent than RHEL, and probably hacker types will otherwise be using Arch. So this change probably really only affects people that should have switched their desktop distro a long time ago.
For server use, where this isn't an issue at all for most use cases, putting aside personal preferences, RHEL is likely not a terrible choice, especially on AWS.
The author of this blog has been working on critical pieces of Xorg infrastructure for a long time, he only gets paid by Red Hat.
Framing it like him (and many of the other people that do the actual work) have no agency, and that his explanation is just toeing some sort of corporate line is such a lazy critique.