There shouldnt be x11/xorg nor xwayland, either wayland or no land.
Otherwise we gonna face the loop of legacy and unwanted vulnerabilities.
Will be considered during: port to Wayland - Development - Whonix Forum
1 Like
For the Trixie port, removing Xwayland does not look possible without switching to a resource-heavy desktop environment or using hacks:
- There seem to be very few desktops that are fully ready for Wayland in Debian Trixie. GNOME is ready, KDE is ready, LXQt is ready enough (still some rough edges but they can mostly be papered over). XFCE is missing critical functionality and is too buggy. Cinnamon and Budgie are likely too immature and are potentially resource-heavy anyway. So in practical terms, it’s LXQt or nothing if we want to port to Wayland for Trixie.
- LXQt supports quite a few compositors (Labwc, KWin, Wayfire, Hyprland, Sway, River and Niri), but of those, KWin is a resource-heavy KDE component, and everything other than labwc and wayfire are beginner-unfriendly tiling compositors. Wayfire does not appear to support software rendering in Trixie, making it unusable in VirtualBox at least in my initial testing, so we’re limited to labwc (which is the recommended compositor for LXQt anyway).
- labwc in Trixie is unable to start without XWayland installed: Degrade gracefully when built with xwayland support but it isn't available during runtime · Issue #434 · labwc/labwc · GitHub Attempting to remove Xwayland and start labwc results in:
The only options I can see moving forward are:
- Allow XWayland but attempt to restrict all apps to using Wayland instead of X if possible
- Attempt to kill XWayland after session start and hope it doesn’t come back
- Replace XWayland with some dummy binary that can fool labwc into thinking it’s there
Further research into making a fake XWayland binary will probably occur, but we should be ready for this to not work.
Also, spice-vdagent (which provides clipboard sharing and mouse integration under KVM) requires XWayland to be running in order to function. Theoretically we could document how to enable XWayland for users who depend on those features, but in general, not having them is a serious usability issue. (We’re facing similar issues with VirtualBox, which still needs investigation.)
2 Likes
from my perspective all of the above desktop environments are moving towards Wayland support in a relatively good way. We don’t like GNOME because of previous privacy concerns, and we don’t like KDE because of resource consumption. The other two we could live with, the only reason we can’t live with XFCE is because the developers aren’t all that fast at porting since they have lives to live too.
I thought about Budgie, but 10.9 only has preliminary (i.e. experimental) Wayland support, which insinuates it will probably be as rough or worse than XFCE in Trixie.
I’m not sure how much of this is unfounded supersition and how much of it is reasonable wariness, but Kylin and Kylin-related projects scare me. Kylin (which openKylin is the open-source variant of) ss state-funded by China as I understand it, and China’s current government is, to put it mildly, not particularly well-known for its commitment to privacy or user freedom. I don’t necessarily mind using software that is Chinese in origin if it’s well-respected by the global community, but something state-sponsored… it’s kind of like using encryption algorithms designed by the NSA; even if they look good on the surface, there’s probably a backdoor. I fear the same could be true here too.
This fear is further enhanced by the fact that another Linux desktop environment with ties to the Chinese government, Deepin, was removed from openSUSE because of a mixture of semi-malicious packager behavior and the code being a security disaster under the hood. I don’t have any particular reason to trust Kylin more than Deepin, and wouldn’t be surprised if the code was similarly horrible.
Aside from the privacy and security concerns, I’ve used Kylin very briefly doing testing for Ubuntu, and found the English in several spots to be too broken to be comfortably usable. Since Kicksecure and Whonix are primarily targeted towards English-speaking users, I don’t think this would be a good fit.
2 Likes
Thats what i shortcut into one word.
Awesome then, i had the same conclusions.
If LXQt with dummy xwayland will work, not a bad idea, nice workaround.
Well, I tried dummy Xwayland, and it almost worked…
Note the panel is missing. It actually does show up eventually but it requires a configuration change to get it to appear (or so it seems), it’s frozen when it appears, it takes a good few minutes for it to appear, it lags heavily, and it’s otherwise not usable. labwc itself doesn’t seem to have any issues with the setup, and a lot of the rest of LXQt is fine with it, but the panel is not happy at all. Not sure what part of it is using X11, but something’s using it, or so it seems… After it finishes freezing intermittently for several minutes, it works pretty well.
The /usr/bin/Xwayland binary is literally just:
#!/bin/bash
sleep infinity
I think we’re going to have to go with Xwayland at least this development cycle. It’s still a major step in the right direction even if we haven’t reached perfection yet.
2 Likes
Is there any way to restrict KDE or GNOME? You’ve already implemented user separation, and Sysmaint severely limits the system. Maybe now KDE could be a great option, which would put an end to all the Wayland issues. I understand that desktop minimalism is very important, but how suitable is LXQt for Linux users who mainly use GNOME and KDE now? And how important is resource consumption compared to the security of Wayland when separating users? It could save you a lot of time by not having to reinvent solutions with the unpopular and inconvenient LXQt.
This is the development sub-forum.
Before participating in a development discussion, please ensure you have thoroughly reviewed the entire thread. For example, a link to https://forums.whonix.org/t/port-to-wayland/17380 was already provided, where the topic of GNOME/KDE is explicitly discussed.
From that thread:
It’s probably not a port to GNOME. Reasons: Dev/GNOME - Whonix
That link now redirects to:
Reading that page alone should make it clear why GNOME is not being considered.
This will be formalized here:
Development Discussion Expectations
1 Like
part of Calamares without XWayland:
Related… Port to Wayland was done in version 18.
2 Likes