Linux has long provided tools for running multiple programs
simultaneously. In the X Window System
environment, in particular, you can run multiple programs, each in
its own window, on one screen. Most window managers take this a
step further by implementing a pager, where
each “page” hosts its own unique collection of windows,
enabling you to run dozens of programs without cluttering your
screen with a confusing mish-mash of windows.
Sometimes, though, even a pager doesn’t go far enough
— you might want to run multiple window manager or desktop
environments, perhaps even as different users. Similarly, you might
want to run one desktop environment on your local computer while
accessing another computer, including its own desktop environment,
using the first computer’s screen and keyboard. Fortunately,
Linux provides tools to do all of the latter.
One solution is to run multiple instances of your X server, but
link each one to a separate Linux virtual terminal. This approach
works well, but has the disadvantage of requiring awkward
keypresses to switch between environments. Another approach is
Xnest.
Xnest is a standard part of the
XFree86 and X.org-X11
X servers, and provides an X server that runs inside a standard X
window. Using Xnest, you can run two
different GUI environments, one inside another’s window. The
Xnest– hosted session can function under a
different username than the main environment, or can link to a
remote computer, if necessary. Xnest can be
handy for local or remote system administration (you can log into
remote computers or test a user’s malfunctioning GUI
configuration) and for day-to-day (non- “i”>root) functions (for remote system access or to run
multiple desktop environments).
The Relationship Between X and Xnest
To fathom X and Xnest is to understand
the role of servers. Put succinctly, server
software responds to data transfer requests from other
(client) software. In the X model of the world, client programs
(such as Mozilla Firefox, OpenOffice.org,
and xterm) request data transfers to and
from a computer’s screen, keyboard, and mouse. The X server
manages those resources on behalf of its client programs and
leverages network protocols to connect clients from remote systems.
The fact that a human interacts directly with the screen, keyboard,
and mouse is irrelevant. So is the fact that the X clients and
servers often both reside on the same computer. It’s the
nature of the interaction between the X server and the programs it
manages that’s important in defining X as a server.
Where does this leave Xnest, though? This
program is both a client “i”>and a server: Xnest runs within a
normal X session, making it a client of that X session.
Simultaneously, Xnest functions as an X
server to additional programs, providing them with a (virtual)
display, keyboard, and mouse.
In principle, a program that runs within an “i”>Xnest session needn’t know that “i”>Xnestis using another X server’s calls to manage
its own input and output. In practice, though, this fact does have
consequences. In passing its clients X calls on to its own X
server, Xnest introduces inefficiencies and
opportunities for things to go wrong. Thus, in practice, programs
sometimes run more slowly or exhibit display quirks when run within
an Xnest session. These problems
aren’t usually very onerous for typical office programs or
the like, but they can cause games and video-display programs to
behave poorly.
“http://www.linux-mag.com/images/2007-03/guru/xnest.png” class=
The main advantages of Xnest are that
it’s a native X protocol, so it entails relatively little in
the way of overhead and it integrates more smoothly with
applications. You’re less likely to see video redrawing
errors or other glitches with Xnest, for
instance. (This isn’t to say that “i”>Xnest is perfect in this respect; it is imperfect,
particularly when you try to run graphics-intensive programs, such
as games.)
VNC, by contrast, is a platform-neutral protocol, so its main
advantage is that it can be used on multiple operating systems,
including Linux, Windows, Mac OS X, and
others. This fact can be a big plus when you need cross-platform
access, but it’s not very important for Linux-to-Linux (or
Linux-to-Unix or Unix-to-Linux) access.
Xnest and VNC also use different
client-server relationships. You sit at the computer that runs the
VNC client and use it to access a (possibly remote) VNC server. As
noted earlier, though, you sit at the Xnest
server and use it to access a (possibly remote) X client. This
reversal of relationships can have consequences in some situations,
such as when you’re using a computer that resides behind a
firewall. Typically, VNC will require less in the way of special
firewall configuration to work correctly. (In the case of remote
access, the XDMCP server is on the X client computer, which further
complicates matters when using X from a firewalled computer.)
Overall, Xnest is usually a superior
solution for Linux-to-Linux connectivity on a local network,
whereas VNC is superior when used in a cross-platform manner and
sometimes when working through a firewall is necessary. If in
doubt, you may want to try both tools and see which one works best
for you.