docs/unix-phil
view unix-phil-slides.ms @ 29:302daab2e8ee
Added tag cs talk version for changeset faff9ea75591
| author | meillo@marmaro.de |
|---|---|
| date | Sun, 14 Mar 2010 10:33:45 +0100 |
| parents | e8adc3571e8c |
| children |
line source
1 .TL
2 \fR\s-6Why\s0\fP
3 .br
4 the Unix Philosophy
5 .br
6 .vs -4
7 \fR\s-6still matters\s0\fP
8 .AU
9 .ft R
10 .sp 1.2i
11 .ps 11
12 markus schnalke <meillo@marmaro.de>
15 .S "Goals of this talk
16 .I
17 Introduce the Unix Phil
18 .I
19 Show that most modern software is crap
20 .I
21 Explain why the Unix Phil leads to good/better software
22 .I
23 Convince you that good software is of matter
24 .sp 2
25 .I
26 Make you think
29 .S "Roadmap
30 .I
31 Background
32 .I
33 What is the Unix Phil?
34 .I
35 The Unix Phil after Gancarz
36 .I
37 Real world examples
38 .I
39 Final thoughts
44 .P "Background
48 .S "How I met the Unix Phil
49 .LP
50 First contact through dwm (suckless project)
51 .LP
52 ``cat -v Considered Harmful''
53 .LP
54 ``The Unix and the Echo''
55 .LP
56 ``The Unix Programming Environment''
57 .LP
58 .sp 1
59 Better understanding through digging in the past
62 .S "Historical background
63 .LP
64 The late 60s and early 70s
65 .LP
66 Operating systems are complex
67 .LP
68 Brooks' ``The Mythical Man-Month''
69 .LP
70 MULTICS had just failed
71 .LP
72 A lot of different hardware
73 .LP
74 Limited computing power
75 .LP
76 Textual input and output (line printers)
79 .S "Everything is a file
80 .LP
81 Is the(?) basic concept in Unix (and even more in Plan9)
82 .LP
83 Made simple operating systems possible
84 .LP
85 It is not covered by the Unix Phil
86 .br
87 The Unix Phil is on a different level
88 .LP
89 .sp 2
90 Unix is mainly two things:
91 .I
92 An operating system (system calls)
93 .I
94 A toolchest (coreutils)
98 .P "What is the Unix Phil?
102 .S "What is the Unix Phil *itself*?
103 .LP
104 ``The Unix philosophy is a set of cultural norms and philosophical
105 approaches to developing software based on the experience of
106 leading developers of the Unix operating system.''
107 (wikipedia)
108 .sp 2
109 .LP
110 How the inventors of Unix write software.
111 .LP
112 Common things of classic Unix tools.
113 .sp 2
114 .LP
115 Difficult to define
118 .S "Unix Phil vs. SW dev processes
119 .LP
120 The Unix Phil
121 .I
122 much: *what* to program
123 .I
124 few: *how* to program
126 .LP
127 Software developments processes:
128 .I
129 few: *what* to program
130 .I
131 much: *how* to program
133 .sp 2
134 .LP
135 Extreme Programming is like the Unix Phil
136 but with more *how* than *what*,
137 and with formalisms
143 .S "What is the Unix Phil?
144 .I
145 Doug McIlroy (1978)
146 .I
147 Mike Gancarz: ``The Unix Philosophy'' (1994)
148 .I
149 Eric S. Raymond: ``The Art of Unix Programming'' (2003)
150 .sp 2
151 .I
152 Richard Gabriel: ``Worse is Better'' (1989)
155 .S "Doug McIlroy
156 .LP
157 This is the Unix philosophy:
158 .I
159 Write programs that do one thing and do it well.
160 .I
161 Write programs to work together.
162 .I
163 Write programs to handle text streams, because that is a universal interface.
166 .S "Mike Gancarz: ``The Unix Philosophy''
167 .I
168 Small is beautiful.
169 .I
170 Make each program do one thing well.
171 .I
172 Build a prototype as soon as possible.
173 .I
174 Choose portability over efficiency.
175 .I
176 Store data in flat text files.
177 .I
178 Use software leverage to your advantage.
179 .I
180 Use shell scripts to increase leverage and portability.
181 .I
182 Avoid captive user interfaces.
183 .I
184 Make every program a filter.
185 .sp 1
186 .LP
187 Plus ten lesser tenets
192 .P "The Unix Phil after Gancarz
196 .S "Small is beautiful
197 .LP
198 Small software is easier to understand, write, maintain
199 .LP
200 Less lines of code contain less bugs
201 .LP
202 Monsters are large
205 .S "Make each program do one thing well
206 .LP
207 Programs with many functions are large
208 .LP
209 One thing is easier to understand
210 .LP
211 Often straight forward to implement
212 .LP
213 Toolchests
214 .LP
215 Reusable
218 .S "Build a prototype as soon as possible
219 .LP
220 Shows the quality of the design
221 .LP
222 Shows the problems of the software
223 .LP
224 The best way to shape a software
225 .LP
226 Users find bugs
227 .LP
228 Incremental development
231 .S "Choose portability over efficiency
232 .LP
233 (Originates in a lot of incompatible hardware in history)
234 .LP
235 Use is most important
236 .LP
237 Availability
238 .LP
239 Only needs to be fast enough
242 .S "Store data in flat text files
243 .LP
244 (originally: ``Store numerical data in flat ASCII files'')
245 .LP
246 Binary data is machine-dependent
247 .LP
248 Human readable data is:
249 .I
250 As generic as possible
251 .I
252 Is very likely supported
253 .I
254 Many tools work on it (Unix toolchest)
255 .I
256 Directly editable by humans
257 .LP
258 Processing needs only to be fast enough
261 .S "Use software leverage to your advantage
262 .LP
263 What do we have computers for?
264 .LP
265 Make best use of computing power
266 .LP
267 Reduce development effort
268 .LP
269 Toolchests and a powerful shell
272 .S "Use shell scripts to increase leverage and portability
273 .LP
274 Was very important in history
275 .LP
276 High level languages
277 .LP
278 Prototyping
279 .LP
280 Quick hacks
281 .LP
282 Users are ``programmers''
285 .S "Avoid captive user interfaces
286 .LP
287 Don't assume the user to be human
288 .LP
289 Exclude the user whenever possible
290 .LP
291 Automate
292 .LP
293 How does it scale?
294 .LP
295 Bloat
298 .S "Make every program a filter
299 .LP
300 Programs transform data
301 .LP
302 Combine programs
303 .LP
304 Have one common interface
305 .LP
306 Toolchests
310 .P "real world examples
313 .S "find -printf
314 .LP
315 How to reformat the output of find(1) to have ``FILENAME PATH''
316 instead of ``PATH/FILENAME''?
317 .LP
318 The ``easy'' way:
319 \f(CWfind /dir -printf "%P %h\en"\fP
320 .LP
321 The ``good'' way:
322 .br
323 .CW "\s-1find /dir | sed 's,\e(.*\e)/\e(.*\e),\e2 \e1,'
324 .LP
325 The difference shows off when one wants, for instance,
326 the path to be manipulated further.
327 .LP
328 .sp 3
329 Source (in German):
330 .CW "\s-1http://debianforum.de/forum/viewtopic.php?t=117683
333 .S "Various
334 .LP
335 Who uses
336 .CW "grep -R
337 ?
338 .sp 1
339 .LP
340 .CW "cat -v
342 .sp 1
343 .LP
344 Pagers are taken for granted
346 .sp 1
347 .LP
348 What about the readline?
352 .S "MH / nmh
353 .LP
354 A Mail User Agent (MUA)
355 .LP
356 Is a toolchest
357 .LP
358 Work with mails like with generic files
359 .LP
360 The only(?) MUA that follows the Unix Phil
361 .LP
362 Has a very special feeling
365 .S "uzbl
366 .LP
367 A web browser that adheres to the Unix Phil
368 .LP
369 A young project (about 1 year)
370 .LP
371 Central question:
372 .br
373 What is the one task a web browser covers?
374 .LP
375 Makes very visible use of software leverage
376 .LP
377 Suffers hard from our broken web
383 .P "Final thoughts
386 .S "Say no
387 .LP
388 In today's computer world, following the Unix Phil means often asceticism
389 .LP
390 One needs to abjure a lot of ``nice'' features
391 .LP
392 Actually, it is abjuring the *bad* features
393 .LP
394 Leads to a valuable attitude, IMO
395 .LP
396 .sp 2
397 Transfer it to your everyday life
400 .S "Avoid complexity
401 .LP
402 Avoid complexity first and foremost
403 .LP
404 Complexity is the ``boss enemy'', software developers fight against
405 .LP
406 Strive for simplicity, clarity, generality
407 .LP
408 .sp 2
409 Transfer it to your everyday life
412 .S "Good solutions
413 .LP
414 We don't need just solutions, we need good ones
415 .LP
416 Today, we can make almost everything possible,
417 but we still cannot make it good
418 .LP
419 .sp 2
420 Transfer it to your everyday life
423 .S "Live it
424 .LP
425 The Unix Phil is more than just a few guidelines
426 .LP
427 You cannot follow only some of the tenets
428 .LP
429 To understand the Unix Phil, you need to engage with it
430 .LP
431 .sp 4
432 .ce
433 .B
434 It's a philosophy \(en live it!
440 .P "References
443 .S Literature
444 .I
445 ``\fBThe Unix Philosophy\fP''
446 by Mike Gancarz
447 .br
448 Go and get it!
449 .I
450 ``\fBThe Unix Programming Environment\fP''
451 by Kernighan and Pike
452 .br
453 A Bible for Unix-lovers.
454 .I
455 ``\fBThe Mythical Man-Month\fP''
456 and ``\fBNo Silver Bullet\fP''
457 by Fred Brooks
458 .br
459 About complexity in software development.
460 .I
461 ``\fBThe Practice of Programming\fP''
462 by Kernighan and Pike
463 .br
464 How good code should look like.
465 .I
466 ``\fBcat -v Considered Harmful\fP''
467 by Pike and Kernighan
468 .CW \s-2http://harmful.cat-v.org/cat-v/\s+2
469 .br
470 A must-read.
473 .S
474 .LP
475 This talk was prepared using tools of the Heirloom project:
476 .CW \s-2http://heirloom.sf.net\s+2
477 .LP
478 The slides macros are based on
479 .br
480 .CW \s-2http://repo.cat-v.org/troff-slider/\s+2
481 .sp
483 .LP
484 The slides are available on my website
485 .CW \s-2http://marmaro.de/docs\s+2
486 and on
487 .CW \s-2http://ulm.ccc.de/ChaosSeminar/\s+2
488 .sp
489 .LP
490 See my paper on the topic, too.
492 .sp 2
493 2010-03-08