From bogus@does.not.exist.com Fri Dec 28 08:08:12 2018 From: bogus@does.not.exist.com () Date: Thu, 27 Dec 2018 22:08:12 -0000 Subject: No subject Message-ID: runs the same stuff. > You can find T11 chips in several Q-bus and Unibus peripherals, most notably > the RQDX1, 2, and 3 (the chip labeled "27-17311-01"). Also used in VT240/241 terminals. My collection have some marked DEC DC311/es (T-11 engineering samples). I's a nice chip with a straightforward interface. Anyone that knows 8085, nsc800 would like interfacing t-11. Instruction set is base LSI11. Allison Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id EAA79855 for pups-liszt; Thu, 11 May 2000 04:16:31 +1000 (EST) From bogus@does.not.exist.com Fri Dec 28 08:08:12 2018 From: bogus@does.not.exist.com () Date: Thu, 27 Dec 2018 22:08:12 -0000 Subject: No subject Message-ID: register compatible to the SBI, BI, XMI CI adapters. (+- a few additional registers, if I remember correctely.) Once I had the idea to write DSSI support for NetBSD. I gave up this idea, as this requires a TM doc for SCA, and this is a unobtainioum. As Ultrix has this bits already, it should be doable in Ultrix. -- tsch��, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/ From bogus@does.not.exist.com Fri Dec 28 08:08:12 2018 From: bogus@does.not.exist.com () Date: Thu, 27 Dec 2018 22:08:12 -0000 Subject: No subject Message-ID: > > These file are now in the Unix Archive on minnie.tuhs.org in > PDP-11/Boot_Images/2.11_on_Simh > > The mirror sites should pick them up soon. > From bogus@does.not.exist.com Fri Dec 28 08:08:12 2018 From: bogus@does.not.exist.com () Date: Thu, 27 Dec 2018 22:08:12 -0000 Subject: No subject Message-ID: old licenses are still valid. Caldera/SCO are the le- gal owners today; i.e. the license holders. I'm not aware that they created a new license, super- seeding the old ones. My opinion is that the xBSDs are still restricted (to personal, educational/research type of use). The first really unrestricted BSD would be 4.4BSD-lite. NetBSD was indeed the first spin-off of this one... But as all the precedent writers, I'm no lawyer too. -- M. Giegerich, mail: migieger at vsnl.com, phone: +91.(0)80.5530154 From bogus@does.not.exist.com Fri Dec 28 08:08:12 2018 From: bogus@does.not.exist.com () Date: Thu, 27 Dec 2018 22:08:12 -0000 Subject: No subject Message-ID: "Cuckoo's Egg", by Cliff Stoll, and his accounts of that whole business are interesting. Incidentally that's the book that hatched my interests in things UNIX. And as it happens, I constantly, perhaps every couple of months read it. Dennis, did you see my message on when a GUI was first available with UNIX? If so, please contact me off-list. Or even on-list. ------------------- Gregg C Levine hansolofalcon at worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke."� Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: tuhs-admin at minnie.tuhs.org [mailto:tuhs-admin at minnie.tuhs.org] On > Behalf Of Dennis Ritchie > Sent: Monday, October 14, 2002 11:41 PM > To: tuhs at minnie.tuhs.org; dmr at plan9.bell-labs.com > Subject: [TUHS] Re: rtm > > Garcia is correct to praise the Hafner/Markoff account > of the worm incident. There were some details about > the kids' accounts and exploits that Markoff decided > to elide; by the time he wrote that chapter he had > become rather sympathetic with the Morris family. > > In 1995 another big incident occurred: the exploitation > of the SYN TCP-connection takeover attack (Mitnick > etc.) Markoff got another front-page NYT story out > of this (and a book with Shimomura). I sent mail > to Markoff at the time of the newspaper coverage reminding > him that RTM had discovered the basic attack > in 1985 (see CSTR 117 at > http://www.cs.bell-labs.com/cm/cs/cstr.html ); > while here during a summer. Markoff replied in part, > > >Interesting how often RTM figures, one way or another, in your front-page > >stories, and of course the [Cyberpunk] book.... > > > > Dennis Ritchie > > yes, this is true. you know i sat there on sunday for about ten minutes and > thought about whether i should include rtm in my story - it would obviously > have spiced it up. i finally decided not to on the grounds that 1. i have > done enough to mythologize him for one decade 2. he is probably entitled > not to be dragged through all this again. i still wonder whether i did the > readers a disservice... > > Incidentally, "RTM Sr." was (while here) "rhm" by login name, > and always called Bob; I don't think he actually has a middle name (at least > I don't know it.) I think it's like Harry S Truman. RTM > is called Robert, and never used Jr. > > About > > > [Bob] Morris, he said, was the kind of guy who always liked to tinker with > > things, and if an object had buttons, Morris just had to push them. > > In fact, sometimes Morris was just a little too quick with his fingers. > > On one side of a machine room was the light switch, and on the other > > side was the power to the machine. > > > On at least one occasion, you guessed it -- Morris hit the wrong switch. > > Some people hung a disk pack that got ruined around his neck, and someone > > put up a big sign as a reminder: "THIS IS THE WEST WALL!" > > I suspect that we may be dealing with the "Schryer filter" regarding > some of the details. Norm S. was right about Bob's being > an aggressive investigator and fiddler, but I don't > connect the west-wall sign with Morris in particular, but my > memory could be failing too. Norman Wilson > might have been around for advent of the sign. > In the event, it had more to do with circuit breakers > labelled in small print "east wall" and "west wall" > and someone choosing the wrong one. > > Dennis > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/tuhs From bogus@does.not.exist.com Fri Dec 28 08:08:12 2018 From: bogus@does.not.exist.com () Date: Thu, 27 Dec 2018 22:08:12 -0000 Subject: No subject Message-ID: > > These file are now in the Unix Archive on minnie.tuhs.org in > PDP-11/Boot_Images/2.11_on_Simh > > The mirror sites should pick them up soon. > From bogus@does.not.exist.com Fri Dec 28 08:08:12 2018 From: bogus@does.not.exist.com () Date: Thu, 27 Dec 2018 22:08:12 -0000 Subject: No subject Message-ID: when Ken went to the U.K to give a talk, he made the decision to switch over to the | symbol. Anyway, I could be completely wrong about this being in Salus' book, so if I am, I'll have to hunt down where this info came from. Cheers, Warren From ches at cheswick.com Sat Dec 1 00:55:11 2018 From: ches at cheswick.com (WIlliam Cheswick) Date: Fri, 30 Nov 2018 09:55:11 -0500 Subject: [TUHS] man-page style In-Reply-To: <20181129184845.GB18414@mcvoy.com> References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> Message-ID: <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> I sat down to my first TCP/IP connected host around 1985, and the first thing I wanted to do was to configure my first non-UUCP email machine. After an hour of wading through sendmail’s state machines, I gave up wondering why it had to be so hard. In the amazing 184 BSTJ, Dave Presotto had described upas, the replacement he built for sendmail. I loved its ease of use, and it was one of the reasons I wanted to join 1127, which I did in late 1987. I supported email and upas for a number of years, including the {bitnet | csnet | uucp | acsnet(?)} -> domain migration. Like the proverbial (and non-existent) boiling frog, this crept up on me: it was a mild surprise to realize we were using the other stuff much any more. Aside from configuration issues, the main complaint with sendmail was that it was a huge program running as root, with intentional and unintentional holes in. For many years it was a steady source of security problems, including its use in the Morris worm. That said, sendmail is still running, and handling a fair amount of mail, I believe. A few years ago I checked for recent security problems and found none reported. I think this is a case of “software annealing”: if you don’t change the specs much, and keep working on it, you will eventually get most of the bugs. As for the configuration: when Norman Wilson moved to Toronto, he implemented some form of little language for configuring sendmail, treating it somewhat as an assembly language. I don’t know the details, but they might be of interest. > On Nov 29, 2018, at 1:48 PM, Larry McVoy wrote: > > Indeed. Sendmail got a lot of hate but mostly from people in pure > user at host.domain worlds. I lived in the UUCP / BitNet / Arpanet > world and while sendmail was definitely not the easiest thing to > configure, once you got it right it just kept working (unlike UUCP > that seemed to need constant babysitting). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ches at cheswick.com Sat Dec 1 01:05:42 2018 From: ches at cheswick.com (William Cheswick) Date: Fri, 30 Nov 2018 10:05:42 -0500 Subject: [TUHS] Upas rewrite little language In-Reply-To: <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> Message-ID: Whoa! I hadn’t realized that I have in my archives mail configuration files from no later that 1993. Here is one rewrite file from “research”, as in “research!dmr": more rewrite # local mail [^!@%.=]+ translate "exec /v/lib/upas/translate '&'" local!([^!@]+) >> /usr/spool/mail/\1 \l!(.+) alias \1 research\.att\.com!(.+) alias \1 research\.research\.att\.com!(.+) alias \1 plan9\.research\.att\.com!(.+) alias \1 league\.att\.com!(.+) alias league!\1 league\.research\.att\.com!(.+) alias league!\1 league!(.+) alias \1 # convert @ format to ! format ([^!]+)@([^!@]+) alias \2!\1 # convert % addresses for us only. ([^!]+)%([^!%]+) alias \2!\1 # network gateways uucp!(.+) alias \1 bitnet!(.+) alias inet!bitnet!\1 uunet!(.+) alias inet!uunet.uu.net!\1 .*tempo\.att\.com!.* | "exec /v/lib/upas/route '\s' allegra.att.com" "'&'" vax135!(.*) | "exec /v/lib/upas/route '\s' big.l1135.att.com" "\1" \[([^!]+)\]!(.+) | "exec /v/lib/upas/route.ip '\s' '\1'" "'\2'" ([^!]+\.att\.com)!(.+) | "exec /v/lib/upas/route '\s' '\1'" "'\2'" [^!]+\..* | "exec /v/lib/upas/route '\s' inet" "'&'" ([^!]+)!(.+) | "exec /v/lib/upas/route '\s' '\1'" "'\2’" ==== and here is the rewrite file for the mail application gateway no later than 1998: # get rid of the .att.com domain part of the name. # It's not used internally. ([^%!@.]+)\.att\.com!(.+) alias \1!\2 # the following must change: we don't really want these used. att\.com!(.+) alias \1 att\.arpa!(.+) alias \1 (arpa|att-gw|gate)(\.arpa)?!(.+) alias \3 # rerouting: uunet!(.+) alias uunet.uu.net!\1 mcvax!(.+) alias uunet.uu.net!mcvax!\1 local!(.+) >> /usr/spool/mail/\1 #tempo!(.+) alias research!tempo!\1 sola!(.+) alias jones!\1 # a very common mistake .*! | "echo Bad address: '&'; exit 1" # a problem at cunyvm. cunyvm\.cuny\.edu!(cunyvm\.cuny\.edu)!(.+) alias \1!\2 # gateways uucp!(.+) alias \1 csnet!(.+) alias relay.cs.net!\1 bitnet!([^!]+)!(.+) alias CUNYVM.CUNY.EDU!\1.BITNET!\2 bitnet!([^!]+)@([^!]+) alias CUNYVM.CUNY.EDU!\2.BITNET!\1 mailnet!([^!]+)!(.+) alias mit-multics.arpa!\1.MAILNET!\2 acsnet!(.+) alias research!& attmail!(.+) auth false # attmail!(.+) alias attbl!attmail!\1 # convert @ format to ! format always (so locals can use @ format) (.+)@([^!@]+) alias \2!_pct_!\1 # convert % format only if the first hop isn't on the internet. ([^!]+)%([^!%]+) alias \2!\1 ([^!.]+)!(.+!)?_pct_!(.+)%([^!%]+) alias \1!\2\4!_pct_!\3 ([^!.]+)!(.+)%([^!%]+) alias \1!\3!_pct_!\2 # get rid of our _pct_ tag ((.+)!)?_pct_!(.+) alias \1\3 # don't route through research just to get to another machine # this MUST follow the %@ conversion research!([^!]+)!(.+) alias \1!\2 research!([^!]+) alias inet!\1 # at this point, anything without a "." in the first component inet!(.+) | "exec /usr/lib/upas/route.inet '\s' inet" "'\1'" (att|coma|alice|allegra)!(.+) | "exec /usr/lib/upas/route.toatt '\s' \1" "'\2'" ([^.!]+)!(.+) | "exec /usr/lib/upas/route.toatt '\s' att" "'&'" # Only local or Internet Domain addresses below this line. # various semi-official domain addresses ([^!]+)\.(csnet|bitnet|acsnet|mailnet|uucp)!(.*) alias \2!\1!\3 # Domain routings - arranged with the other AT&T postmasters sf\.att\.com!(.+) alias attunix!\1 ([^!.]+)\.sf\.att\.com!(.+) alias attunix!\1!\2 ([^!.]+)\.(astro|mercury|phone|div111)\.nj\.att\.com!(.+) alias \1!\2 ([^!]*\.)?mis\.oh\.att\.com!.+ alias att!& ([^!]*\.)?dptg\.att\.com!.+ alias dptg!& ([^!]*\.)?garage(\.nj)?\.att\.com!.+ alias garage!& ([^!]*)\.tempo(\.nj)?\.att\.com!(.+) alias \1!\3 ([^!]*\.)?homer\.nj\.att\.com!.+ alias ulysses!& ([^!]+)\.aloft\.att\.com!(.+) alias aloft!& (([^!]*\.)?uso\.att\.com)!(.+) | "smtpqer -n -d .att.com -H att.att.com '\s' '\1'" "'\3'" ([^!]+)\.att\.com(\.)?!(.+) | "echo 'Unknown AT\&T domain:' '&' >\&2; exit 1" # Ready to send Internet mail. ([^!]+)!(.+) | "smtpqer -n -d .att.com -H att.att.com '\s' '\1'" "'\2'" # carefully selected local translates postmaster alias coma!postmaster [^!@%]*[._]+[^!@%]* translate \ "exec /usr/lib/post/post -o '%^25name %20ema %^city, %+state ' -x -- '&'" [^!@%]+ translate "exec translate '&'" [^!@%]+ >> /usr/spool/mail/& -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Dec 1 08:58:55 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 1 Dec 2018 09:58:55 +1100 (EST) Subject: [TUHS] man-page style In-Reply-To: <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> Message-ID: On Fri, 30 Nov 2018, WIlliam Cheswick wrote: > I supported email and upas for a number of years, including the {bitnet > | csnet | uucp | acsnet(?)} -> domain migration.  Like the proverbial > (and non-existent) boiling frog, this crept up on me: it was a mild > surprise to realize we were using the other stuff much any more. Err, why the query after ACSnet? We in Oz preferred it over UUCP, because it was far superior, with self-routing etc. -- Dave From arnold at skeeve.com Sun Dec 2 05:53:16 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 01 Dec 2018 12:53:16 -0700 Subject: [TUHS] man-page style In-Reply-To: <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> Message-ID: <201812011953.wB1JrGQh029358@freefriends.org> WIlliam Cheswick wrote: > As for the configuration: when Norman Wilson moved to Toronto, he > implemented some form of little language for configuring sendmail, > treating it somewhat as an assembly language. Not from Norman (I'm pretty sure), there was a program called 'ease' that did just that. Using it, I wrote a sendmail config file *from scratch* for the computing center and math/cs system at Emory U, where I worked at the time. Because of that, the Morris worm totally passed us by. :-) I think that I have literally forgotten more about sendmail than most people ever know, and I'm totally OK with that. :-) Arnold From norman at oclsc.org Sun Dec 2 06:52:36 2018 From: norman at oclsc.org (Norman Wilson) Date: Sat, 01 Dec 2018 15:52:36 -0500 Subject: [TUHS] man-page style Message-ID: <1543697561.28059.for-standards-violators@oclsc.org> WIlliam Cheswick wrote: > As for the configuration: when Norman Wilson moved to Toronto, he > implemented some form of little language for configuring sendmail, > treating it somewhat as an assembly language. Bill's half right. I didn't invent a language; I used what was there. I decided that the best way to deal with Sendmail's own configuration language was to treat it as I would the assembly language for a specialized, irregularly-designed microprocessor: 1. Understand as well as possible what the instructions actually do; 2. Write the simplest possible program that will get the job done; 3. Avoid extra layers of macros and so on that hide the details, because that also hides the irregularities and makes it harder to understand and debug; 4. By the same reason, don't just copy someone else's program that does something complicated; write your own and do things simply. Sendmail has plenty of design flaws (not just in the language), as I'm sure Eric will acknowledge; but I think the biggest problem people have had with it that most people copied the rather-complicated sample configuration files shipped with the source rather than just reading the manual, doing a few experiments to understand the behaviour, and writing something simple. On the other hand, I've never quite understood why so many people treat device drivers as scary and untouchable, copying an existing one and hacking it until it seems to work rather than understanding what the device actually does and writing a simple program to control it. So perhaps my brain just doesn't work normally. Norman Wilson Toronto ON From gtaylor at tnetconsulting.net Sun Dec 2 07:26:34 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 1 Dec 2018 14:26:34 -0700 Subject: [TUHS] man-page style In-Reply-To: <201812011953.wB1JrGQh029358@freefriends.org> References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> <201812011953.wB1JrGQh029358@freefriends.org> Message-ID: On 12/1/18 12:53 PM, arnold at skeeve.com wrote: >> As for the configuration: when Norman Wilson moved to Toronto, he >> implemented some form of little language for configuring sendmail, >> treating it somewhat as an assembly language. > > Not from Norman (I'm pretty sure), there was a program called 'ease' > that did just that. Using it, I wrote a sendmail config file *from scratch* > for the computing center and math/cs system at Emory U, where I worked > at the time. Where can I find out more about 'ease' and what Normal wrote & used? I'm quite fond of m4, which I picked up from Sendmail < 20 years ago. > Because of that, the Morris worm totally passed us by. :-) :-) > I think that I have literally forgotten more about sendmail than most > people ever know, and I'm totally OK with that. :-) I do think that I've gotten a better understanding of email, and SMTP in general, than some of my coworkers thanks to Sendmail and my pursuit of making it work. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Sun Dec 2 07:34:43 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 1 Dec 2018 14:34:43 -0700 Subject: [TUHS] man-page style In-Reply-To: <1543697561.28059.for-standards-violators@oclsc.org> References: <1543697561.28059.for-standards-violators@oclsc.org> Message-ID: <2addfda0-76bf-a649-b2a3-ec6ad1c78418@spamtrap.tnetconsulting.net> On 12/1/18 1:52 PM, Norman Wilson wrote: > Bill's half right. I didn't invent a language; I used what was there. Can I ask what language you did use? Was it m4 or something else? > I decided that the best way to deal with Sendmail's own configuration > language was to treat it as I would the assembly language for a > specialized, irregularly-designed microprocessor: > > 1. Understand as well as possible what the instructions actually do; > 2. Write the simplest possible program that will get the job done; > 3. Avoid extra layers of macros and so on that hide the details, because > that also hides the irregularities and makes it harder to understand > and debug; > 4. By the same reason, don't just copy someone else's program that does > something complicated; write your own and do things simply. > > Sendmail has plenty of design flaws (not just in the language), as > I'm sure Eric will acknowledge; but I think the biggest problem people > have had with it that most people copied the rather-complicated sample > configuration files shipped with the source rather than just reading > the manual, doing a few experiments to understand the behaviour, and > writing something simple. I see the same lack of understanding in a lot of things. > On the other hand, I've never quite understood why so many people > treat device drivers as scary and untouchable, copying an existing one > and hacking it until it seems to work rather than understanding what > the device actually does and writing a simple program to control it. > So perhaps my brain just doesn't work normally. For me, I don't know where to get good documentation of what the device actually does and how to make it do it. I also don't have a good (read: any) understanding of the OS / kernels that I'd connect the device to. So, writing software to connect the device (I don't fully comprehend) to the OS / kernel (that I don't fully comprehend) in a language (that I'm not fluent in) is an uphill battle for me. I have great respect and gratitude for the people that do write device drivers. I don't create the Lego bricks. But I do try to build interesting and useful things out of the Lego bricks that others have built. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From norman at oclsc.org Sun Dec 2 09:09:39 2018 From: norman at oclsc.org (Norman Wilson) Date: Sat, 01 Dec 2018 18:09:39 -0500 Subject: [TUHS] man-page style Message-ID: <1543705783.3909.for-standards-violators@oclsc.org> I wrote (re my approach to sendmail.cf): > Bill's half right. I didn't invent a language; I used what was there. Grant Taylor asked: Can I ask what language you did use? Was it m4 or something else? ==== I think you missed my point. The language I used was plain old sendmail.cf. Norman Wilson Toronto ON From ches at cheswick.com Sun Dec 2 09:24:23 2018 From: ches at cheswick.com (WIlliam Cheswick) Date: Sat, 1 Dec 2018 18:24:23 -0500 Subject: [TUHS] man-page style In-Reply-To: References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> Message-ID: <8F45FE18-D6D8-47B0-B3D1-01EE8610F298@cheswick.com> We supported many nets, including ACSnet: uucp!research!ches bitnet!templevm!rdk csnet!! acsnet!! I didn’t remember the exact name of the net, but we delivered to it. > On Nov 30, 2018, at 5:58 PM, Dave Horsfall wrote: > > Err, why the query after ACSnet? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Sun Dec 2 12:37:20 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 1 Dec 2018 19:37:20 -0700 Subject: [TUHS] man-page style In-Reply-To: <1543705783.3909.for-standards-violators@oclsc.org> References: <1543705783.3909.for-standards-violators@oclsc.org> Message-ID: <77f99540-23ad-ade5-4568-bb9eae918341@spamtrap.tnetconsulting.net> On 12/1/18 4:09 PM, Norman Wilson wrote: > I think you missed my point. The language I used was plain old > sendmail.cf. Sorry, I mistook the context to be that you wrote something to write the cf file / language for you. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Sun Dec 2 12:44:07 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 1 Dec 2018 18:44:07 -0800 Subject: [TUHS] man-page style In-Reply-To: <77f99540-23ad-ade5-4568-bb9eae918341@spamtrap.tnetconsulting.net> References: <1543705783.3909.for-standards-violators@oclsc.org> <77f99540-23ad-ade5-4568-bb9eae918341@spamtrap.tnetconsulting.net> Message-ID: <20181202024407.GC15379@mcvoy.com> On Sat, Dec 01, 2018 at 07:37:20PM -0700, Grant Taylor via TUHS wrote: > On 12/1/18 4:09 PM, Norman Wilson wrote: > >I think you missed my point. The language I used was plain old > >sendmail.cf. > > Sorry, I mistook the context to be that you wrote something to write the cf > file / language for you. I'm kinda with Grant on this one. Maybe I misunderstood but what I thought you did was treat the sendmail.cf as assembler for a weird processor and then you wrote a higher level language that compiled down to sendmail.cf. Which, if that's that you did, is pretty studly. I think Grant was asking what you did the higher level language in, he was wondering if it was m4 (which I doubt, if I were doing that it would either be some nasty perl script that I thought was going to be small but wasn't, or I'd just go to lex/yacc/C). From gtaylor at tnetconsulting.net Sun Dec 2 12:59:08 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 1 Dec 2018 19:59:08 -0700 Subject: [TUHS] man-page style In-Reply-To: <20181202024407.GC15379@mcvoy.com> References: <1543705783.3909.for-standards-violators@oclsc.org> <77f99540-23ad-ade5-4568-bb9eae918341@spamtrap.tnetconsulting.net> <20181202024407.GC15379@mcvoy.com> Message-ID: On 12/1/18 7:44 PM, Larry McVoy wrote: > I'm kinda with Grant on this one. Maybe I misunderstood but what I > thought you did was treat the sendmail.cf as assembler for a weird > processor and then you wrote a higher level language that compiled > down to sendmail.cf. Which, if that's that you did, is pretty studly. > I think Grant was asking what you did the higher level language in, > he was wondering if it was m4 Yep, that's what I was my interpretation and my question. > (which I doubt, if I were doing that it would either be some nasty perl > script that I thought was going to be small but wasn't, or I'd just go > to lex/yacc/C). One of these days I should find out the genesis of the m4 (.mc) file syntax that is used to generate the .cf file. I'm curious why m4 was chosen over other languages. I wonder what the other language options were. I know that I learned m4 because of Sendmail's .mc file. I've since started using m4 for a number of other things. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From norman at oclsc.org Sun Dec 2 13:24:20 2018 From: norman at oclsc.org (Norman Wilson) Date: Sat, 1 Dec 2018 22:24:20 -0500 (EST) Subject: [TUHS] man-page style Message-ID: <20181202032420.0E7F54422F@lignose.oclsc.org> Grant: Sorry, I mistook the context to be that you wrote something to write the cf file / language for you. === Yep, evidently I didn't write clearly enough. Sorry about that. (Which links us nicely back to the Subject: line, and the concise clarity of the original manual-entry style!) Norman Wilson Toronto ON From arnold at skeeve.com Sun Dec 2 17:22:45 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 02 Dec 2018 00:22:45 -0700 Subject: [TUHS] Ease (was Re: man-page style) In-Reply-To: References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> <201812011953.wB1JrGQh029358@freefriends.org> Message-ID: <201812020722.wB27MleQ030692@freefriends.org> Grant Taylor via TUHS wrote: > > Not from Norman (I'm pretty sure), there was a program called 'ease' > > that did just that. Using it, I wrote a sendmail config file *from scratch* > > for the computing center and math/cs system at Emory U, where I worked > > at the time. > > Where can I find out more about 'ease' and what Norman wrote & used? Ease was posted in comp.sources. and I think there was ;login: article about it. We're talking mid-1980s here. I subsequently added a few features to it, mainly to support features in Sun's sendmail. It's mentioned in Eric's (I think) book about Sendmail from the late 80s or early 90s (and I have a footnote in there, I think). I will see if I can dig up the sources. It would undoubtedly take some work to bring them into the 21st century. Arnold From gtaylor at tnetconsulting.net Sun Dec 2 17:32:22 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 2 Dec 2018 00:32:22 -0700 Subject: [TUHS] Ease (was Re: man-page style) In-Reply-To: <201812020722.wB27MleQ030692@freefriends.org> References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> <201812011953.wB1JrGQh029358@freefriends.org> <201812020722.wB27MleQ030692@freefriends.org> Message-ID: On 12/2/18 12:22 AM, arnold at skeeve.com wrote: > Ease was posted in comp.sources. and I think there was ;login: > article about it. We're talking mid-1980s here. I subsequently added a > few features to it, mainly to support features in Sun's sendmail. > > It's mentioned in Eric's (I think) book about Sendmail from the late > 80s or early 90s (and I have a footnote in there, I think). > > I will see if I can dig up the sources. It would undoubtedly take some > work to bring them into the 21st century. Thank you for the information. I'll see if I can't find at something in the Usenet archives. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From arnold at skeeve.com Mon Dec 3 03:22:27 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 02 Dec 2018 10:22:27 -0700 Subject: [TUHS] Ease (was Re: man-page style) In-Reply-To: References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com> <201812011953.wB1JrGQh029358@freefriends.org> <201812020722.wB27MleQ030692@freefriends.org> Message-ID: <201812021722.wB2HMRTv024365@freefriends.org> Grant Taylor via TUHS wrote: > On 12/2/18 12:22 AM, arnold at skeeve.com wrote: > > Ease was posted in comp.sources. and I think there was ;login: > > article about it. We're talking mid-1980s here. I subsequently added a > > few features to it, mainly to support features in Sun's sendmail. > > > > It's mentioned in Eric's (I think) book about Sendmail from the late > > 80s or early 90s (and I have a footnote in there, I think). > > > > I will see if I can dig up the sources. It would undoubtedly take some > > work to bring them into the 21st century. > > Thank you for the information. > > I'll see if I can't find at something in the Usenet archives. I just now sent the code in direct email. Arnold From dave at horsfall.org Mon Dec 3 08:17:30 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 3 Dec 2018 09:17:30 +1100 (EST) Subject: [TUHS] Happy birthday, John Backus! Message-ID: As every computer programmer should know, John Backus was emitted in 1924; he gave us the BNF syntax (he is the "B"), but he also gave us that FORTRAN obscenity... Yeah, it was a nice language at the time; the engineers loved it, but tthe computer scientists hated it (have you ever tried to debug a FORTRAN program that somebody else wrote?). Trivia: there is no way that FORTRAN can be described in any syntax; it is completely ad-hoc. -- Dave From dave at horsfall.org Mon Dec 3 08:30:06 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 3 Dec 2018 09:30:06 +1100 (EST) Subject: [TUHS] man-page style In-Reply-To: <1543705783.3909.for-standards-violators@oclsc.org> References: <1543705783.3909.for-standards-violators@oclsc.org> Message-ID: On Sat, 1 Dec 2018, Norman Wilson wrote: > I think you missed my point. The language I used was plain old > sendmail.cf. And anyone who has not edited sendmail.cf (shudder!) is not a programmer. -- Dave From toby at telegraphics.com.au Mon Dec 3 08:34:06 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Sun, 2 Dec 2018 17:34:06 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: Message-ID: <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au> On 2018-12-02 5:17 PM, Dave Horsfall wrote: > As every computer programmer should know, John Backus was emitted in > 1924; he gave us the BNF syntax (he is the "B"), but he also gave us > that FORTRAN obscenity...  Yeah, it was a nice language at the time; the > engineers loved it, but tthe computer scientists hated it (have you ever > tried to debug a FORTRAN program that somebody else wrote?). He made amends by being early to recognise that problem, and propose solutions, in his 1977 ACM Turing Award lecture (still perfectly relevant today): https://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf --Toby > > Trivia: there is no way that FORTRAN can be described in any syntax; it > is completely ad-hoc. > > -- Dave > From imp at bsdimp.com Mon Dec 3 11:05:19 2018 From: imp at bsdimp.com (Warner Losh) Date: Sun, 2 Dec 2018 18:05:19 -0700 Subject: [TUHS] man-page style In-Reply-To: References: <1543705783.3909.for-standards-violators@oclsc.org> Message-ID: On Sun, Dec 2, 2018 at 3:31 PM Dave Horsfall wrote: > On Sat, 1 Dec 2018, Norman Wilson wrote: > > > I think you missed my point. The language I used was plain old > > sendmail.cf. > > And anyone who has not edited sendmail.cf (shudder!) is not a programmer. > Blind, write-only programming at its finest. Trial and error until you think there's no more error. Think. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at bitblocks.com Mon Dec 3 11:14:07 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Sun, 02 Dec 2018 17:14:07 -0800 Subject: [TUHS] man-page style In-Reply-To: Your message of "Mon, 03 Dec 2018 09:30:06 +1100." References: <1543705783.3909.for-standards-violators@oclsc.org> Message-ID: <20181203011414.DAE3D156E410@mail.bitblocks.com> On Mon, 03 Dec 2018 09:30:06 +1100 Dave Horsfall wrote: Dave Horsfall writes: > On Sat, 1 Dec 2018, Norman Wilson wrote: > > > I think you missed my point. The language I used was plain old > > sendmail.cf. > > And anyone who has not edited sendmail.cf (shudder!) is not a programmer. :-) In 1985 for a client I had to check if Sendmail's implementation of SMTP met FIPS standard or some such (don't ask -- I don't recall most of the details now). I got pretty familiar with it. But ever since then I have not wanted to use it. I switched to PostFix a long time ago but that too has become rather complicated. From lm at mcvoy.com Mon Dec 3 11:30:25 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 2 Dec 2018 17:30:25 -0800 Subject: [TUHS] man-page style In-Reply-To: <20181203011414.DAE3D156E410@mail.bitblocks.com> References: <1543705783.3909.for-standards-violators@oclsc.org> <20181203011414.DAE3D156E410@mail.bitblocks.com> Message-ID: <20181203013025.GB10043@mcvoy.com> On Sun, Dec 02, 2018 at 05:14:07PM -0800, Bakul Shah wrote: > On Mon, 03 Dec 2018 09:30:06 +1100 Dave Horsfall wrote: > Dave Horsfall writes: > > On Sat, 1 Dec 2018, Norman Wilson wrote: > > > > > I think you missed my point. The language I used was plain old > > > sendmail.cf. > > > > And anyone who has not edited sendmail.cf (shudder!) is not a programmer. As a systems guy I think if you have not written, or understood, swtch(), you are not a systems guy. But I don't think we should judge each other, we should admire those amongst us who have taken the time to understand something deeply. Doesn't really matter if it is the kernel (though that's where I like it) or sendmail.cf (I gotta give credit to those that get that), it is all about deep understanding. If you did that much work and got it, welcome to the club. It's kind of a shitty club because nobody gets what you do so nobody values it, but some of us do. From robpike at gmail.com Mon Dec 3 11:32:32 2018 From: robpike at gmail.com (Rob Pike) Date: Mon, 3 Dec 2018 12:32:32 +1100 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au> References: <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au> Message-ID: Fortran was a marvel. Don't judge it by today's ideas about language design. -rob On Mon, Dec 3, 2018 at 9:34 AM Toby Thain wrote: > On 2018-12-02 5:17 PM, Dave Horsfall wrote: > > As every computer programmer should know, John Backus was emitted in > > 1924; he gave us the BNF syntax (he is the "B"), but he also gave us > > that FORTRAN obscenity... Yeah, it was a nice language at the time; the > > engineers loved it, but tthe computer scientists hated it (have you ever > > tried to debug a FORTRAN program that somebody else wrote?). > > He made amends by being early to recognise that problem, and propose > solutions, in his 1977 ACM Turing Award lecture (still perfectly > relevant today): > > https://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf > > --Toby > > > > > > > Trivia: there is no way that FORTRAN can be described in any syntax; it > > is completely ad-hoc. > > > > -- Dave > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Mon Dec 3 13:36:59 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 02 Dec 2018 22:36:59 -0500 Subject: [TUHS] > there is no way that FORTRAN can be described in any syntax Message-ID: <201812030336.wB33axfq080387@tahoe.cs.Dartmouth.EDU> I did just that. The National Bureau of Standards picked it up in NBS Handbook 131, "Using ANS FORTRAN" (1980). It is expressed in the same formalism that Burroughs used for Algol. Doug From toby at telegraphics.com.au Mon Dec 3 14:11:51 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Sun, 2 Dec 2018 23:11:51 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au> Message-ID: On 2018-12-02 8:32 PM, Rob Pike wrote: > Fortran was a marvel. Don't judge it by today's ideas about language design. The 1977 lecture was by John Backus, not me, so I'm confused who that's directed at. > > -rob > > > On Mon, Dec 3, 2018 at 9:34 AM Toby Thain > wrote: > > On 2018-12-02 5:17 PM, Dave Horsfall wrote: > > As every computer programmer should know, John Backus was emitted in > > 1924; he gave us the BNF syntax (he is the "B"), but he also gave us > > that FORTRAN obscenity...  Yeah, it was a nice language at the > time; the > > engineers loved it, but tthe computer scientists hated it (have > you ever > > tried to debug a FORTRAN program that somebody else wrote?). > > He made amends by being early to recognise that problem, and propose > solutions, in his 1977 ACM Turing Award lecture (still perfectly > relevant today): > > https://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf > > --Toby > > > > > > > Trivia: there is no way that FORTRAN can be described in any > syntax; it > > is completely ad-hoc. > > > > -- Dave > > > From robpike at gmail.com Mon Dec 3 14:27:20 2018 From: robpike at gmail.com (Rob Pike) Date: Mon, 3 Dec 2018 15:27:20 +1100 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au> Message-ID: To the author of the first message, the one who called Fortran an "obscenity". -rob On Mon, Dec 3, 2018 at 3:11 PM Toby Thain wrote: > On 2018-12-02 8:32 PM, Rob Pike wrote: > > Fortran was a marvel. Don't judge it by today's ideas about language > design. > > The 1977 lecture was by John Backus, not me, so I'm confused who that's > directed at. > > > > > -rob > > > > > > On Mon, Dec 3, 2018 at 9:34 AM Toby Thain > > wrote: > > > > On 2018-12-02 5:17 PM, Dave Horsfall wrote: > > > As every computer programmer should know, John Backus was emitted > in > > > 1924; he gave us the BNF syntax (he is the "B"), but he also gave > us > > > that FORTRAN obscenity... Yeah, it was a nice language at the > > time; the > > > engineers loved it, but tthe computer scientists hated it (have > > you ever > > > tried to debug a FORTRAN program that somebody else wrote?). > > > > He made amends by being early to recognise that problem, and propose > > solutions, in his 1977 ACM Turing Award lecture (still perfectly > > relevant today): > > > > > https://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf > > > > --Toby > > > > > > > > > > > > Trivia: there is no way that FORTRAN can be described in any > > syntax; it > > > is completely ad-hoc. > > > > > > -- Dave > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rly1 at embarqmail.com Mon Dec 3 15:31:47 2018 From: rly1 at embarqmail.com (Ron Young) Date: Sun, 02 Dec 2018 21:31:47 -0800 Subject: [TUHS] > there is no way that FORTRAN can be described in any syntax In-Reply-To: <201812030336.wB33axfq080387@tahoe.cs.Dartmouth.EDU> References: <201812030336.wB33axfq080387@tahoe.cs.Dartmouth.EDU> Message-ID: <7E.F0.08702.4CFB40C5@smtp04.onyx.dfw.sync.lan> Your message dated: Sun, 02 Dec 2018 22:36:59 -0500 -------- > > I did just that. The National Bureau of Standards picked it up > in NBS Handbook 131, "Using ANS FORTRAN" (1980). It is expressed > in the same formalism that Burroughs used for Algol. > > Doug a couple of more data points: Arthur Sale wrote an article on classifying fortran statements, Volume 14 Number 1 of the Computer Journal that describes how to classify fortran statements into 1 of 36 types. URL:https://www.researchgate.net/profile/Arthur_Sale/publication/220459829_The_classification_of_FORTRAN_statements/links/02e7e5181a234c6545000000/The-classification-of-FORTRAN-statements.pdf). by using the above, you can do some preprocessing to correct spacing, line continuations, remove sequence numbers (cols 73-80) and other formatting to make parsing easier. John Levine wrote a ftn77 subset parser using lex and yacc (the shar file that I have is dated Nov 1988). -ron =============================================================================== Ron Young rly1 at embarqmail.com From arnold at skeeve.com Mon Dec 3 16:53:37 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 02 Dec 2018 23:53:37 -0700 Subject: [TUHS] man-page style In-Reply-To: References: <1543705783.3909.for-standards-violators@oclsc.org> Message-ID: <201812030653.wB36rbeq026790@freefriends.org> Dave Horsfall wrote: > On Sat, 1 Dec 2018, Norman Wilson wrote: > > > I think you missed my point. The language I used was plain old > > sendmail.cf. > > And anyone who has not edited sendmail.cf (shudder!) is not a programmer. > > -- Dave Now you're just starting a pissing contest. From arnold at skeeve.com Mon Dec 3 16:52:23 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 02 Dec 2018 23:52:23 -0700 Subject: [TUHS] man-page style In-Reply-To: <2155b676-a250-926c-1236-1e413cb2019f@neophilic.com> References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com> <201811290725.wAT7PuE1019145@freefriends.org> <2155b676-a250-926c-1236-1e413cb2019f@neophilic.com> Message-ID: <201812030652.wB36qNWM026757@freefriends.org> Eric Allman wrote: > > On 2018-11-28 23:25 , arnold at skeeve.com wrote: > > > Any chance you, or someone else, could write that missing manual that > > explains the "why" of the various troff features? > > > > I've been through CSTR 54 a few times too, although I haven't tried > > to write a macro package from scratch, and I have to admit that there > > are things that mystify me. > > At this point it's been so many years since I was actively working on > troff that it would require more-or-less starting from zero. Perhaps > when I retire I'll have that kind of time. OK, we'll hold you to it. :-) Thanks, Arnold From jpl.jpl at gmail.com Mon Dec 3 23:10:51 2018 From: jpl.jpl at gmail.com (John P. Linderman) Date: Mon, 3 Dec 2018 08:10:51 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au> Message-ID: If you understood the architecture and instruction set of the IBM 709/7090/7094 series (I cut my programming teeth on the 7094), you understood the "quirks" of Fortan: three way branches, indexing arrays in reverse order, always executing a loop at least once, etc. Fortran "tricked" the writer into producing code that worked well on those machines, but was much easier to understand and modify than assembler. Not all that different from C and DEC boxes, but the IBM machines were less coherent. On Sun, Dec 2, 2018 at 11:29 PM Rob Pike wrote: > To the author of the first message, the one who called Fortran an > "obscenity". > > -rob > > > On Mon, Dec 3, 2018 at 3:11 PM Toby Thain > wrote: > >> On 2018-12-02 8:32 PM, Rob Pike wrote: >> > Fortran was a marvel. Don't judge it by today's ideas about language >> design. >> >> The 1977 lecture was by John Backus, not me, so I'm confused who that's >> directed at. >> >> > >> > -rob >> > >> > >> > On Mon, Dec 3, 2018 at 9:34 AM Toby Thain > > > wrote: >> > >> > On 2018-12-02 5:17 PM, Dave Horsfall wrote: >> > > As every computer programmer should know, John Backus was emitted >> in >> > > 1924; he gave us the BNF syntax (he is the "B"), but he also gave >> us >> > > that FORTRAN obscenity... Yeah, it was a nice language at the >> > time; the >> > > engineers loved it, but tthe computer scientists hated it (have >> > you ever >> > > tried to debug a FORTRAN program that somebody else wrote?). >> > >> > He made amends by being early to recognise that problem, and propose >> > solutions, in his 1977 ACM Turing Award lecture (still perfectly >> > relevant today): >> > >> > >> https://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf >> > >> > --Toby >> > >> > >> > >> > > >> > > Trivia: there is no way that FORTRAN can be described in any >> > syntax; it >> > > is completely ad-hoc. >> > > >> > > -- Dave >> > > >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Dec 4 02:25:23 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 3 Dec 2018 11:25:23 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: Message-ID: On Sun, Dec 2, 2018 at 5:18 PM Dave Horsfall wrote: > Yeah, it was a nice language at the time; the engineers loved it, Dave at this risk of piling-on, I feel like to I need to comment because while I personally to not use it, my customers do. It's still an excellent tool, and the reality is that Fortran has pretty much paid my salary for almost every computer firm I have worked since I left grad school. That's 5 start-ups and too many large firms to count. Fortran2018 (which was release just last week BTW) is hardly the language I learned in the early 1970s (Fortran-IV) or my father a dozen or so years previous to me. Knocking modern Fortran is sort of like saying, "Any vehicle that is made by Ford sucks because the Model T was not as good as what we can do today." I fear your are making statements about Fortran-2 - maybe 77 or even 90. But the language is niether dead nor useless. Check out an answer I did for quora last summer: Clem Cole's answer to Is the future of Fortran Programming Dead I also point out, if you watch the nightly news on TV, you are using Fortran. Pretty much, all the weather data internationally is crunched on Fortran codes. The same is true for most 'large science.' As for why we will still use it is that *the work (the math) has not changed (If it ain’t broke, don’t fix it). And most importantly, history has shown that it has never been economically interesting to bother (or at least so far).* Please read my Quora answers to see a much more detailed analysis of that statement. > but tthe computer scientists hated it I get it. But ... at least we were taught it. I'm saddened to say my fairly recent CS major daughter was never shown it in her days in college. In a funny twist of fate, her grandfather (my Dad) was taught Fortran in 1958 at a course at her college (Carleton) via an NSF grant. As I have said elsewhere, in the 70's the CMU CS Dept, was arguing with the Engineering school. In those days, the CS Dept said, "Fortran was dead." But like the Phoenix, it is seems to get be getting more beautiful and stronger with each reincarnation. > (have you ever tried to debug a FORTRAN program that somebody else wrote?). Hrrumft. You can write bad code is *any* language. See the annual obscure C prize. FWIW: This little gem is legal Fortran-IV. The last time I compiled it on my Mac, a Fortran2013 draft comforming compiler, Intel Fortran's ifort, will accept thios deck also with no special switches BTW. That said, the last time I checked it on my Mac, ifort generated incorrect code (it was reported as a bug, I'm not sure of the status of the fix and I have not updated the compiler since last summer): C This FORTRAN program may be compiled and run on a Norsk Data C computer running SINTRAN and the FTN compiler. It uses only C FORTRAN reserved words, and contains just one numerical C constant, in a character string (a format specifier). When C you run it, it prints a well known mathematical construct... C C Even FORTRAN is a block structured programming language: C PROGRAM ;PROGRAM;INTEGERIF,INTEGER,GOTO,IMPLICIT;REALREAL,DIMENSION,EXTERNA AL,FORMAT,END;INTEGERLOGICAL;REALCOMPLEX,DATA,CALL,ASSIGN,CHARACTER R;DOFORIF=INTEGER,INTEGER;ENDDO;INTEGER=IF+IF;GOTO=INTEGER*INTEGER* *INTEGER*INTEGER-INTEGER-IF;CALLFUNCTION(IMPLICIT,REAL,DIMENSION,EX XTERNAL,FORMAT,END,LOGICAL,COMPLEX,DATA,CALL,ASSIGN,CHARACTER);CALL LSUBROUTINE(IMPLICIT,LOGICAL,GOTO,IF,INTEGER);END;SUBROUTINEFUNCTIO ON(IMPLICIT,REAL,DIMENSION,EXTERNAL,FORMAT,END,LOGICAL,COMPLEX,DATA A,CALL,ASSIGN,CHARACTER);RETURN;END;SUBROUTINESUBROUTINE(IMPLICIT,L LOGICAL,GOTO,IF,INTEGER);INTEGERGOTO,IMPLICIT(GOTO),LOGICAL(GOTO),I IF,INTEGER,EXTERNAL,RETURN;DOFOREXTERNAL=IF,GOTO;DOFORRETURN=INTEGE ER,EXTERNAL-IF;IMPLICIT(RETURN)=LOGICAL(RETURN)+LOGICAL(RETURN-IF); ;ENDDO;IMPLICIT(IF)=IF;IMPLICIT(EXTERNAL)=IF;DOFORRETURN=IF,GOTO-EX XTERNAL;WRITE(IF,'(''$ '')');ENDDO;DOFORRETURN=IF,EXTERNAL;WRITE(I IF,'(''$''I4)')IMPLICIT(RETURN);ENDDO;WRITE(IF,'( /)');DOFORRETURN= =IF,GOTO;LOGICAL(RETURN)=IMPLICIT(RETURN);ENDDO;ENDDO;END The output should be something like this: 1 1 1 1 2 1 1 3 3 1 1 4 6 4 1 1 5 10 10 5 1 1 6 15 20 15 6 1 1 7 21 35 35 21 7 1 1 8 28 56 70 56 28 8 1 1 9 36 84 126 126 84 36 9 1 1 10 45 120 210 252 210 120 45 10 1 1 11 55 165 330 462 462 330 165 55 11 1 1 12 66 220 495 792 924 792 495 220 66 12 1 I admit, I'm glad I'm not a compiler writer. But they do have an amazing product that is very useful to a lot of people and still quite popular. BTW: Here is the same program, in a bit more readable form: PROGRAM BLOCK INTEGER I1,I2,I3,I4,I5 DIMENSION I1(13),I2(13) I4=1 I5=2 I3=13 CALL PASCAL(I1,I2,I3,I4,I5) END SUBROUTINE PASCAL(IP1,IP2,IP3,IP4,IP5) INTEGER IP3,IP1(IP3),IP2(IP3),IP4,IP5 INTEGER IP6,IP7 DO IP6=IP4,IP3 DO IP7=IP5,IP6-IP4 IP1(IP7)=IP2(IP7)+IP2(IP7-IP4) ENDDO IP1(IP4)=IP4 IP1(IP6)=IP4 DO IP7=IP4,IP3-IP6 WRITE(*,'(" "$)') ENDDO DO IP7=IP4,IP6 WRITE(*,'(I4$)') IP1(IP7) ENDDO WRITE(*,*) DO IP7=IP4,IP3 IP2(IP7)=IP1(IP7) ENDDO ENDDO END ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Tue Dec 4 02:30:48 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 03 Dec 2018 11:30:48 -0500 Subject: [TUHS] The (un)importance of roff Message-ID: <201812031630.wB3GUmIj022190@tahoe.cs.Dartmouth.EDU> Thhis is a cross-posting from the groff mailing list, where it was speculated that without roff there might be no Unix. Old hands will be familiar with the story. > Without roff, Unix might well have disappeared. The patent department and the AT&T president's office are the only in-house examples I know where Unix was adopted because of *roff. The important adoptions, which led Berk Tague to found a separate Unix Support Group, were mainstream telephone applications and PWB, a Unix-based IDE. The first telephone application happened in the field. An engineer in Charlotte, NC, heard of this cheap easily programmed system and proposed to use it to automate the scheduling and dispatch of maintenance on the floor of a wire center. Ken visited to help get them started. The first Bell Labs telephone application was automating the analysis of central-office trouble reports. These had been voluminous stacks of punched cards that reported every anomaly detected in huge electromechanical switches. The Unix application captured the data on line and identfied systematic failures in real time. The patent adoption was a direct result of Joe Ossanna's salesmaship. Other early adopters were self-motivated, but the generous support lent by Ken, Joe, and others was certainly a tipping force that helped turn isolated events into a self-sustaining movement. Doug From clemc at ccc.com Tue Dec 4 02:42:20 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 3 Dec 2018 11:42:20 -0500 Subject: [TUHS] The (un)importance of roff In-Reply-To: <201812031630.wB3GUmIj022190@tahoe.cs.Dartmouth.EDU> References: <201812031630.wB3GUmIj022190@tahoe.cs.Dartmouth.EDU> Message-ID: On Mon, Dec 3, 2018 at 11:31 AM Doug McIlroy wrote: > it was speculated that without roff there might be no Unix. > Old hands will be familiar with the story. > Doug - thank you for retelling the story. As you say, older hand knew it. FWIW: It's one of my examples of when I try to explain my observation UNIX became self-sustaining because "Simple Economics always beats Sophisticated Design" The key point is that UNIX obtained >>users<< (customers) because it inexpensively did what people needed to do when they had not other way ->> "simple economics." But it had to be based on solid foundations. Just being "cheap" is not good enough. It has be "useful." UNIX found 'users' that needed what it brought them. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Dec 4 06:10:32 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 3 Dec 2018 15:10:32 -0500 Subject: [TUHS] > there is no way that FORTRAN can be described in any syntax In-Reply-To: <7E.F0.08702.4CFB40C5@smtp04.onyx.dfw.sync.lan> References: <201812030336.wB33axfq080387@tahoe.cs.Dartmouth.EDU> <7E.F0.08702.4CFB40C5@smtp04.onyx.dfw.sync.lan> Message-ID: On 12/3/18, Ron Young wrote: > > John Levine wrote a ftn77 subset parser using lex and yacc (the shar > file that I have is dated Nov 1988). > Just curious--what parts of Fortran 77 did he leave out? Unfortunately the Fortran language was being developed at the same time that Chomsky was first doing his research on formal grammars. Languages such as Algol, C, PL/I, and Pascal were designed to be easily split into a lexical regular grammar and a context-free grammar (the lex/yacc paradigm). Fortran has some nasty grammatical quirks that make it a bear to parse--context-sensitive lexical analysis, for example. Given the string: DO10I=1,10 you don't know whether to lex it as: DO10I = 1 or: DO 10 I = 1 until you see the comma. Yes, full Fortran can be expressed in BNF and other formal syntax mechanisms. But I don't think you can use lex and yacc to generate a compiler for it. -Paul W. From paul.winalski at gmail.com Tue Dec 4 06:20:59 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 3 Dec 2018 15:20:59 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: Message-ID: I replied in detail to the child thread on it being impossible to devise a formal grammar for Fortran before I saw this one (its parent). Of course one can write a grammar for Fortran using a formal system such as BNF. It's just not going to be a well-behaved context-free grammar such as one can do for C or Pascal, and you won't be able to feed the grammar to lex and yacc, press a button, and have a compiler pop out. Fortran was being devised at the same time that Chomsky, et. al. were doing the research on formal languages. Essentially, Fortran syntax was devised before computer scientists knew better. I suspect COBOL has similar issues. -Paul W. From clemc at ccc.com Tue Dec 4 06:37:04 2018 From: clemc at ccc.com (Clem Cole) Date: Mon, 3 Dec 2018 15:37:04 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: Message-ID: On Mon, Dec 3, 2018 at 3:21 PM Paul Winalski wrote: > Fortran was being devised at the same time that Chomsky, et. > al. were doing the research on formal languages. Essentially, Fortran > syntax was devised before computer scientists knew better. I suspect > COBOL has similar issues. > I agree. I think you nailed about "not knowing any better.' And it really is amazing how well it has endured. Like a lot of things, the first guys do make errors because they really have not yet eccounter the longer term issues - they are just trying to solve the problem they had in front of them. On another fron, just think the issues in networking that were made in the 70s. Same thing. But IP/TCP works and works really well and has endured. You folks in the compiler team and in particular the Fortran crew, did a great job over the years. I used to kid your boss asking of there were Fortran developers than customers in our DEC days; but all kidding aside. And he knew I knew. I have always respected those folks. As I said, they paid my salary for so many years. I think it's sad we don't teach Fortran to 'modern' programmers in a comparitive languages class. The students should know what is good, why it has lasted and marvel at what a wonder system people devised in the late 1950s and how well Computer Scientists have over the next 60 years kept it strong and relevant. Then you can teach them, Rust, Go or whatever the cool kids think are hot and important. Ask them all, why do we think this languages will or will not last (and the end, it will be economics but that's another thread). Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rly1 at embarqmail.com Tue Dec 4 06:55:23 2018 From: rly1 at embarqmail.com (Ron Young) Date: Mon, 03 Dec 2018 12:55:23 -0800 Subject: [TUHS] > there is no way that FORTRAN can be described in any syntax In-Reply-To: References: <201812030336.wB33axfq080387@tahoe.cs.Dartmouth.EDU> <7E.F0.08702.4CFB40C5@smtp04.onyx.dfw.sync.lan> Message-ID: Your message dated: Mon, 03 Dec 2018 15:10:32 -0500 -------- > On 12/3/18, Ron Young wrote: > > > > John Levine wrote a ftn77 subset parser using lex and yacc (the shar > > file that I have is dated Nov 1988). > > > Just curious--what parts of Fortran 77 did he leave out? > not sure... I'll check when I get home. > > Yes, full Fortran can be expressed in BNF and other formal syntax > mechanisms. But I don't think you can use lex and yacc to generate a > compiler for it. > agreed... but if you use Sale's classifier, you can insert whitespace to convert the input to something that lex/yacc can handle. Although in practice, using a hand-written lexer or a state machine (like open-watcom IIRC) would probably be the way to go. -ron > -Paul W. =============================================================================== Ron Young rly1 at embarqmail.com From hellwig.geisse at mni.thm.de Tue Dec 4 06:46:27 2018 From: hellwig.geisse at mni.thm.de (Hellwig Geisse) Date: Mon, 03 Dec 2018 21:46:27 +0100 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: Message-ID: <1543869987.2133.4.camel@mni.thm.de> On Mo, 2018-12-03 at 15:20 -0500, Paul Winalski wrote: > Of course one can write a grammar for Fortran using a formal system > such as BNF.  It's just not going to be a well-behaved context-free > grammar such as one can do for C or Pascal, and you won't be able to > feed the grammar to lex and yacc, press a button, and have a compiler > pop out. This in fact also isn't possible for C because of the "typedef problem". See for example here: http://eli.thegreenplace.net/2007/11/24/the-context-sensitivity-of-cs-grammar Hellwig From paul.winalski at gmail.com Tue Dec 4 08:24:40 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 3 Dec 2018 17:24:40 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: Message-ID: On 12/3/18, Clem Cole wrote: > > Hrrumft. You can write bad code is *any* language. See the annual > obscure C prize. Someone once said that a good Fortran programmer can write Fortran in any programming language. -Paul W. From ron at ronnatalie.com Tue Dec 4 08:44:19 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Mon, 3 Dec 2018 17:44:19 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au> Message-ID: <034001d48b59$bb078750$311695f0$@ronnatalie.com> You also had a unique insight into LISP (what CAR and CDR really mean). If you understood the architecture and instruction set of the IBM 709/7090/7094 series (I cut my programming teeth on the 7094), you understood the "quirks" of Fortan -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Tue Dec 4 09:00:38 2018 From: stewart at serissa.com (Lawrence Stewart) Date: Mon, 3 Dec 2018 18:00:38 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: Message-ID: I’ve told this story before, but not here, I think. Brian Reid talked me into teaching a programming language survey course at Stanford around 1983. There were programming assignments in Pascal, LISP, APL, and Snobol. Being young and too clever, I rewrote the Snobol assignment to be matching lists of crossword puzzle solution words for across and down into a grid representing the board (X’s and O’s). I seriously underestimated how hard this would be for new programmers, so my own solution turned out to be the second fastest. The fastest Snobol solution was a thing that if you held it out at arms length, you would swear it was FORTRAN. -L > On 2018, Dec 3, at 5:24 PM, Paul Winalski wrote: > > On 12/3/18, Clem Cole wrote: >> >> Hrrumft. You can write bad code is *any* language. See the annual >> obscure C prize. > > Someone once said that a good Fortran programmer can write Fortran in > any programming language. > > -Paul W. From dave at horsfall.org Tue Dec 4 17:48:56 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 4 Dec 2018 18:48:56 +1100 (EST) Subject: [TUHS] man-page style In-Reply-To: References: <1543705783.3909.for-standards-violators@oclsc.org> Message-ID: On Sun, 2 Dec 2018, Warner Losh wrote: > And anyone who has not edited sendmail.cf (shudder!) is not a > programmer. > > Blind, write-only programming at its finest. Trial and error until you > think there's no more error. Think. I can only say one thing: APL\360... Now, *there* was a write-only language. Oh, the stories that I could tell. -- Dave From dot at dotat.at Tue Dec 4 21:53:14 2018 From: dot at dotat.at (Tony Finch) Date: Tue, 4 Dec 2018 11:53:14 +0000 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: Message-ID: Clem Cole wrote: > Fortran2018 (which was release just last week BTW) is hardly the language I > learned in the early 1970s (Fortran-IV) or my father a dozen or so years > previous to me. One of the more obscure books I have is about "the F programming language" http://www.fortran.com/F/ which is the modern subset of Fortran 95. A curious thing about F is that it doesn't include DO WHILE; my understanding is that there was a faction of the Fortran standardization committee which was firmly against WHILE, and that was the faction that defined the F subset. I can't now find any information about this argument / controversy, but my link archive includes https://dl.acm.org/citation.cfm?doid=800168.811545 Brenda Baker's paper on converting Fortran IV programs to ratfor. Tony. -- f.anthony.n.finch http://dotat.at/ Irish Sea: Southwest 5, backing east, then becoming cyclonic later, 5 to 7, perhaps gale 8 later. Slight or moderate, occasionally rough later. Rain or showers. Good, occasionally poor. From clemc at ccc.com Wed Dec 5 00:23:20 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 4 Dec 2018 09:23:20 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: Message-ID: As I said, I'm an OS type, I just sit near a number of compiler folks and have been known to eat lunch with them - so I'm not aware of any that. Unfortunately, about a month ago we lost the guy to ask about it (the late Stan Whitlock), who was secretary of the Fortran standards committee for about 30 years. I'll try to ask Eklund and Grove (who are both retired but I still see socially on occasion) what they remember about F and if I learn anything I'll pass it back here. Clem ᐧ On Tue, Dec 4, 2018 at 6:53 AM Tony Finch wrote: > Clem Cole wrote: > > > Fortran2018 (which was release just last week BTW) is hardly the > language I > > learned in the early 1970s (Fortran-IV) or my father a dozen or so years > > previous to me. > > One of the more obscure books I have is about "the F programming language" > http://www.fortran.com/F/ which is the modern subset of Fortran 95. A > curious thing about F is that it doesn't include DO WHILE; my > understanding is that there was a faction of the Fortran standardization > committee which was firmly against WHILE, and that was the faction that > defined the F subset. > > I can't now find any information about this argument / controversy, but my > link archive includes https://dl.acm.org/citation.cfm?doid=800168.811545 > Brenda Baker's paper on converting Fortran IV programs to ratfor. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Irish Sea: Southwest 5, backing east, then becoming cyclonic later, 5 to 7, > perhaps gale 8 later. Slight or moderate, occasionally rough later. Rain or > showers. Good, occasionally poor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Dec 5 00:43:06 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 4 Dec 2018 09:43:06 -0500 (EST) Subject: [TUHS] Happy birthday, John Backus! Message-ID: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> > From: Toby Thain > He made amends by being early to recognise that problem, and propose > solutions, in his 1977 ACM Turing Award lecture Actually, I'd consider a far bigger amend to be his work on Algol 60 (he was one of the main contributors), which Hoare so memorably described as "a language so far ahead of its time that it was not only an improvement on its predecessors but also on nearly all its successors". AFAICT, although Algol 60 itself is no longer used, basically _every_ modern programming language (other than wierd, parallel ones, etc) is heavily descended from Algol 60 (e.g. C, via CPL). As for FORTRAN, it's worth recalling that it was originally for the IBM 704, which was their very _first_ commercial computer with core memory! And not a lot of it - early 704's came with a massive 4KW of main memory! So the compiler had to be squeezed into _very_ small space - and it reportedly did an excellent job of emitting efficient code (at a time when a lot of people thought that couldn't be done, and so were hostile to the concept of writing program in HLL). And the compiler had to be written entirely in assembler, to boot... Which brings up an interesting query - I wonder when/what the last compiler written in assembler was? I gather these days compilers for new machines are always bootstrapped as cross-compilers (an X compiler for the Y machine is written in X, run through the X compiler for the [existing] Z machine, and then run though itself, on the Z machine, to produce binary of itself for the Y machine). Noel From clemc at ccc.com Wed Dec 5 00:53:29 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 4 Dec 2018 09:53:29 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> Message-ID: On Tue, Dec 4, 2018 at 9:43 AM Noel Chiappa wrote: > Which brings up an interesting query - I wonder when/what the last > compiler written in assembler was? > Excellent question -- IBM's Fortran-H maybe? circa mid 1970's would be my guess. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at telegraphics.com.au Wed Dec 5 01:08:56 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Tue, 4 Dec 2018 10:08:56 -0500 Subject: [TUHS] APL - was Re: man-page style In-Reply-To: References: <1543705783.3909.for-standards-violators@oclsc.org> Message-ID: <97743c31-e625-39b1-902e-2e531e90ec6f@telegraphics.com.au> On 2018-12-04 2:48 AM, Dave Horsfall wrote: > On Sun, 2 Dec 2018, Warner Losh wrote: > >>       And anyone who has not edited sendmail.cf (shudder!) is not a >>       programmer. >> >> Blind, write-only programming at its finest. Trial and error until you >> think there's no more error. Think. > > I can only say one thing: APL\360...  Now, *there* was a write-only > language. For a more positive take on APL -- only for the open-minded -- try watching: https://www.youtube.com/watch?v=9xCJ3BCIudI > > Oh, the stories that I could tell. > > -- Dave > > > > > > > > > > > From toby at telegraphics.com.au Wed Dec 5 01:18:48 2018 From: toby at telegraphics.com.au (Toby Thain) Date: Tue, 4 Dec 2018 10:18:48 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> Message-ID: On 2018-12-04 9:43 AM, Noel Chiappa wrote: > > From: Toby Thain > > > He made amends by being early to recognise that problem, and propose > > solutions, in his 1977 ACM Turing Award lecture > > Actually, I'd consider a far bigger amend to be his work on Algol 60 (he was Possibly, but it's far harder to unpack thesis and reasoning from a codebase. > one of the main contributors), which Hoare so memorably described as "a > language so far ahead of its time that it was not only an improvement on its > predecessors but also on nearly all its successors". > ... > > Noel > From tuhs at tkr.bondplaza.com Wed Dec 5 02:24:17 2018 From: tuhs at tkr.bondplaza.com (Tim Rylance) Date: Tue, 4 Dec 2018 16:24:17 +0000 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> Message-ID: <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com> > On 4 Dec 2018, at 14:53, Clem Cole wrote: > On Tue, Dec 4, 2018 at 9:43 AM Noel Chiappa > wrote: > Which brings up an interesting query - I wonder when/what the last compiler written in assembler was? > Excellent question -- IBM's Fortran-H maybe? circa mid 1970's would be my guess. > ᐧ The Fortran H compiler was mostly written in Fortran: 27,415 lines of Fortran and 16,721 lines of assembler according to slide 12 of [1]. There were some language extensions (structures and pointers) to support this, enabled by the secret compiler option XL. They are described in Appendix J of the Program Logic Manual for the compiler [2]. The early-1980s Fortran 77 compiler for the GEC 4090 was written in Babbage, a thin PL/360-like veneer over the raw 4090 instruction set. [1] http://booksite.elsevier.com/9780120884780/Graduate_Lecture_Slides/Core_Lectures/02FortranH.ppt [2] http://www.bitsavers.org/pdf/ibm/360/fortran/Y28-6642-3_FortH_PLM_Nov68.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Dec 5 02:53:29 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 4 Dec 2018 11:53:29 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com> References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com> Message-ID: On Tue, Dec 4, 2018 at 11:34 AM Tim Rylance wrote: > The Fortran H compiler was mostly written in Fortran: 27,415 lines of > Fortran and 16,721 lines of assembler according to slide 12 of [1]. > Thanks for the pointer. As Doug points out, Burrough's ESPOL started the transition in the early 60s, but it took awhile for it to be something that was done 100% of time by everyone. The mid-70s is clearly the transistion time - as you point out [2/3 self hosting, 1/3 assembler]. I wonder what part was which? Wirth wrote PL/360 to create Algol-W in the late 60s. But York/APL (and I believe APL/360) which were the same timeframe, were assembler [I hacked on the former on TSS in the early/mid 70s]. The first DEC compilers for the 360 bit and 12 bit lines were written in assembler, but they switched to BLISS (and some other languages for different front-ends) by the 70s for the newer generations of compilers. Paul can give that history as he was part of it. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Wed Dec 5 03:07:55 2018 From: cym224 at gmail.com (Nemo) Date: Tue, 4 Dec 2018 12:07:55 -0500 Subject: [TUHS] APL - was Re: man-page style In-Reply-To: <97743c31-e625-39b1-902e-2e531e90ec6f@telegraphics.com.au> References: <1543705783.3909.for-standards-violators@oclsc.org> <97743c31-e625-39b1-902e-2e531e90ec6f@telegraphics.com.au> Message-ID: On 04/12/2018, Toby Thain wrote: > On 2018-12-04 2:48 AM, Dave Horsfall wrote: >> I can only say one thing: APL\360... Now, *there* was a write-only >> language. > > For a more positive take on APL -- only for the open-minded -- try > watching: > https://www.youtube.com/watch?v=9xCJ3BCIudI > >> >> Oh, the stories that I could tell. When I attended an UML course -- about a hundred years ago or so -- one of the attendees was from Reuters. He told us that they were moving to C++ because they could not hire enough people to learn APL, their preferred development language at the tim, even though willing to teach them APL. He thought it far better suited to their task than C++. N. >> >> -- Dave >> >> >> >> >> >> >> >> >> >> >> > > From paul.winalski at gmail.com Wed Dec 5 03:46:46 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 4 Dec 2018 12:46:46 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com> Message-ID: On 12/4/18, Clem Cole wrote: > > The first DEC compilers for the 360 bit and 12 bit lines were written in > assembler, but they switched to BLISS (and some other languages for > different front-ends) by the 70s for the newer generations of compilers. > Paul can give that history as he was part of it. Unfortunately I can't give much of DEC's compiler history as I was a member of the software development tools team at the time. I didn't pay too much attention to what was going on with the VAX compilers. I moved to the compiler world in 1985 as part of the GEM compiler back end team, which was tasked with developing a new, common back end to replace the various VAX code generators going forward. The compiler guys wanted to concentrate on optimization and code generation, so they hired me--a software development tools guy--to design and implement the non-compiler parts of the back end such as command line parsing, heap memory management, file I/O, and object file generation. Over the years GEM was targeted to MIPS, PRISM, Alpha, and Itanium machine architectures, and VMS, Unix, Linux, and Windows NT operating systems. We were working on x86 when Compaq sold the Alpha architecture and its engineering team (including GEM) to Intel. Intel never did anything with the GEM technology. BLISS was DEC engineering's official implementation language. BLISS-32 was used for the VAX. I'm pretty sure VAX Fortran, VAX COBOL, VAX BASIC, and VAX Pascal were all written in BLISS. They all had their own independently developed code generators. VAX C and VAX PL/I were written by Dave Cutler's compiler group in the late 70s/early 80s. They shared a common back end called the VAX Code Generator (VCG). I don't know what the implementation language for VCG was; I think it was C (Dave Cutler was not a BLISS fan). VAX PL/I used the Frieburghouse PL/I front end, which I think was written in C. VAX Ada was also VCG-based; the front end was written in BLISS. VAXeln Pascal might have been written in Pascal. All of DEC's Alpha compilers used GEM as the back end. There was also a VAX MACRO GEM-based compiler that took VAX assembler as its input language and generated native Alpha code. GEM was originally completely written in BLISS, but in the mid-1980s I started rewriting the modules under my control in the common subset of C/C++ to take advantage of strong typing (BLISS has no data typing whatsoever). DEC C/C++ for Alpha used the Edison Design Group C/C++ front end. DEC acquired COMPASS's compiler technology and DEC Fortran used the COMPASS Fortran front end to support Fortran 90. That code is written in C. -Paul W. From paul.winalski at gmail.com Wed Dec 5 03:55:25 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 4 Dec 2018 12:55:25 -0500 Subject: [TUHS] APL - was Re: man-page style In-Reply-To: References: <1543705783.3909.for-standards-violators@oclsc.org> <97743c31-e625-39b1-902e-2e531e90ec6f@telegraphics.com.au> Message-ID: Regarding APL\360, I interned at IBM's Cambridge Scientific Center for a few years before joining DEC in 1980. My first job there was to write a link editor in S/360 assembler that would run stand-alone on S/360 hardware (why I was doing this is an interesting story, but long and way off-topic). This was to replace an existing link editor that was written in APL\360. It was the largest APL program I've ever seen--it ran for over 10 pages of solid code! It also ran slower than death. -Paul W. From gtaylor at tnetconsulting.net Wed Dec 5 04:55:05 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 4 Dec 2018 11:55:05 -0700 Subject: [TUHS] APL - was Re: man-page style In-Reply-To: References: <1543705783.3909.for-standards-violators@oclsc.org> <97743c31-e625-39b1-902e-2e531e90ec6f@telegraphics.com.au> Message-ID: <4df2393f-afc8-52b0-2c15-221a072d3dea@spamtrap.tnetconsulting.net> On 12/4/18 10:55 AM, Paul Winalski wrote: > why I was doing this is an interesting story, but long and way off-topic I'm always interested in odd stories like this. Perhaps it would be more on topic on the COFF mailing list. ;-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From dave at horsfall.org Wed Dec 5 06:44:12 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 5 Dec 2018 07:44:12 +1100 (EST) Subject: [TUHS] ARPAnet now 4 nodes Message-ID: The ARPAnet reached four nodes on this day in 1969 (anyone know their names?); at least one "history" site reckoned the third node was connected in 1977 (and I'm still waiting for a reply to my correction). Well, I can believe that perhaps there were only three left by then... Hmmm... According to my notes, the nodes were UCSB, UCLA, SRI, and Utah. -- Dave From clemc at ccc.com Wed Dec 5 06:50:45 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 4 Dec 2018 15:50:45 -0500 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: References: Message-ID: That's correct. Although it was 1969. I just sent Dave the paper from the IEEE Annals of History of Computing: 1058-6180/15 [2015] Called 'The Production and Interpretation of APRANET Maps" by Fidler and Currie ᐧ On Tue, Dec 4, 2018 at 3:45 PM Dave Horsfall wrote: > The ARPAnet reached four nodes on this day in 1969 (anyone know their > names?); at least one "history" site reckoned the third node was connected > in 1977 (and I'm still waiting for a reply to my correction). Well, I can > believe that perhaps there were only three left by then... > > Hmmm... According to my notes, the nodes were UCSB, UCLA, SRI, and Utah. > > -- Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Wed Dec 5 06:57:17 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 04 Dec 2018 20:57:17 +0000 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: (Dave Horsfall's message of "Wed, 5 Dec 2018 07:44:12 +1100 (EST)") References: Message-ID: <7w1s6xggcy.fsf@junk.nocrew.org> Dave Horsfall wrote: > Well, I can believe that perhaps there were only three left by then... Certainly not. From clemc at ccc.com Wed Dec 5 06:57:10 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 4 Dec 2018 15:57:10 -0500 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: References: Message-ID: BTW: By Sept '73 there were ~20 IMPs and ~15 TIPs The total hosts was ~45 My March '74, the numbers had doubled. ᐧ On Tue, Dec 4, 2018 at 3:50 PM Clem Cole wrote: > That's correct. Although it was 1969. I just sent Dave the paper from > the IEEE Annals of History of Computing: 1058-6180/15 [2015] Called > 'The Production and Interpretation of APRANET Maps" by Fidler and Currie > ᐧ > > On Tue, Dec 4, 2018 at 3:45 PM Dave Horsfall wrote: > >> The ARPAnet reached four nodes on this day in 1969 (anyone know their >> names?); at least one "history" site reckoned the third node was >> connected >> in 1977 (and I'm still waiting for a reply to my correction). Well, I >> can >> believe that perhaps there were only three left by then... >> >> Hmmm... According to my notes, the nodes were UCSB, UCLA, SRI, and Utah. >> >> -- Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Dec 5 06:59:46 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 4 Dec 2018 15:59:46 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com> Message-ID: On 12/4/18, Paul Winalski wrote: > > Over the years GEM was targeted to MIPS, PRISM, Alpha, and Itanium > machine architectures, and VMS, Unix, Linux, and Windows NT operating > systems. We were working on x86 when Compaq sold the Alpha > architecture and its engineering team (including GEM) to Intel. I forgot one: Tandem NonStop OS on Alpha, which was under development at Compaq at the time that Compaq decided to sell off the Alpha technology to Intel. The Tandem stuff was retargeted to Itanium. We GEM folks lost track of Tandem at that time, so I don't know what back end HP is using for the NonStop on Itanium product. -Paul W. From dave at horsfall.org Wed Dec 5 07:16:38 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 5 Dec 2018 08:16:38 +1100 (EST) Subject: [TUHS] In Memoriam: John Lions Message-ID: We lost Dr. John Lions of this day in 1998; he was one of my Comp Sci lecturers (yes, I helped him write The Book, and yes, you'll find my name in the back). -- Dave From dave at horsfall.org Wed Dec 5 07:26:29 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 5 Dec 2018 08:26:29 +1100 (EST) Subject: [TUHS] man-page style In-Reply-To: <20181203013025.GB10043@mcvoy.com> References: <1543705783.3909.for-standards-violators@oclsc.org> <20181203011414.DAE3D156E410@mail.bitblocks.com> <20181203013025.GB10043@mcvoy.com> Message-ID: On Sun, 2 Dec 2018, Larry McVoy wrote: >>> And anyone who has not edited sendmail.cf (shudder!) is not a >>> programmer. > > As a systems guy I think if you have not written, or understood, > swtch(), you are not a systems guy. Ahh, line 2238... -- Dave From lm at mcvoy.com Wed Dec 5 07:34:52 2018 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 4 Dec 2018 13:34:52 -0800 Subject: [TUHS] man-page style In-Reply-To: References: <1543705783.3909.for-standards-violators@oclsc.org> <20181203011414.DAE3D156E410@mail.bitblocks.com> <20181203013025.GB10043@mcvoy.com> Message-ID: <20181204213452.GI3316@mcvoy.com> On Wed, Dec 05, 2018 at 08:26:29AM +1100, Dave Horsfall wrote: > On Sun, 2 Dec 2018, Larry McVoy wrote: > > >>>And anyone who has not edited sendmail.cf (shudder!) is not a > >>>programmer. > > > >As a systems guy I think if you have not written, or understood, swtch(), > >you are not a systems guy. > > Ahh, line 2238... I dunno what line it is, I'm guessing that's the # for the Lions book? I learned swtch() because I wrote a userland thread library for Udi Manber as a grad student (yield based as I recall). I'd never really thought about it hard, yeah, did all the CS toy OS stuff but I don't think they made us write that. I loved writing it, I did a super minimal one that had the bulk of the work in C, just did the save/restore in asm. It's just so satisying to go in as one process and come out as the other (and annoying when some idiot used floating point - who does that? Cough, Clem, cough. and you realize you didn't save/restore fp registers :) From nobozo at gmail.com Wed Dec 5 08:06:46 2018 From: nobozo at gmail.com (Jon Forrest) Date: Tue, 4 Dec 2018 14:06:46 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: References: Message-ID: <690a4d0f-f9f7-5ca8-8057-b7ab6b40875f@gmail.com> On 12/4/2018 12:44 PM, Dave Horsfall wrote: > Hmmm... According to my notes, the nodes were UCSB, UCLA, SRI, and > Utah. I had commented on the ARPAnet's presence at UCSB on this list earlier. Back then, being on the ARPAnet didn't mean anything like what being on the Internet means now. Back then, only a few research groups had access to, or even knew about, the ARPAnet. I didn't find out about it until I was a grad student there in the late '70s even though I had been an undergrad from 73-75. Jon Forrest From bakul at bitblocks.com Wed Dec 5 08:11:27 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Tue, 4 Dec 2018 14:11:27 -0800 Subject: [TUHS] man-page style In-Reply-To: <20181204213452.GI3316@mcvoy.com> References: <1543705783.3909.for-standards-violators@oclsc.org> <20181203011414.DAE3D156E410@mail.bitblocks.com> <20181203013025.GB10043@mcvoy.com> <20181204213452.GI3316@mcvoy.com> Message-ID: On Dec 4, 2018, at 1:34 PM, Larry McVoy wrote: > > On Wed, Dec 05, 2018 at 08:26:29AM +1100, Dave Horsfall wrote: >> On Sun, 2 Dec 2018, Larry McVoy wrote: >> >>>>> And anyone who has not edited sendmail.cf (shudder!) is not a >>>>> programmer. >>> >>> As a systems guy I think if you have not written, or understood, swtch(), >>> you are not a systems guy. >> >> Ahh, line 2238... > > I dunno what line it is, I'm guessing that's the # for the Lions book? > > I learned swtch() because I wrote a userland thread library for Udi Manber > as a grad student (yield based as I recall). I'd never really thought > about it hard, yeah, did all the CS toy OS stuff but I don't think they > made us write that. I loved writing it, I did a super minimal one that > had the bulk of the work in C, just did the save/restore in asm. I too built a coroutine library. We used it for simulating some real h/w we were building. The nice thing about h/w simulation is no recursion so your threads can work with as little as 50-100 bytes of stack, so even on a 64MB machine 100K threads was not a problem! There is no yield() here being a simulation core. Thread switch occurs in wait(), signal() & busy(n) -- the last one to simulate passage of time. I built the very initial version in 1982-83 using setjmp/longjmp! We used it to check if our 5.6Mhz bus could support ethernet traffic while doing other things. Of course, this is much simpler than a unix swtch(). From lm at mcvoy.com Wed Dec 5 08:14:21 2018 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 4 Dec 2018 14:14:21 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <690a4d0f-f9f7-5ca8-8057-b7ab6b40875f@gmail.com> References: <690a4d0f-f9f7-5ca8-8057-b7ab6b40875f@gmail.com> Message-ID: <20181204221421.GL3316@mcvoy.com> On Tue, Dec 04, 2018 at 02:06:46PM -0800, Jon Forrest wrote: > On 12/4/2018 12:44 PM, Dave Horsfall wrote: > >Hmmm... According to my notes, the nodes were UCSB, UCLA, SRI, and > >Utah. > > I had commented on the ARPAnet's presence at UCSB on this list > earlier. Back then, being on the ARPAnet didn't mean anything > like what being on the Internet means now. Has anyone put together a list of IMPs and dates in the order they were added to the net? -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From grog at lemis.com Wed Dec 5 08:49:25 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 5 Dec 2018 09:49:25 +1100 Subject: [TUHS] Tandem NSK implementation language (was: Happy birthday, John Backus!) In-Reply-To: References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com> Message-ID: <20181204224925.GB55383@eureka.lemis.com> On Tuesday, 4 December 2018 at 15:59:46 -0500, Paul Winalski wrote: > On 12/4/18, Paul Winalski wrote: >> >> Over the years GEM was targeted to MIPS, PRISM, Alpha, and Itanium >> machine architectures, and VMS, Unix, Linux, and Windows NT operating >> systems. We were working on x86 when Compaq sold the Alpha >> architecture and its engineering team (including GEM) to Intel. > > I forgot one: Tandem NonStop OS on Alpha, which was under development > at Compaq at the time that Compaq decided to sell off the Alpha > technology to Intel. Was this a start-from-scratch operation? The original Tandem OS (called Guardian at the time) was written in Tandem's TAL (Transaction Application Language, amongst other productions), a vague evolution of HP's SPL that looked more like Algol, starting in about 1974. That is also the earliest I know of an operating system being implemented entirely in a high level language. When Tandem started using other architectures (MIPS) in the late 1980s we discussed translating the whole thing to C. I was asked to write a 99% translator (maintaining comments and such), and failed. I lost track of the system after that, but it seems surprising that they would have started again from scratch. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From grog at lemis.com Wed Dec 5 08:54:04 2018 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 5 Dec 2018 09:54:04 +1100 Subject: [TUHS] swtch() (was: man-page style) In-Reply-To: References: <1543705783.3909.for-standards-violators@oclsc.org> <20181203011414.DAE3D156E410@mail.bitblocks.com> <20181203013025.GB10043@mcvoy.com> Message-ID: <20181204225404.GC55383@eureka.lemis.com> On Wednesday, 5 December 2018 at 8:26:29 +1100, Dave Horsfall wrote: > On Sun, 2 Dec 2018, Larry McVoy wrote: > >>>> And anyone who has not edited sendmail.cf (shudder!) is not a >>>> programmer. >> >> As a systems guy I think if you have not written, or understood, >> swtch(), you are not a systems guy. > > Ahh, line 2238... Not line 325 of ken/slp.c? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From paul.winalski at gmail.com Wed Dec 5 10:08:56 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 4 Dec 2018 19:08:56 -0500 Subject: [TUHS] Tandem NSK implementation language (was: Happy birthday, John Backus!) In-Reply-To: <20181204224925.GB55383@eureka.lemis.com> References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com> <20181204224925.GB55383@eureka.lemis.com> Message-ID: On 12/4/18, Greg 'groggy' Lehey wrote: > On Tuesday, 4 December 2018 at 15:59:46 -0500, Paul Winalski wrote: >> >> I forgot one: Tandem NonStop OS on Alpha, which was under development >> at Compaq at the time that Compaq decided to sell off the Alpha >> technology to Intel. > > Was this a start-from-scratch operation? The original Tandem OS > (called Guardian at the time) was written in Tandem's TAL (Transaction > Application Language, amongst other productions), a vague evolution of > HP's SPL that looked more like Algol, starting in about 1974. That is > also the earliest I know of an operating system being implemented > entirely in a high level language. No, not start-from-scratch. They modified the existing MIPS TAL front end to generate GEM intermediate language. I don't know if the TAL front end generated GEM IL directly or if they wrote some sort of IL-to-IL translator wedge. IIRC we didn't need to do any object file work in GEM to support Tandem because they were already using an object file format we supported (ELF or COFF). > When Tandem started using other architectures (MIPS) in the late 1980s > we discussed translating the whole thing to C. I was asked to write a > 99% translator (maintaining comments and such), and failed. IIRC some of the Tandem code was in C at this point (1999) but a TAL for Alpha was also needed. -Paul W. From paul at mcjones.org Wed Dec 5 14:48:24 2018 From: paul at mcjones.org (Paul McJones) Date: Tue, 4 Dec 2018 20:48:24 -0800 Subject: [TUHS] Tandem NSK implementation language (was: Happy birthday, John Backus!) In-Reply-To: References: Message-ID: <385DF3A2-447D-4CD4-AC5C-9F541070C28B@mcjones.org> > On Dec 4, 2018, Greg 'groggy' Lehey wrote: > > The original Tandem OS (called Guardian at the time) was written in Tandem's TAL (Transaction Application Language, amongst other productions), a vague evolution of HP's SPL that looked more like Algol, starting in about 1974. That is also the earliest I know of an operating system being implemented entirely in a high level language. Most likely the earliest operating system written in a high-level language was the one for the Burroughs B5000 (early 1960s), written in a dialect of Algol 60. Others: Multics, written in PL/1 (starting in mid 1960s), the operating system for the Berkeley Computer Corporation’s BCC-500, written in BCC SPL (system programming language) (late 1960s), OS6 by Stoy and Strachey, written in BCPL (early 1970s), Xerox Alto OS, written in BCPL (about 1974). From pdagog at gmail.com Wed Dec 5 16:50:48 2018 From: pdagog at gmail.com (Pierre DAVID) Date: Wed, 5 Dec 2018 07:50:48 +0100 Subject: [TUHS] man-page style In-Reply-To: <20181204213452.GI3316@mcvoy.com> References: <1543705783.3909.for-standards-violators@oclsc.org> <20181203011414.DAE3D156E410@mail.bitblocks.com> <20181203013025.GB10043@mcvoy.com> <20181204213452.GI3316@mcvoy.com> Message-ID: <20181205065048.GA11562@vagabond> On Tue, Dec 04, 2018 at 01:34:52PM -0800, Larry McVoy wrote: >On Wed, Dec 05, 2018 at 08:26:29AM +1100, Dave Horsfall wrote: >> On Sun, 2 Dec 2018, Larry McVoy wrote: >> >> >>>And anyone who has not edited sendmail.cf (shudder!) is not a >> >>>programmer. >> > >> >As a systems guy I think if you have not written, or understood, swtch(), >> >you are not a systems guy. >> >> Ahh, line 2238... > >I dunno what line it is, I'm guessing that's the # for the Lions book? > "You are not expected..." Pierre From iain at csp-partnership.co.uk Wed Dec 5 18:16:55 2018 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Wed, 5 Dec 2018 08:16:55 +0000 Subject: [TUHS] Tandem NSK implementation language (was: Happy birthday, John Backus!) In-Reply-To: <385DF3A2-447D-4CD4-AC5C-9F541070C28B@mcjones.org> References: <385DF3A2-447D-4CD4-AC5C-9F541070C28B@mcjones.org> Message-ID: > On 5 Dec 2018, at 04:48, Paul McJones wrote: > >> On Dec 4, 2018, Greg 'groggy' Lehey wrote: >> >> The original Tandem OS (called Guardian at the time) was written in Tandem's TAL (Transaction Application Language, amongst other productions), a vague evolution of HP's SPL that looked more like Algol, starting in about 1974. That is also the earliest I know of an operating system being implemented entirely in a high level language. > > Most likely the earliest operating system written in a high-level language was the one for the Burroughs B5000 (early 1960s), written in a dialect of Algol 60. Others: Multics, written in PL/1 (starting in mid 1960s), the operating system for the Berkeley Computer Corporation’s BCC-500, written in BCC SPL (system programming language) (late 1960s), OS6 by Stoy and Strachey, written in BCPL (early 1970s), Xerox Alto OS, written in BCPL (about 1974). > About 1972 the Department of Computer Science at Strathclyde University in Scotland had an operating system implemented on a front-end-processor (Icant remember the make) that allowed the submission and control of jobs to a “mainframe” - an ICL 1904s. The operating system was written in STAB - a language initially designed and developed by Professor Andrew Colin - and loosely modelled on BCPL. My memory is that the FEP was about 12 19” racks, it supported about 15-20 users and did not lose your files terribly often ;-) From clemc at ccc.com Thu Dec 6 00:29:33 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Dec 2018 09:29:33 -0500 Subject: [TUHS] Tandem NSK implementation language (was: Happy birthday, John Backus!) In-Reply-To: <385DF3A2-447D-4CD4-AC5C-9F541070C28B@mcjones.org> References: <385DF3A2-447D-4CD4-AC5C-9F541070C28B@mcjones.org> Message-ID: Paul beat me to it.. HP's SPL and Tandem's TAL were old news by then ... In fact the HP's 3000's and HP 9000's stack architecture was model from the B5000, see below... On Wed, Dec 5, 2018 at 12:35 AM Paul McJones wrote: > > On Dec 4, 2018, Greg 'groggy' Lehey wrote: > > > > The original Tandem OS (called Guardian at the time) was written in > Tandem's TAL (Transaction Application Language, amongst other productions), > a vague evolution of HP's SPL that looked more like Algol, starting in > about 1974. That is also the earliest I know of an operating system being > implemented entirely in a high level language. > > Most likely the earliest operating system written in a high-level language > was the one for the Burroughs B5000 (early 1960s), written in a dialect of > Algol 60. Called Executive Systems Problem Oriented Language or ESPOL . A later edition (66/67 time frame) of the reference manual for the 5500 can be found on bitsavers as: ESPOL B5500 Reference Manual 1967 ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 6 01:33:45 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Dec 2018 10:33:45 -0500 Subject: [TUHS] swtch() (was: man-page style) In-Reply-To: <20181204225404.GC55383@eureka.lemis.com> References: <1543705783.3909.for-standards-violators@oclsc.org> <20181203011414.DAE3D156E410@mail.bitblocks.com> <20181203013025.GB10043@mcvoy.com> <20181204225404.GC55383@eureka.lemis.com> Message-ID: Same thing... it's line 2238 in Lions' numbering system on sheet 22 of the sources book. It's line 325 of ken/slp.c if you are in ed/vi or the like. ᐧ On Tue, Dec 4, 2018 at 5:55 PM Greg 'groggy' Lehey wrote: > On Wednesday, 5 December 2018 at 8:26:29 +1100, Dave Horsfall wrote: > > On Sun, 2 Dec 2018, Larry McVoy wrote: > > > >>>> And anyone who has not edited sendmail.cf (shudder!) is not a > >>>> programmer. > >> > >> As a systems guy I think if you have not written, or understood, > >> swtch(), you are not a systems guy. > > > > Ahh, line 2238... > > Not line 325 of ken/slp.c? > > Greg > -- > Sent from my desktop computer. > Finger grog at lemis.com for PGP public key. > See complete headers for address and phone numbers. > This message is digitally signed. If your Microsoft mail program > reports problems, please read http://lemis.com/broken-MUA > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Dec 6 02:24:36 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 5 Dec 2018 11:24:36 -0500 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) Message-ID: Another DEC compiler that I forgot was the original C compiler for Tru64 Unix on the Alpha. This was done at the DECwest facility in Seattle (which originally had been set up by Dave Cutler). It was a very strict implementation of the ANSI C89 standard--it had no extensions such as K&R support. One customer called it the "Rush Limbaugh of C compilers" because it was extremely conservative and you couldn't argue with it. -Paul W. From paul.winalski at gmail.com Thu Dec 6 02:46:55 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 5 Dec 2018 11:46:55 -0500 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: References: Message-ID: Another curious compiler at DEC was VAX Ultrix Fortran. DEC had gotten a lot of push-back from the research community, who wanted to use VAX and Ultrix but considered the f77 compiler inadequate and wanted to use VAX Fortran, which only ran on VAX/VMS. There was a rush project to port VAX Fortran to Ultrix. It was decided that the quickest way to get a quality compiler to market was to have the VAX Fortran compiler continue to emit VMS-format object files, and to modify the VAX/VMS linker to accept a.out object files and to emit a.out images. Four of us worked on the linker port. Two of us from the VAX/VMS languages team did the linker mods and two engineers from the Ultrix group wrote code to translate VMS debug information to Unix stabs. The resulting linker was called lk. The VAX Fortran RTL was also ported, and since we had a way to produce Unix executables from VMS object files, it meant we didn't have to rewrite the RTL, which was mainly in BLISS but also had modules in Fortran, VAX assembler, and Pascal. -Paul W. From imp at bsdimp.com Thu Dec 6 03:06:15 2018 From: imp at bsdimp.com (Warner Losh) Date: Wed, 5 Dec 2018 10:06:15 -0700 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: References: Message-ID: On Wed, Dec 5, 2018 at 9:48 AM Paul Winalski wrote: > Another curious compiler at DEC was VAX Ultrix Fortran. DEC had > gotten a lot of push-back from the research community, who wanted to > use VAX and Ultrix but considered the f77 compiler inadequate and > wanted to use VAX Fortran, which only ran on VAX/VMS. There was a > rush project to port VAX Fortran to Ultrix. It was decided that the > quickest way to get a quality compiler to market was to have the VAX > Fortran compiler continue to emit VMS-format object files, and to > modify the VAX/VMS linker to accept a.out object files and to emit > a.out images. Four of us worked on the linker port. Two of us from > the VAX/VMS languages team did the linker mods and two engineers from > the Ultrix group wrote code to translate VMS debug information to Unix > stabs. The resulting linker was called lk. The VAX Fortran RTL was > also ported, and since we had a way to produce Unix executables from > VMS object files, it meant we didn't have to rewrite the RTL, which > was mainly in BLISS but also had modules in Fortran, VAX assembler, > and Pascal. > Nice work! We ran VMS on our MicroVAX rather than Ultrix or 4.[23]BSD because of the FORTRAN compiler being so much better on VMS and our group needing it for its hydrological simulations. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Dec 6 03:49:05 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 5 Dec 2018 12:49:05 -0500 Subject: [TUHS] Happy birthday, John Backus! In-Reply-To: References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu> <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com> Message-ID: On 12/4/18, Paul Winalski wrote: > > GEM was originally > completely written in BLISS, but in the mid-1980s I started rewriting > the modules under my control in the common subset of C/C++ to take > advantage of strong typing (BLISS has no data typing whatsoever). Typo. I meant to say "mid-1990s". -Paul W. From clemc at ccc.com Thu Dec 6 03:58:41 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Dec 2018 12:58:41 -0500 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: References: Message-ID: I'll never forget Bill Munson's warnings at the 1980 USENIX conference. Munson ran 'TIG' - Telephone Industries Group, in Merrimack, NH - who job at DEC was helping their largest customer: AT&T. Us university types were screaming at Bill and team "When is DEC going to 'support' UNIX?" Bill got up an cautioned, 'Be careful what you wish/ask us to do. If we do support Unix, we will have to put Fortran, Cobol, and PL/1 on it -- which I don't think you really want.' I'm not sure which languages did eventually get supported and on which versions of Ultrix. But once Paul's lk was released (and you can still find it in /bin on the base Ultrix distributions), you did indeed see a number of the languages move to Ultrix. I think for the Vax it was just VAX/11C, Fortran and Pascal. I think Ultrix11 may have gotten Fortran, but as I said; I don't remember. I do remember the TIG folks talking about a PL/1 project and a proposal for Cobol and RP/G because some of the Wall Street types wanted them, but I don't remember any of those getting released (that said, I was also not watching things Vaxen by that time). By the time I came back to Ultrix to do the MIPS 4000 stuff a few years later, tech languages offerings were different and the GEM compilers had come on the scene. Clem ᐧ On Wed, Dec 5, 2018 at 11:48 AM Paul Winalski wrote: > Another curious compiler at DEC was VAX Ultrix Fortran. DEC had > gotten a lot of push-back from the research community, who wanted to > use VAX and Ultrix but considered the f77 compiler inadequate and > wanted to use VAX Fortran, which only ran on VAX/VMS. There was a > rush project to port VAX Fortran to Ultrix. It was decided that the > quickest way to get a quality compiler to market was to have the VAX > Fortran compiler continue to emit VMS-format object files, and to > modify the VAX/VMS linker to accept a.out object files and to emit > a.out images. Four of us worked on the linker port. Two of us from > the VAX/VMS languages team did the linker mods and two engineers from > the Ultrix group wrote code to translate VMS debug information to Unix > stabs. The resulting linker was called lk. The VAX Fortran RTL was > also ported, and since we had a way to produce Unix executables from > VMS object files, it meant we didn't have to rewrite the RTL, which > was mainly in BLISS but also had modules in Fortran, VAX assembler, > and Pascal. > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Thu Dec 6 04:16:45 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 5 Dec 2018 13:16:45 -0500 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: References: Message-ID: On 12/5/18, Clem Cole wrote: > I'll never forget Bill Munson's warnings at the 1980 USENIX conference. > Munson ran 'TIG' - Telephone Industries Group, in Merrimack, NH - who job > at DEC was helping their largest customer: AT&T. Us university types > were screaming at Bill and team "When is DEC going to 'support' UNIX?" Bill > got up an cautioned, 'Be careful what you wish/ask us to do. If we do > support Unix, we will have to put Fortran, Cobol, and PL/1 on it -- which I > don't think you really want.' > TIG's mission was to insure that DEC gear did what AT&T wanted. For Unix this mainly was assisting in ports to new DEC hardware and writing device drivers. Their mission was distinctly NOT to develop anything DEC-specific. They were obsessively paranoid about that--they called such things "vendor traps". Our attitude in the VAX/VMS languages and software tools group was very different. We were all about making VAX/VMS different, and better, in the marketplace in order to attract customers to our platform. When DEC officially decided to do their own, fully supported version of Unix (to be branded Ultrix), things happened exactly as Bill Munson predicted. The VAX/VMS languages & tools group started planning for an orderly port of all of our products to Ultrix. We got immediate and fierce push-back from the Ultrix engineering group (formerly TIG). So we dropped the whole idea. Only to have to do a panic port of VAX Fortran a few years later. Sigh. The wonder of culture clashes. It took a long time for the "vendor trap" idea to die in DEC's Unix group. Sun and others weren't as prissy when it came to putting their own extensions into their Unix offerings, and the DEC Unix group eventually found themselves being considered a trailing-edge offering. -Paul W. P.S. - I forgot VAX RPG as one of DEC's language products. I think it was VCG-based, but I'm not certain of that. From henry.r.bent at gmail.com Thu Dec 6 04:26:09 2018 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 5 Dec 2018 13:26:09 -0500 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: References: Message-ID: On Wed, 5 Dec 2018 at 13:01, Clem Cole wrote: > I'm not sure which languages did eventually get supported and on which > versions of Ultrix. But once Paul's lk was released (and you can still > find it in /bin on the base Ultrix distributions), you did indeed see a > number of the languages move to Ultrix. I think for the Vax it was just > VAX/11C, Fortran and Pascal. I think Ultrix11 may have gotten Fortran, but > as I said; I don't remember. I do remember the TIG folks talking about a > PL/1 project and a proposal for Cobol and RP/G because some of the Wall > Street types wanted them, but I don't remember any of those getting > released (that said, I was also not watching things Vaxen by that time). > By the time I came back to Ultrix to do the MIPS 4000 stuff a few years > later, tech languages offerings were different and the GEM compilers had > come on the scene. > http://bitsavers.trailing-edge.com/pdf/dec/vax/ultrix-32/4.0_Jun90/AA-MG63B-TE_ULTRIX_Technical_Summary_Jun90.pdf seems to imply that as of Ultrix 4.0, there were COBOL and Ada compilers for the VAX (Table 4-1). Elsewhere VAX LISP for Ultrix is mentioned, which I had no idea existed. I hope that these compilers have been preserved somewhere, as I imagine they sold in relatively small quantities. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 6 04:46:44 2018 From: clemc at ccc.com (Clem Cole) Date: Wed, 5 Dec 2018 13:46:44 -0500 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: References: Message-ID: On Wed, Dec 5, 2018 at 1:29 PM Henry Bent wrote: > > http://bitsavers.trailing-edge.com/pdf/dec/vax/ultrix-32/4.0_Jun90/AA-MG63B-TE_ULTRIX_Technical_Summary_Jun90.pdf > seems to imply that as of Ultrix 4.0, there were COBOL and Ada compilers > for the VAX (Table 4-1). Elsewhere VAX LISP for Ultrix is mentioned, which > I had no idea existed. I hope that these compilers have been preserved > somewhere, as I imagine they sold in relatively small quantities. > It all gets fuzzy by then - what was released and what actually existed. Their was a Vax LISP from the Franz guys, but I think the DEC/CMU Common LISP was VMS also was there. The 11 has been dropped from support an the PMAX has replaced it but the compilers for PMAX are coming primarily from MIPS. I do not believe DEC did a LISP themselves for the MIPS machines. But, it turns out a number of the MIPS compilers would work on Ultrix, although DEC had not released them directly. But some 3rd parties did on their own, sometimes with DEC's blessing and sometimes not. Plus the Alpha is being developed by then, so TLG is up to neck in the GEM development cycle which would replace everything i the languages teams when the dust settled (as Paul has mentioned it was an amazing piece of work at the time and still somewhat lasts today - the VMS,Inc folks of course are built an INTEL*64 code generator for it and supposedlty have VMS booting on modern HW these days). Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Thu Dec 6 04:56:54 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 05 Dec 2018 18:56:54 +0000 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: (Clem Cole's message of "Wed, 5 Dec 2018 13:46:44 -0500") References: Message-ID: <7wtvjrdcp5.fsf@junk.nocrew.org> Clem Cole wrote: > Henry Bent wrote: >> Elsewhere VAX LISP for Ultrix is mentioned, which I had no idea >> existed. > Their was a Vax LISP from the Franz guys, but I think the DEC/CMU > Common LISP was VMS also was there. Franz Lisp is kind of a Maclisp for VAX. It can run Macsyma. There was also NIL, for VMS. Was it ever finished? From norman at oclsc.org Thu Dec 6 05:13:06 2018 From: norman at oclsc.org (Norman Wilson) Date: Wed, 05 Dec 2018 14:13:06 -0500 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) Message-ID: <1544037189.3870.for-standards-violators@oclsc.org> Lars Brinkhoff: There was also NIL, for VMS. Was it ever finished? ==== If so, is there a pointer to it? Norman Wilson Toronto On From paul.winalski at gmail.com Thu Dec 6 05:15:14 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 5 Dec 2018 14:15:14 -0500 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: References: Message-ID: On 12/5/18, Clem Cole wrote: > > Plus the Alpha is being developed by then, so TLG is up to neck in the GEM > development cycle which would replace everything i the languages teams when > the dust settled (as Paul has mentioned it was an amazing piece of work at > the time and still somewhat lasts today - the VMS,Inc folks of course are > built an INTEL*64 code generator for it and supposedlty have VMS booting on > modern HW these days). One of the design goals for GEM was to avoid another fire drill like the VAX Fortran Ultrix port. GEM had a set of modules called the GEM Shell that isolated the rest of the compiler from OS platform-dependent activities such as command line parsing, file I/O, heap memory management, source locator management, and object file generation. The GEM Shell presented a set of abstract APIs for these activities to the rest of the compiler. This made support of new OS platforms or object file formats relatively easy. GEM already supported Itanium by the time Compaq sold off the Alpha technology to Intel. VMS is mostly implemented in BLISS and VAX assembler, and GEM-based Itanium-targeted compilers already existed for both of these. VMS Software Inc. uses the GEM-based compilers for support and ongoing new development on the Alpha and Itanium platforms. For the Intel64 port of VMS, VSI is using Clang/LLVM as their C/C++ compiler. For BLISS and VAX assembler, they are using the GEM-based front ends, and a GEM-to-LLVM IL translator to use LLVM as the optimizer/code generator. -Paul W. From arrigo at alchemistowl.org Thu Dec 6 07:35:06 2018 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Wed, 5 Dec 2018 22:35:06 +0100 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: References: Message-ID: As one of the OSF/1 T1.0 customers back when I remember well all these compilers during the transition from Ultrix… I was wondering if anyone remembers the HPF compiler and the “pangolin” parallel debugger which I used around 1994 on an Alpha farm connected with FDDI. I fondly recall our DEC contact for pangolin who was really helpful but I totally forgot his name :( The HPF group in contact with us was also small but fixed loads of bugs we reported. Arrigo From scj at yaccman.com Thu Dec 6 10:37:48 2018 From: scj at yaccman.com (Steve Johnson) Date: Wed, 05 Dec 2018 16:37:48 -0800 Subject: [TUHS] stories In-Reply-To: <20181128171725.GJ5701@mcvoy.com> Message-ID: <176ee799252cfa8fc7aa535a02cac1c609ceaf8d@webmail.yaccman.com> I heard about Bell Labs from someone who had a summer job a couple of years earlier.  He said the people were smart and dedicated, and it was not a place where everybody went home at 5PM (that was an understatement!).  One of my professors knew someone there and gave them a call, so an interview was set up.  It was about a 2 hour drive from my home outside of Philadelphia, so I left three hours before the interview, ran into some traffic, and then got horribly lost (oh for a GPS!).  I got to the interview an hour and 15 minutes late and talked to an HR person who said, in effect, "It's a shame you came in today.  We hardly hire anyone, and we've already hired everyone we need for the summer.  But since you're here, we've arranged for your to have lunch with one of our busy researchers..."   I had a 2-hour lunch with Tom Crowley, and we really hit it off.  Tom then took me around and introduced me to people as "This is Steve who will be working with us this summer...".   Then he took me back to HR, where they effectively repeated their earlier message.  It was my first, but far from my last, experience with organizational incoherence.   But in any case, I got the job.  After the first summer, I was hooked... It's probably worth pointing out that Xerox PARC soon became a serious competitor for computing talent, with almost no overlap with the labs in the computer area--they were a lisp shop and WYSIWYG text processing and such.  I had some very spirited discussions with PARC folks at conferences that were a lot of fun and very stimulating.  In the compiler area, IBM Yorktown Heights also did work much different from the Labs, and lead to lively debates at conferences. Steve ----- Original Message ----- From: "Larry McVoy" To:"The Eunuchs Hysterical Society" Cc: Sent:Wed, 28 Nov 2018 09:17:25 -0800 Subject:[TUHS] stories Ken's story got me thinking about stuff I would still like to learn and his comment about "when I got to Bell Labs"... made me wonder how did Ken, Dennis, Brian, Joe and the rest of the crew make their way to Bell Labs? When I was just starting out, Sun was sort of the Bell Labs of the time (not that Sun was the same as Bell Labs but it was sort of the center of the Unix universe in my mind). So I wanted to go there and had to work at it a bit but I got there. Was Bell Labs in the 60's like that? If you were a geek was that the place to go? I was born in '62 so I don't have any memory of how well known the Labs were back then. So how was it that so many smart - and somewhat like minded it seems - people end up there? --lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Thu Dec 6 13:22:58 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 05 Dec 2018 22:22:58 -0500 Subject: [TUHS] Stories Message-ID: <201812060322.wB63MwGn025254@tahoe.cs.Dartmouth.EDU> > So how was it that so many smart - and somewhat like minded it seems > people end up there? [At Bell Labs] 1. Bell Labs had a great reputation, though it was not at first known for computing. 2. Research recruiters were researchers themselves, not HR people. 3. Recruiting was for quality hires, not for particular jobs; complementary talent was valued. 4. Whom a candidate met on site was determined after s/he gave a seminar; this promoted good matchups. 5. Researchers decided for themselves what to work on--either self- generated or an interesting problem from elsewhere in the company. 6. If you needed to know something in most any field, you could usually find a willing expert to get you on track to an answer. 7. Annual merit review was collegial. No one lost out because of unlucky draw of a supervisor. 8. Collegiality in fact beat that of any faculty I know. Office doors were always open; new arrivals needed only to do good work, not to chase tenure. This culture grew from the grand original idea of the Labs: R&D for the whole of AT&T funded by the whole of AT&T, with a long time horizon. I joined thinking the Labs was good seasoning for academia. The culture held me for 39 years. The premise was viable in the days of regulated monopoly. It has been greatly watered down since. Doug From arnold at skeeve.com Fri Dec 7 05:26:14 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 06 Dec 2018 12:26:14 -0700 Subject: [TUHS] Stories In-Reply-To: <201812060322.wB63MwGn025254@tahoe.cs.Dartmouth.EDU> References: <201812060322.wB63MwGn025254@tahoe.cs.Dartmouth.EDU> Message-ID: <201812061926.wB6JQEFm017949@freefriends.org> Doug McIlroy wrote: > > So how was it that so many smart - and somewhat like minded it seems > > people end up there? [At Bell Labs] > > 1. Bell Labs had a great reputation, though it was not at first known > for computing. > > ..... Sounds wonderful. I often wished I could have gone there, but not everyone got into 1127. > This culture grew from the grand original idea of the Labs: R&D for > the whole of AT&T funded by the whole of AT&T, with a long time horizon. > I joined thinking the Labs was good seasoning for academia. The culture > held me for 39 years. > > The premise was viable in the days of regulated monopoly. It has been > greatly watered down since. Which is a great shame, IMHO. I've been meaning to ask here. There are a number of stories of, shall we say pranks, pulled by the Unix room folks, and the group's sense of humor was often reflected in writing in the man pages. Was this more widespread in the Bell Labs culture? Did your average physicist / chemist / electical engineer do the equivalent kinds of things? Thanks, and thanks for the wonderful stories! Arnold From Caipenghui_c at 163.com Fri Dec 7 14:27:41 2018 From: Caipenghui_c at 163.com (Caipenghui) Date: Fri, 07 Dec 2018 04:27:41 +0000 Subject: [TUHS] c's comment Message-ID: <1C1BB8D2-9535-4A6D-96E8-3792F14BCBAE@163.com> Why can't c language comments be nested? What is the historical reason for language design?Feeling awkward. Caipenghui From g.branden.robinson at gmail.com Fri Dec 7 18:31:56 2018 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 7 Dec 2018 03:31:56 -0500 Subject: [TUHS] c's comment In-Reply-To: <1C1BB8D2-9535-4A6D-96E8-3792F14BCBAE@163.com> References: <1C1BB8D2-9535-4A6D-96E8-3792F14BCBAE@163.com> Message-ID: <20181207083154.ucpd6qim3ghclfhn@crack.deadbeast.net> At 2018-12-07T04:27:41+0000, Caipenghui wrote: > Why can't c language comments be nested? What is the historical reason > for language design?Feeling awkward. I'm a callow youth compared to many on this list but I'll give it a try. My understanding is that it's not so much a historical reason[1] as a design choice motivated by ease of lexical analysis. As you may be aware, interpretation and compilation of programming languages often split into two parts: lexical analysis and semantic parsing. For instance, in int a = 1; A lexical analyzer breaks this input into several "tokens": * A type declarator; * A variable name; * An assignment operator; * A numerical literal (constant); * A statement separator; * A newline. Because we'll need it in a moment, here's another example: char s[] = "foobar"; /* initial value */ The tokens here are: * A type declarator; * A variable name; * An array indicator, which is really part of the type declarator (nobody said C was easy); * An assignment operator; * A string literal; * A statement separator; * A comment; * A newline. The lexical analyzer ("lexer") categorizes the tokens and hands them to a semantic parser to give them meaning and build a "machine" that will execute the code. (That "machine" is then translated into instructions that will run on a general-purpose computer, either in silicon or software, as we see in virtual machines like Java's.) There is such a thing as "lexerless parsing" which combines these two steps into one, but tokenization vs. semantic analysis remains a useful way to learn about how programs actually become things that execute. To answer your question, it is often desirable, because it can keep matters simple and comprehensible, to have a programming language that is easy to tokenize. Regular expressions are a popular means of doing tokenization, and the classic Unix tool "lex" has convenient support for this. (Its classic counterpart, a parser generator, is known as "yacc".) If you have experience with regular expressions you may realize that there are things that it is hard (or impossible[2]) for them to do. In classic C, there is only one type of comment. It starts with '/*' not inside a string literal, and continues until a '*/' is seen. It is a simple rule. If you wanted to nest comments, then the lexer would have to keep track of state--specifically, how many '/*'s it had seen, and pop one and only one of them for each '*/' it encounters. Furthermore, you have another design decision to make; should '*/' count to close a comment if it occurs inside a string literal inside a comment? People might comment out code containing string literals, after all, and then you have to worry about what those string literals might contain. Not only is it easier on a programmer's suffering brain to keep a programming language lexically simple--see the recent thread on the nightmare that is Fortran lexing, for instance--but it also affords easier opportunities for things that are not language implementations to lexically analyze your language. A tremendously successful example of this is "syntax" highlighting in text editors and IDE editor windows, which mark up your code with pretty colors to help you understand what you are doing. At this point you may see, incidentally, why it is more correct to call "syntax highlighting" lexical highlighting instead. A well-trained lexical analyzer can correctly tokenize and highlight: int a = 42; int a = "foobar"; But a syntax parser knows that a string literal cannot be assigned to a variable of integral type--that's a syntax error. It might be nice if our text editors would catch this kind of mistake, too, and for all I know Eclipse or NetBeans does. But doing so adds significantly more machinery to the development environment. In my experience, lexical highlighting largely forecloses major categories of fumble-fingers or rookie mistakes that used to linger until a compilation was attempted. Back in the old days (1993!) a freshman programmer on SunOS 4 would be subjected to a truly incomprehensible chain of compiler errors that arose from a single lexical mistake like a missing semicolon. With the arms race of helpful compiler diagnostics currently going between LLVM and GCC, and with our newfangled text editors doing lexical analysis and spraying terminal windows with avant-garde SGR escapes making things colorful, the learning process for C seems less savage than it used to be. If you'd like to learn more about lexing and parsing from a practical perspective, with the fun of implementing your own C-like language step-by-step which you can then customize to your heart's content, I recommend chapter 8 of: _The Unix Programming Environment_, by Kernighan and Pike, Prentice Hall 1984. I have to qualify that recommendation a bit because you will have to do some work to port traditional K&R C to ANSI C, and point out that these days people use flex and bison (or flex and byacc) instead of lex and yacc, but if you're a moderately seasoned C programmer who hasn't checked off the "written a compiler" box, K&P hold one's hand pretty well through the process. It's how I got my feet wet, it taught me a lot, and was less intimidating than Aho, Sethi, and Ullman. I will venture that programming languages that are simple to parse tend to be easier to learn and retain, and promote more uniformity in presentation. In spite of the feats on display in the IOCCC, and interminable wars over brace style and whitespace, we see less variation in source code layout in lexically simple languages than we (historically) did in Fortran. As much as I would love to have another example of a hard-to-lex language, I don't know one. As others pointed out here, Backus knew the revolution when he saw it, and swiftly chose the winning side. I welcome correction on any of the above points by the sages on this list. Regards, Branden [1] A historical choice would be the BCPL comment style of '//', reintroduced in C++ and eventually admitted into C with the C99 standard. An ahistorical choice would have been using '@@' for this purpose, for instance. [2] The identity between the CS regular languages and what can be recognized by "regular expression" implementations was broken long ago, and I am loath to make claims about what something like perlre can't do. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Caipenghui_c at 163.com Fri Dec 7 19:53:14 2018 From: Caipenghui_c at 163.com (Caipenghui) Date: Fri, 07 Dec 2018 09:53:14 +0000 Subject: [TUHS] c's comment In-Reply-To: <20181207083154.ucpd6qim3ghclfhn@crack.deadbeast.net> References: <1C1BB8D2-9535-4A6D-96E8-3792F14BCBAE@163.com> <20181207083154.ucpd6qim3ghclfhn@crack.deadbeast.net> Message-ID: <37B2A52F-43FC-4B2B-970F-170318D89135@163.com> 于 December 7, 2018 8:31:56 AM UTC, "G. Branden Robinson" 写到: > At 2018-12-07T04:27:41+0000, Caipenghui wrote: > > Why can't c language comments be nested? What is the historical > reason > > for language design?Feeling awkward. > > I'm a callow youth compared to many on this list but I'll give it a > try. > > My understanding is that it's not so much a historical reason[1] as a > design choice motivated by ease of lexical analysis. > > As you may be aware, interpretation and compilation of programming > languages often split into two parts: lexical analysis and semantic > parsing. > > For instance, in > > int a = 1; > > A lexical analyzer breaks this input into several "tokens": > * A type declarator; > * A variable name; > * An assignment operator; > * A numerical literal (constant); > * A statement separator; > * A newline. > > Because we'll need it in a moment, here's another example: > > char s[] = "foobar"; /* initial value */ > > The tokens here are: > * A type declarator; > * A variable name; > * An array indicator, which is really part of the type declarator > (nobody said C was easy); > * An assignment operator; > * A string literal; > * A statement separator; > * A comment; > * A newline. > > The lexical analyzer ("lexer") categorizes the tokens and hands them > to > a semantic parser to give them meaning and build a "machine" that will > execute the code. (That "machine" is then translated into > instructions > that will run on a general-purpose computer, either in silicon or > software, as we see in virtual machines like Java's.) > > There is such a thing as "lexerless parsing" which combines these two > steps into one, but tokenization vs. semantic analysis remains a > useful > way to learn about how programs actually become things that execute. > > To answer your question, it is often desirable, because it can keep > matters simple and comprehensible, to have a programming language that > is easy to tokenize. Regular expressions are a popular means of doing > tokenization, and the classic Unix tool "lex" has convenient support > for > this. (Its classic counterpart, a parser generator, is known as > "yacc".) > > If you have experience with regular expressions you may realize that > there are things that it is hard (or impossible[2]) for them to do. > > In classic C, there is only one type of comment. It starts with '/*' > not inside a string literal, and continues until a '*/' is seen. > > It is a simple rule. If you wanted to nest comments, then the lexer > would have to keep track of state--specifically, how many '/*'s it had > seen, and pop one and only one of them for each '*/' it encounters. > > Furthermore, you have another design decision to make; should '*/' > count > to close a comment if it occurs inside a string literal inside a > comment? People might comment out code containing string literals, > after all, and then you have to worry about what those string literals > might contain. > > Not only is it easier on a programmer's suffering brain to keep a > programming language lexically simple--see the recent thread on the > nightmare that is Fortran lexing, for instance--but it also affords > easier opportunities for things that are not language implementations > to > lexically analyze your language. > > A tremendously successful example of this is "syntax" highlighting in > text editors and IDE editor windows, which mark up your code with > pretty > colors to help you understand what you are doing. > > At this point you may see, incidentally, why it is more correct to > call > "syntax highlighting" lexical highlighting instead. > > A well-trained lexical analyzer can correctly tokenize and highlight: > > int a = 42; > int a = "foobar"; > > But a syntax parser knows that a string literal cannot be assigned to > a > variable of integral type--that's a syntax error. It might be nice if > our text editors would catch this kind of mistake, too, and for all I > know Eclipse or NetBeans does. But doing so adds significantly more > machinery to the development environment. In my experience, lexical > highlighting largely forecloses major categories of fumble-fingers or > rookie mistakes that used to linger until a compilation was attempted. > Back in the old days (1993!) a freshman programmer on SunOS 4 would be > subjected to a truly incomprehensible chain of compiler errors that > arose from a single lexical mistake like a missing semicolon. With > the > arms race of helpful compiler diagnostics currently going between LLVM > and GCC, and with our newfangled text editors doing lexical analysis > and > spraying terminal windows with avant-garde SGR escapes making things > colorful, the learning process for C seems less savage than it used to > be. > > If you'd like to learn more about lexing and parsing from a practical > perspective, with the fun of implementing your own C-like language > step-by-step which you can then customize to your heart's content, I > recommend chapter 8 of: > > _The Unix Programming Environment_, by Kernighan and Pike, > Prentice Hall 1984. > > I have to qualify that recommendation a bit because you will have to > do > some work to port traditional K&R C to ANSI C, and point out that > these > days people use flex and bison (or flex and byacc) instead of lex and > yacc, but if you're a moderately seasoned C programmer who hasn't > checked off the "written a compiler" box, K&P hold one's hand pretty > well through the process. It's how I got my feet wet, it taught me a > lot, and was less intimidating than Aho, Sethi, and Ullman. > > I will venture that programming languages that are simple to parse > tend > to be easier to learn and retain, and promote more uniformity in > presentation. In spite of the feats on display in the IOCCC, and > interminable wars over brace style and whitespace, we see less > variation > in source code layout in lexically simple languages than we > (historically) did in Fortran. As much as I would love to have > another > example of a hard-to-lex language, I don't know one. As others > pointed > out here, Backus knew the revolution when he saw it, and swiftly chose > the winning side. > > I welcome correction on any of the above points by the sages on this > list. > > Regards, > Branden > > [1] A historical choice would be the BCPL comment style of '//', > reintroduced in C++ and eventually admitted into C with the C99 > standard. An ahistorical choice would have been using '@@' for this > purpose, for instance. > > [2] The identity between the CS regular languages and what can be > recognized by "regular expression" implementations was broken long > ago, > and I am loath to make claims about what something like perlre can't > do. Thank you for your wonderful comments. I don't know what Dennis Ritchie thinks? Why not put the comment content in the first line of the comment? First example: /* hello world * * */ Second example: /* * hello world * */ To be honest, this is a bit uncomfortable for some perfectionists and looks uncomfortable. As Dennis said a word, "You can't understand this." Caipenghui From Caipenghui_c at 163.com Fri Dec 7 19:53:14 2018 From: Caipenghui_c at 163.com (Caipenghui) Date: Fri, 07 Dec 2018 09:53:14 +0000 Subject: [TUHS] c's comment In-Reply-To: <20181207083154.ucpd6qim3ghclfhn@crack.deadbeast.net> References: <1C1BB8D2-9535-4A6D-96E8-3792F14BCBAE@163.com> <20181207083154.ucpd6qim3ghclfhn@crack.deadbeast.net> Message-ID: <37B2A52F-43FC-4B2B-970F-170318D89135@163.com> 于 December 7, 2018 8:31:56 AM UTC, "G. Branden Robinson" 写到: > At 2018-12-07T04:27:41+0000, Caipenghui wrote: > > Why can't c language comments be nested? What is the historical > reason > > for language design?Feeling awkward. > > I'm a callow youth compared to many on this list but I'll give it a > try. > > My understanding is that it's not so much a historical reason[1] as a > design choice motivated by ease of lexical analysis. > > As you may be aware, interpretation and compilation of programming > languages often split into two parts: lexical analysis and semantic > parsing. > > For instance, in > > int a = 1; > > A lexical analyzer breaks this input into several "tokens": > * A type declarator; > * A variable name; > * An assignment operator; > * A numerical literal (constant); > * A statement separator; > * A newline. > > Because we'll need it in a moment, here's another example: > > char s[] = "foobar"; /* initial value */ > > The tokens here are: > * A type declarator; > * A variable name; > * An array indicator, which is really part of the type declarator > (nobody said C was easy); > * An assignment operator; > * A string literal; > * A statement separator; > * A comment; > * A newline. > > The lexical analyzer ("lexer") categorizes the tokens and hands them > to > a semantic parser to give them meaning and build a "machine" that will > execute the code. (That "machine" is then translated into > instructions > that will run on a general-purpose computer, either in silicon or > software, as we see in virtual machines like Java's.) > > There is such a thing as "lexerless parsing" which combines these two > steps into one, but tokenization vs. semantic analysis remains a > useful > way to learn about how programs actually become things that execute. > > To answer your question, it is often desirable, because it can keep > matters simple and comprehensible, to have a programming language that > is easy to tokenize. Regular expressions are a popular means of doing > tokenization, and the classic Unix tool "lex" has convenient support > for > this. (Its classic counterpart, a parser generator, is known as > "yacc".) > > If you have experience with regular expressions you may realize that > there are things that it is hard (or impossible[2]) for them to do. > > In classic C, there is only one type of comment. It starts with '/*' > not inside a string literal, and continues until a '*/' is seen. > > It is a simple rule. If you wanted to nest comments, then the lexer > would have to keep track of state--specifically, how many '/*'s it had > seen, and pop one and only one of them for each '*/' it encounters. > > Furthermore, you have another design decision to make; should '*/' > count > to close a comment if it occurs inside a string literal inside a > comment? People might comment out code containing string literals, > after all, and then you have to worry about what those string literals > might contain. > > Not only is it easier on a programmer's suffering brain to keep a > programming language lexically simple--see the recent thread on the > nightmare that is Fortran lexing, for instance--but it also affords > easier opportunities for things that are not language implementations > to > lexically analyze your language. > > A tremendously successful example of this is "syntax" highlighting in > text editors and IDE editor windows, which mark up your code with > pretty > colors to help you understand what you are doing. > > At this point you may see, incidentally, why it is more correct to > call > "syntax highlighting" lexical highlighting instead. > > A well-trained lexical analyzer can correctly tokenize and highlight: > > int a = 42; > int a = "foobar"; > > But a syntax parser knows that a string literal cannot be assigned to > a > variable of integral type--that's a syntax error. It might be nice if > our text editors would catch this kind of mistake, too, and for all I > know Eclipse or NetBeans does. But doing so adds significantly more > machinery to the development environment. In my experience, lexical > highlighting largely forecloses major categories of fumble-fingers or > rookie mistakes that used to linger until a compilation was attempted. > Back in the old days (1993!) a freshman programmer on SunOS 4 would be > subjected to a truly incomprehensible chain of compiler errors that > arose from a single lexical mistake like a missing semicolon. With > the > arms race of helpful compiler diagnostics currently going between LLVM > and GCC, and with our newfangled text editors doing lexical analysis > and > spraying terminal windows with avant-garde SGR escapes making things > colorful, the learning process for C seems less savage than it used to > be. > > If you'd like to learn more about lexing and parsing from a practical > perspective, with the fun of implementing your own C-like language > step-by-step which you can then customize to your heart's content, I > recommend chapter 8 of: > > _The Unix Programming Environment_, by Kernighan and Pike, > Prentice Hall 1984. > > I have to qualify that recommendation a bit because you will have to > do > some work to port traditional K&R C to ANSI C, and point out that > these > days people use flex and bison (or flex and byacc) instead of lex and > yacc, but if you're a moderately seasoned C programmer who hasn't > checked off the "written a compiler" box, K&P hold one's hand pretty > well through the process. It's how I got my feet wet, it taught me a > lot, and was less intimidating than Aho, Sethi, and Ullman. > > I will venture that programming languages that are simple to parse > tend > to be easier to learn and retain, and promote more uniformity in > presentation. In spite of the feats on display in the IOCCC, and > interminable wars over brace style and whitespace, we see less > variation > in source code layout in lexically simple languages than we > (historically) did in Fortran. As much as I would love to have > another > example of a hard-to-lex language, I don't know one. As others > pointed > out here, Backus knew the revolution when he saw it, and swiftly chose > the winning side. > > I welcome correction on any of the above points by the sages on this > list. > > Regards, > Branden > > [1] A historical choice would be the BCPL comment style of '//', > reintroduced in C++ and eventually admitted into C with the C99 > standard. An ahistorical choice would have been using '@@' for this > purpose, for instance. > > [2] The identity between the CS regular languages and what can be > recognized by "regular expression" implementations was broken long > ago, > and I am loath to make claims about what something like perlre can't > do. Thank you for your wonderful comments. I don't know what Dennis Ritchie thinks? Why not put the comment content in the first line of the comment? First example: /* hello world * * */ Second example: /* * hello world * */ To be honest, this is a bit uncomfortable for some perfectionists and looks uncomfortable. As Dennis said a word, "You can't understand this." Caipenghui From edouardklein at gmail.com Fri Dec 7 22:11:40 2018 From: edouardklein at gmail.com (Edouard KLEIN) Date: Fri, 7 Dec 2018 13:11:40 +0100 Subject: [TUHS] SDF's celebration of 50 years of UNIX Message-ID: Hi all, I haven't seen this on the list yet (apologies if I missed it): https://unix50.org/ You can get a shell in various historical version of UNIX. Enjoy ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Sat Dec 8 00:06:35 2018 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Fri, 7 Dec 2018 14:06:35 +0000 Subject: [TUHS] c's comment In-Reply-To: <20181207083154.ucpd6qim3ghclfhn@crack.deadbeast.net> References: <1C1BB8D2-9535-4A6D-96E8-3792F14BCBAE@163.com> <20181207083154.ucpd6qim3ghclfhn@crack.deadbeast.net> Message-ID: <20181207140635.nlwngnu5alrqnekn@h-174-65.A328.priv.bahnhof.se> On 7 Dec 2018 03:31 -0500, from g.branden.robinson at gmail.com (G. Branden Robinson): > Back in the old days (1993!) a freshman programmer on SunOS 4 would be > subjected to a truly incomprehensible chain of compiler errors that > arose from a single lexical mistake like a missing semicolon. That's around the time when I first started dabbling in C. One of the first things I figured out was that it was a great help to ignore all errors but the first one if I got a slew of errors during compilation; figure out how to fix that first one, recompile, and see if the other errors went away. Usually, they did. Thankfully, the programs I was working on at the time were small, so compilation time wasn't an issue. I think that advice was even in one of the books I was (trying to) follow. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “The most dangerous thought that you can have as a creative person is to think you know what you’re doing.” (Bret Victor) From mutiny.mutiny at india.com Sat Dec 8 01:02:11 2018 From: mutiny.mutiny at india.com (Donald ODona) Date: Fri, 7 Dec 2018 15:02:11 +0000 (UTC) Subject: [TUHS] SDF's celebration of 50 years of UNIX In-Reply-To: References: Message-ID: <807970192.93411.1544194931374.JavaMail.tomcat@india-live-be03> thanks a lot. That's really cool. Even edition zero is online! At 7 Dec 2018 12:21:00 +0000 (+00:00) from Edouard KLEIN : > Hi all, > > I haven't seen this on the list yet (apologies if I missed it): > > https://unix50.org/ > > You can get a shell in various historical version of UNIX. > > Enjoy ! From richard at inf.ed.ac.uk Sat Dec 8 01:01:25 2018 From: richard at inf.ed.ac.uk (Richard Tobin) Date: Fri, 7 Dec 2018 15:01:25 +0000 (GMT) Subject: [TUHS] c's comment In-Reply-To: Caipenghui's message of Fri, 07 Dec 2018 04:27:41 +0000 Message-ID: <20181207150125.D600B2283C8E@macaroni.inf.ed.ac.uk> > Why can't c language comments be nested? For comments that really are comments, what would be the point? For comments that are really removal of code - commenting out - there is a better mechanism, #if (or #ifdef), which does nest. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From paul.winalski at gmail.com Sat Dec 8 05:03:46 2018 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 7 Dec 2018 14:03:46 -0500 Subject: [TUHS] DEC compilers (was Happy birthday, John Backus!) In-Reply-To: References: Message-ID: On 12/5/18, Arrigo Triulzi wrote: > > I was wondering if anyone remembers the HPF compiler and the “pangolin” > parallel debugger which I used around 1994 on an Alpha farm connected with > FDDI. > IIRC the DEC HPF compiler used the COMPASS Fortran 90 parser and front end with GEM as the back end. That product lives on as the Intel Fortran compiler, but with Intel's back end instead of GEM. -Paul W. From doug at cs.dartmouth.edu Sat Dec 8 13:54:17 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 07 Dec 2018 22:54:17 -0500 Subject: [TUHS] C comments Message-ID: <201812080354.wB83sHQI000641@tahoe.cs.Dartmouth.EDU> Very little in language design is so contentious as comment conventions. C borrowed the PL/I convention, which had the virtue of being useful for both in-line and interlinear comments, and did not necessitate marking every line of a long comment. Nobody in the Unix lab had had much experience with the convention, despite having worked on Multics for which PL/I was the implementation language. And how did PL/I get the convention? It was proposed by Paul Rogoway at the first NPL (as it was then called) design-committee meeting that I attended. Apparently the topic had been debated for some while before and people were tired of the subject. Paul was more firmly committed to his new idea than others were to old options, so it carried more or less by default. Besides, there was a much more interesting topic on the agenda. Between the previous meeting and that one, George Radin had revamped the entire NPL proposal from mainly Fortran-like syntax to Algol-like. That was heady enough stuff to divert people's attention from comments. As for inexperiece. The comment conventions of previous languages had not fostered the practice of commenting out code. So that idea, which is the main impetus for nesting comments, was not in anybody's mind at the time. Had it been, nesting might well have carried the day. It probably could have been changed before 1980, but thereafter there were too many C compilers. Then standards introduced even more conservatism. Perhaps Ken can remember whether the notion was ever seriously considered. Doug From dave at horsfall.org Sun Dec 9 06:04:45 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 9 Dec 2018 07:04:45 +1100 (EST) Subject: [TUHS] Grace Hopper Message-ID: We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing Grace", she was a remarkable woman, both in computers and the Navy. She coined the term "debugging" when she extracted a moth from a set of relay contacts from a computer (the Harvard Mk I) and wrote "computer debugged" in the log, taping the deceased Lepidoptera in there as well. She was convinced that computers could be programmed in an English-like language and developed Flow-Matic, which in turn became, err, COBOL... She was posthumously awarded the Presidential Medal of Freedom in 2016 by Barack Obama. -- Dave From rminnich at gmail.com Sun Dec 9 13:31:07 2018 From: rminnich at gmail.com (ron minnich) Date: Sat, 8 Dec 2018 19:31:07 -0800 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: I got to meet her a couple times. I got a nanosecond from her twice and lost both of them. One story she told was of navigating tokyo using an international language ... Cobol. On Sat, Dec 8, 2018 at 12:06 PM Dave Horsfall wrote: > > We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing > Grace", she was a remarkable woman, both in computers and the Navy. She > coined the term "debugging" when she extracted a moth from a set of relay > contacts from a computer (the Harvard Mk I) and wrote "computer debugged" > in the log, taping the deceased Lepidoptera in there as well. She was > convinced that computers could be programmed in an English-like language > and developed Flow-Matic, which in turn became, err, COBOL... She was > posthumously awarded the Presidential Medal of Freedom in 2016 by Barack > Obama. > > -- Dave From arnold at skeeve.com Mon Dec 10 02:19:00 2018 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 09 Dec 2018 09:19:00 -0700 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: <201812091619.wB9GJ0qB028870@freefriends.org> Hi Dave. We went through this last year: Dave Horsfall wrote: > We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing > Grace", she was a remarkable woman, both in computers and the Navy. She > coined the term "debugging" According to https://en.wikipedia.org/wiki/Debugging#Origin_of_the_term: The terms "bug" and "debugging" are popularly attributed to Admiral Grace Hopper in the 1940s.[1] While she was working on a Mark II computer at Harvard University, her associates discovered a moth stuck in a relay and thereby impeding operation, whereupon she remarked that they were "debugging" the system. However, the term "bug", in the sense of "technical error", dates back at least to 1878 and Thomas Edison (see software bug for a full discussion). Similarly, the term "debugging" seems to have been used as a term in aeronautics before entering the world of computers. Indeed, in an interview Grace Hopper remarked that she was not coining the term[citation needed]. The moth fit the already existing terminology, so it was saved. A letter from J. Robert Oppenheimer (director of the WWII atomic bomb "Manhattan" project at Los Alamos, NM) used the term in a letter to Dr. Ernest Lawrence at UC Berkeley, dated October 27, 1944,[2] regarding the recruitment of additional technical staff. Please update your notes ... Thanks, Arnold From dave at horsfall.org Mon Dec 10 11:56:29 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 10 Dec 2018 12:56:29 +1100 (EST) Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! Message-ID: Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron), was born on this day in 1815; arguably the world's first computer programmer and a highly independent woman, she saw the potential in Charles Babbage's new-fangled invention. J.F.Ossanna was given unto us on this day in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. Who'ld've thought that two computer greats would share the same birthday? -- Dave From cym224 at gmail.com Mon Dec 10 12:22:02 2018 From: cym224 at gmail.com (Nemo) Date: Sun, 9 Dec 2018 21:22:02 -0500 Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! In-Reply-To: References: Message-ID: On 09/12/2018, Dave Horsfall wrote (in part): > > Who'ld've thought that two computer greats would share the same birthday? Are there at least 23 computer greats? > > -- Dave > From jacob.ritorto at gmail.com Tue Dec 11 08:05:18 2018 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Mon, 10 Dec 2018 17:05:18 -0500 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: Hi, I have an 11/45 I'm hoping will be running soon. I'd like to run 2.9BSD on it because it's the most highly functional system I know of that has "official hopes" to fit on such a restrictive machine. I've heard that it's really unlikely / tough to get a kernel built that'll run tcp (I care mostly about ftp and telnet) on such a small-memory-footprint machine. Is this true? Would anyone be willing to do a quick mentoring / working session with me to get me up to speed with the constraints I'm facing here and possibly give me a jump on making adjustments to build such a kernel if possible? thx jake P.S. There's kind of an implied challenge in the 2.11bsd setup docs, mentioning that "2.11BSD would probably only require a moderate amount of squeezing to fit on machines with less memory, but it would also be very unhappy about the prospect." I'm sure it's been attempted before, but would anyone be up to the challenge of trying to get that going with networking on an 18-bit-address-space pdp11? -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Dec 11 11:21:06 2018 From: clemc at ccc.com (Clem cole) Date: Mon, 10 Dec 2018 20:21:06 -0500 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: References: Message-ID: <940B149F-923C-4D12-B5D7-698DEA2E4F1F@ccc.com> It is going to be very difficult. If this is real HW you might try practicing configuration using simh. It will be faster and easy to play with until you have the config that meets your needs. That said for telnet and ftp you are going to need tcp. Btw. I might suggest setting up and Arduino, an RPi or the like and connect via serial ports to the 11. That way you might not need networking. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Dec 10, 2018, at 5:05 PM, Jacob Ritorto wrote: > > Hi, > I have an 11/45 I'm hoping will be running soon. > > I'd like to run 2.9BSD on it because it's the most highly functional system I know of that has "official hopes" to fit on such a restrictive machine. > > I've heard that it's really unlikely / tough to get a kernel built that'll run tcp (I care mostly about ftp and telnet) on such a small-memory-footprint machine. Is this true? > > Would anyone be willing to do a quick mentoring / working session with me to get me up to speed with the constraints I'm facing here and possibly give me a jump on making adjustments to build such a kernel if possible? > > thx > jake > > P.S. There's kind of an implied challenge in the 2.11bsd setup docs, mentioning that "2.11BSD would probably only require a moderate amount of squeezing to fit on machines with less memory, but it would also be very unhappy about the prospect." > > I'm sure it's been attempted before, but would anyone be up to the challenge of trying to get that going with networking on an 18-bit-address-space pdp11? > From gtaylor at tnetconsulting.net Tue Dec 11 11:55:19 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 10 Dec 2018 18:55:19 -0700 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: <940B149F-923C-4D12-B5D7-698DEA2E4F1F@ccc.com> References: <940B149F-923C-4D12-B5D7-698DEA2E4F1F@ccc.com> Message-ID: <4c0c11da-1223-ab19-72ec-4effeeb63127@spamtrap.tnetconsulting.net> On 12/10/18 6:21 PM, Clem cole wrote: > That said for telnet and ftp you are going to need tcp. What protocols did 2.9BSD support? Did it have NCP? Or was it strictly serial protocols like interactive terminals / UUCP? Would it be any easier to use an external NCP to TCP/IP gateway? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From jnc at mercury.lcs.mit.edu Tue Dec 11 12:11:35 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 10 Dec 2018 21:11:35 -0500 (EST) Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: <20181211021135.2013F18C08A@mercury.lcs.mit.edu> > From: Grant Taylor > What protocols did 2.9BSD support? Did it have NCP? NCP was turned off on 1 January, 1983. What do you think?a > Would it be any easier to use an external NCP to TCP/IP gateway? Such as? Noel From gtaylor at tnetconsulting.net Tue Dec 11 12:36:33 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 10 Dec 2018 19:36:33 -0700 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: <20181211021135.2013F18C08A@mercury.lcs.mit.edu> References: <20181211021135.2013F18C08A@mercury.lcs.mit.edu> Message-ID: <369b368b-9bac-827f-6383-37c62a6b87d7@spamtrap.tnetconsulting.net> On 12/10/18 7:11 PM, Noel Chiappa wrote: > NCP was turned off on 1 January, 1983. What do you think?a I don't know 2.9BSD's time frame (and did not look it up) so I can't say one way or the other. Based on your response I'm going to assume that it's not possible. > Such as? I'd have to go back and look, but I think I have read about an NCP and IP speaking host in the last few months. It may have been related to MULTICS. The idea is that it might be simpler to speak TCP/IP to such a machine and then connect from it to 2.9BSD, if 2.9BSD supported NCP. If the OPs goal is to get network connectivity on an 18-bit PDP, then that might be another option that doesn't require shoehorning TCP/IP into said PDP. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From imp at bsdimp.com Tue Dec 11 13:28:02 2018 From: imp at bsdimp.com (Warner Losh) Date: Mon, 10 Dec 2018 20:28:02 -0700 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: <369b368b-9bac-827f-6383-37c62a6b87d7@spamtrap.tnetconsulting.net> References: <20181211021135.2013F18C08A@mercury.lcs.mit.edu> <369b368b-9bac-827f-6383-37c62a6b87d7@spamtrap.tnetconsulting.net> Message-ID: On Mon, Dec 10, 2018 at 7:37 PM Grant Taylor via TUHS wrote: > On 12/10/18 7:11 PM, Noel Chiappa wrote: > > NCP was turned off on 1 January, 1983. What do you think?a > > I don't know 2.9BSD's time frame (and did not look it up) so I can't say > one way or the other. > > Based on your response I'm going to assume that it's not possible. > I kinda doubt it has good NCP support: it was released in November of 1983. > > Such as? > > I'd have to go back and look, but I think I have read about an NCP and > IP speaking host in the last few months. It may have been related to > MULTICS. > > The idea is that it might be simpler to speak TCP/IP to such a machine > and then connect from it to 2.9BSD, if 2.9BSD supported NCP. > > If the OPs goal is to get network connectivity on an 18-bit PDP, then > that might be another option that doesn't require shoehorning TCP/IP > into said PDP. > I'd get it running in simh, then move to real hardware. It's going to take a lot of elbow grease to make that work, I think. But I haven't looked in detail at things. Ultrix-11 is of similar vintage, and similar functionality and does boot on the 18-bit 11's. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Dec 11 14:42:07 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 10 Dec 2018 23:42:07 -0500 (EST) Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: <20181211044207.DE66618C08A@mercury.lcs.mit.edu> > From: Warner Losh > I kinda doubt it has good NCP support: it was released in November of > 1983. Wow, that far back? I'd assumed it was later (considerably later). Looking at the 2.9 networking stuff: https://minnie.tuhs.org//cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net it does indeed have _no_ NCP support. > I'd get it running in simh, then move to real hardware. Absolutely; running in an emulator is, I have found, a key step on getting an old OS running. I've found Ersatz-11 to be really good for PDP-11 emulation. > It's going to take a lot of elbow grease to make that work, I think. Indeed; part of the problem, if the goal is going to be 'run it on real hardware' is 'what network interface to use'. All the ARPANET interfaces are out. There are drivers there for Proteon, Ungermann-Bass, Xerox 3MB Ethernet, etc interfaces, but i) where you gonna find one, and ii) you'll need a router to connect up to most other things. There's a driver for the Interlan Ethernet interface, but AFAIK, those are non-existent. (If anyone has one they're willing to part with, please let me know!) DEC Ethernet interfaces are available, but i) only the QBUS ones are common, DEUNAs and DELUAs are almost impossible to find, that I've even seen, and ii) it would need a driver. > Ultrix-11 is of similar vintage, and similar functionality and does boot > on the 18-bit 11's. Yes, definitely worth looking at; I know it had TCP/IP (we had it on our -11/73 at Proteon), but I don't know which interfaces it supported; probably just the DEC ones (which, given the above, is not necessarily a Bad Thing). Noel From lars at nocrew.org Tue Dec 11 17:22:47 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 11 Dec 2018 07:22:47 +0000 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: <4c0c11da-1223-ab19-72ec-4effeeb63127@spamtrap.tnetconsulting.net> (Grant Taylor via TUHS's message of "Mon, 10 Dec 2018 18:55:19 -0700") References: <940B149F-923C-4D12-B5D7-698DEA2E4F1F@ccc.com> <4c0c11da-1223-ab19-72ec-4effeeb63127@spamtrap.tnetconsulting.net> Message-ID: <7wk1kg34u0.fsf@junk.nocrew.org> Grant Taylor wrote: > What protocols did 2.9BSD support? Did it have NCP? Or was it > strictly serial protocols like interactive terminals / UUCP? > > Would it be any easier to use an external NCP to TCP/IP gateway? It's actually a challenge to find *any* NCP software today. I think it would be interesting to recreate a small ARPANET. Here's a copy of "Network Unix" from Illinois: https://github.com/larsbrinkhoff/network-unix-v6 From clemc at ccc.com Wed Dec 12 01:28:32 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Dec 2018 10:28:32 -0500 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: <7wk1kg34u0.fsf@junk.nocrew.org> References: <940B149F-923C-4D12-B5D7-698DEA2E4F1F@ccc.com> <4c0c11da-1223-ab19-72ec-4effeeb63127@spamtrap.tnetconsulting.net> <7wk1kg34u0.fsf@junk.nocrew.org> Message-ID: Having had an extremely small part to play in 2.x story (some of my code is in there), I can offer a little of the history which hopefully you can glean some wisdom: re: NCP 1. The NCP code from Illinois, Rand *et al* - talked to the BBN-1822 interface. To my knowledge, no other networking interface was connected to that code base. - 1822 interface board are not be found - what would you connect the other end too? - Which means that you need to write an NCP driver for some other networking HW you can find for the Unibus 2. The only PDP-11 @ UCB that might have ever run the NCP code was Ing70 and that was long before 2BSD was released (much less 2.X) - As Noel pointed out, there is no NCP code in the 2.9 BSD distribution re: BSD 2.x & BSD 3.0 - 4.1 1. BSD 2.0 was the Seventh Edition changes from UCB for the PDP-11 (primarily what was running on the Cory Hall System) 2. BSD 3.0 was the first Vax release for "Ernie" in Evans. For all intents this is 2.0 + changes to the Kernel to allow V7 to run on a 780 with paging turned on [I don't remember if csh is default shell for root, it might be -> a user used to the way the 7th edition worked if presented with BSD 3.0 will find 'finger ROM/muscle memory' compatibility]. 3. BSD 4.1 was the widely released Vax distribution where Research Editions and BSD began to diverge. This was the system that convinced ARPA to make UNIX the supported OS for the next generation being VMS [which was being pushed by Stanford]. 4. Anything in the 2.X line post the original 2BSD tape was a group of mostly undergrads trying to move features from Ernie back to the Cory Hall system. These changes were then duplicated around campus (Math and Stat Depts as an example) who had purchased PDP-11s. The first big change was adding overlays for applications so larger address user programs like vi could keep running. But you tended to need at least sperate I/D (i.e. the 17th address bit as I like to call it). 5. Once the kernel overlay code (which I think was about 2.7) was added, it was pretty amazing how much the PDP-11 team did getting many of the later Vax kernel features supported, such a FFS, MIT's Job Control for the csh, new signals and even networking on some systems with 'enough' main memory [i.e. the 22BIT ones]. re: IP and BSD 1. UCBVAX (running BSD 4.1) was spliced to the Internet via IP/TCP using the BBN 1.0 IP/TCP release for the Vax by Eric Cooper 2. BSD 4.1a thru 4.2 were different versions of Vax work from the new CSRG team with new features for the Arpa community; including the creation of sockets and resplicing the BBN stack back the new kernel. So the issue you will run into is that to get all of the features that were crammed into BSD 2.X from the Vax, you need 'enough' memory to keep the overlays loaded. I do not believe the Kernel can swap itself out. Besides the kernel (i-space) code itself, space for I/O buffers becomes a huge issue (it always was before you added networking on the Research systems). To compound the issue, the networking code has its own memory scheme call 'mbufs' which came from the original BBN code [Rob wrote it to be portable to multiple OS's not just UNIX - the BBN distribution works on things like the HP/3000 also]. Space for all the buffers is going to be your problem. The less kernel code you have resident, the more room you have for applications code and I/O buffers. This is why I suggested that if you really want telnet and ftp to the PDP-11, you might be better off moving the networking stack out of the kernel and put a serial line (or even a DR-11B with a simple transfer protocol) via an Arduino or the like. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Dec 12 02:16:30 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 11 Dec 2018 11:16:30 -0500 (EST) Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: <20181211161631.0053818C089@mercury.lcs.mit.edu> > From: Clem Cole > This is why I suggested that if you really want telnet and ftp to the > PDP-11, you might be better off moving the networking stack out of the > kernel Really, the answer is that I need to get off my @ss and put the MIT V6+ system up (I have all the files, just need to get a round tuit). It has TCP/IP, but is it not all crammed into the kernel. And unlike the early BBN V6, it doesn't do TCP as a single process to which all the other client/server processes talk via IPC. Instead, the only thing in the kernel is inbound demuxing, and minimal outbound processing. (IIRC, outbound packets are copied into kernel buffers; an earlier version of the networking interface driver actually did do inbound and outbound DMA directly from buffers in the user's process, but only one process could use the network interface at a time.) The TCP code was a library that was built into the user process which did the server/client applications. (The servers which supported login, like FTP, needed to run as root, like the ordinary login, setuid'ing to the entered user-id.) I don't remember if we supported server Telnet, but I think we did. So we must have added PTY's of some sort, I'll have to check. Since the TCP was in the user process, we actually had a couple of different ones, depending on the application. Dave Clark had done a quick-n-dirty TCP on the Alto (in BCPL) which was only good for things like user Telnet, not for applications that sent a lot of data. We ported that one for the first TCP; we later did a 'high-speed bulk data' TCP, used for FTP, etc. I don't remember which one SMTP used. The whole thing worked _really_ well. Alas, I don't think anyone else picked up on it. The kernel code is not that large, it should even run on a /40, without overlays (although the number of disk buffers would probably get hit). And since the TCP is in user processes, it could all get swapped out, so it would run OK on machines without that much physical memory. The issue is going to be that it will need a new network interface driver, since I think the only driver ever done for it was for Pronet. And now we get back to the 'what interfaces are available' question. Doing a DEC driver would allow use of DEQNA's and DELQA's on QBUS machines, which would be optimal, since they are common. And people could bring up Unix with TCP/IP on -11/23's. But we'd have to add ARP (which I would do as a process, with only the IP->Ether address mapping table stored in the kernel). I wrote a really nice ARP for the C Gateway that could easily be used for that. Noel From clemc at ccc.com Wed Dec 12 02:26:41 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Dec 2018 11:26:41 -0500 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: <20181211161631.0053818C089@mercury.lcs.mit.edu> References: <20181211161631.0053818C089@mercury.lcs.mit.edu> Message-ID: IIRC is how UNET worked for V7. FWIW: UNE T was the original product from 3COM and somewhere I have the package with the Postmark as the 32nd of December - because 3Com had a requirement to ship by the end of the year to their VCs. At the last hours, Greg Shaw and Bruce Borden ran into a problem, so it shipped a day late [they obviously got their money]. Clem ᐧ On Tue, Dec 11, 2018 at 11:17 AM Noel Chiappa wrote: > > From: Clem Cole > > > This is why I suggested that if you really want telnet and ftp to the > > PDP-11, you might be better off moving the networking stack out of > the > > kernel > > Really, the answer is that I need to get off my @ss and put the MIT V6+ > system > up (I have all the files, just need to get a round tuit). > > > It has TCP/IP, but is it not all crammed into the kernel. And unlike the > early > BBN V6, it doesn't do TCP as a single process to which all the other > client/server processes talk via IPC. > > Instead, the only thing in the kernel is inbound demuxing, and minimal > outbound > processing. (IIRC, outbound packets are copied into kernel buffers; an > earlier > version of the networking interface driver actually did do inbound and > outbound > DMA directly from buffers in the user's process, but only one process > could use > the network interface at a time.) > > The TCP code was a library that was built into the user process which did > the > server/client applications. (The servers which supported login, like FTP, > needed to run as root, like the ordinary login, setuid'ing to the entered > user-id.) I don't remember if we supported server Telnet, but I think we > did. So we must have added PTY's of some sort, I'll have to check. > > Since the TCP was in the user process, we actually had a couple of > different > ones, depending on the application. Dave Clark had done a quick-n-dirty > TCP on > the Alto (in BCPL) which was only good for things like user Telnet, not for > applications that sent a lot of data. We ported that one for the first > TCP; we > later did a 'high-speed bulk data' TCP, used for FTP, etc. I don't remember > which one SMTP used. > > The whole thing worked _really_ well. Alas, I don't think anyone else > picked > up on it. > > > The kernel code is not that large, it should even run on a /40, without > overlays (although the number of disk buffers would probably get hit). And > since the TCP is in user processes, it could all get swapped out, so it > would > run OK on machines without that much physical memory. > > The issue is going to be that it will need a new network interface driver, > since I think the only driver ever done for it was for Pronet. And now we > get > back to the 'what interfaces are available' question. Doing a DEC driver > would > allow use of DEQNA's and DELQA's on QBUS machines, which would be optimal, > since they are common. And people could bring up Unix with TCP/IP on > -11/23's. > > But we'd have to add ARP (which I would do as a process, with only the > IP->Ether address mapping table stored in the kernel). I wrote a really > nice > ARP for the C Gateway that could easily be used for that. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Dec 12 02:57:07 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 11 Dec 2018 11:57:07 -0500 (EST) Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: <20181211165707.3A1E618C089@mercury.lcs.mit.edu> PS: > IIRC, outbound packets are copied into kernel buffers IDRC; according to the documentation, outbound packets are DMA'd directly from user memory. I have yet to read the code to verify this. > we must have added PTY's of some sort There is indeed a PTY driver; it has comments from BBN'ers who edited it, so perhaps we got it from BBN. > I don't remember which one SMTP used. The 'simple' TCP. > The whole thing worked _really_ well. Alas, I don't think anyone else > picked up on it. So I found a long list of people we sent tapes to. Oh well.... > The kernel code is not that large, it should even run on a /40, without > overlays (although the number of disk buffers would probably get hit). Well, maybe... Here is the output of 'size' on the last Unix image for that machine: 40560+3098+44594 It was a /45, so split I/D (no overlays, though). How much could be trimmed out of that, I'm not sure. Noel From nobozo at gmail.com Wed Dec 12 03:01:41 2018 From: nobozo at gmail.com (Jon Forrest) Date: Tue, 11 Dec 2018 09:01:41 -0800 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: <20181211165707.3A1E618C089@mercury.lcs.mit.edu> References: <20181211165707.3A1E618C089@mercury.lcs.mit.edu> Message-ID: <4de85973-b870-88fe-7e22-52de79a2f7c3@gmail.com> Too bad Keith Bostic isn't on this list. IIRC, he did a lot of the PDP-11 Unix integration work. Jon From lars at nocrew.org Wed Dec 12 03:21:55 2018 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 11 Dec 2018 17:21:55 +0000 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: (Clem Cole's message of "Tue, 11 Dec 2018 10:28:32 -0500") References: <940B149F-923C-4D12-B5D7-698DEA2E4F1F@ccc.com> <4c0c11da-1223-ab19-72ec-4effeeb63127@spamtrap.tnetconsulting.net> <7wk1kg34u0.fsf@junk.nocrew.org> Message-ID: <7wlg4w0yj0.fsf@junk.nocrew.org> Clem Cole wrote: > * 1822 interface board are not be found > * what would you connect the other end too? If you really wanted to, I guess you could use a UniBone running a simulation of the 1822 interface. From clemc at ccc.com Wed Dec 12 04:03:27 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Dec 2018 13:03:27 -0500 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: <20181211165707.3A1E618C089@mercury.lcs.mit.edu> References: <20181211165707.3A1E618C089@mercury.lcs.mit.edu> Message-ID: On Tue, Dec 11, 2018 at 11:57 AM Noel Chiappa wrote: > > we must have added PTY's of some sort > > There is indeed a PTY driver; it has comments from BBN'ers who edited it, > so > perhaps we got it from BBN. > Hmm, I could be mis remembering, but IIRC the original PTY driver goes back to the Rand and/or UofI for the NCP. I suspect BBN got it from the Bruce Borden's Rand distribution tape which was 74 or 75, I think. Named Piped were definiately a Rand-ism (they were originally called 'Rand Pipes') and were on that tape along with their Editor. It's too bad Greg is not here to ask. My memory and Noel may know by the IMP release dates, is that Rand was on connected before UofI. But there were issues and somethings were not 100% until the UofI NCP; which was the first really complete NCP for UNIX. I'm pretty sure that Greg's version went back to Bruce, as well as to BBN and Harvard and I would have assumes MIT also. I don't remember if the original Rand Pipes and PTYs were 5th or 6th edition originally. I'm fairly sure, UofI's NCP was 6th edition but think that Rand goes back to at least 5th if not 4th. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Dec 12 04:43:15 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 11 Dec 2018 13:43:15 -0500 (EST) Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: <20181211184316.014E618C089@mercury.lcs.mit.edu> > From: Clem Cole > I could be mis remembering No... :-) > IIRC the original PTY driver goes back to the Rand and/or UofI for the > NCP. Yup. I found a pty.c in the NCP system, it's clearly the ancestor (comments match): https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/dmr/pty.c > I suspect BBN got it from the Bruce Borden's Rand distribution tape Or possibly indirectly; my copy of the NCP came from NOSC via SRI. In addition to the one above, there are also these: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/dmr/misc/pty.c.ill https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/dmr/misc/pty.c.x Here: https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/dmr/pty.c is the BBN version, you can compare the them all. The MIT one is derived from the BBN one. > Named Piped were definiately a Rand-ism (they were originally called 'Rand Pipes') Well, _RAND_ called them 'ports': https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/doc/ipc/ports > But there were issues and somethings were not 100% until the UofI NCP; > which was the first really complete NCP for UNIX. Somewhere I found a document about the UofI code, I think they wrote it from scratch? Sorry, too lazy to look at it. See here: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC for links. Noel From clemc at ccc.com Wed Dec 12 04:51:35 2018 From: clemc at ccc.com (Clem Cole) Date: Tue, 11 Dec 2018 13:51:35 -0500 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: <20181211184316.014E618C089@mercury.lcs.mit.edu> References: <20181211184316.014E618C089@mercury.lcs.mit.edu> Message-ID: On Tue, Dec 11, 2018 at 1:43 PM Noel Chiappa wrote: > > > Named Piped were definiately a Rand-ism (they were originally called > 'Rand Pipes') > > Well, _RAND_ called them 'ports': > > https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/doc/ipc/ports > > Absolutely right... Rand Ports ... I stand corrected. Ports/Pipes -- same thing ... ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ritorto at gmail.com Wed Dec 12 11:20:51 2018 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Tue, 11 Dec 2018 20:20:51 -0500 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? In-Reply-To: References: <20181211184316.014E618C089@mercury.lcs.mit.edu> Message-ID: Man, this thread is really going! Excellent to see; thank you, all! I'm going to of course begin with what Clem and others suggested and do it on a simh 11/45 initially to try to get the needed tcp stuff compiled in. In looking at https://minnie.tuhs.org//cgi-bin/utree.pl?file=2.9BSD/usr/net/sys/net/NOTES , it's mentioned that >>> The 4K bytes of in address malloc space for dynamic structures is ok for an >>> I/D machine, but may be tight on a /34 or /23. Not sure yet whether this >>> will squeeze in. , so it feels like there's hope that it can be done. Lots of rereading and research for me to get to the point of completely understanding that NOTES file. Anyway, I'm going to try and get a simh instance up somewhere publicly accessible (will provide creds to those curious / interested) and see where I get stuck. Will be back with more questions! Thanks again for the initial engagement on this! jake P.S. I do have a Xylogics Annex "terminal server" that'd be a great front end to the real 11/45's serial lines as Clem suggested, but for me, the romance of having the machine truly speaking tcp as intended is one of the goals. I'll keep the Annex handy for when it's running SysV and other things that definitively can't speak tcp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Wed Dec 12 20:29:56 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 12 Dec 2018 11:29:56 +0100 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: <0432D5D3-2835-4288-AA4A-57AF3311F4F3@planet.nl> > I'm sure it's been attempted before, but would anyone be up to the > challenge of trying to get that going with networking on an > 18-bit-address-space pdp11? By coincidence I’m in the middle of a project to make V6 run with the Gurwitz TCP stack on a TI990 clone (which is pretty similar to a PDP11). It runs without separate I/D as two processes in about 100KB. The Gurwitz TCP stack was the reference implementation for the VAX that BBN did in 1981. It is in the THUS archive: https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP As documented in IEN168, the actual TCP processing happens in a separate kernel process, much like process 0 (swapper) in Unix itself. It turns out that the network process shares no data (other than the u struct) with the kernel proper and can be run in a separate address space. Just a few ’thunks’ are needed: open/read/write/close from the kernel to the TCP stack and sleep/wakeup in the other direction. A V6 Unix kernel runs in 48KB with buffers, the TCP stack with buffers needs about the same; both must remain resident - i.e. it ties up about 100KB of the 256KB core on a 18-bit machine. I suppose when using separate I/D it can run without thunks: the code size is about 25KB for both a minimal V6 kernel and the TCP stack, the rest is data. In my setup, network connectivity is via a SLIP interface. The Gurwitz code also has an Ethernet driver (note ARP was not invented yet), but I’m not using that. I’m happy to report that this 1981 tcp/ip code can still talk to current OSX and Linux machines. Just yesterday I got the setup working and I can run minimalist telnet connections etc. Alas it is not quite stable yet, it tends to crash after 5-10 minutes of use. The BBN reference implementation includes FTP and Telnet servers and clients which I think will still interoperate with current versions. As a final remark note that this BBN code uses an API that is almost unchanged from the API as used on NCP Unix. As compared to sockets this means that a listening connection is not a rendez-vous, but blocks until a connection is made (and then becomes an active connection, i.e. stops listening), and that there is no “select” type functionality. From jnc at mercury.lcs.mit.edu Thu Dec 13 00:14:18 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 12 Dec 2018 09:14:18 -0500 (EST) Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: <20181212141418.81F0718C084@mercury.lcs.mit.edu> > From: Paul Ruizendaal > project to make V6 run with the Gurwitz TCP stack on a TI990 clone > (which is pretty similar to a PDP11). Neat! > the code size is about 25KB for both a minimal V6 kernel and the TCP > stack, the rest is data. That's impressively small; the MIT V6+ with 'demux only in the kernel' was 40KB for the combined code (although I can't easily get separate figures for the networking part and the rest). > The Gurwitz code also has an Ethernet driver (note ARP was not invented > yet) How did it get Ethernet addresses? Noel From jnc at mercury.lcs.mit.edu Thu Dec 13 00:38:49 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 12 Dec 2018 09:38:49 -0500 (EST) Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: <20181212143849.9A97C18C084@mercury.lcs.mit.edu> > From: Paul Ruizendaal > a project to make V6 run ... on a TI990 clone Oh, about the basic part of this: did you start with a plain V6 distribution? So you've had to do all the machine language stuff from scratch (and modify things in C like estabur())? What are you using for a C compiler ? Is there one out there, or did you have to do your own? > In my setup, network connectivity is via a SLIP interface. Yeah, that's probably the way to go, to start with. Noel From pnr at planet.nl Thu Dec 13 03:55:17 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 12 Dec 2018 18:55:17 +0100 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: <3273DCC7-C127-4126-A5AD-C78104D3EEAB@planet.nl> > > the code size is about 25KB for both a minimal V6 kernel and the TCP > > stack, the rest is data. > > That's impressively small; the MIT V6+ with 'demux only in the kernel' was > 40KB for the combined code (although I can't easily get separate figures for > the networking part and the rest). I think my sentence was confusing: it is ~25KB each, so about 50KB combined. The original V6 kernel was about 29KB (says here https://www.tuhs.org//cgi-bin/utree.pl?file=V6). I've simplified the TTY driver, only support one type of disk driver, dropped shared text segments, dropped FP emulation. Remains about 25KB. Note that the SLIP is merely via a "super RAW" mode on the TTY driver, so I don't need to include the bulky IMP interface driver. Even at 30KB, the V6 kernel must have offered the best bang/buck ratio in the history of software, imho. > > The Gurwitz code also has an Ethernet driver (note ARP was not invented > > yet) > > How did it get Ethernet addresses? :^) See here: https://www.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet/netconf.c "Someday this will be generated from the configuration file." I think later it did, but I don't have that code. > > a project to make V6 run ... on a TI990 clone > > Oh, about the basic part of this: did you start with a plain V6 distribution? > So you've had to do all the machine language stuff from scratch (and modify > things in C like estabur())? > What are you using for a C compiler ? Is there one out there, or did you have > to do your own? I has been a journey. I started with the 2.11BSD compiler and ported that to the TI990 architecture (more precisely the 9995 chip, which is similar to a T11 chip). I debugged that to make XINU run, and then moved on to LSX (as recovered by the BK-UNIX project). Then I started with the V6 kernel from the TUHS website and made that work. Dave Pitts made it work on a real TI990 (he has a TI990/10 and a TI990/12 in working order). So, yes, I did bootstrap all the low level stuff from scratch. After a three year hiatus I resumed work on this, integrating the Gurwitz TCP stack. The journey is documented here: http://1587660.websites.xs4all.nl/cgi-bin/9995/timeline The network code is in a different tree, I'll move it over to the above tree over the weekend. Paul From ik at sjmulder.nl Sat Dec 15 00:34:03 2018 From: ik at sjmulder.nl (Sijmen J. Mulder) Date: Fri, 14 Dec 2018 15:34:03 +0100 Subject: [TUHS] Original Space Traveller source Message-ID: <1544798043.2270363.1609203984.3AEE7024@webmail.messagingengine.com> Hi all, A Reddit user is asking about Space Traveller: >I am an OpenBSD user and am interested in finding the original source code for Ken Thompson's Space Traveller. I have been searching the web for sometime now, but have sadly come up empty handed. Does anyone here by chance know where I could find a copy of it's source code? I am wanting to port it over to OpenBSD as a thank you to it's helpful and welcoming community. From ik at sjmulder.nl Sat Dec 15 00:35:16 2018 From: ik at sjmulder.nl (Sijmen J. Mulder) Date: Fri, 14 Dec 2018 15:35:16 +0100 Subject: [TUHS] Original Space Traveller source In-Reply-To: <1544798043.2270363.1609203984.3AEE7024@webmail.messagingengine.com> References: <1544798043.2270363.1609203984.3AEE7024@webmail.messagingengine.com> Message-ID: <1544798116.2270632.1609204336.0B0CC361@webmail.messagingengine.com> Op vr dec 14 2018, om 15:34 schreef Sijmen J. Mulder: > A Reddit user is asking about Space Traveller: > > >I am an OpenBSD user and am interested in finding the original source code for Ken Thompson's Space Traveller. I have been searching the web for sometime now, but have sadly come up empty handed. Does anyone here by chance know where I could find a copy of it's source code? I am wanting to port it over to OpenBSD as a thank you to it's helpful and welcoming community. Sorry for early send, misclicked. Thread here: https://www.reddit.com/r/unix/comments/a6583w/space_traveller/ Maybe someone on this list can help? Sijmen From pnr at planet.nl Sat Dec 15 11:54:49 2018 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 15 Dec 2018 02:54:49 +0100 Subject: [TUHS] 2.9bsd with networking on 18-bit possible? Message-ID: > The journey is documented here: > http://1587660.websites.xs4all.nl/cgi-bin/9995/timeline > > The network code is in a different tree, I'll move it over to the above tree over the weekend. Posted the network bit in the online repo; it's in the v6net directory. Also fixed the instability - it is quite satisfying to login to v6 from a 'nc' client on modern hardware. However, I also found that the BBN code from November 1981 is what is says on the can: beta. I'll move to the October 1982 code when I find some time. Paul PS, this is the 'server' that nc connects to: #define unchar unsigned char #define netaddr unsigned long #include "con.h" #include #include unsigned long ipaddr(w,x,y,z) int w,x,y,z; { unsigned long ip; ip = w; ip = (ip<<8)|x; ip = (ip<<8)|y; ip = (ip<<8)|z; return ip; } struct con con; void child(fd) int fd; { close(0); dup(fd); close(1); dup(fd); close(2); dup(fd); close(fd); execl("/bin/sh", "[net-sh]", 0); } main() { int i, n, sd; con.c_mode = CONTCP; con.c_fcon = ipaddr(192,168,1,114); con.c_lcon = ipaddr(172,16,0,2); con.c_fport = 0; con.c_lport = 4000; sd = open("/net", &con); printf("Connected\n", sd); child(sd); close(sd); } From wkt at tuhs.org Mon Dec 17 20:40:07 2018 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 17 Dec 2018 20:40:07 +1000 Subject: [TUHS] Test e-mail: minnie upgrade Message-ID: <20181217104007.GA15849@minnie.tuhs.org> All, I just upgraded minnie to Ubuntu 18.08 LTS. This is just a test e-mail to confirm that the mailing list software is stil working. Cheers, Warren From krewat at kilonet.net Thu Dec 20 03:14:29 2018 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 19 Dec 2018 12:14:29 -0500 Subject: [TUHS] vintage boards on ebay Message-ID: <922eb438-61dd-36b6-4039-06091992fd5f@kilonet.net> https://www.ebay.com/str/Zees-Fine-Finds A few old DEC boards/modules. I don't think there's anything PDP-11 related, but figured someone on this mailing list might find something interesting. art k. From ron at ronnatalie.com Thu Dec 20 06:10:08 2018 From: ron at ronnatalie.com (ron at ronnatalie.com) Date: Wed, 19 Dec 2018 15:10:08 -0500 Subject: [TUHS] vintage boards on ebay In-Reply-To: <922eb438-61dd-36b6-4039-06091992fd5f@kilonet.net> References: <922eb438-61dd-36b6-4039-06091992fd5f@kilonet.net> Message-ID: <395e01d497d6$d72f16d0$858d4470$@ronnatalie.com> And much if it is misidentified. The 548 board is not from a 402, but... get this, an IBM 548 interpreter. From aek at bitsavers.org Thu Dec 20 11:47:30 2018 From: aek at bitsavers.org (Al Kossow) Date: Wed, 19 Dec 2018 17:47:30 -0800 Subject: [TUHS] vintage boards on ebay In-Reply-To: <922eb438-61dd-36b6-4039-06091992fd5f@kilonet.net> References: <922eb438-61dd-36b6-4039-06091992fd5f@kilonet.net> Message-ID: <82e4da44-63ec-a78b-93a1-3716c18bb7e3@bitsavers.org> the most interesting is the PDP-6 ALU slice with Gordon Bell's autograph On 12/19/18 9:14 AM, Arthur Krewat wrote: > https://www.ebay.com/str/Zees-Fine-Finds > > A few old DEC boards/modules. > > I don't think there's anything PDP-11 related, but figured someone on this mailing list might find something interesting. > > art k. > From aek at bitsavers.org Thu Dec 20 11:46:43 2018 From: aek at bitsavers.org (Al Kossow) Date: Wed, 19 Dec 2018 17:46:43 -0800 Subject: [TUHS] Mt Xinu manual scanning finished Message-ID: http://bitsavers.org/pdf/mtXinu From reed at reedmedia.net Thu Dec 20 12:35:36 2018 From: reed at reedmedia.net (Jeremy C. Reed) Date: Wed, 19 Dec 2018 20:35:36 -0600 (CST) Subject: [TUHS] Mt Xinu manual scanning finished In-Reply-To: References: Message-ID: On Wed, 19 Dec 2018, Al Kossow wrote: > http://bitsavers.org/pdf/mtXinu Thanks for doing this. I see it says "with NFS" and I see various docs like getmntent, rnusers, yppasswd, getdirentries (like also in the UWisc4.3 edition). Does any of this have a summary of what was added to or changed from 4.3BSD? From davida at pobox.com Thu Dec 20 13:08:03 2018 From: davida at pobox.com (David Arnold) Date: Thu, 20 Dec 2018 14:08:03 +1100 Subject: [TUHS] Mt Xinu manual scanning finished In-Reply-To: References: Message-ID: <0F9F50D5-8595-442C-B4F1-68AE3B6F373A@pobox.com> > On 20 Dec 2018, at 12:46, Al Kossow wrote: > > http://bitsavers.org/pdf/mtXinu The first “unix” that I had serious amounts of time on was Minix 1.something (1.3, maybe?). This was about 1988, I think. There was a HP-UX machine (I think an HP-9000) at my university (QUT) that I had an account on, but it was busy, and hard to get a terminal, and I didn’t have dialup access as a lowly undergrad. So I got a hold of a stack of floppies, wiped my MS-DOS install, and built myself a Minix system on my i286 PC. In flicking through the Mt Xinu manuals, I’m struck by the fact that my knowledge of basic Unix utilities is, to this day, largely limited to what was in Minix. jot, rs, various others are foreign to me — and they’re the ones not in Minix v1. I seem to recall spending many, many hours poring over man pages, reading the docs cover to cover, as I explored the system. I guess I should read these now … :-) Thanks Al, d From wobblygong at gmail.com Fri Dec 21 19:39:21 2018 From: wobblygong at gmail.com (Wesley Parish) Date: Fri, 21 Dec 2018 22:39:21 +1300 Subject: [TUHS] Travesty Generators Message-ID: Hi One of the reasons I enjoy emacs is Meta-X dissociated-press, which turns the most turgid bureaucratic prose into something truly worth reading. Has anybody documented or provided a timeline for the emergence of the Travesty Generator? (I know that text processing was one of the major focuses of university research, as opposed to the more utilitarian focuses of the scientific computing or corporate record keeping areas. One early CompSci book I got from a second-hand booksellers in Christchurch before the earthquakes, had a nice section on SNOBOL.) So who wrote the first Travesty Generator/s? From will.senn at gmail.com Mon Dec 24 04:17:33 2018 From: will.senn at gmail.com (Will Senn) Date: Sun, 23 Dec 2018 12:17:33 -0600 Subject: [TUHS] Pdp11 implementations on fpga in 2018 Message-ID: <04B21E3F-9437-4A1A-AA29-31A04D1318D0@gmail.com> Hi folks, This is a little sideways from on topic, but no too far. Is there a good open source implementation of a pdp11 for fpga in verilog/vhdl that works well for Unix v6+? Google turns up a number, but I’m hoping some of y’all have actual experience with one that you could recommend over others. I’m financially challenged so it’s a requirement that it run on cheap fpga’s not some Tesla prototype :) Regards, Will Sent from my iPhone From wkt at tuhs.org Mon Dec 24 06:02:11 2018 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 24 Dec 2018 06:02:11 +1000 Subject: [TUHS] Archive(s) of old academic papers? Message-ID: <20181223200211.GA16923@minnie.tuhs.org> Hi all, also an off-topic question. I got a private e-mail from a person who has been trying to collect old academic papers from the CompSci/IT field. Does anybody know of an existing archive for old CS/IT papers? Thanks, Warren From joe at via.net Mon Dec 24 07:53:07 2018 From: joe at via.net (joe mcguckin) Date: Sun, 23 Dec 2018 13:53:07 -0800 Subject: [TUHS] Archive(s) of old academic papers? In-Reply-To: <20181223200211.GA16923@minnie.tuhs.org> References: <20181223200211.GA16923@minnie.tuhs.org> Message-ID: <70FB0A33-8061-4DA4-9806-CE163FCC473D@via.net> sci-hub. I recently was looking for a bunch of papers - some as old as 40 years. sci-hub had them all. This is fantastic. My old modus operandi of making a list and going to the Stanford Math library to browse, copy or download them using Stanford's electronic subscription to the desired journals no longer works as: 1) The math library no longer exists 2) The trend at Stanford is to house paper books and journals off-site in Livermore somewhere. All the libraries seem to be going paperless, err, bookless... 3) They only seem to subscribe to a subset of ACM, SIAM, etc. online Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Dec 23, 2018, at 12:02 PM, Warren Toomey wrote: > > Hi all, also an off-topic question. I got a private e-mail from a person > who has been trying to collect old academic papers from the CompSci/IT > field. Does anybody know of an existing archive for old CS/IT papers? > > Thanks, Warren From gtaylor at tnetconsulting.net Wed Dec 26 10:49:49 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 25 Dec 2018 17:49:49 -0700 Subject: [TUHS] NFS & Kerberos woes... Message-ID: Do any fellow TUHS subscribers have any experience with NFS, particularly in combination with Kerberos authentication? I'm messing with something that is making me think that Kerberos authentication (sec=krb5{,i,p}) usurps no_root_squash. Meaning that root can't access files owned by other users with go-rwx. Almost as if no_root_squash wasn't configured on the export. Does anyone have a spare bone that they would be willing to throw my way? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Wed Dec 26 12:01:19 2018 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 25 Dec 2018 18:01:19 -0800 Subject: [TUHS] NFS & Kerberos woes... In-Reply-To: References: Message-ID: <20181226020119.GF18199@mcvoy.com> I'm an NFS guy, learned it a bit at uwisc and then a lot more at Sun. But Sun didn't do the Kerberos stuff, at least while I was there. Didn't Kerberos come from MIT? If so, I bet anything that Ted Ts'o would know the details. My guess is it was part of project athena and I think that overlaps with Ted. Yo, Ted, Merry Christmas, what about this Kerberos authentication stuff? :) On Tue, Dec 25, 2018 at 05:49:49PM -0700, Grant Taylor via TUHS wrote: > Do any fellow TUHS subscribers have any experience with NFS, particularly in > combination with Kerberos authentication? > > I'm messing with something that is making me think that Kerberos > authentication (sec=krb5{,i,p}) usurps no_root_squash. > > Meaning that root can't access files owned by other users with go-rwx. > Almost as if no_root_squash wasn't configured on the export. > > Does anyone have a spare bone that they would be willing to throw my way? > > > > -- > Grant. . . . > unix || die > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From tytso at mit.edu Wed Dec 26 14:49:20 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Tue, 25 Dec 2018 23:49:20 -0500 Subject: [TUHS] NFS & Kerberos woes... In-Reply-To: <20181226020119.GF18199@mcvoy.com> References: <20181226020119.GF18199@mcvoy.com> Message-ID: <20181226044920.GB4158@mit.edu> On Tue, Dec 25, 2018 at 06:01:19PM -0800, Larry McVoy wrote: > I'm an NFS guy, learned it a bit at uwisc and then a lot more at Sun. > But Sun didn't do the Kerberos stuff, at least while I was there. > > Didn't Kerberos come from MIT? If so, I bet anything that Ted Ts'o > would know the details. My guess is it was part of project athena > and I think that overlaps with Ted. Yo, Ted, Merry Christmas, > what about this Kerberos authentication stuff? :) So the way Kerberized NFS was used at Project Athena was that after you authenticated as some Kerberos principal, say, such as "tytso at ATHENA.MIT.EDU", there was mapping function/database which would map that Kerberos authentication to a user id --- say, 15806. On the Athena client, at login time /bin/login (or a PAM module) would do a Hesiod lookup for (tytso, passwd) in the athena.mit.edu Hesiod domain. This translate to a DNS lookup for class=HS, type=TXT, for tytso.passwd.ns.athena.mit.edu: {/usr/projects/xfstests-bld/build-64} (master) 1067% hesinfo -lb tytso passwd hes_to_bind(tytso, passwd) expands to tytso.passwd.ns.athena.mit.edu which resolves to tytso:*:15806:101:Theodore Y. Ts'o,E40-343,38091,:/mit/tytso:/bin/athena/tcsh Because of the Kerberos authentication for tytso at ATHENA.MIT.EDU, the Kerberos-authenticated NFS server would map all NFS requests (regardless of the uid/gid in the NFS RPC) to the uid in the mapping database --- in my case, 15806. The mapping database and the Hesiod DNS zone files are created from administration management system called Moira. This is important, because access checks are going to both be done on the client side, as well as the server side. And the Kerberos NFS mapping only affects the uid/gid in the used for server-side access control checks (e.g., it replaces the uid/gid in the NFS RPC request). It does *not* affect the uid/gid returned by stat(2) / getattr request. All of this is saying, yes, of *course* Kerberos authenticated NFS turns off no_root_squash. The whole point of using Kerberos authentication is so the server is willing to blindly trust the uid/gid asserted by the client and grant access on that basis. If you are going to allow the the NFS server to go, "Hurr, durr... you are claiming a uid of 0 --- OK! You can do whatever you want." ---- why bother with Kerberos authentication at all in the fairst place!?! Now, I believe you *could* configure in the mapping database that authentication from some Kerberos principal such as "tytso/root at ATHENA.MIT.EDU" or "host/cwcc.mit.edu at ATHENA.MIT.EDU" (you can use service principals from a Kerberos keytab as a client principal for the purposes of machine authentication) should be mapped to uid 0. This wasn't somethingh we generally did, though, since the general model we used is that root on the local client should mean _nothing_. Indeed, on Public Athena workstations, the assumption was that anyone could get root (since MIT students had physical access, and there's nothing quite as dangerous than a bored MIT student). Hence, during thet time when I was an undergraduate, the public root password as "mrroot". Anyone could su to root thus eliminating the challenge of "breaking root". As a result, we never tried to give uid 0 special server-side permissions, since it went against the model that IP address-based authentication and blind-faith trust in assertions of uid==0 from NFS clients as just being silly. Cheers, - Ted From gtaylor at tnetconsulting.net Wed Dec 26 18:45:21 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 26 Dec 2018 01:45:21 -0700 Subject: [TUHS] NFS & Kerberos woes... In-Reply-To: <20181226044920.GB4158@mit.edu> References: <20181226020119.GF18199@mcvoy.com> <20181226044920.GB4158@mit.edu> Message-ID: First: Thank you for the very detailed response Ted. I hope that my response is worth while. On 12/25/18 9:49 PM, Theodore Y. Ts'o wrote: > So the way Kerberized NFS was used at Project Athena was that > after you authenticated as some Kerberos principal, say, such as > "tytso at ATHENA.MIT.EDU", there was mapping function/database which would > map that Kerberos authentication to a user id --- say, 15806. Okay. My (limited) understanding is that I have that functionality with Kerberos (for authentication) and LDAP (for directory information). Please correct me if that's incorrect. > On the Athena client, at login time /bin/login (or a PAM module) > would do a Hesiod lookup for (tytso, passwd) in the athena.mit.edu > Hesiod domain. This translate to a DNS lookup for class=HS, type=TXT, > for tytso.passwd.ns.athena.mit.edu: It's my understanding that Project Athena used Hesiod data stored in DNS in place of what I'm storing in LDAP. That is both Hesiod and LDAP store information, meta data, about accounts, which is typically stored in /etc/passwd. The important distinction is that password / authentication information is decidedly NOT stored in DNS or LDAP. Instead, authentication is solely in the Kerberos realm. (Pun is somewhat intended.) Is that correct? > {/usr/projects/xfstests-bld/build-64} (master) > 1067% hesinfo -lb tytso passwd > hes_to_bind(tytso, passwd) expands to > tytso.passwd.ns.athena.mit.edu > which resolves to > tytso:*:15806:101:Theodore Y. Ts'o,E40-343,38091,:/mit/tytso:/bin/athena/tcsh I'm taking that to be the Hesiod equivalent of "getent passwd tytso". Is that correct? > Because of the Kerberos authentication for tytso at ATHENA.MIT.EDU, the > Kerberos-authenticated NFS server would map all NFS requests (regardless > of the uid/gid in the NFS RPC) to the uid in the mapping database --- > in my case, 15806. If I'm understanding you correctly, you're stating that Kerberos authenticated NFS uses the uid & gid learned via Kerberos authentication and ignoring the purported uid & gid from the NFS RPC. This makes sense. It also removes the need to trust the NFS RPC which was inherently dependent on trusting the NFS client machine. > This is important, because access checks are going to both be done on > the client side, as well as the server side. I hadn't thought about this before. I guess client side might be an optimization for clients. But I would only trust server side. (Likewise with client side JavaScript compared to server side $LanguageDejure.) > And the Kerberos NFS mapping only affects the uid/gid in the used for > server-side access control checks (e.g., it replaces the uid/gid in the > NFS RPC request). ACK > It does *not* affect the uid/gid returned by stat(2) / getattr request. Okay. I'm going to have to think about that more. I wonder if that means that my "getent passwd" method mentioned above is flawed. > All of this is saying, yes, of *course* Kerberos authenticated NFS turns > off no_root_squash. Hum. I have no problem accepting that Kerberized NFS wants to not blindly trust the uid & gid that the NFS client claims. But I would think that an authenticated root account would satisfy Kerberized NFS and allow uid & gid 0. As in we trust the Kerberos authentication, and retrieved uid & gid 0 from the directory (Hesiod or LDAP). Thus I would expect a trusted uid & gid of 0 to be allowed to access files despite what the file system permissions say. Though, as sure as I type that, I wonder about "an authenticated root account". As in are there multiple? Or is there a common shared single root account with uid & gid 0. - I don't know what should be done there. I think a single common root account would match a single common tytso account. But I can see the security advantage of not having a single common root account. The use case that I'm working with, which works perfectly fine with sec=sys. /home is mounted off of an export with no_root_squash. So, sshd running as root can access /home/tytso/.ssh/authorized_keys. But, this doesn't seem to work when I use sec=krb5{,i,p}. It seems as if root can't access files that standard file system permissions prohibit access to. As if root_squash was in effect. I /think/ that root has a valid Kerberos TGT, thus can properly authenticate to NFS and as such /should/ be able to access /home/tytso/.ssh/authorized_keys. Perhaps I am making a bad assumption in thinking the system's keytab is sufficient to allow root to authenticate to Kerberos. - I'm relatively new to Kerberos and still learning the ropes. > The whole point of using Kerberos authentication is so the server is > willing to blindly trust the uid/gid asserted by the client and grant > access on that basis. If you are going to allow the the NFS server to go, > "Hurr, durr... you are claiming a uid of 0 --- OK! You can do whatever > you want." ---- why bother with Kerberos authentication at all in the > fairst place!?! I'm not trying to blindly have root access files that it doesn't have permission to. I'm perfectly happy to have root authenticate to Kerberos and have the proper tickets to satisfy NFS. I /thought/ I was doing exactly that. Perhaps I'm mistaken. > Now, I believe you *could* configure in the mapping database > that authentication from some Kerberos principal such as > "tytso/root at ATHENA.MIT.EDU" or "host/cwcc.mit.edu at ATHENA.MIT.EDU" (you > can use service principals from a Kerberos keytab as a client principal > for the purposes of machine authentication) should be mapped to uid 0. Hum. The idea of mapping host/$FQDN@$REALM to uid 0 sounds like it might be part of what I /think/ I am wanting and that I should do some more reading about it. I could also be mistaken in thinking that I want (properly authenticated) root to have access like I'm describing. > This wasn't somethingh we generally did, though, since the general > model we used is that root on the local client should mean _nothing_. > Indeed, on Public Athena workstations, the assumption was that anyone > could get root Understandable. That makes sense. Especially in that situation. This is also one of the reasons that I'm questioning if my logic about allowing an authenticated root having access. But, I'm not (yet) aware of another way to enable sshd, running as root, to access ~/.ssh/authorized_keys files from an NFS export. I'd be happy to hear about other ways. Aside: I'm actually authenticating to SSH using Kerberos via GSSAPI. I'm wanting access to ~/.ssh/authorized_keys file for another PAM module for something else. (This works perfectly fine with sec=sys or local non-NFS files.) > (since MIT students had physical access, and there's nothing quite as > dangerous than a bored MIT student). LOL I get it. > Hence, during thet time when I was an undergraduate, the public root > password as "mrroot". Anyone could su to root thus eliminating the > challenge of "breaking root". Ya. Knowing the ""secret really take the wind out of the sails of trying to learn the ""secret. > As a result, we never tried to give uid 0 special server-side permissions, > since it went against the model that IP address-based authentication > and blind-faith trust in assertions of uid==0 from NFS clients as just > being silly. I think I get the reason why you say that and why you did what you did. That just leaves me looking for another solution to needing to access ~/.ssh/authorized_keys with 0600 permissions. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Wed Dec 26 18:48:42 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 26 Dec 2018 01:48:42 -0700 Subject: [TUHS] NFS & Kerberos woes... In-Reply-To: <20181226020119.GF18199@mcvoy.com> References: <20181226020119.GF18199@mcvoy.com> Message-ID: <9a102767-bff2-c6e6-d585-23cac100d715@spamtrap.tnetconsulting.net> On 12/25/18 7:01 PM, Larry McVoy wrote: > I'm an NFS guy, learned it a bit at uwisc and then a lot more at Sun. > But Sun didn't do the Kerberos stuff, at least while I was there. That sort of surprises me. I guess I had assumed that NFS was Sun centric. Though I shouldn't be surprised that someone else stood on Sun's shoulders and extended NFS. Especially when (I think that) Kerberos MIT centric. > Didn't Kerberos come from MIT? If so, I bet anything that Ted Ts'o > would know the details. My guess is it was part of project athena and > I think that overlaps with Ted. Yo, Ted, Merry Christmas, what about > this Kerberos authentication stuff? :) Thank you for the response Larry. It's amazing what can be learned by participating in the TUHS mailing list & community. :-D -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From emu at e-bbes.com Wed Dec 26 23:43:51 2018 From: emu at e-bbes.com (emanuel stiebler) Date: Wed, 26 Dec 2018 08:43:51 -0500 Subject: [TUHS] Pdp11 implementations on fpga in 2018 In-Reply-To: <04B21E3F-9437-4A1A-AA29-31A04D1318D0@gmail.com> References: <04B21E3F-9437-4A1A-AA29-31A04D1318D0@gmail.com> Message-ID: <77412cac-ff78-0b16-0f21-e72e2fa77bea@e-bbes.com> On 2018-12-23 13:17, Will Senn wrote: > Hi folks, > > This is a little sideways from on topic, but no too far. Is there a good open source implementation of a pdp11 for fpga in verilog/vhdl that works well for Unix v6+? Google turns up a number, but I’m hoping some of y’all have actual experience with one that you could recommend over others. I’m financially challenged so it’s a requirement that it run on cheap fpga’s not some Tesla prototype :) I know of two: https://opencores.org/projects/w11 and http://pdp2011.sytse.net/wordpress/pdp-11/ Both projects are so old, they should run on FPGA boards you probably could get for free ... Have fun! From will.senn at gmail.com Thu Dec 27 02:04:10 2018 From: will.senn at gmail.com (Will Senn) Date: Wed, 26 Dec 2018 10:04:10 -0600 Subject: [TUHS] Pdp11 implementations on fpga in 2018 In-Reply-To: <77412cac-ff78-0b16-0f21-e72e2fa77bea@e-bbes.com> References: <04B21E3F-9437-4A1A-AA29-31A04D1318D0@gmail.com> <77412cac-ff78-0b16-0f21-e72e2fa77bea@e-bbes.com> Message-ID: <8B9AF6DF-94D1-4278-B734-B926302D11D2@gmail.com> Sent from my iPhone > On Dec 26, 2018, at 7:43 AM, emanuel stiebler wrote: > >> On 2018-12-23 13:17, Will Senn wrote: >> Hi folks, >> >> This is a little sideways from on topic, but no too far. Is there a good open source implementation of a pdp11 for fpga in verilog/vhdl that works well for Unix v6+? Google turns up a number, but I’m hoping some of y’all have actual experience with one that you could recommend over others. I’m financially challenged so it’s a requirement that it run on cheap fpga’s not some Tesla prototype :) > > I know of two: > > https://opencores.org/projects/w11 > > and > > http://pdp2011.sytse.net/wordpress/pdp-11/ > > > Both projects are so old, they should run on FPGA boards you probably > could get for free ... > > Have fun! I need to find those free boards :). Those are the best sites, I’ve seen, too. I’m not entirely sure why I’m wanting to do the fpga thing when simh seems to work just fine for everything I’ve ever wanted to use it for, but having a switch controlled machine that can be put on a shelf and taken off and plugged in and run is appealing. Not quite as appealing as having a PiDP-11, but for those of us on a budget, it seems right somehow! Will From reed at reedmedia.net Thu Dec 27 07:49:24 2018 From: reed at reedmedia.net (reed at reedmedia.net) Date: Wed, 26 Dec 2018 15:49:24 -0600 (CST) Subject: [TUHS] Usenix: no official Unix 50th celebration, (yet) In-Reply-To: References: <20180826003127.GA18905@minnie.tuhs.org> Message-ID: I thought I read a different email saying that there will be a track about the 50th anniversary. But cannot find any details or reference to it now. Does anyone have information about Unix 50th celebration(s)? Is it time for paper submissions? ... From norman at oclsc.org Thu Dec 27 08:59:28 2018 From: norman at oclsc.org (Norman Wilson) Date: Wed, 26 Dec 2018 17:59:28 -0500 Subject: [TUHS] Usenix: no official Unix 50th celebration, (yet) Message-ID: <1545865172.9894.for-standards-violators@oclsc.org> I thought I read a different email saying that there will be a track about the 50th anniversary. But cannot find any details or reference to it now. Does anyone have information about Unix 50th celebration(s)? Is it time for paper submissions? ... ==== If you mean for the 2019 USENIX Annual Technical Conference, the CFP is https://www.usenix.org/conference/atc19/call-for-papers The submission deadline is about three weeks away, on 2019-01-10. I see nothing explicit about a UNIX 50th celebration, alas. At least one program-committee member is on this list; perhaps more information will appear. Or there's a contact address for the program co-chairs on the web page cited above. Norman Wilson Toronto ON From clemc at ccc.com Thu Dec 27 11:16:45 2018 From: clemc at ccc.com (Clem cole) Date: Wed, 26 Dec 2018 20:16:45 -0500 Subject: [TUHS] Usenix: no official Unix 50th celebration, (yet) In-Reply-To: <1545865172.9894.for-standards-violators@oclsc.org> References: <1545865172.9894.for-standards-violators@oclsc.org> Message-ID: <62438659-505C-42BF-B59A-C1D8F07DCD12@ccc.com> Thanks. That’s partly right - the track is a room usenix is providing but they are not sponsoring a larger party. We are taking submissions and have been for a bit. But we are working the living computer history folks in Seattle and are trying to do something larger at their site during one night of ATC. I’m not near a real computer for abit. I’ll send a more detailed message hopefully tomorrow I have better connectivity. Clem Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Dec 26, 2018, at 5:59 PM, Norman Wilson wrote: > > I thought I read a different email saying that there will be a track > about the 50th anniversary. But cannot find any details or reference to > it now. > > Does anyone have information about Unix 50th celebration(s)? > > Is it time for paper submissions? ... > > ==== > > If you mean for the 2019 USENIX Annual Technical Conference, > the CFP is > > https://www.usenix.org/conference/atc19/call-for-papers > > The submission deadline is about three weeks away, on > 2019-01-10. > > I see nothing explicit about a UNIX 50th celebration, alas. > > At least one program-committee member is on this list; perhaps > more information will appear. Or there's a contact address > for the program co-chairs on the web page cited above. > > Norman Wilson > Toronto ON From gtaylor at tnetconsulting.net Thu Dec 27 16:24:00 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 26 Dec 2018 23:24:00 -0700 Subject: [TUHS] =?utf-8?b?TkZTICYgS2VyYmVyb3Mgd29lcy4uLiDigJQgU09MVkVE?= In-Reply-To: References: Message-ID: <357ec30a-5fe3-80d4-ef04-2c8d336a46cc@spamtrap.tnetconsulting.net> On 12/25/18 5:49 PM, Grant Taylor via TUHS wrote: > Do any fellow TUHS subscribers have any experience with NFS, > particularly in combination with Kerberos authentication? After much toil and tribulation, I've managed to get things working. > I'm messing with something that is making me think that Kerberos > authentication (sec=krb5{,i,p}) usurps no_root_squash. I've found that no_root_squash is still equally as applicable in Kerberized NFS as it is in non-Kerberized NFS. no_root_squash actually still does the same thing in Kerberized NFS. I figured out (by grinding through possible options) that I needed to do the following: Add a new principal, root/host.sub.domain.tld, and add it to host's (system wide) keytab file. I also needed to configure and enable translations in the /etc/idmapd.conf file /on/ /the/ /NFS/ /server/. --8<-- [Static] root/host.sub.domain.tld = root [Translation] GSS-Methods = static,nsswitch -->8-- Hopefully this will help someone trying to do something similar in the future. Now, services running as root (sshd) are able to read files (authorized_keys) that root doesn’t have permission to read (owned by user and 0600) on an NFS mount (/home) that is using Kerberos authentication. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Thu Dec 27 16:27:21 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 26 Dec 2018 23:27:21 -0700 Subject: [TUHS] NFS & Kerberos woes... In-Reply-To: <20181226044920.GB4158@mit.edu> References: <20181226020119.GF18199@mcvoy.com> <20181226044920.GB4158@mit.edu> Message-ID: <7b67bc61-28e0-4305-6d30-7b8b402c4cbe@spamtrap.tnetconsulting.net> On 12/25/18 9:49 PM, Theodore Y. Ts'o wrote: > Now, I believe you *could* configure in the mapping database > that authentication from some Kerberos principal such as > "tytso/root at ATHENA.MIT.EDU" or "host/cwcc.mit.edu at ATHENA.MIT.EDU" (you > can use service principals from a Kerberos keytab as a client principal > for the purposes of machine authentication) should be mapped to uid 0. Ted, you ultimately pointed me down the proper path. My first few attempts at implementing what you were suggesting, including (re)using the host/client.sub.domain.tld at REALM, didn't work out as desired. After much trial and tribulation, I did manage to get it working using a different principal, root/client.sub.domain.tld at REALM. See my previous reply to my original message for more details. Thank you again for the very detailed reply Ted. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From dave at horsfall.org Fri Dec 28 13:08:17 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 28 Dec 2018 14:08:17 +1100 (EST) Subject: [TUHS] Happy birthday, John von Neumann! Message-ID: We gained John von Neumann on this day in 1903, and if you haven't heard of him then you are barely human... As computer science goes, he's right up there with Alan Turing. There is speculation that he knew of Babbage's work; see https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann . -- Dave From dave at horsfall.org Fri Dec 28 16:31:31 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 28 Dec 2018 17:31:31 +1100 (EST) Subject: [TUHS] swtch() (was: man-page style) In-Reply-To: <20181204225404.GC55383@eureka.lemis.com> References: <1543705783.3909.for-standards-violators@oclsc.org> <20181203011414.DAE3D156E410@mail.bitblocks.com> <20181203013025.GB10043@mcvoy.com> <20181204225404.GC55383@eureka.lemis.com> Message-ID: On Wed, 5 Dec 2018, Greg 'groggy' Lehey wrote: >> Ahh, line 2238... > > Not line 325 of ken/slp.c? The Lions book. "You are not expected to understand this". -- Dave From dave at horsfall.org Fri Dec 28 16:32:51 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 28 Dec 2018 17:32:51 +1100 (EST) Subject: [TUHS] man-page style In-Reply-To: <20181204213452.GI3316@mcvoy.com> References: <1543705783.3909.for-standards-violators@oclsc.org> <20181203011414.DAE3D156E410@mail.bitblocks.com> <20181203013025.GB10043@mcvoy.com> <20181204213452.GI3316@mcvoy.com> Message-ID: On Tue, 4 Dec 2018, Larry McVoy wrote: >>> As a systems guy I think if you have not written, or understood, swtch(), >>> you are not a systems guy. >> >> Ahh, line 2238... > > I dunno what line it is, I'm guessing that's the # for the Lions book? Yep. -- Dave From will.senn at gmail.com Sat Dec 29 10:25:49 2018 From: will.senn at gmail.com (Will Senn) Date: Fri, 28 Dec 2018 18:25:49 -0600 Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? Message-ID: So... I whacked /usr/sys/lib1 and lib2 ‘accidentally’ meaning I logged in as bin changed to /usr/sys and typed rm lib1 and rm lib2 :). Now, I was thinking at the time that I could regenerate them... this seems like a possibility, but I can’t seem to get them back. sh run as bin doesn’t do it. So, what magic incantation is required to rebuild them. What motivated the exploration was a desire to modify main.c and see those changes manifest. Help. Thanks, Will Sent from my iPhone From will.senn at gmail.com Sat Dec 29 11:26:23 2018 From: will.senn at gmail.com (Will Senn) Date: Fri, 28 Dec 2018 19:26:23 -0600 Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? In-Reply-To: <20181229010900.19F6218C074@mercury.lcs.mit.edu> References: <20181229010900.19F6218C074@mercury.lcs.mit.edu> Message-ID: Ah! Thanks Noel. Yes, the two files are created and then a slew of linker errors. What you say makes sense. I can just compare with another v6 instance that I have that is similar to replicate the delivered order. Now I’m off to trying it out. Will Sent from my iPhone On Dec 28, 2018, at 7:09 PM, Noel Chiappa wrote: >> From: Will Senn > >> I whacked /usr/sys/lib1 and lib2 'accidentally' meaning I logged in as >> bin changed to /usr/sys and typed rm lib1 and rm lib2 :). > > Doesn't sound very accidental... :-) > >> sh run as bin doesn't do it. > > Odd. 'run' in /usr/sys on my V6 machine (not that I use that, mind) says: > > chdir ken > cc -c -O *.c > ar r ../lib1 > rm *.o > chdir ../dmr > cc -c -O *.c > ar r ../lib2 > rm *.o > > which should regenerate them - sort of. I suspect you really meant 'doing sh > run creates a lib1 and lib2, but then I get errors from the ld phase with > missing symbols'. Yes? > > If so, the thing is that the V6 linker won't pull in an object module from a > library unless a global in it satisfies an already existing (i.e. in the > linking process) undefined global. (I don't know if this is true of later > linkers; never used 'em.) In other words, when loading a multi-module system, > the module with 'main' has to be first, and then the rest in an order such > that each one holds a previously-undefined symbol. > > So the order of the object modules you'll get in lib? from the above, if you > precede them with 'rm lib?', is probably not the right order. (The above shell > script assumes they already exist, with the modules in the right order, so the > above just replaces them with the newly compiled versions...) > >> So, what magic incantation is required to rebuild them. > > Here's the ordering in lib1: > > main.o > alloc.o > iget.o > prf.o > rdwri.o > slp.o > subr.o > text.o > trap.o > sig.o > sysent.o > clock.o > fio.o > malloc.o > nami.o > pipe.o > sys1.o > sys2.o > sys3.o > sys4.o > > Other orders would work too (e.g. you could move sys?.o up just after sysent.o > and it should work). > > My lib2 is somewhat odd, so I hesitate to list it, but since most modules in > dmr are pulled in from entries in c.c, almost any order will work, I think. > > Noel From jnc at mercury.lcs.mit.edu Sat Dec 29 11:09:00 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 28 Dec 2018 20:09:00 -0500 (EST) Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? Message-ID: <20181229010900.19F6218C074@mercury.lcs.mit.edu> > From: Will Senn > I whacked /usr/sys/lib1 and lib2 'accidentally' meaning I logged in as > bin changed to /usr/sys and typed rm lib1 and rm lib2 :). Doesn't sound very accidental... :-) > sh run as bin doesn't do it. Odd. 'run' in /usr/sys on my V6 machine (not that I use that, mind) says: chdir ken cc -c -O *.c ar r ../lib1 rm *.o chdir ../dmr cc -c -O *.c ar r ../lib2 rm *.o which should regenerate them - sort of. I suspect you really meant 'doing sh run creates a lib1 and lib2, but then I get errors from the ld phase with missing symbols'. Yes? If so, the thing is that the V6 linker won't pull in an object module from a library unless a global in it satisfies an already existing (i.e. in the linking process) undefined global. (I don't know if this is true of later linkers; never used 'em.) In other words, when loading a multi-module system, the module with 'main' has to be first, and then the rest in an order such that each one holds a previously-undefined symbol. So the order of the object modules you'll get in lib? from the above, if you precede them with 'rm lib?', is probably not the right order. (The above shell script assumes they already exist, with the modules in the right order, so the above just replaces them with the newly compiled versions...) > So, what magic incantation is required to rebuild them. Here's the ordering in lib1: main.o alloc.o iget.o prf.o rdwri.o slp.o subr.o text.o trap.o sig.o sysent.o clock.o fio.o malloc.o nami.o pipe.o sys1.o sys2.o sys3.o sys4.o Other orders would work too (e.g. you could move sys?.o up just after sysent.o and it should work). My lib2 is somewhat odd, so I hesitate to list it, but since most modules in dmr are pulled in from entries in c.c, almost any order will work, I think. Noel From wkt at tuhs.org Sat Dec 29 11:35:27 2018 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 29 Dec 2018 11:35:27 +1000 Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? In-Reply-To: <20181229010900.19F6218C074@mercury.lcs.mit.edu> References: <20181229010900.19F6218C074@mercury.lcs.mit.edu> Message-ID: <20181229013527.GA3844@minnie.tuhs.org> On Fri, Dec 28, 2018 at 08:09:00PM -0500, Noel Chiappa wrote: > Odd. 'run' in /usr/sys on my V6 machine (not that I use that, mind) says: > > chdir ken > cc -c -O *.c > ar r ../lib1 > rm *.o > chdir ../dmr > cc -c -O *.c > ar r ../lib2 > rm *.o > > which should regenerate them - sort of. I just tried it here. I had to do: chdir ken; ... ar r ../lib1 *.o chdir ../dmr; ... ar r ../lib2 *.o to get them to rebuild. Otherwise, I had empty libraries. Cheers, Warren From wkt at tuhs.org Sat Dec 29 14:59:13 2018 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 29 Dec 2018 14:59:13 +1000 Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? In-Reply-To: <82e23dba-38a4-3ee4-e35a-6293b8eef749@gmail.com> References: <20181229010900.19F6218C074@mercury.lcs.mit.edu> <20181229013527.GA3844@minnie.tuhs.org> <82e23dba-38a4-3ee4-e35a-6293b8eef749@gmail.com> Message-ID: <20181229045913.GA21435@minnie.tuhs.org> > On 12/28/18 7:35 PM, Warren Toomey wrote: > > I just tried it here. I had to do: > > chdir ken; ... > > ar r ../lib1 *.o > > chdir ../dmr; ... > > ar r ../lib2 *.o On Fri, Dec 28, 2018 at 08:02:55PM -0600, Will Senn wrote: > I wound up doing: > chdir ken > cc -c -O *.c > ar r ../lib1 main.o > ar r ../lib1 alloc.o > ar r ../lib1 iget.o > ar r ../lib1 prf.o > ar r ../lib1 rdwri.o > ar r ../lib1 slp.o > ar r ../lib1 subr.o > ar r ../lib1 text.o > ar r ../lib1 trap.o > ar r ../lib1 sig.o > ar r ../lib1 sysent.o > ar r ../lib1 clock.o > ar r ../lib1 fio.o > ar r ../lib1 malloc.o > ar r ../lib1 nami.o > ar r ../lib1 pipe.o > ar r ../lib1 sys1.o > ar r ../lib1 sys2.o > ar r ../lib1 sys3.o > ar r ../lib1 sys4.o > > rm *.o > > chdir ../dmr > cc -c -O *.c > > ar r ../lib2 bio.o > ar r ../lib2 tty.o > ar r ../lib2 dc.o > ar r ../lib2 dn.o > ar r ../lib2 dp.o > ar r ../lib2 kl.o > ar r ../lib2 mem.o > ar r ../lib2 pc.o > ar r ../lib2 rf.o > ar r ../lib2 rk.o > ar r ../lib2 tc.o > ar r ../lib2 tm.o > ar r ../lib2 partab.o > ar r ../lib2 rp.o > ar r ../lib2 lp.o > ar r ../lib2 dhdm.o > ar r ../lib2 dh.o > ar r ../lib2 dhfdm.o > ar r ../lib2 sys.o > ar r ../lib2 hp.o > ar r ../lib2 ht.o > ar r ../lib2 hs.o > rm *.o > > Then I continued with the system build and it worked and my changes were > there! > Will Yes, order will be important, I forgot. There's no ranlib in v6 :-) Cheers, Warren From jnc at mercury.lcs.mit.edu Sun Dec 30 00:13:56 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 29 Dec 2018 09:13:56 -0500 (EST) Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? Message-ID: <20181229141356.AA78018C073@mercury.lcs.mit.edu> > From: Warren Toomey > I just tried it here. I had to do: > ... > ar r ../lib1 *.o > ... > to get them to rebuild. Otherwise, I had empty libraries. Duhh. I never noticed the missing "*.o"! I wonder how that one slipped through? Looking at 'run', it really does look like it was used to prepare the systems on the distribution tape. So probably the libraries just happened to already hold the latest and greatest, so that error had no effect. The thing with needing to order the library contents properly to cause all the modules to get loaded is, I reckon, the reason why 'ar' has those arguments to specify where in the archive a given file goes. Noel From clemc at ccc.com Sun Dec 30 02:26:40 2018 From: clemc at ccc.com (Clem Cole) Date: Sat, 29 Dec 2018 11:26:40 -0500 Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? In-Reply-To: <20181229045913.GA21435@minnie.tuhs.org> References: <20181229010900.19F6218C074@mercury.lcs.mit.edu> <20181229013527.GA3844@minnie.tuhs.org> <82e23dba-38a4-3ee4-e35a-6293b8eef749@gmail.com> <20181229045913.GA21435@minnie.tuhs.org> Message-ID: On Fri, Dec 28, 2018 at 11:59 PM Warren Toomey wrote: > Yes, order will be important, I forgot. There's no ranlib in v6 :-) > Good point. I've forgotten as to where and when did ranlib appear in the dev stream? Was it research, UCB or somewhere else like on the Harvard Tape? Just now, I took a quick peak at the 1BSD archive on TUHS.org but the subdirtectories are all packed up as v6 ar archives (cont.a files) - *i.e.* when somebody converted the BSD stp tape to a tar image they just wrote the archive and then rewrote it as a compressed tar ball. So I will take a little more work to unpack them, ensure the dates are 1978 based. (which I'll do at some point and offer them back to Warren). But I do remember when ranlib showing up it was such a win for fixing C compiler (well linkage) errors. I could have sworn, we had it was before V7, so maybe it came with the Typesetter C or UNIX/TS stuff. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Dec 30 02:49:29 2018 From: imp at bsdimp.com (Warner Losh) Date: Sat, 29 Dec 2018 09:49:29 -0700 Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? In-Reply-To: References: <20181229010900.19F6218C074@mercury.lcs.mit.edu> <20181229013527.GA3844@minnie.tuhs.org> <82e23dba-38a4-3ee4-e35a-6293b8eef749@gmail.com> <20181229045913.GA21435@minnie.tuhs.org> Message-ID: On Sat, Dec 29, 2018, 11:27 AM Clem Cole > > On Fri, Dec 28, 2018 at 11:59 PM Warren Toomey wrote: > >> Yes, order will be important, I forgot. There's no ranlib in v6 :-) >> > > Good point. I've forgotten as to where and when did ranlib appear in > the dev stream? Was it research, UCB or somewhere else like on the > Harvard Tape? > > Just now, I took a quick peak at the 1BSD archive on TUHS.org but the > subdirtectories are all packed up as v6 ar archives (cont.a files) - > *i.e.* when somebody converted the BSD stp tape to a tar image they just > wrote the archive and then rewrote it as a compressed tar ball. So I will > take a little more work to unpack them, ensure the dates are 1978 based. > (which I'll do at some point and offer them back to Warren). > > But I do remember when ranlib showing up it was such a win for fixing C > compiler (well linkage) errors. I could have sworn, we had it was before > V7, so maybe it came with the Typesetter C or UNIX/TS stuff. > But wasn't it tsort that did the heavy lifting to get things in order? ar c foo.a `tsort *.o` Ranlib just made it fast by adding an index.. Warner > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Sun Dec 30 03:12:14 2018 From: will.senn at gmail.com (Will Senn) Date: Sat, 29 Dec 2018 11:12:14 -0600 Subject: [TUHS] V6 intro file display in terminal Message-ID: <8375736D-3D49-46DE-81B0-52E5B5BD9292@gmail.com> There is a file, intro, in /usr/doc/man/man0, that is a system introduction prepared for a ‘Graphic System phototypesetter... in troff’. I was wondering if there was a way to display the file in v6 on the terminal, similar to displaying man pages: nroff /usr/doc/man/man0/naa /usr/doc/man/man1/write.1 I couldn’t find a troff command and the output from various nroff incantations were less readable than cat. Thanks, Will From clemc at ccc.com Sun Dec 30 03:48:26 2018 From: clemc at ccc.com (Clem cole) Date: Sat, 29 Dec 2018 12:48:26 -0500 Subject: [TUHS] Deleted lib1 and lib2 in v6, recoverable? In-Reply-To: References: <20181229010900.19F6218C074@mercury.lcs.mit.edu> <20181229013527.GA3844@minnie.tuhs.org> <82e23dba-38a4-3ee4-e35a-6293b8eef749@gmail.com> <20181229045913.GA21435@minnie.tuhs.org> Message-ID: <664BE02F-D7FE-4D43-BE02-5E8A46262CCA@ccc.com> Yes. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Dec 29, 2018, at 11:49 AM, Warner Losh wrote: > > > >> On Sat, Dec 29, 2018, 11:27 AM Clem Cole > >> >>> On Fri, Dec 28, 2018 at 11:59 PM Warren Toomey wrote: >>> Yes, order will be important, I forgot. There's no ranlib in v6 :-) >> >> Good point. I've forgotten as to where and when did ranlib appear in the dev stream? Was it research, UCB or somewhere else like on the Harvard Tape? >> >> Just now, I took a quick peak at the 1BSD archive on TUHS.org but the subdirtectories are all packed up as v6 ar archives (cont.a files) - i.e. when somebody converted the BSD stp tape to a tar image they just wrote the archive and then rewrote it as a compressed tar ball. So I will take a little more work to unpack them, ensure the dates are 1978 based. (which I'll do at some point and offer them back to Warren). >> >> But I do remember when ranlib showing up it was such a win for fixing C compiler (well linkage) errors. I could have sworn, we had it was before V7, so maybe it came with the Typesetter C or UNIX/TS stuff. > > > But wasn't it tsort that did the heavy lifting to get things in order? > > ar c foo.a `tsort *.o` > > Ranlib just made it fast by adding an index.. > > Warner >> ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Dec 30 04:06:40 2018 From: clemc at ccc.com (Clem cole) Date: Sat, 29 Dec 2018 13:06:40 -0500 Subject: [TUHS] V6 intro file display in terminal In-Reply-To: <8375736D-3D49-46DE-81B0-52E5B5BD9292@gmail.com> References: <8375736D-3D49-46DE-81B0-52E5B5BD9292@gmail.com> Message-ID: <87266B13-CC87-4014-894C-07B6F7927819@ccc.com> Will. You are reliving the experience 👌 IIRC nroff for v6 assumes the output is an ASR37 There are numerous filters such as ul(1) and more(1) that appear in those days that will help make the output more readable but you’ll need to install them. Do look at the 1bsd tape as well as the first usenix tape. You’ll find a lot things that will make v6 a little more sane. Also. As you probably have discovered tar was Ken’s creation for Unix/TS (widely distributed in V7) to replace v6’s tp and harvard’s stp. There is a version of it called v6tar that was released with V7 to help with conversions. I’m fairly sure Warren has a binary on the archive. With that you should be able write things that are easy to move between you simh system and a modern machine. One other handy trick is creating a copy of Horton’s uuencode/undecode pair. The sources are in many places (and many languages these days). I may even have a version I once created to back port it to the v6 compiler. But you should be able too pretty easily. The only issue is no stdio but the portable C lib in v6 has everything the encode twins need. so I expect you can back port it yourself in under an hour. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Dec 29, 2018, at 12:12 PM, Will Senn wrote: > > There is a file, intro, in /usr/doc/man/man0, that is a system introduction prepared for a ‘Graphic System phototypesetter... in troff’. I was wondering if there was a way to display the file in v6 on the terminal, similar to displaying man pages: > > nroff /usr/doc/man/man0/naa /usr/doc/man/man1/write.1 > > I couldn’t find a troff command and the output from various nroff incantations were less readable than cat. > > Thanks, > > Will > From lm at mcvoy.com Sun Dec 30 04:26:33 2018 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 29 Dec 2018 10:26:33 -0800 Subject: [TUHS] V6 intro file display in terminal In-Reply-To: <87266B13-CC87-4014-894C-07B6F7927819@ccc.com> References: <8375736D-3D49-46DE-81B0-52E5B5BD9292@gmail.com> <87266B13-CC87-4014-894C-07B6F7927819@ccc.com> Message-ID: <20181229182633.GR6178@mcvoy.com> On Sat, Dec 29, 2018 at 01:06:40PM -0500, Clem cole wrote: > > With that you should be able write things that are easy to move between you simh system and a modern machine. One other handy trick is creating a copy of Horton???s uuencode/undecode pair. If Will can't find uuencode/undecode I can provide C functions that do that. We rewrote them for BitKeeper. From will.senn at gmail.com Sun Dec 30 11:26:25 2018 From: will.senn at gmail.com (Will Senn) Date: Sat, 29 Dec 2018 19:26:25 -0600 Subject: [TUHS] Troff, eqn, tbl, etc Message-ID: <47485C4A-BCCD-4FA0-A0AF-3B37EEAC1D93@gmail.com> In the help file for v6 (/usr/doc/hel), it says that troff, eqn, etc are not part of the distro and even though there are man pages, the utils are not present in my base v6 install. I know this because I copied the hel0-hel5 files and naa over to my mac and used groff to make ps files and ps2pdf to turn those files into pdfs. While they came out ok, there was some overlapping text and the math equations were imperfect. I figured if I could do more preprocessing in v6 before moving files into mac, they might come out better, but the utils as noted above. Do we have the utils as bits somewhere (or is this an oblique reference to 1bsd)? Thanks, Will Sent from my iPhone