https://news.ycombinator.com/item?id=45925950 GNOME 50 completes the migration to Wayland, dropping X11 backend code (linuxiac.com)
12 days ago | 185 comments
I'm not 100% aligned with default KDE either but that doesn't matter because it has options to configure it just the way I want.
Until it hard crashed my machine after I opened discord in firefox. Konqueror crashed on opening.
Edit: oh, I guess swapping FreeBSD for Linux? Yeah nah, I don't know GP, but I suspect this isn't a reason for them to switch OS just to solve this.
I also like that I don't constantly have to learn new stuff like the new ip commands or systemd. It just works. Oh and ZFS on root as a first class citizen is amazing of course.
This! I didn't realize how much I wanted this. FreeBSD release base packages are stable but all the regular packages are super up to date. Plasma looks very updated and stable.
I've tried rolling distros like Opensuse Tumble and Manjaro but eventually if you don't update them regularly you get a huge change and often many things change/break. Had your bluetooth speakers working finally? Now that's gone!
On the other hand stable releases in linux distros also seem to fail. Didn't update your random Ubuntu server in the corner of the office for the last year? Well now the apt links are broken and down for the release so you can't update the current release so you can upgrade.
> I also like that I don't constantly have to learn new stuff like the new ip commands or systemd. It just works. Oh and ZFS on root as a first class citizen is amazing of course.
It's nice, many of the same basics I learned on freebsd 6 years ago all still magically work. ifconfig works even with ipv6. You learn two files and you can do most anything.
I'm definitely gonna consider Freebsd for embedded devices if I can as well. You dint need buildroot or yocto as it's already part of the BSDs.
https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...
https://www.phoronix.com/news/Qt-Wayland-Compositor-Restart
As I understand it, in Wayland all the necessary state lives client side, so a client is free to wait around and connect to a new compositor. The compositor might not place the windows exactly where they were before, but there is nothing architecturally that forces clients to crash if the compositor crashes.
A single crash of what? I have used a Wayland only system for a long time and application-level crashes certainly don't bring down other applications much less the whole desktop.
Both window manager and shell were historically extremely likely to crash, whereas the display server was very resilient (and the session script would restart the WM and shell as needed). I'm not sure how separate the shell is nowadays, but more than just the traditional duties of a WM have been embugged into the display server.
1. ssh into a machine with a running session
2. start (something) that lets me remotely connect to it
Right now I have two working solutions for X11 (x11vnc, freerdp-shadow) but zero for Wayland. I think this is intentional because the venn diagram of remote-access-tools and malware has a large intersection, but it's very useful too!
That "with a running session" bit greatly helps here. While GDM allows you to have remote login and headless sessions [1], with SDDM you're locked out for the moment. There's plans to turn SDDM into a KDE-powered, more featured plasma-login-manager with KRDP integration, but no concrete development yet [2].
https://quantumproductions.info/articles/2024-06/krdp-plasma...
(I assumed being logged in is what you meant by having "a running session".)
I used GNOME for many years, but nearly every UX decision they have made in the past 20 years has been the polar opposite of my desires. I have come to the conclusion that the developers in the GNOME project don't want me using their software and I'm happy to oblige them.
But it needs a logged-in session, you can't get access to the login manager.
These might have something to do with it:
https://develop.kde.org/docs/administration/portal-permissio...
Is this specifically to do with screen sharing or streaming? I use it purely as a chat client under Wayland and it has generally worked fine.
(Now that I think of it, I've had a few weird crashes, but nothing which made it unusable)
To OP's point, assuming it's limited to Wayland, this seems reasonable to call out as "doesn't work properly".
I don't see anyone talking about a Wayland crash, it's about Discord crashing.
> I tried Wayland earlier today on my home lab with Plasma and FreeBSD. It seemed pretty great for a bit and ran my monitor at 120Hz.
> Until it hard crashed my machine after I opened discord in firefox. Konqueror crashed on opening.
I lost track of the indentation on my phone
I assume others are talking about the standalone client. Which, to be fair, I assume is also an Electron app but that's Chromium, not Firefox.
The only difference between Arch and any other regular distro is simply that in Arch there are no major upgrade versions, so any breaking changes you have to perform them manually. Period.
In the rest, they do it for you. But they update key components as well and/or stop getting updated at some point (same as not updating Arch).
For example, I am a happy Fedora user, but I don't get why they don't upgrade the Plasma or Gnome version in the same release but they do upgrade the kernel, when the kernel update may bring more breaking changes...
The recommended "solution" is to edit the .desktop file to resemble the following:
QT_QPA_PLATFORM=wayland ECORE_EVAS_ENGINE=wayland_egl ELM_ENGINE=wayland_egl SDL_VIDEODRIVER=wayland _JAVA_AWT_WM_NONREPARENTING=1 keepassxc
The main issue for me with keepassxc is the broken autotype on wayland
So they won't have to do.much for Gamescope, and the current hardware should support Wayland. We shall see with the new hardware coming out next year though.
I guess I have to buy a 4K monitor in future.
KDE had the setting to allow X11 apps to scale themselves (no more blurry XWayland apps) years ahead of GNOME.
I suspect the original commenter had an issue with GNOME specifically, as I've noticed it too, on Wayland native apps. GNOME handled fractional scaling poorly, and fonts didn't align to the grid right and looked fuzzy at anything that's not 1x or 2x scale.
KDE got this right from day 1.
It does, but not every DE expose that functionality. There is some command that should be DE-agnostic like wlr-randr that should allow you to do that.
I set DPI so that a 15pt font occupies 15pt physical space on screen. Not sure how to set DPI using fractional scaling.
I don't know whether GNOME supports anything similar, unlike KDE they really don't like giving users very many configuration options.
TL;DR their Wayland backend is incomplete, it accidentally got enabled for some users, run KiCad on XWayland instead until their EGL backend is ready.
In a Qemu VM a testing installation of Plasma+Wayland is dog slow and crashes the whole system. Using the workaround for X it runs faster and stable.
I think your post proves opposite.
Just so I'm clear: I still think it's too early to drop X11 support (even though Wayland has been basically fine for me for a long time).
FWIW, it is my understanding that XWayland is still supported, so it's not like your apps will stop working.
Also there needs to be an alternative for (or patch to) simplescreenrecorder that works under Wayland. I don't want use a complex thing like OBS to make a quick demo video to demonstrate something for a co-worker and stuff.
Applications generally work through XWayland. Accessibility and automation tools do not.
So I'm very skeptical of the coreutils rewrite. In the current state it's incomplete, slower (not optimized), and replacing all GPL code with MIT/BSD code also feels strange to me.
Oh, also Godot has a lot of issues on Wayland at the moment, specifically the Godot editor. I spent a long time trying to figure those out, because if I'm developing I would really rather be in a Wayland session where my DPI stuff works much better, but ultimately I resigned to just running the Godot editor only under an X11 session.
FreeBSD does have Wayland but it's not ready for prime time
And FreeBSD packages are rolling so I'm normally on the latest and greatest.
Or, what's so wrong with anything so people need to replace it with something else instead of improving it?
Let's say I'm an old man favoring improving existing stuffs instead of starting from scratch. I like debugging and wish to work as a sys programmer specialized in debugging and fixing/improving legacy codebase. But again I'm not really a sys programmer so I'm probably on the wrong side.
He later worked for Nokia, Intel and eventually his own startup related to VR.
During his time as a Google summer of code student, his project was to paralelize X code so it could run in multiple threads, making better use of modern hardware with many cores. His project failed. The reason: X code was so bad that paralelizing and making it thread-safe required so many locks that it ran slower! It was a better idea to start from scratch. I remember, at the time, taking a look at the source code and asking him why there was a X86 emulator built-in in X source code. His answer was that that was required to run some video BIOS on non-x86 computers, namely Sun workstations. That was the level of legacy code in X.
This is just an illustration of many problems X had. Vignatti was one of the X devs that migrated to wayland development. Many other core X devs did the same. People saying that X is fixable, that it can be improved or what else... These people may be right, but I trust X core developers more than these people when the subject is X development.
1. Security - Any program using X11 can read keystrokes, passwords, or the contents of any other window. Fixing this would break all existing X11 applications.
2. Performance - X11's client-server model doesn't work with hardware accelerated graphics, requiring hacks to get around. X11 is basically stuck with this legacy.
The ground-up re-design of X11 to fix those two issues is Wayland.
If you can't trust the process don't run it. If you have to run it, isolate all of it.
Wayland gives you neither the freedom to safely tailor your security policy, nor the security guarantees to warrant its inflexibility.
I mean, yeah, it does, maybe. So why bother creating a password to a service if their database is probably running Linux anyway and the rdbms is probably compromised and yadda yadda yadda. It's the kind of argument you can make for anything.
Also no - privilege escalation is not "numerous" on Linux. It's very difficult to do in practice. It's only really a problem on systems built on old kernels which refuse to update. But those will always be insecure, just like running Windows 7 will be insecure.
If you do it further down the stack, you break accessibility and automation even more... this has been tried. Doesn't work.
The end goal is to have actually working Android-like sandboxing rather than some broken firejail crap.
The last time I looked into it, I found out I would have to deal with each compositor separately. On top of that, the target apps would have to be written with the new API in mind.
I really wish they would figure this out. It just feels like with Threadripper etc the time is perfect for a return of thin-clients/not-so-dummy terminals running X11-like applications over the network on a server. Especially for development where many of us are running under-powered laptops and could use the boost to compilation from a beefy machine.
I wasn't talking about X11, just that capability.
Never heard of Waypipe before, but it was mentioned in a sibling comment, and that might be exactly what I'm looking for.
If anything, the variety of alternative solutions for that today -- everything from single-app to high-res full-desktop game streaming -- are much more robust and viable on modern networks than the X approach ever was, even if it was a neat-o "freebie" thing that fell out of its design. You get what you pay for, I guess.
When you start to consider things such as HDR, hardware planes (important if you want energy efficient video decoding) etc, the protocol just doesn't make that kind of thing easy, compared to Wayland which does by it's use of surfaces etc.
The redesign also reflects their priorities. The best analogy I can come up with is imagine a small group of people maintaining an old car frame and mechanical workings. They work hard to keep the engine running, but it's in a chassis with leaf springs and direct steering. It also has lots of vestigial things like a hand-crank even though most people have been using an electric starter for years. Other people use this as a platform to make complete cars with body &c. but this is both too much and too old for the small group to maintain themselves.
So they build a new, more modern engine and wait for other people to build a car around it, which is more sustainable amount of work for them. Lots of other people complain that the engine isn't a car, and when they use the engine with one brand of car, the brakes don't work and when they use it with another brand of car, the steering doesn't work. This makes sense, since previously the underlying platform implemented much of those, but now it doesn't and everyone is figuring out how to build those and couple them to the new engine.
Eventually you reach the point where each brand has created its own brakes, suspension &c. that mostly work about the same, but the only actual common component is the engine now. That's about where we are today.
Isn't wayland just soem protocol? so did the ex X11 devs wrote soem specifications and then soem went to GNOME< some to KDE and others are just editing the specifications ?
I think the issue is that there is no wayland library that a DE can use so everyone is forced to implement it as part of the DE , so the end result is a lot of missing features and incompatibility.
I could be wrong, I still run Linux but I decided years ago to stop following the Linux drama, I will use Kubuntu LTS and hopefully when it drops X11 the Wayland implementation and the X11 fallback would be usable.
> The wayland protocol is essentially only about input handling and buffer management
So sending input to clients and managing the buffers needed is what wayland implements. Everything else is either done in the clients (e.g. rendering) or the compositor (pretty much everything else).
Note that this is a subset of what X11 did (though rendering had pretty much already moved to the client for modern applications). X11, of course, handled input, and it also provided an IPC mechanism (which is how clients e.g. communicated things to the WM). Wayland, at its core, is just those two things.
Nobody is stopping you from pulling together a group and working on all this free software, forging forth on Xorg, and forking or maintaining the DEs to work with X11 as long as you want to maintain it. I think the group of people who wants to do that will be quite small, because I've really only seen the sentiment from people who have never actually hacked on an X11 codebase and worked with the protocols themselves. You can want X11 to stay alive, but you can't really demand the people who don't want to work on it anymore to keep working on it.
Not saying that is what happened here, but sometimes the answer is because the old one is just not fun to work on anymore.
There is some interesting reasoning behind that (which I will let more learned people expand on) but since I'm not doing the work I'm pretty zen about just accepting the decisions of the people who did.
1) it would really be nice to renovate that old house in the city center of an old Italian town! Oh but hold and behold: you'd have to spend hours, days, months, even years (I am not kidding) just waiting for approval and agreeing on what you can and cannot do with the house. And it would cost twice as much as building a new one. And the new one would have better insulation and a modern layout, and be exactly like you want. That's why it's not always the case to fix and improve an existing thing.
2) it would really be nice to fix that car from the '60ies. Oh but hold and behold: the design doesn't really allow you to have all the safety measures of modern cars. And the maximum speed is going go be 65mph on a good day. And it's going to cost you twice as much as a new car, OR you'd have to learn tons of mechanical stuff to be able to fix it yourself. That's why it's not always the case to fix and improve existing things.
3) it's just more fun to build new things (at least for some people). It's open source. People do this for free, to learn and enjoy their time. They can do whatever they want, and they decided to go with the shiny new thing. Is it better than fixing and improving an existing technology? I don't know. But apparently it's more fun! :)
Ah you mean like in the wayland-protocols repo? :)
(not disagreeing with your actual point though)
This 12 years old video explains it better than anything I ever seen:
Tech debt. The X11 dev have thrown the towel and have prefered working on something they deemed more maintainable.
not claiming that it applies here, but I wrote some small programs where writing my own library from scratch too less time than I spend on trying to understand existing one
In another case I was unaware that existing solution exists and I tried writing my own one (then migrated when I realized that surely this kind of thing was done and people on local hackerspace chat pointed out that it sounds like Ansible).
For that matter running joke on hackerspace chat is about spending 500 PLN and 20 hours on building a chair to save 400 PLN. Because in this case hobby playing with a wood was actual point, not maximum effectiveness.
Similarly, this year I planted basil - and fixed costs for pots etc are large enough that it will never make economic sense. But looking at plants growing from seed (and then eaten prematurely by some caterpillars) was really cool. LARPing a farmer and seeing how plant grows from tiny seed to about 50 cm plant was really cool and I recommend it.
>It's the community that has by and large decided to move to maintaining other solutions. If you still want to use fvwm you can still run it on arch with x11 until x11 is not maintained and the kernel breaks it somehow
well you just framed it perfectly; it's still forced on the end-user regardless of whether or not you want to call it 'linux' or 'the community that controls and steers linux" .
I don't know about you, but corporate dictates always leave a bad taste in my mouth.
The Linux software environment is more broadly controlled by corporations, but that goes for every single mainstream operating system.
The narrative that everything is corporate and greed is, imo, a deep deep dis-service. Incredible things are happening on the edge, and there's nothing else on the planet remotely resembling the conjunctive discollaboration here. Folks have incredible leverage from existing open source works, & add their own sparkle, time and time again. (Nearly never does this box us in.)
For sure there are big projects too, with huge corporate influence and millions of users.
But it is a deeply rotten proposition to me to try selling some corrupt world case, that this land here is just as rotten and poisoned as the application/apppliance-ized rest of world. That there's coersion. There's some being left behind the pack, some, but so little. "Linux" is still the best freest most augment-intelligemce computing out there by a light year, and it's trends are healthy.
(Wayland in fact has improved & strengthened that stance, freed us from a nasty monolith that everyone had to use, and given us actual freedom of implementation. Wayland is part of the liberation, the addition of choice & liberty. It's wild to me that people seek those old chains.)
That said, you cannot run Wayland apps this way, it is purely for X11 only. If applications/rendering toolkits remove X11 support, you're out of luck. But Wayback may actually be a reason for some of them to keep maintaining X11 backends a bit longer, anyway.
1. Applications or toolkits only supporting Wayland. An example of this is Waydroid, though thankfully that's the only example I'm currently aware of.
2. Desktop Environments only supporting Wayland. Examples now include GNOME and KDE.
3. Drivers only supporting Wayland. I think this may be the case of some "exotic" systems; I believe there are some postmarketos systems that don't have graphics with anything else. Thankfully, the existence of Wayback means this is probably a non-concern.
That’s how memos work.
But if KDE is no longer willing to provide the single most important feature of all - actually working in the first place, rather than just denying that bugs exist - I guess I'll have to hunt for a new DE.
It looks like the only serious possibilities are:
Cinnamon - my gut says this might have the most users? Often cited as the reason to use Linux Mint by people who don't know the difference between a distro and a desktop environment.
LXQt - apparently has stabilized enough to obsolete LXDE (hopefully it isn't being developed by headless chickens like GNOME and now KDE)
MATE - why must there be so many GNOME forks? (I know why) ... does this one even have anything to distinguish it?
Xfce - the longest stable history as its own thing
I think they explain your options quite well in this blog post: https://blogs.kde.org/2025/11/26/going-all-in-on-a-wayland-f...
As they say, distro's like "AlmaLinux 9 includes the Plasma X11 session and will be supported until sometime in 2032".
For me personally, the first dealbreaker I keep hitting is the fact that input-method-adjacent keyboard logic is quite broken (necessary if you ever want to use a language other than English, even temporarily).
There are also, of course, the innumerable minor bugs that will be fixed from one release to the next (but also replaced by other bugs). The number of these decay exponentially and it will probably be a decade or so before Wayland sessions becomes as stable as X11 in this regard.
There are quite a few cases where applications auto-detect that Wayland is running and as a result run in degraded mode, intentionally or unintentionally. I remember some bug with menus not working properly ...
And scaling, often touted as one of Wayland's features, often works better under X11!
Also I don't understand your relation between a vpn and a graphic protocol.
Imagine you have Cisco VPN and you want to connect - you connect and then close the dialog. It is just gone. Why? On wayland no tray icon is shown.
Now imagine you have Fortigate VPN and you want to connect - you enter the IP address and click connect but nothing really happens. Why? No confirmation dialog was ever displayed in wayland.
Now imagine you have palo alto vpn and you try to connect ... good luck.
Can you work around that by using CLI? Yes, but this is THE issue with wayland. Until critical business apps work, x11 version must be supported, otherwise plasma is only useful for gamers and those that do not have to use their pc for work. I am not against switching to wayland, I just want a reasonable roadmap, not something like - we are going to break your major apps next time you upgrade.
edit: I just mentioned VPNs because they are the first in line when it comes to work from home. Don't let me start on remote support or remote control apps.
Having said that, deprecating x11 completely is the one motivation for dev to fix bugs and/or find ways. Wayland really started to catch up with missing features when some distros like Fedora started using it by default.
If you want to stay on legacy stuff such as x11 while the remaining stuff is fixed, there are plenty of long term support distros out there anyway. You aren't forced to use the latest bleeding edge kde version available.
As said in one of my comments - this could very well mean that the next version of Debian will have KDE Wayland only which would already mean <5years of support today. I am not saying wayland is not catching up, I am saying enterprise apps are the issue.