4 ms·

In all fairness, my experience is that most of the issues are in the broader ecosystem at this point. Wayland, itself, is just a protocol. The display servers

In all fairness, my experience is that most of the issues are in the broader ecosystem at this point. Wayland, itself, is just a protocol. The display servers are just the display servers. But then you have Gtk and Gnome, Qt and KDE, software like Firefox and Chrome, etc. All of those have to updated as well, and while Wayland the protocol, the display servers, and a lot of the suite of infrastructure around it is in pretty good shape, the toolkits and clients and so forth all still need a lot of work. And you only need to look at the Python 3 transition to see how hard it is to shift a whole ecosystem. So I'm willing to cut the Wayland guys some slack. But it does mean there's still a ways to go, yet, before things are ready for prime time.

michaelmrose 6y ago
The perspective that wayland is just a protocol and doesn't need to address real issues is why it has so many of them to start with.
- CarelessExpert 6y ago
  That I completely agree with. The folks involved in designing the Wayland protocol seemed to have shed a lot of key features in the name of simplicity or security, forgetting that the solution actually has to meet real, human user needs. Those needs include things like screenshots and screensharing, global hotkey binding, etc, etc. To address that, we now have a range of extension protocols, which is creating fragmentation. The CSD-vs-SSD debate is a perfect example. Things are slowly coalescing--PipeWire is maturing, for example, filling some key gaps--but it's taking time and meanwhile IMO the ecosystem continues to be too immature for broad adoption.
  - taway098123 6y ago
    Screen sharing and screenshots weren't an afterthought. Weston had support for those for a long time, but gnome and kde decided to do something different, probably because they saw pipewire was maturing. Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Maybe someone will figure out a good way to do this but I wouldn't hold my breath. You're better off writing a compositor extension to do what you want. The CSD-vs-SSD debate isn't anything new, there were apps that used CSD before wayland, and there were X11 window managers that didn't draw any window decorations. There is fragmentation there but it's caused by the apps, you won't fix that one without rewriting all of them to have the same policy on decorations, probably that means redesigning all of them to use the same widget toolkit and designs.
    - zaat 6y ago
      > Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Is this feature standard on every OS in use by human kind today? Is this feature requested by most users and not having it pisses off most users? Is this feature available on the system that Wayland aims to replace?
      - taway098123 6y ago
        All of those questions are really irrelevant. The point with Wayland is to make something that's more secure than the systems it aims to replace, not to make exactly the same thing. If you want to help, maybe show a way this can be done without poking a huge security hole? Regarding pissed off users, in my experience most computer users are used to Microsoft Windows and get pissed off when things don't work exactly like that, so unless you work for Microsoft then it's a lost cause trying to please them all.
        michaelmrose 6y ago
        If you don't have any users you will soon find yourself without developers so it is in fact quite relevant.
        taway098123 6y ago
        That seems like the reverse of the way it's always been on Linux, where there are only developers and no users...
        zaat 6y ago
        I'm working with i3 (on X, obviously). Perhaps I'm diluted but my experience is that users of this setup are happy about their setup and love the system they use. I don't know of any way an Ethernet device can be truely secured, perhaps it should be disabled until a solution is found. I couldn't care less about a system that is more secure if it massively interfere with day to day usability.
kbumsik 6y ago
> Wayland, itself, is just a protocol That is the root of the problems IMO. The thing is, this design decision had made the ecosystem a lot harder to grow than X11/xorg.
- Zambyte 6y ago
  Maybe it has made is slower to grow, but harder? Now we have several dominant Wayland implementations including wlroots, Mutter, and KWin (the latter is still getting there from what I've heard). This is already 3x the number of dominant implementations of X11. Compositor developers can choose to use an existing implementation that suits their needs, or to develop one from scratch (that is compatible by implementing the same Wayland protocol). I think making Wayland just a protocol has made it easier to grow.
  - floatboth 6y ago
    Dominant compositor implementations – the dominant wayland implementation is libwayland :) About the only serious alternative is the Rust one – the crate has a native mode. (but you still have to use the libwayland backend if you want to do GL because of how Mesa's EGL impl is tied to… yeah, lol, hard problems here :D) But seriously, the "competition" between these compositors is awesome. This is like web standards again. Testing your client across different compositors reveals bugs (either in them, or in your client) and everything evolves together in standard ways. With the single Xorg server, everything got completely ossified, if anyone wanted to rewrite a full "production ready" X11 server they'd have to be bug-compatible with Xorg.

michaelmrose 6y ago

The perspective that wayland is just a protocol and doesn't need to address real issues is why it has so many of them to start with.

CarelessExpert 6y ago
That I completely agree with. The folks involved in designing the Wayland protocol seemed to have shed a lot of key features in the name of simplicity or security, forgetting that the solution actually has to meet real, human user needs. Those needs include things like screenshots and screensharing, global hotkey binding, etc, etc. To address that, we now have a range of extension protocols, which is creating fragmentation. The CSD-vs-SSD debate is a perfect example. Things are slowly coalescing--PipeWire is maturing, for example, filling some key gaps--but it's taking time and meanwhile IMO the ecosystem continues to be too immature for broad adoption.
- taway098123 6y ago
  Screen sharing and screenshots weren't an afterthought. Weston had support for those for a long time, but gnome and kde decided to do something different, probably because they saw pipewire was maturing. Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Maybe someone will figure out a good way to do this but I wouldn't hold my breath. You're better off writing a compositor extension to do what you want. The CSD-vs-SSD debate isn't anything new, there were apps that used CSD before wayland, and there were X11 window managers that didn't draw any window decorations. There is fragmentation there but it's caused by the apps, you won't fix that one without rewriting all of them to have the same policy on decorations, probably that means redesigning all of them to use the same widget toolkit and designs.
  - zaat 6y ago
    > Allowing arbitrary clients to globally capture keys at will is impossible to do without opening up a hole for keyloggers. Is this feature standard on every OS in use by human kind today? Is this feature requested by most users and not having it pisses off most users? Is this feature available on the system that Wayland aims to replace?
    - taway098123 6y ago
      All of those questions are really irrelevant. The point with Wayland is to make something that's more secure than the systems it aims to replace, not to make exactly the same thing. If you want to help, maybe show a way this can be done without poking a huge security hole? Regarding pissed off users, in my experience most computer users are used to Microsoft Windows and get pissed off when things don't work exactly like that, so unless you work for Microsoft then it's a lost cause trying to please them all.
      - michaelmrose 6y ago
        If you don't have any users you will soon find yourself without developers so it is in fact quite relevant.
        taway098123 6y ago
        That seems like the reverse of the way it's always been on Linux, where there are only developers and no users...
      - zaat 6y ago
        I'm working with i3 (on X, obviously). Perhaps I'm diluted but my experience is that users of this setup are happy about their setup and love the system they use. I don't know of any way an Ethernet device can be truely secured, perhaps it should be disabled until a solution is found. I couldn't care less about a system that is more secure if it massively interfere with day to day usability.

kbumsik 6y ago

> Wayland, itself, is just a protocol That is the root of the problems IMO. The thing is, this design decision had made the ecosystem a lot harder to grow than X11/xorg.

Zambyte 6y ago
Maybe it has made is slower to grow, but harder? Now we have several dominant Wayland implementations including wlroots, Mutter, and KWin (the latter is still getting there from what I've heard). This is already 3x the number of dominant implementations of X11. Compositor developers can choose to use an existing implementation that suits their needs, or to develop one from scratch (that is compatible by implementing the same Wayland protocol). I think making Wayland just a protocol has made it easier to grow.
- floatboth 6y ago
  Dominant compositor implementations – the dominant wayland implementation is libwayland :) About the only serious alternative is the Rust one – the crate has a native mode. (but you still have to use the libwayland backend if you want to do GL because of how Mesa's EGL impl is tied to… yeah, lol, hard problems here :D) But seriously, the "competition" between these compositors is awesome. This is like web standards again. Testing your client across different compositors reveals bugs (either in them, or in your client) and everything evolves together in standard ways. With the single Xorg server, everything got completely ossified, if anyone wanted to rewrite a full "production ready" X11 server they'd have to be bug-compatible with Xorg.