From: Raz Mathias (razvanma_at_exchange.microsoft.com)
Date: Thu Jan 08 2004 - 17:35:21 PST
This paper introduced the basic Unix system. I found it interesting
early on that "the most important role of Unix is to provide a file
system." This is a bold statement from the point of view of a modern
operating system, which needs to provide processor and I/O device
sharing, virtual memory, protection, security, connectivity, etc. Even
so, this file system is fairly primitive and limited by today's
standards.
The decision to make files sequences of 14 or fewer characters seemed to
be a limiting idea in the naming (although more flexible than the
eight-dot-three notation DOS provides). There is no consideration given
to extending the character set (code pages, Unicode, etc.), but this was
probably not a concern at the time. The directory system is basically a
rooted tree of pointers to underlying resources such as files and
devices. These underlying files are then reference-counted, allowing
for the possibility of placing them in different locations in the
directory hierarchy. I believe that this ability to classify a resource
under more than one path name is quite powerful and is, even today, not
used to its full potential. For example, it is not natural (at least
from the UI of an OS like Windows) to classify an mp3 or picture into
different categories. The idea is quite appealing to me. In terms of
file systems, the important aspect of indexing files based on different
attributes (to support fast searches) is not at all touched upon; this
would have been another valuable venue for exploration. I also found it
slightly humorous reading "They [file locks] are unnecessary because we
are not faced with large, single-file data bases maintained by impendent
processes." This is quite a bold and non-scaling assumption to make in
the design of an OS. Another design detail that doesn't scale is that
of "large files" being one megabyte maximum. Such artificial
limitations should be excluded from modern operating systems.
Furthermore file quotas are omitted, which are also a useful form of
protection
The protection section did not go into much depth, choosing instead to
discuss the interesting "set-user-ID" feature. This feature allows the
user to impersonate the owner of a file when it is executed. From a
security standpoint, this seems like a brittle mechanism and should
probably be used sparingly an in accordance with the principle of least
privilege.
Also, the statement "the success of Unix is largely due to the fact that
it was not designed to meet any predefined objectives" probably made
sense at the time, an operating system built from first principles that
doesn't make too many constraining assumptions is more versatile. In
many ways, though, this statement is wrong in today's world. Operating
systems need to be written with the potential running applications in
mind. For example, it is difficult to build a scalable server, a
distributed transaction system, or a scalable web server without some
support from the underlying system. For this reason, a "barebones"
operating system is not at all the trend today.
The brief statement in the reliability section "our statistics on
reliability are much more subjective than the others" reflects a poor
attitude toward product quality that only recently has been changing.
This archive was generated by hypermail 2.1.6 : Thu Jan 08 2004 - 17:35:02 PST