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?
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.
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, ...
-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.
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.
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
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.
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"
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.
Worth noting that Firefox has run on Wayland by default on Fedora for many, many years at this point because the Fedora team patched it to do that. Firefox also uses Wayland on the default RHEL9 desktop and its derivatives, and it's been quite easy for power users to enable it in other environments. So it's quite well battle tested.
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.
> 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 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...)
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.
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 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.
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.
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.
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 :)
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.
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.
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.
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? :)
Seems you have little to gain by that. I'm also a Wayland laggard, I still haven't switched any of my machines over, but I recognize it's the future. I think they've chipped away at all the big complaints at this point, so it's just a process of bringing all the applications I care about online, and I think that work is largely done, too. Whenever XFCE announces official support[1], I'll switch over and give it a try.
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.
> 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.
>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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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
> 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..
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.
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.
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.
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.
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?
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 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.
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.
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.
> 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.
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.
> [...] 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.
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:
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.
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.
> 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.
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.
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.
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
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).
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:
> 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.
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...
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.
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.
> 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.
> 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.
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.
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?
Documentation and tutorials. I see X11 devs who aren't even looking at Wayland struggling with this stuff. It is very, very clearly not as easy as you are making it sound.
Nor are you in a position to say that everything works if you don't use accessibility controls. You're very confident that the at-spi protocol is fine for everything given that you are someone who does not rely on the at-spi protocol to use a computer and who does not use it as a daily driver.
I am inclined to say that if users who do rely on accessibility controls on a daily basis are complaining, probably they're not making up their complaints.
Who's fault it is that they're running into issues? Again, it doesn't really matter, the issues persist.
> I am inclined to say that if users who do rely on accessibility controls are complaining, probably they're not making up their complaints.
This entire thread started off by someone saying untrue rumors about Wayland and DE's regarding accessibility - so excuse everyone who thinks the complaints are likely misguided.
Again - if something is lacking in Wayland compatibility - now - is the time to ask app developers to update. If for some reason it cannot be done in Wayland, it should be reported to the Wayland project! This is not rocket science...
Right now XWayland works as it should. So provide some specifics or get off the pot...
> This entire thread started off by someone saying untrue rumors about Wayland and DE's regarding accessibility
I'm going to tentatively push back on this, my (very limited) understanding of the at-spi protocol is that it exposes application-specific controls and that it's not relevant to conversations about how to control a DE, and that current DEs do not in fact expose a common shared protocol across all of them for the kinds of controls that Talon needs.
I'm not an expert on this stuff by any means, but from what I can tell, OP is correct and is not spouting untrue rumors. I'd welcome correction in the form of some kind of accessible documentation for integrating with those window managers that uses a universal common protocol for all of them, but getting back to something I've pointed out multiple times above:
> so excuse everyone who thinks the complaints are likely misguided. [...] This is not rocket science...
This kind of response isn't particularly convincing given that I note you still haven't linked over some novice-accessible documentation about how to work with this stuff or test it, likely because that novice-accessible documentation is difficult to find if it exists at all.
I would love some easy ways to verify what at-spi controls, how to integrate with it in different languages, and how different DEs handle exposing it for their own interfaces. The absence of approachable documentation is a big reason why people are confused about Wayland (and about other good projects like Flatpak that get commonly maligned on HN, but that's a longer conversation). The absence of easy, clear information about how all of this stuff works might at least partially explain why application developers aren't quickly modernizing.
If you think that Talon developers are lying about how DEs work, then education efforts using clear, user-and-developer facing documentation about the protocols involved would be a pretty good way of combating FUD.
----
> Right now XWayland works as it should. So provide some specifics or get off the pot...
First, as others have mentioned, XWayland is insufficient for the kinds of needs that Talon has; operations like enumerating windows or handling focus can not (and should not) be handled via XWayland unless you plan to run your entire desktop environment in XWayland.
Secondly, XWayland is not the future. It is also a dead end. I'm glad that it exists for now, it is absolutely critical for early adoption of Wayland and is critical for supporting some apps. But XWayland is not a permanent solution to accessibility problems and it's wild to hear people simultaneously say that X11 is a walking zombie and to tell people that accessibility is fine because if there are any problems with Wayland you can always just tie your applications to a walking zombie.
The goal here is to get rid of X11, or at least that's what I think the goal should be, because I do think that X11 is a walking zombie and I resent the fact that I'm still using it.
----
My concern is not that Wayland can't be accessible or that there aren't ways to make it accessible. My concern is that regardless of whether or not universal protocols exist right now, it doesn't look like they're being used and it doesn't look like Wayland is going to be accessible for a lot of people in reality. And I don't care who's fault that is; it's still the case that calling developers lazy and accusing people who are sharing real accessibility problems that they have right now of spreading "untrue rumors" does not seem to be helping to improve the situation.
This isn't a situation like NVIDIA where there's one specific company we can all shame; if a bunch of disparate developers aren't taking the necessary steps to update their applications, then something is going wrong in the communication process or the steps aren't clear enough, or the incentives aren't aligne...
> 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.
> 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.
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.
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:\
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.
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.
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.
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.
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'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.
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 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.
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:
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
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...
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.
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)
> 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.
I think the downvoting is often because there are no arguments, just negativity without explaining what exactly is problematic, like in your comment which is also getting downvoted...
I do not like how ready the big spenders in the Linux sphere are to push wayland into every crack, considering:
1. It consistently breaks closed-cource software that I need to use in education like Mathematica and MATLAB
2. It requires tweaking to work with Flameshot and related screenshotting software
3. It breaks emulation layers like Wine and Proton (or significantly decreases performance). This was a dealbreaker since I managed to move almost completely to Linux for gaming.
4. It does weird things with scaling. I used to use three monitors (two 1080p above one another and a 1060p to the side) and it always did weird things if I tried to span windows across it.
5. It still is not working properly on Nvidia.
There is a problem with these technologies where the leaders are reinventing wheels and making them square in the process, acting like past paradigms are completely useless and that you're ridiculous for even questioning the departure from status quo. And because big entities like Microsoft, Red Hat, Fedora, Canonical etc. spend money on them, the main users have little say in the features developed. Desktop finally got to a reliable and comfortable point with software compatibility and usability, but now we have a ton of people funded by the EmbraceExtendExtinguish crowd pushing a new desktop protocol stack that obviously breaks things.
1) I haven't used these, but I assume newer releases will be native to Wayland.
2) This is because you need to make an API call to the compositor to capture the screen. This is a one-time change unless you're using a very old application that hasn't had Wayland support added in the last decade.
3) It doesn't significantly impact Wine/Proton performance. In fact the Steam Deck runs a Wayland compositor (Gamescope) with the games under XWayland. Valve is porting Wine/Proton to support Wayland natively.
4) This isn't up to Wayland but up to the compositor.
5) This is Nvidia's fault for trying to force everyone else's hand by using their driver API model of choice for years until only recently capitulating.
Yes. Anytime anything that's generally good comes up, there's a torrent of reactionary butter voices, who cast broad disparagement about with abandon. It's a terrible plague.
We dealt with it for years for systemd, but the tides have turned there pretty broadly & 99.999% of us get it and see the value and understand how it's much better than copy pasting shoddy shell scripts around.
Making arguments that people can rebut or support would drastically alter the situation. (Those arguments not all being "Nvidia doesn't work well" would also be required in this case; we of open source are closest to the gods but even us saintly miracle workers on earth have limits & that green devil does confound us.)
Climbing up the ladder from lowest to highest form of disagreement, it would be nice to see folks able to acknowledge perspectives from the other side, to be able to go through what aspects are good & great. Having nuance does not seem to be a strong suit for the anti systemd anti pulseaudio anti Wayland posters. Sometimes there's some of this done, but often pretty backhanded. I'd like to see more steelmanning.
> Making arguments that people can rebut or support would drastically alter the situation
This is why the non-specific griping gets an immediate downvote from me. There are only a few things where the crappiness is so widely agreed upon that you don’t need to explain; if you’re talking about something which millions of computers are already running, it’s quite unlikely that something is completely unusable, or that anything useful will come out of the ranting. If there are specific details, though, it’s possible to have a productive conversation and maybe lead to some open source work.
Adding on to myself, a core frustration I have with Wayland criticism in specific is that a lot of people seem to bring very totalized expectations to the debate.
I confess, I still think The Cathedral and the Bazaar describes a very real distinction in how stuff is developed. One grand pre-designed edifice, versus a lot of different forces in a action slowly sussing out what works well. There's so many people mad sad and angry that everything isn't already perfect. There's people mad sad and angry that everything isn't more centralized, isnt all the same. They see the lack of a core display server as some horrible flaw.
That freedom to try & iterate & explore solution spaces has made things go slower. Sure, yes, and that's had pain. But we've seen so much innovation at the edge, various servers trying different takes & different protocols, and then coming together to try to figure out how to mesh stuff together.
Some people are so averse to these sticky complicated involved processes. It's short term inconvenient to not have a dictator deciding, just picking from off the cuff.
I try to empathize with these views, & I get the yearning for not having to hash stuff out, to some degree. But I don't see any nuance that I'd hope for. I don't see that these harsh unforgiving critics get the stakes, I don't see that they have any appreciation for iteration, I don't see that they have any idea the benefit of this being a social not dictatorial process. They apply their preconceived notions of software as cathedral building to a situation that is shooting for long long long stakes, that wants direly to be long term good after watching many shortly made ad-hoc decisions compound into the X schmorgasboard of ideas.
I feel like these people don't want to be reasoned with. They don't want to consider the Bazaar model. They don't want to respect or love the expansion/contraction of innovation-at-the-edge and then coming together. They by and large don't see that the ability to build a Wayland server out of nothing in a weekend has a decent-if-different counter-position to their angst that one could keep reusing X to build new WM's.
I believe & cherish that we are iterating through Wayland. Protocols are happening. The progress has been clear and nots le, even though various pieces have been harder to settle upon & get right. It's commonly said that the protocol discussions (wars) are resistant to listening to app devs, but in many many threads it's clear there's dueling ideas of what the protocol ought to be, of what works well, but people interpret un-acceptance of their idea as rejection. Things are iterating. Some pieces are harder than others but it seems clear there s iteration. And the village of ideas model that's happening here keeps seeming to make good critical assessments, keeps finding very high quality options, after hard tribulation.
I don't see the nuance from critics: they have specific issues but so often comprehension for the scene, only their own personal bailiwicks. Their criticisms are often the best thing happening, are why this is working, maybe just not at their asked for pace (but instead a build-it-for-life path). They see innovation at the edge as terrible and bad and their enemy, when it is the salvation & protection from mistakes & ability to try things safely that lets us figure stuff out. Critics of systems similarly felt persistently low dimensional, shallow, uninterested & unengaged & uncontemplative. I want nuance and respect, ability to recognize tradeoffs & appreciate the other views, regardless of what one feels, and I find that severely lacking in most HN criticism. And the critics are soooo vocal, so persistent. They exhaust us. While offering little.
Systemd, Wayland and Gnome seem to be a concerted effort from Red Hat. I won't use them; once there are no more Linux distros that let me avoid them, I'll be off to BSD-land. I'm not a hostage!
It's Corporate Open-Source, with the same corporate politics behind it.
Fortunately I've managed to excise this mess of interconnected dependencies from my computer and run plain X11 with a very functional desktop environment.
No PulseAudio, Systemd, NetworkManager, PipeWire or even D-Bus. And a very low memory footprint and the system is extremely fast, despite it being old hardware.
All of this bloatware is coming out of Freedesktop.org, which is run by Red Hat / GNOME. And it's where most of the toxicity in open source is coming from.
I've also gotten rid of the "modern" user-interface design trends as well. I get a high contrast, high information density desktop with full colour icons. None of this depressing grey garbage we get nowadays. All of the keyboard shortcuts work - I don't even need to use the mouse.
If you showed someone from 20 years ago what a "modern" desktop interface looked like, they would be outraged and in disbelief. We have taken an enormous step back for some reason.
I think you want Slackware. It's about as close to a BSD system that linux gets, no systemd...install i3wm and you've got mostly what the commenter above described.
I used Slack for many, many years both as a personal OS and a production server. It's rock solid, fast, and lean. It's not easy though, and you're going to be doing a lot of compiling from source and package management by hand. These are the trade-offs.
Linux is and has been courting the casual user for quite a while now, which is why I think things are going in this direction. It's a testament to its modularity that it can support the Windows shipjumpers as well as your use cases.
Because, frankly systemd + gnome + wayland actually work well together.
I'm not a Unix grey beard, but I've been using Linux for a while (6 years at this point). I have literally never had a problem that was related to systemd. So all the anti-systemd rhetoric just doesn't seem to have much merit to me.
Gnome is frankly the most polished DE on Linux. I've used many DEs and have run DWM and Sway setups. They all have their pros and cons, but Gnome is fine in my experience. In fact, Gnome is the most the most like a Window Manger of all the DEs. You can pretty easily get a keyboard only setup with Gnome.
I've been on Fedora for the last 2 years and Wayland has also been fine. Stuff like screen sharing was annoying at first, but I can't even remember the last time I noticed I was on wayland.
So call me a Red Hat Shill or whatever, but I just don't see what the hate is all about with systemd/Gnome/Wayland.
>Stuff like screen sharing was annoying at first, but I can't even remember the last time I noticed I was on wayland.
Does this mean screen sharing actually works on Wayland? Before I abandoned Manjaro for macOS (mostly because I needed the M1 battery life), it default-switched to Wayland after some updates and I only discovered on a work call that Wayland screensharing was broken. That was early this year.
The details are fuzzy to me now, and my situation may have been odd as I had changed hardware from an Nvidia GPU to an AMD APU, but it was astounding as an end user that that was the state of this "production ready, replace everything under the sun with it" software.
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 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!
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.)
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.
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.
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."
> 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.
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]
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.
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.
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.
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.
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%.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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".
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.
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].
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.
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.
> 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.
> 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.
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)
> 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.
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!
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?
> 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.”.
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.
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.
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.
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.
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)?
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.
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.
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.
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.
>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.
> 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’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.
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.
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.
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.
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.
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.
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 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.
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.
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.
264 comments
[ 4.0 ms ] story [ 195 ms ] threadhttps://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)
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?
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.
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, ...
https://medium.com/@fulalas/gnome-42-the-nonsense-continues-...
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
-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.
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.
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).
Is this something I can use if I'm using i3wm?
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.
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.
I was under the impression WINE was less conservative and more that they really needed features that Wayland only recently added (relative positioning?)
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...)
It will eventually be dropped like a hot potato, just like HAL.
At LEAST read the docs for your distro:
https://docs.voidlinux.org/config/session-management.html
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.
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.
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
[1]: https://www.phoronix.com/news/GIMP-2.99.2-Released
[2]: https://www.enlightenment.org/about-wayland
[1] Sounds like some upcoming major version https://wiki.xfce.org/releng/wayland_roadmap
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/
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.
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.
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.
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 run the OS that runs the programs I want to use.
Why wouldn't someone ditch an OS for another to keep using the software they want?
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.
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...
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.
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.
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.
When I hear accessibility I tend to think of screen readers - magnification or text to speech - for people with low vision.
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.
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.
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
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'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..
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.
It is never too late to start improving things.
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.
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 considered wlroots but the complexity is far higher and Im not in a rush to move to Wayland.
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.
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.
> 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 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.
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.
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.
> 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.
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.
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.
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.
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.
But Windows 11 really achieves greatness in a lot of ways, which offsets it.
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.
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...
Basically people complaining about needing to do work to modernize.
All the things will eventually be just fine. X11 is a walking zombie.
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.
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.
X11 is a complete dead end. All applications need to eventually update. Put pressure on app developers to get to it...
btw, I already said something wrong, because, which wayland? It's not a thing.
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.
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.
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.
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.
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.
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?
What cannot be accomplished with ATK/AT-SPI?
It's literally all there... but alas, we love to complain.
Documentation and tutorials. I see X11 devs who aren't even looking at Wayland struggling with this stuff. It is very, very clearly not as easy as you are making it sound.
Nor are you in a position to say that everything works if you don't use accessibility controls. You're very confident that the at-spi protocol is fine for everything given that you are someone who does not rely on the at-spi protocol to use a computer and who does not use it as a daily driver.
I am inclined to say that if users who do rely on accessibility controls on a daily basis are complaining, probably they're not making up their complaints.
Who's fault it is that they're running into issues? Again, it doesn't really matter, the issues persist.
This entire thread started off by someone saying untrue rumors about Wayland and DE's regarding accessibility - so excuse everyone who thinks the complaints are likely misguided.
Again - if something is lacking in Wayland compatibility - now - is the time to ask app developers to update. If for some reason it cannot be done in Wayland, it should be reported to the Wayland project! This is not rocket science...
Right now XWayland works as it should. So provide some specifics or get off the pot...
I'm going to tentatively push back on this, my (very limited) understanding of the at-spi protocol is that it exposes application-specific controls and that it's not relevant to conversations about how to control a DE, and that current DEs do not in fact expose a common shared protocol across all of them for the kinds of controls that Talon needs.
I'm not an expert on this stuff by any means, but from what I can tell, OP is correct and is not spouting untrue rumors. I'd welcome correction in the form of some kind of accessible documentation for integrating with those window managers that uses a universal common protocol for all of them, but getting back to something I've pointed out multiple times above:
> so excuse everyone who thinks the complaints are likely misguided. [...] This is not rocket science...
This kind of response isn't particularly convincing given that I note you still haven't linked over some novice-accessible documentation about how to work with this stuff or test it, likely because that novice-accessible documentation is difficult to find if it exists at all.
I would love some easy ways to verify what at-spi controls, how to integrate with it in different languages, and how different DEs handle exposing it for their own interfaces. The absence of approachable documentation is a big reason why people are confused about Wayland (and about other good projects like Flatpak that get commonly maligned on HN, but that's a longer conversation). The absence of easy, clear information about how all of this stuff works might at least partially explain why application developers aren't quickly modernizing.
If you think that Talon developers are lying about how DEs work, then education efforts using clear, user-and-developer facing documentation about the protocols involved would be a pretty good way of combating FUD.
----
> Right now XWayland works as it should. So provide some specifics or get off the pot...
First, as others have mentioned, XWayland is insufficient for the kinds of needs that Talon has; operations like enumerating windows or handling focus can not (and should not) be handled via XWayland unless you plan to run your entire desktop environment in XWayland.
Secondly, XWayland is not the future. It is also a dead end. I'm glad that it exists for now, it is absolutely critical for early adoption of Wayland and is critical for supporting some apps. But XWayland is not a permanent solution to accessibility problems and it's wild to hear people simultaneously say that X11 is a walking zombie and to tell people that accessibility is fine because if there are any problems with Wayland you can always just tie your applications to a walking zombie.
The goal here is to get rid of X11, or at least that's what I think the goal should be, because I do think that X11 is a walking zombie and I resent the fact that I'm still using it.
----
My concern is not that Wayland can't be accessible or that there aren't ways to make it accessible. My concern is that regardless of whether or not universal protocols exist right now, it doesn't look like they're being used and it doesn't look like Wayland is going to be accessible for a lot of people in reality. And I don't care who's fault that is; it's still the case that calling developers lazy and accusing people who are sharing real accessibility problems that they have right now of spreading "untrue rumors" does not seem to be helping to improve the situation.
This isn't a situation like NVIDIA where there's one specific company we can all shame; if a bunch of disparate developers aren't taking the necessary steps to update their applications, then something is going wrong in the communication process or the steps aren't clear enough, or the incentives aren't aligne...
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?
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.
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.
…
> 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.
> 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/
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.
[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...
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.
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.
I'm planning on moving all of my machines from Linux to BSD in part because of this, and in part because of SystemD.
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.
> 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.
> 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.
https://news.ycombinator.com/item?id=24922625
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...
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.
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)
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.
1. It consistently breaks closed-cource software that I need to use in education like Mathematica and MATLAB
2. It requires tweaking to work with Flameshot and related screenshotting software
3. It breaks emulation layers like Wine and Proton (or significantly decreases performance). This was a dealbreaker since I managed to move almost completely to Linux for gaming.
4. It does weird things with scaling. I used to use three monitors (two 1080p above one another and a 1060p to the side) and it always did weird things if I tried to span windows across it.
5. It still is not working properly on Nvidia.
There is a problem with these technologies where the leaders are reinventing wheels and making them square in the process, acting like past paradigms are completely useless and that you're ridiculous for even questioning the departure from status quo. And because big entities like Microsoft, Red Hat, Fedora, Canonical etc. spend money on them, the main users have little say in the features developed. Desktop finally got to a reliable and comfortable point with software compatibility and usability, but now we have a ton of people funded by the EmbraceExtendExtinguish crowd pushing a new desktop protocol stack that obviously breaks things.
2) This is because you need to make an API call to the compositor to capture the screen. This is a one-time change unless you're using a very old application that hasn't had Wayland support added in the last decade.
3) It doesn't significantly impact Wine/Proton performance. In fact the Steam Deck runs a Wayland compositor (Gamescope) with the games under XWayland. Valve is porting Wine/Proton to support Wayland natively.
4) This isn't up to Wayland but up to the compositor.
5) This is Nvidia's fault for trying to force everyone else's hand by using their driver API model of choice for years until only recently capitulating.
We dealt with it for years for systemd, but the tides have turned there pretty broadly & 99.999% of us get it and see the value and understand how it's much better than copy pasting shoddy shell scripts around.
Making arguments that people can rebut or support would drastically alter the situation. (Those arguments not all being "Nvidia doesn't work well" would also be required in this case; we of open source are closest to the gods but even us saintly miracle workers on earth have limits & that green devil does confound us.)
Climbing up the ladder from lowest to highest form of disagreement, it would be nice to see folks able to acknowledge perspectives from the other side, to be able to go through what aspects are good & great. Having nuance does not seem to be a strong suit for the anti systemd anti pulseaudio anti Wayland posters. Sometimes there's some of this done, but often pretty backhanded. I'd like to see more steelmanning.
This is why the non-specific griping gets an immediate downvote from me. There are only a few things where the crappiness is so widely agreed upon that you don’t need to explain; if you’re talking about something which millions of computers are already running, it’s quite unlikely that something is completely unusable, or that anything useful will come out of the ranting. If there are specific details, though, it’s possible to have a productive conversation and maybe lead to some open source work.
I confess, I still think The Cathedral and the Bazaar describes a very real distinction in how stuff is developed. One grand pre-designed edifice, versus a lot of different forces in a action slowly sussing out what works well. There's so many people mad sad and angry that everything isn't already perfect. There's people mad sad and angry that everything isn't more centralized, isnt all the same. They see the lack of a core display server as some horrible flaw.
That freedom to try & iterate & explore solution spaces has made things go slower. Sure, yes, and that's had pain. But we've seen so much innovation at the edge, various servers trying different takes & different protocols, and then coming together to try to figure out how to mesh stuff together.
Some people are so averse to these sticky complicated involved processes. It's short term inconvenient to not have a dictator deciding, just picking from off the cuff.
I try to empathize with these views, & I get the yearning for not having to hash stuff out, to some degree. But I don't see any nuance that I'd hope for. I don't see that these harsh unforgiving critics get the stakes, I don't see that they have any appreciation for iteration, I don't see that they have any idea the benefit of this being a social not dictatorial process. They apply their preconceived notions of software as cathedral building to a situation that is shooting for long long long stakes, that wants direly to be long term good after watching many shortly made ad-hoc decisions compound into the X schmorgasboard of ideas.
I feel like these people don't want to be reasoned with. They don't want to consider the Bazaar model. They don't want to respect or love the expansion/contraction of innovation-at-the-edge and then coming together. They by and large don't see that the ability to build a Wayland server out of nothing in a weekend has a decent-if-different counter-position to their angst that one could keep reusing X to build new WM's.
I believe & cherish that we are iterating through Wayland. Protocols are happening. The progress has been clear and nots le, even though various pieces have been harder to settle upon & get right. It's commonly said that the protocol discussions (wars) are resistant to listening to app devs, but in many many threads it's clear there's dueling ideas of what the protocol ought to be, of what works well, but people interpret un-acceptance of their idea as rejection. Things are iterating. Some pieces are harder than others but it seems clear there s iteration. And the village of ideas model that's happening here keeps seeming to make good critical assessments, keeps finding very high quality options, after hard tribulation.
I don't see the nuance from critics: they have specific issues but so often comprehension for the scene, only their own personal bailiwicks. Their criticisms are often the best thing happening, are why this is working, maybe just not at their asked for pace (but instead a build-it-for-life path). They see innovation at the edge as terrible and bad and their enemy, when it is the salvation & protection from mistakes & ability to try things safely that lets us figure stuff out. Critics of systems similarly felt persistently low dimensional, shallow, uninterested & unengaged & uncontemplative. I want nuance and respect, ability to recognize tradeoffs & appreciate the other views, regardless of what one feels, and I find that severely lacking in most HN criticism. And the critics are soooo vocal, so persistent. They exhaust us. While offering little.
It's something else, look what got downvoted/flagged, it's propaganda/censorship at this point ;)
Fortunately I've managed to excise this mess of interconnected dependencies from my computer and run plain X11 with a very functional desktop environment.
No PulseAudio, Systemd, NetworkManager, PipeWire or even D-Bus. And a very low memory footprint and the system is extremely fast, despite it being old hardware.
All of this bloatware is coming out of Freedesktop.org, which is run by Red Hat / GNOME. And it's where most of the toxicity in open source is coming from.
I've also gotten rid of the "modern" user-interface design trends as well. I get a high contrast, high information density desktop with full colour icons. None of this depressing grey garbage we get nowadays. All of the keyboard shortcuts work - I don't even need to use the mouse.
If you showed someone from 20 years ago what a "modern" desktop interface looked like, they would be outraged and in disbelief. We have taken an enormous step back for some reason.
I used Slack for many, many years both as a personal OS and a production server. It's rock solid, fast, and lean. It's not easy though, and you're going to be doing a lot of compiling from source and package management by hand. These are the trade-offs.
Linux is and has been courting the casual user for quite a while now, which is why I think things are going in this direction. It's a testament to its modularity that it can support the Windows shipjumpers as well as your use cases.
I'm not a Unix grey beard, but I've been using Linux for a while (6 years at this point). I have literally never had a problem that was related to systemd. So all the anti-systemd rhetoric just doesn't seem to have much merit to me.
Gnome is frankly the most polished DE on Linux. I've used many DEs and have run DWM and Sway setups. They all have their pros and cons, but Gnome is fine in my experience. In fact, Gnome is the most the most like a Window Manger of all the DEs. You can pretty easily get a keyboard only setup with Gnome.
I've been on Fedora for the last 2 years and Wayland has also been fine. Stuff like screen sharing was annoying at first, but I can't even remember the last time I noticed I was on wayland.
So call me a Red Hat Shill or whatever, but I just don't see what the hate is all about with systemd/Gnome/Wayland.
Does this mean screen sharing actually works on Wayland? Before I abandoned Manjaro for macOS (mostly because I needed the M1 battery life), it default-switched to Wayland after some updates and I only discovered on a work call that Wayland screensharing was broken. That was early this year.
The details are fuzzy to me now, and my situation may have been odd as I had changed hardware from an Nvidia GPU to an AMD APU, but it was astounding as an end user that that was the state of this "production ready, replace everything under the sun with it" software.
It does work well via the browser. Zoom is a lottery of pain.
The problem is you're not really criticising anything and are just complaining with no real substance. It's just boring whinging.
And I personally dislike systemd, wayland, and gnome, but you don't see me complaining about it every chance I get.
Cool. I guess I can delay switching to Wayland until the future!
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..
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!
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.)
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.
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.
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.
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."
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.
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...
Also, did you enable VSync on both the tests? And the same form of VSync? That can have an impact on input lag.
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.
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.
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.
Personally I can't wait until everybody comes to their senses and drops this pile of garbage API and goes back to X11.
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.
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.
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".
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.
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>
[1] https://flatpak.github.io/xdg-desktop-portal/docs/portal-int...
<https://wayland.app/protocols/wlr-screencopy-unstable-v1>
<https://sr.ht/~emersion/grim/>
<https://github.com/ammen99/wf-recorder>
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.
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.
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.
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.
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.
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)
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.
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.
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 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?
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.
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.
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.
Security needs to allow usability or the whole system fails.
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...
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”.
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.”.
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.
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.
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.
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.
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.
`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.
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.
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)
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.
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 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.
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.
Game changer.
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.
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.
Citation 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.
Proof needed.
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.