← Back to Kevin's homepagePublished: 2020 July 5Last updated: 2021 June 6

Can I work via remote desktop?

I recently moved to Tapei, but was able to bring only my beloved 2012 MacBook Air, which struggles to compile Rust or maintain enough free disk space to npm install anything.

Instead of buying a more powerful desktop/laptop, could I do all of my development work on a powerful “cloud” server? Cost isn’t really a concern here: I’m actually curious if a cloud dev server could be an overall better experience than buying and maintaining local hardware.

Definitely send me an email if you’ve tried a work setup like this and have sugggestions.

Otherwise, please enjoy my rough notes.

Requirements

Essential:

Nice to have:

Non-goals:

2021 June Update: A Solution

Use Parsec for remoting and VirtualHere to forward USB peripherals from client to host. Parsec only works for Windows hosts with GPUs, and despite a decade-old account, $10k of billing history, and a card on file, Google Cloud refuses to rent me a GPU. (See this setup script if you’re luckier in the cloud dept.)

I ended up installing Bootcamp on my Mac mini to boot natively into Windows (Parsec doesn’t work through a Parallels 16 VM). I access this “server” from anywhere via Tailscale.

From the fabrication space across town I’m able to remote in from my laptop and do CAD work with a spacemouse with completely tolerable end-to-end latency (20ms). Amazing!

Latency feasibility

I already pay AWS for servers, so I’ll start there for initial testing.

Tapei pings to Hong Kong and Tokyo are around 30–40ms; Singapore is about 50ms. (Those cities are about 1000, 2000, and 3000 km from Taipei.)

Google Cloud actually has a data center in Taipei, so they’d likely be the lowest latency option. Of course, latency is greatly affected by wifi congestion and a bunch of other factors, so I’ll do actual measurements once I have the thin client wired up.

Playing with this latency demo suggests that 50ms feels fine to me — though I definitely notice 100ms (Aside: can I really trust a web app to simulate latency reliably?)

In any case, I have some options that aren’t obviously infeasible for geographic reasons.

Update: A nice man from Chunghwa Telecom installed a very nice fiber optic cable in my apartment and from a wired connection I can ping Google in 3–5ms. So, definitely not worried about latency.

Local hardware: Raspberry Pi 4

My apartment came with a 4k TV, so I’d like to drive this at 60Hz from a single board computer. I believe the Raspberry Pi 4B should work:

Total cost should be around $100. Unfortunately there’s no Amazon here (PCHome and Shopee just aren’t the same), so I’ll go by Jin Hua and nearby stalls to pick everything up:

Update: I borrowed a 1GB RAM Pi 4 from a friend to test, but it’s not looking good:

(All this on a clean install of Raspberry Pi OS Lite 2020-05-27 + XFCE4 desktop)

Local hardware: TBD

Software: Apache Guacamole

Apache Guacamole is a sort of “proxy” that lets you access many different remote desktop protocols (VNC, RDP, SSH, etc.) via a web-based GUI. There are lots of features and configuration and you have to build the server side from source.

I found the GUI to be fairly responsive (with 150–200ms ping times to the underlying remote), but unfortunately I don’t believe there’s any way for the web based frontend to fully “capture” all keyboard events. From their docs:

Certain key combinations are impossible to press within a web application like Guacamole because they are reserved by the operating system (Ctrl+Alt+Del or Alt+Tab, for example)

They provide a “virtual keyboard” as a workaround, but that’s a non-starter for my use case of a full replacement.

It’s possible that I could configure the thin client or my keyboard hardware itself to do some kind of remapping, but that seems complex and fiddly and sort of defeats Guacamole’s “no client needed” value prop.

Notes

Spin up a pre-cooked AWS image: https://docs.bitnami.com/aws/apps/guacamole/

launched in Singapore on t3a-large, ip 54.169.217.225 Modified AWS security group to allow all traffic in/out (YOLO), then I could connect

Login to guac:

http://54.169.217.225:8080
guacadmin / c2qyUYd1paC4 (password generated by bitnami script, found in ec2 logs)

HTTPS doesn’t work out of the box, I think this is expected to be run behind nginx or something.

Logged in to the remote via SSH so I could install VNC and a desktop environment:

sudo apt install tightvncserver xfce4
echo 'startxfce4 &' | tee -a .vnc/xstartup

Confirmed VNC worked by opening it from my Mac:

open vnc://54.169.217.225:5901

Configured Guac (via web admin) to expose this VNC connection. Then I was able to connect via Guac’s web interface, and the remote UI felt decent.

Software: X2go

Ran into this via 2017 HN thread about Apache Guacamole. Also from a 2018 blog post about a similar remote desktop setup.

This runs an X11 server remotely and then proxies it to your local machine in some way that’s supposed to be much more efficient than just using the X11 forwarding directly.

On Mac, unfortunately, I found it to be unusably slow and each window on the remote desktop would appear as a separate window on my Mac. (Including, awkwardly, both the Linux desktop manager’s window chrome and Mac’s window chrome drawn around that!)

I could be missing something about how X11 works on Mac, but my initial test suggests that it wouldn’t be possible to have the remote window manager “in charge” (i.e., I had to use the Mac window shortcuts to switch between remote windows).

That said, it may work fine with a Linux “thin client”, so I’ll revisit this later

Notes

I tested on the same instance that I spun up to test Guacomole:

sudo apt-get install x2goserver x2goserver-xsession

Had to download + install 15 MB client for mac, as well as install XQuartz (100 MB+).

Much easier setup, though, didn’t have to futz with many settings — just fill in the remote’s address and SSH login.

Software: RDP

Let’s try XRDP on Ubuntu 20 LTS, by Google Cloud Taiwan.

apt install xrdp xfce4

Testing with Microsoft Remote Desktop Version 10.3.12 1801 (installed via Mac App Store) on my 2012 Macbook Air. Connected via ethernet, ping time is 6–9ms.

Was able to connect to remote PC, but I don’t think I have a password. Can I login via SSH pubkey? Eh, maybe via tunneling. YOLO, lets just sudo passwd to give myself a password to try out latency, etc.

XFCE desktop feels very snappy, though dragging windows around the lag between window position and mouse cursor position is noticable. I can watch YouTube at (eyeballing) 5–10 fps, but the sound doesn’t work (probably I suspect Linux, not RDP).

Scrolling via touchpad feels weird; not sure if that’s RDP or Linux.

Impressed this xrdp just worked out of the box.

Lets try “Windows Server 2019 Datacenter with Desktop Experience” see how snappy that is. Had to stop my Ubuntu instance first, since Google Cloud only gave my 8 CPU quota in Taiwan. Had to wait a few minutes for windows datacenter to boot (really!?!)

Used Google Cloud Admin UI to create a Windows password, it autogenerated p>f$yrvOH.%OwOE RDP Login took tens of seconds for initial windows setup modals. Feels pretty snappy, though same window/cursor mismatch when dragging windows.

Had to turn off Internet Explorer advanced security settings so that I could download Chrome.

Youtube videos are much smoother than from Linux — still choppier than native, though.

Also: Google Cloud Admin UI always has loading spinners after every click for 500ms, even though I’m 10ms from their datacenter ¯_(ツ)_/¯.

Software: Parsec Gaming

Windows hosts only, “teams” plan starts at $150 billed monthly. Let’s give it a shot anyway.

Downloaded native mac client; frustratingly I’m not allowed to paste in passwords so had to manually type out from password manager. Installed on Windows Cloud VM, that also worked fine.

It showed up on the mac app, but when I tried to connect I ran into Unable To Initialize Encoder On Your Server error. Presumably it doesn’t like the GPU in my Google Cloud instance.

Lets try spinning up another instance but with a GPU. My only option is NVIDIA Tesla K80.

Fails to boot, “zone does not have enough resources”. There is no way to change the zone from the failed instance. Guess I’ll just start over.

Oh, I bet it’s because my “GPU (All regions)” quota limit is 0. Well, I’ll ask Google for more and try again in a few days when they get back to me.

Actually, the autoresponder got back to me quickly!

Unfortunately, we are unable to grant you additional quota at this time. If this is a new project please wait 48h until you resubmit the request or until your Billing account has additional history.

I guess a decade-long account history and thousands of dollars of ad spending doesn’t make me trustworthy enough to rent GPU time =)

Not Parsec’s fault, but if I can’t get it running in Google’s nearby datacenter it’s probably not worth it.

2018 Nov article about how to setup Parsec on Google Cloud: https://medium.com/flickstiq-com/how-to-setup-google-cloud-for-cloud-gaming-b8c1eddef243

Software: No Machine

Installed No Machine (NX) via RDP on same Google Cloud Windows instance I used to test RDP. Had to restart the remote. Also had to open up port 4000 via Google Cloud admin (I just allowed all traffic from my home IP).

I got Windows login screen after connecting, and keyboard layout didn’t match that of my Mac’s.

Somehow Window’s screen resolution is 640x480. NoMachine isn’t automatically resizing it when I resize the window on my Mac. I cannot resize in Windows because, no joke, the “display” pane of settings app doesn’t scroll and there is so much whitespace that the dropdown I need is below the fold.

Downloaded qres and ran in powershell:

./qres.exe x=800 y=600

which raised a (graphical!) popup that said “screen mode not found”. Hmm, maybe this is built into newer versions of Windows?

Set-DisplayResolution -Width 1024 -Height 768 -Force

ran but didn’t work (not supported by video device)

Hmm, seems like NX uses the same physical video setting as the hardware. But Windows without a screen plugged in may only allow low resolution modes. One solution appears to be adding a headless DVI dongle to the machine, which isn’t possible in my case.

FWIW, YouTube videos look very smooth on 640x480.

Well, I wanted linux anyway, lets try NX with that.

Ah, this works very well. Setting the NX client to auto-resize the remote screen works (unlike Windows) and YouTube streams fine at my full macbook air resolution. Audio is delayed, but this post suggests its a linux driver problem.

Sofar, NX is easily the best solution. YouTube video and everything else is very smooth.

Seems like the best solution thus far.

Software TBD