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鈥�
as its new banner. Older groups like IETF and the BSD developers would begin to apply it
restrospectively to what they had been doing all along. In fact, by 2000 the rhetoric of open
source would not just unify the hacker culture's present practice and plans for the future, but
re-color its view of its own past.

The galvanizing effect of the Netscape announcement, and of the new prominence of Linux,
reached well beyond the Unix community and the hacker culture. Beginning in 1995,
developers from various platforms in the path of Microsoft's Windows juggernaut (MacOS;
Amiga; OS/2; DOS; CP/M; the weaker proprietary Unixes; various mainframe,
minicomputer, and obsolete microcomputer operating systems) had banded together around
Sun Microsystems's Java. Many disgruntled Windows developers joined them in hopes of
maintaining at least some nominal independence from Microsoft. But Sun's handling of Java
was (as we discuss in Chapter 12 (Languages)) clumsy and alienating on several levels.
Many Java developers liked what they saw in the nascent open-source movement, and
followed Netscape's lead into Linux and open source just as they had previously followed
Netscape into Java.

Open-source activists welcomed the surge of immigrants from everywhere. The old Unix
hands began to share the new immigrants' dreams of not merely passively out-enduring the
Microsoft monopoly, but actually reclaiming key markets from it. The open-source
community as a whole prepared a major push for mainstream respectability, and began to
welcome alliances with major corporations that increasingly feared losing control of their
own businesses as Microsoft's lock-in tactics grew ever bolder.

There was one exception: Richard Stallman and the Free Software Movement. 鈥淥pen
source鈥� was explicitly intended to replace Stallman's preferred 鈥渇ree software鈥� with a public
label that was ideologically neutral, acceptable both to historically opposed groups like the
BSD hackers and those who did not wish to take a position in the GPL/anti-GPL debate.

Stallman flirted with adopting the term, then rejected it on the grounds that it failed to
represent the moral position that was central to his thinking. The Free Software Movement

has since insisted on its separateness from 鈥渙pen source鈥�. Most hackers outside the Free
Software Movement view this position as a divisive quibble, creating perhaps the most
significant political fissure in the hacker culture.

The other (and more important) intention behind 鈥渙pen source鈥� was to present the hacker
community's methods in a more market-friendly, less confrontational way. In this role,
fortunately, it proved an unqualified success.

Prev Up Next

Origins and history of the hackers,
1961-1995

Home The lessons of Unix history

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 鈥� and maintaining the adaptive flexibility of our software and the
design tradition that goes with it is correspondingly imperative.

Never bet against the cheap plastic solution. Or, equivalently, the low-end/high-volume
hardware technology almost always ends up climbing the power curve and winning. The
economist Clayton Christensen calls this disruptive technology and showed how this
happened with disk drives, steam shovels, and motorcycles in The Innovator's Dilemma
[Christensen]. We saw it happen as minicomputers displaced mainframes, workstations and
servers replaced minis, and commodity Intel boxes replaced workstations and servers. The
open-source movement is winning by commoditizing software. To prosper, Unix needs to
maintain the knack of co-opting the cheap plastic solution rather than trying to fight it.

Finally, the old-school Unix community's efforts to be 鈥減rofessional鈥� by welcoming in all
the command machinery of conventional corporate organization, finance, and marketing
failed. We had to be rescued from our folly by a rebel alliance of obsessive geeks and
creative misfits 鈥� who then proceeded to show us that professionalism and dedication really
meant what we had been doing before we succumbed to the mundane persuasions of 鈥渟ound
business practices鈥�.

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

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

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

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 鈥� (a) what the operating-system designers intended, and
(b) uniformities forced on designs by costs and limitations in the programming environment.

What is the unifying idea?

Unix has a couple of unifying ideas or metaphors that shape its APIs and the development
style that proceeds from them 鈥� the most important of these are probably the 鈥渆verything is a
file鈥� model and the pipe metaphor. In general, development style under any given operating
system is strongly conditioned by the unifying ideas baked into the system by its designers 鈥�
they percolate upwards into applications programming from the models provided by system
tools and APIs.

Accordingly, the most basic question to ask in contrasting Unix with another operating
system is: does it have unifying ideas that shape its development, and how do they differ from
Unix's?

To design the perfect anti-Unix: have no unifying idea at all, just an incoherent pile of ad-hoc
features.

Cooperating processes

In the Unix experience, inexpensive process-spawning and easy inter-process communication
(IPC) makes a whole ecology of small tools, pipes, and filters possible. We'll explore this
ecology in Chapter 6 (Multiprogramming); here, we need to point out some consequences of
expensive process-spawning and IPC.

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 鈥� an ordinary (non-root) user cannot alter or read another user's files without
permission. A third is the confinement of security-critical functions to the smallest possible
pieces of trusted code. Under Unix, even the shell (the system command interpreter) is not a
privileged program.

The strength of an operating system's internal boundaries is not merely an abstract issue of
design 鈥� it has important practical consequences for the security of the system.

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 鈥� out-of band data used (for example) to associate a document file with an application
that understands it. (The classic Unix way to handle these associations is to have applications
recognize 鈥榤agic numbers鈥�, or other type data in-band of the file.)

OS-level record structures are generally an optimization hack, and do little more than
complicate APIs and programmers' lives. They encourage the use of opaque record-oriented
file formats that generic tools like text editors cannot read properly.

File attributes can be useful, but (as we will see in Chapter 18 (Futures)) can raise some
awkward semantic issues in a world of byte-stream-oriented tools and pipes. When file
attributes are supported at the operating-system level, they predispose programmers to use
opaque formats and lean on the file attributes to tie them to the specific applications that
interpret them.

To design the perfect anti-Unix, have a cumbersome set of record structures that make it a hit-
or-miss proposition whether any given tool will be able to even read a file as the writer
intended it. Add file attributes and have the system depend on them heavily, so that the
semantics of a file will not be determinable by looking at its in-band data.

Binary file formats

If your operating system uses binary formats for critical data (such as user-account records) it
is likely that no tradition of readable textual formats for applications will develop. We explain
in more detail why this is a problem in Chapter 5 (Textuality). For now it's sufficient to note

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 鈥� because they can't be.
Outputs aren't conformable to inputs.
l
Remote system administration will be sparsely supported, more difficult to use, and
more network-intensive.
l
Even simple non-interactive programs will incur the overhead of a GUI or elaborate
scripting interface.
l
Servers, daemons, and background processes will probably be impossible or at least
rather difficult to program.


To design the perfect anti-Unix, have no CLI interface and no capability to script programs.

Who is the intended audience?