Hooray! A new release of Xorg is always a good reason to celebrate. Long live the all-singing all-dancing feature-rich network-transparent display system which is still the best (and often only) solution for a lot of common user needs, even 39 years after its creation.
I think Linux (and other unix-like system) would be best off with something like rio on plan9. The API should look like a file-system hierarchy, and API virtualization/access management/input output hooks and mapping could also be file-system-like.
> An XQuartz installation consists of many individual pieces of software which have various licenses. The X.Org software components’ licenses are discussed on the X.Org Foundation Licenses page.[1] The quartz-wm[2] window manager included with the XQuartz distribution uses the Apple Public Source License Version 2.[3]
Redhat stands to lose their defacto control over X after the XLibre fork so they have to stop trying to kill it. Who would have thought that competition would make things better for everyone?
That's a new take: Project with new release 1 day ago declared deprecated!
I've been using Linux for around 2 decades. I am currently running Fedora 43/KDE Plasma ... and wait for it ... Xorg.
Why? Because it works. It works well!
Why don't I use Wayland? Because it breaks everything.
- Screensharing is just wonky and inconsistent across applications. It has gotten better in the last 2 years, but it's still quite wonky. And janky. And flobby. I **could** put effort into fixing this, but it already works in Xorg.
- I have a bunch of Xorg/xdotool scripts bound to hotkeys. Move, resize windows. If AppX is running and the window isn't shown, show it; otherwise, hide it. If AppX and AppY are both running and meta+y is pressed, then tile in a specific way, else do something different. These scripts are either ungodly difficult to rewrite to work in Wayland or just flat-out impossible in the name of "security".
- Easystroke. https://github.com/mmh0000/easystroke . Nothing like that exists on Wayland (that actually works). And I can not live without it after having it for 20 years.
Easystroke is a mouse-gesture program: hold button, draw various lines or shapes, release button. Triggers any action. Like window minimize, execute command
Xorg isn't neglected for "ideological reasons", it's neglected because development is work - and most of the people with knowledge of the problem domain decided they didn't want to work on Xorg anymore, and most of the companies that were paying for it decided they didn't want to pay for it anymore (apart from baseline maintenance, Xwayland and security fixes). And the people who want Xorg support maintained in perpetuity rarely seem interested in maintaining Xorg themselves, at least not properly (see this history of Xlibre introducing bugs and LLM slop).
You are free to spend your own time and resources doing the work, but you don't get to dictate how other people spend theirs.
Modesetting work was done in 2022, but for some reason no one had released a new stable release of the Xserver with this patch included since then. This was one of the reasons Xlibre was created, there was all these improvements to Xorg sitting ready for release but never being released.
Exactly. Just think about how much work it was to move from X to Wayland, how Nvidia didn't want to play ball, how different the architectures are, in a world where ossification is very much a thing. AND STILL there was enough momentum to get all the major players on board. I have never done any X programming but it must have been bad when people would so readily jump ship and put all that work in. Same for systemd.
Wayland was simpler because it was just a compositor. It meant people interested in graphics acceleration could focus on just that, iterating faster without the friction of the rest of the stack. But now that the Wayland ecosystem has to reinvent everything else, it's clearly at least as much work, if not more so. The initial switch moved the tightly knit rendering developers to a better local optimum, at the expense of a worse global optimum.
It forces some kind of modularity. Maybe that is a good thing. We don't have all features of X11 in Wayland but we also have features in Wayland that are missing in X11. I have been on Wayland for a while now and I can't say I am really suffering. There are some tings I'd like improved further but the protocol is evolving all the time. I think we'll get there. Also the decision is already made by the big distros anyways. They seem to be mostly happy.
Wayland is the complete opposite of modular; that's why the compositor has to handle everything. The claimed problem with X11 was it was too modular, easy for different clients to control various aspects of the environment, but perhaps too easy, lacking a security policy framework to limit client access. (Or at least a framework that was fully baked. Wayland put an end to such initiatives.)
The lack of modularity in Wayland has been widening the rift between the desktop environments. It's as-if KDE and GNOME each forked X11 and went their own ways.
Not true. Wayland simply cuts out the middleman. Making the compositor the display server is one of the best things Wayland did. This brings so many advantages, such as true tear-free graphics and lower input latency.
The middle man was there to make sure everyone understood each other. Now simple things like taking a screenshot requires programs to speak multiple different languages.
Again, not true: if you want to take a screenshot in a generic way, you have to go through the XDG portal API, which is generic across all the compositors that support them, i.e. most of them.
The XDG Portal framework is obscenely complex (PipeWire, D-BUS over separate channels, etc), still requires each individual compositor and other components to specifically implement various aspects for things like screen sharing, and there's a ton of broken edges between the myriad interacting components. All-in-all the complete opposite of modular.
And that's the point. X11 provided a framework for all of this. Not perfect, but deliberately extensible. The Wayland alternatives are so much more complicated and brittle, and have to work around the limitations of Wayland. The effort expended by groups like freedesktop.org to architect and standardize new features would have been (and was) so much more productive in the X11 world.
I understand where you're coming from, but there is no turning back at this point. Sure, you could still run dwm on Xorg or Xlibre and pretend Wayland doesn't exist, but the reality is that the vast majority of Linux distributions and desktop environments have already committed to this stack, and application developers are going to target these portals.
There's also talk of D-Bus eventually being replaced with Varlink [0], showing that this whole ecosystem is still very much a moving target. What feels like endless breakage and friction right now is really just the noise of a massive architectural migration in progress. Eventually, the dust will settle, the APIs will stabilize, and the whole stack will become boring, reliable, and really good. That is how I prefer to look at it.
If you want to see things move in a specific direction or address any particular problem, the best path forward is to get involved and participate in the projects that interest you.
> This brings so many advantages, such as true tear-free graphics and lower input latency.
Curiously, people always seem to list the same advantages, and it's a very short list. Fewer (but still non-zero) torn frames are the top of the list pretty much every time, since that was the very first thing its creator listed in his original goals... but that's a pretty small benefit in exchange for breaking entire categories of functionality. Like, it looks smoother when I scroll, but features I rely on heavily every day are forbidden.
As for input latency... that doesn't seem like it was ever a problem. Using X11, I'm able to get 500 to 1000 inputs per second even on a potato PC. That's faster than the frame rate of pretty much any screen, and fast enough even for audio / midi purposes. Reducing input latency from ~1.5ms to ~1.0ms doesn't really matter when the timeslice scheduling has ~6ms of jitter on an average system, a common screen only draws a frame every ~16ms, and many input devices have 50+ ms of their own additional latency.
> if you want to take a screenshot in a generic way, you have to go through the XDG portal API
This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots. Like many things users need, they decided it was someone else's problem, and threw it over the fence for the fragmented ecosystem of downstream projects to solve. So each downstream project came up with their own workarounds for essential features not existing. The solutions had to be built entirely outside of Wayland, and even after years of development, the solutions are still incomplete, unreliable, complex, and full of caveats. It required (and still requires) everyone except Wayland's core devs to write a lot more code for less functionality than they used to get with a couple of simple API calls. They had to architect entire complex infrastructure layers in order to work around a missing feature in the core protocol, since the core devs stubbornly refused to allow it.
Similar situation for input automation and remote control. It's a common thing people need. I use it every day and can't use the notebook at my desk without it... but the Wayland folks refused to solve it, so it had to be done outside of Wayland. For example, one workaround is to give the user direct access to the kernel so they can create fake input devices at a kernel level, and generate the inputs they need, which Wayland then sees as a local physical keyboard or mouse. So... problem solved, from Wayland's point of view. The user gets what they need, sort of, and it's implemented outside of Wayland, so Wayland doesn't have any security issues. But... and this is a big "but"... the solution involves giving users device-level kernel access. Which seems significantly worse than the issue it was originally trying to solve.
> I understand where you're coming from, but there is no turning back at this point.
A position of "sure it has major problems, but it's too late now" is not a position of progress. Much like the situation with pulseaudio being deployed everywhere then replaced with pipewire, it's almost never too late to fix bad software architecture. As you said, this whole ecosystem is still very much a moving target.
The ideal solution would be the creation of a new system which supports the features, protocols, and APIs of the older system(s), in a way which "just works". But that requires a very different mindset from the people behind it. Instead of "not my problem, someone else can deal with it" like the Wayland policy, a proper solution needs people to adopt a "the buck stops here" approach, and take responsibility for making the entire system work. Things like accessibility, network transparency, automation, and legacy support... need to be built in from the ground up, not rejected or treated as an afterthought for someone else to handle.
> Curiously, people always seem to list the same advantages, and it's a very short list.
The things I listed are just the tip of the iceberg. Having studied earlier versions of X like X10, X11, and now Wayland, I could go on and on. What I'm trying to emphasize here is not to look at Wayland through an Xorg lens. I know it's easy to look at Wayland and immediately think it's a rigid protocol that breaks everything, but the reality is that it's a lot more flexible than people realize. Once you understand it, I think the closest thing that comes to mind is "There is no spoon." And just like there is no spoon, there are also no windows, only surfaces, but again, that's only the tip of the iceberg.
If you want an example of what I'm talking about, take a look at projects like p9wl. [0] This is using wlroots to create a proxy between Linux and Plan 9 in order to display windows remotely. Such flexibility is only possible when the protocols are small and composable, which Wayland is.
> As for input latency... that doesn't seem like it was ever a problem.
I never said it's impossible to get acceptable input latency on Xorg. I'm just saying that when your input and graphics go directly through your compositor, the experience is on a completely different level. This is even more true with features like direct scanout, where the compositor steps aside to send graphics directly to the GPU and input directly to the game as it goes fullscreen. It simply makes using your computer so much more pleasant. These input latency issues were exactly what Kristian Høgsberg tried to fix in Xorg, and addressing them was one of the primary motivations behind creating Wayland. [1]
> This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots.
You're thinking through your Xorg lens again. That's understandable, since you're probably used to it. However, to really understand Wayland, you have to look at it through a different lens. Wayland isn't defective, and it's not trying to be Xorg 2. It's a protocol. It doesn't do your laundry, nor does it take screenshots. It's just there to provide the mechanism for sending buffers to your compositor.
You can think of Wayland as thin building blocks to build compositors, just as you can build window managers on X, except this time, the core protocol does one thing and the libraries already exist. Wayland exists because all the infrastructure is already there in the kernel and in libraries.
The screenshot feature is the job of the compositor. Most compositors already have this feature built in. As I mentioned before, XDG portals exist, and interoperability will only keep getting better.
> Similar situation for input automation and remote control.
I agree input automation and remote desktop are still problematic. GNOME and KDE have their own remote desktop solutions, as do most of the others, but I haven't had a need to use them myself. All in all, Wayland really isn't trying to prevent you from doing things, it's just a protocol.
I'm pretty sure all this will be solved eventually, and I understand the frustration of those who need these features. However, I also understand Wayland and compositor developers taking a careful approach here, and it shows.
> A position of "sure it has major problems, but it's too late now" is not a position of progress.
That's not what I intended to say. The intended message was: the core Wayland protocol is set in stone and won't change, but we can build these things that aren't working and make them work. That is already happening every day. Progress has been steady, it's a lot better than it used to be, and it will only keep getting better. Going from Wayland into a whole different windowing system, I don't see that happening, at least not in the next 60+ years, but I definitely see the whole Wayland ecosystem improving.
I don't care about either X, but that guy's name is in this release, and judging purely by the number of commits (since I lack X expertise to judge any other way), he seems to be the top contributor.
Looks like there's no way you can avoid "conspiracy theorists" if you want to use X, including Xwayland, eh?
Metux (Enrico Weigelt) was banned from the Xorg project because his patches kept breaking things, often in ways which demonstrated he didn't even do the bare minimum before pushing commits. Like, adding code which didn't even compile. It's fascinating to look through the huge pile of commits they had to revert after banning him, to see how bad a lot of it is. I picked a few at random, and ... wow.
So he started his own fork.
The ban didn't seem to have any relation to politics or personal behavior. However, he was widely known for being ... how to put it in a way which is acceptable here ... uh, difficult to deal with. Like, after Linus Torvalds made a vow to be nicer, he made an exception just one time... for metux. He was the only person obnoxious enough to get Linus to break his vow. Which, if I recall correctly, was how he ended up focusing on the Xorg project. After getting booted from Linux, he picked a different project.
That's who is in charge of XLibre.
Things didn't get political until he announced the fork. Because, although politics had nothing to do with him getting banned (either time), he framed it as if he was being targeted for political reasons, and used inflammatory political language in the project's documentation. This gained a lot of attention and caused a lot of controversy, and also had the effect of ensuring the contributors all had mostly the same political views.
Anyway, the number of commits doesn't tell much of the story. The content of the commits (especially the reverted ones at Xorg) are far more enlightening.
People have all kind of opinions about xlibre as a project and the politics around it that I'm not interested in, but if they're driving xorg to improve, that's a good thing.
I'm not some anti-wayland zealot but you will pry xfce out of my cold dead hands.
>I'm not some anti-wayland zealot but you will pry xfce out of my cold dead hands.
Hard same. I'm using xfce on my laptop with mint xfce edition, and it's a breath of fresh air. Everything just works how you'd expect it to work, and it gets out of your way.
I tried sway a couple years ago and I lost count of the number of things I needed to go and find wayland specific workarounds for. I know things have gotten better since then, but I didn't see any benefit to switching and a whole lot of hassle.
X11 was 21 years old when the Wayland folks decided it was obsolete and needed to be replaced.
Wayland is now about 18 years old. So, by Wayland standards, only 3 more years until it, too, will be obsolete and need to be replaced.
That day can't come soon enough. :D
Maybe the next one will actually be able to do the things I need a display system to do. Until then, at least we've still got X11. And Wayland has taught everyone all sorts of things about what not to do.
Exactly. That was one of the first examples which came to mind for me too.
I often still use just ALSA, but pipewire is at least pretty decent and mostly "just works". Unlike pulseaudio, which was kind of a plague on Linux audio for ages.
On that note, for about 15 years, a funny thing kept happening. Any time anything on my Linux boxes broke, I'd trace the issue to its origin (bug hunting was literally my job, after all), and about half, maybe even two thirds of the time... it traced back to Lennart Poettering. That man was singlehandedly responsible for more than half the bugs I encountered for a decade and a half. It became so routine that I started practicing my impression of Severus Snape, so I could shake my fist at the sky and exclaim, "Poettering!!!"
Anyway, Wayland feels like another one of those... where someone has to do it wrong and create a lot of trouble before someone else comes along to do it right. But that second part hasn't happened yet. So it's still in a broken state where half the stuff I do on a daily basis isn't even possible in Wayland.
Whether the topic is Wayland or cheese or the finer points of knitting, one does not make an anonymous throwaway account to post statements one wants to stand behind and be associated with. Using an anon burner account makes every comment inherently more questionable than it would otherwise be, regardless of what is actually said.
Yeah, but they haven't added any features in years, from what I assumed to be a maintenance only/feature frozen stance in favor of Wayland, which is (primarily) why xlibre forked.
With a project as user/dev hostile as wayland, it's much better to be a 'last mover' than first.
For the life of me, I'll never understand how wayland got traction with the community.
'Hey guys, we decided to implement a display server from scratch! We broke a ton of existing functionality and made a ton of low level stuff that X used to handle the responsibility of WM/DE devs!'
You'll excuse me if I am not terribly enthusiastic about breaking all sorts of functionality to solve a security problem I've never experienced in my 25 years on linux.
Exactly. It's hard to be enthusiastic about something which breaks a lot of stuff I rely on daily, when the benefit is that it fixes problems I've never had.
My theory about the motivation behind the extra security is that it's largely driven by corporations wanting to make desktop Linux less free and less open, and normalize proprietary software instead of open-source. Because profit. Proprietary software is inherently not trustworthy, so the execution environment needs extra security and restrictions, and must be generally less powerful to reduce the damage it can do. Essentially, proprietary software needs the same precautions as malware. So the corps needed to "androidify" desktop Linux. Hence the change from curated distro package repositories to corporate app stores, and the reason why there's so much money pushing to replace X11 with Wayland.
In an open-source ecosystem, users and developers are one and the same, or at least on the same "side", cooperating with each other to make tools which work as well as possible for everyone. Each big program tends to be a collaborative effort where a lot of people contribute to make things better for everyone. Things mostly "just work" and people can typically trust their computers not to do anything weird or hostile.
Very different than a proprietary commercial ecosystem, where users and developers have more of an adversarial relationship. Each program tends to be created in a closed silo by one person or a relatively small team, and is designed primarily to extract money from users, with all other concerns being secondary. It is very common for profit-driven developers to engage in deceptive practices, or do things the user doesn't want, like showing advertisements, collecting and selling data, sabotaging products from competitors, using the device as a node in a botnet or secret compute farm, forcing unwanted updates, microtransactions or subscription fees, etc. So nothing can be trusted, and the entire system needs extensive protections against every type of misbehavior imaginable... even if that means reducing the power and features available to the user.
I've really enjoyed the past few decades of living entirely in the open-source world, where those problems pretty much just don't exist. But with corps pushing the androidification of desktop Linux, I fear those days may be coming to an end.
Wayland security is a side effect of how the core protocol works. In X, you have one giant buffer, while in Wayland, each application renders to its own buffer and pushes that buffer to the compositor when ready.
X has had compositing for ages as well. That didn't require preventing applications from moving the cursor or simulating keyboard input and even screen grabs still work fine.
It is, but my argument is that better security is not needed! There is only one user. All apps are his/hers.
Linux security inside a user's session is bad in general. It all started in the '90s from the principle that all installed software is FOSS, sources inspected, and compiled distro packages trusted.
- Permissions are per-user, not per-app. If I ever need permissions to something, every app I run gets the same permissions.
- No isolation for personal files. Any app running as me can read all of them. Bookmarks, firefox passwords, everything.
- No per-app firewall mechanisms. Any app can call home and send user's files, including those passwords.
- System events are broadcasted via dbus to any app wanting to listen to them.
So why make the GUI secure if everything else isn't? If anyone wants to have better security (or privacy) in Linux, would have to start with the basic permissions model.
More importantly, adding more security has a real cost because either you just can't do some things or need to punch a bunch of custom-built holes in your security. If you can avoid paying that cost by having only trusted software why wouldn't you.
It’s not about multi-user security. I would not like a compromised video player to be able to see my Signal chats just because both apps are in the same window system.
Does Signal save history? Or does it save your encryption keys in a file? If it does, then a compromized program can just read those files directly. No need for X, no need for a GUI, a simple console app can do it.
More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory, etc. and impersonate you. Also without X.
> Does Signal save history? Or does it save your encryption keys in a file?
Even on Signal Desktop, retrieving things from an outside app is very-hard-to-impossible depending on configuration and what you're after.
There's a reason most Signal bots (even benign ones) hook up an event stream to a specially configured Signal daemon and build an external record of data from Signal by watching for events over time.
> More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory...
I think you're missing a lot of the attack surface here. "Local execution is game over" is a technically-true-but-incomplete thought-terminating statement; it's more useful to assess "if I grant local execution, what attackers are likely to be interested in that, and what attacks are they likely to perform?"
Like sure, if you install something containing a full userland rootkit designed to attack a given application, and that application isn't running in a container such that you have to pivot through root to access it, you're screwed.
Those do exist, but there are a ton of local attack vectors that aren't that. Many pieces of malicious code that install with local apps aren't that complex, since complexity begets size and suspicious-behavior detection. Less complex malware would prefer to e.g. read Firefox's sqlite database files rather than try to execute new instances of trusted programs like Signal to get data out of them. We know from analysis of a lot of malware that it overwhelmingly prefers low-hanging fruit that's easy to harvest quickly and without doing much that risks detection. Some malware's scarier, but like Mickens said, most people a) aren't gonna get Mossad'd on, and b) can't do much about it if they are: https://www.usenix.org/system/files/1401_08-12_mickens.pdf
There are also local attack vectors that don't involve installing malware directly. Local programs that run code (browsers) and plenty of other exploits in e.g. decoders are limited enough in what's possible within the exploit chain that they can't calc.exe you and instead rely on info harvesting from speculative execution
Flatpak/Snap/etc., also can assist with a layer of local-app security here.
Put all that together, and you end up at the conclusion that a large volume of data is only practically accessible to a lot of malware by accessing another running app's memory. Two significant ways to do that are 1) reading memory directly (significantly mitigated by hardware permissioning/segmentation/ASLR) and 2) reading data those apps publish to the display system. Wayland makes that second one a lot harder.
Yet Qubes OS demostrates it's possible to run X11 programs isolated from each other. They had the need and will to improve security, and found the way over a decade ago.
Making server side decorations an important part of it. Oh, the irony.
Qubes OS achieves isolation by separating apps into VMs. Wayland does this at the display protocol level. If Qubes OS is serious about security, they should consider Wayland with containerization. It would result in a similar level of isolation with significantly lower resource overhead.
I feel like the sheer volume of OS LPEs and escape CVEs in container runtimes indicates that, at least for now, the security boundary capabilities of containers are inferior to those of VMs.
Which is ironic, given that a lot of the tools that underly a container runtime were originally designed to facilitate security, not ease of deployment.
You're aware of the VM escape issues over the past decade? There's no perfect, and high overhead from running many guests can also create security risks. Wayland with all of its problems remains a logical step forward from the X model.
It's better than the security of pretty much anything physical in your home. Somehow you seem to be OK with your stove letting anyone turn it on and have other solutions to deal with misuse. The same solutions apply to your virtual desktop.
IMO the issue is that the same group stewarding Wayland was also xorg, and intentionally stifled improvement on xorg even when the work just a matter of merging the PR.
Merging a PR by drive-by contributors is far from trivial. As the maintainer, you become responsible for the other person's code for all eternity; it's on you to read it, understand it, update it when stuff around it changes, and fix it when it breaks.
Not a problem for obviously-correct changes of a couple of lines, but most PRs aren't like that.
I understand and that's a fair point. I should have phrased that differently, in that the PRs for features were waiting to be merged. I'm sure merging into a codebase as... storied? as xorg is no small task.
Open source developers are not required to spend their time prioritizing your priorities. You just have to look to Xlibre to see that a lot of contributions are quite bad quality, and in a C codebase of Xorg's complexity and security profile it's not a small job to review things.
Nothing I said in any way implied that freedesktop should be required to do anything. I can't speak to the quality of xlibre merges, only that if whatever is going on over there led to improvements in xorg after a drought, that's a good thing.
If wayland had been sold as a hardened display for those who needed that level of security, I would not have a problem with it.
As it is, the community got constantly browbeat with 'this is the future' and 'it's so much faster!' when recent benchmarks have proven that to be false.
Then go use X. Nobody's stopping you, you can just ignore any brow beating. /ignore is a useful IRC command.
You'll probably find it to be a not great experience, since almost all the people who spend their time actually working on graphics and GUIs in the Linux world prefer to work on Wayland. So X doesn't get much love these days (and you're not entitled to their efforts after all). But it's not like they erased all the old X code from existence.
You may notice issues with some GPU drivers if you have hardware with new drivers, because older GPU drivers contain X-specific workarounds which new drivers may lack (I know this is an issue with the Apple M1 GPU, I suspect it might be an issue with Panthor as well). But that's not really relevant with typical consumer hardware.
Desktop environments have varying levels of X support these days. GNOME hasn't been adding new features to X for a while, and GNOME 50 completely drops X. So if you're a GNOME fan you may not like that. KDE ends X11 support in 6.8. But it's always possible to stay on GNOME 49 or KDE Plasma 6.7 forever, or use an X11 window manager.
The X11 back-end is deprecated in GTK 4, so don't expect a ton of improvements to it, but it'll remain supported for all of GTK 4's life so you probably won't notice anything there immediately. But it means GTK 5 will drop the X11 back-end entirely, so at some point in the coming decade, GTK applications will gradually stop working.
Regardless of GUI toolkit, applications are slowly moving towards the XDG Portal way of doing things instead of the X11 way; which is fine, there's no reason why X systems can't support the portal dbus APIs, but I suspect that there will be more issues there once applications start dropping their X11 implementations of things. This is an area under active development and I would expect X11 to not see much of that development. I have no idea if anyone has implemented a portal for X11. Maybe you'd have to do that yourself eventually to keep new versions of certain programs running, I don't know how the state of portals is on X.
There are other things too that software can do to break X11 support even when their toolkit supports X, and expect that this has started happening to some degree and will slowly continue.
It is for netflix, or the cloud image storage provider that wants to secure against the consumer easily extracting data and going to someone else. The user being able to easily take a program made by a third party and have it completely rearrange the guts of any other program is the basis of consumer security in a world without a unified government keeping commercial interests at bay.
It is, but nothing can be done about it. That's how Linux permissions work. Any app running as me can execute any other app I have permissions to run. It can pipe stdin/out/err, trace it, etc. Why should the desktop apps be different?
My desktop apps can’t trace other apps because they don’t have my sudo password. Some of my desktop apps run in containers/snaps or whatnot and other user processes can’t get to their internals without pivoting to root. Apps can’t read each other’s memory because of segmentation.
There is a lot more to desktop inter-app security than “if an app had a root shell then it could compromise things”. A great many attack vectors that we see constantly have a much narrower ingress than that.
Do you also loose sleep over the fact that everyone you let into your home could decide to rearrange your furniture and smash your TV and go trawling through a bunch of private stuff?
Wayland is not a "display server", it's a display protocol.
A lot of the "existing functionality" that it broke has nothing to do with displays, it's stuff that got crammed into Xorg at some point whether it made sense or not.
I find it quite funny that many of the same people that rag on systemd and say it does too many things, are big fans of Xorg doing a bunch of things that "display server" probably should not be handling.
Even if Wayland was a "display server", it would still "remove existing functionality" if it meant that in any principled sense, because "display server" is only half of what Xorg does.
But sure, the transition was difficult and took a long time.
>Wayland is not a "display server", it's a display protocol.
I, as an end user, do NOT care.
>A lot of the "existing functionality" that it broke has nothing to do with displays, it's stuff that got crammed into Xorg at some point whether it made sense or not.
I also don't care about ivory tower ideals of what is within the dominion of 'display' and what is not. The fact of the matter is their changes broke a ton of functionality, and instead of even trying to provide feature parity, they basically dumped all that responsibility onto the WM/DE devs.
I have no idea why the community didn't take one look at their proposal and flatly ignore them.
> instead of even trying to provide feature parity, they basically dumped all that responsibility onto the WM/DE devs.
In other words, the Wayland people should perhaps have defined official protocol extensions early on to cover most of what X did, thus preventing all the initial interop issues when Gnome and KDE and Sway tried to reinvent them independently.
In hindsight, it's my opinion that wayland, if it had to exist at all, should have been implemented like this:
1. Add GBM to graphics drivers and start working it up the stack from the bottom, stopping at Xorg. That is, make rootful XWayland the standard Xorg before standalone even is a thing. This reduces maintenance work up front rather than belatedly.
2.a. Implement weston as a standalone compositor.
2.b. Actually make weston fully functional. Figure out everything needed to provide an actual working desktop environment with the features that users expect out of the box. Standardize all the protocols needed for at least a basic XFCE-ish environment rather than hoping someone else will do it.
3. Then, only after these things are done and working, announce to the world that wayland, a quiet project that has until now explicitly suggested nobody use it, is now the future of linux graphical systems and everyone should plan to migrate.
This pretty much. Xorg got almost everything that I care about to have a functionning GUI. You only startx and the only thing you may need are utils programs like a wm, a compositor, a bar… now you have conflicting implementation from gnome, kde, wlroots,… each with its own set of features.
Yeah, instead of the wayland folks leading the effort to fix issues, it's often some individual DE / WM going off, fixing it the way they prefer, and wayland grudgingly adopting it as official because they know the ecosystem is fragmenting bad enough as it is.
The community doesn't really have a say because Xorg is effectively on life support and the Xorg devs are now working on Wayland. There aren't many people in this world who could keep Xorg going. Some distros are sticking to Xorg, but it will become more and more difficult in the coming years.
Not in the short-term, for sure, and probably not even in the mid-term. But hardware keeps changing, and at some point nobody will care enough (or be able) to implement proper support for it in X (or proper support of X in that hardware). Hopefully we still have at least a decade of X though.
And this transition is nowhere near done. Just look at Kicad and pretty much any DAW that loads audio plugins (to name two major usecases where Wayland simply doesn't cut it).
Sure Xwayland exists and mostly (not entirely) works, but that's a band-aid for what is essentially a "we broke it and don't care" approach.
The daw problem is really really bad too. We've got a de facto standard forming right now where you link libwayland.so and hope the structs never ever ever change in the next 30 years.
It may be reasonable when you emulate a completely different platform but not when your are providing a compatibility feature in a supposed successor platform that can be designed to support that use case.
I can't find the benchmarks now, but the ones I recently saw on hacker news, xwayland was notably worse than either wayland native or xorg native. Bad enough to be noticeable by the average user.
It does not matter, X11 is also not a display server it is a protocol. That distinction changes nothing.
For what it's worth Xorg is the display server, before that it was XFree86, there was also Xsgi and Xsun and for mac Xquartz, I even saw a neat project once where the Xserver was in javascript, I am trying to find it again but our modern search engines are a bit shit. The point being all of these can interoperate with one another.
Around computers it is difficult to find the correct unit of time to
measure progress. Some cathedrals took a century to complete. Can you
imagine the grandeur and scope of a program that would take as long?
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982
We have our cathedrals, only we are such barbarians as to call them worthless garbage and unfit for purpose and do our best to tear our legacy down.
> Wayland is not a "display server", it's a display protocol.
This is a huge part of what "user/dev hostile" means in my book; with Wayland, getting a working desktop always someone else's responsibility, all features have to be reimplemented across DEs endlessly (with often-incompatible variations, of course), and they all blame each other and program authors for bugs while the Wayland project refuses to even acknowledge basic features like desktop automation or screen recording.
> But sure, the transition was difficult and took a long time.
And this irks me too, people are convinced they're done but I still don't have xmacro. And flameshot is broken, while the alternatives suck. And support for everything depends on the DE now. And java.awt.Robot is broken with no replacement. And the clipboard randomly misses copies. And OBS screen recording is broken for me. And there's no support for display resolution scaling. And ssh -X is gone, while waypipe doesn't work all programs.
But hey, at least there's HDR now or something! It was definitely worth replacing a functioning stack for this. I'm so glad that Plasma 6.8 removes X support!
People aren't lamenting over Wayland not doing font rendering or audio but they care about display system features like screen recording and input automation that Wayland intentionally hobbles.
Wayland didn't start as a corporate project, and even if it had, you might be shocked to learn that the majority of contributions to projects like the Linux kernel and Mesa actually come from corporations, not individuals, right?
> I'll never understand how wayland got traction with the community
There were only a few people willing to work on an alternative, and they didn't have to take a vote, so they just did what they wanted. Corporations and projects adopted it because they wanted something different, and it was the only other option.
Now that we have AI, it will be much easier for genuine community alternatives to emerge, even if we have to battle over the legal ramifications. I for one am willing to go without "official support" to have software that doesn't suck.
It doesn't. Or at least it didn't last I checked, maybe that's changed, but I doubt it. I've tried the Wayland alternatives, and they left such a bad taste in my mouth that I'd really rather never touch Wayland again. Sway in particular was an exercise in frustration, the damned thing refused to use the right keyboard layout no matter how hard I tried.
Most stuff is fully rewritten/replaced. KDE and GNOME (maybe XFCE) are special cases. Sway acting as the Wayland version of i3wm is more what I expect. There was an early project to replicate AwesomeWM called WayCooler, but after a few years of trying to rewrite some major parts in Rust, the project died. There was a list of wlroots-based compositors at some point where most were replacements for the various old WMs.
I used to run xorg and wayland together and switch between them because you know you setup xorg no matter what even if you daily drive wayland. Since 2024 or so however I don’t remember opening a xorg session.
Out of the loop and this is definitely off topic, but what happened to the Xfree86 project? Is Xorg the same? The venerable xfree86config program is gone from the distrib so I assume it is not the same.
To be precise, X.org is/was a replacement to the project but a continuation of the software. AKA a fork that won. You sill have the xf86 prefix everywhere in X.org
Hooray! A new release of Xorg is always a good reason to celebrate. Long live the all-singing all-dancing feature-rich network-transparent display system which is still the best (and often only) solution for a lot of common user needs, even 39 years after its creation.
Well, Quartz is okay too, even though it lacks network transparency.
Arcan is looking like a very promising successor to the X protocol and Xorg server. It's not there yet, but it gets closer year after year.
I think Linux (and other unix-like system) would be best off with something like rio on plan9. The API should look like a file-system hierarchy, and API virtualization/access management/input output hooks and mapping could also be file-system-like.
The mention of XQuartz (for macOS) reminded me to check that, and 2.8.6 was released mid-July:
* https://www.xquartz.org/releases/bare/XQuartz-2.8.6.html
Previously 2.8.5 was out in 2023:
* https://www.xquartz.org/releases/bare/XQuartz-2.8.5.html
There's a XQuartz 2.8.7 beta as well (xorg-server 26.1 rebase):
* https://www.xquartz.org/releases/index.html
omg, it's been over a decade since I have last used XQuartz. Did they finally open source the whole quartz-wm?
> An XQuartz installation consists of many individual pieces of software which have various licenses. The X.Org software components’ licenses are discussed on the X.Org Foundation Licenses page.[1] The quartz-wm[2] window manager included with the XQuartz distribution uses the Apple Public Source License Version 2.[3]
* https://www.xquartz.org/index.html
Just looked it up, that Apple license is indeed approved as open source/free software by the FSF and OSI!
> FSF approved Yes (Version 2.0, not versions 1.0, 1.1 and 1.2)[2][3]
> OSI approved Yes
* https://en.wikipedia.org/wiki/Apple_Public_Source_License
Ah, I can see that the binary blob is not needed anymore. Nice.
This is a much more substantial changelog than I was expecting for something that is often presented as a deprecated project.
Redhat stands to lose their defacto control over X after the XLibre fork so they have to stop trying to kill it. Who would have thought that competition would make things better for everyone?
Alan Coopersmith works at Oracle, on Solaris. I don't know of any effort to use Wayland on Solaris, so maintaining X really is their only option.
OTOH, RedHat seems happy to let X die.
I doubt they care too much. They probably just have customers with applications stuck on a legacy window system. And they pay for that maintenance.
It basically is a deprecated project.
That's a new take: Project with new release 1 day ago declared deprecated!
I've been using Linux for around 2 decades. I am currently running Fedora 43/KDE Plasma ... and wait for it ... Xorg.
Why? Because it works. It works well!
Why don't I use Wayland? Because it breaks everything.
What does easystroke even do ? There is no README in the repo.
Sorry.
Easystroke is a mouse-gesture program: hold button, draw various lines or shapes, release button. Triggers any action. Like window minimize, execute command
This is the “official” repo but it was abandoned long ago: https://github.com/thjaeger/easystroke
My first linked repo is me and Claude working to fix build errors and app bugs to keep it running.
I use the Gentoo docs as my guide for this - both have first class support and they don't nudge you in either direction.
Out of curiosity: Is there any app that works on Wayland but not on X?
>Out of curiosity: Is there any app that works on Wayland but not on X?
foot, fuzzel, visurf.
XWayland
Intel modesetting driver with tearfree support in a xorg release!
Hoorah! Hopefully big distros will at least offer an optional upgrade to this.
I'm all for people switching to wayland but there should be choice and xorg should not be neglected for ideological reasons.
Xorg isn't neglected for "ideological reasons", it's neglected because development is work - and most of the people with knowledge of the problem domain decided they didn't want to work on Xorg anymore, and most of the companies that were paying for it decided they didn't want to pay for it anymore (apart from baseline maintenance, Xwayland and security fixes). And the people who want Xorg support maintained in perpetuity rarely seem interested in maintaining Xorg themselves, at least not properly (see this history of Xlibre introducing bugs and LLM slop).
You are free to spend your own time and resources doing the work, but you don't get to dictate how other people spend theirs.
Modesetting work was done in 2022, but for some reason no one had released a new stable release of the Xserver with this patch included since then. This was one of the reasons Xlibre was created, there was all these improvements to Xorg sitting ready for release but never being released.
Exactly. Just think about how much work it was to move from X to Wayland, how Nvidia didn't want to play ball, how different the architectures are, in a world where ossification is very much a thing. AND STILL there was enough momentum to get all the major players on board. I have never done any X programming but it must have been bad when people would so readily jump ship and put all that work in. Same for systemd.
Wayland was simpler because it was just a compositor. It meant people interested in graphics acceleration could focus on just that, iterating faster without the friction of the rest of the stack. But now that the Wayland ecosystem has to reinvent everything else, it's clearly at least as much work, if not more so. The initial switch moved the tightly knit rendering developers to a better local optimum, at the expense of a worse global optimum.
It forces some kind of modularity. Maybe that is a good thing. We don't have all features of X11 in Wayland but we also have features in Wayland that are missing in X11. I have been on Wayland for a while now and I can't say I am really suffering. There are some tings I'd like improved further but the protocol is evolving all the time. I think we'll get there. Also the decision is already made by the big distros anyways. They seem to be mostly happy.
> It forces some kind of modularity.
Wayland is the complete opposite of modular; that's why the compositor has to handle everything. The claimed problem with X11 was it was too modular, easy for different clients to control various aspects of the environment, but perhaps too easy, lacking a security policy framework to limit client access. (Or at least a framework that was fully baked. Wayland put an end to such initiatives.)
The lack of modularity in Wayland has been widening the rift between the desktop environments. It's as-if KDE and GNOME each forked X11 and went their own ways.
> Wayland is the complete opposite of modular
Not true. Wayland simply cuts out the middleman. Making the compositor the display server is one of the best things Wayland did. This brings so many advantages, such as true tear-free graphics and lower input latency.
The middle man was there to make sure everyone understood each other. Now simple things like taking a screenshot requires programs to speak multiple different languages.
Again, not true: if you want to take a screenshot in a generic way, you have to go through the XDG portal API, which is generic across all the compositors that support them, i.e. most of them.
The XDG Portal framework is obscenely complex (PipeWire, D-BUS over separate channels, etc), still requires each individual compositor and other components to specifically implement various aspects for things like screen sharing, and there's a ton of broken edges between the myriad interacting components. All-in-all the complete opposite of modular.
And that's the point. X11 provided a framework for all of this. Not perfect, but deliberately extensible. The Wayland alternatives are so much more complicated and brittle, and have to work around the limitations of Wayland. The effort expended by groups like freedesktop.org to architect and standardize new features would have been (and was) so much more productive in the X11 world.
I understand where you're coming from, but there is no turning back at this point. Sure, you could still run dwm on Xorg or Xlibre and pretend Wayland doesn't exist, but the reality is that the vast majority of Linux distributions and desktop environments have already committed to this stack, and application developers are going to target these portals.
There's also talk of D-Bus eventually being replaced with Varlink [0], showing that this whole ecosystem is still very much a moving target. What feels like endless breakage and friction right now is really just the noise of a massive architectural migration in progress. Eventually, the dust will settle, the APIs will stabilize, and the whole stack will become boring, reliable, and really good. That is how I prefer to look at it.
If you want to see things move in a specific direction or address any particular problem, the best path forward is to get involved and participate in the projects that interest you.
[0] - https://www.youtube.com/watch?v=NsVhkz2Xl0E&t=1415s
> This brings so many advantages, such as true tear-free graphics and lower input latency.
Curiously, people always seem to list the same advantages, and it's a very short list. Fewer (but still non-zero) torn frames are the top of the list pretty much every time, since that was the very first thing its creator listed in his original goals... but that's a pretty small benefit in exchange for breaking entire categories of functionality. Like, it looks smoother when I scroll, but features I rely on heavily every day are forbidden.
As for input latency... that doesn't seem like it was ever a problem. Using X11, I'm able to get 500 to 1000 inputs per second even on a potato PC. That's faster than the frame rate of pretty much any screen, and fast enough even for audio / midi purposes. Reducing input latency from ~1.5ms to ~1.0ms doesn't really matter when the timeslice scheduling has ~6ms of jitter on an average system, a common screen only draws a frame every ~16ms, and many input devices have 50+ ms of their own additional latency.
> if you want to take a screenshot in a generic way, you have to go through the XDG portal API
This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots. Like many things users need, they decided it was someone else's problem, and threw it over the fence for the fragmented ecosystem of downstream projects to solve. So each downstream project came up with their own workarounds for essential features not existing. The solutions had to be built entirely outside of Wayland, and even after years of development, the solutions are still incomplete, unreliable, complex, and full of caveats. It required (and still requires) everyone except Wayland's core devs to write a lot more code for less functionality than they used to get with a couple of simple API calls. They had to architect entire complex infrastructure layers in order to work around a missing feature in the core protocol, since the core devs stubbornly refused to allow it.
Similar situation for input automation and remote control. It's a common thing people need. I use it every day and can't use the notebook at my desk without it... but the Wayland folks refused to solve it, so it had to be done outside of Wayland. For example, one workaround is to give the user direct access to the kernel so they can create fake input devices at a kernel level, and generate the inputs they need, which Wayland then sees as a local physical keyboard or mouse. So... problem solved, from Wayland's point of view. The user gets what they need, sort of, and it's implemented outside of Wayland, so Wayland doesn't have any security issues. But... and this is a big "but"... the solution involves giving users device-level kernel access. Which seems significantly worse than the issue it was originally trying to solve.
> I understand where you're coming from, but there is no turning back at this point.
A position of "sure it has major problems, but it's too late now" is not a position of progress. Much like the situation with pulseaudio being deployed everywhere then replaced with pipewire, it's almost never too late to fix bad software architecture. As you said, this whole ecosystem is still very much a moving target.
The ideal solution would be the creation of a new system which supports the features, protocols, and APIs of the older system(s), in a way which "just works". But that requires a very different mindset from the people behind it. Instead of "not my problem, someone else can deal with it" like the Wayland policy, a proper solution needs people to adopt a "the buck stops here" approach, and take responsibility for making the entire system work. Things like accessibility, network transparency, automation, and legacy support... need to be built in from the ground up, not rejected or treated as an afterthought for someone else to handle.
> Curiously, people always seem to list the same advantages, and it's a very short list.
The things I listed are just the tip of the iceberg. Having studied earlier versions of X like X10, X11, and now Wayland, I could go on and on. What I'm trying to emphasize here is not to look at Wayland through an Xorg lens. I know it's easy to look at Wayland and immediately think it's a rigid protocol that breaks everything, but the reality is that it's a lot more flexible than people realize. Once you understand it, I think the closest thing that comes to mind is "There is no spoon." And just like there is no spoon, there are also no windows, only surfaces, but again, that's only the tip of the iceberg.
If you want an example of what I'm talking about, take a look at projects like p9wl. [0] This is using wlroots to create a proxy between Linux and Plan 9 in order to display windows remotely. Such flexibility is only possible when the protocols are small and composable, which Wayland is.
> As for input latency... that doesn't seem like it was ever a problem.
I never said it's impossible to get acceptable input latency on Xorg. I'm just saying that when your input and graphics go directly through your compositor, the experience is on a completely different level. This is even more true with features like direct scanout, where the compositor steps aside to send graphics directly to the GPU and input directly to the game as it goes fullscreen. It simply makes using your computer so much more pleasant. These input latency issues were exactly what Kristian Høgsberg tried to fix in Xorg, and addressing them was one of the primary motivations behind creating Wayland. [1]
> This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots.
You're thinking through your Xorg lens again. That's understandable, since you're probably used to it. However, to really understand Wayland, you have to look at it through a different lens. Wayland isn't defective, and it's not trying to be Xorg 2. It's a protocol. It doesn't do your laundry, nor does it take screenshots. It's just there to provide the mechanism for sending buffers to your compositor.
You can think of Wayland as thin building blocks to build compositors, just as you can build window managers on X, except this time, the core protocol does one thing and the libraries already exist. Wayland exists because all the infrastructure is already there in the kernel and in libraries.
The screenshot feature is the job of the compositor. Most compositors already have this feature built in. As I mentioned before, XDG portals exist, and interoperability will only keep getting better.
> Similar situation for input automation and remote control.
I agree input automation and remote desktop are still problematic. GNOME and KDE have their own remote desktop solutions, as do most of the others, but I haven't had a need to use them myself. All in all, Wayland really isn't trying to prevent you from doing things, it's just a protocol.
I'm pretty sure all this will be solved eventually, and I understand the frustration of those who need these features. However, I also understand Wayland and compositor developers taking a careful approach here, and it shows.
> A position of "sure it has major problems, but it's too late now" is not a position of progress.
That's not what I intended to say. The intended message was: the core Wayland protocol is set in stone and won't change, but we can build these things that aren't working and make them work. That is already happening every day. Progress has been steady, it's a lot better than it used to be, and it will only keep getting better. Going from Wayland into a whole different windowing system, I don't see that happening, at least not in the next 60+ years, but I definitely see the whole Wayland ecosystem improving.
[0] - https://www.youtube.com/watch?v=tRx75piIlxo
[1] - https://archive.fosdem.org/2012/interview/kristian-hogsberg....
Luckily there is XLibre if the xorg developers can't develop X any more.
[flagged]
I don't care about either X, but that guy's name is in this release, and judging purely by the number of commits (since I lack X expertise to judge any other way), he seems to be the top contributor.
Looks like there's no way you can avoid "conspiracy theorists" if you want to use X, including Xwayland, eh?
Metux (Enrico Weigelt) was banned from the Xorg project because his patches kept breaking things, often in ways which demonstrated he didn't even do the bare minimum before pushing commits. Like, adding code which didn't even compile. It's fascinating to look through the huge pile of commits they had to revert after banning him, to see how bad a lot of it is. I picked a few at random, and ... wow.
So he started his own fork.
The ban didn't seem to have any relation to politics or personal behavior. However, he was widely known for being ... how to put it in a way which is acceptable here ... uh, difficult to deal with. Like, after Linus Torvalds made a vow to be nicer, he made an exception just one time... for metux. He was the only person obnoxious enough to get Linus to break his vow. Which, if I recall correctly, was how he ended up focusing on the Xorg project. After getting booted from Linux, he picked a different project.
That's who is in charge of XLibre.
Things didn't get political until he announced the fork. Because, although politics had nothing to do with him getting banned (either time), he framed it as if he was being targeted for political reasons, and used inflammatory political language in the project's documentation. This gained a lot of attention and caused a lot of controversy, and also had the effect of ensuring the contributors all had mostly the same political views.
Anyway, the number of commits doesn't tell much of the story. The content of the commits (especially the reverted ones at Xorg) are far more enlightening.
It looks like it's under more active development currently, however I don't see them adding many big new features at this point.
Isn't most of this already in xlibre?
People have all kind of opinions about xlibre as a project and the politics around it that I'm not interested in, but if they're driving xorg to improve, that's a good thing.
I'm not some anti-wayland zealot but you will pry xfce out of my cold dead hands.
>I'm not some anti-wayland zealot but you will pry xfce out of my cold dead hands.
Hard same. I'm using xfce on my laptop with mint xfce edition, and it's a breath of fresh air. Everything just works how you'd expect it to work, and it gets out of your way.
I tried sway a couple years ago and I lost count of the number of things I needed to go and find wayland specific workarounds for. I know things have gotten better since then, but I didn't see any benefit to switching and a whole lot of hassle.
X11 was 21 years old when the Wayland folks decided it was obsolete and needed to be replaced.
Wayland is now about 18 years old. So, by Wayland standards, only 3 more years until it, too, will be obsolete and need to be replaced.
That day can't come soon enough. :D
Maybe the next one will actually be able to do the things I need a display system to do. Until then, at least we've still got X11. And Wayland has taught everyone all sorts of things about what not to do.
We already had a similar situation with PulseAudio. Happily outlived that monstrosity.
Exactly. That was one of the first examples which came to mind for me too.
I often still use just ALSA, but pipewire is at least pretty decent and mostly "just works". Unlike pulseaudio, which was kind of a plague on Linux audio for ages.
On that note, for about 15 years, a funny thing kept happening. Any time anything on my Linux boxes broke, I'd trace the issue to its origin (bug hunting was literally my job, after all), and about half, maybe even two thirds of the time... it traced back to Lennart Poettering. That man was singlehandedly responsible for more than half the bugs I encountered for a decade and a half. It became so routine that I started practicing my impression of Severus Snape, so I could shake my fist at the sky and exclaim, "Poettering!!!"
Anyway, Wayland feels like another one of those... where someone has to do it wrong and create a lot of trouble before someone else comes along to do it right. But that second part hasn't happened yet. So it's still in a broken state where half the stuff I do on a daily basis isn't even possible in Wayland.
So many people spreading FUD about Wayland who don't have a clue.
One guy creating an anonymous throwaway account, to make questionable posts without risking action against his real account.
BTW, what's the policy on that sort of thing here?
Questionable posts? Care to explain? So not having the same opinion that you have or being in favor of Wayland is questionable now?
Whether the topic is Wayland or cheese or the finer points of knitting, one does not make an anonymous throwaway account to post statements one wants to stand behind and be associated with. Using an anon burner account makes every comment inherently more questionable than it would otherwise be, regardless of what is actually said.
[dead]
Xorg has had releases for years and will continue to do so. But as you can see in the announcement, enterprise users are the driving factor.
Yeah, but they haven't added any features in years, from what I assumed to be a maintenance only/feature frozen stance in favor of Wayland, which is (primarily) why xlibre forked.
Even xfce will one day move to Wayland.
With a project as user/dev hostile as wayland, it's much better to be a 'last mover' than first.
For the life of me, I'll never understand how wayland got traction with the community.
'Hey guys, we decided to implement a display server from scratch! We broke a ton of existing functionality and made a ton of low level stuff that X used to handle the responsibility of WM/DE devs!'
I think it was the "security" argument. Some magic words like "security" and "protect the children" make most people go insane, abandon all reason.
You'll excuse me if I am not terribly enthusiastic about breaking all sorts of functionality to solve a security problem I've never experienced in my 25 years on linux.
Exactly. It's hard to be enthusiastic about something which breaks a lot of stuff I rely on daily, when the benefit is that it fixes problems I've never had.
My theory about the motivation behind the extra security is that it's largely driven by corporations wanting to make desktop Linux less free and less open, and normalize proprietary software instead of open-source. Because profit. Proprietary software is inherently not trustworthy, so the execution environment needs extra security and restrictions, and must be generally less powerful to reduce the damage it can do. Essentially, proprietary software needs the same precautions as malware. So the corps needed to "androidify" desktop Linux. Hence the change from curated distro package repositories to corporate app stores, and the reason why there's so much money pushing to replace X11 with Wayland.
In an open-source ecosystem, users and developers are one and the same, or at least on the same "side", cooperating with each other to make tools which work as well as possible for everyone. Each big program tends to be a collaborative effort where a lot of people contribute to make things better for everyone. Things mostly "just work" and people can typically trust their computers not to do anything weird or hostile.
Very different than a proprietary commercial ecosystem, where users and developers have more of an adversarial relationship. Each program tends to be created in a closed silo by one person or a relatively small team, and is designed primarily to extract money from users, with all other concerns being secondary. It is very common for profit-driven developers to engage in deceptive practices, or do things the user doesn't want, like showing advertisements, collecting and selling data, sabotaging products from competitors, using the device as a node in a botnet or secret compute farm, forcing unwanted updates, microtransactions or subscription fees, etc. So nothing can be trusted, and the entire system needs extensive protections against every type of misbehavior imaginable... even if that means reducing the power and features available to the user.
I've really enjoyed the past few decades of living entirely in the open-source world, where those problems pretty much just don't exist. But with corps pushing the androidification of desktop Linux, I fear those days may be coming to an end.
Wayland security is a side effect of how the core protocol works. In X, you have one giant buffer, while in Wayland, each application renders to its own buffer and pushes that buffer to the compositor when ready.
X has had compositing for ages as well. That didn't require preventing applications from moving the cursor or simulating keyboard input and even screen grabs still work fine.
I'm aware, I've been there since Xgl when Kristian Høgsberg worked on AIGLX. Wayland makes the current X model the default, it is X.
Yeah people never stop to ask "security from whom". I don't need my display servers to secure me from the tools I choose to run.
Xorg's security (and X11 in general) is objectively terrible - this is not even a debatable question.
It is, but my argument is that better security is not needed! There is only one user. All apps are his/hers.
Linux security inside a user's session is bad in general. It all started in the '90s from the principle that all installed software is FOSS, sources inspected, and compiled distro packages trusted.
So why make the GUI secure if everything else isn't? If anyone wants to have better security (or privacy) in Linux, would have to start with the basic permissions model.More importantly, adding more security has a real cost because either you just can't do some things or need to punch a bunch of custom-built holes in your security. If you can avoid paying that cost by having only trusted software why wouldn't you.
It’s not about multi-user security. I would not like a compromised video player to be able to see my Signal chats just because both apps are in the same window system.
Does Signal save history? Or does it save your encryption keys in a file? If it does, then a compromized program can just read those files directly. No need for X, no need for a GUI, a simple console app can do it.
More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory, etc. and impersonate you. Also without X.
> Does Signal save history? Or does it save your encryption keys in a file?
Even on Signal Desktop, retrieving things from an outside app is very-hard-to-impossible depending on configuration and what you're after.
There's a reason most Signal bots (even benign ones) hook up an event stream to a specially configured Signal daemon and build an external record of data from Signal by watching for events over time.
> More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory...
I think you're missing a lot of the attack surface here. "Local execution is game over" is a technically-true-but-incomplete thought-terminating statement; it's more useful to assess "if I grant local execution, what attackers are likely to be interested in that, and what attacks are they likely to perform?"
Like sure, if you install something containing a full userland rootkit designed to attack a given application, and that application isn't running in a container such that you have to pivot through root to access it, you're screwed.
Those do exist, but there are a ton of local attack vectors that aren't that. Many pieces of malicious code that install with local apps aren't that complex, since complexity begets size and suspicious-behavior detection. Less complex malware would prefer to e.g. read Firefox's sqlite database files rather than try to execute new instances of trusted programs like Signal to get data out of them. We know from analysis of a lot of malware that it overwhelmingly prefers low-hanging fruit that's easy to harvest quickly and without doing much that risks detection. Some malware's scarier, but like Mickens said, most people a) aren't gonna get Mossad'd on, and b) can't do much about it if they are: https://www.usenix.org/system/files/1401_08-12_mickens.pdf
There are also local attack vectors that don't involve installing malware directly. Local programs that run code (browsers) and plenty of other exploits in e.g. decoders are limited enough in what's possible within the exploit chain that they can't calc.exe you and instead rely on info harvesting from speculative execution
Flatpak/Snap/etc., also can assist with a layer of local-app security here.
Put all that together, and you end up at the conclusion that a large volume of data is only practically accessible to a lot of malware by accessing another running app's memory. Two significant ways to do that are 1) reading memory directly (significantly mitigated by hardware permissioning/segmentation/ASLR) and 2) reading data those apps publish to the display system. Wayland makes that second one a lot harder.
Yet Qubes OS demostrates it's possible to run X11 programs isolated from each other. They had the need and will to improve security, and found the way over a decade ago.
Making server side decorations an important part of it. Oh, the irony.
Qubes OS achieves isolation by separating apps into VMs. Wayland does this at the display protocol level. If Qubes OS is serious about security, they should consider Wayland with containerization. It would result in a similar level of isolation with significantly lower resource overhead.
I feel like the sheer volume of OS LPEs and escape CVEs in container runtimes indicates that, at least for now, the security boundary capabilities of containers are inferior to those of VMs.
Which is ironic, given that a lot of the tools that underly a container runtime were originally designed to facilitate security, not ease of deployment.
You're aware of the VM escape issues over the past decade? There's no perfect, and high overhead from running many guests can also create security risks. Wayland with all of its problems remains a logical step forward from the X model.
I was narrowly responding to the point about Qubes using VMs. I have no problems with Wayland’s design; I agree that it’s a step forward.
Ah, got it! Thanks for clarifying. That makes a lot of sense.
It's better than the security of pretty much anything physical in your home. Somehow you seem to be OK with your stove letting anyone turn it on and have other solutions to deal with misuse. The same solutions apply to your virtual desktop.
Great, so let wayland be a hardened option for those who care.
It is and you're free to use X if you want
IMO the issue is that the same group stewarding Wayland was also xorg, and intentionally stifled improvement on xorg even when the work just a matter of merging the PR.
Merging a PR by drive-by contributors is far from trivial. As the maintainer, you become responsible for the other person's code for all eternity; it's on you to read it, understand it, update it when stuff around it changes, and fix it when it breaks.
Not a problem for obviously-correct changes of a couple of lines, but most PRs aren't like that.
I understand and that's a fair point. I should have phrased that differently, in that the PRs for features were waiting to be merged. I'm sure merging into a codebase as... storied? as xorg is no small task.
>and intentionally stifled improvement on xorg
Open source developers are not required to spend their time prioritizing your priorities. You just have to look to Xlibre to see that a lot of contributions are quite bad quality, and in a C codebase of Xorg's complexity and security profile it's not a small job to review things.
Nothing I said in any way implied that freedesktop should be required to do anything. I can't speak to the quality of xlibre merges, only that if whatever is going on over there led to improvements in xorg after a drought, that's a good thing.
If wayland had been sold as a hardened display for those who needed that level of security, I would not have a problem with it.
As it is, the community got constantly browbeat with 'this is the future' and 'it's so much faster!' when recent benchmarks have proven that to be false.
Then go use X. Nobody's stopping you, you can just ignore any brow beating. /ignore is a useful IRC command.
You'll probably find it to be a not great experience, since almost all the people who spend their time actually working on graphics and GUIs in the Linux world prefer to work on Wayland. So X doesn't get much love these days (and you're not entitled to their efforts after all). But it's not like they erased all the old X code from existence.
> You'll probably find it to be a not great experience
I'm confused where I'm likely to be suffering. If I start using Wayland tomorrow would I even notice? Apart from having to switch DEs, of course.
Depends on a lot of context.
You may notice issues with some GPU drivers if you have hardware with new drivers, because older GPU drivers contain X-specific workarounds which new drivers may lack (I know this is an issue with the Apple M1 GPU, I suspect it might be an issue with Panthor as well). But that's not really relevant with typical consumer hardware.
Desktop environments have varying levels of X support these days. GNOME hasn't been adding new features to X for a while, and GNOME 50 completely drops X. So if you're a GNOME fan you may not like that. KDE ends X11 support in 6.8. But it's always possible to stay on GNOME 49 or KDE Plasma 6.7 forever, or use an X11 window manager.
The X11 back-end is deprecated in GTK 4, so don't expect a ton of improvements to it, but it'll remain supported for all of GTK 4's life so you probably won't notice anything there immediately. But it means GTK 5 will drop the X11 back-end entirely, so at some point in the coming decade, GTK applications will gradually stop working.
Regardless of GUI toolkit, applications are slowly moving towards the XDG Portal way of doing things instead of the X11 way; which is fine, there's no reason why X systems can't support the portal dbus APIs, but I suspect that there will be more issues there once applications start dropping their X11 implementations of things. This is an area under active development and I would expect X11 to not see much of that development. I have no idea if anyone has implemented a portal for X11. Maybe you'd have to do that yourself eventually to keep new versions of certain programs running, I don't know how the state of portals is on X.
There are other things too that software can do to break X11 support even when their toolkit supports X, and expect that this has started happening to some degree and will slowly continue.
> GTK 5 will drop the X11 back-end entirely, so at some point in the coming decade, GTK applications will gradually stop working.
Hopefully someone will come up with Wayland emulation layer for x11 then.
Not exactly what you're talking about but I use Weston for Waydroid in xorg on xfce. You just get a Weston window on your desktop.
That would be apt and hilarious, at the same time ...
Thanks for the thoughtful reply. I'll keep an eye out, but all seems fine so far.
Are you seriously acting like every application having full access over other applications is not an actual security issue?
It is for netflix, or the cloud image storage provider that wants to secure against the consumer easily extracting data and going to someone else. The user being able to easily take a program made by a third party and have it completely rearrange the guts of any other program is the basis of consumer security in a world without a unified government keeping commercial interests at bay.
It is, but nothing can be done about it. That's how Linux permissions work. Any app running as me can execute any other app I have permissions to run. It can pipe stdin/out/err, trace it, etc. Why should the desktop apps be different?
See my other comment too.
My desktop apps can’t trace other apps because they don’t have my sudo password. Some of my desktop apps run in containers/snaps or whatnot and other user processes can’t get to their internals without pivoting to root. Apps can’t read each other’s memory because of segmentation.
There is a lot more to desktop inter-app security than “if an app had a root shell then it could compromise things”. A great many attack vectors that we see constantly have a much narrower ingress than that.
You don't need sudo for trace under the same account. You can even attach a debugger and read all app's memory.
Virtualization is another thing entirely. But if you want it that way, then why not simply start a second X for the untrusted app?
Do you also loose sleep over the fact that everyone you let into your home could decide to rearrange your furniture and smash your TV and go trawling through a bunch of private stuff?
Wayland is not a "display server", it's a display protocol.
A lot of the "existing functionality" that it broke has nothing to do with displays, it's stuff that got crammed into Xorg at some point whether it made sense or not.
I find it quite funny that many of the same people that rag on systemd and say it does too many things, are big fans of Xorg doing a bunch of things that "display server" probably should not be handling.
Even if Wayland was a "display server", it would still "remove existing functionality" if it meant that in any principled sense, because "display server" is only half of what Xorg does.
But sure, the transition was difficult and took a long time.
>Wayland is not a "display server", it's a display protocol.
I, as an end user, do NOT care.
>A lot of the "existing functionality" that it broke has nothing to do with displays, it's stuff that got crammed into Xorg at some point whether it made sense or not.
I also don't care about ivory tower ideals of what is within the dominion of 'display' and what is not. The fact of the matter is their changes broke a ton of functionality, and instead of even trying to provide feature parity, they basically dumped all that responsibility onto the WM/DE devs.
I have no idea why the community didn't take one look at their proposal and flatly ignore them.
> instead of even trying to provide feature parity, they basically dumped all that responsibility onto the WM/DE devs.
In other words, the Wayland people should perhaps have defined official protocol extensions early on to cover most of what X did, thus preventing all the initial interop issues when Gnome and KDE and Sway tried to reinvent them independently.
In hindsight, it's my opinion that wayland, if it had to exist at all, should have been implemented like this:
1. Add GBM to graphics drivers and start working it up the stack from the bottom, stopping at Xorg. That is, make rootful XWayland the standard Xorg before standalone even is a thing. This reduces maintenance work up front rather than belatedly.
2.a. Implement weston as a standalone compositor.
2.b. Actually make weston fully functional. Figure out everything needed to provide an actual working desktop environment with the features that users expect out of the box. Standardize all the protocols needed for at least a basic XFCE-ish environment rather than hoping someone else will do it.
3. Then, only after these things are done and working, announce to the world that wayland, a quiet project that has until now explicitly suggested nobody use it, is now the future of linux graphical systems and everyone should plan to migrate.
Yes and more fundamentally they should have acknowledged that not everyone needs to be treated with the security model of a mobile app.
This pretty much. Xorg got almost everything that I care about to have a functionning GUI. You only startx and the only thing you may need are utils programs like a wm, a compositor, a bar… now you have conflicting implementation from gnome, kde, wlroots,… each with its own set of features.
Yeah, instead of the wayland folks leading the effort to fix issues, it's often some individual DE / WM going off, fixing it the way they prefer, and wayland grudgingly adopting it as official because they know the ecosystem is fragmenting bad enough as it is.
The community doesn't really have a say because Xorg is effectively on life support and the Xorg devs are now working on Wayland. There aren't many people in this world who could keep Xorg going. Some distros are sticking to Xorg, but it will become more and more difficult in the coming years.
People keep saying Xorg will stop working, but it has yet to turn into a pumpkin, so I dunno man.
Can it do new things? Eh, probably not. Do I need it to do new things? Not really.
Not in the short-term, for sure, and probably not even in the mid-term. But hardware keeps changing, and at some point nobody will care enough (or be able) to implement proper support for it in X (or proper support of X in that hardware). Hopefully we still have at least a decade of X though.
I have no idea why the community didn't take one look at their proposal and flatly ignore them.
At the time, RedHat basically controlled Gnome via paid devs and donations. And the same for this Wayland nonsense. Oh, and systemd too!
Notice a pattern?
If nothing else this is a very strong commentary on just how challenging landing positive changes in Xorg felt to the community.
And this transition is nowhere near done. Just look at Kicad and pretty much any DAW that loads audio plugins (to name two major usecases where Wayland simply doesn't cut it).
Sure Xwayland exists and mostly (not entirely) works, but that's a band-aid for what is essentially a "we broke it and don't care" approach.
The daw problem is really really bad too. We've got a de facto standard forming right now where you link libwayland.so and hope the structs never ever ever change in the next 30 years.
Also, as benchmarks show, xwayland introduces pretty bad latency..
The latency isn't that bad, it's reasonable for a compatibility shim.
It may be reasonable when you emulate a completely different platform but not when your are providing a compatibility feature in a supposed successor platform that can be designed to support that use case.
I can't find the benchmarks now, but the ones I recently saw on hacker news, xwayland was notably worse than either wayland native or xorg native. Bad enough to be noticeable by the average user.
It does not matter, X11 is also not a display server it is a protocol. That distinction changes nothing.
For what it's worth Xorg is the display server, before that it was XFree86, there was also Xsgi and Xsun and for mac Xquartz, I even saw a neat project once where the Xserver was in javascript, I am trying to find it again but our modern search engines are a bit shit. The point being all of these can interoperate with one another.
We have our cathedrals, only we are such barbarians as to call them worthless garbage and unfit for purpose and do our best to tear our legacy down.> X11 is also not a display server it is a protocol
With a reference implementation. Xsgi, Xsun, Xquartz, and all the rest used the reference implementation with platform driver glue.
> Wayland is not a "display server", it's a display protocol.
Bailey: Wayland replaces Xorg
Motte: Wayland is just a protocol
> because "display server" is only half of what Xorg does.
Yes, that's a big part of the problem. X was build for I/O, Wayland was built for O and had to be dragged kicking and screaming into rudimentary I.
> Wayland is not a "display server", it's a display protocol.
This is a huge part of what "user/dev hostile" means in my book; with Wayland, getting a working desktop always someone else's responsibility, all features have to be reimplemented across DEs endlessly (with often-incompatible variations, of course), and they all blame each other and program authors for bugs while the Wayland project refuses to even acknowledge basic features like desktop automation or screen recording.
> But sure, the transition was difficult and took a long time.
And this irks me too, people are convinced they're done but I still don't have xmacro. And flameshot is broken, while the alternatives suck. And support for everything depends on the DE now. And java.awt.Robot is broken with no replacement. And the clipboard randomly misses copies. And OBS screen recording is broken for me. And there's no support for display resolution scaling. And ssh -X is gone, while waypipe doesn't work all programs.
But hey, at least there's HDR now or something! It was definitely worth replacing a functioning stack for this. I'm so glad that Plasma 6.8 removes X support!
People aren't lamenting over Wayland not doing font rendering or audio but they care about display system features like screen recording and input automation that Wayland intentionally hobbles.
> For the life of me, I'll never understand how wayland got traction with the community.
Corporate drive. Originally sponsored by Intel followed by IBM (RedHat) and the rest followed suit.
Money, the "cure" to the hacker ethos.
Wayland didn't start as a corporate project, and even if it had, you might be shocked to learn that the majority of contributions to projects like the Linux kernel and Mesa actually come from corporations, not individuals, right?
Sauce?
It's how any of these projects get shifted in distribution if not sponsored.
> Kristian Høgsberg, I work at Intel in the graphics team in the Open Source Technology Center. I'm the founder and maintainer of the Wayland project.
You either pitch or bring it with you. Demonstrate a tech demo and you're granted an engineer or two. It's how Amiga came to be, Steve Jobs with NeXT.
And it appears you can no longer link anything from reddit without being asked to login and they've now nuked old.reddit
If you have an account this thread has some very insightful comments. https://www.reddit.com/r/linux/comments/1m0ztn/how_is_waylan...
They've been working on Wayland support for awhile now.
https://wiki.xfce.org/releng/wayland_roadmap
> I'll never understand how wayland got traction with the community
There were only a few people willing to work on an alternative, and they didn't have to take a vote, so they just did what they wanted. Corporations and projects adopted it because they wanted something different, and it was the only other option.
Now that we have AI, it will be much easier for genuine community alternatives to emerge, even if we have to battle over the legal ramifications. I for one am willing to go without "official support" to have software that doesn't suck.
[dead]
They're already busy doing precisely that: https://lwn.net/Articles/1078942
And I'll be there.
There's already and experimental support no?
> you will pry xfce out of my cold dead hands
AwesomeWM for me. I've essentially fused with it. Warts and all.
Does it not work on Wayland?
I can't imagine life without AwesomeWM.
It doesn't. Or at least it didn't last I checked, maybe that's changed, but I doubt it. I've tried the Wayland alternatives, and they left such a bad taste in my mouth that I'd really rather never touch Wayland again. Sway in particular was an exercise in frustration, the damned thing refused to use the right keyboard layout no matter how hard I tried.
Most stuff is fully rewritten/replaced. KDE and GNOME (maybe XFCE) are special cases. Sway acting as the Wayland version of i3wm is more what I expect. There was an early project to replicate AwesomeWM called WayCooler, but after a few years of trying to rewrite some major parts in Rust, the project died. There was a list of wlroots-based compositors at some point where most were replacements for the various old WMs.
[dead]
I used to run xorg and wayland together and switch between them because you know you setup xorg no matter what even if you daily drive wayland. Since 2024 or so however I don’t remember opening a xorg session.
Note that Enrico Weigelt is the "XLibre" guy and some of his fixes made it into this release, you can search for his name in the message.
Duplicate functionality compared to XLibre was reimplemented here from scratch, or sourced from XLibre?
Pulling good ideas from downstream forks is actually kind of what open source is all about, isn't it?
At least one was looks like it was sourced from XLibre: https://github.com/X11Libre/xserver/pull/1314
I'll wait to pick up the XLibre version of this with the correct patches.
Out of the loop and this is definitely off topic, but what happened to the Xfree86 project? Is Xorg the same? The venerable xfree86config program is gone from the distrib so I assume it is not the same.
XFree86 died a long time ago. X.org is its replacement.
There was a bunch of infighting as well as a dispute over license changes. People just abandoned it.
To be precise, X.org is/was a replacement to the project but a continuation of the software. AKA a fork that won. You sill have the xf86 prefix everywhere in X.org