From: Cem Paya 98 (Cem.Paya.98_at_Alum.Dartmouth.ORG)
Date: Wed Jan 07 2004 - 17:37:30 PST
Cem Paya, CSE551P
The UNIX time-sharing system
Dennis M. Ritchie, Ken Thompson
This is an early “vintage” paper (1974) with high-level
overview of the UNIX system. While it’s clearly showing
its age with anachronisms (references to typewriters,
hardware “costing as little as $40,000” and painstaking
descriptions of the PDP/11 peripherals) the paper was
clearly ahead of its time. In relatively small space the
authors describe key concepts that made UNIX successful:
file system, notion of links, treating hardware devices as
ordinary files subject to same semantics, access-control &
security for files, command shell, etc.
Reading this paper in 2004 with the benefit of 30 years of
hindsight in commercial operating systems development, we
can single out the times when the authors were proved
prescient. For example they comment about the advantages
of treating I/O devices as part of the file system, which
simplifies programming—important since being developer-
friendly is one of the stated objectives. Section #3.5 on
file protection suggests security was one of the
considerations in design. Discussion around using an
editor as shell to prevent users from invoking UNIX
programs not intended for their use is perhaps the first
mention of the problem of sandboxing. Pipe mechanism (what
the authors describe as filters) is an elegant way to tie
together multiple programs. Perhaps most important
contribution is their philosophy on design: small pieces,
each doing one task well, joined together using the OS.
They contrast the command line approach to printing
directory contents into an offline file (“ls” run in
cascade with “pr” and “opr”) verses a single monolithic
directory listing application that supports the
functionality of all three commands, describing the latter
as “unwise for efficiency reasons.” In spite of Ritchie’s
knack for understatements at work here, this idea of
building up powerful functionality by tying together very
many small programs is at the core of UNIX.
On the downside, UNIX has also introduced its fair share
of problems. Section on protection describes the ill-fated
notion of SUID (set-user-ID) programs which has been a
constant source of security problems. The success of UNIX
is paradoxically attributed to the lack of formal
objectives, recounting the history of Ken Thompson
creating an operating system to make better use of an
otherwise under-utilized PDP7. Lack of clear requirements
generally does not bide well for consistent design,
although in the case of UNIX they were perhaps supplanted
by the three guiding principles. One of these is a clear
strength, namely that the system can maintain itself.
Second is largely historical and perhaps on balance not
good influence: severe size constraints is not a good
guiding principle in the face of Moore’s law. (Example:
use of 32-bit time counters which will overflow in 2038 to
create the next Y2K crisis.) The last one is simply mind-
boggling when UNIX is considered in light of its
commercial potential. In an age of ubiqutious computing
ease of writing code is hardly one of the benefits end
users will appreciate. Granted that can indirectly
influence quality of the platform by determining what
types of applications will be written, but such early
emphasis on developer requirements seems oddly incongruent
in current view of computing.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 17:37:36 PST