Comment by enriquto | Hacker News Reader

Comment by enriquto | Hacker News Reader

Parent Full thread

> 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.

See: 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.

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

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.

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.

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.

> 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.

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?

> 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?

No, they often can't. Things like Flatpak make it so apps have no unnecessary access to the filesystem.

Fortunately, things like snap and flatpak are still fringe projects with no realistic perspectives for a widespread adoption. Which would be ridiculous, anyway: why would you want all the programs in /usr/bin to be isolated "apps"?

I run most of my GUI stuff out of flatpaks now, it's pretty great. Run the latest releases on a stable LTS with no dependency problems.

Pretty much any accessibility or automation software suffers here without having to be a root. Wayland makes accessibility impossible is developer with its fragmentation. Want to make tools that work across now Wayland ecosystem good luck with that.

> Pretty much any accessibility or automation software suffers here without having to be a root

Even with root they'll have a harder time; there's a difference between "I can trivially tell the X server to give me details about events and then interact with arbitrary windows in arbitrary ways" vs "by running as root, I can watch raw input events come in from the mouse/keyboard and then try to figure out what they mean".

It’s almost like there are layers to security. You don’t have to be root, but nor should any random npm install script be able to steal keystrokes and send them away. While we are it, linux desktop security just sucks all around.

adding mouse gestures with easystroke

Reply on news.ycombinator.com