The most obvious shared problem is nonportability. Most of
Unix's pre-1980 competitors were tied to a single hardware platform,
and died with that platform. One reason VMS survived long enough to
merit inclusion here as a case study is that it was successfully
ported from its original VAX hardware to the Alpha processor (and in
2003 is being ported from Alpha to Itanium). MacOS successfully
made the jump from the Motorola 68000 to PowerPC chips in the late
1980s. Microsoft Windows escaped this problem by being in the
right place when commoditization flattened the market for
general-purpose computers into a PC monoculture.
From 1980 on, another particular weakness continually reemerges
as a theme in different systems that Unix either steamrollered or
outlasted: an inability to support networking gracefully.
In a world of pervasive networking, even an operating system
designed for single-user use needs multiuser capability (multiple
privilege groups) — because without that, any network
transaction that can trick a user into running malicious code will
subvert the entire system (Windows macro viruses are only the tip of
this iceberg). Without strong multitasking, the ability of an
operating system to handle network traffic and run user programs at
the same time will be impaired. The operating system also needs
efficient IPC so that its network programs can communicate with each
other and with the user's foreground applications.
Windows gets away with having severe deficiencies in these areas
only by virtue of having developed a monopoly position before
networking became really important, and by having a user population
that has been conditioned to accept a shocking frequency of crashes
and security breaches as normal. This is not a stable situation, and
it is one that partisans of Linux have successfully (in 2003)
exploited to make major inroads in the server-operating-system
market.
Around 1980, during the early heyday of personal computers,
operating-system designers dismissed Unix and traditional timesharing
as heavyweight, cumbersome, and inappropriate for the brave new world
of single-user personal machines — despite the fact that GUI
interfaces tended to demand the reinvention of multitasking to cope
with threads of execution bound to different windows and widgets. The
trend toward client operating systems was so intense that server
operating systems were at times dismissed as steam-powered relics of a
bygone age.
But as the designers of BeOS noticed, the requirements of
pervasive networking cannot be met without implementing something very
close to general-purpose timesharing. Single-user client operating
systems cannot thrive in an Internetted world.
This problem drove the reconvergence of client and server
operating systems. The first, pre-Internet attempts at peer-to-peer
networking over LANs, in the late 1980s, began to expose the
inadequacy of the client-OS design model. Data on a network has to
have rendezvous points in order to be shared; thus, we can't do
without servers. At the same time, experience with the Macintosh and
Windows client operating systems raised the bar on the minimum quality
of user experience customers would tolerate.
With non-Unix models for timesharing effectively dead by 1990,
there were not many possible responses client operating-system
designers could mount to this challenge. They could co-opt Unix (as
MacOS X has done), re-invent roughly equivalent features a patch at a
time (as Windows has done), or attempt to reinvent the entire world
(as BeOS tried and failed to do). But meanwhile, open-source Unixes
were growing client-like capabilities to use GUIs and run on
inexpensive personal machines.
These pressures turned out, however, not to be as symmetrically
balanced as the above description might imply. Retrofitting
server-operating-system features like multiple privilege classes and
full multitasking onto a client operating system is very difficult,
quite likely to break compatibility with older versions of the client,
and generally produces a fragile and unsatisfactory result rife with
stability and security problems. Retrofitting a GUI onto a server
operating system, on the other hand, raises problems that can largely
be finessed by a combination of cleverness and throwing
ever-more-inexpensive hardware resources at the problem. As with
buildings, it's easier to repair superstructure on top of a solid
foundation than it is to replace the foundations without
trashing the superstructure.
Besides having the native architectural strengths of a server
operating system, Unix was always agnostic about its intended
audience. Its designers and implementers never assumed they knew all
potential uses the system would be put to.
Thus, the Unix design proved more capable of reinventing itself as
a client than any of its client-operating-system competitors were of
reinventing themselves as servers. While many other factors of
technology and economics contributed to the Unix resurgence of
the 1990s, this is one that really foregrounds itself in any
discussion of operating-system design style.
