UnixWare 7: revolution or revision?
We’ve been hearing about Gemini, the combination of OpenServer and UnixWare into a single operating system, for years now. Conforming to System V Release 5 (SVR5), Gemini provides an interesting blend of the two older operating systems. The kernel of Gemini is the UnixWare 2.1 operating system and core services, libraries, and commands. Add to that OpenServer 5’s networking stacks, along with traditional OpenServer installation and configuration tools, and you have a new hybrid operating system. To sweeten the product, throw in some new functionality that offers high availability and clustering, remote administration, and better hardware support, and Gemini starts to look very attractive.
Gemini, now known as UnixWare 7, has finally become available. Early beta versions were made available in January to some developers and reviewers, mostly to good reviews. However, the typical number of beta bugs and problems made it difficult to evaluate the product critically. With the Early Availability version of UnixWare 7 rolled out in February, we had a version we could seriously test and report on.
By the time you read this, UnixWare 7 will be in full customer ship, and you’re big debate will be whether to upgrade your existing SCO Unixware or SCO OpenServer systems to the new version. UnixWare 7 is an amalgam of the two operating systems, meant to unify the two versions and produce a more robust, standardized Unix with better performance.
A companion article elsewhere in this issue explains the design philosophy behind UnixWare 7 and its architecture. It also looks at how UnixWare 7 differs from the earlier versions of UnixWare and OpenServer. In this article, we take a hands-on approach to installing and testing UnixWare 7. We report our problems and critiques, primarily, because that’s what most system administrators want to know about: what hassles will we have if we move to UnixWare 7 early.
Some of the most important features of UnixWare 7 are its CDE environment, Internet functionality, scalability, and performance improvements. The move to Common Desktop Environment makes sense, as most of the rest of the Unix world is going there. CDE will not be for everyone, but in an environment with Unix workstations that run CDE, it will be useful to allow SCO platforms to keep the same interface, too. CDE doesn’t replace the older Panorama interface, as you still have the choice of either. The X system has been upgraded to Release 6, the latest version in use. Release 6 of X increases performance a little, and adds new functionality for application programmers.
Internet functionality has been expanded through better integration of Netscape’s FastTrack Server with the high-performance UnixWare kernel. All the usual advanced features are included, such as SSL 3, authentication, and HTML-based administration. UnixWare 7 comes with Navigator Gold 3.0 and authoring support tools, so a Web administrator can use UnixWare 7 to develop and provide a complete Web site for an intranet or connection to the Internet. Java support is through the Java Development Kit, included as part of the UnixWare 7 Development Kit.
Scalability and performance have been designed to allow you to move your SCO system from single processor to multiple CPUs, as well as expanding the size of supported users and devices, without upgrading the entire operating system. Physical RAM and disk limits supported by UnixWare 7 are now beyond the limits of most SCO systems. Reliability has been enhanced through a redesigned architecture, including a better storage device subsystem.
UnixWare 7 is available in at least eight different editions, all with slightly different features and requirements. The Base edition contains, as you would expect, all the basic components. The Business Edition adds a bunch of utilities such as ARCserve/Open, the Common Desktop Environment (CDE) desktop, and Netscape FastTrack Server. A set of addition smaller utilities round out the Business Edition. The Departmental Edition and Enterprise Edition are much the same as the Business Edition; we couldn’t tell from the descriptions what the differences between them are on a package-by-package basis. Presumably the difference is in the licensing for users. The Development Edition contains tools for software development. The Free Edition is the give-away stripped version of UnixWare 7 which contains almost all the components of the larger systems, but licensed for a single user only. Finally the Intranet and Messaging Editions are tailored for more specific tasks on a network. The multiple edition approach may seem confusing and awkward, but they do allow you to purchase as much UnixWare 7 power as you need. Upgrading from one level to another is much simpler now, providing better scalability.
Our early availability version of UnixWare 7 was supplied on two CD-ROMs with two installation diskettes. Recommended hardware requirements for UnixWare 7 are a Pentium processor, 32MB RAM, and 0.5GB hard drive. UnixWare 7 will run on a fast 80486, as we found out, but it runs so slowly that it is essentially useless for any real work except perhaps as a single-user workstation. The 32MB RAM requirements is also a minimum. While our test system ran with just that much RAM, there was a considerable amount of paging involved. When we added SIMMs to bump memory to 64MB the paging problem lessened considerably. We only got rid of paging slow-downs completely when we bumped our test system to 128MB RAM. If you plan on application development or regular use of the CDE desktop, treat 64MB as a minimum.
The 0.5GB disk requirement shouldn’t be much of a problem considering today’s hard drives. While it is possible to run UnixWare 7 in about 300MB using minimum installation choices, there’s no room left for applications. Half a gigabyte won’t get you much spare room on the disk if you decide to install most of the components of UnixWare 7. Instead, plan on at least a 1GB drive, and preferably more.
Video subsystem minimum requirements are a SuperVGA-compatible monitor and video card that can produce an 800x600 resolution. The old 640x480 option just went out the window. Luckily, unless you have a video card and monitor left over from the early part of this decade, meeting the 800x600 resolution minimum won’t be too tough.
A network card is also required, unless you plan to run standalone. Most companies offer UnixWare drivers which should work with UnixWare 7. We tested four different 10/100MHz Ethernet network cards left over from our earlier roundup, and each worked with the UnixWare 7 software using older UnixWare drivers or automatic configuration routines.
In short, the minimum requirements SCO recommends for UnixWare 7 are just that: bare minimums. Yes, the system will run, but it runs slowly and there’s lots of paging. For a serious workstation setup loaded with some applications, figure on a fairly fast Pentium (166MHz or better), 64MB RAM, 1GB disk drive, and a 1024x768 video subsystem as a minimum. For a UnixWare 7 server, up those requirements to at least a 233MHz Pentium, 128MB RAM, 2GB disk drive, and a similar video system. These requirements are not much different than those for Windows NT, UnixWare 7’s major competition. Essentially, the same holds true for all server setups: buy lots of hardware and keep it up to date.
We loaded our evaluation copy of UnixWare 7 on an ALR Revolution 2XL with two 266MHZ Pentiums, 128MB RAM, 9.1GB SCSI-II disk drive, and integrated Cirrus video system capable of 1280x1024. We used our favorite monitor, a ViewSonic P815 21-inch model to display the CDE desktop. With that hardware setup, we had almost no paging, excellent response under client load, and a video interface that was attractive and useful.
As with most SCO Unix installation routines, during system install you can partition the hard drives however you want, or accept the defaults. Since UnixWare 7 is an amalgam of SVR4 and the older UnixWare operating systems, the filesystems that are recommended will probably look strange to administrators who haven’t worked with both systems before. The default values UnixWare 7 chose on our 9.1GB disk were acceptable, but on our smaller test system with only a 2.1GB SCSI hard drive we had to manually alter the defaults to allow applications to be properly loaded. Some applications insist on loading on a particular filesystem (such as /opt, /home, or /var) so you must perform a little bit of advance planning before accepting default filesystem sizes (unless you have a large disk, or plan to add more in the future).
The filesystems used by UnixWare 7 include the traditional root and boot (/stand) filesystems, swap partition (set it to at least the size of your RAM, and much higher if you are running a server that will experience heavy application loads), /dev/volprivate which is used by the Online Data Manager to ensure data can be recovered in case of a crash, and /dev/dump which holds a core image of the system should it crash. If you plan on using the Java Workshop or Java Studio package, swap space requirement jump enormously; SCO recommends at least 350MB swap space and 64MB RAM to run either package. A quick test showed that even these recommendations are on the low side; we bumped swap space to 500MB and RAM to 128MB to get better performance.
The data filesystems can be on any attached drive and include /home and /home2 for user data, /var for installation and administration files, and both /tmp and /var/tmp for temporary file storage. While some of these filesystems can be incorporated under others as a directory if disk space is tight, most system administrators will want to have separate filesystems for each. UnixWare 7 can be installed on IDE drives as easily as SCSI drives, as we found out on our 80486 system. The IDE controller is automatically detected during installation. If IDE and SCSI drives exist in the same system, IDE drives take precedence. ATAPI CD-ROM drives are not detected by UnixWare 7, so can’t be used for installation.
As with other SCO operating systems, UnixWare 7 allows an upgrade from earlier versions. We tried an upgrade from UnixWare version 2.1 and it proceeded smoothly, maintaining our existing filesystems. A full, new installation takes about forty minutes on our ALR server. After you have UnixWare 7 installed on one system, you can perform network installations to other machines. An Ethernet network is required; we tried a network installation over an FDDI subnet and UnixWare 7 wouldn’t recognize it.
We tried a network installation from our ALR server to an old 80486 system, which proceeded smoothly after we figured out how to create the Network Installation Utilities diskettes, although the process was much slower than from a CD-ROM. One problem we encountered was a Host Bus Adapter diskette for the SCSI controllers: our review copy didn’t have a separate diskette, although there were fairly current versions of the drivers on the CD-ROM. An older HBA from the last release of UnixWare solved the problem for one of our controllers.
A quick warning for DPT controller card users: if your DPT card has more than 512MB RAM on-board, you will need to use a utility to configure out memory above that limit. Since most DPT users have nowhere near that much cache RAM, this isn’t much of a problem. Also, some older DPT firmware versions do not seem to work with UnixWare 7. Using a newer firmware rev and disabling IDE support should fix the problem.
During installation, UnixWare 7 presents the Device Configuration Utility. The DCU can be used to preconfigure most of the hardware on the system during installation. After two aborted attempts to install everything at once, we gave up and followed SCO’s advice to install only the bare minimums at primary installation, then add the other devices separately as system administrator.
Once the UnixWare 7 software is installed, the operating system is configured like older versions. Use the Account Manager to set up user accounts (on our upgrade installation we lost our existing accounts and had to recreate them), use the Mail Manager to set up the mail subsystem (sendmail or MMDF), and the Network Configuration Manager to fine-tune the network setup. The rest of the system uses the usual configuration utilities, too. We did experience a glitch on one system with a Diamond Stealth 64 video card, which caused the cursor to disappear or the screen image to become full of garbage. The problem seems to stem from systems with 64MB RAM or more. Editing the grafinfo file as SCO suggests fixed that problem, but may cause a few scratched heads during installation. The problem occurs with some S3 video cards, too.
One choice that will be new to UnixWare 7 users is the decision to employ either the Common Desktop Environment (CDE) interface, or the Panorama Desktop (based on pmwm). After playing with both, we prefer the CDE interface even though it has steeper system requirements than the more traditional Panorama Desktop. CDE is being used on most other Unix workstations and servers, such as those from Hewlett-Packard, and the ability to keep the same interface across a heterogeneous network is attractive.
Testing the System
A few problems arose with our Early Availability testing version, none serious. Perhaps the most important glitch we ran into was with our root password. When the system is booted into single-user mode, we couldn’t do anything. It turns out that the root password must contain only seven-bit characters (regular ASCII characters) or the single-user console is essentially useless. Even if you do use 7-bit characters and log in as single user, to run anything that requires full-screen addressing (such as editing a file with vi) requires a few more steps to set the key mapping and terminal parameters properly. Hopefully this problem will disappear in later releases, as many of us work in single user mode when setting up and configuring new systems. (The use of characters that are not 7-bit tends to be a problem for international users, not those relying on English as their system language. Using the high-bit characters on an English system does help increase security enormously, though.)
A few other idiosyncrasies were found during the testing period, none of them worth more than a note. For example, some man pages (notably the NFS server man page) refer to options that are not supported. Using Netscape for mail or news retrieval causes the Netscape window to overwhelm the 800x600 resolution, so some buttons disappear off the bottom of the screen. This doesn’t happen with higher resolutions. By default, only 40-bit encryption versions of Netscape are loaded. To load the 128-bit versions you need to load the Strong Encryption Supplement.
When using NFS to mount a UnixWare 7 directory, pipe filetypes do not show up properly and symbolic links display incorrectly. VisionFS causes a few minor problems, too, such as sharing directory display corruption (no damage to data). The SNMP Manager caused a few failures until permissions are modified, and we managed to repeatedly lock up the CDE environment using the Network Configuration Manager to remove a network adapter.
On the mail side, xbiff is not supported with UnixWare 7 (so xbiff fans will have to adjust to another package), and using the Netscape mail agent requires physically coding the inbox folder location. If you log in as root, you can’t use IMAP to connect to a remote host (this is not a problem, as it in fact enhances security, but some system administrators will try anyway). Also for security reasons, mail folders cannot be linked (either hard or soft links). Since this is common practice for some system administrators for backup convenience, another adjustment is necessary.
What will you miss if you’re a died-in-the-wool OpenServer or UnixWare 2.1 user? Not that much, in fact. Sure, some things are implemented differently and there will need to be some custom application tweaking because of the changes, but on the whole most users will see no change to their working environment (unless you change desktop to CDE). Porting will be an issue for some applications that involve Streams, for example. UnixWare 7 includes much of Streams, but some features of Streams such as auto-push and tty devices are not implemented in UnixWare 7. In a similar vein, Screen Interface (SI) support that was in UnixWare 2.1 is dropped with UnixWare 7 in favor of the Gemini No Frame Buffer (NFB) graphics driver. A rewrite of this type will be time-consuming.
If you’ve developed network applications under OpenServer at the link-layer level, there will be some changes, too, as the driver interface in UnixWare 7 is not the same. If you have applications that use Netware Open Datalink Interface, they are going to be in bigger trouble as the final version of UnixWare 7 won’t support ODI. We haven’t had a chance to check the Developer’s Kit for UnixWare 7, but it should provide some porting tools that will help move existing applications from either UnixWare or OpenServer.
Our Early Availability version of UnixWare 7 was supplied with a 50-user license. To evaluate the performance of the latest UnixWare version, we set up a second server with identical hardware but running UnixWare 2.1 Application Server. Each machine was configured on the same subnet. A set of ten Windows NT workstation clients were then installed and scripts used to simulate five sessions each onto each server. Two sessions on each NT Workstation were X clients, and three were running scripts that performed FTP, Telnet, and Netscape accesses to the servers. The network was configured as 100Mbps Ethernet through an SMC switch.
To test performance, each server was bombarded with scripted client requests for twenty minutes. We monitored the client delays using Vital Signs’ Net.Medic software as well as some custom C applications. On the server, we ran the Performance Monitor utilities to check disk swaps, memory usage, and TCP service request bottlenecks. Because the timings are inaccurate for short duration events, we took the longer-term view and measured mean results. The numbers that arose were normalized and comparisons between the two servers made. So is UnixWare 7 faster? No. At least not in the Early Availability version. On all our tests, UnixWare 2.1 Application Server ran a little faster, usually about 11% better than UnixWare 7. The actual results differed depending on the test, but overall the newest edition of UnixWare 7 was not a speed demon compared to its older sibling. Keep in mind, though, that we are testing a pre-shipping version, and optimization is bound to occur before SCO lets UnixWare 7 out the door.
We repeated the tests on a SCO OpenServer 5.0.4 server, with better results. UnixWare 2.1 has been faster than OpenServer over similar tests, and UnixWare 7 continued the trend. UnixWare 7 measured about 3% faster than the OpenServer 5.0.4 server over the test time, although it is difficult to be quantitative about this small a difference. Nonetheless, the performance differences, especially using X client access, were noticeable by users.
How does UnixWare 7 compare with the other server packages now available? The primary competition for UnixWare 7 is going to be Solaris, Linux, and Windows NT. Dealing with Windows NT first it’s obvious these two are quite different. While Windows NT is often thought of as the best features of Unix combined with a better GUI and thirty years of design hindsight, there is still a lot to be said for Unix’ down-to-the-metal approach to everything. Speed tests between UnixWare 7 and Windows NT are difficult to perform properly because our Unix X scripts don’t apply under NT, and that’s the major performance drain. As far as simple file transfer and telnet applications go, UnixWare 7 has a performance advantage, albeit small.
Comparing UnixWare 7 to Linux is again a bit unfair. Linux has the advantage of being a smaller, more performance-oriented kernel. In our tests with Caldera Open Linux, Linux ran faster than UnixWare 7 in all tests. However, Linux lacks some of the more advanced features of UnixWare 7 (including CDE) and also suffers in the architecture design and API forums. We’re still not sure we’d trust a large commercial network to Linux, despite its very stable current form.
Solaris is the most popular Unix workstation or server variant of Unix. The latest version of Solaris adds a number of new features to the already stable operating system. A performance comparison is almost meaningless in the lab, though, because of the different hardware required by each system. Still, we did run Solaris 2.7 on a SPARC Ultra server similarly equipped as our UnixWare 7 ALR server. Solaris won the competition, although the difference is due to the SPARC chip. Keep in mind that a SPARC Ultra system is considerably more expensive than our ALR test system.
Time to Upgrade?
Do you upgrade your existing systems to UnixWare 7, or stay with older UnixWare and OpenServer versions? As you have read, all our problems with UnixWare 7 were trivial. Indeed, it is likely many of them will have been solved in the final release of the product. Those problems that do remain all have workarounds.
A potential downside to upgrading occurs if you have a lot of legacy applications that are intimately tied to OpenServer or UnixWare. As mentioned above, some features that most programmers use in both earlier operating systems are no longer in UnixWare 7, so application porting may become an issue. This is especially true for those who wrote applications that intimately work with the older APIs. It is unlikely these ports are going to be trivial.
Really the only serious consideration to upgrading is the system requirements. If you are running on an underpowered machine now, things will just get worse with UnixWare 7. If you have the horsepower and RAM to run UnixWare 7 properly, then the upgrade is definitely worth the trouble. UnixWare 7 combines a better architecture with strong APIs, resulting in a marriage of OpenServer and UnixWare that gets the best of both, throws in a few new features, and gives you a better all-round operating system. That’s what we all wanted from UnixWare 7.