10 ms·

The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve perform

The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve performance there, and bring some of the security benefits of those setups to other distributions.

jude- 6y ago
Seems to me that firewalling X11 programs from one another would take a lot less work and be a lot less disruptive than requiring users to run multiple VMs with multiple X11 servers and/or replace the whole graphics stack.
- cycloptic 6y ago
  Maybe that's true if that's your only concern, but there are other reasons to replace X11 than just this. Also, X11 is arguably not the whole graphics stack, at this point the DRM/Mesa piece is much larger and more significant, and Wayland doesn't replace it outright anyway -- it makes it optional if needed for backwards compatibility, in the same way that macOS has XQuartz.
  - jude- 6y ago
    The other two concerns in GP are no screen tearing, and better hidpi / multi-monitor support. Is it truly less work and less disruptive to address these to concerns within X11 than it is to throw X11 out (and also leave all nvidia users high and dry)? Also, keep in mind that throwing X11 out and replacing it will take more than just technical legwork -- it will also take ecosystem buy-in and standardization, and if we're being honest with ourselves, this is the harder problem. Recall that the X11 ecosystem has a 30-year head start on this, and there's a crap-ton of 3rd party software that assumes an X11 environment that Wayland is going to need to emulate. If X11 does indeed go the way of the dodo, I think we can reasonably expect another 30 years of bug reports in the form of "Fuck Wayland! I upgraded to Wayland and my $IMPORTANT_THING broke!". I very much doubt that at the end of the day the switch to Wayland is going to be overall easier than just fixing X11, but would love to be convinced otherwise.
    - cycloptic 6y ago
      The usual way to fix other concerns like that has been to add more WM atoms or add more X extensions, which is a similarly uphill battle requiring buy-in and standardization, and typically old X clients just won't be updated to support those new things. The way to get the most value out of such things would be to add support to the major toolkits, but those have already been ported to Wayland for some years now. The backwards compatibility is done through XWayland which functions similarly to XQuartz, in that it is just the Xorg server running using Wayland as a backend driver.
      - jude- 6y ago
        What do you think is more of an uphill battle, in terms of time and energy sunk? Adding another X extension that can be incrementally deployed, or trying to phase X out by maintaining both an X11 and Wayland back-end for all apps trying to avoid breakage? This doesn't even speak to X11 apps that aren't built with toolkits (for example, I use xterm, xpdf, xfig, Openbox, etc.). XWayland is a nice idea, don't get me wrong. But it's not a 100% replacement either. Distros offering XWayland are even up-front about it's shortcomings [1][2][3]. [1] https://wiki.debian.org/Wayland https://wiki.debian.org/Wayland [2] https://docs.fedoraproject.org/en-US/quick-docs/debug-wayland-problems/ https://docs.fedoraproject.org/en-US/quick-docs/debug-waylan... [3] https://wiki.archlinux.org/index.php/wayland#XWayland https://wiki.archlinux.org/index.php/wayland#XWayland
        cycloptic 6y ago
        There isn't much difference there, but it would be more of an uphill battle if you tried to put everything different that Wayland does into X extensions. That still requires maintaining an extra code path for old X servers that don't support the new extensions, and creates additional risk of breaking things and causing regressions in the X server because of all the new code you're adding. Clients like term, xpdf, and xfig should work fine in XWayland. Window managers won't work without getting ported, but someone has been working on a port of Openbox: https://github.com/johanmalm/labwc https://github.com/johanmalm/labwc
- tux1968 6y ago
  Trying to shoehorn proper security into X11 would be a formidable effort and still be quite disruptive to client software. Back when Wayland was just being proposed there were not a lot of developers working on X. They almost-unanimously agreed that it was time to break with backward compatibility and eject a lot of cruft that had built up over the years, such as the horrible font handling. Modern toolkits had already started moving away from using many of these X11 facilities and were doing much more client side anyway. So the argument was that a relatively clean slate design was called for which should dispense with the cruft and better handle client-side rendering. It's not perfect and I know it is disruptive for some people, but at least here it has led to a much better experience for some years now.
  - jude- 6y ago
    Would addressing the "firewalling" issue be more disruptive than throwing out X11? Because, Wayland definitely firewalls programs (among many other things) -- surely just implementing firewalling in X11 is not nearly as difficult or disruptive? Implementing firewalling could even be done in an incremental way that's easily reverted or tailored to individual apps and users.
    - tux1968 6y ago
      I'm no expert in the X11 codebase, but I have lots of respect for the guys who were working on it at the time the Wayland direction was undertaken. So I don't feel in a position to second guess their opinion or tremendous contributions, especially since it has led to a much better experience than I ever had with X.
      - jude- 6y ago
        That doesn't make them infallible. If anything, Wayland smells like yet another instance of CADT [1]. Like, why can no one explain why a world-breaking change like Wayland is justified, when the problems Wayland solves seem like they could be addressed by repairing X11? I'm honestly interested in building a better X11, and am willing to contribute both time and money. But first, I'd like to understand why the X11 maintainers deemed Wayland necessary -- like, what am I missing here? [1] https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html

jude- 6y ago

Seems to me that firewalling X11 programs from one another would take a lot less work and be a lot less disruptive than requiring users to run multiple VMs with multiple X11 servers and/or replace the whole graphics stack.

cycloptic 6y ago
Maybe that's true if that's your only concern, but there are other reasons to replace X11 than just this. Also, X11 is arguably not the whole graphics stack, at this point the DRM/Mesa piece is much larger and more significant, and Wayland doesn't replace it outright anyway -- it makes it optional if needed for backwards compatibility, in the same way that macOS has XQuartz.
- jude- 6y ago
  The other two concerns in GP are no screen tearing, and better hidpi / multi-monitor support. Is it truly less work and less disruptive to address these to concerns within X11 than it is to throw X11 out (and also leave all nvidia users high and dry)? Also, keep in mind that throwing X11 out and replacing it will take more than just technical legwork -- it will also take ecosystem buy-in and standardization, and if we're being honest with ourselves, this is the harder problem. Recall that the X11 ecosystem has a 30-year head start on this, and there's a crap-ton of 3rd party software that assumes an X11 environment that Wayland is going to need to emulate. If X11 does indeed go the way of the dodo, I think we can reasonably expect another 30 years of bug reports in the form of "Fuck Wayland! I upgraded to Wayland and my $IMPORTANT_THING broke!". I very much doubt that at the end of the day the switch to Wayland is going to be overall easier than just fixing X11, but would love to be convinced otherwise.
  - cycloptic 6y ago
    The usual way to fix other concerns like that has been to add more WM atoms or add more X extensions, which is a similarly uphill battle requiring buy-in and standardization, and typically old X clients just won't be updated to support those new things. The way to get the most value out of such things would be to add support to the major toolkits, but those have already been ported to Wayland for some years now. The backwards compatibility is done through XWayland which functions similarly to XQuartz, in that it is just the Xorg server running using Wayland as a backend driver.
    - jude- 6y ago
      What do you think is more of an uphill battle, in terms of time and energy sunk? Adding another X extension that can be incrementally deployed, or trying to phase X out by maintaining both an X11 and Wayland back-end for all apps trying to avoid breakage? This doesn't even speak to X11 apps that aren't built with toolkits (for example, I use xterm, xpdf, xfig, Openbox, etc.). XWayland is a nice idea, don't get me wrong. But it's not a 100% replacement either. Distros offering XWayland are even up-front about it's shortcomings [1][2][3]. [1] https://wiki.debian.org/Wayland https://wiki.debian.org/Wayland [2] https://docs.fedoraproject.org/en-US/quick-docs/debug-wayland-problems/ https://docs.fedoraproject.org/en-US/quick-docs/debug-waylan... [3] https://wiki.archlinux.org/index.php/wayland#XWayland https://wiki.archlinux.org/index.php/wayland#XWayland
      - cycloptic 6y ago
        There isn't much difference there, but it would be more of an uphill battle if you tried to put everything different that Wayland does into X extensions. That still requires maintaining an extra code path for old X servers that don't support the new extensions, and creates additional risk of breaking things and causing regressions in the X server because of all the new code you're adding. Clients like term, xpdf, and xfig should work fine in XWayland. Window managers won't work without getting ported, but someone has been working on a port of Openbox: https://github.com/johanmalm/labwc https://github.com/johanmalm/labwc
tux1968 6y ago
Trying to shoehorn proper security into X11 would be a formidable effort and still be quite disruptive to client software. Back when Wayland was just being proposed there were not a lot of developers working on X. They almost-unanimously agreed that it was time to break with backward compatibility and eject a lot of cruft that had built up over the years, such as the horrible font handling. Modern toolkits had already started moving away from using many of these X11 facilities and were doing much more client side anyway. So the argument was that a relatively clean slate design was called for which should dispense with the cruft and better handle client-side rendering. It's not perfect and I know it is disruptive for some people, but at least here it has led to a much better experience for some years now.
- jude- 6y ago
  Would addressing the "firewalling" issue be more disruptive than throwing out X11? Because, Wayland definitely firewalls programs (among many other things) -- surely just implementing firewalling in X11 is not nearly as difficult or disruptive? Implementing firewalling could even be done in an incremental way that's easily reverted or tailored to individual apps and users.
  - tux1968 6y ago
    I'm no expert in the X11 codebase, but I have lots of respect for the guys who were working on it at the time the Wayland direction was undertaken. So I don't feel in a position to second guess their opinion or tremendous contributions, especially since it has led to a much better experience than I ever had with X.
    - jude- 6y ago
      That doesn't make them infallible. If anything, Wayland smells like yet another instance of CADT [1]. Like, why can no one explain why a world-breaking change like Wayland is justified, when the problems Wayland solves seem like they could be addressed by repairing X11? I'm honestly interested in building a better X11, and am willing to contribute both time and money. But first, I'd like to understand why the X11 maintainers deemed Wayland necessary -- like, what am I missing here? [1] https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html