# HG changeset patch # User meillo@marmaro.de # Date 1271332392 -7200 # Node ID 0a435d76b86891c0122ab7557c96726e5c6c7b95 # Parent 14f5ff66ad8aae109606d488866c81fd93f40829 applied corrections by Dieter@be; and did spell checking diff -r 14f5ff66ad8a -r 0a435d76b868 unix-phil.ms --- a/unix-phil.ms Thu Apr 15 12:30:25 2010 +0200 +++ b/unix-phil.ms Thu Apr 15 13:53:12 2010 +0200 @@ -97,7 +97,7 @@ .H 1 "Importance of software design in general .LP Software design is the planning of how the internal structure -and external interfaces of a software should look like. +and external interfaces of software should look like. It has nothing to do with visual appearance. If we take a program as a car, then its color is of no matter. Its design would be the car's size, its shape, the locations of doors, @@ -113,7 +113,7 @@ Often invisible though, are the wasted possible gains. Good software design can make these gains available. .PP -A software's design deals with quality properties. +Software design deals with quality properties. Good design leads to good quality, and quality is important. Any car may be able to drive from A to B, but it depends on the car's properties whether it is a good choice @@ -123,7 +123,7 @@ And it depends on its properties if the ride will be fun. .PP -Requirements for a software are twofold: +Requirements for software are twofold: functional and non-functional. .IP \(bu Functional requirements define directly the software's functions. @@ -134,20 +134,20 @@ Functional requirements are easier to define and to verify. .IP \(bu Non-functional requirements are called \fIquality\fP requirements, too. -The quality of a software are the properties that are not directly related to +The quality of software are the properties that are not directly related to the software's basic functions. Tools of bad quality often do solve the problems they were written for, but introduce problems and difficulties for usage and development, later on. Quality aspects are often overlooked at first sight, and are often difficult to define clearly and to verify. .PP -Quality is hardly interesting when the software gets built initially, -but it has a high impact on usability and maintenance of the software, later. -A short-sighted might see in developing a software, mainly building something up. -But experience shows, that building the software the first time is +Quality is hardly interesting when software gets built initially, +but it has a high impact on usability and maintenance, later. +A short-sighted might see in developing software, mainly building something up. +But experience shows, that building software the first time is only a small amount of the overall work. Bug fixing, extending, rebuilding of parts \(en maintenance work \(en -does soon take over the major part of the time spent on a software. +does soon take over the major part of the time spent on a software project. And of course, the time spent actually using the software. These processes are highly influenced by the software's quality. Thus, quality must not be neglected. @@ -155,11 +155,11 @@ bad quality during the first build, although this is the time when you should care about good quality most. .PP -Software design has little to do with the basic function of a software \(en +Software design has little to do with the basic function of software \(en this requirement will get satisfied anyway. -Software design is more about quality aspects of the software. +Software design is more about quality aspects of software. Good design leads to good quality, bad design to bad quality. -The primary functions of the software will be affected modestly by bad quality, +The primary functions of software will be affected modestly by bad quality, but good quality can provide a lot of additional gain, even at places where one never expected it. .PP @@ -187,7 +187,7 @@ .I Portability (adaptability, installability, co-existence, replaceability) .LP -Good design can improve these properties of a software, +Good design can improve these properties of software, bad designed software likely suffers in these points. .PP One further goal of software design is consistency. @@ -196,7 +196,7 @@ can be provided by good design. .PP Software should be well designed because good design avoids many -problems during a software's lifetime. +problems during a software project's lifetime. And software should be well designed because good design can offer much additional gain. Indeed, much effort should be spent into good design to make software more valuable. @@ -333,7 +333,7 @@ .PP The Unix toolchest \fIis\fP a set of small, (mostly) non-interactive programs that are filters on byte streams. -They are, to a large extend, unrelated in their function. +They are, to a large extent, unrelated in their function. Hence, the Unix toolchest provides a large set of functions that can be accessed by combining the programs in the desired way. .PP @@ -361,7 +361,7 @@ A toolchest is often more difficult to use. It is necessary to become familiar with each of the tools, to be able to use the right one in a given situation. -Additionally, one needs to combine the tools in a senseful way himself. +Additionally, one needs to combine the tools in a sensible way himself. This is like a sharp knife \(en it is a powerful tool in the hand of a master, but of no good value in the hand of an unskilled. However, learning single, small tools of a toolchest is easier than @@ -370,7 +370,7 @@ if the tools of a toolchest have a common, consistent style. He will be able to transfer knowledge over from one tool to another. .PP -Moreover, the second drawback can be removed to a large extend +Moreover, the second drawback can be removed to a large extent by adding wrappers around the basic tools. Novice users do not need to learn several tools, if a professional wraps complete command lines into a higher-level script. @@ -406,7 +406,7 @@ The Unix shell provides the possibility to combine small programs into large ones. But a powerful shell is a great feature in other ways, too. For instance by being scriptable. -Control statements are build into the shell. +Control statements are built into the shell. The functions, however, are the normal programs of the system. Thus, as the programs are already known, learning to program in the shell becomes easy. @@ -450,7 +450,7 @@ unix philosophy .], page 28 f.] .PP -Prototyping is often seen as a first step in building a software. +Prototyping is often seen as a first step in building software. This is, of course, good. However, the Unix Philosophy has an \fIadditional\fP perspective on prototyping: After having built the prototype, one might notice, that the prototype is already @@ -474,7 +474,7 @@ .PP (2) Requirements change during time. Hence it is best to delay requirement-based design decisions as long as possible. -The software should be small and flexible as long as possible +Software should be small and flexible as long as possible to react on changing requirements. Shell scripts, for example, are more easily adjusted as C programs. .PP @@ -496,7 +496,7 @@ .IP \(bu As working parts are available soon, the real requirements can get identified soon. .IP \(bu -When a software is usable and valuable, it gets used, and thus tested. +When software is usable and valuable, it gets used, and thus tested. Hence problems will be found at early stages of the development. .IP \(bu The prototype might be enough for the moment, @@ -554,7 +554,7 @@ and avoiding optimizations that introduce dependencies on specific hardware. Hardware has a much lower lifetime than software. By chaining software to a specific hardware, -the software's lifetime gets shortened to that of this hardware. +its lifetime gets shortened to that of this hardware. In contrast, software should be easy to port \(en adaptation is the key to success. .PP @@ -579,7 +579,7 @@ A large .I "range of usability ensures good adaptation, and thus good survival. -It is a special distinction if a software becomes used in fields of action, +It is a special distinction if software becomes used in fields of action, the original authors did never imagine. Software that solves problems in a general way will likely be used for many kinds of similar problems. @@ -603,10 +603,10 @@ (4) .I "Reuse of parts is even one step further. -A software may completely lose its field of action, -but parts of which the software is build may be general and independent enough +Software may completely lose its field of action, +but parts of which the software is built may be general and independent enough to survive this death. -If software is build by combining small independent programs, +If software is built by combining small independent programs, then these parts are readily available for reuse. Who cares if the large program is a failure, but parts of it become successful instead? @@ -639,7 +639,7 @@ the driving force in the discussion. .PP This first case study is about the mail user agents (\s-1MUA\s0) -\s-1MH\s0 (``mail handler'') and its descendent \fInmh\fP +\s-1MH\s0 (``mail handler'') and its descendant \fInmh\fP (``new mail handler''). .[ nmh website @@ -661,7 +661,7 @@ quarter century of unix .], page 41 f.] It was a small program that either printed the user's mailbox file -or appended text to someone elses mailbox file, +or appended text to someone else's mailbox file, depending on the command line arguments. .[ manual mail(1) @@ -1026,7 +1026,7 @@ This comes from limited development resources. More active developers could quickly change this. But \s-1MH\s0 is also limited by design, which is the larger problem. -\s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extend. +\s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extent. These design conflicts are not easily solvable. Possibly, they require a redesign. \s-1IMAP\s0 may be too different to the classic mail model, @@ -1192,10 +1192,10 @@ This means, navigating through websites by following links. Rendering the \s-1HTML\s0 sources is a different job, too. It is covered by the webkit render engine, in uzbl's case. -Audio and video content and files like PostScript, \s-1PDF\s0, and the like, -are also not the job of a web browser. -They should be handled by external applications \(en -ones which's job is to handle such data. +Audio and video content and files like PostScript, \s-1PDF\s0, +and the like, are also not the job of a web browser. +Such content should be handled by external programs \(en +programs that were written to handle such data. Uzbl strives to do it this way. .PP Remember Doug McIlroy: @@ -1223,6 +1223,8 @@ needs to be changed. Alternatively it would be possible to query the program to use by reading a global file or an environment variable, in the handler script. +Of course, one can tell uzbl to use a different handler script, too. +This requires a one line change in uzbl's config file. .PP Uzbl does neither have its own download manager nor depends on a specific one, hence uzbl's browsing abilities will not be lowered by having @@ -1266,7 +1268,7 @@ .PP .B "Avoid captive user interfaces" . -One could say, that uzbl, to a large extend, actually \fIis\fP +One could say, that uzbl, to a large extent, actually \fIis\fP a captive user interface. But the difference to most other web browsers is, that uzbl is only the captive user interface frontend (and the core of the backend). @@ -1305,9 +1307,9 @@ The distribution includes another 3\,500 lines of Shell and Python code, which are the handler scripts and plugins like a modal interface. Further more, uzbl uses functionality of external tools like -\fIwget\fP and \fInetcat\fP. +\fIwget\fP and \fIsocat\fP. Up to this point, uzbl looks pretty neat and small. -The ugly part of uzbl is the web content renderer, webkit. +The ugly part of uzbl is the web content render engine, webkit. Webkit consists of roughly 400\,000 (!) lines of code. Unfortunately, small web render engines are not possible anymore because of the modern web. @@ -1397,7 +1399,7 @@ Throughout the paper, the aim was do explain \fIwhy\fP something should be done the Unix way. It was tried to give reasons that expose that the Unix Philosophy -is a preferrable way for designing software. +is a preferable way for designing software. .PP The Unix Philosophy is close to the software developer's point of view. Its main goal is taming the beast ``software complexity''.