docs/unix-phil: unix-phil.ms comparison

comparison unix-phil.ms @ 38:3628e9649046

wrote uzbl summary and did several spell fixes

author	meillo@marmaro.de
date	Sat, 03 Apr 2010 12:56:38 +0200
parents	9282c4cea18c
children	c87143793d82

comparison

equal deleted inserted replaced

-:9282c4cea18c
+:3628e9649046
 .AB
 .ti \n(.iu
 This paper discusses the importance of the Unix Philosophy in software design.
 Today, few software designers are aware of these concepts,
 and thus most modern software is limited and does not make use of software leverage.
-Knowing and following the tenets of the Unix Philosophy makes software more valuable.
+Knowing and following the guidelines of the Unix Philosophy makes software more valuable.
 .AE
 .\".if t .2C
 .FS
 Elm, pine, mutt, and a whole bunch of graphical \s-1MUA\s0s
 followed Mail's direction.
 They are large, monolithic programs which include all emailing functions.
 .PP
 A different way was taken by the people of \s-1RAND\s0 Corporation.
-In the beginning, they also had used a monolitic mail system,
+In the beginning, they also had used a monolithic mail system,
 called \s-1MS\s0 (for ``mail system'').
 But in 1977, Stockton Gaines and Norman Shapiro
 came up with a proposal of a new email system concept \(en
 one that honors the Unix Philosophy.
 The concept was implemented by Bruce Borden in 1978 and 1979.
 .NH 2
 Contrasts to monolithic mail systems
 .LP
 All \s-1MUA\s0s are monolithic, except \s-1MH\s0.
-Although there might acutally exist further, very little known,
+Although there might actually exist further, very little known,
 toolchest \s-1MUA\s0s, this statement reflects the situation pretty well.
 .PP
 Monolithic \s-1MUA\s0s gather all their functions in one program.
 In contrast, \s-1MH\s0 is a toolchest of many small tools \(en one for each job.
 Following is a list of important programs of \s-1MH\s0's toolchest
 The user does not leave the shell to run \s-1MH\s0,
 but he uses the various \s-1MH\s0 programs within the shell.
 Using a monolithic program with a captive user interface
 means ``entering'' the program, using it, and ``exiting'' the program.
 Using toolchests like \s-1MH\s0 means running programs,
-alone or in combinition with others, even from other toolchests,
+alone or in combination with others, even from other toolchests,
 without leaving the shell.
 .NH 2
 Data storage
 .LP
 One month after the first code showed up,
 a mailing list was installed to coordinate and discuss further development.
 A wiki was set up to store documentation and scripts that showed up on the
 mailing list and elsewhere.
 .PP
-In the, now, one year of uzbl's existance, it was heavily developed in various branches.
+In the, now, one year of uzbl's existence, it was heavily developed in various branches.
 Plaetinck's task became more and more to only merge the best code from the
 different branches into his main branch, and to apply patches.
 About once a month, Plaetinck released a new version.
 In September 2009, he presented several forks of uzbl.
-Uzbl, acutally, opened the field for a whole family of web browsers with similar shape.
+Uzbl, actually, opened the field for a whole family of web browsers with similar shape.
 .PP
 In July 2009, \fILinux Weekly News\fP published an interview with Plaetinck about uzbl.
 In September 2009, the uzbl web browser was on \fISlashdot\fP.
 .NH 2
 As uzbl does neither have its own download manager nor depends on a
 specific one, thus uzbl's browsing abilities will not be lowered by having
 a bad download manager.
 Uzbl's download capabilities will just as good as the ones of the best
 download manager available on the system.
-Of course, this applies to all of the other supplimentary tools, too.
+Of course, this applies to all of the other supplementary tools, too.
 .PP
 .B "Use software leverage to your advantage" .
 Shell scripts are a good choice to extend uzbl.
 Uzbl is designed to be extended by external tools.
 .B "Avoid captive user interfaces" .
 One could say, that uzbl, to a large extend, 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.
-Many parts of the backend are independed of uzbl.
+Many parts of the backend are independent of uzbl.
 Some are distributed with uzbl, for some external programs, handler scripts
 are distributed, arbitrary additional functionality can be added if desired.
 .PP
 The frontend is captive \(en that is true.
 This is okay for the task of browsing the web, as this task is only relevant
 The only case when one might want to automate the rendering function is
 to generate images of rendered webpages.
 .PP
 .B "Small is beautiful"
-is not easy to apply to a web browser, primary because the rendering task
+is not easy to apply to a web browser, primary because modern web technology
-is very complex.
+is very complex; hence the rendering task is very complex.
 Modern web browsers will always consist of many thousand lines of code,
 unfortunately.
 Using the toolchest approach and wrappers can split the browser into
 several small parts, tough.
 .PP
 Uzbl-core consists of about 3\,500 lines of C code.
 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 external tools like \fIwget\fP, \fInetcat\fP.
+Further more, uzbl uses functionality of external tools like
+\fIwget\fP and \fInetcat\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 renderer, webkit.
 Webkit consists of roughly 400\,000 (!) lines of code.
+Unfortunately, small web render engines are not possible anymore
+because of the modern web.
+The problems section will explain this in more detail.
 .PP
 .B "Build a prototype as soon as possible" .
 Plaetinck made his code public, right from the beginning.
-Discussion and development was open to everyone interessted.
+Discussion and development was, and still is, open to everyone interested.
-Within this first year of uzbl's existance, a new version was released,
+Development versions of uzbl can be obtained very simply from the code
+repository.
+Within the first year of uzbl's existence, a new version was released
 more often than once a month.
-Development version can be optained very simply from the code repository.
+Different forks and branches arose.
-Different forks and branches arose, new features were tested for suitability.
+They introduced new features, which were tested for suitability.
 The experiences of using prototypes influenced further development.
 Actually, all development was community driven.
-Plaetinck says:
+Plaetinck says, three months after uzbl's birth:
 ``Right now I hardly code anything myself for Uzbl.
 I just merge in other people's code, ponder a lot, and lead the discussions.''
 .[
 %A FIXME
 %O http://lwn.net/Articles/341245/
 .NH 2
 Problems
 .LP
-broken web
+Similar to \s-1MH\s0, uzbl, too suffers from being different.
+It is sad, but people use what they know.
-.PP
+Fortunately, uzbl's user interface can look and feel very much the
-But all functionality should be accessable at the backend too.
+same as the one of the well known web browsers,
-Uzbl fails here, mainly because of webkit.
+hiding the internal differences.
-Uzbl is not clearly separated into frontend and backend,
+But uzbl has to provide this similar look and feel to be accepted
-especially the render engine is not an separate building part,
+as a ``normal'' browser by ``normal'' users.
-like, for instance, the download manager is.
+.PP
-This comes from the design of webkit.
+The more important problem is the modern web.
-Webkit is not a self-standing program but a library to include.
+The modern web is simply broken.
-This might be of need for a graphical application to avoid complexity,
+It has state in a state-less protocol,
-but webkit has a lot of features included that do not belong to the
+it misuses technologies,
-webpage rendering job; a browsing history is just one example.
+and it is helplessly overloaded.
-.PP
+The result are web content render engines that must consist
-Ideally, webkit would just render the source of a webpage into a
+of hundreds of thousands lines of code.
-nice formated representation.
+They also must combine and integrate many different technologies,
-.PP
+only to make our modern web usable.
-be a black box
+Website to image converter are hardly possible to run without
+human interaction because of state in sessions, impossible
+deep-linking, and unautomatable technologies.
+.PP
+The web was misused to provide all kinds of imaginable wishes.
+Now web browsers, and eventually the users, suffer from it.
 .NH 2
 Summary uzbl
 .LP
+``Uzbl is a browser that adheres to the Unix Philosophy'',
+that is how uzbl is seen by its authors.
+Indeed, uzbl follows the Unix Philosophy in many ways.
+It consists of independent parts that work together,
+its core is mainly a mediator which glues the parts together.
+.PP
+Software leverage can excellently be seen in uzbl.
+It makes use of external tools, separates independent tasks
+in independent parts, and glues them together with small
+handler scripts, around uzbl-core.
+.PP
+As uzbl, more or less, consists of a set of tools and a bit
+of glue, anyone can put the parts together and expand it
+in any desired way.
+Uzbl is very flexible and customizable.
+These properties make it valuable for advanced users,
+but may keep novice users from using it.
+.PP
+Uzbl's main problem is the modern web, that makes it hard
+to design a sane web browser.
+Despite this bad situation, uzbl does a fairly good job.
 .NH 1
 Final thoughts

Mercurial > docs > unix-phil

comparison unix-phil.ms @ 38:3628e9649046