1.1 --- a/unix-phil.ms	Sun Apr 18 10:37:24 2010 +0200
     1.2 +++ b/unix-phil.ms	Sun Apr 18 20:44:15 2010 +0200
     1.3 @@ -206,7 +206,7 @@
     1.4  
     1.5  .H 1 "The Unix Philosophy
     1.6  .LP
     1.7 -The origins of the Unix Philosophy were already introduced.
     1.8 +The origins of the Unix Philosophy have already been introduced.
     1.9  This chapter explains the philosophy, oriented on Gancarz,
    1.10  .[
    1.11  gancarz
    1.12 @@ -216,7 +216,7 @@
    1.13  
    1.14  .H 2 Pipes
    1.15  .LP
    1.16 -Following are some examples to demonstrate how applied Unix Philosophy feels like.
    1.17 +The following examples demonstrate how the Unix Philosophy is applied.
    1.18  Knowledge of using the Unix shell is assumed.
    1.19  .PP
    1.20  Counting the number of files in the current directory:
    1.21 @@ -239,7 +239,7 @@
    1.22  to remove all lines that contain ``foo''.
    1.23  The rest equals the previous example.
    1.24  .PP
    1.25 -Finding the five largest entries in the current directory.
    1.26 +Finding the five largest entries in the current directory:
    1.27  .DS
    1.28  du -s * | sort -nr | sed 5q
    1.29  .DE
    1.30 @@ -254,18 +254,18 @@
    1.31  .PP
    1.32  The presented command lines are examples of what Unix people would use
    1.33  to get the desired output.
    1.34 -There are also other ways to get the same output.
    1.35 -It's a user's decision which way to go.
    1.36 +There are other ways to get the same output;
    1.37 +it is the user's decision which way to go.
    1.38  .PP
    1.39  The examples show that many tasks on a Unix system
    1.40  are accomplished by combining several small programs.
    1.41 -The connection between the single programs is denoted by the pipe operator `|'.
    1.42 +The connection between the programs is denoted by the pipe operator `|'.
    1.43  .PP
    1.44  Pipes, and their extensive and easy use, are one of the great
    1.45  achievements of the Unix system.
    1.46 -Pipes between programs have been possible in earlier operating systems,
    1.47 -but it has never been a so central part of the concept.
    1.48 -When, in the early seventies, Doug McIlroy introduced pipes into the
    1.49 +Pipes were possible in earlier operating systems,
    1.50 +but never before have they been such a central part of the concept.
    1.51 +In the early seventies when Doug McIlroy introduced pipes into the
    1.52  Unix system,
    1.53  ``it was this concept and notation for linking several programs together
    1.54  that transformed Unix from a basic file-sharing system to an entirely new way of computing.''
    1.55 @@ -275,14 +275,14 @@
    1.56  .]
    1.57  .PP
    1.58  Being able to specify pipelines in an easy way is,
    1.59 -however, not enough by itself.
    1.60 -It is only one half.
    1.61 +however, not enough by itself;
    1.62 +it is only one half.
    1.63  The other is the design of the programs that are used in the pipeline.
    1.64 -They need interfaces that allow them to be used in such a way.
    1.65 +They need interfaces that allow them to be used in this way.
    1.66  
    1.67  .H 2 "Interface design
    1.68  .LP
    1.69 -Unix is, first of all, simple \(en Everything is a file.
    1.70 +Unix is, first of all, simple \(en everything is a file.
    1.71  Files are sequences of bytes, without any special structure.
    1.72  Programs should be filters, which read a stream of bytes from standard input (stdin)
    1.73  and write a stream of bytes to standard output (stdout).
    1.74 @@ -297,43 +297,44 @@
    1.75  If the programs are orthogonal to each other \(en the best case \(en
    1.76  then the set of different functions is greatest.
    1.77  .PP
    1.78 -Programs can also have a separate control interface,
    1.79 -besides their data interface.
    1.80 -The control interface is often called ``user interface'',
    1.81 +Programs can also have a separate control interface
    1.82 +in addition to their data interface.
    1.83 +The control interface is often called the ``user interface'',
    1.84  because it is usually designed to be used by humans.
    1.85 -The Unix Philosophy discourages to assume the user to be human.
    1.86 +The Unix Philosophy discourages the assumption that the user will be human.
    1.87  Interactive use of software is slow use of software,
    1.88  because the program waits for user input most of the time.
    1.89 -Interactive software requires the user to be in front of the computer.
    1.90 -Interactive software occupy the user's attention while they are running.
    1.91 +Interactive software also requires the user to be in front of the computer,
    1.92 +occupying his attention during usage.
    1.93  .PP
    1.94 -Now to come back to the idea of combining several small programs,
    1.95 -to have a more specific function.
    1.96 -If these single tools would all be interactive,
    1.97 +Now, back to the idea of combining several small programs
    1.98 +to perform a more specific function:
    1.99 +If these single tools were all interactive,
   1.100  how would the user control them?
   1.101 -It is not only a problem to control several programs at once,
   1.102 -if they run at the same time,
   1.103 -it also very inefficient to have to control each of the single programs
   1.104 -that are intended to act as one large program.
   1.105 -Hence, the Unix Philosophy discourages programs to demand interactive use.
   1.106 +It is not only a problem to control several programs at once
   1.107 +if they run at the same time;
   1.108 +it is also very inefficient to have to control each program
   1.109 +when they are intended to act in concert.
   1.110 +Hence, the Unix Philosophy discourages designing programs which demand
   1.111 +interactive use.
   1.112  The behavior of programs should be defined at invocation.
   1.113  This is done by specifying arguments to the program call
   1.114  (command line switches).
   1.115 -Gancarz discusses this topic as ``avoid captive user interfaces''.
   1.116 +Gancarz discusses this topic as ``avoid[ing] captive user interfaces''.
   1.117  .[ [
   1.118  gancarz unix philosophy
   1.119  .], page 88 ff.]
   1.120  .PP
   1.121 -Non-interactive use is, during development, also an advantage for testing.
   1.122 -Testing of interactive programs is much more complicated,
   1.123 -than testing of non-interactive programs.
   1.124 +Non-interactive use is also an advantage for testing during development.
   1.125 +Testing interactive programs is much more complicated
   1.126 +than testing non-interactive counterparts.
   1.127  
   1.128  .H 2 "The toolchest approach
   1.129  .LP
   1.130  A toolchest is a set of tools.
   1.131 -Instead of having one big tool for all tasks, one has many small tools,
   1.132 +Instead of one big tool for all tasks, there are many small tools,
   1.133  each for one task.
   1.134 -Difficult tasks are solved by combining several of the small, simple tools.
   1.135 +Difficult tasks are solved by combining several small, simple tools.
   1.136  .PP
   1.137  The Unix toolchest \fIis\fP a set of small, (mostly) non-interactive programs
   1.138  that are filters on byte streams.
   1.139 @@ -341,84 +342,88 @@
   1.140  Hence, the Unix toolchest provides a large set of functions
   1.141  that can be accessed by combining the programs in the desired way.
   1.142  .PP
   1.143 -There are also advantages for developing small toolchest programs.
   1.144 -It is easier and less error-prone to write small programs.
   1.145 -It is also easier and less error-prone to write a large set of small programs,
   1.146 -than to write one large program with all the functionality included.
   1.147 -If the small programs are combinable, then they offer even a larger set
   1.148 -of functions than the single large program.
   1.149 +The act of software development benefits from small toolchest programs, too.
   1.150 +Writing small programs is generally easier and less error-prone
   1.151 +than writing large programs.
   1.152 +Hence, writing a large set of small programs is still easier and
   1.153 +less error-prone than writing one large program with all the
   1.154 +functionality included.
   1.155 +If the small programs are combinable, then they offer even an even larger set
   1.156 +of functions than the single monolithic program.
   1.157  Hence, one gets two advantages out of writing small, combinable programs:
   1.158  They are easier to write and they offer a greater set of functions through
   1.159  combination.
   1.160  .PP
   1.161 -But there are also two main drawbacks of the toolchest approach.
   1.162 +There are also two main drawbacks of the toolchest approach.
   1.163  First, one simple, standardized interface has to be sufficient.
   1.164  If one feels the need for more ``logic'' than a stream of bytes,
   1.165 -then a different approach might be of need.
   1.166 -But it is also possible, that he just can not imagine a design where
   1.167 -a stream of bytes is sufficient.
   1.168 +then a different approach might be required.
   1.169 +Also, a design where a stream of bytes is sufficient,
   1.170 +might not be conceivable.
   1.171  By becoming more familiar with the ``Unix style of thinking'',
   1.172  developers will more often and easier find simple designs where
   1.173  a stream of bytes is a sufficient interface.
   1.174  .PP
   1.175 -The second drawback of a toolchest affects the users.
   1.176 -A toolchest is often more difficult to use.
   1.177 -It is necessary to become familiar with each of the tools,
   1.178 -to be able to use the right one in a given situation.
   1.179 -Additionally, one needs to combine the tools in a sensible way himself.
   1.180 -This is like a sharp knife \(en it is a powerful tool in the hand of a
   1.181 -master, but of no good value in the hand of an unskilled.
   1.182 -However, learning single, small tools of a toolchest is easier than
   1.183 +The second drawback of the toolchest approach concerns the users.
   1.184 +A toolchest is often more difficult to use because
   1.185 +it is necessary to become familiar with each tool and
   1.186 +be able to choose and use the right one in any given situation.
   1.187 +Additionally, one needs to know how to combine the tools in a sensible way.
   1.188 +The issue is similar to having a sharp knife \(en
   1.189 +it is a powerful tool in the hand of a master,
   1.190 +but of no value in the hand of an unskilled person.
   1.191 +However, learning single, small tools of a toolchest is often easier than
   1.192  learning a complex tool.
   1.193 -And the user will already have a basic understanding of a yet unknown tool,
   1.194 +The user will already have a basic understanding of an as yet unknown tool
   1.195  if the tools of a toolchest have a common, consistent style.
   1.196 -He will be able to transfer knowledge over from one tool to another.
   1.197 +He will be able to transfer knowledge of one tool to another.
   1.198  .PP
   1.199 -Moreover, the second drawback can be removed to a large extent
   1.200 +This second drawback can be removed to a large extent
   1.201  by adding wrappers around the basic tools.
   1.202 -Novice users do not need to learn several tools, if a professional wraps
   1.203 +Novice users do not need to learn several tools if a professional wraps
   1.204  complete command lines into a higher-level script.
   1.205  Note that the wrapper script still calls the small tools;
   1.206  it is just like a skin around them.
   1.207 -No complexity is added this way.
   1.208 -But new programs can get created out of existing one with very low effort.
   1.209 +No complexity is added this way,
   1.210 +but new programs can be created out of existing one with very little effort.
   1.211  .PP
   1.212  A wrapper script for finding the five largest entries in the current directory
   1.213 -could look like this:
   1.214 +might look like this:
   1.215  .DS
   1.216  #!/bin/sh
   1.217  du -s * | sort -nr | sed 5q
   1.218  .DE
   1.219 -The script itself is just a text file that calls the command line,
   1.220 -which a professional user would type in directly.
   1.221 -It is probably worth to make the program flexible on the number of
   1.222 -entries it prints:
   1.223 +The script itself is just a text file that calls the commands
   1.224 +that a professional user would type in directly.
   1.225 +It is probably beneficial to make the program flexible in regard to
   1.226 +the number of entries it prints:
   1.227  .DS
   1.228  #!/bin/sh
   1.229  num=5
   1.230  [ $# -eq 1 ] && num="$1"
   1.231  du -sh * | sort -nr | sed "${num}q"
   1.232  .DE
   1.233 -This script acts like the one before, when called without an argument.
   1.234 -But one can also specify a numerical argument to define the number of lines to print.
   1.235 -One can surely imagine even more flexible versions, however,
   1.236 -they will still relay on the external programs,
   1.237 -which do the actual work.
   1.238 +This script acts like the one before when called without an argument,
   1.239 +but the user can also specify a numerical argument to define the number
   1.240 +of lines to print.
   1.241 +One can surely imagine even more flexible versions;
   1.242 +however, they will still rely on the external programs
   1.243 +which actually do the work.
   1.244  
   1.245  .H 2 "A powerful shell
   1.246  .LP
   1.247 -The Unix shell provides the possibility to combine small programs into large ones.
   1.248 -But a powerful shell is a great feature in other ways, too.
   1.249 -For instance by being scriptable.
   1.250 -Control statements are built into the shell.
   1.251 -The functions, however, are the normal programs of the system.
   1.252 -Thus, as the programs are already known,
   1.253 +The Unix shell provides the ability to combine small programs into large ones.
   1.254 +But a powerful shell is a great feature in other ways, too;
   1.255 +for instance, by being scriptable.
   1.256 +Control statements are built into the shell
   1.257 +and the functions are the normal programs of the system.
   1.258 +As the programs are already known,
   1.259  learning to program in the shell becomes easy.
   1.260  Using normal programs as functions in the shell programming language
   1.261  is only possible because they are small and combinable tools in a toolchest style.
   1.262  .PP
   1.263 -The Unix shell encourages to write small scripts,
   1.264 -by combining existing programs, because it is so easy to do.
   1.265 +The Unix shell encourages writing small scripts,
   1.266 +by combining existing programs because it is so easy to do.
   1.267  This is a great step towards automation.
   1.268  It is wonderful if the effort to automate a task equals the effort
   1.269  to do the task a second time by hand.
   1.270 @@ -426,14 +431,14 @@
   1.271  then the user will be happy to automate everything he does more than once.
   1.272  .PP
   1.273  Small programs that do one job well, standardized interfaces between them,
   1.274 -a mechanism to combine parts to larger parts, and an easy way to automate tasks,
   1.275 -this will inevitably produce software leverage.
   1.276 -Getting multiple times the benefit of an investment is a great offer.
   1.277 +a mechanism to combine parts to larger parts, and an easy way to automate tasks
   1.278 +will inevitably produce software leverage,
   1.279 +achieving multiple times the benefit of the initial investment.
   1.280  .PP
   1.281  The shell also encourages rapid prototyping.
   1.282  Many well known programs started as quickly hacked shell scripts,
   1.283 -and turned into ``real'' programs, written in C, later.
   1.284 -Building a prototype first, is a way to avoid the biggest problems
   1.285 +and turned into ``real'' programs later written in C.
   1.286 +Building a prototype first is a way to avoid the biggest problems
   1.287  in application development.
   1.288  Fred Brooks explains in ``No Silver Bullet'':
   1.289  .[
   1.290 @@ -457,14 +462,18 @@
   1.291  Prototyping is often seen as a first step in building software.
   1.292  This is, of course, good.
   1.293  However, the Unix Philosophy has an \fIadditional\fP perspective on prototyping:
   1.294 -After having built the prototype, one might notice, that the prototype is already
   1.295 +After having built the prototype, one might notice that the prototype is already
   1.296  \fIgood enough\fP.
   1.297 -Hence, no reimplementation, in a more sophisticated programming language,
   1.298 +Hence, no reimplementation in a more sophisticated programming language
   1.299  might be of need, at least for the moment.
   1.300  Maybe later, it might be necessary to rewrite the software, but not now.
   1.301  By delaying further work, one keeps the flexibility to react on
   1.302  changing requirements.
   1.303  Software parts that are not written will not miss the requirements.
   1.304 +Well known is Gordon Bell's classic saying:
   1.305 +``The cheapest, fastest, and most reliable components are those
   1.306 +that aren't there.''
   1.307 +.\" FIXME: ref?
   1.308  
   1.309  .H 2 "Worse is better
   1.310  .LP
   1.311 @@ -472,21 +481,21 @@
   1.312  others call it the ``Worse is better'' approach.
   1.313  Experience from real life projects shows:
   1.314  .PP
   1.315 -(1) It is almost never possible to define the
   1.316 +(1) It is almost impossible to define the
   1.317  requirements completely and correctly the first time.
   1.318  Hence one should not try to; one will fail anyway.
   1.319  .PP
   1.320  (2) Requirements change during time.
   1.321  Hence it is best to delay requirement-based design decisions as long as possible.
   1.322 -Software should be small and flexible as long as possible
   1.323 -to react on changing requirements.
   1.324 -Shell scripts, for example, are more easily adjusted as C programs.
   1.325 +Software should be small and flexible as long as possible in order
   1.326 +to react to changing requirements.
   1.327 +Shell scripts, for example, are more easily adjusted than C programs.
   1.328  .PP
   1.329  (3) Maintenance work is hard work.
   1.330  Hence, one should keep the amount of code as small as possible;
   1.331 -it should just fulfill the \fIcurrent\fP requirements.
   1.332 -Software parts that will be written in future,
   1.333 -do not need maintenance till then.
   1.334 +it should only fulfill the \fIcurrent\fP requirements.
   1.335 +Software parts that will be written in the future
   1.336 +do not need maintenance until that time.
   1.337  .PP
   1.338  See Brooks' ``The Mythical Man-Month'' for reference.
   1.339  .[ [
   1.340 @@ -498,35 +507,35 @@
   1.341  .IP \(bu
   1.342  As the initial effort is low, one will likely start right away.
   1.343  .IP \(bu
   1.344 -As working parts are available soon, the real requirements can get identified soon.
   1.345 +Real requirements can be identified quickly since working parts are
   1.346 +available sooner.
   1.347  .IP \(bu
   1.348  When software is usable and valuable, it gets used, and thus tested.
   1.349 -Hence problems will be found at early stages of the development.
   1.350 +This ensures that problems will be found in the early stages of development.
   1.351  .IP \(bu
   1.352 -The prototype might be enough for the moment,
   1.353 -thus further work can get delayed to a time
   1.354 -when one knows better about the requirements and problems,
   1.355 -than now.
   1.356 +The prototype might be enough for the moment;
   1.357 +thus, further work can be delayed until a time
   1.358 +when one knows about the requirements and problems more thoroughly.
   1.359  .IP \(bu
   1.360 -Implementing now only the parts that are actually needed at the moment,
   1.361 -introduces fewer programming and maintenance work.
   1.362 +Implementing only the parts that are actually needed at the moment
   1.363 +introduces less programming and maintenance work.
   1.364  .IP \(bu
   1.365 -If the global situation changes so that the software is not needed anymore,
   1.366 -then less effort was spent into the project, than it would have be
   1.367 -when a different approach had been used.
   1.368 +If the situation changes such that the software is not needed anymore,
   1.369 +then less effort was spent on the project than it would have been
   1.370 +if a different approach had been taken.
   1.371  
   1.372  .H 2 "Upgrowth and survival of software
   1.373  .LP
   1.374 -So far it was talked about \fIwriting\fP or \fIbuilding\fP software.
   1.375 -Although these are just verbs, they do imply a specific view on the work process
   1.376 -they describe.
   1.377 -The better verb, however, is to \fIgrow\fP.
   1.378 +So far, \fIwriting\fP or \fIbuilding\fP software has been discussed.
   1.379 +Although ``writing'' and ``building'' are just verbs,
   1.380 +they do imply a specific view on the work process they describe.
   1.381 +A better verb would be to \fI``grow''\fP.
   1.382  Creating software in the sense of the Unix Philosophy is an incremental process.
   1.383 -It starts with a first prototype, which evolves as requirements change.
   1.384 +It starts with an initial prototype, which evolves as requirements change.
   1.385  A quickly hacked shell script might become a large, sophisticated,
   1.386  compiled program this way.
   1.387  Its lifetime begins with the initial prototype and ends when the software is not used anymore.
   1.388 -While being alive it will get extended, rearranged, rebuilt.
   1.389 +While alive, it will be extended, rearranged, rebuilt.
   1.390  Growing software matches the view that ``software is never finished. It is only released.''
   1.391  .[ [
   1.392  gancarz
   1.393 @@ -535,44 +544,44 @@
   1.394  .PP
   1.395  Software can be seen as being controlled by evolutionary processes.
   1.396  Successful software is software that is used by many for a long time.
   1.397 -This implies that the software is needed, useful, and better than alternatives.
   1.398 -Darwin talks about: ``The survival of the fittest.''
   1.399 +This implies that the software is necessary, useful, and better than the alternatives.
   1.400 +Darwin describes ``the survival of the fittest.''
   1.401  .[
   1.402  darwin
   1.403  origin of species
   1.404  .]
   1.405 -Transferred to software: The most successful software, is the fittest,
   1.406 -is the one that survives.
   1.407 +In relation to software, the most successful software is the fittest;
   1.408 +the one that survives.
   1.409  (This may be at the level of one creature, or at the level of one species.)
   1.410  The fitness of software is affected mainly by four properties:
   1.411  portability of code, portability of data, range of usability, and reusability of parts.
   1.412  .PP
   1.413  (1)
   1.414 -.I "Portability of code
   1.415 -means, using high-level programming languages,
   1.416 +.I "``Portability of code''
   1.417 +means using high-level programming languages,
   1.418  sticking to the standard,
   1.419  .[ [
   1.420  kernighan pike
   1.421  practice of programming
   1.422  .], chapter\|8]
   1.423  and avoiding optimizations that introduce dependencies on specific hardware.
   1.424 -Hardware has a much lower lifetime than software.
   1.425 -By chaining software to a specific hardware,
   1.426 -its lifetime gets shortened to that of this hardware.
   1.427 +Hardware has a much shorter lifespan than software.
   1.428 +By chaining software to specific hardware,
   1.429 +its lifetime is limited to that of this hardware.
   1.430  In contrast, software should be easy to port \(en
   1.431  adaptation is the key to success.
   1.432  .PP
   1.433  (2)
   1.434 -.I "Portability of data
   1.435 +.I "``Portability of data''
   1.436  is best achieved by avoiding binary representations
   1.437 -to store data, because binary representations differ from machine to machine.
   1.438 +to store data, since binary representations differ from machine to machine.
   1.439  Textual representation is favored.
   1.440 -Historically, \s-1ASCII\s0 was the charset of choice.
   1.441 -For the future, \s-1UTF\s0-8 might be the better choice.
   1.442 +Historically, \s-1ASCII\s0 was the character set of choice;
   1.443 +for the future, \s-1UTF\s0-8 might be the better way forward.
   1.444  Important is that it is a plain text representation in a
   1.445 -very common charset encoding.
   1.446 +very common character set encoding.
   1.447  Apart from being able to transfer data between machines,
   1.448 -readable data has the great advantage, that humans are able to directly
   1.449 +readable data has the great advantage that humans are able to directly
   1.450  read and edit it with text editors and other tools from the Unix toolchest.
   1.451  .[ [
   1.452  gancarz
   1.453 @@ -581,15 +590,15 @@
   1.454  .PP
   1.455  (3)
   1.456  A large
   1.457 -.I "range of usability
   1.458 +.I "``range of usability''
   1.459  ensures good adaptation, and thus good survival.
   1.460 -It is a special distinction if software becomes used in fields of action,
   1.461 -the original authors did never imagine.
   1.462 +It is a special distinction when software becomes used in fields of endeavor,
   1.463 +the original authors never imagined.
   1.464  Software that solves problems in a general way will likely be used
   1.465  for many kinds of similar problems.
   1.466  Being too specific limits the range of usability.
   1.467  Requirements change through time, thus use cases change or even vanish.
   1.468 -As a good example in this point,
   1.469 +As a good example of this point,
   1.470  Allman identifies flexibility to be one major reason for sendmail's success:
   1.471  .[
   1.472  allman
   1.473 @@ -605,27 +614,28 @@
   1.474  Successful software adapts itself to the changing world.
   1.475  .PP
   1.476  (4)
   1.477 -.I "Reuse of parts
   1.478 -is even one step further.
   1.479 -Software may completely lose its field of action,
   1.480 -but parts of which the software is built may be general and independent enough
   1.481 +.I "``Reusability of parts''
   1.482 +goes one step further.
   1.483 +Software may become obsolete and completely lose its field of action,
   1.484 +but the constituent parts of the software may be general and independent enough
   1.485  to survive this death.
   1.486  If software is built by combining small independent programs,
   1.487  then these parts are readily available for reuse.
   1.488 -Who cares if the large program is a failure,
   1.489 -but parts of it become successful instead?
   1.490 +Who cares that the large program is a failure,
   1.491 +if parts of it become successful instead?
   1.492  
   1.493  .H 2 "Summary
   1.494  .LP
   1.495 -This chapter explained central ideas of the Unix Philosophy.
   1.496 +This chapter explained ideas central to the Unix Philosophy.
   1.497  For each of the ideas, the advantages they introduce were explained.
   1.498 -The Unix Philosophy are guidelines that help to write more valuable software.
   1.499 -From the view point of a software developer or software designer,
   1.500 -the Unix Philosophy provides answers to many software design problem.
   1.501 +The Unix Philosophy is a set of guidelines that help in the design of
   1.502 +more valuable software.
   1.503 +From the viewpoint of a software developer or software designer,
   1.504 +the Unix Philosophy provides answers to many software design problems.
   1.505  .PP
   1.506 -The various ideas of the Unix Philosophy are very interweaved
   1.507 +The various ideas comprising the Unix Philosophy are very interweaved
   1.508  and can hardly be applied independently.
   1.509 -However, the probably most important messages are:
   1.510 +The most important messages are:
   1.511  .I "``Keep it simple!''" ,
   1.512  .I "``Do one thing well!''" ,
   1.513  and
   1.514 @@ -637,8 +647,8 @@
   1.515  .LP
   1.516  The previous chapter introduced and explained the Unix Philosophy
   1.517  from a general point of view.
   1.518 -The driving force were the guidelines; references to
   1.519 -existing software were given only sparsely.
   1.520 +The driving force was that of the guidelines;
   1.521 +references to existing software were given only sparsely.
   1.522  In this and the next chapter, concrete software will be
   1.523  the driving force in the discussion.
   1.524  .PP
   1.525 @@ -657,7 +667,7 @@
   1.526  
   1.527  .H 2 "Historical background
   1.528  .LP
   1.529 -Electronic mail was available in Unix very early.
   1.530 +Electronic mail was available in Unix from a very early stage.
   1.531  The first \s-1MUA\s0 on Unix was \f(CWmail\fP,
   1.532  which was already present in the First Edition.
   1.533  .[ [
   1.534 @@ -676,27 +686,26 @@
   1.535  Later, emailing became more powerful, and thus more complex.
   1.536  The simple \f(CWmail\fP, which knew nothing of subjects,
   1.537  independent handling of single messages,
   1.538 -and long-time email storage, was not powerful enough anymore.
   1.539 -In 1978 at Berkeley, Kurt Shoens wrote \fIMail\fP (with capital `M')
   1.540 +and long-term email storage, was not powerful enough anymore.
   1.541 +In 1978 at Berkeley, Kurt Shoens wrote \fIMail\fP (with a capital `M')
   1.542  to provide additional functions for emailing.
   1.543 -Mail was still one program, but now it was large and did
   1.544 -several jobs.
   1.545 -Its user interface is modeled after the one of \fIed\fP.
   1.546 -It is designed for humans, but is still scriptable.
   1.547 -\fImailx\fP is the adaptation of Berkeley Mail into System V.
   1.548 +Mail was still one program, but was large and did several jobs.
   1.549 +Its user interface was modeled after \fIed\fP.
   1.550 +Ed is designed for humans, but is still scriptable.
   1.551 +\fImailx\fP is the adaptation of Berkeley Mail for System V.
   1.552  .[
   1.553  ritter
   1.554  mailx history
   1.555  .]
   1.556 -Elm, pine, mutt, and a whole bunch of graphical \s-1MUA\s0s
   1.557 -followed Mail's direction.
   1.558 -They are large, monolithic programs which include all emailing functions.
   1.559 +Elm, pine, mutt, and a slew of graphical \s-1MUA\s0s
   1.560 +followed Mail's direction:
   1.561 +large, monolithic programs which included all emailing functions.
   1.562  .PP
   1.563  A different way was taken by the people of \s-1RAND\s0 Corporation.
   1.564 -In the beginning, they also had used a monolithic mail system,
   1.565 +Initially, they also had used a monolithic mail system
   1.566  called \s-1MS\s0 (for ``mail system'').
   1.567  But in 1977, Stockton Gaines and Norman Shapiro
   1.568 -came up with a proposal of a new email system concept \(en
   1.569 +came up with a proposal for a new email system concept \(en
   1.570  one that honored the Unix Philosophy.
   1.571  The concept was implemented by Bruce Borden in 1978 and 1979.
   1.572  This was the birth of \s-1MH\s0 \(en the ``mail handler''.
   1.573 @@ -706,7 +715,7 @@
   1.574  However, it's core concepts remained the same.
   1.575  In the late 90s, when development of \s-1MH\s0 slowed down,
   1.576  Richard Coleman started with \fInmh\fP, the new mail handler.
   1.577 -His goal was to improve \s-1MH\s0 especially in regard of 
   1.578 +His goal was to improve \s-1MH\s0 especially in regard to
   1.579  the requirements of modern emailing.
   1.580  Today, nmh is developed by various people on the Internet.
   1.581  .[
   1.582 @@ -721,14 +730,14 @@
   1.583  .H 2 "Contrasts to monolithic mail systems
   1.584  .LP
   1.585  All \s-1MUA\s0s are monolithic, except \s-1MH\s0.
   1.586 -Although there might actually exist further, very little known,
   1.587 -toolchest \s-1MUA\s0s, this statement reflects the situation pretty well.
   1.588 +Although some very little known toolchest \s-1MUA\s0s might also exist,
   1.589 +this statement reflects the situation pretty well.
   1.590  .PP
   1.591  Monolithic \s-1MUA\s0s gather all their functions in one program.
   1.592  In contrast, \s-1MH\s0 is a toolchest of many small tools \(en one for each job.
   1.593  Following is a list of important programs of \s-1MH\s0's toolchest
   1.594  and their function.
   1.595 -It gives a feeling of how the toolchest looks like.
   1.596 +It gives an indication of what the toolchest looks like.
   1.597  .IP \(bu
   1.598  .CW inc :
   1.599  incorporate new mail (this is how mail enters the system)
   1.600 @@ -764,7 +773,7 @@
   1.601  send prepared message (this is how mail leaves the system)
   1.602  .LP
   1.603  \s-1MH\s0 has no special user interface like monolithic \s-1MUA\s0s have.
   1.604 -The user does not leave the shell to run \s-1MH\s0,
   1.605 +The user does not leave the shell to run \s-1MH\s0;
   1.606  instead he uses the various \s-1MH\s0 programs within the shell.
   1.607  Using a monolithic program with a captive user interface
   1.608  means ``entering'' the program, using it, and ``exiting'' the program.
   1.609 @@ -774,24 +783,24 @@
   1.610  
   1.611  .H 2 "Data storage
   1.612  .LP
   1.613 -\s-1MH\s0's mail storage is a directory tree under the user's
   1.614 +\s-1MH\s0's mail storage consists of a hierarchy under the user's
   1.615  \s-1MH\s0 directory (usually \f(CW$HOME/Mail\fP),
   1.616  where mail folders are directories and mail messages are text files
   1.617  within them.
   1.618  Each mail folder contains a file \f(CW.mh_sequences\fP which lists
   1.619  the public message sequences of that folder,
   1.620 -for instance the \fIunseen\fP sequence for new messages.
   1.621 +for instance, the \fIunseen\fP sequence for new messages.
   1.622  Mail messages are text files located in a mail folder.
   1.623 -The files contain the messages as they were received.
   1.624 -They are named by ascending numbers in each folder.
   1.625 +The files contain the messages as they were received,
   1.626 +and they are named by ascending numbers in each folder.
   1.627  .PP
   1.628  This mailbox format is called ``\s-1MH\s0'' after the \s-1MUA\s0.
   1.629  Alternatives are \fImbox\fP and \fImaildir\fP.
   1.630 -In the mbox format all messages are stored within one file.
   1.631 +In the mbox format, all messages are stored within one file.
   1.632  This was a good solution in the early days, when messages
   1.633 -were only a few lines of text and were deleted soon.
   1.634 -Today, when single messages often include several megabytes
   1.635 -of attachments, it is a bad solution.
   1.636 +were only a few lines of text deleted within a short period of time.
   1.637 +Today, with single messages often including several megabytes
   1.638 +of attachments, this is a bad solution.
   1.639  Another disadvantage of the mbox format is that it is
   1.640  more difficult to write tools that work on mail messages,
   1.641  because it is always necessary to first find and extract
   1.642 @@ -811,7 +820,7 @@
   1.643  \f(CWrefile\fP is like \f(CWmv\fP,
   1.644  and \f(CWrmm\fP is like \f(CWrm\fP.
   1.645  .PP
   1.646 -\s-1MH\s0 extends the context of processes in Unix by two more items,
   1.647 +\s-1MH\s0 extends the context of processes in Unix by two more items
   1.648  for its tools:
   1.649  .IP \(bu
   1.650  The current mail folder, which is similar to the current working directory.
   1.651 @@ -822,7 +831,8 @@
   1.652  The current message, relative to a mail folder, is a special sequence.
   1.653  It enables commands like \f(CWnext\fP and \f(CWprev\fP.
   1.654  .LP
   1.655 -In contrast to Unix' context, which is maintained by the kernel,
   1.656 +In contrast to the general process context in Unix,
   1.657 +which is maintained by the kernel,
   1.658  \s-1MH\s0's context must be maintained by the tools themselves.
   1.659  Usually there is one context per user, which resides in his
   1.660  \f(CWcontext\fP file in the \s-1MH\s0 directory,
   1.661 @@ -843,7 +853,7 @@
   1.662  and
   1.663  .B "do one thing well
   1.664  are two design goals that are directly visible in \s-1MH\s0.
   1.665 -Gancarz actually presents \s-1MH\s0 in his book as example under the
   1.666 +Gancarz actually uses \s-1MH\s0 in his book as example under the
   1.667  headline ``Making \s-1UNIX\s0 Do One Thing Well'':
   1.668  .[ [
   1.669  gancarz
   1.670 @@ -858,54 +868,55 @@
   1.671  components, but also that such designs are actually preferable.
   1.672  .LP
   1.673  The various programs of \s-1MH\s0 were relatively easy to write,
   1.674 -because each of them is small, limited to one function,
   1.675 -and has clear boundaries.
   1.676 -For the same reasons, they are also good to maintain.
   1.677 -Further more, the system can easily get extended.
   1.678 -One only needs to put a new program into the toolchest.
   1.679 -This was done, for instance, when \s-1MIME\s0 support was added
   1.680 +because each one was small, limited to one function,
   1.681 +and had clear boundaries.
   1.682 +For the same reasons, they are also easy to maintain.
   1.683 +Further more, the system can easily get extended:
   1.684 +One only needs to place a new program into the toolchest.
   1.685 +This was done when \s-1MIME\s0 support was added
   1.686  (e.g. \f(CWmhbuild\fP).
   1.687 -Also, different programs can exist to do the basically same job
   1.688 +Also, different programs can exist to do basically the same job
   1.689  in different ways (e.g. in nmh: \f(CWshow\fP and \f(CWmhshow\fP).
   1.690  .PP
   1.691 -If someone needs a mail system with some additionally
   1.692 -functions that are not available anywhere yet, he best expands a
   1.693 -toolchest system like \s-1MH\s0.
   1.694 +If someone needs a mail system with some additional
   1.695 +functionality that is not available anywhere yet,
   1.696 +it is beneficial to expand a toolchest system like \s-1MH\s0.
   1.697  There he can add new functionality by simply adding additional
   1.698 -programs to the toolchest.
   1.699 -There he does not risk to break existing functionality by doing so.
   1.700 +programs to the toolchest;
   1.701 +he does not risk to break existing functionality by doing so.
   1.702  
   1.703  .PP
   1.704 -.B "Store data in flat text files
   1.705 -is followed by \s-1MH\s0.
   1.706 +.B "Store data in flat text files" ;
   1.707 +this principle was followed by \s-1MH\s0.
   1.708  This is not surprising, because email messages are already plain text.
   1.709  \s-1MH\s0 stores the messages as it receives them,
   1.710 -thus any other tool that works on \s-1RFC\s0\|2822 mail messages can operate
   1.711 +thus any other tool that works on \s-1RFC\s0\|2822 compliant mail
   1.712 +messages can operate
   1.713  on the messages in an \s-1MH\s0 mailbox.
   1.714 -All other files \s-1MH\s0 uses are plain text, too.
   1.715 +All other files \s-1MH\s0 uses are plain text as well.
   1.716  It is therefore possible and encouraged to use the text processing
   1.717  tools of Unix' toolchest to extend \s-1MH\s0's toolchest.
   1.718  
   1.719  .PP
   1.720  .B "Avoid captive user interfaces" .
   1.721  \s-1MH\s0 is perfectly suited for non-interactive use.
   1.722 -It offers all functions directly and without captive user interfaces.
   1.723 -If, nonetheless, users want a graphical user interface,
   1.724 +It offers all functions directly, without captive user interfaces.
   1.725 +If users want a graphical user interface,
   1.726  they can have it with \fIxmh\fP, \fIexmh\fP,
   1.727  or with the Emacs interface \fImh-e\fP.
   1.728  These are frontends for the \s-1MH\s0 toolchest.
   1.729 -This means, all email-related work is still done by \s-1MH\s0 tools,
   1.730 +This means all email-related work is still done by \s-1MH\s0 tools,
   1.731  but the frontend calls the appropriate commands when the user
   1.732  clicks on buttons or pushes a key.
   1.733  .PP
   1.734 -Providing easy-to-use user interfaces in form of frontends is a good
   1.735 +Providing additional user interfaces in form of frontends is a good
   1.736  approach, because it does not limit the power of the backend itself.
   1.737 -The frontend will anyway only be able to make a subset of the
   1.738 -backend's power and flexibility available to the user.
   1.739 -But if it is a separate program,
   1.740 +The frontend will only be able to make a subset of the
   1.741 +backend's power and flexibility available to the user,
   1.742 +but if it is a separate program,
   1.743  then the missing parts can still be accessed at the backend directly.
   1.744 -If it is integrated, then this will hardly be possible.
   1.745 -An additional advantage is the possibility to have different frontends
   1.746 +If it is integrated, then this will be much more difficult.
   1.747 +An additional advantage is the ability to have different frontends
   1.748  to the same backend.
   1.749  
   1.750  .PP
   1.751 @@ -920,18 +931,18 @@
   1.752  .]
   1.753  Chapter\|18 of the book shows a basic implementation
   1.754  of a subset of \s-1MH\s0 in ksh scripts.
   1.755 -Of course, this is just a demonstration, but a brilliant one.
   1.756 +This is just a demonstration, but a brilliant one.
   1.757  It shows how quickly one can implement such a prototype with shell scripts,
   1.758  and how readable they are.
   1.759 -The implementation in the scripting language may not be very fast,
   1.760 -but it can be fast enough though, and this is all that matters.
   1.761 +The implementation in scripting language may not be very fast,
   1.762 +but it can be fast enough, and this is all that matters.
   1.763  By having the code in an interpreted language, like the shell,
   1.764 -portability becomes a minor issue, if we assume the interpreter
   1.765 +portability becomes a minor issue if we assume the interpreter
   1.766  to be widespread.
   1.767  .PP
   1.768  This demonstration also shows how easy it is to create single programs
   1.769 -of a toolchest software.
   1.770 -Eight tools (two of them have multiple names) and 16 functions
   1.771 +of toolchest software.
   1.772 +Eight tools (two of them having multiple names) and 16 functions
   1.773  with supporting code are presented to the reader.
   1.774  The tools comprise less than 40 lines of ksh each,
   1.775  in total about 200 lines.
   1.776 @@ -939,8 +950,8 @@
   1.777  in total about 450 lines.
   1.778  Such small software is easy to write, easy to understand,
   1.779  and thus easy to maintain.
   1.780 -A toolchest improves the possibility to only write some parts
   1.781 -and though create a working result.
   1.782 +A toolchest improves one's ability to only write some parts of a
   1.783 +program while still creating a working result.
   1.784  Expanding the toolchest, even without global changes,
   1.785  will likely be possible.
   1.786  
   1.787 @@ -956,10 +967,10 @@
   1.788  Software leverage is heavily encouraged by the ease of
   1.789  creating shell scripts that run a specific command line,
   1.790  built of several \s-1MH\s0 programs.
   1.791 -There is few software that so much wants users to tailor their
   1.792 -environment and to leverage the use of the software, like \s-1MH\s0.
   1.793 +There are few pieces of software that encourages users to tailor their
   1.794 +environment and to leverage the use of the software like \s-1MH\s0.
   1.795  .PP
   1.796 -Just to make one example:
   1.797 +Just to cite one example:
   1.798  One might prefer a different listing format for the \f(CWscan\fP
   1.799  program.
   1.800  It is possible to take one of the distributed format files
   1.801 @@ -970,31 +981,31 @@
   1.802  scan: -form FORMATFILE
   1.803  .DE
   1.804  must be added to \f(CW.mh_profile\fP.
   1.805 -If one wants this different format as an additional command,
   1.806 -instead of changing the default, he needs to create a link to
   1.807 +If one wants this alternative format available as an additional command,
   1.808 +instead of changing the default, he just needs to create a link to
   1.809  \f(CWscan\fP, for instance titled \f(CWscan2\fP.
   1.810  The line in \f(CW.mh_profile\fP would then start with \f(CWscan2\fP,
   1.811 -as the option should only be in effect for a program that is called as
   1.812 +as the option should only be in effect for a program that is invoked as
   1.813  \f(CWscan2\fP.
   1.814  
   1.815  .PP
   1.816  .B "Make every program a filter
   1.817 -is hard to find in \s-1MH\s0.
   1.818 -The reason therefore is that most of \s-1MH\s0's tools provide
   1.819 +is hard to find implemented in \s-1MH\s0.
   1.820 +The reason is that most of \s-1MH\s0's tools provide
   1.821  basic file system operations for mailboxes.
   1.822 -It is the same reason because of which \f(CWls\fP, \f(CWcp\fP, \f(CWmv\fP,
   1.823 +It is for the same reason because that \f(CWls\fP, \f(CWcp\fP, \f(CWmv\fP,
   1.824  and \f(CWrm\fP aren't filters neither.
   1.825 -\s-1MH\s0 does not provide many filters itself, but it is a basis
   1.826 -to write filters for.
   1.827 +\s-1MH\s0 does not provide many filters itself,
   1.828 +but it provides a basis upon which to write filters.
   1.829  An example would be a mail text highlighter,
   1.830 -that means a program that makes use of a color terminal to display
   1.831 -header lines, quotations, and signatures in distinct colors.
   1.832 +a program that makes use of a color terminal to display header lines,
   1.833 +quotations, and signatures in distinct colors.
   1.834  The author's version of such a program is an awk script with 25 lines.
   1.835  
   1.836  .PP
   1.837  .B "Build a prototype as soon as possible
   1.838  was again well followed by \s-1MH\s0.
   1.839 -This tenet, of course, focuses on early development, which is
   1.840 +This tenet, of course, focuses on early development, which is a
   1.841  long time ago for \s-1MH\s0.
   1.842  But without following this guideline at the very beginning,
   1.843  Bruce Borden may have not convinced the management of \s-1RAND\s0
   1.844 @@ -1019,33 +1030,37 @@
   1.845  
   1.846  .H 2 "Problems
   1.847  .LP
   1.848 -\s-1MH\s0 is not without problems.
   1.849 -There are two main problems: one is technical, the other is about human behavior.
   1.850 +\s-1MH\s0 is not without its problems.
   1.851 +There are two main problems: one is technical, the other pertains to human behavior.
   1.852  .PP
   1.853 -\s-1MH\s0 is old and email today is very different to email in the time
   1.854 +\s-1MH\s0 is old and email today is quite different than it was in the time
   1.855  when \s-1MH\s0 was designed.
   1.856 -\s-1MH\s0 adapted to the changes pretty well, but it is limited, though.
   1.857 +\s-1MH\s0 adapted to the changes fairly well, but it has its limitations.
   1.858  \s-1MIME\s0 support and support for different character encodings
   1.859  is available, but only on a moderate level.
   1.860  This comes from limited development resources.
   1.861 -More active developers could quickly change this.
   1.862 +A larger and more active developer base could quickly remedy this.
   1.863  But \s-1MH\s0 is also limited by design, which is the larger problem.
   1.864  \s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extent.
   1.865 -These design conflicts are not easily solvable.
   1.866 -Possibly, they require a redesign.
   1.867 -\s-1IMAP\s0 may be too different to the classic mail model,
   1.868 -which \s-1MH\s0 covers, so that \s-1MH\s0 may never support it well.
   1.869 +These design conflicts are not easily solvable
   1.870 +and may require a redesign.
   1.871 +\s-1IMAP\s0 may be too incompatible with the classic mail model,
   1.872 +which \s-1MH\s0 covers, so \s-1MH\s0 may never support it well.
   1.873 +(Using \s-1IMAP\s0 and a filesystem abstraction layer to only map
   1.874 +a remote directory into the local filesystem, is a different topic.
   1.875 +\s-1IMAP\s0 support is seen as being able to access the special
   1.876 +mail features of the protocol.)
   1.877  .PP
   1.878 -The other kind of problem are human habits.
   1.879 +The other kind of problem relates to human habits.
   1.880  In this world, where almost all \s-1MUA\s0s are monolithic,
   1.881 -it is very difficult to convince people to use a toolbox style \s-1MUA\s0
   1.882 +it is very difficult to convince people to use a toolchest-style \s-1MUA\s0
   1.883  like \s-1MH\s0.
   1.884 -The habits are so strong, that even people who understand the concept
   1.885 -and advantages of \s-1MH\s0 do not like to switch,
   1.886 +These habits are so strong, that even people who understand the concept
   1.887 +and advantages of \s-1MH\s0 are reluctant to switch,
   1.888  simply because \s-1MH\s0 is different.
   1.889 -Unfortunately, the frontends to \s-1MH\s0, which could provide familiar look'n'feel,
   1.890 -are quite outdated and thus not very appealing, compared to the modern interfaces
   1.891 -of many monolithic \s-1MUA\s0s.
   1.892 +Unfortunately, the frontends to \s-1MH\s0, which could provide familiar
   1.893 +look and feel, are quite outdated and thus not very appealing in comparison
   1.894 +to the modern interfaces of many monolithic \s-1MUA\s0s.
   1.895  One notable exception is \fImh-e\fP which provides an Emacs interface
   1.896  to \s-1MH\s0.
   1.897  \fIMh-e\fP looks much like \fImutt\fP or \fIpine\fP, 
   1.898 @@ -1054,62 +1069,62 @@
   1.899  .H 2 "Summary
   1.900  .LP
   1.901  \s-1MH\s0 is an \s-1MUA\s0 that follows the Unix Philosophy in its design.
   1.902 -It consists of a toolchest of small tools, each of them does one job well.
   1.903 +It consists of a toolchest of small tools, each of which does one job well.
   1.904  The toolchest approach offers great flexibility to the user.
   1.905  It is possible to utilize the complete power of the Unix shell with \s-1MH\s0.
   1.906 -This makes \s-1MH\s0 a very powerful mail system.
   1.907 -Extending and customizing \s-1MH\s0 is easy and encouraged.
   1.908 +This makes \s-1MH\s0 a very powerful mail system,
   1.909 +and extending and customizing \s-1MH\s0 is easy and encouraged.
   1.910  .PP
   1.911  Apart from the user's perspective, \s-1MH\s0 is development-friendly.
   1.912  Its overall design follows clear rules.
   1.913 -The single tools do only one job, thus they are easy to understand,
   1.914 -easy to write, and good to maintain.
   1.915 +The single tools do only one job; thus they are easy to understand,
   1.916 +write, and maintain.
   1.917  They are all independent and do not interfere with the others.
   1.918 -Automated testing of their function is a straight forward task.
   1.919 +Automated testing of their function is a straightforward task.
   1.920  .PP
   1.921 -It is sad, that \s-1MH\s0's differentness is its largest problem,
   1.922 -as its differentness is also its largest advantage.
   1.923 -Unfortunately, for most people their habits are stronger
   1.924 -than the attraction of the clear design and the power, \s-1MH\s0 offers.
   1.925 +It is sad, that \s-1MH\s0's dissimilarity to other \s-1MUA\s0s is its
   1.926 +largest problem, as this dissimilarity is also its largest advantage.
   1.927 +Unfortunately, most people's habits are stronger
   1.928 +than the attraction of the clear design and the power \s-1MH\s0 offers.
   1.929  
   1.930  
   1.931  
   1.932  .H 1 "Case study: uzbl
   1.933  .LP
   1.934 -The last chapter took a look on the \s-1MUA\s0 \s-1MH\s0,
   1.935 -which is an old and established software.
   1.936 +The last chapter focused on the \s-1MUA\s0 \s-1MH\s0,
   1.937 +which is an old and established piece of software.
   1.938  This chapter covers uzbl, a fresh new project.
   1.939  Uzbl is a web browser that adheres to the Unix Philosophy.
   1.940  Its name comes from the \fILolspeak\fP word for ``usable'';
   1.941 -it is pronounced identical.
   1.942 +both are pronounced in the same way.
   1.943  
   1.944  .H 2 "Historical background
   1.945  .LP
   1.946  Uzbl was started by Dieter Plaetinck in April 2009.
   1.947 -The idea was born in a thread in the Arch Linux Forums.
   1.948 +The idea was born in a thread on the Arch Linux forums.
   1.949  .[
   1.950  arch linux forums
   1.951  browser
   1.952  .]
   1.953 -After some discussion about failures of well known web browsers,
   1.954 -Plaetinck (alias Dieter@be) came up with a very sketchy proposal
   1.955 -of how a better web browser could look like.
   1.956 -To the question of another member, if Plaetinck would write that program,
   1.957 -because it would sound fantastic, Plaetinck replied:
   1.958 +After some discussion about the failures of well-known web browsers,
   1.959 +Plaetinck (alias Dieter@be) came up with a rough proposal
   1.960 +of how a better web browser could look.
   1.961 +In response to another member who asked if Plaetinck would write this
   1.962 +program because it sounded fantastic, Plaetinck replied:
   1.963  ``Maybe, if I find the time ;-)''.
   1.964  .PP
   1.965  Fortunately, he found the time.
   1.966  One day later, the first prototype was out.
   1.967 -One week later, uzbl had an own website.
   1.968 +One week later, uzbl had its own website.
   1.969  .[
   1.970  uzbl website
   1.971  .]
   1.972 -One month after the first code showed up,
   1.973 -a mailing list was installed to coordinate and discuss further development,
   1.974 -and a wiki was added to store documentation and scripts that showed up on the
   1.975 -mailing list and elsewhere.
   1.976 +One month after the initial code was presented,
   1.977 +a mailing list was set up to coordinate and discuss further development,
   1.978 +and a wiki was added to store documentation and scripts that cropped up
   1.979 +on the mailing list and elsewhere.
   1.980  .PP
   1.981 -In the, now, one year of uzbl's existence, it was heavily developed on various branches.
   1.982 +In the first year of uzbl's existence, it was heavily developed on various branches.
   1.983  Plaetinck's task became more and more to only merge the best code from the
   1.984  different branches into his main branch, and to apply patches.
   1.985  .[
   1.986 @@ -1120,9 +1135,11 @@
   1.987  .[ [
   1.988  uzbl website
   1.989  .], news archive]
   1.990 -Uzbl, actually, opened the field for a whole family of web browsers with similar shape.
   1.991 +Uzbl actually opened the field for a whole family of web browsers with
   1.992 +a similar design.
   1.993  .PP
   1.994 -In July 2009, \fILinux Weekly News\fP published an interview with Plaetinck about uzbl.
   1.995 +In July 2009, \fILinux Weekly News\fP published an interview with
   1.996 +Plaetinck about uzbl.
   1.997  .[
   1.998  lwn uzbl
   1.999  .]
  1.1000 @@ -1137,72 +1154,72 @@
  1.1001  most web browsers are monolithic, but uzbl is a frontend to a toolchest.
  1.1002  .PP
  1.1003  Today, uzbl is divided into uzbl-core and uzbl-browser.
  1.1004 -Uzbl-core is, how its name already indicates, the core of uzbl.
  1.1005 -It handles commands and events to interface other programs,
  1.1006 -and also displays webpages by using \fIwebkit\fP as render engine.
  1.1007 -Uzbl-browser combines uzbl-core with a bunch of handler scripts, a status bar,
  1.1008 -an event manager, yanking, pasting, page searching, zooming, and more stuff,
  1.1009 -to form a ``complete'' web browser.
  1.1010 -In the following text, the term ``uzbl'' usually stands for uzbl-browser,
  1.1011 +Uzbl-core is, as its name indicates, the core of uzbl.
  1.1012 +It handles commands and events to interface with other programs,
  1.1013 +and displays webpages by using \fIwebkit\fP as its rendering engine.
  1.1014 +Uzbl-browser combines uzbl-core with a selection of handler scripts,
  1.1015 +a status bar, an event manager, yanking, pasting, page searching,
  1.1016 +zooming, and much more functionality, to form a ``complete'' web browser.
  1.1017 +In the following text, the term ``uzbl'' usually refers to uzbl-browser,
  1.1018  so uzbl-core is included.
  1.1019  .PP
  1.1020 -Unlike most other web browsers, uzbl is mainly the mediator between the
  1.1021 +Unlike most other web browsers, uzbl is mainly the mediator between
  1.1022  various tools that cover single jobs.
  1.1023 -Therefore, uzbl listens for commands on a named pipe (fifo), a Unix socket,
  1.1024 +Uzbl listens for commands on a named pipe (fifo), a Unix socket,
  1.1025  and on stdin, and it writes events to a Unix socket and to stdout.
  1.1026  Loading a webpage in a running uzbl instance requires only:
  1.1027  .DS
  1.1028  echo 'uri http://example.org' >/path/to/uzbl-fifo
  1.1029  .DE
  1.1030 -The graphical rendering of the webpage is done by webkit,
  1.1031 -a web content engine.
  1.1032 -Uzbl-core is built around libwebkit.
  1.1033 +The rendering of the webpage is done by libwebkit,
  1.1034 +around which uzbl-core is built.
  1.1035  .PP
  1.1036  Downloads, browsing history, bookmarks, and the like are not provided
  1.1037 -by the core itself, like they are in other web browsers.
  1.1038 -Uzbl-browser also only provides, so called, handler scripts that wrap
  1.1039 -external applications which provide the actual functionality.
  1.1040 +by the core itself like they are in other web browsers.
  1.1041 +Uzbl-browser also only provides ``handler scripts'' which wrap
  1.1042 +external applications to provide the actual functionality.
  1.1043  For instance, \fIwget\fP is used to download files and uzbl-browser
  1.1044  includes a script that calls wget with appropriate options in
  1.1045  a prepared environment.
  1.1046  .PP
  1.1047 -Modern web browsers are proud to have addons, plugins, and modules, instead.
  1.1048 +Modern web browsers are proud to have addons, plugins, modules,
  1.1049 +and so forth.
  1.1050  This is their effort to achieve similar goals.
  1.1051 -But instead of using existing, external programs, modern web browsers
  1.1052 +But instead of using existing external programs, modern web browsers
  1.1053  include these functions.
  1.1054  
  1.1055  .H 2 "Discussion of the design
  1.1056  .LP
  1.1057 -This section discusses uzbl in regard of the Unix Philosophy,
  1.1058 +This section discusses uzbl in regard to the Unix Philosophy,
  1.1059  as identified by Gancarz.
  1.1060  
  1.1061  .PP
  1.1062  .B "Make each program do one thing well" .
  1.1063  Uzbl tries to be a web browser and nothing else.
  1.1064 -The common definition of a web browser is, of course, highly influenced by
  1.1065 -existing implementations of web browsers, although they are degenerated.
  1.1066 -Web browsers should be programs to browse the web, and nothing more.
  1.1067 -This is the one thing they should do.
  1.1068 +The common definition of a web browser is highly influenced by
  1.1069 +existing implementations of web browsers.
  1.1070 +But a web browser should be a program to browse the web, and nothing more.
  1.1071 +This is the one thing it should do.
  1.1072  .PP
  1.1073 -Web browsers should not, for instance, manage downloads.
  1.1074 -This is the job download managers exist for.
  1.1075 -Download managers do primary care about being good in downloading files.
  1.1076 +Web browsers should not, for instance, manage downloads;
  1.1077 +this is the job of download managers.
  1.1078 +A download manager is primary concerned with downloading files.
  1.1079  Modern web browsers provide download management only as a secondary feature.
  1.1080 -How could they do this job better, than programs that exist only for
  1.1081 +How could they do this job better than programs that exist only for
  1.1082  this very job?
  1.1083 -And how could anyone want less than the best download manager available?
  1.1084 +And why would anyone want less than the best download manager available?
  1.1085  .PP
  1.1086  A web browser's job is to let the user browse the web.
  1.1087  This means, navigating through websites by following links.
  1.1088  Rendering the \s-1HTML\s0 sources is a different job, too.
  1.1089 -It is covered by the webkit render engine, in uzbl's case.
  1.1090 -Audio and video content and files like PostScript, \s-1PDF\s0,
  1.1091 -and the like, are also not the job of a web browser.
  1.1092 -Such content should be handled by external programs \(en
  1.1093 -programs that were written to handle such data.
  1.1094 +In uzbl's case, this is covered by the webkit rendering engine.
  1.1095 +Handling audio and video content, PostScript, \s-1PDF\s0,
  1.1096 +and other such files are also not the job of a web browser.
  1.1097 +Such content should be handled by external programs
  1.1098 +that were written to handle such data.
  1.1099  Uzbl strives to do it this way.
  1.1100  .PP
  1.1101 -Remember Doug McIlroy:
  1.1102 +Remember Doug McIlroy's words:
  1.1103  .I
  1.1104  ``Write programs that do one thing and do it well.
  1.1105  Write programs to work together.''
  1.1106 @@ -1210,30 +1227,31 @@
  1.1107  .PP
  1.1108  The lesser tenet
  1.1109  .B "allow the user to tailor the environment
  1.1110 -matches good here.
  1.1111 -There was the question, how anyone could want anything less than the
  1.1112 -best program for the job.
  1.1113 -But as personal preferences matter, it is probably more important to ask:
  1.1114 -How could anyone want something else than his preferred program for the job?
  1.1115 +applies here as well.
  1.1116 +Previously, the question, ``Why would anyone want anything less than the
  1.1117 +best program for the job?'' was put forward.
  1.1118 +But as personal preferences matter, it might be more important to ask:
  1.1119 +``Why would anyone want something other than his preferred program for
  1.1120 +the job?''
  1.1121  .PP
  1.1122 -Usually users want one program for a specific job.
  1.1123 -Hence, whenever the task is, for instance, downloading,
  1.1124 +Users typically want one program for a specific job.
  1.1125 +Hence, whenever one wishes to download something,
  1.1126  the same download manager should be used.
  1.1127 -More advanced users might want to have this download manager in this
  1.1128 -situation and that one in that situation.
  1.1129 -They should be able to configure it this way.
  1.1130 -With uzbl, one can use any download manager the user wants.
  1.1131 -To switch to a different one, only one line in a small handler script
  1.1132 +More advanced users might want to use one download manager in a certain
  1.1133 +situation and another in a different situation;
  1.1134 +they should be able to configure it this way.
  1.1135 +With uzbl, any download manager can be used.
  1.1136 +To switch to a different one, a single line in a small handler script
  1.1137  needs to be changed.
  1.1138 -Alternatively it would be possible to query the program to use by
  1.1139 -reading a global file or an environment variable, in the handler script.
  1.1140 -Of course, one can tell uzbl to use a different handler script, too.
  1.1141 -This requires a one line change in uzbl's config file.
  1.1142 +Alternatively, it would be possible to query which download manager to use by
  1.1143 +reading a global file or an environment variable in the handler script.
  1.1144 +Of course, uzbl can use a different handler script as well.
  1.1145 +This simply requires a one line change in uzbl's configuration file.
  1.1146  .PP
  1.1147 -Uzbl does neither have its own download manager nor depends on a
  1.1148 -specific one, hence uzbl's browsing abilities will not be lowered by having
  1.1149 +Uzbl neither has its own download manager nor depends on a specific one;
  1.1150 +hence, uzbl's browsing abilities will not be crippled by having
  1.1151  a bad download manager.
  1.1152 -Uzbl's download capabilities will be just as good as the ones of the best
  1.1153 +Uzbl's download capabilities will be as good as the best
  1.1154  download manager available on the system.
  1.1155  Of course, this applies to all of the other supplementary tools, too.
  1.1156  
  1.1157 @@ -1241,8 +1259,8 @@
  1.1158  .B "Use software leverage to your advantage" .
  1.1159  Uzbl is designed to be extended by external tools.
  1.1160  These external tools are usually wrapped by small handler shell scripts.
  1.1161 -Shell scripts are the glue in this approach.
  1.1162 -They make the various parts fit together.
  1.1163 +Shell scripts form the basis for the glue which holds the various
  1.1164 +parts together.
  1.1165  .PP
  1.1166  The history mechanism of uzbl shall be presented as an example.
  1.1167  Uzbl is configured to spawn a script to append an entry to the history
  1.1168 @@ -1253,12 +1271,13 @@
  1.1169  file=/path/to/uzbl-history
  1.1170  echo `date +'%Y-%m-%d %H:%M:%S'`" $6 $7" >> $file
  1.1171  .DE
  1.1172 -\f(CW$6\fP and \f(CW$7\fP expand to the \s-1URL\s0 and the page title.
  1.1173 +\f(CW$6\fP and \f(CW$7\fP expand to the \s-1URL\s0 and the page title,
  1.1174 +respectively.
  1.1175  .PP
  1.1176  For loading an entry, a key is bound to spawn a load-from-history script.
  1.1177  The script reverses the history to have newer entries first,
  1.1178 -then displays \fIdmenu\fP to let the user select an item,
  1.1179 -and afterwards writes the selected \s-1URL\s0 into uzbl's command input pipe.
  1.1180 +displays \fIdmenu\fP to let the user select an item,
  1.1181 +and then writes the selected \s-1URL\s0 into uzbl's command input pipe.
  1.1182  With error checking and corner case handling removed,
  1.1183  the script looks like this:
  1.1184  .DS
  1.1185 @@ -1272,64 +1291,63 @@
  1.1186  
  1.1187  .PP
  1.1188  .B "Avoid captive user interfaces" .
  1.1189 -One could say, that uzbl, to a large extent, actually \fIis\fP
  1.1190 +One could say that uzbl, to a large extent, actually \fIis\fP
  1.1191  a captive user interface.
  1.1192 -But the difference to most other web browsers is, that uzbl is only
  1.1193 +But the difference from other web browsers is that uzbl is only
  1.1194  the captive user interface frontend (and the core of the backend).
  1.1195  Many parts of the backend are independent of uzbl.
  1.1196 -Some are distributed with uzbl, for some external programs,
  1.1197 -handler scripts are distributed,
  1.1198 -but arbitrary additional functionality can be added if desired.
  1.1199 +For some external programs, handler scripts are distributed with uzbl;
  1.1200 +but arbitrary additional functionality can always be added if desired.
  1.1201  .PP
  1.1202  The frontend is captive \(en that is true.
  1.1203  This is okay for the task of browsing the web, as this task is only relevant
  1.1204 -for humans.
  1.1205 -Automated programs would \fIcrawl\fP the web.
  1.1206 -That means, they read the source directly.
  1.1207 -The source includes all the semantics.
  1.1208 -The graphical representation is just for humans to transfer the semantics
  1.1209 +to humans.
  1.1210 +Automated programs would \fIcrawl\fP the web, that means,
  1.1211 +read the source directly, including all semantics.
  1.1212 +The graphical representation is just for humans to understand the semantics
  1.1213  more intuitively.
  1.1214  
  1.1215  .PP
  1.1216  .B "Make every program a filter" .
  1.1217  Graphical web browsers are almost dead ends in the chain of information flow.
  1.1218  Thus it is difficult to see what graphical web browsers should filter.
  1.1219 -Graphical web browsers exist almost only to be interactively used by humans.
  1.1220 -The only case when one might want to automate the rendering function is
  1.1221 +Graphical web browsers exist almost exclusively to be interactively used
  1.1222 +by humans.
  1.1223 +The only case in which one might want to automate the rendering function is
  1.1224  to generate images of rendered webpages.
  1.1225  
  1.1226  .PP
  1.1227  .B "Small is beautiful"
  1.1228 -is not easy to apply to a web browser, because modern web technology
  1.1229 -is very complex, hence the rendering task is very complex.
  1.1230 -Modern web browsers have to consist of many thousand lines of code,
  1.1231 -unfortunately.
  1.1232 -Using the toolchest approach and wrappers can split the browser into
  1.1233 -several small parts, tough.
  1.1234 +is not easy to apply to a web browser because modern web technology
  1.1235 +is very complex; hence, the rendering task is very complex.
  1.1236 +Unfortunately, modern web browsers ``have'' to consist of many thousand
  1.1237 +lines of code,
  1.1238 +Using the toolchest approach and wrappers can help to split the browser
  1.1239 +into several small parts, though.
  1.1240  .PP
  1.1241  As of March 2010, uzbl-core consists of about 3\,500 lines of C code.
  1.1242  The distribution includes another 3\,500 lines of Shell and Python code,
  1.1243 -which are the handler scripts and plugins like a modal interface.
  1.1244 -Further more, uzbl uses functionality of external tools like
  1.1245 +which are the handler scripts and plugins like one to provide a modal
  1.1246 +interface.
  1.1247 +Further more, uzbl makes use of external tools like
  1.1248  \fIwget\fP and \fIsocat\fP.
  1.1249  Up to this point, uzbl looks pretty neat and small.
  1.1250 -The ugly part of uzbl is the web content render engine, webkit.
  1.1251 +The ugly part of uzbl is the rendering engine, webkit.
  1.1252  Webkit consists of roughly 400\,000 (!) lines of code.
  1.1253 -Unfortunately, small web render engines are not possible anymore
  1.1254 -because of the modern web.
  1.1255 +Unfortunately, small rendering engines are not feasible anymore
  1.1256 +due to the nature of the modern web.
  1.1257  
  1.1258  .PP
  1.1259  .B "Build a prototype as soon as possible" .
  1.1260 -Plaetinck made his code public, right from the beginning.
  1.1261 -Discussion and development was, and still is, open to everyone interested.
  1.1262 -Development versions of uzbl can be obtained very simply from the code
  1.1263 -repository.
  1.1264 +Plaetinck made his code public right from the beginning.
  1.1265 +Discussion and development was, and still is, open to everyone interested,
  1.1266 +and development versions of uzbl can be obtained very easily from the
  1.1267 +code repository.
  1.1268  Within the first year of uzbl's existence, a new version was released
  1.1269  more often than once a month.
  1.1270 -Different forks and branches arose.
  1.1271 -They introduced new features, which were tested for suitability
  1.1272 -for the main branch.
  1.1273 -The experiences of using prototypes influenced further development.
  1.1274 +Different forks and branches arose introducing new features which were
  1.1275 +then considered for merging into the main branch.
  1.1276 +The experiences with using prototypes influenced further development.
  1.1277  Actually, all development was community driven.
  1.1278  Plaetinck says, three months after uzbl's birth:
  1.1279  ``Right now I hardly code anything myself for Uzbl.
  1.1280 @@ -1342,51 +1360,50 @@
  1.1281  
  1.1282  .H 2 "Problems
  1.1283  .LP
  1.1284 -Similar to \s-1MH\s0, uzbl, too suffers from being different.
  1.1285 +Similar to \s-1MH\s0, uzbl suffers from being different.
  1.1286  It is sad, but people use what they know.
  1.1287 -Fortunately, uzbl's user interface can look and feel very much the
  1.1288 -same as the one of the well known web browsers,
  1.1289 +Fortunately, uzbl's user interface can be made to look and feel very similar
  1.1290 +to the one of the well known web browsers,
  1.1291  hiding the internal differences.
  1.1292  But uzbl has to provide this similar look and feel to be accepted
  1.1293  as a ``normal'' browser by ``normal'' users.
  1.1294  .PP
  1.1295 -Though, the more important problem is the modern web.
  1.1296 +The more important problem here is the modern web.
  1.1297  The modern web is simply broken.
  1.1298 -It has state in a state-less protocol,
  1.1299 -it misuses technologies,
  1.1300 -and it is helplessly overloaded.
  1.1301 -The result are web content render engines that must consist
  1.1302 -of hundreds of thousands lines of code.
  1.1303 -They also must combine and integrate many different technologies,
  1.1304 -only to make our modern web accessible.
  1.1305 -Website to image converter are hardly possible to run without
  1.1306 +It has state in a state-less protocol, misuses technologies,
  1.1307 +and is helplessly overloaded.
  1.1308 +This results in rendering engines that ``must'' consist
  1.1309 +of hundreds of thousands of lines of code.
  1.1310 +They also must combine and integrate many different technologies
  1.1311 +to make our modern web accessible.
  1.1312 +This results, however, in a failing attempt to provide good usability.
  1.1313 +Website-to-image converters are almost impossible to run without
  1.1314  human interaction because of state in sessions, impossible
  1.1315 -deep-linking, and unautomatable technologies.
  1.1316 +deep-linking, and ``unautomatable'' technologies.
  1.1317  .PP
  1.1318 -The web was misused to provide all kinds of imaginable wishes.
  1.1319 -Now web browsers, and eventually the users, suffer from it.
  1.1320 +The web was misused in order to attempt to fulfill all kinds of wishes.
  1.1321 +Now web browsers, and ultimately users, suffer from it.
  1.1322  
  1.1323  
  1.1324  .H 2 "Summary
  1.1325  .LP
  1.1326  ``Uzbl is a browser that adheres to the Unix Philosophy'',
  1.1327 -that is how uzbl is seen by its authors.
  1.1328 +is how uzbl is seen by its authors.
  1.1329  Indeed, uzbl follows the Unix Philosophy in many ways.
  1.1330  It consists of independent parts that work together,
  1.1331  while its core is mainly a mediator which glues the parts together.
  1.1332  .PP
  1.1333 -Software leverage can excellently be seen in uzbl.
  1.1334 -External tools are used, independent tasks are separated
  1.1335 -in independent parts and glued together with small handler scripts.
  1.1336 +Software leverage is put to excellent use.
  1.1337 +External tools are used, independent tasks are separated out
  1.1338 +to independent parts and glued together with small handler scripts.
  1.1339  .PP
  1.1340 -As uzbl, more or less, consists of a set of tools and a bit
  1.1341 -of glue, anyone can put the parts together and expand it
  1.1342 -in any desired way.
  1.1343 -Uzbl is very flexible and customizable.
  1.1344 -These properties make it valuable for advanced users,
  1.1345 -but may keep novice users from using it.
  1.1346 +Since uzbl roughly consists of a set of tools and a bit of glue,
  1.1347 +anyone can put the parts together and expand it in any desired way.
  1.1348 +Flexibility and customization are properties that make it valuable
  1.1349 +for advanced users, but may keep novice users from understanding
  1.1350 +and using it.
  1.1351  .PP
  1.1352 -But uzbl's main problem is the modern web, that makes it hard
  1.1353 +But uzbl's main problem is the modern web, which makes it very difficult
  1.1354  to design a sane web browser.
  1.1355  Despite this bad situation, uzbl does a fairly good job.
  1.1356  
  1.1357 @@ -1395,27 +1412,28 @@
  1.1358  
  1.1359  .LP
  1.1360  This paper explained why good design is important.
  1.1361 -It introduced the Unix Philosophy as guidelines to good design,
  1.1362 -in order to create good quality software.
  1.1363 -Then, real life software, that was designed with the Unix Philosophy
  1.1364 -in mind, was discussed.
  1.1365 +It introduced the Unix Philosophy as a set of guidelines that encourage
  1.1366 +good design in order to create good quality software.
  1.1367 +Then, real world software that was designed with the Unix Philosophy
  1.1368 +in mind was discussed.
  1.1369  .PP
  1.1370 -Throughout the paper, the aim was do explain \fIwhy\fP something
  1.1371 +Throughout this paper, the aim was do explain \fIwhy\fP something
  1.1372  should be done the Unix way.
  1.1373 -It was tried to give reasons that expose that the Unix Philosophy
  1.1374 -is a preferable way for designing software.
  1.1375 +Reasons were given to substantiate the claim that the Unix Philosophy
  1.1376 +is a preferable way of designing software.
  1.1377  .PP
  1.1378  The Unix Philosophy is close to the software developer's point of view.
  1.1379 -Its main goal is taming the beast ``software complexity''.
  1.1380 -Hence it strives first and foremost for simplicity, of software.
  1.1381 -It might appear, that usability for people is a minor goal.
  1.1382 -Actually, the Unix Philosophy sees usability as a result of sound design.
  1.1383 -Sound design does not need to be most intuitive,
  1.1384 +Its main goal is taming the beast known as ``software complexity''.
  1.1385 +Hence it strives first and foremost for simplicity of software.
  1.1386 +It might appear that usability for humans is a minor goal,
  1.1387 +but actually, the Unix Philosophy sees usability as a result of sound design.
  1.1388 +Sound design does not need to be ultimately intuitive,
  1.1389  but it will provide a consistent way to access the enormous power
  1.1390  of software leverage.
  1.1391  .PP
  1.1392 -Being able to solve some concrete problem becomes less and less important,
  1.1393 -as there is software available for nearly every possible task today.
  1.1394 +Being able to solve some specific concrete problem becomes less and less
  1.1395 +important as there is software available for nearly every possible task
  1.1396 +today.
  1.1397  But the quality of software matters.
  1.1398  It is important that we have \fIgood\fP software.
  1.1399  .sp
  1.1400 @@ -1424,12 +1442,12 @@
  1.1401  .PP
  1.1402  The largest problem of software development is the complexity involved.
  1.1403  It is the only part of the job that computers cannot take over.
  1.1404 -The Unix Philosophy fights complexity as main enemy.
  1.1405 +The Unix Philosophy fights complexity, as it is the main enemy.
  1.1406  .PP
  1.1407  On the other hand,
  1.1408 -the most unique gain of software is its ability to leverage.
  1.1409 +the most unique advantage of software is its ability to leverage.
  1.1410  Current software still fails to make the best possible use of this ability.
  1.1411 -The Unix Philosophy concentrates much on exploiting this great opportunity.
  1.1412 +The Unix Philosophy concentrates on exploiting this great opportunity.
  1.1413  
  1.1414  
  1.1415  .bp