From uchinews!linac!att!att!allegra!alice!dmr Thu Jan 14 10:35:42 CST 1993 Article: 33234 of alt.folklore.computers Path: uchinews!linac!att!att!allegra!alice!dmr From: dmr@alice.att.com (Dennis Ritchie) Newsgroups: alt.folklore.computers Subject: Re: HISTORY OF WORD PROCESSIN Message-ID: <24604@alice.att.com> Date: 13 Jan 93 07:50:20 GMT Article-I.D.: alice.24604 Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 39 Status: R Doug Jones writes, "Prior to [1973], UNIX was developed without official sanction from the management of the labs (all technical staff members were allowed 20% of their time for personal projects, so this wasn't unusual). By having the labs support UNIX officially as a word processing system, Kernighan and Ritchie and Thompson and McIlroy were able to devote more of their time to UNIX than the 20% they would otherwise have been allowed." I don't know what criteria were used in merit review by BTL research management prior to 1973, but based on the feedback I got from my boss then, and allowing for the fact that McIlroy was Ken's department head, this is inexact. Proto-unix (ca. 1968-69) failed to be supported by management to the extent that they refused to buy a $500K PDP-10 for us, and it took a bit of subterfuge to get a $50K PDP-11. However, I'm certain the effort was never regarded as a "personal project" distinct from real work. Ken's and later my efforts with the PDP-7 were fully supported in terms of time commitment. In particular, Doug McIlroy was extraordinarily supportive, and enthusiastic, and he dove in himself just about instantly. My own merit reviews took a significant turn for the better when I joined Ken in working on Unix. It is true that word-processing and formatting (using Teletype model 37s) for the Bell Labs patent group was the first productive application of Unix outside our immediate group. And for the sake of history, here is the sequence of terminals I have used at home, all paid for by my employer. Dates are approximate. 1968: IBM 1050 (14.5 cps) 1970: Teletype 37 (15 cps) 1975: GE Terminet 300 (30 cps) 1978: HP 2621 (120 cps) 1983: Jerq (Blit) (120, later 960 cps) 1990: Gnot (Plan 9) (960 cps) 1992: Gnot (Plan 9) (8192 cps ISDN) Dennis Ritchie From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!nobody Tue May 31 23:33:46 CDT 1994 Article: 68734 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!nobody From: rdavis4@umbc.edu (davis robert) Newsgroups: alt.folklore.computers Subject: AT&T Unix Editions after the 7th Edition and Plan 9 Date: 31 May 1994 16:56:44 -0400 Organization: University of Maryland, Baltimore County Lines: 70 Message-ID: <2sg8acINNba7@umbc8.umbc.edu> NNTP-Posting-Host: f-umbc8.umbc.edu Summary: Some fascinating historical information Status: RO What follows is some information on UNIX and Plan 9 history that some a.f.c readers may find to be of interest: A few days ago, I posted the following question: Can anyone shed any light on AT&T versions of UNIX, after V7, which were never released outside of AT&T? Was Version 10 the last of the Version n flavors of UNIX? Also, did these internal versions of UNIX, which were not released, have much to do with Plan 9? Last night, I received the following, very interesting and informative, reply to it from Dennis Ritchie, which he has kindly given me permission to post: Sure. The general context is that by the early 80s, Unix development for products and internal support had moved into the organization first called USG, and which then (using a variety of names) ended up as USL. The research group continued to support its own version of the system for use by people in our group and for experimentation. The last real infusion of technology from us into USG/USL was streams, though we continued to consult with them on smaller things. The correct term for the releases the research group made was "editions" since they were always keyed to new editions of the manual--but still, "version n" is often used. The Eighth Edition system was licenced to about 20 universities starting in 1985. We had various things going against us--mostly, we didn't feel comfortable in pushing our system too hard as a competitor to System V, which was at that point the company's actual product; and moreover, we weren't in a position to support it. Taking it on was somewhat a labor of love both for us and for the people who licensed it. In subsequent years, we published the Ninth and Tenth Edition manuals and continued to work on (and use) the system. In particular our approach to networking and IPC, which stands in contrast to Berkeley's sockets and USL's TLI, was written up in SP&E by me and Presotto. Nevertheless it became clear several years ago that working on Unix was a dead end. The 8-10th edition systems worked only on Vax (no longer an interesting machine), and no one could get up the enthusiasm to port it. Instead it seemed time to move on. Plan 9 was written from scratch, although the API (i.e. the system calls) is for the most part similar to that of Unix. There are some very deep differences (especially the per-process interpretation of the file system namespace) that lead to a different overall structure. One thing that the 10th edition work influenced was its approach to networking (naming in networks, the importance of finding transport semantics that work across networks, etc.) This wasn't taken over wholesale, but if you read the SP&E paper and look at the Plan 9 approach, you'll see the similarity. Feel free to post this if you like. Dennis Ritchie -- Robert D. Davis | Eccentrics have more fun! :-) ...uunet!mystica!rdd |------------------------------------------------------ rdavis4@umbc.edu | Looking for work... if you can hire me, please ftp my 1-410-744-7964 | resume from ftp.digex.net, /pub/access/rdd/resume. From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!pipex!uunet!news.sprintlink.net!avg Fri Dec 3 02:21:18 CST 1993 Article: 53624 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!pipex!uunet!news.sprintlink.net!avg From: avg@sprintlink.net (Vadim Antonov) Newsgroups: alt.folklore.computers Subject: Re: The Original UNIX Date: 3 Dec 1993 07:36:32 GMT Organization: Sprint Internetworking Services Lines: 92 Message-ID: <2dmqa0$bu4@news.sprintlink.net> References: <1993Dec3.034115.20370@news.uiowa.edu> NNTP-Posting-Host: titan.sprintlink.net X-Newsreader: TIN [version 1.1 PL9] Status: RO I cannot tell about accuracy of pre-v6 Unix descriptions, but.. In <1993Dec3.034115.20370@news.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 (jones@pyrite) wrote: : The next step was to use a PDP-11/45. Nah. PDP-11/34 and PDP-11/40. : This still limited processes to : 64K each (well, you could go out on a limb and use 64K of code separated : from 64K of data, but that was messy). It was impossible in PDP-11s w/o separate I/D space (11/34 and 11/40). Separate code and data space on 11/45 and later models was quite natural and straightforward. The only problem was necessity to keep two copies of binaries for old and new PDPs. MNOS RL 1.2 (my v6-based v7-compatible :-) and BSD 2.9 also had code overlays (i.e. they can flip one or more pages on procedure calls) effectively allowing to build real large programs. DEMOS 2/P (P is for PDP) inherited BSD 2.9 overlays but after some heavy hacking page flipping was accelerated by factor of 10 which made them a practical alternative. As a matter of fact, practically all BSD-derived utilities in DEMOS 2/P were ported from BSD 4.1 (a VAX system -- including real large things like INGRES v7). : It had a memory management unit : that allowed the machine to address a total of 256K bytes, where each : 64K address space was made up of 8 segments of up to 8K bytes each. 11/45 had two 64Kb spaces (one is r/o) and could address up to 248Kb RAM. Later models (11/70 etc) could address up to 4Mb (by extending the memory bus to 22bits) but 64+64 limit was still there. Actually there was a Soviet-made machine, SM-1420, which could address up to 2Mb but had no separate I/D! : This : version of UNIX used a 3 segment model of memory for each process -- : a code segment (shared and reentrant), There was a program format with *writeable* and no shared code; some programs actually used it (ULISP...) : a data segment (private, statically : allocated, and initialized at load time, and a stack segment, initialized : with argv and argc. The data segment could be expanded (by sbrk) to : create space for such things as the heap used by malloc. Stack segment was expanded downwards automagically on protected page interrupts. On 11/40 and 11/34 there was no way to recover from that interrupt in general case and some instructions (like mov -(sp),-(sp)) were "prohibited". Later CPUs have fixed that problem with a special register (control reg 2 :-). : Segments were not paged! In theory, it would have been possible to treat : each 8K segment as a page, but this wasn't done. Instead, UNIX segments : were made of one or more adjacent 8K segments (the last of which might be : only partially allocated), and the whole segment was treated as a unit for : swapping purposes. Made absolutely no sense to *page* programs spread over only 8 pages. For all practical purposes all those pages were in active set. Later versions of Unix actually swapped small processes as whole pieces for the very same reason. : The result was that fork, for example, was quite easy : to implement; you just swap out the data and stack segments, then use the : copy in memory as the skeleton of the newly created process. Actually, fork was a side-effect of swapping :-) Somewhere i read that initially it was thought as "swap in but don't delete image in swap area". : The first version of UNIX I know of that used demand paged virtual memory : was BSD UNIX on the VAX. The design of the UNIX fork primitive that had : seemed so elegent in a swapping environment suddenly became a real problem, : because you can't duplicate a segment without copying the pages from disk : to main memory. There also was an issue of rotten VAX MMU design -- it lacks functionality necessary for straight-forward COW implementation. The realistic COW for UNIX appeared in NET BSD (derived from Mach). : Eventually, a fast solution to this was implemented, : involving lazy copying where only pages that were actually modified got : copied, and this solution is why UNIX now performs reasonably well in : demand paged virtual memory environments. Depends on which Unix :-) Later-age BSDs do it reasonably well. --vadim From cpierce1@cp500.fsic.ford.com Wed Jun 7 17:06:35 CDT 1995 Article: 104236 of alt.folklore.computers Xref: uchinews alt.folklore.computers:104236 Path: uchinews!vixen.cso.uiuc.edu!newsrelay.iastate.edu!newsxfer.itd.umich.edu!jobone!fiesta.srl.ford.com!eccdb1.pms.ford.com!cp500.fsic.ford.com!cpierce1 From: cpierce1@cp500.fsic.ford.com (Clinton Pierce (R)) Newsgroups: alt.folklore.computers Subject: Re: UNIX Folklore Questions Date: 7 Jun 1995 20:17:51 GMT Organization: Ford Motor Co., Powertrain Systems Lines: 75 Distribution: world Message-ID: <3r51hf$kjm@eccdb1.pms.ford.com> References: <3r4cl4$nef@eccdb1.pms.ford.com> NNTP-Posting-Host: cp500.fsic.ford.com Keywords: TRUE FOLKLORE Status: R In article <3r4cl4$nef@eccdb1.pms.ford.com>, cpierce1@cp500.fsic.ford.com (Clinton Pierce (R)) writes: |> I'm teaching a intro UNIX course and I've got a few holes in the courseware |> for background material. Can anyone help: |> |> 1. The "vi" editor uses "hjkl" for cursor movement. It's been explained |> to me that one of the early tubes that vi was run on actually had |> "^h^j^k^l" mapped to cursor movement and that vi was simply left that way |> (minus the control key). What was the name of that early terminal? |> |> 2. Why the slash "/" as a pathname separator? (I KNOW why DOS uses the |> backslash, and I know why the pipe (|) symbol is what it is...but why |> the slash?) |> |> 3. How was "Space Travel" played? |> |> 4. Is MULTICS still used? Where? |> |> 5. How big (estimation) were earlier UNIX source/binary distributions? |> For a full load of UNIX, how much disk was required? (For contrast against, |> say, AIX where a full load can easily exceed 500MB). Whew! That was fast! I got several replies in E-Mail. The most complete and authoritative came from Tom Duff, here it is: To: cpierce1@cp500.fsic.ford.com Date: Wed, 7 Jun 1995 15:04:11 EDT Subject: Re: UNIX Folklore Questions 1) The terminal with ^h^j^k^l cursor motion was the Lear-Seigler ADM1 (also ADM2, ADM3, ADM3a, etc.). The arrows on the hjkl keys of their keyboards, rather than the motion codes they accepted, probably suggested the vi motion commands. (What I mean is that even if the codes were different, the arrows being on the hjkl keys probably would have decided the matter.) 2) The slash was picked because its easy to type, (corner of the keyboard, no shift) and carries no other obvious semantic weight. 3) All I know about Space Travel is that it drew the sky as seen from a space ship, rather than showing the ship on a map as in Spacewar. 4) Multics is certainly still in use, although I'd be very surprised if Honeywell still made Multics machines. Don't know where. 5) Here are the sizes of various early UNIX distributions, calculated by running du over our archive copies (sizes in kilobytes): 1804 v5 1457 v6 8646 v7 31887 v8 893 32v 40200 4.2bsd The sizes of the actual distribution media are mostly slightly larger than these numbers. For example, v5 was distributed as an rk05 file system image whose exact size was 2436K bytes, (4872 blocks of 512 bytes each), but that included the free list, i-list and other file system overhead. -Tom Duff -- ----------------------------------------------------------------------o------ Clinton A. Pierce | "If you rush a Miracle Man | \ / \ / cpierce1@cp500.fsic.ford.com| you get rotten miracles." | \ G / DCI, Inc. on loan to Ford. | --Miracle Max, The Princess Bride | / \ / \ ------------------------------------------------------------------Freemason-- From peter@nmti.com Wed Aug 2 12:29:26 CDT 1995 Article: 109979 of alt.folklore.computers Xref: uchinews alt.folklore.computers:109979 comp.os.linux.advocacy:21049 comp.unix.advocacy:10815 Newsgroups: comp.os.linux.advocacy,comp.unix.advocacy,alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!swrinde!news.uh.edu!uuneo.neosoft.com!nmtigw!peter From: peter@nmti.com (Peter da Silva) Subject: Re: Recommend: Unix Haters Web page Message-ID: Sender: peter@nmti.com (peter da silva) Organization: Network/development platform support, NMTI References: <3vk20k$fd1@azure.acsu.buffalo.edu> Date: Tue, 1 Aug 1995 21:46:02 GMT Lines: 37 Status: R In article , Steve Summit wrote: > In article <3vk20k$fd1@azure.acsu.buffalo.edu>, stoner@cs.buffalo.edu > (Christopher A Stoner) writes: > > In article , Peter da Silva wrote: > > |% ls /usr/spool/news > > |/usr/spool/news not found > > |Gee, that doesn't work either. > > Well, if you are getting news from a remote server... > > then you won't be able to look at the spool files. > Unless you have a virtual filesystem that goes off and does NNTP > for you when you try to access /usr/spool/news/. Which of course is the point. If Usenet had been designed on the same principles as UNIX that's how it'd work. Of course UNIX hasn't been designed to UNIX principles since Version 7. Sockets suck. Streams suck worse. If UNIX networking was UNIXy you'd write a web client like this: ( echo "GET /" cat <&0 ) > /dev/tcp/www.yahoo.com/80 The bits of UNIX that people hate most aren't UNIX's fault at all. -- Peter da Silva (NIC: PJD2) `-_-' Network Management Technology Incorporated 'U` 1601 Industrial Blvd. Sugar Land, TX 77478 USA +1 713 274 5180 "Har du kramat din varg idag?"