news@omepd (News Account) (08/19/88)
---------- From: mcg@mipon2.intel.com (Steven McGeady) Path: mipon2!mcg In article <274@umbio.MIAMI.EDU> jherr@umbio.MIAMI.EDU (Jack Herrington) writes: >BTW, BSD 2.9 was the fore-runner of 4.1. Which in turn spawned 4.2, >who in turn was kind enough to spawn 4.3, and soon 4.4. No, this isn't true. BSD 1.0 (although it was probably just called the "Berkeley Distribution") came out in the summer of 1979 (78?). I remember because Mike Sleator, Rico Tudor, Alan Watt, and I drove from Reed College in Portland to Berkeley in a pink 1956 Buick Roadmaster to pick it up from Bill Joy. We were interested in the Berkeley Pascal compiler, which was first released on that tape, although it had other goodies on it, including a hacked-up version of 'ed' called 'ex' (no 'vi' then). Everyone at that time (Yale, Harvard, Purdue, us) had hacked 'ed' to put in prompts or whatever, but Bill went way overboard :-) with this thing called 'open' mode, which ultimately grew into 'vi'. The code on this tape was (only) for the PDP-11, because that's all anyone had at the time. At some later time, BSD 2.0 came out, still oriented toward the PDP-11. BSD 2.0 may have come along at the same time as V7, I don't recall. In 1981 or 1982, BSD 3.0 came out, which was Berkeley's answer to AT&T's V32, the first (non-paging) VAX version of UNIX. At this stage, the BSD 2.0 distribution for the PDP-11 started growing fractional digits, and had tried to track the VAX BSD releases, which went to 4.0, followed shortly by 4.1, then a long (breathless) gap in which some parties got interim versions such as 4.1b and 4.1c, then 4.2, and another long gap, and then 4.3. The are probably other fractional releases to which I was not privy, but these are the major ones. BSD 2.? has hit major releases 2.3, 2.4, 2.9, and beyond, methinks, though I haven't run on a PDP-11 for years. BSD 4.2 first implemented the major changes in the filesystem and added all the networking code. BSD 4.3 made it all work. The ancestry of UNIX is reasonably convoluted, including as it does the above-mentioned Berkeley releases, the Bell Labs Research UNIX releases (V5, V6, V7, V8), the AT&T PWB Releases (PWB1.0, PWB3.0), and the related AT&T Product Releases (System III, System V, Sys VR1, R2, R3, R4). The early lineage was also molded by university contributions from places other than Berkeley. Did anyone besides me ever run the 'Yale Shell'? Yale, Harvard, Purdue, University of Toronto, City University of New York (CUNY), and a number of other places made many contributions to the community back then. Armando Stettner once put together a UNIX family tree, but I don't know what became of it. But I digress ... S. McGeady
lance@Roma.orc.olivetti.com (Lance Berc) (08/20/88)
In article <3763@omepd> mcg@iwarpo3.UUCP (Steve McGeady) writes: > >BSD 4.2 first implemented the major changes in the filesystem and added >all the networking code. BSD 4.3 made it all work. > The first crack at the networking code was 4.1a, which was enough for us to get all our Vaxen talking together. The revamped file system came out with 4.1c. As far as I know, 4.1b was never a full release. Other than parts of the networking (especially IP subnets) 4.2 was pretty solid. Most of the 4.3 changes were performance enhancements over 4.2. lance Lance Berc lance@orc.olivetti.com Beer as an alternate Olivetti Research Center lance%orc.uucp@unix.sri.com currency! Menlo Park, California (415) 496-6248 < These opinions bear no resemblance to those of Ing. C. Olivetti & C. SpA. >
henry@utzoo.uucp (Henry Spencer) (08/21/88)
In article <27596@oliveb.olivetti.com> lance@Roma.UUCP (Lance Berc) writes: >... Other than parts of the networking (especially IP subnets) >4.2 was pretty solid... Well, if you ignore a large stack of bugs, including some nasty security holes... -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
allbery@ncoast.UUCP (Brandon S. Allbery) (08/24/88)
As quoted from <3763@omepd> by news@omepd (News Account): +--------------- | but these are the major ones. BSD 2.? has hit major releases 2.3, 2.4, 2.9, | and beyond, methinks, though I haven't run on a PDP-11 for years. +--------------- BSD 2.10 was released concurrently with BSD 4.3, and tracks its features insofar as such is possible on a PDP-11. Speaking of BSD... I have heard that Berkeley is taking the time to divide the BSD sources into the part that requires an AT&T license and the part that doesn't. Which side will the Pascal compiler fall on? Also, back when ncoast was a Model 16 with a pitifully small hard drive (I often found my home directory to be on a mounted floppy!) one of the first generation ncoast hackers told me about Berkeley Pascal. One of the things he said to me was that it required a modified yacc. Is that so? Is there a version that doesn't, or a way to change it so it doesn't, or a way for a non-source-licensed site to bring up the modified yacc? (This entire paragraph is irrelevant if the Pascal compiler turns out to have AT&T code in it.) ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
donn@utah-gr.UUCP (Donn Seeley) (08/24/88)
[I'm crushed that no one has remembered the notorious 8.2 BSD... 9.2 BSD was the obvious successor, but was never implemented.] From: allbery@ncoast.UUCP (Brandon S. Allbery) ... I have heard that Berkeley is taking the time to divide the BSD sources into the part that requires an AT&T license and the part that doesn't. Which side will the Pascal compiler fall on? Almost certainly, the AT&T side. It's probably not a problem that Ken Thompson helped to write it, but it certainly is a problem that it generates PCC (/lib/f1) intermediate code. There's also the yacc issue (see below). As for the translator/interpreter system, it's possible that these sources are independent from AT&T; if the yacc problem is resolved, it might be possible to use the non-compiler part of Pascal. ... One of the things he said to me was that it required a modified yacc. Is that so? ... Yes, Berkeley Pascal uses its own version of yacc, called 'eyacc'. I've thought about implementing a PCC intermediate code front end for GCC. If Berkeley Pascal turned out to be free, such a back end could buy you a compiler. I'm not sure if it's worth it, though. This is one of the few times I've heard anyone express any desire to use Berkeley Pascal except as a last resort, Donn Seeley University of Utah CS Dept donn@cs.utah.edu 40 46' 6"N 111 50' 34"W (801) 581-5668 utah-cs!donn
chris@mimsy.UUCP (Chris Torek) (08/25/88)
In article <12285@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >I have heard that Berkeley is taking the time to divide the BSD sources into >the part that requires an AT&T license and the part that doesn't. Which >side will the Pascal compiler fall on? [someone told] me ... that it >required a modified yacc. Is that so? Is there a version that doesn't, >or a way to change it so it doesn't, or a way for a non-source-licensed >site to bring up the modified yacc? It uses `eyacc', which is slightly hacked for error recovery, and at the time, had larger compiled-in limits. (It may still have larger limits, although I believe yacc's limits were expanded in 3BSD.) I have reproduced below the READ_ME file and the comment from ey1.c (which the READ_ME claims is in `y1.c'). >(This entire paragraph is irrelevant if the Pascal compiler turns out >to have AT&T code in it.) Probably not, but there is one small detail: It uses the f77 code generator, which is quite definitely derived from AT&T code. Hence you could make similar changes to bison (e.g.), and come up with a working `compiler', but all it would produce would be a PCC intermediate file. [READ_ME:] Copyright (c) 1980 Regents of the University of California. All rights reserved. The Berkeley software License Agreement specifies the terms and conditions for redistribution. @(#)READ_ME 5.1 (Berkeley) 4/29/85 August 28, 1977 This directory contains source for a version of yacc needed by the Pascal parser. The differences between this yacc and a stadard version 6 yacc are indicated in a comment in y1.c. Note that the standard yacc parser will not work on the tables produced by "eyacc" and also that these changes are really useful only with a fairly large set of error recovery routines which are part of both "pi" and "pxp". The routines are language independent, but the method will only work on languages which have some redundancy in them... it is probably ill suited for C, but would work fine in ALGOL-60, ALGOL-W, EUCLID, LIS, SP/K, PL/1, ALPHARD, CLU, ... Sun Apr 8 21:43:08 PST 1979 A paper describing the method used by eyacc will appear in August in the SIGPLAN Boulder conference. Mon May 5, 1980 The eyacc in this directory has been modified to work for version 7. This involved syntax fixes and changing the I/O calls to standard version 7 calls. [ey1.c comment:] /**** NB ----- * * This version of yacc, known as "eyacc" has been slightly but * importantly modified to allow error recovery in the UNIX Pascal * translator "pi" and also in "pix". * * Changes here include: * * 1) Enumeration of test actions when "error" is an input token. * * 2) Change to the encoding of the action entries. Test entries * are encoded as the arithmetic inverse of the symbol being tested * for. This is an optimization that makes the parser run at the * same speed even though, with error productions and enumerated * lookaheads, it would normally be much slower. Of course the * same thing could be done to the regular yacc... * * 3) Different table sizes * * 4) Recognizes form feeds * * 5) Also most of the numbers for the sizes of the tables have been * increased, to an extent to allow for "eyacc"ing of the Pascal grammar * and of a grammar which I have for "EUCLID". * * There seem to be subtle dependencies between the various magic * numbers... I found some of them but to be safe most of the limits * are very generous... for this reason "eyacc" will most likely * have to run separate i/d... no matter. * * Bill Joy * Computer Science Division * EECS Department * University of California, Berkeley * Berkeley, California 94704 * * Office: (415) 642-4948 * Home: (415) 524-4510 ****/ -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
allbery@ncoast.UUCP (Brandon S. Allbery) (08/30/88)
As quoted from <2805@utah-gr.UUCP> by donn@utah-gr.UUCP (Donn Seeley): +--------------- | From: allbery@ncoast.UUCP (Brandon S. Allbery) | | ... | I have heard that Berkeley is taking the time to divide the BSD | sources into the part that requires an AT&T license and the | part that doesn't. Which side will the Pascal compiler fall on? | | This is one of the few times I've heard anyone express any desire to use | Berkeley Pascal except as a last resort, +--------------- You got a better idea? One that doesn't require us to shell out money we don't have to buy a commercial Pascal (for a machine that runs an outdated OS!)? (Yes, I know about "p2c", but it's not the same thing, really. Although fancy front-ends might succeed in making it look similar to a real Pascal compiler.) ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
mikej@cpmain.UUCP (Michael R. Johnston) (09/02/88)
I have apparently come into this one late. Was the "History of BSD Unix" an
article that was posted to the net? If so would someone mind mailing me
a copy?
BTW: Don't ALL mail me a copy if it is large. Maybe send me a note asking
if I've received it or not *GRIN*.
Thanks all.
--
Michael R. Johnston - @NET: mikej@cpmain.uucp
...{cmcl2!phri!,uunet!}dasys1!cpmain!mikej || ...philabs!mergvax!cpmain!mikej