undefined | Better HN

0 pointstgflynn3y ago0 comments

I'm not sure what you mean. X can certainly run a full remote desktop, or at least it could, I'm not sure how well it works with current versions of KDE and Gnome.

If you mean connect remotely to a desktop that someone else is using on another machine, yes that is indeed a different use case.

0 comments

3 comments · 1 top-level

saurik3y ago· 2 in thread

I mean the latter, as I maintain the former isn't useful. The people who want to remote desktop into their Windows computer generally aren't asking about this feature so they can simply get fresh access to a remote computer as that's generally not how remote desktop is configured: it is so they can leave all of their programs running on the remote computer and get remote access to it.

dixie_land3y ago

how is the former not useful? At end of the day there's some app you're running on that RDP session right? X simply allows you to run that app remotely and display it locally.

Eg, my kvm (virtualization) host runs RHEL and no desktop environment, but I can easily run virt-manager using X forwarding over SSH when I'm creating a new VM and a GUI is easily than writing a domain XML

In face I've forwarded virt-manager to Linux, macOS (XQuartz) and Windows (WSL w/ X server)

saurik3y ago

I mean, OK, it isn't never useful: maybe you are sitting at a computer that really doesn't have the power to do the thing you want to do, or maybe the thing you want to do really needs access to very large files and it is better to run the computation next to the data.

However, this isn't why people want to use the "remote desktop" protocol. The app that I'm accessing over RDP isn't something I'm running after I connect to RDP: virtually all of the time it is an app that has been running for weeks and will remain running for weeks to come.

I am using my computer right now, after having woken up from a nap. This computer is doing all the things I left it doing when I went to take that nap. It has a bunch of state for all of these running applications, and if every time I walked away from my computer all of that state disappeared, I'd be annoyed, as I want to be able to sit down at my computer and do five minutes of work and then go off and do something else and come back and do five minutes more of work.

This is the primary use case for the remote desktop protocol: I leave a bunch of software running on my desktop and then I go somewhere else and I can remotely log in to my desktop and see all of my running programs. If I have spotty wifi and I only manage to get connected for 30 seconds before I get disconnected, I can just reconnect and everything is exactly where it was as I wasn't logging to run anything: I'm accessing things that are already running.

So, no: "at the end of the day" these are fundamentally different use cases, and the former use case simply isn't something I feel like I ever want to do. Hell: it isn't even what I generally want with a terminal! (I had always set myself up so I had running static screen sessions going that I'd remotely connect into, and then I use either autossh or a little bash function running ssh in a loop to reconnect to that remote screen session so when I open my laptop it steals my terminal from wherever I was using it last to my local display.)

The premise of remote desktop connections is something which kind of changes how you use your computer: once you try it and get used to it, you start to treat the terminal you are at as a commodity, as every computer not only has access to your files but every computer has the same state and let's you immediately jump right in to where you left off with your work. In contrast, I'd claim the use cases where you want to, while you are out, run an app on a computer you aren't at is a niche use case.

3 more replies

j / k navigate · click thread line to collapse