The Art of Unix Programming

haoji

Problems in the environment of Unix

Prev Chapter 18. Futures

Next



Problems in the environment of Unix

The old-time Unix culture has largely reinvented itself in the open-source movement. Doing
so saved us from extinction, but it also means that the problems of open source are now ours
as well.

One of these is how to make open-source development economically sustainable. We have
reconnected with our roots in the collaborative, open process of Unix's early days. We have
largely won the technical argument for abandoning secrecy and proprietary control. We have
thought of ways to cooperate with markets and managers on more equal terms than we ever
could in the 1970s and 1980s, and in many ways our experiments have succeeded. In 2003
the open-source Unixes, and their core development groups, have achieved a degree of
mainstream respectability and authority that would have been unimaginable as recently as
the mid-1990s.

We have come a long way. But we have a long way to go yet. We know what business
models might work in theory, and now we can even point at a sporadic handful of successes
that demonstrate that they do work in practice; now we have to show that they can be made
to work reliably over a longer term.

One important sub-problem related to economic sustainability is how to organize end-user
testing. Historically, the Unix culture's concentration on infrastructure has meant that we
have not tended to build programs that depended for their value on providing a comfortable
interface for end-users. Now, especially in the open-source Unixes that aim to compete
directly with Microsoft and Apple, that is changing. But end-user interfaces need to be
systematically tested with real end users 鈥

haoji

These are economic problems. We have other problems of a more political nature, because
success makes enemies.

Some are familiar. Microsoft's ambition for an unchallengeable monopoly lock on computing
made the defeat of Unix a strategic goal for them in the mid-1980s five years before we
knew we were in a fight. In early 2003, despite having had several growth markets it was
counting on largely usurped by Linux, Microsoft is still the wealthiest and most powerful
software company in the world. Microsoft knows very well that it must defeat the new-
school Unixes of the open-source movement in order to survive. To defeat them, it must
destroy or discredit the culture that produced them.

Unix's comeback in the hands of the open-source community, and its association with the
freewheeling culture of the Internet, has made it newer enemies as well. Hollywood and Big
Media feel deeply threatened by the Internet and have launched a multi-pronged attack on
uncontrolled software development. Existing legislation like the Digital Millennium
Copyright Act has already been used to prosecute software developers who were doing
things the media moguls disliked. Contemplated schemes like the so-called Trusted
Computing Platform Alliance and Palladium threaten [69] to make open-source development
effectively illegal 鈥

haoji

Problems in the culture of Unix

Prev Chapter 18. Futures

Next



Problems in the culture of Unix

Just as important as the technical problems with Unix itself and the challenges consequent on
its success are the cultural problems of the community around it. There are at least two
serious ones; a lesser challenge of internal transition, and a greater one of of overcoming our
historical elitism.

The lesser challenge is that of friction between the old-school Unix gurus and the new-school
open-source crowd. The success of Linux, in particular, is not an entirely comfortable
phenomenon for a lot of older Unix programmers. This is partly a generational problem. The
raucous energy, na茂vete and gleeful zealotry of the Linux kids sometimes grates on elders
who have been around since the 1970s and (often rightly) consider themselves wiser. It's
only exacerbated by the fact that the kids are succeeding where the elders failed.

The greater problem of psychology only became clear to the author after spending three days
at a Macintosh developer conference in 2000. It was a very enlightening experience to be
immersed in a programming culture with assumptions diametrically opposed to those of the
Unix world.

Macintosh programmers are all about the user experience. They're architects and decorators.
They design from the outside in, asking first 鈥淲hat kind of interaction do we want to
support?鈥

haoji

don't understand how Unix people can live with it.

Both design philosophies have some validity, but the two camps have a great deal of
difficulty seeing each others' points. The typical Unix developer's reflex is to dismiss
Macintosh software as gaudy fluff, eye-candy for the ignorant, and to continue building
software that appeals to other Unix developers. If end-users don't like it, so much the worse
for the end-users; they will come around when they get a clue.

In many ways this kind of parochialism has served us well. We are the keepers of the
Internet and the World Wide Web. Our software and our traditions dominate serious
computing, the applications where 24/7 reliability and minimal downtime is a must. We
really are extremely good at building solid infrastructure; not perfect by any means, but there
is no other software technical culture that has anywhere close to our track record, and it is
one to be proud of.

The problem is that we increasingly face challenges that demand a more inclusive view.
Most of the computers in the world don't live in server rooms, but rather in the hands of those
end users. In early Unix days, before personal computers, our culture defined itself partly as
a revolt against the priesthood of the mainframes, the keepers of the big iron. Later, we
absorbed the power-to-the-people idealism of the early microcomputer enthusiasts. But today
we are the priesthood; we are the people who run the networks and the big iron. And our
implicit demand is that if you want to use our software, you must learn to think like us.

In 2003, there is a deep ambivalence in our attitude 鈥

haoji

served us so well 鈥

haoji

Reasons to believe

Prev Chapter 18. Futures

Next



Reasons to believe

The future of Unix is full of difficult problems. Would we truly want it any other way?

For more than thirty years we have thrived on challenges. We pioneered the best practices of
software engineering. We created today's Internet and Web. We have built the largest, most
complex, and most reliable software systems ever to exist. We outlasted the IBM monopoly
and we're making a run against Microsoft's that is good enough to deeply frighten them.

Not that everything has been triumph by any means. In the 1980s we nearly destroyed
ourselves by acceding to the proprietary capture of Unix. We neglected the low end, the
nontechnical end-users, for far too long and thereby left Microsoft an opening to grossly
lower the quality standards of software. Intelligent observers have pronounced our
technology, our community, and our values to be dead any number of times.

But always we have come storming back. We make mistakes. but we learn from our
mistakes. We have transmitted our culture across generations; we have absorbed much of
what was best from the early academic hackers and the ARPANET experimenters and the
microcomputer enthusiasts and a number of other cultures. The open-source movement has
resurrected the vigor and idealism of our early years, and today we are stronger and more
numerous than we have ever been.

So far, betting against the Unix hackers has always been short-term smart but long-term
stupid. We can prevail, if we choose to.

Prev Up Next

Problems in the culture of Unix

Home Appendix A. Glossary of
Abbreviations

haoji

Appendix A. Glossary of Abbreviations

Prev

Next



Appendix A. Glossary of Abbreviations

API
Application Programming Interface.The set of procedure calls that communicates
with a linkable procedure library or an operating-system kernel or the combination of
both.
BSD
Berkeley Systems Distribution. The generic name of the Unix distributions issued by
the Computer Science Research Group at the University of California at Berkeley
between 1976 and 1994, and of the open-source Unixes genetically descended from
them.
CLI
Command Line Interface. Considered archaic by some, but still very useful in the
Unix world.
CPAN
Comprehensive Perl Archive Network. The central Web repository for Perl modules
and extensions.
GNU
GNU's Not Unix! The recursive acronym for the Free Software Foundation's project
to produce an entire free-software clone of Unix. This effort didn't entirely succeed,
but did produce many of the essential tools of modern Unix development including
Emacs and the GNU Compiler Collection.
GUI

haoji

Graphical User Interface. The modern style of application interface using mice,
windows, and icons invented at XEROX PARC during the 1970s, as opposed to the
older CLI or roguelike styles.
IDE
Integrated Development envirinment. A GUI workbench for developing code,
pfeatyring facilities like symbolic debugging, version control, and data-structure
browsing. These are not commonly used under Unix, for reasons discussed in Chapter
13 (Tools)
IETF
Internet Engineering Task Force. The entity responsible for defining Internet
protocols such as TCP/IP. A loose, collegial organization mainly of technical people.
MIME
Multipurpose Internet Mail Extensions. A series of RFCs that describe standards for
embedding binary and multi-part messages within RFC-822 mail. Besides being used
for mail transport, MIME is used as an underlevel by important application protocols
including HTTP and BEEP.
OO
Object Oriented. A style of programming that tries to encapsulate data to be
manipulated and the code that manipulates it in (theoretically) sealed containers
called objects. By contrast, non-object-oriented programming is more casual about
exposing the internals of the data structure and code.
OS
Operating System. The foundation software of a machine; that which schedules tasks,
allocates storage, and presents a default interface to the user between applications.
The facilities an operating system provides and its general design philosophy exert an
extremely strong influence on programming style and on the technical cultures that
grow up around its host machines.
PDF

haoji

Portable Document Format. The PostScript language for control of printers and other
imaging devices is designed to be streamed to printers. PDF is a sequence of Postcript
pages, packaged with annotations so it can conveniently be used as a display format.
PDP-11
Programmable Data Processor 11. Possibly the single most successful minicomputer
design in history; first shipped in 1970, last shipped in 1990, and the immediate
ancestor of the VAX. The PDP-11 was the first major Unix platform.
PNG
Portable Network Graphics. The World Wide Web Consortium's standard and
recommended format for bit-map graphics images. An elegantly-designed binary
graphics format described in Chapter 5 (Textuality).
RFC
Request For Comment. An Internet standard. The name arose at a time when the
documents were regarded as proposals to be submitted to a then-nonexistent but
anticipated formal approval process of some sort. The formal approval process never
materialized.
RPC
Remote Procedure Call.Used of IPC methods that attempt to create the illusion that
the processes exchanging them are running in the same address space, so they can
cheaply (a) share complex structures, and (b) call each other like function libraries,
ignoring latency and other performance consideration. This illusion is notoriously
difficult to sustain.
TCP/IP
Tranmission Control Protocol/Internet Protocol. The basic protocol of the Internet
since the conversion from NCP in 1983. Provides reliable transport of data streams.
UDP/IP
Universal Datagram Protocol. Provides unreliable but low-latency transport for small
data packets.

haoji

UI
User Interface.
VAX
Formally, Virtual Address Extension.; the name of a classic minicomputer design
developed by Digital Equipment Corporation (later merged with Compaq, later
merged with Hewlett-Packard) from the PDP-11. The first VAX shipped in 1977. For
ten years after 1980 VAXen were among the most important Unix platforms.
Microprocessor reimplementations are still shipping today.


Prev Up Next

Reasons to believe

Home Appendix B. References