Remote desktops

From Helpful
(Redirected from Remote X windows)
Jump to: navigation, search

Shell, admin, and both:

Shell - command line and bash notes · shell login - profiles and scripts ·· find and xargs and parallel · screen and tmux
Linux admin - disk and filesystem · users and permissions · security enhanced linux · health and statistics · kernel modules · YP notes · unsorted and muck
Logging and graphing - Logging · RRDtool and munin notes
Network admin - Firewalling and other packet stuff ·

X and graphical desktop:

Linux desktop tweaking · Remote X windows · X startup notes · X notes

X windows over the network

X is an inherently networked protocol.

Each X application is an X client that you can connect to any X server. Options:

  • Usually: the X server is on the same machine -- it's the thing displaying graphics on your monitor.
A number of modern extensions will only work when run locally -- notably hardware related ones, such as GPU features.
  • Remote: you log into a remote machine, you tell an app on the remote machine to contact your local X server over the network.
  • A third alternative made more sense in the early days of thin dumb terminals (cheaper computers that could do little more than display things): Connect such termanals via a permanent LAN to a server, make the server send a login manager to you.
The display manager is mostly just another app, except it presents a login prompt, starts your display manager on a desktop (which indirectly runs all your apps).

Note that any sort of remote X makes less sense over a large distance, or over wifi, as then the connection and the session are transient, meaning the app would die the first network hiccup.

If you want a remote X session that keeps running, look at ways of wrapping it - VNC, NX, Xpra, etc.

The short version

You can tell any X app (technically X client) to display on any X display it can reach.

In the typical case this is on the local machine (:0, :1, etc. - this is usually transparent because it picks up the the contents of DISPLAY environment variable)

In another common case this is an SSH tunnel (mostly just because end-to-end access over anything larger than a LAN is likely to be firewalled).

Setup Speed Details
ssh -X nearly none (assuming exising SSH server) Good (draw commands, small lag for encryption) Security (auth and encryption) is already handled. Some SSH servers disable X by default and you have to configire it.
X over local net fiddling with xhost Good (draw commands) Avoids SSH overhead. Host permissions may be annoying. Next to impossible over WAN, at least without VPN (and SSH may be simpler than VPN).
XDMCP + X server on local net More involved (various configs, networking details) Good (draw commands) Quite practical once set up properly. (and could be done via VPN-style network)
VNC Fairly simple (e.g. when following examples) Acceptable (bitmap difference) Session keeps running when you disconnect - can be handy
VNC + XDMCP Could be involved Acceptable (bitmap difference) Can be useful for multi-user setups. Less restricted than basic XDMCP since that part can be local to the server
NX Usually easy (sometimes a pain) Acceptable to decent Cleverer and faster than VNC. No additional auth (or encryption) details to think about as it just uses ssh. Some NX variations and combinations can be a little prickly to set up. If it works, it works, if it doesn't you may need to dig around.

Note that 'local net' is not necessarily restrictive - that is, VPNs can make it practical over a distance, as do ssh tunnels (as mentioned).

Note on speed: Nothing deals well with fast-updating graphics like fading images and video (even a gigabit LAN connection would only be acceptably fast). If you use a flashier window manager (like KDE and recent versions of gnome), you probably want to turn off things like fading, expanding/collapsing menus and such.

TODO: read and other things about NX

The longer version

Unless you know it well, you may want to skim over X terminology.


When you want to make X from another server come to you (or send it elsewhere) the easiest way is usually some form of tunneling, and the easiest among those is often tunneling provided by SSH.

SSH daemons on unices often supports tunneling X, and if the client you use also knows about X tunneling, most of the work will be done for you.

Usually, this works by having the SSH server allocate an extra display, such as localhost:10, and the X-tunnel-supporting client will point DISPLAY to this. To X clients running there, this looks and acts just like any other local (implicitly trusted) display, it just happens to be backed by a tunnel managed by sshd. This is also the reason you should not change the DISPLAY yourself. In the best case you send it to the same computer nonsecurely, but usually you'll just break it.

Of course, the ssh daemon has to support doing this, and it has to be enabled. It may be disabled for security/leanness reasons. If so, change your sshd config . Note that filenames tend to vary a little between versions and implementations - /etc/ssh2/sshd2_config versus /etc/ssh/sshd_config, that sort of thing.

For the fairly OpenSSH, the option is X11Forwarding yes. (Also, you want X11UseLocalhost to be its default, yes, unless you know that and why you don't.)

For the server, it's AllowX11Forwarding yes.

Clients usually allow it out of the box. If not, the option is ForwardX11 yes.

X servers

A graphical *nix workstation almost always runs an X server on your graphics card on display :0, and most support running others on :1, :2 and so on - some modern linux distributions use that ability to support user switching.

X itself is a networked protocol, so X clients and servers need not be on the same computer - or use the same OS. There are several interesting alternative X servers:

  • Cygwin/X is part of Cygwin, running under windows. Free, and runs the basics well.
  • WeirdX is an X server implemented in Java, also free.
  • Exceed is a commercial X server for Windows. In my limited experience it works well too.
  • Unix versions of VNC servers are X servers, which then serve the graphical result over their own, bitmap-based protocol. A number of VNC implementations are free.

And some I never used myself:


What and how

The X Display Manager Control Protocol (XDMCP) lets you graphically login to a remote computer. That is, it asks a remote host to connect to your X server.

XDMCP works by invitation: A host that would like XDMCP to manage it will advertize itself, inviting an XDMCP-capable host to connect to its X server.

It makes remote X logins about as flexible as local logins -- on local networks, anyway (XDMCP uses UDP, which means it can't be forwarded over SSH (as X itself can). If you want to do XDMCP over larger distances, you would use some type of VPN, probably an encrypted VPN to avoid all sorts of snooping of either protocol)

XDMCP setups can be useful for users as it's a simple way of running things remotely but showing them on your client/workstation.

This can also be a handy way to use thin client, or reuse an old computer, to do little more than display all the work that's done on the more powerful remote host.

Using a login manager this way can be handy for admins, as logins will be mediated by this XDMCP host - a single place: XDMCP runs on some remote host, and itself runs a login manager (like like xdm, gdm, kdm). It runs on a remote host, and is just another X client that connects to your local X server.

(It also avoids the trouble of having to bake your own password setup, and deal with fixed screen numbers -- as is the case for multiple remote logins the VNC way)


  • An XDMCP server should obviously be powerful when it serves more than one or two clients, as it's doing most of the work.
  • Since you are running the X server that things get displayed on, there's usually no reason you can't have local X clients connect to it at the same time - though it can get confusing to you in that you don't necessarily know what came from which host.

Technical details

Connection process:

  • The XDMCP server is set up with XDMCP enabled (listens for connections - UDP port 117)
  • Someone starts an X server, and either implicitly or explicitly either queries a specific XDMCP server, or broadcasts to ask whether there are any XDMCP servers on the subnet.
  • The XDMCP server accepts the connection, or notices the broadcast. From the user's point of view, the XDMCP server starts connecting X clients to you. Usually, it gives a login screen as you would also get locally. Once authenticated, it will send you applications.


XDMCP uses UDP port 117.

The X protocol will need TCP ports dependent on the X server's display number: 6000+screennumber (6000 for :0, 6001 for :1, etc).


XDMCP is usually disabled by default since you need to know what you're doing to use it securely. The XDMCP server/port should only be reachable from the computers that should be able to use it, and more importantly, the X servers that connect to it should only accept X clients from the XDMCP server.

More specific access control is possible, and regularly a good idea since the very simplest methods open up XDMCP login to everyone on the local network. A simple option is usually to alter the XDMCP server's firewall so that the only hosts that can reach XDMCP (UDP port 117) are the ones you want to allow.

You may want to make the graphical end (X server) only accept incoming X protocol connections from the XDMCP host(s). Your client may do that automatically.


On the (XDMCP) Server side, you have a display manager - you can choose one, or use the one you use for local login. GDM or KDM are recommended somewhat over XDM.

Inform the system of the change/choice: set DISPLAYMANAGER, often in /etc/rc.conf or /etc/conf.d/xdm.

Alter the display manager's configuration to enable XDMCP. For example, for gdm this would likely be in /etc/X11/gdm/gdm.conf. Read the manual for details on the settings you're changing.

Once done, (re)Start the display manager. Make it start at bootup if it wasn't configured to do so. Note that the service will probably be /etc/init.d/xdm, regardless of which you configured.

On the XDMCP Client / X server side, you set up your X server to use XDMCP.

For programs that render X themselves, and X when setting up for thin clients, this is a configuration job.

Most regular workstations will also allow remote login: most login managers will have an alternative to local login hidden somewhere in the options, with options for a host query or a broadcast.

Broadcast means it will ask the local network segment whether there are any XDMCP servers (this may locked down). A query tries a specific host.

Example using Cygwin/X (windows) as a client

After installing Cygwin/X (requires a decent bit of basic Cygwin, which I don't otherwise use) I made a link in my start menu to a batch file I created at C:\cygwin\connect.bat containing:

@echo off
chdir C:\cygwin\bin
bash --login -i -c "XWin.exe -query -keyhook -nodecoration" 

Querying a specific server refers to an XDMCP query that will give you that server's login manager.

If you get only the checkered-pattern screen when you try this and no xdm/kdm/gdm/some other login screen shows up, this means no X client is actually connecting to you, usually meaning something like:

  • that server is not serving XDMCP, or not doing so on the local network,
  • the relevant ports are firewalled on one side or the other,
  • the XDMCP query (which is UDP) didn't get routed (e.g. a TCP-only VPN),
  • your local X server rejects the X client (often for authentication reasons)

You can usually tell from errors (or complete lack of response) in logs

Notes on that script:

  • This is probably a dumb way, it leaves a cmd.exe window open, but it works. (I'm open to suggestions on how to get around that, but I wonder whether it's possible, at least in combination with XDMCP)
  • -keyhook means alt-tabbing and such work within the X server
  • -fullscreen would be nice, but for some reason it is exclusive with -keyhook (probably to avoid getting caught in your X display, though there'd usually be the windows key to get around that), however,
  • -nodecoration is rather similar; it makes an as-big-as-your-screen root window without window borders, and it does combine with keyhook

There's also an option to have each program get its own client-side window (and to hide the desktop), which you may prefer when you like to work on two computers at once.

See also the Cygwin/X user guide

See also

X forwarding:


Citrix notes

See also Remote X windows)


When you need cross-platformness, VNC (Virtual Network Computing) was historically the easiest choice, and occasionally still is.

It's not the most efficient, though, and details vary a little between platforms and implementations.

For example, in *nix you can host X windows inside within VNC servers, while in a windows you can only yield control of a logged-in session.

VNC implementations

These are primarily notes
It won't be complete in any sense.
It exists to contain fragments of useful information.
  • TightVNC: server and client, free, windows and *nix.
Otherwise fairly minimal (e.g. no GLX support in the server(verify))
Tight protocol was a good choice for a decent while (roughly until tiger/turbo)
Also not actively developed since XP
  • RealVNC: server and client, free and paid-for versions, windows-only but has extra features like file transfer. Seems targeted at helpdesks.
  • UltraVNC: Similar to RealVNC, but free.
has tight protocol
and since a 2015 patch is

focuses on speed. By itself a little cleverer, so does better than tight at video and 3D content
the optional use of VirualGL gives more performance for 3D
the research / implementation details behind some of its design choices have been adopted by others, including TigerVNC, libvncserver, and recently UltraVNC
on Linux there is a server (verify) (see also VirtualGL instructions. Use of VirtualGL is optional)
on windows, the server end is recommended to be a post-2015 UltraVNC (verify)[1]

In part meant to update TurboVNC, and provides a few modern features (RealVNC-like) and some TurboVNC updates, though for performance TurboVNC is generally preferable(verify).

Other notes:

  • about various turbos:
libjpeg-turbo is a SIMD-optimized variant of libjpeg (mostly drop-in)
TurboJPEG is a higher-level API (developed for VirtualGL, TurboVNC) which can be backed by libjpeg-turbo, or similar such optimizations
TurboVNC's speed comes in part from using TurboJPEG, partly from spending less (CPU)time deciding what to send how (itself in part because sending with jpeg is a bit cheaper via turbpjpeg)
  • about VirtualGL
intercepts rendered GL results in-process, works out as indirect but hardware-accelerated rendering
(where available; can also be built against mesa to be able to use 3D on GPU-less servers)
which makes it pretty efficient to view 3D apps results (and video) rendered elsewhere on a fairly thin client (pretty impressive on LAN, by previous standards)
intercepts: meaning does not require apps to be built against it, you just have to start it in a specific way (vglrun)
can do its own transport, e.g. displaying the results of one X (3D) server in another (2D)
perhaps more frequently seen with TurboVNC (or similar). This requires more CPU but provides other features, e.g. tending to be more reactive on high-latency, low-bandwidth connections.
associated but not tied to TurboVNC

  • some special cases where one or more of the more modern details apply, e.g. in virtualbox (verify)
  • Other/specialzed: See e.g. [2]


A VNC client connects to an IP and either a display-number-dependent port.

The port VNC serves on is usually 5900+displaynumber (...on X. On windows that's usually 1)

(Port 5800+displaynumber, if you see it, is for serving the java client, if applicable)

(Port 6000+displaynumber is X windows, which should only matter internally when serving from *nix)

VNC, X and window managers

Most VNC servers are X servers so are a session upon themselves. A few leech onto existing sessions somehow.

When they are independent, you often start one as and for a specific user. (In some setups it makes sense to run a session manager so that anyone can connect and the authentication is handled by it)

One of the few differences with a regular X server is that it has its own configuration file that lists what it should do when started.

For example, the TightVNC server places this in ~/.vnc/xstartup, and might e.g. contain:

xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls &
twm &

xrdb sets a number of properties on the root window that is created (I'm not sure how necessary this actually is)
xsetroot sets the background (the 'root window') to a solid color instead of the default pattern so that it compresses better
xterm -ls gives you a login shell in an xterm to start working with. (this shell is a child of the vnc server process, meaning it will outlive you killing the window manager, unlike shells you started from the window manager)
twm is a very simple window manager. You may like blackbox or xfce4 or others. (Or even something like KDE if you turn the fancy graphics all the way down.)

On xfce and Tab:


Starting a vnc server:


This is a perl script that will assume some defaults and start a vncserver on the first available X display. The local display, if applicable, usually takes up only :0, so this starts at :1. When more than one local / VNC display is used, you may want to specify a specific number to avoid confusion.

You can use more options:

vncserver :2 -geometry 900x700 -depth 16

Geometry controls the desktop size. Can be anything, I prefer something that makes the client window not cover everything.

Depth 16 will be a little easier on the network than 24, and a little uglier.

Stopping a vnc server:

vncserver -kill :2

You should save things, of course, and possibly log out of your windowing environment to let it save its settings.

Multiple monitors


Note that by default, VNC is not encrypted. Some flavours support it, but for more general security you may wish to look at ssh tunneling or the zebedee tunneling (apparently faster than ssh for this purpose) mentioned here.

A password is hashed and stored for a particular server (usually per-user), always one for interaction, and possibly one for viewing.

Clients may store this hash (The TightVNC client can store all connection info in a file so that a simple double-click will reconnect you). Therefore: don't use your best password, it may be brute forcable. Of course, the same goes for the password hash on the server side.

From an applet

Go to the TightVNC download page and download the 'javabin'.

Then put up a page that contains something like:

   <applet code="VncViewer.class" archive="VncViewer.jar" width="1024" height="776">
    <param name="PORT" value="5901">

This example counts on this running on the same machine. Because of Java network security (the limitations on where applets can connect to), that's the easiest setup.

The applet has a pre-set size (as java applets do) and when this is smaller than the VNC screen's size it is simply not shown. The extra 8 pixels of height is for the buttons.

Possible applet parameters include:

  • "HOST": Seems to default to localhost. Java's security restrictions apply.
  • "PORT": Port you want to connect to.
    is :1,
     :2, etc.
  • "Open New Window": "Yes" or anything else for no.
  • "Show Controls": "No" to disable the buttons on top.
  • "Offer Relogin": "No", or anyhing else for yes.
  • "Show Offline Desktop" "Yes" to continue showing desktop if remotely disconnected.
  • "PASSWORD" hard-coded password. Not generally a good idea to use.
  • "ENCPASSWORD", just as bad an idea. (Don't know which hash yet, (verify))


  • "Defer screen updates"
  • "Defer cursor updates"
  • "Defer update requests"

These (additionally GUI-configurable) options are also settable by PARAM:

  • "Encoding": "Tight" by default, other possiblities are "Hextile", "RRE", "CoRRE", "Zlib"
  • "Compression level": "Default" by default. (Range: 1..9)
  • "JPEG image quality": "6" by default. (Range: 0..9)
  • "Cursor shape updates": "Enable" by default. (Other options? "Ignore"?)
  • "Use CopyRect": "Yes" by default
  • "Restricted colors": "No" by default ("Yes" means 256 colors).
  • "Mouse buttons 2 and 3": "Normal" by default, can be "Reversed".
  • "View only": "No" by default.
  • "Share desktop": "Yes" by default (multiple logins cooperate).

On speed

Client side config

On the same PC, bandwidth is irrelevant because it's typically just a RAM transfer

  • So Raw is the lowest-latency option

On LAN, bandwidth is barely relevant, and lowering latency is noticeable

  • avoiding compression is usually worth the lower overhead
Hextile is probably the most efficient of the raw-style variants (auto seems to prefer it because of that)
  • it can help to avoid server-side and/or client-side pixelformat conversion
if both sides are full color, then e.g. transferring 256 color is two conversions and probably not worth the saved bandwidth

On the internet, and particularly on wifi bandwidth can become important to response latency

  • "auto" may land on hextile
    • on wifi, ZRLE (lossless compression), or Tight without JPEG (then also lossless) tends to behave better than hextile when there are images and gradients
  • if you can accept lossful transfer, consider:
    • tight with JPEG and/or
    • 256 colors
  • Zlib is mainly just a fallback for when ZRLE and Tight are not available

For reference (UltraVNC's list):

  • Tight
based on zlib, with some pre-processing that should help compression ratio and CPU use
optional JPEG compression, with quality setting
good for low-bandwidth connections
For high-bandwidth the extra processing may actually mean lower responsiveness than some others
  • ZRLE - similar to tight, but:
lossless (no JPEG), good for mostly-monocolored regions
came later than tight(verify), may do a little better at the lossless part (verify)
does fewer incremental upgrades than tight, so tight may seem faster on certain types of regions(verify)
For high-bandwidth the extra processing may actually be a bottlneck
specific to realvnc, ultravnc (verify), whereas tight is supported by more
  • Ultra - experimental, non-standard. Uses LZO compresison, which favours speed over compression. Lossless, so in theory a better variant of ZRLE.
Specific to UltraVNC
  • ZYWRLE ('ZLib YUV Wavelet Run Length


wavelet-based, should do better on video-like uses
  • Zlib - but CPU-costly. These days meant as a fallback when the more efficient Tight is not supported

  • Hextile - sends small tiles, each as raw or RRE.
for LAN office use this may be the lowest-latency choice
  • RRE and CoRRE - basically 2d RLE. Efficient for simple graphics like office use, not for photographic regions.
  • Raw
least overhead when on the same machine


  • CopyRect - will send only areas that update (for any, or just for raw?(verify))
generally helps, leave it on
  • Cache encoding - needs CPU for checking, so is only worth it if you expect a bunch of areas to exactly recur (artifacts from turbo mode and such can accumulate)
generally doesn't help, leave it off

Tight: most of the above, minus ZRLE and Ultra


  • Screen Sharing: raw, ZLib, ZRLE, and some custom mac stuff (features for mac-to-mac connections)
  • JollysFastVNC:
  • Chicken:

See also

Server-side config


Black right half in multi-monitor (UltraVNC)


The data seems to get to you (scrolling left and right on a smaller window works)
making the window two monitors wide means the right side is black

The UltraVNC client seems to allocate a viewport it will draw in. By default this seems to be the first/left monitor's size (and order indeed seems to matter when you have monitors of different size).

Some older clients allowed you to control this, with a dropdown that essentially listed each individual monitor size, and the combined desktop size.

Presumably the reason is that the client allocates this before connecting, i.e. before knowing how large this viewport should be(verify) The workaround for me was an older client, and choosing the largest size in that dropdown.

"Server did not offer supported security type"

Probably to Ubuntu desktop sharing, vino - by default it requires encryption, which tightvnc does not support.(verify)

(More technically, vino only allows auth method rfbTLS, and while it's auth, it also forces the socket to TLS - and it's the only one that does that)

So either

  • Switch to a VNC client that supports encryption (e.g. remmina),
  • tell the server to not require encryption. Know what this means to security, though.

There is a vino-preferences, but it is just the basic settings that you also get via the taskbar icon.

To not require encryption, use
to find and uncheck:
org → gnome → desktop → remote-access → require-encryption

Note that if you are comfortable with SSH, you can use it for an encrypted tunnel,

and you could additionally set

"Unknown authentication scheme from VNC server: 18" (Remmina)

Not disabling encryption helps.

More details:

Ultravnc forgets password, and other settings (WinXP)

That is, the Admin properties dialog lets you apply things, but once you click OK the settings are not saved in your ultravnc.ini

In our case, file permissions were not the problem.

It turns out it was a WinXP antimalware feature, specifically the "protect my computer and data from unauthorized program activity" checkmark on the "Run as" dialog that comes up when saving.

Uncheck that and you're fine.

See also


There are various VNC toys, like the vnc2swf program that you can use to record interaction as Flash video. Various details and more are at eg. this page.


VNC encrypts passwords using (ECB-mode) DES, with some extra details:

If shorter than 8 bytes, the password is padded with NULs up to 8 bytes.
ECB key is based on the password
in ASCII form
8 bytes (truncated or right-padded with NULs as necessary)
each byte bit-reversed

The actual exchange looks like a nonce challenge response thing.

VNC servers tend to store the password in a file (or the Windows registry)

I've noticed at least one doing some padding

If you want to generate the password hash, you may wish to find a utility.

See also:


An open implementation of Microsoft's Remote Desktop Protocol (a.k.a. Terminal Services)



Intended for remote assistance, cooperation. Unattended access also possible.

Free version does what you want, paid version is slicker. And necessary for commercial use.

Windows Remote Desktop

Remote logins

Remote logins, in the form of seeing another computer in a window and interacing with it, is possible when you have Windows XP or a recent server variant: both a server and the client, called either Terminal Services or Remote Desktop - it was renamed at one point.

On non-server versions of windows such as XP, there is a built-in limit that means you can only have one login at all, local or remote; logging in in one way will take over the same session, disconnecting the other. I forget whether this is fixable, but chances are microsoft doesn't really want you to do so. It's not a technological limit. In fact, they briefly promised it for SP2. I suspect it's rooted in the lessened motivation you would get to buy a server OS from them.

Interesting to note is that there is a linux client that works quite well.


To enable it or verify it is enabled, right-click on 'My Computer', click 'Properties', and find the 'Remote' tab. Check the checkmark named 'Allow users to connect remotely to this computer'.

Remote assistance is, I believe, the same thing but established through invitations (for helpdesks and the like) and likely allows the connected to computer to look too (regular remote desktop throws the computer itself back to the login screen once there is a remote login). I never used it, so I usually disable remote assistance. (And given windows' track record in security, I feel a little safer disabling things I never use anyway)

Access control

The only things you have to set up is access control, under 'Select Remote Users'. Administrators are always allowed, and if you want to have regular users log in, you have to add them here. If, incidentally, you have a passwordless login, which people do to make their computer start up to their desktop without having to log in - you cannot use that particular account for Remote Desktop. Either you accept that and use another account (and accept that that won't give you the My Documents of your regular user) or you have to add a password to the account.

(The last is done via 'Control Panel', 'User accounts', <click the user>, 'Change my password'. You should do this as the user itself, and not as an admin, when possible.)

Linux client

rdesktop is a good option. Try to get the latest version. With a little option fiddling it should be able to fit most needs, including even thin client pseudo-windows machines.

You usually want:

  • color depth to be high-color:
    -a 24
  • to specify fullscreen -f, or a resolution, e.g.
    -g 1024x768

Also useful:

  • -u loginname
    fills that in in the login. Probably most useful if you create a shell script with your options.

For speed, you can fiddle with:

  • -x m
    disables the background, most fancy animations, etc.
  • -m
    only sends mouse clicks, not motion. Less back-and-forth, but hovering and a few other things don't quite act like it should.
  • -z
    compression - I've not noticed a big difference, though

From an applet

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Go to the properJavaRDP sourceforge page, or rather, the projects' download page.

Then try some howling on a full moon, because I can't get it to bloody work.

  <param name="port" value="3389" />


Caveat: Being java under regular security restrictions, you will have to serve this from the windows computer you want to connect to - or loosen java's security, but that defeats most of the purpose - if you can do that, you can also just run the windows or linux client. -->



This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Guacamole is a HTML5 (canvas-and-javascript) frontend to a guac server, where that server relays to RDP and VNC backends (and is extendable there).

In other words, it makes it easier to unify and expose those.

See also:

Xpra notes

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Xpra is like tmux/screen-type persistemce for X11: They are actually displaying to a background process, which relays it when you are connected.

In basis it is rootless, meaning individual windows show up elsewhere (and that you probably want to start e.g. a shell on it, as in the example below)

(It can also sync clipboard, sound, and printers, forward notifications, and some other potentially nice things.)

Quick start:

# start a new session on display :100
xpra start :100 --start-child=xterm
# in practice it can make more sense to add your initial program(s) to ~/.xpra/xpra.conf

# connect to it locally to test:
xpra attach :100
# connect to it remotely (via SSH, it's handy to do the auth and encryption for you)
xpra attach

If you think the encryption is a bottleneck for you (or redundant because you're already on VPN), you can consider doing it via a direct TCP connection (optionally still with a password), something like:

# start like:
xpra start :100 --start-child=xterm --bind-tcp=
# connect like:
xpra attach


  • (You can get a desktop mode, by starting a nested X11 server as the initial process, which then uses another display and a little more thinking - see the docs)
  • Xpra is itself a window manager, meaning you can't start your own unless you fiddle with desktop mode.

See also:

Winswitch notes


Mostly used in the context of virtual machines.

See also: