Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Wayland is the poster child for a rewrite that tries to be 'simple' and in doing so over-complicates this by under specification. Other commenters have mentioned that usability extension issues but I wanted to discuss my experience as someone who maintains their own wayland client (for drawterm: https://github.com/9front/drawterm).
There are plenty of technical differences between how KDE, Gnome, and Wlroots that just cause more work for me. Perhaps most popularly Gnome is dying on the hill of "child size decorations", meaning that without mostly Gnome specific code you will get no title bar. KDE and Wlroots do upscaling different, KDE upscales with video in mind, Wlroots upscales with text in mind. There is no way to specify how a client would like this upscaling to be done, so to get consistent display you have to do the upscaling yourself. Some other minor annoyances include having to implement key repeat yourself, and no standard way for programs to cause a mouse movement.
Like this article mentions I use wayland because it's the "only game in town", but after porting drawterm I became fairly unimpressed with the technical design.
Sensitive features like screenshots, input methods, screen locking and whatnot are behind extensions (or portals). I'm not familiar with the state of GNOME/KDE/Flatpak, but at least on the wlroots side of things it is true that currently these extensions are enabled and accessible by any process that can talk to the Wayland socket (breaking those security benefits, as you say). This is changing with protocols such as security-context that allow a sandbox engine like Flatpak (or your custom scripts) to restrict what features apps can use. (so your browser can't register an input method, or some random app can't lock the screen)
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
https://github.com/swaywm/sway/pull/7648
https://github.com/flatpak/flatpak/pull/4920
Sensitive features like screenshots, input methods, screen locking and whatnot are behind extensions (or portals). I'm not familiar with the state of GNOME/KDE/Flatpak, but at least on the wlroots side of things it is true that currently these extensions are enabled and accessible by any process that can talk to the Wayland socket (breaking those security benefits, as you say). This is changing with protocols such as security-context that allow a sandbox engine like Flatpak (or your custom scripts) to restrict what features apps can use. (so your browser can't register an input method, or some random app can't lock the screen)
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
https://github.com/swaywm/sway/pull/7648
https://github.com/flatpak/flatpak/pull/4920