Comment by jcrites | Hacker News Reader

Comment by jcrites | Hacker News Reader

Beautiful! I've been looking for something like this and hadn't heard of Guacamole.

Where I work, it's standard for developers to work using a "cloud desktop", i.e., a remote machine hosted in the cloud that's used for personal development with a very production-like environment [1]. When accompanied by a powerful laptop it's all most engineers need. However, client and server software for various protocols like RDP and VNC on various platforms is still a pain. It'd be great to have a simple and easy way to provide viable remote access built directly into servers -- from any client device with no prior setup. I'm glad to have come across this.

I'm curious how Guacamole's HTML5 rendering compares to solutions like the Ace editor when used to render terminals and text areas. At a high level, it looks like Guacamole is based on RealMint which uses the HTML5 canvas tag, whereas Ace manipulates regular text elements to effect styling. I'll have to experiment with them.

[1] And for that reason I was amused to see the following on the Guacamole home page: "Keep your desktop in the cloud: Desktops accessed through Guacamole need not physically exist. With both Guacamole and a desktop operating system hosted in the cloud, you can combine the convenience of Guacamole with the resilience and flexibility of cloud computing."

I tend to use Amazon Workspaces for this. It's a joy to work with(especially now it supports two screens). Having a desktop that is exactly the same wherever I am doesn't sound like much but is one of those small things that you really miss when it's gone. I'm not aware of any other providers, though I'm sure there are 1000s. One nice advantage of Workspaces is that it integrates with Amazon AD out of the box.

There are surprisingly few providers, and AWS WorkSpaces is unusual in that it has no minimum number of desktops. One gotcha with WorkSpaces: it is cheap enough to make sense for just one user if you the free "Simple" AD option, but "Full" AD with GPO support etc. does add a cost (though not a significant one for a business).

OVH Virtual Cloud Desktop (https://www.ovh.co.uk/cloud/cloud-desktop/) does not have a minimum no. of users and it starts from 10 GBP/month.

That's very interesting. AWS WorkSpaces does have a per-hourly billing, but OVH might be simpler and a better price for some cases.

> it's standard for developers to work using a "cloud desktop"

Personally I prefer something like Apple's iCloud Drive; your files are downloaded locally and made available offline, letting you work on them with any device, even after it's disconnected from the Internet.

This lets my data stay mine, encrypted on my local storage, individually manageable and tag-able like all regular files, included in Time Machine etc. backups, and available even if iCloud Drive goes down.

For example, although you cannot compile full Xcode projects on iPads (yet), I can take code from them, edit it in Swift Playgrounds on my iPad, and copy it back into iCloud Drive for continuing on my iMac.

Edit: That is not to say having access to a full desktop system from any device isn't desirable, but I do prefer my files to remain available on local storage.

I want to know more about your 'cloud desktop' setup. I have tried to do it myself but it's quite laggy (like heavy lag in typing code, scrolling content). I wonder how you guys solve that.

I know Ace-like editor works great but it's usually a minimal web editor compared to something like Sublime running on vnc/rdp.

One solution for remote development is to handle some heavy lifting like responsive display logic locally in the client. For two examples of this pattern, see Cloud9 IDE [1] (which builds on Ace) and Eclipse Che [2] (which uses the Orion editor). They're web-based IDEs that run remotely on the server, but load the content, such as the file tree and files you've opened, locally into your browser. So you can load your session from anywhere and no permanent state is kept on the client.

As far as protocols like RDP and NX go, I don't know of a silver bullet. I use machines hosted in Portland from my location in Seattle and the latency is low enough that remote UIs feel close to native. Some protocols are better than others at handling high-latency connections or low-bandwidth connections. I'd recommend testing a few and see what works best for your environment. You might also measure the round trip time: for any protocol that needs a round-trip with the server to update the display, the RTT will fundamentally bound the UI's responsiveness - to do better you have to load some display logic onto the client. Scrolling and character echo are two examples of logic that's really valuable to have on the client. (Many SSH clients have local predictive echo for that reason; they echo by default except when they've detected a password prompt)

I should clarify though that a lot of development takes place on a person's local laptop, synchronizing between that and the cloud desktop (such as with Git and other tools). The former provides responsiveness and the user's preferred OS and tools, while the latter provides a production-like OS with high performance that is better able to handle complex software stacks like multi-microservice applications or sizable ecommerce websites. It's also convenient to have a relatively pristine environment that isn't frequently interrupted by e.g. laptop hibernation and network changes.

[1] https://c9.io

[2] https://www.eclipse.org/che/

> One solution for remote development is to handle some heavy lifting like responsive display logic locally in the client.

Another example is emacs in server mode: although normally folks use a Unix socket, it's possible to use a network socket instead. The remote emacs actually contains all the state, and the local emacsclient just connects to it.

Another approach is to run emacs locally, and access remote files & commands with TRAMP.

Depends on how much latency you got. RDP and SSH can feel natively if latency is low enough.

I worked at a big hardware chip company 10~12 years ago and we also had a similar setup; except that the "cloud desktop" wasn't really a personal one, it's shared among the team. Whoever needs to do tasks that need the powerful machine to run will Remote Desktop into it; other than that normally you use the company laptop (which is pretty powerful for its time too). I don't remember having a lot of pain with Remote Desktop or VNC at the time; but the web client would certainly be cooler.

Reply on news.ycombinator.com