4 ms·
Wayland has a lot of problems, but they're adoption problems. 1) Wayland isn't a replacement for all of X.org. It's a replacement for much of X11, the protocol
by DCKing 7y ago
Wayland has a lot of problems, but they're adoption problems.
1) Wayland isn't a replacement for all of X.org. It's a replacement for much of X11, the protocol. "Wayland is just a protocol" - there's no wayland binary on your computer like there is an xorg binary. All the problems/limitations people commonly perceive with Wayland are actually problems/limitations within Wayland implementations like Mutter (Gnome) or KWin (KDE) and lacking application support. There's really not that much that "Wayland" as a project could deliver as it's just a protocol [1]!
2) Replacing something like your entire graphics stack requires a widespread, coordinated effort to unify the various Linux distro's under it. That widespread coordinated effort is not actually possible in the (by "design") extremely fragmented Linux market. The only approach is to slowly let Wayland implementations evolve, and there we have it.
Hot take: Wayland will not fully replace X11 the coming 10 years. There is no fundamental solution to the two problems above. Many popular desktops (Xfce, Cinnamon) have no plan to support Wayland at all. Some don't even want to. In the future, there will be choices for graphics stacks on Linux leading to further fragmentation.
[1]: The projects that should deliver here are: Gnome, KDE, other open source desktops. Although I think using Gnome with Wayland is superior in many ways to X11, it still has certain quite major shortcomings. It's also application toolkits: Qt and Gtk work luckily, but Electron is waiting for some Chrome renovations before supporting Wayland, and then there's stuff like Wine and Java where the refactor/reward balance simply doesn't favor them. And sometimes applications have to be updated to stop relying on using hardcoded X11 stuff, and use agnostic Gtk/Qt/Freedesktop functionality.
There's a lot of history with X11 that we have to move away from, and the incentives and coordination only allow for slow movement.
- deleted 7y ago[deleted]
- sprash 7y ago> Wayland has a lot of problems, but they're adoption problems. No they are deep philosophical problems. The lack of necessary protocols that allow a unified implementation for things like screen sharing, hotkey daemons, window managers, xdotools or clipboard managers are the problem. As long as there is no standardized way to do essential tasks that are typical for a desktop use case Wayland will eternally cause problems.
- DCKing 7y agoYou're not describing a philosophical problem of "what's possible", as all of these things are perfectly possible on a desktop with Wayland and broader Freedesktop standards, and many have working examples currently. Wayland being as small as it is, is not supposed to be a restriction on features of your entire desktop. But there's no standard interopability with a standard X11 socket anymore. There's interopability with KWin and Mutter and wlroots and a bunch of other things through FreeDesktop standards (Wayland being among them). You might consider it a philosophical problem that Wayland is not trying to solve all the problems that X11 tried to solve. You might attach a lot of philosophical value to that architecture. But Windows, macOS, ChromeOS and Android seem to be doing extremely well on an architecture that is a lot less like X11 and a lot more like Wayland.
- zlynx 7y ago> things like: > screen sharing: - Security problem, untrusted access to display, explicitly denied by design. > hotkey daemons - Security problem, untrusted input, denied by design. > window managers - Messing about with windows without authorization, denied by design. > xdotools - Untrusted input. > clipboard managers - Untrusted access to clipboard. Either the compositor application has to do it, or it has to delegate it to a trusted application. So yeah, deep philosophical problems. If you wanted Wayland to work exactly like X11 it won't because that is explicitly against its security design.
- DCKing 7y agoAll these security arguments are pure figments of your imagination. They are not based in reality at all. Wayland is trying to do less than X11. The things you mention are not solved at the display protocol level on any platform but X11. Your security strawman never comes in to play.
- AnIdiotOnTheNet 7y ago> Security problem Yeah, it's not like anyone needs that functionality to do work or anything. In fact, why not just refuse to boot the computer in the first place? That'll stop a lot of security problems.
- nirvdrum 7y agoThanks for clarifying more of what Wayland is. I was really hoping for a better remote desktop solution on Linux and had high hopes Wayland would deliver on that. My understanding is it doesn't, but is that something a compliant implementation could add as extended functionality? Or is that all wishful thinking? Sometimes I boot my Linux native installation as a raw disk VM in Windows 10 with VMware Workstation and then use Windows's remote desktop. That is surprisingly more responsive and a better overall experience than either VNC, X2Go, or X11 forwarding can deliver. I'd love to see something on par for Linux desktops.
- DCKing 7y agoThis is possible, but it requires application support. As a user it is therefore extremely painful and limited still. Standards and libraries for this have only recently become available, and only the first applications are adapting towards it. The nice thing is that these new standards and libraries should support both X11 and Wayland equally as I understand it. Why is this taking so long on the """Wayland desktop"""? Screen sharing/remote desktop is a problem that Wayland as a protocol does not try to solve (this problem is also not solved by the display protocols on any other platform for the record). And because of that, it requires central coordination in the Linux world to standardize solve. And central coordination in the Linux world always turns out to be a total mess.
- yjftsjthsd-h 7y ago> All the problems/limitations people commonly perceive with Wayland are actually problems/limitations within Wayland implementations like Mutter (Gnome) or KWin (KDE) and lacking application support. There's really not that much that "Wayland" as a project could deliver as it's just a protocol In practice if all/most implementations are buggy, I think it's fair to lump them all together and say that Wayland (as used by the software actually running on my machine) has problems. You know the meme about how whenever someone tries Desktop Linux and has trouble, someone pops up and says "just use this other distro, with this particular set of software and this exact configuration, and it'll just work!"? Wayland feels like that. Sure, if I want to go all in on GNOME (on Fedora), it'll probably work. Sure, if I use Sway with the right set of compatible programs it'll work. But... I could also just stay on X where all my programs work now with no tinkering, where I can drop in any screenshot program, any clipboard manager, any screen sharing program, any keyboard configuration/emulation tool (I'm really fond of xdotool), and it will work.
- DCKing 7y ago> In practice if all/most implementations are buggy, I think it's fair to lump them all together and say that Wayland. Fair enough. I think it's a bit unfair to label the collective failure of the Linux community/ecosystem to actually make change happen as "Wayland has problems". But it's true that in 2020 you will still lose use cases when using anything Wayland based. Wayland will never replace the X11 based workflows you describe though, because it isn't X11. Although X11 has a lot of fundamental problems, flexibility isn't one. And some flexibility you will have to give up moving to any Wayland based desktop.
- StillBored 7y agoWhich is yet another case of fix the problems with the existing stack rather than creating a new one. Yah, you don't get to be a hero, and product arch, etc for making X work better. I have yet to see a convincing argument that X couldn't have been made more secure by bolting on another opt-in extension. Then once in place, like GL ES, you start deprecating all the features used by basically no-one.
- DCKing 7y agoI don't understand your post, nobody mentioned security in this discussion?
- bigger_cheese 7y agoOne of the big issues is there is a heap of legacy cruft in the existing X Stack which makes trying to fix/enhance X difficult. From what I understand the way it is written not easy to cleanly depreciate certain features like you've suggested. So I can totally see the appeal for a clean break from having to maintain strict backwards compatibility with a stack that has its roots in the 1980's.