![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
This article is the result of my efforts to build a personal Digital Alpha workstation to run Linux/Alpha. For under $500 (US), I assembled a 166 MHz Universal Desktop Box (often called a UDB or Multia) with a half gigabyte of disk space, 32 megabytes of memory, 2x CD ROM drive, ethernet port, 2 serial ports, and a parallel port. For a few dollars more, this could easily be expanded with more disk and RAM.
Rather than engage in a lengthy discourse on how I went about building my particular Linux/Alpha workstation, I'd like to share my observations regarding the Alpha-specific peculiarities I encountered. I had used Linux/x86 for years, but I found that there were some Alpha installation issues which were brand new to me. Once I understood these few issues, it was simple to construct a useful Linux/Alpha system.
Why indeed? When the usual x86 offerings are inexpensive and omnipresent, why bother constructing a low-end Linux/Alpha box?
There's lots of talk today about running 64-bit applications. But much of the discussion is nothing more than that -- talk. If you want to find out if your application will survive and thrive in 64 bits, here is a very low cost opportunity to try it out. A low cost Linux/Alpha platform represents an excellent opportunity for porting and testing software in a true 64-bit environment.
Just as many organizations are beginning to see that Linux can be used to their competitive advantage, others are beginning to see that the Linux/Alpha combination can be used in environments where extreme horsepower is required for certain tasks. However, those who hold the purse strings are wary of pouring money into a different hardware architecture until they have concrete proof that the new system will do the job (and rightfully so). An inexpensive Linux/Alpha system becomes an ideal prototype that can demonstrate the possible effectiveness of the proposed solution without incurring high costs. Once the concept is validated, it may be possible to secure management backing for a full-blown Linux/Alpha solution.
The Intel IA64 architecture is coming with the expected release of Intel's "Merced" processor around the year 2000. Many UNIX vendors are lining up to make sure that their particular UNIX implementation becomes the standard UNIX for the new architecture. Many Linux folks, of course, would like to see Linux/IA64 enter the fray early so that early adopters of the IA64 architecture might find themselves looking at Linux/IA64 as a viable first 64-bit operating system.
So what does Linux/Alpha have to do with this? Well, some programs in the mountain of Open Source code that we find in the Linux world are not currently functional in the 64 bit world of Linux/Alpha. And many new programs have to be tested on a 64-bit environment to make sure they will make the jump to Linux/IA64. We need to make sure that all those programs that add value to Linux are 64-bit friendly when IA64 hits the streets. An excellent way of doing that is through porting the code to the 64-bit Linux/Alpha platform. Not only will the Linux world be ready to invade the IA64 space when it is birthed, but this will also serve to further solidify the Linux/Alpha offering.
I've met many people over the past few years who desired to use Linux/Alpha, but could not afford the price tag. Now, however, it is clear that falling hardware prices and the availability of used Alpha machines is clearing the way for people to use Linux/Alpha. Just recently, retailers like Linux Systems Labs began selling low-priced Red Hat Linux/Alpha CDs (GPL distribution). And the long-awaited Debian V2 will support the Alpha platform as well.
There has never been a better time to take a look at Linux/Alpha.
It never hurts to add more current technical expertise to your resume. And experience in a 64-bit UNIX implementation could look awfully nice on the resume when many companies begin employing 64-bit architectures like Alpha and IA64.
I work for Compaq Computer Corporation (in the part of Compaq which used to be Digital Equipment Corporation) as a Technical Consultant in the Networks and Systems Integration Services (NSIS) organization in the US Federal Government Region. It is my desire to be ready to serve Linux/Alpha customers in the Federal Government, so I decided to prepare myself by personally purchasing, installing, and using a Linux/Alpha system.
I have already used Linux/x86 successfully as a part of two customer engagements within the past year. A few of my coworkers locally have also used Linux/x86 in customer engagements during that timeframe. I haven't seen any Linux/Alpha work yet, but I intend to be ready when it comes!
And let's not forget the big reason: Linux/Alpha is a blast! If you thought Linux was fun to work with on the x86 architecture, wait until you have 64 bits to play with!
As the sole breadwinner for a family of four in the greater Washington DC area, I do not have great sums of money to pour into development of a computer system of any sort. I've built several PCs over the years and I've always followed the same basic rules: stay well behind the technology curve and keep it CHEAP! Quality is a concern (building junk is a total waste of money; you lose more by building garbage than by building something that is more expensive but functional), but financial limitations are quite real. So, by buying good used products and/or non-current unused products, I can shave the price down to acceptable levels without sacrificing usability. Sure, I'd like to run dual 600 MHz Alpha processors with 50 gigabytes of disk and a gigabyte of RAM -- but I'd prefer to stay married, thank you!
With these guidelines in mind, I purchased all of the following pieces through on-line auctions (I used eBay, Haggle, and Onsale) and local computer shows in the first few months of 1998.
Here is what I assembled:
| 1. | DEC Universal Desktop Box (UDB; aka Multia) | $189 |
| 2. | TI 16 MB 72 Pin Parity Memory | $29 |
| 3. | 16 MB 72 Pin Parity Memory | $38 |
| 4. | IBM 540 MB SCSI Disk | $44 |
| 5. | Toshiba SCSI 2x CD | $25 |
| 6. | Generic SCSI Cable | $16 |
| 7. | Generic Internal SCSI Cable | $13 |
| 8. | Mitsumi Keyboard (PS/2 style) | $13 |
| 9. | NEC SVGA Monitor | $94 |
| 10. | DEC Mouse (PS/2 style) | (free; included with UDB) |
| 11. | Generic SCSI Case | (free; had this already) |
| 12. | Red Hat Powertools 5.0 | $19 |
| *** TOTAL *** | $480 |
As a user of Linux/x86 since 1995, I've grown accustomed to the capabilities and methodologies of the Linux/x86 world. I found a handful of differences in the Linux/Alpha world which are worth noting to someone who wants to make the jump to 64 bits:
The Alpha system needs to load the initial boot code from a partition that the Alpha console (in ROM) understands. So, a single disk Linux/Alpha system is likely to have at least three partitions:
Linux/x86 folks will obviously be used to the need for root and swap partitions, but the floppy-sized FAT partition containing LINLOAD.EXE and MILO is a different concept.
Linux/x86 has the simple, yet highly useful, LILO (LInux LOader) to boot Linux from the hard drive. Linux/Alpha has MILO (MIni LOader) to accomplish the same task, but using a slightly different methodology. Rather than residing in a boot block, MILO resides in the tiny DOS-formatted partition on the SCSI drive (normally /dev/sda1). The Alpha console boots MILO from the DOS FAT partition, then MILO boots Linux/Alpha from the Ext2 partition (/dev/sda2).
Since there are often differences between the hardware standardly found on different Alpha machines, you are given a choice of pre-built kernels to use when installing the operating system. It is generally quite easy to select the appropriate kernel for your machine, since the documentation very clearly maps the available kernels to most common Alpha models. But it is still different than most Linux/x86 installation procedures.
The Alpha processor family and the x86 processor family are two different animals. As one might expect, a 64-bit RISC processor and a 32-bit CISC processor go about their respective tasks in very different ways. What does this mean to someone who wants to build a Linux/Alpha workstation? Don't be stingy with memory or processor speed if you can help it. In particular, I've found that my Linux/Alpha system performs much better with additional memory. There is quite a noticeable improvement in speed when running at 32 megabytes as opposed to 16 megabytes. In fact, the first real upgrade I hope to perform is to add more memory to the system. Thankfully, memory is much more affordable than it was at the beginning of the decade, so adding a few more megabytes isn't a particularly expensive proposition.
It is important to remember that some Alpha machines (notably the older Turbochannel bus machines) do not currently run Linux. Make certain that the Alpha system you intend to purchase is listed on the Linux/Alpha Home Page. Also, if you select the UDB, be aware that it is a bounded box -- there is essentially no room for an internal disk drive (yes, you can use a 2.5 inch SCSI drive, but that is expensive compared to a 3.5 inch SCSI drive), there is absolutely no room for a CDROM drive in the box, and the processor speed is relatively slow. If you intend to upgrade the system to a faster Alpha processor in the future, you'd probably be better off with an Alpha with a more standard case and motherboard. I chose the UDB because it was available very cheaply and I already owned an external drive cabinet that I could use to mount the hard drive and CDROM drive. I found some excellent technical information online provided by Annex Technology.
While the Red Hat 5.0 Linux/Alpha installation is quite good, it is not quite as simple as the Linux/x86 installation. As I've already mentioned, you'll need to select a kernel for your machine, create a small FAT boot partition, as well as a few other simple steps which you didn't need to perform on a Linux/x86 install. It is helpful, then, to locate and use a "cookbook" or "cheat sheet" to help you during the installation.
The UDB I purchased was originally sold by Starship Computer via one of the Internet auctions. I purchased the UDB used from the original buyer who no longer needed the unit. This person included the original installation instructions supplied by Starship in the box. The instructions were quite good and very detailed. I have already seen similar documents circulating in the newsgroups pertaining to the installation of Red Hat 5.1 for Alpha. If you can obtain such an installation guide, it can save you time and keep you from forgetting small Alpha-specific details.
For the UDB, at least, matched memory SIMMs are critical. The first set I obtained from an auction which advertised new SIMMs shipped together. They did not specifically say that they were matched. They were not. That's one mistake I will not make again. The SIMMs did work together for a while, but once the machine ran for a while, it began to generate memory errors. I replaced them with a set of matched SIMMs and all memory problems ceased.
I found out that the kernel supplied in Red Hat 5.0 for the UDB (noname.img) had a bug that prevented it from using the thinwire ethernet adapter. I simply downloaded the kernel supplied with Red Hat 4.2 and I was back in business.
This was a problem that took much longer to identify than to fix. The Red Hat errata page (https://www.redhat.com/support/docs/errata.html), one of the first places to turn with possible distribution errors, was silent on this subject at the time. As there are less Linux/Alpha users in the world than Linux/x86, the newsgroups were not spilling over with information on this problem as one would expect if there was a kernel problem in a Linux/x86 distribution. Yet the newsgroups held the answer nonetheless; it just took a little longer to locate the message which gave me the key to the problem.
The pppd package supplied in Red Hat 5.0 didn't work properly on Alpha. I consulted the Red Hat errata on the Red Hat homepage and downloaded the corrected PPP kit. One rpm command later, I had a working PPP protocol. Again, it took longer to identify the problem than it did to correct it.
While X Windows is usable with only 16 MB of memory, it will need to swap out jobs just to start up. 32 MB will yield a much faster X Windows system, as it will be able to load without swapping. If you can afford more memory, it is to your benefit.
Perhaps my greatest frustration was the lack of a fully-functional, native, graphical, 64-bit web browser. Lynx, a character-cell browser, is useful for downloading software upgrades, if needed, such as the kernel and PPP kits mentioned above. Unfortunately, it is not as helpful for general browsing, due to its non-graphical nature. There is Grail, which is written in Python, but the current version (0.4) seems too flaky for normal use. One common solution seems to be to use Netscape for x86 under the EM86 emulator (below), but it's not a "native" Alpha solution.
As of this writing, the best native solution I've found is QtMozilla, Mozilla compiled using the Qt libraries. It was created as a demonstration of Troll Tech's Qt libraries, but it is quite usable. I have also seen reports of other Linux/Alpha Mozilla implementations, so I hope that we will see a stable, full-featured Mozilla for Alpha before very long.
Don't forget about EM86, Digital's software for running Linux/x86 binaries on Linux/Alpha. You can find the latest kits at Digital's FTP location. Red Hat kernels included in the 5.0 and 5.1 distributions now support EM86 right out of the box (no longer any need to rebuild the kernel). Also, kernels starting with 2.0.34 (as well as the latest 2.1.x development kernel) have integrated EM86 support without requiring the use of patches before building. Be aware, though, that you may not find the emulation speed acceptable on older, slower Alpha boxes.
Make sure you read the FAQ (https://www.azstarnet.com/~axplinux/FAQ.html) and the chapter on the Alpha installation in the Red Hat Installation Guide. And don't forget to check the Red Hat errata page (https://www.redhat.com/support/docs/errata.html) for any known problems in the distribution.
I found that building the UDB was an enlightening experience, as was installing Red Hat Linux for Alpha 5.0. I have already used the system to port 32-bit applications to a 64-bit platform. Even if it is not exactly a whirlwind by current system standards, my inexpensive Linux/Alpha UDB system has been a very worthwhile (and fun) acquisition.