Xorg being removed. What does this mean?
who-t.blogspot.com
who-t.blogspot.com
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.
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.
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...
Heck, there's nothing wrong using anything anywhere, it's a question of fulfilling the requirements.
Meanwhile, you in another comment:
> You can use `xdpyinfo` yourself to see all the extensions you have loaded.
So, which one is it? Is it unchanging or is it evolved through several extensions?
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.
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.
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 ?
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.
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?
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.
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.
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.
Ugh, dammit, I'm real sad to hear that - I would have hoped it'd be more usable than that at this point - they've been working on it for so long!
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.
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
Yep.
PSA: If you think not breaking user space is an "issue", please don't ever do anything but non-critical web development.
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).
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.
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.
Anyone that disagrees with the Xorg's developers decision, is welcomed to jump in.
Most actual development was done by hundreds of people in the early 1980s by the Massachusetts Institute of Technology
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.
But this is what he is doing.
I guess the problem is not that Redhat is doing what it is doing. The problem is that other are blindly following it.
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.
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.
Getting there but they need a bit of help if anyone is looking to contribute to an accessibility project.
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.
barrier has been unmaintained for a long time.
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
The aforementioned waynergy is a synergy client with explicit support for wlroots-based compositors like swaym.
> 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.
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.
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.
Operating systems can run on VMs or containers. When comething runs on top of those OSs, they are not running on bare metal.
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).
I'll have to say though, I find that particular definition of bare metal quite strange.
"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.
It's true that you don't have to, but you certainly can.
In fact, the first implementation of containers in Linux - Linux Containers, or LXC - works exactly that way.
This may or may not be as great a distinction as you might want in order to consider it bare metal vs. not. I'll leave that up to you.
├── hw
│ ├── kdrive
│ ├── vfb
│ ├── xfree86 <- this one is Xorg
│ ├── xnest
│ ├── xquartz
│ ├── xwayland
│ └── xwin
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!)
So this may not be a big deal
You're right, but Red Hat led Debian/Ubuntu over the systemd cliff.
(Because, you know, a gigantic ball of binary code is better than runit/s6/sysv/etc. /s)
I'm happy the gigantic ball of ill-maintained shell scripts from the last century is gone from my systems.
Sv, smf, s6, openrc, runit, dinit, epoch, BSD, ...
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.
If this is your idea of an argument as to why this move is bad, then you have no leg to stand on.
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++).
I like the X11 protocol for things like forwarding over ssh but xorg itself has given me so many problems throughout my entire history of using Linux.
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)