.\".if n .pl 1000i
.de XX
.pl 1v
..
.em XX
.\".nr PI 0
.\".if t .nr PD .5v
.\".if n .nr PD 1v
.nr lu 0
.de CW
.nr PQ \\n(.f
.if t .ft CW
.ie \\$1 .if n .ul 999
.el .if n .ul 1
.if t .if !\\$1 \&\\$1\f\\n(PQ\\$2
.if n .if \\n(.$=1 \&\\$1
.if n .if \\n(.$>1 \&\\$1\c
.if n .if \\n(.$>1 \&\\$2
..
.ds [. \ [
.ds .] ]
.\"----------------------------------------
.TL
Why the Unix Philosophy still matters
.AU
markus schnalke <meillo@marmaro.de>
.AB
.ti \n(.iu
This paper discusses the importance of the Unix Philosophy in software design.
Today, few software designers are aware of these concepts,
and thus most modern software is limited and does not make use of software leverage.
Knowing and following the tenets of the Unix Philosophy makes software more valuable.
.AE

.if t .2C

.FS
.ps -1
This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
Mentor was professor Schweiggert. 2010-02-05
.br
You may get this document from my website
.CW \s-1http://marmaro.de/docs
.FE

.NH 1
Introduction
.LP
Building a software is a process from an idea of the purpose of the software
to its release.
No matter \fIhow\fP the process is run, two things are common:
the initial idea and the release.
The process inbetween can be of any shape.
The the maintainance work after the release is ignored for the moment.
.PP
The process of building splits mainly in two parts:
the planning of what and how to build, and implementing the plan by writing code.
This paper focuses on the planning part \(en the designing of the software.
.PP
Software design is the plan of how the internals and externals of the software should look like,
based on the requirements.
This paper discusses the recommendations of the Unix Philosphy about software design.
.PP
The here discussed ideas can get applied by any development process.
The Unix Philosphy does recommend how the software development process should look like,
but this shall not be of matter here.
Similar, the question of how to write the code is out of focus.
.PP
The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet.
The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
It is no limited set of rules, but what people see to be common to typical Unix software.
Several people stated their view on the Unix Philosophy.
Best known are:
.IP \(bu
Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
.[
%A M. D. McIlroy
%A E. N. Pinson
%A B. A. Taque
%T UNIX Time-Sharing System Forward
%J The Bell System Technical Journal
%D 1978
%V 57
%N 6
%P 1902
.]
.IP \(bu
Mike Gancarz' book ``The UNIX Philosophy''.
.[
%A Mike Gancarz
%T The UNIX Philosophy
%D 1995
%I Digital Press
.]
.IP \(bu
Eric S. Raymond's book ``The Art of UNIX Programming''.
.[
%A Eric S. Raymond
%T The Art of UNIX Programming
%D 2003
%I Addison-Wesley
%O .CW \s-1http://www.faqs.org/docs/artu/
.]
.LP
These different views on the Unix Philosophy have much in common.
Especially, the main concepts are similar for all of them.
But there are also points on which they differ.
This only underlines what the Unix Philosophy is:
A retrospective view on the main concepts of Unix software;
especially those that were sucessful and unique to Unix.
.\" really?
.PP
Before we will have a look at concrete concepts,
we discuss why software design is important
and what problems bad design introduces.


.NH 1
Importance of software design in general
.LP
Why should we design software at all?
It is general knowledge, that even a bad plan is better than no plan.
Ignoring software design is programming without a plan.
This will lead pretty sure to horrible results.
.PP
The design of a software is its internal and external shape.
The design talked about here has nothing to do with visual appearance.
If we see a program as a car, then its color is of no matter.
Its design would be the car's size, its shape, the number and position of doors,
the ratio of passenger and cargo transport, and so forth.
.PP
A software's design is about quality properties.
Each of the cars may be able to drive from A to B,
but it depends on its properties whether it is a good car for passenger transport or not.
It also depends on its properties if it is a good choice for a rough mountain area.
.PP
Requirements to a software are twofold: functional and non-functional.
Functional requirements are easier to define and to verify.
They are directly the software's functions.
Functional requirements are the reason why software gets written.
Someone has a problem and needs a tool to solve it.
Being able to solve the problem is the main functional requirement.
It is the driving force behind all programming effort.
.PP
On the other hand, there are also non-functional requirements.
They are called \fIquality\fP requirements, too.
The quality of a software is about properties that are not directly related to
the software's basic functions.
Quality aspects are about the properties that are overlooked at first sight.
.PP
Quality is of few matter when the software gets initially built,
but it will be of matter in usage and maintainance of the software.
A short-sighted might see in developing a software mainly building something up.
Reality shows, that building the software the first time is only a small amount
of the overall work.
Bug fixing, extending, rebuiling of parts \(en short: maintainance work \(en
does soon take over the major part of the time spent on a software.
Not to forget the usage of the software.
These processes are highly influenced by the software's quality.
Thus, quality should never be neglected.
The problem is that you hardly ``stumble over'' bad quality during the first build,
but this is the time when you should care about good quality most.
.PP
Software design is not about the basic function of a software;
this requirement will get satisfied anyway, as it is the main driving force behind the development.
Software design is about quality aspects of the software.
Good design will lead to good quality, bad design to bad quality.
The primary functions of the software will be affected modestly by bad quality,
but good quality can provide a lot of additional gain from the software,
even at places where one never expected it.
.PP
The ISO/IEC 9126-1 standard, part 1,
.[
%I International Organization for Standarization
%T ISO Standard 9126: Software Engineering \(en Product Quality, part 1
%C Geneve
%D 2001
.]
defines the quality model as consisting out of:
.IP \(bu
.I Functionality
(suitability, accuracy, inter\%operability, security)
.IP \(bu
.I Reliability
(maturity, fault tolerance, recoverability)
.IP \(bu
.I Usability
(understandability, learnability, operability, attractiveness)
.IP \(bu
.I Efficiency
(time behaviour, resource utilisation)
.IP \(bu
.I Maintainability
(analysability, changeability, stability, testability)
.IP \(bu
.I Portability
(adaptability, installability, co-existence, replaceability)
.LP
These goals are parts of a software's design.
Good design can give these properties to a software,
bad designed software will miss them.
.PP
One further goal of software design is consistency.
Consistency eases understanding, working on, and using things.
Consistent internals and consistent interfaces to the outside can be provided by good design.
.PP
We should design software because good design avoids many problems during a software's lifetime.
And we should design software because good design can offer much gain,
that can be unrelated to the software main intend.
Indeed, we should spend much effort into good design to make the software more valuable.
The Unix Philosophy shows how to design software well.
It offers guidelines to achieve good quality and high gain for the effort spent.


.NH 1
The Unix Philosophy
.LP
The origins of the Unix Philosophy were already introduced.
This chapter explains the philosophy and shows concrete examples of its application.

.SH
Examples
.LP
Following are some examples to demonstrate how applied Unix Philosophy feels like.
Knowledge of using the Unix shell is assumed.
.PP
Counting the number of files in the current directory:
.DS
.CW
ls | wc -l
.DE
The
.CW ls
command lists all files in the current directory, one per line,
and
.CW "wc -l
counts how many lines they are.
.PP
Counting all files that do not contain ``foo'' in their name:
.DS
.CW
ls | grep -v foo | wc -l
.DE
Here, the list of files is filtered by
.CW grep
to remove all that contain ``foo''.
The rest is the same as in the previous example.
.PP
Finding the five largest entries in the current directory.
.DS
.CW
du -s * | sort -nr | sed 5q
.DE
.CW "du -s *
returns the recursively summed sizes of all files
-- no matter if they are regular files or directories.
.CW "sort -nr
sorts the list numerically in reverse order.
Finally,
.CW "sed 5q
quits after it has printed the fifth line.
.PP
The presented command lines are examples of what Unix people would use
to get the desired output.
There are also other ways to get the same output.
It's a user's decision which way to go.

.SH
Pipes
.LP
The examples show that a lot of tasks on a Unix system
are accomplished by combining several small programs.
The connection between the single programs is denoted by the pipe operator `|'.
.PP
Pipes, and their extensive and easy use, are one of the great
achievements of the Unix system.
Pipes between programs have been possible in earlier operating systems,
but it has never been a so central part of the concept.
When, in the early seventies, Doug McIlroy introduced pipes for the
Unix system,
``it was this concept and notation for linking several programs together
that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
.[
%T Unix: An Oral History
%O .CW \s-1http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
.] 
.PP
Being able to specify pipelines in an easy way is,
however, not enough by itself.
It is only one half.
The other is the design of the programs that are used in the pipeline.
They have to be of an external shape that allows them to be be used in such a way.

.SH
Interface architecture
.LP
Unix is, first of all, simple: Everything is a file.
Files are sequences of bytes, without any special structure.
Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
and write a stream of bytes to ``standard output'' (stdout).
.PP
If our files \fIare\fP sequences of bytes,
and our programs \fIare\fP filters on byte streams,
then there is exactly one standardized interface.
Thus it is possible to combine them in any desired way.
.PP
Even a handful of small programs will yield a large set of combinations,
and thus a large set of different functions.
This is leverage!
.PP
If the programs are orthogonal to each other \(en the best case \(en
then the set of different functions is greatest.
.PP
Now, the Unix toolchest is a set of small programs that
are filters on byte streams.
They are to a large extend unrelated in their function.
Hence, the Unix toolchest provides a large set of functions
that can be accessed by combining the programs in the desired way.

.SH
Advantages of toolchests
.LP
A toolchest is a set of tools.
Instead of having one big tool for all tasks, one has many small tools,
each for one task.
Difficult tasks are solved by combining several of the small, simple tools.
.PP
It is easier and less error-prone to write small programs.
It is also easier and less error-prone to write a large set of small programs,
than to write one large program with all the functionality included.
If the small programs are combinable, then they offer even a larger set
of functions than the single large program.
Hence, one gets two advantages out of writing small, combinable programs.
.PP
There are two drawbacks of the toolchest approach.
First, one simple, standardized, unidirectional Interface has to be sufficient.
If one feels the need for more ``logic'' than a stream of bytes,
then a different approach might be of need, or, more likely,
he just did not came to a design where a stream of bytes is sufficient.
The other drawback of a toolchest affects the users.
A toolchest is often more difficult to use for novices.
It is neccessary to become familiar with each of the tools,
to be able to use the right one in a given situation.
Additinally, one needs to combine the tools in a senseful way on its own.
This is like a sharp knive \(en it is a powerful tool in the hand of a master,
but of no good value in the hand of an unskilled.
.PP
Luckily, the second drawback can be solved easily by adding wrappers around the single tools.
Novice users do not need to learn several tools if a professional wraps
the single commands into a single script.
Note that the wrapper script still calls the small tools;
the wrapper script is just like a skin around.
No complexity is added this way.
.PP
A wrapper script for finding the five largest entries in the current directory
could look like this:
.DS
.CW
#!/bin/sh
du -s * | sort -nr | sed 5q
.DE
The script itself is just a text file that calls the command line
a professional user would type in directly.






.NH 2
foo
.LP
standalone vs. tool chain
.LP
software leverage
.LP
possiblities

.NH 2
Results
.LP
The unix phil is an answer to the sw design question
.LP
tool chains empower the uses of sw

.NH 1
Case study: nmh

.NH 2
History
.LP
MH, nmh.
They are old.

.NH 2
Contrasts to similar sw
.LP
vs. Thunderbird, mutt, mailx, pine
.LP
flexibility, no redundancy, use the shell

.NH 2
Gains of the design
.LP

.NH 2
Problems
.LP

.NH 1
Case study: uzbl

.NH 2
History
.LP
uzbl is young

.NH 2
Contrasts to similar sw
.LP
like with nmh
.LP
addons, plugins, modules

.NH 2
Gains of the design
.LP

.NH 2
Problems
.LP
broken web

.NH 1
Final thoughts

.NH 2
Quick summary
.LP
good design
.LP
unix phil
.LP
case studies

.NH 2
Why people should choose
.LP
Make the right choice!

.nr PI .5i
.rm ]<
.de ]<
.LP
.de FP
.IP \\\\$1.
\\..
.rm FS FE
..
.SH
References
.[
$LIST$
.]
.wh -1p