Let's say that you're a system administrator responsible for a large set of computer systems -- everything from Linux servers to Macintosh desktops. Like most system administrators, you're very busy, tracking down problems, installing new software, monitoring systems, and helping end-users. Sounds pretty typical, huh?
Let’s say that you’re a system administrator responsible for a large set of computer systems — everything from Linux servers to Macintosh desktops. Like most system administrators, you’re very busy, tracking down problems, installing new software, monitoring systems, and helping end-users. Sounds pretty typical, huh?
Well, now imagine yourself being tens, hundreds, or even thousands of miles away. Could you still do your job?
For some systems, distance doesn’t pose any real problem. Remote login, virtual private networks, and even KVM over IP provide plenty of solutions for remote system administration. However, desktop administration is another story. Most desktop computers don’t support remote login, and even if they do, most problems can’t be solved using the command line. Desktop support, the bulk of help desk queries, is inherently a hands-on job.
Wouldn’t it be nice if you could provide hands-on repair even if your hands were at a field office or holding a latte at the neighborhood Starbucks? Well, enjoy that double espresso in the comfort of that cafe, because TightVNC is the answer to your prayers.
TightVNC, a leading variant of the Virtual Network Computing (VNC) software originally developed by the former AT&T Laboratory in Cambridge, England, is a remote display system that allows you to peer into a computer’s “desktop” from anywhere on the Internet and from a wide variety of machine architectures.
So, have a user with problems on Windows? If that user has a TightVNC server installed, you can connect from your Linux machine using a TightVNC client (VNC reverses the sense of client and server in the same way that the X Window System does) and see what that user sees, and even usurp control of their mouse and keyboard. In fact, with TightVNC running between the two machines, you can use their desktop as if you were sitting in front of their Windows — or Macintosh, or Linux — machine.
TightVNC is incredibly useful. Have a Macintosh at home that you need to access from your hotel room? No problem. Need to help your husband troubleshoot his computer yet again? No problem. Need to access the console of a machine halfway across campus? No problem.
Indeed, once you’ve used TightVNC and see what it can do, you’ll wonder how you ever lived without it. And, provided that there is direct IP connectivity between any two machines, using TightVNC is extremely simple and doesn’t require a lot of computer knowledge.
This month, Linux Magazine Editor-in-Chief Martin Streicher and SourceForge.net Site Director Pat McGovern discuss TightVNC via email with project leader Constantin Kaplinsky. Kaplinsky, 29, is a graduate of Tomsk Polytechnic University in Tomsk, Russia, where he still lives and is employed as a software developer and teaching assistant. Along with Vladimir Vologjanin, 31, Oleg Sheikin, 39, and Dennis Syrovatsky, 25, all of Tomsk, as well, Kaplinsky develops and releases TightVNC (from its web site at http://www.tightvnc.com) in his spare time. Almost live… here’s the skinny on one of the coolest software packages ever.
Constantin, what makes TightVNC different from other VNC implementations?
Constantin Kaplinsky: Like other VNC implementations, TightVNC is a remote control, remote display package derived from VNC. However, unlike the standard VNC distribution, TightVNC includes a lot of new features, improvements, and bug fixes.
Major improvements include bandwidth-friendly “Tight” encoding, local cursor support on the client side [cursor motion does not generate screen updates, saving bandwidth], an extensible protocol, file transfers, an enhanced GUI, 24-bit color support in the Java viewer, and more. The TightVNC team is contantly working on new improvements, while at the same time, trying to gather all of the useful features from other VNC-derived distributions.
Our goal is to make TightVNC the best VNC distribution available, while keeping it free, stable, and compatible with other RFB-compliant VNC software.
RFB? What’s that?
Kaplinsky: The VNC system implements a remote frame buffer. So, we often refer to the protocol underlying VNC as the RFB protocol, or just RFB.
How did TightVNC get started?
Kaplinsky: TightVNC was born on the [now defunct] Cosource.com site. That was the place where potential sponsors of Open Source software could find developers for their projects. It was the spring of 2000, and I was working on my thesis on data compression, looking for an opportunity to apply my knowledge to a real software project. I was lucky to find a request to “optimize VNC for low-bandwidth networks” at Cosource.com. My work took less than a month, and by the end of that time, I had implemented a new bandwidth-friendly VNC encoding. I called the new encoding “Tight,” named after its compression capabilities.
Then I initiated another project at Cosource.com. The second project added optional JPEG compression to the Tight encoding, support for Tight encoding in the Java viewer, and automatic SSH tunneling in the Unix/Linux viewer. Around that time, development of the standard VNC was put in limbo, but I continued working on my implementation.
People often called my VNC variation “Tight VNC,” so the name stuck, and by the end of August 2001, TightVNC was a new and separate VNC distribution with many new features, bug fixes, and optimizations. I’ve been working on TightVNC ever since.
TightVNC is included with nearly all major Linux distributions. That’s pretty impressive.
Kaplinsky: Yeah, the vnc package included in Red Hat Linux is essentially TightVNC. The package is pretty ubiquitous now. There are about 80,000 downloads of TightVNC from the SourceForge.net site every month. Of course, TightVNC’s popularity is heavily based on the popularity of its direct ancestor, VNC.
But, it is nice to receive lots of positive feedback from users and other developers, and I’m happy I can help so many people.
When I first started development of TightVNC, poor data compression was one of the most significant problems of the original VNC. Now, with that addressed, and with a host of new features, people find VNC even more useful.
Are there ways to improve the package even more?
Kaplinsky: Definitely. VNC still lacks built-in encryption and strong authentication. TightVNC itself doesn’t perform too well on Win32, and there are a number of problems specific to Unix.
For example, the Xvnc server is based on the obsolete XFree 3.3 architecture, and the X11 [TightVNC client] GUI is primitive. I think these are the key issues to address in the nearest future. Also, there are other things that we’d like to have in TightVNC: HTTP tunneling, server-side scaling, and so on.
How can people help?
Kaplinsky: There are many different ways to contribute: you can make donations, sponsor the development of some features, contribute patches, report bugs, improve the documentation, or just field questions from the TightVNC mailing list. The TightVNC site has a wish list, and has contact information for me as well as the other TightVNC developers.
How much time do you spend on TightVNC?
Kaplinsky: I teach students at Tomsk Polytechnic University, but that takes less time than I spend working on Open Source projects.
I’d say that I spend ten to fifty hours per week on the project. That’s not only coding — that time also includes answering email, processing bug reports, preparing new releases, and so on. That time also includes my work on another Open Source project, VNC Reflector, [found online at http://sourceforge.net/projects/vnc-reflector]. It’s a sort of VNC proxy to connect a number of VNC clients to a VNC server.
What’s your development environment like?
Kaplinsky: I work primarily at home, on a PII-350 machine, with both Linux and Windows NT 4.0 installed. My favorite development environment is xemacs (due to its powerful editing features), but I also use IDEs under Windows.
I rarely use code debuggers; it’s much easier for me to locate bugs by auditing the code and inserting debugging output statements.
I hope to buy another machine soon, because it’s not always convenient to run both the TightVNC server and the viewer on the same computer. Having a network would greatly simplify testing and debugging.
What’s been your biggest challenge? Besides not having a network at home?
Kaplinsky: Perhaps the biggest challenge has been finding time for all of the activity related to project maintenance — answering e-mails, auditing patches, working on new features, testing — all that takes a lot of time.
It’s a real advantage that the entire core development team lives in the same town. We meet often, discuss direction, and assign tasks and bugs to each other. Recently, we started working in pairs, and have found that this practice results in better overall productivity.
To close, if you could change one thing about the project, what would it be?
Kaplinsky: Well, that’s difficult to answer. I think if I wanted to change something about the project, I would start trying to change that.
Martin Streicher is the Editor-in-Chief of
Constantin Kaplinsky is the project leader of TightVNC. Constantin can be reached at firstname.lastname@example.org.