They always said they could have easily integrated Luca like features but no, ofc we need to pick the option with millions of marketing money behind it instead of waiting for a privacy focused version.
If the submission was for Sway, it would be equally sad that it was bound to 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 boot straight into the console and then have a setup where I either run startx or start_sway.
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 :)
> I boot straight into the console and then have a setup where I either run startx or start_sway
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?
:) literally no reason other than curiosity and a strong will to get that yak shaved.
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.
Wayland has a bad case of security at the cost of usability. They've been adding protocols here and there but there are still obvious things missing. Last time I checked it wasn't even possible to create something like xdotool without relying on some nasty hacks.
And on top of that the “security” is useless because any software that runs as one's user account can simply do things such as ptrace the compositor or override the compositor in the PATH with a malicious one or LD_PRELOAD the compositor. As soon as malicious software run as one's own user, then that is that and it can do anything that the user can do.
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.
You are forgetting that you actually can sandbox and contain apps. Under X11, doing that and then giving the app access to the display is dangerous. Under Wayland it is not. This matters for Flatpak, Snap, firejail, etc.
I have seen multiple such arguments that you can “sandbox” X11 access, with no proof or really bad compromises; I don’t believe it.
> You are forgetting that you actually can sandbox and contain apps. Under X11, doing that and then giving the app access to the display is dangerous. Under Wayland it is not. This matters for Flatpak, Snap, firejail, etc.
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 Waylandper sē: naturally things that need access don't work, and Nvidia card acceleration does not work.
What Firejail supports is nested X servers, which are complicated and often buggy. Last I checked Firejail itself only recommended using X11 sandboxing when dealing with hostile situations.
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.
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.
"Last time I checked it wasn't even possible to create something like xdotool without relying on some nasty hacks."
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.
It greatly annoys me that wayland still doesn't have any solutions for synergy/barrier type software. I depend on it daily for using my desktop and laptop and it's tedious to make the switch as it currently is.
I made a program called rkvm which works on a level below display servers (works with uinput directly) and thus doesn't suffer from these problems. Currently, it only supports Linux and Windows, where only client support is implemented on Windows, but it works well for my use case.
I've been meaning to try out barrier. How do you like it? Is it responsive/fast? I had synergy running across linux/mac machines a number of years ago and it wasn't super reliable back then..
I have been using synergy for 6 or 7 years. Barrier the past year. It works reliably, more so then synergy, and I'm typing this reply through barrier right now :) It also fixes a few quirks I had like xorg screen changes wasn't reflected in synergy and it would start having weird boundaries.
Sway is nice. Mostly a better i3, with great mouse support, easy multiple keyboard config, some aesthetic features, ... even the small tools around like swayidle, swaylock are fine.
Yep. I've been using sway for a year now and I like it more than i3. When I switched to wayland I also dumped nvidia which has generally been great, but I have had several problems with the Intel drivers, unfortunately. I run the stable kernel.org kernel and currently need to patch it so it works. But I'd rather run a system that I can fix then one I can't.
Sway works with any GPU that implements the proper API on Linux. Nvidia has a bad case of NIH syndrome and does their own thing independent from other GPU manufacturers.
So it would be more accurate to say Nvidia does not do sway.
there's some cool stuff in the works but it doesnt sound like there's a plan to internalize the work into devtools but to keep it as a web app and rely on a serviceworker for "localness" - not great, imo.
My impression as a web user is that if any devs actually use the performance inspector it's just to learn their site is slow and then not do anything about it.
Your devs might develop perfectly well behaving stuff just to see it get totally obliterated by loading 3 external tracking scripts through Tag Manager, three different pixels and 7 external contact form/chat bots/newsletter popover scripts from their CRM/ad platform/whatever crap marketing wants.
Sadly noone cares what the performance inspector says. Newspapers just get slower and slower. Our local newspaper takes 15 seconds to first visible paint and another 5-10 seconds to usefulness on my phone...
See https://github.com/corona-warn-app/cwa-documentation/blob/ma... for details on how they do it.