From all the criticisms leveled at Wayland, this is definitely the strangest I've ever heard.

I really cannot thing of any existing functionality ever broken by a new release of wayland-protocols, neither by a plain bug nor by a bad interaction. No doubt someone else will be able to recall an example, but it's really not a common thing.

This is partially because the governance model and community mindset is the opposite of what you describe. Inclusion of new protocols in the stable release requires existing, proven implementations and consensus across multiple implementors, making it a high bar. New proposals run a gauntlet where pretty much everyone is looking at the consequences in detail.

In fact a more common criticism of Wayland is that the focus on high quality and the consensus requirement are too strict and have slowed down filling in feature gaps users need filled faster. This argument I think can be successfully defended against - mainly, that it helps avoid the mess X11 became over time -, but at least has some basic merit in reality and is an avatar for genuine user pain.

As for X11, as someone who had to implement a lot of X11 specs over the years, I can tell you that their provenance between X11 itself as well as ICCCM and EMWH had plenty of super dumb ideas and cruft and inconsistencies from lack of foresight and eventually datedness. You don't want to see the towering stack of hacks and heuristics we used to have to ship to make X11 behave somewhat consistently and sane :)

In short, with all due respect, but I think you really don't know what you're talking about. We really should resist this type of narrative reality distortion field on an engineering forum.

This car runs KDE Plasma's KWin, along with many other Mercedes-Benz models currently launching:

https://youtu.be/wo5As8et1G8

https://youtu.be/pqJ-9SUPFwY

Notably this deployment doesn't use any of the old-gen automotive Wayland cruft like ivi-shell though. It's pretty much the desktop stack now.

It should be mandatory wherein the title bar is expected/desired by the user and not inherently the responsibility of each individual app by default. The wm should have the capability of drawing a titlebar for each app and do so by default unless the app opts to draw its own OR the user configures the system to not do so.

Wayland still doesn't support screensavers last I checked, which is wild to me. Truly bizarre that such longstanding feature is just absent.

Yeah, most of those real gaps have been solved at this point. I'd encourage you to give it a shot now with Avahi

For the server/compositor.

Not for the client, or if you want to write a wm and is forced to write a compositor.

And actually I'm not even even convinced about the server if talking about a minimal server like this that insists on DRI/GBM, and ditches all the old rendering cruft.

Afaik Xorg is 'only' like ~500k lines of code, which is not huge by the standards of large porjects. In fact, one of the major counter arguments against Wayland, is that the compositor + a few core libs, like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code (which has a ton of unused cruft).

What's the simple way for a bash script to get the title of the currently focused window? In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.

It shouldn't be hard, all I want to do is fuzzy match window titles to named audio streams in pipewire, but "Oohh noo that's a security flaw!" say the patronizing Wayland developers who care more about making their own lives as developers simple than supporting basic desktop functionality.

That sounds cool, but TBQH the last thing I want to do is make myself dependent on some obscure piece of tech I've only heard of once before (just now.) My plan is to keep running X as long as I can manage to make it run. If river finds traction and is well known to me in 10 years then I'll consider it then.

This is one of my big problems with Wayland; the fragmentation of Wayland imposes an unacceptable cost to picking the wrong DE, whereas with X all my tools for X still work regardless of my DE.

I don't have any interest in river. I have my own wm that does exactly what I want, so why would I switch?

Wayland doesn't solve any problems I have, and would create new ones, such as having to adapt to new tools or write my own compositor.

Battery life just isn't a relevant consideration for me.

Tech is full of examples of 'successor' technologies, that were aiming to provide a clean rewrite without legacy, which then got bogged down with supporting a bunch of corner cases and accumulated their own share of cruft and could be no longer be considered a cleaner alternative. All the while the majority of the userbase being stuck on the old platform because the new one is buggy and doesn't offer anything tangibly better.

Vulkan, various node replacements come to mind.

Wayland at this point has existed almost as long as X11, longer if you only count the Linux years, yet its still not quite there.

https://news.ycombinator.com/item?id=46382947

Read this including my response.

A lot of X features are actually Xorg features and they only work because there is a single implementation that everyone tried to integrate with.

Turns out the moment there are two implementations, which is hard on X and easy on Wayland, you can no longer rely on targeting a single implementation for direct integration anymore.

This means a lot of non-X but Xorg features need a protocol extension in Wayland, because things are being standardized that previously were exclusive to Xorg.

> I think the problem is that people wanting to build that and being in position to (being paid for by their employer), are fed up with X11.

I think one of the intrinsic problems with relying on developers being paid by their employers is they can easily become personally disinvested from the thing they're maintaining; they get paid well, the day-to-day grind gets stale, they get interests and hobbies other than computing but keep working on the thing because it's their job. Eventually they find that just buying a Mac is an easier lifestyle at home, and gradually maintaining X transforms from something they do out of passion for the project into something which is just a job. So they look for ways to make their job easier, hit on the classic "instead of maintaining old thing it'll be more fun to make our own", and because they are now untethered from the needs of real users they only need to make sure the new thing supports the bare minimum to keep their employer happy. They no longer care how real users feel, any use case that isn't required in the checklists approved by management get deliberately abandoned. So we end up with Wayland lacking common sense desktop features in demand by users for years because it's simply not convienent for the developers who are now dispassionate 9-5ers.

I prefer to take my chances with enthusiasts keeping X working on shoestring budgets. Maybe a few more years of development of coding models will make ongoing maintenance easier going forward and I'll never have to switch. I'm willing to make that bet. If it turns out that in 5 years I am forced to switch, at least by then Wayland will be five years more mature, and maybe my cynicism will even be proven wrong by then and Wayland will be good by then (but I'm not holding my breath for that.) Anyway, I have nothing to lose by using X as long as humanly possible.

[dead]

> This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day.

You two here don't mention any of the reasons. It is hard to discuss this when there are no specifics, so what was needed, and what was not added?

At around that time X.org worked entirely fine for me, sans some NVIDIA driver config I had to set up in /etc

few years after even that wasn't required.

Yeah it missed some features I could theoretically use in 2025 but I didn't had different DPI/refresh rate displays back then and those could probably be put into X11 protocol just fine

Technically Xorg can handle fractional scaling across mixed dpi and refresh rate monitors, but it requires support from toolkits, window managers and applications which means the developers of all of those (or at least toolkits and window managers) need to cooperate. At minimum, you need toolkit support for the most basic. AFAIK Qt6 does have this support and should be able to handle fractional scaling across mixed DPI monitors but not in an ideal way since for better experience you'd need the app/toolkit cooperating with the window manager instead of the toolkit trying to do everything on its own without knowledge of the rest of the desktop. I wrote about it in detail here[0] but the gist is that it is largely an issue of getting the developers of various projects to cooperate than some feature Xorg itself lacks (it doesn't). Wayland had it easier here because it started from scratch and developers had to worry about those things for supporting it. On a more positive note, because of Wayland (and Win32, if a toolkit support scaling there) the the hard part of the work on the toolkit side should already be there.

For VRR the issue is how current desktop compositors render their output, though it should be technically possible to make a Xorg desktop compositor to use separate outputs for each monitor (may need to use Vulkan with custom barriers for vsync though, this is something i've only ). The alternative is to not use a desktop compositor at all, which is what i'm doing (since i also dislike the desktop lag introduced by desktop compositors). I have a 165Hz VRR monitor that i used it for a bit (even connected a separate 60Hz monitor for a bit) and worked fine, though eventually i disabled the VRR functionality since at 165Hz tearing is almost imperceptible (and it never bothered me even on 60Hz monitors anyway) while my monitor is one of those that have some annoying flickering with VRR enabled. In any case, the issue is with the setup and desktop compositor used, not with Xorg itself.

Of course from a user's perspective all these most likely do not make much of a difference.

For HDR there is no support for it Xorg though. Personally, the main use for HDR would be either some movie or playing a game, i.e. fullscreen apps, and switching to another virtual terminal running a Wayland compositor (or just Gamescope) just for those is perfectly fine - having to press ctrl+alt+f1/f2 instead of alt+tab is not a deal big enough to change the entire desktop setup i've been using for many years :-P.

[0] https://news.ycombinator.com/item?id=45858043

Why? People complain that the YAML specification/protocol is too complex. This may be, but I found using YAML much, much easier and nicer than XML. So to me these two things are not necessarily interconnected. You can have a great implementation and a crappy protocol; but also a great protocol and a crappy implementation.

Me too!

The point of the protocol spec being minimal is that it enables a wide variety of implementations, something it definitely succeeded at.

I still don't know how people twist this obvious success into a failure.

To my knowledge, X11 didn't offer a comprehensive accessibility API either - there's no Linux equivalent of stuff like MS Active Accessibility or MSUIA on Linux.

Even back then Qt, GTK and everyone else offered their own API and screen readers needed to integrate with every single one - this didn't really change under Wayland, only the sandboxing makes certain operations harder, but the accessibility story on Linux is not great, and never was.

It's not a single thing. Trying to get a screen reader on GNU/Linux is awful. Getting dwell click is easy on X11 and... some Wayland implementations. Or if you like: It was bad on X, and is worse on Wayland.

"The devs of x11" is a wide category, considering how many X11 devs weren't even born when X11 was first written. Plenty of X11 devs objected to Wayland and tried to patch X11, but when half the devs decide they want to write a replacement and put the original into maintenance-mode, there's not much you can do.

and failed to learn any lesson from X11

Yeah, no, the X11 devs made pretty much all the wrong tradeoffs for me.

“Obsolete” means that a replacement exists which is as good as, or better than, the thing it aims to replace, in every significant way.

X11 is far from obsolete.

In what way was X11 obsolete in 1987?

Uh, there are plenty of extensions. Session management perhaps? In experimental state.

Wayland:

* straight up doesn't work on at least one of my laptops (driver problems AFAICT)

* does run on the other one, but crashes at an alarming rate compared to Xorg

* breaks all of my accessibility tools (some have (worse) replacements, some don't)

HiDPI scaling (not even fractional, 2x aka 200%), for some apps like OnlyOffice, VMWare Workstation, but not only, on Ubuntu 24.04. Had to switch back to X.

You can blame the apps all you want, but it's a fact of life, and Wayland has been around for 18 years.

At this point you'd hope they'd pull an early 90s Microsoft: https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

I don't know how you can read about the many experiences people have with Wayland not working - even now, let alone 2020 - and conclude that "all things work".

I think we are finally at the point where you can say most things work and it's silly to go back to X11, but even so Wayland has clearly been a huge failure.

> Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.

> [...]

> By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.

So it's a great analogy. Wayland started out proudly proclaiming that it intentionally didn't support features in the name of "security" but everyone should "upgrade" because this was totally better, and has been very slowly discovering that actually all the stuff it willfully dropped was useful and has mostly evolved back to near feature parity with Xorg.

There’s a reason they’re called Pythonistas

It’s always drama and they’re the center of it.

(I’m joking of course, Merry Christmas)

Python is really one of the worst designed languages. It always baffles me that people recommend it to beginners.

Nvidia had a driver for Vulkan for Kepler which launched in 2012, AMD had support all the way back to GCN 1.0 (also 2012). Intel did have issues supporting it, I can't recall if it was for hardware reasons or just lack of desire for a driver.

Vulkan has substantial advantages for multi-threaded code, as well as exposing the underlying asynchronous nature of running code on the GPU. The kind of thing you want to be able to control with a desktop compositor where controlling vsync and present timing is very important.

There are Xorg and XLibre for pre-2016 hardware.

Yeah, my bad sorry.

It really doesn't. The security benefits of Wayland are about isolating applications from each other, which this still has.

Also that's only really relevant to this running in a container. My point was that you can have headless Wayland.

And common sense mitigations: if a new program I've never seen before drops an actionable control under my cursor, maybe just default to not immediately accepting the next input to it so I have a chance to see it.

It does on Android

Happened a lot in browsers.

My parents did fine with Linux. My mom still does; it's certainly less maintenance effort from me than Windows would require.

It was fine for non-technical users since at least early GNOME 2, if you're ready to help them set up and maintain. Semi-technical users (Windows power users, gamers, &c — people who like to install and configure things, but fear the deep dark abyss of the terminal) were and remain more problematic.

Unity days were the nadir of linux desktop ux — it was when Gnome 2 was gone, and 3 not yet there. Still better than contemporaneous Windows 8, though.

I can bet there’s no OS that are easy to install for a non-technical user. And that start from booting the installation media. Give someone a OS with their software already installed and they will use whatever OS that is.

People are always task-oriented, not tool oriented unless they’re nerds.

I had Kubuntu installed on my grandfather's computer for a year. I ended up replacing it for Windows because my aunt likes to install stuff on it. But my grandfather was happy with it. He only needed a working web browser and a program to use the TV tunner.

"Oh no" is what you'd say after getting yourself some nice RSI and discovering that your hands hurt due to mouse or trackpad usage.

> Neither have keybindings that make any sense.

I can agree on Windows, but there is no such thing as "keybindings that don't make sense" on a proper Linux WM given that you can literally make up any keybindings you want. I mean this strictly from a window management perspective, yes applications running in those windows have often got their own idea of what good UX is, and this clashes. That's just a trade-off of Linux and to a lesser extent Windows not being complete walled gardens.

> that have never used Mac OSX

I have _used_ Mac OSX. It was and continues to be a confusing experience every time. I'm not saying that this would be the case if I bothered to learn it, but in all the times I have used it, I have failed to see any feature which would make me want to switch to it over i3 or which I feel like is missing in i3. Really it doesn't seem like there is any way of making it act remotely close to i3. Tiling as an option on top of whatever Mac OSX has is just as appealing to me as tiling on top of what Windows has.

> Unless you want to copy and paste, or have consistent key bindings cross applications, or take screenshots. Sure

I've never had copy and paste fail on Linux. The only issues I've had is with more modern applications not implementing the selection properly which is a feature you don't have on windows in the first place. No idea about Macs.

Screenshots have always and will continue to work (the way I want them to) because I can, as mentioned, bind any key to any action.

I've definitely experienced parts of the windows UI crash. explorer.exe isnt just a file browser, half of the UI runs on top of it.

Xhost and xapps

The server is not usually a remote machine. The server is the app accepting remote connections.

This has been true for decades.

https://en.wikipedia.org/wiki/Server_(computing)

This is obtuse.

[dead]