The Art of Unix Programming

haoji

The Mozilla release helped further concentrate opinions. In March of 1998 an unprecedented
summit meeting of community influence leaders representing almost all of the major tribes
convened to consider common goals and tactics. That meeting adopted a new label for the
common development method of all the factions: open source.

Within six months almost all the tribes in the hacker community would accept 鈥渙pen source鈥

haoji

has since insisted on its separateness from 鈥渙pen source鈥

haoji

The lessons of Unix history

Prev Chapter 2. History

Next



The lessons of Unix history

The largest-scale pattern in the history of Unix is this: when and where Unix has adhered
most closely to open-source practices, it has prospered. Attempts to proprietarize it have
invariably resulted in stagnation and decline.

In retrospect, this should probably have become obvious much sooner than it did. We lost ten
years after 1984 learning our lesson, and it would probably serve us very ill to ever again
forget it.

Being smarter than anyone else about important but narrow issues of software design didn't
prevent us from being almost completely blind about the consequences of interactions
between technology and economics that were happening right under our noses. Even the
most perceptive and forward-looking thinkers in the Unix community were at best half-
sighted. The lesson for the future is that over-committing to any one technology or business
model would be a mistake 鈥

haoji

The application of these lessons with respect to software technologies other than Unix is left
as an easy exercise for the reader.

Prev Up Next

The open-source movement: 1998
and onward.

Home Chapter 3. Contrasts

haoji

Chapter 3. Contrasts

Prev Part I. Context

Next



Chapter 3. Contrasts

Comparing the Unix Philosophy With Others

Table of Contents

The elements of operating-system style
What is the unifying idea?
Cooperating processes
Internal boundaries
File attributes and record structures
Binary file formats
Preferred UI style
Who is the intended audience?
What are the entry barriers to development?



Operating-system comparisons
VMS
Mac OS
OS/2
Windows NT
BeOS
Linux



What goes around, comes around


If you have any trouble sounding condescending, find a Unix user to show you how it's done.

--Scott Adams

The design of operating systems conditions the style of software development under them in
many ways both obvious and subtle. Much of this book traces connections between the
design of the Unix operating system and the philosophy of program design that has evolved
around it. For contrast, it will therefore be instructive to contrast the classic Unix way with

haoji

the styles of design and programming native to other major operating systems.

Prev Up Next

The lessons of Unix history

Home The elements of operating-system
style

haoji

The elements of operating-system style

Prev Chapter 3. Contrasts

Next



The elements of operating-system style

Before we can start discussing specific operating systems, we'll need an organizing
framework for the ways that operating-system design can affect programming style. These are
patterns that will recur repeatedly in our specific examples.

Overall, the design and programming styles associated with different operating system seem
to derive from two different sources 鈥

haoji

If an operating system makes spawning new processes expensive, you'll usually see all of the
following consequences:

l
Multithreading is extensively used for tasks that Unix would handle with multiple
communicating lightweight processes.
l
Learning and using asynchronous I/O is a must.
l
Monster monoliths become a more natural way of programming.
l
Lots of policy has to be expressed within those monoliths. This encourages C++ and
elaborately layered internal code organization, rather than C and relatively flat internal
hierarchies.
l
When processes can't avoid a need to communicate, they do so through mechanisms
that are clumsy, inefficient, and insecure, such as temporary files.


This is an example of common stylistic traits (even in applications programming) being
driven by a limitation in the OS environment.

To design the perfect anti-Unix, make process-spawning very expensive and leave IPC as an
unsupported or half-supported afterthought.

Internal boundaries

Unix has wired into it an assumption that the programmer knows best. It doesn't stop you or
request confirmation when you do dangerous things with your own data, like rm -fr *. On the
other hand, Unix is rather careful about not letting you step on other people's data.

Unix has at least three levels of internal boundaries that guard against malicious users or
buggy programs. One is memory management; Unix uses its hardware's memory
management unit (MMU) to ensure that separate processes are prevented from intruding on
the others' memory-address spaces. A second is the presence of true privilege groups for
multiple users 鈥

haoji

To design the perfect anti-Unix, discard or bypass memory management so that a runaway
process can crash, subvert, or corrupt any running program. Have weak or nonexistent
privilege groups, so users can readily alter each others' files and the system's critical data.
And trust large volumes of code, like the entire shell and GUI, so that any bug or successful
attack on that code becomes a threat to the entire system.

File attributes and record structures

Unix files have neither record structure nor attributes. In some operating systems, files have
an associated record structure; the operating system (or its service libraries) knows about files
with a fixed record length, or about text line termination and whether CR/LF is to be read as a
single logical character.

In other operating systems, files and directories can have name/attribute pairs associated with
them 鈥

haoji

the following:

l
Even if CLI, scripting and pipes are supported, very few filters will evolve.
l
Data files will be accessible only through dedicated tools. Developers will think of the
tools rather than the data files as central. Thus, different versions of file formats will
tend to be incompatible.


To design the perfect anti-Unix, make all file formats binary and opaque, and require
heavyweight tools to read and edit them.

Preferred UI style

In Chapter 11 (User Interfaces) we will develop in some detail the consequences of the
differences between command-line interfaces (CLIs) and graphical user interfaces (GUIs).
Which kind an operating system's designers choose as its normal mode of presentation will
affect many aspects of the design, from process scheduling and memory management on up
to the application programming interfaces (APIs) presented for applications to use.

It has been enough years since the Macintosh that very few people need to be convinced that
weak GUI facilities in an operating system are a problem. The Unix lesson is the opposite;
that weak CLI facilities are a less obvious but equally severe deficit.

If the CLI facilities of an operating system are weak or nonexistent, you'll also see the
following consequences:

l
Programs will not be designed to cooperate with each other 鈥