Sadly it's bound to X11.
The alternative for me was to migrate to sway[1] to have a similar environment in wayland.
The alternative for me was to migrate to sway[1] to have a similar environment in wayland.
I think projects like this should link each other as alternatives though, to aid in discovery. Since they are for different protocols, I don't think they will lose anything by linking their "competitor".
I can see that sway mentions and links to i3, but I can't see anything similar from i3. Not sure if they haven't noticed it or if they are not fond of it.
I love i3 and it was my first experience with tiling WM years ago. It is absolutely a radical break for me from all other WM's since tiling allows me to work in deep focus many desktops, 1 desktop per activity/task and my focus always on one thing not many.
Also wanting not to miss out on the future I moved to sway in parallel. I am literally in sway 90% of the time. The only difference is if I have to use video / webRTC screensharing or similar (usually in the browser), in which case sway will not work. This is why I maintain a dual system of both i3/sway.
Also I trust i3 to be more stable for when I am standing in front of a crowd or have to connect my system to a variety of different external beamers, monitors etc.
It sounds nuts to "maintain" 2 WM's but my configuration and workflow never deviates no matter which system I use even across upgrades of i3/sway.
When I plug in a new freshly installed machine I just fetch my dotfiles and have both i3/sway in exactly the same way as I'm used to ... It's incredibly easy keeping both around if one has to (or wants to). Bonus of sway is also that it has gaps support (which is cool on bigger screens, less important on laptops).
edit: both sway / i3 gave me no problems at all running them under restrictive environments such as LD_PRELOAD=libhardened_malloc.so (from GrapheneOS) and also work with under firejail without problems. I'll stop since it's anyway clear I am a big fan of both :)
Screensharing under sway works fine with firefox and chromium through xdpw.
Interesting, I do the same thing but just use startx. I find it hard to find convincing reasons to move from X apart from it 'being dead,' which isn't very convincing to me. What benefits to you get from sway in your setup? Is it compatible with things like ssh X forwarding?
I don't hink X is dead for a while. There is a lot of reasons for application devs not to support sway unless a strong enough user-base from that camp justifies the effort. Consider also that some of the heavy lifting previously done by X is being offloaded to Sway.
My motivation to switch to it was because Sway claims that you can just drop in your .config/i3/config and sway will be compatible to it. (it's pretty close).
What I wanted was transparency (not via a clunky workaround like compton). Also a system that takes less of my resources while in use to also roll it out on 10 or 15 year old machines I own. Sway delivers here and also has less issues with screen tearing than X with my card.
Literally everything I needed previously worked in Sway (often with different commands, e.g. wofi instead of rofi, or grim for screenshots, Waybar instead of Polybar, etc)
anything else like tmux, ssh-forwarding and all things in the terminal work perfectly.
The argument raised against this is that it should be used in conjunction with some measure of a sandboxing technique, and that X11 is “impossible to sandbox”, but X11 sandboxes exist: how they work is a proxy server that sits in between the sandboxed application and the real server that determines what to let through and what not, the sandboxed application thus believes it is the only thing running inside of it's own X11 server, which maps it onto the bigger one.
Then the counter argument is that that “doesn't count” and isn't “true sandboxing”, but that is the exact same technique that sandboxes that use Wayland use for say DBus, or PulseAudio, and has always been the standard way of sandboxing such daemons and servers.
That's always the highly theoretical argument that comes in to defend these promises that are false on a practical level “it doesn't count”, even though the practical result is the same.
All the ways to circumvent Wayland's security “don't count” even though they can all the same be used to compromise it.
I am quite convinced after having spoken with many a Wayland developer that nigh none of them actually care about the “security” they so often talk about: they care about a certain theoretical elegance of a “secure system" that only exists in theory but exists in no reality as something that actually has been practically realized. All the actual, effective, real world ways to pierce it are wished away with that they “don't count” as they don't exist in their theoretical dream world.
I have seen multiple such arguments that you can “sandbox” X11 access, with no proof or really bad compromises; I don’t believe it.
I addressed this in my very post and forgot no such thing.
Firejail can and does sandbox X11.
> I have seen multiple such arguments that you can “sandbox” X11 access, with no proof or really bad compromises; I don’t believe it.
How is there no proof? it exists in Firejail at this moment..
The compromises are those which one has to live with on Wayland per sē: naturally things that need access don't work, and Nvidia card acceleration does not work.
https://firejail.wordpress.com/documentation-2/x11-guide/
This existed and happened long ere Wayland was even conceived.
I consider having to use a nested X server, even one capable of forwarding, a huge compromise based on my experience with it.
Anyway, that did not exist before Wayland was even conceived. First of all, hardware acceleration in Xpra has been a relatively rocky story for a long time. Second of all, Firejail didn’t support using it until 2016.
If you want to keep buying borderline Linux-incompatible video cards and running an unmaintained display server, by all means try to jam a security model onto an inherently insecure client-server system to help justify it. As cold as it may be, the world will happily leave you behind. And if you don’t believe me, just keep waiting. Lots of people thought Macromedia Flash would stick around forever, too.
As in, a form of sandboxing.
> which are complicated
They are no more complicated than every other proxied daemon, as my original post very much explained.
> and often buggy.
Then I'm sure you can provide me with such a bug.
> Last I checked Firejail itself only recommended using X11 sandboxing when dealing with hostile situations.
Then I'm sure you can cite this recommendation.
> I consider having to use a nested X server, even one capable of forwarding, a huge compromise based on my experience with it.
I'm sure that you can come with an actual concrete example of a problem, because when I used it it simply appears as if the application normally ran in it's Window, and I would not be able to tell the difference had I not known.
> Anyway, that did not exist before Wayland was even conceived. First of all, hardware acceleration in Xpra has been a relatively rocky story for a long time. Second of all, Firejail didn’t support using it until 2016.
The first Firejail beta releases itself was in 2014, long after Wayland was first conceived.
The first Xpra release was in 2008, however.
> If you want to keep buying borderline Linux-incompatible video cards and running an unmaintained display server, by all means try to jam a security model onto an inherently insecure client-server system to help justify it. As cold as it may be, the world will happily leave you behind. And if you don’t believe me, just keep waiting. Lots of people thought Macromedia Flash would stick around forever, too.
I'm sure you'll tell the next man that proved you wrong that you “never saw proof” as well, and he will provide proof too, which you will just as dismiss with vague arguments of “It's buggy and a huge compromise, but I won't provide any specifics on which bugs, and which compromises.”
People that actually think that Wayland is the “future” that will replace X11 with this constant “features that many users need are insecure and they really don't need them.” are a laughter. As of this moment most user interfaces haven't even tried an attempt to make a Wayland port and aren't interested; the only noteable ports are KDE, GNOME, Sway, and Enlightenment, two of which had to add back many of the cut features to make their system work, but had to do so in incompatible, nonstandardized ways.
It must have been around 2013 when I first heard talk about how Wayland was ready and would leave X11 behind, and adoption hasn't increased much since then.
Well, there's ydotool for Wayland, but unfortunately it doesn't even have half the features of xdotool, and probably won't be improving much any time soon, since its README says "Since Jun, 2019, I have little time to maintain this project".
At this rate, it'll probably take another 10 or 20 years for Wayland to catch up to all the already-existing useful features of X.
The most difficult part was to find a good wayland terminal and I recommend “foot”, https://codeberg.org/dnkl/foot
So it would be more accurate to say Nvidia does not do sway.