3 ms·

0. RDP is not as simple as sending draw commands. It has eg commands that correspond to scrolling regions of the screen to save on network use, a framerate limi

0. RDP is not as simple as sending draw commands. It has eg commands that correspond to scrolling regions of the screen to save on network use, a framerate limit (25fps I think) and allows some colour space reduction to reduce bandwidth too. I think it does a bunch of raster things (eg maybe caching floating windows like right-click menus). I think the windows server implementation can take advantage of information about the composition of the screen from windows. 1. There is some trade off of latency for bandwidth: it may take more time to figure out a small change to send over the network. Looking at api use from eg X may help with old apps that make small updates but more modern apps (or even modern fonts) which just render to gpu buffers and composite are less amenable to this. Very modern apps that use special apis to do lower latency scrolling/resize may be a little better. 3. A lot of the time for Linux the solution is to use ssh and terminal apps as they tend to make smaller updates and require less bandwidth. You can also try mosh to compensate for high latency connections. Text editors can work ok in terminals, especially fancy modern ones with eg mouse support. And for web things you can do set up a socks proxy over ssh which I think can work for a lot of apps which are really just web sites. So this may be part of the reason: fewer people see Remote Desktop as necessary. 4. I’ve had reasonable success with xrdp on the server and a windows client. One needed to select 32-but colour to get a better protocol version and turning off double-buffering in some apps (eg emacs) helped. But that was over a wired high bandwidth low latency connection.

mike_hock 4y ago
3 is the cart before the horse. "Real" terminal apps (i.e. command line utilities) are fine the way they are and you wouldn't use them any differently locally. They don't even need to care if stdout is a tty, and they reap all the benefits from a CLI because you can script them and pipe them into grep/awk/etc... But as soon as we skid into ncurses territory, we're stuck with ANSI terminal codes to make some sort of graphical UI. Those apps don't benefit from being in a terminal (e.g. you can't grep htop output), and there's obviously some desire to make something visually appealing. Using in-band magic escape codes from the 1970s with severely limited functionality for that is just a workaround for the lack of a standard remote desktop protocol that actually works, is reasonably efficient and SSH-friendly. Sure, the fact that you can make ncurses apps feeds back into complacency with the status quo, but that's always true. The enemy of great is good enough. The other alternative is making a web UI, which in principle has the right architecture (run the UI on the client side and only push/pull meaningful data to/from the server), but unfortunately that's tied to HTTP(s), which isn't exactly SSH-friendly. What we'd need is a transport-agnostic version of HTTP that can be given a socket and communicate with the server through that without demanding to know how to open more connections to the server and demanding that those connections be made through AF_INET or AF_INET6 sockets. So again, some server software is implemented as a web UI (like CUPS), but that's a workaround for the lack of something more straightforward that's also a de-facto standard.
- projektfu 4y ago
  I've tunneled web UI before with good results. For example, to remotely adjust syncthing settings. A slightly more user friendly way of setting up tunnels and service discovery would help.

mike_hock 4y ago

3 is the cart before the horse. "Real" terminal apps (i.e. command line utilities) are fine the way they are and you wouldn't use them any differently locally. They don't even need to care if stdout is a tty, and they reap all the benefits from a CLI because you can script them and pipe them into grep/awk/etc... But as soon as we skid into ncurses territory, we're stuck with ANSI terminal codes to make some sort of graphical UI. Those apps don't benefit from being in a terminal (e.g. you can't grep htop output), and there's obviously some desire to make something visually appealing. Using in-band magic escape codes from the 1970s with severely limited functionality for that is just a workaround for the lack of a standard remote desktop protocol that actually works, is reasonably efficient and SSH-friendly. Sure, the fact that you can make ncurses apps feeds back into complacency with the status quo, but that's always true. The enemy of great is good enough. The other alternative is making a web UI, which in principle has the right architecture (run the UI on the client side and only push/pull meaningful data to/from the server), but unfortunately that's tied to HTTP(s), which isn't exactly SSH-friendly. What we'd need is a transport-agnostic version of HTTP that can be given a socket and communicate with the server through that without demanding to know how to open more connections to the server and demanding that those connections be made through AF_INET or AF_INET6 sockets. So again, some server software is implemented as a web UI (like CUPS), but that's a workaround for the lack of something more straightforward that's also a de-facto standard.

projektfu 4y ago
I've tunneled web UI before with good results. For example, to remotely adjust syncthing settings. A slightly more user friendly way of setting up tunnels and service discovery would help.