| rev |
line source |
|
meillo@2
|
1 .\".if n .pl 1000i
|
|
meillo@0
|
2 .de XX
|
|
meillo@0
|
3 .pl 1v
|
|
meillo@0
|
4 ..
|
|
meillo@0
|
5 .em XX
|
|
meillo@1
|
6 .\".nr PI 0
|
|
meillo@1
|
7 .\".if t .nr PD .5v
|
|
meillo@1
|
8 .\".if n .nr PD 1v
|
|
meillo@0
|
9 .nr lu 0
|
|
meillo@0
|
10 .de CW
|
|
meillo@0
|
11 .nr PQ \\n(.f
|
|
meillo@0
|
12 .if t .ft CW
|
|
meillo@0
|
13 .ie \\$1 .if n .ul 999
|
|
meillo@0
|
14 .el .if n .ul 1
|
|
meillo@0
|
15 .if t .if !\\$1 \&\\$1\f\\n(PQ\\$2
|
|
meillo@0
|
16 .if n .if \\n(.$=1 \&\\$1
|
|
meillo@0
|
17 .if n .if \\n(.$>1 \&\\$1\c
|
|
meillo@0
|
18 .if n .if \\n(.$>1 \&\\$2
|
|
meillo@0
|
19 ..
|
|
meillo@0
|
20 .ds [. \ [
|
|
meillo@0
|
21 .ds .] ]
|
|
meillo@1
|
22 .\"----------------------------------------
|
|
meillo@0
|
23 .TL
|
|
meillo@0
|
24 Why the Unix Philosophy matters
|
|
meillo@0
|
25 .AU
|
|
meillo@0
|
26 markus schnalke <meillo@marmaro.de>
|
|
meillo@0
|
27 .AB
|
|
meillo@1
|
28 .ti \n(.iu
|
|
meillo@2
|
29 This paper discusses the importance of the Unix Philosophy in software design.
|
|
meillo@0
|
30 Today, few software designers are aware of these concepts,
|
|
meillo@0
|
31 and thus most modern software is limited and does not use software leverage.
|
|
meillo@0
|
32 Knowing and following the tenets of the Unix Philosophy makes software more valuable.
|
|
meillo@0
|
33 .AE
|
|
meillo@0
|
34
|
|
meillo@2
|
35 .if t .2C
|
|
meillo@2
|
36
|
|
meillo@2
|
37 .FS
|
|
meillo@2
|
38 .ps -1
|
|
meillo@2
|
39 This paper was prepared for the seminar ``Software Analysis'' at University Ulm.
|
|
meillo@2
|
40 Mentor was professor Schweiggert. 2010-02-05
|
|
meillo@2
|
41 .br
|
|
meillo@2
|
42 You may get this document from my website
|
|
meillo@2
|
43 .CW \s-1http://marmaro.de/docs
|
|
meillo@2
|
44 .FE
|
|
meillo@2
|
45
|
|
meillo@0
|
46 .NH 1
|
|
meillo@0
|
47 Introduction
|
|
meillo@0
|
48 .LP
|
|
meillo@0
|
49 Building a software is a process from an idea of the purpose of the software
|
|
meillo@0
|
50 to the finished program.
|
|
meillo@0
|
51 No matter \fIhow\fP the process is run, two things are common:
|
|
meillo@0
|
52 the initial idea and the release.
|
|
meillo@0
|
53 But the the process inbetween can be of any shape.
|
|
meillo@0
|
54 The time of release and the maintainance work after the release are ignored here, for the moment.
|
|
meillo@1
|
55 .PP
|
|
meillo@0
|
56 The process of building splits mainly in two parts:
|
|
meillo@0
|
57 the planning of what and how to build, and implementing the plan by writing code.
|
|
meillo@0
|
58 This paper focuses on the planning \(en the design \(en of software.
|
|
meillo@0
|
59 The here discussed ideas may be applied to any development process.
|
|
meillo@0
|
60 Though the Unix Philosphy does recommend how the software development process should look like,
|
|
meillo@0
|
61 this shall not be of matter here.
|
|
meillo@0
|
62 Similar, the question of how to write the code is out of focus.
|
|
meillo@1
|
63 .PP
|
|
meillo@1
|
64 This paper discusses the connection between software design and the Unix Philosphy.
|
|
meillo@1
|
65 Software design is the work between the requirements and the plan of how the internals and externals
|
|
meillo@1
|
66 of the software should look like.
|
|
meillo@1
|
67 However, the term ``Unix Philosophy'' was used but not explained yet.
|
|
meillo@1
|
68 .PP
|
|
meillo@1
|
69 The Unix Philosophy is the essence of how the Unix operating system and its toolchest was designed.
|
|
meillo@1
|
70 It is no limited set of rules, but what people see what is common to typical Unix software.
|
|
meillo@1
|
71 Several people stated their view on the Unix Philosophy.
|
|
meillo@1
|
72 Best known are:
|
|
meillo@1
|
73 .IP \(bu
|
|
meillo@1
|
74 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
|
|
meillo@1
|
75 .[
|
|
meillo@1
|
76 %A M. D. McIlroy
|
|
meillo@1
|
77 %A E. N. Pinson
|
|
meillo@1
|
78 %A B. A. Taque
|
|
meillo@1
|
79 %T UNIX Time-Sharing System Forward
|
|
meillo@1
|
80 %J The Bell System Technical Journal
|
|
meillo@1
|
81 %D 1978
|
|
meillo@1
|
82 %V 57
|
|
meillo@1
|
83 %N 6
|
|
meillo@1
|
84 %P 1902
|
|
meillo@1
|
85 .]
|
|
meillo@1
|
86 .IP \(bu
|
|
meillo@1
|
87 Mike Gancarz' book ``The UNIX Philosophy''.
|
|
meillo@1
|
88 .[
|
|
meillo@1
|
89 %A Mike Gancarz
|
|
meillo@1
|
90 %T The UNIX Philosophy
|
|
meillo@1
|
91 %D 1995
|
|
meillo@1
|
92 %I Digital Press
|
|
meillo@1
|
93 .]
|
|
meillo@1
|
94 .IP \(bu
|
|
meillo@1
|
95 Eric S. Raymond's book ``The Art of UNIX Programming''.
|
|
meillo@1
|
96 .[
|
|
meillo@1
|
97 %A Eric S. Raymond
|
|
meillo@1
|
98 %T The Art of UNIX Programming
|
|
meillo@1
|
99 %D 2003
|
|
meillo@1
|
100 %I Addison-Wesley
|
|
meillo@2
|
101 %O .CW \s-1http://www.faqs.org/docs/artu/
|
|
meillo@1
|
102 .]
|
|
meillo@0
|
103 .LP
|
|
meillo@1
|
104 These different views on the Unix Philosophy have much in common.
|
|
meillo@1
|
105 Especially, the main concepts are seen by all of them.
|
|
meillo@1
|
106 But there are also points on which they differ.
|
|
meillo@1
|
107 This only underlines what the Unix Philosophy is:
|
|
meillo@1
|
108 A retrospective view on the main concepts of Unix software;
|
|
meillo@1
|
109 especially those that were sucessful and unique to Unix.
|
|
meillo@1
|
110 .PP
|
|
meillo@1
|
111 Before we will have a look at concrete concepts,
|
|
meillo@1
|
112 we discuss why software design is important
|
|
meillo@1
|
113 and what problems bad design introduces.
|
|
meillo@0
|
114
|
|
meillo@0
|
115
|
|
meillo@0
|
116 .NH 1
|
|
meillo@0
|
117 Importance of software design
|
|
meillo@0
|
118 .LP
|
|
meillo@2
|
119 Why should we design software at all?
|
|
meillo@2
|
120 It should be general knowledge, that a bad plan is better than no plan.
|
|
meillo@2
|
121 As stated earlier in this document, the process of building a software
|
|
meillo@2
|
122 means going from an idea to a release.
|
|
meillo@2
|
123 The development process tells how to get from the idea to the release.
|
|
meillo@2
|
124 Software design tells how the built software should look like.
|
|
meillo@2
|
125 .PP
|
|
meillo@2
|
126 It is not enough that the released software offers all requested functionality.
|
|
meillo@2
|
127 It is a misbelief that only function matters.
|
|
meillo@2
|
128 Building a software the first time is only a small part of the overall work.
|
|
meillo@2
|
129 The larger part begins when the software is released for the first time
|
|
meillo@2
|
130 \(en maintainance and extending work..
|
|
meillo@2
|
131 This part soon covers more time than the time which was needed to build the software the first time.
|
|
meillo@2
|
132 .\" cf. brooks?
|
|
meillo@2
|
133 .PP
|
|
meillo@2
|
134 The extendability and maitainability of a software highly depends on its design.
|
|
meillo@2
|
135 Good design eases these tasks much.
|
|
meillo@2
|
136 Bad design, in contrast, requires much more effort for maintaining and
|
|
meillo@2
|
137 extending the software.
|
|
meillo@2
|
138 Developers should, for their own best, have maintainability and extendability in mind
|
|
meillo@2
|
139 when they design the software.
|
|
meillo@2
|
140 .PP
|
|
meillo@2
|
141 Users of the software do not care about maintainability and extendability,
|
|
meillo@2
|
142 at least not directly.
|
|
meillo@2
|
143 They care about usability and flexibility.
|
|
meillo@2
|
144 They want the software to directly solve their problems.
|
|
meillo@2
|
145 They want to be able to to use all its functions if they learned a few of them.
|
|
meillo@2
|
146 They want to use the software for similar tasks.
|
|
meillo@2
|
147 Software is successful if users enjoy using it.
|
|
meillo@2
|
148 Good software design can offer great flexibility and usability.
|
|
meillo@2
|
149 .PP
|
|
meillo@2
|
150 Good design matters for developers \fIand\fP for users.
|
|
meillo@2
|
151 Hence both groups should care about good software design.
|
|
meillo@2
|
152 Bad design limits the software in some way.
|
|
meillo@2
|
153 It may still provide all requested function, but it will have worse quality,
|
|
meillo@2
|
154 and thus require more work effort for developers or frustrate users.
|
|
meillo@2
|
155 .PP
|
|
meillo@2
|
156 Good software design is to the implementation like data structures are to algorithms
|
|
meillo@2
|
157 \(en if you get the former right, then you do not need to care about the latter,
|
|
meillo@2
|
158 it will simply go the right way.
|
|
meillo@2
|
159 .\" cf. ??? ``good data, bad algos''
|
|
meillo@0
|
160
|
|
meillo@0
|
161
|
|
meillo@0
|
162
|
|
meillo@0
|
163
|
|
meillo@0
|
164 .NH 1
|
|
meillo@0
|
165 The Unix Philosophy
|
|
meillo@0
|
166
|
|
meillo@0
|
167 .NH 2
|
|
meillo@0
|
168 what it is
|
|
meillo@0
|
169 .LP
|
|
meillo@0
|
170 definitions by McIlroy, Gancarz, ESR (maybe already in the intro)
|
|
meillo@0
|
171 .LP
|
|
meillo@0
|
172 cf. unix tool chain
|
|
meillo@0
|
173 .LP
|
|
meillo@0
|
174 enabler pipe
|
|
meillo@0
|
175
|
|
meillo@0
|
176 .NH 2
|
|
meillo@2
|
177 Architecture
|
|
meillo@2
|
178 .LP
|
|
meillo@2
|
179 the most important design decision.
|
|
meillo@2
|
180
|
|
meillo@2
|
181 the topic here
|
|
meillo@2
|
182
|
|
meillo@2
|
183 .NH 2
|
|
meillo@0
|
184 Interface architecture
|
|
meillo@0
|
185 .LP
|
|
meillo@0
|
186 standalone vs. tool chain
|
|
meillo@0
|
187 .LP
|
|
meillo@0
|
188 software leverage
|
|
meillo@0
|
189 .LP
|
|
meillo@0
|
190 possiblities
|
|
meillo@0
|
191
|
|
meillo@0
|
192 .NH 2
|
|
meillo@0
|
193 Results
|
|
meillo@0
|
194 .LP
|
|
meillo@0
|
195 The unix phil is an answer to the sw design question
|
|
meillo@0
|
196 .LP
|
|
meillo@0
|
197 tool chains empower the uses of sw
|
|
meillo@0
|
198
|
|
meillo@0
|
199 .NH 1
|
|
meillo@0
|
200 Case study: nmh
|
|
meillo@0
|
201
|
|
meillo@0
|
202 .NH 2
|
|
meillo@0
|
203 History
|
|
meillo@0
|
204 .LP
|
|
meillo@0
|
205 MH, nmh.
|
|
meillo@0
|
206 They are old.
|
|
meillo@0
|
207
|
|
meillo@0
|
208 .NH 2
|
|
meillo@0
|
209 Contrasts to similar sw
|
|
meillo@0
|
210 .LP
|
|
meillo@0
|
211 vs. Thunderbird, mutt, mailx, pine
|
|
meillo@0
|
212 .LP
|
|
meillo@0
|
213 flexibility, no redundancy, use the shell
|
|
meillo@0
|
214
|
|
meillo@0
|
215 .NH 2
|
|
meillo@0
|
216 Gains of the design
|
|
meillo@0
|
217 .LP
|
|
meillo@0
|
218
|
|
meillo@0
|
219 .NH 2
|
|
meillo@0
|
220 Problems
|
|
meillo@0
|
221 .LP
|
|
meillo@0
|
222
|
|
meillo@0
|
223 .NH 1
|
|
meillo@0
|
224 Case study: uzbl
|
|
meillo@0
|
225
|
|
meillo@0
|
226 .NH 2
|
|
meillo@0
|
227 History
|
|
meillo@0
|
228 .LP
|
|
meillo@0
|
229 uzbl is young
|
|
meillo@0
|
230
|
|
meillo@0
|
231 .NH 2
|
|
meillo@0
|
232 Contrasts to similar sw
|
|
meillo@0
|
233 .LP
|
|
meillo@0
|
234 like with nmh
|
|
meillo@0
|
235 .LP
|
|
meillo@0
|
236 addons, plugins, modules
|
|
meillo@0
|
237
|
|
meillo@0
|
238 .NH 2
|
|
meillo@0
|
239 Gains of the design
|
|
meillo@0
|
240 .LP
|
|
meillo@0
|
241
|
|
meillo@0
|
242 .NH 2
|
|
meillo@0
|
243 Problems
|
|
meillo@0
|
244 .LP
|
|
meillo@0
|
245 broken web
|
|
meillo@0
|
246
|
|
meillo@0
|
247 .NH 1
|
|
meillo@0
|
248 Final thoughts
|
|
meillo@0
|
249
|
|
meillo@0
|
250 .NH 2
|
|
meillo@0
|
251 Quick summary
|
|
meillo@0
|
252 .LP
|
|
meillo@0
|
253 good design
|
|
meillo@0
|
254 .LP
|
|
meillo@0
|
255 unix phil
|
|
meillo@0
|
256 .LP
|
|
meillo@0
|
257 case studies
|
|
meillo@0
|
258
|
|
meillo@0
|
259 .NH 2
|
|
meillo@0
|
260 Why people should choose
|
|
meillo@0
|
261 .LP
|
|
meillo@0
|
262 Make the right choice!
|
|
meillo@0
|
263
|
|
meillo@0
|
264 .nr PI .5i
|
|
meillo@0
|
265 .rm ]<
|
|
meillo@0
|
266 .de ]<
|
|
meillo@0
|
267 .LP
|
|
meillo@0
|
268 .de FP
|
|
meillo@0
|
269 .IP \\\\$1.
|
|
meillo@0
|
270 \\..
|
|
meillo@0
|
271 .rm FS FE
|
|
meillo@0
|
272 ..
|
|
meillo@0
|
273 .SH
|
|
meillo@0
|
274 References
|
|
meillo@0
|
275 .[
|
|
meillo@0
|
276 $LIST$
|
|
meillo@0
|
277 .]
|
|
meillo@0
|
278 .wh -1p
|
