Shoestring doesn't even begin to cover it. Buying computers was definitely out. So I hit on the idea of buying used Wyse Winterms. Winterms are thin clients that talk either RDP or Citrix ICA. These could be had for about $20 a pop on eBay. I would hit local pawn shops, thrift stores and recycling places to get monitors and keyboards to go with them.
But they're just dumb terminals with Windows CE on them. How to actually use them?
I set up a Linux system with xrdp and a bunch of X sessions for the Winterms to talk to. Took a lot of fiddling to get it right. Like I probably spent two weeks in the evenings getting everything right. But even I was surprised how well it worked. With a full-screen web browser in kiosk mode it shaved massive amounts of time off how long it took to get through the reg line.
We actually used that setup for about three years before we had enough money to invest in better hardware. Over that time I'd estimate about 8,000 people used them. But I'll always have a soft spot for those stupid Winterms and xrdp.
Then I hit upon the idea of using them as even more dumb terminals. So I set up a PXE server that would serve an NFS volume hosting a minimal Linux distro and setting those winterms to boot via DHCP.
Surprisingly those winterms not only supported Linux but ran it really well.
This system ran for several years until those old green screens were replaced with web front ends instead. Which made me sad for two reasons, firstly the end of the PXE solution which works so smoothly, and secondly seeing the old green screen server decommissioned, which was a Sun SPARC box bought in the 90s and had an uptime of something ridiculous like 8 years.
These days the same software (now used at a number of conventions) is used with mobile devices and the need for having convention-provided kiosks has slowed quite a bit.
People still forget their passwords all the time.
Is the difference between RDP and xforwarding basically RDP is giving you a video of the remote display and sending the mouse clicks + XY position top? Vs xfowarding which natively renders the buttons and such and in the button example sending signal that a particular button got clicked?
I imagine a trade off is more security vulnerabilities with xforwarding? Does some have more incite into this?
For those who haven't used it and want to try it, you install "xpra" on your Linux box with "yum" or "apt", then fire up an xpra server with "xpra start" (or "nohup xpra start &"), then make a note of which extra display it has added (like ":1"). It's not replacing the display manager (as far as I'm aware).
Download a windows client from xpra.org, then connect through SSH. Once connected, you get a small icon in the Windows taskbar with lots of menu options. Under the "Start" option, you have sub-menus which give you access to all the Linux desktop programs on the target machine.
For example, I use XPRA to connect to my Ubuntu 20.04 laptop and run "Start -> Accessories -> Terminal Emulator". It opens an XFCE4 terminal on my Windows desktop, looking as if it was a native Windows application. In the terminal, I can type "thunar" and a new Thunar file manager window will open on the Windows desktop, or "xemacs" for a text editor.
It's very fast because it's only sending 1 window at a time, not the whole desktop. I can disconnect, then re-connect and the windows will re-appear as I had left them.
It's not perfect (some dialog boxes don't respond to mouse clicks), but it is worth playing with.
Rough X vs Xpra sketch:
display <-> X server | <----X proto-----> | app
display <-> Xpra client | <---h264/input---> | Xpra server <-X proto-> app
That's not at all how RDP works, that's how VNC works. RDP basically considers your display (and sound, clipboard and devices) as though they were connected to the server. Have a 4k display locally but only some crappy 1024x768 relic connected to the server? Doesn't matter, you can have a 4k desktop. Cut from your local stuff and paste to your remote stuff. Print from a remote program to your local printer. Configuration is just a few checkboxes.
VNC over SSH should be as secure as you need, but it's never likely to be as performant as RDP.
In the 90's when everything was made of lines and rectangles, you're right that this deep integration made RDP perform much much better.
Now though, nearly all applications are composited bitmaps (webviews, opengl surfaces, etc). There isn't much scope for sending the raw draw calls over the wire anymore, and instead using some video codec to send the surfaces as bitmaps, and then compositing on the client is about the best you can do.
VNC doesn't even do that though...
In all seriousness though it's useful if you use VNC just to remote monitor a screen and want to leave it open indefinitely.
Also RDP uses TCP and UDP which makes it bad for SSH tunnelling, as opposed to VNC which is TCP only and easy to tunnel.
With TCP multi-megabyte buffers can end up forming and when you've shoved data into TCP there's no way to cancel sending it.
- Compile it yourself. The package that comes with your distribution is bad and has things like copy/paste disabled.
- Configuration of authentication takes some effort.
Wow, using xrdp was a complete gong show to manage. The most common bugs were in the assignment of displays on user logon, as well as a crappy, often buggy, login screen (though GUI logins for linux are fascinatingly weird pretty much universally.)
That being said, even in evaluating alternatives there wasn't anything much better. Linux remote desktop managers are just not that great yet.
As much as I hate Windows, I have to tip my hat to Microsoft's and say that their RDP implementation stands more than head and shoulders above any alternative remote desktop implementations I've tried.
Developers these days are getting much better at doing things over the command line. The trend of using GUIs for everything recently appears to be ebbing into a "right tool for the right job" mindset. Which is a very promising trend I've noticed. Hopefully remote workflows are entirely done through emulating terminals over SSH in a few years time :)
Unlike RDP, xpra defaults to passing over individual windows — it acts as windows manager for it's own Xorg process on server. This can completely side-step the hassle of wrapping and interacting with existing desktop environment, it's login screens etc. Xpra uses unmodified Xorg server from your distribution with xf86-video-dummy driver to achieve this. Mirroring existing Xorg session is also supported (but slower).
Do you remember what issues were there with NX? I found out pretty much to "just work" and with a really good performance too.
The student computers at my lab run Windows and do not allow user's to install software or run foreign executables. They have great monitors though. I use an RDP instance to access my VNC linux boxes remotely.
Windows 7 and Windows 10 come with a built-in RDP client.
Also, VNC is pretty insecure. So I only listen on localhost, then connect via RDP for authentication.
If you do a `ps -ef | grep vnc` while you're connected via Xrdp you should find the underlying vnc sessions. Something like:
Xvnc :32 -auth .Xauthority -geometry 1920x1080 -depth 24 -rfbauth....
It's been a bit mixed for us. As a sysadmin for non-technical users who need some linux access, it's wonderful because it's so much easier for them to connect. The stability has left quite a bit to be desired though - I have to nuke quite a few sessions and have them start from scratch.
On the server:
x11vnc -display :0 -noxdamage -shared -repeat -forever
ssh -T server 'nc 127.0.0.1 5900'
ssh -N -L5900:127.0.0.1:5900 user@server
ExecStart=ssh -T server 'nc 127.0.0.1 5900'
The socket has to be connected to stdin/stdout instead of using SSH forwarding since SSH doesn't support fd-based socket activation.
It is like a vandal with a baseball bat.
Xrdp has an advantage in that it allows Windows to talk to Linux servers with its own Terminal Services client stack.
The only solution that worked for me, both configuration and performance wise, is sadly closed source - NX Server (which is excellent).
Also, if you look carefully at the default config mechanism, Xrdp does RDP to VNC translation internally, and runs Xvnc for each login.
Why is it ironic? I've been using systemd since before it was part of any distribution; it has been extremely convenient and helpful from the very start, and every year it gets even better (as new components mature enough to enable, e.g. systemd-timesyncd).
Even having working it was much slower than on windows stack within same datacenter.
I've recently heard good words about x2go. I didn't know about it earlier. Maybe it could save someone brain cells :)
For myself I decided do not use the RDP protocol on linux clients' machines.
Although, I leave a connected tty backgrounded with Spice -- the audio works seamlessly. Small bits of lag, but I use it for spotify in the background.
I've been searching for a good (free) virtual desktop/workstation solution but Proxmox as a host + SPICE so far as the best I have found. I'd love to also find something free that supports virtualized or pass-through GPU. I agree that SPICE is not perfect, but it's the only protocol that feels like I am actually using the remote machine as a local desktop unlike VNC or RDP.
The performance is good and it doesn't rely on weird (to me) installation like NX does (NX installation creates a unix user, maybe this is necessary for some enterprise-y things, but my use case is "a smoother VNC").
I seem to recall facing issues with having exactly the same version on both client and server because the code didn't try for any forward or backwards compatibility, don't know if that's still the case.
I couldn't replicate it a while later after an OS upgrade and I have since given up on it. Does anybody else have experience with this? Should I give it another try?
The quality is amazing.
Right now the biggest issue I have with RDP on Linux is that the default packages that ship with most distros are useless—they are either outdated (still in VNC proxy mode) or poorly integrated with login managers. Also, even though I get “free” multi-head when accessing a Windows desktop from my Mac (and believe me, that is an amazing way to work on a daily basis) I have yet to get it to work 100% with a Linux server (it works and I get multi-head, but sometimes displays are swapped for some reason).
Many people don’t “get” RDP because they confuse it with VNC and other remote display solutions. But when it is set up properly, it is _massively_ better than VNC, NX or Xpra in terms of bandwidth, latency, and client support (yes, there are thousands of VNC clients, and every Linux box can do X over SSH, but I can use RDP from my iPad, Android, etc., and those are the thin clients I travel with).
Anyone comparing VNC to RDP favorably is nuts. RDP is a much more optimized protocol for high latency, low bandwidth. Only Citrix compares favorably from user's point of view. Maybe NoMachine NX as well. Both i cannot get to work over https (nomachine) and kubernetes (citrix).
Not requiring a custom, vague client also helps.
XRDP uses a Xorg driver or is able to use a VNC backend. Even then its faster than VNC. It can use pam for authentication.
Personally I encountered a problem that Xrdp recognizes wrong keyboard layout (I use JPN Windows and US keyboard, but recognized as JP keyboard in Xrdp)
RemoteFX is active, but on my 2560x1440 display there is still a bit of sluggishness. However, it's fine to run PyCharm locally on the WSL2, which is my primary use case with this.
In the Features section of the xrdp GitHub project page is this:
"Connect to a Linux desktop using RDP from anywhere (requires xorgxrdp Xorg module)"
Does this imply that serving from a headless Linux machine is not possible like we can with vncserver instances?
MacOS sorely needs an RDP server though. VNC is an awful UX for me and idk why. Didn't start off that way.
Also, another benefit of VNC is that it's like tmux: if your session gets interrupted then your programs won't all get HUP'd.