Firefox 121 defaults to Wayland on Linux(omgubuntu.co.uk)
omgubuntu.co.uk
Firefox 121 defaults to Wayland on Linux
https://www.omgubuntu.co.uk/2023/12/firefox-121-released-now-defaults-to-wayland-on-linux
260 comments
> Traditionally more conservative projects like Cinnamon and Wine are finally adopting Wayland too.
I was under the impression WINE was less conservative and more that they really needed features that Wayland only recently added (relative positioning?)
I was under the impression WINE was less conservative and more that they really needed features that Wayland only recently added (relative positioning?)
I would describe it as both. Adding support for a new OS API adds a significant development, maintenance, and testing burden. When I was working on Wine, for changes in the higher-level audio APIs I would have to run tests across all of [macos coreaudio, linux alsa, linux alsa-pulse, linux pulseaudio, linux ossv4, and BSD ossv4]. Any change to those OS-level implementations had to be duplicated across all of them. It's a serious consideration to add support for new API, so we strongly preferred to offload that work to a shim layer (xwayland, alsa-pulse) as much as possible to avoid increasing the amount of code we had to write & maintain.
Desktop is even more complicated. Think about the infinite fractal of Linux windowing systems and DEs and drivers and end-user configurations, and having to maintain consistent win32 windowing behavior across _all_ of them... you realize adding in Wayland support is a massive development effort and support and maintenance commitment, even if it did have all the needed features.
Then also consider that new technologies have many bugs and change frequently; many Wine users do not use the latest version of Wine; and how important being able to build & run older Wine versions is for regression testing... it adds up to adding new OS API support being a very expensive thing to do. So yeah, it makes sense to be conservative about it. The Linux community's love for throwing away stable libraries and replacing them with a fresh new thing is a serious hindrance to writing quality software on a long timescale. (Oh look, it's PipeWire coming down the road... oh joy...)
Desktop is even more complicated. Think about the infinite fractal of Linux windowing systems and DEs and drivers and end-user configurations, and having to maintain consistent win32 windowing behavior across _all_ of them... you realize adding in Wayland support is a massive development effort and support and maintenance commitment, even if it did have all the needed features.
Then also consider that new technologies have many bugs and change frequently; many Wine users do not use the latest version of Wine; and how important being able to build & run older Wine versions is for regression testing... it adds up to adding new OS API support being a very expensive thing to do. So yeah, it makes sense to be conservative about it. The Linux community's love for throwing away stable libraries and replacing them with a fresh new thing is a serious hindrance to writing quality software on a long timescale. (Oh look, it's PipeWire coming down the road... oh joy...)
Did it actually require a patch? I thought it just required a certain env var set, so they probably could have just made a wrapper script that set it and invoked the binary (located somewhere other than /usr/bin/firefox), which I'd expect is very minimal packing step compared to patching the code for building
I don't read "patch" as necessarily a "source code patch" per-se. Even if they just add/modify one line in the build script, I'd say that particular distribution of the Firefox application to be "patched".
I think almost every single distro's Firefox would be patched by that definition. Pretty much every package format requires at least one line of shell script to be invoked in some fashion.
I too have been using Firefox on Wayland for some time now (on Arch Linux). I'm not quite sure when that switch was made though. I recall for some time I had to manually set that flag myself, but I just checked and apparently I've been running on Wayland by default for some time now.
I am sensing zero momentum for Wayland. It was is absolutely idiotic API with lots of unnecessary arbitrary restriction and vast over-complication and over-engineering for no other reason than NIHS.
It will eventually be dropped like a hot potato, just like HAL.
It will eventually be dropped like a hot potato, just like HAL.
So the largest two desktop environments defaulting to it, popular WMs (sway, etc) getting Wayland versions, PLUS agnostic projects like Firefox, is "zero momentum?" If anything, it's made (sadly) obvious which projects severely lack resources to migrate - the XFCE, enlightenment, gimp, etc. of the world.
I think we will find a lot of these projects always had the resources.
There are many people in the Linux community that are just vehemently opposed to it.
I suspect that in many cases the “lack of resources” was simply not having the resources to convince some of these people to stop being roadblocks.
There are many people in the Linux community that are just vehemently opposed to it.
I suspect that in many cases the “lack of resources” was simply not having the resources to convince some of these people to stop being roadblocks.
GIMP hasn't even migrated to GTK3 yet. The upcoming GIMP 3 will finally use GTK3 and is slated for release in a few months, but this is years after almost everyone else. Certainly in the case of GIMP I think "lack of resources" can be substantiated pretty easily. IIRC GIMP 3 will also get Wayland support – I'd have to check to be sure.
I'm less sure about XFCE or Enlightenment. Judging from [1] the XFCE people have been working on it since Feb 2021 (when that page was created), but real issues still remain, and I'm not surprised that "let's do a substantial rewrite of much of our codebase from something that works perfectly fine to ... something else that works perfectly fine" is not hugely top priority for a fairly small project like this. Call that "people being roadblocks" if you will, but that doesn't strike me as fair. Neither of us get to decide where these people spend their time.
[1]: https://wiki.xfce.org/releng/wayland_roadmap
I'm less sure about XFCE or Enlightenment. Judging from [1] the XFCE people have been working on it since Feb 2021 (when that page was created), but real issues still remain, and I'm not surprised that "let's do a substantial rewrite of much of our codebase from something that works perfectly fine to ... something else that works perfectly fine" is not hugely top priority for a fairly small project like this. Call that "people being roadblocks" if you will, but that doesn't strike me as fair. Neither of us get to decide where these people spend their time.
[1]: https://wiki.xfce.org/releng/wayland_roadmap
It's not as dire as you think :) Gimp should get Wayland support automatically when they complete the move to Gtk3 (which supports Wayland, Gtk2 does not) and the betas already support Wayland [1]. Enlightenment has clear plans for a Wayland mode [2]. Xfce has stated they'll support it too of course, but it's the largest change they'd be making in decades so it's understandable they're cautious. Maybe the momentum will have people get involved for Xfce, I'm pretty hopeful for all projects.
[1]: https://www.phoronix.com/news/GIMP-2.99.2-Released
[2]: https://www.enlightenment.org/about-wayland
[1]: https://www.phoronix.com/news/GIMP-2.99.2-Released
[2]: https://www.enlightenment.org/about-wayland
I felt like I also saw the momentum the OP talks about, and then when I went to try and set up Sway as my window manager in a new Void Linux installation it was a total nightmare. I need some new thing called a "seat manager" that I never needed with X11? And the only options are the bloated elogind (the whole point of Void is to avoid systemd style programs) or the somewhat feature bare seatd, neither of which I could get to work? Pass.
Well, you're choosing the least popular (non-systemd) approach, and also skipping elogind. This stuff JustWorks on systemd based systems, so your blaim is inaccurate.
At LEAST read the docs for your distro:
https://docs.voidlinux.org/config/session-management.html
At LEAST read the docs for your distro:
https://docs.voidlinux.org/config/session-management.html
Where do you think I found out about the necessity to install either of those things in the first place?
If Wayland only JustWorks on systemd-based systems that's not exactly making a great case for it, and this thread has plenty of other downstream stuff that it seems to upend as well.
If Wayland only JustWorks on systemd-based systems that's not exactly making a great case for it, and this thread has plenty of other downstream stuff that it seems to upend as well.
I'm not trying to make a case for it, it's the simple the truth that systemd has simplified a lot of this behind the scenes work. If you'd prefer to stick to the un-maintained X server because you value your init system more, that's up to you :)
Unfortunately the accessibility software[1] I use will likely never support Wayland due to Wayland's design requiring accessibility to be reimplemented by every DE, which means for you are no longer say supporting Windows, Mac and Linux; but Windows, Mac, X11, Gnome, KDE, Mate, Cina...
It's very weird to say, but I feel like I'll eventually be dropping Linux and moving to Windows, and it won't be for videogames.
[1] https://talonvoice.com/
It's very weird to say, but I feel like I'll eventually be dropping Linux and moving to Windows, and it won't be for videogames.
[1] https://talonvoice.com/
This is wrong. Accessibility software uses the at-spi protocol and this work with kde, gnome and in both x11 and wayland.
There are some minor issues with Wayland but most of it works.
I don't know what talon is doing as it seems proprietary, but the issue might be there.
There are some minor issues with Wayland but most of it works.
I don't know what talon is doing as it seems proprietary, but the issue might be there.
To be completely clear I am not a Linux programmer, and I don't have the bandwidth I think to become one, this is my secondhand understanding of the situation.
Here is a bit of a discussion though on this topic:
- a summary of the situation: https://github.com/splondike/wayland-accessibility-notes/blo...
- talon-required features and their current compatibility: https://github.com/splondike/wayland-accessibility-notes/blo...
Here is a bit of a discussion though on this topic:
- a summary of the situation: https://github.com/splondike/wayland-accessibility-notes/blo...
- talon-required features and their current compatibility: https://github.com/splondike/wayland-accessibility-notes/blo...
Keep in mind a lot of the belly aching you read is from people miffed their X11 application needs to be updated.
Basically people complaining about needing to do work to modernize.
All the things will eventually be just fine. X11 is a walking zombie.
Basically people complaining about needing to do work to modernize.
All the things will eventually be just fine. X11 is a walking zombie.
> people miffed their X11 application needs to be updated.
Yes, users are very understandably miffed that things which were working are suddenly broken and somebody now has to fix it in order to return to the status quo.
> things will eventually be just fine
Wayland is 15 years old. At this rate it will be due for replacement before it's feature complete.
Yes, users are very understandably miffed that things which were working are suddenly broken and somebody now has to fix it in order to return to the status quo.
> things will eventually be just fine
Wayland is 15 years old. At this rate it will be due for replacement before it's feature complete.
> things which were working are suddenly broken
…
> Wayland is 15 years old.
So, it's not very sudden, then, is it?
So much of what people see as wrong in Wayland is about slow-moving applications and driver vendors refusing to adapt; waiting until their software is actually broken before they do anything. We've had more than a decade knowing full well what is coming. I sympathize that an application you rely on is caught up in that. Nobody wanted that situation. But X11 has had a pretty good life. And unless Talon on Linux is suddenly abandoned, I really doubt those developers are going to keep hitching their wagon to X11. At some point, (probably soon now that distributors are getting serious about it), they will take a look at what's new and they will make it work with Wayland.
With that said, I don't think you have to worry for a while. I doubt apps are ever going to stop working in X11 altogether. You might end up with a different desktop at some point if you're using GNOME or KDE, but that's all.
…
> Wayland is 15 years old.
So, it's not very sudden, then, is it?
So much of what people see as wrong in Wayland is about slow-moving applications and driver vendors refusing to adapt; waiting until their software is actually broken before they do anything. We've had more than a decade knowing full well what is coming. I sympathize that an application you rely on is caught up in that. Nobody wanted that situation. But X11 has had a pretty good life. And unless Talon on Linux is suddenly abandoned, I really doubt those developers are going to keep hitching their wagon to X11. At some point, (probably soon now that distributors are getting serious about it), they will take a look at what's new and they will make it work with Wayland.
With that said, I don't think you have to worry for a while. I doubt apps are ever going to stop working in X11 altogether. You might end up with a different desktop at some point if you're using GNOME or KDE, but that's all.
To an end user it could easily be sudden; you install a new version of Fedora and oops your screenshot tool no longer works, and better hope the only accessibility tools you needed were built in to GNOME.
> And unless Talon on Linux is suddenly abandoned, I really doubt those developers are going to keep hitching their wagon to X11. At some point, (probably soon now that distributors are getting serious about it), they will take a look at what's new and they will make it work with Wayland.
That's assuming that they can make it work with Wayland, which appears rather unlikely since the API surface doesn't exist. As you say, Wayland has had more than a decade but most of that time was spent loudly proclaiming that such functionality was a security problem and had no legitimate usecases so here we are.
> With that said, I don't think you have to worry for a while. I doubt apps are ever going to stop working in X11 altogether.
I certainly hope I can keep using X until Wayland actually reaches feature parity, but I'm already seeing pressure on both sides; waydroid is the first[0] application to outright refuse to support X, while Asahi Linux was loudest about not wanting to support Xorg but they're hardly the only ones. I suspect I'm going to end up with a 3-layer system comprised of cage[1] running xwayland running my real graphical environment with some applications in their own little cage windows. It's a little annoying but as a break-glass option it seems to function with only slightly more papercuts than X11 programs on Xorg:\
[0] Well, first that I've noticed at least.
[1] https://www.hjdskes.nl/projects/cage/
> And unless Talon on Linux is suddenly abandoned, I really doubt those developers are going to keep hitching their wagon to X11. At some point, (probably soon now that distributors are getting serious about it), they will take a look at what's new and they will make it work with Wayland.
That's assuming that they can make it work with Wayland, which appears rather unlikely since the API surface doesn't exist. As you say, Wayland has had more than a decade but most of that time was spent loudly proclaiming that such functionality was a security problem and had no legitimate usecases so here we are.
> With that said, I don't think you have to worry for a while. I doubt apps are ever going to stop working in X11 altogether.
I certainly hope I can keep using X until Wayland actually reaches feature parity, but I'm already seeing pressure on both sides; waydroid is the first[0] application to outright refuse to support X, while Asahi Linux was loudest about not wanting to support Xorg but they're hardly the only ones. I suspect I'm going to end up with a 3-layer system comprised of cage[1] running xwayland running my real graphical environment with some applications in their own little cage windows. It's a little annoying but as a break-glass option it seems to function with only slightly more papercuts than X11 programs on Xorg:\
[0] Well, first that I've noticed at least.
[1] https://www.hjdskes.nl/projects/cage/
> Yes, users are very understandably miffed that things which were working are suddenly broken and somebody now has to fix it in order to return to the status quo.
You are misunderstanding. You can continue to keep using applications in X11-mode for as long as those applications maintain that code path. But many of the niceties Wayland provides, X11 won't get because it is virtually unmaintained.
Or said another way, X11 is already broken and getting slightly more broken every day.
And before you get angry at X11 going unmaintained, would you have expected Apple to support Carbon ad-infinitum?
Look at the backwards-compatibility and new-framework-adoption-rate woes Windows has to deal with because Win32 exists and devs are lazy / expensive.
You are misunderstanding. You can continue to keep using applications in X11-mode for as long as those applications maintain that code path. But many of the niceties Wayland provides, X11 won't get because it is virtually unmaintained.
Or said another way, X11 is already broken and getting slightly more broken every day.
And before you get angry at X11 going unmaintained, would you have expected Apple to support Carbon ad-infinitum?
Look at the backwards-compatibility and new-framework-adoption-rate woes Windows has to deal with because Win32 exists and devs are lazy / expensive.
Making it worse, the X11 developer team has publicly stated several times X11 is beyond fixing. That's why the X11 team de facto abandoned X11 and created Wayland in the first place.
X11 is a complete dead end. All applications need to eventually update. Put pressure on app developers to get to it...
X11 is a complete dead end. All applications need to eventually update. Put pressure on app developers to get to it...
The fact that X11 is a dead end (which I agree with) is why the accessibility conversation around Wayland is even more important to have.
If X11 was going to be some permanent fixture at least people who rely on it for apps that are abandoned or proprietary or can't/won't be updated would have an alternative they could keep using. But while X11 isn't going away any time soon, it's also very clearly not what we want to be building on or encouraging people to use. When I criticize the state of Wayland, I'm not saying X11 is great. I don't want to be on X11, I want to use Wayland. I want the features that Wayland has.
Where accessibility is concerned, we're at risk of losing a bunch of users if they lose the ability to use applications they rely on during the transition or if there aren't alternatives to help control the applications that don't get updated. This is not something where we can just say, "oh the developers are lazy."
If the stuff doesn't get supported, regardless of whether it's the developers' fault or Wayland's fault, the users can't just deal with it until the ecosystem catches up. Instead, they go to Windows (or more realistically to Mac, my understanding is that Apple is kind of the gold standard if you need accessibility controls).
----
Also add to this that "developers need to modernize" minimizes just how unapproachable a lot of this stuff actually is. I don't have a good grasp of how accessibility works in X11 because the development philosophy there has been for years "let the toolkit handle it" or "don't worry about it, controllers will just do something weird to handle window placement or font sizes on their own."
What are the standards for handling those problems in the future? There probably are standards, and they're probably better than what X11 was doing, but I don't feel confident that I know what they are. And there are X11 apps that are written by developers who aren't professionals and that have even less knowledge than I do about how the Linux desktop actually works. I would challenge anyone to find a good tutorial online written at a level that novice developers can understand that walks through how to make sure that a Wayland app is accessible, what changes need to be made from X11, and what the common problems or pitfalls are that developers might face.
Again, wouldn't necessarily be the biggest problem in the world -- except for the fact that X11 is a dead end and Wayland is the future. And because it's the future, we really, really need to make this stuff work.
If X11 was going to be some permanent fixture at least people who rely on it for apps that are abandoned or proprietary or can't/won't be updated would have an alternative they could keep using. But while X11 isn't going away any time soon, it's also very clearly not what we want to be building on or encouraging people to use. When I criticize the state of Wayland, I'm not saying X11 is great. I don't want to be on X11, I want to use Wayland. I want the features that Wayland has.
Where accessibility is concerned, we're at risk of losing a bunch of users if they lose the ability to use applications they rely on during the transition or if there aren't alternatives to help control the applications that don't get updated. This is not something where we can just say, "oh the developers are lazy."
If the stuff doesn't get supported, regardless of whether it's the developers' fault or Wayland's fault, the users can't just deal with it until the ecosystem catches up. Instead, they go to Windows (or more realistically to Mac, my understanding is that Apple is kind of the gold standard if you need accessibility controls).
----
Also add to this that "developers need to modernize" minimizes just how unapproachable a lot of this stuff actually is. I don't have a good grasp of how accessibility works in X11 because the development philosophy there has been for years "let the toolkit handle it" or "don't worry about it, controllers will just do something weird to handle window placement or font sizes on their own."
What are the standards for handling those problems in the future? There probably are standards, and they're probably better than what X11 was doing, but I don't feel confident that I know what they are. And there are X11 apps that are written by developers who aren't professionals and that have even less knowledge than I do about how the Linux desktop actually works. I would challenge anyone to find a good tutorial online written at a level that novice developers can understand that walks through how to make sure that a Wayland app is accessible, what changes need to be made from X11, and what the common problems or pitfalls are that developers might face.
Again, wouldn't necessarily be the biggest problem in the world -- except for the fact that X11 is a dead end and Wayland is the future. And because it's the future, we really, really need to make this stuff work.
> Where accessibility is concerned, we're at risk of losing a bunch of users if they lose the ability to use applications they rely on during the transition
The wayland/x11 compatibility shims work and will continue to do so for a long time, for the reasons you are mentioning. Basically both will work on a Wayland system for the foreseeable future - the big change was making Wayland the default which puts the focus there instead of allowing people to mentally push that work off into the future.
Wayland is prime-time, it's shipping as the default for all the big distros. It's here - time to get with it and update your codebase. Like has already been pointed out, Wayland isn't new, and this day has been coming for years. Now app developers will be compelled to finally put in the work.
It's not fair to complain about Wayland when it's some app developers that are not modernizing.
The wayland/x11 compatibility shims work and will continue to do so for a long time, for the reasons you are mentioning. Basically both will work on a Wayland system for the foreseeable future - the big change was making Wayland the default which puts the focus there instead of allowing people to mentally push that work off into the future.
Wayland is prime-time, it's shipping as the default for all the big distros. It's here - time to get with it and update your codebase. Like has already been pointed out, Wayland isn't new, and this day has been coming for years. Now app developers will be compelled to finally put in the work.
It's not fair to complain about Wayland when it's some app developers that are not modernizing.
> It's not fair to complain about Wayland when it's app developers that are not modernizing.
How do they modernize?
Like you point out, Wayland isn't new. So, I would repeat:
> I would challenge anyone to find a good tutorial online written at a level that novice developers can understand that walks through how to make sure that a Wayland app is accessible, what changes need to be made from X11, and what the common problems or pitfalls are that developers might face.
"Need to modernize" is worthless advice without follow-up advice about what needs to be done to modernize. How many developers building apps for Linux even know what the at-spi protocol is?
----
But more to the point:
> It's not fair
I'm not blaming Wayland devs. I like a lot of Wayland's approach to controls and structure, I agree with a lot of the development philosophy. This isn't about what's fair, I'm telling you that because Wayland is the future and because X11 is a dead end, if users with accessibility concerns can't use Wayland and they can't stick with X11 (which will become increasingly difficult for them to do as X11 decays more and more), they will leave the Linux ecosystem entirely because they will not be physically able to use it. It does not matter who's fault that is.
Is it fair? Who cares, it's going to happen regardless if the accessibility situation doesn't improve.
This is just kicking the can back and forth, blaming application developers changes nothing about the situation that people are in. If application developers need to modernize, then the question becomes "how do we make that easier for them to do and how do we encourage more of them to do it?" Because clearly the current approach of calling them lazy doesn't seem to be working.
How do they modernize?
Like you point out, Wayland isn't new. So, I would repeat:
> I would challenge anyone to find a good tutorial online written at a level that novice developers can understand that walks through how to make sure that a Wayland app is accessible, what changes need to be made from X11, and what the common problems or pitfalls are that developers might face.
"Need to modernize" is worthless advice without follow-up advice about what needs to be done to modernize. How many developers building apps for Linux even know what the at-spi protocol is?
----
But more to the point:
> It's not fair
I'm not blaming Wayland devs. I like a lot of Wayland's approach to controls and structure, I agree with a lot of the development philosophy. This isn't about what's fair, I'm telling you that because Wayland is the future and because X11 is a dead end, if users with accessibility concerns can't use Wayland and they can't stick with X11 (which will become increasingly difficult for them to do as X11 decays more and more), they will leave the Linux ecosystem entirely because they will not be physically able to use it. It does not matter who's fault that is.
Is it fair? Who cares, it's going to happen regardless if the accessibility situation doesn't improve.
This is just kicking the can back and forth, blaming application developers changes nothing about the situation that people are in. If application developers need to modernize, then the question becomes "how do we make that easier for them to do and how do we encourage more of them to do it?" Because clearly the current approach of calling them lazy doesn't seem to be working.
XWayland does not seem to be going away anytime soon. So until it does (if it ever does), X11 apps will continue to work.
I don't use accessibility features, but I do daily drive a Wayland system (Fedora 39 and 38) and have experienced zero issues. I honestly don't even know what system any given app is trying to use - it all "just works". That is to say I don't believe the sky is falling like some people make it sound.
With that said - the more pressure that is placed on app developers to figure it out, the better. Kicking the can down the road just because XWayland works today is foolish. If you have an app that you rely on that uses X11 exclusively - you should complain to the app developers today so that tomorrow it doesn't stop working.
I don't use accessibility features, but I do daily drive a Wayland system (Fedora 39 and 38) and have experienced zero issues. I honestly don't even know what system any given app is trying to use - it all "just works". That is to say I don't believe the sky is falling like some people make it sound.
With that said - the more pressure that is placed on app developers to figure it out, the better. Kicking the can down the road just because XWayland works today is foolish. If you have an app that you rely on that uses X11 exclusively - you should complain to the app developers today so that tomorrow it doesn't stop working.
> I don't use accessibility features, but I do daily drive a Wayland system (Fedora 39 and 38) and have experienced zero issues.
The entire Linux conversation on accessibility summed up in one sentence.
> If you have an app that you rely on that uses X11 exclusively - you should complain to the app developers today so that tomorrow it doesn't stop working.
And when they say, "we agree, what specifically do we need to do to be accessible under Wayland", what do I tell them?
The entire Linux conversation on accessibility summed up in one sentence.
> If you have an app that you rely on that uses X11 exclusively - you should complain to the app developers today so that tomorrow it doesn't stop working.
And when they say, "we agree, what specifically do we need to do to be accessible under Wayland", what do I tell them?
> The wayland/x11 compatibility shims work and will continue to do so for a long time, for the reasons you are mentioning.
Accessibility is the one thing that xwayland isn't useful for; if my input system can't interact with wayland windows, what's the point?
Accessibility is the one thing that xwayland isn't useful for; if my input system can't interact with wayland windows, what's the point?
> or more realistically to Mac, my understanding is that Apple is kind of the gold standard if you need accessibility controls.
Honestly, yes.
The iPhone is light years ahead of Android on the accessibility side, and it is the device you are most likely to always carry with you.
If you are using an iPhone, it already makes more sense to purchase a Mac, and from that point on going knee-deep into the Apple ecosystem makes sense in a lot of ways.
Like, you can hook up your smart doorbell to your Apple TV (for HomeKit), and when someone rings the door / motion is detected, Apple's image recognition can tell you on your iPhone who is at the door.
Honestly, yes.
The iPhone is light years ahead of Android on the accessibility side, and it is the device you are most likely to always carry with you.
If you are using an iPhone, it already makes more sense to purchase a Mac, and from that point on going knee-deep into the Apple ecosystem makes sense in a lot of ways.
Like, you can hook up your smart doorbell to your Apple TV (for HomeKit), and when someone rings the door / motion is detected, Apple's image recognition can tell you on your iPhone who is at the door.
xorg can be an unfixable mess, and wayland can still be unfit for purpose as a replacement. Both can be true at the same time.
btw, I already said something wrong, because, which wayland? It's not a thing.
btw, I already said something wrong, because, which wayland? It's not a thing.
I mean, if you want accessibility support, generally straying outside of big/default projects ends up being a struggle.
Like, you can complain about missing deep accessibility support in something like Bpswm or Ratpoison, but is that really fair?
I'm guessing accessibility support is/will be pretty good on both Mutter (Gnome) and Kwin (KDE). Wlroots-based probably will be too with the community attention it is getting. Stray beyond that and you'll be on your own.
Like, you can complain about missing deep accessibility support in something like Bpswm or Ratpoison, but is that really fair?
I'm guessing accessibility support is/will be pretty good on both Mutter (Gnome) and Kwin (KDE). Wlroots-based probably will be too with the community attention it is getting. Stray beyond that and you'll be on your own.
100% false. Literally nothing you said here is true.
> You can continue to keep using applications in X11-mode for as long as those applications maintain that code path.
Notice that I never said applications. I'm aware that xwayland is actually quite good these days; the problem is accessibility and automation tools that it can't support.
> would you have expected Apple to support Carbon ad-infinitum?
> Look at the backwards-compatibility and new-framework-adoption-rate woes Windows has to deal with because Win32 exists and devs are lazy / expensive.
Yeah, devs are expensive, which is why backward compatibility is so important. Microsoft, for its many faults, seems to understand that breaking applications every few years and demanding that developers put in time in order to keep things working is poor form, leading to people making comments like
> I’ll also give a shout-out to our friends in the Operating Systems business: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, and so on, for doing such a great job of backwards compatibility on their successful platforms.
- https://medium.com/@steve.yegge/dear-google-cloud-your-depre...
In fact, the rest of that essay is a great commentary on exactly why this kind of thing is bad and why Apple should be derided exactly for this kind of thing.
Notice that I never said applications. I'm aware that xwayland is actually quite good these days; the problem is accessibility and automation tools that it can't support.
> would you have expected Apple to support Carbon ad-infinitum?
> Look at the backwards-compatibility and new-framework-adoption-rate woes Windows has to deal with because Win32 exists and devs are lazy / expensive.
Yeah, devs are expensive, which is why backward compatibility is so important. Microsoft, for its many faults, seems to understand that breaking applications every few years and demanding that developers put in time in order to keep things working is poor form, leading to people making comments like
> I’ll also give a shout-out to our friends in the Operating Systems business: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, and so on, for doing such a great job of backwards compatibility on their successful platforms.
- https://medium.com/@steve.yegge/dear-google-cloud-your-depre...
In fact, the rest of that essay is a great commentary on exactly why this kind of thing is bad and why Apple should be derided exactly for this kind of thing.
Is there documentation about how to get started with at-spi somewhere that I just haven't been able to find online?
https://wiki.linuxfoundation.org/accessibility/atk/at-spi/st... exists, but is fairly unapproachable and it's not clear to me as a developer where I would start if I was trying to either build an application that hooked into at-spi or to set up automated tests for at-spi events on my own software.
The common advice is always "use a graphical toolkit", but let's say I'm stepping outside of a toolkit like GTK and I'm building something smaller, or let's say that I want to build a toy screenreader of my own. I've had an awful time trying to find documentation about this stuff.
https://wiki.linuxfoundation.org/accessibility/atk/at-spi/st... exists, but is fairly unapproachable and it's not clear to me as a developer where I would start if I was trying to either build an application that hooked into at-spi or to set up automated tests for at-spi events on my own software.
The common advice is always "use a graphical toolkit", but let's say I'm stepping outside of a toolkit like GTK and I'm building something smaller, or let's say that I want to build a toy screenreader of my own. I've had an awful time trying to find documentation about this stuff.
Here[1] is a good introduction. And here[2] are links to the library and dbus[3] reference documentation.
[1] https://en.trycht.cz/2023/12/15/down-and-down-exploring-the-...
[2] https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/main/READ...
[3] https://gnome.pages.gitlab.gnome.org/at-spi2-core/devel-docs...
[1] https://en.trycht.cz/2023/12/15/down-and-down-exploring-the-...
[2] https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/main/READ...
[3] https://gnome.pages.gitlab.gnome.org/at-spi2-core/devel-docs...
Genuinely thanks, I was familiar with the second two links but the first link in particular is useful. I've been trying to get a handle around the inner workings of Linux accessibility in my spare time for a while, so I'm grateful for more resources.
So this is not meant to be dismissive of you, I really do appreciate it, but also wow this is still pretty anemic documentation compared to most other tech fields. I kind of wonder if this is also a chicken-and-egg problem because the way the healthy documentation springs up around projects is enough people use the projects that they run into issues, they start documenting best practices... and in areas like Linux accessibility where (as I understand it) there are often like 10-20 people total working on the technologies behind it at any given time, that community isn't going to exist and we're going to get tutorials that say stuff like:
> Of course, there are much more interfaces to use or implement for specific objects, like the Text interface for text controls, Table interface for tables, etc., but the principles of these interfaces are the same, just a normal DBus programming with all it entails.
So there aren't going to be a ton of people doing interesting things in that field or digging into how stuff works, which means it's not going to have people available to help make the field more approachable.
But again, I do appreciate the resources you did find.
So this is not meant to be dismissive of you, I really do appreciate it, but also wow this is still pretty anemic documentation compared to most other tech fields. I kind of wonder if this is also a chicken-and-egg problem because the way the healthy documentation springs up around projects is enough people use the projects that they run into issues, they start documenting best practices... and in areas like Linux accessibility where (as I understand it) there are often like 10-20 people total working on the technologies behind it at any given time, that community isn't going to exist and we're going to get tutorials that say stuff like:
> Of course, there are much more interfaces to use or implement for specific objects, like the Text interface for text controls, Table interface for tables, etc., but the principles of these interfaces are the same, just a normal DBus programming with all it entails.
So there aren't going to be a ton of people doing interesting things in that field or digging into how stuff works, which means it's not going to have people available to help make the field more approachable.
But again, I do appreciate the resources you did find.
I am not an expert, but at-spi doesn't solve the problem here as it was already discussed in the slack for the talon software. Basically "Accessibility software uses the at-spi protocol" seems to be an over-generalization.
The important bits:
> if you only say "accessibility" you may get the response "but at-spi2 works independent of x11 or wayland" the problem with at-spi2 is that it's opt-in by the application, so some programs just don't show up at all. the coverage of at-spi2 in video games is basically zero, for
and
> [...] wayland's stance on tools like talon is 'no' [...]
I may also need to switch back to windows if X11 support is dropped "too far" before wayland is there in the accessibility aspect.
The important bits:
> if you only say "accessibility" you may get the response "but at-spi2 works independent of x11 or wayland" the problem with at-spi2 is that it's opt-in by the application, so some programs just don't show up at all. the coverage of at-spi2 in video games is basically zero, for
and
> [...] wayland's stance on tools like talon is 'no' [...]
I may also need to switch back to windows if X11 support is dropped "too far" before wayland is there in the accessibility aspect.
> Wayland's design requiring accessibility to be reimplemented by every DE
I'm not a big Wayland fan (quite the opposite truly), but I don't know if this is true: if there's an accessibility protocol made for Wayland you could (in theory) have one accessibility SW accessing many Wayland DE.
So this isn't a Wayland design issue, but it is an implementation issue: given that many DE have reimplemented the Wayland server, there will be less shared code than with X and more bugs to take into account.
Of course given the age of Wayland and that this is still an issue really show the problems with Wayland..
I'm not a big Wayland fan (quite the opposite truly), but I don't know if this is true: if there's an accessibility protocol made for Wayland you could (in theory) have one accessibility SW accessing many Wayland DE.
So this isn't a Wayland design issue, but it is an implementation issue: given that many DE have reimplemented the Wayland server, there will be less shared code than with X and more bugs to take into account.
Of course given the age of Wayland and that this is still an issue really show the problems with Wayland..
> the Wayland server
This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.
Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there.
There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.
This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.
Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. I think most casual users haven't realized this. KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
That makes targeting it, whatever "it" actually is, with tools for accessibility all that much harder. That's on top of the Wayland protocol's hostility to things that would make that job easier. We've "secured" the system against use by anyone who doesn't have working eyes or hands. There's no malice there, just the unintended consequence of a system designed by able-bodied people. I'm not even sure X is better in this regard, except that there are solutions like Talon that work there.
There are shared libraries like wlroots that can help with consistency, but it doesn't implement everything and not every compositor is using it. Something like accessibility shouldn't be an extension protocol but a core part of the design.
> This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.
>
> Wayland has conflated those two concepts by making every Wayland compositor have to do both roles.
This is fine. Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver. You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects. Focus on what users actually need from the applications (like: working screen capture).
X11 - the platform with more window managers and terminal emulators than actual apps. Wayland needn't repeat the same mistakes, but here we are on that trajectory.
> KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
Close enough. We have kwin, Mutter, and wlroots (the last one effectively doing what Weston should have done from the start) - three disjoint codebases.
Gnome telling SDL2 to link to libadwaita to draw clientside window borders is just cherry on top.
This is fine. Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver. You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects. Focus on what users actually need from the applications (like: working screen capture).
X11 - the platform with more window managers and terminal emulators than actual apps. Wayland needn't repeat the same mistakes, but here we are on that trajectory.
> KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain).
Close enough. We have kwin, Mutter, and wlroots (the last one effectively doing what Weston should have done from the start) - three disjoint codebases.
Gnome telling SDL2 to link to libadwaita to draw clientside window borders is just cherry on top.
I'm going to partially agree and partially disagree, I think...
> Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
Every other graphical system did so by tying the protocol to an entire specific software stack; Windows/Android/MacOS/Haiku all require you to use their single official compositor and window manager. I get that you're arguing that's a good thing, but I pretty strongly disagree.
> IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver.
Hard agree, 100% yes; even if they'd just focused on shipping a single working example desktop environment, at least it would have forced them to figure out all the protocols that need to exist.
> You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects.
I'm less convinced of that; people aren't asking for shallow customization at all, and I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm. You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
But overall, I tend to agree; personally I would have liked wlroots to effectively become the unifying point and have been part of the initial release, along with actually shipping most of the needed protocols up front rather than effectively leaving everything except drawing windows as a TODO.
> Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
Every other graphical system did so by tying the protocol to an entire specific software stack; Windows/Android/MacOS/Haiku all require you to use their single official compositor and window manager. I get that you're arguing that's a good thing, but I pretty strongly disagree.
> IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver.
Hard agree, 100% yes; even if they'd just focused on shipping a single working example desktop environment, at least it would have forced them to figure out all the protocols that need to exist.
> You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects.
I'm less convinced of that; people aren't asking for shallow customization at all, and I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm. You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
But overall, I tend to agree; personally I would have liked wlroots to effectively become the unifying point and have been part of the initial release, along with actually shipping most of the needed protocols up front rather than effectively leaving everything except drawing windows as a TODO.
> [...] I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm.
I am a former dwm user (contributed patches too), and I'd say we represent a group of marginal importance. Suckless is as much a philosophy as it is a lifestyle choice. It proves that simplistic software can be practical, but skims over many in-depth issues, such as accessibility.
Once we get the elitists out of the way, the needs of the 99.99% are not that hard to meet: Windows & macOS combined market share more than proves it; tools like Hammerspoon or AutoHotkey fill the gaps for most power users.
> You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
Hammerspoon uses Lua; macOS doesn't even ship a Lua interpreter or ObjC bindings.
Also, the majority of the population is not technically competent enough to even care about decisions such as JavaScript vs Guile vs Bash; power users in practice turn out patient enough to put up with garbage like AppleScript, because it gets work done.
The continued prevalence of memory unsafe languages is unfortunate, but a well-written and well-maintained C project used by a million people is going to provide more value than an absolute marvel of engineering, written in Rust, used by a hundred.
I am a former dwm user (contributed patches too), and I'd say we represent a group of marginal importance. Suckless is as much a philosophy as it is a lifestyle choice. It proves that simplistic software can be practical, but skims over many in-depth issues, such as accessibility.
Once we get the elitists out of the way, the needs of the 99.99% are not that hard to meet: Windows & macOS combined market share more than proves it; tools like Hammerspoon or AutoHotkey fill the gaps for most power users.
> You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
Hammerspoon uses Lua; macOS doesn't even ship a Lua interpreter or ObjC bindings.
Also, the majority of the population is not technically competent enough to even care about decisions such as JavaScript vs Guile vs Bash; power users in practice turn out patient enough to put up with garbage like AppleScript, because it gets work done.
The continued prevalence of memory unsafe languages is unfortunate, but a well-written and well-maintained C project used by a million people is going to provide more value than an absolute marvel of engineering, written in Rust, used by a hundred.
From an outsider point of view it looks like the ecosystem would have been much healthier if KDE and Gnome had used wlroots. Get everyone talking in the abstraction so plugins can be written.
Whereas Wayland originated in 2008, sway didn't exist until 2015, Wlroots 2017. This is not when they were ready merely when development begun.
Furthermore it was of vital import for KDE and Gnome to support both X11 and Wayland for years and leverage their large existing codebase. Wlroots would both have to travel back in time like the terminator from 2018/2020 to 2010 and become universally suitable en route.
Furthermore it was of vital import for KDE and Gnome to support both X11 and Wayland for years and leverage their large existing codebase. Wlroots would both have to travel back in time like the terminator from 2018/2020 to 2010 and become universally suitable en route.
Personally I don't plan to switch to Wayland without using wlroots based compositor (preferably one I write myself).
Have you looked into it? I believe writing a wlroots compositor to be in the general ballpark of as difficult as writing an Xorg window manager—which is, beyond the type of project I’m likely to take up in my spare time, but at least doable by mere mortals.
Far more work. I wrote the X wm I'm currently using in a couple of weeks and it's a few hundred lines of code. You can get a working X WM in a few dozen lines or tens of thousands. Mine is ca. 700 at this point (floating+tiling).
I considered wlroots but the complexity is far higher and Im not in a rush to move to Wayland.
I considered wlroots but the complexity is far higher and Im not in a rush to move to Wayland.
Yes, the lack of an unified server is such a shame. The great selling point of Wayland originally was that it avoided extra context switches by unifying the server and the window manager, this means every window manager must reimplement the server and every protocol by itself. But in an ideal world, we could have had a single Wayland server and window managers being loaded as plugins in the server process.
> But in an ideal world, we could have had a single Wayland server and window managers being loaded as plugins in the server process.
It is never too late to start improving things.
It is never too late to start improving things.
Ecosystem effects mean that it kind of is. Even if we made the software in question (probably on top of wlroots, maybe even just extending wayfire which IIRC kind of already has the plugin system you need?) there is zero chance GNOME or KDE will use it, and I wouldn't bet even on sway or such.
Well, if people are using Gnome or KDE they've already largely chosen conformity, so why care about that?
On the one hand, yes, I'm tempted to just ignore GNOME+KDE because they'll never play nice, and just go build something better without them.
On the other hand, this means that the ecosystem overall stays fragmented and we get an eternal state of "to do X in Windows do foo, in MacOS do bar, and on desktop Linux see this wiki page discussing your options". And while I suppose there would be value in ex. screenshot tools only needing 3 code paths, it would have been nice to only need 1.
On the other hand, this means that the ecosystem overall stays fragmented and we get an eternal state of "to do X in Windows do foo, in MacOS do bar, and on desktop Linux see this wiki page discussing your options". And while I suppose there would be value in ex. screenshot tools only needing 3 code paths, it would have been nice to only need 1.
The overhead is low enough that my current wm is written in Ruby and the WM is nowhere near the hot path for anything. The notion that it's a problem or have the WM put of process is nonsense. If I ever write a Wayland compositor, I'll add an out of process WM interface, because it's far nicer to be able to restart at will without killing apps.
> If I ever write a Wayland compositor, I'll add an out of process WM interface
This is something I've been wondering for a long time - how long will it take before someone writes a Wayland-based server that provides an interface for window managers, system trays, and whatever other clients running in other processes, mimicking what X does?
This is something I've been wondering for a long time - how long will it take before someone writes a Wayland-based server that provides an interface for window managers, system trays, and whatever other clients running in other processes, mimicking what X does?
I think the main thing stopping it is that people get "stuck" on the compositor since even writing a wlroots based compositor is far more effort than the bare minimum for an X wm.
From what I can tell, Wayland makes things much less customizable and much more brittle than X11 (since Gnome, KDE, etc have their own monolithic compositors, and implementing a compositor is much more complicated than implementing a window manager). Since accessibility implies customization (for different people's issues), I think that means the Wayland ecosystem will never support accessibility in practice.
Take this redit post from someone with a bum shoulder, for example:
https://www.reddit.com/r/linux/comments/17oo98g/wayland_simp...
It's the second hit for "Wayland Accessiblity Protocol", so (I'm guessing) if there is such a protocol, it's extremely obscure and unsupported.
The first hit links to these two pages, which are separate lists of wayland accessibility regressions for KDE and GTK:
https://www.freedesktop.org/wiki/Accessibility/Wayland/
https://www.freedesktop.org/wiki/Accessibility/GTK-a11y-reva...
Of course, even if they address all the things on both lists (which is at least twice as much work as doing it under X11 was) none of that will help the person with a bad shoulder, since they need to mix and match between multiple environments to use their machine.
Take this redit post from someone with a bum shoulder, for example:
https://www.reddit.com/r/linux/comments/17oo98g/wayland_simp...
It's the second hit for "Wayland Accessiblity Protocol", so (I'm guessing) if there is such a protocol, it's extremely obscure and unsupported.
The first hit links to these two pages, which are separate lists of wayland accessibility regressions for KDE and GTK:
https://www.freedesktop.org/wiki/Accessibility/Wayland/
https://www.freedesktop.org/wiki/Accessibility/GTK-a11y-reva...
Of course, even if they address all the things on both lists (which is at least twice as much work as doing it under X11 was) none of that will help the person with a bad shoulder, since they need to mix and match between multiple environments to use their machine.
> Wayland makes things much less customizable and much more brittle than X11
Another way to put it is Wayland with a few years of development by a few Linux players (others were building alternatives, while yet others were seeing which one would win out, and yet others were hoping to stay on X11 forever) under its belt, is almost as solid as X11 with many decades of development by all the Linux players.
The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. X11 has been built and expanded for decades and even today is incapable of doing many modern functions that its competitors can.
Wayland, OTOH, has almost reached parity with X11 rapidly, does things that X11 is not even capable of, and has a roadmap to reach complete parity.
Another way to put it is Wayland with a few years of development by a few Linux players (others were building alternatives, while yet others were seeing which one would win out, and yet others were hoping to stay on X11 forever) under its belt, is almost as solid as X11 with many decades of development by all the Linux players.
The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong. X11 has been built and expanded for decades and even today is incapable of doing many modern functions that its competitors can.
Wayland, OTOH, has almost reached parity with X11 rapidly, does things that X11 is not even capable of, and has a roadmap to reach complete parity.
That's not "another way to put it", that's a completely different claim. Now if you'd like to make the claim that Wayland is actually developing at a great pace because the first 10 years didn't really count, that's plausibly defensible in some ways, though I'm not sure how we could objectively tell[0].
> The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong.
It's also not something anyone is arguing, and something that's not really meaningful because we have Xorg already. At best, you're arguing that Wayland actually has a chance to catch up even though it hasn't in the first 15 years.
> Wayland, OTOH, has almost reached parity with X11 rapidly,
Debatable but possible,
> does things that X11 is not even capable of,
Capable of without more extensions, but who's counting?
> and has a roadmap to reach complete parity.
Yeah, no. Wayland has roadmaps to someday hope to implement a lot of features, but explicitly is designed to not cover others and AFAIK has nobody working on others. There is not, and probably never will be, a wayland protocol to separate the window manager from the display server. There could be but AFAIK isn't any effort to let programs manipulate windows in a portable way (read: there will never be accessibility tools that work on all, or even most, compositors). Wayland is aiming for ~90% feature parity with X, and may someday reach it.
---
[0] I can think of some metrics you could use, but they're all hopelessly entangled in confounding variables. For example, we could graph number of X11 window managers released per year against Wayland compositors released per year, but even if you could pin down good numbers they're happening in completely different ecosystems and contexts. Likewise, we could make up a list of features and when they were added, but it seems a bit unreasonable to ex. hold it against X11 that nobody cared about HiDPI for the first ~30 years it existed.
> The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong.
It's also not something anyone is arguing, and something that's not really meaningful because we have Xorg already. At best, you're arguing that Wayland actually has a chance to catch up even though it hasn't in the first 15 years.
> Wayland, OTOH, has almost reached parity with X11 rapidly,
Debatable but possible,
> does things that X11 is not even capable of,
Capable of without more extensions, but who's counting?
> and has a roadmap to reach complete parity.
Yeah, no. Wayland has roadmaps to someday hope to implement a lot of features, but explicitly is designed to not cover others and AFAIK has nobody working on others. There is not, and probably never will be, a wayland protocol to separate the window manager from the display server. There could be but AFAIK isn't any effort to let programs manipulate windows in a portable way (read: there will never be accessibility tools that work on all, or even most, compositors). Wayland is aiming for ~90% feature parity with X, and may someday reach it.
---
[0] I can think of some metrics you could use, but they're all hopelessly entangled in confounding variables. For example, we could graph number of X11 window managers released per year against Wayland compositors released per year, but even if you could pin down good numbers they're happening in completely different ecosystems and contexts. Likewise, we could make up a list of features and when they were added, but it seems a bit unreasonable to ex. hold it against X11 that nobody cared about HiDPI for the first ~30 years it existed.
> Another way to put it is Wayland with a few years of development by a few Linux players (others were building alternatives, while yet others were seeing which one would win out, and yet others were hoping to stay on X11 forever) under its belt, is almost as solid as X11 with many decades of development by all the Linux players.
If Wayland is going to be caught up and have feature parity so soon, then why can't decisions to deprecate and remove X11 be 100% put on hold until then?
> The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong.
Nobody thinks that. But at the time X11 was missing all of those important features, there wasn't another full-featured option that everyone was rushing to deprecate and remove support for to force everyone onto the immature and incomplete X11, at the expense of things that already worked.
If Wayland is going to be caught up and have feature parity so soon, then why can't decisions to deprecate and remove X11 be 100% put on hold until then?
> The idea that X11 was a completely working option which had every capability it does today within years of its inception is wrong.
Nobody thinks that. But at the time X11 was missing all of those important features, there wasn't another full-featured option that everyone was rushing to deprecate and remove support for to force everyone onto the immature and incomplete X11, at the expense of things that already worked.
It is sort of interesting, having the renderer split from the desktop environment did seem to enforce some level of compatibility.
Of course, there’s no reason that this has to be a separate process, it could just have been a library that everybody links to. wlroots looked like it could have been a nice library that provided a lot of that shared functionality, but then Gnome and KDE didn’t use it, so the predictions of fracturing seem to have come true.
Of course, there’s no reason that this has to be a separate process, it could just have been a library that everybody links to. wlroots looked like it could have been a nice library that provided a lot of that shared functionality, but then Gnome and KDE didn’t use it, so the predictions of fracturing seem to have come true.
I just switched back to Windows after 20 years on Linux and I regret it... I'll be switching back ASAP... everything just works better by default on Linux for what I do (I don't game much but Steam is pretty nice on Linux anyways).
The main problem is just their steady increase in cross-selling, nagware, advertising, and feature bloat. That is what makes me want to be rid of it.
But Windows 11 really achieves greatness in a lot of ways, which offsets it.
But Windows 11 really achieves greatness in a lot of ways, which offsets it.
You'd switch your entire OS before trying an alternative accessibility program or a DE that comes with one? What's the state of accessibility on Gnome for example that seems to come with batteries included?
I'm not trying to be rude just genuinely curious, and I also don't use a DE, wayland or accessibility, so I have no horse in the game.
I'm not trying to be rude just genuinely curious, and I also don't use a DE, wayland or accessibility, so I have no horse in the game.
Talon is what I would describe as accessibility for programmers (my definition, not the developer's!). You effectively write software that replaces keyboard and mouse usage, generically, flexibly and programmatically.
So when you write commands you bind them in different way: app specific[1], feature specific[2][3], OS-specific, hecking __programming language specific__[4] etc, and then talon mixes and matches all of that stuff together.
So let's say I have VSCode focused on a javascript file . Talon knows this, and so I have "panel switch" which is a vscode specific command, and "op strict equal" to insert ` === `, but I also have generic text editing commands (because it's an editor), and multi cursor commands (because vscode has been tagged as multi cursor supporting), and tab commands (because vscode is a tab-based editor), and so on and so on.
If I then switched to the browser I would keep the generic text editing commands, and the tab commands, as it supports both of those things, but I would no longer have multi cursor support (or JS commands), because my browser doesn't support that.
This also means you can by and large use the same talon config (and so the same voice commands) on windows, mac and x11.
So for me switching to windows is actually less of a pain because most of the ways I interact with my computer don't actually change, as talon abstracts that away quite a bit.
[1] https://github.com/talonhub/community/blob/main/apps/vscode/... / https://github.com/talonhub/community/blob/main/apps/vscode/...
[2] https://github.com/talonhub/community/blob/main/core/windows...
[3] where vscode gets its features "bound" https://github.com/talonhub/community/blob/main/apps/vscode/...
[4] https://github.com/talonhub/community/blob/main/lang/javascr...
So when you write commands you bind them in different way: app specific[1], feature specific[2][3], OS-specific, hecking __programming language specific__[4] etc, and then talon mixes and matches all of that stuff together.
So let's say I have VSCode focused on a javascript file . Talon knows this, and so I have "panel switch" which is a vscode specific command, and "op strict equal" to insert ` === `, but I also have generic text editing commands (because it's an editor), and multi cursor commands (because vscode has been tagged as multi cursor supporting), and tab commands (because vscode is a tab-based editor), and so on and so on.
If I then switched to the browser I would keep the generic text editing commands, and the tab commands, as it supports both of those things, but I would no longer have multi cursor support (or JS commands), because my browser doesn't support that.
This also means you can by and large use the same talon config (and so the same voice commands) on windows, mac and x11.
So for me switching to windows is actually less of a pain because most of the ways I interact with my computer don't actually change, as talon abstracts that away quite a bit.
[1] https://github.com/talonhub/community/blob/main/apps/vscode/... / https://github.com/talonhub/community/blob/main/apps/vscode/...
[2] https://github.com/talonhub/community/blob/main/core/windows...
[3] where vscode gets its features "bound" https://github.com/talonhub/community/blob/main/apps/vscode/...
[4] https://github.com/talonhub/community/blob/main/lang/javascr...
That is one incredibly cool piece of software.
Is it app state specific? Can it detect a text box within an app? Or a text box while in Insert mode in a vim-like app?
By and large it's not that smart, no.
For example[1] it doesn't know if you're using VSCode that you have focused the inbuilt terminal, and so it should now accept terminal commands (eg "cd <whatever>") until you focus back. It knows about the language that you are using because you have configured your text editor to have the file name in the window name, which it can reliably read. This is also how you have website specific configuration.
[1] last I checked! I think there was some work to try to solve this problem, I'm not sure where they got to though, I kind of went down my own configuration fork for a while
For example[1] it doesn't know if you're using VSCode that you have focused the inbuilt terminal, and so it should now accept terminal commands (eg "cd <whatever>") until you focus back. It knows about the language that you are using because you have configured your text editor to have the file name in the window name, which it can reliably read. This is also how you have website specific configuration.
[1] last I checked! I think there was some work to try to solve this problem, I'm not sure where they got to though, I kind of went down my own configuration fork for a while
With Talon on Mac I believe this is possible (Mac has surprisingly nice accessibility APIs), but I don't know whether Talon on X11 can do it. If it's possible it would probably(?) involve rolling your own at-spi stuff.
Apple in general seems to really embrace accessibility. I remember using the screen reader back in middle school because it was “cool”, and now some 25 years later I can see that it was the tip of the accessibility iceberg. My iPhone has just _tons_ of accessibility features that I’ll probably never use, but that are invaluable to people experiencing all kinds of accessibility hurdles in their daily life.
I can’t speak much to windows accessibility, although Mouse Keys got me through several rough times in my life where I fried or broke my mouse in some way or another. I do think windows has improved with time, at least by accidentally triggering the screen reading in W10 more times than I’d care to admit
I can’t speak much to windows accessibility, although Mouse Keys got me through several rough times in my life where I fried or broke my mouse in some way or another. I do think windows has improved with time, at least by accidentally triggering the screen reading in W10 more times than I’d care to admit
[deleted]
How does that have anything to do with disabilities? Honest, it sounds like a form of fancy customisation and I don't doubt Wayland may not support it, but that's not why accessibility is a thing.
> Honest, it sounds like a form of fancy customisation
Accessibility is customization, and customization is accessibility. They are one and the same.
User control over interfaces is an accessibility feature. At the heart of accessible control schemes is the notion that if a user isn't able to use a traditional control-scheme they should be able to build or hook into something else or customize something that works for them.
This is a big problem with how the Linux community thinks about accessibility. Accessibility is not a separate concern from user agency and control. Accessibility IS user agency and control over a user's interface. It is the ability to take an interface you can't use or that is frustrating or painful to use and to adapt it to your needs.
Accessibility is fully aligned with Linux/GNU philosophy, but we treat it like a separate issue and like it's a chore to support, rather than being a central pillar of how we ought to be approaching software development in general.
----
Here, GP has RSI which means their customization is linked to a traditional physical disability. But to be clear, even if that wasn't the case and even if this just made their life easier and they didn't have a clear, socially accepted disability classification to point to -- customization is still accessibility. Gatekeeping accessibility or asking people to prove that they're fully "disabled" isn't really helpful, we should still be prioritizing making it possible to build things like this. And we should still be treating it like an accessibility concern regardless of whether there's an easily defined disability to point to.
Accessibility is customization, and customization is accessibility. They are one and the same.
User control over interfaces is an accessibility feature. At the heart of accessible control schemes is the notion that if a user isn't able to use a traditional control-scheme they should be able to build or hook into something else or customize something that works for them.
This is a big problem with how the Linux community thinks about accessibility. Accessibility is not a separate concern from user agency and control. Accessibility IS user agency and control over a user's interface. It is the ability to take an interface you can't use or that is frustrating or painful to use and to adapt it to your needs.
Accessibility is fully aligned with Linux/GNU philosophy, but we treat it like a separate issue and like it's a chore to support, rather than being a central pillar of how we ought to be approaching software development in general.
----
Here, GP has RSI which means their customization is linked to a traditional physical disability. But to be clear, even if that wasn't the case and even if this just made their life easier and they didn't have a clear, socially accepted disability classification to point to -- customization is still accessibility. Gatekeeping accessibility or asking people to prove that they're fully "disabled" isn't really helpful, we should still be prioritizing making it possible to build things like this. And we should still be treating it like an accessibility concern regardless of whether there's an easily defined disability to point to.
I have such bad RSI from computer use that I can't use a keyboard for any length of time close to allowing me to hold a fulltime (or likely part time) job.
I have solved this by replacing my keyboard with voice commands almost entirely (I don't actually have a keyboard on my desk, but I can reach for my laptop keyboard if I really really have to), and am slowly working on replacing a trackball with an eye tracker (it's kind of headache-inducing though, so it's likely the trackball will stay for a while)
I'm not a medical professional but that sounds like a disability to me.
I have solved this by replacing my keyboard with voice commands almost entirely (I don't actually have a keyboard on my desk, but I can reach for my laptop keyboard if I really really have to), and am slowly working on replacing a trackball with an eye tracker (it's kind of headache-inducing though, so it's likely the trackball will stay for a while)
I'm not a medical professional but that sounds like a disability to me.
Thanks, that is the sort of answer I was looking for - a real disability and how you're working around it.
When I hear accessibility I tend to think of screen readers - magnification or text to speech - for people with low vision.
When I hear accessibility I tend to think of screen readers - magnification or text to speech - for people with low vision.
Recent discussions on HN have mentioned RSI being cured by exercise. (If I recall, someone specifically mentioned pull-ups.) It makes a kind of intuitive sense to me that the problem might be more a lack of normal wrist movement than the abnormal movement and positioning that the keyboard/mouse need.
This is a fundamental problem with people not suffering from medical problems understanding those who do.
Real diseases often have a progression of permanent damage over time and real treatments have positive and negative interactions with other aspects of patient health, cost, and a wide range of outcomes. Commercials especially push a simplistic view that a person has a problem and undergoes a treatment and their problem is resolved. This is as real as crimes being solved in scope of an hour drama or as real if you prefer as people hacking by pounding on the keyboard really fast.
Most users in Developed countries have access to both doctors and the internet and have whatever level of problems they have in spite of pursuing treatment options and probably wont benefit from "one weird trick" to beat RSI.
Real diseases often have a progression of permanent damage over time and real treatments have positive and negative interactions with other aspects of patient health, cost, and a wide range of outcomes. Commercials especially push a simplistic view that a person has a problem and undergoes a treatment and their problem is resolved. This is as real as crimes being solved in scope of an hour drama or as real if you prefer as people hacking by pounding on the keyboard really fast.
Most users in Developed countries have access to both doctors and the internet and have whatever level of problems they have in spite of pursuing treatment options and probably wont benefit from "one weird trick" to beat RSI.
RSI doesn’t seem to be one thing that has a universal cure.
Traditionally it has no cure at all, but apparently there are those who disagree.
The odds are pretty good that computer-related RSI is similar to other computer-related RSI. I see no particular need to specify that I'm not talking about tennis elbow when that is already abundantly evident from the context. Most of my comments could include an accurate disclaimer that I'm not talking about tennis elbow, but it wouldn't improve any of them.
The odds are pretty good that computer-related RSI is similar to other computer-related RSI. I see no particular need to specify that I'm not talking about tennis elbow when that is already abundantly evident from the context. Most of my comments could include an accurate disclaimer that I'm not talking about tennis elbow, but it wouldn't improve any of them.
> How does that have anything to do with disabilities? Honest, it sounds like a form of fancy customisation and I don't doubt Wayland may not support it, but that's not why accessibility is a thing.
Only on the internet would someone discuss a change they've made due to a disability, only to have someone else say challenge them on it and imply that they're bullshitting.
Only on the internet would someone discuss a change they've made due to a disability, only to have someone else say challenge them on it and imply that they're bullshitting.
Some disabilities make it harder to type, for example, so being able to (efficiently) use your voice is useful.
Because Talon is voice control, not just generic scripting.
If he/she is used to the program and wants to use it... yea? Why not?
I run the OS that runs the programs I want to use.
I run the OS that runs the programs I want to use.
Not sure why you're being down voted: not everyone cares about all levels of the software stack. Most people can be perfectly functional as long as they see a "Google chrome" icon anywhere on the display and once in chrome they feel at home. There's an entire OS built around chrome.
Why wouldn't someone ditch an OS for another to keep using the software they want?
Why wouldn't someone ditch an OS for another to keep using the software they want?
> Not sure why you're being down voted
Probably because it was a legitimate question out of curiosity with a couple sub-questions, and "why not" is a dismissal rather than an answer.
Probably because it was a legitimate question out of curiosity with a couple sub-questions, and "why not" is a dismissal rather than an answer.
> which means for you are no longer say supporting Windows, Mac and Linux; but Windows, Mac, X11, Gnome, KDE, Mate, Cina...
At a toolkit level, you don't really have to worry about that. When developing GTK or Qt apps, most of the DE integration and Wayland/x11-specific features are handled for you automatically. Basic trackpad gestures, copy/paste and windowing heuristics are handled by the toolkit, and so is accessibility software if your toolkit supports it.
If an app doesn't work well on a desktop's Wayland implimentation, it is less often a Wayland problem and more a desktop/toolkit problem. We had the same issue with non-conformist x11 software, unfortunately.
At a toolkit level, you don't really have to worry about that. When developing GTK or Qt apps, most of the DE integration and Wayland/x11-specific features are handled for you automatically. Basic trackpad gestures, copy/paste and windowing heuristics are handled by the toolkit, and so is accessibility software if your toolkit supports it.
If an app doesn't work well on a desktop's Wayland implimentation, it is less often a Wayland problem and more a desktop/toolkit problem. We had the same issue with non-conformist x11 software, unfortunately.
>most of the DE integration and Wayland/x11-specific features are handled for you automatically...
Just no ability to launch windows at absolute positions or do non-standard input stuff (like special mice, keyboards, or keyboard/mouse sharing) unless your particular wayland flavor has libei. And some waylands like sway are actively hostile to libei. Which is kind of microcosm of the waylands as whole.
Just no ability to launch windows at absolute positions or do non-standard input stuff (like special mice, keyboards, or keyboard/mouse sharing) unless your particular wayland flavor has libei. And some waylands like sway are actively hostile to libei. Which is kind of microcosm of the waylands as whole.
It's a microcosm of Linux. x11 had wildly non-conformant desktops since forever, having a larger spec doesn't inherently fix things or force desktops to abide by the rules.
Projects like GNOME would have dropped AppIndicator and server-side decorations whether it was included in Wayland or not. Drilling-down on a minimal set of secure features was the only path forward if Wayland wanted developers to take the protocol seriously.
Projects like GNOME would have dropped AppIndicator and server-side decorations whether it was included in Wayland or not. Drilling-down on a minimal set of secure features was the only path forward if Wayland wanted developers to take the protocol seriously.
TBF, I honestly think that X11 is also pretty bad about a lot of this stuff, but accessibility engines are able to hack around the problems. The underlying issue here is that in general, whether it's X11/Wayland/whatever, on Linux we don't treat accessibility issues like high priority items to fix and we don't treat accessibility interfaces as first-class citizens in the DE.
To the extent that we allow programmable interfaces outside of the terminal, we put those interfaces on top of the graphics stack rather than underneath it and we treat them like alternative control schemes, not common interfaces that every input device should be hooking into and sharing regardless of whether they're for some "disabled" category or not. Disability is a spectrum, having separate categories for "normal" interfaces and accessible interfaces doesn't capture that.
These problems are kind of universal, but X11 just happened to be so wildly insecure and had such bad encapsulation that devs could work around that problem. Which... better than nothing, I guess, but our primary way of mitigating accessibility problems shouldn't be to make our software worse.
I'm still on X11; I haven't fully figured out tablet settings and I'm waiting for OpenTabletdriver to mature a bit more before taking a serious dive into Wayland. But does being on X11 mean that my desktop is accessible or that I can test software that I build with a common screenreader to make sure it works for disabled users? No, of course not, I use i3wm where as far as I can tell accessibility software like Orca can't hook into any of the programs that I run, even programs with explicit support for Orca.
I don't think the problem here is the technology, the technology just reveals a deeper apathy that has always been present. It won't be fixed until we change our relationship with differently abled users and start working with accessibility communities on shared protocols/interfaces rather than treating those interfaces like afterthoughts. A lot of the "debates" about accessibility requirements like controlling window position, etc... stem from that issue and probably have solutions that would work for everyone if we prioritized finding them and approaching the problems from different angles.
To the extent that we allow programmable interfaces outside of the terminal, we put those interfaces on top of the graphics stack rather than underneath it and we treat them like alternative control schemes, not common interfaces that every input device should be hooking into and sharing regardless of whether they're for some "disabled" category or not. Disability is a spectrum, having separate categories for "normal" interfaces and accessible interfaces doesn't capture that.
These problems are kind of universal, but X11 just happened to be so wildly insecure and had such bad encapsulation that devs could work around that problem. Which... better than nothing, I guess, but our primary way of mitigating accessibility problems shouldn't be to make our software worse.
I'm still on X11; I haven't fully figured out tablet settings and I'm waiting for OpenTabletdriver to mature a bit more before taking a serious dive into Wayland. But does being on X11 mean that my desktop is accessible or that I can test software that I build with a common screenreader to make sure it works for disabled users? No, of course not, I use i3wm where as far as I can tell accessibility software like Orca can't hook into any of the programs that I run, even programs with explicit support for Orca.
I don't think the problem here is the technology, the technology just reveals a deeper apathy that has always been present. It won't be fixed until we change our relationship with differently abled users and start working with accessibility communities on shared protocols/interfaces rather than treating those interfaces like afterthoughts. A lot of the "debates" about accessibility requirements like controlling window position, etc... stem from that issue and probably have solutions that would work for everyone if we prioritized finding them and approaching the problems from different angles.
This is very true, and unfortunately there are very few people working on linux accessibility (including not me! I am part of the problem!).
TBC I don't have any educated opinions about Wayland (I don't know remotely enough to know if the decisions they made are good ones in the grander scheme of things), more that it's this looming existential sadness that I'll eventually have to give up on Linux.
And this is probably some form of "losing", but honestly WSL gets me pretty close to where I want to be in the getting shit done department. Just not in the "not using Windows" department ;-)
(MacOS is another fine option, but I literally bought a framework laptop a week ago, so that door is financially closed to me for a long while)
TBC I don't have any educated opinions about Wayland (I don't know remotely enough to know if the decisions they made are good ones in the grander scheme of things), more that it's this looming existential sadness that I'll eventually have to give up on Linux.
And this is probably some form of "losing", but honestly WSL gets me pretty close to where I want to be in the getting shit done department. Just not in the "not using Windows" department ;-)
(MacOS is another fine option, but I literally bought a framework laptop a week ago, so that door is financially closed to me for a long while)
> This is very true, and unfortunately there are very few people working on linux accessibility (including not me! I am part of the problem!).
Accessibility work itself ironically suffers from an accessibility problem. I brought up i3wm above, the issue for that is pretty illuminating: https://github.com/i3/i3/issues/3393
It's not that the devs are saying "this doesn't matter", the devs behind one of the most popular tiling window managers in the X11 ecosystem are saying, "this does matter, but we don't know how to fix it. We don't know what changes we'd need to make to be accessible."
It's a tragedy because I honestly believe that if accessibility communities were more heavily baked into testing and development in Linux and if this wasn't treated like two separate worlds, it would be better for everyone -- fixing accessibility concerns very often improves interfaces across the board and makes them more powerful. Of course, it shouldn't be the primary motivation, but it's worth mentioning that every single screenreader is a potential adblocker, every alternative control scheme is a way to automate and script software, every comprehensive text-based description of an interface is a way to pipe that interface into a terminal and build tools on top of it.
There's a huge amount of potential, but how do you bridge that gap? I don't really know, I tried looking into Orca to see what would need to happen here and bounced off of it pretty hard, it's not a very approachable tech stack and there aren't tutorials or getting started guides. And on the other side of the issue I can preach about needing accessibility input during interface design, but I'm not in a position to give specific advice because I don't use screenreaders or alternate control schemes and I don't know what the biggest problems are.
The people who need to be involved in that process can't get involved because there's a tech barrier in place even for technically inclined people, and because the underlying software locks them out from the start. i3wm isn't ever going to get someone who's intimately familiar with Orca to jump into the conversation because the people who need to use Orca can't use i3wm. So that leaves the people who can address that tech barrier, but they don't know what to do or how to approach the problem because of the lack of involvement and because the communities are isolated from each other. So it's a chicken-and-egg problem and I don't know how to solve it.
Accessibility work itself ironically suffers from an accessibility problem. I brought up i3wm above, the issue for that is pretty illuminating: https://github.com/i3/i3/issues/3393
It's not that the devs are saying "this doesn't matter", the devs behind one of the most popular tiling window managers in the X11 ecosystem are saying, "this does matter, but we don't know how to fix it. We don't know what changes we'd need to make to be accessible."
It's a tragedy because I honestly believe that if accessibility communities were more heavily baked into testing and development in Linux and if this wasn't treated like two separate worlds, it would be better for everyone -- fixing accessibility concerns very often improves interfaces across the board and makes them more powerful. Of course, it shouldn't be the primary motivation, but it's worth mentioning that every single screenreader is a potential adblocker, every alternative control scheme is a way to automate and script software, every comprehensive text-based description of an interface is a way to pipe that interface into a terminal and build tools on top of it.
There's a huge amount of potential, but how do you bridge that gap? I don't really know, I tried looking into Orca to see what would need to happen here and bounced off of it pretty hard, it's not a very approachable tech stack and there aren't tutorials or getting started guides. And on the other side of the issue I can preach about needing accessibility input during interface design, but I'm not in a position to give specific advice because I don't use screenreaders or alternate control schemes and I don't know what the biggest problems are.
The people who need to be involved in that process can't get involved because there's a tech barrier in place even for technically inclined people, and because the underlying software locks them out from the start. i3wm isn't ever going to get someone who's intimately familiar with Orca to jump into the conversation because the people who need to use Orca can't use i3wm. So that leaves the people who can address that tech barrier, but they don't know what to do or how to approach the problem because of the lack of involvement and because the communities are isolated from each other. So it's a chicken-and-egg problem and I don't know how to solve it.
I find this disappointing (the lack of accessibility tooling) as Wayland felt like a good opportunity to factor in accessibility from the get go.
For what it's worth though, accessibility was mentioned as one of the improvement area for which Gnome got funding: https://www.phoronix.com/news/GNOME-This-Week-Homed
Not sure what it will mean in practice, accessibility being a large topic.
For what it's worth though, accessibility was mentioned as one of the improvement area for which Gnome got funding: https://www.phoronix.com/news/GNOME-This-Week-Homed
Not sure what it will mean in practice, accessibility being a large topic.
There are a lot of missed opportunities with Wayland.
The sad thing to me is that Wayland is aiming at replacing X while at the same time proudly stating that they aren't going to support a fair bit of the functionality that X provides.
That makes the whole effort an exercise in regression to me.
The sad thing to me is that Wayland is aiming at replacing X while at the same time proudly stating that they aren't going to support a fair bit of the functionality that X provides.
That makes the whole effort an exercise in regression to me.
I do really like Wayland personally, for my usage it is now a really solid experience. No more weird graphical glitches and really smooth gaming experience. The side project pipewire is just amazing.
I really hope that protocols for accessibility will get the attention it deserves though
If you're seriously considering dropping Linux, I suggest investigating the BSDs as an alternative rather than Windows. No need to throw the baby out with the bathwater.
The issue is Wayland accessibility vs X11. How is this any different on a BSD?
Most BSDs have not adopted Wayland and, at least for now, most have said they don't intend to adopt Wayland.
I'm planning on moving all of my machines from Linux to BSD in part because of this, and in part because of SystemD.
I'm planning on moving all of my machines from Linux to BSD in part because of this, and in part because of SystemD.
Where'd you get that idea. Wayland is part of the freebsd handbook. There's even a page on xenocera about how to use sway on openbsd and what issues are left to make it work fully. Wayland compositors will end up working fine on openbsd. That obviously doesn't cover all the bsds yet though, but it will get there.
I guess my information is out of date. That's very disappointing news indeed.
I've enjoyed BSDs, but I don't know how sustainable an approach this is. Unless the BSD maintainers are going to absorb and maintain the old X codebase (they have already refused to treat it as a system component, and it's reputedly hard to maintain), it seems like sooner or later they will have to switch to Wayland, unless something else comes along. And while BSD might be able to solve the fragmentation problem within themselves, they would probably diverge from GNOME and KDE by doing so, cf XKCD #927, and anyway they are generally loath to include or endorse graphical components in the base system.
A first step might be to just have a list of all the functionality affected by fragmentation. So far, unfortunately, most such lists are accompanied by if not subsumed within angry rants.
A first step might be to just have a list of all the functionality affected by fragmentation. So far, unfortunately, most such lists are accompanied by if not subsumed within angry rants.
The future of X, if it has one, is to rip the backend off a Wayland compositor, deprecate most legacy features (server side fonts, most drawing primitives) and most visuals (e.g. Xrender has a required set of visuals; support those and no others) then test app by app you care about and add client side shims of there are any apps anyone cares about that can't be patched.
Most X apps these days use only a tiny subset of request types anyway (source: lots of time spent with xtruss) and most of what's left is easy to shim.
The X protocol is messy, but very little of it is used by software people both a) care about, and that b) isn't available in source form and can easily be upgraded.
Sometimes I wonder about taking wlroots and doing a FrankenCompositor with first class X protocol support, including window management and all the bits the Wayland proponents keep not wanting to add...
Most X apps these days use only a tiny subset of request types anyway (source: lots of time spent with xtruss) and most of what's left is easy to shim.
The X protocol is messy, but very little of it is used by software people both a) care about, and that b) isn't available in source form and can easily be upgraded.
Sometimes I wonder about taking wlroots and doing a FrankenCompositor with first class X protocol support, including window management and all the bits the Wayland proponents keep not wanting to add...
I don't know why they'd inevitably have to switch to Wayland. However, you never know what the future may bring. If BSD ceases to be a refuge, then I'll investigate other options at that time. For now, though, it seems OK.
> they would probably diverge from GNOME and KDE by doing so
Which would be something I could live with. I dislike Gnome quite a lot so don't care about that. I do use KDE, but it's nothing that would hurt too much to do without if necessary.
> they would probably diverge from GNOME and KDE by doing so
Which would be something I could live with. I dislike Gnome quite a lot so don't care about that. I do use KDE, but it's nothing that would hurt too much to do without if necessary.
> they have already refused to treat it as a system component, and it's reputedly hard to maintain
> and anyway they are generally loath to include or endorse graphical components in the base system.
I don't remember the others off the top of my head, but OpenBSD certainly seems to be treating Xenocara as a core part of the OS? It's not in the main src tree, but it's maintained in-house, the x* sets are treated like any other, and even some non-graphical programs depend on the xbase set for things like font rendering.
> and anyway they are generally loath to include or endorse graphical components in the base system.
I don't remember the others off the top of my head, but OpenBSD certainly seems to be treating Xenocara as a core part of the OS? It's not in the main src tree, but it's maintained in-house, the x* sets are treated like any other, and even some non-graphical programs depend on the xbase set for things like font rendering.
Mea culpa. I was only familiar with FreeBSD and NetBSD. As 'johnny22 noted, FreeBSD has already started looking at what they can do about Wayland. There is some discussion of the OpenBSD approach here:
https://news.ycombinator.com/item?id=24922625
https://news.ycombinator.com/item?id=24922625
Wayland is already an entry in the freebsd handbook. Here's a page on xenocera (the patchset on top of xorg that openbsd uses) describing what's they had to do to make sway run on openbsd https://xenocara.org/Wayland_on_OpenBSD.html
> it’s clear that Wayland is the future for modern, secure, performant display server needs on Linux.
Cool. I guess I can delay switching to Wayland until the future!
Cool. I guess I can delay switching to Wayland until the future!
Yea, more and more with computing, when I hear I should switch to something because it is "the future" or "modern," I am instantly suspicious. Maybe I'm just getting elderly and cranky, but "newness" itself is not a compelling sales pitch. I am more interested in things that have been already working in more than the happy-path case for 20 years, and have all their edge cases battle tested, and from the other replies to this article, it looks like there is still tons of work to do to cover every case. I think I'll be waiting another 10 years at least, and I hope distributions at least keep X.org as an option for at least that long.
Many years ago I used to look forward to every new software release. That was when software got better with each version. Nowadays things just get worse with each release, when it comes to user-interfaces and desktop apps. Time to move on to something else.
> Nowadays things just get worse with each release, when it comes to user-interfaces and desktop apps.
This is spot on and it makes me sad. We have hardware and programming languages available to us that people could only dream of 30 years ago and so much of the software we produce with it is objectively worse. I don't think Wayland (or X) is really salvageable at this point.
This is spot on and it makes me sad. We have hardware and programming languages available to us that people could only dream of 30 years ago and so much of the software we produce with it is objectively worse. I don't think Wayland (or X) is really salvageable at this point.
I wouldn't say that things necessarily get worse with each update. I think new features get gradually added which make the software less accessible and/or harder to learn for beginners and/or impact performance.
I know, all of the things I said can be said to be the worsening of the software. But what many people think when they read that sentence is that just the simple act of updating software is detrimental to the user's needs. Which I don't think is true all the time.
I know, all of the things I said can be said to be the worsening of the software. But what many people think when they read that sentence is that just the simple act of updating software is detrimental to the user's needs. Which I don't think is true all the time.
The modern design trends, removal of color from the user interface, increasing the amount of white space everywhere. And the gradual dumbing down of everything. I think those are each a real step back, compared to the old versions. So it slowly kept getting worse, bit by bit, until we got to where we are now.
> Yea, more and more with computing, when I hear I should switch to something because it is "the future" or "modern," I am instantly suspicious.
Same, but I'd take a step further. If the most common argument in favor of application X or Platform Y is that it's "more modern" or "the future", I make a mental note to avoid using that tech if at all possible - it's almost always guaranteed to be garbage. It's the tech equivalent of being set up on a blind date and being told the other person is "Nice".
Same, but I'd take a step further. If the most common argument in favor of application X or Platform Y is that it's "more modern" or "the future", I make a mental note to avoid using that tech if at all possible - it's almost always guaranteed to be garbage. It's the tech equivalent of being set up on a blind date and being told the other person is "Nice".
It'd probably help if most new things didn't also bolt on a bunch of anti-features and come with vague promises of reaching feature parity with the thing they say they're going to replace.
It is not being elderly. It is experience. We’ve seen more stuff becoming older. And we see similarities.
That being said. Wayland is good and it shall have replaced X11 years ago! It is made by the same people which maintain X11. Same applies to Systemd, implemented in C, unified interface and simple configs. Nothing is perfect and things need to mature. As usual :)
And? Tactile keyboards, switches and knobs are much better than touch screens. Mechanical keyboards are the counter reaction to bad input devices. I love TUIs because they are more efficient than GUIs and easier than CLIs. GUI won? Notcurses (C++) and Rust bring many new TUIs.
But also?
I’ve seen Electron and from the first moment I wondered why it resembles Flash. With a built-in huge web browser. Eating resources and fitting nowhere. Same for touch screens in cars. And VR-Headsets…bruh…are that 3D-Shutter Glasses?!
Vice versa - I hope for lightweight AR-Glasses. But only with a standard VESA-Protocol or a BLE-Profile.
That being said. Wayland is good and it shall have replaced X11 years ago! It is made by the same people which maintain X11. Same applies to Systemd, implemented in C, unified interface and simple configs. Nothing is perfect and things need to mature. As usual :)
And? Tactile keyboards, switches and knobs are much better than touch screens. Mechanical keyboards are the counter reaction to bad input devices. I love TUIs because they are more efficient than GUIs and easier than CLIs. GUI won? Notcurses (C++) and Rust bring many new TUIs.
But also?
I’ve seen Electron and from the first moment I wondered why it resembles Flash. With a built-in huge web browser. Eating resources and fitting nowhere. Same for touch screens in cars. And VR-Headsets…bruh…are that 3D-Shutter Glasses?!
Vice versa - I hope for lightweight AR-Glasses. But only with a standard VESA-Protocol or a BLE-Profile.
What is good about Wayland? I only see a really idiotic, badly designed API and a very over-complicated ecosystem that requires lots of bloat, parallel infrastructure and duplicated effort to do even the simplest tasks due to lack of standardization of essential functionality.
Personally I can't wait until everybody comes to their senses and drops this pile of garbage API and goes back to X11.
Personally I can't wait until everybody comes to their senses and drops this pile of garbage API and goes back to X11.
What drives me up the wall is the number of apps they broke in the name of 'security' when the threat is not something most users will ever face. Even if they wanted to do that, they should have had a popup display asking the user for permission, and not simply breaking it.
Also, say what you will about Xorg, but it's very much 'batteries included', the idea of wayland foisting so much of what used to be X's responsibilities off to the wm just reeks of 'ivory tower'ness.
Also, say what you will about Xorg, but it's very much 'batteries included', the idea of wayland foisting so much of what used to be X's responsibilities off to the wm just reeks of 'ivory tower'ness.
The problem is that with a shared X11, sandboxing is pointless.
Any application with access to the X11 socket has easy privilege escalation available to it. By for example, injecting into a sudo enabled terminal or keylogging the user.
Admittedly, with Wayland the security situation wasn't ideal until recently with the adoption of security contexts that can finally allow you to deny screen capture access among other Wayland protocols to sandboxed applications[1].
[1] <https://git.sr.ht/~whynothugo/way-secure>
Any application with access to the X11 socket has easy privilege escalation available to it. By for example, injecting into a sudo enabled terminal or keylogging the user.
Admittedly, with Wayland the security situation wasn't ideal until recently with the adoption of security contexts that can finally allow you to deny screen capture access among other Wayland protocols to sandboxed applications[1].
[1] <https://git.sr.ht/~whynothugo/way-secure>
So like nearly every other X11 user, my X11 server is not exposed to the network at all. Not the internet, and not my LAN. It's the default; you have to do work to make it insecure. I don't hot-desk, and I use SSH to talk to the machines on my network that don't need a GUI. Wayland solves a problem that I've never had.
I don't believe I'm an outlier. I believe most Linux users are like me: they are conscious of security issues, and they don't need a nanny to look after them. I don't think that the majority of Linux users are hot-desking corporate users, with multiple user sessions on the same machine, or trying to run a GUI over a network connection. Those are eccentric use-cases.
Red Hat/Gnome are trying to make a version of Linux that can be used by a child. I think that's a fine objective; but it's not even on the horizon. An operating system that just gets out of your way would be lovely, but for now it's a dream (and Windows isn't that system, of course; I think managing a Linux system is miles easier than trying to manage Windows).
As far as Gnome is concerned, it's experienced at least two violent changes of direction in its history. One of the things you need from a child-friendly OS is no violent changes of direction. If a GUI in particular changes dramatically from one version to the next, that's a big fail.
I don't believe I'm an outlier. I believe most Linux users are like me: they are conscious of security issues, and they don't need a nanny to look after them. I don't think that the majority of Linux users are hot-desking corporate users, with multiple user sessions on the same machine, or trying to run a GUI over a network connection. Those are eccentric use-cases.
Red Hat/Gnome are trying to make a version of Linux that can be used by a child. I think that's a fine objective; but it's not even on the horizon. An operating system that just gets out of your way would be lovely, but for now it's a dream (and Windows isn't that system, of course; I think managing a Linux system is miles easier than trying to manage Windows).
As far as Gnome is concerned, it's experienced at least two violent changes of direction in its history. One of the things you need from a child-friendly OS is no violent changes of direction. If a GUI in particular changes dramatically from one version to the next, that's a big fail.
> So like nearly every other X11 user, my X11 server is not exposed to the network at all.
Are you misunderstanding what the OP meant by "socket"? It doesn't have to literally be a network socket, but your X11 apps all connect to the server via some IPC mechanism, could be a network socket or a local named pipe (I think it lives out in /var/, but I'm not on a Linux system atm). Their point was there is no client authentication or separation via this IPC mechanism: one X11 application can send messages directly to another X11 application. That's where their example of a malicious app inserting text into a sudo terminal comes from. You can see this for yourself using a virtual keyboard program. It's just an X11 app like any other, it's just injecting messages for the server to dispatch to another client.
> I believe most Linux users are like me: they are conscious of security issues, and they don't need a nanny to look after them.
I feel under this argument, you can also describe memory segmentation as a "nanny" =/ I don't think many would argue we should go back to shared memory systems.
Are you misunderstanding what the OP meant by "socket"? It doesn't have to literally be a network socket, but your X11 apps all connect to the server via some IPC mechanism, could be a network socket or a local named pipe (I think it lives out in /var/, but I'm not on a Linux system atm). Their point was there is no client authentication or separation via this IPC mechanism: one X11 application can send messages directly to another X11 application. That's where their example of a malicious app inserting text into a sudo terminal comes from. You can see this for yourself using a virtual keyboard program. It's just an X11 app like any other, it's just injecting messages for the server to dispatch to another client.
> I believe most Linux users are like me: they are conscious of security issues, and they don't need a nanny to look after them.
I feel under this argument, you can also describe memory segmentation as a "nanny" =/ I don't think many would argue we should go back to shared memory systems.
> one X11 application can send messages directly to another X11 application.
Sure. I get that. But I don't run malicious applications on X; and I don't pipe the output of curl into bash.
> I don't think many would argue we should go back to shared memory systems.
Me neither. But from my perspective, memory segmentation is necessary to protect me against incompetent programmers, not malicious applications. Breaking X11 security isn't something that happens by accident, it requires actual malice.
Sure. I get that. But I don't run malicious applications on X; and I don't pipe the output of curl into bash.
> I don't think many would argue we should go back to shared memory systems.
Me neither. But from my perspective, memory segmentation is necessary to protect me against incompetent programmers, not malicious applications. Breaking X11 security isn't something that happens by accident, it requires actual malice.
> But I don't run malicious applications on X
The thing about malicious applications is that they usually don't do a lot to inform the user that they are a malicious application. "I don't run malicious applications" is a claim shared by nearly everyone who's ever run a malicious application.
The thing about malicious applications is that they usually don't do a lot to inform the user that they are a malicious application. "I don't run malicious applications" is a claim shared by nearly everyone who's ever run a malicious application.
I've never been mugged, probably because I don't hang out around shady characters at night.
Back in the 80s, I got viruses and trojans, because (a) I was promiscuous with floppy disks, and (b) I worked with students. And I installed software from shady places that came with unwanted stuff like browser toolbars.
Nowadays, I use Linux, and I find I can rely on the distro's package repository. So I only install software from the repository; if I need to try something that isn't packaged by the distro, I proceed with extreme caution.
I'm sure it's different if you're running a corporate Linux desktop fleet; but this is a home network, with one laptop that runs any GUI at all. The laptop exposes no network ports. In fact the entire home network exposes no internet ports.
I think Red Hat would be fine, if they'd stick to serving corporate requirements. I just wish they'd stop shoving stuff down the throats of non-corporate users. I'm particularly annoyed by systemd; Poettering is a specialist in throat-shoving.
Unfortunately, I don't seem to be able to get Bluetooth Audio to work on Linux without pulseaudio. I have a pair of nice Bose cans that I can't use, because I don't want to run pulse. I need a bluetooth audio stack that depends only on ALSA. (I think it's possible, but every time I try I run into a brick wall, and I've got tired)
Back in the 80s, I got viruses and trojans, because (a) I was promiscuous with floppy disks, and (b) I worked with students. And I installed software from shady places that came with unwanted stuff like browser toolbars.
Nowadays, I use Linux, and I find I can rely on the distro's package repository. So I only install software from the repository; if I need to try something that isn't packaged by the distro, I proceed with extreme caution.
I'm sure it's different if you're running a corporate Linux desktop fleet; but this is a home network, with one laptop that runs any GUI at all. The laptop exposes no network ports. In fact the entire home network exposes no internet ports.
I think Red Hat would be fine, if they'd stick to serving corporate requirements. I just wish they'd stop shoving stuff down the throats of non-corporate users. I'm particularly annoyed by systemd; Poettering is a specialist in throat-shoving.
Unfortunately, I don't seem to be able to get Bluetooth Audio to work on Linux without pulseaudio. I have a pair of nice Bose cans that I can't use, because I don't want to run pulse. I need a bluetooth audio stack that depends only on ALSA. (I think it's possible, but every time I try I run into a brick wall, and I've got tired)
> I've never been mugged, probably because I don't hang out around shady characters at night.
People frequently get mugged in broad daylight in 'safe' areas.
Malicious applications can come in trustworthy looking packages. Just look at the amount of malicious applications that have been found in python libraries recently, none of which you would have installed or used directly.
X is insecure and your habits maybe have been enough to protect you so far, but banking on them always doing so in the future is kind of silly.
People frequently get mugged in broad daylight in 'safe' areas.
Malicious applications can come in trustworthy looking packages. Just look at the amount of malicious applications that have been found in python libraries recently, none of which you would have installed or used directly.
X is insecure and your habits maybe have been enough to protect you so far, but banking on them always doing so in the future is kind of silly.
This is such an elitist take of the situation.
One person may not be gullible enough to unintentionally run a malicious application, but once you extend it to a group of people, the claim will likely no longer be true. What if your coworker(s) accidentally ran a rogue X11 application, their passwords got keylogged, and now your company systems are compromised?
And the above paragraph only operates under the assumption that you, the one person, is perfect, who never makes mistakes, never runs malicious applications, and runs on a distro that is never compromised, providing programs developed by people who are security-minded.
You might have been compromised never knowing it.
On the other hand, the other day when I shared my screen on Firefox, my Wayland compositor (indirectly through xdg-desktop-portal) asked me to confirm that it was my intention to let the browser see my desktop. I felt that was pretty nifty.
One person may not be gullible enough to unintentionally run a malicious application, but once you extend it to a group of people, the claim will likely no longer be true. What if your coworker(s) accidentally ran a rogue X11 application, their passwords got keylogged, and now your company systems are compromised?
And the above paragraph only operates under the assumption that you, the one person, is perfect, who never makes mistakes, never runs malicious applications, and runs on a distro that is never compromised, providing programs developed by people who are security-minded.
You might have been compromised never knowing it.
On the other hand, the other day when I shared my screen on Firefox, my Wayland compositor (indirectly through xdg-desktop-portal) asked me to confirm that it was my intention to let the browser see my desktop. I felt that was pretty nifty.
> one X11 application can send messages directly to another X11 application. That's where their example of a malicious app inserting text into a sudo terminal comes from.
If I'm running a malicious application, I have much bigger worries than a an injected sudo. It has access to all my files!
> I feel under this argument, you can also describe memory segmentation as a "nanny" =/ I don't think many would argue we should go back to shared memory systems.
On my desktop I use memory segmentation to protect against programming errors, not for security.
If I'm running a malicious application, I have much bigger worries than a an injected sudo. It has access to all my files!
> I feel under this argument, you can also describe memory segmentation as a "nanny" =/ I don't think many would argue we should go back to shared memory systems.
On my desktop I use memory segmentation to protect against programming errors, not for security.
> If I'm running a malicious application, I have much bigger worries than a an injected sudo. It has access to all my files!
If you practice sandbox hygiene on linux (eg. bubblewrap) the only files it will have access to are the ones absolutely necessary for its functioning such as a private /home/user per application. However if you use X11, all such measures will be useless.
You could of course run nested X11 (eg. Xephyr). But the inconvenience is of such magnitude why not use Wayland?
If you practice sandbox hygiene on linux (eg. bubblewrap) the only files it will have access to are the ones absolutely necessary for its functioning such as a private /home/user per application. However if you use X11, all such measures will be useless.
You could of course run nested X11 (eg. Xephyr). But the inconvenience is of such magnitude why not use Wayland?
And then a website triggers an exploit in your firefox process and gains remote code execution. Okay, firefox uses sandboxing so even with code execution the attacker won't gain much. Except that sandboxed process has a unix-socket connection open to a certain other process...
Yeah, I get it. You make a good point. A website might target a Linux desktop user in the way you describe, and that is a serious weakness in X11.
But this is a rather exotic scenario: the attacker uses an exploit that works on the Linux version of a browser, and uses that to attack some other application running under X11. That's a complicated chain of dependencies; it might be worth it if I was operating a bank of Uranium centrifuges, but not just to violate my privacy (e.g. steal passwords from my password manager).
I think Wayland is a fine project, and when it's mature I'll jump. I'd prefer a local-only GUI. But I don't think it's mature yet. And the way it's pushed reminds me of Poetteringware; I need to be sure I'm not being shafted.
But this is a rather exotic scenario: the attacker uses an exploit that works on the Linux version of a browser, and uses that to attack some other application running under X11. That's a complicated chain of dependencies; it might be worth it if I was operating a bank of Uranium centrifuges, but not just to violate my privacy (e.g. steal passwords from my password manager).
I think Wayland is a fine project, and when it's mature I'll jump. I'd prefer a local-only GUI. But I don't think it's mature yet. And the way it's pushed reminds me of Poetteringware; I need to be sure I'm not being shafted.
> The problem is that with a shared X11, sandboxing is pointless.
You're not hearing me. For most desktop users, there was never a need to sandbox applications. It's simply not a threat vector 99% of desktop linux users have ever dealt with. It's certainly not a big enough problem to break the screen / input recording and sharing of tons of applications. Again, if you need to do that, the correct way is to PROMPT the user, not invisibly disable it entirely.
You're not hearing me. For most desktop users, there was never a need to sandbox applications. It's simply not a threat vector 99% of desktop linux users have ever dealt with. It's certainly not a big enough problem to break the screen / input recording and sharing of tons of applications. Again, if you need to do that, the correct way is to PROMPT the user, not invisibly disable it entirely.
You’re saying Linux users never make mistakes like clicking on the wrong link or opening the wrong attachment? Unless that’s true, yes, we need sandboxing.
[deleted]
Sandboxing would be nice, but very little gets sandboxed right now, so it's hard to classify it as a real need.
And the sandboxes that do get used aren't very vulnerable to X11 attacks. If you're running firefox the web process sandbox doesn't have X11 access, and by the time the rendering process gets chain-exploited it can access your files directly without needing to go through X11.
And the sandboxes that do get used aren't very vulnerable to X11 attacks. If you're running firefox the web process sandbox doesn't have X11 access, and by the time the rendering process gets chain-exploited it can access your files directly without needing to go through X11.
Arguing that we shouldn’t deploy sandboxing because it’s not widely used seems counterproductive, and a recipe for not catching up with macOS or even Windows.
Even if Firefox is perfect, that still leaves everything else which connects to the outside world or opens downloaded files. We know there’s a long history of those exploits and everyone serious in the desktop OS space has been trying to harden things so it’s not a single mistake away from an irrecoverable compromise.
Even if Firefox is perfect, that still leaves everything else which connects to the outside world or opens downloaded files. We know there’s a long history of those exploits and everyone serious in the desktop OS space has been trying to harden things so it’s not a single mistake away from an irrecoverable compromise.
Nobody said we shouldn't, it's a matter of whether this particular attack vector is worth so much trouble to prevent.
Security needs to allow usability or the whole system fails.
Security needs to allow usability or the whole system fails.
Preventing any compromise of an X11 app from being easily escalated seems useful, and there's no usability hit for users. Developers have to update code designed in the 1990s – which I should note most of us griped about even back then – but that's not especially onerous and has multiple other benefits.
AFAIK Wayland does not provide screen capture though. It is provided outside of it via xdg-desktop-portal[1].
[1] https://flatpak.github.io/xdg-desktop-portal/docs/portal-int...
[1] https://flatpak.github.io/xdg-desktop-portal/docs/portal-int...
wlroots-based compositors had screen capture for a long time. I'm not sure about Gnome.
<https://wayland.app/protocols/wlr-screencopy-unstable-v1>
<https://sr.ht/~emersion/grim/>
<https://github.com/ammen99/wf-recorder>
<https://wayland.app/protocols/wlr-screencopy-unstable-v1>
<https://sr.ht/~emersion/grim/>
<https://github.com/ammen99/wf-recorder>
The X11 Security extension is nearly 30 years old at this point, but Wayland users still haven't heard of it. One wonders what else they're missing out on.
I've wondered about this for a while - why didn't XACE get wide adoption?
From what I can find XACE doesn't actually work all that well. e.g. [1] mentions "X Applications expect full access to X server and die when denied any access".
It's rather vague and kind of hard to find more detailed information.
I also agree with the sibling comment from tedunangst that most people just don't worry all that much about keyloggers, nor should they IMHO because it's not really a common attack vector.
[1]: https://fedorapeople.org/~dwalsh/SELinux/Presentations/sandb...
It's rather vague and kind of hard to find more detailed information.
I also agree with the sibling comment from tedunangst that most people just don't worry all that much about keyloggers, nor should they IMHO because it's not really a common attack vector.
[1]: https://fedorapeople.org/~dwalsh/SELinux/Presentations/sandb...
Because nobody actually cares about keyloggers. They just like how it feels to say "Wayland is secure". Anybody who cared about key loggers or screen scrapers or any of that solved their problem two decades ago.
Yes and then HN'lers will shame any distro enabling it by default to death.
Popup asking?
Sounds exactly like what Flatpak/Portals are doing.
Batteries included? That is the reason why X11 is/was shipped alongside Wayland for some time. It will be dropped and XWayland remains for compatibility reasons. And Wayland has already some batteries X11 doesn’t, better scaling support. Security through Portals/Flatpak. We’re in 2023, screensharing works for some time now ;)
We don’t get stuck in legacy hell like Windows. And we don’t cut off compatibility like Apple. Bumpy ride but prospects are good.
Next thing? A new virtual console for userspace? Something like KMSCON? https://en.wikipedia.org/wiki/Kmscon
I don’t want delete the good old thing. I want see them alive and improving :). Without the usual “it must become worse before it becomes better”.
Batteries included? That is the reason why X11 is/was shipped alongside Wayland for some time. It will be dropped and XWayland remains for compatibility reasons. And Wayland has already some batteries X11 doesn’t, better scaling support. Security through Portals/Flatpak. We’re in 2023, screensharing works for some time now ;)
We don’t get stuck in legacy hell like Windows. And we don’t cut off compatibility like Apple. Bumpy ride but prospects are good.
Next thing? A new virtual console for userspace? Something like KMSCON? https://en.wikipedia.org/wiki/Kmscon
I don’t want delete the good old thing. I want see them alive and improving :). Without the usual “it must become worse before it becomes better”.
> We don’t get stuck in legacy hell like Windows.
legacy hell hasn't been a thing for a long time, and flatpack basically uses the same solution Windows does - numerous redundant different versions of older libraries.
> And we don’t cut off compatibility like Apple
Without Flatpack or similar, Linux is honestly pretty terrible as far as backwards compatibility goes.
legacy hell hasn't been a thing for a long time, and flatpack basically uses the same solution Windows does - numerous redundant different versions of older libraries.
> And we don’t cut off compatibility like Apple
Without Flatpack or similar, Linux is honestly pretty terrible as far as backwards compatibility goes.
IIRC any time I've used a flatpak app, it's downloaded tons of dependencies along with it because everything is sandboxed. I know disk space is cheap but it's kind of silly to me that the flatpak version of an app is 500mb while the deb version is ~ 5mb.
That 500MB almost entirely the runtime, which is shared across apps.
Yep. It settles down as soon as you have more Flatpaks installed.
But yes. Flatpaks require more memory and disk space and fixes in private libraries are not fixed by a friendly package maintainer for all packages. I use native packages from Arch for most stuff and for new hot or weird stuff Flatpak. Especially for Closed-Source weird stuff.
I prefer most - if not all - handle by native packages because that is a core feature of Linux. But there will be always others for reasons. For example plugins, Vim relies here mostly on Vimplug. Steam is thing I need to accept but itself a candidate for Flatpak (currently I prefer the native package). And to be precisely, Meson is also a package-manager for C/C++ developers.
PS: I also use Flatpaks when otherwise many unusual dependencies are involved. That one application using Qt? Flatpak. And vice versa some applications which doing well move from Flatpak to native package (Marker did that).
PPS: GNOME-Software does a good job in handling native packages, Flatpak and LVFS at the same time. I use mostly pacman, flatpak and fwupd. But sometimes I need the captains approach “Linux. Make it so.”.
But yes. Flatpaks require more memory and disk space and fixes in private libraries are not fixed by a friendly package maintainer for all packages. I use native packages from Arch for most stuff and for new hot or weird stuff Flatpak. Especially for Closed-Source weird stuff.
I prefer most - if not all - handle by native packages because that is a core feature of Linux. But there will be always others for reasons. For example plugins, Vim relies here mostly on Vimplug. Steam is thing I need to accept but itself a candidate for Flatpak (currently I prefer the native package). And to be precisely, Meson is also a package-manager for C/C++ developers.
PS: I also use Flatpaks when otherwise many unusual dependencies are involved. That one application using Qt? Flatpak. And vice versa some applications which doing well move from Flatpak to native package (Marker did that).
PPS: GNOME-Software does a good job in handling native packages, Flatpak and LVFS at the same time. I use mostly pacman, flatpak and fwupd. But sometimes I need the captains approach “Linux. Make it so.”.
Wayland sucks. At least for Nvidia users.
RN dealing with -
1- when it comes back from suspend, the whole screen is filled with Rainbows. Pretty, but useless. 2- display scaling setting is either ignored or completely broken, no in between. Display settings in general seem wonky.
If I pretend these two things don't exist, the smoothness during gaming is far superior though..
RN dealing with -
1- when it comes back from suspend, the whole screen is filled with Rainbows. Pretty, but useless. 2- display scaling setting is either ignored or completely broken, no in between. Display settings in general seem wonky.
If I pretend these two things don't exist, the smoothness during gaming is far superior though..
I am not bullish on Wayland but it's not Wayland's fault that nVidia is abnormally uncooperative with the open source community.
I lurk on several Linux enthusiast forums and subreddits and whenever a new person wanders in asking why they get a blank screen on boot, or their laptop can't resume properly, or their desktop crashes randomly, I have observed that there is a roughly 0.95 chance they have an nVidia card in their system. (With or without the proprietary drivers.)
I lurk on several Linux enthusiast forums and subreddits and whenever a new person wanders in asking why they get a blank screen on boot, or their laptop can't resume properly, or their desktop crashes randomly, I have observed that there is a roughly 0.95 chance they have an nVidia card in their system. (With or without the proprietary drivers.)
Why does it work perfectly on X11, then?
Nothing works perfectly on X11.
WTF is this revisionism. There’s a reason nearly everyone in the Linux community has been trying to create an X11 alternative.
Because X11 is really terrible at doing many things.
Sure Wayland doesn’t do everything X11 does. Yet. It’s also decades younger and doesn’t have decades worth of patches and workarounds making things work.
Finally Wayland does things that X11 simply cannot do, and unlike Wayland where some of the things it “cannot” (more often chooses not to by design) do can be offloaded to other parts of the system, the same is not true of X11.
WTF is this revisionism. There’s a reason nearly everyone in the Linux community has been trying to create an X11 alternative.
Because X11 is really terrible at doing many things.
Sure Wayland doesn’t do everything X11 does. Yet. It’s also decades younger and doesn’t have decades worth of patches and workarounds making things work.
Finally Wayland does things that X11 simply cannot do, and unlike Wayland where some of the things it “cannot” (more often chooses not to by design) do can be offloaded to other parts of the system, the same is not true of X11.
> There’s a reason nearly everyone in the Linux community has been trying to create an X11 alternative.
Maybe because the developers themselves have deprecated it? That would be freedesktop.org.
I think an X11 alternative would be a Good Thing. In the future, that might well be Wayland, I suppose. But I don't trust freedesktop.org; I have learned to expect them to play compatibility games in order to achieve hegemony. The main reason I use Linux is to avoid hegemonic overlords.
Maybe because the developers themselves have deprecated it? That would be freedesktop.org.
I think an X11 alternative would be a Good Thing. In the future, that might well be Wayland, I suppose. But I don't trust freedesktop.org; I have learned to expect them to play compatibility games in order to achieve hegemony. The main reason I use Linux is to avoid hegemonic overlords.
>Nothing works perfectly on X11
Agreed. "Perfect" is a stretch. What I'm saying, though, is that on an NVidia card, I can actually run a graphical system with X11. It has screen tearing and freaks out when my monitors aren't framerate matched, but it runs.
Wayland crashes on startup. Every time. I've tried every setting, every environment variable, every kernel parameter, and it doesn't work at all. And when I roll up my sleeves and dig deep on forums/github issues, the answer I get is basically "Yeah, this is broken. Blame NVidia."
X11 isn't under active development. That's not a good situation. However, I don't think the alternative is very compelling when their response to a super common system configuration being totally broken is "not my problem. shoulda bought AMD."
>Sure Wayland doesn’t do everything X11 does. Yet. It’s also decades younger and doesn’t have decades worth of patches and workarounds making things work.
It's over a decade old. The remaining blindspots as far as X11 backwards compatibility should be super niche things. Not "using NVidia."
Agreed. "Perfect" is a stretch. What I'm saying, though, is that on an NVidia card, I can actually run a graphical system with X11. It has screen tearing and freaks out when my monitors aren't framerate matched, but it runs.
Wayland crashes on startup. Every time. I've tried every setting, every environment variable, every kernel parameter, and it doesn't work at all. And when I roll up my sleeves and dig deep on forums/github issues, the answer I get is basically "Yeah, this is broken. Blame NVidia."
X11 isn't under active development. That's not a good situation. However, I don't think the alternative is very compelling when their response to a super common system configuration being totally broken is "not my problem. shoulda bought AMD."
>Sure Wayland doesn’t do everything X11 does. Yet. It’s also decades younger and doesn’t have decades worth of patches and workarounds making things work.
It's over a decade old. The remaining blindspots as far as X11 backwards compatibility should be super niche things. Not "using NVidia."
That reasoning is flawed. I could easily counter it with similar flawed reasoning: My AMD cards works (without proprietary kernel modules) flawlessly wit Wayland. I can play Cyberpunk out of the box.
Because Nvidia, until recently, refused to use the driver model (GBM) that everyone else adopted because they wanted to force everyone to use EGLStreams, which was their choice of API.
At the time EGLStream was an open standard where GBM was a proprietary API tightly coupled to Mesa. Extra work had to be done in Mesa in order to let Nvidia write a backend for it. Nvidia released such a backend over 2 years ago.
Because nVidia supports X11 and other old APIs but not newer ones.
Wayland does not define AFAICT new APIs that a driver needs to support, but it does use the newer ones that nVidia never bothered to support.
Wayland does not define AFAICT new APIs that a driver needs to support, but it does use the newer ones that nVidia never bothered to support.
> If I pretend these two things don't exist, the smoothness during gaming is far superior though..
Really? I find Wayland way worse for gaming. Like there's a few extra frames of delay or something. It _really_ messes with me and I can't stand it. It's why I'm still on X11 for now.
Really? I find Wayland way worse for gaming. Like there's a few extra frames of delay or something. It _really_ messes with me and I can't stand it. It's why I'm still on X11 for now.
That's really weird... I play Rocket League on 144 frames and X is far more janky.. while Wayland keeps a very smooth 144 99% of the time, and input delay feels non existent but on X it feels like 2-3 frames behind.
Did you mean seconds? 2-3 frames on 144 FPS would be roughly 17 ms which I think is too short for a human to notice.
Also, did you enable VSync on both the tests? And the same form of VSync? That can have an impact on input lag.
Also, did you enable VSync on both the tests? And the same form of VSync? That can have an impact on input lag.
I can notice audio and video being 50ms out of sync. Surely when interacting one could do better.
edit: I recall reading about timing experiments. IIRC good participants could get down to 10ms accuracy when trying to time moving their finger to a signal.
edit: I recall reading about timing experiments. IIRC good participants could get down to 10ms accuracy when trying to time moving their finger to a signal.
Ah, I think I was confusing the human notice time (is that a thing?) with the human reaction time. Thanks for correcting.
Yes reaction time is around 100-150ms. The experiment I read about was specifically about testing the accuracy of planned motion, which as mentioned was way better.
hmm... It was fairly un scientific.. I will try VSync and report back. I would prefer to use X tbh, because of these bugs. It's certainly not seconds behind, but yea, maybe more like 50-100ms instead of 17.
On NixOS/KDE/Wayland with my 3070 ti, my gaming experience is admittedly excellent. Disabling V-Sync ingame, I get the same latency I did on x11, same performance, with much better frame pacing and VRR support. Strictly comparing across protocols, Wayland is what I prefer to game on. YMMV.
Nvidia's drivers are flaky and deserve their own condemnation, but that's a problem no matter what you use. You won't escape Nvidia's enormous firmware files and driver jank even if you run your machine headless.
Nvidia's drivers are flaky and deserve their own condemnation, but that's a problem no matter what you use. You won't escape Nvidia's enormous firmware files and driver jank even if you run your machine headless.
It has really low latency on Steam Deck OLED, so it seems not to be fault of protocol, but either your HW or compositor.
Steam deck is AMD, not Nvidia. I was surprised that the parent had good performance in games with Nvidia+Wayland.
Edit: I did a quick Google search, and your comment is dishonest. Many people are complaining about input lag on the steam deck. They've even measured it [0]
[0] https://www.reddit.com/r/SteamDeck/comments/11yuulz/input_la...
Edit: I did a quick Google search, and your comment is dishonest. Many people are complaining about input lag on the steam deck. They've even measured it [0]
[0] https://www.reddit.com/r/SteamDeck/comments/11yuulz/input_la...
I specifically said OLED, yes the LED model is not so great. The improvement across board is described eg. here https://www.eurogamer.net/digitalfoundry-2023-steam-deck-ole...
Yeah, look at the input lag in your link. If you enable the frame limit it goes to shit. It's unclear to me if this is Wayland's fault or Valves fault or a mixture of both. The new version doesn't fix the issue, it just reduces latency somewhere else so all the latencies go down.
More like "Nvidia sucks. That includes Wayland users."
I can't deny that, but the fact is, X still works fine.. and a lot of people use NVIDIA cards and don't want to throw them away. I guess they are the real culprit though, to be sure.
But if were a random new user who booted into Wayland-only new fedora only to find my installation is already borked... what are we supposed to tell them? Oh yea, Linux is only for AMD users.. sorry!
But if were a random new user who booted into Wayland-only new fedora only to find my installation is already borked... what are we supposed to tell them? Oh yea, Linux is only for AMD users.. sorry!
[deleted]
Even worse for me, I have a hybrid laptop with integrated amd-gpu and a dedicated nvidia, and there is no way to specify primary gpu on Wayland. Everything goes through integrated and nvidia card just sits at 0%.
You can delay it forever until nobody maintains X11 anymore, or the ones who join/remain start breaking things there too. X11R6 is about 30 years old now. I think that's enough time for them to demand a rewrite.
To everyone who is sceptical about Wayland, give it a try now I've been daily driving it for the past 2.5 years. If you've used it more than 6 months ago give it a try it's changing and it's changing fast
FWIW, that is not an endorsement from my perspective. I don't want my windowing stuff to change significantly in 6 months. Let me know when it settles down.
I gave it a try. It's shit!
Worse latency and performance (on intel and AMD), xdotools don't work, window managers don't work. Doesn't work without dbus (the first thing I usually uninstall) and additional seat/login daemons which indicates its bad design.
Worse latency and performance (on intel and AMD), xdotools don't work, window managers don't work. Doesn't work without dbus (the first thing I usually uninstall) and additional seat/login daemons which indicates its bad design.
I’ve also been using it for, I think, 2 years now. While it has fewer issues in my experience, they’ve also destroyed features for nebulous security benefits. I’ve wasted quite a lot of time trying to get things to work on Wayland that just worked on X11.
You could wait a century and compositing would still suck.
Related discussion from 1 month ago:
https://news.ycombinator.com/item?id=38281264
Firefox Is Going to Try and Ship with Wayland Enabled by Default (phoronix.com) 151 comments
Previous discussion:
https://news.ycombinator.com/item?id=38488850 17 days ago, 6 comments (mozilla.org)
https://news.ycombinator.com/item?id=38281264
Firefox Is Going to Try and Ship with Wayland Enabled by Default (phoronix.com) 151 comments
Previous discussion:
https://news.ycombinator.com/item?id=38488850 17 days ago, 6 comments (mozilla.org)
I want to move to the "future", but I use several firefox profiles via xpra in combination with xdotool based hotkeys. The fluidity with which I can control my different profile windows without a mouse and with which I can switch between computers with no lag with this setup is a big reason why I have stuck with a Linux desktop, so I am sad to see those super powers go away for no perceived benefit. I have tried Wayland several times now and don't notice any performance differences, just more bugs in Wayland.
`xdotool search` seems like it has been deemed a security issue for reasons I can't understand (if someone has hacked in to the point that they can even run such query commands, surely I'm already pwn'd). Maybe I'm oversimplifying it, but to me it's like being upset that someone who broke into your house can see the color of your curtains. The powerful feature set of X far outweighs these minor security concerns.
And it looks like xpra is facing huge issues switching over https://github.com/Xpra-org/xpra/issues/387 :(, I have yet to be as satisfied with any other free remote desktop software (paid nomachine is close but less scriptable).
I hope these aren't fundamental limitations of wayland, but the challenges seem steep.
`xdotool search` seems like it has been deemed a security issue for reasons I can't understand (if someone has hacked in to the point that they can even run such query commands, surely I'm already pwn'd). Maybe I'm oversimplifying it, but to me it's like being upset that someone who broke into your house can see the color of your curtains. The powerful feature set of X far outweighs these minor security concerns.
And it looks like xpra is facing huge issues switching over https://github.com/Xpra-org/xpra/issues/387 :(, I have yet to be as satisfied with any other free remote desktop software (paid nomachine is close but less scriptable).
I hope these aren't fundamental limitations of wayland, but the challenges seem steep.
>if someone has hacked in to the point that they can even run such query commands, surely I'm already pwn'd
Achieving RCE in a single program meaning your entire system is pwned is behind the times compared other operating systems. In order to make freedesktop's security competitive again security restrictions need to be added.
Achieving RCE in a single program meaning your entire system is pwned is behind the times compared other operating systems. In order to make freedesktop's security competitive again security restrictions need to be added.
> if someone has hacked in to the point that they can even run such query commands, surely I'm already pwn'd
I believe the idea is that by adding security measures in the graphical server, you can limit it better. So yes, if there's no other protections then the graphical server is the least of your problems, but if you run a program in a container then the graphical server becomes the weakest link so we'd like to protect it. (I don't know why other protections - https://wiki.archlinux.org/title/Firejail#Firejail_with_Xorg or XACE - weren't good enough, but there is an argument for something there)
I believe the idea is that by adding security measures in the graphical server, you can limit it better. So yes, if there's no other protections then the graphical server is the least of your problems, but if you run a program in a container then the graphical server becomes the weakest link so we'd like to protect it. (I don't know why other protections - https://wiki.archlinux.org/title/Firejail#Firejail_with_Xorg or XACE - weren't good enough, but there is an argument for something there)
Am I right in thinking this title is non-sensical? From my understanding of the article, "Firefox 121 ships with native Wayland support" would work better.
Firefox can't "default" to anything because it has to run atop whatever display server I'm running. I guess you could say it "defaults to Wayland" instead of XWayland, but I can't see that being the common interpretation.
Firefox can't "default" to anything because it has to run atop whatever display server I'm running. I guess you could say it "defaults to Wayland" instead of XWayland, but I can't see that being the common interpretation.
It already shipped with native wayland support; the only "change" is that you no longer have to set an env var (MOZ_ENABLE_WAYLAND=1) to get native Wayland instead of XWayland. Maybe "defaults to native Wayland" is the "most" correct way of saying it, but that's a bit more editorial with respect to the article's actual title.
I think the title is pretty reasonable. When given the choice between Wayland and X (because both are available, typically this is a Wayland + XWayland config) Firefox will now pick Wayland instead of X by default.
Of course if only X is available (or only Wayland) it will continue to use what is available.
I think "Firefox now prefers Wayland over X" may have been a bit more accurate, but that also has other possible interpretations.
Of course if only X is available (or only Wayland) it will continue to use what is available.
I think "Firefox now prefers Wayland over X" may have been a bit more accurate, but that also has other possible interpretations.
Meanwhile, Chromium Wayland is still broken for me on two PCs, as it has been for over a year in spite of my best efforts to troubleshoot, due to some bad interaction with the Nvidia driver. GPU acceleration doesn't work, and there are some other possibly related issues like copy paste locking up the browser and crashing the browser.
Firefox is kind of flakey on Nvidia wayland too. Sometimes it just refuses to launch, but it mostly does work with GPU acceleration if it manages to launch.
I should mention that every bug, and dozens more, immediately disappears if I disable the Nvidia driver completely and just run off my AMD IGP.
Firefox is kind of flakey on Nvidia wayland too. Sometimes it just refuses to launch, but it mostly does work with GPU acceleration if it manages to launch.
I should mention that every bug, and dozens more, immediately disappears if I disable the Nvidia driver completely and just run off my AMD IGP.
The Sway flag to allow running on an NVIDIA GPU used to be `--i-wont-buy-an-nvidia-gpu-again` or something like that. I took it to heart and couldn't be happier with my AMD dGPU. What boggles the mind is the sheer number of laptops that claim to be Linux laptops, while shipping with NVIDIA dGPUs.
Yes, it used to be `--my-next-gpu-wont-be-nvidia`. Nowadays it's the much tamer `--unsupported-gpu`
I don't care for Wayland because I don't care for the FreeDesktop people, Red Hat or IBM. It's also horribly bloated, x.org runs comfortably on very very little hardware, Wayland is an incredible resource hog by comparison.
I hope soon, the FreeDesktop people will formally stop "supporting" X.org so some other, more interested party can finally take control. FreeDesktop's charter promises that they will extend X.org, not abandon it OR replace it, so if you've given donations to them (as my organization has) you should feel a little ripped off.
I hope soon, the FreeDesktop people will formally stop "supporting" X.org so some other, more interested party can finally take control. FreeDesktop's charter promises that they will extend X.org, not abandon it OR replace it, so if you've given donations to them (as my organization has) you should feel a little ripped off.
> x.org runs comfortably on very very little hardware, Wayland is an incredible resource hog by comparison.
Citation needed.
Citation needed.
Nope, no citation needed. It's just the truth.
I got 1~2 hours of additional battery life on Wayland. Unless we have a very different definition of "truth" or "an incredible resource hog", then indeed citation is needed.
Since you are the first in this comment chain to assert that Wayland is bloated, perhaps you should also be the first to provide evidences to support your assertion too.
Since you are the first in this comment chain to assert that Wayland is bloated, perhaps you should also be the first to provide evidences to support your assertion too.
>I got 1~2 hours of additional battery life on Wayland.
Proof needed.
Proof needed.
I wonder, does Wayland requires to allocate gigantic buffers for every window or it is possible to make a Wayland implementation that doesn't require tens of megabytes of RAM? For example, is it possible to render window by tiles (of course only changed tiles) using a small 200×200 buffer? Is it possible to use a single buffer for all applications (which they use in turn)?
All modern composited desktops have buffers per app, even on X11.
But isn't this super expensive, especially when there are many windows and 4K resolution displays? I don't like that you need 10 buffers for 10 full-screen windows when you see only the topmost one.
Say you have a dozen of full screen windows. That’s 3840 × 2160 × 3 bytes per window or 24MB, so our dozen windows take just shy of 300MB uncompressed. That’s not nothing, but it’s also a small fraction of the RAM on even a phone for one of the primary functions of the device, and the upside is that you avoid all kinds of nasty challenges coordinating updates and access between applications and the window server because there’s no shared state between applications and the window manager can do things like transparency, scaling, or all-windows switching views without any app involvement.
Another way of looking at this, Apple did the same move over a decade ago with far more limited hardware and pretty much everyone loved it because the speed and stability boost was quite noticeable.
Another way of looking at this, Apple did the same move over a decade ago with far more limited hardware and pretty much everyone loved it because the speed and stability boost was quite noticeable.
[deleted]
I’m still not sure I understand Wayland. With X11, the server manages input, windows, and desktops and provides hooks so a window manager process can decorate those objects. Other processes can make a window and logically draw to it, and the X server does the physical rendering to a screen.
But with Wayland, who does the physical rendering? This responsibility is all now dumped on the window manager?
Edit: ahah, modern systems punt the actual drawing off to the kernel, using Kernel Mode Setting. What I would’ve called the framebuffer when I were a lad.
But with Wayland, who does the physical rendering? This responsibility is all now dumped on the window manager?
Edit: ahah, modern systems punt the actual drawing off to the kernel, using Kernel Mode Setting. What I would’ve called the framebuffer when I were a lad.
>But with Wayland, who does the physical rendering?
The application renders to a texture.
The compositor takes all of the textures from windows and composites them into a single texture that will then get displayed.
> This responsibility is all now dumped on the window manager?
No, the window manager manages the windows and giwen the compositor information on how it should composite.
The application renders to a texture.
The compositor takes all of the textures from windows and composites them into a single texture that will then get displayed.
> This responsibility is all now dumped on the window manager?
No, the window manager manages the windows and giwen the compositor information on how it should composite.
For the full picture I think https://www.youtube.com/watch?v=RIctzAQOe44 is still a pretty good overview of why X11's design doesn't really apply well to modern usage. Particularly the second half of the "core X11" chapter.
The TL;DR is that the vast majority of apps are now rendered on the client and most window managers are compositing. This means that the flows look like this:
1. X server reads input.
2. X server sends input to the window manager.
3. The window manager maps the input to a window and sends it back to X.
4. The X server sends it to the clients.
5. The client re-renders and sends it's buffer to the X sever. (Unsyncronized)
6. The X sever sends the new buffers to the window manager.
7. The window manager composites the desktop and sends the result back to the X server.
8. The X server displays the buffer.
The TL;DR is that the X server just does inefficient IPC and some top level I/O. Basically all of the rendering is done in the clients or window manager.
So Wayland attempts to improve on this model, highlights are:
1. Well designed IPC interface and async/hotplug baked in.
2. Remove the X server intermediary.
3. Actually add frame metadata to allow avoiding tearing.
4. Switch to a more declarative approach for most APIs. For example actually having the concepts of full-screen, modals, popups and screensavers. This fixes issues like using volume keys while a context menu is open and many others.
5. Provide the ability to have capability-based security for things like reading other application's outputs and inputs.
The top level I/O management have been moved into libraries as much as possible. Output is mostly managed by the regular graphics APIs and kernel DRM and input is managed by libinput. Of course you don't have to use these libraries, but they are pretty commonly used.
People get upset that there are now N compositors, but in X most window managers were compositors anyways, it hasn't really changed this equation. There were also lots of optional extensions so window-manger compatibility was never perfect.
The TL;DR is that the vast majority of apps are now rendered on the client and most window managers are compositing. This means that the flows look like this:
1. X server reads input.
2. X server sends input to the window manager.
3. The window manager maps the input to a window and sends it back to X.
4. The X server sends it to the clients.
5. The client re-renders and sends it's buffer to the X sever. (Unsyncronized)
6. The X sever sends the new buffers to the window manager.
7. The window manager composites the desktop and sends the result back to the X server.
8. The X server displays the buffer.
The TL;DR is that the X server just does inefficient IPC and some top level I/O. Basically all of the rendering is done in the clients or window manager.
So Wayland attempts to improve on this model, highlights are:
1. Well designed IPC interface and async/hotplug baked in.
2. Remove the X server intermediary.
3. Actually add frame metadata to allow avoiding tearing.
4. Switch to a more declarative approach for most APIs. For example actually having the concepts of full-screen, modals, popups and screensavers. This fixes issues like using volume keys while a context menu is open and many others.
5. Provide the ability to have capability-based security for things like reading other application's outputs and inputs.
The top level I/O management have been moved into libraries as much as possible. Output is mostly managed by the regular graphics APIs and kernel DRM and input is managed by libinput. Of course you don't have to use these libraries, but they are pretty commonly used.
People get upset that there are now N compositors, but in X most window managers were compositors anyways, it hasn't really changed this equation. There were also lots of optional extensions so window-manger compatibility was never perfect.
I'm happy to see that this transition is finally nearing its end. TBH, I think most of us expected certain drivers to take a long time, but I've been shocked at how long it took for some other basic things to happen. Synergy support just kept getting kicked down the road, possibly into its own irrelevancy? :)
funny how they introduced wayland support in their nightly build over 5 years ago (https://news.ycombinator.com/item?id=18465506), and people continue to complain about wayland support till date.
i am in support of pushing for newer standards this way, whether that is the intention or just a side-effect. no progress happens when people in the most impactful position refuse to adapt it. the needle moves only when casual users are made to test it.
almost 10 years ago, nvidia drivers sucked massively for laptops with hybrid graphics on x11 (sometimes not giving video out at all). they now suck at wayland. if we put up with all that in the past with the older standard, so be it today in the name of progress.
i am in support of pushing for newer standards this way, whether that is the intention or just a side-effect. no progress happens when people in the most impactful position refuse to adapt it. the needle moves only when casual users are made to test it.
almost 10 years ago, nvidia drivers sucked massively for laptops with hybrid graphics on x11 (sometimes not giving video out at all). they now suck at wayland. if we put up with all that in the past with the older standard, so be it today in the name of progress.
I have never been successful enabling Wayland in Ubuntu. I have tried multiple times over the last 3 years, most recently on 22.04.
Every time I try to enable it, either: everything still uses X11 on reboot, or the system boots to a black screen and I need to use recovery to revert.
Every time I try to enable it, either: everything still uses X11 on reboot, or the system boots to a black screen and I need to use recovery to revert.
Mozilla will likely be one of the first to drop X11 support, forcing everyone to move to Wayland or use some emulation layer. They did the same with removal of ALSA audio support.
I use kde and I usually put this line in /etc/environment to enable wayland “MOZ_ENABLE_WAYLAND=1”, and you can check that you are using it and not the adapter by going to about:support and search for wayland, it should be “wayland” and not “xwayland”. It improves the performance especially for video playback and such, but also enables the toch pad gestures in some laptops and zoom in/out.
Wayland needs to support screensavers before I'll consider using it.
[deleted]
> New option to force-underline links in websites
Game changer.
Game changer.
Sorry for the OT but this is driving me crazy.
How does "dark mode" work in desktop linux?
I'm using i3wm and I haven't been able to find a way to "press a button and every app turns into dark mode". To be clear, all my apps are already configured to take the theme from "system theme", I just haven't been able to find how to change this system theme.
On android this is pretty well integrated, what's the deal with desktop?
How does "dark mode" work in desktop linux?
I'm using i3wm and I haven't been able to find a way to "press a button and every app turns into dark mode". To be clear, all my apps are already configured to take the theme from "system theme", I just haven't been able to find how to change this system theme.
On android this is pretty well integrated, what's the deal with desktop?
On GNOME and KDE, this is simple. Window managers, of course, are going to come with their own solutions. The setting is exposed through the XDG Desktop Portal.
You're being downvoted but you're right.
If you're using a Window Manager (like i3) they are unlikely to come with utilities like this. You need to download another app (lxapperance for Xorg) or write a script to flip the appropriate settings.
If you're using a Window Manager (like i3) they are unlikely to come with utilities like this. You need to download another app (lxapperance for Xorg) or write a script to flip the appropriate settings.
> The setting is exposed through the XDG Desktop Portal.
Is this something I can use if I'm using i3wm?
Is this something I can use if I'm using i3wm?
A desktop environment like Gnome or KDE does a lot of this for you. You can try using a stand alone program like lxappearance (from LXDE) to tweak your settings. Or you can configure it yourself https://wiki.archlinux.org/title/GTK#Dark_theme_variant
> On android this is pretty well integrated, what's the deal with desktop?
I have a button in gnome that toggles dark mode on/off that switches the desktop over that works for just about everything (not discord though).
I have a button in gnome that toggles dark mode on/off that switches the desktop over that works for just about everything (not discord though).
I wrote a little toggle script for the Gnome apps:
#!/bin/bash
color_scheme=$(gsettings get org.gnome.desktop.interface color-scheme)
case $color_scheme in
*default* ) new_color_scheme="'prefer-dark'";;
* ) new_color_scheme="'default'";;
esac
gsettings set org.gnome.desktop.interface color-scheme "$new_color_scheme"Not sure about dark mode, but theming in general in Linux is so broken for me compared to the past. Many applications now use themes set by desktop configuration (but with some choosing gtk-related settings, others choosing qt-related settings, which can differ).
But no matter what theme I choose, there will always SOMETHING be broken. In one theme some part of an application will have black text on a black background. Another theme fixes that, but them makes in the alt+tab application switcher the part that highlights which application you're selecting invisible. Other themes have almost invisible scrollbars. Various applications have missing icons because they no longer have their own built-in ones.
I wish every application just had its own actually working built-in theme, rather than trying to shoehorn a global desktop theme inside of everything. It used to be like that in the past and it looked perfect compared to the mess now. Desktop theme settings should just be about the outer window borders and stuff.
Also, does there even exist ONE theme still today that actually visually distinguishes the selected and non-selected windows well? They're all super subtle about this now. Give me a bright blue selected window, gray non-selected window titlebar please so I can tell at a side-eye glance what's focused.
But no matter what theme I choose, there will always SOMETHING be broken. In one theme some part of an application will have black text on a black background. Another theme fixes that, but them makes in the alt+tab application switcher the part that highlights which application you're selecting invisible. Other themes have almost invisible scrollbars. Various applications have missing icons because they no longer have their own built-in ones.
I wish every application just had its own actually working built-in theme, rather than trying to shoehorn a global desktop theme inside of everything. It used to be like that in the past and it looked perfect compared to the mess now. Desktop theme settings should just be about the outer window borders and stuff.
Also, does there even exist ONE theme still today that actually visually distinguishes the selected and non-selected windows well? They're all super subtle about this now. Give me a bright blue selected window, gray non-selected window titlebar please so I can tell at a side-eye glance what's focused.
Sounds like you want GNOME + libadwaita or KDE + Breeze. Never had theming issues with that combination.
Thanks, I'm using cinnamon.
I loved KDE 3.5, but ever since KDE 4 and plasma, I've tried multiple times and never liked it.
I also don't like Gnome, doesn't fit my workflows well, it doesn't support moving windows between multiple desktops well, no window list enabled by default, ...
I loved KDE 3.5, but ever since KDE 4 and plasma, I've tried multiple times and never liked it.
I also don't like Gnome, doesn't fit my workflows well, it doesn't support moving windows between multiple desktops well, no window list enabled by default, ...
If one user wants theming, he certainly doesn't "want" Gnome, themes break every versions
https://medium.com/@fulalas/gnome-42-the-nonsense-continues-...
https://medium.com/@fulalas/gnome-42-the-nonsense-continues-...
They said each application should have its own theme that it supports, which is exactly what libadwaita is. A theme that apps can bundle and force.
Can't you see the contradiction?
What's a theme and customization if the DE/app forces 'themes' on the user?
Getting downvoted over this further prove my whole point
https://news.ycombinator.com/item?id=38696961
What's a theme and customization if the DE/app forces 'themes' on the user?
Getting downvoted over this further prove my whole point
https://news.ycombinator.com/item?id=38696961
What I'm looking for is:
-Allow to choose theme for the window decorations (titlebar etc...) and the desktop itself in its settings and have this applied consistently in the desktop (all applications use same window decorations on the outer part of their windows, ...).
-Let application have their own icons inside of the window (I have nothing against applications reusing icons, but let the developer choose them, not desktop-dependent since that's clearly not working out). Like say the "save file" icon in a text editor: I'd rather have a well-chosen one by the developer of this text editor, than one that either doesn't work or look completely out of place but was enforced by some desktop standard.
What I don't like is:
-applications changing / removing the outer window borders. They have no business changing that, only the inside content of their windows. E.g. a browser removing the title bar of its window can make some menus the desktop provides there inaccessible, make it invisible which window is focused, etc...
-application using external theme (e.g. based on some desktop standard) icons for its internal contents and then not working properly because the creator of the application could not know what the external theme would look like. This does not work out for various reasons: having 1 desktop setting makes it impossible to fix individual programs since changing theme to fix 1 may break another, e.g. say you have themes "adwaita" and "greybird" in your desktop setting, theme adwaita breaks program A (e.g. it shows black text on black background; just arbitrary example, not saying adwaita actually does this but I know at least one epub reader that showed black text on black background for some desktop settings in real life) but works in program B, and theme greybord works in program A but breaks program B (e.g. its icons will be invisible or whatever): If program A and program B just had their own inner contents, this problem would not exist.
Also, different applications having to be consistent across each other for their inner contents is something I couldn't care less about, so it's not worth all the problems it causes.
-Allow to choose theme for the window decorations (titlebar etc...) and the desktop itself in its settings and have this applied consistently in the desktop (all applications use same window decorations on the outer part of their windows, ...).
-Let application have their own icons inside of the window (I have nothing against applications reusing icons, but let the developer choose them, not desktop-dependent since that's clearly not working out). Like say the "save file" icon in a text editor: I'd rather have a well-chosen one by the developer of this text editor, than one that either doesn't work or look completely out of place but was enforced by some desktop standard.
What I don't like is:
-applications changing / removing the outer window borders. They have no business changing that, only the inside content of their windows. E.g. a browser removing the title bar of its window can make some menus the desktop provides there inaccessible, make it invisible which window is focused, etc...
-application using external theme (e.g. based on some desktop standard) icons for its internal contents and then not working properly because the creator of the application could not know what the external theme would look like. This does not work out for various reasons: having 1 desktop setting makes it impossible to fix individual programs since changing theme to fix 1 may break another, e.g. say you have themes "adwaita" and "greybird" in your desktop setting, theme adwaita breaks program A (e.g. it shows black text on black background; just arbitrary example, not saying adwaita actually does this but I know at least one epub reader that showed black text on black background for some desktop settings in real life) but works in program B, and theme greybord works in program A but breaks program B (e.g. its icons will be invisible or whatever): If program A and program B just had their own inner contents, this problem would not exist.
Also, different applications having to be consistent across each other for their inner contents is something I couldn't care less about, so it's not worth all the problems it causes.
For things like text readability, much of the fault lies on developers for not using parameterized colors (e.g. “primary text”, “secondary text”, etc) which can change as needed to fit light/dark mode, accessibility modes, and even things like user-preference UI tints.
Use of CSS in GTK for theming (maybe Qt too, not sure?) doesn’t help matters since both user applied-themes and developer-applied CSS can screw things up by overriding things in a half-baked way.
Use of CSS in GTK for theming (maybe Qt too, not sure?) doesn’t help matters since both user applied-themes and developer-applied CSS can screw things up by overriding things in a half-baked way.
i3wm and Android are polar opposites in terms of how much power users have to customize the experience (almost a necessity for using i3wm, and almost impossible on a unrooted Android). Strange situation you're in if you want a locked down, polished end-user experience on i3.
I use `lxappearance` to modify theme and other such UI settings from within i3wm.
[deleted]
bluedays(1)
[deleted]
I am sensing a large momentum for Wayland in the Linux community though. Finally there is maturity for Wayland in KDE, there is very strong commitment from various projects to default to Wayland (this being one of them). Traditionally more conservative projects like Cinnamon and Wine are finally adopting Wayland too. It seems critical mass has been achieved to get things really moving in the community, and it's about time.