3 ms·
> There's nothing inherently preventing any of these things from working on Wayland. In theory that is correct. In practice, the Wayland protocol fails to addr
by sprash 7y ago
> There's nothing inherently preventing any of these things from working on Wayland.
In theory that is correct. In practice, the Wayland protocol fails to address the required access control policy interfaces necessary for a modern Desktop to work. A Desktop is not a phone interface or a car entertainment system. Resource sharing that enables basic things like push-to-talk, remote work or full screen streaming are absolutely essential for a Desktop computing environment. Wayland developers push such functionality down as a particular "implementation detail" of a Wayland compositor, which is a huge mistake. Donating to braindead projects like wlroots will not solve the problem at all. Access control policy needs to be made part of the core protocol ASAP or Wayland will have no chance to succeed in any meaningful way in the future.
- alxlaz 7y agoThat's really not how Wayland development works. Except for resource management and data transfer (wl_compositor, wl_shm_pool etc.), pretty much everything in the "core" Wayland protocol has originated in compositor implementations that were then standardized. "Donating to braindead projects like wlroots" is exactly how this problem is going to be solved. There's no Wayland cabal where people just sit around a table writing specifications in the hope that they'll eventually get implemented somewhere. This is pretty much how X11 was built, too, by the way.
- sprash 7y ago> That's really not how Wayland development works Maybe then Wayland should change "how Wayland developement works" because after 10 years of developement the results are disappointing to say the least. Projects like the Arcan display server show that even a single dude writing stuff in his spare time can easily be more productive.
- alxlaz 7y agoIt's a development model that worked reasonably well for the X protocol. Wayland isn't great now but it's not much worse than X was in 1994, after 10 years of development (and the first version of X11, which saw the light of day in 1987 or so, was pretty different from the early drafts of the X protocol). There was no ICCCM back then (ok, there was ICCCM 1.0 but that wasn't anywhere near great or universal), no session management, no xkb, no xdamage, no Xinerama, no hotplug, no glx, no randr... It helped that there were a bunch of big players sinking lots of money into it, and the documentation was good enough that it was easy to get started -- way easier than it is with Wayland. So after 1993 or so things really started picking up speed. But Xfree cca. 1994 wasn't great.
- sprash 7y ago> It's a development model that worked reasonably well for the X protocol. The development of early X11 didn't work very well at all. Even Keith Packard himself says so [1]. 1.: https://www.youtube.com/watch?v=cj02_UeUnGQ https://www.youtube.com/watch?v=cj02_UeUnGQ
- alxlaz 7y agoMost of the bad parts that Keith Packards covers are about the pre-X11 days. But yeah, Wayland is developed more or less like X11 was developed after the mid '90s or so. The difference is that there isn't much commercial involvement on the desktop side. SGI, DEC, HP, Sun, IBM, and later Red Hat & friends, sank quite some money into X's development, and a non-zero amount of that money ended up going into a particular implementation (XFree, later Xorg) and in developing desktop solutions on top of it. Most of that money stream is flowing towards other things than desktops now. Desktop Wayland development is largely a hobby effort (there are some exceptions, but nowhere near as many as in the heyday of X11, and not all of these efforts apply throughout the Wayland "universe"). That may eventually change as Xorg's maintenance will eventually stop, since no one really wants to do that anymore...
- ddalex 7y agoWayland doesn't have a chance anyhow because * Very few actually interesting programs run natively on it * As such the push to improve is largely political * Leading to low effort commitment outside the orgs that push it * Which deters developers for actually porting stuff to it As such you end up with half baked PoCs that doesn't incentivize anybody to move them forward while X is still working better by far. In short, there is no compelling reason for anybody to switch platforms. It's a solution looking for a problem.