5 ms·
No matter how horrible X may be, it has a lot of value for end users. Almost all of this value is in the ecosystem around X. You can't capture an ecosystem unl
by andyjpb 6y ago
No matter how horrible X may be, it has a lot of value for end users. Almost all of this value is in the ecosystem around X.
You can't capture an ecosystem unless you provide that value, plus the activation energy needed to persuade people to change.
systemd (as an example of a large, recent, change to the "whole system") touched end-users far less than X so the pain was felt mainly by distributors and sysadmins.
Time and again, software that's "better" fails in the market because it doesn't provide the things that users need, want or use.
Backwards compatibility is usually key when trying to capture a large, long established user base. ...and that means backwards compatibility even (or especially!) with all the "bad" or "wrong" stuff. This is one of the things that makes software "products" much harder than software "engineering" (which in turn is "harder" than computer science).
Science is how it works. Engineering is getting it to work and productisation is getting people to adopt it.
Wayland has to solve problems that end-users actually care about rather than just being better in technical ways.
- DCKing 6y agoTo be fair to """Wayland""" (again, whatever that means), Gnome on Wayland seems to be a lot better when it comes to the core smoothness of the desktop experience. I have never seen tearing on Gnome on Wayland, and with X11 I saw it every day. I haven't used KDE on Wayland extensively, but in my short time with it it was a lot less glitchy graphically speaking than X11. For all the shortcomings of the """Wayland ecosystem""", there seems to be true technical merit Wayland has over X11. If only because it fundamentally solves X11's buffer sharing problem. But the writing's on the wall. This change is not coming about through market forces as you're suggesting, but where the developer's interests are. And that's pretty clear X.org's development has slowed down significantly compared to whatever is happening around a Wayland ecosystem. Although sadly not as much effort is put into the stuff that is needed outside of Wayland.
- 4bpp 6y agoI think tearing may be one of those personal preferences where the population is divided down somewhere near the middle, but people on either side can not fathom the existence of the other as anything other than some sort of bad-faith exercise in contrarianism. At least, I for my part could never imagine ever willingly giving up a "real feature" (my perception!) like xdotool for the cosmetic benefits of no tearing (which to me feels like a problem on the importance level of "getting the blinky blue LEDs on your GPU fan to work"), but at the same time there is clearly a large number of people on tech support forums, stackexchange etc. to whom it is of show-stopping significance, as evidenced by the effort and time put into achieving non-tearing and how often it is presented as a self-evident killer feature of systems like Wayland.
- saurik 6y agoThat tearing issue even comes from a tradeoff space: a couple days ago on another thread about X people were noting that to avoid the tearing Wayland seems to have higher latency, and some people (and I would be one of them, were I to experience this) care way more about lower latency than "never ever ever see tearing".
- sergeykish 6y ago> The compositor is evil > First, I want to make it clear that I’m not accusing the compositor of true evil, which I define roughly as deliberately causing suffering. There’s unfortunately too much of that in the world. I mean it in the more metaphorical sense that it causes serious problems and forces other parts of the system to be more complex to work around its limitations. https://news.ycombinator.com/item?id=24466929 https://news.ycombinator.com/item?id=24466929
- DCKing 6y agoI can't find the story you're talking about here, but one thing that would be good to understand here is whether this is some flaw in the Wayland protocol, or whether this is an implementation issue in a specific Wayland compositor like Gnome's Mutter. People tend to blame a lot of issues resulting from immature implementations on some unspecified "Wayland" (whatever that means). All I can find is that in the past Mutter had lower latency for its Wayland implementation when compared to it using X.org, but it seems that Mutter's latency story has always been iffy in the past. FWIW it seems that Sway for example has finely grained input latency tweaks built in while being Wayland compliant [1]. [1]: https://github.com/swaywm/sway/releases/tag/1.4 https://github.com/swaywm/sway/releases/tag/1.4
- CountSessine 6y ago...which was a peculiar discussion because I don't think anyone mentioned that just about everyone runs X today with some combination of DRI2 or DRI3, which involves plenty of latency, boundary-crossing, and buffer-copying.
- sergeykish 6y ago
- ldng 6y agoI'm really surprise at the tearing argument here. I've had Nvidia, AMD, Intel and Matrox graphic cards, sometimes on Intel other on AMD, so I've known tearing ... But that have been fixed for me with the introduction of double buffering and GL compositor. Waaaayyy before Wayland even existed. So that argument does not really fly with. Granted, internally those combo are ugly and clunky. And Wayland might have a cleaner design. But in the vast majority of cases, X11 implementations have worked for the end user. It certainly did for me. Wayland does not. I've never managed to have it working smoothly for me ! As a user (like in a user story you could say), I don't care that the Wayland protocol does not cover X11 protocol, I want my screengrabber and my video to just work. And if it is "cross-platform/desktop" the better. As a user I do not want a different set of bugs because I use a Gtk screengrabber and a Qt video editor and the Wayland team decided it was not in their scope to handle it. IMHO, sadly, it ends up in nobody's scope and/or in code duplication.