1.1 --- a/unix-phil.ms	Sat Apr 10 15:00:38 2010 +0200
     1.2 +++ b/unix-phil.ms	Mon Apr 12 09:33:01 2010 +0200
     1.3 @@ -22,6 +22,10 @@
     1.4  .if '\\$1'1' .nr PS -2
     1.5  ..
     1.6  
     1.7 +.am QP
     1.8 +.ps -1
     1.9 +..
    1.10 +
    1.11  .\"----------------------------------------
    1.12  
    1.13  .TL
    1.14 @@ -65,7 +69,6 @@
    1.15  unix philosophy
    1.16  .]
    1.17  .QP
    1.18 -.ps -1
    1.19  The \fIUnix philosophy\fP is a set of cultural norms and philosophical
    1.20  approaches to developing software based on the experience of leading
    1.21  developers of the Unix operating system.
    1.22 @@ -98,23 +101,23 @@
    1.23  but the fundamental idea behind it all, is ``small is beautiful''.
    1.24  
    1.25  .PP
    1.26 -The Unix Philosophy tells how to design and write good software for Unix.
    1.27 -Many concepts described here base on facilities of Unix.
    1.28 +The Unix Philosophy explains how to design good software for Unix.
    1.29 +Many concepts described here, base on facilities of Unix.
    1.30  Other operating systems may not offer such facilities,
    1.31  hence it may not be possible to design software in the way of the
    1.32  Unix Philosophy for them.
    1.33  .PP
    1.34  The Unix Philosophy has an idea of how the process of software development
    1.35  should look like, but large parts of the philosophy are quite independent
    1.36 -from the development process used.
    1.37 +from a concrete development process.
    1.38  However, one will soon recognize that some development processes work well
    1.39  with the ideas of the Unix Philosophy and support them, while others are
    1.40  at cross-purposes.
    1.41 -Kent Beck's books about Extreme Programming are valuable supplimental
    1.42 -resources.
    1.43 +Kent Beck's books about Extreme Programming are valuable supplemental
    1.44 +resources on this topic.
    1.45  .PP
    1.46  The question of how to actually write code and how the code should looks
    1.47 -like internally, are out of focus here.
    1.48 +like in detail, are out of focus here.
    1.49  ``The Practice of Programming'' by Kernighan and Pike,
    1.50  .[
    1.51  kernighan pike
    1.52 @@ -135,15 +138,16 @@
    1.53  It has nothing to do with visual appearance.
    1.54  If we take a program as a car, then its color is of no matter.
    1.55  Its design would be the car's size, its shape, the locations of doors,
    1.56 -the passenger/space ratio, the luggage capacity, and so forth.
    1.57 +the passenger/space ratio, the available controls and instruments,
    1.58 +and so forth.
    1.59  .PP
    1.60  Why should software get designed at all?
    1.61  It is general knowledge, that even a bad plan is better than no plan.
    1.62  Not designing software means programming without plan.
    1.63  This will pretty sure lead to horrible results.
    1.64 -Horrible to use and horrible to maintain.
    1.65 +Software that is horrible to use and horrible to maintain.
    1.66  These two aspects are the visible ones.
    1.67 -Often invisible are the wasted possible gains.
    1.68 +Often invisible though, are the wasted possible gains.
    1.69  Good software design can make these gains available.
    1.70  .PP
    1.71  A software's design deals with quality properties.
    1.72 @@ -166,30 +170,29 @@
    1.73  It is the driving force behind all programming effort.
    1.74  Functional requirements are easier to define and to verify.
    1.75  .IP \(bu
    1.76 -Non-functional requirements are also called \fIquality\fP requirements.
    1.77 +Non-functional requirements are called \fIquality\fP requirements, too.
    1.78  The quality of a software are the properties that are not directly related to
    1.79  the software's basic functions.
    1.80 -Tools of bad quality often solve the problems they were written for,
    1.81 +Tools of bad quality often do solve the problems they were written for,
    1.82  but introduce problems and difficulties for usage and development, later on.
    1.83  Quality aspects are often overlooked at first sight,
    1.84 -and they are often difficult to define clearly and to verify.
    1.85 +and are often difficult to define clearly and to verify.
    1.86  .PP
    1.87 -Quality is of few matter when the software gets built initially,
    1.88 -but it is of matter for usage and maintenance of the software.
    1.89 -A short-sighted might see in developing a software mainly building something up.
    1.90 +Quality is hardly interesting when the software gets built initially,
    1.91 +but it has a high impact on usability and maintenance of the software, later.
    1.92 +A short-sighted might see in developing a software, mainly building something up.
    1.93  But experience shows, that building the software the first time is
    1.94  only a small amount of the overall work.
    1.95 -Bug fixing, extending, rebuilding of parts
    1.96 -\(en maintenance work, for short \(en
    1.97 +Bug fixing, extending, rebuilding of parts \(en maintenance work \(en
    1.98  does soon take over the major part of the time spent on a software.
    1.99 -Not to forget the usage of the software.
   1.100 +And of course, the time spent actually using the software.
   1.101  These processes are highly influenced by the software's quality.
   1.102  Thus, quality must not be neglected.
   1.103 -The problem with quality is that you hardly ``stumble over''
   1.104 +However, the problem with quality is that you hardly ``stumble over''
   1.105  bad quality during the first build,
   1.106 -but this is the time when you should care about good quality most.
   1.107 +although this is the time when you should care about good quality most.
   1.108  .PP
   1.109 -Software design is less the basic function of a software \(en
   1.110 +Software design has little to do with the basic function of a software \(en
   1.111  this requirement will get satisfied anyway.
   1.112  Software design is more about quality aspects of the software.
   1.113  Good design leads to good quality, bad design to bad quality.
   1.114 @@ -197,7 +200,7 @@
   1.115  but good quality can provide a lot of additional gain,
   1.116  even at places where one never expected it.
   1.117  .PP
   1.118 -The ISO/IEC 9126-1 standard, part 1,
   1.119 +The ISO/IEC\|9126-1 standard, part\|1,
   1.120  .[
   1.121  iso product quality
   1.122  .]
   1.123 @@ -222,7 +225,7 @@
   1.124  (adaptability, installability, co-existence, replaceability)
   1.125  .LP
   1.126  Good design can improve these properties of a software,
   1.127 -bad designed software probably suffers from not having them.
   1.128 +bad designed software likely suffers in these points.
   1.129  .PP
   1.130  One further goal of software design is consistency.
   1.131  Consistency eases understanding, working on, and using things.
   1.132 @@ -230,7 +233,7 @@
   1.133  can be provided by good design.
   1.134  .PP
   1.135  Software should be well designed because good design avoids many
   1.136 -problems during the software's lifetime.
   1.137 +problems during a software's lifetime.
   1.138  And software should be well designed because good design can offer
   1.139  much additional gain.
   1.140  Indeed, much effort should be spent into good design to make software more valuable.
   1.141 @@ -279,8 +282,8 @@
   1.142  .DE
   1.143  Here, the list of files is filtered by
   1.144  .CW grep
   1.145 -to remove all that contain ``foo''.
   1.146 -The rest is the same as in the previous example.
   1.147 +to remove all lines that contain ``foo''.
   1.148 +The rest equals the previous example.
   1.149  .PP
   1.150  Finding the five largest entries in the current directory.
   1.151  .DS
   1.152 @@ -289,10 +292,10 @@
   1.153  du -s * | sort -nr | sed 5q
   1.154  .DE
   1.155  .CW "du -s *
   1.156 -returns the recursively summed sizes of all files
   1.157 +returns the recursively summed sizes of all files in the current directory
   1.158  \(en no matter if they are regular files or directories.
   1.159  .CW "sort -nr
   1.160 -sorts the list numerically in reverse order.
   1.161 +sorts the list numerically in reverse order (descending).
   1.162  Finally,
   1.163  .CW "sed 5q
   1.164  quits after it has printed the fifth line.
   1.165 @@ -310,20 +313,20 @@
   1.166  achievements of the Unix system.
   1.167  Pipes between programs have been possible in earlier operating systems,
   1.168  but it has never been a so central part of the concept.
   1.169 -When, in the early seventies, Doug McIlroy introduced pipes for the
   1.170 +When, in the early seventies, Doug McIlroy introduced pipes into the
   1.171  Unix system,
   1.172  ``it was this concept and notation for linking several programs together
   1.173  that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
   1.174  .[
   1.175  aughenbaugh
   1.176  unix oral history
   1.177 -.] 
   1.178 +.]
   1.179  .PP
   1.180  Being able to specify pipelines in an easy way is,
   1.181  however, not enough by itself.
   1.182  It is only one half.
   1.183  The other is the design of the programs that are used in the pipeline.
   1.184 -They have to interfaces that allows them to be used in such a way.
   1.185 +They need interfaces that allow them to be used in such a way.
   1.186  
   1.187  .NH 2
   1.188  Interface design
   1.189 @@ -333,41 +336,41 @@
   1.190  .LP
   1.191  Unix is, first of all, simple \(en Everything is a file.
   1.192  Files are sequences of bytes, without any special structure.
   1.193 -Programs should be filters, which read a stream of bytes from ``standard input'' (stdin)
   1.194 -and write a stream of bytes to ``standard output'' (stdout).
   1.195 -.PP
   1.196 +Programs should be filters, which read a stream of bytes from standard input (stdin)
   1.197 +and write a stream of bytes to standard output (stdout).
   1.198  If the files \fIare\fP sequences of bytes,
   1.199  and the programs \fIare\fP filters on byte streams,
   1.200 -then there is exactly one standardized data interface.
   1.201 -Thus it is possible to combine them in any desired way.
   1.202 +then there is exactly one data interface.
   1.203 +Hence it is possible to combine programs in any desired way.
   1.204  .PP
   1.205 -Even a handful of small programs will yield a large set of combinations,
   1.206 +Even a handful of small programs yields a large set of combinations,
   1.207  and thus a large set of different functions.
   1.208  This is leverage!
   1.209  If the programs are orthogonal to each other \(en the best case \(en
   1.210  then the set of different functions is greatest.
   1.211  .PP
   1.212 -Programs might also have a separate control interface,
   1.213 +Programs can also have a separate control interface,
   1.214  besides their data interface.
   1.215  The control interface is often called ``user interface'',
   1.216  because it is usually designed to be used by humans.
   1.217  The Unix Philosophy discourages to assume the user to be human.
   1.218  Interactive use of software is slow use of software,
   1.219  because the program waits for user input most of the time.
   1.220 -Interactive software requires the user to be in front of the computer
   1.221 -all the time.
   1.222 +Interactive software requires the user to be in front of the computer.
   1.223  Interactive software occupy the user's attention while they are running.
   1.224  .PP
   1.225 -Now we come back to the idea of using several small programs, combined,
   1.226 +Now to come back to the idea of combining several small programs,
   1.227  to have a more specific function.
   1.228  If these single tools would all be interactive,
   1.229  how would the user control them?
   1.230 -It is not only a problem to control several programs at once if they run at the same time,
   1.231 +It is not only a problem to control several programs at once,
   1.232 +if they run at the same time,
   1.233  it also very inefficient to have to control each of the single programs
   1.234 -that are intended to work as one large program.
   1.235 +that are intended to act as one large program.
   1.236  Hence, the Unix Philosophy discourages programs to demand interactive use.
   1.237  The behavior of programs should be defined at invocation.
   1.238 -This is done by specifying arguments (``command line switches'') to the program call.
   1.239 +This is done by specifying arguments to the program call
   1.240 +(command line switches).
   1.241  Gancarz discusses this topic as ``avoid captive user interfaces''.
   1.242  .[
   1.243  gancarz unix philosophy
   1.244 @@ -402,10 +405,12 @@
   1.245  than to write one large program with all the functionality included.
   1.246  If the small programs are combinable, then they offer even a larger set
   1.247  of functions than the single large program.
   1.248 -Hence, one gets two advantages out of writing small, combinable programs.
   1.249 +Hence, one gets two advantages out of writing small, combinable programs:
   1.250 +They are easier to write and they offer a greater set of functions through
   1.251 +combination.
   1.252  .PP
   1.253 -There are two drawbacks of the toolchest approach.
   1.254 -First, one simple, standardized, unidirectional interface has to be sufficient.
   1.255 +But there are also two main drawbacks of the toolchest approach.
   1.256 +First, one simple, standardized interface has to be sufficient.
   1.257  If one feels the need for more ``logic'' than a stream of bytes,
   1.258  then a different approach might be of need.
   1.259  But it is also possible, that he just can not imagine a design where
   1.260 @@ -415,27 +420,26 @@
   1.261  a stream of bytes is a sufficient interface.
   1.262  .PP
   1.263  The second drawback of a toolchest affects the users.
   1.264 -A toolchest is often more difficult to use for novices.
   1.265 +A toolchest is often more difficult to use.
   1.266  It is necessary to become familiar with each of the tools,
   1.267  to be able to use the right one in a given situation.
   1.268 -Additionally, one needs to combine the tools in a senseful way on its own.
   1.269 -This is like a sharp knife \(en it is a powerful tool in the hand of a master,
   1.270 -but of no good value in the hand of an unskilled.
   1.271 +Additionally, one needs to combine the tools in a senseful way himself.
   1.272 +This is like a sharp knife \(en it is a powerful tool in the hand of a
   1.273 +master, but of no good value in the hand of an unskilled.
   1.274 +However, learning single, small tools of a toolchest is easier than
   1.275 +learning a complex tool.
   1.276 +And the user will already have a basic understanding of a yet unknown tool,
   1.277 +if the tools of a toolchest have a common, consistent style.
   1.278 +He will be able to transfer knowledge over from one tool to another.
   1.279  .PP
   1.280 -However, learning single, small tool of the toolchest is easier than
   1.281 -learning a complex tool.
   1.282 -The user will have a basic understanding of a yet unknown tool,
   1.283 -if the several tools of the toolchest have a common style.
   1.284 -He will be able to transfer knowledge over one tool to another.
   1.285 -.PP
   1.286 -Moreover, the second drawback can be removed easily by adding wrappers
   1.287 -around the single tools.
   1.288 -Novice users do not need to learn several tools if a professional wraps
   1.289 -the single commands into a more high-level script.
   1.290 +Moreover, the second drawback can be removed to a large extend
   1.291 +by adding wrappers around the basic tools.
   1.292 +Novice users do not need to learn several tools, if a professional wraps
   1.293 +complete command lines into a higher-level script.
   1.294  Note that the wrapper script still calls the small tools;
   1.295 -the wrapper script is just like a skin around.
   1.296 -No complexity is added this way,
   1.297 -but new programs can get created out of existing one with very low effort.
   1.298 +it is just like a skin around them.
   1.299 +No complexity is added this way.
   1.300 +But new programs can get created out of existing one with very low effort.
   1.301  .PP
   1.302  A wrapper script for finding the five largest entries in the current directory
   1.303  could look like this:
   1.304 @@ -445,10 +449,10 @@
   1.305  #!/bin/sh
   1.306  du -s * | sort -nr | sed 5q
   1.307  .DE
   1.308 -The script itself is just a text file that calls the command line
   1.309 -a professional user would type in directly.
   1.310 -Making the program flexible on the number of entries it prints,
   1.311 -is easily possible:
   1.312 +The script itself is just a text file that calls the command line,
   1.313 +which a professional user would type in directly.
   1.314 +It is probably worth to make the program flexible on the number of
   1.315 +entries it prints:
   1.316  .DS
   1.317  .CW
   1.318  .ps -1
   1.319 @@ -459,6 +463,9 @@
   1.320  .DE
   1.321  This script acts like the one before, when called without an argument.
   1.322  But one can also specify a numerical argument to define the number of lines to print.
   1.323 +One can surely imagine even more flexible versions, however,
   1.324 +they will still relay on the external programs,
   1.325 +which do the actual work.
   1.326  
   1.327  .NH 2
   1.328  A powerful shell
   1.329 @@ -466,23 +473,23 @@
   1.330  	\*(SN A powerful shell
   1.331  .XE
   1.332  .LP
   1.333 -It was already said, that the Unix shell provides the possibility to
   1.334 -combine small programs into large ones easily.
   1.335 -A powerful shell is a great feature in other ways, too.
   1.336 -.PP
   1.337 -For instance by including a scripting language.
   1.338 -The control statements are build into the shell.
   1.339 -The functions, however, are the normal programs, everyone can use on the system.
   1.340 -Thus, the programs are known, so learning to program in the shell is easy.
   1.341 +The Unix shell provides the possibility to combine small programs into large ones.
   1.342 +But a powerful shell is a great feature in other ways, too.
   1.343 +For instance by being scriptable.
   1.344 +Control statements are build into the shell.
   1.345 +The functions, however, are the normal programs of the system.
   1.346 +Thus, as the programs are already known,
   1.347 +learning to program in the shell becomes easy.
   1.348  Using normal programs as functions in the shell programming language
   1.349  is only possible because they are small and combinable tools in a toolchest style.
   1.350  .PP
   1.351 -The Unix shell encourages to write small scripts out of other programs,
   1.352 -because it is so easy to do.
   1.353 +The Unix shell encourages to write small scripts,
   1.354 +by combining existing programs, because it is so easy to do.
   1.355  This is a great step towards automation.
   1.356  It is wonderful if the effort to automate a task equals the effort
   1.357 -it takes to do it the second time by hand.
   1.358 -If it is so, then the user will be happy to automate everything he does more than once.
   1.359 +to do the task a second time by hand.
   1.360 +If this holds,
   1.361 +then the user will be happy to automate everything he does more than once.
   1.362  .PP
   1.363  Small programs that do one job well, standardized interfaces between them,
   1.364  a mechanism to combine parts to larger parts, and an easy way to automate tasks,
   1.365 @@ -492,33 +499,32 @@
   1.366  The shell also encourages rapid prototyping.
   1.367  Many well known programs started as quickly hacked shell scripts,
   1.368  and turned into ``real'' programs, written in C, later.
   1.369 -Building a prototype first is a way to avoid the biggest problems
   1.370 +Building a prototype first, is a way to avoid the biggest problems
   1.371  in application development.
   1.372 -Fred Brooks writes in ``No Silver Bullet'':
   1.373 +Fred Brooks explains in ``No Silver Bullet'':
   1.374  .[
   1.375  brooks
   1.376  no silver bullet
   1.377  .]
   1.378  .QP
   1.379 -.ps -1
   1.380  The hardest single part of building a software system is deciding precisely what to build.
   1.381  No other part of the conceptual work is so difficult as establishing the detailed
   1.382  technical requirements, [...].
   1.383  No other part of the work so cripples the resulting system if done wrong.
   1.384  No other part is more difficult to rectify later.
   1.385  .PP
   1.386 -Writing a prototype is a great method to become familiar with the requirements
   1.387 -and to actually run into real problems.
   1.388 -Today, prototyping is often seen as a first step in building a software.
   1.389 +Writing a prototype is a great method for becoming familiar with the requirements
   1.390 +and to run into real problems early.
   1.391 +.PP
   1.392 +Prototyping is often seen as a first step in building a software.
   1.393  This is, of course, good.
   1.394  However, the Unix Philosophy has an \fIadditional\fP perspective on prototyping:
   1.395  After having built the prototype, one might notice, that the prototype is already
   1.396  \fIgood enough\fP.
   1.397 -Hence, no reimplementation, in a more sophisticated programming language, might be of need,
   1.398 -for the moment.
   1.399 +Hence, no reimplementation, in a more sophisticated programming language,
   1.400 +might be of need, at least for the moment.
   1.401  Maybe later, it might be necessary to rewrite the software, but not now.
   1.402 -.PP
   1.403 -By delaying further work, one keeps the flexibility to react easily on
   1.404 +By delaying further work, one keeps the flexibility to react on
   1.405  changing requirements.
   1.406  Software parts that are not written will not miss the requirements.
   1.407  
   1.408 @@ -528,21 +534,25 @@
   1.409  	\*(SN Worse is better
   1.410  .XE
   1.411  .LP
   1.412 -The Unix Philosophy aims for the 80% solution;
   1.413 +The Unix Philosophy aims for the 90% solution;
   1.414  others call it the ``Worse is better'' approach.
   1.415 +Practical experience shows, that:
   1.416  .PP
   1.417 -First, practical experience shows, that it is almost never possible to define the
   1.418 +(1) It is almost never possible to define the
   1.419  requirements completely and correctly the first time.
   1.420 -Hence one should not try to; it will fail anyway.
   1.421 -Second, practical experience shows, that requirements change during time.
   1.422 +Hence one should not try to; one will fail anyway.
   1.423 +.PP
   1.424 +(2) Requirements change during time.
   1.425  Hence it is best to delay requirement-based design decisions as long as possible.
   1.426 -Also, the software should be small and flexible as long as possible
   1.427 +The software should be small and flexible as long as possible
   1.428  to react on changing requirements.
   1.429  Shell scripts, for example, are more easily adjusted as C programs.
   1.430 -Third, practical experience shows, that maintenance is hard work.
   1.431 -Hence, one should keep the amount of software as small as possible;
   1.432 +.PP
   1.433 +(3) Maintenance work is hard work.
   1.434 +Hence, one should keep the amount of code as small as possible;
   1.435  it should just fulfill the \fIcurrent\fP requirements.
   1.436 -Software parts that will be written later, do not need maintenance now.
   1.437 +Software parts that will be written in future,
   1.438 +do not need maintenance till then.
   1.439  .PP
   1.440  Starting with a prototype in a scripting language has several advantages:
   1.441  .IP \(bu
   1.442 @@ -550,16 +560,16 @@
   1.443  .IP \(bu
   1.444  As working parts are available soon, the real requirements can get identified soon.
   1.445  .IP \(bu
   1.446 -When a software is usable, it gets used, and thus tested.
   1.447 +When a software is usable and valuable, it gets used, and thus tested.
   1.448  Hence problems will be found at early stages of the development.
   1.449  .IP \(bu
   1.450  The prototype might be enough for the moment,
   1.451 -thus further work on the software can be delayed to a time
   1.452 +thus further work on the software can get delayed to a time
   1.453  when one knows better about the requirements and problems,
   1.454  than now.
   1.455  .IP \(bu
   1.456 -Implementing now only the parts that are actually needed now,
   1.457 -requires fewer maintenance work.
   1.458 +Implementing now only the parts that are actually needed at the moment,
   1.459 +introduces fewer programming and maintenance work.
   1.460  .IP \(bu
   1.461  If the global situation changes so that the software is not needed anymore,
   1.462  then less effort was spent into the project, than it would have be
   1.463 @@ -575,13 +585,12 @@
   1.464  Although these are just verbs, they do imply a specific view on the work process
   1.465  they describe.
   1.466  The better verb, however, is to \fIgrow\fP.
   1.467 -.PP
   1.468  Creating software in the sense of the Unix Philosophy is an incremental process.
   1.469  It starts with a first prototype, which evolves as requirements change.
   1.470  A quickly hacked shell script might become a large, sophisticated,
   1.471  compiled program this way.
   1.472  Its lifetime begins with the initial prototype and ends when the software is not used anymore.
   1.473 -While being alive it will get extended, rearranged, rebuilt (from scratch).
   1.474 +While being alive it will get extended, rearranged, rebuilt.
   1.475  Growing software matches the view that ``software is never finished. It is only released.''
   1.476  .[
   1.477  gancarz
   1.478 @@ -628,13 +637,13 @@
   1.479  is best achieved by avoiding binary representations
   1.480  to store data, because binary representations differ from machine to machine.
   1.481  Textual representation is favored.
   1.482 -Historically, ASCII was the charset of choice.
   1.483 -In the future, UTF-8 might be the better choice, however.
   1.484 +Historically, \s-1ASCII\s0 was the charset of choice.
   1.485 +For the future, \s-1UTF\s0-8 might be the better choice.
   1.486  Important is that it is a plain text representation in a
   1.487  very common charset encoding.
   1.488  Apart from being able to transfer data between machines,
   1.489 -readable data has the great advantage, that humans are able
   1.490 -to directly edit it with text editors and other tools from the Unix toolchest.
   1.491 +readable data has the great advantage, that humans are able to directly
   1.492 +read and edit it with text editors and other tools from the Unix toolchest.
   1.493  .\" gancarz tenet 5
   1.494  .PP
   1.495  (3)
   1.496 @@ -644,25 +653,23 @@
   1.497  It is a special distinction if a software becomes used in fields of action,
   1.498  the original authors did never imagine.
   1.499  Software that solves problems in a general way will likely be used
   1.500 -for all kinds of similar problems.
   1.501 -Being too specific limits the range of uses.
   1.502 +for many kinds of similar problems.
   1.503 +Being too specific limits the range of usability.
   1.504  Requirements change through time, thus use cases change or even vanish.
   1.505 -A good example in this point is Allman's sendmail.
   1.506 +As a good example in this point,
   1.507  Allman identifies flexibility to be one major reason for sendmail's success:
   1.508  .[
   1.509  allman
   1.510  sendmail
   1.511  .]
   1.512  .QP
   1.513 -.ps -1
   1.514  Second, I limited myself to the routing function [...].
   1.515  This was a departure from the dominant thought of the time, [...].
   1.516  .QP
   1.517 -.ps -1
   1.518 -Third, the sendmail configuration file was flexible enough to adopt
   1.519 +Third, the sendmail configuration file was flexible enough to adapt
   1.520  to a rapidly changing world [...].
   1.521  .LP
   1.522 -Successful software adopts itself to the changing world.
   1.523 +Successful software adapts itself to the changing world.
   1.524  .PP
   1.525  (4)
   1.526  .I "Reuse of parts
   1.527 @@ -671,7 +678,7 @@
   1.528  but parts of which the software is build may be general and independent enough
   1.529  to survive this death.
   1.530  If software is build by combining small independent programs,
   1.531 -then there are parts readily available for reuse.
   1.532 +then these parts are readily available for reuse.
   1.533  Who cares if the large program is a failure,
   1.534  but parts of it become successful instead?
   1.535  
   1.536 @@ -681,17 +688,17 @@
   1.537  	\*(SN Summary
   1.538  .XE
   1.539  .LP
   1.540 -This chapter explained the central ideas of the Unix Philosophy.
   1.541 -For each of the ideas, it was exposed what advantages they introduce.
   1.542 -The Unix Philosophy are guidelines that help to write valuable software.
   1.543 +This chapter explained central ideas of the Unix Philosophy.
   1.544 +For each of the ideas, the advantages they introduce were explained.
   1.545 +The Unix Philosophy are guidelines that help to write more valuable software.
   1.546  From the view point of a software developer or software designer,
   1.547  the Unix Philosophy provides answers to many software design problem.
   1.548  .PP
   1.549  The various ideas of the Unix Philosophy are very interweaved
   1.550  and can hardly be applied independently.
   1.551  However, the probably most important messages are:
   1.552 +.I "``Keep it simple!''" ,
   1.553  .I "``Do one thing well!''" ,
   1.554 -.I "``Keep it simple!''" ,
   1.555  and
   1.556  .I "``Use software leverage!''
   1.557  
   1.558 @@ -715,10 +722,10 @@
   1.559  \s-1MH\s0 (``mail handler'') and its descendent \fInmh\fP
   1.560  (``new mail handler'').
   1.561  \s-1MUA\s0s provide functions to read, compose, and organize mail,
   1.562 -but (ideally) not to transfer.
   1.563 -In this document, the name \s-1MH\s0 will be used for both of them.
   1.564 +but (ideally) not to transfer it.
   1.565 +In this document, the name \s-1MH\s0 will be used to include nmh.
   1.566  A distinction will only be made if differences between
   1.567 -them are described.
   1.568 +\s-1MH\s0 and nmh are described.
   1.569  
   1.570  
   1.571  .NH 2
   1.572 @@ -735,8 +742,8 @@
   1.573  quarter century of unix
   1.574  %P 41 f.
   1.575  .]
   1.576 -It was a small program that either prints the user's mailbox file
   1.577 -or appends text to someone elses mailbox file,
   1.578 +It was a small program that either printed the user's mailbox file
   1.579 +or appended text to someone elses mailbox file,
   1.580  depending on the command line arguments.
   1.581  .[
   1.582  manual mail(1)
   1.583 @@ -747,9 +754,9 @@
   1.584  Later, emailing became more powerful, and thus more complex.
   1.585  The simple \f(CWmail\fP, which knew nothing of subjects,
   1.586  independent handling of single messages,
   1.587 -and long-time storage of them, was not powerful enough anymore.
   1.588 -At Berkeley, Kurt Shoens wrote \fIMail\fP (with capital `M')
   1.589 -in 1978 to provide additional functions for emailing.
   1.590 +and long-time email storage, was not powerful enough anymore.
   1.591 +In 1978 at Berkeley, Kurt Shoens wrote \fIMail\fP (with capital `M')
   1.592 +to provide additional functions for emailing.
   1.593  Mail was still one program, but now it was large and did
   1.594  several jobs.
   1.595  Its user interface is modeled after the one of \fIed\fP.
   1.596 @@ -768,7 +775,7 @@
   1.597  called \s-1MS\s0 (for ``mail system'').
   1.598  But in 1977, Stockton Gaines and Norman Shapiro
   1.599  came up with a proposal of a new email system concept \(en
   1.600 -one that honors the Unix Philosophy.
   1.601 +one that honored the Unix Philosophy.
   1.602  The concept was implemented by Bruce Borden in 1978 and 1979.
   1.603  This was the birth of \s-1MH\s0 \(en the ``mail handler''.
   1.604  .PP
   1.605 @@ -777,7 +784,7 @@
   1.606  However, it's core concepts remained the same.
   1.607  In the late 90s, when development of \s-1MH\s0 slowed down,
   1.608  Richard Coleman started with \fInmh\fP, the new mail handler.
   1.609 -His goal was to improve \s-1MH\s0, especially in regard of 
   1.610 +His goal was to improve \s-1MH\s0 especially in regard of 
   1.611  the requirements of modern emailing.
   1.612  Today, nmh is developed by various people on the Internet.
   1.613  .[
   1.614 @@ -822,30 +829,30 @@
   1.615  change current folder
   1.616  .IP \(bu
   1.617  .CW refile :
   1.618 -refile message into folder
   1.619 +refile message into different folder
   1.620  .IP \(bu
   1.621  .CW rmm :
   1.622  remove message
   1.623  .IP \(bu
   1.624  .CW comp : 
   1.625 -compose a new message
   1.626 +compose new message
   1.627  .IP \(bu
   1.628  .CW repl :
   1.629 -reply to a message
   1.630 +reply to message
   1.631  .IP \(bu
   1.632  .CW forw : 
   1.633 -forward a message
   1.634 +forward message
   1.635  .IP \(bu
   1.636  .CW send : 
   1.637 -send a prepared message (this is how mail leaves the system)
   1.638 +send prepared message (this is how mail leaves the system)
   1.639  .LP
   1.640  \s-1MH\s0 has no special user interface like monolithic \s-1MUA\s0s have.
   1.641  The user does not leave the shell to run \s-1MH\s0,
   1.642 -but he uses the various \s-1MH\s0 programs within the shell.
   1.643 +instead he uses the various \s-1MH\s0 programs within the shell.
   1.644  Using a monolithic program with a captive user interface
   1.645  means ``entering'' the program, using it, and ``exiting'' the program.
   1.646  Using toolchests like \s-1MH\s0 means running programs,
   1.647 -alone or in combination with others, even from other toolchests,
   1.648 +alone or in combination with others, also from other toolchests,
   1.649  without leaving the shell.
   1.650  
   1.651  .NH 2
   1.652 @@ -859,10 +866,11 @@
   1.653  where mail folders are directories and mail messages are text files
   1.654  within them.
   1.655  Each mail folder contains a file \f(CW.mh_sequences\fP which lists
   1.656 -the public message sequences of that folder, for instance new messages.
   1.657 +the public message sequences of that folder,
   1.658 +for instance the \fIunseen\fP sequence for new messages.
   1.659  Mail messages are text files located in a mail folder.
   1.660  The files contain the messages as they were received.
   1.661 -They are numbered in ascending order in each folder.
   1.662 +They are named by ascending numbers in each folder.
   1.663  .PP
   1.664  This mailbox format is called ``\s-1MH\s0'' after the \s-1MUA\s0.
   1.665  Alternatives are \fImbox\fP and \fImaildir\fP.
   1.666 @@ -875,11 +883,10 @@
   1.667  more difficult to write tools that work on mail messages,
   1.668  because it is always necessary to first find and extract
   1.669  the relevant message in the mbox file.
   1.670 -With the \s-1MH\s0 mailbox format,
   1.671 -each message is a self-standing item, by definition.
   1.672 +With the \s-1MH\s0 mailbox format, each message is a separate file.
   1.673  Also, the problem of concurrent access to one mailbox is
   1.674  reduced to the problem of concurrent access to one message.
   1.675 -Maildir is generally similar to \s-1MH\s0's format,
   1.676 +The maildir format is generally similar to the \s-1MH\s0 format,
   1.677  but modified towards guaranteed reliability.
   1.678  This involves some complexity, unfortunately.
   1.679  .PP
   1.680 @@ -891,9 +898,8 @@
   1.681  \f(CWrefile\fP is like \f(CWmv\fP,
   1.682  and \f(CWrmm\fP is like \f(CWrm\fP.
   1.683  .PP
   1.684 -The context of tools in Unix consists mainly the current working directory,
   1.685 -the user identification, and the environment variables.
   1.686 -\s-1MH\s0 extends this context by two more items:
   1.687 +\s-1MH\s0 extends the context of processes in Unix by two more items,
   1.688 +for its tools:
   1.689  .IP \(bu
   1.690  The current mail folder, which is similar to the current working directory.
   1.691  For mail folders, \f(CWfolder\fP provides the corresponding functionality
   1.692 @@ -903,11 +909,13 @@
   1.693  The current message, relative to a mail folder, is a special sequence.
   1.694  It enables commands like \f(CWnext\fP and \f(CWprev\fP.
   1.695  .LP
   1.696 -In contrast to Unix' context, which is chained to the shell session,
   1.697 -\s-1MH\s0's context is independent.
   1.698 -Usually there is one context for each user, but a user can have many
   1.699 -contexts.
   1.700 -Public sequences are an exception, as they belong to the mail folder.
   1.701 +In contrast to Unix' context, which is maintained by the kernel,
   1.702 +\s-1MH\s0's context must be maintained by the tools themselves.
   1.703 +Usually there is one context per user, which resides in his
   1.704 +\f(CWcontext\fP file in the \s-1MH\s0 directory,
   1.705 +but a user can have several contexts, too.
   1.706 +Public sequences are an exception, as they belong to a mail folder,
   1.707 +and reside in the \f(CW.mh_sequences\fP file there.
   1.708  .[
   1.709  man page mh-profile mh-sequence
   1.710  .]
   1.711 @@ -918,23 +926,22 @@
   1.712  	\*(SN Discussion of the design
   1.713  .XE
   1.714  .LP
   1.715 -The following paragraphs discuss \s-1MH\s0 in regard to the tenets
   1.716 -of the Unix Philosophy which Gancarz identified.
   1.717 +This section discusses \s-1MH\s0 in regard to the tenets
   1.718 +of the Unix Philosophy that Gancarz identified.
   1.719  
   1.720  .PP
   1.721  .B "Small is beautiful
   1.722  and
   1.723  .B "do one thing well
   1.724  are two design goals that are directly visible in \s-1MH\s0.
   1.725 -Gancarz actually presents \s-1MH\s0 as example under the headline
   1.726 -``Making UNIX Do One Thing Well'':
   1.727 +Gancarz actually presents \s-1MH\s0 in his book as example under the
   1.728 +headline ``Making \s-1UNIX\s0 Do One Thing Well'':
   1.729  .[
   1.730  gancarz
   1.731  unix philosophy
   1.732  %P 125
   1.733  .]
   1.734  .QP
   1.735 -.ps -1
   1.736  [\s-1MH\s0] consists of a series of programs which
   1.737  when combined give the user an enormous ability
   1.738  to manipulate electronic mail messages.
   1.739 @@ -942,8 +949,8 @@
   1.740  possible to build large applications from smaller
   1.741  components, but also that such designs are actually preferable.
   1.742  .LP
   1.743 -The various small programs of \s-1MH\s0 were relatively easy
   1.744 -to write, because each of them is small, limited to one function,
   1.745 +The various programs of \s-1MH\s0 were relatively easy to write,
   1.746 +because each of them is small, limited to one function,
   1.747  and has clear boundaries.
   1.748  For the same reasons, they are also good to maintain.
   1.749  Further more, the system can easily get extended.
   1.750 @@ -952,19 +959,22 @@
   1.751  (e.g. \f(CWmhbuild\fP).
   1.752  Also, different programs can exist to do the basically same job
   1.753  in different ways (e.g. in nmh: \f(CWshow\fP and \f(CWmhshow\fP).
   1.754 +.PP
   1.755  If someone needs a mail system with some additionally
   1.756 -functions that are available nowhere yet, he best takes a
   1.757 -toolchest system like \s-1MH\s0 where he can add the
   1.758 -functionality with little work.
   1.759 +functions that are not available anywhere yet, he best expands a
   1.760 +toolchest system like \s-1MH\s0.
   1.761 +There he can add new functionality by simply adding additional
   1.762 +programs to the toolchest.
   1.763 +There he does not risk to break existing functionality by doing so.
   1.764  
   1.765  .PP
   1.766  .B "Store data in flat text files
   1.767  is followed by \s-1MH\s0.
   1.768  This is not surprising, because email messages are already plain text.
   1.769  \s-1MH\s0 stores the messages as it receives them,
   1.770 -thus any other tool that works on RFC 2822 mail messages can operate
   1.771 +thus any other tool that works on \s-1RFC\s0\|2822 mail messages can operate
   1.772  on the messages in an \s-1MH\s0 mailbox.
   1.773 -All other files \s-1MH\s0 uses are plain text too.
   1.774 +All other files \s-1MH\s0 uses are plain text, too.
   1.775  It is therefore possible and encouraged to use the text processing
   1.776  tools of Unix' toolchest to extend \s-1MH\s0's toolchest.
   1.777  
   1.778 @@ -973,11 +983,12 @@
   1.779  \s-1MH\s0 is perfectly suited for non-interactive use.
   1.780  It offers all functions directly and without captive user interfaces.
   1.781  If, nonetheless, users want a graphical user interface,
   1.782 -they can have it with \fIxmh\fP or \fIexmh\fP, too.
   1.783 +they can have it with \fIxmh\fP or \fIexmh\fP.
   1.784  These are graphical frontends for the \s-1MH\s0 toolchest.
   1.785  This means, all email-related work is still done by \s-1MH\s0 tools,
   1.786 -but the frontend issues the appropriate calls when the user
   1.787 +but the frontend calls the appropriate commands when the user
   1.788  clicks on buttons.
   1.789 +.PP
   1.790  Providing easy-to-use user interfaces in form of frontends is a good
   1.791  approach, because it does not limit the power of the backend itself.
   1.792  The frontend will anyway only be able to make a subset of the
   1.793 @@ -985,8 +996,8 @@
   1.794  But if it is a separate program,
   1.795  then the missing parts can still be accessed at the backend directly.
   1.796  If it is integrated, then this will hardly be possible.
   1.797 -Further more, it is possible to have different frontends to the same
   1.798 -backend.
   1.799 +An additional advantage is the possibility to have different frontends
   1.800 +to the same backend.
   1.801  
   1.802  .PP
   1.803  .B "Choose portability over efficiency
   1.804 @@ -998,9 +1009,9 @@
   1.805  bolsky korn
   1.806  korn shell
   1.807  .]
   1.808 -They demonstrated, in chapter 18 of the book, a basic implementation
   1.809 +Chapter\|18 of the book shows a basic implementation
   1.810  of a subset of \s-1MH\s0 in ksh scripts.
   1.811 -Of course, this was just a demonstration, but a brilliant one.
   1.812 +Of course, this is just a demonstration, but a brilliant one.
   1.813  It shows how quickly one can implement such a prototype with shell scripts,
   1.814  and how readable they are.
   1.815  The implementation in the scripting language may not be very fast,
   1.816 @@ -1008,20 +1019,21 @@
   1.817  By having the code in an interpreted language, like the shell,
   1.818  portability becomes a minor issue, if we assume the interpreter
   1.819  to be widespread.
   1.820 +.PP
   1.821  This demonstration also shows how easy it is to create single programs
   1.822  of a toolchest software.
   1.823 -There are eight tools (two of them have multiple names) and 16 functions
   1.824 -with supporting code.
   1.825 -Each tool comprises between 12 and 38 lines of ksh,
   1.826 +Eight tools (two of them have multiple names) and 16 functions
   1.827 +with supporting code are presented to the reader.
   1.828 +The tools comprise less than 40 lines of ksh each,
   1.829  in total about 200 lines.
   1.830 -The functions comprise between 3 and 78 lines of ksh,
   1.831 +The functions comprise less than 80 lines of ksh each,
   1.832  in total about 450 lines.
   1.833  Such small software is easy to write, easy to understand,
   1.834  and thus easy to maintain.
   1.835  A toolchest improves the possibility to only write some parts
   1.836  and though create a working result.
   1.837 -Expanding the toolchest without global changes will likely be
   1.838 -possible, too.
   1.839 +Expanding the toolchest, even without global changes,
   1.840 +will likely be possible.
   1.841  
   1.842  .PP
   1.843  .B "Use software leverage to your advantage
   1.844 @@ -1031,12 +1043,13 @@
   1.845  Tailoring the environment is heavily encouraged by the ability to
   1.846  directly define default options to programs.
   1.847  It is even possible to define different default options
   1.848 -depending on the name under which the program was called.
   1.849 -Software leverage is heavily encouraged by the ease it is to
   1.850 -create shell scripts that run a specific command line,
   1.851 +depending on the name under which a program is called.
   1.852 +Software leverage is heavily encouraged by the ease of
   1.853 +creating shell scripts that run a specific command line,
   1.854  built of several \s-1MH\s0 programs.
   1.855  There is few software that so much wants users to tailor their
   1.856  environment and to leverage the use of the software, like \s-1MH\s0.
   1.857 +.PP
   1.858  Just to make one example:
   1.859  One might prefer a different listing format for the \f(CWscan\fP
   1.860  program.
   1.861 @@ -1053,25 +1066,22 @@
   1.862  instead of changing the default, he needs to create a link to
   1.863  \f(CWscan\fP, for instance titled \f(CWscan2\fP.
   1.864  The line in \f(CW.mh_profile\fP would then start with \f(CWscan2\fP,
   1.865 -as the option should only be in effect when scan is called as
   1.866 +as the option should only be in effect for a program that is called as
   1.867  \f(CWscan2\fP.
   1.868  
   1.869  .PP
   1.870  .B "Make every program a filter
   1.871  is hard to find in \s-1MH\s0.
   1.872  The reason therefore is that most of \s-1MH\s0's tools provide
   1.873 -basic file system operations for the mailboxes.
   1.874 -The reason is the same because of which
   1.875 -\f(CWls\fP, \f(CWcp\fP, \f(CWmv\fP, and \f(CWrm\fP
   1.876 -aren't filters neither.
   1.877 -However, they build a basis on which filters can operate.
   1.878 +basic file system operations for mailboxes.
   1.879 +It is the same reason because of which \f(CWls\fP, \f(CWcp\fP, \f(CWmv\fP,
   1.880 +and \f(CWrm\fP aren't filters neither.
   1.881  \s-1MH\s0 does not provide many filters itself, but it is a basis
   1.882  to write filters for.
   1.883 -An example would be a mail message text highlighter,
   1.884 +An example would be a mail text highlighter,
   1.885  that means a program that makes use of a color terminal to display
   1.886  header lines, quotations, and signatures in distinct colors.
   1.887 -The author's version of this program, for instance,
   1.888 -is a 25 line awk script.
   1.889 +The author's version of such a program is an awk script with 25 lines.
   1.890  
   1.891  .PP
   1.892  .B "Build a prototype as soon as possible
   1.893 @@ -1087,8 +1097,7 @@
   1.894  %P 132
   1.895  .]
   1.896  .QP
   1.897 -.ps -1
   1.898 -[...] but they [Stockton Gaines and Norm Shapiro] were not able
   1.899 +[...] but [Stockton Gaines and Norm Shapiro] were not able
   1.900  to convince anyone that such a system would be fast enough to be usable.
   1.901  I proposed a very short project to prove the basic concepts,
   1.902  and my management agreed.
   1.903 @@ -1107,33 +1116,33 @@
   1.904  	\*(SN Problems
   1.905  .XE
   1.906  .LP
   1.907 -\s-1MH\s0, for sure is not without problems.
   1.908 +\s-1MH\s0 is not without problems.
   1.909  There are two main problems: one is technical, the other is about human behavior.
   1.910  .PP
   1.911  \s-1MH\s0 is old and email today is very different to email in the time
   1.912  when \s-1MH\s0 was designed.
   1.913 -\s-1MH\s0 adopted to the changes pretty well, but it is limited.
   1.914 -For example in development resources.
   1.915 +\s-1MH\s0 adapted to the changes pretty well, but it is limited, though.
   1.916  \s-1MIME\s0 support and support for different character encodings
   1.917  is available, but only on a moderate level.
   1.918 -More active developers could quickly improve there.
   1.919 -It is also limited by design, which is the larger problem.
   1.920 +This comes from limited development resources.
   1.921 +More active developers could quickly change this.
   1.922 +But \s-1MH\s0 is also limited by design, which is the larger problem.
   1.923  \s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extend.
   1.924  These design conflicts are not easily solvable.
   1.925  Possibly, they require a redesign.
   1.926 -Maybe \s-1IMAP\s0 is too different to the classic mail model which \s-1MH\s0 covers,
   1.927 -hence \s-1MH\s0 may never work well with \s-1IMAP\s0.
   1.928 +\s-1IMAP\s0 may be too different to the classic mail model,
   1.929 +which \s-1MH\s0 covers, so that \s-1MH\s0 may never support it well.
   1.930  .PP
   1.931 -The other kind of problem is human habits.
   1.932 -When in this world almost all \s-1MUA\s0s are monolithic,
   1.933 +The other kind of problem are human habits.
   1.934 +In this world, where almost all \s-1MUA\s0s are monolithic,
   1.935  it is very difficult to convince people to use a toolbox style \s-1MUA\s0
   1.936  like \s-1MH\s0.
   1.937 -The habits are so strong, that even people who understood the concept
   1.938 +The habits are so strong, that even people who understand the concept
   1.939  and advantages of \s-1MH\s0 do not like to switch,
   1.940  simply because \s-1MH\s0 is different.
   1.941  Unfortunately, the frontends to \s-1MH\s0, which could provide familiar look'n'feel,
   1.942 -are quite outdated and thus not very appealing compared to the modern interfaces
   1.943 -which monolithic \s-1MUA\s0s offer.
   1.944 +are quite outdated and thus not very appealing, compared to the modern interfaces
   1.945 +of many monolithic \s-1MUA\s0s.
   1.946  
   1.947  .NH 2
   1.948  Summary \s-1MH\s0
   1.949 @@ -1141,17 +1150,12 @@
   1.950  	\*(SN Summary \s-1MH\s0
   1.951  .XE
   1.952  .LP
   1.953 -\s-1MH\s0 is an \s-1MUA\s0 that follows the Unix Philosophy in its design
   1.954 -and implementation.
   1.955 +\s-1MH\s0 is an \s-1MUA\s0 that follows the Unix Philosophy in its design.
   1.956  It consists of a toolchest of small tools, each of them does one job well.
   1.957 -The tools are orthogonal to each other, to a large extend.
   1.958 -However, for historical reasons, there also exist distinct tools
   1.959 -that cover the same task.
   1.960 -.PP
   1.961  The toolchest approach offers great flexibility to the user.
   1.962 -He can use the complete power of the Unix shell with \s-1MH\s0.
   1.963 +It is possible to utilize the complete power of the Unix shell with \s-1MH\s0.
   1.964  This makes \s-1MH\s0 a very powerful mail system.
   1.965 -Extending and customizing \s-1MH\s0 is easy and encouraged, too.
   1.966 +Extending and customizing \s-1MH\s0 is easy and encouraged.
   1.967  .PP
   1.968  Apart from the user's perspective, \s-1MH\s0 is development-friendly.
   1.969  Its overall design follows clear rules.
   1.970 @@ -1175,9 +1179,11 @@
   1.971  .XE
   1.972  .LP
   1.973  The last chapter took a look on the \s-1MUA\s0 \s-1MH\s0,
   1.974 -this chapter is about uzbl, a web browser that adheres to the Unix Philosophy.
   1.975 -``uzbl'' is the \fIlolcat\fP's word for the English adjective ``usable''.
   1.976 -It is pronounced the identical.
   1.977 +which is an old and established software.
   1.978 +This chapter covers uzbl, a fresh new project.
   1.979 +Uzbl is a web browser that adheres to the Unix Philosophy.
   1.980 +Its name comes from the \fILolspeak\fP word for ``usable'';
   1.981 +it is pronounced identical.
   1.982  
   1.983  .NH 2
   1.984  Historical background
   1.985 @@ -1203,10 +1209,10 @@
   1.986  One week later, uzbl had an own website.
   1.987  One month after the first code showed up,
   1.988  a mailing list was installed to coordinate and discuss further development.
   1.989 -A wiki was set up to store documentation and scripts that showed up on the
   1.990 +Then a wiki followed to store documentation and scripts that showed up on the
   1.991  mailing list and elsewhere.
   1.992  .PP
   1.993 -In the, now, one year of uzbl's existence, it was heavily developed in various branches.
   1.994 +In the, now, one year of uzbl's existence, it was heavily developed on various branches.
   1.995  Plaetinck's task became more and more to only merge the best code from the
   1.996  different branches into his main branch, and to apply patches.
   1.997  About once a month, Plaetinck released a new version.
   1.998 @@ -1228,7 +1234,7 @@
   1.999  Today, uzbl is divided into uzbl-core and uzbl-browser.
  1.1000  Uzbl-core is, how its name already indicates, the core of uzbl.
  1.1001  It handles commands and events to interface other programs,
  1.1002 -and also displays webpages by using webkit as render engine.
  1.1003 +and also displays webpages by using \fIwebkit\fP as render engine.
  1.1004  Uzbl-browser combines uzbl-core with a bunch of handler scripts, a status bar,
  1.1005  an event manager, yanking, pasting, page searching, zooming, and more stuff,
  1.1006  to form a ``complete'' web browser.
  1.1007 @@ -1236,19 +1242,20 @@
  1.1008  so uzbl-core is included.
  1.1009  .PP
  1.1010  Unlike most other web browsers, uzbl is mainly the mediator between the
  1.1011 -various tools that cover single jobs of web browsing.
  1.1012 +various tools that cover single jobs.
  1.1013  Therefore, uzbl listens for commands on a named pipe (fifo), a Unix socket,
  1.1014  and on stdin, and it writes events to a Unix socket and to stdout.
  1.1015 -The graphical rendering of the webpage is done by webkit, a web content engine.
  1.1016 -Uzbl-core is build around this library.
  1.1017  Loading a webpage in a running uzbl instance requires only:
  1.1018  .DS
  1.1019  .CW
  1.1020  echo 'uri http://example.org' >/path/to/uzbl-fifo
  1.1021  .DE
  1.1022 +The graphical rendering of the webpage is done by webkit,
  1.1023 +a web content engine.
  1.1024 +Uzbl-core is built around libwebkit.
  1.1025  .PP
  1.1026 -Downloads, browsing history, bookmarks, and thelike are not provided
  1.1027 -by uzbl-core itself, as they are in other web browsers.
  1.1028 +Downloads, browsing history, bookmarks, and the like are not provided
  1.1029 +by the core itself, like they are in other web browsers.
  1.1030  Uzbl-browser also only provides, so called, handler scripts that wrap
  1.1031  external applications which provide the actual functionality.
  1.1032  For instance, \fIwget\fP is used to download files and uzbl-browser
  1.1033 @@ -1258,7 +1265,7 @@
  1.1034  Modern web browsers are proud to have addons, plugins, and modules, instead.
  1.1035  This is their effort to achieve similar goals.
  1.1036  But instead of using existing, external programs, modern web browsers
  1.1037 -include these functions, although they might be loaded at runtime.
  1.1038 +include these functions.
  1.1039  
  1.1040  .NH 2
  1.1041  Discussion of the design
  1.1042 @@ -1275,13 +1282,13 @@
  1.1043  The common definition of a web browser is, of course, highly influenced by
  1.1044  existing implementations of web browsers, although they are degenerated.
  1.1045  Web browsers should be programs to browse the web, and nothing more.
  1.1046 -This is the one thing they should do, as demanded by the Unix Philosophy.
  1.1047 +This is the one thing they should do.
  1.1048  .PP
  1.1049 -Web browsers should, for instance, not manage downloads.
  1.1050 +Web browsers should not, for instance, manage downloads.
  1.1051  This is the job download managers exist for.
  1.1052  Download managers do primary care about being good in downloading files.
  1.1053  Modern web browsers provide download management only as a secondary feature.
  1.1054 -How could they perform this job better, than programs that exist only for
  1.1055 +How could they do this job better, than programs that exist only for
  1.1056  this very job?
  1.1057  And how could anyone want less than the best download manager available?
  1.1058  .PP
  1.1059 @@ -1306,42 +1313,39 @@
  1.1060  matches good here.
  1.1061  There was the question, how anyone could want anything less than the
  1.1062  best program for the job.
  1.1063 -But as personal preferences matter much,
  1.1064 -it is probably more important to ask:
  1.1065 +But as personal preferences matter, it is probably more important to ask:
  1.1066  How could anyone want something else than his preferred program for the job?
  1.1067  .PP
  1.1068 -Usually users want one program for one job.
  1.1069 +Usually users want one program for a specific job.
  1.1070  Hence, whenever the task is, for instance, downloading,
  1.1071 -exactly one download manager should be used.
  1.1072 +the same download manager should be used.
  1.1073  More advanced users might want to have this download manager in this
  1.1074  situation and that one in that situation.
  1.1075  They should be able to configure it this way.
  1.1076  With uzbl, one can use any download manager the user wants.
  1.1077  To switch to a different one, only one line in a small handler script
  1.1078  needs to be changed.
  1.1079 -Alternatively it would be possible to query an entry in a global file
  1.1080 -or an environment variable, which specifies the download manager to use,
  1.1081 -in the handler script.
  1.1082 +Alternatively it would be possible to query the program to use by
  1.1083 +reading a global file or an environment variable, in the handler script.
  1.1084  .PP
  1.1085 -As uzbl does neither have its own download manager nor depends on a
  1.1086 -specific one, thus uzbl's browsing abilities will not be lowered by having
  1.1087 +Uzbl does neither have its own download manager nor depends on a
  1.1088 +specific one, hence uzbl's browsing abilities will not be lowered by having
  1.1089  a bad download manager.
  1.1090 -Uzbl's download capabilities will just as good as the ones of the best
  1.1091 +Uzbl's download capabilities will be just as good as the ones of the best
  1.1092  download manager available on the system.
  1.1093  Of course, this applies to all of the other supplementary tools, too.
  1.1094  
  1.1095  .PP
  1.1096  .B "Use software leverage to your advantage" .
  1.1097 -Shell scripts are a good choice to extend uzbl.
  1.1098  Uzbl is designed to be extended by external tools.
  1.1099  These external tools are usually wrapped by small handler shell scripts.
  1.1100  Shell scripts are the glue in this approach.
  1.1101  They make the various parts fit together.
  1.1102  .PP
  1.1103 -As an example, the history mechanism of uzbl shall be presented.
  1.1104 +The history mechanism of uzbl shall be presented as an example.
  1.1105  Uzbl is configured to spawn a script to append an entry to the history
  1.1106  whenever the event of a fully loaded page occurs.
  1.1107 -The script to append the entry to the history not much more than:
  1.1108 +The script to append the entry to the history is not much more than:
  1.1109  .DS
  1.1110  .CW
  1.1111  #!/bin/sh
  1.1112 @@ -1349,11 +1353,13 @@
  1.1113  echo `date +'%Y-%m-%d %H:%M:%S'`" $6 $7" >> $file
  1.1114  .DE
  1.1115  \f(CW$6\fP and \f(CW$7\fP expand to the \s-1URL\s0 and the page title.
  1.1116 -For loading an entry, a key is bound to spawn a load from history script.
  1.1117 +.PP
  1.1118 +For loading an entry, a key is bound to spawn a load-from-history script.
  1.1119  The script reverses the history to have newer entries first,
  1.1120 -then displays \fIdmenu\fP to select an item,
  1.1121 +then displays \fIdmenu\fP to let the user select an item,
  1.1122  and afterwards writes the selected \s-1URL\s0 into uzbl's command input pipe.
  1.1123 -With error checking and corner cases removed, the script looks like this:
  1.1124 +With error checking and corner case handling removed,
  1.1125 +the script looks like this:
  1.1126  .DS
  1.1127  .CW
  1.1128  #!/bin/sh
  1.1129 @@ -1369,10 +1375,11 @@
  1.1130  One could say, that uzbl, to a large extend, actually \fIis\fP
  1.1131  a captive user interface.
  1.1132  But the difference to most other web browsers is, that uzbl is only
  1.1133 -the captive user interface frontend and the core of the backend.
  1.1134 +the captive user interface frontend (and the core of the backend).
  1.1135  Many parts of the backend are independent of uzbl.
  1.1136 -Some are distributed with uzbl, for some external programs, handler scripts
  1.1137 -are distributed, arbitrary additional functionality can be added if desired.
  1.1138 +Some are distributed with uzbl, for some external programs,
  1.1139 +handler scripts are distributed,
  1.1140 +but arbitrary additional functionality can be added if desired.
  1.1141  .PP
  1.1142  The frontend is captive \(en that is true.
  1.1143  This is okay for the task of browsing the web, as this task is only relevant
  1.1144 @@ -1387,20 +1394,20 @@
  1.1145  .B "Make every program a filter" .
  1.1146  Graphical web browsers are almost dead ends in the chain of information flow.
  1.1147  Thus it is difficult to see what graphical web browsers should filter.
  1.1148 -Graphical web browsers exist almost only for interactive use by humans.
  1.1149 +Graphical web browsers exist almost only to be interactively used by humans.
  1.1150  The only case when one might want to automate the rendering function is
  1.1151  to generate images of rendered webpages.
  1.1152  
  1.1153  .PP
  1.1154  .B "Small is beautiful"
  1.1155 -is not easy to apply to a web browser, primary because modern web technology
  1.1156 -is very complex; hence the rendering task is very complex.
  1.1157 -Modern web browsers will always consist of many thousand lines of code,
  1.1158 +is not easy to apply to a web browser, because modern web technology
  1.1159 +is very complex, hence the rendering task is very complex.
  1.1160 +Modern web browsers have to consist of many thousand lines of code,
  1.1161  unfortunately.
  1.1162  Using the toolchest approach and wrappers can split the browser into
  1.1163  several small parts, tough.
  1.1164  .PP
  1.1165 -Uzbl-core consists of about 3\,500 lines of C code.
  1.1166 +As of March 2010, uzbl-core consists of about 3\,500 lines of C code.
  1.1167  The distribution includes another 3\,500 lines of Shell and Python code,
  1.1168  which are the handler scripts and plugins like a modal interface.
  1.1169  Further more, uzbl uses functionality of external tools like
  1.1170 @@ -1410,7 +1417,6 @@
  1.1171  Webkit consists of roughly 400\,000 (!) lines of code.
  1.1172  Unfortunately, small web render engines are not possible anymore
  1.1173  because of the modern web.
  1.1174 -The problems section will explain this in more detail.
  1.1175  
  1.1176  .PP
  1.1177  .B "Build a prototype as soon as possible" .
  1.1178 @@ -1421,7 +1427,8 @@
  1.1179  Within the first year of uzbl's existence, a new version was released
  1.1180  more often than once a month.
  1.1181  Different forks and branches arose.
  1.1182 -They introduced new features, which were tested for suitability.
  1.1183 +They introduced new features, which were tested for suitability
  1.1184 +for the main branch.
  1.1185  The experiences of using prototypes influenced further development.
  1.1186  Actually, all development was community driven.
  1.1187  Plaetinck says, three months after uzbl's birth:
  1.1188 @@ -1447,7 +1454,7 @@
  1.1189  But uzbl has to provide this similar look and feel to be accepted
  1.1190  as a ``normal'' browser by ``normal'' users.
  1.1191  .PP
  1.1192 -The more important problem is the modern web.
  1.1193 +Though, the more important problem is the modern web.
  1.1194  The modern web is simply broken.
  1.1195  It has state in a state-less protocol,
  1.1196  it misuses technologies,
  1.1197 @@ -1455,7 +1462,7 @@
  1.1198  The result are web content render engines that must consist
  1.1199  of hundreds of thousands lines of code.
  1.1200  They also must combine and integrate many different technologies,
  1.1201 -only to make our modern web usable.
  1.1202 +only to make our modern web accessible.
  1.1203  Website to image converter are hardly possible to run without
  1.1204  human interaction because of state in sessions, impossible
  1.1205  deep-linking, and unautomatable technologies.
  1.1206 @@ -1474,12 +1481,11 @@
  1.1207  that is how uzbl is seen by its authors.
  1.1208  Indeed, uzbl follows the Unix Philosophy in many ways.
  1.1209  It consists of independent parts that work together,
  1.1210 -its core is mainly a mediator which glues the parts together.
  1.1211 +while its core is mainly a mediator which glues the parts together.
  1.1212  .PP
  1.1213  Software leverage can excellently be seen in uzbl.
  1.1214 -It makes use of external tools, separates independent tasks
  1.1215 -in independent parts, and glues them together with small
  1.1216 -handler scripts, around uzbl-core.
  1.1217 +External tools are used, independent tasks are separated
  1.1218 +in independent parts and glued together with small handler scripts.
  1.1219  .PP
  1.1220  As uzbl, more or less, consists of a set of tools and a bit
  1.1221  of glue, anyone can put the parts together and expand it
  1.1222 @@ -1488,7 +1494,7 @@
  1.1223  These properties make it valuable for advanced users,
  1.1224  but may keep novice users from using it.
  1.1225  .PP
  1.1226 -Uzbl's main problem is the modern web, that makes it hard
  1.1227 +But uzbl's main problem is the modern web, that makes it hard
  1.1228  to design a sane web browser.
  1.1229  Despite this bad situation, uzbl does a fairly good job.
  1.1230