From bogus@does.not.exist.com  Thu Dec 27 09:21:55 2018
From: bogus@does.not.exist.com ()
Date: Wed, 26 Dec 2018 23:21:55 -0000
Subject: No subject
Message-ID: <mailman.0.1545866520.9753.tuhs@minnie.tuhs.org>

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  Thu Dec 27 09:21:55 2018
From: bogus@does.not.exist.com ()
Date: Wed, 26 Dec 2018 23:21:55 -0000
Subject: No subject
Message-ID: <mailman.1.1545866523.9753.tuhs@minnie.tuhs.org>

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  Thu Dec 27 09:21:55 2018
From: bogus@does.not.exist.com ()
Date: Wed, 26 Dec 2018 23:21:55 -0000
Subject: No subject
Message-ID: <mailman.2.1545866524.9753.tuhs@minnie.tuhs.org>

>
> 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  Thu Dec 27 09:21:55 2018
From: bogus@does.not.exist.com ()
Date: Wed, 26 Dec 2018 23:21:55 -0000
Subject: No subject
Message-ID: <mailman.3.1545866525.9753.tuhs@minnie.tuhs.org>

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  Thu Dec 27 09:21:55 2018
From: bogus@does.not.exist.com ()
Date: Wed, 26 Dec 2018 23:21:55 -0000
Subject: No subject
Message-ID: <mailman.4.1545866529.9753.tuhs@minnie.tuhs.org>

"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  Thu Dec 27 09:21:55 2018
From: bogus@does.not.exist.com ()
Date: Wed, 26 Dec 2018 23:21:55 -0000
Subject: No subject
Message-ID: <mailman.5.1545866529.9753.tuhs@minnie.tuhs.org>

>
> 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  Thu Dec 27 09:21:55 2018
From: bogus@does.not.exist.com ()
Date: Wed, 26 Dec 2018 23:21:55 -0000
Subject: No subject
Message-ID: <mailman.6.1545866529.9753.tuhs@minnie.tuhs.org>

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: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.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 <lm at mcvoy.com> wrote:
> 
> Indeed.  Sendmail got a lot of hate but mostly from people in pure
> user at host.domain <mailto: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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181130/6cc1ba90/attachment.html>

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: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com>
Message-ID: <A61F8BBC-1C96-46E9-AA7E-D27D6EDE123E@cheswick.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181130/49b5cb24/attachment.html>

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: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com>
Message-ID: <alpine.BSF.2.21.9999.1812010954340.52810@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com>
Message-ID: <201812011953.wB1JrGQh029358@freefriends.org>

WIlliam Cheswick <ches at cheswick.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.

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 <ches at cheswick.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.

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: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com>
 <201812011953.wB1JrGQh029358@freefriends.org>
Message-ID: <c6bd203f-a4c2-6a2c-1546-1fb9fca9ed19@spamtrap.tnetconsulting.net>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181201/1ed1b25e/attachment.bin>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181201/1b03af12/attachment.bin>

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: <alpine.BSF.2.21.9999.1812010954340.52810@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com>
 <alpine.BSF.2.21.9999.1812010954340.52810@aneurin.horsfall.org>
Message-ID: <8F45FE18-D6D8-47B0-B3D1-01EE8610F298@cheswick.com>

We supported many nets, including ACSnet:

uucp!research!ches
bitnet!templevm!rdk
csnet!<host>!<user>
acsnet!<host>!<user>

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 <dave at horsfall.org> wrote:
> 
> Err, why the query after ACSnet?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181201/59030742/attachment.html>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181201/0a0528d4/attachment.bin>

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: <fa7ad0c6-5b64-ae1d-42dd-41c95a1e2b51@spamtrap.tnetconsulting.net>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181201/2f9760b0/attachment.bin>

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: <c6bd203f-a4c2-6a2c-1546-1fb9fca9ed19@spamtrap.tnetconsulting.net>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com>
 <201812011953.wB1JrGQh029358@freefriends.org>
 <c6bd203f-a4c2-6a2c-1546-1fb9fca9ed19@spamtrap.tnetconsulting.net>
Message-ID: <201812020722.wB27MleQ030692@freefriends.org>

Grant Taylor via TUHS <tuhs at minnie.tuhs.org> 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.<something> 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: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com>
 <201812011953.wB1JrGQh029358@freefriends.org>
 <c6bd203f-a4c2-6a2c-1546-1fb9fca9ed19@spamtrap.tnetconsulting.net>
 <201812020722.wB27MleQ030692@freefriends.org>
Message-ID: <c296d150-2d70-b3e0-298e-fa9494e24572@spamtrap.tnetconsulting.net>

On 12/2/18 12:22 AM, arnold at skeeve.com wrote:
> Ease was posted in comp.sources.<something> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181202/a6a91a24/attachment.bin>

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: <c296d150-2d70-b3e0-298e-fa9494e24572@spamtrap.tnetconsulting.net>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <68E43E9C-BD27-4DDB-93D1-AD82EBCA976A@cheswick.com>
 <201812011953.wB1JrGQh029358@freefriends.org>
 <c6bd203f-a4c2-6a2c-1546-1fb9fca9ed19@spamtrap.tnetconsulting.net>
 <201812020722.wB27MleQ030692@freefriends.org>
 <c296d150-2d70-b3e0-298e-fa9494e24572@spamtrap.tnetconsulting.net>
Message-ID: <201812021722.wB2HMRTv024365@freefriends.org>

Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:

> On 12/2/18 12:22 AM, arnold at skeeve.com wrote:
> > Ease was posted in comp.sources.<something> 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: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
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: <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
References: <1543705783.3909.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
Message-ID: <CANCZdfrDm0rG=BCX2=8WRzKQ8jyh9TN2j0AD4dF7BKFg_ZNebg@mail.gmail.com>

On Sun, Dec 2, 2018 at 3:31 PM Dave Horsfall <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181202/54fe189c/attachment.html>

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."
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
References: <1543705783.3909.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
Message-ID: <20181203011414.DAE3D156E410@mail.bitblocks.com>

On Mon, 03 Dec 2018 09:30:06 +1100 Dave Horsfall <dave at horsfall.org> 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>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.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 <dave at horsfall.org> 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: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au>
Message-ID: <CAKzdPgwMSP_DM1OXP9kACUP3mCZVWEjEXofdDsbZwGqWXCQ_HQ@mail.gmail.com>

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 <toby at telegraphics.com.au> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181203/3a80dd49/attachment.html>

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: <CAKzdPgwMSP_DM1OXP9kACUP3mCZVWEjEXofdDsbZwGqWXCQ_HQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au>
 <CAKzdPgwMSP_DM1OXP9kACUP3mCZVWEjEXofdDsbZwGqWXCQ_HQ@mail.gmail.com>
Message-ID: <e4830fc5-21bd-234d-b945-faf6f64422d9@telegraphics.com.au>

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 <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> 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: <e4830fc5-21bd-234d-b945-faf6f64422d9@telegraphics.com.au>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au>
 <CAKzdPgwMSP_DM1OXP9kACUP3mCZVWEjEXofdDsbZwGqWXCQ_HQ@mail.gmail.com>
 <e4830fc5-21bd-234d-b945-faf6f64422d9@telegraphics.com.au>
Message-ID: <CAKzdPgwFXTYFqw6R9ppkVe_UoRd210yxr59GTASy6-2ALFwAuw@mail.gmail.com>

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 <toby at telegraphics.com.au> 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 <toby at telegraphics.com.au
> > <mailto:toby at telegraphics.com.au>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181203/3eb1d0f1/attachment.html>

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: <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
References: <1543705783.3909.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
Message-ID: <201812030653.wB36rbeq026790@freefriends.org>

Dave Horsfall <dave at horsfall.org> 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>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.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 <tuhs at eric.allman.name> 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: <CAKzdPgwFXTYFqw6R9ppkVe_UoRd210yxr59GTASy6-2ALFwAuw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au>
 <CAKzdPgwMSP_DM1OXP9kACUP3mCZVWEjEXofdDsbZwGqWXCQ_HQ@mail.gmail.com>
 <e4830fc5-21bd-234d-b945-faf6f64422d9@telegraphics.com.au>
 <CAKzdPgwFXTYFqw6R9ppkVe_UoRd210yxr59GTASy6-2ALFwAuw@mail.gmail.com>
Message-ID: <CAC0cEp9Mzy0PVhXKennZkFv7fk10jneqVD0fphDb=xstCwFSGA@mail.gmail.com>

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 <robpike at gmail.com> 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 <toby at telegraphics.com.au>
> 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 <toby at telegraphics.com.au
>> > <mailto:toby at telegraphics.com.au>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181203/3607f820/attachment.html>

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: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
Message-ID: <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>

On Sun, Dec 2, 2018 at 5:18 PM Dave Horsfall <dave at horsfall.org> 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
<https://www.quora.com/Is-the-future-of-Fortran-programming-dead/answer/Clem-Cole>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181203/0d8b7c6b/attachment.html>

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: <CAC20D2M=znbxjgiRbhUXQ8hQ8qcyyU+k5vrP6nPPP5TTrYMnDg@mail.gmail.com>

On Mon, Dec 3, 2018 at 11:31 AM Doug McIlroy <doug at cs.dartmouth.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181203/a112e6ca/attachment.html>

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: <CABH=_VSWf+2Z2O0yNOu=EBi3jYOXDk-bdEwzYSD+KSMcu9pfJg@mail.gmail.com>

On 12/3/18, Ron Young <rly1 at embarqmail.com> 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:

    <identifier> DO10I
    <operator> =
    <integer constant> 1

or:

    <keyword> DO
    <integer constant> 10
    <identifier> I
    <operator> =
    <integer constant> 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: <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
Message-ID: <CABH=_VTGj_Fugj7nNPu47G2nP2kjJivw-ummrWYnQe8tRtwqkQ@mail.gmail.com>

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: <CABH=_VTGj_Fugj7nNPu47G2nP2kjJivw-ummrWYnQe8tRtwqkQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
 <CABH=_VTGj_Fugj7nNPu47G2nP2kjJivw-ummrWYnQe8tRtwqkQ@mail.gmail.com>
Message-ID: <CAC20D2MPZY-D9PqJrYU1W5FrRWa_fo1xutAeaXZgkZ4dOkmexg@mail.gmail.com>

On Mon, Dec 3, 2018 at 3:21 PM Paul Winalski <paul.winalski at gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181203/4110ce49/attachment.html>

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: <CABH=_VSWf+2Z2O0yNOu=EBi3jYOXDk-bdEwzYSD+KSMcu9pfJg@mail.gmail.com>
References: <201812030336.wB33axfq080387@tahoe.cs.Dartmouth.EDU>
 <7E.F0.08702.4CFB40C5@smtp04.onyx.dfw.sync.lan>
 <CABH=_VSWf+2Z2O0yNOu=EBi3jYOXDk-bdEwzYSD+KSMcu9pfJg@mail.gmail.com>
Message-ID: <E0.CB.14659.B38950C5@smtp01.onyx.dfw.sync.lan>

Your message dated: Mon, 03 Dec 2018 15:10:32 -0500
--------
> On 12/3/18, Ron Young <rly1 at embarqmail.com> 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: <CABH=_VTGj_Fugj7nNPu47G2nP2kjJivw-ummrWYnQe8tRtwqkQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
 <CABH=_VTGj_Fugj7nNPu47G2nP2kjJivw-ummrWYnQe8tRtwqkQ@mail.gmail.com>
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: <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
Message-ID: <CABH=_VTOor-bjQx+92y3s9MXMSVhNzVPwEk93PFxoOAxQr6b9A@mail.gmail.com>

On 12/3/18, Clem Cole <clemc at ccc.com> 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: <CAC0cEp9Mzy0PVhXKennZkFv7fk10jneqVD0fphDb=xstCwFSGA@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <7942e6cc-177f-7155-f80f-80732da69d51@telegraphics.com.au>
 <CAKzdPgwMSP_DM1OXP9kACUP3mCZVWEjEXofdDsbZwGqWXCQ_HQ@mail.gmail.com>
 <e4830fc5-21bd-234d-b945-faf6f64422d9@telegraphics.com.au>
 <CAKzdPgwFXTYFqw6R9ppkVe_UoRd210yxr59GTASy6-2ALFwAuw@mail.gmail.com>
 <CAC0cEp9Mzy0PVhXKennZkFv7fk10jneqVD0fphDb=xstCwFSGA@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181203/1583bc11/attachment.html>

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: <CABH=_VTOor-bjQx+92y3s9MXMSVhNzVPwEk93PFxoOAxQr6b9A@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
 <CABH=_VTOor-bjQx+92y3s9MXMSVhNzVPwEk93PFxoOAxQr6b9A@mail.gmail.com>
Message-ID: <DD36F8A9-8482-46D2-8E9A-A7E875A526B1@serissa.com>

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 <paul.winalski at gmail.com> wrote:
> 
> On 12/3/18, Clem Cole <clemc at ccc.com> 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: <CANCZdfrDm0rG=BCX2=8WRzKQ8jyh9TN2j0AD4dF7BKFg_ZNebg@mail.gmail.com>
References: <1543705783.3909.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <CANCZdfrDm0rG=BCX2=8WRzKQ8jyh9TN2j0AD4dF7BKFg_ZNebg@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1812041840260.52810@aneurin.horsfall.org>

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: <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1812041141370.2487@grey.csi.cam.ac.uk>

Clem Cole <clemc at ccc.com> 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  <dot at dotat.at>  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: <alpine.DEB.2.20.1812041141370.2487@grey.csi.cam.ac.uk>
References: <alpine.BSF.2.21.9999.1812030906220.52810@aneurin.horsfall.org>
 <CAC20D2Puu3x+2sbt+dCSrmJ_cLk_p8R-WnSPHOKhcGvxN5BsCg@mail.gmail.com>
 <alpine.DEB.2.20.1812041141370.2487@grey.csi.cam.ac.uk>
Message-ID: <CAC20D2Ogg1DOgrq_BOuLbaQT7a4bZaapt35hXONp7pCdDO30kg@mail.gmail.com>

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 <dot at dotat.at> wrote:

> Clem Cole <clemc at ccc.com> 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  <dot at dotat.at>  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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181204/bde909b2/attachment.html>

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: <CAC20D2P6P3jSOY3uC6SVHxdi9SYJBjiExa9=anUGYNVQ+1w+Gg@mail.gmail.com>

On Tue, Dec 4, 2018 at 9:43 AM Noel Chiappa <jnc at mercury.lcs.mit.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181204/3fd27316/attachment.html>

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: <alpine.BSF.2.21.9999.1812041840260.52810@aneurin.horsfall.org>
References: <1543705783.3909.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <CANCZdfrDm0rG=BCX2=8WRzKQ8jyh9TN2j0AD4dF7BKFg_ZNebg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1812041840260.52810@aneurin.horsfall.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: <c00f33c5-cf51-cd36-2426-d6ac72de93ef@telegraphics.com.au>

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: <CAC20D2P6P3jSOY3uC6SVHxdi9SYJBjiExa9=anUGYNVQ+1w+Gg@mail.gmail.com>
References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu>
 <CAC20D2P6P3jSOY3uC6SVHxdi9SYJBjiExa9=anUGYNVQ+1w+Gg@mail.gmail.com>
Message-ID: <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com>


> On 4 Dec 2018, at 14:53, Clem Cole <clemc at ccc.com> wrote:
> On Tue, Dec 4, 2018 at 9:43 AM Noel Chiappa <jnc at mercury.lcs.mit.edu <mailto:jnc at mercury.lcs.mit.edu>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181204/26ab8ee3/attachment.html>

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>
 <CAC20D2P6P3jSOY3uC6SVHxdi9SYJBjiExa9=anUGYNVQ+1w+Gg@mail.gmail.com>
 <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com>
Message-ID: <CAC20D2PsA=_Yf-hZRM6wCJL7H3Y9o6cSE02s5oPz_VHfqRYxRA@mail.gmail.com>

On Tue, Dec 4, 2018 at 11:34 AM Tim Rylance <tuhs at tkr.bondplaza.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181204/19affe72/attachment.html>

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>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <CANCZdfrDm0rG=BCX2=8WRzKQ8jyh9TN2j0AD4dF7BKFg_ZNebg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1812041840260.52810@aneurin.horsfall.org>
 <97743c31-e625-39b1-902e-2e531e90ec6f@telegraphics.com.au>
Message-ID: <CAJfiPzwLRHeqtKf+=_uhTJne9mrS1zbDgdzVMvZj19zo3nCPEQ@mail.gmail.com>

On 04/12/2018, Toby Thain <toby at telegraphics.com.au> 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: <CAC20D2PsA=_Yf-hZRM6wCJL7H3Y9o6cSE02s5oPz_VHfqRYxRA@mail.gmail.com>
References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu>
 <CAC20D2P6P3jSOY3uC6SVHxdi9SYJBjiExa9=anUGYNVQ+1w+Gg@mail.gmail.com>
 <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com>
 <CAC20D2PsA=_Yf-hZRM6wCJL7H3Y9o6cSE02s5oPz_VHfqRYxRA@mail.gmail.com>
Message-ID: <CABH=_VTUM_zStuhGNqqEcntTnnn8smZh4mLbx+KaewNzLMqu_w@mail.gmail.com>

On 12/4/18, Clem Cole <clemc at ccc.com> 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: <CAJfiPzwLRHeqtKf+=_uhTJne9mrS1zbDgdzVMvZj19zo3nCPEQ@mail.gmail.com>
References: <1543705783.3909.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <CANCZdfrDm0rG=BCX2=8WRzKQ8jyh9TN2j0AD4dF7BKFg_ZNebg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1812041840260.52810@aneurin.horsfall.org>
 <97743c31-e625-39b1-902e-2e531e90ec6f@telegraphics.com.au>
 <CAJfiPzwLRHeqtKf+=_uhTJne9mrS1zbDgdzVMvZj19zo3nCPEQ@mail.gmail.com>
Message-ID: <CABH=_VRt1FZSRMuMiXj0LMiLka+qSC2WMu0FPPKiTm0gO2=LnQ@mail.gmail.com>

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: <CABH=_VRt1FZSRMuMiXj0LMiLka+qSC2WMu0FPPKiTm0gO2=LnQ@mail.gmail.com>
References: <1543705783.3909.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <CANCZdfrDm0rG=BCX2=8WRzKQ8jyh9TN2j0AD4dF7BKFg_ZNebg@mail.gmail.com>
 <alpine.BSF.2.21.9999.1812041840260.52810@aneurin.horsfall.org>
 <97743c31-e625-39b1-902e-2e531e90ec6f@telegraphics.com.au>
 <CAJfiPzwLRHeqtKf+=_uhTJne9mrS1zbDgdzVMvZj19zo3nCPEQ@mail.gmail.com>
 <CABH=_VRt1FZSRMuMiXj0LMiLka+qSC2WMu0FPPKiTm0gO2=LnQ@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181204/ed869cd7/attachment.bin>

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: <alpine.BSF.2.21.9999.1812050737560.52810@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.1812050737560.52810@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1812050737560.52810@aneurin.horsfall.org>
Message-ID: <CAC20D2PN6QJAJrmnpJR-ZJ24f_Dh4smf2vOCag=cp_pT8u64rQ@mail.gmail.com>

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 <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181204/53139051/attachment.html>

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: <alpine.BSF.2.21.9999.1812050737560.52810@aneurin.horsfall.org>
 (Dave Horsfall's message of "Wed, 5 Dec 2018 07:44:12 +1100 (EST)")
References: <alpine.BSF.2.21.9999.1812050737560.52810@aneurin.horsfall.org>
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: <CAC20D2PN6QJAJrmnpJR-ZJ24f_Dh4smf2vOCag=cp_pT8u64rQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1812050737560.52810@aneurin.horsfall.org>
 <CAC20D2PN6QJAJrmnpJR-ZJ24f_Dh4smf2vOCag=cp_pT8u64rQ@mail.gmail.com>
Message-ID: <CAC20D2NLi0d6A7nORUkVbADnTK1-xGbLUFAL=_WSDisk-Lnm+Q@mail.gmail.com>

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 <clemc at ccc.com> 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 <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181204/3b4a7955/attachment.html>

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: <CABH=_VTUM_zStuhGNqqEcntTnnn8smZh4mLbx+KaewNzLMqu_w@mail.gmail.com>
References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu>
 <CAC20D2P6P3jSOY3uC6SVHxdi9SYJBjiExa9=anUGYNVQ+1w+Gg@mail.gmail.com>
 <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com>
 <CAC20D2PsA=_Yf-hZRM6wCJL7H3Y9o6cSE02s5oPz_VHfqRYxRA@mail.gmail.com>
 <CABH=_VTUM_zStuhGNqqEcntTnnn8smZh4mLbx+KaewNzLMqu_w@mail.gmail.com>
Message-ID: <CABH=_VSewc0u6ef8SsGE=GjmMSBm4Fv-Wj+WFFaenwHjWF38_g@mail.gmail.com>

On 12/4/18, Paul Winalski <paul.winalski at gmail.com> 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: <alpine.BSF.2.21.9999.1812050808530.52810@aneurin.horsfall.org>

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>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <20181203011414.DAE3D156E410@mail.bitblocks.com>
 <20181203013025.GB10043@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.1812050823420.52810@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.1812050823420.52810@aneurin.horsfall.org>
References: <1543705783.3909.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <20181203011414.DAE3D156E410@mail.bitblocks.com>
 <20181203013025.GB10043@mcvoy.com>
 <alpine.BSF.2.21.9999.1812050823420.52810@aneurin.horsfall.org>
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: <alpine.BSF.2.21.9999.1812050737560.52810@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1812050737560.52810@aneurin.horsfall.org>
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>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <20181203011414.DAE3D156E410@mail.bitblocks.com>
 <20181203013025.GB10043@mcvoy.com>
 <alpine.BSF.2.21.9999.1812050823420.52810@aneurin.horsfall.org>
 <20181204213452.GI3316@mcvoy.com>
Message-ID: <F2E410AC-2825-451C-81E4-BB2E032A52D1@bitblocks.com>

On Dec 4, 2018, at 1:34 PM, Larry McVoy <lm at mcvoy.com> 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: <alpine.BSF.2.21.9999.1812050737560.52810@aneurin.horsfall.org>
 <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: <CABH=_VSewc0u6ef8SsGE=GjmMSBm4Fv-Wj+WFFaenwHjWF38_g@mail.gmail.com>
References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu>
 <CAC20D2P6P3jSOY3uC6SVHxdi9SYJBjiExa9=anUGYNVQ+1w+Gg@mail.gmail.com>
 <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com>
 <CAC20D2PsA=_Yf-hZRM6wCJL7H3Y9o6cSE02s5oPz_VHfqRYxRA@mail.gmail.com>
 <CABH=_VTUM_zStuhGNqqEcntTnnn8smZh4mLbx+KaewNzLMqu_w@mail.gmail.com>
 <CABH=_VSewc0u6ef8SsGE=GjmMSBm4Fv-Wj+WFFaenwHjWF38_g@mail.gmail.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 <paul.winalski at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181205/dffaf780/attachment.sig>

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: <alpine.BSF.2.21.9999.1812050823420.52810@aneurin.horsfall.org>
References: <1543705783.3909.for-standards-violators@oclsc.org>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <20181203011414.DAE3D156E410@mail.bitblocks.com>
 <20181203013025.GB10043@mcvoy.com>
 <alpine.BSF.2.21.9999.1812050823420.52810@aneurin.horsfall.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181205/60b75982/attachment.sig>

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>
 <CAC20D2P6P3jSOY3uC6SVHxdi9SYJBjiExa9=anUGYNVQ+1w+Gg@mail.gmail.com>
 <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com>
 <CAC20D2PsA=_Yf-hZRM6wCJL7H3Y9o6cSE02s5oPz_VHfqRYxRA@mail.gmail.com>
 <CABH=_VTUM_zStuhGNqqEcntTnnn8smZh4mLbx+KaewNzLMqu_w@mail.gmail.com>
 <CABH=_VSewc0u6ef8SsGE=GjmMSBm4Fv-Wj+WFFaenwHjWF38_g@mail.gmail.com>
 <20181204224925.GB55383@eureka.lemis.com>
Message-ID: <CABH=_VRmsCfkXmzK2xrPkgQDrnYKZHUvzha5Y_5WT-mjd-614Q@mail.gmail.com>

On 12/4/18, Greg 'groggy' Lehey <grog at lemis.com> 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: <mailman.1.1543975201.8252.tuhs@minnie.tuhs.org>
References: <mailman.1.1543975201.8252.tuhs@minnie.tuhs.org>
Message-ID: <385DF3A2-447D-4CD4-AC5C-9F541070C28B@mcjones.org>

> On Dec 4, 2018, Greg 'groggy' Lehey <grog at lemis.com> 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>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <20181203011414.DAE3D156E410@mail.bitblocks.com>
 <20181203013025.GB10043@mcvoy.com>
 <alpine.BSF.2.21.9999.1812050823420.52810@aneurin.horsfall.org>
 <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: <mailman.1.1543975201.8252.tuhs@minnie.tuhs.org>
 <385DF3A2-447D-4CD4-AC5C-9F541070C28B@mcjones.org>
Message-ID: <E5385161-BB3C-43B3-87B6-3473819806ED@csp-partnership.co.uk>


> On 5 Dec 2018, at 04:48, Paul McJones <paul at mcjones.org> wrote:
> 
>> On Dec 4, 2018, Greg 'groggy' Lehey <grog at lemis.com> 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: <mailman.1.1543975201.8252.tuhs@minnie.tuhs.org>
 <385DF3A2-447D-4CD4-AC5C-9F541070C28B@mcjones.org>
Message-ID: <CAC20D2MMVqtsCx=R+TMDy4UJ5S1k7XU3-5A90-CBmBYgnpxxnA@mail.gmail.com>

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 <paul at mcjones.org> wrote:

> > On Dec 4, 2018, Greg 'groggy' Lehey <grog at lemis.com> 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
<https://en.wikipedia.org/wiki/Executive_Systems_Problem_Oriented_Language>.
 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
<http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1032638_B5500_ESPOL_RefManOct67.pdf>
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181205/da3a8177/attachment.html>

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>
 <alpine.BSF.2.21.9999.1812030925020.52810@aneurin.horsfall.org>
 <20181203011414.DAE3D156E410@mail.bitblocks.com>
 <20181203013025.GB10043@mcvoy.com>
 <alpine.BSF.2.21.9999.1812050823420.52810@aneurin.horsfall.org>
 <20181204225404.GC55383@eureka.lemis.com>
Message-ID: <CAC20D2MkYDayFNouuz_6dEPSr_GANFKt+Oj10QGO1V2DNpooyA@mail.gmail.com>

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 <grog at lemis.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181205/d36cf070/attachment.html>

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: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>

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: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
Message-ID: <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>

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: <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
 <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
Message-ID: <CANCZdfo41Oiii1Urfhc+5KTJzgW6cAiEXyjCzaXVeE7TM7=Enw@mail.gmail.com>

On Wed, Dec 5, 2018 at 9:48 AM Paul Winalski <paul.winalski at gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181205/85453667/attachment.html>

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: <CABH=_VTUM_zStuhGNqqEcntTnnn8smZh4mLbx+KaewNzLMqu_w@mail.gmail.com>
References: <20181204144306.A830E18C0A0@mercury.lcs.mit.edu>
 <CAC20D2P6P3jSOY3uC6SVHxdi9SYJBjiExa9=anUGYNVQ+1w+Gg@mail.gmail.com>
 <2DBF1622-0489-4F39-88A5-BCE130732041@tkr.bondplaza.com>
 <CAC20D2PsA=_Yf-hZRM6wCJL7H3Y9o6cSE02s5oPz_VHfqRYxRA@mail.gmail.com>
 <CABH=_VTUM_zStuhGNqqEcntTnnn8smZh4mLbx+KaewNzLMqu_w@mail.gmail.com>
Message-ID: <CABH=_VTSoKkyWS2iMnGRnf6=VW3j=pTyY800uOp+bc-W2GSDyQ@mail.gmail.com>

On 12/4/18, Paul Winalski <paul.winalski at gmail.com> 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: <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
 <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
Message-ID: <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>

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 <paul.winalski at gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181205/79fffbfe/attachment.html>

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: <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
 <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
 <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>
Message-ID: <CABH=_VRyc2tfP46w8Vgc0sCLAJyaq4m4q_1gP=SJfpJry=+3Bw@mail.gmail.com>

On 12/5/18, Clem Cole <clemc at ccc.com> 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: <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
 <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
 <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>
Message-ID: <CAEdTPBcbh241896vNTgsBGU20g6a_MDQ1ikJQf+bAx_DNOAyoQ@mail.gmail.com>

On Wed, 5 Dec 2018 at 13:01, Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181205/ba389591/attachment.html>

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: <CAEdTPBcbh241896vNTgsBGU20g6a_MDQ1ikJQf+bAx_DNOAyoQ@mail.gmail.com>
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
 <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
 <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>
 <CAEdTPBcbh241896vNTgsBGU20g6a_MDQ1ikJQf+bAx_DNOAyoQ@mail.gmail.com>
Message-ID: <CAC20D2PnjAM=OSsjwktriS_BmAUwaCcRsLwPKm6A8mSmf362jw@mail.gmail.com>

On Wed, Dec 5, 2018 at 1:29 PM Henry Bent <henry.r.bent at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181205/940aae6e/attachment.html>

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: <CAC20D2PnjAM=OSsjwktriS_BmAUwaCcRsLwPKm6A8mSmf362jw@mail.gmail.com>
 (Clem Cole's message of "Wed, 5 Dec 2018 13:46:44 -0500")
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
 <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
 <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>
 <CAEdTPBcbh241896vNTgsBGU20g6a_MDQ1ikJQf+bAx_DNOAyoQ@mail.gmail.com>
 <CAC20D2PnjAM=OSsjwktriS_BmAUwaCcRsLwPKm6A8mSmf362jw@mail.gmail.com>
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: <CAC20D2PnjAM=OSsjwktriS_BmAUwaCcRsLwPKm6A8mSmf362jw@mail.gmail.com>
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
 <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
 <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>
 <CAEdTPBcbh241896vNTgsBGU20g6a_MDQ1ikJQf+bAx_DNOAyoQ@mail.gmail.com>
 <CAC20D2PnjAM=OSsjwktriS_BmAUwaCcRsLwPKm6A8mSmf362jw@mail.gmail.com>
Message-ID: <CABH=_VTcn6zdqVUrfXp3ug_6A0W+=HRLR0rU2Ngp=eCL0y0tSg@mail.gmail.com>

On 12/5/18, Clem Cole <clemc at ccc.com> 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: <CABH=_VTcn6zdqVUrfXp3ug_6A0W+=HRLR0rU2Ngp=eCL0y0tSg@mail.gmail.com>
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
 <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
 <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>
 <CAEdTPBcbh241896vNTgsBGU20g6a_MDQ1ikJQf+bAx_DNOAyoQ@mail.gmail.com>
 <CAC20D2PnjAM=OSsjwktriS_BmAUwaCcRsLwPKm6A8mSmf362jw@mail.gmail.com>
 <CABH=_VTcn6zdqVUrfXp3ug_6A0W+=HRLR0rU2Ngp=eCL0y0tSg@mail.gmail.com>
Message-ID: <FCE97019-C600-4D3E-881B-90927EFBF531@alchemistowl.org>

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" <lm at mcvoy.com>
To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181205/0f162393/attachment.html>

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 <doug at cs.dartmouth.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181207/ddc6c8a4/attachment.sig>

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" <g.branden.robinson at gmail.com> 写到:
> 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" <g.branden.robinson at gmail.com> 写到:
> 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: <CANiMCTMUCCNnpJ64+rOtUuFt2MexW2jSn4u1cYa3Y+hjMbg51g@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181207/63a6a6e5/attachment.html>

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: <CANiMCTMUCCNnpJ64+rOtUuFt2MexW2jSn4u1cYa3Y+hjMbg51g@mail.gmail.com>
References: <CANiMCTMUCCNnpJ64+rOtUuFt2MexW2jSn4u1cYa3Y+hjMbg51g@mail.gmail.com>
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 <edouardklein at gmail.com>:
> Hi all,
> 
> I haven't seen this on the list yet (apologies if I missed it):
> 
> <a target="_blank" href="https://unix50.org/">https://unix50.org/</a>
> 
> 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: <FCE97019-C600-4D3E-881B-90927EFBF531@alchemistowl.org>
References: <CABH=_VTsixrXYL4LNEej9DtwV_TzErw6D=EZLTMAD64aYEA4mg@mail.gmail.com>
 <CABH=_VSr8tByoz8FOoGpe6Yz8CH_Zbi10qOLMb15eX-+oBhB+w@mail.gmail.com>
 <CAC20D2Nh5w7wPMo0s568cToPSBJd7gtcEWdif57wizqV09_CJg@mail.gmail.com>
 <CAEdTPBcbh241896vNTgsBGU20g6a_MDQ1ikJQf+bAx_DNOAyoQ@mail.gmail.com>
 <CAC20D2PnjAM=OSsjwktriS_BmAUwaCcRsLwPKm6A8mSmf362jw@mail.gmail.com>
 <CABH=_VTcn6zdqVUrfXp3ug_6A0W+=HRLR0rU2Ngp=eCL0y0tSg@mail.gmail.com>
 <FCE97019-C600-4D3E-881B-90927EFBF531@alchemistowl.org>
Message-ID: <CABH=_VRQ8ySwru5C4C0vOcQZwfHj-OjkbLp_q7bg22yY=n_txg@mail.gmail.com>

On 12/5/18, Arrigo Triulzi <arrigo at alchemistowl.org> 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: <alpine.BSF.2.21.9999.1812090700220.52810@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.1812090700220.52810@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1812090700220.52810@aneurin.horsfall.org>
Message-ID: <CAP6exYKNGA6163c4CeguZxVHEn0p_y0TARYhogeNbq_QQ=-=1A@mail.gmail.com>

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 <dave at horsfall.org> 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: <alpine.BSF.2.21.9999.1812090700220.52810@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1812090700220.52810@aneurin.horsfall.org>
Message-ID: <201812091619.wB9GJ0qB028870@freefriends.org>

Hi Dave.

We went through this last year:

Dave Horsfall <dave at horsfall.org> 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: <alpine.BSF.2.21.9999.1812101249470.52810@aneurin.horsfall.org>

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: <alpine.BSF.2.21.9999.1812101249470.52810@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1812101249470.52810@aneurin.horsfall.org>
Message-ID: <CAJfiPzxdgyfuchL9Ppu1ZwvjkrcG3Zvhg46gSgRFR1OXfHW9rw@mail.gmail.com>

On 09/12/2018, Dave Horsfall <dave at horsfall.org> 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: <CAHYQbfBnUoX9Eefe6xO_taa8Lg=5x2=c+FRZakod1sY_cffQfg@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181210/17bc0784/attachment.html>

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: <CAHYQbfBnUoX9Eefe6xO_taa8Lg=5x2=c+FRZakod1sY_cffQfg@mail.gmail.com>
References: <CAHYQbfBnUoX9Eefe6xO_taa8Lg=5x2=c+FRZakod1sY_cffQfg@mail.gmail.com>
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 <jacob.ritorto at gmail.com> 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: <CAHYQbfBnUoX9Eefe6xO_taa8Lg=5x2=c+FRZakod1sY_cffQfg@mail.gmail.com>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181210/c66ad8be/attachment.bin>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181210/77e1953c/attachment.bin>

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: <CANCZdfpW9fDU5oK4DjxF2MW5M_zSP+T_-u1dG0j=o4kP69OXuQ@mail.gmail.com>

On Mon, Dec 10, 2018 at 7:37 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181210/a3c6b79f/attachment.html>

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: <CAHYQbfBnUoX9Eefe6xO_taa8Lg=5x2=c+FRZakod1sY_cffQfg@mail.gmail.com>
 <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: <CAHYQbfBnUoX9Eefe6xO_taa8Lg=5x2=c+FRZakod1sY_cffQfg@mail.gmail.com>
 <940B149F-923C-4D12-B5D7-698DEA2E4F1F@ccc.com>
 <4c0c11da-1223-ab19-72ec-4effeeb63127@spamtrap.tnetconsulting.net>
 <7wk1kg34u0.fsf@junk.nocrew.org>
Message-ID: <CAC20D2N0sfVm-WNHu5yzE3W7sDS+WAQBshkk67aFC_vO+h31sQ@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181211/f5d1529c/attachment.html>

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 <clemc at ccc.com>

    > 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: <CAC20D2NxzMvta6vP6pqsghHKpSUqE3f0sCWCgYArNqtVpaeRwA@mail.gmail.com>

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 <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Clem Cole <clemc at ccc.com>
>
>     > 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181211/faafedf5/attachment.html>

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: <CAC20D2N0sfVm-WNHu5yzE3W7sDS+WAQBshkk67aFC_vO+h31sQ@mail.gmail.com>
 (Clem Cole's message of "Tue, 11 Dec 2018 10:28:32 -0500")
References: <CAHYQbfBnUoX9Eefe6xO_taa8Lg=5x2=c+FRZakod1sY_cffQfg@mail.gmail.com>
 <940B149F-923C-4D12-B5D7-698DEA2E4F1F@ccc.com>
 <4c0c11da-1223-ab19-72ec-4effeeb63127@spamtrap.tnetconsulting.net>
 <7wk1kg34u0.fsf@junk.nocrew.org>
 <CAC20D2N0sfVm-WNHu5yzE3W7sDS+WAQBshkk67aFC_vO+h31sQ@mail.gmail.com>
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: <CAC20D2MQWqAOXFe18n+NaEiwfv-w4adTMnRzzftEj3svf0dagg@mail.gmail.com>

On Tue, Dec 11, 2018 at 11:57 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181211/fb762777/attachment.html>

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: <CAC20D2N8MMzMR+tBfu4MMh+wPY4CMbqG4NEys6xdvnxPEzC=Tg@mail.gmail.com>

On Tue, Dec 11, 2018 at 1:43 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181211/924a10b5/attachment.html>

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: <CAC20D2N8MMzMR+tBfu4MMh+wPY4CMbqG4NEys6xdvnxPEzC=Tg@mail.gmail.com>
References: <20181211184316.014E618C089@mercury.lcs.mit.edu>
 <CAC20D2N8MMzMR+tBfu4MMh+wPY4CMbqG4NEys6xdvnxPEzC=Tg@mail.gmail.com>
Message-ID: <CAHYQbfAcYJDiMPxQ5xn7enk8jEPzcpspoiBp9BMwEb9zCEV-zA@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181211/0b29369d/attachment.html>

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: <A818805B-9545-4AE3-9943-02E51BB6E374@planet.nl>


> 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 <stdio.h>
#include <string.h>

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: <b893d815-4a1f-a5d3-87c8-d8ee23951fd0@bitsavers.org>

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: <b893d815-4a1f-a5d3-87c8-d8ee23951fd0@bitsavers.org>
References: <b893d815-4a1f-a5d3-87c8-d8ee23951fd0@bitsavers.org>
Message-ID: <alpine.NEB.2.20.1812192032530.9397@t1.m.reedmedia.net>

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: <b893d815-4a1f-a5d3-87c8-d8ee23951fd0@bitsavers.org>
References: <b893d815-4a1f-a5d3-87c8-d8ee23951fd0@bitsavers.org>
Message-ID: <0F9F50D5-8595-442C-B4F1-68AE3B6F373A@pobox.com>

> On 20 Dec 2018, at 12:46, Al Kossow <aek at bitsavers.org> 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: <CACNPpeZr1vjAk1zh_6-d=q_XZaLo5WDSXdhJKQ6xLH7rAtzxLg@mail.gmail.com>

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 <wkt at tuhs.org> 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: <bd626b01-b74a-14d9-c31e-6b5437464387@spamtrap.tnetconsulting.net>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181225/3882646c/attachment.bin>

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: <bd626b01-b74a-14d9-c31e-6b5437464387@spamtrap.tnetconsulting.net>
References: <bd626b01-b74a-14d9-c31e-6b5437464387@spamtrap.tnetconsulting.net>
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: <bd626b01-b74a-14d9-c31e-6b5437464387@spamtrap.tnetconsulting.net>
 <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:

<tytso at cwcc> {/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: <bd626b01-b74a-14d9-c31e-6b5437464387@spamtrap.tnetconsulting.net>
 <20181226020119.GF18199@mcvoy.com> <20181226044920.GB4158@mit.edu>
Message-ID: <ebc01026-94b1-351c-8c42-8521ae1e2084@spamtrap.tnetconsulting.net>

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?

> <tytso at cwcc> {/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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181226/392f02e8/attachment.bin>

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: <bd626b01-b74a-14d9-c31e-6b5437464387@spamtrap.tnetconsulting.net>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181226/8fb75997/attachment.bin>

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 <emu at e-bbes.com> 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: <CAC20D2OAdEZT2ncwY3s=TmPSGNG_jcs5dJ4qk+X3NKO88OG-3A@mail.gmail.com>
References: <20180826003127.GA18905@minnie.tuhs.org>
 <CAC20D2OAdEZT2ncwY3s=TmPSGNG_jcs5dJ4qk+X3NKO88OG-3A@mail.gmail.com>
Message-ID: <alpine.NEB.2.21.1812261547390.502@t1.m.reedmedia.net>

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 bogus@does.not.exist.com  Fri Dec 28 08:07:54 2018
From: bogus@does.not.exist.com ()
Date: Thu, 27 Dec 2018 22:07:54 -0000
Subject: No subject
Message-ID: <mailman.0.1545948478.26209.tuhs@minnie.tuhs.org>

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)

