Operating-System Comparisons
The logic of Unix's design choice stands out more clearly when
we contrast it with other operating systems. Here we will attempt
only a design overview; for detailed discussion of the technical
features of different operating systems.[24]
Figure3.1 indicates the genetic relationships
among the timesharing operating systems we'll survey. A few other
operating systems (marked in gray, and not necessarily timesharing)
are included for context. Sytems in solid boxes are still live. The
‘birth’ are dates of first shipment;[25] the ‘death’ dates are generally
when the system was end-of-lifed by its vendor.
Solid arrows indicate a genetic relationship or very strong
design influence (e.g., a later system with an API deliberately
reverse-engineered to match an earlier one). Dashed lines indicate
significant design influence. Dotted lines indicate weak design
influence. Not all the genetic relationships are acknowledged by the
developers; indeed, some have been officially denied for legal or
corporate-strategy reasons but are open secrets in the
industry.
The ‘Unix’ box includes all proprietary Unixes,
including both AT&T and early Berkeley versions. The
‘Linux’ box includes the open-source Unixes, all of which
launched in 1991. They have genetic inheritance from early Unix
through code that was freed from AT&T proprietary control by the
settlement of a 1993 lawsuit.[26]
VMS is the proprietary operating system originally developed for
the VAX minicomputer from Digital Equipment Corporation. It was first
released in 1978, was an important production operating system in the
1980s and early 1990s, and continued to be maintained when DEC was
acquired by Compaq and Compaq was acquired by Hewlett-Packard. It is
still sold and supported in mid-2003, though little new development
goes on in it today.[27] VMS is surveyed here to show the contrast between
Unix and other CLI-oriented operating systems from the minicomputer
era.
VMS has full preemptive multitasking, but makes
process-spawning very expensive. The VMS file system has an elaborate
notion of record types (though not attributes). These traits have all
the consequences we outlined earlier on, especially (in VMS's case)
the tendency for programs to be huge, clunky monoliths.
VMS features long, readable COBOL-like system commands and
command options. It has very comprehensive on-line help (not for APIs,
but for the executable programs and command-line syntax). In fact, the
VMS CLI and its help system are the organizing metaphor of VMS.
Though X windows has been retrofitted onto the system, the
verbose CLI remains the most important stylistic influence on program
design. This has the following major implications:
-
The frequency with which people use command-line functions — the more voluminously you have to type, the less you want to
do it.
-
The size of programs — people want to type less, so they
want to use fewer programs, and write larger ones with more bundled
functions.
-
The number and types of options your program
accepts — they must conform to the syntactic
constraints imposed by the help system.
-
The ease of using the help system — it's very complete,
but search and discovery tools for it are absent and it has poor
indexing. This makes acquiring broad knowledge difficult, encourages
specialization, and discourages casual programming.
VMS has a respectable system of internal boundaries. It was
designed for true multiuser operation and fully employs the hardware
MMU to protect processes from each other. The system command
interpreter is privileged, but the encapsulation of critical functions
is otherwise reasonably good. Security cracks against VMS have been
rare.
VMS tools were initially expensive, and its interfaces are
complex. Enormous volumes of VMS programmer documentation are only
available in paper form, so looking up anything is a time-consuming,
high-overhead operation. This has tended to discourage exploratory
programming and learning a large toolkit. Only since being nearly
abandoned by its vendor has VMS developed casual programming and a
hobbyist culture, and that culture is not particularly strong.
Like Unix, VMS predated the client/server distinction. It was
successful in its day as a general-purpose timesharing operating
system. The intended audience was primarily technical users and
software-intensive businesses, implying a moderate tolerance for
complexity.
[an error occurred while processing this directive]
