docs/unix-phil
view unix-phil.ms @ 6:a6b837d822b7
rewrote ch02
| author | meillo@marmaro.de |
|---|---|
| date | Thu, 18 Feb 2010 11:24:36 +0100 |
| parents | 48f1f3465550 |
| children | 606f0ffca834 |
line source
1 .\".if n .pl 1000i
2 .de XX
3 .pl 1v
4 ..
5 .em XX
6 .\".nr PI 0
7 .\".if t .nr PD .5v
8 .\".if n .nr PD 1v
9 .nr lu 0
10 .de CW
11 .nr PQ \\n(.f
12 .if t .ft CW
13 .ie \\$1 .if n .ul 999
14 .el .if n .ul 1
15 .if t .if !\\$1 \&\\$1\f\\n(PQ\\$2
16 .if n .if \\n(.$=1 \&\\$1
17 .if n .if \\n(.$>1 \&\\$1\c
18 .if n .if \\n(.$>1 \&\\$2
19 ..
20 .ds [. \ [
21 .ds .] ]
22 .\"----------------------------------------
23 .TL
24 Why the Unix Philosophy still matters
25 .AU
26 markus schnalke <meillo@marmaro.de>
27 .AB
28 .ti \n(.iu
29 This paper discusses the importance of the Unix Philosophy in software design.
30 Today, few software designers are aware of these concepts,
31 and thus most modern software is limited and does not make use of software leverage.
32 Knowing and following the tenets of the Unix Philosophy makes software more valuable.
33 .AE
35 .if t .2C
37 .FS
38 .ps -1
39 This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
40 Mentor was professor Schweiggert. 2010-02-05
41 .br
42 You may get this document from my website
43 .CW \s-1http://marmaro.de/docs
44 .FE
46 .NH 1
47 Introduction
48 .LP
49 Building a software is a process from an idea of the purpose of the software
50 to its release.
51 No matter \fIhow\fP the process is run, two things are common:
52 the initial idea and the release.
53 The process inbetween can be of any shape.
54 The the maintainance work after the release is ignored for the moment.
55 .PP
56 The process of building splits mainly in two parts:
57 the planning of what and how to build, and implementing the plan by writing code.
58 This paper focuses on the planning part \(en the designing of the software.
59 .PP
60 Software design is the plan of how the internals and externals of the software should look like,
61 based on the requirements.
62 This paper discusses the recommendations of the Unix Philosphy about software design.
63 .PP
64 The here discussed ideas can get applied by any development process.
65 The Unix Philosphy does recommend how the software development process should look like,
66 but this shall not be of matter here.
67 Similar, the question of how to write the code is out of focus.
68 .PP
69 The name ``Unix Philosophy'' was already mentioned several times, but it was not explained yet.
70 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
71 It is no limited set of rules, but what people see to be common to typical Unix software.
72 Several people stated their view on the Unix Philosophy.
73 Best known are:
74 .IP \(bu
75 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
76 .[
77 %A M. D. McIlroy
78 %A E. N. Pinson
79 %A B. A. Taque
80 %T UNIX Time-Sharing System Forward
81 %J The Bell System Technical Journal
82 %D 1978
83 %V 57
84 %N 6
85 %P 1902
86 .]
87 .IP \(bu
88 Mike Gancarz' book ``The UNIX Philosophy''.
89 .[
90 %A Mike Gancarz
91 %T The UNIX Philosophy
92 %D 1995
93 %I Digital Press
94 .]
95 .IP \(bu
96 Eric S. Raymond's book ``The Art of UNIX Programming''.
97 .[
98 %A Eric S. Raymond
99 %T The Art of UNIX Programming
100 %D 2003
101 %I Addison-Wesley
102 %O .CW \s-1http://www.faqs.org/docs/artu/
103 .]
104 .LP
105 These different views on the Unix Philosophy have much in common.
106 Especially, the main concepts are similar for all of them.
107 But there are also points on which they differ.
108 This only underlines what the Unix Philosophy is:
109 A retrospective view on the main concepts of Unix software;
110 especially those that were sucessful and unique to Unix.
111 .\" really?
112 .PP
113 Before we will have a look at concrete concepts,
114 we discuss why software design is important
115 and what problems bad design introduces.
118 .NH 1
119 Importance of software design in general
120 .LP
121 Why should we design software at all?
122 It is general knowledge, that even a bad plan is better than no plan.
123 Ignoring software design is programming without a plan.
124 This will lead pretty sure to horrible results.
125 .PP
126 The design of a software is its internal and external shape.
127 The design talked about here has nothing to do with visual appearance.
128 If we see a program as a car, then its color is of no matter.
129 Its design would be the car's size, its shape, the number and position of doors,
130 the ratio of passenger and cargo transport, and so forth.
131 .PP
132 A software's design is about quality properties.
133 Each of the cars may be able to drive from A to B,
134 but it depends on its properties whether it is a good car for passenger transport or not.
135 It also depends on its properties if it is a good choice for a rough mountain area.
136 .PP
137 Requirements to a software are twofold: functional and non-functional.
138 Functional requirements are easier to define and to verify.
139 They are directly the software's functions.
140 Functional requirements are the reason why software gets written.
141 Someone has a problem and needs a tool to solve it.
142 Being able to solve the problem is the main functional requirement.
143 It is the driving force behind all programming effort.
144 .PP
145 On the other hand, there are also non-functional requirements.
146 They are called \fIquality\fP requirements, too.
147 The quality of a software is about properties that are not directly related to
148 the software's basic functions.
149 Quality aspects are about the properties that are overlooked at first sight.
150 .PP
151 Quality is of few matter when the software gets initially built,
152 but it will be of matter in usage and maintainance of the software.
153 A short-sighted might see in developing a software mainly building something up.
154 Reality shows, that building the software the first time is only a small amount
155 of the overall work.
156 Bug fixing, extending, rebuiling of parts \(en short: maintainance work \(en
157 does soon take over the major part of the time spent on a software.
158 Not to forget the usage of the software.
159 These processes are highly influenced by the software's quality.
160 Thus, quality should never be neglected.
161 The problem is that you hardly ``stumble over'' bad quality during the first build,
162 but this is the time when you should care about good quality most.
163 .PP
164 Software design is not about the basic function of a software;
165 this requirement will get satisfied anyway, as it is the main driving force behind the development.
166 Software design is about quality aspects of the software.
167 Good design will lead to good quality, bad design to bad quality.
168 The primary functions of the software will be affected modestly by bad quality,
169 but good quality can provide a lot of additional gain from the software,
170 even at places where one never expected it.
171 .PP
172 The ISO/IEC 9126-1 standard, part 1,
173 .[
174 %I International Organization for Standarization
175 %T ISO Standard 9126: Software Engineering \(en Product Quality, part 1
176 %C Geneve
177 %D 2001
178 .]
179 defines the quality model as consisting out of:
180 .IP \(bu
181 .I Functionality
182 (suitability, accuracy, inter\%operability, security)
183 .IP \(bu
184 .I Reliability
185 (maturity, fault tolerance, recoverability)
186 .IP \(bu
187 .I Usability
188 (understandability, learnability, operability, attractiveness)
189 .IP \(bu
190 .I Efficiency
191 (time behaviour, resource utilisation)
192 .IP \(bu
193 .I Maintainability
194 (analysability, changeability, stability, testability)
195 .IP \(bu
196 .I Portability
197 (adaptability, installability, co-existence, replaceability)
198 .LP
199 These goals are parts of a software's design.
200 Good design can give these properties to a software,
201 bad designed software will miss them.
204 .NH 1
205 The Unix Philosophy
206 .LP
207 The origins of the Unix Philosophy were already introduced.
208 This chapter explains the philosophy and shows concrete examples of its application.
210 .SH
211 Examples
212 .LP
213 Following are some examples to demonstrate how applied Unix Philosophy feels like.
214 Knowledge of using the Unix shell is assumed.
215 .PP
216 Counting the number of files in the current directory:
217 .DS
218 .CW
219 ls | wc -l
220 .DE
221 The
222 .CW ls
223 command lists all files in the current directory, one per line,
224 and
225 .CW "wc -l
226 counts how many lines they are.
227 .PP
228 Counting all files that do not contain ``foo'' in their name:
229 .DS
230 .CW
231 ls | grep -v foo | wc -l
232 .DE
233 Here, the list of files is filtered by
234 .CW grep
235 to remove all that contain ``foo''.
236 The rest is the same as in the previous example.
237 .PP
238 Finding the five largest entries in the current directory.
239 .DS
240 .CW
241 du -s * | sort -nr | sed 5q
242 .DE
243 .CW "du -s *
244 returns the recursively summed sizes of all files
245 -- no matter if they are regular files or directories.
246 .CW "sort -nr
247 sorts the list numerically in reverse order.
248 Finally,
249 .CW "sed 5q
250 quits after it has printed the fifth line.
251 .PP
252 The presented command lines are examples of what Unix people would use
253 to get the desired output.
254 There are also other ways to get the same output.
255 It's a user's decision which way to go.
257 .SH
258 Pipes
259 .LP
260 The examples show that a lot of tasks on a Unix system
261 are accomplished by combining several small programs.
262 The connection between the single programs is denoted by the pipe operator `|'.
263 .PP
264 Pipes, and their extensive and easy use, are one of the great
265 achievements of the Unix system.
266 Pipes between programs have been possible in earlier operating systems,
267 but it has never been a so central part of the concept.
268 When, in the early seventies, Doug McIlroy introduced pipes for the
269 Unix system,
270 ``it was this concept and notation for linking several programs together
271 that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
272 .[
273 %T Unix: An Oral History
274 %O .CW \s-1http://www.princeton.edu/~hos/frs122/unixhist/finalhis.htm
275 .]
276 .PP
277 Being able to specify pipelines in an easy way is,
278 however, not enough by itself.
279 It is only one half.
280 The other is the design of the programs that are used in the pipeline.
281 They have to be of an external shape that allows them to be be used in such a way.
283 .SH
284 Interface architecture
285 .LP
286 Unix is, first of all, simple: Everything is a file.
287 Files are sequences of bytes, without any special structure.
288 Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
289 and write a stream of bytes to ``standard output'' (stdout).
290 .PP
291 If our files \fIare\fP sequences of bytes,
292 and our programs \fIare\fP filters on byte streams,
293 then there is exactly one standardized interface.
294 Thus it is possible to combine them in any desired way.
295 .PP
296 Even a handful of small programs will yield a large set of combinations,
297 and thus a large set of different functions.
298 This is leverage!
299 .PP
300 If the programs are orthogonal to each other \(en the best case \(en
301 then the set of different functions is greatest.
302 .PP
303 Now, the Unix toolchest is a set of small programs that
304 are filters on byte streams.
305 They are to a large extend unrelated in their function.
306 Hence, the Unix toolchest provides a large set of functions
307 that can be accessed by combining the programs in the desired way.
309 .SH
310 Advantages of toolchests
311 .LP
312 A toolchest is a set of tools.
313 Instead of having one big tool for all tasks, one has many small tools,
314 each for one task.
315 Difficult tasks are solved by combining several of the small, simple tools.
316 .PP
317 It is easier and less error-prone to write small programs.
318 It is also easier and less error-prone to write a large set of small programs,
319 than to write one large program with all the functionality included.
320 If the small programs are combinable, then they offer even a larger set
321 of functions than the single large program.
322 Hence, one gets two advantages out of writing small, combinable programs.
323 .PP
324 There are two drawbacks of the toolchest approach.
325 First, one simple, standardized, unidirectional Interface has to be sufficient.
326 If one feels the need for more ``logic'' than a stream of bytes,
327 then a different approach might be of need, or, more likely,
328 he just did not came to a design where a stream of bytes is sufficient.
329 The other drawback of a toolchest affects the users.
330 A toolchest is often more difficult to use for novices.
331 It is neccessary to become familiar with each of the tools,
332 to be able to use the right one in a given situation.
333 Additinally, one needs to combine the tools in a senseful way on its own.
334 This is like a sharp knive \(en it is a powerful tool in the hand of a master,
335 but of no good value in the hand of an unskilled.
336 .PP
337 Luckily, the second drawback can be solved easily by adding wrappers around the single tools.
338 Novice users do not need to learn several tools if a professional wraps
339 the single commands into a single script.
340 Note that the wrapper script still calls the small tools;
341 the wrapper script is just like a skin around.
342 No complexity is added this way.
343 .PP
344 A wrapper script for finding the five largest entries in the current directory
345 could look like this:
346 .DS
347 .CW
348 #!/bin/sh
349 du -s * | sort -nr | sed 5q
350 .DE
351 The script itself is just a text file that calls the command line
352 a professional user would type in directly.
359 .NH 2
360 foo
361 .LP
362 standalone vs. tool chain
363 .LP
364 software leverage
365 .LP
366 possiblities
368 .NH 2
369 Results
370 .LP
371 The unix phil is an answer to the sw design question
372 .LP
373 tool chains empower the uses of sw
375 .NH 1
376 Case study: nmh
378 .NH 2
379 History
380 .LP
381 MH, nmh.
382 They are old.
384 .NH 2
385 Contrasts to similar sw
386 .LP
387 vs. Thunderbird, mutt, mailx, pine
388 .LP
389 flexibility, no redundancy, use the shell
391 .NH 2
392 Gains of the design
393 .LP
395 .NH 2
396 Problems
397 .LP
399 .NH 1
400 Case study: uzbl
402 .NH 2
403 History
404 .LP
405 uzbl is young
407 .NH 2
408 Contrasts to similar sw
409 .LP
410 like with nmh
411 .LP
412 addons, plugins, modules
414 .NH 2
415 Gains of the design
416 .LP
418 .NH 2
419 Problems
420 .LP
421 broken web
423 .NH 1
424 Final thoughts
426 .NH 2
427 Quick summary
428 .LP
429 good design
430 .LP
431 unix phil
432 .LP
433 case studies
435 .NH 2
436 Why people should choose
437 .LP
438 Make the right choice!
440 .nr PI .5i
441 .rm ]<
442 .de ]<
443 .LP
444 .de FP
445 .IP \\\\$1.
446 \\..
447 .rm FS FE
448 ..
449 .SH
450 References
451 .[
452 $LIST$
453 .]
454 .wh -1p