The UPS man rang my buzzer. I sat in my chair sweating bullets. Do I even dare? Despite better judgment, I buzzed him in. “Did anyone see you?” I asked in a nervous voice. “Uh, just sign here.” He gave me an annoyed look and after getting my John Hancock, he handed me the package. I hurriedly closed my blinds, fearful someone might see the contents as I opened it. The package sat on my coffee table for about an hour while we (that is to say, me and the package) stared each other down. A scene from the cult classic Terry Gilliam movie Time Bandits came to mind: “Mum! Dad! Don’t touch it! It’s pure evil!“
While I doubt the package contained pure evil (in fact, I was pretty sure it contained some install CDs and perhaps some manuals), I’m sure many of my friends as well as tens of thousands of others in the open source community would conclude otherwise.
For you see, the package was from SCO. Dun dun dunnnnnnnnnn.
The purpose of that lame little melodrama was to illustrate the rather unique context of this operating system review. I want to be as objective as possible, but I’d be a fool to think such a review could possibly avoid the controversy and raw emotions surrounding the company offering the product I’ve chosen to evaluate.
The SCO Group has earned their now nefarious reputation of pure evil from the open source community and others for their recent legal tactics. However, separate from the legal arguments and the drama of the battle of the open letters, SCO does actually sell a product (beyond “licenses” for Linux).
Actually, they have a pair of Unix offerings: UnixWare and OpenServer. SCO recently announced they’d sold licenses to these products to a number of companies, including McDonald’s and Warner Brothers. Not having used either, and giving the mounting controversy, I decided to take a look at what SCO considers their premier Unix offering, UnixWare 7.1.3. Drama aside, UnixWare is an operating system that people do use, so I figured it’s worth a look and arranged to do an evaluation.
The Test System
The system I used to test is definitely not top of the line, but it is indicative of the type of hardware currently still commonly used in a server environment. It’s also the only system I currently have available to perform such evaluations.
Vendor: VA Linux
Processor: (2) Intel Pentium IIIs at 600 MHz, 256 KB cache
Motherboard: Intel L440GX+
RAM: 512 MB PC133 ECC
DISK: (1) 9 GB Maxtor SCSI LVD 10,000 RPM
SCSI Controller: Adaptec AIC-7896 Dual Channel
Video: Cirrus Logic GD 5480 2 MB RAM
Installation was fairly straightforward. It’s a text-based installation, and while not as fancy as the newer graphical-based installations, it was still fully functional. UnixWare had no problem recognizing any of my hardware, and installed the drivers automatically.
The only real difference from most installations, including a recent Solaris installation I performed, was the prompting for a license key. If you lack a license key, you can defer entering one in favor of an evaluation license which is good for 60 days. I didn’t have a license key, so I opted for the evaluation license. It took about 20 minutes to get the first CD loaded, and then prompted me for a reboot.
After the system rebooted, the installation continues by asking to insert each CD (there were 5), and prompting for which packages on the CDs I’d like to install. This was very different than the usual “pick what packages you want to install, and I’ll figure out which CDs you need” method more commonly used by installers. This was much more time consuming, and it required a much higher level of interaction.
The packages on these install CDs had their own very unique install scripts, and there were additional license keys required for several of the portions, including the NeTraverse Merge, ReliantHA Host Monitoring Software, and others. It seemed a bit disjointed and patched-together.
You can defer going through the other CDs which is what I’d recommend as it saves quite a bit of time. UnixWare and most of what you need comes on the first disk and installs in about 20 minutes. You can go back and install the other packages later if necessary.
Despite using a dual-processor system, SMP support is a licensed feature, so this installation only recognized one of the two processors.
Logging on the first time, I found a pretty bare-bones system. For instance, neither of the shells tcsh or bash were installed (which was annoying as I can’t imagine using a system without one of the two). Also installed is a built-in UnixWare (non-GCC) C compiler, but not a C++ compiler (see the compiling section for more on this).
One of the oddities I found while using this system was the tar utility. UnixWare’s version of tar is very garrulous, and will throw warnings all over the place.
x tcsh-6.12.00/win32/stdio.c, 15774 bytes, 31 tape blocks UX:tar: WARNING: Cannot get passwd information for christos UX:tar: WARNING: tcsh-6.12.00/win32/stdio.c: owner not changed
It’ll send warnings on just about everything, which can be very frustrating if you’re trying to follow along with what files are actually being unpacked. You can of course suppress these warnings, but that means using a different syntax than you’re probably used to. Installing GNU’s tar, which of course does not suffer that malady, is probably a better solution.
The overall feel greatly resembles Solaris, owing of course to their common System V heritage. The package management system is very familiar, and includes the familiar commands
pkginfo, although the syntax is a bit different. On Solaris, I’d typically do
pkgadd –d . or
pkgadd –d packagefile.pkg to install a package. In UnixWare, that particular syntax does not work, so to add a package file you’d
run cat packagefile.pkg | pkgadd -d –.
When checking out the file system, I was surprised to learn UnixWare includes a version of the venerable Veritas File System (vxfs). You can use the old stalwart UFS, but there are several advantages to using vxfs, primarily speed and fscking issues.
The history of UnixWare is a bit confusing. (Take a look at this site for a more detailed chronicle of UnixWare’s history, as well as the history of Unix in general.) UnixWare jumped from version 2.1.2 to version 7 in 1998. Then, in 2001, the new release of UnixWare 7 suddenly became Open UNIX 8 (7.1.2?). In 2002, Open UNIX 8 was updated as UnixWare 7.1.3.
One side effect of this constant name changing is that it sometimes confuses build scripts when compiling software (as it did with tcsh).
The login screen, again familiar if you’re used to Solaris, offers either a CDE, KDE (Linux-based), or OKP login environment. (OKP is the OpenServer Kernel Personality). The CDE desktop is fairly Spartan, with no fancy anti-aliased fonts and a color scheme that makes Solaris’s CDE desktop look like Mac OS X, but it’s fully functional.
Aside from the bland CDE layout, the graphical SCO administration application was impressive, and it included the ability to choose not only the screen resolution, but the refresh rate (something missing in most Linux installs, and Solaris). It’s a full featured graphical administration program, allowing one to administer mail, file systems, process priorities, and more all from a graphical menu.
One oddity of the UnixWare X11 install is that it’s X11R5, not X11R6. I didn’t compile any X11 applications, so I wonder what kind of problems this might present. The Linux emulation environment sports an X11R6 installation.
Software availability is certainly not one of UnixWare’s more attractive areas. As far as modern enterprise applications go, there’s just not a lot available. Sun’s Java is only current through 1.3. Oracle hasn’t released a UnixWare port for a while, and are not planning on doing any future releases. UnixWare just doesn’t seem to be on the radar for enterprise application developers.
The solution, for the most part, is to run applications (such as Oracle) on UnixWare’s Linux Kernel Personality (LKP), its Linux emulation environment (discussed later in this review). I could see this making sense in situations where most of the software is running UnixWare natively, with a few applications required that only run Linux running in the LKP. But I can’t see it making any sense to run the UnixWare operating system and having all the applications running in the LKP.
SCO has a “skunkware” download site, which includes pre-compiled UnixWare binary versions of open source applications such as Apache and GCC. Some of the pre-compiled binaries are old, and I wouldn’t recommend running them (for instance, Apache 1.3.26 and PHP-4.1.2 are the most recent on the site, while Apache 1.3.29 and PHP 4.3.4 are out now). If you do use one of these pre-compiled, make sure it’s a version that doesn’t include known security vulnerability.
Compiling software was probably the most frustrating part of this review. To sum it up, it’s a major hassle to get many applications compiled, and some I couldn’t get compiled at all. This is important, given the lack of what’s available for the UnixWare platform on a pre-compiled and enterprise level, you’re going to need to do a lot of compiling. If you run UnixWare, you’re going to need to know your way around a Makefile, and an overall higher level of compiling savvy than you would on other systems.
As I said before, the basic UnixWare installation includes a (non GCC) C compiler, but does not include a C++ compiler. That’s something to keep in mind, as many applications, such as MySQL, have C++ code, so you’ll need some type of C++ compiler in order to compile them. SCO does offer a C++ compiler as part of the UnixWare Development Kit, which lists for $599. I didn’t have an evaluation license (or the $600) so I decided to use a pre-compiled GCC 2.95.2 from the skunkware site to compile applications that required a C++ compiler.
For the first application to compile under UnixWare, I chose tcsh. For just the virtue of the greater productivity it affords me, I consider tcsh (or bash) a necessity, so I downloaded the source from a site listed on tcsh.org. (I tried using the tcsh versions posted on SCO’s skunkware site, but they all exhibited a strange up-arrow last-command problem, to the point of being unusable.)
It took me a bit to get it to compile. The ./configure script failed to discover what kind of OS it is (which happens with a few other auto-configure scripts).
./configure loading cache ./config.cache checking host system type... i686-unknown-sysv5UnixWare7.1.3 checking cached host tuple... ok configure: error: Tcsh can't guess the configuration file name for 'i686-unknown-sysv5UnixWare7.1.3' systems. Check tcsh's 'Ported' file for manual configuration instructions.
After experimenting with a few of the config.h files and adjusting Makefile, I was able to get tcsh to compile, and it did not exhibit the strange behavior of the skunkware tcsh.
I was able to compile Apache, OpenSSL 0.9.7c, OpenSSH 3.7.1p2, and a few others without much trouble. For the most part I was able to get them to compile with both the built-in C compiler, and the GCC 2.95.2 package I got from the skunkware site.
However, I could not get mysql-4.0.16 to compile at all with GCC despite hours of trying. I also could not get any version of GCC 3 to compile with either the older GCC or the built-in C compiler. (While the GCC team has contemplated doing so, they haven’t yet removed support for SCO products).
The Linux Kernel Personality (Linux LKP) was to me the most impressive of UnixWare’s capabilities. The LKP is a separate environment under UnixWare running a version of what looks like Caldera’s OpenLinux, and allows UnixWare to run Linux compiled binaries unmodified.
Effectively, the LKP is like running Linux in a separate VMWare-style environment. It runs as a kernel module (there doesn’t seem to be an actual Linux Kernel running, rather the module accepts Linux system calls), and shares space on the root file system. Even to uname it looks like a Linux system:
# uname -a
Linux sco1.vegan.net 2.4.13 #1 Thu Oct 31 02:32:23 EST 2002 i686 unknown
The Linux file system is accessible to UnixWare via a /linux mount. To interact with the Linux image, all you need to do is type in “linux”, or run one of the Linux shells from UnixWare, such as /linux/bin/tcsh. The LKP is chroot’ed to the /linux file system, and the UnixWare file system is available to the LKP environment by a /unixware mount.
The Linux kernel version number piqued my interest, because of the recent kernel vulnerability responsible for the compromise of some Debian project servers. I’m not sure if the same kernel exploit would work in the LKP, but it’d be an interesting test.
The LKP works so well that the KDE environment runs entirely from this realm (CDE runs native to UnixWare). The KDE/Linux desktop seemed significantly slower than the CDE counterpart, so much so that entering text in a window often took a second or two to echo back, although that could easily have more to do with my poor Cirrus 2MB video card than slowness in the emulation. However, the CDE UnixWare-native version was fairly snappy and responsive. Unfortunately, I did not have a faster video card to test with the system.
Earlier I mentioned have problems compiling software under UnixWare. Oddly enough, this was not the case in the LKP. I was able to compile Apache 1.3.29, MySQL 4.0.16, GCC 3.3.2, OpenSSH 3.7.1p2, OpenSSL 0.9.7c, and a number of other applications without any trouble or mucking around in the Makefile.
I ran some tests to see if the LKP imposed any performance penalty as opposed to running natively in UnixWare, and the results were pretty surprising.
To test, I used OpenSSL 0.9.7c’s openssl speed function, invoking the command with openssl speed rsa dsa. To compile, I used the built-in C compiler for the UnixWare version and GCC 2.95.2 for the LKP version.
The results for both were virtually identical. For this test at least, there was no apparent performance penalty for running applications in the LKP versus natively.
Also included with UnixWare is the OKP (OpenServer Kernel Personality). OpenServer is SCO’s other Unix product, and UnixWare offers an environment similar to the LKP to run OpenServer-native binaries unmodified. Not being familiar with OpenServer, I didn’t evaluate that environment.
To evaluate security, I took a look at how well SCO handles security bulletins and issues fixes. SCO has two different patch/update methods: The maintenance pack, and the update pack. The current as of writing for both is update pack 3 and maintenance pack 3, and they both contain security fixes, bug fixes, and functionality updates. Maintenance packs are freely available, where as update packs require a subscription license. Update packs include everything that you’d get in a maintenance pack, and more.
Not having a license for the update packs, I wasn’t able to fully evaluate SCO’s adeptness at security. Looking at SCO’s published security updates, they seem to have caught a number of the more current bugs, including the recent sendmail exploit as well as potential OpenSSH vulnerabilities. UnixWare came installed with OpenSSH version 3.4p1, and the maintenance pack 3 I installed did not include the most recent version, OpenSSH 3.7.1p2. That version appears to be included in update pack 3, but again I can’t confirm since I’ve been unable to apply it. Maintenance pack 3 did include a fixed version of sendmail.
Fortunately, despite trouble with other applications, I was able to compile current versions of OpenSSL (0.9.7c) and OpenSSH (3.7.1p2).
A user community is an invaluable resource to any operating system or application, whether they are commercial or open source, as they offer a certain measure of support that no vendor could possibly provide alone. These resources are typically realized with Google searches, Usenet posts, and message boards (just to name a few).
The ability to leverage this user base is usually directly related to the size of the user base, and that’s where UnixWare is lacking. In all of the issues I came up against when using UnixWare, I had trouble finding solutions online. This is not to say that there aren’t very talented people posting about technical issues and their solutions, there just aren’t that many of them.
Thus far in this evaluation I’ve avoided the “SCO factor”, but when speaking on issues beyond the purely technical, it’s impossible to ignore the animosity that SCO has generated with its legal actions and the ramifications that they create. It certainly can’t help adoption of UnixWare, and I think there’s a very compelling argument that it will significantly harm adoption. As a result, the limited user base could cause community-based involvement to suffer significantly, and user community is something that I at least consider very important from and admin perspective.
On a side note I have sympathy for UnixWare users, who now find themselves embattled for running an operating system whose vendor has now become nefarious. Many SCO users don’t agree with SCO’s tactics, but they do find themselves responsible for UnixWare systems, and can easily end up the target of derision. This is also true for SCO employees. I have to imagine that many (perhaps most) don’t agree with their employer’s new tactics. It’d do well to give SCO users and employees the benefit of the doubt.
Enter the Cost Matrix
Cost is always a consideration, and this is perhaps where UnixWare is the most disappointing. For a single-CPU system with one user, UnixWare is $799. For 5 users, the price goes up to $1,399. Here is the complete price list I got from SCO:
Data Center Edition
They were somewhat vague as to what constitutes a user. Here is their definition of a user, from their EULA, quoted to me from a SCO rep:
“User” is a person accessing the Software via a local or remote interactive device, such as a terminal or workstation, except where such use is exclusive to routing or gateway functions of the Software.
I’m inclined to think that it’s a similar model to Microsoft’s definition of a “user”. I can’t imagine it would consist of database users or simultaneous web users, as this would make this product virtually unusable as an Internet server. That is of course speculation, so contact SCO if you’ve any questions regarding their licensing policies.
In doing a comparison with other open source and commercial Unix and Unix-like operating systems, UnixWare is significantly more expensive. To illustrate this, I did a quick price comparison between UnixWare, Linux (both free and enterprise), Solaris x86, and FreeBSD. For the comparison, Enterprise Linux is defined as the distributions that come with some level of support (such as Red Hat Enterprise Server, and SUSE Linux Enterprise Server), and the free Linux would include projects like Slackware and Fedora.
FreeBSD (and other BSDs)
Solaris 9 x86
(supposedly possible, but
For the pricing I used listed prices from RedHat and SUSE (recently acquired by Novell) for their base packages. Obviously, support levels will differ from vendor to vendor as well as prices based on levels of support, so of course doing your own comparison based on your needs would be beneficial if you’re evaluating operating systems.
From this comparison, you can see that UnixWare is dramatically more. On top of that, extras like the UnixWare UDK (and the C++ compiler) and/or access to the UnixWare Update Packs can add significant cost.
The future of UnixWare seems a bit murky. There’s something I noticed while searching through SCO’s press releases, or rather something I noticed was missing: Any announcement of 64-bit support for either Itanium 2 or AMD’s x86-64 platform. It doesn’t appear that 64-bit is on any publicized road map for UnixWare, while other operating systems such as Linux, Solaris, and Windows are either currently supporting or have announced impending support. To me, this is a major strike against UnixWare.
And as I’ve said before, the SCO litigation can’t help UnixWare’s adoption, and is probably in fact severely harming it. While not wanting to get into the FUD factor that SCO has been accused of, one wonders what all this could bode for the future of UnixWare.
The Linux emulation (LKP) works extremely well and I was not able to measure any performance hit from my tests. SCO administration is a good graphical system
There are very few enterprise applications available for UnixWare. Compiling applications is difficult, and requires a greater amount of compiling savvy than Linux, FreeBSD, Solaris, and others. The cost is extremely high compared to other free and commercial Unix-type operating systems, and given the limitations, doesn’t seem worth it. SCO’s legal maneuvers place a dark cloud over the future of UnixWare, and have created an angry backlash.
All in all, it’s hard to find a compelling value proposition in UnixWare, even without taking into account the animosity that SCO has generated. When you do consider the SCO issue, (as it is impossible to ignore) the UnixWare story is even less compelling. I can’t consider it a leading operating system, in terms of either technology or functionality, and I couldn’t imagine any situation where I’d recommend it as a solution.
While The LKP is indeed impressive, it would only make sense running UnixWare-native applications with a need to run a few Linux apps. Given that few commercial applications run natively in UnixWare while most run great in Linux, this doesn’t seem to a situation that would be very common.
Linux offers a far greater value and far better enterprise application support. In addition to Linux, FreeBSD and the other BSDs, and Linux offer a far better open source environment, better hardware support, and more features.
If you want to use a commercial Unix for x86 (and one not targeted by SCO – at least not yet), then Solaris x86 is a very strong offering, with far more enterprise applications available, is far less expensive, and leverages a much larger install base than UnixWare.
In short, the lack of commercial applications and user community, the difficulty with open source applications, the SCO litigation, and the high price are all marks against UnixWare. There are just very few reasons to adopt UnixWare as your platform, and plenty of reasons to adopt (or migrate to) other platforms.