3. The Individual Pieces

3.1.1. The Hardware

The simple way to find out just what you need is to throw together a machine, just about any machine, and then see how it performs under the load it will actually be asked to bear. Then experiment a bit: Will the computer start to swap if you take out half of the RAM, will it speed up if you put in double the amount? See if you can get away with a slower processor or a smaller hard disk. If you can, get feedback from your users.

These trial runs can take time and may seem like a lot of work. The idea here is to fit the mock mainframe's hardware as exactly as possible to the task at hand so you can use the rest of the hardware for other stuff. Also, these trial runs can have surprising results. Most people have little experience in building a system for more than one user, and tend to overestimate the processor strength required while underestimating the amount of memory they need.

For example, for our current setup at home in 2003 -- two people running SuSE 8.2 and KDE 3.1 with a regular load of email clients, multiple browser windows, chatting and music playback -- an AMD Duron 1.0 GHz processor turned out to be overkill. We ended up with a secondhand SMP mainboard with two used Intel Pentium II Xeon 450 MHz CPUs (yes, Pentium "two"). Further experiments showed that 512 MByte RAM was slightly too much RAM: 384 MByte is fine, if you can live with the system going into swap once in a blue moon.

Decades of hardware marketing have produced computer users who reflexively go out and buy a faster processor when things slow down. But even the fastest CPU can't do more than one thing at once (we're ignoring tricks like hyperthreading), it is just somewhat better at faking it. To really do two things at the same time, you need more than one processor. Such systems are usually referred to as "SMP"-computers, from symmetrical nultiprocessing. You can get them with eight processors or more (Intel Pentium II Xeon, AMD Opteron, Intel Xeon) but in our price range, two CPU (dual-processor) systems are the most common.

More than one processor will go a long way towards keeping the system responsive even when there are lots of processes running. What it will not do is make a single process run twice as fast as on a system with a single processor of the same speed. One way to visualize this is to imagine you are doing your laundry: Two washing machines will get the whole job done in about half the time, but that does not mean that they now each spin twice as fast; each load still takes just as long as before. Things are actually more complicated, but this is a good rule of thumb.

Although processor speed might be important for gamers on the bleeding edge or people who want to simulate nuclear explosions on their desktop machine, the current clock speeds are simply perverse for normal use. You can usually get away with far slower processors than the market is trying to force down your throat, especially if you have more than one CPU. This is a good thing because SMP-mainboards are more expensive than normal, single-processor boards, and then you still have to buy that second processor. Keep in mind that more recent (AMD Opteron / Intel Xeon) SMP systems can have expensive needs such as a special power supply and extra large cases.

A multi-processor mainboard is not a must for a mock mainframe. But if you find your system groaning under multiple users, adding processors might give you a better deal than adding MHz.

(At the time of writing, there was also the problem of latency in the Linux kernel. In the 2.4.* series, the kernel is not pre-emptable, so occasionally a one-processor system will stall while something is happening in the bowels of the operating system. The 2.6.* kernels are supposed to be far more responsive, which would be the end of that problem and of this paragraph,too).

If you are going to build a system where it is important you don't loose your data even between those regular backups you perform every night right after you floss your teeth, you might want to consider a RAID (Redundant Array of Inexpensive Disks) setup. Very roughly speaking, a RAID setup duplicates the data on more than one hard disk, so that if one drive crashes, the others still have copies.

In summary:

• Think RAM before processor speed. With more than one user, you'll be using more memory and less CPU time than you expect.

• Two slower processors can be better than one fast one. A faster processor can switch between more than one task faster than a slow one, but two processors don't have to switch at all. This means you can use older hardware, which will almost always be less expensive even though you will need more of it.

• Consider SCSI and RAID. SCSI instead of IDE gives you more drives on one machine, and they are able to play amongst themselves without processor supervision. However, SCSI drives are more expensive and make more noise. RAID helps protect your data from hard disk failure. Both are for more ambitious setups.

When buying hardware for a mock mainframe, online auctioneers are your friends. Whereas your local computer store will try to sell you the newest fad, there is no shortage of previous-generation hardware at affordable prices online.

3.1.2. The Software

X Windows has one important aspect that we make extended use of with the mock mainframe: It is network transparent. The software responsible for controlling the input/output devices -- screen(s), keyboard, and mouse -- can be on a different computer than the programs you are actually running. With X, it is possible to sit in Beijing, China, with a 486DX and run your programs on a supercomputer in Langley, Virginia.

This has a whole number of advantages. Graphics are hard work for a computer; having them processed on a different machine than the program they belong to takes a big load off of the central computer. They are not so hard, however, that they can't be handled by an older processor. In the distant past of computer technology, there were special machines called X Terminals that did nothing but display graphics. Today, a spare computer with an Intel PentiumPro or an AMD K6 with 300 MHz is enough. This lets you have one big, fat machine running the actual programs and a whole host of cheap, small machines doing all the graphics. Which is exactly what we are looking for.

X Windows does have some drawbacks. It gobbles up a lot of bandwidth, so you will want a fast network. Also, some of the terminology is strange. The computer (or rather the software) that controls screen, mouse, and keyboard is called the "X server", because it "serves" the actual program, which in turn is called the "X client". In this text, we'll stick to "host" and "terminals" to avoid confusion.

There are all kinds of good Linux HOWTOs about X Windows, so again we'll just go through the basic steps and let you consult the special texts. I'm assuming that you already have X set up on the mock mainframe; your distribution should handle that part for you.

First, we have to start the program that handles remote X logins. This is xdm (X Display Manager). Depending on your system and taste, you might want to use the KDE version kdm or Gnome version gdm instead; both have nicer graphics and more features. Check the XDMCP Mini-HOWTO by Thomas Chao for more details. Normally, you'll want xdm (or whatever) to start up in the run level that you ususally use for graphics (for example, run level 5 for SuSE 8.2).

Even when xdm is running, the mock mainframe should not let you connect from the outside, which is good security. You distribution might let you change this with a simple entry in one of its configuration files (for example, SuSE 8.2 uses /etc/sysconfig/displaymanager). If you have to do it the hard way, you will want to change /etc/X11/xdm/xdm-config and /opt/kde3/share/config/kdm/kdmrc if you are using kdm.

After all of this is done, you are ready to test the link. Get a computer you know has a functioning X system, boot it in console mode -- not in graphics mode (runlevel 3 instead of 5 on SuSE systems, use init 3 as root from a shell). Log in and type

/usr/X11/bin/X -terminate -query <host>

where "<host>" is the name or IP-address of the mock mainframe. You should get the same X login prompt as if were sitting at the host machine.

3.2.1. Dual Boot Machines

Some people -- those without a time consuming job, a spouse, or children, for example -- will want to be able to spend lots of time playing hardware intensive computer games. Although more and more games are coming out for Linux, this usually means running a machine that has a closed source operating system such as Microsoft Windows. The solution to this problem is to set up the game computers as dual boot machines. The messy details are usually handled automatically by whatever distribution you are using; if not, check out the Linux Installation Strategies mini-HOWTO Tobby Banerjee.

The mock mainframe setup lets you keep the size and complexity of the Linux partition on a dual boot machine to a minimum: All it has to do is to get X running and connected. There are various way to do this, I usually just do the following:

1. Go to /etc/X11/xdm/. In the file Xservers, comment out the line that is either

   :0 local /usr/X11R6/bin/X :0 vt07

   or something similar by putting a hash mark ("#") at the beginning. This will stop the computer from starting up X locally during boot time.

2. In /etc/inittab, insert a new line such as (for SuSE 8.2)

   xx:5:respawn:/usr/X11R6/bin/X -query <host>

   where "<host>" again is the name of the mock mainframe. The "5" is the runlevel that boots with X; "xx" is just a label I picked; you might have to adapt both to your system (please be careful: Playing around with inittab can cause big trouble). This will start X with a call to the mock mainframe, and you should get the login window when you are on the dual boot computer.

Dual boot machines are nice if you don't have to switch between operating systems too often. All of the rebooting can quickly become a bore, though, and a dual boot machine cannot be considered truly expendable, given the price of closed source operating systems.

3.2.2. Linux Terminals

The Linux Terminal Server Project [http://www.ltsp.org] (LTSP) lets you use old hardware to put together bare-bones computers without hard disks that run as thin clients. These machines are cheap, quiet, quick to set up, and once they are running, require just about zero maintenance (unless, say, a fan breaks). At LinuxWorld 2003 in San Francisco, the LTSP project deservedly took the award for "Best Open Source Project". If you are going to have terminals that are in use constantly, it is hard to see how this would not be the best solution.

If you are using a 100 Mbit ("Fast") Ethernet network, stay above a 486DX; a Pentium II should be fine. See if you can scrape together about 32 MByte of RAM. You'll need a floppy drive for the initial phase. You'll also need a decent graphics card and a monitor -- "decent" doesn't necessarily mean a AGP graphics card with 128 MByte RAM, it means a clear, crisp picture.

The only thing you have to pay slightly more attention to is the network card. Find one that has a socket to plug ROM chips in: a "bootable" network card. You can get away with one that doesn't have the socket, but then you have to keep booting from the floppy. We'll also need the unique number (Media Access Control or MAC number) of the network card. On good cards, it is included on a little sticker on the board and looks something like this:

00:50:56:81:00:01

If you can't find it on the card, try booting the system with a Linux rescue floppy or any other kernel. The number should be displayed during boot when the card is detected.

Add a keyboard and a case and that's it. Notice we don't have a hard disk, let alone a CD-ROM. With the right kind of fans for the power supply and the processor, you have a very quiet machine.

When turned on, the Linux Terminal, like any other computer, looks around to see what it has been given in way of hardware. It finds a network card with a MAC and notices that it has a floppy with a boot disk (or a boot ROM in the network card. It starts the boot program). This in effect tells the Linux Terminal:

Got your MAC? Good. Now scream for help as loud as you can.

Using some more code from the boot program, the terminal starts a program called tftp (Trivial File Transfer Protocol), a stripped-down version of the venerable ftp. This downloads the kernel from the host machine. The terminal then boots this kernel.

Like every other Linux system, the terminal needs a root filesystem. Instead of getting it from a harddisk, it imports it from the mock mainframe via NFS (Network File System). If the terminal has very little memory, it can also mount a swap partition this way. The terminal then starts X, connects to the mock mainframe via xdm, and throws up the login screen.

This all happens amazingly fast. If you turn off all of the various BIOS boot checks on the terminal and boot off of an EPROM in the network card instead of a floppy, it happens even faster.

Running dhcpd, tftpd, and nfsd on the mock mainframe is a security risk you might not be willing to take. In the chapter on Support Machines, we'll show a way of getting around this.

Leave their configuration files untouched for now. The LTSP configuration and installation programs will do most of the work for you. There are some things you still need to do by hand (at time of writing, the LTSP people were working on a more automatic installation system). Edit the files:

Creating a boot floppy for the Linux Terminal is usually trivial. Armed with your type of Ethernet card, go to the website mentioned in the LTSP documentation (currently Marty Connor's ROM-O-Matic Website [http://www.rom-o-matic.net/]), and follow the instructions for a boot floppy. This should produce a file of a few dozen kilobytes that you can then put on a floppy and boot from. Later, when you are sure that your hardware configuration is not going to change and your setup works, replace the floppy by an EPROM that you plug into your Ethernet card.

Linux Terminals will probably require some user education. People who have only ever used Windows tend to have trouble visualizing a system where the graphics layer is not only independent from the rest of the operating system, but can also be accessed from multiple screens. The best way to explain this is with examples. One trick that people new to X just love is when programs start on one terminal and then appear on a different one. To enable this (but only in a safe environment!), sit down at a terminal and type

xhost +<host>

where "<host>" is the name of the mock mainframe. Then, move to a different terminal and start a program such as xeyes or xroach:

xeyes -display <terminal>:0 &

The eyes should appear on the first terminal's monitor, providing endless amusement for all. When you are done explaining what happened, remember to retract the privileges again on the first terminal with

xhost -<host>

You can also use this example to point out why it is dangerous to use the xhost command.

Another question that usually comes up is the speed of Linux Terminals. One nice way to demonstrate this is to run a series of screen savers from the xlock suite. For example

xlock -inwindow -mode kumppa

or more generally

xlock -inwindow -mode random

Though the results will depend on your hardware, this usually takes care of any doubts.

If you are using a desktop such as KDE that allows you to shut down the computer when you log off, make sure that this function is disabled. Otherwise, your users will shut down the mock mainframe when trying to get out of the terminal. Tell them to just turn off the power once they have logged out. Older users will feel a sense of nostalgia, and younger users will stare at you as if you have gone mad. Such is progress.

3.2.3. Real X Terminals

If fortune smiles on you or you are rich, you might find yourself with a real thin client. Installing one is usually not much different than setting up a Linux Terminal, except that you will need the software from the vendor, you will probably have to pay for support, and when something goes wrong, you won't be able to fix it yourself.

The Linux Documentation Project has a number of general and special HOWTOs on how to set up X Terminals, for example the Connecting X Terminals to Linux Mini-HOWTO by Salvador J. Peralta or the NCD-X-Terminal Mini-HOWTO by Ian Hodge.

3.2.4. X Server Programs

As a final way of connecting to the mock mainframe, there are "X server" programs that run under different operating systems (remember, the X server powers the terminal side of things). These let you log onto Linux machines with an operating system that does not natively run X.

Most X servers for Windows cost money, in some cases a lot of money. The single exception I am aware of is Cygwin [http://cygwin.com/xfree/], which ports X (and GNU tools) to Windows machines.

If you have an Apple computer with OS X, you are in better shape. Check the XDarwin [http://www.xdarwin.com/] project. XDarwin is an Apple version of the X Window System that sits on the Darwin operating system -- a variant of BSD -- that is the core of OS X.

(There is one GPL X Server written in Java you might try: WeirdX [http://www.jcraft.com/weirdx/], though the author points out it is not made for heavy loads.)