1.1 --- a/unix-phil.ms	Thu Apr 15 12:30:25 2010 +0200
     1.2 +++ b/unix-phil.ms	Thu Apr 15 13:53:12 2010 +0200
     1.3 @@ -97,7 +97,7 @@
     1.4  .H 1 "Importance of software design in general
     1.5  .LP
     1.6  Software design is the planning of how the internal structure
     1.7 -and external interfaces of a software should look like.
     1.8 +and external interfaces of software should look like.
     1.9  It has nothing to do with visual appearance.
    1.10  If we take a program as a car, then its color is of no matter.
    1.11  Its design would be the car's size, its shape, the locations of doors,
    1.12 @@ -113,7 +113,7 @@
    1.13  Often invisible though, are the wasted possible gains.
    1.14  Good software design can make these gains available.
    1.15  .PP
    1.16 -A software's design deals with quality properties.
    1.17 +Software design deals with quality properties.
    1.18  Good design leads to good quality, and quality is important.
    1.19  Any car may be able to drive from A to B,
    1.20  but it depends on the car's properties whether it is a good choice
    1.21 @@ -123,7 +123,7 @@
    1.22  And it depends on its properties if the ride will be fun.
    1.23  
    1.24  .PP
    1.25 -Requirements for a software are twofold:
    1.26 +Requirements for software are twofold:
    1.27  functional and non-functional.
    1.28  .IP \(bu
    1.29  Functional requirements define directly the software's functions.
    1.30 @@ -134,20 +134,20 @@
    1.31  Functional requirements are easier to define and to verify.
    1.32  .IP \(bu
    1.33  Non-functional requirements are called \fIquality\fP requirements, too.
    1.34 -The quality of a software are the properties that are not directly related to
    1.35 +The quality of software are the properties that are not directly related to
    1.36  the software's basic functions.
    1.37  Tools of bad quality often do solve the problems they were written for,
    1.38  but introduce problems and difficulties for usage and development, later on.
    1.39  Quality aspects are often overlooked at first sight,
    1.40  and are often difficult to define clearly and to verify.
    1.41  .PP
    1.42 -Quality is hardly interesting when the software gets built initially,
    1.43 -but it has a high impact on usability and maintenance of the software, later.
    1.44 -A short-sighted might see in developing a software, mainly building something up.
    1.45 -But experience shows, that building the software the first time is
    1.46 +Quality is hardly interesting when software gets built initially,
    1.47 +but it has a high impact on usability and maintenance, later.
    1.48 +A short-sighted might see in developing software, mainly building something up.
    1.49 +But experience shows, that building software the first time is
    1.50  only a small amount of the overall work.
    1.51  Bug fixing, extending, rebuilding of parts \(en maintenance work \(en
    1.52 -does soon take over the major part of the time spent on a software.
    1.53 +does soon take over the major part of the time spent on a software project.
    1.54  And of course, the time spent actually using the software.
    1.55  These processes are highly influenced by the software's quality.
    1.56  Thus, quality must not be neglected.
    1.57 @@ -155,11 +155,11 @@
    1.58  bad quality during the first build,
    1.59  although this is the time when you should care about good quality most.
    1.60  .PP
    1.61 -Software design has little to do with the basic function of a software \(en
    1.62 +Software design has little to do with the basic function of software \(en
    1.63  this requirement will get satisfied anyway.
    1.64 -Software design is more about quality aspects of the software.
    1.65 +Software design is more about quality aspects of software.
    1.66  Good design leads to good quality, bad design to bad quality.
    1.67 -The primary functions of the software will be affected modestly by bad quality,
    1.68 +The primary functions of software will be affected modestly by bad quality,
    1.69  but good quality can provide a lot of additional gain,
    1.70  even at places where one never expected it.
    1.71  .PP
    1.72 @@ -187,7 +187,7 @@
    1.73  .I Portability
    1.74  (adaptability, installability, co-existence, replaceability)
    1.75  .LP
    1.76 -Good design can improve these properties of a software,
    1.77 +Good design can improve these properties of software,
    1.78  bad designed software likely suffers in these points.
    1.79  .PP
    1.80  One further goal of software design is consistency.
    1.81 @@ -196,7 +196,7 @@
    1.82  can be provided by good design.
    1.83  .PP
    1.84  Software should be well designed because good design avoids many
    1.85 -problems during a software's lifetime.
    1.86 +problems during a software project's lifetime.
    1.87  And software should be well designed because good design can offer
    1.88  much additional gain.
    1.89  Indeed, much effort should be spent into good design to make software more valuable.
    1.90 @@ -333,7 +333,7 @@
    1.91  .PP
    1.92  The Unix toolchest \fIis\fP a set of small, (mostly) non-interactive programs
    1.93  that are filters on byte streams.
    1.94 -They are, to a large extend, unrelated in their function.
    1.95 +They are, to a large extent, unrelated in their function.
    1.96  Hence, the Unix toolchest provides a large set of functions
    1.97  that can be accessed by combining the programs in the desired way.
    1.98  .PP
    1.99 @@ -361,7 +361,7 @@
   1.100  A toolchest is often more difficult to use.
   1.101  It is necessary to become familiar with each of the tools,
   1.102  to be able to use the right one in a given situation.
   1.103 -Additionally, one needs to combine the tools in a senseful way himself.
   1.104 +Additionally, one needs to combine the tools in a sensible way himself.
   1.105  This is like a sharp knife \(en it is a powerful tool in the hand of a
   1.106  master, but of no good value in the hand of an unskilled.
   1.107  However, learning single, small tools of a toolchest is easier than
   1.108 @@ -370,7 +370,7 @@
   1.109  if the tools of a toolchest have a common, consistent style.
   1.110  He will be able to transfer knowledge over from one tool to another.
   1.111  .PP
   1.112 -Moreover, the second drawback can be removed to a large extend
   1.113 +Moreover, the second drawback can be removed to a large extent
   1.114  by adding wrappers around the basic tools.
   1.115  Novice users do not need to learn several tools, if a professional wraps
   1.116  complete command lines into a higher-level script.
   1.117 @@ -406,7 +406,7 @@
   1.118  The Unix shell provides the possibility to combine small programs into large ones.
   1.119  But a powerful shell is a great feature in other ways, too.
   1.120  For instance by being scriptable.
   1.121 -Control statements are build into the shell.
   1.122 +Control statements are built into the shell.
   1.123  The functions, however, are the normal programs of the system.
   1.124  Thus, as the programs are already known,
   1.125  learning to program in the shell becomes easy.
   1.126 @@ -450,7 +450,7 @@
   1.127  unix philosophy
   1.128  .], page 28 f.]
   1.129  .PP
   1.130 -Prototyping is often seen as a first step in building a software.
   1.131 +Prototyping is often seen as a first step in building software.
   1.132  This is, of course, good.
   1.133  However, the Unix Philosophy has an \fIadditional\fP perspective on prototyping:
   1.134  After having built the prototype, one might notice, that the prototype is already
   1.135 @@ -474,7 +474,7 @@
   1.136  .PP
   1.137  (2) Requirements change during time.
   1.138  Hence it is best to delay requirement-based design decisions as long as possible.
   1.139 -The software should be small and flexible as long as possible
   1.140 +Software should be small and flexible as long as possible
   1.141  to react on changing requirements.
   1.142  Shell scripts, for example, are more easily adjusted as C programs.
   1.143  .PP
   1.144 @@ -496,7 +496,7 @@
   1.145  .IP \(bu
   1.146  As working parts are available soon, the real requirements can get identified soon.
   1.147  .IP \(bu
   1.148 -When a software is usable and valuable, it gets used, and thus tested.
   1.149 +When software is usable and valuable, it gets used, and thus tested.
   1.150  Hence problems will be found at early stages of the development.
   1.151  .IP \(bu
   1.152  The prototype might be enough for the moment,
   1.153 @@ -554,7 +554,7 @@
   1.154  and avoiding optimizations that introduce dependencies on specific hardware.
   1.155  Hardware has a much lower lifetime than software.
   1.156  By chaining software to a specific hardware,
   1.157 -the software's lifetime gets shortened to that of this hardware.
   1.158 +its lifetime gets shortened to that of this hardware.
   1.159  In contrast, software should be easy to port \(en
   1.160  adaptation is the key to success.
   1.161  .PP
   1.162 @@ -579,7 +579,7 @@
   1.163  A large
   1.164  .I "range of usability
   1.165  ensures good adaptation, and thus good survival.
   1.166 -It is a special distinction if a software becomes used in fields of action,
   1.167 +It is a special distinction if software becomes used in fields of action,
   1.168  the original authors did never imagine.
   1.169  Software that solves problems in a general way will likely be used
   1.170  for many kinds of similar problems.
   1.171 @@ -603,10 +603,10 @@
   1.172  (4)
   1.173  .I "Reuse of parts
   1.174  is even one step further.
   1.175 -A software may completely lose its field of action,
   1.176 -but parts of which the software is build may be general and independent enough
   1.177 +Software may completely lose its field of action,
   1.178 +but parts of which the software is built may be general and independent enough
   1.179  to survive this death.
   1.180 -If software is build by combining small independent programs,
   1.181 +If software is built by combining small independent programs,
   1.182  then these parts are readily available for reuse.
   1.183  Who cares if the large program is a failure,
   1.184  but parts of it become successful instead?
   1.185 @@ -639,7 +639,7 @@
   1.186  the driving force in the discussion.
   1.187  .PP
   1.188  This first case study is about the mail user agents (\s-1MUA\s0)
   1.189 -\s-1MH\s0 (``mail handler'') and its descendent \fInmh\fP
   1.190 +\s-1MH\s0 (``mail handler'') and its descendant \fInmh\fP
   1.191  (``new mail handler'').
   1.192  .[
   1.193  nmh website
   1.194 @@ -661,7 +661,7 @@
   1.195  quarter century of unix
   1.196  .], page 41 f.]
   1.197  It was a small program that either printed the user's mailbox file
   1.198 -or appended text to someone elses mailbox file,
   1.199 +or appended text to someone else's mailbox file,
   1.200  depending on the command line arguments.
   1.201  .[
   1.202  manual mail(1)
   1.203 @@ -1026,7 +1026,7 @@
   1.204  This comes from limited development resources.
   1.205  More active developers could quickly change this.
   1.206  But \s-1MH\s0 is also limited by design, which is the larger problem.
   1.207 -\s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extend.
   1.208 +\s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extent.
   1.209  These design conflicts are not easily solvable.
   1.210  Possibly, they require a redesign.
   1.211  \s-1IMAP\s0 may be too different to the classic mail model,
   1.212 @@ -1192,10 +1192,10 @@
   1.213  This means, navigating through websites by following links.
   1.214  Rendering the \s-1HTML\s0 sources is a different job, too.
   1.215  It is covered by the webkit render engine, in uzbl's case.
   1.216 -Audio and video content and files like PostScript, \s-1PDF\s0, and the like,
   1.217 -are also not the job of a web browser.
   1.218 -They should be handled by external applications \(en
   1.219 -ones which's job is to handle such data.
   1.220 +Audio and video content and files like PostScript, \s-1PDF\s0,
   1.221 +and the like, are also not the job of a web browser.
   1.222 +Such content should be handled by external programs \(en
   1.223 +programs that were written to handle such data.
   1.224  Uzbl strives to do it this way.
   1.225  .PP
   1.226  Remember Doug McIlroy:
   1.227 @@ -1223,6 +1223,8 @@
   1.228  needs to be changed.
   1.229  Alternatively it would be possible to query the program to use by
   1.230  reading a global file or an environment variable, in the handler script.
   1.231 +Of course, one can tell uzbl to use a different handler script, too.
   1.232 +This requires a one line change in uzbl's config file.
   1.233  .PP
   1.234  Uzbl does neither have its own download manager nor depends on a
   1.235  specific one, hence uzbl's browsing abilities will not be lowered by having
   1.236 @@ -1266,7 +1268,7 @@
   1.237  
   1.238  .PP
   1.239  .B "Avoid captive user interfaces" .
   1.240 -One could say, that uzbl, to a large extend, actually \fIis\fP
   1.241 +One could say, that uzbl, to a large extent, actually \fIis\fP
   1.242  a captive user interface.
   1.243  But the difference to most other web browsers is, that uzbl is only
   1.244  the captive user interface frontend (and the core of the backend).
   1.245 @@ -1305,9 +1307,9 @@
   1.246  The distribution includes another 3\,500 lines of Shell and Python code,
   1.247  which are the handler scripts and plugins like a modal interface.
   1.248  Further more, uzbl uses functionality of external tools like
   1.249 -\fIwget\fP and \fInetcat\fP.
   1.250 +\fIwget\fP and \fIsocat\fP.
   1.251  Up to this point, uzbl looks pretty neat and small.
   1.252 -The ugly part of uzbl is the web content renderer, webkit.
   1.253 +The ugly part of uzbl is the web content render engine, webkit.
   1.254  Webkit consists of roughly 400\,000 (!) lines of code.
   1.255  Unfortunately, small web render engines are not possible anymore
   1.256  because of the modern web.
   1.257 @@ -1397,7 +1399,7 @@
   1.258  Throughout the paper, the aim was do explain \fIwhy\fP something
   1.259  should be done the Unix way.
   1.260  It was tried to give reasons that expose that the Unix Philosophy
   1.261 -is a preferrable way for designing software.
   1.262 +is a preferable way for designing software.
   1.263  .PP
   1.264  The Unix Philosophy is close to the software developer's point of view.
   1.265  Its main goal is taming the beast ``software complexity''.