From: Cliff Schmidt (cliff_at_bea.com)
Date: Wed Jan 07 2004 - 13:22:22 PST
The UNIX paper is mainly interesting from a historical context. Many of the
features that I'm familiar with (often from features that found their way
into MS-DOS) were discussed, even though several of them originated in other
operating systems such as Multics.
It was especially interesting to read justification for concepts that we
take for granted today, such as:
- the structure of files is controlled by the program which uses them, not
by the system
- reasons for a tree-structured file system
- protection system's use of the seventh bit to temporarily change user
identification. This issue of delegation is being revisited today in Web
services and other places around distributed computing.
- buffering and caching secondary storage in core memory. I wondered
whether this was first being figured out for UNIX or whether these concepts
were borrowed from Database Management Systems of the time.
- process synchronization and forking -- also interesting to read how the
thought process behind having the Shell create a sub process for each
execution which returns back to the shell when finished (unless the '&'
character is used). Also interesting how the Shell passes on standard or
redirected input and output devices to the new process and is then able to
return to its own devices.
- desirability of pushing device-dependent considerations into the
operating system
- explanation of a system "crash" and the statistics on system reliability,
including the 98% uptime. I don't think that 2/3 of crashes today are due
to hardware.
Features that I wasn't familiar with (as a Windows user) were:
- linking: unlike Windows shortcuts, files don't actually exist in any
particular directory.
- special files: seems to allow more than the 26 possible device names
used by Windows (A:, C:, etc) by letting file names be used as device names,
although later in the paper there is mention of a pair of bytes that
constitute an internal device name -- this might be the true limit to the
number of potential devices.
I was a little concerned about the following statements:
- It's possible to become scrambled when two users write on a file
simultaneously, but in practice difficulties do not arise. I don't
think that would be acceptable today.
- The i-number is an integer pointer, which inherently limits the number
of files that the system can manage to the max value of an integer on
the system (possibly 65k for this system?).
- the buffering system may not perform an I/O until some time after the
application attempts to write. The authors do not mention whether an
explicit option is available to force a flush of the buffer to secondary
storage. Without this, a system crash could cause loss of data that the
user was told was saved.
It was interesting to note that from the very beginning, UNIX was designed
to be an operating system for developers, namely the two authors of the
paper. This explains a lot of the design features.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 13:22:25 PST