6 ms·

Sadly Sway is bound to wayland.

by q3k 6y ago

Foxboron 6y ago
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.
- SubGenius 6y ago
  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..
  - Foxboron 6y ago
    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.
    - SubGenius 6y ago
      Ah good. Thanks, I'll give it a go today!
- trefil 6y ago
  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. https://github.com/htrefil/rkvm https://github.com/htrefil/rkvm
  - Foxboron 6y ago
    Need server on windows and client on linux so this won't work properly yet for me.
emptyparadise 6y ago
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.
- Blikkentrekker 6y ago
  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.
  - jchw 6y ago
    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.

Sadly Sway is bound to wayland.

by q3k 6y ago

Sadly Sway is bound to wayland.

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.

SubGenius 6y ago
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..
- Foxboron 6y ago
  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.
  - SubGenius 6y ago
    Ah good. Thanks, I'll give it a go today!
trefil 6y ago
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. https://github.com/htrefil/rkvm https://github.com/htrefil/rkvm
- Foxboron 6y ago
  Need server on windows and client on linux so this won't work properly yet for me.

emptyparadise 6y ago

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.

Blikkentrekker 6y ago
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.
- jchw 6y ago
  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.