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 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: 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 wrote: > Just checking you are all still out there :-) > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: 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: 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 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" 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: 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: 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 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: On 10/04/2019, Warren Toomey 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: References: <20190410075426.GA11907@minnie.tuhs.org> Message-ID: <1JOIuGgWE2KzKEm6Qr_fZLC82MT-p-iyZe4FqBpNPLMhBKNVmD_urkDONg5Gk5DlmjQWhdxAGMCe32hxczg-P1skbe_2fnIS8cAY4WiSBD0=@kix.es> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, 10 de April de 2019 15:41, Nemo 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: Hi There! Sergio El mié., 10 abr. 2019 9:55, Warren Toomey escribió: > Just checking you are all still out there :-) > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <20190410075426.GA11907@minnie.tuhs.org> Message-ID: It has been fun watching the replies to the ping. timeout. David > On Apr 10, 2019, at 8:14 AM, SPC wrote: > > Hi There! > > Sergio > > El mié., 10 abr. 2019 9:55, Warren Toomey > escribió: > Just checking you are all still out there :-) > Cheers, Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: 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> <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 wrote: >> On 10/04/2019, Warren Toomey 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: 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" > 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: 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: 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: References: Message-ID: On Wed, Apr 10, 2019 at 1:00 PM Pat Barron 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: 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: 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: 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: <14453.1554920068@cesium.clock.org> Message-ID: 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 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: 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: References: Message-ID: 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 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: 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: References: <14453.1554920068@cesium.clock.org> Message-ID: 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 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 > 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: 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: References: <14453.1554920068@cesium.clock.org> Message-ID: 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 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 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 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: 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: References: <14453.1554920068@cesium.clock.org> 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: 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: 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: References: 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: References: <14453.1554920068@cesium.clock.org> Message-ID: <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com> On Apr 10, 2019, at 3:24 PM, 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. 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: References: Message-ID: On Apr 10, 2019, at 4:06 PM, Richard Salz 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: References: Message-ID: 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 wrote: > > On Apr 10, 2019, at 4:06 PM, Richard Salz 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: <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: 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: References: Message-ID: On Wed, Apr 10, 2019 at 6:07 PM Pat Barron 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 -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <14453.1554920068@cesium.clock.org> <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: 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: 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 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: <14453.1554920068@cesium.clock.org> <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 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 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 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: References: Message-ID: George Michaelson wrote: > On Apr 10, 2019, at 4:06 PM, Richard Salz 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 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: <14453.1554920068@cesium.clock.org> <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com> <7b575d14-270c-1d3a-7419-0329ffb42669@esse.ch> Message-ID: 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 wrote: > On 4/11/19 1:19 AM, Bakul Shah wrote: > > On Apr 10, 2019, at 3:24 PM, Clem Cole 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: 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: References: <14453.1554920068@cesium.clock.org> <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com> <7b575d14-270c-1d3a-7419-0329ffb42669@esse.ch> Message-ID: On Thu, Apr 11, 2019 at 9:49 AM Clem Cole 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: 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: References: <14453.1554920068@cesium.clock.org> <57C2E8D6-148C-487E-A6AE-B6E0E6EC337C@bitblocks.com> <7b575d14-270c-1d3a-7419-0329ffb42669@esse.ch> Message-ID: 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 wrote: > On Thu, Apr 11, 2019 at 9:49 AM Clem Cole 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: 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: 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 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: On Apr 11, 2019, at 8:57 AM, Richard Tobin 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: References: Message-ID: <7A06D817-72BD-47CB-BEE5-25755B4C3ABF@eschatologist.net> On Apr 10, 2019, at 4:06 PM, Richard Salz 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: <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 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: On Fri, Apr 12, 2019 at 8:51 AM Noel Chiappa 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: 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: 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" 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: 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: 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 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: 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 > 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 >> 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: 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: References: Message-ID: On Tue, Apr 16, 2019 at 11:43 PM Paul Ruizendaal 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: 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: 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: 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: References: <20190413225903.GA8566@minnie.tuhs.org> Message-ID: 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 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: 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 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: References: Message-ID: Can't help on the main thrust of this, but can answer one question... On Thu, Apr 18, 2019 at 8:33 PM 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 > 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). FILE.EXT was the format. This was later extended to FILE.EXT. So the <> just contain the whole path, separated by dots. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: (reed@reedmedia.net's message of "Thu, 18 Apr 2019 20:54:11 -0500 (CDT)") References: 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: References: <20190413225903.GA8566@minnie.tuhs.org> Message-ID: <201904191018.x3JAI9ml023554@freefriends.org> Robert Swierczek 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 写到: > 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: 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 写到: > 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: 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: <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> <201904191018.x3JAI9ml023554@freefriends.org> Message-ID: 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 wrote: > Robert Swierczek 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: 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: References: Message-ID: On Thu, Apr 18, 2019 at 10:33 PM 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: 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: References: Message-ID: 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 wrote: > > > On Thu, Apr 18, 2019 at 10:33 PM 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: 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: References: Message-ID: 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: References: Message-ID: 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: References: Message-ID: 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 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: 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: 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: References: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.com> Message-ID: 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 wrote: > Yes indeed, I am interested! > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <201904201900.x3KJ0fSs009517@darkstar.fourwinds.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 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 & 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> <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: 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> <201904201931.x3KJVZLN014194@darkstar.fourwinds.com> <0cdc4e00-bce9-cd68-193f-1c78323a8c5e@spamtrap.tnetconsulting.net> Message-ID: 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: On Sat, Apr 20, 2019 at 4:43 PM Noel Chiappa 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: 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: References: <20190420224241.489E218C09F@mercury.lcs.mit.edu> 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> <201904202253.x3KMr7LR010510@darkstar.fourwinds.com> Message-ID: On Sat, Apr 20, 2019 at 4:53 PM Jon Steinhart 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: 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: References: <20190420224241.489E218C09F@mercury.lcs.mit.edu> <201904202253.x3KMr7LR010510@darkstar.fourwinds.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: 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> <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: 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: References: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.com> <20190421002212.2E1861AF502@yagi.h-net.msu.edu> Message-ID: 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: 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: 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 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: 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: References: <201904202257.x3KMvRQ1011077@darkstar.fourwinds.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: References: <20190413225903.GA8566@minnie.tuhs.org> <201904191018.x3JAI9ml023554@freefriends.org> Message-ID: <201904221915.x3MJFZa7018938@freefriends.org> Thanks for that link. It was an interesting watch. Arnold "John P. Linderman" 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 wrote: > > > Robert Swierczek 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: 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: References: 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: References: 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: <20190423224702.GA90155@indra.papnet.eu> Message-ID: > 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: -- 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: 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: References: Message-ID: On Thu, Apr 25, 2019, 6:56 PM 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: 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: On Sat, Apr 27, 2019 at 8:26 AM Anthony Martin 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: 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: References: <20190427141655.GA8310@alice> 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: On Sat, Apr 27, 2019 at 10:26 AM Anthony Martin 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: 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: References: <20190427141655.GA8310@alice> Message-ID: <201904281200.x3SC03Oa014615@freefriends.org> Dan Cross 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: References: <20190427141655.GA8310@alice> Message-ID: Dan Cross writes: > On Sat, Apr 27, 2019 at 10:26 AM Anthony Martin > 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: References: <20190427141655.GA8310@alice> Message-ID: <5B95265E-B86B-4957-8C49-7448180A0F97@bitblocks.com> On Apr 28, 2019, at 4:47 AM, Dan Cross 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: On Apr 28, 2019, at 12:45 PM, Jon Forrest 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. 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 > 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: References: <20190427141655.GA8310@alice> Message-ID: On Sat, Apr 27, 2019 at 9:38 AM Warner Losh wrote: > > > On Sat, Apr 27, 2019 at 8:26 AM Anthony Martin 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: 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: 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 wrote: > Von: Jon Forrest > > > 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: 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: 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: 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: References: Message-ID: 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 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: 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: References: 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 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: On Mon, Apr 29, 2019 at 8:39 AM Norman Wilson 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: 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: References: <20190428165452.9BB414422F@lignose.oclsc.org> <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.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> <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se> Message-ID: On Mon, Apr 29, 2019 at 12:14 PM Michael Kjörling 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: 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> <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se> Message-ID: On Mon, 29 Apr 2019 at 14:15, Michael Kjörling 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: 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> <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?= 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 /{config,state,,cache} to be more modular than {config,state,,cache}/ -- 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: 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: 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: References: <20190428165452.9BB414422F@lignose.oclsc.org> <97e93751-6e2f-a120-2159-0fb0246ad683@gmail.com> <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se> 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> <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se> <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> <20190429180512.q2jrlsyhvb7cx4ev@h-174-65.A328.priv.bahnhof.se> <20190430064408.ry56lmufdgq7uaut@h-174-65.A328.priv.bahnhof.se> <20190430072449.GA79218@wopr> Message-ID: 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 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> <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