Yesterday I played around a little bit with VNC (Virtual Network Computing) on our home network. VNC can be used (among other things) to pull up a remote desktop on a local machine and treat it as if you were sitting at the remote machine. One of its appeals is that it’s multi-platform, unlike similar technologies like Microsoft’s Remote Desktop Services. At home, VNC’s basic appeal is convenience. For example, while sitting upstairs, I can pull up the display of my basement Linux server to make a quick edit in GnuCash. Another example: When I’m doing our taxes, I can work downstairs in the office (where all our records are), pull up the Windows desktop upstairs, and run the tax software there.

Installation on the Windows box was straightforward. I just downloaded and installed the distribution from RealVNC, and it installed both the viewer and server. No surprises, and it seems to work great.

For the Mac.. My only Mac is a laptop, and I can’t really see wanting to connect to it with VNC. Still, I looked into it anyhow. First I tried a product called OSXvnc, which seems to work OK, but then I learned that MacOS 10.4 (Tiger) has VNC functionality built in, so I can use that if I ever need it. What I’m really interested in for the Mac, is a good VNC client. And that’s the weird thing.. Apple includes built-in VNC server support, but they don’t supply a VNC client. And there seems to be no one “defacto” VNC client that most people use on the Mac. There’s one called VNCThing, which was very hard to track down, but appears to work. It appears to be orphanware, though. There’s another one out there called Chicken of the VNC which appears to be a little less stale. Once I’m ready I’ll probably try that one out.

Next up: The Linux box. First the easy stuff: RealVNC supplies a Linux VNC client that works fine. That brings us to the server. In grand Linux tradition, there is more than one way to do a VNC server, and none of the methods is a perfect solution.

• Method 1: Creates a totally new VNC X “session” (for example, if the main desktop is host:0, the first VNC session would be host:1). Advantage: modular and efficient. Disadvantage: Doesn’t export your main desktop, so everything has to be done inside the virtual VNC session. To access that, you need to use a VNC viewer even on the host PC. Fine for remote access, but not real efficient for working on the host.
• Method 2: Export the main X11 desktop using a polling server such as x11vnc. Advantage: works fine, no extra configuration required. Disadvantage: slow.
• Method 3: Export the main X11 desktop using the VNC module supplied for XFree86 v4. Advantage: ties into the X server itself, so no polling is required and it’s very efficient. Disadvantage: Doesn’t work with direct rendering (DRI module) enabled. If I start the server with both VNC and DRI enabled, the server freezes the first time I try to access it remotely. This seems to be a compatibility issue between VNC and my particular video driver/card (ATI Rage Pro or somesuch, r128 driver). If I disable DRI, it works fine. So, if I want to use this solution, I have to give up direct rendering (which really isn’t the end of the world).

This is sort of a microcosm of what’s wrong with the current state of desktop Linux. Lots of potential, but lots of interoperability issues. I still haven’t decided which method to use, but I’m sure I’ll settle on one eventually.

Now that I’ve got VNC working at home, the next step is to get it so I can access my home Linux desktop from work. To do this I think I want to tunnel the VNC connection through SSH. Google turns up lots of tutorials on how to do this, so once I’m back in the office, I’ll try it out.