My Next Pentium Is A DEC Alpha

With the propagation of Linux onto non-Intel platforms, we are no longer tied to PCs for running our favorite *nix. I have been getting very leery of the “Pentium per 6 months” phenomena we've been seeing the last couple of years (i.e., whatever you buy is obsolete before you get it home). Each provides incremental enhancements, but nothing to get too excited about.

My goals were to find a new machine that could run Windows NT well, and provide me with an interesting platform for Linux work. (Well, someone has to study the enemy!) Limited to Pentiums, running NT on anything less than 133 MHz would not cut it. Frankly, I'm not expecting anything fun from the Pentium family until the HP/Intel PA-Risc merger chip is released (the forthcoming P7). So, it was off to other directions. A quick market survey indicated that DEC Alphas met my requirements, are competitively priced, and deliver good performance.

I settled on the DEC Universal Desktop Box (UDB), a.k.a. the Multia. This is a fairly compact (2.8x12.5x12.5 in) package which includes a 166- or 233-MHz Alpha, 24MB memory (expandable to 128MB), 256KB cache, Ethernet, floppy, two serial, one parallel, SCSI-2, sound and video components. The 166-MHz unit comes with an internal 340MB hard disk, or else a 520MB unit. Expansion is possible through a PCI card slot and two PCMCIA slots. The video chip supports multisync monitors from 640x480 to 1280x1024, 60 Hz to 75 Hz refresh rates; and the sound card is a clone of the Microsoft Sound system.

I found that the internal hard disk was too small. Removing it, however, was out of the question. Digital put in a 2.5" form-factor drive, a size popular in laptops, but which are generally IDE drives. I could force a 3.5" SCSI-2 drive in, but who would want the drive I removed? It's not too bad. I use the internal drive for boot partitions and swap space, and an external 1GB disk and a CD-ROM drive.

The Multia comes with a three-button PS/2 mouse, but no keyboard. You can obtain UDBs that support PS/2- or PC/AT-style keyboard connectors. Choose a keyboard type and a standard Multi-Sync monitor, and you are ready to run.

Alpha motherboards have PCI adaptors. Therefore you have a ready supply of PC-compatible adaptor cards that can be used with the Multia. For example, there are drivers for joystick adaptors. Even though the UDB comes with most of the features you would want anyway, there's no reason why you could not install a different video card, ISDN controller, etc., as drivers become available.

What makes the UDB special is the lack of frills. Digital, in an effort to keep the price down, markets the machine without software or licenses, and only about three pages of “documentation”--a pictorial essay on how to connect external devices to the connectors, how to open the case and insert RAM, a pointer to Linux on Alpha homepage (www.azstartnet.com/~axplinux) and information on how to join the declinux mailing list.

Digital decided that they rather liked the “Multia” name. The name therefore refers to both the Alpha version I am describing to you, as well as an Intel Pentium version. The boxes look very similar, and target the same market. I have not seen documentation that refers to the Intel Multia as a UDB, whereas the names are interchangeable for the Alpha version. Windows NT refers to the unit as a “Multia”, and the Linux FAQ prefers “UDB”. So take your pick, but be sure the DEC person knows which one you mean.

This machine seems perfect for Linux and Windows NT. In fact, DEC, seeing a market for a low-cost *nix, participated in developing the port with Linus and the Internet community. The result is a 64-bit Unix that is binary-compatible with statically-linked DEC Unix (formerly OSF-1) applications. So, the availability of commercial software is not too big an issue. If you need a program like Netscape or WordPerfect, get the DEC Unix version. If it is statically linked, it should run with no problems.

Alpha Linux is interesting in that one of the main repositories of platform-specific code is kept on gatekeeper.dec.com. [See “Porting Linux to the DEC Alpha”, by Jim Paradis, in LJ #19—ED] Equally interesting is the fact that a lot of the platform-specific code is written (and source shared by) DEC engineers.

The DEC Alpha source has been merged back into the generic Linux version 1.3.x. The result is, you can go to Linus' home page and download and build the linux-pre2.0.10 with full Alpha support. But, there is no support (yet) for sharable libraries (neither about QMAGIC/ZMAGIC, nor ELF). Plans are afoot to go to ELF while retaining DEC Unix compatibility via statically-linked binaries.

BLADE 0.3 based on 1.3 kernel; freely available

Red Hat 2.1 1.3.57 kernel; commercial distribution; shipping

Craftworks 2.1 1.3.89 kernel; commercial distribution; shipping soon

Of these, BLADE 0.3 is the original stable distribution. The README file at gatekeeper.dec.com suggests that you go with a commercial distribution instead. BLADE therefore is basically recent legacy code, albeit freely available.

BLADE, Red Hat, and Craftworks all come with the requisite kernel, compilers, libraries and utilities you would expect from a baseline Linux distribution. The commercial distributions, however, come with all the “goodies” you would expect (and get) from their Intel brethren—such as editors, networking, X-Windows, TCL/TK, etc.

What differentiates one commercial distribution from the other is the package mix that each vendor ships with his CDs. Ease of use of the installation packages has to be weighed in. The documentation is essentially the same for the Alpha and the Intel versions. Both Red Hat and Craftworks, however, come with installation instructions. Red Hat adds the Alpha FAQ to the documentation. Either way, there is little enough unique about the AXP to require custom documentation.

My UDB came pre-installed with Windows NT and Linux (I had ordered Red Hat 2.1). The vendor, DCG Computers, installed a pre-release of the Craftworks 2.1 package, so I could help them compare and contrast the two versions. Here are some of my findings.

The Craftworks product is newer than Red Hat 2.1; you get Linux kernel 1.3.89 versus Red Hat's 1.3.57. Both are fairly stable, and of course, you can always download the latest kernel no matter which package you use.

The DEC DC21030 display controller chip (aka the TGA) is built into the Multia. The Red Hat 2.1 does not come with an X display driver for this chip, although Craftworks does. Other video drivers come with the XFree86 port for the Alpha, including the S3, P9000, and Mach 64 (which both Red Hat and Craftworks have.) When Red Hat 2.1 was released, you had to buy a PCI video adaptor to run X on the UDP. In the interim, DEC has released an X server for the TGA, which Craftworks includes. Craftworks also comes with Lesstif, a Motif 1.2-like widget library.

The great equalizer is the installation program. Both run reasonably well, but each has little personality quirks that provide a few minutes' grief. The Red Hat package will partition your hard disk, make the swap partition (mkswap), but then forget to make the ext2 partition (mke2fs). Fortunately, you can switch over to the second virtual terminal and take care of this omission before continuing the installation process.

The Craftworks install package is somewhat overzealous in enforcing the size of the swap partition. They want you to have a 32 MB swap. That is fine, but I made a smaller one with Red Hat previously. The notification/irritation prompt keeps coming up about the small swap partition. It wouldn't let me do anything about it, such as kill it, and resize the partitions, but it was very persistent in its warnings. I finally had to bring up Red Hat's partition editor to delete all partitions by hand before I could continue. It could understand an empty partition table, but one that was made incorrectly beforehand could not be dealt with.

The trials and tribulations provided by the install programs yielded more amusement than anything else. So, the question is, which distribution would I use? Well, before I chicken out and tell you that I hand-merged things that I liked from both distributions (such as: glint from Red Hat, NYS shadow passwords from Craftworks, the Craftworks X Server, 1.3.89 kernel, etc.) let me mention to you that not all the candidates have been heard from.

Red Hat is scheduled to release version 3.0.3. I noticed that they have the new X Server. No doubt their standard packages have been updated to match their Intel 3.0.3 offerings.

On PCs, the boot ROM attempts to read the initial sector of the primary floppy drive, or of the primary hard disk. Bootstrapping from that sector, the rest of the operating system is loaded. This design is fairly limited and the fact that the DEC moves away from that nonsense is the good news. The SRM Console Loader for the Multia comes with the ARC loader. ARC is pretty cool, insofar as you can have multiple operating systems configured (from which you may choose at boot-time); these systems' boot sector can exist on any partition of any addressable device, including the floppy disk or CD-ROM. In fact, you can have vmlinux on the floppy drive and have the root partition be on a hard disk. This is all the good news.

The bad news is that I am a dangerous fellow. As I mentioned, I had DCG Computers install Windows NT and Linux together. Unfortunately, too much space was given to NT (more appropriately, I like to fit 2GB of Linux onto a 1GB partition). So, there I was, an hour after unpacking everything and firing it up, readjusting the partition table and trying to keep the ARC loader appraised of what I was doing. Well, I ended up with ARC knowing of NO operating system, and the partition table being empty, and I could boot neither NT nor Linux! Now comes the moment of gravely earned education...

Craftworks comes with the boot and root/installation partition on floppies. There are instructions on how to reprogram ARC to understand that the floppy disk has the operating system. Red Hat has the images of these floppies on the CD-ROM, but you have to find a way to get those downloaded to floppy. A friend with a PC and CD-ROM drive is useful (definitely, definitely, definitely make master copies of those floppies after you finish your installation).

ARC was written by Microsoft and DEC. Its specialty is loading operating systems from file systems it understands, specifically MSDOS FAT partitions. Once you point to one, you tell it which executable to run in order `to load the desired operating system. For Windows NT, that would be OSLOADER.EXE. For Linux, that would be MILO. But, the requirement here is that your loader has to be found on a FAT file system (it could be in any subdirectory, given whatever name you'd like). Let me add to the fun by telling you that I initially received the UDP without the Craftworks CD-ROM and boot diskettes (they came the next week). Oh, and don't forget the three pages of documentation: none of the pictures told me what I wanted to know about ARC.

Thankfully, I had Windows NT, and ARC was written to simplify NT support. There's a menu option called “install NT”, which will install from the CD-ROM. The Microsoft documentation for any non-Intel platform was sort of humorous, saying, “see the vendor's documentation for detailed installation instructions for your platform.” But, then it said to run cd:\system\setupldr. System, system; what's a system?!?

Thankfully, the Pentium was nearby, and a quick directory of the NT's CD-ROM yielded that there were several directories, named after risc processors, where setupldr could be found. One of which is “alpha”... (Insert “D'Oh!” here).

Off to the races I went. Setupldr allowed NT to be installed, which gave me a nice FAT partition. On that Windows NT partition I placed a copy of MILO. A fun Saturday, which I stretched out to 4 am Sunday as the result ...

So, could I have moved the Red Hat CD to the Pentium and had it make the boot floppies? Yes, but if I remained Alpha-centric, I was doomed. Also, I had to learn ARC, and expected that having Windows NT install itself would educate me enough to get through it. Which it did; but if you look at something like this with no background, it looks scary:

LOADIDENTIFIER=Linux
SYSTEMPARTITION=multi(0)disk(0)fdisk(0)
OSLOADER=multi(0)disk(0)fdisk(0)\linload.exe
OSLOADPARTITION=multi(0)disk(0)fdisk(0)
OSLOADFILENAME=\milo
OSLOADOPTIONS=

Which, if I look at SYSTEMPARTITION, tells me that the system partition can be found off the Multia, off of the floppy disk controller, on floppy disk 0. As opposed to my current Linux setup:

LOADIDENTIFIER=Linux
SYSTEMPARTITION=scsi(0)disk(0)rdisk(0)partition(1)
OSLOADER=scsi(0)disk(0)rdisk(0)partition(1)\linload.exe
OSLOADPARTITION=scsi(0)disk(0)rdisk(0)partition(1)
OSLOADFILENAME=\udb.arc
OSLOADOPTIONS=boot sdb1:vmlinux.gz root=/dev/sdb1

Which says that I should go to the SCSI controller, a SCSI hard disk, raw hard disk 0, partition 1. Do you notice that this looks like a hierarchical file system? And so it does, except that it is describing the controller/hardware path to get to the boot code.

Of course, I caused my own disaster, but that makes the repairing much more rewarding (you have that relief factor). After the first weekend of fun, what could I do for amusement? Porting over some of my favorite utilities would be fun. Both Red Hat and Craftworks take some of the fun out by already porting over the Apache Web Server and browsers, but I could still have some fun by moving other stuff over. So, the next question is, “What do you have to know to port code to Alpha Linux?”

X-Windows applications that use IMakefiles basically configure themselves out of the box. GNU software that uses autoconf/configure to figure out what system it is running on tends to get confused. The machine configuration string that it synthesizes looks like alpha-unknown-linuxaout. This is confusing because it is an alpha that is not running DEC Unix, nor is it Linux running on an Intel system. What to do? Well, I usually put in the following code segment into configure:

alpha-dec-osf3* )
    machine=alpha opsys=decosf3-1
  ;;
  ## We're Alpha Linux
  alpha-*-linux* )
    machine=alpha_linux opsys=linux_axp
 ;;

  ## Altos 3068
  m68*-altos-sysv* )
    machine=altos opsys=usg5-2
  ;;

But that means I have to write a ./src/m/alpha_linux.h (which I would make by blending alpha.h, and removing anything cd DEC Unix specific), and ./src/s/linux_axp.h (which would be made from linux.h, minus instructions on how to make sharable libraries). None of that is too difficult. Later releases of most software will come with pre-built configuration files as autoconf gets updated, and developers begin to use the new version.

The other issue you get involved with is the fact that several programs publicly available assume 32-bit addresses and 32-bit ints. Linux for the Alpha is a 64-bit operating system, with 64-bit addresses. Frequently, this provides harmless warnings about adding 32-bit offsets to 64-bit pointers.

Then there are the programs that attempt to override the definition of operating system calls. System calls that have been standardized to take parameters like size_t (but is being redefined for unsigned int) will cause complaints from the compiler.

The really insidious things, though, are those programs that do bitwise manipulations without regard to portability. Generally, I've learned to become suspicious of any program that isn't packaged with autoconf/IMakefile, which runs only on one platform (e.g., it runs on Linux; you tell us if it runs on Solaris, BSD, HPUX, etc).

The Future Looks Bright

Many packages compile out of the box. With ELF support comes the ability to port the Java JDK over. Sun, HP, and other notables are releasing their 64-bit processors to the marketplace. And while everyone argues what the 64-bit standard for Unix will be, we will already have been there, and have moved on to more interesting projects.