> 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.
Mozilla took away native ALSA support and forced everyone to use PulseAudio, fortunately there are emulation libraries you can install to work around that.
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.
As a light Talon+Cursorless user, I'd be happy with a very small subset of these features. I'm guessing all you really need for Cursorless to work is 02 (Get PID associated with a given window) and 18 (Emulate pressing keyboard keys).
And emulating keys could be done completely outside of wayland, using uinput instead.
How can we contribute? When I first started using Cursorless I wanted to try porting the keyboard emulation to uinput before I realized Talon was closed source.
As if not having new features added for 2 years makes it stop working? barrier is perfectly fine on normal linux desktop installs. I actually use synergy 1.x personally which has been "unmaintained" for much, much longer. Except synergy 1.x will compile and run on anything from windows 98 to ubuntu 10.04 to latest arch. You can't get a waynergy or inputleap to compile on an OS more than 3 years old. And even then, as you say, it's crapshoot if the particular wayland you use will have libei; many like sway are actively hostile to it and never will: https://github.com/swaywm/wlroots/issues/2378
An unmaintained network service written in an unsafe language is generally speaking unsafe to use, and a great way to get exposed to RCEs. You do you, but running such code is a Very Bad Idea™ and absolutely not okay on a normal desktop install.
The aforementioned waynergy is a synergy client with explicit support for wlroots-based compositors like swaym.
Vague insinuations without support, most of which are effectively mitigated by running synergy or barrier over an ssh tunnel. What you mean by "unsafe language"?
> waynergy is a synergy client
Yes, a client, but you can't actually be a synergy server with waynergy. And input-leap support to work with a subset of the waylands depends on libei.
"Vague insinuations"? There's nothing vague about it. An unmaintained network server is not safe to run, period. That's not a controversial statement, just common sense from observing how fast we go through CVE's.
Can you take steps to reduce risk? Sure, but managing to safely detonate a bomb does not make bomb explosions safe. Suggesting that such unsafe practices can or should be part of a normal desktop setup as you did is definitely not sound.
>An unmaintained network server is not safe to run, period.
Period, huh?
Could you please advise, in excruciating detail, exactly why is it not safe to run an unmaintained network server in an environment with no access to any untrusted network? How is is a security risk to run an old version of synergy between two machines which can only talk to each other and don't even have any physical link to any other machine? Which aspect of being old or unmaintained or "written in an unsafe language" allows remote code execution over an airgap? Please be sure to provide links and references, I've not heard of this trick before, I'll be pretty impressed.
Yeah, they're "vague insinuations".
There are many possible mitigations to the old "it's unmaintained, therefore insecure" security-theatre chestnut - another comment in this thread specifically mentions that most security issues are mitigated by running over an SSH tunnel. There are more secure options like routing all networking via a VPN, or as mentioned above simply not being accessible from an untrusted network.
You don't know the details of everybody's requirements or environment, so you're not in a position to dictate what security precautions or risks are reasonable for them to take or ignore in their particular circumstances.
Some people, for example, need to be able to use or access machines running old operating systems. These are situations that do actually exist in the real world, often due to reasons related to them being in the real world, and very often outside the control of the people trying to get stuff done.
There are lots of valid reasons why people want to run old software, too.
A normal desktop setup runs the software you expect it to run, and can connect to the machine you were able to connect to yesterday, to continue to get stuff done.
A "normal" desktop doesn't suddenly shit the bed refusing to run software which is perfectly fine to run in your particular set of circumstances, and it certainly doesn't insist on overriding the judgement of the experienced user who has evaluated the security implications, if any, and decided to proceed anyway, to get stuff done.
Compare it to the other servers in the same `hw` directory:
├── hw
│ ├── kdrive
│ ├── vfb
│ ├── xfree86 <- this one is Xorg
│ ├── xnest
│ ├── xquartz
│ ├── xwayland
│ └── xwin
Xorg/xfree86 is the one that renders to your display hardware (metal), compared to `vfb` which renders to the Linux Virtual FrameBuffer API, `xnest` which renders to another X server, `xquartz` which renders to Apple's "quartz" display system, `xwayland` which renders to a wayland server, and xwin which renders to Win32.
And, uh `kdrive`, which renders to... um... something or other.
Edit: Also, while Linux now has Atomic ModeSetting and the Direct Rendering Manager APIs, for a lot of Xorg/Xfree86's history it didn't, and the X server did a lot more direct manipulation of the display hardware than it does now. Switching virtual consoles between X consoles and Linux terminal consoles used to be a weird dance between Xorg in userspace and the kernel to make sure that the hardware handoff between them didn't mess up. This dance took about a second to complete (which is forever in CPU time) rather than being the instantaneous sort of switch it is now. But even now, with DRM and the other stuff, Xorg still does a lot of talking directly to the hardware.
What's really weird about reading this is that I can hear, in the back of my mind, the sound my CRT makes while doing this switch. But I have no memory of ever switching from X -> virtual console since LCDs were a thing. I guess... that's when X stopped crashing routinely? Weird stuff!
(Also, am I crazy or is there also a smell associated with this operation? I swear I remember something like that. When the mode switches, the monitor degausses itself, and then there is a faint smell of ozone? Computers used to be weird!)
Means that the X server directly communicates with the display driver to do the low-level rendering. Compare that with Xwayland, in which the server is an application talking to wayland or Xephyr which renders to a frame buffer in another X.
Running on bare metal usually means not in a VM or container. It means they talk to the hardware in the most direct way. Sure, it takes drivers, kernel, etc but that's about it.
Operating systems can run on VMs or containers. When comething runs on top of those OSs, they are not running on bare metal.
A container is simply a process with isolated namespaces — an OS does not run within them, and any hardware access they have is mediated by the OS in the same way as any other process. This being from Linux’s POV anyway: once you’re running Docker on other OS’s, there’s a Linux VM in the middle.
Sure, the average container in fact brings along an entire OS distribution like Alpine or Ubuntu or whatnot, but there’s still no extra layers added (save perhaps for the filesystem). Then again, running an OS at all is not “bare metal” by some definitions… it’s all various amounts of alloys I suppose.
I think this part of the discussion is just a disagreement as to what constitutes an OS, and whether running a process with a different rootfs entails "running a different OS".
This is not what whot meant. He meant "bare metal" in that Xorg is the display server talking to your input (evdev) and output devices (drm/kms), rather than running as a rootful or rootless child of another display server as is the case with Xwayland or Xephyr.
A "bare metal" display server can run in VMs, or even in containers (although the latter is a little pointless as the device access violates sandbox safety).
It's also a bit of a weird thing to describe. Native? Master? Normal?
"Nested" is more or less the de-facto term in Wayland-land for the child scenario (pretty much all Wayland display servers natively support a rootful child mode either as real feature or for testing/debugging, some even under X), but there isn't really a good word for the normal case.
I never had any horse in systemd/init.d and wasn't too familiar with the issue until I watched this presentation. systemd seems reasonable enough after considering it.
Alpine & Gentoo are on OpenRC, Void is on runit, the BSDs have always had their own init, everything else I can think of is either on systemd, or hardly significant.
I mean, sysvinit was horrible, and systemd is horrible in very different ways, just wondering who and why is holding on.
Systemd is fine. I've used it for years, never once had an issue. And the "Unix philosophy" is completely overrated, it provides no value. So I don't care in the least if it's a gigantic ball of code.
If this is your idea of an argument as to why this move is bad, then you have no leg to stand on.
Yeah, these giant balls of biary code like GNU & Systemd are terrible. There should be a new project & legal foundation for every tool, organizations need to follow the UNIX philosophy.
The systemd transition was rocky early on but we're way past that and it works great. I say this having dealt with systemd in production since the early days and IMO there's no reason for continuing to hate on it.
It means the steam client has finally trashed its legacy 32bits code and has finally a native wayland backend (keep Xwayland for old games).
Ofc, it would have a wayland->x11 fallback (force-able with a command line opition), like with a vulkan->GL->GPU (force-able with a command line option).
It means too I finally have to code my wayland compositor (full dma-buf/vulkan/CPU), probably based on valve one (but in C and/or assembly, not that abomination of c++).
Does anyone actually use an X server on RHEL10? I thought mostly used for servers, and people who wanted a good Linux desktop had switched to a different distro (or, more likely, Mac) a long time ago.
RHEL Workstation is primarily used for graphics workstations to run ports of old SGI-compatible software, and in particle physics laboratories for loading all workstations with a standard set of science, mathematics, and TeX publishing software.
RHEL is also used in automotive applications, such as in-car entertainment systems, but this use case has already standardized on Wayland (it was one of the first things Wayland was widely used for)
Well, xorg-server is 1 package that doesn't depend on much on its own. What you're describing sounds more like bad client dependencies pulling in chunks of a desktop environment.
You don't need to fight anything/anyone. The code is open source, fork and maintain it. You shouldn't have any issue replacing the "broken vanity project by a minor amateur maintainer", right?
This is wrong. For legacy code there is Xwayland and the blog post actually describes it.
I'm using Wayland on Archlinux and despite I run currently no legacy software Xwayland is active:
$ xlsclients
gsd-xsettings
mutter-x11-frames
Therefore Xwayland is running and consuming 164 Megabyte of RSS. Despite I don't run applications depending on X11. I suspect the file /etc/xdg/autostart/org.gnome.SettingsDaemon.XSettings.desktop is the cause:
If I guess it right this should help X11 based applications to get the needed settings. Probably /org/gnome/mutter/experimental-features with autoclose-xwayland is what I want. I assumed that is already the default - wrong assumption. Xwayland remains available for stuff like legacy software (various games from Steam) and doesn't consume resources when not required. I wouldn’t be surprised if legacy games ship in future (ten years or more…) with a built-in Xwayland-Wrapper or something similar.
> Xorg works, has always worked, and will continue to work
Sure, you could say the same about IE6.
> Wayland is a broken vanity project by a minor amateur maintainer
Despite its flaws, Wayland is a widely adopted production-ready project made by Xorg maintainers and nearly everyone else who has been seriously working on the graphics stack on Linux in the past 5 years. There is a good chance that Wayland is running in your car's infotainment system.
And it only works on Linux, that is the issue. Porting to other UN*X is a major pain. There is a lot more to the world than Linux.
Also I am sure Wayland will never be ported to AIX, you know, the UNIX used by many large finance companies. BSDs are having a hard time with it due to Linuxisms.
Some purchased (3rd party) admin items do, they use motif. We have a couple at work. Some people run these using windows app, I showed people how use Linux years ago.
It means your distro is terrible and it is time to switch.
The author of this blog works for Red Hat though, so he won't speak that particular truth.