Wayland is not ready as a 1:1 compatible Xorg replacement just yet(gist.github.com)
gist.github.com
Wayland is not ready as a 1:1 compatible Xorg replacement just yet
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
349 comments
I have had the opposite experience: fewer people making bad arguments against Wayland and more competent commentary overall. I also can't remember a time when X Windows was seen as being well engineered and not being in need of replacement.
Virtually all of the complaints listed in this rant are the result of enforcing a sane security model.
> I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root.
These are not compelling arguments for running the GUI as root or allowing different applications to spy on each other.
I suspect the rationale behind this rant is motivated by the author's position as a BSD distro manager. BSD people really dislike it when Linux replaces legacy Unix infrastructure with Linux specific technologies. But if Wayland is doomed as an Xorg replacement, then why has development activity dropped off [0][1]?
[0]: https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Se... [1]: https://www.openhub.net/p/x
Virtually all of the complaints listed in this rant are the result of enforcing a sane security model.
> I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root.
These are not compelling arguments for running the GUI as root or allowing different applications to spy on each other.
I suspect the rationale behind this rant is motivated by the author's position as a BSD distro manager. BSD people really dislike it when Linux replaces legacy Unix infrastructure with Linux specific technologies. But if Wayland is doomed as an Xorg replacement, then why has development activity dropped off [0][1]?
[0]: https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Se... [1]: https://www.openhub.net/p/x
The safest computer is a turned off computer buried in concrete, would you use that as your daily driver?
I'm sure I would have driven a 1960's death trap [0] given that was the only option at the time.
[0]: https://en.wikipedia.org/wiki/Unsafe_at_Any_Speed
[0]: https://en.wikipedia.org/wiki/Unsafe_at_Any_Speed
Good thing you have x11 and wayland then, for those that want all the features out of the box and don't want to handle the hassles of restricted gpus or installing a package for each feature: just go x11.
Else, yeah, wayland I guess.
I have no vested interests (other than being a RescueTime user who likes apps that can also create global keystrokes) and I also think it's a bad model. I as a user should be able to trust a piece of GUI software to have privileged access to certain things; that usually means running as root. If there were a way to define a role which was privileged but only in certain areas (such as RescueTime getting access to all window titles and perhaps some contents but that's it), then that would be a possible argument against running as root, but no such thing has been proposed here.
I agree! I can't imagine such a thing hasn't been proposed, as it is required by accessibility software.
It's not a sane security model if the product doesn't do what the users need it to do as a result.
It does. Just not with gates wide open.
For example, screenshots. It is still possible to make screenshots. It is not possible to make screenshots without the user knowing. What use case do you have to make screenshots without user knowledge, that benefits the user?
For example, screenshots. It is still possible to make screenshots. It is not possible to make screenshots without the user knowing. What use case do you have to make screenshots without user knowledge, that benefits the user?
Corporate computers frequently make screen shots or screen recordings of employee interactions.
The benefit of being wide open is that no coordination is needed between desktop environment and developer leading to a wide open field of tools that work on every environment without exception, difference in feature set, no need to check if version foo works on version bar of $DESKTOP.
You could of course get virtually the same benefits plus improved security at the cost of some complexity by standardizing the feature in common usage for nearly 30 years towards the beginning of the development cycle of Wayland instead of 13 years in.
You point out the need for security and completely ignore the fact that such security could trivially have been obtained without reducing users to obtaining a pile of tools only from their desktop environment or waiting 20 years for things to standardize so they can again pick and choose the best tools for the particular task.
The benefit of being wide open is that no coordination is needed between desktop environment and developer leading to a wide open field of tools that work on every environment without exception, difference in feature set, no need to check if version foo works on version bar of $DESKTOP.
You could of course get virtually the same benefits plus improved security at the cost of some complexity by standardizing the feature in common usage for nearly 30 years towards the beginning of the development cycle of Wayland instead of 13 years in.
You point out the need for security and completely ignore the fact that such security could trivially have been obtained without reducing users to obtaining a pile of tools only from their desktop environment or waiting 20 years for things to standardize so they can again pick and choose the best tools for the particular task.
> Corporate computers frequently make screen shots or screen recordings of employee interactions.
It's not like they haven't figured out how to do that with Windows or OS X.
> The benefit of being wide open is that no coordination is needed between desktop environment and developer
The same is true of virtual memory.
> You point out the need for security and completely ignore the fact that such security could trivially have been obtained
The Xorg developers who tried really hard for decades would disagree with you. That's why programmers that Red Hat used to pay to hack on Xorg now get paid to develop Wayland [0].
[0]: https://www.theregister.com/2020/10/30/x_server_lead_maintai...
It's not like they haven't figured out how to do that with Windows or OS X.
> The benefit of being wide open is that no coordination is needed between desktop environment and developer
The same is true of virtual memory.
> You point out the need for security and completely ignore the fact that such security could trivially have been obtained
The Xorg developers who tried really hard for decades would disagree with you. That's why programmers that Red Hat used to pay to hack on Xorg now get paid to develop Wayland [0].
[0]: https://www.theregister.com/2020/10/30/x_server_lead_maintai...
> The Xorg developers who tried really hard for...
You misunderstand. Wayland development started in 2008. Screenshots/recording should have been on the board from day one and they could have gotten to standardizing on how to handle them in oh 2013-2015?
The sin is not the extra complexity to secure the system. It's having first zero then more than one way to go about it and 13 years later ending up in the situation where some utilities support only X and some only some Wayland implementations. It's the sin of forcing your users to rip out the walls and stare at the plumbing.
What other OS makes you think about display servers?
Red Hat doesn't believe in the Linux ecosystem and it shows they believe in their ecosystem with a singular official GUI and unfortunately an ecosystem in which one is required to use only their tools is a mostly mediocre one because they are best in class in nothing and worst in class in many.
You misunderstand. Wayland development started in 2008. Screenshots/recording should have been on the board from day one and they could have gotten to standardizing on how to handle them in oh 2013-2015?
The sin is not the extra complexity to secure the system. It's having first zero then more than one way to go about it and 13 years later ending up in the situation where some utilities support only X and some only some Wayland implementations. It's the sin of forcing your users to rip out the walls and stare at the plumbing.
What other OS makes you think about display servers?
Red Hat doesn't believe in the Linux ecosystem and it shows they believe in their ecosystem with a singular official GUI and unfortunately an ecosystem in which one is required to use only their tools is a mostly mediocre one because they are best in class in nothing and worst in class in many.
> Screenshots/recording should have been on the board from day one and they could have gotten to standardizing on how to handle them in oh 2013-2015?
I agree that Wayland's development has taken far too long and the transition has been rocky. But what development team couldn't use more funding? Ubuntu throwing a tantrum after the ecosystem rejected Mir and not contributing to Wayland certainly didn't help.
> What other OS makes you think about display servers?
I am sympathetic to arguments that Wayland/Weston could provide more functionality out-of-the-box. The bazaar's fragmented mess of "desktop environments" is certainly not a strength compared to what the Cathedrals have produced. But Linux's uniquely modular GUI stack necessitates coordination across lots of projects to develop and adopt standards.
But not doing anything and sticking with X11 would have condemned us to being stuck with an insecure, buggy, and visually glitchy mess forever.
> Red Hat doesn't believe in the Linux ecosystem
I have my qualms with Red Hat too, but my point was that Wayland was created by Xorg developers because they tried and failed to make X11 competitive. Seriously, just go watch this XFree86/Xorg/Wayland developer's talk [1].
[1]: https://www.youtube.com/watch?v=RIctzAQOe44
I agree that Wayland's development has taken far too long and the transition has been rocky. But what development team couldn't use more funding? Ubuntu throwing a tantrum after the ecosystem rejected Mir and not contributing to Wayland certainly didn't help.
> What other OS makes you think about display servers?
I am sympathetic to arguments that Wayland/Weston could provide more functionality out-of-the-box. The bazaar's fragmented mess of "desktop environments" is certainly not a strength compared to what the Cathedrals have produced. But Linux's uniquely modular GUI stack necessitates coordination across lots of projects to develop and adopt standards.
But not doing anything and sticking with X11 would have condemned us to being stuck with an insecure, buggy, and visually glitchy mess forever.
> Red Hat doesn't believe in the Linux ecosystem
I have my qualms with Red Hat too, but my point was that Wayland was created by Xorg developers because they tried and failed to make X11 competitive. Seriously, just go watch this XFree86/Xorg/Wayland developer's talk [1].
[1]: https://www.youtube.com/watch?v=RIctzAQOe44
> The bazaar's fragmented mess of "desktop environments" is certainly not a strength compared to what the Cathedrals have produced.
I will have to disagree. I like having options. Before Wayland having options meant that your app starting GUI and your file manager was different. If Wayland had meant there were now two options one deprecated and the other coming this wouldn't have really been a huge problem.
It's a problem now because insisting on standardizing on so little means we now have fragmentation the likes of which we never had with X and will likely have for many years to come.
Even more so because it isn't yet ready about 6 years after its fanboys started insisting it was and shitting on other options and dismissing actual problems as the mutterings of crackpots and luddites.
What does "competative" even mean in this context? Linux has had a nicer GUI since 2003 and if you don't hop on the pointless change parade a fairly consistent one. I literally switched to linux for a better interface 19 years ago and its still better.
I will have to disagree. I like having options. Before Wayland having options meant that your app starting GUI and your file manager was different. If Wayland had meant there were now two options one deprecated and the other coming this wouldn't have really been a huge problem.
It's a problem now because insisting on standardizing on so little means we now have fragmentation the likes of which we never had with X and will likely have for many years to come.
Even more so because it isn't yet ready about 6 years after its fanboys started insisting it was and shitting on other options and dismissing actual problems as the mutterings of crackpots and luddites.
What does "competative" even mean in this context? Linux has had a nicer GUI since 2003 and if you don't hop on the pointless change parade a fairly consistent one. I literally switched to linux for a better interface 19 years ago and its still better.
> I will have to disagree. I like having options. Before Wayland having options meant that your app starting GUI and your file manager was different. If Wayland had meant there were now two options one deprecated and the other coming this wouldn't have really been a huge problem.
I agree that the transition has been long and messy. But the Linux desktop experience has always been a fragmented mess of half-baked apps that quickly fall into disrepair. Wayland breaks a lot of stuff that has been in maintenance mode for a long time. That sucks, but it's not a good argument for sticking with X11. The situation with X11 had been unacceptable ever since the adoption of virtual memory and Wayland is the only real alternative.
> It's a problem now because insisting on standardizing on so little means we now have fragmentation the likes of which we never had with X and will likely have for many years to come.
I'm not going to criticize the boundaries of a standard that I haven't been deeply involved with. I understand their impulse to keep it minimal, as Wayland is something of a forever standard. But I am sympathetic to arguments that Wayland doesn't do enough.
> Even more so because it isn't yet ready about 6 years after its fanboys started insisting it was and shitting on other options and dismissing actual problems as the mutterings of crackpots and luddites.
If by "other options" you mean Mir, my memory is that the primary criticism of Mir's original architecture replicated Wayland in an incompatible way without any good reason for doing so. Eventually Mir was re-architected to layer it on top of Wayland and does provide more of the batteries you seem to want to have by default.
If by "other options" you mean X11 ... only crackpots and luddites think applications should be able to spy on each other [0].
What other options were there?
> What does "competitive" even mean in this context?
* Not having every app double as a key-logger.
* A working screen-locker.
* Not tearing on window resize or scrolling while a video plays.
* Multi-DPI monitors.
* Non-blocking API calls.
* etc [1].
I remember context menus being especially glitchy.
> Linux has had a nicer GUI since 2003 and if you don't hop on the pointless change parade a fairly consistent one. I literally switched to linux for a better interface 19 years ago and its still better.
Let me guess, you use some "minimalist" desktop environment? I'm not here to hate on people that don't need what most consider a modern user experience. If that's what you want, that's great! I was into lightweight desktop environments for a while and liked exploring that design space.
But I'm also a usability engineer who remembers Linux back then: it was not competitive with OS X and it still isn't.
[0]: https://en.wikipedia.org/wiki/TempleOS
[1]: https://www.phoronix.com/scan.php?page=article&item=x_waylan...
I agree that the transition has been long and messy. But the Linux desktop experience has always been a fragmented mess of half-baked apps that quickly fall into disrepair. Wayland breaks a lot of stuff that has been in maintenance mode for a long time. That sucks, but it's not a good argument for sticking with X11. The situation with X11 had been unacceptable ever since the adoption of virtual memory and Wayland is the only real alternative.
> It's a problem now because insisting on standardizing on so little means we now have fragmentation the likes of which we never had with X and will likely have for many years to come.
I'm not going to criticize the boundaries of a standard that I haven't been deeply involved with. I understand their impulse to keep it minimal, as Wayland is something of a forever standard. But I am sympathetic to arguments that Wayland doesn't do enough.
> Even more so because it isn't yet ready about 6 years after its fanboys started insisting it was and shitting on other options and dismissing actual problems as the mutterings of crackpots and luddites.
If by "other options" you mean Mir, my memory is that the primary criticism of Mir's original architecture replicated Wayland in an incompatible way without any good reason for doing so. Eventually Mir was re-architected to layer it on top of Wayland and does provide more of the batteries you seem to want to have by default.
If by "other options" you mean X11 ... only crackpots and luddites think applications should be able to spy on each other [0].
What other options were there?
> What does "competitive" even mean in this context?
* Not having every app double as a key-logger.
* A working screen-locker.
* Not tearing on window resize or scrolling while a video plays.
* Multi-DPI monitors.
* Non-blocking API calls.
* etc [1].
I remember context menus being especially glitchy.
> Linux has had a nicer GUI since 2003 and if you don't hop on the pointless change parade a fairly consistent one. I literally switched to linux for a better interface 19 years ago and its still better.
Let me guess, you use some "minimalist" desktop environment? I'm not here to hate on people that don't need what most consider a modern user experience. If that's what you want, that's great! I was into lightweight desktop environments for a while and liked exploring that design space.
But I'm also a usability engineer who remembers Linux back then: it was not competitive with OS X and it still isn't.
[0]: https://en.wikipedia.org/wiki/TempleOS
[1]: https://www.phoronix.com/scan.php?page=article&item=x_waylan...
=================================================
* HALF BAKED
=================================================
> But the Linux desktop experience has always been a fragmented mess of half-baked apps that quickly fall into disrepair.
> Let me guess, you use some "minimalist" desktop environment?
You mean the environments which aren't half backed and instead of falling into disrepair just sit there quietly working the same way so you can use your computer to do useful things?
=================================================
* WAYLAND SECURITY
=================================================
Millions of people have apparently solved the keep applications from secretly hacking you for man eons and decades of real time by not installing uncle bobs malware from www.notarealsite.com or responding to prompts to install software by fake support scam agents.
This is admittedly inferior to better isolation but better isolation is quite hard and few people are actually tackling it in any meaningfully complete way. If I solely switched today from X to Wayland I wouldn't meaningfully improve my security because apps aren't strongly firewalled from one another and so many vectors exist its more like installing a screen door than a bank vault. Proposed improvements like flatpak actually greatly reduce security in practice by
- Allowing users to be targeted by targeting already fixed vulnerabilities in flatpaks with outdated libraries
- Making it MUCH easier to get random bobs software in front of the user
- Trivializing the gap between compromised developer and user by shortening the gap between compromise and distribution from days->weeks to minutes->hours.
All told security is on net a pretty pointless reason to switch to wayland at this point. See qubes, distro processes, FDE, user education about common scams for actual improvement in security.
Lets be real you knew I didn't mean MIR.
=================================================
* COMPETITIVE POINTS
=================================================
- Tearing: I didn't have this problem in 2003 and I don't have it now.
- Multi-DPI monitors: I am typing this on a machine with a 4K monitor flanked by 2 1080p monitors. I scale them down from a higher resolution. Apps think all 3 are the same DPI and its transparently scaled down so that UI elements are identically sized on all displays. Nothing is blurry.
- Non-blocking API calls. I'm using an environment not writing one. None of your users on earth care.
=================================================
* SECURING LOCKED COMPUTERS
=================================================
On desktop machines screen locking provides by default similar levels of security as locking a bathroom door it protects against casual intrusion. You can keep someone from sitting down and looking at your email it cannot prevent an attacker with physical access to your computer from gaining access to your data.
You could get greater security by blocking switching TTY and by blocking usb devices from being attached while the screen is locked for example with USBGuard regardless of choice of display server.
https://usbguard.github.io/
For machines that are at risk of actual attack you would want to to rely on FDE and either full shutdown or locking critical data when user isn't in physical control of the device.
None of this has much to do with choice of display servers and choosing Wayland by default doesn't appear to do much beyond what could be accomplished by blocking changing ttys.
=================================================
* END LINKS
=================================================
I'm not sure why you linked either TempleOS or a 9 year old write up on the design flaws of X.
For what its worth its not only dated but bad as well. Just to pick on a particularly bad patch.
>Wayland breaks everyone's desktop.” Also wrong. Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with.
This was back in 2013 and the entire ecosystem has spent 9 years going through growing pains with applications going through a plethora of Wayland specific issues with entire categories of applications disappearing or requiring different implementations on different compositors years later. In 2013 this was basically the definition of over-promise under-deliver. It's aged like milk and it makes the authors analysis challenging to take seriously.
* HALF BAKED
=================================================
> But the Linux desktop experience has always been a fragmented mess of half-baked apps that quickly fall into disrepair.
> Let me guess, you use some "minimalist" desktop environment?
You mean the environments which aren't half backed and instead of falling into disrepair just sit there quietly working the same way so you can use your computer to do useful things?
=================================================
* WAYLAND SECURITY
=================================================
Millions of people have apparently solved the keep applications from secretly hacking you for man eons and decades of real time by not installing uncle bobs malware from www.notarealsite.com or responding to prompts to install software by fake support scam agents.
This is admittedly inferior to better isolation but better isolation is quite hard and few people are actually tackling it in any meaningfully complete way. If I solely switched today from X to Wayland I wouldn't meaningfully improve my security because apps aren't strongly firewalled from one another and so many vectors exist its more like installing a screen door than a bank vault. Proposed improvements like flatpak actually greatly reduce security in practice by
- Allowing users to be targeted by targeting already fixed vulnerabilities in flatpaks with outdated libraries
- Making it MUCH easier to get random bobs software in front of the user
- Trivializing the gap between compromised developer and user by shortening the gap between compromise and distribution from days->weeks to minutes->hours.
All told security is on net a pretty pointless reason to switch to wayland at this point. See qubes, distro processes, FDE, user education about common scams for actual improvement in security.
Lets be real you knew I didn't mean MIR.
=================================================
* COMPETITIVE POINTS
=================================================
- Tearing: I didn't have this problem in 2003 and I don't have it now.
- Multi-DPI monitors: I am typing this on a machine with a 4K monitor flanked by 2 1080p monitors. I scale them down from a higher resolution. Apps think all 3 are the same DPI and its transparently scaled down so that UI elements are identically sized on all displays. Nothing is blurry.
- Non-blocking API calls. I'm using an environment not writing one. None of your users on earth care.
=================================================
* SECURING LOCKED COMPUTERS
=================================================
On desktop machines screen locking provides by default similar levels of security as locking a bathroom door it protects against casual intrusion. You can keep someone from sitting down and looking at your email it cannot prevent an attacker with physical access to your computer from gaining access to your data.
You could get greater security by blocking switching TTY and by blocking usb devices from being attached while the screen is locked for example with USBGuard regardless of choice of display server.
https://usbguard.github.io/
For machines that are at risk of actual attack you would want to to rely on FDE and either full shutdown or locking critical data when user isn't in physical control of the device.
None of this has much to do with choice of display servers and choosing Wayland by default doesn't appear to do much beyond what could be accomplished by blocking changing ttys.
=================================================
* END LINKS
=================================================
I'm not sure why you linked either TempleOS or a 9 year old write up on the design flaws of X.
For what its worth its not only dated but bad as well. Just to pick on a particularly bad patch.
>Wayland breaks everyone's desktop.” Also wrong. Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with.
This was back in 2013 and the entire ecosystem has spent 9 years going through growing pains with applications going through a plethora of Wayland specific issues with entire categories of applications disappearing or requiring different implementations on different compositors years later. In 2013 this was basically the definition of over-promise under-deliver. It's aged like milk and it makes the authors analysis challenging to take seriously.
On my computer i know (except for the web browser) which program makes screenshots. I want all my programs to function properly but not send my data over the internet. So i really don't see the problem Wayland is trying to solve (web browser still executes remote untrusted code).
Does your OS use protected memory?
Why? If you knew all your programs, and that they are well-behaved, there is no need for that.
But we do use protected memory. And IOMMU (you know all the peripherals that you connect to your computer as well, right?). And other facilities intended to separate programs and hardware from each other.
So the same way as programs do not snoop on shared global heap, do not big-bang i/o ports, etc, programs are not supposed to snoop on shared display surfaces (really just a subset of 'global shared heap'). If you need something specific from them, you ask them via defined way (e.g. screenshot API), that might or might not have facilities to enforce access control.
Because we are not relying on them to be well behaved. Instead, we will notice if they aren't.
Why? If you knew all your programs, and that they are well-behaved, there is no need for that.
But we do use protected memory. And IOMMU (you know all the peripherals that you connect to your computer as well, right?). And other facilities intended to separate programs and hardware from each other.
So the same way as programs do not snoop on shared global heap, do not big-bang i/o ports, etc, programs are not supposed to snoop on shared display surfaces (really just a subset of 'global shared heap'). If you need something specific from them, you ask them via defined way (e.g. screenshot API), that might or might not have facilities to enforce access control.
Because we are not relying on them to be well behaved. Instead, we will notice if they aren't.
If protected memory was implemented somehow per desktop environment and relegated me to choosing between Gnome and KDEs respective browsers/office suites instead of installing Firefox and Emacs I would either eschew it and take the risk or give up on Linux entirely and get a Mac.
> If protected memory was implemented somehow per desktop environment
I'm sure LOTS of people stopped using certain Unix programs that relied on a single address space whenever that was implemented. But to quote myself a few relies up,
>> These are not compelling arguments for running the GUI as root or allowing different applications to spy on each other.
> or give up on Linux entirely and get a Mac.
You mean the Unix that originally decided against using X11 because it would have required a re-write to do what they wanted anyway [1]? You understand that Wayland was designed by core Xorg contributors to replace X11 because attempts to match OS X resulted in a glitchy nightmare ... right?
[1]: https://news.slashdot.org/comments.pl?sid=75257&cid=6734612
I'm sure LOTS of people stopped using certain Unix programs that relied on a single address space whenever that was implemented. But to quote myself a few relies up,
>> These are not compelling arguments for running the GUI as root or allowing different applications to spy on each other.
> or give up on Linux entirely and get a Mac.
You mean the Unix that originally decided against using X11 because it would have required a re-write to do what they wanted anyway [1]? You understand that Wayland was designed by core Xorg contributors to replace X11 because attempts to match OS X resulted in a glitchy nightmare ... right?
[1]: https://news.slashdot.org/comments.pl?sid=75257&cid=6734612
> What use case do you have to make screenshots without user knowledge, that benefits the user?
Headless browser testing. Network admin at a corporate site. For starters.
Headless browser testing. Network admin at a corporate site. For starters.
You can do headless browser testing with virtual screen, that doesn't need real one.
For corporate uses, you can use something like vPro and it's remote access. It works independently of the OS (and by default expects user consent too).
For corporate uses, you can use something like vPro and it's remote access. It works independently of the OS (and by default expects user consent too).
There is a sane API for this use case on every major platform. The argument is that X11 made a mistake by allowing it by default.
Yeah, I still have yet to try Wayland (Xfce user here, which I expect may never port), and I never really got the hype. I honestly just don't get all the gripe people have about X11. I think all the current problems (including the security issues) are solvable through new extensions, if someone wanted to take the time to work them out. Given that But no, it's better to throw everything out, start from scratch, create a ton of new work for people, and 12 years later still not have displaced X11.
Put another way: do we truly believe that in 12+ years, some motivated hackers couldn't evolve X11 into something better? I get that many of the people involved were burnt out on it, and sure, no one (myself included) stepped up to the plate, but it doesn't seem plausible to me that X11 and Xorg are lost causes.
Put another way: do we truly believe that in 12+ years, some motivated hackers couldn't evolve X11 into something better? I get that many of the people involved were burnt out on it, and sure, no one (myself included) stepped up to the plate, but it doesn't seem plausible to me that X11 and Xorg are lost causes.
> Put another way: do we truly believe that in 12+ years, some motivated hackers couldn't evolve X11 into something better?
Yes. It is not just a random program that needs some fixing here and there, it is a program which has to evolve with all its accompanying user space, as almost anything can be a breaking change. Sometimes reinvention is the correct decision, and I am quite sure that the whole X11 team uniformly deciding on that gives it enough weight.
Yes. It is not just a random program that needs some fixing here and there, it is a program which has to evolve with all its accompanying user space, as almost anything can be a breaking change. Sometimes reinvention is the correct decision, and I am quite sure that the whole X11 team uniformly deciding on that gives it enough weight.
In 12 years they probably could have improved X a lot. But the impression I always got (years ago when this was a bigger topic) is it likely would have broken backwards comparability to do right. And if it’s not compatible, is it still X? And would the Wayland haters/holdouts accept it?
IDK. I understand the direction they decided to take.
IDK. I understand the direction they decided to take.
i try to learn x11, is hell, i realy try im tech savvy but god sake.
is this problem difficult hell yea, but heavens x11 makes 10x more complex that should be.
I mean, when your default use-case includes remote rendering of a GUI to clients, you're going to end up with a complex protocol. In the era of heavy servers and thin clients, it makes a lot of sense.
But when most (every?) computer includes some kind of GPU, local rendering makes the most sense -- especially when that's how your primary competitors work.
I don't know enough about Wayland vs X11 to make an informed statement, but I do appreciate that Wayland explicitly didn't try to include remote rendering. Let's just leave that up to other protocols (VNC/RDP/etc...). Now if we can just get one of those protocols to work on an individual application/window basis as opposed to the whole desktop.
But when most (every?) computer includes some kind of GPU, local rendering makes the most sense -- especially when that's how your primary competitors work.
I don't know enough about Wayland vs X11 to make an informed statement, but I do appreciate that Wayland explicitly didn't try to include remote rendering. Let's just leave that up to other protocols (VNC/RDP/etc...). Now if we can just get one of those protocols to work on an individual application/window basis as opposed to the whole desktop.
That would be waypipe, https://gitlab.freedesktop.org/mstoeckl/waypipe#:~:text=wayp....
I tried Wayland, back when. Then spent the evening repairing my newly broken Debian configuration. I had my X back, by the end.
Now I donate monthly to Xorg release engineering.
Now I donate monthly to Xorg release engineering.
> Now I donate monthly to Xorg release engineering.
Could you spare a link, so I can follow your example?
Could you spare a link, so I can follow your example?
Now that I am at my desk...
https://www.patreon.com/p12tic
https://www.patreon.com/p12tic
on my bullseye machine I can have sway running on tty1 and Xorg/xfce running on tty2 (at the same time, same user)
(for when you very rarely need to use X)
(for when you very rarely need to use X)
Not being able to have multi-DPI in X is what moved me over. Scaling one display makes everything fuzzy and increased my idle load substantially, though maybe a different compositor might have given different results.
EDIT: I should also mention that my experience is overall positive, I use swaywm so config and setup is easier than with X (no xorg.conf to tinker with every driver update) with a small stability tradeoff. Sometimes sessions will crash out when doing things with the GPU dmabuffers, which for a lot of people isn't really acceptable, but also who's usually using dmabuffers?
Oh and mouse interactions can be really wrong when going between xwayland windows and native ones.
EDIT: I should also mention that my experience is overall positive, I use swaywm so config and setup is easier than with X (no xorg.conf to tinker with every driver update) with a small stability tradeoff. Sometimes sessions will crash out when doing things with the GPU dmabuffers, which for a lot of people isn't really acceptable, but also who's usually using dmabuffers?
Oh and mouse interactions can be really wrong when going between xwayland windows and native ones.
Looks like there is a plan to implement Wayland in Kfce: https://wiki.xfce.org/releng/wayland_roadmap
sway is a drop-in replacement for i3 if you want to try again!
(and I think the nvidia issue is solved or close to being solved)
wayland has been the only way I've managed to get tear free smooth 60fps on Linux (trying intel, nvidia and amd drivers on Xorg)
(and I think the nvidia issue is solved or close to being solved)
wayland has been the only way I've managed to get tear free smooth 60fps on Linux (trying intel, nvidia and amd drivers on Xorg)
Agreed, I switched to Wayland and Sway when I upgraded to Ubuntu 22.04. It has basically been a drop in replacement and has been working great!
I've moved to using a mac as my primary device, so no more Sway or i3, unfortunately :'(
Though, fwiw, I had no issues with screen tearing once I started using picom. I used to have mild tearing before that, but after setting up picom (don't remember how I configured it exactly) I got buttery smooth output!
Though, fwiw, I had no issues with screen tearing once I started using picom. I used to have mild tearing before that, but after setting up picom (don't remember how I configured it exactly) I got buttery smooth output!
The relevant picom option would be:
vsync = true
I'm using i3, specifically i3-gaps and I'm rather interested in switching.
I don't have nvidia.
Where can I learn more?
I don't have nvidia.
Where can I learn more?
The Arch wiki page for Sway is a pretty good starting point: https://wiki.archlinux.org/title/Sway#Configuration.
FWIW I was also an i3 user for a long time (and xmonad before that), and I’m a very happy convert to Sway.
FWIW I was also an i3 user for a long time (and xmonad before that), and I’m a very happy convert to Sway.
There is a Manjaro Sway community flavor if you want to USB boot something preconfigured and check it out.
is the problem of blurry on XWayland for hidpi solved yet? That one prevented me from migration the last time (still keep sway installed but only login to i3).
Well, that is an X11 issue though. But I don’t know the current state of that
Wayland seemed to languish at 90% complete for years. Wayland was on by default in Ubuntu 17.10, then off in 18.04, then back on in 21.04.
Ubuntu single-handedly delayed Wayland adoption by years.
They didn't switch to Wayland by default, because the apps weren't ready. The apps weren't ready, because they ran on current Ubuntu just fine, so why would they change. Chicken, egg.
Compare that to Apple macOS. Apple breaks macOS compatibility at the rate that GNOME can gush with envy. But the third parties are quick to update, without dragging their feet for years.
So if the signalling was, that Wayland is inevitable by release XX.YY, apps would be ready.
They didn't switch to Wayland by default, because the apps weren't ready. The apps weren't ready, because they ran on current Ubuntu just fine, so why would they change. Chicken, egg.
Compare that to Apple macOS. Apple breaks macOS compatibility at the rate that GNOME can gush with envy. But the third parties are quick to update, without dragging their feet for years.
So if the signalling was, that Wayland is inevitable by release XX.YY, apps would be ready.
No one in the Linux community holds that kind of sway (pun intended). Even in the days of proprietary UNIX you had OpenLook vs CDE/Motif. Sometimes the Cathedral does things better.
I have been on Wayland since Fedora switched to it a few years ago. These days I have picked up a few workflows that just don't work on X11 so my opinion has changed to X11 not quite being ready for real use yet.
interesting, could you elaborate what that is? i am happy on wayland, but i haven't noticed any difference.
Nvidia isn't even a big issue anymore (the proprietary and open drivers both run gnome, plasma, and sway Wayland sessions pretty darn well now) I think there overall was just too big a lag between the "rah rah" and delivery on 95% of the promises so there was a bit of pushback.
I went looking for a video demoing the first statement and came across https://youtu.be/sdSFzZCgWp0. I'd find a better video but sometimes the worse video is too funny to pass up :).
I went looking for a video demoing the first statement and came across https://youtu.be/sdSFzZCgWp0. I'd find a better video but sometimes the worse video is too funny to pass up :).
The problems don't change the fact that it's better & smarter & obvious, and honestly the problems here are... frequently misstated ("Wayland provides no capture APIs"... uhhhh what? this ticket is closed & resolved >2 years ago & webrtc for example works fine.). Leaving X to have a massive rats nest of drivers, and giving every app supreme access to the session, was a terrible situation, and Wayland is a reasonable, far lower surface-area alternative that's far more sensible & leaves far more responsibilities in the kernel's trusting hands.
This post projects an idea that there is a new resurgence of push-back & dislike, a failure to come into fruition, but personally I feel there's been a long continual & ongoing history of refusenik/can't-do attitude, like nearly all new technologies & especially sizable open source developments face. And success is widespread.
What I see as somewhat new is that the pace in Wayland protocol development has indeed really tapered off, with a large part of that slowness being chalk-up-able to (alas) internal obstructionism. A lot of innovations have been really hotly contested. Rather than independent innovation (which Wayland protocols make imminently possible), there's way more bickering in the various protocol proposals & less getting shit off the ground. There's absolutely a place for getting it right, but the clashes have gotten louder & bigger & it's sapping the energy in the room. Virtual input devices for example have been a shit show and a half, all kinds of hard work & valid proposals getting snubbed & shot down left & right, rudely. Some stuff has just been slow: global hotkeys for example.
Even still, I think far more of the problems in this gist relate more to apps that just aren't well maintained (alike your NV gpu that has been a bad actor on the scene), aren't well cared for. Others of these grievances are kind of small & non issues, or just paranoia (eg: conspiracy-theory freak-outs about client side decorations), some are indeed deeply technical sticking points Wayland hasn't specified it's way through yet (hotkeys again), some just seem... wrong (most Intel users don't experience terrible godforsaken tearing all the time?) but a lot of them are just slow apps not doing basic good. Yeah. It takes a long time to improve a vast vast vast vast ecosystem.
That said, it's really been about a year that Wayland has been shipping truly genuinely en-masse, so the visibility & noticeability of issues is much much much higher than it had been.
This post projects an idea that there is a new resurgence of push-back & dislike, a failure to come into fruition, but personally I feel there's been a long continual & ongoing history of refusenik/can't-do attitude, like nearly all new technologies & especially sizable open source developments face. And success is widespread.
What I see as somewhat new is that the pace in Wayland protocol development has indeed really tapered off, with a large part of that slowness being chalk-up-able to (alas) internal obstructionism. A lot of innovations have been really hotly contested. Rather than independent innovation (which Wayland protocols make imminently possible), there's way more bickering in the various protocol proposals & less getting shit off the ground. There's absolutely a place for getting it right, but the clashes have gotten louder & bigger & it's sapping the energy in the room. Virtual input devices for example have been a shit show and a half, all kinds of hard work & valid proposals getting snubbed & shot down left & right, rudely. Some stuff has just been slow: global hotkeys for example.
Even still, I think far more of the problems in this gist relate more to apps that just aren't well maintained (alike your NV gpu that has been a bad actor on the scene), aren't well cared for. Others of these grievances are kind of small & non issues, or just paranoia (eg: conspiracy-theory freak-outs about client side decorations), some are indeed deeply technical sticking points Wayland hasn't specified it's way through yet (hotkeys again), some just seem... wrong (most Intel users don't experience terrible godforsaken tearing all the time?) but a lot of them are just slow apps not doing basic good. Yeah. It takes a long time to improve a vast vast vast vast ecosystem.
That said, it's really been about a year that Wayland has been shipping truly genuinely en-masse, so the visibility & noticeability of issues is much much much higher than it had been.
I guess what I never understood about Wayland is how they managed to ignore some very obvious problems X11 had, and created brand-new ones.
The fact there was no default widget kit is the big one for me. If you're developing a new GUI in the early 2000s, "all the software looks native" is pretty near table stakes. Yeah, not doing so probably avoided a huge holy war, but surely the right thing to do would have been to do Xaw, GTK and Qt flavoured bindings atop some native widget set so you're at least 70% of the way there.
The movement from "window manager" to "compositor" is a huge scope creep. I'm going to admit that one of the things that drew me into Unix/Linux in the late '90s was the appeal of highly customized X11 desktops (i. e. Enlightenment v0.15).
Now, an X11 "window manager" is probably a within scope of one, or a small team, of moderately competent developers. I think one of the big old O'Reilly X11 reference books actually had a clumsy but functional example with line-by-line commentary. I like that I can run something fairly lightweight (FVWM, for example), instead of having to pull in most of the GNOME or KDE desktop incidentally because I want frames around my windows.
A Wayland-style compositor, on the other hand, seems to be a much higher barrier to entry. The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there. I don't recall ever seeing "You have to use TWM because AfterStep won't work with your Trident 9440 video card" back in 1998. I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
The fact there was no default widget kit is the big one for me. If you're developing a new GUI in the early 2000s, "all the software looks native" is pretty near table stakes. Yeah, not doing so probably avoided a huge holy war, but surely the right thing to do would have been to do Xaw, GTK and Qt flavoured bindings atop some native widget set so you're at least 70% of the way there.
The movement from "window manager" to "compositor" is a huge scope creep. I'm going to admit that one of the things that drew me into Unix/Linux in the late '90s was the appeal of highly customized X11 desktops (i. e. Enlightenment v0.15).
Now, an X11 "window manager" is probably a within scope of one, or a small team, of moderately competent developers. I think one of the big old O'Reilly X11 reference books actually had a clumsy but functional example with line-by-line commentary. I like that I can run something fairly lightweight (FVWM, for example), instead of having to pull in most of the GNOME or KDE desktop incidentally because I want frames around my windows.
A Wayland-style compositor, on the other hand, seems to be a much higher barrier to entry. The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there. I don't recall ever seeing "You have to use TWM because AfterStep won't work with your Trident 9440 video card" back in 1998. I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
The fact there was no default widget kit is the big one for me.
This wouldn't have worked. Different DEs will never ever ever agree on a common toolkit. If Wayland had a single official toolkit that means that today one DE (probably GNOME) would be using Wayland and every other DE would still be on Xorg (which is unmaintained).
The movement from "window manager" to "compositor" is a huge scope creep.
It's not. It's actually simpler and more reliable to implement window management inside the display server than using a separate process.
I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
Agreed. Wayland probably could have done a better job of putting 99% of the code in libweston so that different compositors would only have to reimplement 1%.
This wouldn't have worked. Different DEs will never ever ever agree on a common toolkit. If Wayland had a single official toolkit that means that today one DE (probably GNOME) would be using Wayland and every other DE would still be on Xorg (which is unmaintained).
The movement from "window manager" to "compositor" is a huge scope creep.
It's not. It's actually simpler and more reliable to implement window management inside the display server than using a separate process.
I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
Agreed. Wayland probably could have done a better job of putting 99% of the code in libweston so that different compositors would only have to reimplement 1%.
> Agreed. Wayland probably could have done a better job of putting 99% of the code in libweston so that different compositors would only have to reimplement 1%.
But at the same time that was meant as reference implementation, prone to quick changes and no promise of backwards compatibility. It could hinder their initial progress instead.
Wlroots is exactly that and has been available for quite some years now (with many niche wms building on it)
But at the same time that was meant as reference implementation, prone to quick changes and no promise of backwards compatibility. It could hinder their initial progress instead.
Wlroots is exactly that and has been available for quite some years now (with many niche wms building on it)
I don’t know why should a window manager care about frameworks, possibly besides window decorations, but that is unique to each one.
What if I want a simple framebuffer on the screen? I believe wayland’s solution is much more minimalist and elegant, you get a rectangle and whatever you draw over it I’ll show. Frameworks are very complex beasts, very much outside the scope of a wm protocol.
And I very much don’t agree with the window manager compositor “feature creep”. If anything, the only reason it was easy to write for X11 is because X was a huge monolith doing things it really was not meant to, making you in essence write a window layout plugin. That’s why it was easy. But that just pushed (and worse, solidified) the complexity a layer beneath.
Wayland instead solves the complexity of its problem domain, not more, not less. You can still write a window manager plugin over wlroots for example with not much work, but writing a wayland implementation is not the same thing.
And I very much don’t agree with the window manager compositor “feature creep”. If anything, the only reason it was easy to write for X11 is because X was a huge monolith doing things it really was not meant to, making you in essence write a window layout plugin. That’s why it was easy. But that just pushed (and worse, solidified) the complexity a layer beneath.
Wayland instead solves the complexity of its problem domain, not more, not less. You can still write a window manager plugin over wlroots for example with not much work, but writing a wayland implementation is not the same thing.
X11 was designed for use as a remote session. Largely built for Unix, these Unix machines we largely accessed remotely. Local Machines were not as powerful as the mini computers of the time that would run the more heavy duty applications.
Honestly it really wasn't until SGI and NeXT did we see powerful mini computers on the desk running GUI applications in the 90s.
X11 is due for a replacement, but users just dont want to let go. Linux GUI based applications are still a small user base compared to the headless nature Linux normally gets used for.
For every 1 GNU GUI using Linux user, there are 100+ Linux installs that run completely headless. So the demand to move to Wayland is small.
Honestly it really wasn't until SGI and NeXT did we see powerful mini computers on the desk running GUI applications in the 90s.
X11 is due for a replacement, but users just dont want to let go. Linux GUI based applications are still a small user base compared to the headless nature Linux normally gets used for.
For every 1 GNU GUI using Linux user, there are 100+ Linux installs that run completely headless. So the demand to move to Wayland is small.
> A Wayland-style compositor, on the other hand, seems to be a much higher barrier to entry. ... I don't recall ever seeing "You have to use TWM because AfterStep won't work with your Trident 9440 video card" back in 1998.
All in all, the basics of Wayland are a pretty tight package. https://wayland-book.com/ goes through the pieces, and it's not a super thick read. The system of passing around surfaces is comprehensible, tight, makes sense, and there is very little fluff or barriers here, imo.
Wayland has a common core, but absolutely I'd grant that the various protocols do indeed make it a much less tightly coupled thing, with different compositors having different sets of protocols they support. So yes, some apps that require advanced capabilities run much better in some compositors than others; the compositor choice matters. Sometimes there are multiple competing protocols for the same feature-sets, but usually/historically, wayland-protocols hammers stuff out reasonably quickly & most of this is a matter of time.
Still, this is often easier than the past, where apps would have to each test for extensions & have various fast/regular/fallback codepaths depending on available extensions; not necessarily a hindrance to the window-manager, but a bundle of complexity for everyone else trying to use X11 adequately. The Wayland common primitives, on the other hand, are fairly universally performant & well chosen.
Returning to complexity for window-manager/compositor, the situation is not unlike X11 itself, where yes, a simple window manager (or compositor) is possible to spin up relatively quickly, but where there is a sea of different standards to implement to do a good job. Window manager hints, extended window manager hints, and a plethora of other standards existed around X11 that were up to the window-manager to tackle, and implementing each of those took a lot of time too, if you wanted good support for all apps. Different Wayland compositors also have different support for different protocols, and those are a bit deeper rooted capabilities, less superficial than many of the X11 hints (which, if ignored, were less likely to impede use), but the idea is the same: real support to really be decent took work in X11, and it takes work in Wayland to implement a good suite of protocols here too.
Where I disagree highly is calling out the hardware here. Wayland is closely tied to kernel fundamentals; any reasonably supported video card will perform adequately under any competent/non-specialist compositor today. (Certainly some compositors could demand higher standards, such as some of the experimental compositors requiring Vulkan, but generally compositors have very similar, very common requirements.)
> I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
I like where we are, where there are various toolkits/libraries for accelerated implementing. Wlroots, which underpins chiefly Sway (the i3 replacement), has given rise to a variety of other compositors, spanning the gamut from quick/fast/experimental to rich/deep/powerful. libwayland still defines some core ideas, if not compositing implementations, to speed development somewhat. Weston is still available as a reference compositor, although yes it's designed (more or less) to be forked & enhanced, not built to be preserved & built (extensibly) on top of. Wlroots & other alternative toolkits fill this need, & provide a diversity of ideas for how we might get going. Projects like Greenfield, the HTML5 compositor (https://github.com/udevbe/greenfield) demonstrate the diversity we get from not having a single common core technology, are possible because of this belief in protocol & standards over implementations, eased though implementations might be from promoting something like Weston to the one-and-only implementation.
> The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there.
We can't look at a anti-plays-well-with-others entity like Nvidia to assess what is/isn't a good idea. Nvidia spent nearly a decade stomping their feet & demanding only their way was ok. The fact that Embedded OpenGL itself, what the rock their obstinacy was built around (EGLStreams), is quite heavily on the way out further should stress how foolish & self-centered this vendor has been. This discompatibility indicates nothing, is no sign, except an indicator of what kind of a company Nvidia is/was (one that obstructed any implementations of well known & common kernel constructs).
All in all, the basics of Wayland are a pretty tight package. https://wayland-book.com/ goes through the pieces, and it's not a super thick read. The system of passing around surfaces is comprehensible, tight, makes sense, and there is very little fluff or barriers here, imo.
Wayland has a common core, but absolutely I'd grant that the various protocols do indeed make it a much less tightly coupled thing, with different compositors having different sets of protocols they support. So yes, some apps that require advanced capabilities run much better in some compositors than others; the compositor choice matters. Sometimes there are multiple competing protocols for the same feature-sets, but usually/historically, wayland-protocols hammers stuff out reasonably quickly & most of this is a matter of time.
Still, this is often easier than the past, where apps would have to each test for extensions & have various fast/regular/fallback codepaths depending on available extensions; not necessarily a hindrance to the window-manager, but a bundle of complexity for everyone else trying to use X11 adequately. The Wayland common primitives, on the other hand, are fairly universally performant & well chosen.
Returning to complexity for window-manager/compositor, the situation is not unlike X11 itself, where yes, a simple window manager (or compositor) is possible to spin up relatively quickly, but where there is a sea of different standards to implement to do a good job. Window manager hints, extended window manager hints, and a plethora of other standards existed around X11 that were up to the window-manager to tackle, and implementing each of those took a lot of time too, if you wanted good support for all apps. Different Wayland compositors also have different support for different protocols, and those are a bit deeper rooted capabilities, less superficial than many of the X11 hints (which, if ignored, were less likely to impede use), but the idea is the same: real support to really be decent took work in X11, and it takes work in Wayland to implement a good suite of protocols here too.
Where I disagree highly is calling out the hardware here. Wayland is closely tied to kernel fundamentals; any reasonably supported video card will perform adequately under any competent/non-specialist compositor today. (Certainly some compositors could demand higher standards, such as some of the experimental compositors requiring Vulkan, but generally compositors have very similar, very common requirements.)
> I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
I like where we are, where there are various toolkits/libraries for accelerated implementing. Wlroots, which underpins chiefly Sway (the i3 replacement), has given rise to a variety of other compositors, spanning the gamut from quick/fast/experimental to rich/deep/powerful. libwayland still defines some core ideas, if not compositing implementations, to speed development somewhat. Weston is still available as a reference compositor, although yes it's designed (more or less) to be forked & enhanced, not built to be preserved & built (extensibly) on top of. Wlroots & other alternative toolkits fill this need, & provide a diversity of ideas for how we might get going. Projects like Greenfield, the HTML5 compositor (https://github.com/udevbe/greenfield) demonstrate the diversity we get from not having a single common core technology, are possible because of this belief in protocol & standards over implementations, eased though implementations might be from promoting something like Weston to the one-and-only implementation.
> The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there.
We can't look at a anti-plays-well-with-others entity like Nvidia to assess what is/isn't a good idea. Nvidia spent nearly a decade stomping their feet & demanding only their way was ok. The fact that Embedded OpenGL itself, what the rock their obstinacy was built around (EGLStreams), is quite heavily on the way out further should stress how foolish & self-centered this vendor has been. This discompatibility indicates nothing, is no sign, except an indicator of what kind of a company Nvidia is/was (one that obstructed any implementations of well known & common kernel constructs).
At least for me it felt like Xorg as long as it had been felt broken, and we saw those blogposts back then about it and were somewhat optimistic it would be a good fix. As usual though, it didn't really work out and years later things are still broken.
Now that we have pipewire, I don't have any major problem with wayland anymore and use it on both my laptop and desktop.
The elephant in the room that most people miss in these discussions is that these problems aren't so much bugs with any specific part of the Wayland stack as they are limitations core to the Wayland design.
It's not going to get better, because Wayland is a broken/malicious architecture: the protocol basically does nothing useful, leaving essential interfaces such as screen recording for individual "compositors" to define and implement mutually incompatibly. This means that nontrivial applications don't really target Wayland, rather they only target a finite set of Wayland compositors (or other, completely separate software stacks) that they have support for.
This sort of works in favor of "big" DEs like Gnome, but for the rest of the ecosystem it would mean death by fragmentation.
It's not going to get better, because Wayland is a broken/malicious architecture: the protocol basically does nothing useful, leaving essential interfaces such as screen recording for individual "compositors" to define and implement mutually incompatibly. This means that nontrivial applications don't really target Wayland, rather they only target a finite set of Wayland compositors (or other, completely separate software stacks) that they have support for.
This sort of works in favor of "big" DEs like Gnome, but for the rest of the ecosystem it would mean death by fragmentation.
This is correct, and is in fact more worrying than simply a bad implementation.
If there was a bad implementation, it could be fixed. Wayland, on the other hand, does not even specify a way to do things like screen recording, screen capture, automation software (e.g. wmctrl), or other miscellaneous screen features (e.g. Redshift) which effectively means that there is no way to do these things at all.
The official Wayland response is that these features need to be implemented by the individual window managers, but the absence of a standard or protocol specifying them means that (a) many window managers will not implement them and (b) those that do will do so in incompatible ways. Which means that a program like a screen recorder, that was previously agnostic to window managers, now must explicitly support each window manager separately, and even then it may not be possible to use everywhere.
X was a gargantuan mess, and it had to go. The by cutting it out, we've also cut out the only commonality, the lowest common denominator software, sitting between widget libraries and the video drivers. There is now no common interface to access a wide variety of important system functions, and no one has a plan going forward. Wayland refuses to step up.
If there was a bad implementation, it could be fixed. Wayland, on the other hand, does not even specify a way to do things like screen recording, screen capture, automation software (e.g. wmctrl), or other miscellaneous screen features (e.g. Redshift) which effectively means that there is no way to do these things at all.
The official Wayland response is that these features need to be implemented by the individual window managers, but the absence of a standard or protocol specifying them means that (a) many window managers will not implement them and (b) those that do will do so in incompatible ways. Which means that a program like a screen recorder, that was previously agnostic to window managers, now must explicitly support each window manager separately, and even then it may not be possible to use everywhere.
X was a gargantuan mess, and it had to go. The by cutting it out, we've also cut out the only commonality, the lowest common denominator software, sitting between widget libraries and the video drivers. There is now no common interface to access a wide variety of important system functions, and no one has a plan going forward. Wayland refuses to step up.
> The official Wayland response is that these features need to be implemented by the individual window managers
Ever since finding out Wayland is more like a library or spec (wasn't clear and I'm not really into the specifics) that the individual window managers implement, dropping the whole client/server and separation of display and window manager that X11 has, I've been kinda wondering in the back of my mind how long it'll be until someone designs a new system on top of Wayland to bring back that architecture... One that includes these missing APIs that window managers can use, making the new system the common target.
Ever since finding out Wayland is more like a library or spec (wasn't clear and I'm not really into the specifics) that the individual window managers implement, dropping the whole client/server and separation of display and window manager that X11 has, I've been kinda wondering in the back of my mind how long it'll be until someone designs a new system on top of Wayland to bring back that architecture... One that includes these missing APIs that window managers can use, making the new system the common target.
A few years ago?
https://gitlab.freedesktop.org/wlroots/wlroots
> missing APIs
They are not missing, they just were moved from the kitchen sink of X to things like xdg-portal and pipewire. This also helps with things like sandboxing for flatpak apps, where you want apps to ask for permission to record the screen.
https://gitlab.freedesktop.org/wlroots/wlroots
> missing APIs
They are not missing, they just were moved from the kitchen sink of X to things like xdg-portal and pipewire. This also helps with things like sandboxing for flatpak apps, where you want apps to ask for permission to record the screen.
> https://gitlab.freedesktop.org/wlroots/wlroots
No, that's what I was thinking of but couldn't remember the name of. I'm imagining separating the window manager like in X, making them interchangeable without having to hook in everything else.
No, that's what I was thinking of but couldn't remember the name of. I'm imagining separating the window manager like in X, making them interchangeable without having to hook in everything else.
> This sort of works in favor of "big" DEs like Gnome, but for the rest of the ecosystem it would mean death by fragmentation.
Yeah, it encourages more consolidation, e.g. many projects build on wlroots. Not really different from how it has been before (reuse X and this WM and this compositor and ...). The only difference is that instead of a giant X and the kitchen sink and 50 different small projects on top, you now have a small wayland + xdg-portals + one of gnome/kde/wlroots to build on.
> nontrivial applications don't really target Wayland, rather they...
That sounds like a good thing. Instead of hacking X inputs (e.g. xdotool or xcape, just grabbing any input and window) in a horribly insecure and nonstandard way we now get proper standardized components like the above mentioned portals. So no, they don't target "complete separate software stacks", rather the complete opposite.
Yeah, it encourages more consolidation, e.g. many projects build on wlroots. Not really different from how it has been before (reuse X and this WM and this compositor and ...). The only difference is that instead of a giant X and the kitchen sink and 50 different small projects on top, you now have a small wayland + xdg-portals + one of gnome/kde/wlroots to build on.
> nontrivial applications don't really target Wayland, rather they...
That sounds like a good thing. Instead of hacking X inputs (e.g. xdotool or xcape, just grabbing any input and window) in a horribly insecure and nonstandard way we now get proper standardized components like the above mentioned portals. So no, they don't target "complete separate software stacks", rather the complete opposite.
> we now get proper standardized components
This is exactly the thing that's missing and it's practically impossible to hack on top of Wayland now, because any new standard that appears would be just another competing standard (ref. xkcd).
This is exactly the thing that's missing and it's practically impossible to hack on top of Wayland now, because any new standard that appears would be just another competing standard (ref. xkcd).
Except that we got screen recording and all that, so it is seems very much possible.
> any new standard that appears would be just another competing standard
That seems to contradict what you just argued. Adding a new standard is hard and needs buy-in from at least one of gnome/kde/wlroots. So instead of "there are now 15 standards" you have a much more pressure to agree on just one.
> any new standard that appears would be just another competing standard
That seems to contradict what you just argued. Adding a new standard is hard and needs buy-in from at least one of gnome/kde/wlroots. So instead of "there are now 15 standards" you have a much more pressure to agree on just one.
I think calling waylaid malicious is insane. What’s malicious and ignorant is this comment.
I’m pretty sure wayland just follows the small core with plugins strategy. If you prefer the kitchen sink way then whatever. There are official extensions to the protocol here https://gitlab.freedesktop.org/wayland/wayland-protocols and there is also the Wlroots library that can be used to implement a compositor. So, no, those smaller projects are not being “persecuted”
I’m pretty sure wayland just follows the small core with plugins strategy. If you prefer the kitchen sink way then whatever. There are official extensions to the protocol here https://gitlab.freedesktop.org/wayland/wayland-protocols and there is also the Wlroots library that can be used to implement a compositor. So, no, those smaller projects are not being “persecuted”
Right. The problem with projects like systemd and wayland isn't technical, it's social.
Will this bullshit false information ever die? Please check out the project again, because apparently you failed to understand it.
Like, you do realize that the “core” protocol set is ever growing and there has been a standard for screen capture for well over a year now to the point where even discord and the like just works on every wayland implementation? There is usually a bit of experimentation done individually to see what sticks and later a core/accepted protocol is proposed that is shared by everyone.
Like, you do realize that the “core” protocol set is ever growing and there has been a standard for screen capture for well over a year now to the point where even discord and the like just works on every wayland implementation? There is usually a bit of experimentation done individually to see what sticks and later a core/accepted protocol is proposed that is shared by everyone.
Out of curiosity: How do you get screen sharing on Discord? I've been trying to get it running for some time now, but wasn't able to. (arch, gnome)
Do you mean the web client or the electron app? The former should work if the browser itself is compiled with the necessary flags (at least chrome, chromium, firefox), and I believe they are mostly packaged this way nowadays.
The electron app is not yet working as per the arch linux wiki.
The electron app is not yet working as per the arch linux wiki.
Other compositors need to stop fighting and copy GNOME's protocols.
Even if all current Wayland compositors adopted Gnome's protocol extensions, that wouldn't really solve anything; because another compositor could appear next week and choose to abide by pure Wayland, ignoring Gnome's quasi-standard. Where does that leave app authors?
Apps can say that they support Real Wayland not Vanilla Wayland.
Controversial comment but it seems quite valid. I have never once seen any kind of debate about why the Gnome spec is not workable. It's all open source and widely integrates with the wider ecosystem.
Wayland might not be the place for such specs and another common standard should be adopted.
Wayland might not be the place for such specs and another common standard should be adopted.
For one thing, the client-side vs. server-side decorations schism is philosophical and has no right answer. But the community simply doesn't have the resources to implement both so AFAIK the GNOME/CSD side mostly pretends SSD doesn't exist and the SSD side complains about being oppressed.
I think there are two group opinions in this discussion and both are correct: The concept of Wayland is great and well-implemented. The implementation of Wayland is bad. Now if only the first group would trust the second's experiences with Wayland. It really is trash.
Firefox will stop updating the window contents but will still accept clicks and keypresses. You can either start a new Firefox process or go to the application switcher to see the updated window contents.
OpenSCAD editor has a one second lag between a keypress and the character appearing.
Those are the two that affect me everyday.
Firefox will stop updating the window contents but will still accept clicks and keypresses. You can either start a new Firefox process or go to the application switcher to see the updated window contents.
OpenSCAD editor has a one second lag between a keypress and the character appearing.
Those are the two that affect me everyday.
> The concept of Wayland is great and well-implemented. The implementation of Wayland is bad.
I'm going to disagree; some Wayland implementations of Wayland are good, but the concept is bad. Wayland is a beautiful, elegant protocol that does almost nothing, instead delegating everything more interesting than "display these pixels" to other protocols. That could have worked, but in reality nothing else was actually standardized (n.b. if a "standard" isn't implemented by GNOME, KDE, and libroots, it's not actually a standard), so there is no useful "Wayland" only many Wayland implementations. If you pick an implementation that covers every feature you want, it's great! And if you ever want anything it didn't implement, or ever want to use software targeting a different implementation, you're stuck. Thus, I say Wayland is a bad concept, because it ensures that everyone will be forever reimplementing everything, incompatibly.
I'm going to disagree; some Wayland implementations of Wayland are good, but the concept is bad. Wayland is a beautiful, elegant protocol that does almost nothing, instead delegating everything more interesting than "display these pixels" to other protocols. That could have worked, but in reality nothing else was actually standardized (n.b. if a "standard" isn't implemented by GNOME, KDE, and libroots, it's not actually a standard), so there is no useful "Wayland" only many Wayland implementations. If you pick an implementation that covers every feature you want, it's great! And if you ever want anything it didn't implement, or ever want to use software targeting a different implementation, you're stuck. Thus, I say Wayland is a bad concept, because it ensures that everyone will be forever reimplementing everything, incompatibly.
> Thus, I say Wayland is a bad concept, because it ensures that everyone will be forever reimplementing everything, incompatibly.
Why do you think that? There are some arguments on bleeding edge protocol proposals, but once they are wide-spread enough they seem to get implemented by everyone equally well - causing apps to depend on them and solidifying those.
I don’t see any problem here, the slight slowness of certain proposals is simply the bazaar style development where unlike Apple, linux can’t just decide on a fix thing, it has to get a certain network effect going for it firts.
Why do you think that? There are some arguments on bleeding edge protocol proposals, but once they are wide-spread enough they seem to get implemented by everyone equally well - causing apps to depend on them and solidifying those.
I don’t see any problem here, the slight slowness of certain proposals is simply the bazaar style development where unlike Apple, linux can’t just decide on a fix thing, it has to get a certain network effect going for it firts.
> Why do you think that? There are some arguments on bleeding edge protocol proposals, but once they are wide-spread enough they seem to get implemented by everyone equally well - causing apps to depend on them and solidifying those.
Bleeding edge? As far as I can tell, GNOME and wlroots still have incompatible APIs for screenshots.
> it has to get a certain network effect going for it
When it takes years to get network effects for little things like screenshots and screen sharing, I certainly see a problem here.
Bleeding edge? As far as I can tell, GNOME and wlroots still have incompatible APIs for screenshots.
> it has to get a certain network effect going for it
When it takes years to get network effects for little things like screenshots and screen sharing, I certainly see a problem here.
It is lesson from X11.
X11 has many things, for example drawing primitives in core; nobody uses it, but it has to be there, because it was specified so.
Wayland extensions, not being mandatory, solve exactly this problem - if something is not used, it could be removed and clients will know very well, that it is not there.
X11 has many things, for example drawing primitives in core; nobody uses it, but it has to be there, because it was specified so.
Wayland extensions, not being mandatory, solve exactly this problem - if something is not used, it could be removed and clients will know very well, that it is not there.
I can easily agree that X11 had a problem with way too many things in the core spec, and I'm 100% on board with breaking things out. The problem is that they shipped the thing with none of the additional extensions actually defined, which meant that when people went to implement everything outside of the (correctly) tiny core they implemented things differently and incompatibly. It's like a return to the days when the web had multiple major browser engines, and every time you wanted to do something you had to look up what browsers implemented it and what charming little quirks each implementation had.
It was actually a case with X11 too... it took some time to converge on XFree86, or what became X.org eventually. Yes, it is annoying, I agree, but it will get better.
I'm not sure it can get better to the same degree. With X, we ended up mostly with X.org dominating the space, and that meant that it became the de-facto standard way to do certain things - I honestly don't know how many of setxkbmap, xrandr, clipboard management, color management, etc. are X11 features vs X.org features, but either way they were all centralized and worked the same no matter what window manager or desktop environment you put on top of Xorg. With Wayland, there's nothing to ensure that they will converge; GNOME can pick a way to do keyboard layout and just stick with that forever, and wlroots can pick a way to do keyboard layout and just stick with that forever, and users will forever be stuck having to look up how each compositor does or doesn't support changing keyboard layout. (This is not an idle problem to me; I recently found a wayland compositor that I wanted to try, and discovered that in spite of using wlroots it didn't actually expose any way to configure keyboard layout. With a X11 window manager, I'd just run setxkbmap and be done, but with wayland it's literally impossible for me to solve without writing code.)
xrandr (and predecessors, like xf86vidmode, xf86dga, xf86miscsetsaver) , xrender, xvideo (& xvmc) were X.org-isms. If you tried to run against another Xserver, the app either had to handle the case without the extensions, or you didn't run it.
setxkbmap is another interesting thing. There are about two people in the world that know, how it works. Additionally, the linux console used separate mechamism to set console keyboard and font. So it was a duplication of a kind. The nice thing about wayland compositors is, that they remove duplications; X.org (or was it XFree86?) originally included it's own dynamic linker / module loader, driver system and another functionality, that should not be a business of a display server.
So I'm a bit more optimistic. It will became better to the same degree, but it won't be tomorrow. It wasn't quick for X11 either, it took literally decades. Not a consolation, I know.
setxkbmap is another interesting thing. There are about two people in the world that know, how it works. Additionally, the linux console used separate mechamism to set console keyboard and font. So it was a duplication of a kind. The nice thing about wayland compositors is, that they remove duplications; X.org (or was it XFree86?) originally included it's own dynamic linker / module loader, driver system and another functionality, that should not be a business of a display server.
So I'm a bit more optimistic. It will became better to the same degree, but it won't be tomorrow. It wasn't quick for X11 either, it took literally decades. Not a consolation, I know.
In my ~6 years of using Wayland I've never experienced anything like this. In fact, my experience has been that the entire desktop experience was smoother and less buggy.
Admittedly, I've steered clear of NVIDIA products which may have helped.
Admittedly, I've steered clear of NVIDIA products which may have helped.
I used Wayland for almost everything (AMD GPU), but the performance for some applications such as Blender are absolutely abysmal currently.
I have to switch to X when using those apps.
I have to switch to X when using those apps.
You also may have a different config. For example, I use fractional scaling on my laptop (1.5x) which means firefox sometimes crashes when I open the menu, but when I'm using my external monitor at 1x scaling it runs fine so you'd never notice.
https://bugzilla.mozilla.org/show_bug.cgi?id=1693474
https://bugzilla.mozilla.org/show_bug.cgi?id=1693474
I have a 30-bit 4K monitor. It's been an adventure learning about environmental flags and how "the root problem is upstream/downstream from our project"
[deleted]
> Firefox will stop updating the window contents but will still accept clicks and keypresses.
I've only ever had this behavior with FF running under XWayland. Are you sure FF isn't defaulting to X?
I've only ever had this behavior with FF running under XWayland. Are you sure FF isn't defaulting to X?
No. I'm not sure whether Xwayland or Wayland is used, and that's part of the problem.
In about:support, I have MOZ_ENABLE_WAYLAND=1 but also MOZ_USE_XINPUT2=1, which I haven't noticed until right now. xeyes doesn't respond at all (window freezes) so I can't tell which backend is actually in-use via xeyes. Finally, I'm using the package manager Firefox, and I'm not sure if that's different than the snap/flatpak.
In the OpenSCAD case, I've tried installing various qt-related and wayland-related packages and setting QT_QPA_PLATFORM or QT_DEBUG_PLUGINS, but this either ends in a crash or the same slow behavior.
In about:support, I have MOZ_ENABLE_WAYLAND=1 but also MOZ_USE_XINPUT2=1, which I haven't noticed until right now. xeyes doesn't respond at all (window freezes) so I can't tell which backend is actually in-use via xeyes. Finally, I'm using the package manager Firefox, and I'm not sure if that's different than the snap/flatpak.
In the OpenSCAD case, I've tried installing various qt-related and wayland-related packages and setting QT_QPA_PLATFORM or QT_DEBUG_PLUGINS, but this either ends in a crash or the same slow behavior.
> Firefox will stop updating the window contents but will still accept clicks and keypresses. You can either start a new Firefox process or go to the application switcher to see the updated window contents.
I've actually had this happen on macOS (seems to be occasionally triggered on wake from sleep) - assuming it's the same bug, it might not strictly be a wayland issue.
I've actually had this happen on macOS (seems to be occasionally triggered on wake from sleep) - assuming it's the same bug, it might not strictly be a wayland issue.
It's a weird strawman to say that Wayland's problem is that it's not a 1:1 replacement for Xorg. I don't think the author understands what Wayland is or what it intends to do, and it's sad that they didn't let that stop them from writing such a piece with incendiary language like this.
Wayland isn't a complete replacement of Xorg and has never been intended to be one. Nobody with close knowledge of the project has ever pretended it has - that premise just appears in severe oversimplifications and strawmen. Wayland is just a part of a rethink of how Linux desktop architecture works, together with Freedesktop standards for things like screen casting or window control [1]. The state of complete implementations of those Freedesktop standards - as well as application support - to the point it can replace a lot of X11 is pretty lacking for sure [2]. But that's just unfortunately just what you get when trying to establish such a new architecture in an underfunded and undirected community like the Linux desktop community. No need to "boycott" anything - just use whatever you like on Linux, like you always have.
[1]: E.g. contrary to what many people seem to understand, lacking screencasting support is not actually due to faults in """Wayland""", rather apps and desktops not properly supporting a wholly different Freedesktop standard made to work on Wayland compositors and X11 desktops alike (not dependent on any display protocol at all!). Screencasting on macOS, Windows and Wayland is not the display server's job, it's just one of the many things added to the kitchen sink that has become Xorg.
[2]: In fairness, it covers enough that it's working for a lot of people's workflows. It should work for way more people though, and I hope we get there.
Wayland isn't a complete replacement of Xorg and has never been intended to be one. Nobody with close knowledge of the project has ever pretended it has - that premise just appears in severe oversimplifications and strawmen. Wayland is just a part of a rethink of how Linux desktop architecture works, together with Freedesktop standards for things like screen casting or window control [1]. The state of complete implementations of those Freedesktop standards - as well as application support - to the point it can replace a lot of X11 is pretty lacking for sure [2]. But that's just unfortunately just what you get when trying to establish such a new architecture in an underfunded and undirected community like the Linux desktop community. No need to "boycott" anything - just use whatever you like on Linux, like you always have.
[1]: E.g. contrary to what many people seem to understand, lacking screencasting support is not actually due to faults in """Wayland""", rather apps and desktops not properly supporting a wholly different Freedesktop standard made to work on Wayland compositors and X11 desktops alike (not dependent on any display protocol at all!). Screencasting on macOS, Windows and Wayland is not the display server's job, it's just one of the many things added to the kitchen sink that has become Xorg.
[2]: In fairness, it covers enough that it's working for a lot of people's workflows. It should work for way more people though, and I hope we get there.
> Wayland isn't a complete replacment of Xorg and has never intended to be.
Red Hat seems to disagree:
> The X.org display server is deprecated, and will be removed in a future major RHEL release. The default desktop session is now the Wayland session in most cases.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
Red Hat seems to disagree:
> The X.org display server is deprecated, and will be removed in a future major RHEL release. The default desktop session is now the Wayland session in most cases.
https://access.redhat.com/documentation/en-us/red_hat_enterp...
Red Hat is certainly replacing something, but I need some help to see the implication that Wayland the display protocol is a complete replacement for X11 in that snippet. Part of the problem in the conversation, as I state in the sentence after the one you quote, is severe oversimplifications in how people - including Red Hat seemingly - talk about this.
That statement is very far from claiming it’s a “complete replacement”. It says “that is going away, use this now”.
No, that does not say what you think it does.
Nowhere does it say "complete" or "1:1", which is the point. Wayland is supposed to be different/better and that includes dropping some stuff and increasing security (e.g. screen recording or automation tools).
If X11 is going away without there being something to replace all of its use cases, then what are people supposed to do who need those automation tools, etc.?
Current Red Hat release have still like 15(?) years of support, so no rush.
Otherwise the same thing as usual: pay someone to build actually secure automation tools. The way X does these is horribly insecure and broken by design, so wayland rightfully says they won't support doing it that way. Nothing about not doing these ever.
Same for screen recording by the way. "Any app can see everything with absolutely no security"=not supported anymore. "Any app can use this standard way to ask for permission to record"=new. Obviously that breaks older software, but that is on purpose. So you had a transition period where for instance OBS did not work on wayland, then it was updated and now it does.
Otherwise the same thing as usual: pay someone to build actually secure automation tools. The way X does these is horribly insecure and broken by design, so wayland rightfully says they won't support doing it that way. Nothing about not doing these ever.
Same for screen recording by the way. "Any app can see everything with absolutely no security"=not supported anymore. "Any app can use this standard way to ask for permission to record"=new. Obviously that breaks older software, but that is on purpose. So you had a transition period where for instance OBS did not work on wayland, then it was updated and now it does.
> Wayland is just a part of a rethink of how Linux desktop architecture works, together with Freedesktop standards for things like screen casting or window control.
Well, that's part of the problem: I think the consensus is that a lot of these solutions are bunk. Wayland doesn't feel like something you'd build a desktop with, it feels like a software API for digital signage or maybe something for an iPad-like UI. This is cool, but shoehorning it into a desktop is a bad idea. The entire desktop space has moved on, Wayland is comparatively low-tech at this point. Quartz is a good example of this. Not only is it more secure than Wayland, it supports features like app indicators and global menus controls. That's a problem. An even bigger problem is that Mutter, the official Wayland implementation, exists exclusively to support GNOME. Other desktop developers are not welcome, instead they're tossed wlroots and told to make do.
Developmentally, I think Wayland is a trainwreck. If it is a "rethink", then it should have been used to design a tablet OS instead of a desktop OS that runs desktop software and supposedly supports legacy features/apps. If you disagree, then maybe you'd enjoy Windows 8, which is a similarly brave reimagining of the future of the desktop.
Well, that's part of the problem: I think the consensus is that a lot of these solutions are bunk. Wayland doesn't feel like something you'd build a desktop with, it feels like a software API for digital signage or maybe something for an iPad-like UI. This is cool, but shoehorning it into a desktop is a bad idea. The entire desktop space has moved on, Wayland is comparatively low-tech at this point. Quartz is a good example of this. Not only is it more secure than Wayland, it supports features like app indicators and global menus controls. That's a problem. An even bigger problem is that Mutter, the official Wayland implementation, exists exclusively to support GNOME. Other desktop developers are not welcome, instead they're tossed wlroots and told to make do.
Developmentally, I think Wayland is a trainwreck. If it is a "rethink", then it should have been used to design a tablet OS instead of a desktop OS that runs desktop software and supposedly supports legacy features/apps. If you disagree, then maybe you'd enjoy Windows 8, which is a similarly brave reimagining of the future of the desktop.
Mutter is not the “official Wayland implementation”. Wayland has one reference implementation: Weston https://gitlab.freedesktop.org/wayland/weston
It's fair to point out problems in the general project and philosophy, but I think that's a different conversation. The discussion at hand points to general compatibility problems that have never been promised. Even if Wayland had been a different project with the properties you desire (which at face value seem fair enough), that still wouldn't have delivered anything like the strawman 1:1 Xorg compatibility this blog talks about, nor would it likely have overcome the general messiness and lack of direction on the Linux desktop that's keeping both X11 and non-X11 desktops back.
And app-indicators, global menu controls can all be implemented as new wayland protocols and after they get accepted by the majority those can appear reliably everywhere (instead of only in Unity, remember?)
And I fail to see your point, you are mixing up wayland’s tasks quite a bit here. It is pretty similar to Quartz, in that it is also a compositor (as is every other OS’s display manager by the way, it is time for Linux to also get there)
And I fail to see your point, you are mixing up wayland’s tasks quite a bit here. It is pretty similar to Quartz, in that it is also a compositor (as is every other OS’s display manager by the way, it is time for Linux to also get there)
Most of those seem like a consequence of good design? I don't want one process to be able to decide that it's windows should be higher priority than another process, or see what's displayed on another processes windows, or steal keystrokes from windows owned by another process. So I think the net effect of that list is to make me less likely to use Xorg.
Good security doesn't prevent users from executing a legitimate use case though. A user can have legitimate reasons for wanting to share a certain window or their entire screen with a process like Zoom. Once you start preventing users from executing their use case you turn the user into an adversary. They'll start undermining your security model and you will always lose that fight.
This is why permission models exist, make the user aware of the security implications and allow the user to decide on a per-app basis what permissions should be granted. Make the user complimentary to your security model rather than making them an adversary.
This is why permission models exist, make the user aware of the security implications and allow the user to decide on a per-app basis what permissions should be granted. Make the user complimentary to your security model rather than making them an adversary.
> Once you start preventing users from executing their use case you turn the user into an adversary.
I'm reminded of an early systemd security choice that killed all of a users processes on logout, for 'security'. Because they didn't personally have the use-case of wanting to fire off long-running jobs, so didn't consider it.
(I'm not raging at systemd, I like the unit files and while I have some concerns about the design, in general I believe it's a positive thing to have around. IIRC this issue was fixed fairly quickly when it came to light.)
I'm reminded of an early systemd security choice that killed all of a users processes on logout, for 'security'. Because they didn't personally have the use-case of wanting to fire off long-running jobs, so didn't consider it.
(I'm not raging at systemd, I like the unit files and while I have some concerns about the design, in general I believe it's a positive thing to have around. IIRC this issue was fixed fairly quickly when it came to light.)
They still do this. It really sucks when you don't expect it. I wish the people who wanted all this crap would just go run ChromeOS since it does what they want better anyway.
Downvoters: The systemd default really is still to do this, it's just become less obvious because individual distros have been changing it since the initial fallout instead of accepting systemd's default configs.
Really?
Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it.
Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?
I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems.
Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.
Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?
I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems.
Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.
> From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it.
Sure, agreed — and the standard way this was done for decades was by sending a HUP signal to the processes. And the standard way for decades that the user could say, 'hey, don't kill this one process; leave it running' was to use nohup. Systemd just decided to ignore nohup and kill every process, period. After all, it's just as simple for a user to learn the systemd model and how to write systemd unit files, open a text editor, actually write a unit file, install the unit file and use systemctl to start the process as it was to write 'nohup daemon,' right?
This is an example of the sheer unmitigated hubris behind the systemd project. Wayland feels very similar to me. Maybe that's not fair, but it sure feels like it. All I know is that with Wayland I cannot use Linux and Unix for over three decades. It definitely seems to do some things right, but it also seems to do some things wrong, and some things needlessly weirdly.
Among other things, it seems way too difficult to write a compositor from scratch. I am trying to minimise the amount of C/C++ in my life: one nice thing about X is that X bindings exist for many languages which do not rely on xlib or xcb.
Sure, agreed — and the standard way this was done for decades was by sending a HUP signal to the processes. And the standard way for decades that the user could say, 'hey, don't kill this one process; leave it running' was to use nohup. Systemd just decided to ignore nohup and kill every process, period. After all, it's just as simple for a user to learn the systemd model and how to write systemd unit files, open a text editor, actually write a unit file, install the unit file and use systemctl to start the process as it was to write 'nohup daemon,' right?
This is an example of the sheer unmitigated hubris behind the systemd project. Wayland feels very similar to me. Maybe that's not fair, but it sure feels like it. All I know is that with Wayland I cannot use Linux and Unix for over three decades. It definitely seems to do some things right, but it also seems to do some things wrong, and some things needlessly weirdly.
Among other things, it seems way too difficult to write a compositor from scratch. I am trying to minimise the amount of C/C++ in my life: one nice thing about X is that X bindings exist for many languages which do not rely on xlib or xcb.
Please check out my sibling comment on this thread.
> From a theoretical view, why is it a bad thing?
Because it changed longstanding behaviour for no good reason, without consulting anyone on whether they wanted it changed.
> Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?
Yes, if I instructed that user process to do so, and hadn't explicitly set something up to kill all processes on logout. 100% yes.
> I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks
It's not a hack, and it's not ignoring OS signals. HUP is explicitly a hangup, not a kill. If something keeps going after HUP, you leave it alone.
I log into a remote server and start some long compute job - why on earth should a continuing TCP connection get to be the determining factor in whether my job completes?
> But these are trivially portable
OK, but it is an effort to port, even if it's a small one, and it complicates a very simple way of working.
> some manageable breaking changes instead.
This wasn't a 'manageable' breaking change. It wasn't advertised (clearly, because the distros rolled it back when it was discovered) and it broke stuff, because the people writing the new shiny hadn't even considered that it might be a legitimate use case.
They didn't think and things broke. You don't get to paint that as innovation.
Because it changed longstanding behaviour for no good reason, without consulting anyone on whether they wanted it changed.
> Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along?
Yes, if I instructed that user process to do so, and hadn't explicitly set something up to kill all processes on logout. 100% yes.
> I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks
It's not a hack, and it's not ignoring OS signals. HUP is explicitly a hangup, not a kill. If something keeps going after HUP, you leave it alone.
I log into a remote server and start some long compute job - why on earth should a continuing TCP connection get to be the determining factor in whether my job completes?
> But these are trivially portable
OK, but it is an effort to port, even if it's a small one, and it complicates a very simple way of working.
> some manageable breaking changes instead.
This wasn't a 'manageable' breaking change. It wasn't advertised (clearly, because the distros rolled it back when it was discovered) and it broke stuff, because the people writing the new shiny hadn't even considered that it might be a legitimate use case.
They didn't think and things broke. You don't get to paint that as innovation.
Sighup already does this by default. You have tools like nohup and tmux that explicitly (as in, you won't do it accidentally) get around this and systemd breaks those. What bit me last time was running apt upgrade in tmux (I always do this so it doesn't get killed) and I came back to find that apt had been killed.
There wasn't any good reason to change this.
>hur dur why depend on evil systemd
Not everything needs to be a service. I don't mind writing services but stuff like my apt example shouldn't be. This effectively makes interactively using apt reliably over ssh impossible. Sure, I'm the stupid one for wanting usable tools though.
And this is why people reflexively avoid systemd; if you use it stuff just randomly breaks because "stagnation is bad."
There wasn't any good reason to change this.
>hur dur why depend on evil systemd
Not everything needs to be a service. I don't mind writing services but stuff like my apt example shouldn't be. This effectively makes interactively using apt reliably over ssh impossible. Sure, I'm the stupid one for wanting usable tools though.
And this is why people reflexively avoid systemd; if you use it stuff just randomly breaks because "stagnation is bad."
No, nohup and tmux are not explicit at all, they simply ignore the signal. The OS has no way of knowing whether it is a frozen process, or one that wants to run in the background.
If I remember correctly, some systemd maintainer did try to help make tmux systemd-aware so that existing use case could work as-is, but they didn’t want to add it not even as an optional dependency so that’s on them.
I recommend checking out systemd-run, which has a similar mode to basically nohup, you can even alias it to that.
If I remember correctly, some systemd maintainer did try to help make tmux systemd-aware so that existing use case could work as-is, but they didn’t want to add it not even as an optional dependency so that’s on them.
I recommend checking out systemd-run, which has a similar mode to basically nohup, you can even alias it to that.
If you don't install a signal handler the process gets killed frozen or not. The only reason you would ever handle the hup signal is if you want exactly this behavior (user deciding when to terminate the process rather than the OS.) Give me one singular example where this isn't the case.
>I recommend
No. Respectfully, shut the fuck up and listen. It isn't just one thing like this. Every month systemd changes some fundamental thing like this and you trip over it. With systemd you trade knowing how the machine is going to behave (even if it's not intuitive to new people) with never knowing because fundamental crap is always changing. Yes there are always solutions but it really doesn't matter because next release something new will break and you'll only find out when it blows up in your face. With a platform you practically can't predict the behavior for correctness doesn't fucking matter. If I wanted an OS that behaved this way I would just run Windows.
>That's on them
No. Breaking standard platform behavior and demanding other projects depend on your rapidly changing project is not "on them."
>I recommend
No. Respectfully, shut the fuck up and listen. It isn't just one thing like this. Every month systemd changes some fundamental thing like this and you trip over it. With systemd you trade knowing how the machine is going to behave (even if it's not intuitive to new people) with never knowing because fundamental crap is always changing. Yes there are always solutions but it really doesn't matter because next release something new will break and you'll only find out when it blows up in your face. With a platform you practically can't predict the behavior for correctness doesn't fucking matter. If I wanted an OS that behaved this way I would just run Windows.
>That's on them
No. Breaking standard platform behavior and demanding other projects depend on your rapidly changing project is not "on them."
What if the program does install a signal handler, but it has a race condition and enters an infinite loop? What situation does that correspond to from the POV of the OS?
Signal handlers are simply not sufficient to discern between “ok, I’m getting ready for termination”, “I don’t want to terminate”, “not listening”, and “process not responding”. Just because it has been used for decades, doesn’t mean it was ever good. UNIX has plenty less than great decisions that became set in stone.
Signal handlers are simply not sufficient to discern between “ok, I’m getting ready for termination”, “I don’t want to terminate”, “not listening”, and “process not responding”. Just because it has been used for decades, doesn’t mean it was ever good. UNIX has plenty less than great decisions that became set in stone.
>What if it crashes
If an interactive program crashes the user would notice and kill it. If you never handle the nohup signal (and, again, the only reason for handling it in an interactive program is because you want that program to persist when the tty goes away and almost the only things that do this are tools like nohup and tmux, not the processes that run inside them) then your crashed program is going to be killed by the hup signal when the user closes their terminal.
Yes you can contrive pathological examples, yes signals are hacky in general. You're never going to be able to come up with a real problem with this other than "misusing tmux and nohup to manage deamons instead of initd causes problems." There isn't a legitimate problem with handling the hup signal for interactive tools when the user is expecting it.
>RE: Discerning between states
Yeah if you want the OS to manage a process for you write a service. I'm not going to write a service for everything I do interactively that needs to not die if there's a network problem.
Again, because you seem to be missing it, handling the hup signal in an interactive program is just a way to tell the OS that the user is managing the program themselves. If the user does this and then decides not to manage it, "that's on them."
And finally, the real problem here is that systemd breaks stuff like this all the time and makes the platform unpredictable unless you spend time reading the release notes.
If an interactive program crashes the user would notice and kill it. If you never handle the nohup signal (and, again, the only reason for handling it in an interactive program is because you want that program to persist when the tty goes away and almost the only things that do this are tools like nohup and tmux, not the processes that run inside them) then your crashed program is going to be killed by the hup signal when the user closes their terminal.
Yes you can contrive pathological examples, yes signals are hacky in general. You're never going to be able to come up with a real problem with this other than "misusing tmux and nohup to manage deamons instead of initd causes problems." There isn't a legitimate problem with handling the hup signal for interactive tools when the user is expecting it.
>RE: Discerning between states
Yeah if you want the OS to manage a process for you write a service. I'm not going to write a service for everything I do interactively that needs to not die if there's a network problem.
Again, because you seem to be missing it, handling the hup signal in an interactive program is just a way to tell the OS that the user is managing the program themselves. If the user does this and then decides not to manage it, "that's on them."
And finally, the real problem here is that systemd breaks stuff like this all the time and makes the platform unpredictable unless you spend time reading the release notes.
Wayland doesn't prevent anything that people need, but the APIs are different and apps need to be ported. (Worst case, certain features need to be implemented in the compositor itself not in an app.)
Yeah. The most of the screen sharing and recording issues are easily solvable.
It just takes engineering time, and time is money.
As from the global user space, Wayland is in minority, for example for Zoom to create proper support.
Is a standard Google Meet meeting in Chrome for Linux on a Wayland desktop not functional?
Usually not, no.
There are two processes that need to be running that somewhat work.
xdg-desktop-portal & xdg-desktop-portal-wlr
Even then it can be garbled, only supports one screen, and you can’t use it if the process was started under Xwayland - which is opaque when it’s being used.
Might be better under Firefox, but chrome is spotty for me.
There are two processes that need to be running that somewhat work.
xdg-desktop-portal & xdg-desktop-portal-wlr
Even then it can be garbled, only supports one screen, and you can’t use it if the process was started under Xwayland - which is opaque when it’s being used.
Might be better under Firefox, but chrome is spotty for me.
Disabling Xwayland, if you can, makes wayland a much better experience. Not possible for everyone, as you may have software that doesn't work on Wayland, but I ran my daily driver Arch laptop with sway and no X at all for years, everything worked really well.
I have run my daily driver Fedora machine with Gnome and no X at all since May 2021, everything has worked really well for me, too.
I haven't disabled Xwayland, but I have configured the apps that by default do not do it (in my case, Emacs and Chrome) to avoid Xwayland and instead to talk directly to Wayland.
(Gnome's interface design decisions are not very good IMO, but that's clearly not Wayland's fault).
At least some of comments on supposed defects in the architecture of Wayland seem to me to be written by long-time X users who simply do not like change. (I used MacOS for 11 years before I switched to Fedora and barely remember X.)
The problem for those that want to continue to use X -- well, Xserver to be specific -- is that nobody wants to maintain it.
I haven't disabled Xwayland, but I have configured the apps that by default do not do it (in my case, Emacs and Chrome) to avoid Xwayland and instead to talk directly to Wayland.
(Gnome's interface design decisions are not very good IMO, but that's clearly not Wayland's fault).
At least some of comments on supposed defects in the architecture of Wayland seem to me to be written by long-time X users who simply do not like change. (I used MacOS for 11 years before I switched to Fedora and barely remember X.)
The problem for those that want to continue to use X -- well, Xserver to be specific -- is that nobody wants to maintain it.
> Disabling Xwayland, if you can, makes wayland a much better experience. Not possible for everyone, as you may have software that doesn't work on Wayland, but I ran my daily driver Arch laptop with sway and no X at all for years, everything worked really well.
If I can't run suckless terminal then what's the point of having a computer on my desktop? At that point I might as well kill the GUI altogether!
If I can't run suckless terminal then what's the point of having a computer on my desktop? At that point I might as well kill the GUI altogether!
Does screen share work in firefox or chromium if you disable Xwayland and enable wayland rendering for those apps?
Yes, it works well in Firefox if you have the needed packages installed [0]. I don't use Chromium but apparently that works too.
[0] https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...
[0] https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...
Cool. I'm using sway and might need screen sharing in a few weeks. Will check this out.
Xwayland is probably going to be deprecated and removed anyway. It's only included for backward compatibility with "legacy applications". It's like DOS compatibility on Windows.
[deleted]
I guess we should deprecate and remove DOSBox too, right?
DOSBox exists because DOS legacy applications still exist, and will continue to exist for a very long time. The same is true of X legacy applications.
DOSBox exists because DOS legacy applications still exist, and will continue to exist for a very long time. The same is true of X legacy applications.
DOSBox is something different. I was referring to the largely incomplete legacy DOS compatibility on Windows NT based systems.
Soon it will get to the point where the UI toolkits that matter will have ported entirely to Wayland and remove their X11 compatibility code. When that happens, all modern apps will be Wayland-native only. That leaves legacy apps and toolkits that haven't gotten with the program. For those, a VM running an old OS with Xorg will suffice. That is the "DOSBox equivalent" here.
Soon it will get to the point where the UI toolkits that matter will have ported entirely to Wayland and remove their X11 compatibility code. When that happens, all modern apps will be Wayland-native only. That leaves legacy apps and toolkits that haven't gotten with the program. For those, a VM running an old OS with Xorg will suffice. That is the "DOSBox equivalent" here.
Sincerely hope not, I’ll be forced to go back to X11 for jetbrains tools and everything electron based.
(as the version that ships almost never has wayland support enabled in the sandbox browser- and even force enabling it where it isn’t compiled out crashes it randomly)
EDIT: why did I get downvoted for that? It’s extremely true and I’ve tried to run without Xwayland a lot.
(as the version that ships almost never has wayland support enabled in the sandbox browser- and even force enabling it where it isn’t compiled out crashes it randomly)
EDIT: why did I get downvoted for that? It’s extremely true and I’ve tried to run without Xwayland a lot.
Have you had the chance to report those random crashes as bugs (against Electron or your compositor?) I figure that would be helpful for all.
I’ve been using Electron apps natively on Wayland for quite a while with those force-enable flags you mentioned. Few issues so far.
At one point, the apps indeed started crashing. Turns out this was due to the compositor (wl-roots) evolving while the Chromium team didn’t get the memo. They quickly fixed it in Chromium though but not before people started filing bugs. Didn’t take long for their patch to bubble up to the next Electron patch release.
The sooner people report those crashes, the better for everyone involved.
I’ve been using Electron apps natively on Wayland for quite a while with those force-enable flags you mentioned. Few issues so far.
At one point, the apps indeed started crashing. Turns out this was due to the compositor (wl-roots) evolving while the Chromium team didn’t get the memo. They quickly fixed it in Chromium though but not before people started filing bugs. Didn’t take long for their patch to bubble up to the next Electron patch release.
The sooner people report those crashes, the better for everyone involved.
It won’t be deprecated, the very reason it exists is that there will always be plenty of software that won’t get ported to Wayland.
With Chromium having decent Wayland support since a while now, I expect Electron apps will catch up eventually. A major DE deprecating Xwayland would give packagers of Electron apps a reason to get around to it.
FWIW about a month ago I was interviewing, and had a few rounds of interviews on Google Meet. I was actually pleased to discover that it "Just Worked" on my Firefox/Wayland/KDE setup. Screen sharing, video backgrounds, the works. Unlike Zoom which insisted I could only use Gnome on Wayland.
I use Google Meet on Firefox on Wayland. Screen sharing works fine (now). It didn't for a while, admittedly, but now it does.
I'm using Google Meet via Firefox on Ubuntu 22.04 and have not had any success with screen or window sharing, so YMMV.
[deleted]
Sometimes those things are necessary for completely normal, non-nefarious use cases. Instead of giving you the option, you're not allowed to do it at all in the name of Safety®
I'm really not a fan of software being this presumptuous. The root of most of my gripes with things like Windows and macOS (not to mention most of the things gnome/freedesktop puts out) are entirely because of this mindset. I am not interested in infecting Linux with this baby-proofing as well.
Security maximalists, especially when removing or refusing to implement useful functionality as a result of that stance, should be reminded that the first pillar of security is availability.
I'm really not a fan of software being this presumptuous. The root of most of my gripes with things like Windows and macOS (not to mention most of the things gnome/freedesktop puts out) are entirely because of this mindset. I am not interested in infecting Linux with this baby-proofing as well.
Security maximalists, especially when removing or refusing to implement useful functionality as a result of that stance, should be reminded that the first pillar of security is availability.
Honestly you have the right perspective, but you can leave out calling on the "first pillar" of security, what I want people to realize is that security isn't the most important thing at all, it's just a competing concern amongst a number of others, one of those being actually useful for what you need.
Wanting to run programs without them being able to screw around with one another is a use case... and it's more a more common, fundamental one than wanting to run remote video conferencing or whatever.
More to the point, you can always add the ability to do stuff like that, when you have the time to do it in a way that lets the user decide what should and should not have any given kind of access. On the other hand, if you start out by just letting everything run amok and then try to add controls later, assumptions will get changed underneath existing programs. That pretty much always makes things break in ugly ways... if it's even possible to do it at all, which is not guaranteed if you didn't think hard before you designed the function to begin with.
More to the point, you can always add the ability to do stuff like that, when you have the time to do it in a way that lets the user decide what should and should not have any given kind of access. On the other hand, if you start out by just letting everything run amok and then try to add controls later, assumptions will get changed underneath existing programs. That pretty much always makes things break in ugly ways... if it's even possible to do it at all, which is not guaranteed if you didn't think hard before you designed the function to begin with.
Remote video conferencing is vastly more popular than Linux at this point with work from home, remote doctors appointments, and travel issues.
It's now something your 70 year grandmother who doesn't understand computers does.
It's now something your 70 year grandmother who doesn't understand computers does.
My 70 year old grandmother (who'd only be about 10 years older than I am, which is a bit strange...) ALSO runs other programs all the time, and does not expect them to interfere with one another in confusing or malicious ways.
In 19 years I've never seen an application interfere with another in confusing or malicious ways. I don't want to give up actual functionality to solve imaginary problems.
Well, I have, but those were anti-viruses and are commonly understood to be crap outside of enterprise endpoint protection (And usually even then too) :)
This is peak “why do you want that?” An anti-pattern in OSS communities.
No, it's not. It's acknowledging that this is a new protocol, and is intentionally not designed to be a drop-in replacement for X because it makes different trade-offs.
Do you really think that Linux users are asking "why do you want that?" about screen sharing applications? Of course not. You can't implement screen sharing the same way you did in X, and software will need to change if it wants to support Wayland.
Do you really think that Linux users are asking "why do you want that?" about screen sharing applications? Of course not. You can't implement screen sharing the same way you did in X, and software will need to change if it wants to support Wayland.
It falls into a general bucket of vaguely gaslighting behavior wherein the person talking about how a particular use case is important, is met with the claim that it isn’t because of some reason (either it’s not a good use case, software design shouldn’t allow it, or it’s “already possible” in some convoluted way). This isn’t a unique situation, this kind of response happens over and over in the Linux community.
Except no one ever said “software design shouldn’t allow it,” which is the claim here. They said “this software won’t implement that feature the same way that other did, so there will need to be wider changes.”
Which shouldn’t surprise anyone changing their display server.
Which shouldn’t surprise anyone changing their display server.
They said Wayland is good design because it doesn’t allow this feature.
> I don't want one process to be able to […] see what's displayed on another processes windows
> I don't want one process to be able to […] see what's displayed on another processes windows
Quite the statement on an article that lists the biggest apps for screenrecording (like obs) saying wayland is broken and they won't work with it. Just pure persistence in the face of contrary evidence in front of your eyes. If OBS can't figure out how to support wayland there's something wrong with wayland.
This gist is from 2020. OBS does support Wayland now, AFAIK.
The main problem with Wayland seems to be that it's trying to fix some real problems such as those you mentioned but its solution is to build the house as a concrete and steel box without doors or windows. It's true that it's a more secure building that way but since it doesn't work as a house any more that doesn't really matter.
The wayland approach is indeed to build a house and it already has windows and doors for it (though perhaps the painting is not ready).
But that is much easier to do than not getting soaked in the rain when all you have is a door in the middle of nowhere.
But that is much easier to do than not getting soaked in the rain when all you have is a door in the middle of nowhere.
> I don't want one process to be able to decide that it's windows should be higher priority than another process, or see what's displayed on another processes windows, or steal keystrokes from windows owned by another process.
The traditional, greybeard way to deal with a misbehaving application is to stop using it. This “security” approach breaks all other applications instead.
The traditional, greybeard way to deal with a misbehaving application is to stop using it. This “security” approach breaks all other applications instead.
I don't want most of my processes to be able to do those things, but I do want some to. And if my only choices are all of my processes being able to do those things, or none of them being able to, I'd take the former.
I'm currently in the "X11 is still better group" but I will say the way QT does modals on X drives me up the wall and it would be nice to have something force it to behave.
This...seems like complete and total bullshit. It's so bad-faith I'm not going to bother responding to each pseudo-point. They're not wrong in a general sense that Wayland isn't a 1:1 compatible x replacement yet - that part is absolutely true - but this whole "boycott wayland!" nonsense is just done in such a way that I can only conclude malice as the author's objective.
Wayland DOES work with fractional scaling values. It's labeled "experimental" right now but in my personal experience it works fine on both GNOME and KDE.
"Nothing we can do from the $SOMESOFTWARE side so we're closing this issue." stuff is also bullshit. Yes, there IS something you can do from your side software wise, and that's UPDATE THE GOD DAMN SOFTWARE. Steam w/ Wine works out of the box with Wayland and GNOME on Fedora Workstation 36. I just did daily quests in The Elder Scrolls Online with it earlier today. I can even run Elden Ring in the exact same configuration. With a damn controller, no less.
So yeah, this is just bullshit.
Wayland DOES work with fractional scaling values. It's labeled "experimental" right now but in my personal experience it works fine on both GNOME and KDE.
"Nothing we can do from the $SOMESOFTWARE side so we're closing this issue." stuff is also bullshit. Yes, there IS something you can do from your side software wise, and that's UPDATE THE GOD DAMN SOFTWARE. Steam w/ Wine works out of the box with Wayland and GNOME on Fedora Workstation 36. I just did daily quests in The Elder Scrolls Online with it earlier today. I can even run Elden Ring in the exact same configuration. With a damn controller, no less.
So yeah, this is just bullshit.
> Wayland DOES work with fractional scaling values. It's labeled "experimental" right now but in my personal experience it works fine on both GNOME and KDE.
I'm not sure about how it works in KDE, but at least in GNOME the way it works is kind of a hack IMO. When you do a 150% scale, it renders to a framebuffer at 3x the resolution of your display and then scales the framebuffer down by 1/2, which compromises the video quality, as well as wasting CPU (and battery life if you use a laptop).
I'm not sure about how it works in KDE, but at least in GNOME the way it works is kind of a hack IMO. When you do a 150% scale, it renders to a framebuffer at 3x the resolution of your display and then scales the framebuffer down by 1/2, which compromises the video quality, as well as wasting CPU (and battery life if you use a laptop).
> When you do a 150% scale, it renders to a framebuffer at 3x the resolution of your display and then scales the framebuffer down by 1/2, which compromises the video quality,
Isn't that exactly how apple does fractional scaling?
> https://news.ycombinator.com/item?id=19052960
Isn't that exactly how apple does fractional scaling?
> https://news.ycombinator.com/item?id=19052960
It is exactly how Apple does fractional scaling.
There is also some kind of belief, that scaling down framebuffer is somehow demanding. It isn't. The output encoder (the modern equivalent of VGA DAC) can do it on the fly. For several overlaid planes, each at different scale, at once (one of these planes is going to be your cursor).
There is also some kind of belief, that scaling down framebuffer is somehow demanding. It isn't. The output encoder (the modern equivalent of VGA DAC) can do it on the fly. For several overlaid planes, each at different scale, at once (one of these planes is going to be your cursor).
That's just how GNOME/GTK handles scaling on any platform, it's unrelated to what the underlying display server can do.
Windows DWM, Android's SurfaceFlinger, and Wayland allow for true native per display fractional scaling but it's still up to each app to actually use it.
Windows DWM, Android's SurfaceFlinger, and Wayland allow for true native per display fractional scaling but it's still up to each app to actually use it.
Is this true for all windows or only ones running in Xwayland?
Does fractional scaling work with xwayland.
Depends how you define "work".
Since X11 apps can find out the display dpi and render accordingly, they do not communicate to compositor at which scale they really do render their contents. This gets even more interesting, once there are multiple scales (i.e. you have multiple displays, each at different scale).
This leads to compromise, where xwayland assumes that all X11 clients render at 96 dpi and upscales them to the actual one. It is not pretty, bilinear would not be my choice of algorithm here, but the apps are at least correct size. There are patches floating around that modify this assumption, let X11 clients render at actual dpi, and if they don't, let have the user apps with tiny UI. So YMMV.
Since X11 apps can find out the display dpi and render accordingly, they do not communicate to compositor at which scale they really do render their contents. This gets even more interesting, once there are multiple scales (i.e. you have multiple displays, each at different scale).
This leads to compromise, where xwayland assumes that all X11 clients render at 96 dpi and upscales them to the actual one. It is not pretty, bilinear would not be my choice of algorithm here, but the apps are at least correct size. There are patches floating around that modify this assumption, let X11 clients render at actual dpi, and if they don't, let have the user apps with tiny UI. So YMMV.
This actually works seamlessly on X wherein one can scale down lower DPI displays down from a higher resolution so everything is drawn the same size. However X does this it doesn't result in a blurry mess. Logically there is no particular reason it can't be done well on xwayland.
To be charitable one would suppose that its just a low priority as fewer people have high dpi displays. If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard. If you listen to these people talk the less charitable interpretation sounds entirely plausible.
To be charitable one would suppose that its just a low priority as fewer people have high dpi displays. If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard. If you listen to these people talk the less charitable interpretation sounds entirely plausible.
> This actually works seamlessly on X wherein one can scale down lower DPI displays down from a higher resolution so everything is drawn the same size.
Where does it work seamlessly? Yes, Chrome can do that. Gimp and myriad of other X11 apps can't.
I will repeat the point from the previous comment: from the point of compositor there is no way to tell, whether the X11 client does support dpi properly or not. And since it cannot tell (short of guessing), it assumes they don't.
In theory, you could invent a new protocol for X11 apps announcing their capabilities. But good luck with adoption, you may switch to an entirely incompatible protocol as well.
> To be charitable one would suppose that its just a low priority as fewer people have high dpi displays
Strictly speaking, it is not a problem with hidpi. It is problem with fractional scaling.
With hidpi on and fractional scaling off (not set to 200%, entirely turned off), you get all the 1:1 pixel glory. If some app doesn't adjust to dpi, you will see that immediately (basically everything except gtk3+, qt5+ and current firefox/chrome/electron). I actually prefer the blurry one, it makes the apps at least usable.
> If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard.
IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all.
> If you listen to these people talk the less charitable interpretation sounds entirely plausible.
AFAIK there were multiple approaches tried. Even theone, where whitelisted (i.e. the ones that passed manual test) applications would be allowed to run hidpi and the rest upscaled. It went nowhere.
But as they say, patches welcome.
Where does it work seamlessly? Yes, Chrome can do that. Gimp and myriad of other X11 apps can't.
I will repeat the point from the previous comment: from the point of compositor there is no way to tell, whether the X11 client does support dpi properly or not. And since it cannot tell (short of guessing), it assumes they don't.
In theory, you could invent a new protocol for X11 apps announcing their capabilities. But good luck with adoption, you may switch to an entirely incompatible protocol as well.
> To be charitable one would suppose that its just a low priority as fewer people have high dpi displays
Strictly speaking, it is not a problem with hidpi. It is problem with fractional scaling.
With hidpi on and fractional scaling off (not set to 200%, entirely turned off), you get all the 1:1 pixel glory. If some app doesn't adjust to dpi, you will see that immediately (basically everything except gtk3+, qt5+ and current firefox/chrome/electron). I actually prefer the blurry one, it makes the apps at least usable.
> If one was less charitable making X apps work slightly shittier serves as motivation for developers to support the new standard.
IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all.
> If you listen to these people talk the less charitable interpretation sounds entirely plausible.
AFAIK there were multiple approaches tried. Even theone, where whitelisted (i.e. the ones that passed manual test) applications would be allowed to run hidpi and the rest upscaled. It went nowhere.
But as they say, patches welcome.
Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment. 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter.
Smaller changes can be handled with scale and mixed dpi by scaling down from higher res. Note the end result is again not blurry.
You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d
One in general doesn't need to worry after setup if a particular app will work, if it will be wayland native or xwayland, if it will look different on different DPI displays, if it will be blurry, if all functionality will work.
All high and mixed DPI concerns are front loaded into a tiny amount of time setting it up in a way that will just work well without compromise.
A tiny amount of effort by your distro could easily erase even that by simply doing it for you.
>IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all.
This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you.
Then you can call them all luddites for caring more about working hardware than plumbing.
Smaller changes can be handled with scale and mixed dpi by scaling down from higher res. Note the end result is again not blurry.
You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d
One in general doesn't need to worry after setup if a particular app will work, if it will be wayland native or xwayland, if it will look different on different DPI displays, if it will be blurry, if all functionality will work.
All high and mixed DPI concerns are front loaded into a tiny amount of time setting it up in a way that will just work well without compromise.
A tiny amount of effort by your distro could easily erase even that by simply doing it for you.
>IMO it is actually too nice anyway. Should have gone XDarwin all the way -- i.e. to run X11, you have to manually launch separate application, and that server does not support hidpi at all.
This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you.
Then you can call them all luddites for caring more about working hardware than plumbing.
> Apps in general either directly support high DPI or if dumb can be set to an integer scaling factor via environment.
I will again repeat myself there: and how does the display server know, if the app won't tell?
> 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter.
Variables do not work in dynamic environment, where hotplug is a thing. Like personal computing in last 25 years or so.
> You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d
So you are telling here, that:
- there should be a database of apps; ignoring that the display server won't be able to recognize them solely on socket connection and it won't have another info available (no, Xresources is not a solution) - that database would be local system-specific - and it would be static, so if the user hot-plugs some hardware, it won't reflect the current system state anymore - and it would be static at runtime. If you want a change for a running app, you have to restart the app.
Do you see some problems with that?
The problem with this kind of thinking is putting hacks on top of another hacks and then wondering when the mountain goes down.
> This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you.
How exactly did XDarwin destroy adoption of Quartz? If anything, it drove adoption. Instead of trying to hide the shortcomings, it exposed them and offered another solution, without them.
> Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you.
Only those who prefer long pain; those who prefer short pain would do exactly the same.
> Then you can call them all luddites for caring more about working hardware than plumbing.
The entire point is that it does not work. Remember that when someone will complain that the monitor they plugged into their laptop doesn't do the right thing, unlike their Windows or Mac.
I will again repeat myself there: and how does the display server know, if the app won't tell?
> 99% of people are going to need exactly one variable for gtk apps that wouldn't be needed if gtk was just a tad smarter.
Variables do not work in dynamic environment, where hotplug is a thing. Like personal computing in last 25 years or so.
> You spend 30 seconds setting it up then every works including mixed dpi. In fact one could trivialize this at installation and write configuration to xorg.conf or xorg.conf.d
So you are telling here, that:
- there should be a database of apps; ignoring that the display server won't be able to recognize them solely on socket connection and it won't have another info available (no, Xresources is not a solution) - that database would be local system-specific - and it would be static, so if the user hot-plugs some hardware, it won't reflect the current system state anymore - and it would be static at runtime. If you want a change for a running app, you have to restart the app.
Do you see some problems with that?
The problem with this kind of thinking is putting hacks on top of another hacks and then wondering when the mountain goes down.
> This is an example of user hostility that goes a long way towards destroying adoption. Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you.
How exactly did XDarwin destroy adoption of Quartz? If anything, it drove adoption. Instead of trying to hide the shortcomings, it exposed them and offered another solution, without them.
> Wherein your users and downstream projects like distros who actually care about user experience will take pains to avoid you.
Only those who prefer long pain; those who prefer short pain would do exactly the same.
> Then you can call them all luddites for caring more about working hardware than plumbing.
The entire point is that it does not work. Remember that when someone will complain that the monitor they plugged into their laptop doesn't do the right thing, unlike their Windows or Mac.
This is the totality of my present configuration
In my shell config
This isn't automated because I really don't care because like many devices it only actually has one configuration but it would be trivial to do so by computing the exact scale based on difference in DPI. The one thing that can't be determined automatically is the physical layout. There are 17 different GUIs that amount to dragging around iconic representations of your screens. Autoscaling mixed dpi configurations could be a check box checked by default and writing to xconfig could be a button like it is in nvidia-settings.
Other people prefer to simply switch between different named configurations with one of the 17 scripts that have been written to do this.
The gist of why this arrangement needs to app specific configuration for proper behavior per screen is that as far as apps are concerned every monitor has the exact same DPI. Scaling is done by X not the app so if you were to say drag a window from monitor to monitor you would note that the window and its elements remains exactly the same size between monitor not because the app is smart but because X is. This is true enough that you can drag a window halfway between and notice no discontinuity between a line of text across both monitors.
Note that this functionality isn't new nor does it require massive coordination or anything new at all. It has probably worked longer than you've used Linux.
In my shell config
set -gx GDK_SCALE 2
xrandr --dpi 163 --output DP-0 --scale 1.75x1.75 --output HDMI-0 --pos 3360x0 --mode 3840x2160 --output DVI-D-0 --pos 7200x0 --scale 1.75x1.75
This isn't automated because I really don't care because like many devices it only actually has one configuration but it would be trivial to do so by computing the exact scale based on difference in DPI. The one thing that can't be determined automatically is the physical layout. There are 17 different GUIs that amount to dragging around iconic representations of your screens. Autoscaling mixed dpi configurations could be a check box checked by default and writing to xconfig could be a button like it is in nvidia-settings.
Other people prefer to simply switch between different named configurations with one of the 17 scripts that have been written to do this.
The gist of why this arrangement needs to app specific configuration for proper behavior per screen is that as far as apps are concerned every monitor has the exact same DPI. Scaling is done by X not the app so if you were to say drag a window from monitor to monitor you would note that the window and its elements remains exactly the same size between monitor not because the app is smart but because X is. This is true enough that you can drag a window halfway between and notice no discontinuity between a line of text across both monitors.
Note that this functionality isn't new nor does it require massive coordination or anything new at all. It has probably worked longer than you've used Linux.
Great. So you managed the easy part - to scale your screen.
The elephant in the room that you still ignore after several comments in this thread is, that the display manager cannot know magic variables for misc clients, it can barely tell clients apart (and it certainly doesn't know their image names, linked libraries or environment or how they were launched), and it shouldn't know, the clients should tell what resolution they are using so the display manager can adjusts their display. Wayland clients do that, X11 don't.
No, you can't paper over it with some scripts. Suggestions like that always remind me this: https://www.youtube.com/watch?v=ZTdUmlGxVo0
The elephant in the room that you still ignore after several comments in this thread is, that the display manager cannot know magic variables for misc clients, it can barely tell clients apart (and it certainly doesn't know their image names, linked libraries or environment or how they were launched), and it shouldn't know, the clients should tell what resolution they are using so the display manager can adjusts their display. Wayland clients do that, X11 don't.
No, you can't paper over it with some scripts. Suggestions like that always remind me this: https://www.youtube.com/watch?v=ZTdUmlGxVo0
Imagine you are sitting on a train in London with your friend on your way to work and you are having a conversation with your mom back in New York. Meanwhile your friend is loudly insisting that everyone knows that cellular connections can't cross oceans because cell towers just don't have that much range. He's sort of correct but he's missed the point.
Let me try again. Here is an xrandr invocation that configures 3 screens [1080P 24"][4K 27"][1080p 24"]
If one simply runs xrandr after one sees a curious thing. The 1080 monitors are listed as being 3360x1890. If we pop out our calculator we will note that the systems sees every screen as being about 161 DPI. Prove it to yourself if you like.
https://www.sven.de/dpi/
This means that the most poorly written application on earth only has to contend with high dpi support not mixed DPI. X asks nothing of the client it needs no magic variables nor insight into its linked libraries or images. If you grasp the window metaphorically and move it from screen to screen its size won't perceptively flutter because the screen differential in DPI is as far as its concerned within 1%. If you open a fullscreen app it will draw its window to the whole perceptible 3360 width of the screen and X will scale it down to the actual width of 1920. X has taken sole responsibility for giving a fuck what the difference in DPI is. High DPI support at this point is very good and no scripts to "paper" over anything is required.
xrandr --scale is a thing that would have worked in 2003 and still works in 2022 even if people have forgotten about it.
Let me try again. Here is an xrandr invocation that configures 3 screens [1080P 24"][4K 27"][1080p 24"]
xrandr --dpi 163
--output HDMI-0 --mode 1920x1080 --scale 1.75x1.75 --pos 0x0
--output DP-4 --auto --pos 3360x0
--output DP-1 --mode 1680x1050 --scale 1.75x1.75 --pos 7200x0
If one simply runs xrandr after one sees a curious thing. The 1080 monitors are listed as being 3360x1890. If we pop out our calculator we will note that the systems sees every screen as being about 161 DPI. Prove it to yourself if you like.
https://www.sven.de/dpi/
This means that the most poorly written application on earth only has to contend with high dpi support not mixed DPI. X asks nothing of the client it needs no magic variables nor insight into its linked libraries or images. If you grasp the window metaphorically and move it from screen to screen its size won't perceptively flutter because the screen differential in DPI is as far as its concerned within 1%. If you open a fullscreen app it will draw its window to the whole perceptible 3360 width of the screen and X will scale it down to the actual width of 1920. X has taken sole responsibility for giving a fuck what the difference in DPI is. High DPI support at this point is very good and no scripts to "paper" over anything is required.
xrandr --scale is a thing that would have worked in 2003 and still works in 2022 even if people have forgotten about it.
Just use Xorg if you want 1:1 compatibility. For Wayland to be 1:1 compatible it'd have to bend over backwards and do some ninja turtles kind of moves to create a mess nobody wants. The whole point is to be better and better is mostly always incompatible. Although Wayland isn't completely incompatible either but that difference doesn't matter.
However...
I am still shocked at the wonder Linux Desktop is. The world has entered into VR/AR, AI, and completely stupifying marvels of engineering but we still haven't gotten the Linux Desktop right. It's a downright fragmented mess. And if that wasn't enough, we had to build another windowing server! Now there's more fragmentation and apps that barely got the funding to work on X or get ported there will never see daylight on Wayland. Yay! Hurrah! We did it! Not to be so condescending but it's truly terrifying how horribly amateurish Linux Desktop is when the underlying system is so amazing.
It's almost like JavaScript developers got together and decided to build the desktop part of Linux. Every week they deprecated/overhauled/threw away last weeks changes and started a new in the name of engineering. The result? Nothing ever works predictably on anything. You open one app in X and the same app on Wayland...and there's no surety it'll work the same way on both. Now open the same app on Gnome and KDE (although that difference has slowly been fixed so it's now much better).
A lot of things don't work in Linux as they are supposed to. You have to tinker the guts out of them sometimes. Sometimes you may even have to recompile. Props to the way Linux is designed that makes all this possible and not locked down but..man it gets annoying sometimes.
I hope one day we'll have some solidity and stability in Linux with everyone building upon an agreed set of foundations so we can actually move forward instead of rebuilding the same wall over and over again.
However...
I am still shocked at the wonder Linux Desktop is. The world has entered into VR/AR, AI, and completely stupifying marvels of engineering but we still haven't gotten the Linux Desktop right. It's a downright fragmented mess. And if that wasn't enough, we had to build another windowing server! Now there's more fragmentation and apps that barely got the funding to work on X or get ported there will never see daylight on Wayland. Yay! Hurrah! We did it! Not to be so condescending but it's truly terrifying how horribly amateurish Linux Desktop is when the underlying system is so amazing.
It's almost like JavaScript developers got together and decided to build the desktop part of Linux. Every week they deprecated/overhauled/threw away last weeks changes and started a new in the name of engineering. The result? Nothing ever works predictably on anything. You open one app in X and the same app on Wayland...and there's no surety it'll work the same way on both. Now open the same app on Gnome and KDE (although that difference has slowly been fixed so it's now much better).
A lot of things don't work in Linux as they are supposed to. You have to tinker the guts out of them sometimes. Sometimes you may even have to recompile. Props to the way Linux is designed that makes all this possible and not locked down but..man it gets annoying sometimes.
I hope one day we'll have some solidity and stability in Linux with everyone building upon an agreed set of foundations so we can actually move forward instead of rebuilding the same wall over and over again.
I don't think the linux community replaces things on an unreasonable frequency. Apple and Google both swap out things that require breaking changes all the time. The only difference is their OSs has mass adoption and developers just have to do whatever it takes. While linux is largely an after thought.
What is the alternative? Leave linux distros on broken, substandard tech? Sometimes you do just have to break things to make progres. Fedora turned on CGroupsv2 despite Docker not supporting it after years. Very shortly after turning it on and breaking docker, docker updated to support it. It likely never would if no one made the first move to just break things if reasonable time has been given and still no movement occurs.
What is the alternative? Leave linux distros on broken, substandard tech? Sometimes you do just have to break things to make progres. Fedora turned on CGroupsv2 despite Docker not supporting it after years. Very shortly after turning it on and breaking docker, docker updated to support it. It likely never would if no one made the first move to just break things if reasonable time has been given and still no movement occurs.
You are right but mind that you also can't compete on Google's scale. Linux Desktop is mostly volunteer work which means the risk of breaking the same things is higher because a) it'll take much longer to build something better b) you'll run out of resources/motivation c) you'll get distracted d) you won't be able to test it as rigorously.
I don't think it was a bad decision to go the Wayland way at all. But it accumulates because Linux is so fragmented. There's multiple distros, each with their own toolkits, own package managers, own cores etc. And then someone comes along and fragments it at an ever lower level by proposing Wayland. I am sure it fixed a bunch of core issues but look at the cost it will incur:
1. All GUI toolkits will have to support Wayland across the board. Some stuff will break, some stuff will have to be abandoned.
2. After that they'll have to maintain both because it'll take at least a decade or two for everyone to reasonably migrate.
3. The app developers will have to upgrade to this new version of the toolkit. Which they might not be able to do because the changes are too many and too big.
4. The toolkits might even have to backport the Wayland related stuff a few versions. Which would require insane amount of resources.
Is the end result worth it? I bet for a long while we'll be having a way poorer experience due to Wayland. The worst case would be developers ditching X too early when Wayland isn't properly stable. Oh man, it's a recipe for disaster.
I don't think it was a bad decision to go the Wayland way at all. But it accumulates because Linux is so fragmented. There's multiple distros, each with their own toolkits, own package managers, own cores etc. And then someone comes along and fragments it at an ever lower level by proposing Wayland. I am sure it fixed a bunch of core issues but look at the cost it will incur:
1. All GUI toolkits will have to support Wayland across the board. Some stuff will break, some stuff will have to be abandoned.
2. After that they'll have to maintain both because it'll take at least a decade or two for everyone to reasonably migrate.
3. The app developers will have to upgrade to this new version of the toolkit. Which they might not be able to do because the changes are too many and too big.
4. The toolkits might even have to backport the Wayland related stuff a few versions. Which would require insane amount of resources.
Is the end result worth it? I bet for a long while we'll be having a way poorer experience due to Wayland. The worst case would be developers ditching X too early when Wayland isn't properly stable. Oh man, it's a recipe for disaster.
Just because they get away with it doesn't mean it's good. Windows and Microsoft thankfully have not given into CADT.
Windows is the only OS I can’t stand using. It’s incredible to me that such a large company puts out an OS that feels broken and old. It’s like a patchwork of old crap from the 90 and stuff just plain not up to modern expectations. As a user I’m happy to use platforms that put the best future ahead of the smoothest now for developers.
> And if that wasn't enough, we had to build another windowing server
Strictly speaking, Wayland is just the protocol. Pedantry aside, X11 is from 1987, whereas Apple totally redid their display server in 2001 with OS X, and Microsoft in 2006 with Vista. Wayland brings the Linux desktop kicking and screaming into the 21st century. But bazzar development will always be very different than cathedral development, so inevitably Wayland has its problems and rough edges. X11 being longer in the tooth doesn’t help.
Strictly speaking, Wayland is just the protocol. Pedantry aside, X11 is from 1987, whereas Apple totally redid their display server in 2001 with OS X, and Microsoft in 2006 with Vista. Wayland brings the Linux desktop kicking and screaming into the 21st century. But bazzar development will always be very different than cathedral development, so inevitably Wayland has its problems and rough edges. X11 being longer in the tooth doesn’t help.
True but OSX & Microsoft didn't have to deal with the massive amount of fragmentation that exists in Linux. Moving to a better standard is no issue but when everyone is building their own ship at their own cost & labour, it's not such a great idea.
Soon enough all the Linux forums will be filled with workarounds to get X or Y or Z app to work on Wayland or X or something else. The result? Nothing will work as expected for a long time (until everyone has forgotten X).
Soon enough all the Linux forums will be filled with workarounds to get X or Y or Z app to work on Wayland or X or something else. The result? Nothing will work as expected for a long time (until everyone has forgotten X).
> It's almost like JavaScript developers got together and decided to build the desktop part of Linux.
This part has been true for years actually. Gnome Shell UI and various other gnome apps are written in javascript now using gjs[1].
[1] https://gjs.guide/
This part has been true for years actually. Gnome Shell UI and various other gnome apps are written in javascript now using gjs[1].
[1] https://gjs.guide/
A lot of these complaints seem to boil down to a couple of key issues:
1) Wayland isn't X11. Applications whose core purpose is interacting with X11 features (e.g. xrandr, xprop, window managers) won't work on Wayland.
2) Screen recording on Wayland remains an incompletely solved problem, and a lot of applications don't support it yet.
3) Global key capture is, similarly, not a solved problem.
1) Wayland isn't X11. Applications whose core purpose is interacting with X11 features (e.g. xrandr, xprop, window managers) won't work on Wayland.
2) Screen recording on Wayland remains an incompletely solved problem, and a lot of applications don't support it yet.
3) Global key capture is, similarly, not a solved problem.
2 and 3 are big problems and are making me consider switch back to Xorg as it's made some stuff impossible to do. Not having stuff like Redshift is also a big bummer and makes me think if the people behind Wayland have any idea how people actually use computers.
My general perception of it is that it has many good design decisions from the point of software architecture and security, but they are too cumbersome to add stuff to Wayland that is absolutely needed for desktops. The result is that people end up finding a way to do that stuff anyway in the implementations and the ecosystem becomes a fragmented mess that somehow works worse than legacy Xorg.
My general perception of it is that it has many good design decisions from the point of software architecture and security, but they are too cumbersome to add stuff to Wayland that is absolutely needed for desktops. The result is that people end up finding a way to do that stuff anyway in the implementations and the ecosystem becomes a fragmented mess that somehow works worse than legacy Xorg.
"Redshift" doesn't work, but there are many alternatives that do work for Wayland like Gammastep or Wlsunset.
That is true, although I've seen the support being cumbersome at best, specially with Nvidia drivers (although can't put the blame on anyone else other than Nvidia here obviously) even the default Gnome night light doesn't work as it should always.
Wayland is not preventing screen sharing or recoring.
The API supports it pretty well. Problem is that existing applications need to adapt for its use, and if the demand is low, it is not worth the money.
It sounds like you are supporting the author's claim that Wayland will never be a 1:1 replacement for xorg.
To be fair for it to be a 1:1 replacement for xorg that does not mean it also needs to be drop-in (as in all software that works on xorg will work on Wayland right away).
Yes it does.
The solution is to use Pipewire and DBus to connect to proprietary APIs.
The arguement whether it is the correct location to provide a standardised API is a separate one. But Wayland does not support this.
The solution is to use Pipewire and DBus to connect to proprietary APIs.
The arguement whether it is the correct location to provide a standardised API is a separate one. But Wayland does not support this.
> The solution is to use Pipewire and DBus to connect to proprietary APIs.
I don't understand this at all. Can you open a bit more? To my understanding, current screen recording is relying mainly on xdg-desktop-portal and it's variations. It depends on flatpak and glib and uses D-bus. None of these are proprietary to my knowledge.
With these, it supports WebRTC out of the box for browser, and for example OBS studio supports natively, and works really well.
Apps need to implement and use org.freedesktop.portal.* interfaces to support screen recording in Wayland.
I don't understand this at all. Can you open a bit more? To my understanding, current screen recording is relying mainly on xdg-desktop-portal and it's variations. It depends on flatpak and glib and uses D-bus. None of these are proprietary to my knowledge.
With these, it supports WebRTC out of the box for browser, and for example OBS studio supports natively, and works really well.
Apps need to implement and use org.freedesktop.portal.* interfaces to support screen recording in Wayland.
Proprietary is probably the wrong word.
Non-standardised perhaps, specific to the desktop implementation and by implementing the Wayland specification does not give you appropriate screensharing APIs in that namespace.
Because the APIs that are exposed by Gnome, KDE, and wl-roots are all different. Flatpak has access to the `xdg-desktop-portal.*` namespace, but everyone has their own implementation so saying they use the standard namespace is misleading as it makes it sound like all the work is done.
Pipewire masks all that by implementing everyone's API and then exposing this via the Pipewire API, neatly solving the Wayland limitation and providing a standard.
The original statement was:
> Wayland is not preventing screen sharing or recoring. The API supports it pretty well.
No it does not. Pipewire does.
Because the APIs that are exposed by Gnome, KDE, and wl-roots are all different. Flatpak has access to the `xdg-desktop-portal.*` namespace, but everyone has their own implementation so saying they use the standard namespace is misleading as it makes it sound like all the work is done.
Pipewire masks all that by implementing everyone's API and then exposing this via the Pipewire API, neatly solving the Wayland limitation and providing a standard.
The original statement was:
> Wayland is not preventing screen sharing or recoring. The API supports it pretty well.
No it does not. Pipewire does.
This is a fight implementations cannot win.
So there is demand for API. Gnome, KDE, wl-roots implement it, in the discovery phase by their unique way, so we have 3 different APIs. Then, once the requirements are known, standardization happens and every compositor implements the standard API. So far, good.
But what happens with the old, experimental APIs? Because meanwhile, there are apps, that do use them. Remove the old APIs and you will have cries on the Internets, how you break compatibility again (even if you announce deprecation plan years upfront). Do not remove them, and you have complains, that every compositor has its own API (ignoring, that there is a standardized one too, now).
So, there's no pleasing everyone. Someone will complain.
> No it does not. Pipewire does.
xdg-deskop-portal-(gnome|kde|wlr), among other things, which do include desktop-specific dialogs related to the functionality.
So there is demand for API. Gnome, KDE, wl-roots implement it, in the discovery phase by their unique way, so we have 3 different APIs. Then, once the requirements are known, standardization happens and every compositor implements the standard API. So far, good.
But what happens with the old, experimental APIs? Because meanwhile, there are apps, that do use them. Remove the old APIs and you will have cries on the Internets, how you break compatibility again (even if you announce deprecation plan years upfront). Do not remove them, and you have complains, that every compositor has its own API (ignoring, that there is a standardized one too, now).
So, there's no pleasing everyone. Someone will complain.
> No it does not. Pipewire does.
xdg-deskop-portal-(gnome|kde|wlr), among other things, which do include desktop-specific dialogs related to the functionality.
Of course they will. Normally though you have a roadmap with features that people want and screensharing was not a feature that Wayland wanted to get involved in because it runs against their ideology.
That is simply all we are talking about. I don't think the situation that we are in now is terrible, it's just a shame that Wayland ignored it and so it's taken much longer than it should to get it in place.
That is simply all we are talking about. I don't think the situation that we are in now is terrible, it's just a shame that Wayland ignored it and so it's taken much longer than it should to get it in place.
I see now. Thanks for the info.
I've had no problems with KDE's native Redshift clone on Wayland.
>2) Screen recording on Wayland remains an incompletely solved problem, and a lot of applications don't support it yet.
This is a solved problem, but you are correct that a lot of applications don't support it yet. The solution is Pipewire. OBS works fine, Firefox and Chrome can share windows fine, but there's a lot of software out there that won't be updated overnight.
This is a solved problem, but you are correct that a lot of applications don't support it yet. The solution is Pipewire. OBS works fine, Firefox and Chrome can share windows fine, but there's a lot of software out there that won't be updated overnight.
"Overnight"? It's been a decade. Maybe not a decade since these screen-sharing APIs were developed, but that's a part of the problem too, no? Wayland was designed from the start completely neglecting normal every-day use cases.
With wayland I now can't drag&drop to extract files from archives onto the file manager. Issue open literally for 3 years now: https://gitlab.gnome.org/GNOME/file-roller/-/issues/4
I don't expect this to be fixed for another 5-10 years. I used to drag to extract files almost every single day, it's a core use for me. Simply broken now. I get nothing from Wayland, it was a net downside for me.
I don't expect this to be fixed for another 5-10 years. I used to drag to extract files almost every single day, it's a core use for me. Simply broken now. I get nothing from Wayland, it was a net downside for me.
From what I'm reading in that bug report, the problem is that file-roller (a GNOME archiving utility) has a hokey homebrewed implementation of drag-and-drop which no longer works under Wayland. This looks like file-roller's fault, not Wayland's -- other GNOME applications have no problems with DnD.
It's a "there's a solution planned / being worked on". It's not solved until it works for people out of the box for pretty much anything they want to use.
Paraphrasing Charity, "approved protocols don't matter if the users aren't happy".
Paraphrasing Charity, "approved protocols don't matter if the users aren't happy".
If I were PM for a consumer-facing product, number 2 would be a blocker for me and a critical issue. It's such a basic, common, everyday use case that it's mind-boggling to me that they're dropping the ball on it.
#2 is a solved problem. I use Wayland and screen sharing works fine for every app I use (browser-based video chat, OBS). The problem is adoption of the new APIs, not the lack of a solution.
Especially in the era of working from home now: I regularly need to share my screen to demo stuff, or record screen recordings of WIP prototypes...
Even for code reviews sometimes it's easier to do it via screensharing with a full IDE for jumping around the code...
Even for code reviews sometimes it's easier to do it via screensharing with a full IDE for jumping around the code...
Yes, I was using Wayland fairly comfortably but am now using x again thanks to screen sharing and all the different conference tools everyone uses.
At my previous job, we actually recorded screens of users (and kept activity records ~3months). We couldn't serve them wayland, but X11 was enough (it was mostly datascience)
(And by the way, it was only in one of our offer, the most expensive one, and sold as a feature, it was not some shady stuff)
(And by the way, it was only in one of our offer, the most expensive one, and sold as a feature, it was not some shady stuff)
For 2, APIs exist. It is up to the apps to use them.
So if you were PM, the ball would be on your side.
So if you were PM, the ball would be on your side.
So one effectively means:
We, the creators of the new screen thing, are about to break a TON of your old screen things, on purpose.
Now, I'm not saying you can never be that bold -- but if you are, then you need Steve Jobs level effectiveness or you shouldn't do it.
We, the creators of the new screen thing, are about to break a TON of your old screen things, on purpose.
Now, I'm not saying you can never be that bold -- but if you are, then you need Steve Jobs level effectiveness or you shouldn't do it.
The "creators of the new screen thing" are the same people that "maintained the old screen thing". And didn't want to do it anymore, because it was terrible. And nobody else wanted to do it either, because it was terrible.
After 3 years someone finally stepped up to do an Xorg release and had to immediately roll back the main new feature because a massive security vulnerability was found.
https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Se...
After 3 years someone finally stepped up to do an Xorg release and had to immediately roll back the main new feature because a massive security vulnerability was found.
https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Se...
In my experience, "I don't want to work on $SOFTWARE anymore because it's terrible" just means "I'm tired and would prefer to work on something greenfield". I'm not saying there's anything wrong with that (I've succumbed to it myself), but consider how much toil Wayland has created for so many people, and for what benefit after all this time?
You're not wrong, but if literally no one is willing to maintain X11 then your choices are (A) let them build Wayland or (B) just stay on bitrotted Xorg forever. For better or worse, users aren't paying even a small fraction of the development cost of the Linux desktop so the result is a volunteer hacker do-ocracy.
The X windowing system is nearly 40 years old. A lot of its problems stem from design decisions that were made many years ago, and which are virtually impossible to fix. A replacement is overdue.
Counter argument: In contrast to Wayland, X is well engineered with a beautiful core protocol and an extension scheme that let it evolve in a modular way for 40 years. I hate that Linux regresses since about a decade because people insist on rewriting the old stuff producing inferior, incompatible, and half-broken garbage. The arguments for replacing X were never good.
How on Earth is X modular? Why is it a goddamn huge program with literally no reimplementations if it is so good?
Well Wayland 1.0 is 10 years old in October...
Given how far away Wayland is from replacing Xorg for many, I wouldn't be surprised if it'll be replaced by something else before getting its time in the limelight. Wouldn't be the first time.
Then again, never underestimate sunk cost I suppose...
Given how far away Wayland is from replacing Xorg for many, I wouldn't be surprised if it'll be replaced by something else before getting its time in the limelight. Wouldn't be the first time.
Then again, never underestimate sunk cost I suppose...
But I would argue that reality says that you're objectively wrong about "A replacement is overdue."
In the real world, X has remained as good as, or better than Wayland this whole time. Proven by "people still use it, a LOT."
In the real world, X has remained as good as, or better than Wayland this whole time. Proven by "people still use it, a LOT."
There are cases when a software’s basic abstractions/assumptions fundamentally change over time. It is more likely to happen if it is multi-decade old and was created before modern GPUs were even a thing.
X’s basic primitives are simply bad for today’s hardware. It was inevitable to fix at some point. OSX changed to Quartz in 2001 I believe and windows quickly followed with their compositor based display manager.
So no, your assumptions doesn’t hold here at all.
X’s basic primitives are simply bad for today’s hardware. It was inevitable to fix at some point. OSX changed to Quartz in 2001 I believe and windows quickly followed with their compositor based display manager.
So no, your assumptions doesn’t hold here at all.
I've heard people say this and I don't understand the "terrible." What do they mean by that? In my experience, "terrible" is provably false, in that in my work I work with lots of differently skilled people using Linux for lots of different things. And I encounter ALL KINDS of Linux headaches, and exactly zero of them have ever been with X.
I'm talking about maintaining Xorg, not using it. The people maintaining Xorg didn't want to do it anymore, and built Wayland. Very, very people wanted to step in and keep Xorg going.
All of this is outweighed by the fact that any application using X11 has complete control of your entire desktop, including other applications. This fact makes Linux desktops using X11 significantly inferior in security to all other operating systems. There is no way to sandbox an application that is allowed to send window events to all other applications, since it can just tell your desktop environment to open a shell and then send commands at will.
The only reasonable solution (nested X servers and XSECURITY are not reasonable solutions) is to switch to Wayland.
The only reasonable solution (nested X servers and XSECURITY are not reasonable solutions) is to switch to Wayland.
> any application using X11 has complete control of your entire desktop, including other applications[...] There is no way to sandbox an application
That is not a concern in the world that I or many people live in; the desktop is not expected to provide this type of Web browser-level isolation to protect against adversarial programs running on our machines.
It may in theory be worse than e.g. Windows in this regard, but in practice you can operate a computer in the freedesktop.org tradition with much more confidence compared to running Windows. The traditional packaging and distribution practices and social norms turn out to provide a much better line of defense than whatever technical design is being imported from other contemporary OSes.
That is not a concern in the world that I or many people live in; the desktop is not expected to provide this type of Web browser-level isolation to protect against adversarial programs running on our machines.
It may in theory be worse than e.g. Windows in this regard, but in practice you can operate a computer in the freedesktop.org tradition with much more confidence compared to running Windows. The traditional packaging and distribution practices and social norms turn out to provide a much better line of defense than whatever technical design is being imported from other contemporary OSes.
> That is not a concern in the world that I or many people live in; the desktop is not expected to provide this type of Web browser-level isolation to provide protection from adversarial programs running on our machines.
Increasingly, it is. Mobile OS's have operated under this assumption since the App Store. Windows and macOS are both strongly moving in this direction. Sandboxed apps are the future, and desktop Linux is behind.
> The traditional packaging and distribution practices and social norms turn out to provide a much better line of defense than whatever technical design is being imported from other contemporary OSes.
No, they don't. The thing you're trying to defend against is not just hostile apps, but someone remotely achieving RCE in one of your network-exposed applications. With X11, any compromised app has keys to the kingdom.
Increasingly, it is. Mobile OS's have operated under this assumption since the App Store. Windows and macOS are both strongly moving in this direction. Sandboxed apps are the future, and desktop Linux is behind.
> The traditional packaging and distribution practices and social norms turn out to provide a much better line of defense than whatever technical design is being imported from other contemporary OSes.
No, they don't. The thing you're trying to defend against is not just hostile apps, but someone remotely achieving RCE in one of your network-exposed applications. With X11, any compromised app has keys to the kingdom.
> > That is not a concern in the world that I or many people live in[...]
> Increasingly, it is.
You haven't really done anything to show this. And as a point of fact, I'm in much better position to explain the concerns I live with than you are.
Appealing yet again to what other platforms are doing is not an argument. Mac and Windows and Android are doing this. Fine. Granted. Where's your evidence of the actual, practical threat, besides merely gesturing to the (purported) imperative to follow their mitigation strategy? To repeat, this is just not a concern in the world that we're talking about—that other platforms/vendors have taken a different position is not evidence that their position is ipso facto rational and correct.
> The thing you're trying to defend against is not just hostile apps, but someone remotely achieving RCE in one of your network-exposed applications.
I'm not. I'm far more concerned, actually, about the threat from programs and utilities that don't have GUIs, incl. programs that depend on third-party packages of dubious provenance, than I am concerned about the threat of desktop applications reaching across to interfere with each other and violating any (non-existent) expectation of isolation of the sort described here.
> Increasingly, it is.
You haven't really done anything to show this. And as a point of fact, I'm in much better position to explain the concerns I live with than you are.
Appealing yet again to what other platforms are doing is not an argument. Mac and Windows and Android are doing this. Fine. Granted. Where's your evidence of the actual, practical threat, besides merely gesturing to the (purported) imperative to follow their mitigation strategy? To repeat, this is just not a concern in the world that we're talking about—that other platforms/vendors have taken a different position is not evidence that their position is ipso facto rational and correct.
> The thing you're trying to defend against is not just hostile apps, but someone remotely achieving RCE in one of your network-exposed applications.
I'm not. I'm far more concerned, actually, about the threat from programs and utilities that don't have GUIs, incl. programs that depend on third-party packages of dubious provenance, than I am concerned about the threat of desktop applications reaching across to interfere with each other and violating any (non-existent) expectation of isolation of the sort described here.
What would defend you from an npm install script adding a few lines to your bashrc file and starting a keylogger on each start with full network access? When would you realize it happening? What about a malicious build script (have you ever run anything from Arch’s AUR?), a PDF reader with a buffer overflow error exploited by a random PDF file you wanted to read or the like?
EDIT:
But this whole thing means that a normal CLI app also gets to read everything on your screen! It is not only desktop-to-desktop protection, X has no protection whatsoever.
EDIT:
But this whole thing means that a normal CLI app also gets to read everything on your screen! It is not only desktop-to-desktop protection, X has no protection whatsoever.
What? Why is this a reply to my comment?
I think it is quite obvious why I replied - I listed several potential ways your computer could be vulnerable.
Well, it wasn't obvious—hence the question. And it's still not obvious, even now.
What does a "list of several potential ways your computer could be vulnerable"* have to do, specifically, with my comment? Where is the logical throughline? Do you understand my comment to contain an assertion that my computer is not vulnerable if I were to run an "npm install script adding a few lines to your bashrc"? (It doesn't. That's the entire basis for my remark that I'm far more concerned about things like that than the threat of programs monitoring/faking IO among GUI-based apps.)
* ... which, to be clear, is not what your comment actually contains—it was rather a series of questions in non-sequitur
What does a "list of several potential ways your computer could be vulnerable"* have to do, specifically, with my comment? Where is the logical throughline? Do you understand my comment to contain an assertion that my computer is not vulnerable if I were to run an "npm install script adding a few lines to your bashrc"? (It doesn't. That's the entire basis for my remark that I'm far more concerned about things like that than the threat of programs monitoring/faking IO among GUI-based apps.)
* ... which, to be clear, is not what your comment actually contains—it was rather a series of questions in non-sequitur
> It doesn't. That's the entire basis for my remark that I'm far more concerned about things like that than the threat of programs monitoring/faking IO among GUI-based apps...
But there is no difference between a strictly CLI app and a GUI one. Even if you ran everything in a sandbox, under X they could still do every nefarious thing. It would be like sealing one hole of a broken bucket, while water will still leak out on the other ones. Without GUI sandboxing we can’t even start fixing the security question on Linux desktop.
But there is no difference between a strictly CLI app and a GUI one. Even if you ran everything in a sandbox, under X they could still do every nefarious thing. It would be like sealing one hole of a broken bucket, while water will still leak out on the other ones. Without GUI sandboxing we can’t even start fixing the security question on Linux desktop.
> It would be like sealing one hole of a broken bucket, while water will still leak out on the other ones.
I think you've stumbled upon my point without realizing it...
I think you've stumbled upon my point without realizing it...
I had understood that this was also true under ~MacOS and~ Windows.
Keylogging and screen monitoring is trivial in Windows.
Wayland solves a problem that is present on all systems, but it does it with a sledgehammer.
[Edit] I am reminded that MacOS has a sane model for this.
Keylogging and screen monitoring is trivial in Windows.
Wayland solves a problem that is present on all systems, but it does it with a sledgehammer.
[Edit] I am reminded that MacOS has a sane model for this.
macOS has a reasonable security model and it doesn't allow that without explicit (annoying-to-grant) user consent. On Windows, apps that are concerned about RCE can drop privileges and still access the desktop in a secure way. On X11, there is no such option; you have to adopt a Chromium-like content/chrome process model, with the content process having no windowing access whatsoever. Because it's so difficult, almost nobody does this on X11.
Ah, yes you are correct! I do remember the Mac security model, and I think it is a much better solution to Wayland.
Don't ban, just make it a user specific choice.
Don't ban, just make it a user specific choice.
I can't imagine anyone involved with Wayland wants to ban screen recorders. They just want to make sure they get the security right.
But they did, and there are requests that they provide a standardised API for screensharing/recording which are `wontfix`.
All the desktops made their own API outside of Wayland and Pipewire standardised a global API wrapper for everyone's implementation.
Whether that's the correct location rather than Wayland is a separate discussion.
All the desktops made their own API outside of Wayland and Pipewire standardised a global API wrapper for everyone's implementation.
Whether that's the correct location rather than Wayland is a separate discussion.
But then you are just claiming inconsistent things. Also, screen sharing is indeed a different problem as that often mandates sound recording/transmission as well which is very much not in scope for a display manager.
(That’s where we can see how a cathedral model could fare better). I think having a simple screen shot api in wayland is a good idea, while letting pipewire properly solve video (and optionally audio) channeling a good technical solution.
(That’s where we can see how a cathedral model could fare better). I think having a simple screen shot api in wayland is a good idea, while letting pipewire properly solve video (and optionally audio) channeling a good technical solution.
Nothing I have said is inconsistent, and I haven't said that the resulting implementation is bad although I disagree it's outside the realm of a display manager whan all of them had to implement an API to get it to work.
The only thing I have said is that Wayland has not, and will not implement an API to their specification. Everyone has implemented their own one due to the lack of directionn and then Pipewire did the presentation API.
It could have been a lot tidier if Wayland had actually accepted that they are the display server and that Pipewire will want an API to capture the display.
Pipewire is the correct output as it captures both audio and visual and can do manipulation of the output as required, but the display server feeds the visual output.
The only thing I have said is that Wayland has not, and will not implement an API to their specification. Everyone has implemented their own one due to the lack of directionn and then Pipewire did the presentation API.
It could have been a lot tidier if Wayland had actually accepted that they are the display server and that Pipewire will want an API to capture the display.
Pipewire is the correct output as it captures both audio and visual and can do manipulation of the output as required, but the display server feeds the visual output.
MacOS does not allow screen sharing (say in Google Chat) of your entire desktop or other windows without user permission. The application has to be added to a list of allowed applications through the System Preferences.
Same with intercepting all keyboard input IIRC.
Can’t speak to Windows.
Same with intercepting all keyboard input IIRC.
Can’t speak to Windows.
You are correct, I remember now. Although this wasn't always the case, it has been true for a few years now.
Yeah. Two or three releases I think.
MacOS and Windows never gave direct socket and well-defined protocol to the display server. If you wanted to connect, you had to use their client libs.
Turns out, you can handle many cases in the linked libraries and if you do not have them, and you cannot change the protocol, touch luck. Sledgehammer time.
Turns out, you can handle many cases in the linked libraries and if you do not have them, and you cannot change the protocol, touch luck. Sledgehammer time.
All of that is outweighed by the fact that Wayland does not "just work" in the same way Xorg does. I absolutely despise x11, it's far too long in the tooth and needs to be replaced by literally anything. MacOS has been using Quartz for the better part of a decade, and on Linux, your choice of window servers is either Tweedle-Dee or Tweedle-Dum. If Wayland's developers hadn't used wlroots as a purgatory for salient concerns about their project, then we might have a good starting spot. If they created a Xorg-agnostic interface for running a Mutter shell on legacy desktops, that would be even better. But we got nothing. They cut real features like AppIndicators straight out of the project for no good reason. They left every other desktop environment out in the cold.
People understand that Wayland isn't a drop-in replacement for Xorg, and that's becoming a problem. People want to run desktops that aren't GNOME or Sway, people want to use hardware that isn't AMD-based, and people want to use the software they've always had just like they did before. Wayland doesn't do that, and after 10 years of antagonizing Linux software development, I think it's safe to say it failed.
People understand that Wayland isn't a drop-in replacement for Xorg, and that's becoming a problem. People want to run desktops that aren't GNOME or Sway, people want to use hardware that isn't AMD-based, and people want to use the software they've always had just like they did before. Wayland doesn't do that, and after 10 years of antagonizing Linux software development, I think it's safe to say it failed.
>I think it's safe to say [Wayland] failed
In that case I think it is safe to say that all the apps I have been using for over a year have been talking to my window server using a failed protocol.
But I really like the experience.
In that case I think it is safe to say that all the apps I have been using for over a year have been talking to my window server using a failed protocol.
But I really like the experience.
> This fact makes Linux desktops using X11 significantly inferior in security to all other operating systems.
This is a valid enough point in isolation, but it seems belied by actual experience. There are really very few desktop-related exploits I can think of reading about, at least since the days of unencrypted X servers on the network. The most recent panic (maybe 10-15 years ago?) was about the default permissions behind ssh protocol forwarding, and even then I don't think anyone famous got hacked by ssh'ing into an untrusted or compromised host.
The simple truth is that getting access to a user's X display on a modern Linux distro requires being able to run arbitrary code as that user, on their system. And let's be real: if you can do that then the game is up anyway. Local root exploits are cheap and pervasive, and there are much more attractive options to an enterprising hacker than trying to spoof a UI.
This is a valid enough point in isolation, but it seems belied by actual experience. There are really very few desktop-related exploits I can think of reading about, at least since the days of unencrypted X servers on the network. The most recent panic (maybe 10-15 years ago?) was about the default permissions behind ssh protocol forwarding, and even then I don't think anyone famous got hacked by ssh'ing into an untrusted or compromised host.
The simple truth is that getting access to a user's X display on a modern Linux distro requires being able to run arbitrary code as that user, on their system. And let's be real: if you can do that then the game is up anyway. Local root exploits are cheap and pervasive, and there are much more attractive options to an enterprising hacker than trying to spoof a UI.
On my Mac, I can run your code. Maybe I download your program, maybe you break the sandbox on my browser.
You can’t record all my keyboard activity. You can’t see my whole desktop. You can’t see other applications’ windows.
Running local code is not game-over.
You can’t record all my keyboard activity. You can’t see my whole desktop. You can’t see other applications’ windows.
Running local code is not game-over.
There's literally one of these every few weeks: https://www.trendmicro.com/en_us/research/22/d/macos-suhelpe...
I know what you're saying. I'm not saying it's false (I was writing Xlib/Xt code professionally in the late 90's on a giant open network where we all had "xhost +" in our startup scripts, trust me I know what you can do). I'm saying the rest of the system sucks even worse. If you have an exploit on a modern linux system and want to install a keylogger, you don't do it with X. You just don't. It's not a realistic hole.
Especially since the first line of defense (don't let attackers run arbitrary binaries of any type) is actually quite strong on modern systems.
I know what you're saying. I'm not saying it's false (I was writing Xlib/Xt code professionally in the late 90's on a giant open network where we all had "xhost +" in our startup scripts, trust me I know what you can do). I'm saying the rest of the system sucks even worse. If you have an exploit on a modern linux system and want to install a keylogger, you don't do it with X. You just don't. It's not a realistic hole.
Especially since the first line of defense (don't let attackers run arbitrary binaries of any type) is actually quite strong on modern systems.
> And let's be real: if you can do that then the game is up anyway. Local root exploits are cheap and pervasive
That's why seccomp-bpf exists.
That's why seccomp-bpf exists.
An excellent technology. But truthfully if you want to apply that level of filtering, X11 is a more constrained language with more conventional app behavior and it's easier to protect via stateful inspection than arbitrary syscall filtering.
But Wayland is far easier than that to secure, because it's reasonably secure today. Securing X11 would be a lot of work, which nobody has signed up to do. Far easier than fixing the relatively minor complaints about Wayland.
Besides, seccomp-bpf and windowing protocol security are orthogonal. Desktop apps must make syscalls, and they must interact with the window server. You need security for both.
Besides, seccomp-bpf and windowing protocol security are orthogonal. Desktop apps must make syscalls, and they must interact with the window server. You need security for both.
And yet, 12 years later, Wayland still has significant problems, and has not displaced X11. There's a reason for that: it's just not good enough.
I find it hard to believe that the security issues with X11 could not be fixed. It might have to be done in a way that causes some incompatibilities and pain, but I can't imagine that would be anywhere near as bad as all the time people have spent working on and dealing with Wayland.
I mean, c'mon, here's a simple X11 "any app can read out the contents of any other window" solution: add access controls to Xorg so that they can't. You open a connection to the X server, and you can read any window created by that connection, and that's it. Input events? You only get the input events destined for windows created on your connection. Want to write a screenshot or screen recording app, or an app that allows sharing your screen? Cool, we can create an interface for that, one that requires user confirmation. Privilege separation is hardly an unsolved problem.
I'm not saying all of this is easy, but it strains credibility to suggest that this could not have been accomplished in the past 12+ years since work started on Wayland.
I find it hard to believe that the security issues with X11 could not be fixed. It might have to be done in a way that causes some incompatibilities and pain, but I can't imagine that would be anywhere near as bad as all the time people have spent working on and dealing with Wayland.
I mean, c'mon, here's a simple X11 "any app can read out the contents of any other window" solution: add access controls to Xorg so that they can't. You open a connection to the X server, and you can read any window created by that connection, and that's it. Input events? You only get the input events destined for windows created on your connection. Want to write a screenshot or screen recording app, or an app that allows sharing your screen? Cool, we can create an interface for that, one that requires user confirmation. Privilege separation is hardly an unsolved problem.
I'm not saying all of this is easy, but it strains credibility to suggest that this could not have been accomplished in the past 12+ years since work started on Wayland.
> I mean, c'mon, here's a simple X11 "any app can read out the contents of any other window" solution: add access controls to Xorg so that they can't.
This exists and is called XSECURITY. It breaks everything, so nobody uses it. Also, nobody thinks Xorg is secure against RCE from hostile clients: the code is just too old and brittle.
This exists and is called XSECURITY. It breaks everything, so nobody uses it. Also, nobody thinks Xorg is secure against RCE from hostile clients: the code is just too old and brittle.
Xorg network code is considered well audited and very few problems have been found over the years. Please stop making stuff up.
The most recent release had to be rolled back after four zero-day remote privilege escalations were found and given CVEs. The network code may be fine, but everything exposed to the network is not, and manpower is dwindling to address problems.
Here are a zillion memory safety problems in X libraries typical of what happens when you point a fuzzer at 1980s code: https://lists.x.org/archives/xorg-devel/2013-May/036276.html
Why do you think you know enough on the topic to have such strong claims? Wouldn’t giving the benefit of the doubt to the developers behind Wayland (who came from X by the way) be the sane thing to do?
X has trusted on non-trusted clients. The problem is that non-trusted clients were not allowed to use some important extensions such as Xrender. This could be changed though and largely solve this problem. Of course, apps of the same user are not sandboxed against each other on the system level on Unix, so this only helps if you also do this.
I had this problem a while back where I would screen share on zoom and seemingly leftover memory from videos I’d watched in the browser showed up in certain circumstances to people viewing my screen. Utterly horrific.
I believe wayland does in fact fix this issue. Does anybody have more context on what’s going on?
I believe wayland does in fact fix this issue. Does anybody have more context on what’s going on?
A classic problem to do with hardware overlays. It's also why screenshots of videos sometimes have blacked out video in the screenshot.
'Hardware overlay' is an old video acceleration trick to write processed video straight to the output framebuffer. It bypasses the OS windowing system completely and if you as a developer get it wrong in any way you get video peeking through other apps. Video playing via a hardware overlay' has caused such issues for 30 years now. Not just on xorg or Wayland as you'll sometimes see this on windows too.
'Hardware overlay' is an old video acceleration trick to write processed video straight to the output framebuffer. It bypasses the OS windowing system completely and if you as a developer get it wrong in any way you get video peeking through other apps. Video playing via a hardware overlay' has caused such issues for 30 years now. Not just on xorg or Wayland as you'll sometimes see this on windows too.
I recall in the old days, you could get the cheap BT848/878 TV tuner cards. They just merrily piped data into the framebuffer, so if you had things configured right, it would draw a black rectangle, expecting the card to drop video on it, and the actual video would be offset 25 pixels to the left and below the.
And guess what? It worked, even on NetBSD. And you could move it with the tv-stream playing without tearing. And scaling too! Still have one such thing in PCI, gathering dust in some box.
I have QubesOS with a VM for work and another one for personal things. The nice thing with Qubes is that I can share all the screen in the work VM and people will only see work-related windows.
So it doesn't matter what I am browsing in my personal browser, nobody from the work VM can ever see it.
So it doesn't matter what I am browsing in my personal browser, nobody from the work VM can ever see it.
I hoped they would adopt ReactOS for their Windows containers[1].
[1] https://github.com/QubesOS/qubes-issues/issues/2809
[1] https://github.com/QubesOS/qubes-issues/issues/2809
In my experience, Wine has better support and is much more stable than ReactOS, especially when using Proton builds.
I should warn you that it's quite possible for GPU memory to leak into/out of VMs, the safety model is different. So the parent's horror story could absolutely happen to you.
I think that you are mistaken. In Qubes, none of the VMs have access to the GPU by default[0]. May you elaborate or provide some evidence to support your claim?
[0]: Unless you do something "exotic" like pass the GPU through to a particular VM which is not supported and explicitly not recommended for the security reasons that you are thinking about.
[0]: Unless you do something "exotic" like pass the GPU through to a particular VM which is not supported and explicitly not recommended for the security reasons that you are thinking about.
The sharing VM has no access to any GPU. The GPU is wholly owned by the dom0 process that copies pixels to screen memory from pages mapped to VMs.
I've never had that happen, but that does sound pretty terrible. It might be worth installing a second browser exclusively for use with zoom as a possible temporary fix.
Nope. That's on the kernel/gpu driver-side buffer management code, not the display server. And yes, it sucks. https://arxiv.org/pdf/1804.00114.pdf may be of interest.
I'm curious--What GPU/driver were you using? I suspect Nvidia from my experience.
That's nightmare inducing.
I don't want Wayland to be exactly compatible with Xorg. Progress requires abandoning cruft and committing to a hopefully better design. I moved to Wayland 100% earlier this year and not looking back.
I’d have a lot more respect for this web page if it concentrated on the truly problematic stuff like lack of BSD support and not so much complaining about Wayland fixing intractable X11 security holes.
I run wayland (sway) on FreeBSD with intel graphics. It runs fine. My only FreeBSD-specific problem is firefox on wayland on FreeBSD always has a "stuck" tab that you close and it doesn't actually go away. It just becomes non-interactable and wastes space in your tab bar.
I'll be moving back to X11 soon—and for only one feature: color management. Wayland has no way to handle ICC profiles. There is a working group making slow, but good progress, but is also trying to rethink how color management works in the age of HDR displays. This is a good goal, but if I want to do any color sensitive work now, there's nothing I can do. I also wish there was a clear way to donate to fund this particular effort because the rest of Wayland has been good.
This is a fair criticism I can get behind. But I seriously don’t understand why this football-fan like mentality is so apparent around this thread (and around many open-source programs). Thanks for the level-headed argument (and I also hope that color management will get better)
I recently switched back to xorg because of crashing in blender and kdenlive that went away in xorg. (Which I only figured out because I temporarily switched to try to screen record the crashing and found that it went away.)
... but I was shocked at how much faster and responsive Xorg was, -- and because of it have no interest in switching back to wayland even if the crashing issues are resolved.
... but I was shocked at how much faster and responsive Xorg was, -- and because of it have no interest in switching back to wayland even if the crashing issues are resolved.
Reading the first section of the list (screen recording):
- SSR's status seems correct, unimplemented
- Green-recorder is fully archived for 2 years, I mean yes it's technically incompatible with Wayland but that's probably not the main concern there.
- VokoscreenNG added experimental support in 3.1.0 (currently 3.3.0)
- OBS Studio added GA support last summer, the workaround is outdated
So just because the list was revised in April doesn't mean it's up to date with April.
Wayland was definitely pushed too early, a lot of these issues date back to 2016 and tracked through 2020 for example and it was all too soon. This is especially true if you don't use Gnome or KDE. To this day it's also true Wayland still doesn't have full X11 feature parity and I don't think it ever will. What you'll see is more and more of the important ones like screen recording will start to have answers and overall eventually X11 will lack more Wayland features than Wayland lacks X11 features. Mixed rate screens are already an example and fresh things like HDR (not just deep color) may be the big drivers in the coming years. Neither is likely to ever be a true strict subset of the other. Lists like this do a poor job tracking which is actually better for the user because they are focused solely on finding what doesn't work after having had a bad experience instead of tracking what works in each. At the moment this persons workflow would very likely still come out to a preference for X11 but that doesn't change this type of list being a poor way to conclude that.
- SSR's status seems correct, unimplemented
- Green-recorder is fully archived for 2 years, I mean yes it's technically incompatible with Wayland but that's probably not the main concern there.
- VokoscreenNG added experimental support in 3.1.0 (currently 3.3.0)
- OBS Studio added GA support last summer, the workaround is outdated
So just because the list was revised in April doesn't mean it's up to date with April.
Wayland was definitely pushed too early, a lot of these issues date back to 2016 and tracked through 2020 for example and it was all too soon. This is especially true if you don't use Gnome or KDE. To this day it's also true Wayland still doesn't have full X11 feature parity and I don't think it ever will. What you'll see is more and more of the important ones like screen recording will start to have answers and overall eventually X11 will lack more Wayland features than Wayland lacks X11 features. Mixed rate screens are already an example and fresh things like HDR (not just deep color) may be the big drivers in the coming years. Neither is likely to ever be a true strict subset of the other. Lists like this do a poor job tracking which is actually better for the user because they are focused solely on finding what doesn't work after having had a bad experience instead of tracking what works in each. At the moment this persons workflow would very likely still come out to a preference for X11 but that doesn't change this type of list being a poor way to conclude that.
While this post is obviously being updated it goes back many years.
I know there are people who don’t like Wayland’s design or goals. Same with systemd. But we still hear constant complaining.
The big distros appear to have decided on these as the future. You don’t have to like it, you don’t have to use it. But the other (or older) options aren’t going to get much development.
I’m not sure such posts are very productive this many years in.
I know there are people who don’t like Wayland’s design or goals. Same with systemd. But we still hear constant complaining.
The big distros appear to have decided on these as the future. You don’t have to like it, you don’t have to use it. But the other (or older) options aren’t going to get much development.
I’m not sure such posts are very productive this many years in.
> [...] I know there are people who don’t like Wayland’s design or goals. Same with systemd. But we still hear constant complaining.
You know, I was anti-systemd at first, until I started learning more about it and honestly, I kind of like it now. Yes, I fully admit that makes me crazy, but hey the world is upside down anyway so why not join the party? ;-)
> [...] You don’t have to like it, you don’t have to use it. But the other (or older) options aren’t going to get much development.
THIS. THIS THIS THIS! This is why I use Linux! Because with Crapple and Microsnot, I don't have this choice. At least with Linux, I do! Kinda sucks about the other options not being maintained, and I agree that's a problem, but this right here is why I dropped both MacOS and Windows earlier this year for 100% Linux full-time.
And Linux as a desktop has a LONG way to go. But Wayland is a good start.
I, and only I, goddammit, will decide what code runs on MY computer. (Within functional reason; not a lot you can do about binary firmware blobs, realistically, but you get the point.)
Microsoft and Apple rob people of this necessary choice. Such a detriment to personal freedom and security is not acceptable. And if that means I have to endure the X vs. Wayland drama and nonsense, in order to maintain the liberty I should have damn well had from the beginning, well then so be it. I'll take that hit and be better for it.
You know, I was anti-systemd at first, until I started learning more about it and honestly, I kind of like it now. Yes, I fully admit that makes me crazy, but hey the world is upside down anyway so why not join the party? ;-)
> [...] You don’t have to like it, you don’t have to use it. But the other (or older) options aren’t going to get much development.
THIS. THIS THIS THIS! This is why I use Linux! Because with Crapple and Microsnot, I don't have this choice. At least with Linux, I do! Kinda sucks about the other options not being maintained, and I agree that's a problem, but this right here is why I dropped both MacOS and Windows earlier this year for 100% Linux full-time.
And Linux as a desktop has a LONG way to go. But Wayland is a good start.
I, and only I, goddammit, will decide what code runs on MY computer. (Within functional reason; not a lot you can do about binary firmware blobs, realistically, but you get the point.)
Microsoft and Apple rob people of this necessary choice. Such a detriment to personal freedom and security is not acceptable. And if that means I have to endure the X vs. Wayland drama and nonsense, in order to maintain the liberty I should have damn well had from the beginning, well then so be it. I'll take that hit and be better for it.
Do you understand that what you are saying is directly and perfectly antithetical to Free and perhaps even merely Open Source, software?
(the Wayland people apparently didn't, that's for sure)
(the Wayland people apparently didn't, that's for sure)
the reverse is true. FOSS developers are free to work on whatever they want. X11 devs decided they didn't like to work on X11 anymore and created wayland instead. you don't have to like it and you are free to contribute to X11 yourself if it is important to you, but wayland devs don't have any obligations here
Absolutely.
But also, I have no obligations to like or respect what they do either. I think they're going the wrong way and I can say so. The freedom works both ways, and I don't think we should shield them from criticism.
But also, I have no obligations to like or respect what they do either. I think they're going the wrong way and I can say so. The freedom works both ways, and I don't think we should shield them from criticism.
i strongly disagree. criticism must be constructive and helpful. and developers absolutely should be shielded from criticism, especially FOSS developers, because if we don't then they will stop sharing.
basically, ask yourself: is your response friendly and helpful and likely to motivate the developer to consider your issue, or are you venting your frustration. if it's the latter, then please just don't.
see here for example:
https://news.ycombinator.com/item?id=31945618
i made a similar comment a few weeks ago:
https://news.ycombinator.com/item?id=31679373
users should be free to be critical of it
absolutely not. you can say: "unfortunately, i have this problem, so i can't use this, i am going to go use something else". but that's about it.
criticism is the bane of our society. criticism hurts peoples feelings. criticism causes burnout. FOSS maintainers are volunteers and absolutely do not deserve that kind of criticism for just developing software. (that doesn't put them above any criticism. if they are rude or mean to their users, then that may well be criticized. but not if they ignore a problem or are unresponsive. they may well have other things in their life that are more important than to care about your software issue) (and if the developer is paid, direct any criticism at the company, but don't beat up the employee who may not have the freedom to choose what issues to work on)
Being open source doesn't mean nobody should dare criticise you
if you didn't pay for it, it means exactly that.
basically, ask yourself: is your response friendly and helpful and likely to motivate the developer to consider your issue, or are you venting your frustration. if it's the latter, then please just don't.
see here for example:
https://news.ycombinator.com/item?id=31945618
i made a similar comment a few weeks ago:
https://news.ycombinator.com/item?id=31679373
users should be free to be critical of it
absolutely not. you can say: "unfortunately, i have this problem, so i can't use this, i am going to go use something else". but that's about it.
criticism is the bane of our society. criticism hurts peoples feelings. criticism causes burnout. FOSS maintainers are volunteers and absolutely do not deserve that kind of criticism for just developing software. (that doesn't put them above any criticism. if they are rude or mean to their users, then that may well be criticized. but not if they ignore a problem or are unresponsive. they may well have other things in their life that are more important than to care about your software issue) (and if the developer is paid, direct any criticism at the company, but don't beat up the employee who may not have the freedom to choose what issues to work on)
Being open source doesn't mean nobody should dare criticise you
if you didn't pay for it, it means exactly that.
They effectively made bold claims with their plans and they failed to deliver - in a place in open source that people rely on greatly. If they do this badly, that's a betrayal of trust. That is my view.
Now, it's true -- I absolutely have no legal or physical recourse to materially affect them them and because it's open source, I shouldn't. They should never be sued or anything like that.
But you can get out of here with the silly idea that it also shields them from me COMMENTING, even HARSHLY.
Look, I didn't talk about their mama's, I talked about their product.
Your idea that "FOSS developers should be shielded from criticism because they'll stop sharing" is as absurd as "Never boo a musician because THEN THERE WILL BE NO MORE MUSIC."
Now, it's true -- I absolutely have no legal or physical recourse to materially affect them them and because it's open source, I shouldn't. They should never be sued or anything like that.
But you can get out of here with the silly idea that it also shields them from me COMMENTING, even HARSHLY.
Look, I didn't talk about their mama's, I talked about their product.
Your idea that "FOSS developers should be shielded from criticism because they'll stop sharing" is as absurd as "Never boo a musician because THEN THERE WILL BE NO MORE MUSIC."
you may want to read this article and discussion:
https://news.ycombinator.com/item?id=31977136 Why criticism lasts longer than praise (bbc.com)
https://news.ycombinator.com/item?id=31977136 Why criticism lasts longer than praise (bbc.com)
All I said was the mindshare has moved to the new thing and that means the majority of developers did too.
Because I said complaining wasn’t productive?
This far after adoption, I don’t think it is. Fedora isn’t going to see this list and drop Wayland for X. They went to Wayland 7 years ago. I think they’re happy enough, they had plenty of chances to change their mind.
But hyperbolic titles like this one (“Think twice before abandoning Xorg. Wayland breaks everything!”) are unhelpful. HN later changed the title here to something much less inflammatory and more fair.
Because I said complaining wasn’t productive?
This far after adoption, I don’t think it is. Fedora isn’t going to see this list and drop Wayland for X. They went to Wayland 7 years ago. I think they’re happy enough, they had plenty of chances to change their mind.
But hyperbolic titles like this one (“Think twice before abandoning Xorg. Wayland breaks everything!”) are unhelpful. HN later changed the title here to something much less inflammatory and more fair.
Wayland's design reflects it's security model: more news at 11.
Counterpoint: wayland has features X will never support
Care to list what they are ?
I know the one missing function, network transparency :)
I know the one missing function, network transparency :)
Different DPI per display is the big one. A security story that isn’t ¯\_(ツ)_/¯
Display independent DPI scaling. For instance, if you have multiple monitors of different sizes/resolutions, you can scale them independently to have text and windows appear the same size on all of them.
It can be done https://gitlab.freedesktop.org/emersion/waypipe
That wasn’t really true of Xorg for decades to begin with unless you were using some XMotif applications. Other frameworks’ output is predominantly just bitmaps, good luck using that over anything other than local networks. That problem has a better solution, there really is no reason why the display manager should try to solve it (badly).
I believe Simula is built on wayland due to some wayland specific features
So? Clearly we don't need them for anything important, since we've managed without them up until now. That isn't true of the features that X has but Wayland doesn't.
I fully support Wayland, but also also recognizing its problems. Most of it boils down to apps that don't natively support Wayland, or incomplete support for some use case. Otherwise I think Wayland has been great.
Feeling like the brain cycles I was spending thinking about X v Wayland is part of the reason I decided “fuck it” and went back Windows recently.
While systemd was pretty much transparent because it happens around the kernel, Wayland-or-X was regularly in my face.
It seemed like ultimately something in my world was going to snap and break…two things I relied on were going to make a stand on opposite sides of the line in the sand.
And whatever ethical pleasure I might draw from Linux would always be tainted by the consequences of practical smartphone choices.
Ultimately predictability has high value for me and Wayland-or-X was mostly a worry.
YMMV.
While systemd was pretty much transparent because it happens around the kernel, Wayland-or-X was regularly in my face.
It seemed like ultimately something in my world was going to snap and break…two things I relied on were going to make a stand on opposite sides of the line in the sand.
And whatever ethical pleasure I might draw from Linux would always be tainted by the consequences of practical smartphone choices.
Ultimately predictability has high value for me and Wayland-or-X was mostly a worry.
YMMV.
6 weeks ago I upgraded from 20.04/Xorg/i3 to 22.04/Wayland/Sway and I've been really disappointed.
The 3 big issues are: I can't screen share, can't screencap, and it flakes out every 1-2 weeks and the session crashes and I need to start over.
Compared to Xorg where my sessions could run for months, basically indefinitely, and screen/window sharing and just worked.
I've been hoping it being in Ubuntu 22.04 would get it the exposure to get this fixed, but I think I'm going to have to switch back to Xorg.
The 3 big issues are: I can't screen share, can't screencap, and it flakes out every 1-2 weeks and the session crashes and I need to start over.
Compared to Xorg where my sessions could run for months, basically indefinitely, and screen/window sharing and just worked.
I've been hoping it being in Ubuntu 22.04 would get it the exposure to get this fixed, but I think I'm going to have to switch back to Xorg.
That's a terrifyingly toxic comments thread.
For some reason Systemd, Wayland, Gnome and Firefox are regularly the target of these.. when all are decent, open-source softwares. One is free to dislike/not use them, but it seems to be attacked most who are supposedly on the “same side”..
Wayland is/was a terrifyingly toxic way to do software in the FOSS world. If you want to go break things that people love, you might as well go work for Apple or Microsoft.
As a resident of Wayland I find that it breaks web searches with irrelevant results about software.
What did you mean by this?
Wayland is the name of a town. Generic internet searches for "Wayland" often yield results about the software rather than the town, especially because my web search history is quite Linux heavy. Of course this was a tongue-in-cheek reply but true nonetheless.
Sorry, but I don't find the article convincing. The thing about diatribes is that they are a distorted view of reality. My take on Wayland, after using it for several months, is that it is fine for my circumstances. Would I recommend it to other people? No. It doesn't offer a noticeable benefit while the prevalence of software for X suggests that X is the safest bet. On the other hand, Wayland does not deserve the vitriol that is directed towards it.
Wayland is pretty much a requirement for any new, high end laptop or desktop setup. X's inconsistent support of hi-dpi displays, mix/match dpi displays, janky hotplug, and hdr makes it almost a non starter for any laptop sold >=2021 that cost more than $1500
> Wayland is pretty much a requirement for any new, high end laptop or desktop setup.
StumpWM is definitely my requirement for using a computer, and it doesn't support Wayland. And yet my laptops and desktop (all of which cost well over $1,500) are pretty wonderfully useful.
They would be close to useless if I did not have a Lisp-extensible tiling window manager to run on them.
StumpWM is definitely my requirement for using a computer, and it doesn't support Wayland. And yet my laptops and desktop (all of which cost well over $1,500) are pretty wonderfully useful.
They would be close to useless if I did not have a Lisp-extensible tiling window manager to run on them.
[deleted]
This list sucks.
It's basically a complaint that X11 software doesn't work on Wayland while conveniently ignoring patches or alternatives to that same software.
This is akin to saying "32 bit x86 is not a 1:1 compatible ARM64 replacement" or "English is not a 1:1 compatible Japanese replacement" or "Writing with your left hand is not a 1:1 compatible right hand replacement". They are different things. Why should they be? Who said they should be? Where was it agreed it should be? I don't see anyone in the Wayland community who actually does work (e.g. maintaining the protocol spec or large projects) saying it should be.
Also, there are either maintained forks for these (e.g. redshift-wayland for redshift) or straight up Wayland alternatives (e.g. wlsunset instead of redshift). The author even links to the Arch Linux wiki page for Redshift which at the top in a purple banner says "Note: Redshift does not support Wayland [1]. See Backlight#Wayland for alternatives." so that's some nice cherry picking to say the least.
So while the claim "Wayland breaks Redshift" is _technically_ true (even though there's a patch) it is heavy implied, I feel, that there is no alternative which is objectively false and misleading.
It's FOSS, go contribute if you are this upset; it's not like you do not have access to the entire protocol specification for Wayland, and the source code for each and every single item listed. This kind of complaint would make sense if it was closed source software where you cannot make changes without extreme effort in reverse engineering and potential legal problems with redistributing those patches. Not the case here.
It's basically a complaint that X11 software doesn't work on Wayland while conveniently ignoring patches or alternatives to that same software.
This is akin to saying "32 bit x86 is not a 1:1 compatible ARM64 replacement" or "English is not a 1:1 compatible Japanese replacement" or "Writing with your left hand is not a 1:1 compatible right hand replacement". They are different things. Why should they be? Who said they should be? Where was it agreed it should be? I don't see anyone in the Wayland community who actually does work (e.g. maintaining the protocol spec or large projects) saying it should be.
Also, there are either maintained forks for these (e.g. redshift-wayland for redshift) or straight up Wayland alternatives (e.g. wlsunset instead of redshift). The author even links to the Arch Linux wiki page for Redshift which at the top in a purple banner says "Note: Redshift does not support Wayland [1]. See Backlight#Wayland for alternatives." so that's some nice cherry picking to say the least.
So while the claim "Wayland breaks Redshift" is _technically_ true (even though there's a patch) it is heavy implied, I feel, that there is no alternative which is objectively false and misleading.
It's FOSS, go contribute if you are this upset; it's not like you do not have access to the entire protocol specification for Wayland, and the source code for each and every single item listed. This kind of complaint would make sense if it was closed source software where you cannot make changes without extreme effort in reverse engineering and potential legal problems with redistributing those patches. Not the case here.
Back when this article was first posted, I wrote a rebuttal of some of the key points: https://refi64.com/posts/dont-boycott-wayland.html
Since then, the situation has largely pretty much improved, in particular both OBS and Zoom have support for the screen sharing portals.
Since then, the situation has largely pretty much improved, in particular both OBS and Zoom have support for the screen sharing portals.
Wait, so they fixed the stupid X security holes where any application can steal any other application's keystrokes, read any other application's window content, and interfere with global system behavior by for example grabbing ALL keystrokes... but then they went to client-side window decorations so any application can just impersonate any other?
WTF?
WTF?
Desktop Linux will never be Android or iOS.
Desktop software isn't sand-boxed. If you're running applications you don't fully trust then you've already lost. Every app you install can access your full filesystem, communicate freely with other things on your network, scan your browser history, steal your cookies, and exfiltrate it finds over the internet.
Desktop software isn't sand-boxed. If you're running applications you don't fully trust then you've already lost. Every app you install can access your full filesystem, communicate freely with other things on your network, scan your browser history, steal your cookies, and exfiltrate it finds over the internet.
Maybe every app YOU install can do all of that stuff... some of us lead more interesting lives.
This has always been a problem in X, actually, since there was never an assumption that everything showing on your display would be running on your local computer.
This has always been a problem in X, actually, since there was never an assumption that everything showing on your display would be running on your local computer.
I am just popping up here to say from X10R4 onwards, I have never understood why MIT took a concept we understand around client-server, and completely inverted the meaning for anyone approaching it anew. Here i am connecting to a remote device via a telnet, running an xterm to display "back home". Whats the server? the local thing. Whats the client? the thing I run on the remote host: xterm.
Now step outside X. whats the client? the xterm. Whats the server? the remote host.
Semantic confusion is real folks. "Display server" only partially fixed it because people never remember to vocalise the qualifyer. And then you get Xterminals as physical devices, with "local" clients and now client-server is really really confusing.
Now step outside X. whats the client? the xterm. Whats the server? the remote host.
Semantic confusion is real folks. "Display server" only partially fixed it because people never remember to vocalise the qualifyer. And then you get Xterminals as physical devices, with "local" clients and now client-server is really really confusing.
The only way I understand it and stay sane is to say that "the X server serves out access to a display surface which clients like xterm connect to in order to show what they need to show". The X server runs on my machine since that is the display being shared and my programs need a connection to that display.
That's the pragmatic explanation I use.
Otherwise, and especially if you think servers are somehow always somewhere out there, you'll get a rude counter example. Server just means provider of service and thats about it. You're tripping up on your own assumption.
This is why you can telnet/ssh to a server out there, set the display variable to point back to your machine and xterm will try and connect to your machine. Its wanting a connection to your display to show things and to do so it needs a display server, ie yours.
That all probably made sense.
That's the pragmatic explanation I use.
Otherwise, and especially if you think servers are somehow always somewhere out there, you'll get a rude counter example. Server just means provider of service and thats about it. You're tripping up on your own assumption.
This is why you can telnet/ssh to a server out there, set the display variable to point back to your machine and xterm will try and connect to your machine. Its wanting a connection to your display to show things and to do so it needs a display server, ie yours.
That all probably made sense.
with X, the resource being served is your eyes.
That is not the only instance of "well this was technically correct but confusing and now its Enshrined and May never be Touched all Hail Compatibility" or whatever the impulse for wart retention is.
However the whole mess goes to show to me that there is no one true Display System and that there need to be more efforts in this arena, obviously there's still unfilled needs and people feel the compromised currently forced by the available choices are constricting.
OpenGL needs yet another networking extension. That'll fix it.
That is not the only instance of "well this was technically correct but confusing and now its Enshrined and May never be Touched all Hail Compatibility" or whatever the impulse for wart retention is.
However the whole mess goes to show to me that there is no one true Display System and that there need to be more efforts in this arena, obviously there's still unfilled needs and people feel the compromised currently forced by the available choices are constricting.
OpenGL needs yet another networking extension. That'll fix it.
Let's say you are using a Linux workstation and you fire up ngnix on it to host some web site for testing.
You then ssh into a remote server and type "curl https://your-workstation/some-name-here". In this case, your local machine is the server and curl is the client.
This is exactly the same as in the X server case. Your server is running on your machine, and the client is running on the remote machine (which happens to be a server).
You then ssh into a remote server and type "curl https://your-workstation/some-name-here". In this case, your local machine is the server and curl is the client.
This is exactly the same as in the X server case. Your server is running on your machine, and the client is running on the remote machine (which happens to be a server).
Use case I'm missing - clipboard sync with a remote host.
ssh -X forwards clipboard from remote where you can use something like neovim and clipboard syncs to local desktop.
To work around you need to run local terminal in XWayland mode. Something like that for the native Wayland case would be neat.
I'm not going to boycott Wayland though, it's a pointless idea.
ssh -X forwards clipboard from remote where you can use something like neovim and clipboard syncs to local desktop.
To work around you need to run local terminal in XWayland mode. Something like that for the native Wayland case would be neat.
I'm not going to boycott Wayland though, it's a pointless idea.
If it ain't broke, don't fix it.
And I keep hearing arguments about how broke X is or was and none much seem to carry water. Lots of loud hypothetical security issues and literally no remotely significant problems that I, a 20+ year Linux user, ever encountered.
Wayland's just a joke to me now.
And I keep hearing arguments about how broke X is or was and none much seem to carry water. Lots of loud hypothetical security issues and literally no remotely significant problems that I, a 20+ year Linux user, ever encountered.
Wayland's just a joke to me now.
I, for one, did encounter a lot of problems with Xorg. Primarily videos that were completely unwatchable due to screen tearing in VLC player whereas under a Wayland session everything worked perfectly. And this was years ago before Wayland was even mature.
This and scaling are literally the only ones I've ever seen "in the wild," and in my experience hasn't been remotely close to a deal breaker for most.
I find the screen tearing on X11 to be distracting, and it's definitely a deal-breaker for me. That and X11's comparatively poor HiDPI handling (especially for fractional scaling) encouraged me to switch to Wayland years ago. Most new laptop displays are now high enough in resolution to require some type of display scaling (often fractional) to accomodate the average person's eyesight, and I want my software to work smoothly with my hardware.
Somewhat tangential:
I swear I can see the difference in anti-aliasing between X and Wayland. Under the latter it just...looks so much better, smoother, CLEANER. Is that all in my head, or has anyone else noticed that too?
I swear I can see the difference in anti-aliasing between X and Wayland. Under the latter it just...looks so much better, smoother, CLEANER. Is that all in my head, or has anyone else noticed that too?
I would assume they have different font rendering paths. Makes sense to me they might look different.
Should be roughly the same. Are you using fractional scaling? That would add an extra layer of supersampling to the screen.
Tried it with and without, and I swear I can see the difference, but it's slight enough that I wouldn't laugh you out of the room if you told me it was psychosomatic. Which is why I asked if anybody else has noticed that same difference :-)
There are still people who post stupid, mostly nowadays irrelevant complaints from 2015 and believe that Wayland is a 1:1 replacement, even though it isn't by design....
I wanted to implement detachable tabs, similar to what chrome and sublime text have.
I heard it is not possible with wayland, because it doesn't give you the global mouse cursor location.
I heard it is not possible with wayland, because it doesn't give you the global mouse cursor location.
Out of curiosity... what is the purpose of X or Wayland at all when Android and ChromeOS seem to produce low-drama display systems that don't use either of these?
I'll never use it because the shilling is intolerable, obnoxious, obvious.
Duh
Wayland will never be 1:1 compatible with Xorg. Nor will it ever support all of the hardware that Xorg supports. I won't believe otherwise until Wayland works on my Thinkpad T60 with its ATI Mobility Radeon X1400.
[deleted]
Who funds Wayland? I bet it's someone who stands to gain from pouring sand into the Linux desktop engine.
Of course, it's entirely possible I'm misreading the history here: Wayland could've been widely despised back then, or maybe this thread is an outlier. Either way, I'd be happy to see if anybody's got a good pulse check.