91–100 of 134 posts
I am still perfectly happy running X11. I am not going to switch any time soon. Never change a running system. The fact that only Gnome kind-off supports basic accessibility on wayland already shows what a giant failure wayland is.
Earlier quoted context omitted.
What's XLibre? Are they taking Linux desktop accessibility more seriously?
XLibre is a fork of Xorg X11's codebase started by a developer who got kicked out of the Xorg project because he was making lots of changes that broke everything and had a hard time getting along with the other devs. Another dev blindly applied his MRs assuming he had tested stuff before submitting the request and they had to go back and revert a bunch of stuff. Broke nvidia compatibility, broke xrandr extension, and…
The people like OA are spreading misinformation because the developer stated everyone was welcome to contribute and would oppose excessive politics. Keep in mind red hat is currently getting sued 3x over for blatantly racist policies which they used to ban other contributors and forced on their managers, they are evil people.
Earlier quoted context omitted.
> I've seen enough stuff I've flagged disappear quickly, and then reappear later (with surprisingly reasonable discussion), to suggest that the admins will retrieve any popular discussion that was unreasonably assigned to the naughty step. That's the whole point. The default for everything that has at least a small hater base is to disappear, until for manual reenabling by moderators. This is not community moderation…
While I find the moderation on HN a bit heavyhanded at times: When the originator of the XLibre fork decided to push a heavily partisan political stance right there in the README, he made a choice that ensured that the project will be controversial. He can fix that very easily if he wants to. As someone who detest Wayland, I would very much like to see Xlibre be sucessful, but I'm not surprised a lot of people will r…
Earlier quoted context omitted.
Excellent excellent call out. This feels very wrong direction, this using a side-band for accessibility!!! I had no idea. It's surprising to me that security would prompt the push to D-Bus. Wayland's design with the compsitor as the message bus center was built to center security in the architecture, to make the compositor the arbiter of data flows. I'm struggling to picture what the issue was here with sandboxed app…
Compositors are incompatible with one another and have totally different levels of functionality. Most compositors don't do any proper kind of security and permissions and just limit data flows in the most primitive and restrictive way possible. Using something with existing security but the possibility of cross-communication like DBUS is just easier here. Although I expect a lot of confused deputy type of exploits t…
I see far more similar about compositors than different. They have freedom of implementation & do different things, but they offer to apps a very common set of protocols, and some of the newer edgier protocols have more varied adoption. But I see standards & growth & development forward as 'what Wayland is', not "incompatibility" (that's why Wayland proper is purely 100% protocols & not a bespoke impl) and "totally different" (???).
Finding formal concensus to make special stable has been hard. But there is a pleasantly large amount of overlap and interop, even if compositors end up implementing more than one flavor of say gamma control.
> Most compositors don't do any proper kind of security and permissions and just limit data flows in the most primitive and restrictive way possible.
When starting a composite yeah, you figure out who has input and send it there. You render the surface the apps give you. Dataflow is inherently quite unidirectional for a long time when beginning a desktop compositor.
But that doesn't feel true at all today. Most compositors support advanced screen sharing, virtual pointers, and other fairly advanced data-flow protocols, almost all built security in mind, requiring more advanced routing & permissioning, as is very visible with the screen share flows of most apps.
> Using something with existing security but the possibility of cross-communication like DBUS is just easier here.
Agreed, but you yourself in your very negative comment on Wayland in this topic seem quite opposed to second systems in broad basis (and pretty radically down on Wayland in general). I'd like to see the display system protocols able to better tackle talking about and managing what's on the screen, rather than building a second parallel system for saying and working with what's on the screen.
I also think there's a decently strong basis already there in the current protocols. There's a security context to start. https://wayland.app/protocols/security-context-v1 We see more advanced flows like XDG Foreign for apps to expose surfaces and mix them onto our own apps.
At-spi d-bus was already right there & done, and it felt easy to keep using it. It was mostly convenience I feel like, and the justification of security feels like a blunt hammer to deny exploration. https://gitlab.gnome.org/GNOME/at-spi2-core/
Earlier quoted context omitted.
I don't want an X server that supports Wayland. I want a leaner, simpler X server without Wayland. EDIT: To clarify, the reason I mentioned Wayland compositors is that it'd be an opportunity to pick a low-level rendering backend that has been written from scratch without the baggage of Xorg. The "good parts" of X that modern apps actually use are comparatively simple compared to the low level bits - the protocol is t…
XWayland can be run in 'rootless' and 'rootful' modes. Rootless is what it is typically ran as and allows you to integrate X11 apps into your Wayland desktop environment. Rootful would allow you to run X11 desktop with X11 Window manager and the whole ten yards. I don't know how well rootful mode is working because it is rarely used. I imagine it would take some work to make it fully functional. But it something that…
Earlier quoted context omitted.
While I find the moderation on HN a bit heavyhanded at times: When the originator of the XLibre fork decided to push a heavily partisan political stance right there in the README, he made a choice that ensured that the project will be controversial. He can fix that very easily if he wants to. As someone who detest Wayland, I would very much like to see Xlibre be sucessful, but I'm not surprised a lot of people will r…
He stated everyone was welcome regardless of their race or politics. This is only a strongly political stance if you contrast it with Red Hat, whose extremist, racist and illegal discriminatory policies they implemented under the banner of DEI now has them in hot water with 3x workplace discrimination lawsuits. Honestly i don't understand how people can call xlibre political but abide by red hat's active evil.
Earlier quoted context omitted.
Wayland is a perfect example of the second system effect and the sunk cost fallacy. X11 had problems, but instead of fixing them, developers threw the baby out with the bathwater, designed something completely byzantine and weird. Time was invested, so no stopping now or ever. The design of wayland introduces more problems than it solves, only by plastering over with yet another extra protocol that you have to implem…
> X11 had problems, but instead of fixing them You can't fix a protocol that simply isn't designed for how modern graphics hardware works. Both macOS and Windows have upgraded their display stacks over the decades, but it was seamless because unlike Linux, nearly all applications dynamically link the system library which they can upgrade. Linux is late to the party here because everyone wants to make their own toolki…
> GNOME’s Wayland session is now stable and usable with Orca. They did that via an out-of-band D-Bus protocol, rather than going full Wayland. I'm all for keeping D-Bus around for backwards-compatibility (lots of things use AT-SPI2, and I certainly don't want a repeat of the CORBA -> D-Bus migration), but Wayland's AT support should be first-class, not relegated to proprietary GNOME extensions. Per Matt Campbell's ar…
TLDR (non-AI): The author raises very valid points about accessibility under Wayland. The "And Now We Don’t Have a Choice" subtitle seems to address that only Gnome seems to have usable accessibility under Wayland right now but can easily be misunderstood as "we have no alternative to Wayland". The author also mentions X11 sucked in many ways and that this transition also is a moment to rethink what proper accessibil…
Wayland is a perfect example of the second system effect and the sunk cost fallacy. X11 had problems, but instead of fixing them, developers threw the baby out with the bathwater, designed something completely byzantine and weird. Time was invested, so no stopping now or ever. The design of wayland introduces more problems than it solves, only by plastering over with yet another extra protocol that you have to implem…
Earlier quoted context omitted.
> X11 had problems, but instead of fixing them You can't fix a protocol that simply isn't designed for how modern graphics hardware works. Both macOS and Windows have upgraded their display stacks over the decades, but it was seamless because unlike Linux, nearly all applications dynamically link the system library which they can upgrade. Linux is late to the party here because everyone wants to make their own toolki…
The protocol is trivially extensible, and have had plenty of extensions that has significant altered how it behaves. Fixing X in a step wise manner wod have been perfectly doable. The problem is that the Wayland proponents didn't just want to fix the things there was agreement was broken, but also wanted to actively break things that would cause an uproar.