If you are from the Windows world and aren't familiar with Xwindows, probably the closest parallel is to remote control software like PCAnywhere. In more sophisticated implementations, however, Xwindows can be substantially more interesting. If you have a reason to make use of it, you can readily control and display the output from several machines at once on a single desktop. The potential for applicability of this extend well beyond mosixview to other applications within that environment. The few photos and screen shots on these pages, for example, were manipulated with the Gimp (Gnu Image Manipulation Program), a powerful image manipulation program freely-available within the environment, and the diagram of Ralphzilla on the hardware page was done with a similar diagramming application (xdia). As with many GNU applications, the environment may not be as "shrink-wrapped" as that to which you are accustomed, but they allow you to substantially extend your capabilities in contexts that might not be considered to justify a substantial software purchase.

As you investigate Xwindows, however, you may run into some initial confusion over terminology. In the original parlance the display software on your local desktop was referred to as the X server and the software feeding that display from the remote host was referred to as the X client. While there is a coherent rationale behind sch characterization, it does run counter to the more general expectation that equates client with desktop and server with remote, and recent usage has evolved to correspond to the more common expectation. You can still, however, run into implementations that use the more formal nomenclature. If I'm not mistaken, Hummingbird Exceed is one. You are also more likely to run into discussions revolving around the more formal terminology as you read materials that are a few years old.

VNC
The easiest way to implement remote Xwindows display is through the use of the Virtual Network Computer (VNC) package originally developed by AT&T. Using VNC is very much like using PCAnywhere, and indeed there is a version of the VNC server that can be installed on a Windows machine. To install the server on a debian box simply issue the command "apt-get install vncserver". You should make sure as well that the appropriate fonts are installed on the debian machine to allow the desktop to be established; the Xvnc server may simply not start without them The following command will ensure that virtually all of the English language fonts are installed: "apt-get install xfonts-base xfonts-75dpi xfonts-100dpi".

Once the fonts are installed, type "vncserver", which will run the vncserver script, calling Xvnc with the appropriate parameters. You will be asked to set a session password, and Xvnc will be loaded. Make a note, mental if nothing else, of the session ID that was created. You will need to know that to connect to the session. For example, the session ID for the session I started on Ralphzilla was ralphzilla:1. If you have installed the vncviewer program from the VNC site you can now start it, and when given the session connect dialog enter the session ID as noted. Given that the session exists, you will be prompted for the password, and a window will open on your machine in which the applications specified in the /etc/X11/Xsession file are started. If you installed the Gnome environment, as I did, you will be gretted by the Gnome desktop. Should a session not be found, check the file .Xsession-errors in the home directory of the ID under which you ran vncserver for diagnostic information.

That brings up an important point. The id under which you ran the vncserver script is the id under which the displayed desktop is running. If you logged in as root and started the script, the remote display is logged in as root. If you have reason to log in with such authority and have somethinng to protect on the machine, you should take care not to leave your workstation unattended without locking it against unauthorized use.

To the right is a sample of what your desktop might look like running mosixview under gnome, and displaying in a vnc window. As you can see, the entire window is the gnome desktop, and mosixview is displayed on that desktop. (I started mosixview by typing "mosixview" in the dialog displayed after choosing "Run" on the gnome menubar.) You can see my Windows 2000 menubar along the left-hand side of the desktop, the vnc window could be minimized or resized to a smaller size to gain access to the icons behind it or to arrange window placement to facilitate access to Windows applications. My own sense is that vnc is well-suited to a context in which a machine or cluster of machines is primarily dedicated to an application or suite of applications for which a consistent interface is desired. By creating a /etc/X11/Xsession file that calls a desktop configured in the way that you wish, you can readily share an application like Gimp or xdia across an entire network at very low cost. It would be interesting to extend the current investigation of mosix into such areas, but a cluster configured for such use would have substantially different operating characteristics than the one I've constructed, and its configuration should reflect that. Rather than get into these issues at this point, they will be discussed in the alternative mosix implementations section.

Xserver
The second model for remotely displaying Xwindows output is, to my mind, more flexible and customizable, but also involves some cost. If you can't tell, it is also my personal preference and the way I have constructed my own environment. Illustrated by the desktop depicted at right, it involves the use of an Xserver (client?) on the Windows machine. In this configuration, the output from Xwindows applications on several machines can be displayed on seperate windows on the Windows desktop, which you might also hear described as the root window. In the illustrated desktop, you can see the gnome toolbar at the bottom of the screen, along with the mosixview window. These are both running on Ralphzilla. On the left-hand side of the desktop you can see the jpg displayed on the home page of this document opened for editing in the Gimp, the toolbar for which is immediately beneath the window. This application is running on bridget, the p75 that normally serves to run my administrative scripts. (For those who wonder, bridget acquired its name when I initially configured it as a test of a dual-homed box serving as a bridge/firewall. I had named the machine "bridgetest", decided that was a little boring, and as I backspaced over the last three letters I recognized the name bridget and the name stuck.) On the right-hand side of the desktop is a window running taper, a linux tape-backup package. That application is running on a-ralph, a p133 housing two tape drives that I have configured as a backup server. Behind these windows you can see my Windows 2000 desktop.

As I said earlier, constructing such a configuration requires Xserver software on the Windows machine. I am not currently aware of any free Xservers in the Windows environment, the commerically-available packages I've seen range in price from $25 to several hundred dollars USD. The package I use, and with which I am quite happy, is Xthin-pro from LabPro, which fits quite happily into the lower middle portion of this range. (Though I have no problem recommending the package, the standard disclaimers should apply stating that in no way does my recommendation constitute an endoresement by my employer.) I will include links to several Xserver vendors in the links section. You are, of course, free to choose whatever youy wish. Evaluation versions of many packages can be downloaded from the relevant vendor's web site, so you don't actually have to purchase the package to try it out and see if you like it.

Directing the output from an Xwindows application on a remote machine to your Windows machine using one of these packages is really quite simple, as long as you keep the way Xwindows works in mind. First, Xwindows relies ip addresses to direct the remote ouput. Domain name resolution is beyond the current scope of this document, it is doubtful that in the environment you might be constructing you'll have to worry about it. I may add that at a later date, but for now we'll assume that hostnames and addresses are either statically configured or are reserved for specific machines in a dhcp lease range to allow them to be specified as set in a hosts file. If you don't understand what I just said, don't worry about it, it's not likely to be a problem for you.

If you make sure that each of the machines involved in your environment are identified in each other's hosts files, you'll save yourself a few heachaches. On Windows machines, those files are located in different places. In Win9x, they are in the c:\windows\system32 directory, and may not exist as hosts when you first look. As long as the tcpip protocol is installed in network setup, however, the will be a file there named "hosts.sam" (for sample). You can customize this file and rename it, or simply copy into the directory a file you created. On NT 4, Windows 2000, and Windows XP machines it is in the %systemroot%\system32\drivers\etc directory (generally, the systemroot directory will be c:\winnt or c:\windows). On the linux machines, of course, the relevant file is /etc/hosts.

Next, you need to set the DISPLAY environment variable on the linux machines from which you wish to redirect Xwindows output. Remembering that the default shell in a debian setup is the bash shell, you can do this for any given session by simply logging in as the user for which you wish to redirect output and typing "setenv DISPLAY=(machine):0.0". For example, if the machine to which you wish to redirect output is named "ralph1" you would simply type "setenv DISPLAY=ralph1:0.0". (The 0.0 refers to session and display window designations that are not very pertinent in a Windows environment. For your purposes at this point just remember that form.) Setting the variable like that is fine for testing purposes, but if you are going to want to be doing this frequently you'll want to set that variable automatically. This can be done modifying the shell initialization script to include the line setting the DISPLAY variable. In the bash shell, that file is named .bashrc and is located in the home directory of the pertinent userid. For example, for the root user you would want to edit the file /root/.bashrc. If you had created a user named shark, for example, you would edit the file /home/shark/.bashrc. Just put the command "setenv DISPLAY=ralph1:0.0" in that file and each time you spawn a shell under that id the environment variable will be set.

Now you are ready to go. Start the Xserver package you've installed, then start a telnet session on the remote machine. If the DISPLAY variable is set and both hosts are in each other's hosts files, all you have to do is start the Xwindows application. Type "gimp &", for example, and as long as the gimp package is installed on the linux machine gimp will initialize, displaying its toolbar on the Windows machine. (The ampersand simply tells the session to background the process, so your telnet session won't be totally occupied with the gimp application, and you can also do other things without having to start another telnet session.) Pretty cool, huh?

If you're not really familiar with the environment, you should recognize that there are still a number of wrinkles that will take some getting used to. For example, if you were to desire to print to a networked printer, you will need to direct the output to that printer from the linux machine, because that's where the stuff you want to print actually is. There are a number of ways to do this, I may describe some of them in a section on samba. It is also pertinent to remember that if you are working with files on that machine they are on that machine, and you need to either use samba to treat the hard drive on the linux machine as a networked drive from your Windows machine or mount a shared directory on the Windows machine to a mount point on the linux machine to achieve a level of transparency in how images or whatever are handled between the two machines. Nonetheless, you're off and rolling.