VAR Station II

A couple of months ago I agreed to do a review of VA Research's VAR Station II. Although I've built or purchased dozens of systems over the years, it's pretty hard to sell me a new system for personal use. When I picked up the review system, I realized that currently my main system was the old 386 I built eight years ago. It's the one I use for reading all of my mail and news, surfing the Web, compiling and testing new software and most of my programming and writing. The beauty of Linux is in how well it supports my old system. With the new system, I knew I was in for a bit of trauma, as it meant forcing myself to use the system for my daily work after almost a decade with my old reliable. (Quit laughing, it's not that funny—well, maybe it is.)

The other thing I knew would be difficult to overcome was my text-mode bigotry. The VAR Station II is obviously intended to be a graphical workstation—I couldn't do it justice if I stuck with my usual suite of text-mode applications. Normally, I've only made the occasional foray into X to use Netscape, ghostview, xdvior, xv and/or xpaint.

The VAR Station II is built around a 266MHz Intel Pentium II. This is currently the fastest production x86 processor—although I think I spotted an announcement for a 300 MHz model on the horizon. Although this may seem tame next to the DEC Alphas at 500MHz (and some as high as 600), there are some advantages to sticking with an x86 processor. The most obvious advantage is that you can install a copy of DOS, Windows 95 or NT if you have occasional need for a Microsoft application, or you're doing any sort of cross-platform development or testing on any other PC OS. Some users also might need access to iBCS (SCO or other PC Unix binary compatibility) or WABI (Windows 3.x under X Windows) or to some other application that's available for Intel Linux but not for any of the ports to other processors (we're thinking of commercial Linux applications here—which are appearing in increasing numbers).

I'll admit I've considered adopting some other hardware architecture—Alpha or PowerPC, maybe even SPARC. However, my informal survey suggests that the various ports of Linux to other platforms have simply not progressed far enough to offer a performance advantage. For whatever reasons, a 500 MHz Alpha just doesn't appear to be 90% faster than a 266MHz Pentium under the current ports of Linux.

Despite the advantages of the x86 architecture for this sort of system, VA Research's choice of the Intel Pentium II chip was also a distressing feature for me. Just prior to picking up the review system I discovered that a new floating-point math bug had been reported (and confirmed by Intel) in that particular microprocessor series. I asked VA Research about this bug. They let me know that Intel would be able to ship a software fix that would patch the microcode in the processor.

The current Pentium II and MMX processors are basically RISC chips at their core—and they run a set of microcode routines that provide the CISC functions. In the case of the Pentium II and MMX chips there is also a small bank of flash ROM where some upgrades to the processor's microcode can be loaded to permanently “fix” them.

At this time, I haven't received the fix disk. However, despite my concerns about the processor, the hardware seemed to perform flawlessly.

Setting up the hardware consisted of unpacking two boxes (monitor and CPU) and plugging in about five cords (monitor, power, keyboard, mouse and Ethernet). With 64MB of RAM and a fast SymBIOS SCSI controller this machine makes my Pentium 150 (another system that I use just for testing and mostly for NT) feel like sludge. I won't even compare this to “old reliable”. The system came with a sound card installed and pre-configured—but no speakers or patch cord. Naturally, the first speakers I acquired came with the wrong sort of cords.

One quirk I noticed about this SCSI adapter—it doesn't seem to support the new bootable CDs. The recent Red Hat releases are written on bootable CDs, which is nice for installation and downright handy for recovering from your latest typo at the root prompt.

The VAR Station II ships with a three-ring binder that holds some custom documentation and has vinyl floppy pocket and pamphlet pouches. The first page of the custom documentation is a printout describing how to log in, start X and configure the networking parameters (via the Red Hat Control Panel or a text editor).

They ship the systems with a custom user account already added, so I was able to just log in as “jimd” and go. That is a nice touch and hopefully discourages new Linux users from doing normal work as root.

The other pages list all of the settings for all of the installed adapters including the IRQs, DMA channels and I/O ports that are in use. Although I didn't add any additional adapters, this is the exact information that I hate to track down when I do system upgrades so I'm glad they provide it in such a clean, organized fashion.

Connecting the system to my household LAN was simply a matter of plugging it in and changing a few lines in the /etc/sysconfig/network file. (Yes, I used the text-editor method rather than the GUI). It only took a few more minutes to add read-only NFS exports between the VAR Station II and “antares” (the old 386). I was then able to access the Internet using IP Masquerading through antares, which dynamically brings up my PPP link using diald. There really was no fussing with the hardware—ever.

I wish I could say the same for the software. I think it's a shame to ship a machine that's so clearly intended for use as a multimedia graphics workstation and have it boot to a text-mode login. Remember this statement is coming from an affirmed text-mode bigot. I would ship these systems with a run level of 5 as the default setting, thus providing the new user with an xdm (graphical) login prompt.

I also consider it a bit silly to use a 4MB Matrox video card with a depth of only 8 bits. I was able to override this with the command:

xinit -bpp 16

I also found that Red Baron (Red Hat's preferred web browser) refuses to run in “truecolor” mode. From what I've read, it's possible to use Xnest to solve this problem by running an additional instance of the X server on a different display such as :1 and opening a remote client window on it. I had no problems running Xnest, but I couldn't convince it to run with the lower color depth despite several readings of the man page. There were some other programs that didn't like the “truecolor” mode as well.

Despite all of this, there are big advantages to running with the larger color palette if your video card and X server support it. When using xv (the X-viewer package) for photo finishing and other graphics packages, you need the extra colors.

There were two other nuisances about the way X Windows was set up (which I think was the Metro-X server—though XFree86 is also installed). I don't use X Windows much, as I don't like to wait for it to load. Normally, I start a copy of it and leave it running all the time. When my wife wishes to use the system, I prefer for her to run her own copy of X and leave mine alone. I've always been able to manage this by running my copy on a different virtual display with a command like:

startx :1

The included version of the startx shell script was doing something with a file in /tmp and complained when I tried to start a second session. I worked around that problem by using:

xinit xterm :1

Also, the SVGA libraries weren't configured at all. No playing sdoom on this system without a little tweaking.

After configuring the network and starting X, I was greeted with a couple of xterms and a copy of the Red Baron web browser displaying a page from the localhost web server. This had some information and links to the VA Research and Red Hat web sites (along with a warning that you need to have your Internet connection configured before those would work). However, I would like to have seen more extensive local web pages. What I'd really like to see is a multi-media tutorial and tour—similar to the “Welcome” application that comes with a Macintosh Performa. This could be done as a set of web pages, Java programs, a Tcl/Tk script or some combination of those options.

The default window manager for recent versions of Red Hat is FVWM 95 which, as the name suggests, is the familiar FVWM configured and tweaked to provide a feel similar to a certain Microsoft product. This is nice for users who are migrating from that universe and reasonably unobtrusive to those of us who are used to FVWM. You can still access the menus by clicking anywhere in the root window (what Windows calls the “desktop” or “background”), and the other mouse buttons still bring up the “Window Ops” and “Task List” menus. FVWM 95 doesn't put any icons (like “My Computer” or “Recycle Bin”) on the root window, so the similarity to the Windows 95 desktop is minimal. However, it is nice that I can use the alt+tab key binding to cycle among tasks in FVWM 95. I'm told you can set up any of the common X Window managers with that feature, but I've never taken the time to edit my rc files to include it.

While exploring the FVWM 95 menus I found familiar problems. So far this has been true of every installation of Red Hat and Slackware I've done. Several of the menu items are non-functional “placeholders” or examples (such as remote xterms to systems that don't exist on my LAN). Also, some of them try to call programs, such as the xvier game, that simply aren't installed on the system. Other menu items call their binaries with arguments that generate error messages. There was a new problem, for me, with the “screen lock” and “screen blank” submenus. There are so many blank/lock modules listed on the menu that they push off the edge of the screen—and virtual screen scrolling doesn't work in this context. So there are more screen blankers than you can access. Also some of the screen blanker selections just didn't work (due to typos in the rc file). I consider this to be a fairly minor problem that is easily solved by editing your own copy of the .fvwmrc file—if you understand its syntax.

I'd like to see an rc builder added to the default menus (maybe built around “The Dotfile Generator” by Jesper Pedersen Linux Journal Issue 42, October 1997). There's a lot I don't like about the MS Windows and Macintosh user interfaces, but they do have the virtue of being approachable. They have menu items/icons for almost everything and their menu items don't “silently” fail, leaving you wondering what was supposed to happen.

If you don't like FVWM 95, you'd better know how to configure whatever window manager you do like. This installation had a few other window managers installed (twm, olvwm and the old fvwm). However, none of the others had menus that were even close to the system's configuration.

Another problem I bumped into was with the Java demos. There was a tantalizing tree of Java class files under /usr/lib/java/demos. The only problem is that they are applets rather than applications (meaning that they can't be run outside of a browser or viewer). Since neither HotJava nor Netscape was pre-installed and Red Baron and Grail (the two web GUI web browsers that were available) don't support Java, this left a bit of a problem. Here's another case where a few pages on the localhost web server's document tree would greatly help a new user. In this case, I had filed the appletviewer command, and so was able to preview all of the demos with the single xterm/bash command:

cd /usr/lib/java/demos && for i in */examp*.html;\
do appletviewer $i; done

In contrast, DOSEMU is installed and configured. Maybe I'll get around to digging out my old collection of DOS shareware to play with. For test purposes all I did was run dos, change the CONFIG.SYS within the hdimage, restart dos and change directories to the mount point for my C drive back on antares, where I was able to run 4DOS and Norton Commander with no problems. For the record, that was accessing a DOS file system mount on another Linux system through an NFS mount on the local host. It worked without any special fussing.

My only complaint about the way that DOSEMU is configured on this system has to do with the permissions. It started out as SUID root (which is necessary for technical reasons) and world executable. A more conservative and reasonable approach is to create a dos group—and change the binary's permissions to group executable—stripping all access from “other”. This suggestion applies across the board to almost all SUID programs. It limits the number of users who can attempt to exploit security problems with the files. If you routinely add all of your real users to dos and other groups, at least you prevent possible access through pseudo users like bin, www and nobody.

Like other systems that I've had with the OS pre-installed, this one had a “cookie cutter” feel to it. For example there are two partitions: / and /home. The consensus of Unix system administrators is that it's safer to make a relatively small root partition, a medium or large /usr, an alternate root and some other partitions suited to a particular host's needs. A separate /var/spool partition—or even /var/spool/mail and /var/spool/news—are often a good idea. I like to create a large partition to use for /usr/local (on some systems I make /home a symlink to /usr/local/home).

There are many other things I do when setting up systems for myself or my customers—like turning on the immutable bit on system binaries and share libraries (see the Linux-Tips HOWTO) and removing extraneous services from inetd.conf (the single most effective thing you can do to improve your system's security). While I don't expect VA Research or Red Hat to do these by default, it would be nice to see some of these practices codified as install options.

After exploring as much of the pre-installed software as I could find, I installed some other packages. I started with a copy of Mathematica and a copy of Applixware. Those installed easily and ran fine. I fussed with GNUStep DR2 (which is the free NeXT/Open Step clone that's currently being developed), but I never did get it to run. Another package that gave me grief was Lyx (WYSIWYG LaTex word processor).

That is about par for the course. About a third of the programs that I tried to build from sources, and maybe a sixth of the RPM packages I experimented with, didn't build or install on the first try. This is better than my average with Windows programs, and worse then my experience with DOS shareware (although not by much).

For comparison, I recently purchased a Mac Performa which I've been setting up to send to my mother. I bought a couple of CDs full of Mac shareware --mostly games—and played with them to decide which ones to install for her. I found that over 90% of the games and tools could be run right off the CD with no problems—and no installation. For those Powertools that I did decide to install, each was simply a matter of dragging the folder from the CD into my file window (group). In fairness I have to point out that one of the programs that did not behave under MacOS 7.5 managed to completely trash the system drive when I tried it again under the new MacOS 8.0. Norton Utilities was no help for the damaged file system (so now I'm reinstalling everything from scratch). The failure rate was much lower—but more catastrophic.

Now this may seem like an unfair comparison. Linux isn't “supposed” to be as easy to use as MacOS. However, the point I want to make is that Linux is catching up quickly. I wouldn't send my mother a Linux system this year—but in another year or two, I might.

After working with the system as shipped for several weeks I broke down and installed a fresh Red Hat 4.2 onto an external hard drive that I added to the VAR Station II. Red Hat shipped 4.2 shortly after I picked up this review system. However, I didn't upgrade it right away because I wanted to do a fair review of the system as it was shipped. This serves two purposes. One, it tests how well-supported this mix of hardware is by “stock” Linux distributions (and reveals if any custom or special drivers or kernel patches are required). Two, it probably matches the version of Linux that would be installed if you were to get one of these systems now. I picked up a copy of the Red Hat 6 CD set which includes the free portions of Red Hat (no Metro-X server) and mirrors of the sunsite and ftp.x.org sites.

The SymBIOS SCSI controller in this system has a SCSI-3 connector, but VA Research thoughtfully provided a SCSI-2 adapter. Adding the extra drive was simply a matter of picking an unused SCSI ID, and plugging in a cable and terminator.

I normally do upgrades as new installations on separate drives so I can easily revert to the old, working system whenever something “suddenly” doesn't work on the new installation. This installation went smoothly, with the usual fussing over the lilo.conf to convince it that I really did want two bootable partitions on two separate drives. The new twist this time was that I needed an initrd directive.

This new version is much nicer. More of the initially installed menu items work out of the box (at least if you do an install of “everything”), and there are some nice new packages (like the lincity game—a “civilization” for Linux). By far my favorite new package is XEmacs.

XEmacs is an improved Emacs (based on the GNU version—and therefore free). As the name implies XEmacs has enhanced support for fonts and graphics when run under X Windows. The “GNUscape Navigator” (formerly called w3-mode)--a web browser package written in the Emacs lisp macro language—can render pages with embedded graphics under XEmacs but is limited to text mode (like Lynx) under GNU Emacs. The surprise for me is XEmacs' support for ncurses, which allows me to have color and “fontlock” support for my text-mode screens and from my laptop when I log in over a serial line.

This is an excellent combination of hardware for Linux. It is probably the fastest single-processor x86-based system available (VA Research has some multi-processor server systems, too), and all of the equipment works with Linux and is pre-configured for it. If you're tired of fighting with your hardware to get your sound card to play CDs or your video card to work in decent resolutions, you should get a system like this one. The only things missing from the hardware package are the speakers and some sort of suitable backup and bulk storage device.

While I have my concerns about Intel's processors, I am sure that they will fix the problem. The Linux community will work around them if Intel takes too long. I wouldn't build any bridges, aircraft or medical equipment without running the numbers through the same calculations on another architecture, but I've recommended that since the first FDIV bug was announced, and I recommend it regardless of which processor(s) are involved.

Finally, the software configuration is still rough in spots. Red Hat is showing steady improvement, and VA Research does offer other distributions (such as Caldera and Craftworks), if you ask.

VA Research clearly tries to balance the degree to which they customize their installation against the expectations and preferences of experienced Linux users. They also have to do constant research as hardware vendors make unannounced and undocumented changes to various components (which might cause an Ethernet card of a given model to suddenly stop working with Linux, for example), and as the development of Linux and other software that runs under it keeps steaming along. Personally I think they've done an excellent job—there are very few PC manufacturers and integrators that are willing to take up the challenge.

So, if you're tired of getting blank stares when asking vendors about Linux and you need a fast X Windows workstation, get a VAR Station II from VA Research.