The Art of Unix Programming

haoji

Varieties of Open-Source
Licensing

Home Essence and accident in Unix
tradition

haoji

Essence and accident in Unix tradition

Prev Chapter 18. Futures

Next



Essence and accident in Unix tradition

To understand how Unix's design might change in the future, we can start by looking at how
Unix programming style has changed over time in the past. This effort leads us directly to
one of the challenges of understanding the Unix style 鈥

haoji

Looking back, we can identify three specific technology changes that have driven significant
changes in Unix design style; internetworking, bit-mapped graphics displays, and the
personal computer. In each case, the Unix tradition has adapted to the challenge by
discarding accidents that were no longer adaptive and finding new applications for its
essential ideas. Biological evolution works this way too. Evolutionary biologists have a rule:
鈥淒on't assume that historical origin specifies current utility or vice versa.鈥

haoji

persistence of different UI styles that we noted in Chapter 11 (User Interfaces) seems telling.
New-school Unix design has kept the command line, and dealt with the tension between GUI
and CLI approaches by writing lots of CLI-engine/GUI-interface pairs that can be used in
both styles.

The personal computer posed few major design challenges as a technology in itself. The 386
and later chips were powerful enough to give the systems designed around them cost ratios
similar to those of the minicomputers, workstations, and servers on which Unix matured. The
true challenge was a change in the potential market for Unix; the much lower overall price of
the hardware made personal computers attractive to a vastly broader, less technically
sophisticated user population.

The proprietary-Unix vendors, used to the fatter margins from selling more powerful systems
to sophisticated buyers, were never interested in this wider market. The first serious
initiatives towards the end-user desktop came out of the open-source community and were
mounted for essentially ideological reasons. As of early 2003, market surveys indicate that
Linux has reached about 4%-5% share there.

Whether or not Linux ever does substantially better than this, the nature of the Unix
community's response is already clear. We examined it the study of Linux in Chapter 3
(Contrasts). It includes adopting a few technologies (such as CORBA and XML) from
elsewhere, and putting a lot of effort into naturalizing GUIs into the Unix world. But
underneath the themed GUIs and the installation packaging, the main emphasis is still on
modularity and clean code 鈥

haoji

out of Unix's basic abstractions of streams, namespaces, and processes in preference to
layering on new ones.


[67] For a few years it looked like ISO's 7-layer networking standard might compete
successfully with TCP/IP. It was dreamed up by a European standards committee politically
horrified at the thought of adopting any technology birthed in the bowels of the Pentagon.
Alas, their indignation exceeded their technical acuity. The result proved overcomplicated
and unhelpful; see [Padlipsky] for details.

Prev Up Next

Chapter 18. Futures

Home Problems in the design of Unix

haoji

Problems in the design of Unix

Prev Chapter 18. Futures

Next



Problems in the design of Unix

But are there serious problems with those basic abstractions? In chapter 1 (Philosophy) we
touched on several issues that Unix arguably got wrong. Now that the open-source
movement has put the design future of Unix back in the hands of programmers and technical
people, these are no longer decisions we have to live with forever. We'll take a look at them
in order to get a better handle on how Unix might evolve in the future.

A Unix file is just a big bag of bytes

A Unix file is just a big bag of bytes, with no other attributes. In particular, there is no
capability to store information about the file type or a pointer to an associated application
program out-of-band from the file's actual data.

More generally, everything is a byte stream; even hardware devices are byte streams. This
metaphor was a tremendous success of early Unix, and a real advance over a world in which
(for example) compiled programs could not produce output that could be fed back to the
compiler. Pipes and shell programming sprang from this metaphor.

But Unix's byte-stream metaphor is so central that Unix has trouble integrating software
objects with operations that don't fit neatly into the byte stream or file repertoire of
operations (create, open, read, write, delete). This is especially a problem for GUI objects
such as icons, windows, and 鈥榣ive鈥

haoji

every tool that touches it has to take care to either preserve the type field unaltered or
interpret and then rewrite it. While this would be theoretically possible to arrange, in practice
it would be way too fragile.

On the other hand, supporting file attributes raises awkward questions about which file
operations should preserve them. It's pretty clear that a copy of a named file to another name
should copy the source file's attributes as well as its data 鈥

haoji

C lacks a facility for throwing named exceptions with attached data. Thus, the C functions in
the Unix API indicate errors by returning a distinguished value (usually -1 or a NULL
character pointer) and setting a global errno varable.

In retrospect, this is the source of many subtle errors. Programmers in a hurry often neglect
to check return values. Because no exception is thrown, the Rule of Repair is violated;
program flow continues until the error condition manifests as some kind of failure or data
corruption later in execution.

The absence of exceptions also means that some tasks which ought to be simple idioms 鈥

haoji

merit of not requiring piles of macro definitions before the interface could be used). The Plan
9 operating system, written by some of Unix's principal designers in an effort to correct some
of Unix's problems, uses the named fileserver or filesystem as its basic object, rather than the
file/bytestream; Plan 9 filesystems can contain arbitrarily complex hierarchies of named
objects with file-like interfaces.

The Unix security model may be too primitive

Perhaps root is too powerful, and Unix should have finer-grained capabilities or ACLs
(Access Control Lists) for system-administration functions, rather than one superuser that
can do anything. People who take this position argue that too many system programs have
permanent root privileges through the set-user-ID mechanism; if even one can be
compromised, intrusions everywhere will follow.

This argument is weak, however. Modern Unixes allow any given user account to belong to
multiple security groups. Through use of the execute-permission and set-group-ID bits on
program executables, each group can in effect function as an ACL for files or programs.

This theoretical possibility is very little used, however, suggesting that the demand for ACLs
is much less in practice than it is in theory.

Unix has too many different kinds of names for things

Unix unified files and local devices 鈥

haoji

Modern efforts in this line (such as EROS, see the EROS project site) hint that such designs
can offer large benefits including both provable conformance to a security policy and higher
performance.

It must be noted, however, that if this is a failure of the Unix design, it is equally a failure of
all of its competitors no major production operating system has yet followed this lead. [68]


[68] The operating systems of the Apple Newton and the AS/400 minicomputer could be
considered exceptions.

Prev Up Next

Essence and accident in Unix
tradition

Home Problems in the environment of
Unix