Don’t even try to get away with “well, it just works for me” or “but Wayland no worky”
Wow, amazing rhetoric right there. Paraphrasing an argument in dumb language and just stating it’s invalid without any counterargument.
From a technical point of view, great article. But “X works, Y does not” is as valid as an argument as they come. If using X breaks Z and you need Z, fuck using X, I will use Y. Even if Z is “bad software”, I may need it.
If using X breaks Z and you need Z, fuck using X, I will use Y. Even if Z is “bad software”, I may need it.
The end of the article directly acknowledges it, mostly with respect to accessibility.
Don’t even try to get away with “well, it just works for me” or “but Wayland no worky”
Wow, amazing rhetoric right there.
There’s an inverse rhetoric that’s just as bad, if not worse because it’s never spelled out explicitly:
If a piece of hardware doesn’t work on Windows, it’s the hardware vendor’s fault.
If a piece of hardware doesn’t work on Linux, it’s Linux’s fault.
Why? Because my webcam/printer/wifi works in Windows, so if it doesn’t work on this new Linux thingy, it must be the new thingy’s fault, right? Don’t try to muddy the waters with “the vendor didn’t support Linux” or “the vendor didn’t write a driver”: the thing works on Windows, it doesn’t on Linux, it should be obvious to any child that Linux doesn’t work. Now stop bothering me, I have real work to do.
Or something. Actual late adopters are never that blatant, they tend to have shorter, less refutable quips, like “Linux isn’t serious”, or “why would I ever use RISC-V?”, or “this new language lacks tooling”. But the running theme is the same: burdening the new thing with unfair proofs. Here there is a case for X’s API being fundamentally outdated. Making something better (like Wayland is attempting) requires breaking it. Obviously that comes with growing pains, but blaming Wayland for this feels either ignorant or disingenuous to be honest.
Now the article could explain all this in that many words, or it can use the shortcut it did: Don’t even try to get away with “well, it just works for me” or “but Wayland no worky”.
It’s a difficult balance to strike, on two accounts:
Nuance requires more text, which in many cases detracts from the main point. I routinely write nuances and caveats in my own essays, only to axe many of them just to keep it short and to the point. Sometimes those deliberate omissions are mistaken for ignorance.
Sometimes the best response is a dismissive coarse laugh. It’s a way of conveying that the attacked opinion is so ridiculous or outlandish, that whoever holds it should quietly change their mind in shame. It’s a polarising double edge sword however, to be use sparingly and carefully. In the context of this post it’s a harsh introduction, but it does help set the tone of the entire post, which is about depicting X as a crumbling old dinosaur we should stop feeding as a matter of mercy.
There’s also the target audience to keep in mind. Public writings are accessible to anyone, but they’re rarely intended for everyone. Some people would be more swayed by a nuanced take void of mockery, but for me the tone was very effective at conveying how strongly the author felt how bad the X situation really is.
And I didn’t know about battery life. Crap, I just set up XFCE with XMonad, which I’m assuming are under X… it would be nice to have a Wayland alternative. (And I’m still undecided on how much I actually need a desktop environment. Because ultimately I don’t need much: Ethernet, WiFi, mount USB drives, a way to transfer file to and from my Android phone, sound, screen brightness… the list isn’t short, but it’s still pretty bounded.)
A burned out OS dev is ranting with their friends after work. They’re just off a long shift. They’re being acerbic. They’re saying the things nobody says but a lot of people think. Now we’re doing a close reading of the transcript as if it’s a corporate press release. This is how it feels to me.
Is it actually true? Many of the things said in this post aren’t, so I’m skeptical of this too. Would be interesting to run a test.
I personally find it somewhat hard to believe… but plausible, there’s times when I see the X server on my box chewing through some more cpu than i’d expect necessary.
I’m talking more about factual errors than fallacies but three examples:
Multi-monitor scaling / Nonexistent on Xorg
Just plain false, I’m using it right now. (But the later point about getting the desktop settings being unstandardized is a fair point.)
the [fractional scaling] story with Xorg is still in integer scales.
Again, not true.
You’ll be spending more time in a fetal position sobbing than doing anything productive if you even try and interact with X.
lol. This is kinda subjective so maybe it isn’t fair to put next to two factually false statements, but it sounds like she doesn’t actually know what she’s talking about - most Wayland proponents obviously know very little about X so unsurprising - and the later thing about “To get the full experience, I’ll be writing a mini Wayland server and X client, which should teach me a fair bit on how all of this works” sure indicates she probably doesn’t even know the basics.
oh thanks, i know i shouldn’t assume but whelp. i’ll edit that.
I actually would be interested in reading the experience report writing that program though. A lot of newbie X tutorials and rants make a big deal out of the various steps in a hello world, so you go into it thinking it is going to be a mess…. but it actually isn’t much different than a hello world on, Windows, for example. And you can skip some of the steps on computers nowdays since you can pretty safely assume there’s true color support, etc. (until someone plugs in one of those new e-ink things that are all the rage :P but still)
And people criticize the Windows hello world too. There is a fair argument to be made that you can skip the steps and use the defaults instead - indeed, this is the case with most the libraries on top. auto window = new SimpleWindow; window.eventLoop(); for example with my lib… but there’s times when you actually do need to know how to break down the tasks. Maybe you actually do want the window hidden until you’re ready to show it. Maybe you do want to create a subclass instead of taking default behavior. Maybe you actually do want to support a 16 color display. Then new SimpleWindow(); isn’t going to cut it, and the lower level apis show their value.
Xlib itself is a lower level api (not quite as low as it gets, it has some conveniences built in, but not many), and X11 is a lower level protocol - explicitly being “mechanism, not policy”. Then you gotta read the other manuals on top of it. But… again this isn’t that different than other platforms. There’s the Win32 api which does provide some policy but you are still supposed to read the human/computer interaction guidelines and apply them.
I’ve never personally programmed something on Wayland but i wouldn’t be surprised if its low level functions take some boilerplate you don’t need to edit 95% of the time either.
Here there is a case for X’s API being fundamentally outdated. Making something better (like Wayland is attempting) requires breaking it.
The article disagrees with you in its conclusion: “You could probably add all (well, most) of these to Xorg, but not without some pretty fundamental changes, rewrites, and extensions.”
The wayland faq also disagrees with you. https://wayland.freedesktop.org/faq.html#heading_toc_j_5 “Why not extend the X server? Because for the first time we have a realistic chance of not having to do that. It’s entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X. “
In other words, they broke things because they wanted to, not because they had to.
At that point, it is 100% their fault when things that used to work on Linux no longer work on Linux. They deliberately broke it.
What’s different now is that a lot of infrastructure has moved from the X server into the kernel […] or libraries […] and there is very little left that has to happen in a central server process.
But we can’t ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to an optional code path.
Simplicity requires breaking APIs at some point. Even I can’t make the simplest thing out of the box, even for something as easy as a cryptographic signature API. Had to break the API and bump the major version to get from vtable abomination to the simpler (and more flexible!) solution I have now. I can imagine the constraints of a much bigger, much older project like X.
And to be honest, I wouldn’t be surprised if Wayland have to suffer the same fate a couple decades from now.
I don’t think they’re saying you’re not allowed to do a different thing, rather that at this point any interoperability issue between Wayland and Z is probably on Z. You aren’t considering the rest of the paragraph which frames the discussion as
X11 is, to put it simply, not at all fit for any modern system.
A piece of software being incompatible with Wayland does not improve the standing of X11, it introduces the constraint that it’s use requires X11.
X11 being unfit for any modern system does not make Wayland magically fit for a modern system. Wayland proponents need to understand that the introduction of superseding technical requirements (e.g. around rendering and input – huge improvements by Wayland) does not invalidate adjacent functionality that applications have come to depend on. For example, applications that need to know their own location on the display are not bad software. It is just software that is inconvenient for Wayland developers to support on some platforms. It does not matter if there is a Wayland protocol for it because the most-used desktop environment has no intention of supporting it. At the same time they have broken Xwayland rendering so compatibility shims like GDK_BACKEND=x11 don’t work reliably either. So now huge swaths of Wayland users cannot reliably use software that requires functionality that is available on nearly every other modern platform. Users are now left with two options that are both unfit for a modern system.
For example, applications that need to know their own location on the display
What kind of application needs that? I’m not sure even a screen recorder would need to know where other applications windows are located, as long as it can record their contents.
This article has a good breakdown of window types and IMO gives a fair description of the conflict. The main one that still doesn’t work broadly on Wayland is what they call satellite or toolbox windows. These used to be common but got a bad reputation, probably for the better, because they usually got sloppy (e.g. GIMP until about 10 years ago). However there’s a lot of applications that make better use of knowing and setting window coordinates. One I’m partial to is what I call “buddy” programs. I maintain my own diagraming software that is essentially gvim w/ a plugin that collaborates with a rendering server and an image viewer. It originally used Xembed to have gvim embedded in a frame along with the image viewer. Xembed is not supported on Wayland and while there is a protocol for sharing rendering surfaces the GTK maintainers have no intention of refreshing their “socket” feature to use it. The program has an alternative mode where it can collaborate with an external viewer. They are independent processes and windows but it is helpful for them to know their positions relative to one another because they would like to reposition toolbars to be on the side nearest the other application. Wayland designers use inter-application window position as a security bogeyman but this use case doesn’t even really need to know the other application’s position. It can do a pretty good job if it just knew it’s own coordinates in the desktop. i.e. if it is on the left edge with room to the right then the other application is most likely to be to its right side.
Anything that has floating panels benefits from being able to have policies for placing the panels such as put it close to the focused document window, but not overlappying, unless that would be off the edge of the screen. Applications that manage multiple windows in different contexts benefit from being able to create new ones near others.
I’m not familiar with such applications to be honest. I would guess, that in most cases you want to create the new window near the focused window, and that’s a job window managers do right now. The one case it would break down is when we want to create the window near a window that is not focused (and possibly in another workspace while we’re at it). I guess it has its uses, but to be honest this feels fairly niche (though never having ever needed that I do reckon I speak from ignorance).
It’s a UI pattern for a pop-up thing that inspects another thing. Most things on OpenStep can be inspected by hitting meta-I. Ideally, the inspector window should appear close to the thing being inspected.
Applications whose purpose is to move other windows, like devilspie2. I have a peculiar way I like my apps arranged, and devilspie2 lets me achieve that, without having to find a (non-tiling) window manager that supports the kind of rules I can do with devilspie.
So you need to do window management without relying on the window manager… seems to me the real problem is that existing window managers don’t solve your problem, and you ended up working around that.
This is super-niche, but I wrote a 3D viewer application that displays a composite image from two USB cameras ( https://github.com/classilla/camaglyph for devices like the Minoru). Because of the fixed way passive 3D displays are polarized, the window needs to adjust which line it displays where based on its absolute Y position, or otherwise the polarization order is wrong and the wrong image is sent to each eye. I can’t do this in Wayland.
I imagine the Wayland developers would respond with something like “add this yourself” or “nobody does this.”
Niche or not, there’s no substitute for knowing at least the polarity parity of your absolute position. And I don’t think ignoring 3D monitors altogether is a good move for the future. They may get eaten by VR goggles, but I’m not sure the writing is on the wall yet.
Moreover, letting applications know where their windows are (after all they already know how big they are), seems much less disruptive than letting them chose where to place them. You may have a case.
Which version of Wayland are we talking about? The Gnome, Plasma or wlroots version? The community doesn’t seem to even agree on standards and each one of these requires their own portals.
X11 is, to put it simply, not at all fit for any modern system.
Funny, it works on my modern systems. In some ways better than Wayland and in some ways worse. I use X11 primarily, but I have a wayland setup I use on occasion.
There are better ways to convince people than condescend. The technical portions are fine, but when you start out with “your reasons and opinions are wrong” you put people in defensive mode and whatever valid points you have to make have a much harder job to do. I haven’t quite figured out why smart people act like this, but it’s endemic in technical communities.
Back in the bad old days of X11, that was a real problem. Sun, DEC, SGI, and everyone else’s X11 implementations each had different extensions. Some of them were amazing. SGI had GLX and so could run 3D accelerated graphics on their systems. Sun had XDPS, so you could send PostScript drawing commands directly to the X server for print-quality text and graphics.
Gradually, the set of useful extensions became common. Things like the render, composite, and damage extensions gave, basically, a completely new set of core abstractions for implementing a compositing display server and just using X11 as a command-encapsulation protocol. XACE provides fine-grained access control to X resources (sadly, no one uses it, they pretend it doesn’t exist to justify Wayland).
These days, even non-X.org X servers provide the same set of core extensions, to the point that they’re effectively an X12 protocol: you probe for them, but failing to run if they’re not there is totally fine because they’ll always be there.
Wayland has not yet gone through this process. Every compositor provides a set of extensions, many of which are necessary for a lot of tasks. Some of these are compatible, some are not.
Xorg, from the very beginning, only ever had to deal with one display. It did originate from around the 1980s, after all. Having more than one display wasn’t even a thought in their mind, let alone ones with different resolutions and scales. The official docs even consider a “Display” to be the entire Xorg server, with all of its screens combined.
This is such dishonest argumentation. First of all, it is simply a lie that the creators of X weren’t thinking of multiple displays and multiple resolutions. The trade-offs were simply different then. The architecture of X, including having a display server at all, was meant to facilitate many different screens being connected to the central computing resources. It happened to be the case that the volume of data used and the amount of drawing needed to be done meant that on balance it was better to transmit the drawing connections over the network and have a display server drive each physical display. By pretending the creators of X couldn’t have considered this they are trying to make the reader feel as if the X creators are people so unsophisticated as to be unworthy of association.
Probably more importantly though, they speak of X as if it hasn’t been updated since the 1980s (above) but also try to paint it as just some of it’s extensions (below).
When you have just one monitor, it’s all fine and dandy - your game can go right to the display. But several monitors gives you one giant framebuffer for your compositor that draws to all your displays. Xorg doesn’t do normal flipping with double buffering like a “normal” display server would do, as it instead has one framebuffer that it continuously draws to, and expects the hardware to read it once in a while and display it.
Xorg has an extension to do this in Xinerama. There are other ways to handle multiple monitors connecting to the same computer in Xorg. The Arch wiki explains it well, in many fewer words than this post takes to mislead about it :) The options in Xorg aren’t great. I prefer a lot of what Wayland brings to multi-monitor scenarios. It just bothers me to no end that Wayland proponents always want Wayland to be seen as whatever combination of choices they have made for themselves with that platform but then try to paint Xorg as the worst combination of choices they have experienced.
I have mixed feelings. On one hand, I know Wayland is the better protocol. I wish I could use it. But I can’t, for one simple reason: there’s nothing like devilspie2 for Wayland to the best of my knowledge. I have a very peculiar way how I want my windows arranged, and while there are WMs with which I could achieve the same thing under Wayland, they’re all tiling wms, and I’m not a fan of tiling WMs.
On top of this, there’s nothing Wayland would give me that I’d consider worth more than the trouble it would be to switch. Better performance? My GNOME is snappy enough as it is. I recently tried it under Wayland, and didn’t notice any difference in performance. My games? The games I play run perfectly fine on Xorg, I have no complaints. Wouldn’t notice anything if I switched to Wayland. Keyloggers and the like? If someone can install an X11 based keylogger on my system, I have bigger problems than X11, and Wayland wouldn’t save me. Same for screen and audio capture. So the benefits for me, personally, are minimal, but the downside quite severe.
X is bad. We know. Wayland is good. Seems plausible. The rant, however, doesn’t do a very good job at convincing me to give Wayland another try. I’m already familiar with X’s shortcomings, and I’m okay with them. None of the purported wayland benefits are important to me:
I don’t care about architecture. I care about things working. X works, and has devilspie. Wayland also works, but doesn’t have devilspie.
I don’t care about performance, as long as things react faster than I do, and they do, both under X and Wayland.
I don’t care much about security, because I rarely run software I didn’t compile, and the chances of them doing something nasty on my system is pretty darn low.
I don’t care about NVIDIA, because I don’t have any NVIDIA GPUs.
I don’t care about multi-monitor scaling, because both my monitors have the same size and refresh rate.
I don’t care about fractional scaling, I wouldn’t use it even if I was on Wayland.
I don’t have HDR capable devies.
I usually don’t develop GUI applications, but when I do, I hardly ever interact directly with either X or Wayland. I use a toolkit that does it for me, and I don’t need to care.
So what exactly would I gain if I sacrifice devilspie?
I’d love to switch. Wayland is the future. Sadly, it isn’t my present.
Sure, that’s true. But it also breaks a bunch of my software that works perfectly well thank you very much. I might not have 20+ year old workflows (unless you count GNU Emacs ;) ) but I do have 10+ year old workflows.
The arrogance expressed in this article is astounding, and gets my back up. Yes, Wayland is better than X in many, many ways: but dismissing Wayland as not fit for purpose in some cases is dishonest, and dismissing people who just want their workflows to keep working is offensive.
Immature posts like this one really make the situation worse, IMHO. Childish tribalism is at the heart of the problem and the solution is not to try and shame the other “tribe” into submission.
Wayland still has edge cases as the article mentions. If one system wants to replace another heavily entrenched one, it better do everything the old one can do and more.
“GNOME has it” is not enough. GNOME is not the only desktop environment in the open source Unix world.
Wayland appears to be developed in a very Linux-centric manner, leaving large swaths of code that need to be stubbed out on the BSD’s
“Security” concerns with keylogging/etc. are overblown. This isn’t windows, I don’t download random closed-source binaries and run them every other day.
Because it just works for me.
The manner of writing in this article smells very much like the “just do it the new and shiny way! Why? Because!” mindset that’s so common today. If it was intended to convince me to switch, it does a poor job of it.
One of the things that confuses me about this whole Linux desktop issue is the extreme fragmentation. Not only do you have the Desktop Environment/Window Manager split, you have different substrate technologies (X11/Wayland) and you have to keep a mental map of what the stuff you’re actually running (like Gnome) is using under the hood.
For example, is Wayland Linux only (i.e. tightly coupled to systemd)? If not, then it could be used on a BSD and the Linus maxim is not valid :D
For example, is Wayland Linux only (i.e. tightly coupled to systemd)? If not, then it could be used on a BSD and the Linus maxim is not valid :D
It’s worse. Wayland is a protocol. Implementations of Wayland may or may not be tied to a specific OS. Weston is the reference implementation and it runs quite happily on other operating systems. We even have it running with 3D support on CheriBSD on Morello.
Interesting to see that so much of the reasoning is “nobody will ever touch this portion of Xorg again”. The not-so-subtext being “everyone who has maintained it out of a sense of duty for 20 years is burned out and wants to ditch it the instant they have an excuse to”. I wonder how many of those people move on to working on Wayland stuff, or whether the communities diverge?
Many of the people who work on Wayland are also people at X.org et al (Mesa, FDO, etc.). Initial and core Wayland development basically came from people who worked on X, correcting mistakes, and inheriting some of the stuff in the X millieu at the time (i.e. XML based protocol definitions).
Yeah, there’s just a few different ways you could end up with that result. “I hate this and want to make my own thing”, “everyone thinks this is a good idea but not everyone wants to follow up with it”, technical or social schism, etc. I know that Wayland was basically made by a few Xorg developers to begin with but last I heard about that was in the early 2010’s so I don’t know how it’s evolved.
Until accessibility software works broadly on Wayland, it doesn’t work for me. I use Talon and it doesn’t work on Wayland, and it appears this is broadly true for accessibility tools.
Wayland seems great, in a lot of ways, but lately there seems to be this rise of ideological promotion of Wayland and dismissal of reasons to use X, which is disappointing and doesn’t make me optimistic about the community supporting Wayland.
Almost everything that didn’t work even two months ago works now, and tons of progress is being made
That’s the interesting part.
I’ve been running my first non-test install of Wayland on a laptop for about two weeks now and so far everything has worked. This is the first time I’ve not gone back in horror after 2h of usage, so maybe we’re actually getting there. I could even take screenshots this time. (No snark intended, just a factual description.) I think I don’t have any workflows that depend on X, but we’ll see. Also need to try screen sharing and the nvidia card yet :P
There will always be people who have time to watch the development of $THING and be surprised when everyone else goes “last I tried it it didn’t work” and there’s the rest who wouldn’t mind booting up a new app to try, but not install a whole ecosystem and switch a fundamental part of the workflow to just be continuously disappointed.
Bonus rant: the OP seems to have a git/project history going back like 2 years. I’m not even sure I tried wayland in the last two years. This should not be read as some young whippersnappers hurr durr comment, but some of us who were actually looking forward to wayland have been disappointed by its state for longer than the OP might have been using it.
Wow, amazing rhetoric right there. Paraphrasing an argument in dumb language and just stating it’s invalid without any counterargument.
From a technical point of view, great article. But “X works, Y does not” is as valid as an argument as they come. If using X breaks Z and you need Z, fuck using X, I will use Y. Even if Z is “bad software”, I may need it.
The end of the article directly acknowledges it, mostly with respect to accessibility.
There’s an inverse rhetoric that’s just as bad, if not worse because it’s never spelled out explicitly:
Why? Because my webcam/printer/wifi works in Windows, so if it doesn’t work on this new Linux thingy, it must be the new thingy’s fault, right? Don’t try to muddy the waters with “the vendor didn’t support Linux” or “the vendor didn’t write a driver”: the thing works on Windows, it doesn’t on Linux, it should be obvious to any child that Linux doesn’t work. Now stop bothering me, I have real work to do.
Or something. Actual late adopters are never that blatant, they tend to have shorter, less refutable quips, like “Linux isn’t serious”, or “why would I ever use RISC-V?”, or “this new language lacks tooling”. But the running theme is the same: burdening the new thing with unfair proofs. Here there is a case for X’s API being fundamentally outdated. Making something better (like Wayland is attempting) requires breaking it. Obviously that comes with growing pains, but blaming Wayland for this feels either ignorant or disingenuous to be honest.
Now the article could explain all this in that many words, or it can use the shortcut it did: Don’t even try to get away with “well, it just works for me” or “but Wayland no worky”.
Great reply, thanks for providing the perspective that the article is missing.
When I read
I don’t really read the nuanced story you provide. I read a mocking remark that has no argument behind it.
So maybe in this case it would be better to provide a more nuanced story or just omit the mockery altogether.
It’s a difficult balance to strike, on two accounts:
Nuance requires more text, which in many cases detracts from the main point. I routinely write nuances and caveats in my own essays, only to axe many of them just to keep it short and to the point. Sometimes those deliberate omissions are mistaken for ignorance.
Sometimes the best response is a dismissive coarse laugh. It’s a way of conveying that the attacked opinion is so ridiculous or outlandish, that whoever holds it should quietly change their mind in shame. It’s a polarising double edge sword however, to be use sparingly and carefully. In the context of this post it’s a harsh introduction, but it does help set the tone of the entire post, which is about depicting X as a crumbling old dinosaur we should stop feeding as a matter of mercy.
There’s also the target audience to keep in mind. Public writings are accessible to anyone, but they’re rarely intended for everyone. Some people would be more swayed by a nuanced take void of mockery, but for me the tone was very effective at conveying how strongly the author felt how bad the X situation really is.
And I didn’t know about battery life. Crap, I just set up XFCE with XMonad, which I’m assuming are under X… it would be nice to have a Wayland alternative. (And I’m still undecided on how much I actually need a desktop environment. Because ultimately I don’t need much: Ethernet, WiFi, mount USB drives, a way to transfer file to and from my Android phone, sound, screen brightness… the list isn’t short, but it’s still pretty bounded.)
Agree with you 100%.
A burned out OS dev is ranting with their friends after work. They’re just off a long shift. They’re being acerbic. They’re saying the things nobody says but a lot of people think. Now we’re doing a close reading of the transcript as if it’s a corporate press release. This is how it feels to me.
Is it actually true? Many of the things said in this post aren’t, so I’m skeptical of this too. Would be interesting to run a test.
I personally find it somewhat hard to believe… but plausible, there’s times when I see the X server on my box chewing through some more cpu than i’d expect necessary.
That bad? I don’t have the expertise to know, can you cite 3 fallacies?
I’m talking more about factual errors than fallacies but three examples:
Just plain false, I’m using it right now. (But the later point about getting the desktop settings being unstandardized is a fair point.)
Again, not true.
lol. This is kinda subjective so maybe it isn’t fair to put next to two factually false statements, but it sounds like she doesn’t actually know what she’s talking about - most Wayland proponents obviously know very little about X so unsurprising - and the later thing about “To get the full experience, I’ll be writing a mini Wayland server and X client, which should teach me a fair bit on how all of this works” sure indicates she probably doesn’t even know the basics.
Thanks, that’s what I was asking for.
We wouldn’t guess from the writing style, but it’s “she”.
oh thanks, i know i shouldn’t assume but whelp. i’ll edit that.
I actually would be interested in reading the experience report writing that program though. A lot of newbie X tutorials and rants make a big deal out of the various steps in a hello world, so you go into it thinking it is going to be a mess…. but it actually isn’t much different than a hello world on, Windows, for example. And you can skip some of the steps on computers nowdays since you can pretty safely assume there’s true color support, etc. (until someone plugs in one of those new e-ink things that are all the rage :P but still)
And people criticize the Windows hello world too. There is a fair argument to be made that you can skip the steps and use the defaults instead - indeed, this is the case with most the libraries on top.
auto window = new SimpleWindow; window.eventLoop();for example with my lib… but there’s times when you actually do need to know how to break down the tasks. Maybe you actually do want the window hidden until you’re ready to show it. Maybe you do want to create a subclass instead of taking default behavior. Maybe you actually do want to support a 16 color display. Thennew SimpleWindow();isn’t going to cut it, and the lower level apis show their value.Xlib itself is a lower level api (not quite as low as it gets, it has some conveniences built in, but not many), and X11 is a lower level protocol - explicitly being “mechanism, not policy”. Then you gotta read the other manuals on top of it. But… again this isn’t that different than other platforms. There’s the Win32 api which does provide some policy but you are still supposed to read the human/computer interaction guidelines and apply them.
I’ve never personally programmed something on Wayland but i wouldn’t be surprised if its low level functions take some boilerplate you don’t need to edit 95% of the time either.
The article disagrees with you in its conclusion: “You could probably add all (well, most) of these to Xorg, but not without some pretty fundamental changes, rewrites, and extensions.”
The wayland faq also disagrees with you. https://wayland.freedesktop.org/faq.html#heading_toc_j_5 “Why not extend the X server? Because for the first time we have a realistic chance of not having to do that. It’s entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X. “
In other words, they broke things because they wanted to, not because they had to.
At that point, it is 100% their fault when things that used to work on Linux no longer work on Linux. They deliberately broke it.
Good link, that FAQ. I can read from it:
Simplicity requires breaking APIs at some point. Even I can’t make the simplest thing out of the box, even for something as easy as a cryptographic signature API. Had to break the API and bump the major version to get from vtable abomination to the simpler (and more flexible!) solution I have now. I can imagine the constraints of a much bigger, much older project like X.
And to be honest, I wouldn’t be surprised if Wayland have to suffer the same fate a couple decades from now.
I don’t think they’re saying you’re not allowed to do a different thing, rather that at this point any interoperability issue between Wayland and Z is probably on Z. You aren’t considering the rest of the paragraph which frames the discussion as
A piece of software being incompatible with Wayland does not improve the standing of X11, it introduces the constraint that it’s use requires X11.
X11 being unfit for any modern system does not make Wayland magically fit for a modern system. Wayland proponents need to understand that the introduction of superseding technical requirements (e.g. around rendering and input – huge improvements by Wayland) does not invalidate adjacent functionality that applications have come to depend on. For example, applications that need to know their own location on the display are not bad software. It is just software that is inconvenient for Wayland developers to support on some platforms. It does not matter if there is a Wayland protocol for it because the most-used desktop environment has no intention of supporting it. At the same time they have broken Xwayland rendering so compatibility shims like
GDK_BACKEND=x11don’t work reliably either. So now huge swaths of Wayland users cannot reliably use software that requires functionality that is available on nearly every other modern platform. Users are now left with two options that are both unfit for a modern system.What kind of application needs that? I’m not sure even a screen recorder would need to know where other applications windows are located, as long as it can record their contents.
This article has a good breakdown of window types and IMO gives a fair description of the conflict. The main one that still doesn’t work broadly on Wayland is what they call satellite or toolbox windows. These used to be common but got a bad reputation, probably for the better, because they usually got sloppy (e.g. GIMP until about 10 years ago). However there’s a lot of applications that make better use of knowing and setting window coordinates. One I’m partial to is what I call “buddy” programs. I maintain my own diagraming software that is essentially gvim w/ a plugin that collaborates with a rendering server and an image viewer. It originally used Xembed to have gvim embedded in a frame along with the image viewer. Xembed is not supported on Wayland and while there is a protocol for sharing rendering surfaces the GTK maintainers have no intention of refreshing their “socket” feature to use it. The program has an alternative mode where it can collaborate with an external viewer. They are independent processes and windows but it is helpful for them to know their positions relative to one another because they would like to reposition toolbars to be on the side nearest the other application. Wayland designers use inter-application window position as a security bogeyman but this use case doesn’t even really need to know the other application’s position. It can do a pretty good job if it just knew it’s own coordinates in the desktop. i.e. if it is on the left edge with room to the right then the other application is most likely to be to its right side.
Anything that has floating panels benefits from being able to have policies for placing the panels such as put it close to the focused document window, but not overlappying, unless that would be off the edge of the screen. Applications that manage multiple windows in different contexts benefit from being able to create new ones near others.
I’m not familiar with such applications to be honest. I would guess, that in most cases you want to create the new window near the focused window, and that’s a job window managers do right now. The one case it would break down is when we want to create the window near a window that is not focused (and possibly in another workspace while we’re at it). I guess it has its uses, but to be honest this feels fairly niche (though never having ever needed that I do reckon I speak from ignorance).
It’s pretty common for implementing the inspector UI pattern in OpenStep / Mac apps.
Inspector UI? First time I ever heard of it. DuckDuckGo seems to point to GUI testing, is that it?
It’s a UI pattern for a pop-up thing that inspects another thing. Most things on OpenStep can be inspected by hitting meta-I. Ideally, the inspector window should appear close to the thing being inspected.
Applications whose purpose is to move other windows, like devilspie2. I have a peculiar way I like my apps arranged, and devilspie2 lets me achieve that, without having to find a (non-tiling) window manager that supports the kind of rules I can do with devilspie.
So you need to do window management without relying on the window manager… seems to me the real problem is that existing window managers don’t solve your problem, and you ended up working around that.
Yes. But I can solve it under X11, and I can’t solve it under Wayland.
It doesn’t matter that this isn’t a Wayland problem. It is a problem that prevents me from moving to Wayland nevertheless.
This is super-niche, but I wrote a 3D viewer application that displays a composite image from two USB cameras ( https://github.com/classilla/camaglyph for devices like the Minoru). Because of the fixed way passive 3D displays are polarized, the window needs to adjust which line it displays where based on its absolute Y position, or otherwise the polarization order is wrong and the wrong image is sent to each eye. I can’t do this in Wayland.
I imagine the Wayland developers would respond with something like “add this yourself” or “nobody does this.”
Niche or not, there’s no substitute for knowing at least the polarity parity of your absolute position. And I don’t think ignoring 3D monitors altogether is a good move for the future. They may get eaten by VR goggles, but I’m not sure the writing is on the wall yet.
Moreover, letting applications know where their windows are (after all they already know how big they are), seems much less disruptive than letting them chose where to place them. You may have a case.
Which version of Wayland are we talking about? The Gnome, Plasma or wlroots version? The community doesn’t seem to even agree on standards and each one of these requires their own portals.
Funny, it works on my modern systems. In some ways better than Wayland and in some ways worse. I use X11 primarily, but I have a wayland setup I use on occasion.
There are better ways to convince people than condescend. The technical portions are fine, but when you start out with “your reasons and opinions are wrong” you put people in defensive mode and whatever valid points you have to make have a much harder job to do. I haven’t quite figured out why smart people act like this, but it’s endemic in technical communities.
Also which implementation of X11?
Assuming Xorg because that seems to be what everyone else does. :)
Back in the bad old days of X11, that was a real problem. Sun, DEC, SGI, and everyone else’s X11 implementations each had different extensions. Some of them were amazing. SGI had GLX and so could run 3D accelerated graphics on their systems. Sun had XDPS, so you could send PostScript drawing commands directly to the X server for print-quality text and graphics.
Gradually, the set of useful extensions became common. Things like the render, composite, and damage extensions gave, basically, a completely new set of core abstractions for implementing a compositing display server and just using X11 as a command-encapsulation protocol. XACE provides fine-grained access control to X resources (sadly, no one uses it, they pretend it doesn’t exist to justify Wayland).
These days, even non-X.org X servers provide the same set of core extensions, to the point that they’re effectively an X12 protocol: you probe for them, but failing to run if they’re not there is totally fine because they’ll always be there.
Wayland has not yet gone through this process. Every compositor provides a set of extensions, many of which are necessary for a lot of tasks. Some of these are compatible, some are not.
The weird anti-X11 sentiment keeps getting weirder
This is such dishonest argumentation. First of all, it is simply a lie that the creators of X weren’t thinking of multiple displays and multiple resolutions. The trade-offs were simply different then. The architecture of X, including having a display server at all, was meant to facilitate many different screens being connected to the central computing resources. It happened to be the case that the volume of data used and the amount of drawing needed to be done meant that on balance it was better to transmit the drawing connections over the network and have a display server drive each physical display. By pretending the creators of X couldn’t have considered this they are trying to make the reader feel as if the X creators are people so unsophisticated as to be unworthy of association.
Probably more importantly though, they speak of X as if it hasn’t been updated since the 1980s (above) but also try to paint it as just some of it’s extensions (below).
Xorg has an extension to do this in Xinerama. There are other ways to handle multiple monitors connecting to the same computer in Xorg. The Arch wiki explains it well, in many fewer words than this post takes to mislead about it :) The options in Xorg aren’t great. I prefer a lot of what Wayland brings to multi-monitor scenarios. It just bothers me to no end that Wayland proponents always want Wayland to be seen as whatever combination of choices they have made for themselves with that platform but then try to paint Xorg as the worst combination of choices they have experienced.
I have mixed feelings. On one hand, I know Wayland is the better protocol. I wish I could use it. But I can’t, for one simple reason: there’s nothing like devilspie2 for Wayland to the best of my knowledge. I have a very peculiar way how I want my windows arranged, and while there are WMs with which I could achieve the same thing under Wayland, they’re all tiling wms, and I’m not a fan of tiling WMs.
On top of this, there’s nothing Wayland would give me that I’d consider worth more than the trouble it would be to switch. Better performance? My GNOME is snappy enough as it is. I recently tried it under Wayland, and didn’t notice any difference in performance. My games? The games I play run perfectly fine on Xorg, I have no complaints. Wouldn’t notice anything if I switched to Wayland. Keyloggers and the like? If someone can install an X11 based keylogger on my system, I have bigger problems than X11, and Wayland wouldn’t save me. Same for screen and audio capture. So the benefits for me, personally, are minimal, but the downside quite severe.
X is bad. We know. Wayland is good. Seems plausible. The rant, however, doesn’t do a very good job at convincing me to give Wayland another try. I’m already familiar with X’s shortcomings, and I’m okay with them. None of the purported wayland benefits are important to me:
So what exactly would I gain if I sacrifice devilspie?
I’d love to switch. Wayland is the future. Sadly, it isn’t my present.
Sure, that’s true. But it also breaks a bunch of my software that works perfectly well thank you very much. I might not have 20+ year old workflows (unless you count GNU Emacs ;) ) but I do have 10+ year old workflows.
The arrogance expressed in this article is astounding, and gets my back up. Yes, Wayland is better than X in many, many ways: but dismissing Wayland as not fit for purpose in some cases is dishonest, and dismissing people who just want their workflows to keep working is offensive.
Picking on the usual whipping boy: colour profiles still aren’t a thing on Wayland. Doesn’t bother me personally, but I know a lot of folks depend on it.
Immature posts like this one really make the situation worse, IMHO. Childish tribalism is at the heart of the problem and the solution is not to try and shame the other “tribe” into submission.
Why am I using X still?
The manner of writing in this article smells very much like the “just do it the new and shiny way! Why? Because!” mindset that’s so common today. If it was intended to convince me to switch, it does a poor job of it.
What happened to “don’t break userspace”?
Yes that’s been my experience.
Now what?
Isn’t that a Thorvalds tagline specific to the Linux kernel?
sure but you’d believe that guideline would apply to all the Linux stack.
Technically X11 predates Linux by quite a bit ;)
One of the things that confuses me about this whole Linux desktop issue is the extreme fragmentation. Not only do you have the Desktop Environment/Window Manager split, you have different substrate technologies (X11/Wayland) and you have to keep a mental map of what the stuff you’re actually running (like Gnome) is using under the hood.
For example, is Wayland Linux only (i.e. tightly coupled to systemd)? If not, then it could be used on a BSD and the Linus maxim is not valid :D
It’s worse. Wayland is a protocol. Implementations of Wayland may or may not be tied to a specific OS. Weston is the reference implementation and it runs quite happily on other operating systems. We even have it running with 3D support on CheriBSD on Morello.
Interesting to see that so much of the reasoning is “nobody will ever touch this portion of Xorg again”. The not-so-subtext being “everyone who has maintained it out of a sense of duty for 20 years is burned out and wants to ditch it the instant they have an excuse to”. I wonder how many of those people move on to working on Wayland stuff, or whether the communities diverge?
Many of the people who work on Wayland are also people at X.org et al (Mesa, FDO, etc.). Initial and core Wayland development basically came from people who worked on X, correcting mistakes, and inheriting some of the stuff in the X millieu at the time (i.e. XML based protocol definitions).
Yeah, there’s just a few different ways you could end up with that result. “I hate this and want to make my own thing”, “everyone thinks this is a good idea but not everyone wants to follow up with it”, technical or social schism, etc. I know that Wayland was basically made by a few Xorg developers to begin with but last I heard about that was in the early 2010’s so I don’t know how it’s evolved.
Until accessibility software works broadly on Wayland, it doesn’t work for me. I use Talon and it doesn’t work on Wayland, and it appears this is broadly true for accessibility tools.
Wayland seems great, in a lot of ways, but lately there seems to be this rise of ideological promotion of Wayland and dismissal of reasons to use X, which is disappointing and doesn’t make me optimistic about the community supporting Wayland.
I have a modern system that requires color management & DisplayLink, both of which have yet to get support in Wayland.
Tried Wayland. Would like to go back to Wayland. But until there’s better feature support, I can’t be the one for me.
That’s the interesting part.
I’ve been running my first non-test install of Wayland on a laptop for about two weeks now and so far everything has worked. This is the first time I’ve not gone back in horror after 2h of usage, so maybe we’re actually getting there. I could even take screenshots this time. (No snark intended, just a factual description.) I think I don’t have any workflows that depend on X, but we’ll see. Also need to try screen sharing and the nvidia card yet :P
There will always be people who have time to watch the development of $THING and be surprised when everyone else goes “last I tried it it didn’t work” and there’s the rest who wouldn’t mind booting up a new app to try, but not install a whole ecosystem and switch a fundamental part of the workflow to just be continuously disappointed.
Bonus rant: the OP seems to have a git/project history going back like 2 years. I’m not even sure I tried wayland in the last two years. This should not be read as some young whippersnappers hurr durr comment, but some of us who were actually looking forward to wayland have been disappointed by its state for longer than the OP might have been using it.
Great post. The overall conclusion has been evident for a long time (imo) but it’s a treat to see it all laid out.
Really? I hated it.
The opening sentence has multiple falsifiable statements; after that, I lost interest in seconds.
It’s biased, bigoted BS as far as I can see.