22 January 2006

Milestones: Unix (1)

Unix was developed in the mid-1970's to run on a Digital PDP-7; it was eventually "ported" (modified to run on) virtually every computer ever produced. The name "Unix" is a play on the name "Multics," a mainframe operating system that had suffered from excessive size and complexity. It was developed as a hobby by Ken Thompson and Dennis Ritchie and later became one of the more influential products of Bell Labs.

The history of Unix has been told many times (e.g.; here); my interest is in what made Unix a milestone in the development of computer technology. Prior to the 1970's, computer processing was run in a batch format, i.e., without human interaction; typically programs themselves were designed to run like any other industrial machine, with a huge stream of homogeneous inputs subject to a homogeneous process, and with arithmetically predictable outputs, such as the payrolls for a large firm. Multics and Unix were designed for running large numbers of programs on the same processor interactively. This would make Unix compatible with future uses of the computer.

Unix accomplished this through modular architecture; the operating system was to consist of a kernel which was minimal in size, plus a library of utilities. The latter would depend on the computer platform and the peculiar needs of the user. An additional attribute, added in 1973, was the use of high-level programming language, C, for programming applications. This would mean that most of the effort of porting Unix to other machines would hereafter be confined to rewriting the compiler.

One of the results of this approach was that system managers in charge of Unix server or workstation would be allowed [or compelled] to make a very large number of choices about the look and feel of the OS:
X [Windows] strives to provide “mechanism, not policy”, supporting an extremely general set of graphics operations and deferring decisions about toolkits and interface look-and-feel (the policy) up to application level. Unix's other system-level services display similar tendencies; final choices about behavior are pushed as far toward the user as possible. Unix users can choose among multiple shells. Unix programs normally provide many behavior options and sport elaborate preference facilities.

This tendency reflects Unix's heritage as an operating system designed primarily for technical users, and a consequent belief that users know better than operating- system designers what their own needs are.


But the cost of the mechanism-not-policy approach is that when the user can set policy, the user must set policy. Nontechnical end-users frequently find Unix's profusion of options and interface styles overwhelming and retreat to systems that at least pretend to offer them simplicity.

[...] However, it may turn out that this ‘mistake’ confers a critical advantage — because policy tends to have a short lifetime, mechanism a long one. Today's fashion in interface look-and-feel too often becomes tomorrow's evolutionary dead end (as people using obsolete X toolkits will tell you with some feeling!). So the flip side of the flip side is that the “mechanism, not policy” philosophy may enable Unix to renew its relevance long after competitors more tied to one set of policy or interface choices have faded from view.
Eric Steven Raymond, "What Unix Gets Wrong"
This is extremely important for understanding what follows. Even systems managers (and especially their supervisors) like to have most, if not all, of the decisions made for them. Too many options can make decision-making intolerably burdensome. So many engineers, adopting Unix, embraced a particular design policy and thereby created a specific family of Unix systems.

(Part 2)
ADDITIONAL READING & SOURCES: Wikipedia Unix; Unix System V; Berkeley Software Distribution (BSD); Tru64 UNIX (also known as OSF/1); Unix Wars;

USENIX Association website (formerly Unix Users' Group); The Open Group: History and Timeline;

Living Internet: Unix; Eric Steven Raymond, The Art of Unix Programming

Labels: ,


Post a Comment

<< Home