From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13185 invoked from network); 6 Sep 2022 16:11:26 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 6 Sep 2022 16:11:26 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 59ECA40E73; Wed, 7 Sep 2022 02:11:13 +1000 (AEST) Received: from mail-oa1-f53.google.com (mail-oa1-f53.google.com [209.85.160.53]) by minnie.tuhs.org (Postfix) with ESMTPS id 0A55040E6B for ; Wed, 7 Sep 2022 02:11:09 +1000 (AEST) Received: by mail-oa1-f53.google.com with SMTP id 586e51a60fabf-11eab59db71so29246996fac.11 for ; Tue, 06 Sep 2022 09:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=802FUq0p0x/8adj7c8ylrUTxGCEzodFU+vRPoymoJ20=; b=QuRCOW8pohCmCiVjvCWf0KvEjqItaZP7kuVeev7Mr75HtTdRXAD4b+tMkwGa3n/7Q3 j2UYFLfYZofMjjXih7sJqD+FJUKrmH2rE7PqamdYK7ixgEJ08hePR5fPwHuTi2bqPwLJ +iV57DWLz2yvEmC/o/O4LufhMWd92KmNo2UUrSRj1sULHLheQhkDOHji2GfqRtukpK9I QBPcFTS/PIvu6ePIOP5bnjxQS2QXK1s0/kHAlLr6NDuDMs8RBXlsfWi2y5/y4fgFyK6L w5BsD6cqhJFZb7L81aLkddNOIleczL8ueuH/vQP6vbiBEkABCePGX09faIPSoverRO1/ EaHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=802FUq0p0x/8adj7c8ylrUTxGCEzodFU+vRPoymoJ20=; b=ZJFDyq5Gg/8I6XCfbjvbr6VQ4tskGPjOEvqzZ27Tqa+U/G9GBryl2Z9xx8T2OCHdAy DXUWWIzFec8NmxGplO6T7Jy59uDFftDXOlqbyOVFJnNPKlrfhHnaYAQsQ6t4VKtws8q+ iz0D3/M5MTukCx1H4t06Rzr8uQhkqcLBugHv7A//tPi+lWyOXSGrGyxF0SWlAPCi7p6L 7jx0pZ/Tju8vQN/LM5mCNHxftwsksR6GjincnfsBL7M55ww4Vgdn1FvwScArK9EGdcw1 7iFLvBbsvb25gmQThRwTd/+PLn+NlwyedXTHBuJxGwWmN2IoHb07rvP58UvlTFhYKiKH N3SQ== X-Gm-Message-State: ACgBeo1IiNSXswnaUxcdDIxvcTfSlvWGSuWw7x7SLEOsDVsg6hDOgGhv xUXDELYT9wtD7y4e1T6oN6NCCpXKg5gao8/LmQqeQdwTsWA= X-Google-Smtp-Source: AA6agR5tOWmh9sn3FotrvZQM/W3PlmOEAN5vcKHhGPJdIrM8+00XLbJi6rzuQQ1zTgqcxUMwi1qbNl4xzrUcehBjbNg= X-Received: by 2002:a05:6870:3115:b0:11e:753e:d2e3 with SMTP id v21-20020a056870311500b0011e753ed2e3mr12089736oaa.175.1662480607517; Tue, 06 Sep 2022 09:10:07 -0700 (PDT) MIME-Version: 1.0 References: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> In-Reply-To: <453CCF20-3A01-4655-A956-149EDC08FA36@canb.auug.org.au> From: Marc Donner Date: Tue, 6 Sep 2022 12:09:56 -0400 Message-ID: To: TUHS Content-Type: multipart/alternative; boundary="0000000000000ea1ef05e8046e2f" Message-ID-Hash: OUBAI4LUOIXDJA44UAJJ7LOB5GAGWONG X-Message-ID-Hash: OUBAI4LUOIXDJA44UAJJ7LOB5GAGWONG X-MailFrom: marc.donner@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Has this been discussed on-list? How Unix changed Software. List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000000ea1ef05e8046e2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Having spent many formative years at IBM Research throwing (metaphorical) bombs at mainframe systems and infiltrating the place with BSD, I have thought about this question on and off. I would like to augment your comments with a couple of extra observations: UNIX was built for a particular set of users - document writers and programmers Before UNIX the systems were industrial in design and scope. Sort of like MVS was a locomotive - designed to be used for hauling heavy freight (acres of data entry clerks answering 800 numbers and entering transactions). UNIX was more like cars and trucks - designed for use by knowledge workers. When I was a grad student I hung out with some remarkable programmers. We all observed that learning to program was impossible without a body of code to read, study, and learn from. The best places to learn programming in the 70s and 80s were places like MIT, Berkeley, Bell Labs, and IBM Research ... places with an established culture of sharing code internally and large repositories of code to read. By the mid-1980s the Microsoft folks established the notion that software was economically valuable. People stopped giving away source code (IBM's change in strategy was called OCO - "Object Code Only") and it totally shocked the software developer community by destroying the jobs for programmers at user sites. Combine that with the mid-1980s recession and the first layoffs that programmers had ever seen and we saw the first horrified realization that the social contract between programmers and employers did not actually exist. We, the programmer community, woke up and committed ourselves as much as ever we could to non-proprietary languages and tools, putting our shoulders to the OSS movement and hence to UNIX and the layer of tools built on top of it. Of course it helped to have some brilliant engineers like Ken, Dennis, Doug, Rob, Michael, Stu (and and and) and brilliant writers like Brian so that the thing (UNIX) had intellectual integrity and scope. It took UNIX twenty to thirty years, but the economic logic of our approach put an end to efforts to totally dominate the tech world. =3D=3D=3D=3D=3D nygeek.net mindthegapdialogs.com/home On Mon, Sep 5, 2022 at 7:49 PM steve jenkin wrote: > I=E2=80=99ve been looking at this question for a time and thought it coul= d=E2=80=99ve > appeared on the TUHS list - but don=E2=80=99t have an idea of the search = terms to > use on the list. > > Perhaps someone suggest some to me. > > As a starting point, below is what John Lions wrote on a similar topic in > 1978. Conspicuously, =E2=80=9CSecurity=E2=80=9D is missing, though =E2=80= =9CReliability & > Maintenance=E2=80=9D would encompass the idea. > > With hindsight, I=E2=80=99d suggest (Research) Unix took a very strong st= ance on > =E2=80=9CTechnical Debt=E2=80=9D - it was small, clean & efficient, even = elegant. And > =E2=80=98shipped' with zero known bugs. > > It didn=E2=80=99t just bring the Unix kernel to many architectures, the s= ame tools > were applied to create what we now call =E2=80=9COpen Source=E2=80=9D in = User land: > > - Multi-platform / portable > - the very act of porting software to diverse architectures > uncovered new classes of bugs and implicit assumptions. Big- & > Little-endian were irrelevant or unknown Before Unix. > - full source > - compatibility layers via > - written in common, well-known, well-supported languages [ solving the > maintenance & update problem ] > - standard, portable =E2=80=9Ctoolchains=E2=80=9D > - shell, make, compiler, library tools for system linker, > documentation & doc reading tools > - distribution systems including test builds, issue / fault > reporting & tracking > > An emergent property is "Good Security=E2=80=9D, both by Design and by (m= ostly) > error-free implementations. > > In the Epoch Before Unix (which started when exactly?), there was a lot o= f > Shared Software, but very little that could be mechanically ported to > another architecture. > Tools like QED and ROFF were reimplemented on multiple platforms, not > =E2=80=98ported=E2=80=99 in current lingo. > There are still large, complex FORTRAN libraries shared as source. > > There=E2=80=99s an important distinction between =E2=80=9COpen=E2=80=9D a= nd =E2=80=9CFree=E2=80=9D : cost & > availability. > > We=E2=80=99ve gone on to have broadband near universally available with e= asy to > use Internet collaboration tools - e.g. =E2=80=9Cgit=E2=80=9D, =E2=80=9Cm= ercurial=E2=80=9D and =E2=80=9CSubversion=E2=80=9D > just as CVS=E2=80=99s. > > The Unix-created Open Source concept broke Vendor Lock-in & erased most > =E2=80=9CSilos=E2=80=9D. > The BSD TCP/IP stack, and Berkeley sockets library, were sponsored by > DARPA, and made freely available to vendors as source code. > Similarly, important tools for SMTP and DNS were freely available as > Source Code, both speeding the implementation of Internet services and > providing =E2=80=9Cout of the box=E2=80=9D protocol / function compatibil= ity. > > The best tools, or even just adequate, became only a download & install > away for all coding shops, showing up a lot of poor code developed by > in-house =E2=80=9Cexperts=E2=80=9D and radically trimming many project sc= hedules. > > While the Unix =E2=80=9CSoftware Tools=E2=80=9D approach - mediated by th= e STDOUT / STDIN > interface, not API=E2=80=99s - was new & radical, and for many classes of= problems, > provided a definitive solution, > I=E2=80=99d not include it in a list of =E2=80=9COpen Source=E2=80=9D fea= tures. > > It assumes a =E2=80=9Ccommand line=E2=80=9D and process pipelines, which = aren=E2=80=99t relevant > to very large post-Unix program classes: Graphical Apps and Web / Interne= t > services. > > regards > steve jenkin > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Lions, J., "An operating system case study" ACM SIGOPS Operating Systems > Review, July 1978, ACM SIGOPS Oper. Syst. Rev. 12(3): 46-53 (1978) > > > 2. Some Comments on UNIX > ------------------------ > > There is no space here to describe the technical features of UNIX in > detail (see Ritchie and Thompson, 1974 ; also Kernighan and Plauger, 1976= ), > nor to document its performance characteristics, which we have found to b= e > very satisfactory. > > The following general comments do bear upon the present discussion: > > (a) Cost. > UNIX is distributed for "academic and educational purposes" to > educational institutions by the Western Electric Company for only a nomin= al > fee, > and may be implemented effectively on hardware configurations costing > less than $50,000. > > (b) Reliability and Maintenance. > Since no support of any kind is provided by Western Electric, > each installation is potentially on its own for software > maintenance. > UNIX would not have prospered if it were not almost completely > error-free and easy to use. > There are few disappointments and no unpleasant surprises. > > (c) Conciseness. > The PDP-11 architecture places a strong limitation on the size of the > resident operating system nucleus. > As Ritchie and Thompson (1974) observe, > "the size constraint has encouraged not only economy but a certai= n > elegance of design". > The nucleus provides support services and basic management of > processes, files and other resources. > Many important system functions are carried out by utility programs. > Perhaps the most important of these is the command language > interpreter, known as the "shell". > (Modification of this program could alter, even drastically, the > interface between the system and the user.) > > (d) Source Code. > UNIX is written almost entirely in a high level language called "C" > which is derived from BCPL and which is well matched to the PDP-11. > It provides record and pointer types, > has well developed control structures, > and is consistent with modern ideas on structured Programming. > (For the curious, the paper by Kernighan (1975) indirectly indicates > the flavour of "C" > and exemplifies one type of utility program contained in UNIX.) > Something less than i0,000 lines of code are needed to describe the > resident nucleus. > > pg 47 > > (e) Amenability. > Changes can be made to UNIX with little difficulty. > A new system can be instituted by recompiling one or more files (at an > average of 20 to 30 seconds per file), > relinking the file containing the nucleus (another 30 seconds or so), > and rebooting using the new file. > In simple cases the whole process need take no more than a few minutes= . > > (f) Intrinsic Interest. > UNIX contains a number of features which make it interesting in its ow= n > right: > the run-time support for the general tree structured file system > is particularly efficient; > the use of a reserved set of file names smooths the concepts of > device independence; > multiple processes (three or four per user is average) are used i= n > a way which in most systems is regarded as totally extravagant > (this leads to considerable simplification of the system/user > interface); > and the interactive intent of the system has resulted in an > unusually rich set of text editing and formatting programs. > > (g) Limitations. > There are few limitations which are of concern to us. > The PDP-11 architecture limits program size, and this for example > frustrated an initial attempt to transfer Pascal P onto the 11/40. > Perhaps the greatest weakness of UNIX as it is presently distributed > (and this is not fundamental!) > is in the area where other systems usually claim to be strong: > support for "bread and butter" items such as Fortran and Basic. > > (h) Documentation. > The entire official UNIX documentation, including tutorial material, > runs to less than 500 pages. > By some standards this is incredibly meagre, > but it does mean that student can carry his own copy in his brief > case. > > Features of the documentation include: > - an unconventional arrangement of material (unsettling at first, > but really very convenient); > - a terse, enigmatic style, with much information conveyed by > innuendo; > - a permuted KWIC index. > > Most importantly perhaps UNIX encourages the programmer to document hi= s > work. > There is a very full set of programs for editing and formatting text. > The extent to which this has been developed can be gauged from the > paper by Kernighan and Cherry (1975). > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin > > --0000000000000ea1ef05e8046e2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having spent many formative years at IBM Resear= ch throwing (metaphorical) bombs at mainframe systems and infiltrating the = place with BSD, I have thought about this question on and off.

I would like to augment your comments with a coupl= e of extra observations:

UNIX was buil= t for a particular set of users - document writers and programmers

Before UNIX the systems were industrial in des= ign and scope.=C2=A0 Sort of like MVS was a locomotive -=C2=A0 designed to = be used for hauling heavy freight (acres of data entry clerks answering 800= numbers and entering transactions).=C2=A0 UNIX was more like cars and truc= ks - designed for use by knowledge workers.

When I was a grad student I hung out with some remarkable programmers= .=C2=A0 We all observed that learning to program was impossible without a b= ody of code to read, study, and learn from.=C2=A0 The best places to learn = programming in the 70s and 80s were places like MIT, Berkeley, Bell Labs, a= nd IBM Research ... places with an established culture of sharing code inte= rnally and large repositories of code to read.

By the mid-1980s the Microsoft folks established the notion that s= oftware was economically valuable.=C2=A0 People stopped giving away source = code (IBM's change in strategy was called OCO - "Object Code Only&= quot;) and it totally shocked the software developer community by destroyin= g the jobs for programmers at user sites.=C2=A0 Combine that with the mid-1= 980s recession and the first layoffs that programmers had ever seen and we = saw the first horrified realization that the social contract between progra= mmers and employers did not actually exist.

We, the programmer community, woke up and committed ourselves as much= as ever we could to non-proprietary languages and tools, putting our shoul= ders to the OSS movement and hence to UNIX and the layer of tools built on = top of it.

Of course it helped to have= some brilliant engineers like Ken, Dennis, Doug, Rob, Michael, Stu (and an= d and) and brilliant writers like Brian so that the thing (UNIX) had intell= ectual integrity and scope.

It took UN= IX twenty to thirty years, but the economic logic of our approach put an en= d to=C2=A0efforts to totally dominate the tech world.

On Mon, Sep 5, 2022 at 7:49 PM steve jenkin <sjenkin@canb.auug.org.au> wrote:
I=E2=80=99ve been look= ing at this question for a time and thought it could=E2=80=99ve appeared on= the TUHS list - but don=E2=80=99t have an idea of the search terms to use = on the list.

Perhaps someone suggest some to me.

As a starting point, below is what John Lions wrote on a similar topic in 1= 978. Conspicuously, =E2=80=9CSecurity=E2=80=9D is missing, though =E2=80=9C= Reliability & Maintenance=E2=80=9D would encompass the idea.

With hindsight, I=E2=80=99d suggest (Research) Unix took a very strong stan= ce on =E2=80=9CTechnical Debt=E2=80=9D - it was small, clean & efficien= t, even elegant. And =E2=80=98shipped' with zero known bugs.

It didn=E2=80=99t just bring the Unix kernel to many architectures, the sam= e tools were applied to create what we now call =E2=80=9COpen Source=E2=80= =9D in User land:

=C2=A0- Multi-platform / portable
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - the very act of porting software to diverse a= rchitectures uncovered new classes of bugs and implicit assumptions. Big- &= amp; Little-endian were irrelevant or unknown Before Unix.
=C2=A0- full source
=C2=A0- compatibility layers via
=C2=A0- written in common, well-known, well-supported languages [ solving t= he maintenance & update problem ]
=C2=A0- standard, portable =E2=80=9Ctoolchains=E2=80=9D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- shell, make, compiler, library tools fo= r system linker, documentation & doc reading tools
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 distribution systems including te= st builds, issue / fault reporting & tracking

An emergent property is "Good Security=E2=80=9D, both by Design and by= (mostly) error-free implementations.

In the Epoch Before Unix (which started when exactly?), there was a lot of = Shared Software, but very little that could be mechanically ported to anoth= er architecture.
Tools like QED and ROFF were reimplemented on multiple platforms, not =E2= =80=98ported=E2=80=99 in current lingo.
There are still large, complex FORTRAN libraries shared as source.

There=E2=80=99s an important distinction between =E2=80=9COpen=E2=80=9D and= =E2=80=9CFree=E2=80=9D : cost & availability.

We=E2=80=99ve gone on to have broadband near universally available with eas= y to use Internet collaboration tools - e.g. =E2=80=9Cgit=E2=80=9D, =E2=80= =9Cmercurial=E2=80=9D and =E2=80=9CSubversion=E2=80=9D just as CVS=E2=80=99= s.

The Unix-created Open Source concept broke Vendor Lock-in & erased most= =E2=80=9CSilos=E2=80=9D.
The BSD TCP/IP stack, and Berkeley sockets library, were sponsored by DARPA= , and made freely available to vendors as source code.
Similarly, important tools for SMTP and DNS were freely available as Source= Code, both speeding the implementation of Internet services and providing = =E2=80=9Cout of the box=E2=80=9D protocol / function compatibility.

The best tools, or even just adequate, became only a download & install= away for all coding shops, showing up a lot of poor code developed by in-h= ouse =E2=80=9Cexperts=E2=80=9D and radically trimming many project schedule= s.

While the Unix =E2=80=9CSoftware Tools=E2=80=9D approach - mediated by the = STDOUT / STDIN interface, not API=E2=80=99s - was new & radical, and fo= r many classes of problems, provided a definitive solution,
I=E2=80=99d not include it in a list of =E2=80=9COpen Source=E2=80=9D featu= res.

It assumes a =E2=80=9Ccommand line=E2=80=9D and process pipelines, which ar= en=E2=80=99t relevant to very large post-Unix program classes: Graphical Ap= ps and Web / Internet services.

regards
steve jenkin

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Lions, J., "An operating system case study" ACM SIGOPS Operating = Systems Review, July 1978, ACM SIGOPS Oper. Syst. Rev. 12(3): 46-53 (1978)<= br>

2. Some Comments on UNIX
------------------------

There is no space here to describe the technical features of UNIX in detail= (see Ritchie and Thompson, 1974 ; also Kernighan and Plauger, 1976),
nor to document its performance characteristics, which we have found to be = very satisfactory.

The following general comments do bear upon the present discussion:

(a) Cost.
=C2=A0 =C2=A0UNIX is distributed for "academic and educational purpose= s" to educational institutions by the Western Electric Company for onl= y a nominal fee,
=C2=A0 =C2=A0and may be implemented effectively on hardware configurations = costing less than $50,000.

(b) Reliability and Maintenance.
=C2=A0 =C2=A0Since no support of any kind is provided by Western Electric,<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 each installation is potentially on its own for= software maintenance.
=C2=A0 =C2=A0UNIX would not have prospered if it were not almost completely= error-free and easy to use.
=C2=A0 =C2=A0There are few disappointments and no unpleasant surprises.

(c) Conciseness.
=C2=A0 =C2=A0The PDP-11 architecture places a strong limitation on the size= of the resident operating system nucleus.
=C2=A0 =C2=A0As Ritchie and Thompson (1974) observe,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "the size constraint has encouraged not on= ly economy but a certain elegance of design".
=C2=A0 =C2=A0The nucleus provides support services and basic management of = processes, files and other resources.
=C2=A0 =C2=A0Many important system functions are carried out by utility pro= grams.
=C2=A0 =C2=A0Perhaps the most important of these is the command language in= terpreter, known as the "shell".
=C2=A0 =C2=A0(Modification of this program could alter, even drastically, t= he interface between the system and the user.)

(d) Source Code.
=C2=A0 =C2=A0UNIX is written almost entirely in a high level language calle= d "C" which is derived from BCPL and which is well matched to the= PDP-11.
=C2=A0 =C2=A0It provides record and pointer types,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 has well developed control structures,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and is consistent with modern ideas on structur= ed Programming.
=C2=A0 =C2=A0(For the curious, the paper by Kernighan (1975) indirectly ind= icates the flavour of "C"
=C2=A0 =C2=A0 and exemplifies one type of utility program contained in UNIX= .)
=C2=A0 =C2=A0Something less than i0,000 lines of code are needed to describ= e the resident nucleus.

pg 47

(e) Amenability.
=C2=A0 =C2=A0Changes can be made to UNIX with little difficulty.
=C2=A0 =C2=A0A new system can be instituted by recompiling one or more file= s (at an average of 20 to 30 seconds per file),
=C2=A0 =C2=A0relinking the file containing the nucleus (another 30 seconds = or so),
=C2=A0 =C2=A0and rebooting using the new file.
=C2=A0 =C2=A0In simple cases the whole process need take no more than a few= minutes.

(f) Intrinsic Interest.
=C2=A0 =C2=A0UNIX contains a number of features which make it interesting i= n its own right:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the run-time support for the general tree struc= tured file system is particularly efficient;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the use of a reserved set of file names smooths= the concepts of device independence;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple processes (three or four per user is a= verage) are used in a way which in most systems is regarded as totally extr= avagant
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (this leads to considerable simpl= ification of the system/user interface);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and the interactive intent of the system has re= sulted in an unusually rich set of text editing and formatting programs.
(g) Limitations.
=C2=A0 =C2=A0There are few limitations which are of concern to us.
=C2=A0 =C2=A0The PDP-11 architecture limits program size, and this for exam= ple frustrated an initial attempt to transfer Pascal P onto the 11/40.
=C2=A0 =C2=A0Perhaps the greatest weakness of UNIX as it is presently distr= ibuted (and this is not fundamental!)
=C2=A0 =C2=A0is in the area where other systems usually claim to be strong:=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 support for "bread and butter" items = such as Fortran and Basic.

(h) Documentation.
=C2=A0 =C2=A0The entire official UNIX documentation, including tutorial mat= erial, runs to less than 500 pages.
=C2=A0 =C2=A0By some standards this is incredibly meagre,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 but it does mean that student can carry his own= copy in his brief case.

=C2=A0 =C2=A0Features of the documentation include:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - an unconventional arrangement of material (un= settling at first, but really very convenient);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - a terse, enigmatic style, with much informati= on conveyed by innuendo;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - a permuted KWIC index.

=C2=A0 =C2=A0Most importantly perhaps UNIX encourages the programmer to doc= ument his work.
=C2=A0 =C2=A0There is a very full set of programs for editing and formattin= g text.
=C2=A0 =C2=A0The extent to which this has been developed can be gauged from= the paper by Kernighan and Cherry (1975).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenki= n@canb.auug.org.au http://members.tip.net.au/~sjenkin
--0000000000000ea1ef05e8046e2f--