8 ms·

> I still use X11, where and rely on the following features To which I would add: (1) taking screenshots from the command line (xwd) (2) moving windows aroun

> I still use X11, where and rely on the following features To which I would add: (1) taking screenshots from the command line (xwd) (2) moving windows around from the command line (xwit) (3) keyboard-free copy-paste between different programs: select to copy, middle-click to paste (4) global indicator of where my cursor is (xeyes) (5) define global key combinations that launch programs (xbindkeys) (6) globally configure the keyboard in a particular way, key by key, not according to some pre-configured "language" (setxkbmap, xmodmap, xkbset) (7) set keyboard repeat/delay to absurdly unusable values (xset) (8) run graphical programs from a headless virtual machine (ssh -X) I do not mind whether I'm running x11 or wayland, but I care a lot for all these features that are crucial to my workflow. How likely is it that items (1)--(8) will be supported somehow under wayland? I'm a bit concerned that wayland gives a lot of attention to things that are meaningless to me (tearing, scaling, etc), and does not care at all about these basic usability features.

deleted 4y ago
[deleted]
gbil 4y ago
adding mouse gestures with easystroke
from 4y ago
See: https://news.ycombinator.com/item?id=32297479 https://news.ycombinator.com/item?id=32297479 None of these discussions ever go anywhere. They will tell you that wlroots is standardizing all these things etc etc but as it stands today every compositor is at best reimplementing a subset of the features you describe. If I had enough money I would pay the Wayland people to work on something else and let the project collapse because they are constantly undermining the reasons I use Linux on the desktop.
- QEIAo7BCrzKtYQ 4y ago
  That post is some pretty bad misinformation. An API for global keyboard shortcuts was being worked on and just got merged 2 months ago. https://github.com/flatpak/xdg-desktop-portal/issues/624 https://github.com/flatpak/xdg-desktop-portal/issues/624 There is a way to protect against LD_PRELOAD: use sandboxing. X11 is bad for security because it's an intentional escape around the sandbox. The "tear it down and build something else argument" is also going nowhere, anything else you build is going to run into the same questions of how to go about implementing these features.
WhyNotHugo 4y ago
Most of these things work fine (though with wayland-specific tools, rather than X-specific tools), except: > (4) global indicator of where my cursor is (xeyes) AFAIK, no tool allows you to do this. The issue is: clients generally can't snoop on input when they're not in foreground (e.g.: to make key-loggers less trivial). A privileged client could do this using something like layer-shell. It's a hack, but it should work. Somebody needs to write it tho. > (5) define global key combinations that launch programs (xbindkeys) Compositors implement this themselves for the above reason. > (8) run graphical programs from a headless virtual machine (ssh -X) I guess this should work with XWayland? Keep in mind, most X applications work via XWayland. This means normal applications; xbindkeys or xeyes won't work since they rely on reading input when other applications are in foreground.
- enriquto 4y ago
  Thanks for your answers! It's reassuring that most things will still be possible. Still, xeyes is the favorite program of my kid who is starting to learn linux... I'd have a hard time selling wayland to him. > to make key-loggers less trivial Really? Is that a serious reason? Key-loggers are still very much possible because any program can read the memory of all other running programs of the same user. This seems to me like a pointless limitation that creates a lot of unnecessary complexity. But what do I know.
  - exitheone 4y ago
    > Really? Is that a serious reason? Key-loggers are still very much possible because any program can read the memory of all other running programs of the same user. That's not true. Reading other processes memory requires root even for processes of the same user.
    - enriquto 4y ago
      I was going to reply in an impulsive manner (saying, derisively "so how does strace work, then? and why can you attach gdb to already running processes?"). But it turns out that you are right! Well, at least in modern ubuntu/fedora desktop installs, a few years ago they disabled the ptrace(2) system call. ("The maniacs! They did it!", I'm tempted to cry in anger.) You can still read children processes, but unless you change the yama defaults in the kernel, ptrace(2) no longer works for processes that are not children. I didn't notice because I surely have changed this default in my old laptop because I use ptrace daily. But you are right that modern linuxes are likely thus crippled. Still, it seems that an attack model based on defending against a rogue user process is quite doomed. Can't this process change the init files of other programs that will run, even if they aren't its children?

deleted 4y ago

[deleted]

gbil 4y ago

adding mouse gestures with easystroke

from 4y ago

See: https://news.ycombinator.com/item?id=32297479 https://news.ycombinator.com/item?id=32297479 None of these discussions ever go anywhere. They will tell you that wlroots is standardizing all these things etc etc but as it stands today every compositor is at best reimplementing a subset of the features you describe. If I had enough money I would pay the Wayland people to work on something else and let the project collapse because they are constantly undermining the reasons I use Linux on the desktop.

QEIAo7BCrzKtYQ 4y ago
That post is some pretty bad misinformation. An API for global keyboard shortcuts was being worked on and just got merged 2 months ago. https://github.com/flatpak/xdg-desktop-portal/issues/624 https://github.com/flatpak/xdg-desktop-portal/issues/624 There is a way to protect against LD_PRELOAD: use sandboxing. X11 is bad for security because it's an intentional escape around the sandbox. The "tear it down and build something else argument" is also going nowhere, anything else you build is going to run into the same questions of how to go about implementing these features.

WhyNotHugo 4y ago

Most of these things work fine (though with wayland-specific tools, rather than X-specific tools), except: > (4) global indicator of where my cursor is (xeyes) AFAIK, no tool allows you to do this. The issue is: clients generally can't snoop on input when they're not in foreground (e.g.: to make key-loggers less trivial). A privileged client could do this using something like layer-shell. It's a hack, but it should work. Somebody needs to write it tho. > (5) define global key combinations that launch programs (xbindkeys) Compositors implement this themselves for the above reason. > (8) run graphical programs from a headless virtual machine (ssh -X) I guess this should work with XWayland? Keep in mind, most X applications work via XWayland. This means normal applications; xbindkeys or xeyes won't work since they rely on reading input when other applications are in foreground.

enriquto 4y ago
Thanks for your answers! It's reassuring that most things will still be possible. Still, xeyes is the favorite program of my kid who is starting to learn linux... I'd have a hard time selling wayland to him. > to make key-loggers less trivial Really? Is that a serious reason? Key-loggers are still very much possible because any program can read the memory of all other running programs of the same user. This seems to me like a pointless limitation that creates a lot of unnecessary complexity. But what do I know.
- exitheone 4y ago
  > Really? Is that a serious reason? Key-loggers are still very much possible because any program can read the memory of all other running programs of the same user. That's not true. Reading other processes memory requires root even for processes of the same user.
  - enriquto 4y ago
    I was going to reply in an impulsive manner (saying, derisively "so how does strace work, then? and why can you attach gdb to already running processes?"). But it turns out that you are right! Well, at least in modern ubuntu/fedora desktop installs, a few years ago they disabled the ptrace(2) system call. ("The maniacs! They did it!", I'm tempted to cry in anger.) You can still read children processes, but unless you change the yama defaults in the kernel, ptrace(2) no longer works for processes that are not children. I didn't notice because I surely have changed this default in my old laptop because I use ptrace daily. But you are right that modern linuxes are likely thus crippled. Still, it seems that an attack model based on defending against a rogue user process is quite doomed. Can't this process change the init files of other programs that will run, even if they aren't its children?