1.1 --- a/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 22:51:17 2009 +0100
     1.2 +++ b/thesis/tex/4-MasqmailsFuture.tex	Sat Feb 07 23:47:34 2009 +0100
     1.3 @@ -699,12 +699,14 @@
     1.4  
     1.5  A new design does protect against such dead ends.
     1.6  
     1.7 -Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail, which had an almost monopoly for a long time. But when security became important, \sendmail\ was only repaired instead of the problem sources---its insecure design---would have been removed. Thus security problems reappeared and over the years \sendmail's market share shrank as more secure \MTA{}s became available. \sendmail's reaction to the new requirements, in form of \name{sendmail~X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s.
     1.8 +Changing requirements are one possible dead end if the software does not evolve with them. A famous example is \sendmail; it had an almost monopoly for a long time. But when security became important, \sendmail\ was only repaired instead of the problem sources---its insecure design---would have been removed. Thus security problems reappeared and over the years \sendmail's market share shrank as more secure \MTA{}s became available. \sendmail's reaction to the new requirements, in form of \name{sendmail~X} and \name{MeTA1}, came much to late---the users already switched to other \MTA{}s.
     1.9  \index{sendmail}
    1.10  
    1.11 -Redesigning a software as requirements change helps keeping it alive. The knowledge of the Greek philosopher \person{Heraclitus} shall be an inspriation: ``Nothing endures but change.''
    1.12 +Redesigning a software as requirements change helps keeping it alive.
    1.13  \index{redesign}
    1.14  
    1.15 +The knowledge of \person{Heraclitus}, a Greek philosopher, shall be an inspriation: ``Nothing endures but change.''
    1.16 +
    1.17  Another danger is the dead end of complexity which is likely to appear by constant work on the same code base. It is even more likely if the code base has a monolithic architecture. A good example for simplicity is \qmail\ which consists of small independent modules, each with only about one thousand lines of code. Such simple code makes it obvious to understand what it does. The \name{suckless} project \citeweb{suckless.org} for example advertises such a philosophy of small and simple software by following the thoughts of the Unix inventors \cite{kernighan84} \cite{kernighan99}. Simple, small, and clear code avoids complexity and is thus also a strong prerequisite for security.
    1.18  \index{suckless}
    1.19  
    1.20 @@ -717,7 +719,7 @@
    1.21  
    1.22  The avoidance of dead ends is essential for further development on current code, too. Hence it is mandatory to refactor the existing code base sooner or later. Most important is the intention to modularize it, as modularity improves many quality properties, eases further development, and essentially improves security.
    1.23  
    1.24 -One example how modular structure makes it easy to add further functionality is described by \person{Sill}: He says that integrating the \name{amavis} filter framework into the \qmail\ system can be done by simply renaming the \path{qmail-queue} module to \path{qmail-queue-real} and renaming the \path{amavis} executable to \path{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in the \qmail\ system needs to be changed. This is a very admirable ability which is only possible in a modular system that consists of independent executables.
    1.25 +One example how modular structure makes it easy to add further functionality is described by \person{Sill}: He says that integrating the \name{amavis} filter framework into the \qmail\ system can be done by simply renaming the \path{qmail-queue} module to \path{qmail-queue-real} and then renaming the \path{amavis} executable to \path{qmail-queue} \cite[section~12.7.1]{sill02}. Nothing more in the \qmail\ system needs to be changed. This is a very admirable ability which is only possible in a modular system that consists of independent executables.
    1.26  \index{modularity}
    1.27  
    1.28  This thesis showed several times that modularity is a key property for good software design. Modularity can hardly be retrofitted into software, hence development on base of current code will need a throughout restructuring too, to modularize the source code. Thus a new design is similar to such a throughout refactoring, except the dependence on current code.