docs/unix-phil
view unix-phil.ms @ 56:7678e37ceffc
added presentation slides
| author | meillo@marmaro.de |
|---|---|
| date | Thu, 15 Apr 2010 23:04:07 +0200 |
| parents | 0a435d76b868 |
| children | 840cbc667009 |
line source
1 .so style
3 .TL
4 .ps +4
5 Why the Unix Philosophy still matters
6 .AU
7 markus schnalke <meillo@marmaro.de>
8 .AB
9 .ti \n(.iu
10 This paper explains the importance of the Unix Philosophy for software design.
11 Today, few software designers are aware of these concepts,
12 and thus a lot of modern software is more limited than necessary
13 and makes less use of software leverage than possible.
14 Knowing and following the guidelines of the Unix Philosophy makes software more valuable.
15 .AE
17 .FS
18 .ps -1
19 This paper was prepared for the ``Software Analysis'' seminar at University Ulm.
20 Mentor was professor Franz Schweiggert.
21 Handed in on 2010-04-16.
22 You may retrieve this document from
23 .CW \s-1http://marmaro.de/docs \ .
24 .FE
26 .H 1 Introduction
27 .LP
28 The Unix Philosophy is the essence of how the Unix operating system,
29 especially its toolchest, was designed.
30 It is no limited set of fixed rules,
31 but a loose set of guidelines which tell how to write software that
32 suites well into Unix.
33 Actually, the Unix Philosophy describes what is common to typical Unix software.
34 The Wikipedia has an accurate definition:
35 .[
36 wikipedia
37 unix philosophy
38 .]
39 .QP
40 The \fIUnix philosophy\fP is a set of cultural norms and philosophical
41 approaches to developing software based on the experience of leading
42 developers of the Unix operating system.
43 .PP
44 As there is no single definition of the Unix Philosophy,
45 several people have stated their view on what it comprises.
46 Best known are:
47 .IP \(bu
48 Doug McIlroy's summary: ``Write programs that do one thing and do it well.''
49 .[
50 mahoney
51 oral history
52 .]
53 .IP \(bu
54 Mike Gancarz' book ``The UNIX Philosophy''.
55 .[
56 gancarz
57 unix philosophy
58 .]
59 .IP \(bu
60 Eric S. Raymond's book ``The Art of UNIX Programming''.
61 .[
62 raymond
63 art of unix programming
64 .]
65 .LP
66 These different views on the Unix Philosophy have much in common.
67 Especially, the main concepts are similar in all of them.
68 McIlroy's definition can surely be called the core of the Unix Philosophy,
69 but the fundamental idea behind it all, is ``small is beautiful''.
71 .PP
72 The Unix Philosophy explains how to design good software for Unix.
73 Many concepts described here, base on facilities of Unix.
74 Other operating systems may not offer such facilities,
75 hence it may not be possible to design software in the way of the
76 Unix Philosophy for them.
77 .PP
78 The Unix Philosophy has an idea of how the process of software development
79 should look like, but large parts of the philosophy are quite independent
80 from a concrete development process.
81 However, one will soon recognize that some development processes work well
82 with the ideas of the Unix Philosophy and support them, while others are
83 at cross-purposes.
84 Kent Beck's books about Extreme Programming are valuable supplemental
85 resources on this topic.
86 .PP
87 The question of how to actually write code and how the code should looks
88 like in detail, are out of focus here.
89 ``The Practice of Programming'' by Kernighan and Pike,
90 .[
91 kernighan pike
92 practice of programming
93 .]
94 is a good book that covers this topic.
95 Its point of view matches to the one of this paper.
97 .H 1 "Importance of software design in general
98 .LP
99 Software design is the planning of how the internal structure
100 and external interfaces of software should look like.
101 It has nothing to do with visual appearance.
102 If we take a program as a car, then its color is of no matter.
103 Its design would be the car's size, its shape, the locations of doors,
104 the passenger/space ratio, the available controls and instruments,
105 and so forth.
106 .PP
107 Why should software get designed at all?
108 It is general knowledge, that even a bad plan is better than no plan.
109 Not designing software means programming without plan.
110 This will pretty sure lead to horrible results.
111 Software that is horrible to use and horrible to maintain.
112 These two aspects are the visible ones.
113 Often invisible though, are the wasted possible gains.
114 Good software design can make these gains available.
115 .PP
116 Software design deals with quality properties.
117 Good design leads to good quality, and quality is important.
118 Any car may be able to drive from A to B,
119 but it depends on the car's properties whether it is a good choice
120 for passenger transport or not.
121 It depends on its properties if it is a good choice
122 for a rough mountain area.
123 And it depends on its properties if the ride will be fun.
125 .PP
126 Requirements for software are twofold:
127 functional and non-functional.
128 .IP \(bu
129 Functional requirements define directly the software's functions.
130 They are the reason why software gets written.
131 Someone has a problem and needs a tool to solve it.
132 Being able to solve the problem is the main functional goal.
133 It is the driving force behind all programming effort.
134 Functional requirements are easier to define and to verify.
135 .IP \(bu
136 Non-functional requirements are called \fIquality\fP requirements, too.
137 The quality of software are the properties that are not directly related to
138 the software's basic functions.
139 Tools of bad quality often do solve the problems they were written for,
140 but introduce problems and difficulties for usage and development, later on.
141 Quality aspects are often overlooked at first sight,
142 and are often difficult to define clearly and to verify.
143 .PP
144 Quality is hardly interesting when software gets built initially,
145 but it has a high impact on usability and maintenance, later.
146 A short-sighted might see in developing software, mainly building something up.
147 But experience shows, that building software the first time is
148 only a small amount of the overall work.
149 Bug fixing, extending, rebuilding of parts \(en maintenance work \(en
150 does soon take over the major part of the time spent on a software project.
151 And of course, the time spent actually using the software.
152 These processes are highly influenced by the software's quality.
153 Thus, quality must not be neglected.
154 However, the problem with quality is that you hardly ``stumble over''
155 bad quality during the first build,
156 although this is the time when you should care about good quality most.
157 .PP
158 Software design has little to do with the basic function of software \(en
159 this requirement will get satisfied anyway.
160 Software design is more about quality aspects of software.
161 Good design leads to good quality, bad design to bad quality.
162 The primary functions of software will be affected modestly by bad quality,
163 but good quality can provide a lot of additional gain,
164 even at places where one never expected it.
165 .PP
166 The ISO/IEC\|9126-1 standard, part\|1,
167 .[
168 iso product quality
169 .]
170 defines the quality model as consisting out of:
171 .IP \(bu
172 .I Functionality
173 (suitability, accuracy, inter\%operability, security)
174 .IP \(bu
175 .I Reliability
176 (maturity, fault tolerance, recoverability)
177 .IP \(bu
178 .I Usability
179 (understandability, learnability, operability, attractiveness)
180 .IP \(bu
181 .I Efficiency
182 (time behavior, resource utilization)
183 .IP \(bu
184 .I Maintainability
185 (analyzability, changeability, stability, testability)
186 .IP \(bu
187 .I Portability
188 (adaptability, installability, co-existence, replaceability)
189 .LP
190 Good design can improve these properties of software,
191 bad designed software likely suffers in these points.
192 .PP
193 One further goal of software design is consistency.
194 Consistency eases understanding, working on, and using things.
195 Consistent internal structure and consistent interfaces to the outside
196 can be provided by good design.
197 .PP
198 Software should be well designed because good design avoids many
199 problems during a software project's lifetime.
200 And software should be well designed because good design can offer
201 much additional gain.
202 Indeed, much effort should be spent into good design to make software more valuable.
203 The Unix Philosophy shows a way of how to design software well.
204 It offers guidelines to achieve good quality and high gain for the effort spent.
207 .H 1 "The Unix Philosophy
208 .LP
209 The origins of the Unix Philosophy were already introduced.
210 This chapter explains the philosophy, oriented on Gancarz,
211 .[
212 gancarz
213 unix philosophy
214 .]
215 and shows concrete examples of its application.
217 .H 2 Pipes
218 .LP
219 Following are some examples to demonstrate how applied Unix Philosophy feels like.
220 Knowledge of using the Unix shell is assumed.
221 .PP
222 Counting the number of files in the current directory:
223 .DS
224 ls | wc -l
225 .DE
226 The
227 .CW ls
228 command lists all files in the current directory, one per line,
229 and
230 .CW "wc -l
231 counts the number of lines.
232 .PP
233 Counting the number of files that do not contain ``foo'' in their name:
234 .DS
235 ls | grep -v foo | wc -l
236 .DE
237 Here, the list of files is filtered by
238 .CW grep
239 to remove all lines that contain ``foo''.
240 The rest equals the previous example.
241 .PP
242 Finding the five largest entries in the current directory.
243 .DS
244 du -s * | sort -nr | sed 5q
245 .DE
246 .CW "du -s *
247 returns the recursively summed sizes of all files in the current directory
248 \(en no matter if they are regular files or directories.
249 .CW "sort -nr
250 sorts the list numerically in reverse order (descending).
251 Finally,
252 .CW "sed 5q
253 quits after it has printed the fifth line.
254 .PP
255 The presented command lines are examples of what Unix people would use
256 to get the desired output.
257 There are also other ways to get the same output.
258 It's a user's decision which way to go.
259 .PP
260 The examples show that many 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 into 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 aughenbaugh
274 unix oral history
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 need interfaces that allow them to be used in such a way.
283 .H 2 "Interface design
284 .LP
285 Unix is, first of all, simple \(en Everything is a file.
286 Files are sequences of bytes, without any special structure.
287 Programs should be filters, which read a stream of bytes from standard input (stdin)
288 and write a stream of bytes to standard output (stdout).
289 If the files \fIare\fP sequences of bytes,
290 and the programs \fIare\fP filters on byte streams,
291 then there is exactly one data interface.
292 Hence it is possible to combine programs in any desired way.
293 .PP
294 Even a handful of small programs yields a large set of combinations,
295 and thus a large set of different functions.
296 This is leverage!
297 If the programs are orthogonal to each other \(en the best case \(en
298 then the set of different functions is greatest.
299 .PP
300 Programs can also have a separate control interface,
301 besides their data interface.
302 The control interface is often called ``user interface'',
303 because it is usually designed to be used by humans.
304 The Unix Philosophy discourages to assume the user to be human.
305 Interactive use of software is slow use of software,
306 because the program waits for user input most of the time.
307 Interactive software requires the user to be in front of the computer.
308 Interactive software occupy the user's attention while they are running.
309 .PP
310 Now to come back to the idea of combining several small programs,
311 to have a more specific function.
312 If these single tools would all be interactive,
313 how would the user control them?
314 It is not only a problem to control several programs at once,
315 if they run at the same time,
316 it also very inefficient to have to control each of the single programs
317 that are intended to act as one large program.
318 Hence, the Unix Philosophy discourages programs to demand interactive use.
319 The behavior of programs should be defined at invocation.
320 This is done by specifying arguments to the program call
321 (command line switches).
322 Gancarz discusses this topic as ``avoid captive user interfaces''.
323 .[ [
324 gancarz unix philosophy
325 .], page 88 ff.]
326 .PP
327 Non-interactive use is, during development, also an advantage for testing.
328 Testing of interactive programs is much more complicated,
329 than testing of non-interactive programs.
331 .H 2 "The toolchest approach
332 .LP
333 A toolchest is a set of tools.
334 Instead of having one big tool for all tasks, one has many small tools,
335 each for one task.
336 Difficult tasks are solved by combining several of the small, simple tools.
337 .PP
338 The Unix toolchest \fIis\fP a set of small, (mostly) non-interactive programs
339 that are filters on byte streams.
340 They are, to a large extent, unrelated in their function.
341 Hence, the Unix toolchest provides a large set of functions
342 that can be accessed by combining the programs in the desired way.
343 .PP
344 There are also advantages for developing small toolchest programs.
345 It is easier and less error-prone to write small programs.
346 It is also easier and less error-prone to write a large set of small programs,
347 than to write one large program with all the functionality included.
348 If the small programs are combinable, then they offer even a larger set
349 of functions than the single large program.
350 Hence, one gets two advantages out of writing small, combinable programs:
351 They are easier to write and they offer a greater set of functions through
352 combination.
353 .PP
354 But there are also two main drawbacks of the toolchest approach.
355 First, one simple, standardized interface has to be sufficient.
356 If one feels the need for more ``logic'' than a stream of bytes,
357 then a different approach might be of need.
358 But it is also possible, that he just can not imagine a design where
359 a stream of bytes is sufficient.
360 By becoming more familiar with the ``Unix style of thinking'',
361 developers will more often and easier find simple designs where
362 a stream of bytes is a sufficient interface.
363 .PP
364 The second drawback of a toolchest affects the users.
365 A toolchest is often more difficult to use.
366 It is necessary to become familiar with each of the tools,
367 to be able to use the right one in a given situation.
368 Additionally, one needs to combine the tools in a sensible way himself.
369 This is like a sharp knife \(en it is a powerful tool in the hand of a
370 master, but of no good value in the hand of an unskilled.
371 However, learning single, small tools of a toolchest is easier than
372 learning a complex tool.
373 And the user will already have a basic understanding of a yet unknown tool,
374 if the tools of a toolchest have a common, consistent style.
375 He will be able to transfer knowledge over from one tool to another.
376 .PP
377 Moreover, the second drawback can be removed to a large extent
378 by adding wrappers around the basic tools.
379 Novice users do not need to learn several tools, if a professional wraps
380 complete command lines into a higher-level script.
381 Note that the wrapper script still calls the small tools;
382 it is just like a skin around them.
383 No complexity is added this way.
384 But new programs can get created out of existing one with very low effort.
385 .PP
386 A wrapper script for finding the five largest entries in the current directory
387 could look like this:
388 .DS
389 #!/bin/sh
390 du -s * | sort -nr | sed 5q
391 .DE
392 The script itself is just a text file that calls the command line,
393 which a professional user would type in directly.
394 It is probably worth to make the program flexible on the number of
395 entries it prints:
396 .DS
397 #!/bin/sh
398 num=5
399 [ $# -eq 1 ] && num="$1"
400 du -sh * | sort -nr | sed "${num}q"
401 .DE
402 This script acts like the one before, when called without an argument.
403 But one can also specify a numerical argument to define the number of lines to print.
404 One can surely imagine even more flexible versions, however,
405 they will still relay on the external programs,
406 which do the actual work.
408 .H 2 "A powerful shell
409 .LP
410 The Unix shell provides the possibility to combine small programs into large ones.
411 But a powerful shell is a great feature in other ways, too.
412 For instance by being scriptable.
413 Control statements are built into the shell.
414 The functions, however, are the normal programs of the system.
415 Thus, as the programs are already known,
416 learning to program in the shell becomes easy.
417 Using normal programs as functions in the shell programming language
418 is only possible because they are small and combinable tools in a toolchest style.
419 .PP
420 The Unix shell encourages to write small scripts,
421 by combining existing programs, because it is so easy to do.
422 This is a great step towards automation.
423 It is wonderful if the effort to automate a task equals the effort
424 to do the task a second time by hand.
425 If this holds,
426 then the user will be happy to automate everything he does more than once.
427 .PP
428 Small programs that do one job well, standardized interfaces between them,
429 a mechanism to combine parts to larger parts, and an easy way to automate tasks,
430 this will inevitably produce software leverage.
431 Getting multiple times the benefit of an investment is a great offer.
432 .PP
433 The shell also encourages rapid prototyping.
434 Many well known programs started as quickly hacked shell scripts,
435 and turned into ``real'' programs, written in C, later.
436 Building a prototype first, is a way to avoid the biggest problems
437 in application development.
438 Fred Brooks explains in ``No Silver Bullet'':
439 .[
440 brooks
441 no silver bullet
442 .]
443 .QP
444 The hardest single part of building a software system is deciding precisely what to build.
445 No other part of the conceptual work is so difficult as establishing the detailed
446 technical requirements, [...].
447 No other part of the work so cripples the resulting system if done wrong.
448 No other part is more difficult to rectify later.
449 .PP
450 Writing a prototype is a great method for becoming familiar with the requirements
451 and to run into real problems early.
452 .[ [
453 gancarz
454 unix philosophy
455 .], page 28 f.]
456 .PP
457 Prototyping is often seen as a first step in building software.
458 This is, of course, good.
459 However, the Unix Philosophy has an \fIadditional\fP perspective on prototyping:
460 After having built the prototype, one might notice, that the prototype is already
461 \fIgood enough\fP.
462 Hence, no reimplementation, in a more sophisticated programming language,
463 might be of need, at least for the moment.
464 Maybe later, it might be necessary to rewrite the software, but not now.
465 By delaying further work, one keeps the flexibility to react on
466 changing requirements.
467 Software parts that are not written will not miss the requirements.
469 .H 2 "Worse is better
470 .LP
471 The Unix Philosophy aims for the 90% solution;
472 others call it the ``Worse is better'' approach.
473 Experience from real life projects shows:
474 .PP
475 (1) It is almost never possible to define the
476 requirements completely and correctly the first time.
477 Hence one should not try to; one will fail anyway.
478 .PP
479 (2) Requirements change during time.
480 Hence it is best to delay requirement-based design decisions as long as possible.
481 Software should be small and flexible as long as possible
482 to react on changing requirements.
483 Shell scripts, for example, are more easily adjusted as C programs.
484 .PP
485 (3) Maintenance work is hard work.
486 Hence, one should keep the amount of code as small as possible;
487 it should just fulfill the \fIcurrent\fP requirements.
488 Software parts that will be written in future,
489 do not need maintenance till then.
490 .PP
491 See Brooks' ``The Mythical Man-Month'' for reference.
492 .[ [
493 brooks
494 mythical man-month
495 .], page 115 ff.]
496 .PP
497 Starting with a prototype in a scripting language has several advantages:
498 .IP \(bu
499 As the initial effort is low, one will likely start right away.
500 .IP \(bu
501 As working parts are available soon, the real requirements can get identified soon.
502 .IP \(bu
503 When software is usable and valuable, it gets used, and thus tested.
504 Hence problems will be found at early stages of the development.
505 .IP \(bu
506 The prototype might be enough for the moment,
507 thus further work can get delayed to a time
508 when one knows better about the requirements and problems,
509 than now.
510 .IP \(bu
511 Implementing now only the parts that are actually needed at the moment,
512 introduces fewer programming and maintenance work.
513 .IP \(bu
514 If the global situation changes so that the software is not needed anymore,
515 then less effort was spent into the project, than it would have be
516 when a different approach had been used.
518 .H 2 "Upgrowth and survival of software
519 .LP
520 So far it was talked about \fIwriting\fP or \fIbuilding\fP software.
521 Although these are just verbs, they do imply a specific view on the work process
522 they describe.
523 The better verb, however, is to \fIgrow\fP.
524 Creating software in the sense of the Unix Philosophy is an incremental process.
525 It starts with a first prototype, which evolves as requirements change.
526 A quickly hacked shell script might become a large, sophisticated,
527 compiled program this way.
528 Its lifetime begins with the initial prototype and ends when the software is not used anymore.
529 While being alive it will get extended, rearranged, rebuilt.
530 Growing software matches the view that ``software is never finished. It is only released.''
531 .[ [
532 gancarz
533 unix philosophy
534 .], page 26]
535 .PP
536 Software can be seen as being controlled by evolutionary processes.
537 Successful software is software that is used by many for a long time.
538 This implies that the software is needed, useful, and better than alternatives.
539 Darwin talks about: ``The survival of the fittest.''
540 .[
541 darwin
542 origin of species
543 .]
544 Transferred to software: The most successful software, is the fittest,
545 is the one that survives.
546 (This may be at the level of one creature, or at the level of one species.)
547 The fitness of software is affected mainly by four properties:
548 portability of code, portability of data, range of usability, and reusability of parts.
549 .PP
550 (1)
551 .I "Portability of code
552 means, using high-level programming languages,
553 sticking to the standard,
554 .[ [
555 kernighan pike
556 practice of programming
557 .], chapter\|8]
558 and avoiding optimizations that introduce dependencies on specific hardware.
559 Hardware has a much lower lifetime than software.
560 By chaining software to a specific hardware,
561 its lifetime gets shortened to that of this hardware.
562 In contrast, software should be easy to port \(en
563 adaptation is the key to success.
564 .PP
565 (2)
566 .I "Portability of data
567 is best achieved by avoiding binary representations
568 to store data, because binary representations differ from machine to machine.
569 Textual representation is favored.
570 Historically, \s-1ASCII\s0 was the charset of choice.
571 For the future, \s-1UTF\s0-8 might be the better choice.
572 Important is that it is a plain text representation in a
573 very common charset encoding.
574 Apart from being able to transfer data between machines,
575 readable data has the great advantage, that humans are able to directly
576 read and edit it with text editors and other tools from the Unix toolchest.
577 .[ [
578 gancarz
579 unix philosophy
580 .], page 56 ff.]
581 .PP
582 (3)
583 A large
584 .I "range of usability
585 ensures good adaptation, and thus good survival.
586 It is a special distinction if software becomes used in fields of action,
587 the original authors did never imagine.
588 Software that solves problems in a general way will likely be used
589 for many kinds of similar problems.
590 Being too specific limits the range of usability.
591 Requirements change through time, thus use cases change or even vanish.
592 As a good example in this point,
593 Allman identifies flexibility to be one major reason for sendmail's success:
594 .[
595 allman
596 sendmail
597 .]
598 .QP
599 Second, I limited myself to the routing function [...].
600 This was a departure from the dominant thought of the time, [...].
601 .QP
602 Third, the sendmail configuration file was flexible enough to adapt
603 to a rapidly changing world [...].
604 .LP
605 Successful software adapts itself to the changing world.
606 .PP
607 (4)
608 .I "Reuse of parts
609 is even one step further.
610 Software may completely lose its field of action,
611 but parts of which the software is built may be general and independent enough
612 to survive this death.
613 If software is built by combining small independent programs,
614 then these parts are readily available for reuse.
615 Who cares if the large program is a failure,
616 but parts of it become successful instead?
618 .H 2 "Summary
619 .LP
620 This chapter explained central ideas of the Unix Philosophy.
621 For each of the ideas, the advantages they introduce were explained.
622 The Unix Philosophy are guidelines that help to write more valuable software.
623 From the view point of a software developer or software designer,
624 the Unix Philosophy provides answers to many software design problem.
625 .PP
626 The various ideas of the Unix Philosophy are very interweaved
627 and can hardly be applied independently.
628 However, the probably most important messages are:
629 .I "``Keep it simple!''" ,
630 .I "``Do one thing well!''" ,
631 and
632 .I "``Use software leverage!''
636 .H 1 "Case study: \s-1MH\s0
637 .LP
638 The previous chapter introduced and explained the Unix Philosophy
639 from a general point of view.
640 The driving force were the guidelines; references to
641 existing software were given only sparsely.
642 In this and the next chapter, concrete software will be
643 the driving force in the discussion.
644 .PP
645 This first case study is about the mail user agents (\s-1MUA\s0)
646 \s-1MH\s0 (``mail handler'') and its descendant \fInmh\fP
647 (``new mail handler'').
648 .[
649 nmh website
650 .]
651 \s-1MUA\s0s provide functions to read, compose, and organize mail,
652 but (ideally) not to transfer it.
653 In this document, the name \s-1MH\s0 will be used to include nmh.
654 A distinction will only be made if differences between
655 \s-1MH\s0 and nmh are described.
658 .H 2 "Historical background
659 .LP
660 Electronic mail was available in Unix very early.
661 The first \s-1MUA\s0 on Unix was \f(CWmail\fP,
662 which was already present in the First Edition.
663 .[ [
664 salus
665 quarter century of unix
666 .], page 41 f.]
667 It was a small program that either printed the user's mailbox file
668 or appended text to someone else's mailbox file,
669 depending on the command line arguments.
670 .[
671 manual mail(1)
672 .]
673 It was a program that did one job well.
674 This job was emailing, which was very simple then.
675 .PP
676 Later, emailing became more powerful, and thus more complex.
677 The simple \f(CWmail\fP, which knew nothing of subjects,
678 independent handling of single messages,
679 and long-time email storage, was not powerful enough anymore.
680 In 1978 at Berkeley, Kurt Shoens wrote \fIMail\fP (with capital `M')
681 to provide additional functions for emailing.
682 Mail was still one program, but now it was large and did
683 several jobs.
684 Its user interface is modeled after the one of \fIed\fP.
685 It is designed for humans, but is still scriptable.
686 \fImailx\fP is the adaptation of Berkeley Mail into System V.
687 .[
688 ritter
689 mailx history
690 .]
691 Elm, pine, mutt, and a whole bunch of graphical \s-1MUA\s0s
692 followed Mail's direction.
693 They are large, monolithic programs which include all emailing functions.
694 .PP
695 A different way was taken by the people of \s-1RAND\s0 Corporation.
696 In the beginning, they also had used a monolithic mail system,
697 called \s-1MS\s0 (for ``mail system'').
698 But in 1977, Stockton Gaines and Norman Shapiro
699 came up with a proposal of a new email system concept \(en
700 one that honored the Unix Philosophy.
701 The concept was implemented by Bruce Borden in 1978 and 1979.
702 This was the birth of \s-1MH\s0 \(en the ``mail handler''.
703 .PP
704 Since then, \s-1RAND\s0, the University of California at Irvine and
705 at Berkeley, and several others have contributed to the software.
706 However, it's core concepts remained the same.
707 In the late 90s, when development of \s-1MH\s0 slowed down,
708 Richard Coleman started with \fInmh\fP, the new mail handler.
709 His goal was to improve \s-1MH\s0 especially in regard of
710 the requirements of modern emailing.
711 Today, nmh is developed by various people on the Internet.
712 .[
713 ware
714 rand history
715 .]
716 .[
717 peek
718 mh
719 .]
721 .H 2 "Contrasts to monolithic mail systems
722 .LP
723 All \s-1MUA\s0s are monolithic, except \s-1MH\s0.
724 Although there might actually exist further, very little known,
725 toolchest \s-1MUA\s0s, this statement reflects the situation pretty well.
726 .PP
727 Monolithic \s-1MUA\s0s gather all their functions in one program.
728 In contrast, \s-1MH\s0 is a toolchest of many small tools \(en one for each job.
729 Following is a list of important programs of \s-1MH\s0's toolchest
730 and their function.
731 It gives a feeling of how the toolchest looks like.
732 .IP \(bu
733 .CW inc :
734 incorporate new mail (this is how mail enters the system)
735 .IP \(bu
736 .CW scan :
737 list messages in folder
738 .IP \(bu
739 .CW show :
740 show message
741 .IP \(bu
742 .CW next\fR/\fPprev :
743 show next/previous message
744 .IP \(bu
745 .CW folder :
746 change current folder
747 .IP \(bu
748 .CW refile :
749 refile message into different folder
750 .IP \(bu
751 .CW rmm :
752 remove message
753 .IP \(bu
754 .CW comp :
755 compose new message
756 .IP \(bu
757 .CW repl :
758 reply to message
759 .IP \(bu
760 .CW forw :
761 forward message
762 .IP \(bu
763 .CW send :
764 send prepared message (this is how mail leaves the system)
765 .LP
766 \s-1MH\s0 has no special user interface like monolithic \s-1MUA\s0s have.
767 The user does not leave the shell to run \s-1MH\s0,
768 instead he uses the various \s-1MH\s0 programs within the shell.
769 Using a monolithic program with a captive user interface
770 means ``entering'' the program, using it, and ``exiting'' the program.
771 Using toolchests like \s-1MH\s0 means running programs,
772 alone or in combination with others, also from other toolchests,
773 without leaving the shell.
775 .H 2 "Data storage
776 .LP
777 \s-1MH\s0's mail storage is a directory tree under the user's
778 \s-1MH\s0 directory (usually \f(CW$HOME/Mail\fP),
779 where mail folders are directories and mail messages are text files
780 within them.
781 Each mail folder contains a file \f(CW.mh_sequences\fP which lists
782 the public message sequences of that folder,
783 for instance the \fIunseen\fP sequence for new messages.
784 Mail messages are text files located in a mail folder.
785 The files contain the messages as they were received.
786 They are named by ascending numbers in each folder.
787 .PP
788 This mailbox format is called ``\s-1MH\s0'' after the \s-1MUA\s0.
789 Alternatives are \fImbox\fP and \fImaildir\fP.
790 In the mbox format all messages are stored within one file.
791 This was a good solution in the early days, when messages
792 were only a few lines of text and were deleted soon.
793 Today, when single messages often include several megabytes
794 of attachments, it is a bad solution.
795 Another disadvantage of the mbox format is that it is
796 more difficult to write tools that work on mail messages,
797 because it is always necessary to first find and extract
798 the relevant message in the mbox file.
799 With the \s-1MH\s0 mailbox format, each message is a separate file.
800 Also, the problem of concurrent access to one mailbox is
801 reduced to the problem of concurrent access to one message.
802 The maildir format is generally similar to the \s-1MH\s0 format,
803 but modified towards guaranteed reliability.
804 This involves some complexity, unfortunately.
805 .PP
806 Working with \s-1MH\s0's toolchest on mailboxes is much like
807 working with Unix' toolchest on directory trees:
808 \f(CWscan\fP is like \f(CWls\fP,
809 \f(CWshow\fP is like \f(CWcat\fP,
810 \f(CWfolder\fP is like \f(CWcd\fP and \f(CWpwd\fP,
811 \f(CWrefile\fP is like \f(CWmv\fP,
812 and \f(CWrmm\fP is like \f(CWrm\fP.
813 .PP
814 \s-1MH\s0 extends the context of processes in Unix by two more items,
815 for its tools:
816 .IP \(bu
817 The current mail folder, which is similar to the current working directory.
818 For mail folders, \f(CWfolder\fP provides the corresponding functionality
819 of \f(CWcd\fP and \f(CWpwd\fP for directories.
820 .IP \(bu
821 Sequences, which are named sets of messages in a mail folder.
822 The current message, relative to a mail folder, is a special sequence.
823 It enables commands like \f(CWnext\fP and \f(CWprev\fP.
824 .LP
825 In contrast to Unix' context, which is maintained by the kernel,
826 \s-1MH\s0's context must be maintained by the tools themselves.
827 Usually there is one context per user, which resides in his
828 \f(CWcontext\fP file in the \s-1MH\s0 directory,
829 but a user can have several contexts, too.
830 Public sequences are an exception, as they belong to a mail folder,
831 and reside in the \f(CW.mh_sequences\fP file there.
832 .[
833 man page mh-profile mh-sequence
834 .]
836 .H 2 "Discussion of the design
837 .LP
838 This section discusses \s-1MH\s0 in regard to the tenets
839 of the Unix Philosophy that Gancarz identified.
841 .PP
842 .B "Small is beautiful
843 and
844 .B "do one thing well
845 are two design goals that are directly visible in \s-1MH\s0.
846 Gancarz actually presents \s-1MH\s0 in his book as example under the
847 headline ``Making \s-1UNIX\s0 Do One Thing Well'':
848 .[ [
849 gancarz
850 unix philosophy
851 .], page 125 ff.]
852 .QP
853 [\s-1MH\s0] consists of a series of programs which
854 when combined give the user an enormous ability
855 to manipulate electronic mail messages.
856 A complex application, it shows that not only is it
857 possible to build large applications from smaller
858 components, but also that such designs are actually preferable.
859 .LP
860 The various programs of \s-1MH\s0 were relatively easy to write,
861 because each of them is small, limited to one function,
862 and has clear boundaries.
863 For the same reasons, they are also good to maintain.
864 Further more, the system can easily get extended.
865 One only needs to put a new program into the toolchest.
866 This was done, for instance, when \s-1MIME\s0 support was added
867 (e.g. \f(CWmhbuild\fP).
868 Also, different programs can exist to do the basically same job
869 in different ways (e.g. in nmh: \f(CWshow\fP and \f(CWmhshow\fP).
870 .PP
871 If someone needs a mail system with some additionally
872 functions that are not available anywhere yet, he best expands a
873 toolchest system like \s-1MH\s0.
874 There he can add new functionality by simply adding additional
875 programs to the toolchest.
876 There he does not risk to break existing functionality by doing so.
878 .PP
879 .B "Store data in flat text files
880 is followed by \s-1MH\s0.
881 This is not surprising, because email messages are already plain text.
882 \s-1MH\s0 stores the messages as it receives them,
883 thus any other tool that works on \s-1RFC\s0\|2822 mail messages can operate
884 on the messages in an \s-1MH\s0 mailbox.
885 All other files \s-1MH\s0 uses are plain text, too.
886 It is therefore possible and encouraged to use the text processing
887 tools of Unix' toolchest to extend \s-1MH\s0's toolchest.
889 .PP
890 .B "Avoid captive user interfaces" .
891 \s-1MH\s0 is perfectly suited for non-interactive use.
892 It offers all functions directly and without captive user interfaces.
893 If, nonetheless, users want a graphical user interface,
894 they can have it with \fIxmh\fP, \fIexmh\fP,
895 or with the Emacs interface \fImh-e\fP.
896 These are frontends for the \s-1MH\s0 toolchest.
897 This means, all email-related work is still done by \s-1MH\s0 tools,
898 but the frontend calls the appropriate commands when the user
899 clicks on buttons or pushes a key.
900 .PP
901 Providing easy-to-use user interfaces in form of frontends is a good
902 approach, because it does not limit the power of the backend itself.
903 The frontend will anyway only be able to make a subset of the
904 backend's power and flexibility available to the user.
905 But if it is a separate program,
906 then the missing parts can still be accessed at the backend directly.
907 If it is integrated, then this will hardly be possible.
908 An additional advantage is the possibility to have different frontends
909 to the same backend.
911 .PP
912 .B "Choose portability over efficiency
913 and
914 .B "use shell scripts to increase leverage and portability" .
915 These two tenets are indirectly, but nicely, demonstrated by
916 Bolsky and Korn in their book about the Korn Shell.
917 .[
918 bolsky korn
919 korn shell
920 .]
921 Chapter\|18 of the book shows a basic implementation
922 of a subset of \s-1MH\s0 in ksh scripts.
923 Of course, this is just a demonstration, but a brilliant one.
924 It shows how quickly one can implement such a prototype with shell scripts,
925 and how readable they are.
926 The implementation in the scripting language may not be very fast,
927 but it can be fast enough though, and this is all that matters.
928 By having the code in an interpreted language, like the shell,
929 portability becomes a minor issue, if we assume the interpreter
930 to be widespread.
931 .PP
932 This demonstration also shows how easy it is to create single programs
933 of a toolchest software.
934 Eight tools (two of them have multiple names) and 16 functions
935 with supporting code are presented to the reader.
936 The tools comprise less than 40 lines of ksh each,
937 in total about 200 lines.
938 The functions comprise less than 80 lines of ksh each,
939 in total about 450 lines.
940 Such small software is easy to write, easy to understand,
941 and thus easy to maintain.
942 A toolchest improves the possibility to only write some parts
943 and though create a working result.
944 Expanding the toolchest, even without global changes,
945 will likely be possible.
947 .PP
948 .B "Use software leverage to your advantage
949 and the lesser tenet
950 .B "allow the user to tailor the environment
951 are ideally followed in the design of \s-1MH\s0.
952 Tailoring the environment is heavily encouraged by the ability to
953 directly define default options to programs.
954 It is even possible to define different default options
955 depending on the name under which a program is called.
956 Software leverage is heavily encouraged by the ease of
957 creating shell scripts that run a specific command line,
958 built of several \s-1MH\s0 programs.
959 There is few software that so much wants users to tailor their
960 environment and to leverage the use of the software, like \s-1MH\s0.
961 .PP
962 Just to make one example:
963 One might prefer a different listing format for the \f(CWscan\fP
964 program.
965 It is possible to take one of the distributed format files
966 or to write one yourself.
967 To use the format as default for \f(CWscan\fP, a single line,
968 reading
969 .DS
970 scan: -form FORMATFILE
971 .DE
972 must be added to \f(CW.mh_profile\fP.
973 If one wants this different format as an additional command,
974 instead of changing the default, he needs to create a link to
975 \f(CWscan\fP, for instance titled \f(CWscan2\fP.
976 The line in \f(CW.mh_profile\fP would then start with \f(CWscan2\fP,
977 as the option should only be in effect for a program that is called as
978 \f(CWscan2\fP.
980 .PP
981 .B "Make every program a filter
982 is hard to find in \s-1MH\s0.
983 The reason therefore is that most of \s-1MH\s0's tools provide
984 basic file system operations for mailboxes.
985 It is the same reason because of which \f(CWls\fP, \f(CWcp\fP, \f(CWmv\fP,
986 and \f(CWrm\fP aren't filters neither.
987 \s-1MH\s0 does not provide many filters itself, but it is a basis
988 to write filters for.
989 An example would be a mail text highlighter,
990 that means a program that makes use of a color terminal to display
991 header lines, quotations, and signatures in distinct colors.
992 The author's version of such a program is an awk script with 25 lines.
994 .PP
995 .B "Build a prototype as soon as possible
996 was again well followed by \s-1MH\s0.
997 This tenet, of course, focuses on early development, which is
998 long time ago for \s-1MH\s0.
999 But without following this guideline at the very beginning,
1000 Bruce Borden may have not convinced the management of \s-1RAND\s0
1001 to ever create \s-1MH\s0.
1002 In Bruce' own words:
1003 .[ [
1004 ware rand history
1005 .], page 132]
1006 .QP
1007 [...] but [Stockton Gaines and Norm Shapiro] were not able
1008 to convince anyone that such a system would be fast enough to be usable.
1009 I proposed a very short project to prove the basic concepts,
1010 and my management agreed.
1011 Looking back, I realize that I had been very lucky with my first design.
1012 Without nearly enough design work,
1013 I built a working environment and some header files
1014 with key structures and wrote the first few \s-1MH\s0 commands:
1015 inc, show/next/prev, and comp.
1016 [...]
1017 With these three, I was able to convince people that the structure was viable.
1018 This took about three weeks.
1020 .H 2 "Problems
1021 .LP
1022 \s-1MH\s0 is not without problems.
1023 There are two main problems: one is technical, the other is about human behavior.
1024 .PP
1025 \s-1MH\s0 is old and email today is very different to email in the time
1026 when \s-1MH\s0 was designed.
1027 \s-1MH\s0 adapted to the changes pretty well, but it is limited, though.
1028 \s-1MIME\s0 support and support for different character encodings
1029 is available, but only on a moderate level.
1030 This comes from limited development resources.
1031 More active developers could quickly change this.
1032 But \s-1MH\s0 is also limited by design, which is the larger problem.
1033 \s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extent.
1034 These design conflicts are not easily solvable.
1035 Possibly, they require a redesign.
1036 \s-1IMAP\s0 may be too different to the classic mail model,
1037 which \s-1MH\s0 covers, so that \s-1MH\s0 may never support it well.
1038 .PP
1039 The other kind of problem are human habits.
1040 In this world, where almost all \s-1MUA\s0s are monolithic,
1041 it is very difficult to convince people to use a toolbox style \s-1MUA\s0
1042 like \s-1MH\s0.
1043 The habits are so strong, that even people who understand the concept
1044 and advantages of \s-1MH\s0 do not like to switch,
1045 simply because \s-1MH\s0 is different.
1046 Unfortunately, the frontends to \s-1MH\s0, which could provide familiar look'n'feel,
1047 are quite outdated and thus not very appealing, compared to the modern interfaces
1048 of many monolithic \s-1MUA\s0s.
1049 One notable exception is \fImh-e\fP which provides an Emacs interface
1050 to \s-1MH\s0.
1051 \fIMh-e\fP looks much like \fImutt\fP or \fIpine\fP,
1052 but it has buttons, menus, and graphical display capabilities.
1054 .H 2 "Summary
1055 .LP
1056 \s-1MH\s0 is an \s-1MUA\s0 that follows the Unix Philosophy in its design.
1057 It consists of a toolchest of small tools, each of them does one job well.
1058 The toolchest approach offers great flexibility to the user.
1059 It is possible to utilize the complete power of the Unix shell with \s-1MH\s0.
1060 This makes \s-1MH\s0 a very powerful mail system.
1061 Extending and customizing \s-1MH\s0 is easy and encouraged.
1062 .PP
1063 Apart from the user's perspective, \s-1MH\s0 is development-friendly.
1064 Its overall design follows clear rules.
1065 The single tools do only one job, thus they are easy to understand,
1066 easy to write, and good to maintain.
1067 They are all independent and do not interfere with the others.
1068 Automated testing of their function is a straight forward task.
1069 .PP
1070 It is sad, that \s-1MH\s0's differentness is its largest problem,
1071 as its differentness is also its largest advantage.
1072 Unfortunately, for most people their habits are stronger
1073 than the attraction of the clear design and the power, \s-1MH\s0 offers.
1077 .H 1 "Case study: uzbl
1078 .LP
1079 The last chapter took a look on the \s-1MUA\s0 \s-1MH\s0,
1080 which is an old and established software.
1081 This chapter covers uzbl, a fresh new project.
1082 Uzbl is a web browser that adheres to the Unix Philosophy.
1083 Its name comes from the \fILolspeak\fP word for ``usable'';
1084 it is pronounced identical.
1086 .H 2 "Historical background
1087 .LP
1088 Uzbl was started by Dieter Plaetinck in April 2009.
1089 The idea was born in a thread in the Arch Linux Forums.
1090 .[
1091 arch linux forums
1092 browser
1093 .]
1094 After some discussion about failures of well known web browsers,
1095 Plaetinck (alias Dieter@be) came up with a very sketchy proposal
1096 of how a better web browser could look like.
1097 To the question of another member, if Plaetinck would write that program,
1098 because it would sound fantastic, Plaetinck replied:
1099 ``Maybe, if I find the time ;-)''.
1100 .PP
1101 Fortunately, he found the time.
1102 One day later, the first prototype was out.
1103 One week later, uzbl had an own website.
1104 .[
1105 uzbl website
1106 .]
1107 One month after the first code showed up,
1108 a mailing list was installed to coordinate and discuss further development,
1109 and a wiki was added to store documentation and scripts that showed up on the
1110 mailing list and elsewhere.
1111 .PP
1112 In the, now, one year of uzbl's existence, it was heavily developed on various branches.
1113 Plaetinck's task became more and more to only merge the best code from the
1114 different branches into his main branch, and to apply patches.
1115 .[
1116 lwn uzbl
1117 .]
1118 About once a month, Plaetinck released a new version.
1119 In September 2009, he presented several forks of uzbl.
1120 .[ [
1121 uzbl website
1122 .], news archive]
1123 Uzbl, actually, opened the field for a whole family of web browsers with similar shape.
1124 .PP
1125 In July 2009, \fILinux Weekly News\fP published an interview with Plaetinck about uzbl.
1126 .[
1127 lwn uzbl
1128 .]
1129 In September 2009, the uzbl web browser was on \fISlashdot\fP.
1130 .[
1131 slashdot uzbl
1132 .]
1134 .H 2 "Contrasts to other web browsers
1135 .LP
1136 Like most \s-1MUA\s0s are monolithic, but \s-1MH\s0 is a toolchest,
1137 most web browsers are monolithic, but uzbl is a frontend to a toolchest.
1138 .PP
1139 Today, uzbl is divided into uzbl-core and uzbl-browser.
1140 Uzbl-core is, how its name already indicates, the core of uzbl.
1141 It handles commands and events to interface other programs,
1142 and also displays webpages by using \fIwebkit\fP as render engine.
1143 Uzbl-browser combines uzbl-core with a bunch of handler scripts, a status bar,
1144 an event manager, yanking, pasting, page searching, zooming, and more stuff,
1145 to form a ``complete'' web browser.
1146 In the following text, the term ``uzbl'' usually stands for uzbl-browser,
1147 so uzbl-core is included.
1148 .PP
1149 Unlike most other web browsers, uzbl is mainly the mediator between the
1150 various tools that cover single jobs.
1151 Therefore, uzbl listens for commands on a named pipe (fifo), a Unix socket,
1152 and on stdin, and it writes events to a Unix socket and to stdout.
1153 Loading a webpage in a running uzbl instance requires only:
1154 .DS
1155 echo 'uri http://example.org' >/path/to/uzbl-fifo
1156 .DE
1157 The graphical rendering of the webpage is done by webkit,
1158 a web content engine.
1159 Uzbl-core is built around libwebkit.
1160 .PP
1161 Downloads, browsing history, bookmarks, and the like are not provided
1162 by the core itself, like they are in other web browsers.
1163 Uzbl-browser also only provides, so called, handler scripts that wrap
1164 external applications which provide the actual functionality.
1165 For instance, \fIwget\fP is used to download files and uzbl-browser
1166 includes a script that calls wget with appropriate options in
1167 a prepared environment.
1168 .PP
1169 Modern web browsers are proud to have addons, plugins, and modules, instead.
1170 This is their effort to achieve similar goals.
1171 But instead of using existing, external programs, modern web browsers
1172 include these functions.
1174 .H 2 "Discussion of the design
1175 .LP
1176 This section discusses uzbl in regard of the Unix Philosophy,
1177 as identified by Gancarz.
1179 .PP
1180 .B "Make each program do one thing well" .
1181 Uzbl tries to be a web browser and nothing else.
1182 The common definition of a web browser is, of course, highly influenced by
1183 existing implementations of web browsers, although they are degenerated.
1184 Web browsers should be programs to browse the web, and nothing more.
1185 This is the one thing they should do.
1186 .PP
1187 Web browsers should not, for instance, manage downloads.
1188 This is the job download managers exist for.
1189 Download managers do primary care about being good in downloading files.
1190 Modern web browsers provide download management only as a secondary feature.
1191 How could they do this job better, than programs that exist only for
1192 this very job?
1193 And how could anyone want less than the best download manager available?
1194 .PP
1195 A web browser's job is to let the user browse the web.
1196 This means, navigating through websites by following links.
1197 Rendering the \s-1HTML\s0 sources is a different job, too.
1198 It is covered by the webkit render engine, in uzbl's case.
1199 Audio and video content and files like PostScript, \s-1PDF\s0,
1200 and the like, are also not the job of a web browser.
1201 Such content should be handled by external programs \(en
1202 programs that were written to handle such data.
1203 Uzbl strives to do it this way.
1204 .PP
1205 Remember Doug McIlroy:
1206 .I
1207 ``Write programs that do one thing and do it well.
1208 Write programs to work together.''
1209 .R
1210 .PP
1211 The lesser tenet
1212 .B "allow the user to tailor the environment
1213 matches good here.
1214 There was the question, how anyone could want anything less than the
1215 best program for the job.
1216 But as personal preferences matter, it is probably more important to ask:
1217 How could anyone want something else than his preferred program for the job?
1218 .PP
1219 Usually users want one program for a specific job.
1220 Hence, whenever the task is, for instance, downloading,
1221 the same download manager should be used.
1222 More advanced users might want to have this download manager in this
1223 situation and that one in that situation.
1224 They should be able to configure it this way.
1225 With uzbl, one can use any download manager the user wants.
1226 To switch to a different one, only one line in a small handler script
1227 needs to be changed.
1228 Alternatively it would be possible to query the program to use by
1229 reading a global file or an environment variable, in the handler script.
1230 Of course, one can tell uzbl to use a different handler script, too.
1231 This requires a one line change in uzbl's config file.
1232 .PP
1233 Uzbl does neither have its own download manager nor depends on a
1234 specific one, hence uzbl's browsing abilities will not be lowered by having
1235 a bad download manager.
1236 Uzbl's download capabilities will be just as good as the ones of the best
1237 download manager available on the system.
1238 Of course, this applies to all of the other supplementary tools, too.
1240 .PP
1241 .B "Use software leverage to your advantage" .
1242 Uzbl is designed to be extended by external tools.
1243 These external tools are usually wrapped by small handler shell scripts.
1244 Shell scripts are the glue in this approach.
1245 They make the various parts fit together.
1246 .PP
1247 The history mechanism of uzbl shall be presented as an example.
1248 Uzbl is configured to spawn a script to append an entry to the history
1249 whenever the event of a fully loaded page occurs.
1250 The script to append the entry to the history is not much more than:
1251 .DS
1252 #!/bin/sh
1253 file=/path/to/uzbl-history
1254 echo `date +'%Y-%m-%d %H:%M:%S'`" $6 $7" >> $file
1255 .DE
1256 \f(CW$6\fP and \f(CW$7\fP expand to the \s-1URL\s0 and the page title.
1257 .PP
1258 For loading an entry, a key is bound to spawn a load-from-history script.
1259 The script reverses the history to have newer entries first,
1260 then displays \fIdmenu\fP to let the user select an item,
1261 and afterwards writes the selected \s-1URL\s0 into uzbl's command input pipe.
1262 With error checking and corner case handling removed,
1263 the script looks like this:
1264 .DS
1265 #!/bin/sh
1266 file=/path/to/uzbl-history
1267 goto=`tac $file | dmenu | cut -d' ' -f 3`
1268 echo "uri $goto" > $4
1269 .DE
1270 \f(CW$4\fP expands to the path of the command input pipe of the current
1271 uzbl instance.
1273 .PP
1274 .B "Avoid captive user interfaces" .
1275 One could say, that uzbl, to a large extent, actually \fIis\fP
1276 a captive user interface.
1277 But the difference to most other web browsers is, that uzbl is only
1278 the captive user interface frontend (and the core of the backend).
1279 Many parts of the backend are independent of uzbl.
1280 Some are distributed with uzbl, for some external programs,
1281 handler scripts are distributed,
1282 but arbitrary additional functionality can be added if desired.
1283 .PP
1284 The frontend is captive \(en that is true.
1285 This is okay for the task of browsing the web, as this task is only relevant
1286 for humans.
1287 Automated programs would \fIcrawl\fP the web.
1288 That means, they read the source directly.
1289 The source includes all the semantics.
1290 The graphical representation is just for humans to transfer the semantics
1291 more intuitively.
1293 .PP
1294 .B "Make every program a filter" .
1295 Graphical web browsers are almost dead ends in the chain of information flow.
1296 Thus it is difficult to see what graphical web browsers should filter.
1297 Graphical web browsers exist almost only to be interactively used by humans.
1298 The only case when one might want to automate the rendering function is
1299 to generate images of rendered webpages.
1301 .PP
1302 .B "Small is beautiful"
1303 is not easy to apply to a web browser, because modern web technology
1304 is very complex, hence the rendering task is very complex.
1305 Modern web browsers have to consist of many thousand lines of code,
1306 unfortunately.
1307 Using the toolchest approach and wrappers can split the browser into
1308 several small parts, tough.
1309 .PP
1310 As of March 2010, uzbl-core consists of about 3\,500 lines of C code.
1311 The distribution includes another 3\,500 lines of Shell and Python code,
1312 which are the handler scripts and plugins like a modal interface.
1313 Further more, uzbl uses functionality of external tools like
1314 \fIwget\fP and \fIsocat\fP.
1315 Up to this point, uzbl looks pretty neat and small.
1316 The ugly part of uzbl is the web content render engine, webkit.
1317 Webkit consists of roughly 400\,000 (!) lines of code.
1318 Unfortunately, small web render engines are not possible anymore
1319 because of the modern web.
1321 .PP
1322 .B "Build a prototype as soon as possible" .
1323 Plaetinck made his code public, right from the beginning.
1324 Discussion and development was, and still is, open to everyone interested.
1325 Development versions of uzbl can be obtained very simply from the code
1326 repository.
1327 Within the first year of uzbl's existence, a new version was released
1328 more often than once a month.
1329 Different forks and branches arose.
1330 They introduced new features, which were tested for suitability
1331 for the main branch.
1332 The experiences of using prototypes influenced further development.
1333 Actually, all development was community driven.
1334 Plaetinck says, three months after uzbl's birth:
1335 ``Right now I hardly code anything myself for Uzbl.
1336 I just merge in other people's code, ponder a lot, and lead the discussions.''
1337 .[
1338 lwn
1339 uzbl
1340 .]
1343 .H 2 "Problems
1344 .LP
1345 Similar to \s-1MH\s0, uzbl, too suffers from being different.
1346 It is sad, but people use what they know.
1347 Fortunately, uzbl's user interface can look and feel very much the
1348 same as the one of the well known web browsers,
1349 hiding the internal differences.
1350 But uzbl has to provide this similar look and feel to be accepted
1351 as a ``normal'' browser by ``normal'' users.
1352 .PP
1353 Though, the more important problem is the modern web.
1354 The modern web is simply broken.
1355 It has state in a state-less protocol,
1356 it misuses technologies,
1357 and it is helplessly overloaded.
1358 The result are web content render engines that must consist
1359 of hundreds of thousands lines of code.
1360 They also must combine and integrate many different technologies,
1361 only to make our modern web accessible.
1362 Website to image converter are hardly possible to run without
1363 human interaction because of state in sessions, impossible
1364 deep-linking, and unautomatable technologies.
1365 .PP
1366 The web was misused to provide all kinds of imaginable wishes.
1367 Now web browsers, and eventually the users, suffer from it.
1370 .H 2 "Summary
1371 .LP
1372 ``Uzbl is a browser that adheres to the Unix Philosophy'',
1373 that is how uzbl is seen by its authors.
1374 Indeed, uzbl follows the Unix Philosophy in many ways.
1375 It consists of independent parts that work together,
1376 while its core is mainly a mediator which glues the parts together.
1377 .PP
1378 Software leverage can excellently be seen in uzbl.
1379 External tools are used, independent tasks are separated
1380 in independent parts and glued together with small handler scripts.
1381 .PP
1382 As uzbl, more or less, consists of a set of tools and a bit
1383 of glue, anyone can put the parts together and expand it
1384 in any desired way.
1385 Uzbl is very flexible and customizable.
1386 These properties make it valuable for advanced users,
1387 but may keep novice users from using it.
1388 .PP
1389 But uzbl's main problem is the modern web, that makes it hard
1390 to design a sane web browser.
1391 Despite this bad situation, uzbl does a fairly good job.
1394 .H 1 "Final thoughts
1396 .LP
1397 This paper explained why good design is important.
1398 It introduced the Unix Philosophy as guidelines to good design,
1399 in order to create good quality software.
1400 Then, real life software, that was designed with the Unix Philosophy
1401 in mind, was discussed.
1402 .PP
1403 Throughout the paper, the aim was do explain \fIwhy\fP something
1404 should be done the Unix way.
1405 It was tried to give reasons that expose that the Unix Philosophy
1406 is a preferable way for designing software.
1407 .PP
1408 The Unix Philosophy is close to the software developer's point of view.
1409 Its main goal is taming the beast ``software complexity''.
1410 Hence it strives first and foremost for simplicity, of software.
1411 It might appear, that usability for people is a minor goal.
1412 Actually, the Unix Philosophy sees usability as a result of sound design.
1413 Sound design does not need to be most intuitive,
1414 but it will provide a consistent way to access the enormous power
1415 of software leverage.
1416 .PP
1417 Being able to solve some concrete problem becomes less and less important,
1418 as there is software available for nearly every possible task today.
1419 But the quality of software matters.
1420 It is important that we have \fIgood\fP software.
1421 .sp
1422 .LP
1423 .B "But why the Unix Philosophy?
1424 .PP
1425 The largest problem of software development is the complexity involved.
1426 It is the only part of the job that computers cannot take over.
1427 The Unix Philosophy fights complexity as main enemy.
1428 .PP
1429 On the other hand,
1430 the most unique gain of software is its ability to leverage.
1431 Current software still fails to make the best possible use of this ability.
1432 The Unix Philosophy concentrates much on exploiting this great opportunity.
1435 .bp
1436 .TL
1437 References
1438 .LP
1439 .XS
1440 .sp .5v
1441 .B
1442 References
1443 .XE
1444 .ev r
1445 .nr PS -1
1446 .nr VS -1
1447 .[
1448 $LIST$
1449 .]
1450 .nr PS +1
1451 .nr VS +1
1452 .ev
1454 .bp
1455 .TL
1456 Table of Contents
1457 .LP
1458 .PX no