8 ms·

12to11 – run Wayland applications on an X server

93 points by Tiberium 2y ago

wkat4242 2y ago
Interesting. Until now the opposite has been more popular because there weren't many apps dedicated to Wayland but that will probably change now.
pmontra 2y ago
https://sourceforge.net/p/twelveto11/code/HEAD/tree/ https://sourceforge.net/p/twelveto11/code/HEAD/tree/ would be a better link. It still contains the README but it shows the sources and the timestamps, nothing more recent than November 2022. I wonder if it runs apps from the last 18 months. Furthermore, which Wayland only apps might I want to run on my X11 desktop?
- badsectoracula 2y ago
  I tried it some time ago using Qt's environment variable to force the Wayland backend but Qt crashes on startup.
- yjftsjthsd-h 2y ago
  > Furthermore, which Wayland only apps might I want to run on my X11 desktop? Waydroid? There aren't many Wayland-only apps, but they exist.
- natrys 2y ago
  Also doesn't weston have an x11 backend that can also do this? I believe KDE also has kwin_wayland. > which Wayland only apps might I want to run on my X11 desktop? I needed to look into this to run Waydroid[1], that's the only one I can think of. [1] https://waydro.id/ https://waydro.id/
  - nulld3v 2y ago
    I thought kwin_wayland was just KWin... for Wayland...
    - natrys 2y ago
      Probably yeah, I have no idea tbh. But it works for me on x11 too if you run it, and then launch wayland only programs like: XDG_SESSION_TYPE=wayland <app>
      - nolist_policy 2y ago
        XDG_SESSION_TYPE more of a hint thought. You actually have to do something like (export -n DISPLAY; <app>)
    - jchw 2y ago
      In Wayland, though, most of the compositors are also the entire display server. So you can run e.g. Mutter Wayland, kwin_wayland, weston, sway, etc. as an X11 client to varying degrees of success, and it looks and functions kind of like running a nested X server, just, with a Wayland server.
      - roenxi 2y ago
        Not, strictly speaking, on the topic that you were talking about but the display server has been broken up somewhat and compositors don't implement all of it. Compositors generally can't do some core functions that the XServer did - so we end up with the compositor acting as the part of the display server that managed ... compositing, funnily enough and display. But we also seem to need other servers like Pipewire's runtime to abstract Wayland clients as shareable objects.
        jchw 2y ago
        Yeah, that's true. Wayland is, of course, just a protocol (and some C libraries.) You can always implement Wayland compositing under a different display server or compositor, and the best example of that I am aware of is Arcan FE with its Wayland bridge. Even core functions of the Wayland server that are in the same process as the compositor may be split out to common libraries, and of course there are several compositor server libraries for different programming languages that provide the vast majority of the base functionality of a display server implementing the Wayland protocol, notably wlroots, Qt's own Wayland libraries, and Smithay. Wayland compositors generally also inherit large parts of what used to be the X server. Over the past couple of decades, the Linux graphics stack has massively expanded and refactored. X used to manage it all: modesetting, buffers, contexts; the graphics drivers were essentially XFree86/X.org drivers. Today, almost all of that has moved to the kernel and Mesa, in the process giving very powerful new primitives as well. It definitely came with a lot of pain, but it improved both what X.org was and what Wayland can become in the future. Likewise for the input stack: Linux evdev expanded and improved a lot and unified the format of event data from devices, but of course drivers were still needed to handle smoothing out the differences between devices. libinput is probably not everyone's favorite, but I'd say it does a pretty damn good job considering how broad its device support is. Pipewire is not strictly needed, but it is the defacto way to do screen capture on Wayland thanks to desktop portals. I think this is mostly because of GNOME/Mutter. The Mutter project is very cognizant about features and dependencies being put into the Mutter process itself, and seem to favor moving things out of the compositor process. Their approach to doing this in general seems to be by moving things into DBus servers, like the Desktop Portals system. Personally, I have some very mixed feelings about this situation, as could probably be seen based on my past interactions. DBus servers can be an awkward fit for some of this functionality; desktop portals are nominally executed as systemd user services, which as far as I know are typically per-user and not per-session, which would make e.g. nested Wayland sessions trickier. It would, of course, be possible for the Wayland protocols to handle things like this without it explicitly being "in-process", which I personally would prefer; I would prefer if the API doesn't have to map to the underlying structure of the desktop environment. I can definitely see how this is an additional burden and additional point of failure though, so I can't really claim to not understand it at all. It also has allowed Wayland, for better or worse, to side-step the issue of authorization. Instead, it can be handled using DBus, polkit, etc. Wayland is nominally a capabilities-based system, but with the caveat that it doesn't actually have a way to authorize or authenticate anything. As far as I know, there's no protocol to e.g. "ask permission", you just either get an object or you don't. All in all, the practical architecture of Wayland clients is... unique. I think it's pretty clear to anyone that it's a bit of a mess. Honestly, though, I am pretty happy for the groundwork that enables Wayland, as I think it is starting to bear fruit on things where there's just no way incremental improvements were going to get there. Definitely hope that some of the mess can be cleaned up in the future so that users (even power users) don't have to worry about understanding this architecture to do practical day-to-day work.
- Tiberium 2y ago
  It does run recent apps as long as they don't use the new Wayland protocols. I decided against that link because there are a lot of files before the actual README.
- ac130kz 2y ago
  The better question is why keep using X11, if XWayland works just fine.
  - yjftsjthsd-h 2y ago
    XWayland works just fine for applications; accessibility/automation tools and the like are a different story. (Ex. Want to write a script that finds a specific window and sends it keypresses? You're going to use X. Want to watch which window is focused to implement per-application keyboard layouts? X. Actually, want to set the keyboard layout dynamically at all on arbitrary window managers? Somehow Wayland doesn't do that. Once I almost started using a Wayland compositor, until I discovered that it didn't actually hook up the wlroots functions for setting keyboard layout; in X setxkbmap works everywhere.)
    - ac130kz 2y ago
      One can run an XWayland container transparently. Broadcasting keypresses is forbidden due to security reasons, nobody forbids patching it in as an extension. Setting keyboard layout dynamically is as easy as calling swaymsg with the required parameters, if a particular window is required instead, there's a protocol for that in hyprland. It all depends whether a particular window manager does it or not. Finally, I get that accessibility isn't best with Wayland, but it was not ideal with X11 either.
      - yjftsjthsd-h 2y ago
        > One can run an XWayland container transparently. That still only helps for applications (unless you mean just run a whole nested X session, in which case sure but that's not really using wayland). > Broadcasting keypresses is forbidden due to security reasons, nobody forbids patching it in as an extension. Nobody's writing that extension, either; as a user, X does what I want and Wayland doesn't and I'm not in a position to change that. > Setting keyboard layout dynamically is as easy as calling swaymsg with the required parameters, That appears to be just for sway? Or at least (from testing I just did) not all wlroots compositors support it. > if a particular window is required instead, there's a protocol for that in hyprland. It all depends whether a particular window manager does it or not. Exactly. In X, I could use whatever wm I wanted and all the same tools just kept working. In wayland, if I want to do anything interesting I appear to be stuck with sway or maybe hyprland. > Finally, I get that accessibility isn't best with Wayland, but it was not ideal with X11 either. Oh sure; X is a huge pile of hacks and ugly code, but it's a working pile of hacks and ugly code, and quite flexible at that, which is better than Wayland's elegant, well designed brokenness.
- donio 2y ago
  > Furthermore, which Wayland only apps might I want to run on my X11 desktop? A bit late to the thread but this tool is very much something I've been looking for! I want it not so much for current use cases but as a way of future-proofing my current setup since there is little hope that I will be replace it with Wayland anytime soon. I worry that a time might come when essential libraries and tools like gtk and web browsers might remove X11 support. I gave the tool a go and it builds easily and quickly and it was able to run what I've thrown at it so far. One of my concerns was selection/clipboard syncing but even that seems to be working as expected. It's nice that it doesn't even depend on wlroots which can be a bit of a moving target. It only uses the X11 libs and libwayland-server so I think it should be fairly future proof. Overall I think this is a much better solution than cage which was the best option I'd found previously.
yjftsjthsd-h 2y ago
> Wayland programs will then run as regular X windows. Well that'd be nicer than my current solution of running a whole Wayland compositor (usually cage) in a window under X. Of course, it's more work, but that is the usual tradeoff to make...
erik_seaberg 2y ago
Can a headless app talk GLX or EGL and render on the X server's GPU?
b112 2y ago
[flagged]
- rahen 2y ago
  I would hardly call modern X11 nicely conceived. It was nice in the 80s when everything was network transparent, X was indeed a graphic terminal for local or remote Motif apps, and everything handled by the xlib. It was then somewhat reminiscent of Rio although foreign and bolted on top of the system. Nowadays it's just a clunky mess of direct rendering interfaces bolted on top of legacy cruft from a long gone era. It's complex and inefficient.
  - lupusreal 2y ago
    X11 may be clunky, but it's familiar clunky which my tools and workflows are already set up for. I paid the cost incurred by X11's clunk many years ago and now I feel too old and weary to pay it again for Wayland. I no longer enjoy tinkering so I'm going to stick with what already works for me. If Wayland were such a great improvement overall that it didn't incur it's own clunky tax, then the situation might be different. On the contrary, Wayland is not only clunky but fragmented as well; hacks and workarounds for one compositor don't necessarily work for another, so if I switched to it I would be faced with the prospect of either figuring out numerous systems or picking one of them blind and hoping for the best.
    - lpapez 2y ago
      > I no longer enjoy tinkering so I'm going to stick with what already works for me. Absolutely feel the same way, I don't wanna work on my tools, I wanna work on my work. I picked up Linux because I was an enthusiast. Now I use it because Windows became unusable and Linux is actually the best option on the desktop. But I don't care about X11 or Wayland, I just want things to work without fuss - and they mostly do through decades of churn and cruft. In my world legacy cruft is vastly preferable to new problems.
      - prmoustache 2y ago
msk-lywenn 2y ago
Not to be confused with 11on12 which runs direct3d 11 apps on d3d12
patrakov 2y ago
Imakefile found, where a plain old Makefile could be sufficient. Yuck, another dependency on an obsolete piece of software (imake/xmkmf).
- cduzz 2y ago
  That's the X11 tool chain, icky as it may be, it is what it is. No reason to refactor a build environment "just because" Hey Makefiles? How quaint! You should use CMake! Hey CMake? How weird! You should use Maven like the rest of the company! Maven? Yuck! Why don't you simply and just use Makefiles instead of resume engineering? Make? Sheesh how do we deal with integrating different environments? It may be crusty but imake is perfectly suited to this task.
iforgotpassword 2y ago
Good to know this exists, so I can keep using what's been rock solid for me for the last decade for the foreseeable future.
- amelius 2y ago
  X has security issues. For example, an application that has access to your display can do stuff with other applications. For an interesting discussion, see: http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html http://theinvisiblethings.blogspot.com/2011/04/linux-securit...
  - phendrenad2 2y ago
    Well, that's unfortunate. Someone should fix that. Is anyone maintaining X11, or is there continuation fork?
  - welterde 2y ago
    There seems to be XACE/XSELinux, which seemingly exists in the mainline Xorg distro now. I wonder how the experience is with that? In practice I think it doesn't see any adoption, since most people don't run with SELinux or even AppArmor on their desktop and none of the applications run isolated from each other, so it doesn't matter that they all have full access to the X11 server. And for actual security there is qubes, which solves both the application isolation and the X11 security issue.
    - nolist_policy 2y ago
      Eh even if you secure the X11 API itself, your isolated app (browsers absolutely sandbox and isolate themselves from the rest of the system) will still share memory and have a socket open to an 33 year old c codebase (XOrg).
      - welterde 2y ago
        Not sure having shared memory and socket open to N fresh and under active feature development c codebases is that much more conducive to security? (N since while many compositors use wlroots there is still enough rope to hang yourself). To be fair, unless there is a exploitable bug in wlroots/lower wayland code, the blast-radius will be a lot more limited than if one is found in Xserver. I think the Qubes approach is the only one worth considering if one deeply cares about security.
actionfromafar 2y ago
Haha, the "cure" (Wayland) was administeread in such a weak dose over so long time, that the "pathogen" (X11) developed resistance and is now immune to Wayland applications!
- enriquto 2y ago
  In your analogy, if you set instead (more naturally I'd say) "x11=organism" and "wayland=pathogen", then you have exactly described a vaccine! Wayland's weak start allowed the system to develop a healthy immunity to it.
- samus 2y ago
  It was always possible to run Wayland applications via Weston, which has an X backend.
thiht 2y ago
I’m guessing 11 in the name is for X11, but why is Wayland 12? Wouldn’t a name like WtoX or WayToX be more useful? 2to3 made sense for Python 2 to 3, but using the same naming scheme is a bit weak, isn’t it?
- hmry 2y ago
  Wayland is X12, sort of. In the sense that it's developed by the same people as a successor, and they've stopped working on X11. It's much the same way that Vulkan is OpenGL 5. I've been told that's actually the reason it's called V ulkan. :) The name change prevents a Perl 6 situation I suppose.
  - josefx 2y ago
    More like a PHP 6 situation. People where pushing a protocol specification without implementation as if it would be ready to take over the Linux Desktop within a day or two.

93 points by Tiberium 2y ago

Interesting. Until now the opposite has been more popular because there weren't many apps dedicated to Wayland but that will probably change now.

pmontra 2y ago

https://sourceforge.net/p/twelveto11/code/HEAD/tree/ https://sourceforge.net/p/twelveto11/code/HEAD/tree/ would be a better link. It still contains the README but it shows the sources and the timestamps, nothing more recent than November 2022. I wonder if it runs apps from the last 18 months. Furthermore, which Wayland only apps might I want to run on my X11 desktop?

badsectoracula 2y ago
I tried it some time ago using Qt's environment variable to force the Wayland backend but Qt crashes on startup.
yjftsjthsd-h 2y ago
> Furthermore, which Wayland only apps might I want to run on my X11 desktop? Waydroid? There aren't many Wayland-only apps, but they exist.
natrys 2y ago
Also doesn't weston have an x11 backend that can also do this? I believe KDE also has kwin_wayland. > which Wayland only apps might I want to run on my X11 desktop? I needed to look into this to run Waydroid[1], that's the only one I can think of. [1] https://waydro.id/ https://waydro.id/
- nulld3v 2y ago
  I thought kwin_wayland was just KWin... for Wayland...
  - natrys 2y ago
    Probably yeah, I have no idea tbh. But it works for me on x11 too if you run it, and then launch wayland only programs like: XDG_SESSION_TYPE=wayland <app>
    - nolist_policy 2y ago
      XDG_SESSION_TYPE more of a hint thought. You actually have to do something like (export -n DISPLAY; <app>)
  - jchw 2y ago
    In Wayland, though, most of the compositors are also the entire display server. So you can run e.g. Mutter Wayland, kwin_wayland, weston, sway, etc. as an X11 client to varying degrees of success, and it looks and functions kind of like running a nested X server, just, with a Wayland server.
    - roenxi 2y ago
      Not, strictly speaking, on the topic that you were talking about but the display server has been broken up somewhat and compositors don't implement all of it. Compositors generally can't do some core functions that the XServer did - so we end up with the compositor acting as the part of the display server that managed ... compositing, funnily enough and display. But we also seem to need other servers like Pipewire's runtime to abstract Wayland clients as shareable objects.
      - jchw 2y ago
        Yeah, that's true. Wayland is, of course, just a protocol (and some C libraries.) You can always implement Wayland compositing under a different display server or compositor, and the best example of that I am aware of is Arcan FE with its Wayland bridge. Even core functions of the Wayland server that are in the same process as the compositor may be split out to common libraries, and of course there are several compositor server libraries for different programming languages that provide the vast majority of the base functionality of a display server implementing the Wayland protocol, notably wlroots, Qt's own Wayland libraries, and Smithay. Wayland compositors generally also inherit large parts of what used to be the X server. Over the past couple of decades, the Linux graphics stack has massively expanded and refactored. X used to manage it all: modesetting, buffers, contexts; the graphics drivers were essentially XFree86/X.org drivers. Today, almost all of that has moved to the kernel and Mesa, in the process giving very powerful new primitives as well. It definitely came with a lot of pain, but it improved both what X.org was and what Wayland can become in the future. Likewise for the input stack: Linux evdev expanded and improved a lot and unified the format of event data from devices, but of course drivers were still needed to handle smoothing out the differences between devices. libinput is probably not everyone's favorite, but I'd say it does a pretty damn good job considering how broad its device support is. Pipewire is not strictly needed, but it is the defacto way to do screen capture on Wayland thanks to desktop portals. I think this is mostly because of GNOME/Mutter. The Mutter project is very cognizant about features and dependencies being put into the Mutter process itself, and seem to favor moving things out of the compositor process. Their approach to doing this in general seems to be by moving things into DBus servers, like the Desktop Portals system. Personally, I have some very mixed feelings about this situation, as could probably be seen based on my past interactions. DBus servers can be an awkward fit for some of this functionality; desktop portals are nominally executed as systemd user services, which as far as I know are typically per-user and not per-session, which would make e.g. nested Wayland sessions trickier. It would, of course, be possible for the Wayland protocols to handle things like this without it explicitly being "in-process", which I personally would prefer; I would prefer if the API doesn't have to map to the underlying structure of the desktop environment. I can definitely see how this is an additional burden and additional point of failure though, so I can't really claim to not understand it at all. It also has allowed Wayland, for better or worse, to side-step the issue of authorization. Instead, it can be handled using DBus, polkit, etc. Wayland is nominally a capabilities-based system, but with the caveat that it doesn't actually have a way to authorize or authenticate anything. As far as I know, there's no protocol to e.g. "ask permission", you just either get an object or you don't. All in all, the practical architecture of Wayland clients is... unique. I think it's pretty clear to anyone that it's a bit of a mess. Honestly, though, I am pretty happy for the groundwork that enables Wayland, as I think it is starting to bear fruit on things where there's just no way incremental improvements were going to get there. Definitely hope that some of the mess can be cleaned up in the future so that users (even power users) don't have to worry about understanding this architecture to do practical day-to-day work.
Tiberium 2y ago
It does run recent apps as long as they don't use the new Wayland protocols. I decided against that link because there are a lot of files before the actual README.
ac130kz 2y ago
The better question is why keep using X11, if XWayland works just fine.
- yjftsjthsd-h 2y ago
  XWayland works just fine for applications; accessibility/automation tools and the like are a different story. (Ex. Want to write a script that finds a specific window and sends it keypresses? You're going to use X. Want to watch which window is focused to implement per-application keyboard layouts? X. Actually, want to set the keyboard layout dynamically at all on arbitrary window managers? Somehow Wayland doesn't do that. Once I almost started using a Wayland compositor, until I discovered that it didn't actually hook up the wlroots functions for setting keyboard layout; in X setxkbmap works everywhere.)
  - ac130kz 2y ago
    One can run an XWayland container transparently. Broadcasting keypresses is forbidden due to security reasons, nobody forbids patching it in as an extension. Setting keyboard layout dynamically is as easy as calling swaymsg with the required parameters, if a particular window is required instead, there's a protocol for that in hyprland. It all depends whether a particular window manager does it or not. Finally, I get that accessibility isn't best with Wayland, but it was not ideal with X11 either.
    - yjftsjthsd-h 2y ago
      > One can run an XWayland container transparently. That still only helps for applications (unless you mean just run a whole nested X session, in which case sure but that's not really using wayland). > Broadcasting keypresses is forbidden due to security reasons, nobody forbids patching it in as an extension. Nobody's writing that extension, either; as a user, X does what I want and Wayland doesn't and I'm not in a position to change that. > Setting keyboard layout dynamically is as easy as calling swaymsg with the required parameters, That appears to be just for sway? Or at least (from testing I just did) not all wlroots compositors support it. > if a particular window is required instead, there's a protocol for that in hyprland. It all depends whether a particular window manager does it or not. Exactly. In X, I could use whatever wm I wanted and all the same tools just kept working. In wayland, if I want to do anything interesting I appear to be stuck with sway or maybe hyprland. > Finally, I get that accessibility isn't best with Wayland, but it was not ideal with X11 either. Oh sure; X is a huge pile of hacks and ugly code, but it's a working pile of hacks and ugly code, and quite flexible at that, which is better than Wayland's elegant, well designed brokenness.
donio 2y ago
> Furthermore, which Wayland only apps might I want to run on my X11 desktop? A bit late to the thread but this tool is very much something I've been looking for! I want it not so much for current use cases but as a way of future-proofing my current setup since there is little hope that I will be replace it with Wayland anytime soon. I worry that a time might come when essential libraries and tools like gtk and web browsers might remove X11 support. I gave the tool a go and it builds easily and quickly and it was able to run what I've thrown at it so far. One of my concerns was selection/clipboard syncing but even that seems to be working as expected. It's nice that it doesn't even depend on wlroots which can be a bit of a moving target. It only uses the X11 libs and libwayland-server so I think it should be fairly future proof. Overall I think this is a much better solution than cage which was the best option I'd found previously.

yjftsjthsd-h 2y ago

> Wayland programs will then run as regular X windows. Well that'd be nicer than my current solution of running a whole Wayland compositor (usually cage) in a window under X. Of course, it's more work, but that is the usual tradeoff to make...

erik_seaberg 2y ago

Can a headless app talk GLX or EGL and render on the X server's GPU?

b112 2y ago

[flagged]

rahen 2y ago
I would hardly call modern X11 nicely conceived. It was nice in the 80s when everything was network transparent, X was indeed a graphic terminal for local or remote Motif apps, and everything handled by the xlib. It was then somewhat reminiscent of Rio although foreign and bolted on top of the system. Nowadays it's just a clunky mess of direct rendering interfaces bolted on top of legacy cruft from a long gone era. It's complex and inefficient.
- lupusreal 2y ago
  X11 may be clunky, but it's familiar clunky which my tools and workflows are already set up for. I paid the cost incurred by X11's clunk many years ago and now I feel too old and weary to pay it again for Wayland. I no longer enjoy tinkering so I'm going to stick with what already works for me. If Wayland were such a great improvement overall that it didn't incur it's own clunky tax, then the situation might be different. On the contrary, Wayland is not only clunky but fragmented as well; hacks and workarounds for one compositor don't necessarily work for another, so if I switched to it I would be faced with the prospect of either figuring out numerous systems or picking one of them blind and hoping for the best.
  - lpapez 2y ago
    > I no longer enjoy tinkering so I'm going to stick with what already works for me. Absolutely feel the same way, I don't wanna work on my tools, I wanna work on my work. I picked up Linux because I was an enthusiast. Now I use it because Windows became unusable and Linux is actually the best option on the desktop. But I don't care about X11 or Wayland, I just want things to work without fuss - and they mostly do through decades of churn and cruft. In my world legacy cruft is vastly preferable to new problems.
    - prmoustache 2y ago

msk-lywenn 2y ago

Not to be confused with 11on12 which runs direct3d 11 apps on d3d12

patrakov 2y ago

Imakefile found, where a plain old Makefile could be sufficient. Yuck, another dependency on an obsolete piece of software (imake/xmkmf).

cduzz 2y ago
That's the X11 tool chain, icky as it may be, it is what it is. No reason to refactor a build environment "just because" Hey Makefiles? How quaint! You should use CMake! Hey CMake? How weird! You should use Maven like the rest of the company! Maven? Yuck! Why don't you simply and just use Makefiles instead of resume engineering? Make? Sheesh how do we deal with integrating different environments? It may be crusty but imake is perfectly suited to this task.

iforgotpassword 2y ago

Good to know this exists, so I can keep using what's been rock solid for me for the last decade for the foreseeable future.

amelius 2y ago
X has security issues. For example, an application that has access to your display can do stuff with other applications. For an interesting discussion, see: http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html http://theinvisiblethings.blogspot.com/2011/04/linux-securit...
- phendrenad2 2y ago
  Well, that's unfortunate. Someone should fix that. Is anyone maintaining X11, or is there continuation fork?
- welterde 2y ago
  There seems to be XACE/XSELinux, which seemingly exists in the mainline Xorg distro now. I wonder how the experience is with that? In practice I think it doesn't see any adoption, since most people don't run with SELinux or even AppArmor on their desktop and none of the applications run isolated from each other, so it doesn't matter that they all have full access to the X11 server. And for actual security there is qubes, which solves both the application isolation and the X11 security issue.
  - nolist_policy 2y ago
    Eh even if you secure the X11 API itself, your isolated app (browsers absolutely sandbox and isolate themselves from the rest of the system) will still share memory and have a socket open to an 33 year old c codebase (XOrg).
    - welterde 2y ago
      Not sure having shared memory and socket open to N fresh and under active feature development c codebases is that much more conducive to security? (N since while many compositors use wlroots there is still enough rope to hang yourself). To be fair, unless there is a exploitable bug in wlroots/lower wayland code, the blast-radius will be a lot more limited than if one is found in Xserver. I think the Qubes approach is the only one worth considering if one deeply cares about security.

actionfromafar 2y ago

Haha, the "cure" (Wayland) was administeread in such a weak dose over so long time, that the "pathogen" (X11) developed resistance and is now immune to Wayland applications!

enriquto 2y ago
In your analogy, if you set instead (more naturally I'd say) "x11=organism" and "wayland=pathogen", then you have exactly described a vaccine! Wayland's weak start allowed the system to develop a healthy immunity to it.
samus 2y ago
It was always possible to run Wayland applications via Weston, which has an X backend.

thiht 2y ago

I’m guessing 11 in the name is for X11, but why is Wayland 12? Wouldn’t a name like WtoX or WayToX be more useful? 2to3 made sense for Python 2 to 3, but using the same naming scheme is a bit weak, isn’t it?

hmry 2y ago
Wayland is X12, sort of. In the sense that it's developed by the same people as a successor, and they've stopped working on X11. It's much the same way that Vulkan is OpenGL 5. I've been told that's actually the reason it's called V ulkan. :) The name change prevents a Perl 6 situation I suppose.
- josefx 2y ago
  More like a PHP 6 situation. People where pushing a protocol specification without implementation as if it would be ready to take over the Linux Desktop within a day or two.