From jnc at mercury.lcs.mit.edu  Thu Apr  4 22:56:02 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  4 Apr 2019 08:56:02 -0400 (EDT)
Subject: [TUHS] Retaining file-modified timestamps
Message-ID: <20190404125602.5D34518C0F4@mercury.lcs.mit.edu>

So, a while back I mentioned that I'd done tweaked versions of 'cp', 'mv',
'chmod' etc for V6 which retained the original modified date of a file (when
the actual contents were not changed). I had some requests for those versions,
which I have finally got around to checking and uploading (along with 'mvall',
which for some reason V6 didn't have). I've added them to a couple of my V6
pages:

  http://www.chiappa.net/~jnc/tech/V6Unix.html#mvall
  http://www.chiappa.net/~jnc/tech/ImprovingV6.html#FileWrite

Note (per the page) that the latter group all require the smdate() system
call, which was commented out in 'vanilla' V6 (because using it confused the
backup system); the page gives instructions on how to turn it back on.

       Noel

From wkt at tuhs.org  Wed Apr 10 17:54:26 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 10 Apr 2019 17:54:26 +1000
Subject: [TUHS] List ping
Message-ID: <20190410075426.GA11907@minnie.tuhs.org>

Just checking you are all still out there :-)
Cheers, Warren

From arnold at skeeve.com  Wed Apr 10 18:29:59 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 10 Apr 2019 02:29:59 -0600
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <201904100829.x3A8TxSH032335@freefriends.org>

Warren Toomey <wkt at tuhs.org> wrote:

> Just checking you are all still out there :-)
> Cheers, Warren

I'm here, at least!  :-)

Arnold

From angus at fairhaven.za.net  Wed Apr 10 19:17:30 2019
From: angus at fairhaven.za.net (Angus Robinson)
Date: Wed, 10 Apr 2019 11:17:30 +0200
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <CAE49LGnZnQJ3TTzNN0UU63tECzW+DwWYDgeqc0g2muDO=22tzQ@mail.gmail.com>

PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.049 ms


I am here :)


On Wed, Apr 10, 2019 at 9:55 AM Warren Toomey <wkt at tuhs.org> wrote:

> Just checking you are all still out there :-)
> Cheers, Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190410/04a61424/attachment.html>

From usotsuki at buric.co  Wed Apr 10 20:25:33 2019
From: usotsuki at buric.co (Steve Nickolas)
Date: Wed, 10 Apr 2019 06:25:33 -0400 (EDT)
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.02.1904100625210.17830@frieza.hoshinet.org>

On Wed, 10 Apr 2019, Warren Toomey wrote:

> Just checking you are all still out there :-)
> Cheers, Warren
>

Pong

-uso.

From jsteve at superglobalmegacorp.com  Wed Apr 10 20:48:06 2019
From: jsteve at superglobalmegacorp.com (Jason Stevens)
Date: Wed, 10 Apr 2019 18:48:06 +0800
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <7c018cd7-96c3-4c33-8215-208e56602c5e@PU1APC01FT052.eop-APC01.prod.protection.outlook.com>

Still alive!


From: Warren Toomey
Sent: Wednesday, April 10, 2019 3:55 PM
To: tuhs at tuhs.org
Subject: [TUHS] List ping

Just checking you are all still out there :-)
Cheers, Warren

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

From chet.ramey at case.edu  Wed Apr 10 22:11:10 2019
From: chet.ramey at case.edu (Chet Ramey)
Date: Wed, 10 Apr 2019 08:11:10 -0400
Subject: [TUHS] List ping
In-Reply-To: <201904100829.x3A8TxSH032335@freefriends.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
 <201904100829.x3A8TxSH032335@freefriends.org>
Message-ID: <1b384e1e-fb39-f83a-6d77-fa082083703e@case.edu>

On 4/10/19 4:29 AM, arnold at skeeve.com wrote:
> Warren Toomey <wkt at tuhs.org> wrote:
> 
>> Just checking you are all still out there :-)
>> Cheers, Warren
> 
> I'm here, at least!  :-)

It's quiet. Too quiet...


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/

From krewat at kilonet.net  Wed Apr 10 22:28:02 2019
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 10 Apr 2019 08:28:02 -0400
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <286ae744-7b04-f474-fe2c-38698010a671@kilonet.net>

Ping ACK

On 4/10/2019 3:54 AM, Warren Toomey wrote:
> Just checking you are all still out there :-)
> Cheers, Warren
>


From jcapp at anteil.com  Wed Apr 10 23:15:01 2019
From: jcapp at anteil.com (Jim Capp)
Date: Wed, 10 Apr 2019 08:15:01 -0500 (EST)
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <16695910.13861.1554902101754.JavaMail.root@zimbraanteil>

Alive and well! 


From: "Warren Toomey" <wkt at tuhs.org> 
To: tuhs at tuhs.org 
Sent: Wednesday, April 10, 2019 3:54:26 AM 
Subject: [TUHS] List ping 

Just checking you are all still out there :-) 
Cheers, Warren 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190410/d0db19e5/attachment.html>

From gregg.drwho8 at gmail.com  Wed Apr 10 23:26:42 2019
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Wed, 10 Apr 2019 09:26:42 -0400
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <CAC5iaNGyjsOjGEU4Ch7QjxK0swayx99uBmDUQUoc2rcBvzVyOw@mail.gmail.com>

Hello!
I'm still here. Working on a newer and stranger project for an emulated PDP-11..
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Wed, Apr 10, 2019 at 3:55 AM Warren Toomey <wkt at tuhs.org> wrote:
>
> Just checking you are all still out there :-)
> Cheers, Warren

From cym224 at gmail.com  Wed Apr 10 23:41:32 2019
From: cym224 at gmail.com (Nemo)
Date: Wed, 10 Apr 2019 09:41:32 -0400
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <CAJfiPzyiTxXE3vN9fGemvPGrAKbHSg7a2SprHQLTxHq_cjfZxg@mail.gmail.com>

On 10/04/2019, Warren Toomey <wkt at tuhs.org> wrote:
> Just checking you are all still out there :-)
> Cheers, Warren

Well, this is not "Forever September"?  #6-)

I just finished reading a fascinating article on Inferno and was most
amused by the comment in Rob Pike's biblio note at the end.

N.

From kix at kix.es  Thu Apr 11 00:26:36 2019
From: kix at kix.es (=?UTF-8?Q?Rodolfo_Garc=C3=ADa_Pe=C3=B1as_=28kix=29?=)
Date: Wed, 10 Apr 2019 14:26:36 +0000
Subject: [TUHS] List ping
In-Reply-To: <CAJfiPzyiTxXE3vN9fGemvPGrAKbHSg7a2SprHQLTxHq_cjfZxg@mail.gmail.com>
References: <20190410075426.GA11907@minnie.tuhs.org>
 <CAJfiPzyiTxXE3vN9fGemvPGrAKbHSg7a2SprHQLTxHq_cjfZxg@mail.gmail.com>
Message-ID: <1JOIuGgWE2KzKEm6Qr_fZLC82MT-p-iyZe4FqBpNPLMhBKNVmD_urkDONg5Gk5DlmjQWhdxAGMCe32hxczg-P1skbe_2fnIS8cAY4WiSBD0=@kix.es>

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, 10 de April de 2019 15:41, Nemo <cym224 at gmail.com> wrote:

> On 10/04/2019, Warren Toomey wkt at tuhs.org wrote:
>
> > Just checking you are all still out there :-)
> > Cheers, Warren
>
> Well, this is not "Forever September"? #6-)
>
> I just finished reading a fascinating article on Inferno and was most
> amused by the comment in Rob Pike's biblio note at the end.
>
> N.

ICMP Type=0, Code=0, Data="All is fine here!"


Regards,
Rodolfo.

From spedraja at gmail.com  Thu Apr 11 01:14:51 2019
From: spedraja at gmail.com (SPC)
Date: Wed, 10 Apr 2019 17:14:51 +0200
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <CACytpF8O7hfOCWE55Wy+T4e10ogUG3x2EDUvjdmbEYGbZsSLSA@mail.gmail.com>

Hi There!

Sergio

El mié., 10 abr. 2019 9:55, Warren Toomey <wkt at tuhs.org> escribió:

> Just checking you are all still out there :-)
> Cheers, Warren
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190410/1a16da40/attachment.html>

From david at kdbarto.org  Thu Apr 11 01:17:08 2019
From: david at kdbarto.org (David)
Date: Wed, 10 Apr 2019 08:17:08 -0700
Subject: [TUHS] List ping
In-Reply-To: <CACytpF8O7hfOCWE55Wy+T4e10ogUG3x2EDUvjdmbEYGbZsSLSA@mail.gmail.com>
References: <20190410075426.GA11907@minnie.tuhs.org>
 <CACytpF8O7hfOCWE55Wy+T4e10ogUG3x2EDUvjdmbEYGbZsSLSA@mail.gmail.com>
Message-ID: <E7D23321-3FB2-4A02-A295-CFDD6B829F4E@kdbarto.org>

It has been fun watching the replies to the ping.

timeout.

	David

> On Apr 10, 2019, at 8:14 AM, SPC <spedraja at gmail.com> wrote:
> 
> Hi There!
> 
> Sergio
> 
> El mié., 10 abr. 2019 9:55, Warren Toomey <wkt at tuhs.org <mailto:wkt at tuhs.org>> escribió:
> Just checking you are all still out there :-)
> Cheers, Warren

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

From jnc at mercury.lcs.mit.edu  Thu Apr 11 01:57:35 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 10 Apr 2019 11:57:35 -0400 (EDT)
Subject: [TUHS] List ping
Message-ID: <20190410155735.9E47518C097@mercury.lcs.mit.edu>

This thread brings to mind a wonderful saying which I just saw in another forum:

"A wise man speaks when he feels he has something to say - a fool speaks when
he feels he has to say something."

And to reply in advance to the 'but I did't realize so many other people had
sent in replies' - try scanning your emailbox before replying to messages to a
large list.

S/N is to be hallowed.

    Noel


From cym224 at gmail.com  Thu Apr 11 02:01:36 2019
From: cym224 at gmail.com (Nemo Nusquam)
Date: Wed, 10 Apr 2019 12:01:36 -0400
Subject: [TUHS] List ping
In-Reply-To: <201904101359.x3ADxYqV014484@freefriends.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
 <CAJfiPzyiTxXE3vN9fGemvPGrAKbHSg7a2SprHQLTxHq_cjfZxg@mail.gmail.com>
 <201904101359.x3ADxYqV014484@freefriends.org>
Message-ID: <1d227f27-eacd-fdb7-5340-92ad7f2b550f@gmail.com>

On 04/10/19 09:59, arnold at skeeve.com wrote:
> Nemo <cym224 at gmail.com> wrote:
>> On 10/04/2019, Warren Toomey <wkt at tuhs.org> wrote:
>>> Just checking you are all still out there :-) Cheers, Warren 
>> Well, this is not "Forever September"? #6-) I just finished reading a 
>> fascinating article on Inferno and was most amused by the comment in 
>> Rob Pike's biblio note at the end. N. 
> So, please share article link and comment with the list? Thanks, Arnold

Apologies -- I found it here: 
https://ieeexplore.ieee.org/document/6772868/ Bell Labs Tech. J., Vol. 
2, Iss. 1, 1997 (or here 
https://onlinelibrary.wiley.com/doi/pdf/10.1002/bltj.2028 but there must 
an open version available by now).

Pike wrote: "He has never written a program that uses cursor addressing."

N.

From patbarron at acm.org  Thu Apr 11 02:51:40 2019
From: patbarron at acm.org (Pat Barron)
Date: Wed, 10 Apr 2019 12:51:40 -0400 (EDT)
Subject: [TUHS] Paper discussing Unix boot process?
Message-ID: <alpine.LFD.2.21.1904101246310.2133@booboo.lectroid.com>

Long ago, I could swear I'd read a paper (or a TM, or something) that
described the process of a Unix system booting.  It presented a timeline
describing the sequence of how the boot blocks are loaded, the kernel
is loaded, MMU turned on, etc.

However, other than that, I can't recall a thing about it - can't remember
the title, the author, or where I found it.  I don't remember if it talked
about this process on a Bell Labs Unix system, or a BSD system (though it
had to be one of those - either 7th Edition or BSD).  The timeframe was
probably mid to late 1980's, though I could be wrong about that.

Does this ring a bell with anyone?  I really wish I could find it again...

--Pat.

From mutiny.mutiny at india.com  Thu Apr 11 03:07:09 2019
From: mutiny.mutiny at india.com (Donald ODona)
Date: Wed, 10 Apr 2019 17:07:09 +0000 (UTC)
Subject: [TUHS] List ping
In-Reply-To: <16695910.13861.1554902101754.JavaMail.root@zimbraanteil>
References: <16695910.13861.1554902101754.JavaMail.root@zimbraanteil>
Message-ID: <402860558.5887.1554916029908.JavaMail.tomcat@india-live-be02>

Hello!
I'm still here. 

> From: "Warren Toomey" <wkt at tuhs.org> 
> To: tuhs at tuhs.org 
> Sent: Wednesday, April 10, 2019 3:54:26 AM 
> Subject: [TUHS] List ping 
> 
> Just checking you are all still out there :-) 
> Cheers, Warren 

From alan at alanlee.org  Thu Apr 11 03:13:20 2019
From: alan at alanlee.org (alan at alanlee.org)
Date: Wed, 10 Apr 2019 13:13:20 -0400
Subject: [TUHS] List ping
In-Reply-To: <20190410075426.GA11907@minnie.tuhs.org>
References: <20190410075426.GA11907@minnie.tuhs.org>
Message-ID: <457ccecce160e92511694c848f5801b6@alanlee.org>


My response depends on if this is a UDP or ICMP ping.

-Alan

On 2019-04-10 03:54, Warren Toomey wrote:
> Just checking you are all still out there :-)
> Cheers, Warren

From fair-tuhs at netbsd.org  Thu Apr 11 03:20:14 2019
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 10 Apr 2019 10:20:14 -0700
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <alpine.LFD.2.21.1904101246310.2133@booboo.lectroid.com>
Message-ID: <17458.1554916814@cesium.clock.org>

Pat,
	Any such description is either going to be very hardware/system specific, or vague to the point of uselessness. The experience of the NetBSD community, which prides itself on extreme portability and working around broken or  ... let's say "incomplete" vendor firmware, is that such things are highly system-specific.

The vague description is easy:

	some booter or firmware loads the kernel into RAM,

	the kernel initializes the MMU and the rest of the processor(s),
	devices are somehow probed or listed and device drivers called to
	initialize minimally necessary I/O devices (console, data storage so
	you can mount / (root)),

	a process is created, and /sbin/init is exec'd.

Details of firmware or booter provided environment and parameters to the kernel vary a lot; thus that famously small-ish percentage of any Unix kernel that is written in assembler for the processor involved, rather than C.

See also

https://www.quora.com/Are-bootloaders-like-GRUB-and-LILO-hardware-specific/answer/Erik-Fair

https://www.quora.com/What-is-a-concise-explanation-for-the-UNIX-bootstrap-process/answer/Erik-Fair

	Erik

From jon at fourwinds.com  Thu Apr 11 03:47:38 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 10 Apr 2019 10:47:38 -0700
Subject: [TUHS] Does anybody have this book and can look for something for
 me?
Message-ID: <201904101747.x3AHlcN0003707@darkstar.fourwinds.com>

OK, something that's not a ping :-)

I'm trying to track down the author of a cartoon that I'd like to use
in my book so that I can try to get permission.  Last one that I need!

It's a cartoon that I only have on paper and don't know where it came
from.  It has two frames, then and now, the first with a bunch of
cavemen grunting awk, grep, mkdir, yank, the second with a bunch of
people sitting at computers uttering the same.

I recently stumbled upon something that said that these were in a book
called "UNIX Primer PLUS".  Anybody have a copy of that?  If so, can
you please check to see if that's the original or whether they got it
from somewhere else?

Thanks,
	Jon

From patbarron at acm.org  Thu Apr 11 03:56:28 2019
From: patbarron at acm.org (Pat Barron)
Date: Wed, 10 Apr 2019 13:56:28 -0400 (EDT)
Subject: [TUHS] Does anybody have this book and can look for something
 for me?
Message-ID: <alpine.LFD.2.21.1904101353390.2402@booboo.lectroid.com>

This book can apparently be "borrowed" from the Internet Archive.  I'm not 
sure how they do that, haven't tried to, I just see it says you need to 
log in to borrow the book for 14 days.

https://archive.org/details/unixprimerplus00wait

--Pat.

From crossd at gmail.com  Thu Apr 11 03:57:17 2019
From: crossd at gmail.com (Dan Cross)
Date: Wed, 10 Apr 2019 13:57:17 -0400
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <alpine.LFD.2.21.1904101246310.2133@booboo.lectroid.com>
References: <alpine.LFD.2.21.1904101246310.2133@booboo.lectroid.com>
Message-ID: <CAEoi9W68_8VEy7_i8i0B3LPr9p_kMSgdm=2ay3NrFNApfwekTQ@mail.gmail.com>

On Wed, Apr 10, 2019 at 1:00 PM Pat Barron <patbarron at acm.org> wrote:

> Long ago, I could swear I'd read a paper (or a TM, or something) that
> described the process of a Unix system booting.  It presented a timeline
> describing the sequence of how the boot blocks are loaded, the kernel
> is loaded, MMU turned on, etc.
>
> However, other than that, I can't recall a thing about it - can't remember
> the title, the author, or where I found it.  I don't remember if it talked
> about this process on a Bell Labs Unix system, or a BSD system (though it
> had to be one of those - either 7th Edition or BSD).  The timeframe was
> probably mid to late 1980's, though I could be wrong about that.
>
> Does this ring a bell with anyone?  I really wish I could find it again...
>

The book "The Design and Implementation of the 4.3BSD Unix Operating
System" by Leffler et al has a lengthy explanation of booting 4.3BSD on the
VAX towards the beginning of the book. Could that be it? I thought I had a
copy in my office, but don't see it on my bookshelf at the moment. Bach's,
"The Design of the Unix Operating System" contains a brief and very
high-level overview in the chapter on process control, but I recall Leffler
et al having significantly greater detail.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190410/0abc095b/attachment.html>

From patbarron at acm.org  Thu Apr 11 04:02:50 2019
From: patbarron at acm.org (Pat Barron)
Date: Wed, 10 Apr 2019 14:02:50 -0400 (EDT)
Subject: [TUHS] Paper discussing Unix boot process?
Message-ID: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>

The paper I am thinking of (gee, I wish I could remember any other details 
about it...) was *very* detailed and specific, and was hardware-specific 
to either the PDP-11 or VAX.  It would not at all be applicable to Linux 
or any kind of modern OS.

I am wondering if it is something in the Leffler et al book, I'll have to 
go back and review that.  I'll have to find my copy of it first...

--Pat.

From jon at fourwinds.com  Thu Apr 11 04:12:19 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Wed, 10 Apr 2019 11:12:19 -0700
Subject: [TUHS] Does anybody have this book and can look for something for
 me? - solved
Message-ID: <201904101812.x3AICJ1W007634@darkstar.fourwinds.com>

Thanks to Pat, I looked at the book at the Internet Archive and it is there.

From fair-tuhs at netbsd.org  Thu Apr 11 04:14:28 2019
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 10 Apr 2019 11:14:28 -0700
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
Message-ID: <14453.1554920068@cesium.clock.org>

That might well Chapter 6 "Getting Started" of the Lions Commentary on v6 Unix for the PDP-11. My nicely bound copy was published by Peer-to-Peer Communications in 1996.

https://www.peerllc.com/?option=com_content&task=view&id&ItemidD

I'm not sure I know where my samizdat copy from UCB in the early 1980s is ...

	Erik

From clemc at ccc.com  Thu Apr 11 04:28:13 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 10 Apr 2019 14:28:13 -0400
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <14453.1554920068@cesium.clock.org>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
Message-ID: <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>

Lion's chapter 6, has some stuff and exact but might not be what you are
remembering,   Chapter 13 of the BSD book is 'system startup' and
more general than the Lions description.   The other place I would suggest
looking is the three DDJ articles Bill and Lynn Jolitz wrote; although he
might have talked about the 386 specifics, not the vaxen/11.
ᐧ

On Wed, Apr 10, 2019 at 2:15 PM Erik E. Fair <fair-tuhs at netbsd.org> wrote:

> That might well Chapter 6 "Getting Started" of the Lions Commentary on v6
> Unix for the PDP-11. My nicely bound copy was published by Peer-to-Peer
> Communications in 1996.
>
> https://www.peerllc.com/?optioncom_content&taskview&id &ItemidD
>
> I'm not sure I know where my samizdat copy from UCB in the early 1980s is
> ...
>
>         Erik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190410/4201ff6e/attachment.html>

From ewayte at gmail.com  Thu Apr 11 04:35:14 2019
From: ewayte at gmail.com (Eric Wayte)
Date: Wed, 10 Apr 2019 14:35:14 -0400
Subject: [TUHS] Does anybody have this book and can look for something
 for me?
In-Reply-To: <alpine.LFD.2.21.1904101353390.2402@booboo.lectroid.com>
References: <alpine.LFD.2.21.1904101353390.2402@booboo.lectroid.com>
Message-ID: <CAJc6K3V1mR33V7FuW7icoE_+psCXeqoKb-hw0rcO0zqhdUrRdA@mail.gmail.com>

The cartoonist was Bob Johnson.  That cartoon is on page 343.

The UNIX Primer Plus was published by Sams in 1983...

On Wed, Apr 10, 2019 at 1:57 PM Pat Barron <patbarron at acm.org> wrote:

> This book can apparently be "borrowed" from the Internet Archive.  I'm not
> sure how they do that, haven't tried to, I just see it says you need to
> log in to borrow the book for 14 days.
>
> https://archive.org/details/unixprimerplus00wait
>
> --Pat.
>


-- 
Eric Wayte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190410/22328a9a/attachment.html>

From bakul at bitblocks.com  Thu Apr 11 05:05:53 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 10 Apr 2019 12:05:53 -0700
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
 <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
Message-ID: <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>

https://github.com/kanner/lions-book <https://github.com/kanner/lions-book>

has the TeX version of the book. You can probably find a PDF version online.

The 4.3 BSD book may be a better bet. 

> On Apr 10, 2019, at 11:28 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> Lion's chapter 6, has some stuff and exact but might not be what you are remembering,   Chapter 13 of the BSD book is 'system startup' and more general than the Lions description.   The other place I would suggest looking is the three DDJ articles Bill and Lynn Jolitz wrote; although he might have talked about the 386 specifics, not the vaxen/11.         
> ᐧ
> 
> On Wed, Apr 10, 2019 at 2:15 PM Erik E. Fair <fair-tuhs at netbsd.org <mailto:fair-tuhs at netbsd.org>> wrote:
> That might well Chapter 6 "Getting Started" of the Lions Commentary on v6 Unix for the PDP-11. My nicely bound copy was published by Peer-to-Peer Communications in 1996.
> 
> https://www.peerllc.com/?optioncom_content&taskview&id <https://www.peerllc.com/?optioncom_content&taskview&id> &ItemidD
> 
> I'm not sure I know where my samizdat copy from UCB in the early 1980s is ...
> 
>         Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190410/92491c00/attachment-0001.html>

From steffen at sdaoden.eu  Thu Apr 11 07:36:59 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 10 Apr 2019 23:36:59 +0200
Subject: [TUHS] List ping
In-Reply-To: <20190410155735.9E47518C097@mercury.lcs.mit.edu>
References: <20190410155735.9E47518C097@mercury.lcs.mit.edu>
Message-ID: <20190410213659.Y9lu5%steffen@sdaoden.eu>

Noel Chiappa wrote in <20190410155735.9E47518C097 at mercury.lcs.mit.edu>:
 |This thread brings to mind a wonderful saying which I just saw in another \
 |forum:
 |
 |"A wise man speaks when he feels he has something to say - a fool speaks \
 |when
 |he feels he has to say something."

Tucholsky was "even one step further" (shortly before his suicide):

  https://de.wikipedia.org/wiki/Datei:Eine_Treppe_(Tucholskys_Sudelbuch).jpg

 |And to reply in advance to the 'but I did't realize so many other people \
 |had
 |sent in replies' - try scanning your emailbox before replying to messages \
 |to a
 |large list.
 |
 |S/N is to be hallowed.
 |
 |    Noel
 |
 --End of <20190410155735.9E47518C097 at mercury.lcs.mit.edu>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From clemc at ccc.com  Thu Apr 11 08:24:56 2019
From: clemc at ccc.com (Clem Cole)
Date: Wed, 10 Apr 2019 18:24:56 -0400
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
 <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
 <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>
Message-ID: <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>

http://www.lemis.com/grog/Documentation/Lions/index.php is the Lions book
including PS and PDF and in the original troff thankfully.
[Why someone would convert it to tex is a little beyond me].

On Wed, Apr 10, 2019 at 3:06 PM Bakul Shah <bakul at bitblocks.com> wrote:

> https://github.com/kanner/lions-book
>
> has the TeX version of the book. You can probably find a PDF version
> online.
>
> The 4.3 BSD book may be a better bet.
>
> On Apr 10, 2019, at 11:28 AM, Clem Cole <clemc at ccc.com> wrote:
>
> Lion's chapter 6, has some stuff and exact but might not be what you are
> remembering,   Chapter 13 of the BSD book is 'system startup' and
> more general than the Lions description.   The other place I would suggest
> looking is the three DDJ articles Bill and Lynn Jolitz wrote; although he
> might have talked about the 386 specifics, not the vaxen/11.
> ᐧ
>
> On Wed, Apr 10, 2019 at 2:15 PM Erik E. Fair <fair-tuhs at netbsd.org> wrote:
>
>> That might well Chapter 6 "Getting Started" of the Lions Commentary on v6
>> Unix for the PDP-11. My nicely bound copy was published by Peer-to-Peer
>> Communications in 1996.
>>
>> https://www.peerllc.com/?optioncom_content&taskview&id &ItemidD
>>
>> I'm not sure I know where my samizdat copy from UCB in the early 1980s is
>> ...
>>
>>         Erik
>>
>
> ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190410/866f5c3e/attachment.html>

From wkt at tuhs.org  Thu Apr 11 08:53:42 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 11 Apr 2019 08:53:42 +1000
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
 <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
 <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>
 <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>
Message-ID: <20190410225342.GA2279@minnie.tuhs.org>

On Wed, Apr 10, 2019 at 06:24:56PM -0400, Clem Cole wrote:
>    http://www.lemis.com/grog/Documentation/Lions/index.php is the Lions
>    book including PS and PDF and in the original troff thankfully.
>    [Why someone would convert it to tex is a little beyond me].

That's all I knew at the time :-)
	Warren

From rich.salz at gmail.com  Thu Apr 11 09:06:23 2019
From: rich.salz at gmail.com (Richard Salz)
Date: Wed, 10 Apr 2019 19:06:23 -0400
Subject: [TUHS] "Fork considered harmful"
Message-ID: <CAFH29tq4oKm=DU+w=Vw=g74xxDGo3w9od1crDyc7Ukf8Miwm3g@mail.gmail.com>

Any view on this?
https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190410/7cb49094/attachment.html>

From doug at cs.dartmouth.edu  Thu Apr 11 08:17:10 2019
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 10 Apr 2019 18:17:10 -0400
Subject: [TUHS] TUHS Digest, Vol 41, Issue 2
In-Reply-To: <mailman.5.1554923164.1111.tuhs@minnie.tuhs.org>
References: <mailman.5.1554923164.1111.tuhs@minnie.tuhs.org>
Message-ID: <201904102217.x3AMHAUA097159@tahoe.cs.Dartmouth.EDU>

here

From bakul at bitblocks.com  Thu Apr 11 09:19:47 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 10 Apr 2019 16:19:47 -0700
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
 <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
 <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>
 <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>
Message-ID: <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com>

On Apr 10, 2019, at 3:24 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> http://www.lemis.com/grog/Documentation/Lions/index.php is the Lions book including PS and PDF and in the original troff thankfully.

Sorry to disappoint you but it's the same LaTeX source.

> [Why someone would convert it to tex is a little beyond me].


May be someone will be inspired enough to convert this to troff?


From bakul at bitblocks.com  Thu Apr 11 09:24:52 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Wed, 10 Apr 2019 16:24:52 -0700
Subject: [TUHS] "Fork considered harmful"
In-Reply-To: <CAFH29tq4oKm=DU+w=Vw=g74xxDGo3w9od1crDyc7Ukf8Miwm3g@mail.gmail.com>
References: <CAFH29tq4oKm=DU+w=Vw=g74xxDGo3w9od1crDyc7Ukf8Miwm3g@mail.gmail.com>
Message-ID: <A9713625-715B-42B1-8FFA-E6A481A69E11@bitblocks.com>

On Apr 10, 2019, at 4:06 PM, Richard Salz <rich.salz at gmail.com> wrote:
> 
> Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/
> 

FWIW, my view is that any unix evolution that complicates
fork() is/has probably going/gone in the wrong direction.



From ggm at algebras.org  Thu Apr 11 09:37:44 2019
From: ggm at algebras.org (George Michaelson)
Date: Thu, 11 Apr 2019 09:37:44 +1000
Subject: [TUHS] "Fork considered harmful"
In-Reply-To: <A9713625-715B-42B1-8FFA-E6A481A69E11@bitblocks.com>
References: <CAFH29tq4oKm=DU+w=Vw=g74xxDGo3w9od1crDyc7Ukf8Miwm3g@mail.gmail.com>
 <A9713625-715B-42B1-8FFA-E6A481A69E11@bitblocks.com>
Message-ID: <CAKr6gn3-qgbsDaqvr5n-Ojaa9CS2Y+PnSD2AjNbu+9-bCX1TMA@mail.gmail.com>

I don't pay much attention to this stuff any more but I do recall
being absolutely *astonished* how complex the re-binding of process to
inherited I/O was in a lot of systems in the 1980s

fork() and the various exec() flavours had this single compelling
story for me: the stdin/stdout/stderr *and all other open I/O* was
inherited across the process boundary. This alone made writing code
significantly easier.

I did briefly find myself in a world where it wasn't clear where an
X.25 binding was (this was Yorkbox, and then the UCL-CS version of the
same idea, and the per-ISODE OSI stack work) on an FD, but it wasn't
immediately clear which.

We wound up passing a binary-encoded text blob in the execve() info to
"inform" the child what it was meant to look for in file descriptors,
to (re)bind as the X.25 FD to work with. It felt really creepy to do
this, but we simply couldn't find a way round it.

Other systems "for your convenience" felt it was far, far kinder to
either completely obscure the binding of I/O or even terminate it.
Truly bizarre.

Actual runtime cost to mechanise the COW state. and the other bits of
kernel state, and instantiate the process, and fiddly bits were stuff
I simply didn't think about much. it felt like some giant bcopy() call
in the kernel did something in VM aware memory addressing to make a
"copy" of something, which then ran, because it existed. As if you
could clone a vertial slice of the layers of the onion and simply
carry on, irrespective.

But if somebody said VMS or the nascent Microsoft kernel was "better"
I would (and probably still would) be skeptical.

Hard to beat simple.

On Thu, Apr 11, 2019 at 9:25 AM Bakul Shah <bakul at bitblocks.com> wrote:
>
> On Apr 10, 2019, at 4:06 PM, Richard Salz <rich.salz at gmail.com> wrote:
> >
> > Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/
> >
>
> FWIW, my view is that any unix evolution that complicates
> fork() is/has probably going/gone in the wrong direction.
>
>

From steffen at sdaoden.eu  Thu Apr 11 09:35:31 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 11 Apr 2019 01:35:31 +0200
Subject: [TUHS] TUHS Digest, Vol 41, Issue 2
In-Reply-To: <201904102217.x3AMHAUA097159@tahoe.cs.Dartmouth.EDU>
References: <mailman.5.1554923164.1111.tuhs@minnie.tuhs.org>
 <201904102217.x3AMHAUA097159@tahoe.cs.Dartmouth.EDU>
Message-ID: <20190410233531.xZ02Y%steffen@sdaoden.eu>

Doug McIlroy wrote in <201904102217.x3AMHAUA097159 at tahoe.cs.Dartmouth.EDU>:
 |here

Please let me say it once but heartily: good fortune for us.

 --End of <201904102217.x3AMHAUA097159 at tahoe.cs.Dartmouth.EDU>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From patbarron at acm.org  Thu Apr 11 11:06:56 2019
From: patbarron at acm.org (Pat Barron)
Date: Wed, 10 Apr 2019 21:06:56 -0400 (EDT)
Subject: [TUHS] Paper discussing Unix boot process?
Message-ID: <alpine.LFD.2.21.1904102046190.2402@booboo.lectroid.com>

The more I think about this, the more I'm sure I'm barking up the wrong 
tree...

>From bits and pieces I've been able to recall, the thing I am looking for 
was not about Unix - it was about TOPS-20.  It was a timeline of the 
system bootstrap activities from power-on to the point where users could 
log in.  I still don't remember where I found it originally, but at least 
now I'm pretty sure I've been looking in all the wrong places...  I 
believe it originated at CMU, but I don't know for sure that that's where 
I originally located it.

The actual problem I'm trying to solve is, at this point in my 
professional career, I'm starting to interact with a lot of people (even 
experienced software developers) who just have no clue of what has to 
happen to get a computer from the point of "power-on" to the point where 
they can actually use it to do things.  This makes me sad...  So, I'm 
looking for something that I can point these people to that could clue 
them in...  I think the whole bootstrap process is useful to understand 
for a lot of reasons, partly because it makes you think about all the 
little fiddly details that have to be attended to to make the computer do 
what you want - when I was first learning about this, I remember being 
particularly fascinated by what had to happen to prepare for that moment 
at which you turn on the MMU, to make sure that the system continues 
executing in a place you expect it to, in the right processor mode.  I 
know most people that I interact with are using Linux or Windows on 
Intel-architecture machines, but the boot process for Unix on the PDP-10 
or VAX (or even TOPS-20 on the PDP-10) I thought would be a much simpler 
thing to understand.  Though maybe that's the wrong thought process, maybe 
I should just find something related to Linux that is comparable (even 
though I think it's more complicated).

While searching, I also came across a decent presentation by a friend of 
mine who teaches at CMU, and discusses hardware that people probably 
actually work with right now, but I think it would be best consumed along 
with the actual lecture that it goes with.

http://www.cs.cmu.edu/~410-f08/lectures/L20_Bootstrap.pdf

Maybe I'll find what I was originally looking for at some point, but after 
spinning on this for most of the day, I don't think it's related to 
Unix...

--Pat.

From charles.unix.pro at gmail.com  Thu Apr 11 11:27:28 2019
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Wed, 10 Apr 2019 18:27:28 -0700
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <alpine.LFD.2.21.1904102046190.2402@booboo.lectroid.com>
References: <alpine.LFD.2.21.1904102046190.2402@booboo.lectroid.com>
Message-ID: <CANV78LS2yPGXA5xV7c4K4yNFzLDMU5Behee7onXdo1QcQtYJQw@mail.gmail.com>

On Wed, Apr 10, 2019 at 6:07 PM Pat Barron <patbarron at acm.org> wrote:

>
>
> Maybe I'll find what I was originally looking for at some point, but after
> spinning on this for most of the day, I don't think it's related to
> Unix...
>

The Multics System Initialization Program Logic Manual. 139 pages of
somewhat detailed information. There was a time during the dps8/m emulator
development when I could have told you what page and line the emulator had
made it to that day.

http://bitsavers.trailing-edge.com/pdf/honeywell/multics/AN70-1_systemInitPLM_May84.pdf
<http://bitsavers.trailing-edge.com/pdf/honeywell/multics/AN70-1_systemInitPLM_May84.pdf>

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

From grog at lemis.com  Thu Apr 11 11:45:39 2019
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 11 Apr 2019 11:45:39 +1000
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <20190410225342.GA2279@minnie.tuhs.org>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
 <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
 <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>
 <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>
 <20190410225342.GA2279@minnie.tuhs.org>
Message-ID: <20190411014539.GO55046@eureka.lemis.com>

On Thursday, 11 April 2019 at  8:53:42 +1000, Warren Toomey wrote:
> On Wed, Apr 10, 2019 at 06:24:56PM -0400, Clem Cole wrote:
>>    http://www.lemis.com/grog/Documentation/Lions/index.php is the Lions
>>    book including PS and PDF and in the original troff thankfully.
>>    [Why someone would convert it to tex is a little beyond me].
>
> That's all I knew at the time :-)

A bit of background: the sources come from a uuencoded posting on
alt.folklore.computers in May 1994 (almost exactly 25 years ago;
that's interesting in context of 50 years of Unix).  It was titled
"Leo's notes", and I grabbed them before they disappeared.  I didn't
meet Warren in person until some years later.

The source comes from scans that Warren made, and they contain typical
scan errors.  I have a number of patches backed up that I should
apply; I'll send another message when I have.

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/20190411/aad4b4c2/attachment.sig>

From fair-tuhs at netbsd.org  Thu Apr 11 12:26:30 2019
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 10 Apr 2019 19:26:30 -0700
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <alpine.LFD.2.21.1904102046190.2402@booboo.lectroid.com>
Message-ID: <10149.1554949590@cesium.clock.org>

Pat,

I still know a few people from the 36-bit world so I could put you in touch, but if you really want people to understand primitives, you might want to start with a simpler model, e.g., 16-bit minicomputers like the DEC PDP-11 (smaller models), the DG Nova, perhaps the original mc68000 (no MMU or FPU on-chip in that).

Once you add MMUs to the picture, life gets a lot more complicated, and I'm pretty sure the typical applications programmer doesn't really need to know that class of details, but going for PDP-10 (more "mainframe-ish" system) is going to take them there.

	Erik

From fair-tuhs at netbsd.org  Thu Apr 11 12:37:05 2019
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 10 Apr 2019 19:37:05 -0700
Subject: [TUHS] Unix filesystem semantics history - files with holes
Message-ID: <3993.1554950225@cesium.clock.org>

When did the Unix filesystem add the semantics for "files with holes" (large,
sparse files)?

Just an idle question that was sparked by a conversation I had today.

	Erik <fair at clock.org>

From fabio at esse.ch  Thu Apr 11 14:52:08 2019
From: fabio at esse.ch (Fabio Scotoni)
Date: Thu, 11 Apr 2019 06:52:08 +0200
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
 <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
 <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>
 <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>
 <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com>
Message-ID: <7b575d14-270c-1d3a-7419-0329ffb42669@esse.ch>

On 4/11/19 1:19 AM, Bakul Shah wrote:
> On Apr 10, 2019, at 3:24 PM, Clem Cole <clemc at ccc.com> wrote:
>>
>> [...] is the Lions book including PS and PDF and in the original troff thankfully.
> 
> Sorry to disappoint you but it's the same LaTeX source.
> 
>> [Why someone would convert it to tex is a little beyond me].
> 
> 
> May be someone will be inspired enough to convert this to troff?
> 
> 

Not to be too negative, but converting it to troff would be somewhat of
an effort; however, the gains for that seem to be comparatively small.
It would be a change from one language to another, neither of which are
a 1:1 copy of the original.
Even if you had the original troff sources of the book,
groff, heirloom-troff and Plan9 ditroff probably all have line breaking
and character positioning algorithms that don't match the original troff
at the time.

If someone were to undertake this troff endeavor, aiming for a perfect
recreation would be the most beneficial (yet also most difficult) thing
to do.
I've never seen the original commentary, but I'll assume that it used a
homebrewed set of macros.
Thus, the first step would be to reverse engineer the troff macros used
to typeset the book.
Then the TeX sources would need to be converted to those troff macros;
this can possibly be automated entirely.
Then the matching version of troff would need to be used to typeset it
(likely via apout and V6 or V7 troff).
Finally, the C/A/T typesetter output would need to be converted to
PostScript or PDF (either Adobe's psroff or Chris Lewis's psroff from
comp.unix.sources can likely help with that; I got Lewis's psroff to
work a while ago, but it's pretty brittle).

From ron at ronnatalie.com  Thu Apr 11 15:28:57 2019
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 11 Apr 2019 01:28:57 -0400
Subject: [TUHS] Unix filesystem semantics history - files with holes
In-Reply-To: <3993.1554950225@cesium.clock.org>
References: <3993.1554950225@cesium.clock.org>
Message-ID: <0FA98B50-9800-48A8-8B19-D070D17767AF@ronnatalie.com>

Define large?  It appears that filesystems going back to Research V4 supported sparse files.    The maximum file size went up from 2**24 in V6 to 2**32 in V7, and then broke that barrier in several of the subsequent file systems.

> On Apr 10, 2019, at 10:37 PM, Erik E. Fair <fair-tuhs at netbsd.org> wrote:
> 
> When did the Unix filesystem add the semantics for "files with holes" (large,
> sparse files)?
> 
> Just an idle question that was sparked by a conversation I had today.
> 
> 	Erik <fair at clock.org>


From dot at dotat.at  Thu Apr 11 21:38:29 2019
From: dot at dotat.at (Tony Finch)
Date: Thu, 11 Apr 2019 12:38:29 +0100
Subject: [TUHS] "Fork considered harmful"
In-Reply-To: <CAKr6gn3-qgbsDaqvr5n-Ojaa9CS2Y+PnSD2AjNbu+9-bCX1TMA@mail.gmail.com>
References: <CAFH29tq4oKm=DU+w=Vw=g74xxDGo3w9od1crDyc7Ukf8Miwm3g@mail.gmail.com>
 <A9713625-715B-42B1-8FFA-E6A481A69E11@bitblocks.com>
 <CAKr6gn3-qgbsDaqvr5n-Ojaa9CS2Y+PnSD2AjNbu+9-bCX1TMA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1904111226370.13313@grey.csi.cam.ac.uk>

George Michaelson <ggm at algebras.org> wrote:
> On Apr 10, 2019, at 4:06 PM, Richard Salz <rich.salz at gmail.com> wrote:
> >
> > Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/
>
> fork() and the various exec() flavours had this single compelling
> story for me: the stdin/stdout/stderr *and all other open I/O* was
> inherited across the process boundary. This alone made writing code
> significantly easier.

Mark Wooding had an insightful observation in response to that paper: it's
relatively common in Unix to have oblivious intermediaries where it is
important that they pass on things like file descriptors and signal
dispositions. How would you implement nohup() in a spawn-based system?

[ Yorkbox-related tangent: the other day I was trying to find out more
about the JANET NRS (the hosts.txt-alike with names in uk.ac.cam format)
and all I could find out is that it was hosted at Salford on Pr1me
computers https://www.uknof.org.uk/uknof7/Reid-History.pdf ... the reason
for looking because I'm no longer providing secondary DNS for Salford. ]

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Fair Isle: East 2 or 3, veering south 5 or 6. Slight, becoming moderate.
Occasional rain or drizzle. Moderate or good.

From clemc at ccc.com  Thu Apr 11 23:48:03 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 11 Apr 2019 09:48:03 -0400
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <7b575d14-270c-1d3a-7419-0329ffb42669@esse.ch>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
 <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
 <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>
 <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>
 <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com>
 <7b575d14-270c-1d3a-7419-0329ffb42669@esse.ch>
Message-ID: <CAC20D2OWGLa4hHTKa=zYTDnDLGwKzoGPxQeU8gDDGBysTmBQ0w@mail.gmail.com>

As my very fragile nth edition photocopy shows, the original Western
Electric copies are not troff'ed and run through a typesetter because John
(like most of us at the time) did not have access to one (and Tom Ferrin
had not yet done the vcat(1) hack at UCSF).  Lions used standard nroff
output - (in this case, originally to 132 column line printer paper I
believe).

FWIW: [I would check with one of his former students who might know for
sure], but I was under the impression he used the 5th/6th edition version
of the Mike Lesk Macro's (-ms) that were around with nroff at the time.   I
don't remember how underlining was done in the book, because raw nroff
generated ASR37 codes native, and the ul(1) program would not get a wide
release until after BSD [but it is probable that other folks did something
similar too].  Again, I've forgotten how this all worked, but sadly there
was a time when I used it every day ;-)    IIRC early nroff may have had a
switch to generate line printer codes instead.

Also, the 'memorandum macros' (-mm) came out of Whippany, and I believe
were first released with PWB. They may have been included with the
typesetter C release too, but I don't think they are part of V7.    Eric's
UCB thesis macros, (-me) show up with one of the BSDs releases.

It's funny, I used -ms first then got really hot for -mm  because they
could do things like Lists better and used them until I went to UCB.  But
after doing my thesis I went back to the simplicity of Lesk's macros, but
carry a couple of extra (like Lists) in my personal front end.

Like Larry, troff/nroff still my preferred way to do a large document with
chapters

Clem.

On Thu, Apr 11, 2019 at 12:58 AM Fabio Scotoni <fabio at esse.ch> wrote:

> On 4/11/19 1:19 AM, Bakul Shah wrote:
> > On Apr 10, 2019, at 3:24 PM, Clem Cole <clemc at ccc.com> wrote:
> >>
> >> [...] is the Lions book including PS and PDF and in the original troff
> thankfully.
> >
> > Sorry to disappoint you but it's the same LaTeX source.
> >
> >> [Why someone would convert it to tex is a little beyond me].
> >
> >
> > May be someone will be inspired enough to convert this to troff?
> >
> >
>
> Not to be too negative, but converting it to troff would be somewhat of
> an effort; however, the gains for that seem to be comparatively small.
> It would be a change from one language to another, neither of which are
> a 1:1 copy of the original.
> Even if you had the original troff sources of the book,
> groff, heirloom-troff and Plan9 ditroff probably all have line breaking
> and character positioning algorithms that don't match the original troff
> at the time.
>
> If someone were to undertake this troff endeavor, aiming for a perfect
> recreation would be the most beneficial (yet also most difficult) thing
> to do.
> I've never seen the original commentary, but I'll assume that it used a
> homebrewed set of macros.
> Thus, the first step would be to reverse engineer the troff macros used
> to typeset the book.
> Then the TeX sources would need to be converted to those troff macros;
> this can possibly be automated entirely.
> Then the matching version of troff would need to be used to typeset it
> (likely via apout and V6 or V7 troff).
> Finally, the C/A/T typesetter output would need to be converted to
> PostScript or PDF (either Adobe's psroff or Chris Lewis's psroff from
> comp.unix.sources can likely help with that; I got Lewis's psroff to
> work a while ago, but it's pretty brittle).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190411/3910658f/attachment.html>

From crossd at gmail.com  Fri Apr 12 00:54:57 2019
From: crossd at gmail.com (Dan Cross)
Date: Thu, 11 Apr 2019 10:54:57 -0400
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <CAC20D2OWGLa4hHTKa=zYTDnDLGwKzoGPxQeU8gDDGBysTmBQ0w@mail.gmail.com>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
 <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
 <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>
 <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>
 <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com>
 <7b575d14-270c-1d3a-7419-0329ffb42669@esse.ch>
 <CAC20D2OWGLa4hHTKa=zYTDnDLGwKzoGPxQeU8gDDGBysTmBQ0w@mail.gmail.com>
Message-ID: <CAEoi9W54vVH2E1UiUEV=ntydTxk=3D-zT081xPQse7pK-TFPSA@mail.gmail.com>

On Thu, Apr 11, 2019 at 9:49 AM Clem Cole <clemc at ccc.com> wrote:

> As my very fragile nth edition photocopy shows, the original Western
> Electric copies are not troff'ed and run through a typesetter because John
> (like most of us at the time) did not have access to one (and Tom Ferrin
> had not yet done the vcat(1) hack at UCSF).  Lions used standard nroff
> output - (in this case, originally to 132 column line printer paper I
> believe).
>

Indeed. Even the mid-90's Peer-to-Peer press reprinting appears to be,
roughly, a facsimile of line printer output. I say 'roughly' because there
is some prefatory material at the beginning that is properly typeset:
dedications, acknowledgements, etc, all written at the time of
(re)publication and similarly a set of "appreciations" at the end.

Interestingly, the title page appears to be approximately original and is
typeset. It also includes this little gem of a note: "COPY NO. 050B  NAME
PROPERTY OF BELL LABORATORIES, INC. COPY TO BE RETURNED TO: COMPUTING
INFORMATION SERVICE MH 2F-128 UNIX OPERATING SYSTEM SOURCE CODE VERSION 6"
(line breaks elided).

I don't think I've ever seen a copy of the original; I suspect the title
page was reset for the PP publication, though it is of course possible that
Lions could have prepared that specially: doing a "one-off" for a single
page, perhaps under contract with an actual publishing company or graphic
artist or something, would have been reasonable while the rest of the
booklet contents were taken from listings.


> [snip]
>
>
        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190411/653df2ae/attachment.html>

From clemc at ccc.com  Fri Apr 12 01:36:33 2019
From: clemc at ccc.com (Clem Cole)
Date: Thu, 11 Apr 2019 11:36:33 -0400
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <CAEoi9W54vVH2E1UiUEV=ntydTxk=3D-zT081xPQse7pK-TFPSA@mail.gmail.com>
References: <alpine.LFD.2.21.1904101400270.2402@booboo.lectroid.com>
 <14453.1554920068@cesium.clock.org>
 <CAC20D2MRdP3jaQDXKjK6wNry3-zN7n9okhPBEGk4qhDhROSX_Q@mail.gmail.com>
 <A0751BC1-152D-4CE6-9E61-01151DFCBFD7@bitblocks.com>
 <CAC20D2NRXV=Ps6GV+qKnfM1DWcpy-ca09b+3sQXRF01q0RNMHg@mail.gmail.com>
 <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com>
 <7b575d14-270c-1d3a-7419-0329ffb42669@esse.ch>
 <CAC20D2OWGLa4hHTKa=zYTDnDLGwKzoGPxQeU8gDDGBysTmBQ0w@mail.gmail.com>
 <CAEoi9W54vVH2E1UiUEV=ntydTxk=3D-zT081xPQse7pK-TFPSA@mail.gmail.com>
Message-ID: <CAC20D2MxRuUTsOKw8U95MBDzMPo=+WWERf_nf_n19OyoUXKkWw@mail.gmail.com>

When I was at Tektronix in the late 70s, I was able to get my boss to buy
me (us - but for my desk) a copy of the original  (with the orange and red
covers for the two books - the commentary was in one and the sources in the
other but I have forgotten which was which).  However, my own (current)
photocopy was from CMU a few years before.   I left Tek and I have no idea
what happened to that new copy since Tek owned it (and I was not smart
enough at the time to re-duplicate it, so my current copy is a fading nth
generation one).  I must have handed the "real" one to the late Terry
Lawskodi, or maybe Larry Morandi or Steve Glaser (I'll have to ask Steve
and Larry if they know what became of the Tek copy).
ᐧ

On Thu, Apr 11, 2019 at 10:55 AM Dan Cross <crossd at gmail.com> wrote:

> On Thu, Apr 11, 2019 at 9:49 AM Clem Cole <clemc at ccc.com> wrote:
>
>> As my very fragile nth edition photocopy shows, the original Western
>> Electric copies are not troff'ed and run through a typesetter because John
>> (like most of us at the time) did not have access to one (and Tom Ferrin
>> had not yet done the vcat(1) hack at UCSF).  Lions used standard nroff
>> output - (in this case, originally to 132 column line printer paper I
>> believe).
>>
>
> Indeed. Even the mid-90's Peer-to-Peer press reprinting appears to be,
> roughly, a facsimile of line printer output. I say 'roughly' because there
> is some prefatory material at the beginning that is properly typeset:
> dedications, acknowledgements, etc, all written at the time of
> (re)publication and similarly a set of "appreciations" at the end.
>
> Interestingly, the title page appears to be approximately original and is
> typeset. It also includes this little gem of a note: "COPY NO. 050B  NAME
> PROPERTY OF BELL LABORATORIES, INC. COPY TO BE RETURNED TO: COMPUTING
> INFORMATION SERVICE MH 2F-128 UNIX OPERATING SYSTEM SOURCE CODE VERSION 6"
> (line breaks elided).
>
> I don't think I've ever seen a copy of the original; I suspect the title
> page was reset for the PP publication, though it is of course possible that
> Lions could have prepared that specially: doing a "one-off" for a single
> page, perhaps under contract with an actual publishing company or graphic
> artist or something, would have been reasonable while the rest of the
> booklet contents were taken from listings.
>
>
>> [snip]
>>
>>
>         - Dan C.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190411/f24aac18/attachment.html>

From richard at inf.ed.ac.uk  Fri Apr 12 01:57:48 2019
From: richard at inf.ed.ac.uk (Richard Tobin)
Date: Thu, 11 Apr 2019 16:57:48 +0100 (BST)
Subject: [TUHS] Unix filesystem semantics history - files with holes
In-Reply-To: Erik E. Fair's message of Wed, 10 Apr 2019 19:37:05 -0700
Message-ID: <20190411155748.8791B255ADDC@macaroni.inf.ed.ac.uk>

> When did the Unix filesystem add the semantics for "files with holes" (large,
> sparse files)?

It was there in the first edition:

https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf

The FILE SYSTEM (V) man page includes a last paragraph identical to
that of FILSYS (V) in seventh edition:

  If block b in a file exists, it is not necessary that all blocks
  less than b exist.  A zero block number either in the address words
  of the the i-node or in an indirect block indicates that the
  corresponding block has never been allocated.  Such a missing block
  reads as if it contained all zero words.

The first edition indirect blocks were a bit different though: if the
file was bigger than 8 blocks (4kB), all the blocks in the inode were
(singly) indirect.

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


From wlc at jctaylor.com  Fri Apr 12 05:09:47 2019
From: wlc at jctaylor.com (William Corcoran)
Date: Thu, 11 Apr 2019 19:09:47 +0000
Subject: [TUHS] Unix filesystem semantics history - files with holes
In-Reply-To: <20190411155748.8791B255ADDC@macaroni.inf.ed.ac.uk>
References: Erik E. Fair's message of Wed, 10 Apr 2019 19:37:05
 -0700,<20190411155748.8791B255ADDC@macaroni.inf.ed.ac.uk>
Message-ID: <C30B7B29-1C36-4399-8F88-0E463E9AA365@jctaylor.com>

Sparse files: “Thin Provisioning” way ahead of its time.  Combined with the patented SUID: The UNIX marvels never cease.  

It just goes to show that all this marketing BS touted today has already been done before.  


Bill Corcoran 

On Apr 11, 2019, at 12:36 PM, Richard Tobin <richard at inf.ed.ac.uk> wrote:

>> When did the Unix filesystem add the semantics for "files with holes" (large,
>> sparse files)?
> 
> It was there in the first edition:
> 
> https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf
> 
> The FILE SYSTEM (V) man page includes a last paragraph identical to
> that of FILSYS (V) in seventh edition:
> 
>  If block b in a file exists, it is not necessary that all blocks
>  less than b exist.  A zero block number either in the address words
>  of the the i-node or in an indirect block indicates that the
>  corresponding block has never been allocated.  Such a missing block
>  reads as if it contained all zero words.
> 
> The first edition indirect blocks were a bit different though: if the
> file was bigger than 8 blocks (4kB), all the blocks in the inode were
> (singly) indirect.
> 
> -- Richard
> 
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
> 

From bakul at bitblocks.com  Fri Apr 12 05:49:34 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 11 Apr 2019 12:49:34 -0700
Subject: [TUHS] Unix filesystem semantics history - files with holes
In-Reply-To: <20190411155748.8791B255ADDC@macaroni.inf.ed.ac.uk>
References: <20190411155748.8791B255ADDC@macaroni.inf.ed.ac.uk>
Message-ID: <D70410E5-4EFA-4C5A-A2A8-8BF00F7A4824@bitblocks.com>

On Apr 11, 2019, at 8:57 AM, Richard Tobin <richard at inf.ed.ac.uk> wrote:
> 
>> When did the Unix filesystem add the semantics for "files with holes" (large,
>> sparse files)?
> 
> It was there in the first edition:
> 
> https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf

You still had to read all those unallocated blocks as zeroes
if you wanted to copy such a "holey" file. I believe it was
Solaris (may be just for zfs?) that added SEEK_HOLE and
SEEK_DATA lseek whence values.

This could've been hidden if only mmap was allowed on files.
Or alternately read/write buffering was done by the kernel
or the {network,file}-server - which can avoid copying in
cases where it makes sense. 

From cmhanson at eschatologist.net  Fri Apr 12 09:37:52 2019
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Thu, 11 Apr 2019 16:37:52 -0700
Subject: [TUHS] "Fork considered harmful"
In-Reply-To: <CAFH29tq4oKm=DU+w=Vw=g74xxDGo3w9od1crDyc7Ukf8Miwm3g@mail.gmail.com>
References: <CAFH29tq4oKm=DU+w=Vw=g74xxDGo3w9od1crDyc7Ukf8Miwm3g@mail.gmail.com>
Message-ID: <7A06D817-72BD-47CB-BEE5-25755B4C3ABF@eschatologist.net>

On Apr 10, 2019, at 4:06 PM, Richard Salz <rich.salz at gmail.com> wrote:
> 
> Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/

Quite correct in my experience.

The posix_spawn() API isn’t a panacea but (especially with a few *_np extensions) it’s much saner for large real-world applications that run a ton of subprocesses. I work on a large IDE which invokes compilers and such, and it makes a huge difference.

The biggest need for *_np extensions has been control over fd inheritance and chdir behavior. Otherwise a subprocess can wind up inheriting random or no fds from a multithreaded process (thanks to the race between setting up and finishing the call) and you need to use pthread_{chdir,fchdir}() or openat() to set the working directory in which the subprocess is launched.

  -- Chris


From dfawcus+lists-tuhs at employees.org  Fri Apr 12 10:12:10 2019
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Fri, 12 Apr 2019 01:12:10 +0100
Subject: [TUHS] "Fork considered harmful"
In-Reply-To: <7A06D817-72BD-47CB-BEE5-25755B4C3ABF@eschatologist.net>
References: <CAFH29tq4oKm=DU+w=Vw=g74xxDGo3w9od1crDyc7Ukf8Miwm3g@mail.gmail.com>
 <7A06D817-72BD-47CB-BEE5-25755B4C3ABF@eschatologist.net>
Message-ID: <20190412001210.GA31597@bugle.employees.org>

On Thu, Apr 11, 2019 at 04:37:52PM -0700, Chris Hanson wrote:
> On Apr 10, 2019, at 4:06 PM, Richard Salz <rich.salz at gmail.com> wrote:
> > Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/
> Quite correct in my experience.
> 
> The posix_spawn() API isn’t a panacea but (especially with a few *_np extensions) it’s much saner for large real-world applications that run a ton of subprocesses. I work on a large IDE which invokes compilers and such, and it makes a huge difference.

What I ended up doing for children of GUI apps (on OSX) is to fork very early on
before the GUI starts, or the process becomes multi-thread.  Then that child does
all of the real spawning, using fd passing and messages over a pipe (actually a
unix domain socket) to drive it, so usually no need for _np stuff.
There for cases where posix_spawn() is viable, as I recall it was faster than fork+exec.

DF

From jnc at mercury.lcs.mit.edu  Sat Apr 13 00:51:02 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 12 Apr 2019 10:51:02 -0400 (EDT)
Subject: [TUHS] "Fork considered harmful"
Message-ID: <20190412145102.4876F18C0A9@mercury.lcs.mit.edu>

    > From: Richard Salz

    > Any view on this?
    > https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/

Having read this, and seen the subsequent discussion, I think both sides have
good points.

What I perceive to be happening is something I've described previously, but
never named, which is that as a system scales up, it can be necessary to take
one subsystem which did two things, and split it up so there's a custom
subsystem for each.

I've seen this a lot in networking; I've been trying to remember some of the
examples I've seen, and here's the best one I can come up with at the moment:
having the routing track 'unique-ID network interface names' (i.e. interface
'addresses') - think 48-bit IEEE interface IDs' - directly. In a small
network, this works fine for routing traffic, and as a side-benefit, gives you
mobility. Doesn't scale, though - you have to build an 'interface ID to
location name mapping system', and use 'location names' (i.e. 'addresses') in
the routing.

So classic Unix 'fork' does two things: i) creates a new process, and ii) replicates
the environment/etc of an existing process. (In early Unix, the latter was pretty
simple, but as the paper points out, it has now become a) complex and b) expensive.)

I think the answer has to include decomposing the functionality of old fork()
into several separate sub-primitives (albeit not all necessarily directly
accessible to the user): a new-process primitive, which can be bundled with a
number of different alternatives (e.g. i) exec(), ii) environment replication,
iii) address-space replication, etc) - perhaps more than one at once.

So that shell would want a form of fork() which bundled in i) and ii), but
large applications might want something else. And there might be several
variants of ii), e.g. one might replicate only environment variables, another
might add I/O channels, etc.

In a larger system, there's just no 'one size fits all' answer, I think.

	  Noel


From imp at bsdimp.com  Sat Apr 13 01:33:35 2019
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 12 Apr 2019 09:33:35 -0600
Subject: [TUHS] "Fork considered harmful"
In-Reply-To: <20190412145102.4876F18C0A9@mercury.lcs.mit.edu>
References: <20190412145102.4876F18C0A9@mercury.lcs.mit.edu>
Message-ID: <CANCZdfqQXenzx3uN-EL1js6NSbn_9Pz6T5DKMrcL38UB4AAWfQ@mail.gmail.com>

On Fri, Apr 12, 2019 at 8:51 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Richard Salz
>
>     > Any view on this?
>     >
> https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/
>
> Having read this, and seen the subsequent discussion, I think both sides
> have
> good points.
>
> What I perceive to be happening is something I've described previously, but
> never named, which is that as a system scales up, it can be necessary to
> take
> one subsystem which did two things, and split it up so there's a custom
> subsystem for each.
>
> I've seen this a lot in networking; I've been trying to remember some of
> the
> examples I've seen, and here's the best one I can come up with at the
> moment:
> having the routing track 'unique-ID network interface names' (i.e.
> interface
> 'addresses') - think 48-bit IEEE interface IDs' - directly. In a small
> network, this works fine for routing traffic, and as a side-benefit, gives
> you
> mobility. Doesn't scale, though - you have to build an 'interface ID to
> location name mapping system', and use 'location names' (i.e. 'addresses')
> in
> the routing.
>
> So classic Unix 'fork' does two things: i) creates a new process, and ii)
> replicates
> the environment/etc of an existing process. (In early Unix, the latter was
> pretty
> simple, but as the paper points out, it has now become a) complex and b)
> expensive.)
>

Signals, fds, address space, copy vs share, COW vs copy now, etc are all
things. Also I'd split hairs on (i): you need some way to create a new
thread of execution within a process, which is where a lot of the focus of
criticisms of fork has focused on the past.


> I think the answer has to include decomposing the functionality of old
> fork()
> into several separate sub-primitives (albeit not all necessarily directly
> accessible to the user): a new-process primitive, which can be bundled
> with a
> number of different alternatives (e.g. i) exec(), ii) environment
> replication,
> iii) address-space replication, etc) - perhaps more than one at once.
>
> So that shell would want a form of fork() which bundled in i) and ii), but
> large applications might want something else. And there might be several
> variants of ii), e.g. one might replicate only environment variables,
> another
> might add I/O channels, etc.
>
> In a larger system, there's just no 'one size fits all' answer, I think.
>

Agreed. We've already seen that happening, some examples are quite old. We
had vfork() (dating back to 3BSD) which tried to optimize the duplication
stuff. More recently, rfork() (plan9 and later BSD) and clone() (Linux) [*]
have been used to specify what parts of process are copied and/or shared to
allow, among other things, light weight threads to be one of the possible
answers, to allow the fork to happen asynchronously, etc. Linux has a bunch
of other variants as well.

fork as a boogie man is a well known trope, honestly. Criticism of it, and
solutions for it's all-or-nothing approach have been proffered for a long
time. These solutions range from having the helper child process to spawn
other things a more complex process wants, to specialized ways to create
threads (which are process-like things that share an address space and
benefit from special handling in the kernel), to things like rfork or clone
that try to pick-and-choose what aspects of process duplication are needed.
There's a reason that the clone man page is maybe 10x longer than the
classic fork man page.

Warner

[*] This doesn't even begin to look at things like what Solaris, Irix, or a
dozen other unix derivatives did to create threads and/or optimize
different use cases of fork..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190412/564fc278/attachment.html>

From jcapp at anteil.com  Sat Apr 13 02:11:47 2019
From: jcapp at anteil.com (Jim Capp)
Date: Fri, 12 Apr 2019 11:11:47 -0500 (EST)
Subject: [TUHS] "Fork considered harmful"
In-Reply-To: <CAFH29tq4oKm=DU+w=Vw=g74xxDGo3w9od1crDyc7Ukf8Miwm3g@mail.gmail.com>
Message-ID: <32714704.14145.1555085507471.JavaMail.root@zimbraanteil>

I think the problem with fork() is that it's elegance invites people to use it outside its sweet spot. 


I always thought (perhaps wrongly) that fork() didn't have to copy all the memory, just the stack and user areas, and that VM page table entries were cloned to share the code segment. 


fork() is beautiful for what it is and what it does. Being able to create a mirror image of the current process, and to be able to share all the I/O and signal states is cool, if that's what you want. I think the author of the micro$oft article is complaining that fork() shares too much, and therefore to use it is a security risk. 


If you don't want to share all that stuff, maybe you shouldn't be using fork(), or, you should fork() early, sharing EXACTLY what you want to share and nothing more, and then differentiate with exec(). 


C is elegant. C can also be dangerous if you don't use it wisely. 


I think the author should take a lesson from "The Kings Toaster". 


http://www.ee.ryerson.ca:8080/~elf/hack/ktoast.html 


Cheers, 


Jim 







From: "Richard Salz" <rich.salz at gmail.com> 
To: tuhs at tuhs.org 
Sent: Wednesday, April 10, 2019 7:06:23 PM 
Subject: [TUHS] "Fork considered harmful" 



Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/ 

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

From crossd at gmail.com  Sat Apr 13 05:55:54 2019
From: crossd at gmail.com (Dan Cross)
Date: Fri, 12 Apr 2019 15:55:54 -0400
Subject: [TUHS] "Fork considered harmful"
In-Reply-To: <20190412145102.4876F18C0A9@mercury.lcs.mit.edu>
References: <20190412145102.4876F18C0A9@mercury.lcs.mit.edu>
Message-ID: <CAEoi9W6HFL3UcnWkKoqka8Dt16MWskKd6yEJr3HYCcCT9pMTig@mail.gmail.com>

From: Richard Salz

> Any view on this?
> https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/


Yes.

First, I dislike the presentation of the paper. From the pithy title to
snarky section headings to the overly informal register of the writing, I
think the authors did themselves a disservice writing in a style that is
far too colloquial. The argument is presented with too much editorial
comment, as if it's trying to be "edgy" or something. I find that
off-putting and annoying at best.

But stylistic issues aside, the substance of the paper is largely on point.
The fact is that, for better or worse, fork() has not aged gracefully into
the modern age of multi-threaded programs, big graphical applications, and
the like, and the problems the authors point out are very, very real. An
argument can be made along the lines of, "well, just don't write programs
that way..." but the universe of interesting and useful userspace programs
is now large enough that I'm afraid we're well inside the event horizon of
increasing entropy.

It's interesting that they make an oblique reference to Austin's
dissertation, or at least one of the papers that came out of his work
(Clements et al) but they don't go the full way in exploring the
implications.

On Fri, Apr 12, 2019 at 10:51 AM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> Having read this, and seen the subsequent discussion, I think both sides
> have
> good points.
>
> What I perceive to be happening is something I've described previously, but
> never named, which is that as a system scales up, it can be necessary to
> take
> one subsystem which did two things, and split it up so there's a custom
> subsystem for each.
>
> I've seen this a lot in networking; I've been trying to remember some of
> the
> examples I've seen, and here's the best one I can come up with at the
> moment:
> having the routing track 'unique-ID network interface names' (i.e.
> interface
> 'addresses') - think 48-bit IEEE interface IDs' - directly. In a small
> network, this works fine for routing traffic, and as a side-benefit, gives
> you
> mobility. Doesn't scale, though - you have to build an 'interface ID to
> location name mapping system', and use 'location names' (i.e. 'addresses')
> in
> the routing.
>
> So classic Unix 'fork' does two things: i) creates a new process, and ii)
> replicates
> the environment/etc of an existing process. (In early Unix, the latter was
> pretty
> simple, but as the paper points out, it has now become a) complex and b)
> expensive.)
>
> I think the answer has to include decomposing the functionality of old
> fork()
> into several separate sub-primitives (albeit not all necessarily directly
> accessible to the user): a new-process primitive, which can be bundled
> with a
> number of different alternatives (e.g. i) exec(), ii) environment
> replication,
> iii) address-space replication, etc) - perhaps more than one at once.
>

This is approximately what was done in Akaros. The observation, in the MSR
paper and elsewhere, that fork() is a poor abstraction because it tries to
do too much and doesn't interact well with threads (which Akaros was all
about) is essentially correct and created undue burdens on the system's
implementors. The solution there was to split process creation into two
steps: creation proper, and marking a process runnable for the first time.
This gave a parent an opportunity to create a child process and then
populate its file descriptors, environment variables, and so forth before
setting it loose on the system: one got much of the elegance of the fork()
model, but without the bad behavior.

The critical observation is that a hard distinction between fork()/exec()
on one side and spawn() on the other as the only two possible designs is
unnecessary; an intermediate step in the spawn() model preserving the
two-step nature of the fork()/exec() model yields many of the benefits of
both, without many of the problems of one or the other.

So that shell would want a form of fork() which bundled in i) and ii), but
> large applications might want something else. And there might be several
> variants of ii), e.g. one might replicate only environment variables,
> another
> might add I/O channels, etc.
>
> In a larger system, there's just no 'one size fits all' answer, I think.
>

This is, I think, the crux of the argument: Unix fork, as introduced on the
PDP-7, wasn't designed for "large" systems. I'd be curious to know how much
intention was behind the consequences of fork()'s behavior were known in
advance. As Dennis Ritchie's document on early Unix history (well known to
most of the denizens of this list) pointed out, the implementation was an
expedient, and the construct was loosely based on prior art (Genie etc).
Was the idea of the implicit dup()'ing of open file descriptors something
that people thought about consciously at the time? Certainly, once it was
there, people found out that they could exploit it in clever ways for e.g.
IO redirection, pipes (which came later, of course), etc, but I wonder to
what extent that was discovered as opposed to being an explicit design
objective.

Put another way, the thought process may have been along the lines of,
"look at the neat properties that fall out of this thing we've already
got..." as opposed to, "we designed this thing to have all these neat
properties..." Much of the current literature and extant course material
seems to take the latter tack, but it's not at all clear (to me, anyway)
that that's an accurate reflection of the historical reality.

I briefly mentioned Clements's dissertation above. In essence, the
scalability commutativity rule says that interfaces that commute scale
better than those that do not because they do not _require_ serialization,
so they can be parallelized etc. Many of the algorithms in early Unix do
not commute: the behavior of returning the lowest available number when
allocating a file descriptor is an example (consider IO redirection here
and the familiar sequence, "close(1), open("output", O_WRONLY)": this
doesn't work if one does the close after the open, etc). But fork() and
exec() might be the ultimate example. Obviously if I exec() before I fork()
my semantics are very, very different, but more generally the commutativity
must be considered in some context: operations on file descriptors don't
commute with one another, but they do commute with, say, memory writes. On
the other hand, fork() doesn't commute with much of anything at all.

The early Unix algorithms are so incredibly simple (one can easily imagine
the loop over a process's file descriptor table, for example), but one
can't help but wonder if there was any sense of what the consequences of
the details of those algorithms leaking out to user programs would be 50
years later. Surely not?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190412/490ddbd6/attachment.html>

From jnc at mercury.lcs.mit.edu  Sun Apr 14 04:35:19 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 13 Apr 2019 14:35:19 -0400 (EDT)
Subject: [TUHS] Paper discussing Unix boot process?
Message-ID: <20190413183519.8B95918C0B3@mercury.lcs.mit.edu>

    > From: Warren Toomey <wkt at tuhs.org>

    > That's all I knew at the time :-)

:-) I used nroff/troff for a bit, but I didn't like it; I don't recall why,
but I suspect I wasn't using people's macro packages, which probably made it
more difficult to use. My favourite was SCRIBE, but it alas seems to have
died.

    > From: Dan Cross <crossd at gmail.com>

    >> the original Western Electric copies are not troff'ed and run through
    >> a typesetter ...

    > Indeed. Even the mid-90's Peer-to-Peer press reprinting appears to be,
    > roughly, a facsimile of line printer output. ...
    > Interestingly, the title page appears to be approximately original and
    > is typeset.

I finally located my copy of the reprint (I'd been using it to help Fritz
Mueller find a problem in his RK11C, and it wasn't in its normal place), and
comparing it with my 'samizdat' set (which came from a set owned by
Lincoln-Sudbury High School - they actually had an -11 running V6, I helped
their computer person, I forget his name now, with it), I can confirm that:

- The reprint does mostly reproduce the exact page images from the original
(which was indeed, mostly line-printer out), except that the original does not
have the typeset chapter/section header pages. It's possible that the pages in
the reprint are a new printing, but if so, they have exactly matched not only
the layout (not too hard) of the original, but also the font.

- In a couple of places (e.g. Contents, pg. 1; Preface, pg. 1; Chapter One,
pg. 1) "UNIX" has been replaced by "UNIX*" (different font), and at the bottom
of the page has been added "* UNIX is a Trademark of Bell Laboratories", again
in a different font.

- The typeset 'Source Code' title page is in the original; the copy in the
reprint is an exact image, except that the upper-case "This information ...
Written permission of Bell Laboratories" section is not in the original,
which says instead at that place: "This document may contain information
covered by one or more licenses, copyrights and non-disclosure agreements.
Circulation of this document is restricted to holders of a license for the
UNIX Software System from Western Electric. All other circulation or
reproduction is prohibited."

- The typeset 'Commentary' title page is different in my samizdat First
Edition original; it's a copy of the other title page, except that the
second para is replaced by the first sentence of the 'Commentary' title
page of the reprint, and of course the title is different from the other
volume.

	Noel

From wkt at tuhs.org  Sun Apr 14 08:59:03 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 14 Apr 2019 08:59:03 +1000
Subject: [TUHS] VCF East in May
Message-ID: <20190413225903.GA8566@minnie.tuhs.org>

Hi all, just to let you know that VCF East in May has some Unix anniversary
events. bwk will be interviewing ken as one of the keynotes. Wish I could be
there!

Details at: http://vcfed.org/wp/festivals/vintage-computer-festival-east/

Cheers, Warren

From wkt at tuhs.org  Sun Apr 14 09:44:07 2019
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 14 Apr 2019 09:44:07 +1000
Subject: [TUHS] Also, VCF SE
Message-ID: <20190413234407.GA14251@minnie.tuhs.org>

And Earl Baugh just let me know:

   VCF SE at the end of April will have Douglas McIlroy coming to speak.
   We also will have a number of Unix exhibits as well. Unix is the
   topic of the front of the show shirt.

   Earl
   http://vcfed.org/wp/festivals/otherevents/vintage-computer-festival-southeast/

From jnc at mercury.lcs.mit.edu  Tue Apr 16 22:52:37 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue, 16 Apr 2019 08:52:37 -0400 (EDT)
Subject: [TUHS] Paper discussing Unix boot process?
Message-ID: <20190416125237.333B918C0BE@mercury.lcs.mit.edu>

    > From: Charles Anthony

    > The Multics System Initialization Program Logic Manual. 139 pages of
    > somewhat detailed information. 

I was going to mention the Multics init PLM! :-) Needless to say, it's
probably not a good candidate for the original goal - a document describing
how an OS boots - it's simply too complicated for ordinary mortals! (Reading
it makes _my_ head hurt!) There are a couple of reasons it's so complex.

Multics is not a monolitic OS, the way most versions of Unix are (although I
gather this is no longer quite true of Linux); the OS isn't this large blob
of bits you load into memory and start. Its structure makes heavy use of the
segmentation model supported by the hardware. Moreover, although the first
segments loaded aren't paged, many of the later ones are. (This makes sense
in the context of the times; with limited core main memory, you wouldn't want
to devote massive chunks of main memory to have the entire OS always
resident.)

However, this all makes for a more complex booting process; the standard
Multics boot tape (a Multics System Tape) contains many modules, which get
linked in individually at boot time. (In V6 terms - the version I'm most
familiar with - it's as if a Unix boot tape contained 'lib1' and 'lib2', and
the bootstrap included a linker to build the OS binary in memory.) And in fact
the modules come in in tranches, and some of the earlier one are available for
use in loading later tranches (e.g. paging).

This does have some advantages, though; e.g. the MST is the same for all
Multics machines (including the initial boot of a new machine); the system is
customized to the particular configuration during the bootstrap process. This
is actually not too crazy, there are reasons this makes sense.

For one, the whole 'information utility' concept (where Multics admittedly
went down the wrong path, in terms of the future of computers); a single
giant machine (multi-processor, multi-memory bank, multi-I/O controller). The
thing is that any of these could be switched out if it developed a fault, but
then you have to be able to boot that new configuration. (In particular,
Multics wasn't a master-slave multi-processor system, they're all the same;
but only one CPU runs for most of booting, the others are started and added
once the system is running. But the 'bootstrap CPU' might change if the
original bootstrap CPU develops a fault...)

	Noel

From pnr at planet.nl  Wed Apr 17 15:35:11 2019
From: pnr at planet.nl (Paul Ruizendaal)
Date: Wed, 17 Apr 2019 07:35:11 +0200
Subject: [TUHS] Paper discussing Unix boot process?
Message-ID: <D3790A51-AECE-4A0B-BEE2-A26A464424B0@planet.nl>

Maybe xv6 has an explanation of the boot process that is of use to the original poster:

https://pdos.csail.mit.edu/6.828/2018/xv6.html

Paul


From imp at bsdimp.com  Thu Apr 18 04:26:17 2019
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 17 Apr 2019 12:26:17 -0600
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <D3790A51-AECE-4A0B-BEE2-A26A464424B0@planet.nl>
References: <D3790A51-AECE-4A0B-BEE2-A26A464424B0@planet.nl>
Message-ID: <CANCZdfp+bQdTTpnESRe+TZq76-q763CpEJNf6-2q9YVg-Cvptg@mail.gmail.com>

On Tue, Apr 16, 2019 at 11:43 PM Paul Ruizendaal <pnr at planet.nl> wrote:

> Maybe xv6 has an explanation of the boot process that is of use to the
> original poster:
>
> https://pdos.csail.mit.edu/6.828/2018/xv6.html


If you are looking for a generic answer, it goes something like this:

1. Power is applied to the system
2. Support circuits initialize (details vary widely, may include
initializing memory controllers and loading microcode into the CPU)
3. CPU comes out of reset and jumps to a well known location (that's either
initialized by 2 or is ROM of some flavor)
4. The initial boot code confirms this is a power-on reset (and not a
wakeup from sleeping or other condition) and loads the next boot loader
from some media like tape, disk or network
5. The loader then loads the next stage loader, if any. Repeat 5 as many
times as needed to get to loading the kernel. Loader constructs metadata
about the system and passes that to the kernel.
6. Once the kernel is loaded, execution is passed off to the kernel which
looks at the loader metadata to know what's it needs to about the system
that it can't easily get by other means.
6a. Memory is partitions, VM system booted, MMU comes on line, devices
initialized, root is mounted and control passes to init which forks /etc/rc
to bring the sytem up

For most people, this is a sufficient level of detail, unless they are
trying to debug one of the steps then the actual details matter. :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190417/126eb656/attachment.html>

From cph at caipenghui.top  Thu Apr 18 23:08:40 2019
From: cph at caipenghui.top (Caipenghui)
Date: Thu, 18 Apr 2019 13:08:40 +0000
Subject: [TUHS] Talk about some interesting things about Dennis
Message-ID: <3F035D5B-A424-46B1-B005-D50E6C5A0B90@caipenghui.top>

Hello, everyone!

Can you share some interesting things around Dennis?

What is Dennis's character? Is he very humorous? Thank you.

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

From norman at oclsc.org  Fri Apr 19 02:09:31 2019
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 18 Apr 2019 12:09:31 -0400
Subject: [TUHS] Talk about some interesting things about Dennis
Message-ID: <1555603775.18441.for-standards-violators@oclsc.org>

  What is Dennis's character? Is he very humorous? Thank you.

He was more humorous when he was still alive, but I think
he would have appreciated this joke.

Norman Wilson
Toronto ON

From jon at fourwinds.com  Fri Apr 19 02:37:13 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Thu, 18 Apr 2019 09:37:13 -0700
Subject: [TUHS] Talk about some interesting things about Dennis
In-Reply-To: <1555603775.18441.for-standards-violators@oclsc.org>
References: <1555603775.18441.for-standards-violators@oclsc.org>
Message-ID: <201904181637.x3IGbDDM007680@darkstar.fourwinds.com>

Norman Wilson writes:
>   What is Dennis's character? Is he very humorous? Thank you.

Well, this isn't specifically about his character, but the story
of how I first met Ken and Dennis is amusing.  And it was a long
time ago so some of the details may be slightly off.

I was a summer student working on the second floor of Building 2.
My MO was to bike up to the labs every morning, and I do mean up
if you've ever been on Glenside Road.  I would work until dinner
time, bike home, have dinner, borrow the car, and go back to the
labs and work until I was almost too tired to drive home.  In the
wee hours one night I was waiting for something to run and was
getting hungry, so I headed up the the food machines in the attic
on the 6th floor.  While I was waiting for my food I heard a very
mechanical sounding voice going "fuck fuck fuck fuck ...".  I had
to investigate.  Under a heating duct there was a door with a
frosted glass window on which was an 8 1/2 x 11 piece of paper on
which the word UNIX was spelled out in black electrical tape.  It
was the source of the sound.  I opened the door and discovered Ken
and Dennis and maybe some others playing with their recently
acquired Votrax speech synthesizer which they were teaching to
swear.  I also remember in later weeks that it would announce
"x o'clock and all is well" on the hour where x was the current hour.

I think that maybe everyone was high on the smell of the developer
for the C/A/T paper.

Jon

From rmswierczek at gmail.com  Fri Apr 19 11:10:18 2019
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Thu, 18 Apr 2019 21:10:18 -0400
Subject: [TUHS] VCF East in May
In-Reply-To: <20190413225903.GA8566@minnie.tuhs.org>
References: <20190413225903.GA8566@minnie.tuhs.org>
Message-ID: <CAAFR5pZ=JNKdLtabOe8gv3B7Xzmybf0XxFPikPyarK89mB78kA@mail.gmail.com>

I will be making the pilgrimage from Virginia and would love to meet
anyone who will be there.

My main interests are compilers and writing simple software (a rarity
these days.)

I contributed a little bit to Warren's project to resurrect Unix on
the PDP-7 by adding a B compiler built from the few remaining scraps
of the byte-code interpreter, run-time, and documentation.

From gregg.drwho8 at gmail.com  Fri Apr 19 11:52:34 2019
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Thu, 18 Apr 2019 21:52:34 -0400
Subject: [TUHS] VCF East in May
In-Reply-To: <CAAFR5pZ=JNKdLtabOe8gv3B7Xzmybf0XxFPikPyarK89mB78kA@mail.gmail.com>
References: <20190413225903.GA8566@minnie.tuhs.org>
 <CAAFR5pZ=JNKdLtabOe8gv3B7Xzmybf0XxFPikPyarK89mB78kA@mail.gmail.com>
Message-ID: <CAC5iaNGBq=w2oiEZVbsA3Uwb3fPWjnNHipWY-CZqLZ4bk8GVTg@mail.gmail.com>

Hello!
Warren I do wish you could be as well. I'll be there. Robert, I'd very
much like to meet you there. I'll be there for the Saturday.

In my case it is hardware, working out the possibilities behind what
can be connected to the bus designs that a PDP-11 for example could
use.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."

On Thu, Apr 18, 2019 at 9:30 PM Robert Swierczek <rmswierczek at gmail.com> wrote:
>
> I will be making the pilgrimage from Virginia and would love to meet
> anyone who will be there.
>
> My main interests are compilers and writing simple software (a rarity
> these days.)
>
> I contributed a little bit to Warren's project to resurrect Unix on
> the PDP-7 by adding a B compiler built from the few remaining scraps
> of the byte-code interpreter, run-time, and documentation.

From reed at reedmedia.net  Fri Apr 19 11:54:11 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Thu, 18 Apr 2019 20:54:11 -0500 (CDT)
Subject: [TUHS] looking for HOSTS.TXT parsers and how is /dev/net/HOSTNAME
 enabled?
Message-ID: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>

This email is two parts. I am researching 1970's symbolic name to 
network address mapping routines.

1) I am looking for parsers for ancient (pre mid 1982) HOSTS.TXT. Since 
this is Unix list, for Unix is fine :)

RFC 597 (12 December 1973) says a hostname list will be maintained at 
the NIC with the location to be announced. (Interestingly NIC as in 
FEINLER at NIC is probably a nickname as it is not listed in the host 
status list. I am guessing it is a nickname for SRI-ARC or OFFICE-1.)

RFC 606 (December 1973) says there are different hosts lists, but "now"
there is "the official list of host names". It proposed that it should 
be maintained online in machine-readable form. It proposes a format and 
suggested attributes.

RFC 607 (January 10, 1974) the NIC agrees that NIC maintain a text file 
of hostnames, addresses, and attributes. (It has also been suggested 
separately.) The source is maintained in NLS format with multiple 
attributes. (What is this NLS format?) A program could be written to 
generate a weekly ASCII file. They will write the program and the 
generated file will be at OFFICE-1 (IMP #43?) with pathname of 
<NETINFO>HOSTS.TXT  (It's not Unix. It's TENEX I think. The ">" is the 
directory delimiter, but what is "<"?)

I have found a few copies of a hostname table, like 
https://emaillab.jp/pub/hosts/1974/host_names_1974.pdf and 
https://www.bortzmeyer.org/files/hosts.txt-1982-1.pdf But these don't 
appear to be the machine parseable files as defined in the RFC 608 
format. These are just printed formats. (I have also found many of the 
host status reports.)

Well I cannot find a copy of the HOSTS.TXT file anywhere. I am not 
looking for the RFC 810 (1 March 1982) or later format (which is easily 
found).
http://pdp-10.trailing-edge.com/SRI_NIC_PERM_SRC_3_19910112/01/utility/ps-perm.870103.htm 
may have copies of it (old format is OHOSTS.TXT). But I cannot figure 
out if or where there are individual file downloads there. Any ideas?)

That leads me to my question ... does anyone know where parser code for 
the HOSTS.TXT file is at?

2) I skimmed through some C code (for Unix) for sendmsg, mmdf, srvrftp, 
mailer.c, telnet.c that use /dev/net/ followed by up to 14-character 
hostname. I am trying to find the kernel code or routines that enable 
device driver named with a hostname. Any ideas? (In particular I'd like 
to know how those names map to a remote host's address.)

I am researching 1970's symbolic name to network address mapping 
routines, but the only ones I have found are primitive: Purdue's "modest 
UNIX network" using mx and Berkeley's Berknet (single letter hostnames). 
But both use simple compiled-in name-to-address tables. (The Purdue 
implementation looks interesting as it has some design to connect 
between IMPs too, but I don't see any code for finding IMP numbers via 
names. By the way, their "csh" tool was their "connected shell" to run a 
shell on a remote host. The manual had the list of hostnames in it. See 
the Purdue usenix tape.)

Thanks,

  Jeremy C. Reed

echo 'EhZ[h ^jjf0%%h[[Zc[Z_W$d[j%Xeeai%ZW[ced#]dk#f[d]k_d%' | \
  tr            '#-~'            '\-.-{'


From imp at bsdimp.com  Fri Apr 19 12:38:44 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 18 Apr 2019 20:38:44 -0600
Subject: [TUHS] looking for HOSTS.TXT parsers and how is
 /dev/net/HOSTNAME enabled?
In-Reply-To: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
References: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
Message-ID: <CANCZdfpY3B5tKZGj_QKvkY+RjRsR3Kose+5uSoSNi0AWmeqGRA@mail.gmail.com>

Can't help on the main thrust of this, but can answer one question...

On Thu, Apr 18, 2019 at 8:33 PM <reed at reedmedia.net> wrote:

> This email is two parts. I am researching 1970's symbolic name to
> network address mapping routines.
>
> 1) I am looking for parsers for ancient (pre mid 1982) HOSTS.TXT. Since
> this is Unix list, for Unix is fine :)
>
> RFC 597 (12 December 1973) says a hostname list will be maintained at
> the NIC with the location to be announced. (Interestingly NIC as in
> FEINLER at NIC is probably a nickname as it is not listed in the host
> status list. I am guessing it is a nickname for SRI-ARC or OFFICE-1.)
>

NIC is probably what became know as SRI-NIC in latter days. By the time I
joined the internet in the early 80s, SRI-NIC was where you registered your
domain name. I just missed the hostfile by a few years.


> RFC 607 (January 10, 1974) the NIC agrees that NIC maintain a text file
> of hostnames, addresses, and attributes. (It has also been suggested
> separately.) The source is maintained in NLS format with multiple
> attributes. (What is this NLS format?) A program could be written to
> generate a weekly ASCII file. They will write the program and the
> generated file will be at OFFICE-1 (IMP #43?) with pathname of
> <NETINFO>HOSTS.TXT  (It's not Unix. It's TENEX I think. The ">" is the
> directory delimiter, but what is "<"?)
>

It's TENEX or TOPS-20 (they are the same for this purpose). <DIR>FILE.EXT
was the format. This was later extended to <DIR.SUB>FILE.EXT. So the <>
just contain the whole path, separated by dots.

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

From lars at nocrew.org  Fri Apr 19 14:03:12 2019
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 19 Apr 2019 04:03:12 +0000
Subject: [TUHS] looking for HOSTS.TXT parsers and how is
 /dev/net/HOSTNAME enabled?
In-Reply-To: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
 (reed@reedmedia.net's message of "Thu, 18 Apr 2019 20:54:11 -0500
 (CDT)")
References: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
Message-ID: <7wa7gmk5fj.fsf@junk.nocrew.org>

reed wrote:
> I am researching 1970's symbolic name to network address mapping
> routines.  I am looking for parsers for ancient (pre mid 1982)
> HOSTS.TXT. Since this is Unix list, for Unix is fine :)

I have those routines and parsers for the PDP-10 ITS operating system.
(I will just post this one off-topic message in this thread.)

> Well I cannot find a copy of the HOSTS.TXT file anywhere.  I am not
> looking for the RFC 810 (1 March 1982) or later format (which is
> easily found).

Here is a collection, but most of them are from after that date.

https://github.com/ttkzw/hosts.txt

I was thinking SAIL must have had something, but I don't see any hosts
list from the 70s here:

https://www.saildart.org/[*,NET]

From arnold at skeeve.com  Fri Apr 19 20:18:09 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Fri, 19 Apr 2019 04:18:09 -0600
Subject: [TUHS] VCF East in May
In-Reply-To: <CAAFR5pZ=JNKdLtabOe8gv3B7Xzmybf0XxFPikPyarK89mB78kA@mail.gmail.com>
References: <20190413225903.GA8566@minnie.tuhs.org>
 <CAAFR5pZ=JNKdLtabOe8gv3B7Xzmybf0XxFPikPyarK89mB78kA@mail.gmail.com>
Message-ID: <201904191018.x3JAI9ml023554@freefriends.org>

Robert Swierczek <rmswierczek at gmail.com> wrote:

> I will be making the pilgrimage from Virginia and would love to meet
> anyone who will be there.

If "someone" could record the conversation between BWK & Ken and
make it available (YouTube or othrwise), that'd be really cool. :-)

Thanks,

Arnold

From cph at caipenghui.top  Fri Apr 19 21:47:39 2019
From: cph at caipenghui.top (Caipenghui)
Date: Fri, 19 Apr 2019 11:47:39 +0000
Subject: [TUHS] Talk about some interesting things about Dennis
In-Reply-To: <1555603775.18441.for-standards-violators@oclsc.org>
References: <1555603775.18441.for-standards-violators@oclsc.org>
Message-ID: <7035E718-B1BF-4F65-855E-91944AAD67C6@caipenghui.top>

于 April 18, 2019 4:09:31 PM UTC, Norman Wilson <norman at oclsc.org> 写到:
>  What is Dennis's character? Is he very humorous? Thank you.
>
>He was more humorous when he was still alive, but I think
>he would have appreciated this joke.
>
>Norman Wilson
>Toronto ON

I don't no.

Caipenghui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190419/37bdefc0/attachment.html>

From cph at caipenghui.top  Fri Apr 19 21:47:39 2019
From: cph at caipenghui.top (Caipenghui)
Date: Fri, 19 Apr 2019 11:47:39 +0000
Subject: [TUHS] Talk about some interesting things about Dennis
In-Reply-To: <1555603775.18441.for-standards-violators@oclsc.org>
References: <1555603775.18441.for-standards-violators@oclsc.org>
Message-ID: <7035E718-B1BF-4F65-855E-91944AAD67C6@caipenghui.top>

于 April 18, 2019 4:09:31 PM UTC, Norman Wilson <norman at oclsc.org> 写到:
>  What is Dennis's character? Is he very humorous? Thank you.
>
>He was more humorous when he was still alive, but I think
>he would have appreciated this joke.
>
>Norman Wilson
>Toronto ON

I don't no.

Caipenghui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190419/37bdefc0/attachment-0001.html>

From ron at ronnatalie.com  Fri Apr 19 21:57:03 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Fri, 19 Apr 2019 07:57:03 -0400
Subject: [TUHS] looking for HOSTS.TXT parsers and how is
 /dev/net/HOSTNAME enabled?
In-Reply-To: <7wa7gmk5fj.fsf@junk.nocrew.org>
References: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
 <7wa7gmk5fj.fsf@junk.nocrew.org>
Message-ID: <444601d4f6a7$01d00b90$057022b0$@ronnatalie.com>

Amusing thing on parsers.    I had written a short C subroutine to eat HOSTS.TXT directly which we used rather than the Berkeley /etc/hosts format.
It presented the same interface to the caller as the Berkeley one.

We found out that when we added a host with a type "68000" that we suddenly broke every straight BSD system.   Apparently, they used a YACC grammar to parse HOSTS.TXT into /etc/hosts and had screwed it up assuming the machine type field (like the hostname) had to begin with a letter.     It didn't help that the machine we added was named "BRL-ZAP."    There was some discussion that we had done this intentionally.    I pointed out that a YACC grammar was way overkill and there must be some existing file on UNIX that has fields separated by colons that there was simpler stuff written to parse 😊    Anyhow, for expedience Jake just added an "MC" on to the machine type to appease the Berkeley toadies.

There was a protocol defined to download the host file which we ran nighly .



From ron at ronnatalie.com  Fri Apr 19 22:10:38 2019
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Fri, 19 Apr 2019 08:10:38 -0400
Subject: [TUHS] Talk about some interesting things about Dennis
In-Reply-To: <201904181637.x3IGbDDM007680@darkstar.fourwinds.com>
References: <1555603775.18441.for-standards-violators@oclsc.org>
 <201904181637.x3IGbDDM007680@darkstar.fourwinds.com>
Message-ID: <480401d4f6a8$e725f4b0$b571de10$@ronnatalie.com>

I hung out with Dennis at various conferences and had various emails with
him over the year.    He was usually quiet but did have a wry sense of
humor.
Mostly at the conferences, he was content to hang out with us in the lobby
or wherever.    If you didn't know who he was, he looked just like the rest
of the UNIX geeks.

He was very caring, and I got a condolence email on the passing of a
colleague.    The most unexpected one was that back in the day on one of the
mailing lists, I think it was INFO-MICRO and not UNIX-WIZARDS, someone was
talking about since Andrew Fluegelman had died recently and he is generally
credited with the idea of shareware, that it be renamed fluegelwaer in his
honor.   In my rebuttal I suggested that we rename the C compiler Ritchie.
I got a quick "Let's nip this in the bud right now" letter from Dennis.

One year while working for the Army I made up a bunch of No Ada t=-shirts
and sold them at one of the conferences.    I gave Dennis one and I always
got a chuckle when I saw pictures of him wearing it later.    If you have
Peter Salus's UNIX history book, there's a picture of him wearing it there.


From jpl.jpl at gmail.com  Sat Apr 20 00:29:09 2019
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Fri, 19 Apr 2019 10:29:09 -0400
Subject: [TUHS] VCF East in May
In-Reply-To: <201904191018.x3JAI9ml023554@freefriends.org>
References: <20190413225903.GA8566@minnie.tuhs.org>
 <CAAFR5pZ=JNKdLtabOe8gv3B7Xzmybf0XxFPikPyarK89mB78kA@mail.gmail.com>
 <201904191018.x3JAI9ml023554@freefriends.org>
Message-ID: <CAC0cEp-_XgjiU+2xcpJuMxwK0PdUhY0jM5ntLXdck2LB5f8JQw@mail.gmail.com>

I asked Brian if the interview would be recorded and made available to the
public. Here's what he said:

I think so.  I was interviewed there in the same setting a few
years ago and the video is on Youtube (which I hadn't known until
searching for it just now):

   https://www.youtube.com/watch?v=-dxTlU0CB8g


On Fri, Apr 19, 2019 at 6:19 AM <arnold at skeeve.com> wrote:

> Robert Swierczek <rmswierczek at gmail.com> wrote:
>
> > I will be making the pilgrimage from Virginia and would love to meet
> > anyone who will be there.
>
> If "someone" could record the conversation between BWK & Ken and
> make it available (YouTube or othrwise), that'd be really cool. :-)
>
> Thanks,
>
> Arnold
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190419/f42fc530/attachment.html>

From clemc at ccc.com  Sat Apr 20 04:43:40 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 19 Apr 2019 14:43:40 -0400
Subject: [TUHS] looking for HOSTS.TXT parsers and how is
 /dev/net/HOSTNAME enabled?
In-Reply-To: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
References: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
Message-ID: <CAC20D2OOtRZA0PXWUj6JJBHjWT3337dbzfN3VBT7NxKNJS5JoA@mail.gmail.com>

On Thu, Apr 18, 2019 at 10:33 PM <reed at reedmedia.net> wrote:

> This email is two parts. I am researching 1970's symbolic name to
> network address mapping routines.
>
> 1) I am looking for parsers for ancient (pre mid 1982) HOSTS.TXT. Since
> this is Unix list, for Unix is fine :)
>
Got to Warren's archives for BSD 4.2 and look for the htable(8) and
gettable(8).  I believe the parsing routines will be in htable(8).
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190419/50912bcf/attachment.html>

From clemc at ccc.com  Sat Apr 20 04:54:22 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 19 Apr 2019 14:54:22 -0400
Subject: [TUHS] looking for HOSTS.TXT parsers and how is
 /dev/net/HOSTNAME enabled?
In-Reply-To: <CAC20D2OOtRZA0PXWUj6JJBHjWT3337dbzfN3VBT7NxKNJS5JoA@mail.gmail.com>
References: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
 <CAC20D2OOtRZA0PXWUj6JJBHjWT3337dbzfN3VBT7NxKNJS5JoA@mail.gmail.com>
Message-ID: <CAC20D2NuuYemcy4iJxhv7MBWj0cR7HUhez4zcmrR6RJFqPEwuA@mail.gmail.com>

Just saw Ron reply, I remember when that happened - (it could have been you
guys) but after we sold our first Masscomp machine to DoD.  We then added a
note in the administrator's guide we saying use MC68000 and that was the
reason.

As Ron said, getting the latest from the NIC was standard, gettable(8) was
often the way you did it.   We have a script on the Masscomp systems called
getmasterhost IIRC that was a little more programmable because so many
customers were not yet on the Internet, most were not yet running BIND or
the equivalent and kept a static master table some where (and we must have
taught them how to so that in the System Managers' guide).
ᐧ

On Fri, Apr 19, 2019 at 2:43 PM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Thu, Apr 18, 2019 at 10:33 PM <reed at reedmedia.net> wrote:
>
>> This email is two parts. I am researching 1970's symbolic name to
>> network address mapping routines.
>>
>> 1) I am looking for parsers for ancient (pre mid 1982) HOSTS.TXT. Since
>> this is Unix list, for Unix is fine :)
>>
> Got to Warren's archives for BSD 4.2 and look for the htable(8) and
> gettable(8).  I believe the parsing routines will be in htable(8).
> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190419/a0b644e1/attachment.html>

From reed at reedmedia.net  Sat Apr 20 07:52:10 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Fri, 19 Apr 2019 16:52:10 -0500 (CDT)
Subject: [TUHS] looking for HOSTS.TXT parsers and how is
 /dev/net/HOSTNAME enabled?
In-Reply-To: <CAC20D2OOtRZA0PXWUj6JJBHjWT3337dbzfN3VBT7NxKNJS5JoA@mail.gmail.com>
References: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
 <CAC20D2OOtRZA0PXWUj6JJBHjWT3337dbzfN3VBT7NxKNJS5JoA@mail.gmail.com>
Message-ID: <alpine.NEB.2.21.1904191553470.2488@t1.m.reedmedia.net>

Replying to two messages here:

On Fri, 19 Apr 2019, Lars Brinkhoff wrote:
> Here is a collection, but most of them are from after that date.
> 
> https://github.com/ttkzw/hosts.txt

Thanks. I should have mentioned I looked there. It doesn't have it as 
far as I see. It has the same data for the pre-1982 files I already 
have (but they are not RFC 608 style).

But it was interesting to see the three MIT/Stanford versions. I think 
they have a different format unless I misunderstand. Since I cannot find 
SRI-NIC examples (before RFC 810) I don't know for sure.  
https://github.com/ttkzw/hosts.txt/blob/master/pub/hosts/19830119/HOSTS.TXT

If you can point me to PDP-10 ITS routines, I'd appreciate it.

On Fri, 19 Apr 2019, Clem Cole wrote:
>       1) I am looking for parsers for ancient (pre mid 1982)
...
> Got to Warren's archives for BSD 4.2 and look for the htable(8) and
> gettable(8).? I believe the parsing routines will be in htable(8).

Thanks. I have them already (including 4.1c.2). They are the newer 
format. I had looked at htable before. I just looked at my sccs for it:

MRs:
COMMENTS:
date and time created 82/10/20 21:26:49 by sam

4.1     #ifndef lint
4.1     static char sccsid[] = "@(#)htable.c    4.1 (Berkeley) 10/20/82";
4.1     #endif
4.1     
4.1     /*
4.1      * htable - convert NIC host table into a UNIX format.
4.1      * NIC format is described in RFC 810, 1 March 1982.
4.1      */

I was hoping there was an early revision for previous format there, but 
that is the first revision I see in SCCS.

Thank you for reminding me and thanks for pointing me to gettable. I see 
that is a TCP client implementation of the RFC 811 NIC Internet 
Hostnames Server. Awesome. I will be writing about it.

Just noticed the long-obsolete manpage has an error; it says:

     Gettable is a simple program used to obtain the NIC standard host tables
     from a ``nicname'' server.
...
     Gettable operates by opening a TCP connection to the port indicated in
     the service specification for ``nicname''.

It is not a "nicname" client. It is a RFC 811 "hostnames" client.

The first code before 4.2BSD has:

        sp = getservbyname("nicname", "tcp");

The later code has:
        sp = getservbyname("hostnames", "tcp");

4.1c.2 /etc/services had:

nicname         101/tcp         hostname        # usually from sri-nic

4.2BSD /etc/services had:

whois           43/tcp          nicname

hostnames       101/tcp         hostname        # usually from sri-nic

nicname is RFC 812.

but the manpage never got fixed (well I didn't look after FreeBSD 1.0 
which is the newest version of gettable I have).

I was hoping that gettable(8) had HNAME/HADDR query commands then I 
think it would be a very early network name lookup tool. But it just 
had the ALL support to return entire host table.

Still looking for the pre RFC 810 tables from SRI-NIC ...


From cmhanson at eschatologist.net  Sat Apr 20 08:31:14 2019
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Fri, 19 Apr 2019 15:31:14 -0700
Subject: [TUHS] Paper discussing Unix boot process?
In-Reply-To: <alpine.LFD.2.21.1904101246310.2133@booboo.lectroid.com>
References: <alpine.LFD.2.21.1904101246310.2133@booboo.lectroid.com>
Message-ID: <F4C56E6E-238A-4A32-8A26-9C996A5404FC@eschatologist.net>

It may not be exactly what you were thinking of, but there have been a few “bring-up” papers to come out of NetBSD about getting it working on new CPU architectures and new system types. Perhaps one of those is what you read?

  -- Chris


From clemc at ccc.com  Sat Apr 20 08:50:50 2019
From: clemc at ccc.com (Clem Cole)
Date: Fri, 19 Apr 2019 18:50:50 -0400
Subject: [TUHS] looking for HOSTS.TXT parsers and how is
 /dev/net/HOSTNAME enabled?
In-Reply-To: <alpine.NEB.2.21.1904191553470.2488@t1.m.reedmedia.net>
References: <alpine.NEB.2.21.1904181949240.2488@t1.m.reedmedia.net>
 <CAC20D2OOtRZA0PXWUj6JJBHjWT3337dbzfN3VBT7NxKNJS5JoA@mail.gmail.com>
 <alpine.NEB.2.21.1904191553470.2488@t1.m.reedmedia.net>
Message-ID: <CAC20D2Nw18_JwYPfwn2QKEy8vnNeQrB+xA65+cAd_aNWHm2ACQ@mail.gmail.com>

Frankly, I don't remember what Rob did but you might want to poke around
the BBN archives too which Warren should also have.    Gurwitz might have
written something before the UCB code came about that used ftp.  At CMU we
used rsync between the UNIX boxes for files like the host table, (that
where rsync was originally written for those that's don't know); but how it
was kept up to date from the 10's -- I don't remember.   As Lars said, MIT
would have used ITS as its master before the DNS was birthed, but how the
UNIX boxes got it from there is unknown to me [Noel do you know?].

Clem
ᐧ
ᐧ

On Fri, Apr 19, 2019 at 5:53 PM <reed at reedmedia.net> wrote:

> Replying to two messages here:
>
> On Fri, 19 Apr 2019, Lars Brinkhoff wrote:
> > Here is a collection, but most of them are from after that date.
> >
> > https://github.com/ttkzw/hosts.txt
>
> Thanks. I should have mentioned I looked there. It doesn't have it as
> far as I see. It has the same data for the pre-1982 files I already
> have (but they are not RFC 608 style).
>
> But it was interesting to see the three MIT/Stanford versions. I think
> they have a different format unless I misunderstand. Since I cannot find
> SRI-NIC examples (before RFC 810) I don't know for sure.
> https://github.com/ttkzw/hosts.txt/blob/master/pub/hosts/19830119/HOSTS.TXT
>
> If you can point me to PDP-10 ITS routines, I'd appreciate it.
>
> On Fri, 19 Apr 2019, Clem Cole wrote:
> >       1) I am looking for parsers for ancient (pre mid 1982)
> ...
> > Got to Warren's archives for BSD 4.2 and look for the htable(8) and
> > gettable(8).? I believe the parsing routines will be in htable(8).
>
> Thanks. I have them already (including 4.1c.2). They are the newer
> format. I had looked at htable before. I just looked at my sccs for it:
>
> MRs:
> COMMENTS:
> date and time created 82/10/20 21:26:49 by sam
>
> 4.1     #ifndef lint
> 4.1     static char sccsid[] = "@(#)htable.c    4.1 (Berkeley) 10/20/82";
> 4.1     #endif
> 4.1
> 4.1     /*
> 4.1      * htable - convert NIC host table into a UNIX format.
> 4.1      * NIC format is described in RFC 810, 1 March 1982.
> 4.1      */
>
> I was hoping there was an early revision for previous format there, but
> that is the first revision I see in SCCS.
>
> Thank you for reminding me and thanks for pointing me to gettable. I see
> that is a TCP client implementation of the RFC 811 NIC Internet
> Hostnames Server. Awesome. I will be writing about it.
>
> Just noticed the long-obsolete manpage has an error; it says:
>
>      Gettable is a simple program used to obtain the NIC standard host
> tables
>      from a ``nicname'' server.
> ...
>      Gettable operates by opening a TCP connection to the port indicated in
>      the service specification for ``nicname''.
>
> It is not a "nicname" client. It is a RFC 811 "hostnames" client.
>
> The first code before 4.2BSD has:
>
>         sp = getservbyname("nicname", "tcp");
>
> The later code has:
>         sp = getservbyname("hostnames", "tcp");
>
> 4.1c.2 /etc/services had:
>
> nicname         101/tcp         hostname        # usually from sri-nic
>
> 4.2BSD /etc/services had:
>
> whois           43/tcp          nicname
>
> hostnames       101/tcp         hostname        # usually from sri-nic
>
> nicname is RFC 812.
>
> but the manpage never got fixed (well I didn't look after FreeBSD 1.0
> which is the newest version of gettable I have).
>
> I was hoping that gettable(8) had HNAME/HADDR query commands then I
> think it would be a very early network name lookup tool. But it just
> had the ALL support to return entire host table.
>
> Still looking for the pre RFC 810 tables from SRI-NIC ...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190419/00e6ddad/attachment.html>

From jon at fourwinds.com  Sun Apr 21 05:00:41 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 20 Apr 2019 12:00:41 -0700
Subject: [TUHS] UNIX System Internals
Message-ID: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com>

Don't know if this is of interest to anybody out there, but I was
just looking for something else in the basement and came across
two notebooks that look like a UNIX System Internals course.  Appears
to cover version 6, version 7, PWB, 32V, System III, and System V.
Has the Western Electric seal of disapproval on the front.

Jon

From rmswierczek at gmail.com  Sun Apr 21 05:17:03 2019
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Sat, 20 Apr 2019 15:17:03 -0400
Subject: [TUHS] UNIX System Internals
In-Reply-To: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com>
References: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com>
Message-ID: <CAAFR5pYR5spgknY9kJsLvnt3n2AOPKR0=whZ5+beC76bbuiy=w@mail.gmail.com>

Yes indeed, I am interested!

From pechter at gmail.com  Sun Apr 21 05:27:57 2019
From: pechter at gmail.com (William Pechter)
Date: Sat, 20 Apr 2019 15:27:57 -0400
Subject: [TUHS] UNIX System Internals
In-Reply-To: <CAAFR5pYR5spgknY9kJsLvnt3n2AOPKR0=whZ5+beC76bbuiy=w@mail.gmail.com>
References: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com>
 <CAAFR5pYR5spgknY9kJsLvnt3n2AOPKR0=whZ5+beC76bbuiy=w@mail.gmail.com>
Message-ID: <CALwkMd0JhhEjAgWhckYky09bsZ_cuv6o+kzffJ3PmGwYpwmxpQ@mail.gmail.com>

Perhaps Warren can archive it.  If the copyright issues could be handled, I
would kill for a copy...

On Sat, Apr 20, 2019, 15:25 Robert Swierczek <rmswierczek at gmail.com> wrote:

> Yes indeed, I am interested!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190420/ce766377/attachment.html>

From jon at fourwinds.com  Sun Apr 21 05:31:34 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 20 Apr 2019 12:31:34 -0700
Subject: [TUHS] UNIX System Internals
In-Reply-To: <CALwkMd0JhhEjAgWhckYky09bsZ_cuv6o+kzffJ3PmGwYpwmxpQ@mail.gmail.com>
References: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com>
 <CAAFR5pYR5spgknY9kJsLvnt3n2AOPKR0=whZ5+beC76bbuiy=w@mail.gmail.com>
 <CALwkMd0JhhEjAgWhckYky09bsZ_cuv6o+kzffJ3PmGwYpwmxpQ@mail.gmail.com>
Message-ID: <201904201931.x3KJVZLN014194@darkstar.fourwinds.com>

Robert Swierczek writes:
> Yes indeed, I am interested!

William Pechter writes:
> Perhaps Warren can archive it.  If the copyright issues could be handled, I
> would kill for a copy...

OK, well, how do we make this happen?  I'm up in the boonies in Oregon,
don't have an easy way to scan something that big.  I will be in the
bay area next week, and will see Clem and might be able to get him to
haul it back east if that would help.

Funny thing is that I'm not sure that I've ever even looked at the thing.
It's in mint conditions.  Don't have any idea where it came from, maybe
someone else gave me a copy.

Jon

From norman at oclsc.org  Sun Apr 21 06:20:58 2019
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 20 Apr 2019 16:20:58 -0400
Subject: [TUHS] UNIX System Internals
Message-ID: <1555791664.9155.for-standards-violators@oclsc.org>

I'd love to see this stuff.  Were I not so far away I'd offer
to scan them for you, but it shouldn't be hard to find someone
who can in the Bay Area.  (Attention USENIX Association, I
approve use of my membership dues to support this!)

Norman Wilson
Toronto ON

From jblecker at eclipso.eu  Sun Apr 21 07:02:44 2019
From: jblecker at eclipso.eu (John Blecker)
Date: Sat, 20 Apr 2019 23:02:44 +0200
Subject: [TUHS] UNIX System Internals
In-Reply-To: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com>
References: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com>
Message-ID: <32b0c296c5ddca3dbffa18994c67768b@mail.eclipso.de>

Hi,

I'm interested too.

Thanx a lot in advance.

- M
--- original message ---
From: Jon Steinhart <jon at fourwinds.com>
Date: 20.04.2019 21:00:41
To: tuhs at tuhs.org
Subject: [TUHS] UNIX System Internals

> Don't know if this is of interest to anybody out there, but I was
> just looking for something else in the basement and came across
> two notebooks that look like a UNIX System Internals course.  Appears
> to cover version 6, version 7, PWB, 32V, System III, and System V.
> Has the Western Electric seal of disapproval on the front.
> 
> Jon
> 


---

Take your mailboxes with you. Free, fast and secure Mail &amp; Cloud: https://www.eclipso.eu - Time to change!



From gtaylor at tnetconsulting.net  Sun Apr 21 07:18:26 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 20 Apr 2019 15:18:26 -0600
Subject: [TUHS] UNIX System Internals
In-Reply-To: <201904201931.x3KJVZLN014194@darkstar.fourwinds.com>
References: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com>
 <CAAFR5pYR5spgknY9kJsLvnt3n2AOPKR0=whZ5+beC76bbuiy=w@mail.gmail.com>
 <CALwkMd0JhhEjAgWhckYky09bsZ_cuv6o+kzffJ3PmGwYpwmxpQ@mail.gmail.com>
 <201904201931.x3KJVZLN014194@darkstar.fourwinds.com>
Message-ID: <0cdc4e00-bce9-cd68-193f-1c78323a8c5e@spamtrap.tnetconsulting.net>

On 4/20/19 1:31 PM, Jon Steinhart wrote:
> OK, well, how do we make this happen?

I'm guessing we're talking about something like 3" binders with loos 
leaf in them?

How much would it cost to ship (with tracking and desired insurance) it 
to someone who could scan it and return it to you?

I'll raise my hand and toss $10 to group shipping fund.



-- 
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/20190420/9eda3670/attachment.bin>

From rmswierczek at gmail.com  Sun Apr 21 08:18:23 2019
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Sat, 20 Apr 2019 18:18:23 -0400
Subject: [TUHS] UNIX System Internals
In-Reply-To: <0cdc4e00-bce9-cd68-193f-1c78323a8c5e@spamtrap.tnetconsulting.net>
References: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com>
 <CAAFR5pYR5spgknY9kJsLvnt3n2AOPKR0=whZ5+beC76bbuiy=w@mail.gmail.com>
 <CALwkMd0JhhEjAgWhckYky09bsZ_cuv6o+kzffJ3PmGwYpwmxpQ@mail.gmail.com>
 <201904201931.x3KJVZLN014194@darkstar.fourwinds.com>
 <0cdc4e00-bce9-cd68-193f-1c78323a8c5e@spamtrap.tnetconsulting.net>
Message-ID: <CAAFR5pbOGe2LmRiEor-fYooYPe6hPr3m5dsghB61ngMKqbxLdA@mail.gmail.com>

I'm happy to volunteer to scan and return them.  I have a few other
UNIX related things I need to scan as well.

I will be at the Vintage Computer Festival East the first weekend of
May.  If there is an interest in meeting up, I can set up a scanning
party in a nearby hotel suite, bring hardware, folding tables, chairs,
etc..

From jnc at mercury.lcs.mit.edu  Sun Apr 21 08:42:41 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 20 Apr 2019 18:42:41 -0400 (EDT)
Subject: [TUHS] UNIX System Internals
Message-ID: <20190420224241.489E218C09F@mercury.lcs.mit.edu>

    > From: Jon Steinhart

    > OK, well, how do we make this happen?

Is it bound or un-bound, and if the former, are you OK with unbinding it?

If the former, and 'no', we either need to rope in someone with one of those
special rigs for scanning books, or do it by hand.

If not, I have an auto-feed scanner, and volunteer to do it. How large are
the pages?

    Noel

From imp at bsdimp.com  Sun Apr 21 08:47:09 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 20 Apr 2019 16:47:09 -0600
Subject: [TUHS] UNIX System Internals
In-Reply-To: <20190420224241.489E218C09F@mercury.lcs.mit.edu>
References: <20190420224241.489E218C09F@mercury.lcs.mit.edu>
Message-ID: <CANCZdfovWDMEzb9NYFbh4-cRKT+cLuHmnUf-qSNwvw8ZYe-YJQ@mail.gmail.com>

On Sat, Apr 20, 2019 at 4:43 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Jon Steinhart
>
>     > OK, well, how do we make this happen?
>
> Is it bound or un-bound, and if the former, are you OK with unbinding it?
>
> If the former, and 'no', we either need to rope in someone with one of
> those
> special rigs for scanning books, or do it by hand.
>
> If not, I have an auto-feed scanner, and volunteer to do it. How large are
> the pages?
>

I have a sheet-feed scanner that can do hundreds of pages an hour and would
be willing to get the docs, scan then in, proof read them to make sure the
scan was good, and then return the original. I'd be uncomfortable
unbinding...

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

From jon at fourwinds.com  Sun Apr 21 08:53:07 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 20 Apr 2019 15:53:07 -0700
Subject: [TUHS] UNIX System Internals
In-Reply-To: <CANCZdfovWDMEzb9NYFbh4-cRKT+cLuHmnUf-qSNwvw8ZYe-YJQ@mail.gmail.com>
References: <20190420224241.489E218C09F@mercury.lcs.mit.edu>
 <CANCZdfovWDMEzb9NYFbh4-cRKT+cLuHmnUf-qSNwvw8ZYe-YJQ@mail.gmail.com>
Message-ID: <201904202253.x3KMr7LR010510@darkstar.fourwinds.com>

OK, let's make some decisions here since everybody wants to see this and is
willing to help.

This is two 3" binders of 8 1/2 x 11 paper.  It's in really good shape and
should be easy to scan.  I live in the boonies outside of Portland, Oregon.
I'm driving to the bay area with stops in San Franciso and Palo Alto on my
way to the Asilomar Microcomputer Workshop.  The binders are already in my
car so I don't forget them.

So, should these stay on the west coast or head east?  If east, Clem will
be at the workshop and it sounds like he's willing to take them back with
him.  If someone out west is able to scan them, I'll drop them off when
I'm passing through.

Don't all fight over it, just figure out who's gonna do it and I'll get them
there.

Jon

From imp at bsdimp.com  Sun Apr 21 08:56:10 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 20 Apr 2019 16:56:10 -0600
Subject: [TUHS] UNIX System Internals
In-Reply-To: <201904202253.x3KMr7LR010510@darkstar.fourwinds.com>
References: <20190420224241.489E218C09F@mercury.lcs.mit.edu>
 <CANCZdfovWDMEzb9NYFbh4-cRKT+cLuHmnUf-qSNwvw8ZYe-YJQ@mail.gmail.com>
 <201904202253.x3KMr7LR010510@darkstar.fourwinds.com>
Message-ID: <CANCZdfphJENY7q5yGV2sLKHTK0Kzz=0U3z=ODo7tY13OcLVqFQ@mail.gmail.com>

On Sat, Apr 20, 2019 at 4:53 PM Jon Steinhart <jon at fourwinds.com> wrote:

> OK, let's make some decisions here since everybody wants to see this and is
> willing to help.
>
> This is two 3" binders of 8 1/2 x 11 paper.  It's in really good shape and
> should be easy to scan.  I live in the boonies outside of Portland, Oregon.
> I'm driving to the bay area with stops in San Franciso and Palo Alto on my
> way to the Asilomar Microcomputer Workshop.  The binders are already in my
> car so I don't forget them.
>
> So, should these stay on the west coast or head east?  If east, Clem will
> be at the workshop and it sounds like he's willing to take them back with
> him.  If someone out west is able to scan them, I'll drop them off when
> I'm passing through.
>
> Don't all fight over it, just figure out who's gonna do it and I'll get
> them
> there.
>

Sadly, I'm in Denver CO. But I'll also pay for shipping if other options
fall through.

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

From jon at fourwinds.com  Sun Apr 21 08:57:27 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 20 Apr 2019 15:57:27 -0700
Subject: [TUHS] Joe Condon [ long, slightly off-topic post ]
Message-ID: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com>

So as part of my attempt to remember the names of the folks with who I worked
I just read Joe's wikipedia page which doesn't seem accurate to me.  If this
is too off topic let me know.

The page says that Joe "was exposed to UNIX on the Honeywell 516 machines in
the early 1970s."  This seems wrong to me.  We did have a 516, but it ran an
experimental virtual memory system called 516-TSS.  I lived on this system
and still have some of the octal instruction opcodes burned into my brain-ROM.
I seem to recall that the department got a PDP-11/40 that ran UNIX version 3 in
maybe the summer of 1972 which I used for writing up the documentation for my
project.

The page also says that "Condon and Ken Thompson promoted the use of the C
programming language for AT&T’s switching system control programs.  Condon
acquired a small AT&T PBX (telephone switch) that handled about 50 phones;
he made the necessary hardware changes and Thompson wrote the necessary software
programs. The PBX code rewrite in C was a success and hastened the adoption of
C for all switching system software within AT&T."  This also doesn't match my
recollection.

One of the big projects in the department was what I think was called SS1 for
Slave Switch 1, which was an all-digital telephone exchange.  It replaced some
other monstrosity whose details I can't recall except that Joe and Dave Weller
signed the appropriate paperwork allowing me to take a good portion of it home
when it was decommissioned giving me a huge stock of Augat wirewrap boards and
7400-series parts.  The SS1 was originally going to use LSI-11s but the stupid
way in which DEC implemented the DRAM refresh made that impossible.  I think
that the final thing used a couple of PDP-10s.  As part of being all-digital
it used the digital filter work by Jim Kaiser and Hal Alles.  I do remember
going into Carl Christensen's office to ask him a question and found him staring
at a huge C listing; it turns out that a bug in the code had caused SS1 to send
KP pulses without their corresponding ST pulses with the result that every single
keypulse sender in the Berkeley Heights telephone exchange was taken off line and
needed to be manually reset to restore long distance service.  They were not happy.

Anyway, unless there was something that happened later after I was gone, I'm
thinking that the wikipedia page is incorrect and that this PBX was built, not
acquired.  It was, as far as I know, the first use of C to control machinery.

It's actually because of this machine that I'm trying to track down the name
of some folks from down at the end of the hall.  I have strong memories of the
Bell System exhibit at the '64 World's Fair, especially the booth where one
could go and talk and they had bar graphs on a monitor showing the spectrum
of your speech and could mess with it.  Many years later, while waiting for
some deck of cards to finish loading, I poked my head into the lab down the
hall to see what they were doing in there, and noticed polaroid photos of that
exhibit featuring the guys in the lab.  Once they stopped telling stories from
the World's Fair, they taught me a lesson about systems engineering that opened
my eyes.  They were developing a circuit that replaced the pound of iron hybrid
transformers that were on every telephone line with a small toroid and an op-amp.
Their circuit would sense when the iron was getting close to saturation and run
current through an additional winding to keep it in the linear region.  While
that circuit cost a lot more than a hybrid transformer, it paid for itself by
reducing the amount of concrete needed to build telephone exchanges.

Would love to know who these guys were which is why an org chart would help.
And maybe someone out there like Ken can help me out with the accurate history.

Jon

From drb at msu.edu  Sun Apr 21 10:22:11 2019
From: drb at msu.edu (Dennis Boone)
Date: Sat, 20 Apr 2019 20:22:11 -0400
Subject: [TUHS] 516-TSS, was re: Joe Condon
In-Reply-To: (Your message of Sat, 20 Apr 2019 15:57:27 -0700.)
 <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com>
References: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com> 
Message-ID: <20190421002212.2E1861AF502@yagi.h-net.msu.edu>

 > The page says that Joe "was exposed to UNIX on the Honeywell 516
 > machines in the early 1970s."  This seems wrong to me.  We did have a
 > 516, but it ran an experimental virtual memory system called 516-TSS.
 > I lived on this system and still have some of the octal instruction
 > opcodes burned into my brain-ROM.

As a Prime 50-Series buff, I'd be interested in knowing more about this
516-TSS.  Pointers appreciated, if there are any bits, documentation, or
war stories lurking about.

De

From jon at fourwinds.com  Sun Apr 21 11:00:14 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sat, 20 Apr 2019 18:00:14 -0700
Subject: [TUHS] 516-TSS, was re: Joe Condon
In-Reply-To: <20190421002212.2E1861AF502@yagi.h-net.msu.edu>
References: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com>
 <20190421002212.2E1861AF502@yagi.h-net.msu.edu>
Message-ID: <201904210100.x3L10EYK027747@darkstar.fourwinds.com>

Dennis Boone writes:
>  > The page says that Joe "was exposed to UNIX on the Honeywell 516
>  > machines in the early 1970s."  This seems wrong to me.  We did have a
>  > 516, but it ran an experimental virtual memory system called 516-TSS.
>  > I lived on this system and still have some of the octal instruction
>  > opcodes burned into my brain-ROM.
>
> As a Prime 50-Series buff, I'd be interested in knowing more about this
> 516-TSS.  Pointers appreciated, if there are any bits, documentation, or
> war stories lurking about.
>
> De

Well, if I could find my org chart I would probably find it with the 516-TSS
docs.  Here's a little bit of what I can remember...

Our machine had a whopping 12K 16 bit words of core memory, and a 500K disk.
I think that at some point we added another 4K of expensive but faster DRAM.
This sticks in my mind because it was fragile, and when we moved from building
2 to the newly constructed building 7 someone in the group decided to hand-carry
the memory but got caught by the union movers who lectured him on taking food
out of the mouths of their families.

I believe that much of the work on 516-TSS was done by Carl Christensen and
Heinz Lycklama.  Since Heinz is still alive you could ask him if he remembers
anything about it.

The 516 architecture included an index register.  This was used as the base
address register for the VM system.  I recall that there were special acrobatics
that I had to go through if I actually needed to use the index register, probably
involved turning off interrupts or something.

The system was multi-tasking, and was the main machine that the explorer scouts
used.  This is how I got involved before my youthful exuberance and the fact that
I was cutting school and hitchhiking up to the labs so that I could play with it
on non-scouting days got me hired.

The coolest thing about the system was "the loop" which I think was designed by
Dave Weller and Sandy Fraser.  It was an early LAN.  I remember that it had special
repeaters using the hot tech of the time, 74S00s.  Since it was a loop configuration
everyone had in and out jacks in their offices and labs.  When it was meeting time
and people weren't showing up Joe would unplug his to take the network down.  I also
remember one day when the error rate went through the roof; turned out some guy in a
lab down the hall left some cover off of his cyclotron.  Comforting.

One of the main things on the loop were the Glance-G graphics terminals, an early
vector graphics display.  That's what I was working on.  If I remember correctly
they had 74S181 bit slice ALUs and 1101 DRAMs.  Lots of cool stuff was done on them
including graphics editors, a display that showed the phone network routing around
faults which, of course, it no longer does.  The graphics that I did was used by
Jim Kaiser for his digital filter work.

I have some really vague memory of a Glance-G in the UNIX lab.

Some other departments had their own systems.  I eventually moved to area 20 to
work on a 516-TSS based integrated circuit test system where we had things like
wafer steppers and measurement equipment on the loop.  The main high-level language
on the system was called FSNAP, where the F was for floating point and SNAP was from
the SNAP language.  I remember adding pseudo-codes and statements to the language to
support IC test.

Other than that the system was nothing special.  Only had a single-level file system.
It was a great system for me a the time, but once we got our PDP-11 and UNIX I didn't
look back.

Oh, and we had a facility that let a modem on our system call the computer center to
submit printer and card punch jobs and such.  It had the ability to get called back
if we submitted compute jobs.  This may have been the predecessor to the UNIX gerts
command.

There's a special place in my heart for the computer center calling facility.  I had
finished up a large project and sent the whole thing up to the computer center to get
it all printed and cards punched.  I had sent so much stuff that I really annoyed the
summer student who was working in the computer center.  We spent a lot of time together
after she calmed down.  I tracked her down a few years ago and we're still friends.

Jon

From gtaylor at tnetconsulting.net  Sun Apr 21 11:07:43 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 20 Apr 2019 19:07:43 -0600
Subject: [TUHS] UNIX System Internals
In-Reply-To: <CANCZdfphJENY7q5yGV2sLKHTK0Kzz=0U3z=ODo7tY13OcLVqFQ@mail.gmail.com>
References: <20190420224241.489E218C09F@mercury.lcs.mit.edu>
 <CANCZdfovWDMEzb9NYFbh4-cRKT+cLuHmnUf-qSNwvw8ZYe-YJQ@mail.gmail.com>
 <201904202253.x3KMr7LR010510@darkstar.fourwinds.com>
 <CANCZdfphJENY7q5yGV2sLKHTK0Kzz=0U3z=ODo7tY13OcLVqFQ@mail.gmail.com>
Message-ID: <19e6f57a-1705-a19f-8af6-0b4c18b5197e@spamtrap.tnetconsulting.net>

On 4/20/19 4:56 PM, Warner Losh wrote:
> Sadly, I'm in Denver CO. But I'll also pay for shipping if other options 
> fall through.

I'm in the greater Denver area too.  But I'm not sad about it.  I'm just 
sad that I don't have the readily available option to participate in 
things and meet more people.

I'll buy a cup of coffee / drink if you're interested.



-- 
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/20190420/c4b6e9b0/attachment.bin>

From khm at sciops.net  Sun Apr 21 12:18:33 2019
From: khm at sciops.net (Kurt H Maier)
Date: Sat, 20 Apr 2019 19:18:33 -0700
Subject: [TUHS] UNIX System Internals
In-Reply-To: <201904202253.x3KMr7LR010510@darkstar.fourwinds.com>
References: <20190420224241.489E218C09F@mercury.lcs.mit.edu>
 <CANCZdfovWDMEzb9NYFbh4-cRKT+cLuHmnUf-qSNwvw8ZYe-YJQ@mail.gmail.com>
 <201904202253.x3KMr7LR010510@darkstar.fourwinds.com>
Message-ID: <20190421021833.GA21700@wopr>

On Sat, Apr 20, 2019 at 03:53:07PM -0700, Jon Steinhart wrote:
>
> This is two 3" binders of 8 1/2 x 11 paper.  It's in really good shape and
> should be easy to scan.  I live in the boonies outside of Portland, Oregon.
        
If all else fails, I have a document-feed scanner and I live in the     
boonies in Washington state, so I can come and get them, scan them, and
return them.  I've been looking for an excuse to ride the Columbia River
Gorge anyway.  

khm

From mah at mhorton.net  Sun Apr 21 13:07:33 2019
From: mah at mhorton.net (Mary Ann Horton Gmail)
Date: Sat, 20 Apr 2019 20:07:33 -0700
Subject: [TUHS] 516-TSS, was re: Joe Condon
In-Reply-To: <20190421002212.2E1861AF502@yagi.h-net.msu.edu>
References: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com>
 <20190421002212.2E1861AF502@yagi.h-net.msu.edu>
Message-ID: <b17bc584-709b-07f2-9927-df420933591e@mhorton.net>

The Honeywell 516 was the basis for the ARPANET IMP, which later became 
the ARPANET TIP (on a 316 by then.)  The IMP was the router that held 
the ARPANET together, the TIP an enhanced version that allowed terminals 
to telnet to hosts on the net.  This version of the 516 didn't run 
anything like UNIX.

Is it possible he got access via the ARPANET?  Or that somehow his 
access got confused with the ARPANET?

     Mary Ann

On 4/20/19 5:22 PM, Dennis Boone wrote:
>   > The page says that Joe "was exposed to UNIX on the Honeywell 516
>   > machines in the early 1970s."  This seems wrong to me.  We did have a
>   > 516, but it ran an experimental virtual memory system called 516-TSS.
>   > I lived on this system and still have some of the octal instruction
>   > opcodes burned into my brain-ROM.
>
> As a Prime 50-Series buff, I'd be interested in knowing more about this
> 516-TSS.  Pointers appreciated, if there are any bits, documentation, or
> war stories lurking about.
>
> De

From gtaylor at tnetconsulting.net  Sun Apr 21 13:52:59 2019
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 20 Apr 2019 21:52:59 -0600
Subject: [TUHS] 516-TSS, was re: Joe Condon
In-Reply-To: <b17bc584-709b-07f2-9927-df420933591e@mhorton.net>
References: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com>
 <20190421002212.2E1861AF502@yagi.h-net.msu.edu>
 <b17bc584-709b-07f2-9927-df420933591e@mhorton.net>
Message-ID: <db342c2d-9553-6102-1d7d-b4f27408d098@spamtrap.tnetconsulting.net>

On 4/20/19 9:07 PM, Mary Ann Horton Gmail wrote:
> This version of the 516 didn't run anything like UNIX.

What OS did the 516 / TIP run?



-- 
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/20190420/68fc424d/attachment.bin>

From robpike at gmail.com  Sun Apr 21 15:52:13 2019
From: robpike at gmail.com (Rob Pike)
Date: Sun, 21 Apr 2019 15:52:13 +1000
Subject: [TUHS] Joe Condon [ long, slightly off-topic post ]
In-Reply-To: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com>
References: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com>
Message-ID: <CAKzdPgyqfrO0=Ld7mi0rzwoqh-ScDqAGg3aL7CM_cygV8wj1xA@mail.gmail.com>

The Unix on 516s sounds wrong to me. Perhaps it conflates GCOS remote job
entry and Unix?

But the PBX story is correct. To demonstrate how message passing was a good
model for a switching system, in particular to make a point to the
switching systems division of Bell Labs/AT&T, Ken and Joe bought a
commercial PBX and swapped out its processor for a PDP-11/23 (I think), and
programmed it up. It was just before I arrived there but I was given the
impression it had the desired strategic influence on Indian Hill.

The feature we all loved it for was that instead of ringing the phone in
the Unix room when you got a call, it would announce your name through the
voice synthesizer: "Phone call for Ken." "Phone call for Joe". One rapidly
stopped even hearing the announcement if it didn't end with your name.

-rob


On Sun, Apr 21, 2019 at 8:58 AM Jon Steinhart <jon at fourwinds.com> wrote:

> So as part of my attempt to remember the names of the folks with who I
> worked
> I just read Joe's wikipedia page which doesn't seem accurate to me.  If
> this
> is too off topic let me know.
>
> The page says that Joe "was exposed to UNIX on the Honeywell 516 machines
> in
> the early 1970s."  This seems wrong to me.  We did have a 516, but it ran
> an
> experimental virtual memory system called 516-TSS.  I lived on this system
> and still have some of the octal instruction opcodes burned into my
> brain-ROM.
> I seem to recall that the department got a PDP-11/40 that ran UNIX version
> 3 in
> maybe the summer of 1972 which I used for writing up the documentation for
> my
> project.
>
> The page also says that "Condon and Ken Thompson promoted the use of the C
> programming language for AT&T’s switching system control programs.  Condon
> acquired a small AT&T PBX (telephone switch) that handled about 50 phones;
> he made the necessary hardware changes and Thompson wrote the necessary
> software
> programs. The PBX code rewrite in C was a success and hastened the
> adoption of
> C for all switching system software within AT&T."  This also doesn't match
> my
> recollection.
>
> One of the big projects in the department was what I think was called SS1
> for
> Slave Switch 1, which was an all-digital telephone exchange.  It replaced
> some
> other monstrosity whose details I can't recall except that Joe and Dave
> Weller
> signed the appropriate paperwork allowing me to take a good portion of it
> home
> when it was decommissioned giving me a huge stock of Augat wirewrap boards
> and
> 7400-series parts.  The SS1 was originally going to use LSI-11s but the
> stupid
> way in which DEC implemented the DRAM refresh made that impossible.  I
> think
> that the final thing used a couple of PDP-10s.  As part of being
> all-digital
> it used the digital filter work by Jim Kaiser and Hal Alles.  I do remember
> going into Carl Christensen's office to ask him a question and found him
> staring
> at a huge C listing; it turns out that a bug in the code had caused SS1 to
> send
> KP pulses without their corresponding ST pulses with the result that every
> single
> keypulse sender in the Berkeley Heights telephone exchange was taken off
> line and
> needed to be manually reset to restore long distance service.  They were
> not happy.
>
> Anyway, unless there was something that happened later after I was gone,
> I'm
> thinking that the wikipedia page is incorrect and that this PBX was built,
> not
> acquired.  It was, as far as I know, the first use of C to control
> machinery.
>
> It's actually because of this machine that I'm trying to track down the
> name
> of some folks from down at the end of the hall.  I have strong memories of
> the
> Bell System exhibit at the '64 World's Fair, especially the booth where one
> could go and talk and they had bar graphs on a monitor showing the spectrum
> of your speech and could mess with it.  Many years later, while waiting for
> some deck of cards to finish loading, I poked my head into the lab down the
> hall to see what they were doing in there, and noticed polaroid photos of
> that
> exhibit featuring the guys in the lab.  Once they stopped telling stories
> from
> the World's Fair, they taught me a lesson about systems engineering that
> opened
> my eyes.  They were developing a circuit that replaced the pound of iron
> hybrid
> transformers that were on every telephone line with a small toroid and an
> op-amp.
> Their circuit would sense when the iron was getting close to saturation
> and run
> current through an additional winding to keep it in the linear region.
> While
> that circuit cost a lot more than a hybrid transformer, it paid for itself
> by
> reducing the amount of concrete needed to build telephone exchanges.
>
> Would love to know who these guys were which is why an org chart would
> help.
> And maybe someone out there like Ken can help me out with the accurate
> history.
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190421/a7c5d6a3/attachment.html>

From jnc at mercury.lcs.mit.edu  Mon Apr 22 00:15:52 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 21 Apr 2019 10:15:52 -0400 (EDT)
Subject: [TUHS] 516-TSS, was re: Joe Condon
Message-ID: <20190421141552.BA61018C0AA@mercury.lcs.mit.edu>

    > From: Grant Taylor

    > What OS did the 516 / TIP run?

Google is your friend. A Web search for 'ARPANET IMP software' will answer your
question.

	Noel

From jon at fourwinds.com  Mon Apr 22 02:46:29 2019
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 21 Apr 2019 09:46:29 -0700
Subject: [TUHS] Joe Condon [ long, slightly off-topic post ]
In-Reply-To: <CAKzdPgyqfrO0=Ld7mi0rzwoqh-ScDqAGg3aL7CM_cygV8wj1xA@mail.gmail.com>
References: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com>
 <CAKzdPgyqfrO0=Ld7mi0rzwoqh-ScDqAGg3aL7CM_cygV8wj1xA@mail.gmail.com>
Message-ID: <201904211646.x3LGkTw0031117@darkstar.fourwinds.com>

Rob Pike writes:
>
> The Unix on 516s sounds wrong to me. Perhaps it conflates GCOS remote job
> entry and Unix?
>
> But the PBX story is correct. To demonstrate how message passing was a good
> model for a switching system, in particular to make a point to the
> switching systems division of Bell Labs/AT&T, Ken and Joe bought a
> commercial PBX and swapped out its processor for a PDP-11/23 (I think), and
> programmed it up. It was just before I arrived there but I was given the
> impression it had the desired strategic influence on Indian Hill.
>
> The feature we all loved it for was that instead of ringing the phone in
> the Unix room when you got a call, it would announce your name through the
> voice synthesizer: "Phone call for Ken." "Phone call for Joe". One rapidly
> stopped even hearing the announcement if it didn't end with your name.
>
> -rob

Well, I think at this point I know that the 516 part of the story is incorrect
but am not sure exactly what is correct so I'm not going to edit it.  The GCOS
remote job entry had nothing to do with UNIX.  As I said earlier, it may have
been the model for UNIX V3 gerts but I don't know the timing.  I do remember
finding the V3 manual entertaining, I seem to remember that the gerts man page
that said something like "using this command requires divine guidance".  In
hindsight, this probably influenced my own documentation style.

The PBX story must be after my time.  Makes me wonder what ever happened to
the SS1 project.  Since it was written in C I would surmise that it laid the
groundwork for using C in the PBX project.

From arnold at skeeve.com  Tue Apr 23 05:15:35 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 22 Apr 2019 13:15:35 -0600
Subject: [TUHS] VCF East in May
In-Reply-To: <CAC0cEp-_XgjiU+2xcpJuMxwK0PdUhY0jM5ntLXdck2LB5f8JQw@mail.gmail.com>
References: <20190413225903.GA8566@minnie.tuhs.org>
 <CAAFR5pZ=JNKdLtabOe8gv3B7Xzmybf0XxFPikPyarK89mB78kA@mail.gmail.com>
 <201904191018.x3JAI9ml023554@freefriends.org>
 <CAC0cEp-_XgjiU+2xcpJuMxwK0PdUhY0jM5ntLXdck2LB5f8JQw@mail.gmail.com>
Message-ID: <201904221915.x3MJFZa7018938@freefriends.org>

Thanks for that link. It was an interesting watch.

Arnold

"John P. Linderman" <jpl.jpl at gmail.com> wrote:

> I asked Brian if the interview would be recorded and made available to the
> public. Here's what he said:
>
> I think so.  I was interviewed there in the same setting a few
> years ago and the video is on Youtube (which I hadn't known until
> searching for it just now):
>
>    https://www.youtube.com/watch?v=-dxTlU0CB8g
>
>
> On Fri, Apr 19, 2019 at 6:19 AM <arnold at skeeve.com> wrote:
>
> > Robert Swierczek <rmswierczek at gmail.com> wrote:
> >
> > > I will be making the pilgrimage from Virginia and would love to meet
> > > anyone who will be there.
> >
> > If "someone" could record the conversation between BWK & Ken and
> > make it available (YouTube or othrwise), that'd be really cool. :-)
> >
> > Thanks,
> >
> > Arnold
> >

From rmswierczek at gmail.com  Wed Apr 24 08:11:01 2019
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Tue, 23 Apr 2019 18:11:01 -0400
Subject: [TUHS] New project to recreate the B compiler for the PDP-11
Message-ID: <CAAFR5pbE5mX25qzwZMp9BoGxS--dPn0CRm-ziskHDNkG5wO8kA@mail.gmail.com>

I just started a project to recreate the B compiler for the PDP-11 as
authentically as possible, given the few fragments that remain and
some educated guesswork.  It should be fun (for various definitions of
fun).

Here is the repository  https://github.com/rswier/pdp11-B

I have borrowed some tools from Warren's
https://github.com/DoctorWkt/unix-jun72

I have made a good start at reverse engineering the B run time library
in /usr/lib/libb.a.  I have tried to make the source match the same
style as the earliest C library found on the last1120c-bits tape.  The
remaining functions in libb.a include printf and printn which appear
to be written in B.  This should provide more clues needed to create
the compiler.

I am also tackling the dis-assembly of the threaded code interpreter
/usr/lib/bilib.a (which at the moment is a big mess on my hard-drive)

Later steps will include creating the B compiler itself by carefully
pruning down the last1120c C compiler.  The fun here will be to
boot-strap the B compiler without help from any existing modern
compilers.  I think TMG will come into play to make that happen.

All are welcome to contribute!

Rob

From aap at papnet.eu  Wed Apr 24 08:47:02 2019
From: aap at papnet.eu (Angelo Papenhoff)
Date: Wed, 24 Apr 2019 00:47:02 +0200
Subject: [TUHS] New project to recreate the B compiler for the PDP-11
In-Reply-To: <CAAFR5pbE5mX25qzwZMp9BoGxS--dPn0CRm-ziskHDNkG5wO8kA@mail.gmail.com>
References: <CAAFR5pbE5mX25qzwZMp9BoGxS--dPn0CRm-ziskHDNkG5wO8kA@mail.gmail.com>
Message-ID: <20190423224702.GA90155@indra.papnet.eu>

Nice project. I wanted to do something like this too at some point.
I documented B for the PDP-7 and -11 here:
http://squoze.net/B/
I have a partially working, sort of portable B compiler (in C) here:
http://squoze.net/B/b.zip

Since B is so damn portable I wanted to target a bunch of architectures.
Started amd64 and pdp-8 but then other things got in a way (a VCF) and
my attention shifted.

best,
Angelo

On 23/04/19, Robert Swierczek wrote:
> I just started a project to recreate the B compiler for the PDP-11 as
> authentically as possible, given the few fragments that remain and
> some educated guesswork.  It should be fun (for various definitions of
> fun).
> 
> Here is the repository  https://github.com/rswier/pdp11-B
> 
> I have borrowed some tools from Warren's
> https://github.com/DoctorWkt/unix-jun72
> 
> I have made a good start at reverse engineering the B run time library
> in /usr/lib/libb.a.  I have tried to make the source match the same
> style as the earliest C library found on the last1120c-bits tape.  The
> remaining functions in libb.a include printf and printn which appear
> to be written in B.  This should provide more clues needed to create
> the compiler.
> 
> I am also tackling the dis-assembly of the threaded code interpreter
> /usr/lib/bilib.a (which at the moment is a big mess on my hard-drive)
> 
> Later steps will include creating the B compiler itself by carefully
> pruning down the last1120c C compiler.  The fun here will be to
> boot-strap the B compiler without help from any existing modern
> compilers.  I think TMG will come into play to make that happen.
> 
> All are welcome to contribute!
> 
> Rob

From aap at papnet.eu  Wed Apr 24 09:12:55 2019
From: aap at papnet.eu (Angelo Papenhoff)
Date: Wed, 24 Apr 2019 01:12:55 +0200
Subject: [TUHS] New project to recreate the B compiler for the PDP-11
In-Reply-To: <CAAFR5pbE5mX25qzwZMp9BoGxS--dPn0CRm-ziskHDNkG5wO8kA@mail.gmail.com>
References: <CAAFR5pbE5mX25qzwZMp9BoGxS--dPn0CRm-ziskHDNkG5wO8kA@mail.gmail.com>
Message-ID: <20190423231255.GA91890@indra.papnet.eu>

Forgot to mention something on my site but I think I should bring it up
on the list anyway because I think it's a very neat hack
(by dmr, as scj told me):

B expects word addresses but the linker can't generate those on a byte
addressed machine. So all addresses have to be patched before calling
main at runtime. How can you do that if you link multiple files?
You will notice that the disassembled B files printn.s and printf.s
start with 'jmp 9f' and end with 'jsr r5,chain; 0'
Unfortunately we don't have the chain function but the way this
must work is the B runtime falls off into the first B object file,
which jumps to the end, calls a function to patch all addresses in
the current file, and falls off at the end itself into the next file.
The last file in the link has to be a B runtime file as well to end
the chain.

Note that this doesn't work with printn and printf because they're
inside bilib, but they have no addresses that need patching anyway,
guess you have to be careful.

aap

On 23/04/19, Robert Swierczek wrote:
> I just started a project to recreate the B compiler for the PDP-11 as
> authentically as possible, given the few fragments that remain and
> some educated guesswork.  It should be fun (for various definitions of
> fun).
> 
> Here is the repository  https://github.com/rswier/pdp11-B
> 
> I have borrowed some tools from Warren's
> https://github.com/DoctorWkt/unix-jun72
> 
> I have made a good start at reverse engineering the B run time library
> in /usr/lib/libb.a.  I have tried to make the source match the same
> style as the earliest C library found on the last1120c-bits tape.  The
> remaining functions in libb.a include printf and printn which appear
> to be written in B.  This should provide more clues needed to create
> the compiler.
> 
> I am also tackling the dis-assembly of the threaded code interpreter
> /usr/lib/bilib.a (which at the moment is a big mess on my hard-drive)
> 
> Later steps will include creating the B compiler itself by carefully
> pruning down the last1120c C compiler.  The fun here will be to
> boot-strap the B compiler without help from any existing modern
> compilers.  I think TMG will come into play to make that happen.
> 
> All are welcome to contribute!
> 
> Rob

From rmswierczek at gmail.com  Wed Apr 24 09:36:21 2019
From: rmswierczek at gmail.com (Robert Swierczek)
Date: Tue, 23 Apr 2019 19:36:21 -0400
Subject: [TUHS] New project to recreate the B compiler for the PDP-11
In-Reply-To: <20190423224702.GA90155@indra.papnet.eu>
References: <CAAFR5pbE5mX25qzwZMp9BoGxS--dPn0CRm-ziskHDNkG5wO8kA@mail.gmail.com>
 <20190423224702.GA90155@indra.papnet.eu>
Message-ID: <CAAFR5payZ0SH6_tJPAj2FFjfbKCymqOZr5GsmyRO+WDDsviAkw@mail.gmail.com>

> I documented B for the PDP-7 and -11 here: http://squoze.net/B/

Fantastic, it looks like you have solved the libb and bilib reverse engineering!

From dario at darioniedermann.it  Fri Apr 26 00:11:06 2019
From: dario at darioniedermann.it (Dario Niedermann)
Date: Thu, 25 Apr 2019 16:11:06 +0200
Subject: [TUHS] [ANN] Utilities for 4.3BSD: set post-Y2K date, etc.
Message-ID: <20190425141106.GA25487@darioniedermann.it>

Hi! I am releasing 'datekit-1.0' for 4.3BSD-Reno:  a couple of free
utilities for setting post-Y2K date and time, plus timezone and DST.

Here's a brief outtake from the README, detailing the archive contents:

[...]
date.c
    the 4.3BSD-Quasijarus `date' program,  modified to optionally accept
    4-digit years, and default to post-2000 for 2-digit years [...]
    It can also:
        + set Daylight Saving Time: option -d
            [...]
        + set a time zone: -t minutes-West-of-Greenwich.
                              Negative values for East.

rdate.c
    the `rdate' program ported from OpenBSD 2.0: it synchronizes your
    machine's clock  to that of  a remote host,  by connecting to the
    host's "time" service.
[...]

Man page for `rdate' and a Makefile for both programs are provided.

All of the above made and tested in 4.3BSD-Reno, on an emulated
VAX-11/780.

Archive for download at:
<gopher://darioniedermann.it/1/Computing/sw/datekit>

-- 
Dario Niedermann.                 Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/

From reed at reedmedia.net  Fri Apr 26 10:56:07 2019
From: reed at reedmedia.net (reed at reedmedia.net)
Date: Thu, 25 Apr 2019 19:56:07 -0500 (CDT)
Subject: [TUHS] Historical events/conferences in 2019?
Message-ID: <alpine.NEB.2.21.1904251953470.2488@t1.m.reedmedia.net>

I never heard about any history/anniversary track at Usenix in summer in 
Renton, Washington. It will be an unofficial side event if anything. I 
have no details.

I heard about the two Vintage Computer Festival events but probably too 
soon for me.

Does anyone know of any other events with a focus on the Unix 
anniversary?

From imp at bsdimp.com  Fri Apr 26 11:34:56 2019
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 25 Apr 2019 19:34:56 -0600
Subject: [TUHS] Historical events/conferences in 2019?
In-Reply-To: <alpine.NEB.2.21.1904251953470.2488@t1.m.reedmedia.net>
References: <alpine.NEB.2.21.1904251953470.2488@t1.m.reedmedia.net>
Message-ID: <CANCZdfrORPmdpihtK-3Y47uG=X6L9b0Z-=5wmuaC2KkcN43snQ@mail.gmail.com>

On Thu, Apr 25, 2019, 6:56 PM <reed at reedmedia.net> wrote:

> I never heard about any history/anniversary track at Usenix in summer in
> Renton, Washington. It will be an unofficial side event if anything. I
> have no details.
>
> I heard about the two Vintage Computer Festival events but probably too
> soon for me.
>
> Does anyone know of any other events with a focus on the Unix
> anniversary?
>

I have a talk on the 40th anniversary of V7 at EuroBSDCon in October.

Warner

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

From ality at pbrane.org  Sun Apr 28 00:16:55 2019
From: ality at pbrane.org (Anthony Martin)
Date: Sat, 27 Apr 2019 07:16:55 -0700
Subject: [TUHS] A question about ls(1)
Message-ID: <20190427141655.GA8310@alice>

>From at least V2 to V6, the ls(1) command would not
show directory entries whose names began with a '.'
unless the -a flag was supplied.

This was changed in V7: only the directory entries
for "." and ".." would be skipped by default.

All further versions of Research Unix retain the
convention of V7 and Plan 9 ultimately made it
unnecessary. However, BSD and its descendants did
not follow suit. Instead, they continued behaving
like V6 with an additional -A flag to emulate V7.

Was the initial behavior intentional or just a
matter of expediency?

Who made the change and what was their motivation?
Was it a reaction to the intentional hiding of what
came to be known as "dot files"?

Thanks,
  Anthony

From imp at bsdimp.com  Sun Apr 28 01:38:27 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 27 Apr 2019 09:38:27 -0600
Subject: [TUHS] A question about ls(1)
In-Reply-To: <20190427141655.GA8310@alice>
References: <20190427141655.GA8310@alice>
Message-ID: <CANCZdfoftxQ47J7yu--Pqdgiatxz22axn=3Pq=8G30UQBAfpig@mail.gmail.com>

On Sat, Apr 27, 2019 at 8:26 AM Anthony Martin <ality at pbrane.org> wrote:

> From at least V2 to V6, the ls(1) command would not
> show directory entries whose names began with a '.'
> unless the -a flag was supplied.
>
> This was changed in V7: only the directory entries
> for "." and ".." would be skipped by default.
>

gnu ls does not follow this convention. The system V sources one can find
on the internet have the curious code:

#define DOTSUP  1
...
                        if (aflg==0 && dentry->d_name[0]=='.'
# ifndef DOTSUP
                                && (dentry->d_name[1]=='\0' ||
dentry->d_name[1]=='.'
                                && dentry->d_name[2]=='\0')
# endif
                                )  /* check for directory items '.', '..',
                                   *  and items without valid inode-number;
                                   */
                                continue;

which is the V7 behavior ifdef'd out.


> All further versions of Research Unix retain the
> convention of V7 and Plan 9 ultimately made it
> unnecessary. However, BSD and its descendants did
> not follow suit. Instead, they continued behaving
> like V6 with an additional -A flag to emulate V7.
>

This has been the BSD convention since at least 4BSD :)

But I find this interesting, since the 8th edition was based on BSD 4.1c I
thought....

And system III and later all have the above code.


> Was the initial behavior intentional or just a
> matter of expediency?
>
> Who made the change and what was their motivation?
> Was it a reaction to the intentional hiding of what
> came to be known as "dot files"?


It looks like, from the source, to be a blip in V7.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190427/5c17ffac/attachment.html>

From lm at mcvoy.com  Sun Apr 28 01:42:26 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 27 Apr 2019 08:42:26 -0700
Subject: [TUHS] A question about ls(1)
In-Reply-To: <CANCZdfoftxQ47J7yu--Pqdgiatxz22axn=3Pq=8G30UQBAfpig@mail.gmail.com>
References: <20190427141655.GA8310@alice>
 <CANCZdfoftxQ47J7yu--Pqdgiatxz22axn=3Pq=8G30UQBAfpig@mail.gmail.com>
Message-ID: <20190427154226.GH18639@mcvoy.com>

On Sat, Apr 27, 2019 at 09:38:27AM -0600, Warner Losh wrote:
> But I find this interesting, since the 8th edition was based on BSD 4.1c I
> thought....

Is that true?  I sort of lost track of V8 and V9, other than Dennis'
streams (not STREAMS) work.

From norman at oclsc.org  Sun Apr 28 06:11:21 2019
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 27 Apr 2019 16:11:21 -0400 (EDT)
Subject: [TUHS] A question about ls(1)
Message-ID: <20190427201121.899434422F@lignose.oclsc.org>

On Sat, Apr 27, 2019 at 09:38:27AM -0600, Warner Losh wrote:
  But I find this interesting, since the 8th edition was based on BSD 4.1c I
  thought....

`Based on' is an overstatement, except in the kernel.

The system described in the 8th Edition manual (as noted in the
past, there was only sort of a real V8 release) had a kernel
that started as 4.1x BSD.  I'm not sure of the value of x.
It had the Joy/Babaolgu paging code and the complicated changes
to signals, and a lot of the gratuitous asms, but not a trace
of the BSD networking API.  Neither was the BSD FFS present.

Local additions included Dennis's original stream implementation,
which completely replaced the old tty code and rewrote the drivers
for serial-port devices.  The tty driver (responsible for cooked
mode, interrupt and quit signals, and the like) was a stream
module.  The BSD-style `new tty line discipline' was a separate
module, for the few people who couldn't live without csh.

Tom Killian's original version of /proc and Peter Weinberger's original
network file system (neta) client were there.  These were accessed
through a file system switch, also Peter's work.

Instead of FFS, Peter made a simple speedup to the V7 file system:
adding 64 to the minor device number meant the file system used 4KiB
blocks.  The unused space at the end of the now-4KiB superblock was a
bitmap of free blocks, allowing somewhat-smarter block allocation.

There was a hacky implementation of TCP/IP which we didn't really use:
4.Y BSD (I don't know the value of Y) protocol code, wrapped up to
work as stream modules* and shoehorned in, with a custom API quite
different from the BSD one.  The work was done by a summer student,
Robert T. Morris, who later became rather famous for a smaller but
rather more troublesome bit of network code.  Our production network
was Datakit, which was also implemented as stream devices and modules
(it was the network whose use inspired the stream design, in fact).

[* Quite a while ago, someone asked how multiplexing was handled
in the stream world.  I meant to write a reply but never did.  In
a sentence, by a paired device driver and stream module.  If someone
wants more details I'll be glad to write more about that.]

That's just the kernel, though.  The user-mode world was largely
descended from V7 rather than from BSD.  Most people used sh, which
had been augmented a bit by Rob Pike (perhaps et al) to add functions
and a simple external history mechanism (Tom Duff's idea, I think).
wc had no uucp-dependent flags, and cat had no flags at all.  ls did
sniff at whether standard output was a tty and put things in columns.

Things mutated further as time went on, further diverging from and
discarding aspects of the BSD origin.  (I can take credit or blame
for a lot of that, though not all.)  But that happened later, and
is reflected in the 9th and especially 10th editions of the manual.

Norman Wilson
Toronto ON

From jnc at mercury.lcs.mit.edu  Sun Apr 28 09:03:42 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 27 Apr 2019 19:03:42 -0400 (EDT)
Subject: [TUHS] A question about ls(1)
Message-ID: <20190427230342.D983418C073@mercury.lcs.mit.edu>

    > From: Norman Wilson

    > Quite a while ago, someone asked how multiplexing was handled in the
    > stream world.  I meant to write a reply but never did.  In a sentence,
    > by a paired device driver and stream module.  If someone wants more
    > details I'll be glad to write more about that.

Please. Thanks!

	Noel

From pnr at planet.nl  Sun Apr 28 17:15:03 2019
From: pnr at planet.nl (Paul Ruizendaal)
Date: Sun, 28 Apr 2019 08:15:03 +0100
Subject: [TUHS] v8 networking and streams (was: a question about ls)
Message-ID: <64CF029E-7C1F-4DA0-A3B8-5FD4D6B12B6E@planet.nl>

> There was a hacky implementation of TCP/IP which we didn't really use:
> 4.Y BSD (I don't know the value of Y) protocol code, wrapped up to
> work as stream modules* and shoehorned in, with a custom API quite
> different from the BSD one.  The work was done by a summer student,
> Robert T. Morris, who later became rather famous for a smaller but
> rather more troublesome bit of network code.  Our production network
> was Datakit, which was also implemented as stream devices and modules
> (it was the network whose use inspired the stream design, in fact).

I’d love to hear more about that. So far, the only information I have found about (lowercase) streams and networking - as used at the labs - is the v8 source code and a 1984 message from dmr on a mailing list. The (lower level) v8 networking concepts appear to carry through to v10 and Plan9.

It is my impression that the unix/datakit tradition essentially views a network connection as a special kind of device, whereas the unix/arpanet tradition essentially views a network connection as a special kind of pipe. In both cases this would seem to have been an accidental choice driven by convenience in early implementations (respectively the Spider network drivers and NCP Unix from the UoI).

However, that is an impression formed 35+ years after the fact and the contemporary view may have been very different.

Paul


From arnold at skeeve.com  Sun Apr 28 18:45:07 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 28 Apr 2019 02:45:07 -0600
Subject: [TUHS] OT: Need help getting old 9 track tapes read
Message-ID: <201904280845.x3S8j7GQ008565@freefriends.org>

Hi All.

Scott Lee, who worked with me on the Georgia Tech Software Tools
Subystem for Pr1me Computers, recently unearthed two tapes with
some version of that software.  These may be the only copies
extant anywhere.

He says:

| I was cleaning out the basement of my house. They're 35 years old, but 
| they've never been left in the heat or anything. I opened one of them 
| up and checked the tape and it's not self-sticky or anything. The odds 
| that they're readable is slim, because old 9-track bits tended to bleed 
| through each other. You were supposed to spin through the tape every 
| couple of years to make them last longer. That's obviously not happened.

There was discussion here a while back about services that will
recover such tapes and so on. But I didn't save any of that information.

If you have information, PLEASE send it to me so that I can relay it
to Scott.

Dennis Boone & Bill Gunshannon (are you on this list?) - I may ask you
to contribute $$ towards this once I know more.

Thanks!

Arnold

From bakul at bitblocks.com  Sun Apr 28 19:07:15 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 28 Apr 2019 02:07:15 -0700
Subject: [TUHS] OT: Need help getting old 9 track tapes read
In-Reply-To: Your message of "Sun, 28 Apr 2019 02:45:07 -0600."
 <201904280845.x3S8j7GQ008565@freefriends.org>
References: <201904280845.x3S8j7GQ008565@freefriends.org>
Message-ID: <20190428090722.E63EF156E40C@mail.bitblocks.com>

On Sun, 28 Apr 2019 02:45:07 -0600 arnold at skeeve.com wrote:
>
> There was discussion here a while back about services that will
> recover such tapes and so on. But I didn't save any of that information.

http://www.comco-inc.com/media-conversion-services-by-comco-p29851.html

From drb at msu.edu  Sun Apr 28 21:12:01 2019
From: drb at msu.edu (Dennis Boone)
Date: Sun, 28 Apr 2019 07:12:01 -0400
Subject: [TUHS] OT: Need help getting old 9 track tapes read
In-Reply-To: (Your message of Sun, 28 Apr 2019 02:45:07 -0600.)
 <201904280845.x3S8j7GQ008565@freefriends.org>
References: <201904280845.x3S8j7GQ008565@freefriends.org> 
Message-ID: <20190428111202.17AEA1C2FC7@yagi.h-net.msu.edu>

 > Scott Lee, who worked with me on the Georgia Tech Software Tools
 > Subystem for Pr1me Computers, recently unearthed two tapes with some
 > version of that software.  These may be the only copies extant
 > anywhere.

!!!

 > | I was cleaning out the basement of my house. They're 35 years old,
 > | but they've never been left in the heat or anything. I opened one
 > | of them up and checked the tape and it's not self-sticky or
 > | anything. The odds that they're readable is slim, because old
 > | 9-track bits tended to bleed through each other. You were supposed
 > | to spin through the tape every couple of years to make them last
 > | longer. That's obviously not happened.

I've read stuff that old that was stored in worse conditions.  9-track
is surprisingly robust.  Humidity can be worse on the 80s-era media,
aggravating the "sticky shed" problem.  There are several methods for
dealing with that, including low temp baking, chemical treatments,
stripping coating off the back side of the tape, etc.  I use a low-tech
baking solution at home.  Most methods give you a limited number of
reads over a fairly short time period.

 > Dennis Boone & Bill Gunshannon (are you on this list?) - I may ask
 > you to contribute $$ towards this once I know more.

Let me know.

De

From crossd at gmail.com  Sun Apr 28 21:47:35 2019
From: crossd at gmail.com (Dan Cross)
Date: Sun, 28 Apr 2019 07:47:35 -0400
Subject: [TUHS] A question about ls(1)
In-Reply-To: <20190427141655.GA8310@alice>
References: <20190427141655.GA8310@alice>
Message-ID: <CAEoi9W7z+ZvVpBPignn3sU_CFBNwTDgt=SPe_4itjxDdBg2hWw@mail.gmail.com>

On Sat, Apr 27, 2019 at 10:26 AM Anthony Martin <ality at pbrane.org> wrote:

> From at least V2 to V6, the ls(1) command would not
> show directory entries whose names began with a '.'
> unless the -a flag was supplied.
>
> This was changed in V7: only the directory entries
> for "." and ".." would be skipped by default.
>
> All further versions of Research Unix retain the
> convention of V7 and Plan 9 ultimately made it
> unnecessary. However, BSD and its descendants did
> not follow suit. Instead, they continued behaving
> like V6 with an additional -A flag to emulate V7.
>
> Was the initial behavior intentional or just a
> matter of expediency?
>

I believe it's been publicly stated that it was a mistake in early Unix.
Apparently, Rob Pike had a Google+ post to this effect back in 2012 (or
earlier): I see a reference to it from another mailing list around that
time. Unfortunately, the Google+ content is now lost. Rob, do you have a
copy?

Who made the change and what was their motivation?
> Was it a reaction to the intentional hiding of what
> came to be known as "dot files"?


Speaking from memory, I think the intent was to avoid showing '.' and '..',
and that a programming error accidentally hid all dotfiles; probably this
went unnoticed because there just weren't many of them at the time. This
was corrected in 7th Edition, but the existing behavior had already escaped
into the world via Berkeley.

I suspect the "dot file" convention came later, as a side-effect of
observed behavior of ls.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190428/7a6ba488/attachment.html>

From arnold at skeeve.com  Sun Apr 28 22:00:03 2019
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 28 Apr 2019 06:00:03 -0600
Subject: [TUHS] A question about ls(1)
In-Reply-To: <CAEoi9W7z+ZvVpBPignn3sU_CFBNwTDgt=SPe_4itjxDdBg2hWw@mail.gmail.com>
References: <20190427141655.GA8310@alice>
 <CAEoi9W7z+ZvVpBPignn3sU_CFBNwTDgt=SPe_4itjxDdBg2hWw@mail.gmail.com>
Message-ID: <201904281200.x3SC03Oa014615@freefriends.org>

Dan Cross <crossd at gmail.com> wrote:

> I suspect the "dot file" convention came later, as a side-effect of
> observed behavior of ls.

At some point the shell started colluding; echo *  didn't show
dot files either... That dates back at least as far as V7 also.

Arnold

From lists at irreal.org  Mon Apr 29 00:44:00 2019
From: lists at irreal.org (jcs)
Date: Sun, 28 Apr 2019 10:44:00 -0400
Subject: [TUHS] A question about ls(1)
In-Reply-To: <CAEoi9W7z+ZvVpBPignn3sU_CFBNwTDgt=SPe_4itjxDdBg2hWw@mail.gmail.com>
References: <20190427141655.GA8310@alice>
 <CAEoi9W7z+ZvVpBPignn3sU_CFBNwTDgt=SPe_4itjxDdBg2hWw@mail.gmail.com>
Message-ID: <m2y33uw5ov.fsf@irreal.org>


Dan Cross <crossd at gmail.com> writes:

> On Sat, Apr 27, 2019 at 10:26 AM Anthony Martin 
> <ality at pbrane.org> wrote:
>
>> From at least V2 to V6, the ls(1) command would not
>> show directory entries whose names began with a '.'
>> unless the -a flag was supplied.

[snip]

>> Was the initial behavior intentional or just a
>> matter of expediency?
>>
>
> I believe it's been publicly stated that it was a mistake in 
> early Unix.
> Apparently, Rob Pike had a Google+ post to this effect back in 
> 2012 (or
> earlier): I see a reference to it from another mailing list 
> around that
> time. Unfortunately, the Google+ content is now lost. Rob, do 
> you have a
> copy?

Here's a tweet that shows the post: 
https://twitter.com/rauchg/status/698689290667053060/photo/1?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E698689290667053060

From bakul at bitblocks.com  Mon Apr 29 02:15:16 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 28 Apr 2019 09:15:16 -0700
Subject: [TUHS] A question about ls(1)
In-Reply-To: <CAEoi9W7z+ZvVpBPignn3sU_CFBNwTDgt=SPe_4itjxDdBg2hWw@mail.gmail.com>
References: <20190427141655.GA8310@alice>
 <CAEoi9W7z+ZvVpBPignn3sU_CFBNwTDgt=SPe_4itjxDdBg2hWw@mail.gmail.com>
Message-ID: <5B95265E-B86B-4957-8C49-7448180A0F97@bitblocks.com>

On Apr 28, 2019, at 4:47 AM, Dan Cross <crossd at gmail.com> wrote:
> 
> I suspect the "dot file" convention came later, as a side-effect of observed behavior of ls.

This could’ve been avoided if there was a convention about
where to store per user per app settings & possibly state. On
one of my Unix machines I have over 200 dotfiles. 

From norman at oclsc.org  Mon Apr 29 02:54:52 2019
From: norman at oclsc.org (Norman Wilson)
Date: Sun, 28 Apr 2019 12:54:52 -0400 (EDT)
Subject: [TUHS] A question about ls(1)
Message-ID: <20190428165452.9BB414422F@lignose.oclsc.org>

Bakul Shah:

  This could've been avoided if there was a convention about
  where to store per user per app settings & possibly state. On
  one of my Unix machines I have over 200 dotfiles.

====

Some, I think including Ken and Dennis, might have argued
that real UNIX programs aren't complex enough to need
lots of configuration files.

Agree with it or not, that likely explains why the Research
stream never supplied a better convention about where to
store such files.  I do remember some general debate in the
community (e.g. on netnews) about the matter back in the
early 1980s.  One suggestion I recall was to move all the
files to subdirectory `$HOME/...'.  Personally I think
$HOME/conf would have been better (though I lean toward
the view that very few programs should need such files
anyway).

But by then BSD had spread the convention of leaving
`hidden' files in $HOME had spread too far to call
back.  It wouldn't surprise me if some at Berkeley
would rather have moved to a cleaner convention, just
as the silly uucp-baud-rate flags were removed from
wc, but the cat was already out of the bag and too
hard to stuff back in.

On the Ubuntu Linux systems I help run these days, there
is a directory $HOME/.config.  The tree within has 192
directories and 187 regular files.  I have no idea what
all those files are for, but from the names, most are
from programs I may have run once years ago to test
something, or from programs I run occasionally but
have no context I care about saving.  The whole tree
occupies almost six megabytes, which seems small
by current standards, but (as those on this list
certainly know) in the early 1980s it was possible
to run a complete multi-user UNIX system comfortably
from a single 2.5MB RK05 disk.

Norman Wilson
Toronto ON

From nobozo at gmail.com  Mon Apr 29 05:45:07 2019
From: nobozo at gmail.com (Jon Forrest)
Date: Sun, 28 Apr 2019 12:45:07 -0700
Subject: [TUHS] A question about ls(1)
In-Reply-To: <20190428165452.9BB414422F@lignose.oclsc.org>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
Message-ID: <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>



On 4/28/2019 9:54 AM, Norman Wilson wrote:
> Bakul Shah:
> 
>    This could've been avoided if there was a convention about
>    where to store per user per app settings & possibly state. On
>    one of my Unix machines I have over 200 dotfiles.

One of the things I think Windows did right was to have one
place where all configuration information is kept. Sure,
you can argue about the implementation details, but Windows
doesn't have configuration files all over the place.

Jon


From bakul at bitblocks.com  Mon Apr 29 06:00:27 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 28 Apr 2019 13:00:27 -0700
Subject: [TUHS] A question about ls(1)
In-Reply-To: <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
Message-ID: <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>


On Apr 28, 2019, at 12:45 PM, Jon Forrest <nobozo at gmail.com> wrote:
> 
> On 4/28/2019 9:54 AM, Norman Wilson wrote:
>> Bakul Shah:
>>   This could've been avoided if there was a convention about
>>   where to store per user per app settings & possibly state. On
>>   one of my Unix machines I have over 200 dotfiles.
> 
> One of the things I think Windows did right was to have one
> place where all configuration information is kept. Sure,
> you can argue about the implementation details, but Windows
> doesn't have configuration files all over the place.

<Rant due to Windows PTSD elided>

IMHO separate files are fine but it would've been nice to
a) have a place other than $HOME to store these files and
b) a standardized plain text format

May still be worth doing.


From thomas.paulsen at firemail.de  Mon Apr 29 08:16:29 2019
From: thomas.paulsen at firemail.de (Thoma Paulsen)
Date: Mon, 29 Apr 2019 00:16:29 +0200
Subject: [TUHS] A question about ls(1)
In-Reply-To: <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
Message-ID: <9ba54618abe5976097f2733ed3eef254@firemail.de>

Von: Jon Forrest <nobozo at gmail.com>

> One of the things I think Windows did right was to have one
> place where all configuration information is kept. Sure,
> you can argue about the implementation details, but Windows
> doesn't have configuration files all over the place.
>
in theories - yes, in real there are a lot of configuration files all over the place.



From jnc at mercury.lcs.mit.edu  Mon Apr 29 09:44:45 2019
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 28 Apr 2019 19:44:45 -0400 (EDT)
Subject: [TUHS] OT: Need help getting old 9 track tapes read
Message-ID: <20190428234445.0B00218C073@mercury.lcs.mit.edu>

    > From: Arnold Skeeve

    > If you have information, PLEASE send it to me so that I can relay it
    > to Scott.

IMO, only one choice: Chuck Guzis (cclist at sydex.com); he's very active in the
vintage computer community, and reads old media professionally.

I've used him (to recover those backup tapes of the MIT PWB1 system), which
was rather tricky (bad mold; he had to build a special tool to remove it), and
I was incredibly happy. Very reasonable price too - although he may have given
me a special 'collector' rate.. :-)

   Noel

From imp at bsdimp.com  Mon Apr 29 09:59:09 2019
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 28 Apr 2019 17:59:09 -0600
Subject: [TUHS] A question about ls(1)
In-Reply-To: <CANCZdfoftxQ47J7yu--Pqdgiatxz22axn=3Pq=8G30UQBAfpig@mail.gmail.com>
References: <20190427141655.GA8310@alice>
 <CANCZdfoftxQ47J7yu--Pqdgiatxz22axn=3Pq=8G30UQBAfpig@mail.gmail.com>
Message-ID: <CANCZdfq43-MaVcNDjjQgEUGdv1Vr8=iBzZMRzRQhLE5x98=wtg@mail.gmail.com>

On Sat, Apr 27, 2019 at 9:38 AM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sat, Apr 27, 2019 at 8:26 AM Anthony Martin <ality at pbrane.org> wrote:
>
>> From at least V2 to V6, the ls(1) command would not
>> show directory entries whose names began with a '.'
>> unless the -a flag was supplied.
>>
>> This was changed in V7: only the directory entries
>> for "." and ".." would be skipped by default.
>>
>
> gnu ls does not follow this convention. The system V sources one can find
> on the internet have the curious code:
>
> #define DOTSUP  1
> ...
>                         if (aflg==0 && dentry->d_name[0]=='.'
> # ifndef DOTSUP
>                                 && (dentry->d_name[1]=='\0' ||
> dentry->d_name[1]=='.'
>                                 && dentry->d_name[2]=='\0')
> # endif
>                                 )  /* check for directory items '.', '..',
>                                    *  and items without valid inode-number;
>                                    */
>                                 continue;
>
> which is the V7 behavior ifdef'd out.
>

I've confirmed that all the ls.c's that I have from AT&T, apart from
research, do the . is a hidden file thing in ls. All the research things
inherit the V7 behavior (though the V8 sources I found have an
off-by-default ifdef for the BSD behavior). All descendants of SysV that I
could find source to have the V6 behavior, not V7. Both system III and all
revs of System V I could find have an #ifdef for this, and a 1 line change
restore the V7 behavior. Illumos has the BSD semantics and has lost even
the ifdef.

As pointed out later in the thread I was incorrect about 'base on 4.1BSD. I
took a closer look at the sources we have. The kernel has various bits of
BSD included in it starting in V8, but as noted the networking bits seem
odd to my eye. I didn't do a detailed analysis beyond spot checking a few
files. The userland looks more like evolved V7 code with some BSDism
imported rather than a wholesale switch to the BSD versions.

I like the dot is hidden thing. It's simple, elegant, and transports to
other systems well, so long as they are unix or have filesystems that don't
get hung up on 'extension'. That latter bit is likely why many find it...
distasteful.

Warner

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

From jpl.jpl at gmail.com  Mon Apr 29 10:53:05 2019
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Sun, 28 Apr 2019 20:53:05 -0400
Subject: [TUHS] A question about ls(1)
In-Reply-To: <9ba54618abe5976097f2733ed3eef254@firemail.de>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
 <9ba54618abe5976097f2733ed3eef254@firemail.de>
Message-ID: <CAC0cEp9Ug-R4TAKcQPNcjowAu5Oc+jDnvfHC8XFWMoizdWZLcg@mail.gmail.com>

I have a deep-seated distrust of global stuff. In C, obviously. But also
for things like git configs, which may differ substantially for different
directories (one for each project). I cannot imagine trying to control such
things in a single place. Seems intensely ugly.


On Sun, Apr 28, 2019 at 6:47 PM Thoma Paulsen <thomas.paulsen at firemail.de>
wrote:

> Von: Jon Forrest <nobozo at gmail.com>
>
> > One of the things I think Windows did right was to have one
> > place where all configuration information is kept. Sure,
> > you can argue about the implementation details, but Windows
> > doesn't have configuration files all over the place.
> >
> in theories - yes, in real there are a lot of configuration files all over
> the place.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190428/bee6231c/attachment.html>

From imp at bsdimp.com  Mon Apr 29 23:49:19 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 29 Apr 2019 07:49:19 -0600
Subject: [TUHS] MASSCOMP MC-500 Guide to Writing a Unix Device Driver
Message-ID: <CANCZdfo1FMorKD_X31vEz45zsa9PSzhLd0kwtKnyW7pK1P3wCQ@mail.gmail.com>

Greetings,

I'm trying to find the predecessor to "Writing a UNIX Device Driver, J.
Egan & T. Teixeira, 1st ed, 1988". In the preface, it says:

"This book is based on a MASSCOMP manual, Guide to Writing a Unix Device
Driver.  The first version that MASSCOMP published as part of the
documentation set for the MC-500 was based on preliminary drafts prepared
for MASSCOMP  by Cliff Cary and Tom Albough of Creare R&D."

I checked bit keepers and found nothing.

I was wondering if people on this list know of this manual, have a copy,
etc. In general, I'm looking for pre-SysV driver manuals. I can find all
kinds of SysV driver books (some of which cover 4.2BSD or 4.3BSD as well),
but nothing for System III or V7 unix. There were a lot of early systems
that were based on ports of V7 to different architectures that were then
updated to System III or System V (at least according to the big chart of
unix history and some wikipedia entries, which may be just repeating
marketing schlock and not reflect actual reality).

As part of a talk I'm putting together on the 40th anniversary of V7, I
wanted to have a bit of history for things we still have in unix today
(like strategy) and things that successors to unix have added or left
behind (like the packet mux in V7 that was tossed aside for either STREAMS
or netinet from BSD, though packet muxing to userland is back with DPDK).

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

From norman at oclsc.org  Tue Apr 30 00:38:57 2019
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 29 Apr 2019 10:38:57 -0400
Subject: [TUHS] MASSCOMP MC-500 Guide to Writing a Unix Device Driver
Message-ID: <1556548741.10439.for-standards-violators@oclsc.org>

Dennis's `The UNIX I/O System' paper in Volume 2 of the 7/e
manual is basically about how drivers work.  Is that near
enough, possibly as augmented by Ken's `UNIX Implementation'
paper in the same book?

Those were my own starting point, long ago, for understanding
how to write device drivers.  Along with existing source code
as examples, of course, but (unlikely many who hack on device
drivers, I'm afraid) I have always preferred to have a proper
statement of rules, conventions, and interfaces rather than
just reading code and guessing.

Norman Wilson
Toronto ON

From clemc at ccc.com  Tue Apr 30 00:45:50 2019
From: clemc at ccc.com (Clem Cole)
Date: Mon, 29 Apr 2019 10:45:50 -0400
Subject: [TUHS] MASSCOMP MC-500 Guide to Writing a Unix Device Driver
In-Reply-To: <CANCZdfo1FMorKD_X31vEz45zsa9PSzhLd0kwtKnyW7pK1P3wCQ@mail.gmail.com>
References: <CANCZdfo1FMorKD_X31vEz45zsa9PSzhLd0kwtKnyW7pK1P3wCQ@mail.gmail.com>
Message-ID: <CAC20D2NXmwpdjmHabeUav+4UzB0YMjcY0CHALarhAfod=kr7gA@mail.gmail.com>

Warner,

I should have copies of it, I'm also in email contact with both Tom T. (aka
tjt - who is someone I reference often on this list) and Janet (Tom often
weekly).

As for history, until Janet created that document for Masscomp, nothing
existed other than a short paper I believe Dennis wrote for V6 and updated
for V7.   Cliff and Tom A had spent hours in Tom and my shared office
picking our brains.  What they came up with was not quite right (to be
polite) and tjt attempted to fix it - which at least was technically
correct.   Janet has the head of Masscomp's documentation group, re-wrote
Tom's version to make it easier to understand.  I should have the version
in my files [Janet might even have the original troff sources].

When Tim O'Reilly (who had been writing a lot of our doc under contract and
started to do the original 'nutshell' series) cut a deal to take the
documentation he was writing for us 'out of Masscomp' and publish it (thus
creating the original X-Windows documentation and the first real hit for
ORA), precedent had been set.

Shortly after, Tom and I had left for Belmont, ney Stellar, and Janet and
Tom decided to redo it as a book.
ᐧ

On Mon, Apr 29, 2019 at 9:50 AM Warner Losh <imp at bsdimp.com> wrote:

> Greetings,
>
> I'm trying to find the predecessor to "Writing a UNIX Device Driver, J.
> Egan & T. Teixeira, 1st ed, 1988". In the preface, it says:
>
> "This book is based on a MASSCOMP manual, Guide to Writing a Unix Device
> Driver.  The first version that MASSCOMP published as part of the
> documentation set for the MC-500 was based on preliminary drafts prepared
> for MASSCOMP  by Cliff Cary and Tom Albough of Creare R&D."
>
> I checked bit keepers and found nothing.
>
> I was wondering if people on this list know of this manual, have a copy,
> etc. In general, I'm looking for pre-SysV driver manuals. I can find all
> kinds of SysV driver books (some of which cover 4.2BSD or 4.3BSD as well),
> but nothing for System III or V7 unix. There were a lot of early systems
> that were based on ports of V7 to different architectures that were then
> updated to System III or System V (at least according to the big chart of
> unix history and some wikipedia entries, which may be just repeating
> marketing schlock and not reflect actual reality).
>
> As part of a talk I'm putting together on the 40th anniversary of V7, I
> wanted to have a bit of history for things we still have in unix today
> (like strategy) and things that successors to unix have added or left
> behind (like the packet mux in V7 that was tossed aside for either STREAMS
> or netinet from BSD, though packet muxing to userland is back with DPDK).
>
> Warner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190429/e1a09e18/attachment.html>

From lm at mcvoy.com  Tue Apr 30 00:53:45 2019
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 29 Apr 2019 07:53:45 -0700
Subject: [TUHS] MASSCOMP MC-500 Guide to Writing a Unix Device Driver
In-Reply-To: <CAC20D2NXmwpdjmHabeUav+4UzB0YMjcY0CHALarhAfod=kr7gA@mail.gmail.com>
References: <CANCZdfo1FMorKD_X31vEz45zsa9PSzhLd0kwtKnyW7pK1P3wCQ@mail.gmail.com>
 <CAC20D2NXmwpdjmHabeUav+4UzB0YMjcY0CHALarhAfod=kr7gA@mail.gmail.com>
Message-ID: <20190429145345.GO2212@mcvoy.com>

I used to carry around some Masscomp doc, I believe it was about networking.
Masscomp had some great tech writers.

On Mon, Apr 29, 2019 at 10:45:50AM -0400, Clem Cole wrote:
> Warner,
> 
> I should have copies of it, I'm also in email contact with both Tom T. (aka
> tjt - who is someone I reference often on this list) and Janet (Tom often
> weekly).
> 
> As for history, until Janet created that document for Masscomp, nothing
> existed other than a short paper I believe Dennis wrote for V6 and updated
> for V7.   Cliff and Tom A had spent hours in Tom and my shared office
> picking our brains.  What they came up with was not quite right (to be
> polite) and tjt attempted to fix it - which at least was technically
> correct.   Janet has the head of Masscomp's documentation group, re-wrote
> Tom's version to make it easier to understand.  I should have the version
> in my files [Janet might even have the original troff sources].
> 
> When Tim O'Reilly (who had been writing a lot of our doc under contract and
> started to do the original 'nutshell' series) cut a deal to take the
> documentation he was writing for us 'out of Masscomp' and publish it (thus
> creating the original X-Windows documentation and the first real hit for
> ORA), precedent had been set.
> 
> Shortly after, Tom and I had left for Belmont, ney Stellar, and Janet and
> Tom decided to redo it as a book.
> ???
> 
> On Mon, Apr 29, 2019 at 9:50 AM Warner Losh <imp at bsdimp.com> wrote:
> 
> > Greetings,
> >
> > I'm trying to find the predecessor to "Writing a UNIX Device Driver, J.
> > Egan & T. Teixeira, 1st ed, 1988". In the preface, it says:
> >
> > "This book is based on a MASSCOMP manual, Guide to Writing a Unix Device
> > Driver.  The first version that MASSCOMP published as part of the
> > documentation set for the MC-500 was based on preliminary drafts prepared
> > for MASSCOMP  by Cliff Cary and Tom Albough of Creare R&D."
> >
> > I checked bit keepers and found nothing.
> >
> > I was wondering if people on this list know of this manual, have a copy,
> > etc. In general, I'm looking for pre-SysV driver manuals. I can find all
> > kinds of SysV driver books (some of which cover 4.2BSD or 4.3BSD as well),
> > but nothing for System III or V7 unix. There were a lot of early systems
> > that were based on ports of V7 to different architectures that were then
> > updated to System III or System V (at least according to the big chart of
> > unix history and some wikipedia entries, which may be just repeating
> > marketing schlock and not reflect actual reality).
> >
> > As part of a talk I'm putting together on the 40th anniversary of V7, I
> > wanted to have a bit of history for things we still have in unix today
> > (like strategy) and things that successors to unix have added or left
> > behind (like the packet mux in V7 that was tossed aside for either STREAMS
> > or netinet from BSD, though packet muxing to userland is back with DPDK).
> >
> > Warner
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

From imp at bsdimp.com  Tue Apr 30 00:53:50 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 29 Apr 2019 08:53:50 -0600
Subject: [TUHS] MASSCOMP MC-500 Guide to Writing a Unix Device Driver
In-Reply-To: <1556548741.10439.for-standards-violators@oclsc.org>
References: <1556548741.10439.for-standards-violators@oclsc.org>
Message-ID: <CANCZdfo2GhPpsYYEm6Ddu=SN7Y=s5GNFXXQd2CAj1F1TMYNXGA@mail.gmail.com>

On Mon, Apr 29, 2019 at 8:39 AM Norman Wilson <norman at oclsc.org> wrote:

> Dennis's `The UNIX I/O System' paper in Volume 2 of the 7/e
> manual is basically about how drivers work.  Is that near
> enough, possibly as augmented by Ken's `UNIX Implementation'
> paper in the same book?
>

I'm not blessed with paper versions of these, but they are in usr/doc/iosys
and usr/doc/cacm/* respectively.


> Those were my own starting point, long ago, for understanding
> how to write device drivers.  Along with existing source code
> as examples, of course, but (unlikely many who hack on device
> drivers, I'm afraid) I have always preferred to have a proper
> statement of rules, conventions, and interfaces rather than
> just reading code and guessing.
>

Yes. This is exactly what I was looking for, and I'm surprised I hadn't
thought to look here sooner. Thanks!

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190429/7836d157/attachment.html>

From michael at kjorling.se  Tue Apr 30 04:05:12 2019
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Mon, 29 Apr 2019 18:05:12 +0000
Subject: [TUHS] A question about ls(1)
In-Reply-To: <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
 <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>
Message-ID: <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>

On 28 Apr 2019 13:00 -0700, from bakul at bitblocks.com (Bakul Shah):
> IMHO separate files are fine but it would've been nice to
> a) have a place other than $HOME to store these files and

XDG already does that. At least Norman already mentioned ~/.config in
this thread.

https://www.freedesktop.org/wiki/Software/xdg-user-dirs/

Not sure how common that is on non-Linux systems, but it seems pretty
common on modern Linux distributions.

My workstation Debian system has a staggering 3467 files in that
directory, spread around 444 directories (75 directories directly
under ~/.config). Plus another 142 dot-directories and 66 dotfiles in
~/. Now, ~/.config typically uses multiple files per application, and
at a glance there's some stuff there that could definitely go, but I
still shudder to think of having all of those directly under ~/, so
it's clearly doing _some_ good in that regard.

And that's to not even begin to talk about all the stuff you'll find
in /etc on a modern Linux system.

> b) a standardized plain text format

I'm not sure about that; different applications have very different
needs, and trying to shoehorn one into another would be ugly; quite
possibly even more ugly than just having different formats. Imagine
trying to write mail sorting recipies (think procmail) in a file with
the same format as that of one holding word processor settings or an
image metadata store. I guess that's half-way tolerable on Windows
because next to nobody edits the settings directly anyway, but on a
system where many such files are sometimes, or often, edited directly
by the user, it might well hinder more than it helps. I guess you
_could_ go with something like XML or JSON, but that's a bit like
saying "all cars should have an engine and a refillable fuel store",
in that it doesn't actually standardize anything _meaningful_ (in both
of those cases, the magic is in the schema, not the format). Lists of
examples not intended to be exhaustive.

-- 
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 imp at bsdimp.com  Tue Apr 30 06:37:26 2019
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 29 Apr 2019 14:37:26 -0600
Subject: [TUHS] A question about ls(1)
In-Reply-To: <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
 <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>
 <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
Message-ID: <CANCZdfoO4392-fQqgaHm7Ape=dnvww0m5X2h1b7C_jz_rBB0eg@mail.gmail.com>

On Mon, Apr 29, 2019 at 12:14 PM Michael Kjörling <michael at kjorling.se>
wrote:

> On 28 Apr 2019 13:00 -0700, from bakul at bitblocks.com (Bakul Shah):
> > b) a standardized plain text format
>
> I'm not sure about that; different applications have very different
> needs, and trying to shoehorn one into another would be ugly; quite
> possibly even more ugly than just having different formats. Imagine
> trying to write mail sorting recipies (think procmail) in a file with
> the same format as that of one holding word processor settings or an
> image metadata store. I guess that's half-way tolerable on Windows
> because next to nobody edits the settings directly anyway, but on a
> system where many such files are sometimes, or often, edited directly
> by the user, it might well hinder more than it helps. I guess you
> _could_ go with something like XML or JSON, but that's a bit like
> saying "all cars should have an engine and a refillable fuel store",
> in that it doesn't actually standardize anything _meaningful_ (in both
> of those cases, the magic is in the schema, not the format). Lists of
> examples not intended to be exhaustive.
>

The only thing that .profile and .Xdefaults share is a leading '.'. While
the latter could be XML or JSON (almost, neither of those formats has
conditional expressions and .Xdefaults is run through cpp), the former
never could be XML or JSON in any sane universe.

So while some config stuff is stored in the dot files, its nature is
somewhat different.

Also, to use git as an example. my repo has a .git/config in it. For work
repos I put my work email and preferred spelling of my name. those go in
repo/.git/config. But for everything else, I have some global settings in
$HOME/.git/config. There are from time to time other reasons to tweak the
settings of a repo and have it be local to that repo only.

It's a tricky problem...

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

From cbbrowne at gmail.com  Tue Apr 30 06:44:59 2019
From: cbbrowne at gmail.com (Christopher Browne)
Date: Mon, 29 Apr 2019 16:44:59 -0400
Subject: [TUHS] A question about ls(1)
In-Reply-To: <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
 <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>
 <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
Message-ID: <CAFNqd5UPm_U22wYda5HjVQRQiM_85fq5JLR+24Y0NteipQ99Og@mail.gmail.com>

On Mon, 29 Apr 2019 at 14:15, Michael Kjörling <michael at kjorling.se> wrote:

> On 28 Apr 2019 13:00 -0700, from bakul at bitblocks.com (Bakul Shah):
> > IMHO separate files are fine but it would've been nice to
> > a) have a place other than $HOME to store these files and
>
> XDG already does that. At least Norman already mentioned ~/.config in
> this thread.
>
> https://www.freedesktop.org/wiki/Software/xdg-user-dirs/
>
> Not sure how common that is on non-Linux systems, but it seems pretty
> common on modern Linux distributions.
>

That's application-specific, not distribution or OS specific.

I have 58 subdirectories of ~/.config on my workstation at work; that's not
deviating much from your case; 58 directories (indicating about 58 apps),
2047 subdirectories, 7422 files, 481MB of data, the largest bits being
cache data for Google Chrome web browser.


> My workstation Debian system has a staggering 3467 files in that
> directory, spread around 444 directories (75 directories directly
> under ~/.config). Plus another 142 dot-directories and 66 dotfiles in
> ~/. Now, ~/.config typically uses multiple files per application, and
> at a glance there's some stuff there that could definitely go, but I
> still shudder to think of having all of those directly under ~/, so
> it's clearly doing _some_ good in that regard.
>

I have had little reason to worry about this; I tend to concur.


> > b) a standardized plain text format
>
> I'm not sure about that; different applications have very different
> needs, and trying to shoehorn one into another would be ugly; quite
> possibly even more ugly than just having different formats.


Yeah, the time they tried doing that, we got "XML everywhere," and
that wasn't a notable improvement.

What you see on mobile devices these days is that the ".config/" file
is a SQLite database, which is where both configuration and application
data are captured.

As someone that spends a great deal of his time writing SQL code,
I find that not too heinous; others might disagree.  I think having a
SQLite file is better than getting some heinous XML file.
(Especially if the XML file is some thinly disguised serialization of
a hierarchy of COM objects, where modifying element order would be
liable to make your Windows application blow up.)

The "mobile platforms" have gotten quite a lot of milage out of using
SQLite databases (true both on Android and on iOS); there could
be worse things.

The SQLite web site does have a page somewhat proselytizing
this:  https://sqlite.org/appfileformat.html

I heard D Richard Hipp (author of SQLite, now head of the dev team)
explain this at PGCon 5 years ago <
https://www.pgcon.org/2014/schedule/events/736.en.html>

He also contended that the world might be a better place if LibreOffice
documents were captured as SQLite databases rather than being bundles of
XML stored in a .zip archive.  That's a nice lively argument to have.
Actually poke at the slides at PGCon 2014; he makes similar arguments
about git repos (what if metadata were in a database?) and ePub book
files.

If we were going to forcibly shoehorn everything into one thing, I think I'd
rather that than a lot of the alternatives.  But I'm admittedly excessively
comfortable with SQL ;-)

I can live with us having a number of data formats, particularly if
they remain simple.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190429/bf3f71ed/attachment.html>

From bakul at bitblocks.com  Tue Apr 30 08:32:19 2019
From: bakul at bitblocks.com (Bakul Shah)
Date: Mon, 29 Apr 2019 15:32:19 -0700
Subject: [TUHS] A question about ls(1)
In-Reply-To: Your message of "Mon, 29 Apr 2019 18:05:12 -0000."
 <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
 <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>
 <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
Message-ID: <20190429223226.303F9156E40C@mail.bitblocks.com>

On Mon, 29 Apr 2019 18:05:12 -0000 Michael =?utf-8?B?S2rDtnJsaW5n?= <michael at kjorling.se> wrote:
Michael Kj?rling writes:
> On 28 Apr 2019 13:00 -0700, from bakul at bitblocks.com (Bakul Shah):
> > IMHO separate files are fine but it would've been nice to
> > a) have a place other than $HOME to store these files and
>
> XDG already does that. At least Norman already mentioned ~/.config in
> this thread.
>
> https://www.freedesktop.org/wiki/Software/xdg-user-dirs/
>
> Not sure how common that is on non-Linux systems, but it seems pretty
> common on modern Linux distributions.

I meant to suggest that a unix wide convention, with an API to
access config data from programs, may still be of some use.
This should contain user specific configuration in a few lines.

mh for example has a single per user config file: .mh_profile.
It allows you to specify your local maildir's path (defaulting
to ~/Mail). All mail messages and additional state/data is then
stored under ~/Mail or its subdirectories.

So something like "path: foo" can be used store application
specific stuff that doesn't fit in the minimal config model.
The goal would be to cover the majority of programs and
provide some guidelines for more complex applications.

> My workstation Debian system has a staggering 3467 files in that
> directory, spread around 444 directories (75 directories directly
> under ~/.config). Plus another 142 dot-directories and 66 dotfiles in
> ~/. Now, ~/.config typically uses multiple files per application, and
> at a glance there's some stuff there that could definitely go, but I
> still shudder to think of having all of those directly under ~/, so
> it's clearly doing _some_ good in that regard.

I suspect most of these files contain some state and cached
application data or content as opposed to configuration.  Try
the following from your home dir:

du -a .??*|cat -n|grep -v / |\
awk 'BEGIN{x=1;} {print $1-x, $3; x=$1;}'|sort -nr|head

This prints out top 10 of total files/dirs under each
top-level dot directory. You can try similar from .config. For
me, most in the top 10 are programs I haven't used in years!

>
> And that's to not even begin to talk about all the stuff you'll find
> in /etc on a modern Linux system.
>
> > b) a standardized plain text format
>
> I'm not sure about that; different applications have very different
> needs, and trying to shoehorn one into another would be ugly; quite
> possibly even more ugly than just having different formats.

Not shoehorn in everything but support a core set. 

> trying to write mail sorting recipies (think procmail) in a file with
> the same format as that of one holding word processor settings or an
> image metadata store.

By "one place" I meant something like a ~/etc or ~/rc or
~/config directory but not a single file. A separate config
file for each program (and library) that needs it.

Ideally I'd separate config, state, content and cache. I find
<program>/{config,state,<content>,cache} to be more modular
than {config,state,<content>,cache}/<program> -- what Apple
forces on Macs. Ex: ~/Library/Preferences/org.tug.TexWorks.plist

From a.phillip.garcia at gmail.com  Tue Apr 30 11:37:37 2019
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Mon, 29 Apr 2019 21:37:37 -0400
Subject: [TUHS] Running sparc Solaris with qemu
Message-ID: <CAFCBnZsN5VSRR0+hN+KOKwfPDBmbiogmMhPgMFuvqCNfttgj4Q@mail.gmail.com>

https://blog.adafruit.com/2019/04/29/new-guide-build-your-own-sparc-workstation-with-qemu-and-solaris-solaris-opensource-adafruitlearningsystem-adafruit-adafruit/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20190429/354069a5/attachment.html>

From michael at kjorling.se  Tue Apr 30 16:44:08 2019
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Tue, 30 Apr 2019 06:44:08 +0000
Subject: [TUHS] A question about ls(1)
In-Reply-To: <CAFNqd5UPm_U22wYda5HjVQRQiM_85fq5JLR+24Y0NteipQ99Og@mail.gmail.com>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
 <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>
 <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
 <CAFNqd5UPm_U22wYda5HjVQRQiM_85fq5JLR+24Y0NteipQ99Og@mail.gmail.com>
Message-ID: <20190430064408.ry56lmufdgq7uaut@h-174-65.A328.priv.bahnhof.se>

On 29 Apr 2019 16:44 -0400, from cbbrowne at gmail.com (Christopher Browne):
> He also contended that the world might be a better place if LibreOffice
> documents were captured as SQLite databases rather than being bundles of
> XML stored in a .zip archive.  That's a nice lively argument to have.
> Actually poke at the slides at PGCon 2014; he makes similar arguments
> about git repos (what if metadata were in a database?) and ePub book
> files.

At least OpenDocument is an ISO standard; and while it looks at a
glance like the Zip file format and compression themselves aren't
specified in it (at eight pages, there isn't a lot of room for
detailed technical descriptions), ISO/IEC 21320-1:2015 "normatively
references the Zip File Format Specification version 6.3.3 of PKWARE®
Inc", stating that "[d]ocument container files are conforming Zip
files as specified by that document". (Quoted from the summary page.)

https://www.iso.org/standard/60101.html

https://standards.iso.org/ittf/PubliclyAvailableStandards/c060101_ISO_IEC_21320-1_2015.zip

I could be wrong, but I don't _think_ that SQLite has reached quite
that level of adoption.

Also, relational databases have their advantages (I work with them
myself), but lots of office-type documents (word processing documents,
spreadsheets, presentations, etc.) inherently have a somewhat
hierarchical or run-on data structure, lending themselves well to a
hierarchical format. Whether we like it or not, XML also has the
advantage of being a well-established standard for data serialization,
and _with a schema_, can be readily validated.

And if you don't like the outer Zip file container, at least
OpenDocument also allows for single flat XML files. (Typical file name
extension .fo[dt][gpst], as opposed to .o[dt][gpst] for the Zip
container counterpart.) I'm pretty sure LibreOffice can be set up to
save as such files even by default, if that's your cup of tea. Those
get awfully big the moment you start including any non-trivial
content, though.

-- 
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 khm at sciops.net  Tue Apr 30 17:24:49 2019
From: khm at sciops.net (Kurt H Maier)
Date: Tue, 30 Apr 2019 00:24:49 -0700
Subject: [TUHS] A question about ls(1)
In-Reply-To: <20190430064408.ry56lmufdgq7uaut@h-174-65.A328.priv.bahnhof.se>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
 <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>
 <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
 <CAFNqd5UPm_U22wYda5HjVQRQiM_85fq5JLR+24Y0NteipQ99Og@mail.gmail.com>
 <20190430064408.ry56lmufdgq7uaut@h-174-65.A328.priv.bahnhof.se>
Message-ID: <20190430072449.GA79218@wopr>

On Tue, Apr 30, 2019 at 06:44:08AM +0000, Michael Kjörling wrote:
>
> At least OpenDocument is an ISO standard; 
        
So is "Office Open XML"; a sufficiently large campaign fund is 
indistinguishable from a standards committee.
        
> I could be wrong, but I don't _think_ that SQLite has reached quite
> that level of adoption.
          
Every Android device, iPhone/iPad, Chrome or Firefox installation, 
Windows 10 computer or Red Hat Enterprise Linux installation uses 
SQLite.  Also, the Library of Congress considers it as good as XML as a 
storage format.  It is fairly certain that SQLite is wider-adopted than
OpenDocument -- or at least wider-deployed.
          
I'd argue that SQLite files and XML documents both suffer from the same
problem, in that (during normal use) you have to load the whole thing in
order to use it effectively.  In other words, they don't play well with
pipes.
          
But for a document format, maybe the Unix Nature is less of a concern.
          
khm

From wobblygong at gmail.com  Tue Apr 30 20:35:27 2019
From: wobblygong at gmail.com (Wesley Parish)
Date: Tue, 30 Apr 2019 22:35:27 +1200
Subject: [TUHS] A question about ls(1)
In-Reply-To: <20190430072449.GA79218@wopr>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
 <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>
 <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
 <CAFNqd5UPm_U22wYda5HjVQRQiM_85fq5JLR+24Y0NteipQ99Og@mail.gmail.com>
 <20190430064408.ry56lmufdgq7uaut@h-174-65.A328.priv.bahnhof.se>
 <20190430072449.GA79218@wopr>
Message-ID: <CACNPpeaFPf3AgCxa3zLacC1nN=s4uskU2PFBehD27AbzM9iFFQ@mail.gmail.com>

I find it ironical; I put some thought into the problem of making a
very small Office Suite a while ago, and concluded that I could make
the text and spreadsheet and database apps dependent on the database
manager foundation, while making the display apps and the layout apps
(for things such as presentation and desktop publishing) dependent on
a web browser layer.

The native file format for such a miniature office suite would've been
the database file format, with options to export to other file
formats. I couldn't see how I could've escaped XML though for
reduction into various display options. It's big, it's not as precise
as TeX, but it's a lot more widely used.

FWVVLIW ...

Wesley Parish

On 4/30/19, Kurt H Maier <khm at sciops.net> wrote:
> On Tue, Apr 30, 2019 at 06:44:08AM +0000, Michael Kjörling wrote:
>>
>> At least OpenDocument is an ISO standard;
>
> So is "Office Open XML"; a sufficiently large campaign fund is
> indistinguishable from a standards committee.
>
>> I could be wrong, but I don't _think_ that SQLite has reached quite
>> that level of adoption.
>
> Every Android device, iPhone/iPad, Chrome or Firefox installation,
> Windows 10 computer or Red Hat Enterprise Linux installation uses
> SQLite.  Also, the Library of Congress considers it as good as XML as a
> storage format.  It is fairly certain that SQLite is wider-adopted than
> OpenDocument -- or at least wider-deployed.
>
> I'd argue that SQLite files and XML documents both suffer from the same
> problem, in that (during normal use) you have to load the whole thing in
> order to use it effectively.  In other words, they don't play well with
> pipes.
>
> But for a document format, maybe the Unix Nature is less of a concern.
>
> khm
>

From tytso at mit.edu  Tue Apr 30 21:52:31 2019
From: tytso at mit.edu (Theodore Ts'o)
Date: Tue, 30 Apr 2019 07:52:31 -0400
Subject: [TUHS] A question about ls(1)
In-Reply-To: <20190429223226.303F9156E40C@mail.bitblocks.com>
References: <20190428165452.9BB414422F@lignose.oclsc.org>
 <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com>
 <D239CD94-F1BA-47B0-9E16-4F67C09C5CEA@bitblocks.com>
 <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se>
 <20190429223226.303F9156E40C@mail.bitblocks.com>
Message-ID: <20190430115231.GK3789@mit.edu>

On Mon, Apr 29, 2019 at 03:32:19PM -0700, Bakul Shah wrote:
> > My workstation Debian system has a staggering 3467 files in that
> > directory, spread around 444 directories (75 directories directly
> > under ~/.config). Plus another 142 dot-directories and 66 dotfiles in
> > ~/. Now, ~/.config typically uses multiple files per application, and
> > at a glance there's some stuff there that could definitely go, but I
> > still shudder to think of having all of those directly under ~/, so
> > it's clearly doing _some_ good in that regard.
> 
> I suspect most of these files contain some state and cached
> application data or content as opposed to configuration.

Applications which follow the XDG specification (which is what
specified ~/.config are supposed to use ~/.cache for cache files (the
per-user analog of /var/cache) and ~/.local/share for data files (the
per-user analog of /usr/share).  These locations can be overridden by
the environment variables XDG_CACHE_HOME, XDG_DATA_HOME, and
XDG_CONFIG_HOME to override ~/.config.

While I would never under-estimate the ability for application writers
to Get Things Wrong[1], at least in theory there should *not* be state
or cache files stored in ~/.config.

[1] For example, GUI text editors updating precious files in place
using O_TRUNC, as opposed to writing to foo.new, reading the extended
attributes and Posix ACL's from file foo and writing them to foo.new,
calling fsync, and then renaming foo.new to foo --- because The Right
Way is too much trouble for an application author.  Sigh....

Cheers,

						- Ted

