"Linux Gazette...making Linux just a little more fun!"

Sometimes you must have X on the desktop--at work, that is. At home, you would have several choices from your well-appointed stable of Linux ponies. Work is another story--you have the corporately sanctioned productivity tool running on your desktop, and adding an X emulator application is going to cost somebody some money. You blew your software budget for the year on compilers. So what are you going to do now?

Today's typical work environment includes a desktop PC running a version of the Windows operating system. If the job is writing memos and sending around Word documents, that's a reasonably adequate solution. If the job is developing and testing cross-platform GUI applications, then running an X application from your desktop is an effective way to get the work done.

The Trafvu Project

Trafvu is an application for displaying results from traffic simulation models. Such models can be used for planning and design purposes. For example, suppose the city fathers attract the Olympics for the year 2004. What changes need to be made to the traffic system so that the city does not suffer from massive gridlock during the Olympics?

Trafvu was developed in C++ to run on Windows and the X Window System, with XVT being used as a cross-platform tool. For a software development lab, we had several Pentiums running Windows 95 and NT and some Sun workstations running Solaris 2.5. Generally, everyone on the project had a desktop system, and the lab was used for collaborative efforts, such as fixing bugs, and for design meetings. Several of the lab machines were set up as file servers. The application source code was maintained on a Windows NT server using the Mainsoft Sourcesafe software revision control product. Typically, the project source code were extracted to a local machine (lab or desktop), some source files checked out, and C++ code developed or modified and tested; then the modified files were checked back in.

Initially, when porting code from Windows to X, files were transferred to a UNIX workstation using FTP, followed by a repeat of the compile, link, test and debug cycle. As the project progressed, SAMBA was installed on the Sun workstation, so that developers could access their home directories on the Sun workstation from the Windows browser. Then files could be extracted directly to the file system on the workstation. Opening a TELNET session from the Windows PC to the Sun workstation permitted concurrent compilation and linking on both Windows and X.

At this point in the cycle, the source code had been modified, compiled, linked and tested under Windows. Now we needed to test it on the X Window System. We needed a way to run an X application from our desktop PC.

X Emulator Options

There are several ways to provide X on the desktop. A few years ago, X-terminals were very popular. An X-terminal typically has nice real estate (i.e., a large screen), some memory, no local disk space and costs about $1000 to $2000 (most of the expense is that nice monitor). At boot time, it loads an OS from a boot server, so setting up the boot server becomes the headache. As PC processors became cheaper and more capable, the price of hard drives fell through the floor, so the PC desktop became very popular. Typically, PCs run a version of the Windows operating system. Using them as X terminals requires additional software for X emulation. For example, with Hummingbird's Exceed, a typical X emulator, you can run your favorite X application on a convenient UNIX workstation and have X display on your desktop computer. X emulation products for Windows generally cost a few hundred dollars per machine. Currently, network computers (NCs) are being pushed as a solution to the software application configuration nightmare brought on by the proliferation of desktop PCs, and typical prices seem to be about $700US per unit.

Several options are available and if a few hundred dollars is not a concern, the X emulator application is probably the ticket. If, on the other hand, no one will sign the purchase request or many machines need the capability, then a cheaper option is needed.

Linux to the Rescue

With hardware prices falling and Windows applications becoming more bloated, there's usually some older hardware sitting around unused. Who wants to attempt to run Visual C++ 5.001a under Windows 95 on that 486/66 with a 1 GB hard drive? I won't volunteer. Next question--what OS runs X quite comfortably on a 486 with 16MB of memory? The answer is Linux.

Thus, an alternative to the X emulation application is running Linux on the PC. Set up the PC as a dual boot machine and simply boot Linux to run X applications on the desktop. The advantage of using Linux is that no purchase requests have to be signed. Just bring the CD-ROM from home, find some free time and disk space and install it. The disadvantages are finding the time to do the installation and the need to boot between running Windows or X. The hurdles in the process are finding about 300MB of spare disk space and a three-button mouse.

Setting up Linux

Initially, my company installed Linux 1.2.13 on a Gateway 486/66 and a no-name clone 486/66. There are numerous resources on installing Linux, if you need that information. However, having copies of books such as Running Linux and Linux Network Administrator's Guide was essential for us. Internet access for HOWTO documents can also be helpful. Installing on the Gateway and no-name were mostly straightforward. The Gateway did not have a CD-ROM drive, so the CD-ROM was exported from one of the Sun workstations. The Slackware distribution has the option of installing over a network and this worked well. Both the Gateway and the no-name had SCSI cards, and additional SCSI disks were salvaged from other machines for installing Linux. Setting up XFree86 on the no-name was a chore because of the video card. Generally, the cheaper a PC, the less documentation is provided with it. So putting up X on the no-name took quite a bit of experimentation. The Linux multiple console capability is very handy when installing XFree86. ctrl-alt-F1 brings up the screen used to start X (use startx command) to look for error messages. alt-F7 gets you back to your X session, and ctrl-alt-F?, where ?=2, 3, 4, 5 or 6, gets another login session for checking log files, etc.

Later in the project we installed Linux 2.0.0 on a SAG Electronics dual-processor Pentium Pro 200 MHz with an Imagine Number Nine 128 Series II video card with 4MB. The Pentium Pro came with a 4MB hard drive, and a 400MB partition was allocated for Linux. Installation on the Pentium Pro machine was more difficult because the hardware was so new. Video drivers for the Number Nine card were in beta, and the generic SVGA drivers wouldn't work. Upgrades to XFree86 took about 10-20MB of downloading from https://www.xfree86.org/ and perhaps a couple of hours to install and test. The three-button mouse on the Pentium Pro insisted on being difficult, but this was remedied by the advice in the three-button mouse mini-HOWTO.

I tried the two-button mouse emulation and found it to be just good enough to get me in trouble. I would think I had the timings down, roll into an xterm with the root prompt and paste the equivalent of War and Peace in at the command line. (Gee, I hope I didn't do something like rm -rf / in that session.) I did find coworkers who were willing to trade a Logitech three-button mouse for my two-button mouse. Once one is used to the X version of ``cut and paste'', it is very difficult to do without it.

The three PCs were set up with dual boot capability. Initially, we just used a floppy boot disk for Linux, since making one is easily accomplished, and the MBR (Master Boot Record) for Windows remains intact. Later, when Linux had proven itself useful and we were interested in convenience, we added LILO to the MBR. The PCs were frequently used in Windows to edit documents, prepare spreadsheets, etc. It was very handy to access these files without having to boot Windows. Accessing Windows files while the PC is running Linux can be done using SAMBA. For FAT file systems, set up a mount point in /etc/fstab with a file system type of msdos in order to make the Windows file system fully accessible while Linux is running. Install SAMBA on the Linux machines, export the Windows file system through the smb.conf configuration file, and then you can access the files through the Windows browser (File Manager or Explorer, depending on your Windows flavor).

It's encouraging to see file system drivers for FAT and HPFS, since accessing the files from the other operating systems is very convenient while running Linux. However, with current hard drive sizes, FAT is outdated and offers very little security. Microsoft offers some alternative file systems, such as VFAT and NTFS. However, it appears that specifications for these files will remain exclusively with Microsoft. So, although work is in progress on the NTFS driver for Linux, I don't think NTFS support under Linux will be available any time soon. Perhaps a better design choice is to minimize the usage of proprietary file systems on multi-boot machines.

Typically, the Linux PCs were used for an X-terminal login to the Sun workstations. To make this convenient, the ``Goodstuff'' button bar was used. The environment variable DISPLAYHOST was set in this way:

export DISPLAYHOST=vader:0

rsh remote-host date

A side benefit of installing Linux is backing up the file system over the network. A PC usually doesn't have a tape drive, whereas a more backup-conscious Sun workstation may have a 5GB DAT drive. From the Linux PC, the dd command with the appropriate arguments will back up your hard drives to a tape drive on a remote workstation. A crontab entry is good for this type of backup for nonwork hours, so that network bandwidth impact is minimized.

Synopsis

There is a steep learning curve to installing Linux, and my initial installation of Linux took several days. Recently, I installed Slackware 3.2 (2.0.29 kernel) in about two hours, which included bringing up X and restoring home directories. Recent efforts at improving Linux's ease of use have been well spent and make Linux a more viable alternative for use at work.

A spare X terminal is very handy to have around when debugging an application. It is possible to stop events from getting to the debugger on the Sun workstation, so that the console is essentially locked. However, if there's a free X display, set the DISPLAY variable there before running a command-line debugger.

Booting multiple operating systems is an interesting twist on cross-platform application development. If I could have built the trafvu application using the GNU compiler (some issues with the Rogue Wave libraries precluded this), I could have used a single PC for both Windows and X development and testing.

We have used Linux and XFree86 on a daily basis for over a year and have been impressed with the solid performance.