–
By Russell C. Pavlicek –
In the Open Source world, most of the focus these days is on solutions in
the x86 space. But, in the corporate world, computer rooms are still
filled with older systems employing a variety of other architectures.
One of the benefits of Open Source is the fact that these non-x86 boxes
can be used to run the same operating systems as their x86 cousins.
Why is this important? Well, because these systems exist, for
one. Why should these boxes be replaced if they are capable of providing
a function in a cost-effective manner? If an organization decides
that the older boxes are too expensive to maintain or too slow to be
useful, that’s one thing. But if the boxes can be put to good use in a
cost-effective way, why waste them?
Another reason to consider reusing these systems is the way they are
built. Many of these other architectures were designed to run like
iron. The designers expected these machines to run for years at a time
without hardware failure, unlike the PC industry, which has only recently
discovered that a “therapeutic reboot” every few days is not necessarily
an acceptable thing. And by installing Linux or one of the BSDs, you get the advantage of a modern, powerful and supported operating system that fits on these old machines.
The hardware
This article comes out of my experiences with four non-PC architectures:
SPARC, Alpha, VAX, and PMAX/MIPS. There are certainly other choices out
there (NetBSD alone supports 32 architectures with eight distinct
processor types), but I have access to boxes in these four categories.
I consider there to be two types of hardware here: the systems that you
might consider buying to do the job, and those that you don’t want to
pay for but might want to use if the hardware is available. Of the four
architectures I mentioned, I consider SPARC and Alpha to be in the former
category, and VAX and PMAX in the latter. The reason is
simple: performance. SPARC and Alpha can pack a lot of punch, whereas the
VAX and PMAX don’t really have the horsepower that warrants spending money
on them.
For my investigation, I used the following systems:
|
| Alpha Multia |
166 MHz |
64MB |
| SPARCstation 10 |
40 MHz |
48MB |
| DECstation 5000/200 |
25 MHz |
32MB |
| VAXstation 2000 |
0.9 VUPS |
6MB |
| VAXstation 4000/60 |
12 VUPS |
40MB |
(VUP stands for “VAX units of processing,” where one VUP designates the
processing power of a VAX 11/780.)
I have a stack of computers sitting around, including the SPARCstation, VAXstation 4000/60, DECstation, and a SCSI expansion box. In their prime, this pile of
systems would have cost a software professional more than a year’s
salary. Today, this particular set of boxes cost me about $155 on eBay,
nearly half of which was shipping charges.
The software
The choices of Open Source operating systems are actually more extensive
than most people might believe. The PMAX architecture has the fewest
options, with a working NetBSD port, an OpenBSD port that lacks some
hardware support, and a young Linux port. The VAX hardware has functional
NetBSD and OpenBSD ports, as well as fledgling port of Linux. SPARC has
mature NetBSD, OpenBSD, and Linux ports, and an immature FreeBSD port.
Alpha has all four operating system options.
In terms of distribution support, Wasabi NetBSD supports all four
platforms. The official OpenBSD distribution supports all except PMAX.
SuSE Linux publishes distributions for both SPARC and Alpha. Red Hat
supports Alpha (through an arrangement with Compaq), but has apparently
retired its SPARC distribution with Red Hat 6.2. Mandrake has a SPARC
product (Mandrake Corporate Server) and an Alpha beta-test that appears
to have stopped at version 7.2. Debian has active SPARC and Alpha ports.
I should note that the list of operating systems above is probably not
complete. The Open Source world is full of choices, and I would be
shocked if I managed to list every choice available for these platforms.
For my purposes, I installed the following:
- Alpha Multia: Red Hat Linux V7.1 and FreeBSD V4.4
- SPARCstation 10: SuSE Linux V7.3
- VAXstation 2000: NetBSD V1.5.2
- VAXstation 4000/60: NetBSD V1.5.2
- DECstation 5000/2000: NetBSD V1.5.2
As someone who works with technology, it was worthwhile for me to install
a variety of operating systems. An organization faced with deploying such
an array of boxes might want to stay with just one or two operating system
choices to simplify the task of system administration. Personally, the
fact that I can log in to my PC, my SPARCstation, or my Alpha and find the
same Linux operating system and utilities makes my life very comfortable.
Becoming acquainted
One of the potential obstacles to working with these systems is the need
to develop a basic understanding of the hardware. If you worked with
boxes like these before attempting to install an Open Source operating
system, you probably have the background you need. If you haven’t worked
with the hardware before, you may need to spend a little time doing
research.
Some questions you may need to ask include: What is the console language
like? What basic console commands will I need to know? Does the hardware
support a serial console if I don’t have (or want) a monitor and keyboard
attached to it? How is the serial console activated? What type of cable
will I need to attach the serial console to a terminal (or in my case, an
old IBM ThinkPad running minicom under NetBSD)? How much memory and disk
will the system support? Can I possibly cannibalize another retired box to
increase the capacity of this system?
In my case, I had worked with the VAX and Alpha architectures for years,
so they were easy for me to work with. Even though I worked
for Digital Equipment Corporation for over a decade, I never spent any
significant time working with MIPS-based DECstations. So I did have some
investigating to do there, but the console language was so similar to
other DEC offerings that I soon felt comfortable.
The SPARCstation was another case altogether. I had no first-hand
experience with Sun hardware prior to obtaining the box. I had to learn
the console language, the boot commands (which involves a very convoluted
path name if your disk’s SCSI id is not set properly), and configuration
settings. I had to learn how to activate the serial console, how to load
memory into the box, and even where to install the processor board inside
the box. Thankfully, the Web is a wonderful place to find such arcane
bits of knowledge.
While your getting acquainted with the hardware, find the mailing lists
that deal with your hardware on the Web. NetBSD in particular seems to
have some very good mailing list archives that deal with particular
architectures. Find these and other lists, and you will probably discover
a mound of information about your machine.
Loading the software
Loading the chosen operating system can range from a walk in the park to
an effort-intensive task. The individual model may have more to do with
the amount of work needed than the architecture does. For example, the
VAXstation 2000 took hours to load NetBSD, while the VAXstation
4000/60 loaded the same operating system in minutes. In this case, the
fact that the VS2000 had no attached load device (CD or floppy), meant
that a rather elaborate network booting procedure had to be set
up. Meanwhile, the VS4000/60 simply booted from the CD and installed with
ease.
You will need to research the installation procedure for the software, as
well as any architecture-specific instructions you will need to get the
job done. You will also need to determine if the hardware is adequately
supported. You might find that certain devices in the system at hand are
not supported. For example, certain popular video cards fall into this
category in the Alpha world. Unfortunately, the secret proprietary design
of some of these cards makes them impossible to support.
When I was preparing to load FreeBSD 4.4 on the Alpha Multia, I discovered
that there was no working support for the graphics device. This meant
that the installation would need to be done from the serial console and
that the finished system could not be used as an X Window workstation.
If this was a requirement for this box, I could use Linux instead, which
has support for the video card.
Gotchas
Once you have installed the operating system, you may find some
difficulties that either you did not notice in the documentation or were
not completely described in the documentation. In my case, I installed
NetBSD on the VS2000 only to find that there was no working X server for
that machine. That fact was never specifically called out in the
documentation, as far as I can see.
I also found that a bug in the firmware on the Alpha that makes Red
Hat’s preferred method of installation via the SRM console hang
mysteriously. Fortunately, the installation using the ARC console works
fine.
Testing
Once the systems were operational, the next step was to gauge performance
and overall suitability for duty. Running a common benchmark can give you
some idea how the particular machine measures up to other machines
commonly in use. I normally compile and execute
nbench 2.1, the Byte benchmark suite. The idea is not to determine
the absolute performance of the boxes as much as it is to determine what
the box might be able to do. In my tests, the boxes listed in this article score in
the 486 to Pentium range, so they aren’t exactly suited to run the payroll
for a Fortune 100 corporation. But all of them could act as low-volume Web servers,
squid servers, or firewalls for smaller companies or branch offices of
larger organizations. They might also serve as intranet servers to handle
internal functions, like a policies manual or internal news site.
Once you’ve identified the possible functions that a box can perform, it
makes sense to do some stress testing. This is important because the
behavior of these systems are different under load than PCs. Some, like
the Alpha, do much better in the floating point area than PCs of
equivalent performance. Many platforms boast decent I/O rates, due to
SCSI devices and interesting internal busses.
Deployment and beyond
Once you’ve determined which boxes are suitable for what tasks, you are
faced with the tasks of deployment and maintenance. In the case of older
boxes, you might want to consider replacement strategies. In the event of
a catastrophic failure, you may even be able to replace a box of
one type of architecture with one of a different architecture without a
great deal pain. It all depends on the software and operating system
used.
The bottom line is this: An older computer system is not necessarily a
worthless system. In many cases, it can be loaded with a modern,
Internet-aware Open Source operating system and put back to work.
The choice is yours, not your software vendor’s. And that’s the way it
should be.
