.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 matters
.AU
markus schnalke <meillo@marmaro.de>
.\" .AI
.\" .ce 0
.\" .fi
.\" Der Autor liebt Unix und dessen Skripting-Möglichkeiten.
.\" So auch den Shebang-Mechanismus der die Ausführung von Skripten deutlich erleichtert.
.AB
This term 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 use software leverage.
Knowing and following the tenets of the Unix Philosophy makes software more valuable.
.AE

.2C
.NH 1
Introduction
.LP
Building a software is a process from an idea of the purpose of the software
to the finished program.
No matter \fIhow\fP the process is run, two things are common:
the initial idea and the release.
But the the process inbetween can be of any shape.
The time of release and the maintainance work after the release are ignored here, for the moment.
.LP
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 \(en the design \(en of software.
The here discussed ideas may be applied to any development process.
Though the Unix Philosphy does recommend how the software development process should look like,
this shall not be of matter here.
Similar, the question of how to write the code is out of focus.
.LP





.[
%O .CW http://en.wikipedia.org/wiki/Unix_philosophy
.]

.NH 1
Importance of software design
.LP
why design at all

- for dev mainly: extendability and maintainability

- for users: usability and flexibility (but you need to learn how to use it)

no design and bad design limit the use of software

.NH 2
Architecture
.LP
the most important design decision.

the topic here

.NH 1
The Unix Philosophy

.NH 2
what it is
.LP
definitions by McIlroy, Gancarz, ESR (maybe already in the intro)
.LP
cf. unix tool chain
.LP
enabler pipe

.NH 2
Interface architecture
.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