Guacamole – HTML5 Clientless Remote Desktop
guac-dev.org
guac-dev.org
Edit: I used a Linux VM on my home windows box over guacamole from a Chromebook as my primary mobile computer for 6 months. Browsing in Firefox on my remote VM was always faster than browsing the web locally on the Chromebook. If only it worked well on tablets...
I don't suppose[1] it supports RDP 8's new ability to play video on a remote desktop by streaming the media across and decoding it locally (works in the Win/Mac official clients).
I was amazed and dumbfounded the first time a YouTube video played in a remote session with perfectly in-sync audio and video and instant response to mouse clicks and now find it hard to go back...
[1]: Can't test this myself until I get back to a desktop computer (this is from a phone).
I haven't seen any solid implementations of client<->server communication with webrtc compared to websocket, though - but I haven't looked very hard.
It's becoming to be interesting when your VNC/RDP client directly supports websocket, eliminating the need of a proxy and only use a STATIC web server to host client. Wait, it's built-in for qemu since 1.4! http://git.qemu.org/?p=qemu.git;a=commit;h=0057a0d59006d00c2...
I am still waiting better support for Clipboard on QEMU. :/
Currently using NoVNC as a client. Works really well. Keyboard needs more love.
Guacamole has much better performance. Your browser and the guacamole server communicate using a custom, better-performing protocol (http://guac-dev.org/doc/gug/protocol-reference.html). While guacamole can still connect to your server with VNC, it also supports RDP, which is also faster. Even when using Guacamole as a proxy for VNC if your guacd and VNC servers are on LAN together, because the guacamole protocol works much better over high latency connections than VNC does.
Edit: also, Guacamole doesn't use Websockets, which makes it much easier to proxy with your standard HTTP proxy software like apache, which didn't get a Websockets proxy module until 2.4 (Ubuntu 12.04 is 2.2).
With noVNC the protocol decode/encode is done in the browser (modern browsers are plenty fast enough to do this easily), whereas with Guacamole the burden of decode/encode for every client happens on the server where the proxy/client part is running. Even if you need to run websockify to proxy/bridge noVNC, the only thing it is doing is shuttling network traffic and the python implementation of websockify can easily handle lots of simultaneous clients without breaking a sweat.
noVNC was designed with Infrastructure as a Server (IaaS) providers in mind so minimizing server CPU, memory and bandwidth was a goal in the design.
Also, guacamole does use websockets when it is available.
that hss the build down to an art. They GIT the latest code, do the required build and then install for you on your system. After that you just install Guacamole server side and you are done.
I do love that this is open source though. Someone will probably add NX support soon. Sound support also looks pretty impressive.
My guacamole server then connects to x11vnc so I still get RDP-like performance across the internet.
Edit: you'll also want to make an Upstart job for x11vnc so that it starts on boot, and restarts if (when) it dies. You can just copy any of the basic upstart jobs in /etc/init.d/*.conf and investigate. You also may want to make x11vnc start after your X server: http://upstart.ubuntu.com/cookbook/#run-a-job-before-another...
There is a lot of fiddly business :/
Very much still a compile-it-yourself experience. When I was setting up my RDP server on my Mint media center, I went with xrdp + x11rdp setup detailed in some guides at ScaryGliders.net, although the same guy as released a bunch of scripts to do it for you, see https://github.com/scarygliders/X11RDP-o-Matic
I don't really want to deal with recompiling stuff and manual updates though, and expect others to feel the same, which is why I advocated x11vnc to the GP.
Except a browser compatible with HTML5-august-2014-revision. Believe it or not, there are many places stuck in pre-HTML5 times (hotel computers, for example).
If it could stream GIFs and accept clicks with server-side image maps, then it would be compatible with every desktop graphical browser in existence (Opera Mini and text browser would still be not enough).
I can't decide if that's the most brilliant idea I've ever heard or the most terrifying. Probably both.
That should give your Gstreamer support for all formats libav supports.
I remember being surprised that sites like dailymotion and vimeo still wouldn't work since I expected firefox to come with h264 support a while back (the whole cisco thing if I remember correctly). Always just attributed it to not having flash installed or whatever and shrugged my shoulders.
Anyways they work now, and at http://www.youtube.com/html5 it showed no h264 support before, but now it does. So thanks for the comment, without which I would have still been living in the dark. :)
Definitely keeping this in my mental toolbox!
And on Android, there's Transdroid: http://www.transdroid.org/
(I was even able to run Inkscape and Ardour on different logins, without too much fuss .. worked quite well!)
I only use Linux/OSX for local machines, but RDP was substantially more responsive than any VNC server I could get my hands on (including RealVNC Enterprise).
Layering Guacamole shouldn't cause any real trouble beyond that - the dashboard needs to run on a separate Unix machine and so can be pointed at all those desktops just fine once you set up the network interfaces.
> guacamole-client is used to build the subprojects that make up Guacamole, and
> to provide a common central repository. Each project contained here is
> completely independent of guacamole-client and can be built separately, though
> the others may have to be built first. If all projects are built using
> guacamole-client, Maven will take care of the proper build order.
My reading of this is that the client repo also contains the server, which is written in java [Windows RDP server] <--RDP protocol--> [linux Guacamole server] <--HTTP or Websockets--> [HTML5 client in your browser]> You will need a Linux or UNIX computer to host Guacamole.
I would like to have remote/shared access to Xcode + iOS dev stack... Or is there some other way to get that?
Hardly the best setup but at least it's free. Will be checking this out to see if it fits my reqs.