From marzhall.o at gmail.com Fri Jul 1 00:08:34 2022 From: marzhall.o at gmail.com (Marshall Conover) Date: Thu, 30 Jun 2022 10:08:34 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: A fun one: Using folders. People in their early 20s and younger - mostly those who grew up with iPhones, Androids and Ipads - didn't interact with filesystems. Instead, they grew up using apps that handled storage for them. When they wanted a video, they were looking for it in a streaming app, and they used the app's search function. If they were looking at photos, it was much the same. Because of this, as hard as it is to believe, they don't really grok the concept - and this keeps popping up, to my delight. It initially popped into my field of view last year, when an astro professor was running into trouble with undergrad students. The professor was asking the students to put certain data into certain folders, but the students fundamentally didn't understand what "putting certain data in certain folders" meant: https://twitter.com/saavikford/status/1425235201047908359 I love this quote from the professor, though unfortunately the tweet prompting it was deleted. The professor was asked something like "do the students not understand how drawers work?" Her response was, "They fail to grasp that the idea of drawers themselves might exist. Because they have a perfectly valid system of a laundry basket and a robot that retrieves exactly the sock they want when they want it (as I'm finally figuring out). Or something like that, anyway." And this continues to pop up - I saw a reddit thread the other day that brought up entry-level computer science students who are coming in not understanding folders at all. It's being added to the list of abstractions that most people don't interact with day-to-day anymore, and which must be explained. With that said, I have a friend my age (30s) who enjoys bringing up their conviction that the Zoomers are correct, and hierarchical filesystems should go the way of the dinosaur - with searchability/tagging being the correct way to handle storage. That could also be a fun discussion for the ML. One other fun note for the prompt. Someone noted that, working at an apple store, they kept seeing young people use the caps lock key even when just typing the first letter of the sentence; it then clicked that this is closest to how phone keyboards work, and is likely where they got the muscle memory from. Hope you're all having a nice morning, Marshall On Thu, Jun 30, 2022 at 9:40 AM Marc Donner wrote: > > Programming an 026 skip card. Inserting the skip card. > Using ed in kernel safe mode to fix a broken config file. > Threading a half-inch tape in a tape drive. Remembering to insert or remove the write ring. > Cleaning floppy disk heads. > Manually keying a boot program into an SDS-930. > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Thu, Jun 30, 2022 at 9:14 AM steve jenkin wrote: >> >> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”? >> >> Whistling into a telephone while the modem is attached, because your keyboard has a stuck key >> - something I absolutely don’t miss. >> >> Having a computer in a grimy wharehouse with 400 days of uptime & wondering how a reboot might go? >> >> steve j >> >> ========= >> >> 9 Skills Our Grandkids Will Never Have >> >> >> 1: Using record players, audio cassettes, and VCRs >> 2: Using analog phones [ or an Analog Clock ] >> 3. Writing letters by hand and mailing them >> 4. Reading and writing in cursive >> 5. Using manual research methods [ this is a Genealogy site ] >> 6. Preparing food the old-fashioned way >> 7. Creating and mending clothing >> 8. Building furniture from scratch >> 9. Speaking the languages of their ancestors >> >> -- >> Steve Jenkin, IT Systems and Design >> 0412 786 915 (+61 412 786 915) >> PO Box 38, Kippax ACT 2615, AUSTRALIA >> >> mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin >> From lm at mcvoy.com Fri Jul 1 00:15:19 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Jun 2022 07:15:19 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <20220630141519.GN28916@mcvoy.com> I can still remember my amazement when I learned that a floppy or a hard disk wasn't one big file. That's when the light went on that there was a file system. Another one was popen(), I saw the fork in there and my head exploded, for some stupid reason I didn't think that libc would create new processes. One light bulb after another. On Thu, Jun 30, 2022 at 10:08:34AM -0400, Marshall Conover wrote: > A fun one: Using folders. > > People in their early 20s and younger - mostly those who grew up with > iPhones, Androids and Ipads - didn't interact with filesystems. > Instead, they grew up using apps that handled storage for them. When > they wanted a video, they were looking for it in a streaming app, and > they used the app's search function. If they were looking at photos, > it was much the same. Because of this, as hard as it is to believe, > they don't really grok the concept - and this keeps popping up, to my > delight. > > It initially popped into my field of view last year, when an astro > professor was running into trouble with undergrad students. The > professor was asking the students to put certain data into certain > folders, but the students fundamentally didn't understand what > "putting certain data in certain folders" meant: > https://twitter.com/saavikford/status/1425235201047908359 > > I love this quote from the professor, though unfortunately the tweet > prompting it was deleted. The professor was asked something like "do > the students not understand how drawers work?" Her response was, "They > fail to grasp that the idea of drawers themselves might exist. Because > they have a perfectly valid system of a laundry basket and a robot > that retrieves exactly the sock they want when they want it (as I'm > finally figuring out). Or something like that, anyway." > > And this continues to pop up - I saw a reddit thread the other day > that brought up entry-level computer science students who are coming > in not understanding folders at all. It's being added to the list of > abstractions that most people don't interact with day-to-day anymore, > and which must be explained. > > With that said, I have a friend my age (30s) who enjoys bringing up > their conviction that the Zoomers are correct, and hierarchical > filesystems should go the way of the dinosaur - with > searchability/tagging being the correct way to handle storage. That > could also be a fun discussion for the ML. > > One other fun note for the prompt. Someone noted that, working at an > apple store, they kept seeing young people use the caps lock key even > when just typing the first letter of the sentence; it then clicked > that this is closest to how phone keyboards work, and is likely where > they got the muscle memory from. > > Hope you're all having a nice morning, > > Marshall > > On Thu, Jun 30, 2022 at 9:40 AM Marc Donner wrote: > > > > Programming an 026 skip card. Inserting the skip card. > > Using ed in kernel safe mode to fix a broken config file. > > Threading a half-inch tape in a tape drive. Remembering to insert or remove the write ring. > > Cleaning floppy disk heads. > > Manually keying a boot program into an SDS-930. > > ===== > > nygeek.net > > mindthegapdialogs.com/home > > > > > > On Thu, Jun 30, 2022 at 9:14 AM steve jenkin wrote: > >> > >> What are the 1970???s & 1980???s Computing / IT skills ???our grandkids won???t have???? > >> > >> Whistling into a telephone while the modem is attached, because your keyboard has a stuck key > >> - something I absolutely don???t miss. > >> > >> Having a computer in a grimy wharehouse with 400 days of uptime & wondering how a reboot might go? > >> > >> steve j > >> > >> ========= > >> > >> 9 Skills Our Grandkids Will Never Have > >> > >> > >> 1: Using record players, audio cassettes, and VCRs > >> 2: Using analog phones [ or an Analog Clock ] > >> 3. Writing letters by hand and mailing them > >> 4. Reading and writing in cursive > >> 5. Using manual research methods [ this is a Genealogy site ] > >> 6. Preparing food the old-fashioned way > >> 7. Creating and mending clothing > >> 8. Building furniture from scratch > >> 9. Speaking the languages of their ancestors > >> > >> -- > >> Steve Jenkin, IT Systems and Design > >> 0412 786 915 (+61 412 786 915) > >> PO Box 38, Kippax ACT 2615, AUSTRALIA > >> > >> mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin > >> -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From michael at kjorling.se Fri Jul 1 00:23:34 2022 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 30 Jun 2022 14:23:34 +0000 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <4373e29c-d2a9-4964-9721-2a006304bf91@home.arpa> On 30 Jun 2022 23:14 +1000, from sjenkin at canb.auug.org.au (steve jenkin): > What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”? Tediously typing computer programs into their (or others') systems from listings in printed magazines bought in and brought home from a store (by which I mean the physical, brick-and-mortar kind), only to spend anywhere from minutes to days figuring out why the program doesn't do what the magazine says it will, if it even works at all. This thread should probably be on COFF, not TUHS. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From will.senn at gmail.com Fri Jul 1 00:32:02 2022 From: will.senn at gmail.com (Will Senn) Date: Thu, 30 Jun 2022 09:32:02 -0500 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <512b4125-f974-a486-b12c-83b369fe976d@gmail.com> Every time I teach a course that deals with the terminal, I have to have a complete lecture on files, filesystems and the concept of current directory. It is a rare exception that I get students who know them from prior experience. This includes folks into their 40's. in the spirit of what our grandkids won't have skills (or knowledge) for: Our grandkids won't go looking for bent pins on their video cables or know that's why their normally colorful view of the world suddenly tints cyanish... or that a crossover's a cable or that whiz-bang programming languages of the modern era are still playing catch-up to ALGOL 1960 and other brilliant languages of the 20th century or that there was a time when current decided 0's and 1's rather than voltage they'll be endlessly frustrated by CD/DVDs even if they can find a player - some working and some not (writeables have significant calibration and/or deterioration issues) - oh wait, that last one's not my grandkids, it's me :). On 6/30/22 9:08 AM, Marshall Conover wrote: > A fun one: Using folders. > > People in their early 20s and younger - mostly those who grew up with > iPhones, Androids and Ipads - didn't interact with filesystems. > Instead, they grew up using apps that handled storage for them. When > they wanted a video, they were looking for it in a streaming app, and > they used the app's search function. If they were looking at photos, > it was much the same. Because of this, as hard as it is to believe, > they don't really grok the concept - and this keeps popping up, to my > delight. > > It initially popped into my field of view last year, when an astro > professor was running into trouble with undergrad students. The > professor was asking the students to put certain data into certain > folders, but the students fundamentally didn't understand what > "putting certain data in certain folders" meant: > https://twitter.com/saavikford/status/1425235201047908359 > > I love this quote from the professor, though unfortunately the tweet > prompting it was deleted. The professor was asked something like "do > the students not understand how drawers work?" Her response was, "They > fail to grasp that the idea of drawers themselves might exist. Because > they have a perfectly valid system of a laundry basket and a robot > that retrieves exactly the sock they want when they want it (as I'm > finally figuring out). Or something like that, anyway." > > And this continues to pop up - I saw a reddit thread the other day > that brought up entry-level computer science students who are coming > in not understanding folders at all. It's being added to the list of > abstractions that most people don't interact with day-to-day anymore, > and which must be explained. > > With that said, I have a friend my age (30s) who enjoys bringing up > their conviction that the Zoomers are correct, and hierarchical > filesystems should go the way of the dinosaur - with > searchability/tagging being the correct way to handle storage. That > could also be a fun discussion for the ML. > > One other fun note for the prompt. Someone noted that, working at an > apple store, they kept seeing young people use the caps lock key even > when just typing the first letter of the sentence; it then clicked > that this is closest to how phone keyboards work, and is likely where > they got the muscle memory from. > > Hope you're all having a nice morning, > > Marshall > > On Thu, Jun 30, 2022 at 9:40 AM Marc Donner wrote: >> Programming an 026 skip card. Inserting the skip card. >> Using ed in kernel safe mode to fix a broken config file. >> Threading a half-inch tape in a tape drive. Remembering to insert or remove the write ring. >> Cleaning floppy disk heads. >> Manually keying a boot program into an SDS-930. >> ===== >> nygeek.net >> mindthegapdialogs.com/home >> >> >> On Thu, Jun 30, 2022 at 9:14 AM steve jenkin wrote: >>> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”? >>> >>> Whistling into a telephone while the modem is attached, because your keyboard has a stuck key >>> - something I absolutely don’t miss. >>> >>> Having a computer in a grimy wharehouse with 400 days of uptime & wondering how a reboot might go? >>> >>> steve j >>> >>> ========= >>> >>> 9 Skills Our Grandkids Will Never Have >>> >>> >>> 1: Using record players, audio cassettes, and VCRs >>> 2: Using analog phones [ or an Analog Clock ] >>> 3. Writing letters by hand and mailing them >>> 4. Reading and writing in cursive >>> 5. Using manual research methods [ this is a Genealogy site ] >>> 6. Preparing food the old-fashioned way >>> 7. Creating and mending clothing >>> 8. Building furniture from scratch >>> 9. Speaking the languages of their ancestors >>> >>> -- >>> Steve Jenkin, IT Systems and Design >>> 0412 786 915 (+61 412 786 915) >>> PO Box 38, Kippax ACT 2615, AUSTRALIA >>> >>> mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin >>> From pdagog at gmail.com Fri Jul 1 00:42:20 2022 From: pdagog at gmail.com (Pierre DAVID) Date: Thu, 30 Jun 2022 16:42:20 +0200 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: - Add an entry to /etc/termcap. - Try all speeds on your terminal in order to find the good one to connect to your host. Pierre From aek at bitsavers.org Fri Jul 1 01:12:44 2022 From: aek at bitsavers.org (Al Kossow) Date: Thu, 30 Jun 2022 08:12:44 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: On 6/30/22 6:14 AM, steve jenkin wrote: > 9 Skills Our Grandkids Will Never Have Knowing how to do pre-press layout for paper books Organizing things hierarchically From clemc at ccc.com Fri Jul 1 01:23:27 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Jun 2022 11:23:27 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: - that goes with >>dialing<< the phone and putting it in the rubber cups after you hear the tone from the FSK modem at that other end. - putting your deck into run queue and waiting for your turn to get 5 seconds of compile and 3 seconds of CPU time for a student job - being limited to > .5M of storage (if you had any at all) - If you were an operator - handing a tape change request - starting/stopping the batch system to let students' jobs run - changing the print train - moving a plot tape from the computer to the plotter for output - changing disks - what a disk crash actually sounds like (and looks like on the platters) ᐧ On Thu, Jun 30, 2022 at 9:41 AM Marc Donner wrote: > Programming an 026 skip card. Inserting the skip card. > Using ed in kernel safe mode to fix a broken config file. > Threading a half-inch tape in a tape drive. Remembering to insert or > remove the write ring. > Cleaning floppy disk heads. > Manually keying a boot program into an SDS-930. > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Thu, Jun 30, 2022 at 9:14 AM steve jenkin > wrote: > >> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t >> have”? >> >> Whistling into a telephone while the modem is attached, because your >> keyboard has a stuck key >> - something I absolutely don’t miss. >> >> Having a computer in a grimy wharehouse with 400 days of uptime & >> wondering how a reboot might go? >> >> steve j >> >> ========= >> >> 9 Skills Our Grandkids Will Never Have >> < >> https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/ >> > >> >> 1: Using record players, audio cassettes, and VCRs >> 2: Using analog phones >> [ or an Analog Clock ] >> 3. Writing letters by hand and mailing them >> 4. Reading and writing in cursive >> 5. Using manual research methods [ >> this is a Genealogy site ] >> 6. Preparing food the old-fashioned way >> 7. Creating and mending clothing >> 8. Building furniture from scratch >> 9. Speaking the languages of their ancestors >> >> -- >> Steve Jenkin, IT Systems and Design >> 0412 786 915 (+61 412 786 915) >> PO Box 38, Kippax ACT 2615, AUSTRALIA >> >> mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Jul 1 01:35:03 2022 From: clemc at ccc.com (Clem Cole) Date: Thu, 30 Jun 2022 11:35:03 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: a few more ... - the sounds of an ASR 33 - why bang, and splat are called that - the sounds of terminal room - running 'system' diagnostics - what 'dumping core' refers too - rolling an unspooled DECtape up after dropping it and stepping on it, and it still reading - the concept/use of PPT - entering the RIM loader for the PDP-8 from the front panel, so you could load the rest of the boot from PPT - entering the board program into a PDP-8 11/45 without an M792 diode 'ROM' board. - Watching the idle pattern on the lights Note the last 3 can be re-lived with a PiDP-8 or PiDP-11 ᐧ ᐧ On Thu, Jun 30, 2022 at 11:23 AM Clem Cole wrote: > > > - that goes with >>dialing<< the phone and putting it in the rubber > cups after you hear the tone from the FSK modem at that other end. > - putting your deck into run queue and waiting for your turn to get 5 > seconds of compile and 3 seconds of CPU time for a student job > - being limited to > .5M of storage (if you had any at all) > - If you were an operator > - handing a tape change request > - starting/stopping the batch system to let students' jobs run > - changing the print train > - moving a plot tape from the computer to the plotter for output > - changing disks > - what a disk crash actually sounds like (and looks like on the > platters) > > ᐧ > > On Thu, Jun 30, 2022 at 9:41 AM Marc Donner wrote: > >> Programming an 026 skip card. Inserting the skip card. >> Using ed in kernel safe mode to fix a broken config file. >> Threading a half-inch tape in a tape drive. Remembering to insert or >> remove the write ring. >> Cleaning floppy disk heads. >> Manually keying a boot program into an SDS-930. >> ===== >> nygeek.net >> mindthegapdialogs.com/home >> >> >> On Thu, Jun 30, 2022 at 9:14 AM steve jenkin >> wrote: >> >>> What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t >>> have”? >>> >>> Whistling into a telephone while the modem is attached, because your >>> keyboard has a stuck key >>> - something I absolutely don’t miss. >>> >>> Having a computer in a grimy wharehouse with 400 days of uptime & >>> wondering how a reboot might go? >>> >>> steve j >>> >>> ========= >>> >>> 9 Skills Our Grandkids Will Never Have >>> < >>> https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/ >>> > >>> >>> 1: Using record players, audio cassettes, and VCRs >>> 2: Using analog phones >>> [ or an Analog Clock ] >>> 3. Writing letters by hand and mailing them >>> 4. Reading and writing in cursive >>> 5. Using manual research methods >>> [ this is a Genealogy site ] >>> 6. Preparing food the old-fashioned way >>> 7. Creating and mending clothing >>> 8. Building furniture from scratch >>> 9. Speaking the languages of their ancestors >>> >>> -- >>> Steve Jenkin, IT Systems and Design >>> 0412 786 915 (+61 412 786 915) >>> PO Box 38, Kippax ACT 2615, AUSTRALIA >>> >>> mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jul 1 01:44:06 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Jun 2022 08:44:06 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <20220630154406.GT28916@mcvoy.com> On Thu, Jun 30, 2022 at 04:42:20PM +0200, Pierre DAVID wrote: > - Add an entry to /etc/termcap. I have to admit that something like 40 years ago, I tried and failed. Paid Dave Cohrs $20 to write one for me. I remember him laughing at me because it was trivial for him but I just kept screwing it up. That and sendmail.cf, I've fought with that file quite a bit, got it to work but just barely. From athornton at gmail.com Fri Jul 1 01:55:41 2022 From: athornton at gmail.com (Adam Thornton) Date: Thu, 30 Jun 2022 08:55:41 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <779778EE-7A4B-42BC-A3AD-5D70E09E77B8@gmail.com> > On Jun 30, 2022, at 6:14 AM, steve jenkin wrote: > > What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t have”? 80s: being able to understand more or less what the whole machine was doing at any given time. I consider myself fortunate that I grew up on 80s micros where the machines were powerful enough to do interesting-to-a-bright-12-year-old things (like, say, Choplifter), but small enough that...well, there's only 64K, only one instruction is operating at a time, the sound-and-video-coprocessor-(if-any)-APIs are tiny, if you're a determined bright 12-year-old, you can figure out how it's doing what it's doing. This is post-80s, but: Massive midrange hearing loss in their 40s and 50s because of their late 20s and 30s being spent inside very very noisy datacenters. Not that I'm bitter. Just it would have been nice if my parents were right and it had been that loud rock 'n' roll rather than, you know, _fans_. Adam From paul.winalski at gmail.com Fri Jul 1 02:37:17 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 30 Jun 2022 12:37:17 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: On 6/30/22, steve jenkin wrote: > What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t > have”? Not skills, but knowledge of why some things in Unix are the way they are: o why a memory access violation is reported as "segmentation fault" or "bus error", and the difference between the two o why CTRL/D is used to end a shell command line session o why CTRL/S and CTRL/Q are used for flow control in a shell command line session o why an application memory dump after an application crash is called a core file -Paul W. From mphuff at gmail.com Fri Jul 1 05:24:39 2022 From: mphuff at gmail.com (Michael Huff) Date: Thu, 30 Jun 2022 11:24:39 -0800 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: At the risk of going off-topic (Linux and 90's/00's) I'll play too: 1)remembering to set ftp type to binary (that one bit me more than once, at least) 2)learning what a "winmodem" is and avoiding it like the plague! 3)Splitting a partition with FIPS 4)Writing an image to floppy 5)doing anything at all with a floppy, come to think of it 6)Setting jumpers on sound cards and drives 7)learning how to configure XFree86 so that it doesn't blow out your monitor! (never happened to me, but I remember the scary warnings about it: https://www.xfree86.org/4.0.3/chips7.html ) 8)configuring PPP internet On Thu, Jun 30, 2022 at 5:14 AM steve jenkin wrote: > What are the 1970’s & 1980’s Computing / IT skills “our grandkids won’t > have”? > > Whistling into a telephone while the modem is attached, because your > keyboard has a stuck key > - something I absolutely don’t miss. > > Having a computer in a grimy wharehouse with 400 days of uptime & > wondering how a reboot might go? > > steve j > > ========= > > 9 Skills Our Grandkids Will Never Have > < > https://blog.myheritage.com/2022/06/9-skills-our-grandkids-will-never-have/ > > > > 1: Using record players, audio cassettes, and VCRs > 2: Using analog phones > [ or an Analog Clock ] > 3. Writing letters by hand and mailing them > 4. Reading and writing in cursive > 5. Using manual research methods [ > this is a Genealogy site ] > 6. Preparing food the old-fashioned way > 7. Creating and mending clothing > 8. Building furniture from scratch > 9. Speaking the languages of their ancestors > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Jul 1 05:56:46 2022 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 30 Jun 2022 12:56:46 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <202206301956.25UJukpc2340979@darkstar.fourwinds.com> Entering a boot loader using front panel switches. From tuhs at tuhs.org Fri Jul 1 06:43:01 2022 From: tuhs at tuhs.org (Robert Stanford via TUHS) Date: Fri, 1 Jul 2022 06:43:01 +1000 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: editing /etc/inittab On 1/7/22 05:24, Michael Huff wrote: > At the risk of going off-topic (Linux and 90's/00's) I'll play too: > 1)remembering to set ftp type to binary (that one bit me more than > once, at least) > 2)learning what a "winmodem" is and avoiding it like the plague! > 3)Splitting a partition with FIPS > 4)Writing an image to floppy > 5)doing anything at all with a floppy, come to think of it > 6)Setting jumpers on sound cards and drives > 7)learning how to configure XFree86 so that it doesn't blow out your > monitor! (never happened to me, but I remember the scary warnings > about it: https://www.xfree86.org/4.0.3/chips7.html ) > 8)configuring PPP internet > > > On Thu, Jun 30, 2022 at 5:14 AM steve jenkin > wrote: > > What are the 1970’s & 1980’s Computing / IT skills “our grandkids > won’t have”? > > Whistling into a telephone while the modem is attached, because > your keyboard has a stuck key >          - something I absolutely don’t miss. > > Having a computer in a grimy wharehouse with 400 days of uptime & > wondering how a reboot might go? > > steve j > > ========= > > 9 Skills Our Grandkids Will Never Have >         > > >         1: Using record players, audio cassettes, and VCRs >         2: Using analog phones                   [ or an Analog > Clock ] >         3. Writing letters by hand and mailing them >         4. Reading and writing in cursive >         5. Using manual research methods           [ this is a > Genealogy site ] >         6. Preparing food the old-fashioned way >         7. Creating and mending clothing >         8. Building furniture from scratch >         9. Speaking the languages of their ancestors > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 1 06:49:19 2022 From: tuhs at tuhs.org (Chris Pinnock via TUHS) Date: Thu, 30 Jun 2022 21:49:19 +0100 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: Editing /etc/inittab with ed(1). > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS wrote: > > editing /etc/inittab > From rminnich at gmail.com Fri Jul 1 07:11:17 2022 From: rminnich at gmail.com (ron minnich) Date: Thu, 30 Jun 2022 14:11:17 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: at the coreboot workshop 2w ago, we were having very weird memory corruption issues. At some point I popped up dc and started doing base 16 math. Comment: "that's the first time in my life I've ever seen someone use dc for hex math" On Thu, Jun 30, 2022 at 1:49 PM Chris Pinnock via TUHS wrote: > > Editing /etc/inittab with ed(1). > > > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS wrote: > > > > editing /etc/inittab > > > From lm at mcvoy.com Fri Jul 1 07:21:53 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Jun 2022 14:21:53 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <20220630212153.GD11191@mcvoy.com> When your tty settings are messed up, ed(1) has saved my butt a number of times. Also really pleasant to use on slow modems where just the screen refresh takes a long time. ed foo.c /^busted_function .,.+20p is dramatically faster than vi(1) at 300 baud. On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote: > Editing /etc/inittab with ed(1). > > > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS wrote: > > > > editing /etc/inittab > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Fri Jul 1 07:24:45 2022 From: tuhs at tuhs.org (Chris Pinnock via TUHS) Date: Thu, 30 Jun 2022 22:24:45 +0100 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <20220630212153.GD11191@mcvoy.com> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220630212153.GD11191@mcvoy.com> Message-ID: I’ve just used it in a paper I’m writing. As an aside, the relatively recent ed(1) mastery book by Michael Lucas is a rather fun (and very informative read). C > On 30 Jun 2022, at 22:21, Larry McVoy wrote: > > When your tty settings are messed up, ed(1) has saved my butt a number > of times. Also really pleasant to use on slow modems where just the > screen refresh takes a long time. > > ed foo.c > /^busted_function > .,.+20p > > is dramatically faster than vi(1) at 300 baud. > > On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote: >> Editing /etc/inittab with ed(1). >> >>> On 30 Jun 2022, at 21:43, Robert Stanford via TUHS wrote: >>> >>> editing /etc/inittab >>> > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From marc.donner at gmail.com Fri Jul 1 07:24:20 2022 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 30 Jun 2022 17:24:20 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <20220630212153.GD11191@mcvoy.com> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220630212153.GD11191@mcvoy.com> Message-ID: And, of course, even worse editing with cat! ===== nygeek.net mindthegapdialogs.com/home On Thu, Jun 30, 2022 at 5:22 PM Larry McVoy wrote: > When your tty settings are messed up, ed(1) has saved my butt a number > of times. Also really pleasant to use on slow modems where just the > screen refresh takes a long time. > > ed foo.c > /^busted_function > .,.+20p > > is dramatically faster than vi(1) at 300 baud. > > On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote: > > Editing /etc/inittab with ed(1). > > > > > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS > wrote: > > > > > > editing /etc/inittab > > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From audioskeptic at gmail.com Fri Jul 1 07:41:26 2022 From: audioskeptic at gmail.com (James Johnston) Date: Thu, 30 Jun 2022 14:41:26 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220630212153.GD11191@mcvoy.com> Message-ID: Loading your 18" gigantic 5 MB disc in the tray, and giving it 5 minutes to temperature equalize. On Thu, Jun 30, 2022 at 2:26 PM Marc Donner wrote: > And, of course, even worse editing with cat! > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Thu, Jun 30, 2022 at 5:22 PM Larry McVoy wrote: > >> When your tty settings are messed up, ed(1) has saved my butt a number >> of times. Also really pleasant to use on slow modems where just the >> screen refresh takes a long time. >> >> ed foo.c >> /^busted_function >> .,.+20p >> >> is dramatically faster than vi(1) at 300 baud. >> >> On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote: >> > Editing /etc/inittab with ed(1). >> > >> > > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS >> wrote: >> > > >> > > editing /etc/inittab >> > > >> >> -- >> --- >> Larry McVoy Retired to fishing >> http://www.mcvoy.com/lm/boat >> > -- James D. (jj) Johnston Chief Scientist, Immersion Networks -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Jul 1 07:54:45 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Jun 2022 14:54:45 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220630212153.GD11191@mcvoy.com> Message-ID: <20220630215445.GF11191@mcvoy.com> Wire wrapped computers. The Geophysics department (I worked there as a sys admin) had one and we all hated it, wanted it gone, but "there is no budget". So one night after some beers, Bruce Karsh got an evil grin, opened it up, and bent one wire back and forth until it broke under the insulation. Pulled it enough that the wires didn't touch. Attempted to boot it, nothing (which was amazing because I bet there were a ton of wires that could have been broken and you wouldn't notice until you tried to use whatever that wire did). Bruce had a satisfied grin on his face and said "They'll find budget" and they did, whatever we got was way more modern and easy to use, I think it was a Masscomp. On Thu, Jun 30, 2022 at 02:41:26PM -0700, James Johnston wrote: > Loading your 18" gigantic 5 MB disc in the tray, and giving it 5 minutes to > temperature equalize. > > On Thu, Jun 30, 2022 at 2:26 PM Marc Donner wrote: > > > And, of course, even worse editing with cat! > > ===== > > nygeek.net > > mindthegapdialogs.com/home > > > > > > On Thu, Jun 30, 2022 at 5:22 PM Larry McVoy wrote: > > > >> When your tty settings are messed up, ed(1) has saved my butt a number > >> of times. Also really pleasant to use on slow modems where just the > >> screen refresh takes a long time. > >> > >> ed foo.c > >> /^busted_function > >> .,.+20p > >> > >> is dramatically faster than vi(1) at 300 baud. > >> > >> On Thu, Jun 30, 2022 at 09:49:19PM +0100, Chris Pinnock via TUHS wrote: > >> > Editing /etc/inittab with ed(1). > >> > > >> > > On 30 Jun 2022, at 21:43, Robert Stanford via TUHS > >> wrote: > >> > > > >> > > editing /etc/inittab > >> > > > >> > >> -- > >> --- > >> Larry McVoy Retired to fishing > >> http://www.mcvoy.com/lm/boat > >> > > > > -- > James D. (jj) Johnston > > Chief Scientist, Immersion Networks -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From iain at csp-partnership.co.uk Fri Jul 1 08:05:27 2022 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Thu, 30 Jun 2022 23:05:27 +0100 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <20220630215445.GF11191@mcvoy.com> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220630212153.GD11191@mcvoy.com> <20220630215445.GF11191@mcvoy.com> Message-ID: <171E1A5A-268F-44EE-967E-5EF49004F824@csp-partnership.co.uk> Making more mods to the mods you had already made to a driver using adb on /dev/kmem. From unix at deranged.schneider.org Fri Jul 1 08:18:50 2022 From: unix at deranged.schneider.org (Rik Schneider) Date: Thu, 30 Jun 2022 15:18:50 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <171E1A5A-268F-44EE-967E-5EF49004F824@csp-partnership.co.uk> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220630212153.GD11191@mcvoy.com> <20220630215445.GF11191@mcvoy.com> <171E1A5A-268F-44EE-967E-5EF49004F824@csp-partnership.co.uk> Message-ID: Using a cheap pocket AM radio as an improvised signal probe. From marc.donner at gmail.com Fri Jul 1 08:51:09 2022 From: marc.donner at gmail.com (Marc Donner) Date: Thu, 30 Jun 2022 18:51:09 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220630212153.GD11191@mcvoy.com> <20220630215445.GF11191@mcvoy.com> <171E1A5A-268F-44EE-967E-5EF49004F824@csp-partnership.co.uk> Message-ID: Back when I worked at JPL in the late 1970s I was the most junior engineer, so my time slot on the computer (an SDS 930) was from 2AM to 4AM Monday, Wednesday, and Friday. Over time I got to know the guard who patrolled our building and we would hang out and chat when he came by and found me there with the machine room door open. After a while I was ordered to keep the computer room door closed, since keeping it open was unbalancing the A/C. Nonetheless he somehow managed to come in and find me quite regularly. One night I asked him how he knew when I was working. He told me that my program, when it was running, made a characteristic sound on his walkie-talkie. ===== nygeek.net mindthegapdialogs.com/home On Thu, Jun 30, 2022 at 6:19 PM Rik Schneider wrote: > Using a cheap pocket AM radio as an improvised signal probe. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtomek at ceti.pl Fri Jul 1 10:41:18 2022 From: rtomek at ceti.pl (Tomasz Rola) Date: Fri, 1 Jul 2022 02:41:18 +0200 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <20220701004118.GA22338@tau1.ceti.pl> On Thu, Jun 30, 2022 at 11:14:20PM +1000, steve jenkin wrote: > What are the 1970’s & 1980’s Computing / IT skills “our grandkids > won’t have”? > [...] Speaking any foreign language at all without help of a machine. Perhaps also being unable to formulate one's own judgements based on archive contained in one's own head, while offline, i.e. without asking other people/bots what to think. Being offline i.e. without constant buzz of b-s-hit coming in - for a long time (define what "long" actually means - minutes, days?) and not getting psychologically crippled as a result. Come to think about it, for them it is like sensory deprivation is for us. The difference will be, perhaps, that todays adult can undergo s.d. for a while and return to normal, while I can imagine for future adult, such a cutoff (no sensory deprivation, just internet deprivation) might result in effects similar to post traumatic disorders (and similarly long lasting). Ability to turn a computer off/on. Ability to understand importance of having the switch in devices. Handwriting. Ability to perform multiplication & division of long numbers on paper, flawlessly. Already lost to youngsters, from what I hear. Learn to use device by reading paper manual, and only this. Assuming paper manual is any good for the purpose, not just a bunch of slogans. Understand minutiae of older technology, limiting their understanding of our ways and times. So far, the gap seems to would be much bigger than between us and, say, Homo ergaster. Perhaps the gap will be more like between us and H. australopitecus. But paradoxically, understanding of the world, I expect to be bigger nowadays than in a future. Even today, how many people could explain why there is a light after switching the light on? I recall reading about some movie, whose fans were unable to understand why a protagonist took film (celuloid) to some "red room". They suggested it was for making photos sharper. Now imagine what would they say after watching Antonioni's "Blow up" where photography making is a central part of a plot. I am not sure - maybe I am taking it too seriously and I perceive most of posters here as tongue in cheek. But I keep imagining that one day some guy writes "ls -axl" and his head will be stuck on pike, because some cretine would claim his cow's milk turned black. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From lm at mcvoy.com Fri Jul 1 10:46:14 2022 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 30 Jun 2022 17:46:14 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <20220701004118.GA22338@tau1.ceti.pl> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220701004118.GA22338@tau1.ceti.pl> Message-ID: <20220701004614.GK11191@mcvoy.com> I just thought of another one. Reading maps, both road and contour maps. Google maps is a wonderful thing but they don't work in the back country. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From stewart at serissa.com Fri Jul 1 11:13:14 2022 From: stewart at serissa.com (Larry Stewart) Date: Thu, 30 Jun 2022 21:13:14 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <20220701004614.GK11191@mcvoy.com> References: <20220701004614.GK11191@mcvoy.com> Message-ID: <399A7D11-D7DC-4B3D-BF7A-855E042ED661@serissa.com> Sure they work. Just download the area for offline use. Bring a solar charger. But in my day we had a topo map and a compass and liked it. These days I would also bring a satphone or QRP ham rig. Has anyone mentioned porting kermit to a new micro yet? > On Jun 30, 2022, at 8:46 PM, Larry McVoy wrote: > > I just thought of another one. Reading maps, both road and contour maps. > Google maps is a wonderful thing but they don't work in the back country. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Fri Jul 1 20:48:05 2022 From: tuhs at tuhs.org (Tom Ivar Helbekkmo via TUHS) Date: Fri, 01 Jul 2022 12:48:05 +0200 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: (Rik Schneider's message of "Thu, 30 Jun 2022 15:18:50 -0700") References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220630212153.GD11191@mcvoy.com> <20220630215445.GF11191@mcvoy.com> <171E1A5A-268F-44EE-967E-5EF49004F824@csp-partnership.co.uk> Message-ID: Rik Schneider writes: > Using a cheap pocket AM radio as an improvised signal probe. A classmate and I discovered this while learning Z-80 machine language programming on his TRS-80. Of course our programs hung all the time, but we discovered that with a cheap transistor radio, not tuned to any station, sitting next to the TRS-80, we could learn to follow the execution through the BASIC code, into our machine language subroutines, and through the various parts of those. After a while, when our programs hung, we'd usually know just where it had happened. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From ori at heliconbooks.com Fri Jul 1 23:05:30 2022 From: ori at heliconbooks.com (Ori Idan) Date: Fri, 1 Jul 2022 16:05:30 +0300 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: On Thu, Jun 30, 2022 at 7:38 PM Paul Winalski wrote: > > o why a memory access violation is reported as "segmentation fault" or > "bus error", and the difference between the two > > o why CTRL/D is used to end a shell command line session I am not sure I know that, I'd be happy to know. > > o why CTRL/S and CTRL/Q are used for flow control in a shell command > line session > Also would be happy to know. > > o why an application memory dump after an application crash is called > a core file > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at mbsks.franken.de Fri Jul 1 23:17:32 2022 From: m at mbsks.franken.de (Matthias Bruestle) Date: Fri, 1 Jul 2022 15:17:32 +0200 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: I know something! On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: > > o why CTRL/S and CTRL/Q are used for flow control in a shell command > > line session > > > Also would be happy to know. https://en.wikipedia.org/wiki/Software_flow_control But I don't know the answer to Ctrl-D. :( And also the bus error and maybe the segmentation fault if it hasn't to do with a segment register. Matthias -- When You Find Out Your Normal Daily Lifestyle Is Called Quarantine From beebe at math.utah.edu Fri Jul 1 23:31:34 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 1 Jul 2022 07:31:34 -0600 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? Message-ID: >> I don't know the answer to Ctrl-D. The Unix command "man ascii" has the answer: Oct Dec Hex Char Oct Dec Hex Char ------------------------------------------------------------------------ 000 0 00 NUL '\0' 100 64 40 @ 001 1 01 SOH (start of heading) 101 65 41 A 002 2 02 STX (start of text) 102 66 42 B 003 3 03 ETX (end of text) 103 67 43 C 004 4 04 EOT (end of transmission) 104 68 44 D .... Ctrl-D signifies end of transmission. Some other O/Ses have used Ctrl-Z for that purpose, presumably because Z is the final letter of numerous alphabets. There is a good book about the history of character sets (pre-Unicode) in the book described at this URL: http://www.math.utah.edu/pub/tex/bib/master.html#Mackenzie:1980:CCS Bob Bemer (1920--2004), known as Dr. ASCII to some of us, was a key person in the standardization of character sets: https://en.wikipedia.org/wiki/Bob_Bemer https://en.wikipedia.org/wiki/ASCII ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From angus at fairhaven.za.net Fri Jul 1 23:36:44 2022 From: angus at fairhaven.za.net (Angus Robinson) Date: Fri, 1 Jul 2022 15:36:44 +0200 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: The joy's of problem solving (and actually problem solving). How to plugin Commodore 64's and zs spectrum to the TV. 30k dialup speeds...... Figuring out how to dialup to the internet through the banking system (maybe only in South Africa). Also figuring out how to get linux/*BSD to dialup to the internet. Coax cable networks (and the joy of figuring out that the reason why the PC is not connecting to the network is the coax cable T piece is missing. Kind Regards, Angus Robinson On Fri, Jul 1, 2022 at 3:20 PM Matthias Bruestle wrote: > I know something! > > On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: > > > o why CTRL/S and CTRL/Q are used for flow control in a shell command > > > line session > > > > > Also would be happy to know. > > https://en.wikipedia.org/wiki/Software_flow_control > > But I don't know the answer to Ctrl-D. :( And also the bus error > and maybe the segmentation fault if it hasn't to do with a segment > register. > > Matthias > > -- > When You Find Out Your Normal Daily Lifestyle Is Called Quarantine > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Fri Jul 1 23:58:22 2022 From: marc.donner at gmail.com (Marc Donner) Date: Fri, 1 Jul 2022 09:58:22 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: Configuring a uunet node Negotiating a connection with another uunet node (Back in the mid-1980s when I wanted to connect IBM Research connect to uunet we started with friends at DEC, since their node was pretty central. Their management intervened and told us that we could connect through decvax if we called our machine 'ibm-vax' ... I rejected that. We ended up connecting through another research lab nearby.) (Some time ago I played a MMORPG where you got to name your characters. I named one IHNP4.) ===== nygeek.net mindthegapdialogs.com/home On Fri, Jul 1, 2022 at 9:38 AM Angus Robinson wrote: > The joy's of problem solving (and actually problem solving). > How to plugin Commodore 64's and zs spectrum to the TV. > 30k dialup speeds...... Figuring out how to dialup to the internet through > the banking system (maybe only in South Africa). Also figuring out how to > get linux/*BSD to dialup to the internet. > Coax cable networks (and the joy of figuring out that the reason why the > PC is not connecting to the network is the coax cable T piece is missing. > Kind Regards, > Angus Robinson > > > On Fri, Jul 1, 2022 at 3:20 PM Matthias Bruestle > wrote: > >> I know something! >> >> On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: >> > > o why CTRL/S and CTRL/Q are used for flow control in a shell command >> > > line session >> > > >> > Also would be happy to know. >> >> https://en.wikipedia.org/wiki/Software_flow_control >> >> But I don't know the answer to Ctrl-D. :( And also the bus error >> and maybe the segmentation fault if it hasn't to do with a segment >> register. >> >> Matthias >> >> -- >> When You Find Out Your Normal Daily Lifestyle Is Called Quarantine >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sat Jul 2 00:02:41 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 1 Jul 2022 10:02:41 -0400 (EDT) Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022, Nelson H. F. Beebe wrote: > Ctrl-D signifies end of transmission. Some other O/Ses have used > Ctrl-Z for that purpose, presumably because Z is the final letter > of numerous alphabets. I thought only CP/M and its descendants did that. :o (Of course that includes DOS and Windows) -uso. From henry.r.bent at gmail.com Sat Jul 2 00:05:16 2022 From: henry.r.bent at gmail.com (Henry Bent) Date: Fri, 1 Jul 2022 10:05:16 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: On Fri, 1 Jul 2022 at 10:00, Marc Donner wrote: > > (Back in the mid-1980s when I wanted to connect IBM Research connect to > uunet we started with friends at DEC, since their node was pretty central. > Their management intervened and told us that we could connect through > decvax if we called our machine 'ibm-vax' ... I rejected that. We ended up > connecting through another research lab nearby.) > > Was IBM Research using a VAX as their point of contact with the outside world? What was it running? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Sat Jul 2 00:37:21 2022 From: marc.donner at gmail.com (Marc Donner) Date: Fri, 1 Jul 2022 10:37:21 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: We were not using a VAX. We were using a machine called the "RT-PC" and it ran BSD 4.3 or 4.2 (I disremember which). ===== nygeek.net mindthegapdialogs.com/home On Fri, Jul 1, 2022 at 10:05 AM Henry Bent wrote: > On Fri, 1 Jul 2022 at 10:00, Marc Donner wrote: > >> >> (Back in the mid-1980s when I wanted to connect IBM Research connect to >> uunet we started with friends at DEC, since their node was pretty central. >> Their management intervened and told us that we could connect through >> decvax if we called our machine 'ibm-vax' ... I rejected that. We ended up >> connecting through another research lab nearby.) >> >> > Was IBM Research using a VAX as their point of contact with the outside > world? What was it running? > > -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake1024 at gmail.com Sat Jul 2 00:41:50 2022 From: blake1024 at gmail.com (Blake McBride) Date: Fri, 1 Jul 2022 09:41:50 -0500 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: How about rewinding a paper tape dump using the rewind button on an empty mag tape spool? Blake On Fri, Jul 1, 2022 at 8:38 AM Angus Robinson wrote: > The joy's of problem solving (and actually problem solving). > How to plugin Commodore 64's and zs spectrum to the TV. > 30k dialup speeds...... Figuring out how to dialup to the internet through > the banking system (maybe only in South Africa). Also figuring out how to > get linux/*BSD to dialup to the internet. > Coax cable networks (and the joy of figuring out that the reason why the > PC is not connecting to the network is the coax cable T piece is missing. > Kind Regards, > Angus Robinson > > > On Fri, Jul 1, 2022 at 3:20 PM Matthias Bruestle > wrote: > >> I know something! >> >> On Fri, Jul 01, 2022 at 04:05:30PM +0300, Ori Idan wrote: >> > > o why CTRL/S and CTRL/Q are used for flow control in a shell command >> > > line session >> > > >> > Also would be happy to know. >> >> https://en.wikipedia.org/wiki/Software_flow_control >> >> But I don't know the answer to Ctrl-D. :( And also the bus error >> and maybe the segmentation fault if it hasn't to do with a segment >> register. >> >> Matthias >> >> -- >> When You Find Out Your Normal Daily Lifestyle Is Called Quarantine >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jul 2 01:01:50 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 1 Jul 2022 11:01:50 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: Message-ID: On Fri, Jul 1, 2022 at 10:03 AM Steve Nickolas wrote: > On Fri, 1 Jul 2022, Nelson H. F. Beebe wrote: > > > Ctrl-D signifies end of transmission. Some other O/Ses have used > > Ctrl-Z for that purpose, presumably because Z is the final letter > > of numerous alphabets. > > I thought only CP/M and its descendants did that. :o (Of course that > includes DOS and Windows) > Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS used ^Z as an EOF character in their text file format. The key is that they stored a block count, not a byte count in the META. Thus the last byte needs a marker to tell the OS to stop reading. [Early DEC OS's may have done that also, but I never looked at their FS formats]. Unix, of course, never made any distinction to the core OS WRT to 'type' [other than Regular/Directory/Special] and Ken stored a character count. So there was no need to signal EOF with a markered stored on disk.. A pipe or the shell on the other hand does have a need to signal the end of a transaction, and 'End of Transmission,' as Nelson points out, is the ASCII character reserved for the same. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Sat Jul 2 01:50:49 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 01 Jul 2022 15:50:49 +0000 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: (Steve Nickolas's message of "Fri, 1 Jul 2022 10:02:41 -0400 (EDT)") References: Message-ID: <7wv8sg6dd2.fsf@junk.nocrew.org> Steve Nickolas wrote: > Nelson H. F. Beebe wrote: >> Some other O/Ses have used Ctrl-Z for that purpose, presumably >> because Z is the final letter of numerous alphabets. > > I thought only CP/M and its descendants did that. Also TOPS-10. And proably other DEC operating systems, but I don't know much about those. I believe CP/M was inspired by many of the DEC traditions, From imp at bsdimp.com Sat Jul 2 02:20:51 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 1 Jul 2022 10:20:51 -0600 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <7wv8sg6dd2.fsf@junk.nocrew.org> References: <7wv8sg6dd2.fsf@junk.nocrew.org> Message-ID: On Fri, Jul 1, 2022 at 9:50 AM Lars Brinkhoff wrote: > Steve Nickolas wrote: > > Nelson H. F. Beebe wrote: > >> Some other O/Ses have used Ctrl-Z for that purpose, presumably > >> because Z is the final letter of numerous alphabets. > > > > I thought only CP/M and its descendants did that. > > Also TOPS-10. And proably other DEC operating systems, but I don't know > much about those. I believe CP/M was inspired by many of the DEC > traditions, > VMS, TOPS-20, RT-11 and RSTS/e did as well. Presumably RSX did too since DEC tried hard to keep RSX/VMS 'finger compatible' though I have no first hand experience with RSX to say for sure. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Jul 2 04:09:51 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 1 Jul 2022 14:09:51 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <7wv8sg6dd2.fsf@junk.nocrew.org> References: <7wv8sg6dd2.fsf@junk.nocrew.org> Message-ID: On Fri, Jul 1, 2022 at 11:50 AM Lars Brinkhoff wrote: > I believe CP/M was inspired by many of the DEC traditions, > If you do some Internet searching, there is an interview (IIRC from Byte Magazine in the late 1970s) where its author (Gary Kildall) straight out said he was trying to emulate RT-11 for an 8080. The funny thing to remember is that Kildall was a language guy, he wrote CP/M to demo his programming language PL/M for Intel. The demo ended up having more longevity than the tool he was trying to sell. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From skogtun at gmail.com Sat Jul 2 04:12:44 2022 From: skogtun at gmail.com (Harald Arnesen) Date: Fri, 1 Jul 2022 20:12:44 +0200 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <20220701004118.GA22338@tau1.ceti.pl> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <20220701004118.GA22338@tau1.ceti.pl> Message-ID: <67e0d22c-e70b-e9bb-4614-eb1426bf2bd0@gmail.com> Tomasz Rola [01/07/2022 02.41]: I recall reading about some movie, whose fans > were unable to understand why a protagonist took film (celuloid) to > some "red room". They suggested it was for making photos sharper. Except that we didn't use red light in our darkrooms at all, at least not from the 1970s and on. Panchromatic film, of course, needs to be developed in total darkness, so we used film tanks. Photographic paper was not sensitive to red light, but neither very sensitive to yellow-green or amber brown light, which we used when developing paper copies. -- Hilsen Harald Слава Україні! From clemc at ccc.com Sat Jul 2 04:18:03 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 1 Jul 2022 14:18:03 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <7wv8sg6dd2.fsf@junk.nocrew.org> Message-ID: On Fri, Jul 1, 2022 at 12:22 PM Warner Losh wrote: > since DEC tried hard to keep RSX/VMS 'finger compatible' though I have no > first hand > experience with RSX to say for sure. > Hrrmpt... maybe/sort of/after a fashion ... as a UNIX guy and someone that lived it (much less an ex-DECie), I famously argued with Cutler that he didn't! [It's a good beer story for some time in person, but not really for TUHS other than to say it happened, and it was a VMS *vs*. UNIX debate between DC and myself one night at the old Maui Kai in Littleton, MA with our old common boss rsg (*a.k.a.* Fossil) acting as the referee] ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sat Jul 2 04:45:31 2022 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 1 Jul 2022 14:45:31 -0400 (EDT) Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <7wv8sg6dd2.fsf@junk.nocrew.org> References: <7wv8sg6dd2.fsf@junk.nocrew.org> Message-ID: On Fri, 1 Jul 2022, Lars Brinkhoff wrote: > Steve Nickolas wrote: >> Nelson H. F. Beebe wrote: >>> Some other O/Ses have used Ctrl-Z for that purpose, presumably >>> because Z is the final letter of numerous alphabets. >> >> I thought only CP/M and its descendants did that. > > Also TOPS-10. And proably other DEC operating systems, but I don't know > much about those. I believe CP/M was inspired by many of the DEC > traditions, Yeah. As, independent of its position as a knockoff CP/M, was the original MS-DOS (2.0 brought in a few things from Xenix). -uso. From phil at ultimate.com Sat Jul 2 05:22:24 2022 From: phil at ultimate.com (Phil Budne) Date: Fri, 01 Jul 2022 15:22:24 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: Message-ID: <202207011922.261JMOwq092697@ultimate.com> Early use of ASCII control characters was ALL over the map. I remember typing in a BASIC program to approximate PI during a college tour in the late 70's, and whatever system they had (maybe Univac?? there was an unplugged RCA Spectra in the hallway) required typing Control C (ASCII ETX) instead of RETurn on the teletype. *THAT* was a mind-f*ck! Clem Cole wrote: > Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS > used ^Z as an EOF character in their text file format. The key is that > they stored a block count, not a byte count in the META. Thus the last > byte needs a marker to tell the OS to stop reading. [Early DEC OS's may > have done that also, but I never looked at their FS formats]. I TEND to think of the DEC ASCII traditions as coming out of the PDP-6 Monitor (later TOPS-10), which probably dates to c. 1964, and modern Unix/Linux systems are almost fully infected with DEC conventions (DELETE, CTRL/U, CTRL/C vs @/#/DELETE for example), except for ^M and ^Z. The earliest version I have on hand is version 3.19, which includes PDP-10 (KA10) support (c.1968). The scheduler (CLKCSS) has Tom Hastings name on it, dated 6 SEP 67. Tom wrote the MIT CTSS (timesharing on IBM 709/7090) scheduler, and the DEC T/S system mirrors CTSS in many ways (project/programmer numbers). CTSS used ASCII, and it would be interesting to know what conventions were used there!! On topic: Ken might know. @/# seem to have been used on Multics. The full duplex terminal code (SCNSRF) with Robert Clemmens name on it, dated "27 NOV 68" has the following conventions: Use of "^Q" as a convention for control characters. CR ^M return to column zero (used alone in files for overstrike) LF ^J line feed: line terminator HT ^I horizontal tab VT ^K vertical tab (n line feeds on a TTY) FF ^L form feed XON ^Q start TTY paper tape reader XOFF ^S sent by TTY PTR on end of tape? ^U clear input line ^Z EOF 0177 DEL delete a character 033,0175,0176 "ALTMODE" -- used in DDT (& TECO), echoes as "$" I don't have a set of Commonly Used System Programs (CUSPs) from that era, so I can't see how they handle ^Z if they see it in a file. I don't remember seeing ^Z in disk files on TOPS-10. A quick look at the 3.19 code (I rescued it from six DECtapes while at DEC; three each for full & half duplex versions of the code!) and didn't spot the on disk/DECtape metadata formats, but I suspect they were just block counts. There ARE files I've pulled off of tape with embedded NULs, so I suspect code was written to ignore NULs whereever they appeared. "Dump Mode" I/O, where you passed IOWDs -COUNT and WORD_POINTER in halfwords, rather than transferring character at a time into a buffer, was a way to speed up disk I/O, which would easily result in multiple embedded NULs. My recall is that we thought of disk files as made up of blocks, and not characters. MIT AI's Incompatible Timesharing System (ITS), a dig at CTSS (and DEC as well?) used ^C instead of ^Z for EOF, appearing (in triplicate?) inside of (older) files. And ^Z stop a (sub)job and drop into DDT (the debugger *AND* command interpreter), which could be examined, continued, or killed (ALT CTRL/X). I've always assumed BSD used ^Z as the suspend character for this reason. TOPS-20 (and perhaps later day TOPS-10) had file metadata indicating file byte counts, and byte sizes (1-36 bits), but TOPS-20 ALSO only allocated file storage on a page basis (512 36-bit words instead of the TOPS-10 256W block size). The PDP-7 unix inode stores a word count, rather than a byte count, and ISTR programs ignore NULs for the same reason. > Unix, of course, never made any distinction to the core OS WRT to 'type' > [other than Regular/Directory/Special] and Ken stored a character count. > So there was no need to signal EOF with a markered stored on disk.. > > A pipe or the shell on the other hand does have a need to signal the end of > a transaction, and 'End of Transmission,' as Nelson points out, is the > ASCII character reserved for the same. I don't know the rationale for DEC's use of ^Z for EOF, but as I pointed out above, use of ASCII control characters wasn't widely standardized in the 70's (is it today?) To pull the thread back to the list topic 1. Remember which of @ and # deletes a single character. 2. Fix a filesystem without fsck. 3a. Buy a controller card to be able to use a disk 3b. Write a driver for a third party controller. 4. Edit a driver and recompile the kernel to change partition sizes. 5. Use dd to convert a mainframe tape to variable line length ASCII. 6. Wonder whether something with a serial port is a DTE or a DCE. 7. Figure out the serial port settings for a terminal/modem: data bits, parity, stop bits. 8. Adjust jumpers on a peripheral 9. Insert or remove wires for IRQ bus continuity Non-UNIX related: Punch job control cards..... Burst fanfold paper by flicking their finger, to get your printout. Spread out fanfold paper on the floor to get a "big view" ....... From clemc at ccc.com Sat Jul 2 05:53:32 2022 From: clemc at ccc.com (Clem Cole) Date: Fri, 1 Jul 2022 15:53:32 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <202207011922.261JMOwq092697@ultimate.com> References: <202207011922.261JMOwq092697@ultimate.com> Message-ID: Phil nice list. On Fri, Jul 1, 2022 at 3:23 PM Phil Budne wrote: > I've always assumed BSD used ^Z as the suspend character for this reason. > Yes, Kulp's Job control for the PDP-11 was based on his ITS experience. Joy picked it up from Kulp. The other big gift to UNIX from ITS was Eric Shienbrood's more(1) command [discussed elsewhere]. This brings us back to the topic -- the need for more(1) as either built-in like ITS or as command [UNIX] is lost with today's infinite scroll buffers. > To pull the thread back to the list topic > > 2. Fix a filesystem without fsck. > Much less, what was fsck(1) original name at CMU ;-) or why tjk wrote the first version. 4. Edit a driver and recompile the kernel to change partition sizes. > Doing the same with adb(1) on the kernel binary as well as understanding disk geometry and calculating the HEAD/CYL/SEC to block numbers properly. > 6. Wonder whether something with a serial port is a DTE or a DCE. > How about knowing what DTE and DCE mean in the first place. Along with why CTS/RTS (HW) flow control was really needed at high speed. Why the UNIX community tended to migrate to aftermarket DH11, instead of DZ-11s - particularly for UUCP > 8. Adjust jumpers on a peripheral > How about having the proper jumper sizes. Or realizing the DIP switches were not actually toggling properly so the address was wrong. > 9. Insert or remove wires for IRQ bus continuity > Know what a BUS GRANT card does. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at quintile.net Sat Jul 2 09:38:11 2022 From: steve at quintile.net (Steve Simon) Date: Sat, 2 Jul 2022 00:38:11 +0100 Subject: [TUHS] kernel debugging in analogue Message-ID: i remember a fellow student debugging an lsi11 kernel using a form of analogue vectorscope. i think it had a pair of DACs attached to the upper bits of the address bus. it generated a 2d pattern which you could recognise as particular code - interrupts are here, userspace is there, etc. the brightness of the spot indicated the time spent, so you got a bit of profiling too - and deadlocks became obvious. anyone remember these, what where they called? i think it was an HP or Tek product. -Steve From aek at bitsavers.org Sat Jul 2 11:52:52 2022 From: aek at bitsavers.org (Al Kossow) Date: Fri, 1 Jul 2022 18:52:52 -0700 Subject: [TUHS] kernel debugging in analogue In-Reply-To: References: Message-ID: <3a2bf170-9948-8e64-5908-dd78cc8b666e@bitsavers.org> On 7/1/22 4:38 PM, Steve Simon wrote: > anyone remember these, what where they called? i think it was an HP or Tek product. both tek and hp had products that would show you vectors between points in an 8x8 grid representing 64k locations i'm having trouble thinking of the HP part number, it was in the 160x series. it appears on the cover of an hp journal in the mid-70s From aek at bitsavers.org Sat Jul 2 11:57:15 2022 From: aek at bitsavers.org (Al Kossow) Date: Fri, 1 Jul 2022 18:57:15 -0700 Subject: [TUHS] kernel debugging in analogue In-Reply-To: <3a2bf170-9948-8e64-5908-dd78cc8b666e@bitsavers.org> References: <3a2bf170-9948-8e64-5908-dd78cc8b666e@bitsavers.org> Message-ID: On 7/1/22 6:52 PM, Al Kossow wrote: > On 7/1/22 4:38 PM, Steve Simon wrote: > >> anyone remember these, what where they called? i think it was an HP or Tek product. > > both tek and hp had products that would show you vectors between points in an 8x8 grid > representing 64k locations > > i'm having trouble thinking of the HP part number, it was in the 160x series. it appears > on the cover of an hp journal in the mid-70s > > https://archive.org/details/hp_journal_1975-08/page/n3/mode/2up From tuhs at tuhs.org Sat Jul 2 12:45:23 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Fri, 1 Jul 2022 20:45:23 -0600 Subject: [TUHS] kernel debugging in analogue In-Reply-To: <3a2bf170-9948-8e64-5908-dd78cc8b666e@bitsavers.org> References: <3a2bf170-9948-8e64-5908-dd78cc8b666e@bitsavers.org> Message-ID: <2495953f-4097-0c94-05d9-c0c4a73410d8@spamtrap.tnetconsulting.net> On 7/1/22 7:52 PM, Al Kossow wrote: > both tek and hp had products that would show you vectors between > points in an 8x8 grid representing 64k locations > > i'm having trouble thinking of the HP part number, it was in the 160x > series. it appears on the cover of an hp journal in the mid-70s Now I want to nudge / pester Curious Mark to see if he has the equipment to demonstrate this on one of his videos. }:-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From aek at bitsavers.org Sat Jul 2 12:50:14 2022 From: aek at bitsavers.org (Al Kossow) Date: Fri, 1 Jul 2022 19:50:14 -0700 Subject: [TUHS] kernel debugging in analogue In-Reply-To: <2495953f-4097-0c94-05d9-c0c4a73410d8@spamtrap.tnetconsulting.net> References: <3a2bf170-9948-8e64-5908-dd78cc8b666e@bitsavers.org> <2495953f-4097-0c94-05d9-c0c4a73410d8@spamtrap.tnetconsulting.net> Message-ID: On 7/1/22 7:45 PM, Grant Taylor via TUHS wrote: > On 7/1/22 7:52 PM, Al Kossow wrote: >> both tek and hp had products that would show you vectors between points in an 8x8 grid representing 64k locations >> >> i'm having trouble thinking of the HP part number, it was in the 160x series. it appears on the cover of an hp journal in the mid-70s > > Now I want to nudge / pester Curious Mark to see if he has the equipment to demonstrate this on one of his videos.  }:-) > > > I suppose I could loan my 1607 to him. For some reason, I guy did a ewe toob video and never used the mode. https://www.youtube.com/watch?v=SiBozvGl5_I From tuhs at tuhs.org Sat Jul 2 12:51:53 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Fri, 1 Jul 2022 20:51:53 -0600 Subject: [TUHS] Research Datakit notes In-Reply-To: <1420AC1D-8AD7-43C7-8F8B-22E1708846EF@planet.nl> References: <2803DC51-6CBC-4257-B40C-8A559C27CAE3@planet.nl> <20220625230939.GG19404@mcvoy.com> <1420AC1D-8AD7-43C7-8F8B-22E1708846EF@planet.nl> Message-ID: <01b377bf-94e6-6ad4-6a84-ab430c780e95@spamtrap.tnetconsulting.net> On 6/25/22 7:17 PM, Paul Ruizendaal wrote: > In his video (https://www.youtube.com/watch?v=ojRtJ1U6Qzw), Sandy > explains why he became dissatisfied with Spider and the main reason > was that doing switching/routing on a mini computer was just plain > inefficient as compared to a telephone switch (at 37:06). This was > 1972. The result was a new design, Datakit, that could route/switch > packets at high speed and in parallel. I didn't realize, or even fathom that something preceded ATM. Now it seems like Spider preceded Datakit which preceded ATM. Very interesting. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From lm at mcvoy.com Sat Jul 2 12:57:07 2022 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 1 Jul 2022 19:57:07 -0700 Subject: [TUHS] Research Datakit notes In-Reply-To: <01b377bf-94e6-6ad4-6a84-ab430c780e95@spamtrap.tnetconsulting.net> References: <2803DC51-6CBC-4257-B40C-8A559C27CAE3@planet.nl> <20220625230939.GG19404@mcvoy.com> <1420AC1D-8AD7-43C7-8F8B-22E1708846EF@planet.nl> <01b377bf-94e6-6ad4-6a84-ab430c780e95@spamtrap.tnetconsulting.net> Message-ID: <20220702025707.GF11191@mcvoy.com> On Fri, Jul 01, 2022 at 08:51:53PM -0600, Grant Taylor via TUHS wrote: > On 6/25/22 7:17 PM, Paul Ruizendaal wrote: > >In his video (https://www.youtube.com/watch?v=ojRtJ1U6Qzw), Sandy explains > >why he became dissatisfied with Spider and the main reason was that doing > >switching/routing on a mini computer was just plain inefficient as > >compared to a telephone switch (at 37:06). This was 1972. The result was a > >new design, Datakit, that could route/switch packets at high speed and in > >parallel. > > I didn't realize, or even fathom that something preceded ATM. > > Now it seems like Spider preceded Datakit which preceded ATM. Very > interesting. They were Bell Labs, funded by the phone company. It makes sense that they would look at networking through the phone company lens. From tuhs at tuhs.org Sat Jul 2 16:20:18 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sat, 2 Jul 2022 00:20:18 -0600 Subject: [TUHS] kernel debugging in analogue In-Reply-To: References: <3a2bf170-9948-8e64-5908-dd78cc8b666e@bitsavers.org> <2495953f-4097-0c94-05d9-c0c4a73410d8@spamtrap.tnetconsulting.net> Message-ID: On 7/1/22 8:50 PM, Al Kossow wrote: > I suppose I could loan my 1607 to him. :-) > For some reason, I guy did a ewe toob video and never used the mode. > > https://www.youtube.com/watch?v=SiBozvGl5_I I think that I had seen part of this video. I have now seen all of it. Thank you for sharing the link. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From pnr at planet.nl Sat Jul 2 20:10:46 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 2 Jul 2022 12:10:46 +0200 Subject: [TUHS] Compare, contrast and a "Unixy" networking API Message-ID: <1962DE84-726F-498E-853E-6E4A768223E1@planet.nl> Following an insightful post by Norman Wilson (https://minnie.tuhs.org/pipermail/tuhs/2022-June/025929.html) and re-reading a few old papers (https://minnie.tuhs.org/pipermail/tuhs/2022-June/026028.html), I was thinking about similarities and differences between the various Unix networking approaches in the 1975-1985 era and came up with the following observations: - First something obvious: early Unix was organised around two classes of device: character based and block based. Arguably, it is maybe better to think of these classes conceptually as “transient” and “memoizing”. A difference between the two would be wether or not it makes conceptual sense to do a seek operation on them and pipes and networks are in the transient class. - On the implementation side, this relates two early kernel data structures: clists and disk buffers. Clists were designed for slow, low volume traffic and most early Unix network code creates a third kind: the mbufs of Arpanet Unix, BBN-TCP Unix and BSD, the packets of Chesson's V7 packet driver, Ritchie's streams etc. These are all the same when seen from afar: higher capacity replacements for clists. - Typically devices are accessed via a filter. At an abstract level, there is not much difference between selecting a line discipline, pushing a stream filter or selecting a socket type. At the extreme end one could argue that pushing a TCP stack on a network device is conceptually the same as mounting a file system on a disk device. Arguably, both these operations could be performed through a generalised mount() call. - Another implementation point is the organisation of the code. Is the network code in the kernel, or in user land? Conceptually connection management is different from stream management when connected (e.g. CMC and URP with Datakit, or RTP and BSP in Xerox Pups). In the BSD lineage all is in the kernel, and in the Research lineage connection management is done in a user space daemon. Arpanet Unix (originally based on V5) had a curious solution: the network code was organised in a single process, but with code both in kernel mode and in user mode. The user code would make a special system call, and the kernel code would interact with the IMP driver, manage buffers and deliver packets. Only when a state-changing event happened, it would return to user mode and the user code would handle connection management (followed by a new call into kernel mode). Interestingly, this approach mostly hid the IMP connection, and this carried through to the BSD’s where the network devices were also buried in the stack. Arpanet Unix made this choice to conserve kernel address space and to minimize the amount of original kernel code that had to be touched. - Early Unix has three ways to obtain a file descriptor: open, creat and pipe. Later also fifo. In this context adding more (like socket) does not seem like a mortal sin. Arguably, all could be rolled into one, with open() handling all cases. Some of this was done in 4.2BSD. It is possible to combine socket() & friends into open() with additional flags, much as was done in Arpanet Unix and BBN-TCP Unix. - Network connections have different meta data than disk files, and in sockets this handled via specialised calls. This seems a missed opportunity for unified mechanisms. The API used in BBN-TCP handles most of this via ioctl. However, one could (cheekily!) argue that V7 unix has a somewhat byzantine meta data API, with the functionality split over seek, ioctl, fcntl, stat and fstat. These could all be handled in a generalised ioctl. Conceptually, this could also be replaced by using read/write on a meta data file descriptor, which could for example be the regular descriptor with the high bit set. But this, of course, did never exist. - A pain point in Arpanet Unix was that a listening connection (i.e. a server endpoint) would block until a client arrived and then turn into the connection with the client. This would fork out into a service process and the main server process would open a new listening socket for the next client. In sockets this was improved into a rendez-vous type server connection that would spawn individual client connections via ‘accept’. The V8/V9 IPC library took a similar approach, but also developed the mechanism into a generalized way to (i) create rendez-vous points and (ii) ship descriptors across local connections. - The strict blocking nature of IO in early Unix was another pain point for writing early network code. The first solution to that were BBN’s await and capac primitives, which worked around the blocking nature. With SysIII, non-blocking file access appeared and 4.1a BSD saw the arrival of 'select’. Together these offer a much more convenient way to deal with multiple tty or network streams in a single threaded process (although it did modify some of the early Unix philosophy). Non-blocking IO and select() also appeared in the Research lineage with 8th edition. - The file system switch (FSS) arrived around 1983, during the gestation of 8th edition. This was just 1 or 2 years after the network interfaces for BSD and Datakit got their basic shape. Had the FSS been part of V7 (as it well could have been), probably the networking designs would have been a bit different, using virtual directories for networking connections. The ‘namei hack’ in MIT’s CHAOS network code already points in this direction. A similar approach could have been extended to named pipes (arriving in SysIII), where the fifo endpoint could have been set up through creating a file in a virtual directory, and making connections through a regular open of such a virtual file (and 9th edition appears to implement this.) oOo To me it seems that the V1-V7 abstractions, the system call API, etc. were created with the experience of CTSS, Multics and others fresh in mind. The issues were understood and it combined the best of the ideas that came before. When it came to networking, Unix did not have this advantage and was necessarily trying to ride a bike whilst inventing it. Maybe in a different time line it would have been possible to pick the best ideas in this area as well and combine these into a coherent framework. I concur with the observation that this list should be about discussion of what once was and only tangentially about what might have been, so it is only after considerable hesitation that I write the below. Looking at the compare and contrast above (and having been tainted by what became dominant in later decades), I would say that the most “Unixy” way to add networking to V7/SysIII era Unix would have been something like: - Network access via open/read/write/close, in the style of BBN-TCP - Network namespace exposed via a virtual file system, a bit like V9 - Meta data via a generalised ioctl, or via read/write on a meta data descriptor - Connection rendez-vous via a generalised descriptor shipping mechanism, in the style of V8/V9 - Availability of non-blocking access, together with a waiting primitive (select/poll/etc.), in the style of BSD - Primary network device visible as any other device, network protocol mounted similar to a file system. - Both connection management and stream management located in kernel code, in the style of BSD From douglas.mcilroy at dartmouth.edu Sun Jul 3 02:32:39 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 2 Jul 2022 12:32:39 -0400 Subject: [TUHS] Typesetting Mathematics by Kernighan and Cherry, retypeset Message-ID: > I understand UNIX v7 is under this BSD-style license by Caldera Inc. > https://www.tuhs.org/Archive/Caldera-license.pdf The eqn document by Kernighan and Cherry also appears in the v10 manual, copyright by AT&T and published as a trade book. Wouldn't the recent release of v10 also pertain to the manual? Doug From clemc at ccc.com Sun Jul 3 02:51:16 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 2 Jul 2022 12:51:16 -0400 Subject: [TUHS] Typesetting Mathematics by Kernighan and Cherry, retypeset In-Reply-To: References: Message-ID: If V10 was formally released, then yes - I would make that argument and feel free to say it to the judge. That said, did Caldera (and/or Nokia) officially release it or are they just 'not noticing' that it is available in the wild? I was under the impression that the only thing official is through V7. But all the other versions have 'leaked' and are widely available, and whoever owns that IP at this point, is not pursuing protection. I am aware that Caldera ended up with rights of 'UNIX' - certainly through SVR5 -- and they released V1-V7 and 32V under their license (pointed too in the earlier message). However, I am ownsnot aware of who formally owns V8-V10 (I would assume Caldera also but that IP might have stayed with Lucent then Nokia as part of that BTL IP transfer]. Also, did Nokia 'formally' release Plan9 or Inferno -- is there a document like the Caldera one? ᐧ On Sat, Jul 2, 2022 at 12:34 PM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > > I understand UNIX v7 is under this BSD-style license by Caldera Inc. > > https://www.tuhs.org/Archive/Caldera-license.pdf > > The eqn document by Kernighan and Cherry also appears in the v10 > manual, copyright by AT&T and published as a trade book. Wouldn't the > recent release of v10 also pertain to the manual? > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jul 3 02:59:05 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 2 Jul 2022 10:59:05 -0600 Subject: [TUHS] Typesetting Mathematics by Kernighan and Cherry, retypeset In-Reply-To: References: Message-ID: On Sat, Jul 2, 2022 at 10:52 AM Clem Cole wrote: > If V10 was formally released, then yes - I would make that argument and > feel free to say it to the judge. > > That said, did Caldera (and/or Nokia) officially release it or are they > just 'not noticing' that it is available in the wild? > Alcatel-Lucent gave an official grant to V8, V9 and V10. See https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/statement_regarding_Unix_3-7-17.pdf which reads: Statement Regarding Research Unix Editions 8, 9, and 10 Alcatel-Lucent USA Inc. (“ALU-USA”), on behalf of itself and Nokia Bell Laboratories agrees, to the extent of its ability to do so, that it will not assert its copyright rights with respect to any non-commercial copying, distribution, performance, display or creation of derivative works of Research Unix® Editions 8, 9, and 10. The foregoing does not (i) transfer ownership of, or relinquish any, intellectual property rights (including patent rights) of Nokia Corporation, ALU-USA or any of their affiliates, (ii) grant a license to any patent, patent application, or trademark of Nokia Corporation, ALU-USA. or any of their affiliates, (iii) grant any third-party rights or licenses, or (iv) grant any rights for commercial purposes. Neither ALU-USA. nor Nokia Bell Laboratories will furnish or provided support for Research Unix Editions 8, 9, and 10, and make no warranties or representations hereunder, including but not limited to any warranty or representation that Research Unix Editions 8, 9, and 10 does not infringe any third party intellectual property rights or that Research Unix Editions 8, 9, and 10 is fit for any particular purpose. So not exactly the sweeping "We own this and you can do whatever w/o restriction" license one would like, but still much better than "in the wild and unchallenged"... > I was under the impression that the only thing official is through V7. > But all the other versions have 'leaked' and are widely available, and > whoever owns that IP at this point, is not pursuing protection. I am > aware that Caldera ended up with rights of 'UNIX' - certainly through SVR5 > -- and they released V1-V7 and 32V under their license (pointed too in the > earlier message). However, I am ownsnot aware of who formally owns V8-V10 > (I would assume Caldera also but that IP might have stayed with Lucent then > Nokia as part of that BTL IP transfer]. Also, did Nokia 'formally' release > Plan9 or Inferno -- is there a document like the Caldera one? > ᐧ > Caldera did those about 10 years prior to V8-V10 being available. https://9p.io/plan9/about.html has details on plan9, but the latest versions are available under the MIT license. Warner > On Sat, Jul 2, 2022 at 12:34 PM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> > I understand UNIX v7 is under this BSD-style license by Caldera Inc. >> > https://www.tuhs.org/Archive/Caldera-license.pdf >> >> The eqn document by Kernighan and Cherry also appears in the v10 >> manual, copyright by AT&T and published as a trade book. Wouldn't the >> recent release of v10 also pertain to the manual? >> >> Doug >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Jul 3 03:15:31 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 2 Jul 2022 12:15:31 -0500 Subject: [TUHS] Typesetting Mathematics by Kernighan and Cherry, retypeset In-Reply-To: References: Message-ID: <20220702171531.desvlkzkedrpq3fx@illithid> (For those on the TUHS list wondering about context, here it is. I "ported" the document in the Subject line to groff and re-typeset it, discovering some spacing nits in groff and, apparently, a bug in AT&T troff as well--one equation[1] in the sources not appearing in published versions has risen from the grave when rendered with groff. https://lists.gnu.org/archive/html/groff/2022-07/msg00002.html ) > On Sat, Jul 2, 2022 at 12:34 PM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > [Ingo Schwarze wrote:] > > > I understand UNIX v7 is under this BSD-style license by Caldera > > > Inc. https://www.tuhs.org/Archive/Caldera-license.pdf > > > > The eqn document by Kernighan and Cherry also appears in the v10 > > manual, copyright by AT&T and published as a trade book. Wouldn't > > the recent release of v10 also pertain to the manual? At 2022-07-02T12:51:16-0400, Clem Cole wrote: > If V10 was formally released, then yes - I would make that argument > and feel free to say it to the judge. > > That said, did Caldera (and/or Nokia) officially release it or are > they just 'not noticing' that it is available in the wild? > > I was under the impression that the only thing official is through V7. > But all the other versions have 'leaked' and are widely available, and > whoever owns that IP at this point, is not pursuing protection. I am > aware that Caldera ended up with rights of 'UNIX' - certainly through > SVR5 -- and they released V1-V7 and 32V under their license (pointed > too in the earlier message). However, I am ownsnot aware of who > formally owns V8-V10 (I would assume Caldera also but that IP might > have stayed with Lucent then Nokia as part of that BTL IP transfer]. > Also, did Nokia 'formally' release Plan9 or Inferno -- is there a > document like the Caldera one? I believe even early releases of Plan 9 and Infero are both now fully liberated, though the former[2] took much longer than the latter[3]. I'd offer my thanks to anyone who is keeping the Plan 9 and Inferno flames lit. Regards, Branden [1] the last one in section 8, "e sup {i pi sup {rho +1}}" [2] https://marc.info/?l=9fans&m=161650489113326 [3] https://www.vitanuova.com/inferno/licence.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From clemc at ccc.com Sun Jul 3 04:15:04 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 2 Jul 2022 14:15:04 -0400 Subject: [TUHS] Thoughts on Licenses Message-ID: As part of some of simh work, I've been immersed in some licensing discussions. Thanks for the V8-10, Plan-9 and Inferno notes - they are relevant. Anyway, WRT to TUHS, I'm thinking that at least in the case of the Unix style bits, I propose a small change to Waren's top-level directory. Add a new dir called something like 'Legal Docs' or 'Copyrights+Licenses'. Then move the Caldera document and Warren's current note into that area. Then add copies of anything we can collect like the Dan Cross's V8-10, anything WRT to Plan9/Inferno or anything we from the UNIX world - such as something Sun, DEC or HP or like might have added. Maybe add a subdirectory with the AT&T/USL case details. And maybe add a sub-directory with known FOSS licenses used by the UNIX community and add a copy of the 3-clause BSD and maybe even the two GPLs. Then update the README in the current top-level dir. Adding to the contents something like "*the IP contained on this website is covered by different licenses depending on the specific IP. Copies of these can be found with the source code itself, but have also been all collected together in the top-level directory: ...*." I think these all have both historical values, as well as practical values. As I said, I was not sure myself and I think other would be less ignorant if they could find it all easily. In the case of the practical, a for instance, in an email with some lawyers last week, I had pointed them at the Caldera document. I'ld have loved to have been able to say look in this directory. The Caldera and later Nokia Licenses are what we are considering as examples. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Sun Jul 3 05:07:55 2022 From: marc.donner at gmail.com (Marc Donner) Date: Sat, 2 Jul 2022 15:07:55 -0400 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: Message-ID: I would call that top level directory "metadata" ... the licensing stuff is quite relevant to the owner and operator of the system, but not directly relevant to any of its actual content or function. ===== nygeek.net mindthegapdialogs.com/home On Sat, Jul 2, 2022 at 2:17 PM Clem Cole wrote: > As part of some of simh work, I've been immersed in some licensing > discussions. Thanks for the V8-10, Plan-9 and Inferno notes - they are > relevant. > > Anyway, WRT to TUHS, I'm thinking that at least in the case of the Unix > style bits, I propose a small change to Waren's top-level directory. Add > a new dir called something like 'Legal Docs' or 'Copyrights+Licenses'. > Then move the Caldera document and Warren's current note into that area. > Then add copies of anything we can collect like the Dan Cross's V8-10, > anything WRT to Plan9/Inferno or anything we from the UNIX world - such as > something Sun, DEC or HP or like might have added. Maybe add a > subdirectory with the AT&T/USL case details. And maybe add a > sub-directory with known FOSS licenses used by the UNIX community and add a > copy of the 3-clause BSD and maybe even the two GPLs. > > Then update the README in the current top-level dir. Adding to the > contents something like "*the IP contained on this website is covered by > different licenses depending on the specific IP. Copies of these can be > found with the source code itself, but have also been all collected > together in the top-level directory: ...*." > > I think these all have both historical values, as well as practical > values. As I said, I was not sure myself and I think other would be less > ignorant if they could find it all easily. In the case of the practical, > a for instance, in an email with some lawyers last week, I had pointed them > at the Caldera document. I'ld have loved to have been able to say look in > this directory. The Caldera and later Nokia Licenses are what we are > considering as examples. > > Thoughts? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djc at bitb.lt Sun Jul 3 05:09:23 2022 From: djc at bitb.lt (David du Colombier) Date: Sat, 02 Jul 2022 21:09:23 +0200 Subject: [TUHS] Typesetting Mathematics by Kernighan and Cherry, retypeset In-Reply-To: References: Message-ID: <658ee96e-80a7-4598-ad6a-570171c9ebf1@www.fastmail.com> > https://9p.io/plan9/about.html has details on plan9, but the latest > versions are available under the MIT license. All former and current Plan 9 releases are available under the MIT license, since March 2021. http://p9f.org/dl/index.html https://github.com/plan9foundation/plan9 -- David du Colombier From leah at vuxu.org Sun Jul 3 05:36:27 2022 From: leah at vuxu.org (Leah Neukirchen) Date: Sat, 02 Jul 2022 21:36:27 +0200 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: (Clem Cole's message of "Fri, 1 Jul 2022 11:01:50 -0400") References: Message-ID: <874jzz8fyc.fsf@vuxu.org> Clem Cole writes: > On Fri, Jul 1, 2022 at 10:03 AM Steve Nickolas wrote: > >> On Fri, 1 Jul 2022, Nelson H. F. Beebe wrote: >> >> > Ctrl-D signifies end of transmission. Some other O/Ses have used >> > Ctrl-Z for that purpose, presumably because Z is the final letter >> > of numerous alphabets. >> >> I thought only CP/M and its descendants did that. :o (Of course that >> includes DOS and Windows) >> > Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS > used ^Z as an EOF character in their text file format. The key is that > they stored a block count, not a byte count in the META. Thus the last > byte needs a marker to tell the OS to stop reading. [Early DEC OS's may > have done that also, but I never looked at their FS formats]. > > Unix, of course, never made any distinction to the core OS WRT to 'type' > [other than Regular/Directory/Special] and Ken stored a character count. > So there was no need to signal EOF with a markered stored on disk.. > > A pipe or the shell on the other hand does have a need to signal the end of > a transaction, and 'End of Transmission,' as Nelson points out, is the > ASCII character reserved for the same. But that's a common misconception and not how Ctrl-D works on Unix. Ctrl-D is part of the terminal discipline and causes an immediate stop of the current read(2) syscall. If nothing is in the input buffer, this causes a zero-length read which is detected as end of file. You can verify this e.g. by typing "foo" into cat(1). It will print "foo", but not exit. Another Ctrl-D will then quit cat(1) due to the empty read. In no case, a ASCII Ctrl-D 0x4 is sent over a pipe or to a shell. (Over the pty, yes.) cheers, -- Leah Neukirchen https://leahneukirchen.org/ From norman at oclsc.org Sun Jul 3 05:45:38 2022 From: norman at oclsc.org (Norman Wilson) Date: Sat, 2 Jul 2022 15:45:38 -0400 (EDT) Subject: [TUHS] Typesetting Mathematics by Kernighan and Cherry, retypeset Message-ID: Warner Losh: Alcatel-Lucent gave an official grant to V8, V9 and V10. See https://www.tuhs.org/Archive/Distributions/Research/Dan_Cross_v8/statement_regarding_Unix_3-7-17.pdf ==== Quite so. I believe this was announced on a mailing list called TUHS. Those here who are interested in such things might want to subscribe; I have and find it quite useful and interesting, with occasional disappointment. Norman Wilson Toronto ON (typing this on a train in Texas) From clemc at ccc.com Sun Jul 3 05:50:18 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 2 Jul 2022 15:50:18 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <874jzz8fyc.fsf@vuxu.org> References: <874jzz8fyc.fsf@vuxu.org> Message-ID: On Sat, Jul 2, 2022 at 3:36 PM Leah Neukirchen wrote: > But that's a common misconception and not how Ctrl-D works on Unix. > Point taken and my bad on my explanation. Absolutely, any characters can be stored or read/written in a file. As you explained, the *interpretation* of the character is done elsewhere and my words could have been misunderstood by my lack of precision. In fact, tools like uucico and IP over serial all required a full 8-bit path without any interpretation through the terminal handler and would have needed other tricks like escaping to have been made to work otherwise. But what I did say was true. The question was why ^D and I pointed out that the ASCII EOT character was picked for the characters for the terminal handler to use when it needs to make the distinction of when this is the end of the input sequence - i.e. EOT. Moreover, we were discussing a number of chars being processed by the terminal handler such a # @ vs. ^H ^U ^C or SW flow control ^S/^Q, Job Control ^Z/^T and the like. mei cupla for not being more clear. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jul 3 06:57:31 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 2 Jul 2022 14:57:31 -0600 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: Message-ID: Before we go inventing our own thing, let's just add spdx tags and metadata..... there already is a standard for this. Warner On Sat, Jul 2, 2022, 1:09 PM Marc Donner wrote: > I would call that top level directory "metadata" ... the licensing stuff > is quite relevant to the owner and operator of the system, but not directly > relevant to any of its actual content or function. > ===== > nygeek.net > mindthegapdialogs.com/home > > > On Sat, Jul 2, 2022 at 2:17 PM Clem Cole wrote: > >> As part of some of simh work, I've been immersed in some licensing >> discussions. Thanks for the V8-10, Plan-9 and Inferno notes - they are >> relevant. >> >> Anyway, WRT to TUHS, I'm thinking that at least in the case of the Unix >> style bits, I propose a small change to Waren's top-level directory. Add >> a new dir called something like 'Legal Docs' or 'Copyrights+Licenses'. >> Then move the Caldera document and Warren's current note into that area. >> Then add copies of anything we can collect like the Dan Cross's V8-10, >> anything WRT to Plan9/Inferno or anything we from the UNIX world - such as >> something Sun, DEC or HP or like might have added. Maybe add a >> subdirectory with the AT&T/USL case details. And maybe add a >> sub-directory with known FOSS licenses used by the UNIX community and add a >> copy of the 3-clause BSD and maybe even the two GPLs. >> >> Then update the README in the current top-level dir. Adding to the >> contents something like "*the IP contained on this website is covered by >> different licenses depending on the specific IP. Copies of these can be >> found with the source code itself, but have also been all collected >> together in the top-level directory: ...*." >> >> I think these all have both historical values, as well as practical >> values. As I said, I was not sure myself and I think other would be less >> ignorant if they could find it all easily. In the case of the practical, >> a for instance, in an email with some lawyers last week, I had pointed them >> at the Caldera document. I'ld have loved to have been able to say look in >> this directory. The Caldera and later Nokia Licenses are what we are >> considering as examples. >> >> Thoughts? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Jul 3 07:02:44 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 2 Jul 2022 14:02:44 -0700 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: Message-ID: <20220702210244.GU11191@mcvoy.com> If I were looking for licenses "Copyrights+Licenses" would make me find, "metadata" I wouldn't think to look in. But I'm an old retired dude without many brain cells left. On Sat, Jul 02, 2022 at 02:57:31PM -0600, Warner Losh wrote: > Before we go inventing our own thing, let's just add spdx tags and > metadata..... there already is a standard for this. > > Warner > > On Sat, Jul 2, 2022, 1:09 PM Marc Donner wrote: > > > I would call that top level directory "metadata" ... the licensing stuff > > is quite relevant to the owner and operator of the system, but not directly > > relevant to any of its actual content or function. > > ===== > > nygeek.net > > mindthegapdialogs.com/home > > > > > > On Sat, Jul 2, 2022 at 2:17 PM Clem Cole wrote: > > > >> As part of some of simh work, I've been immersed in some licensing > >> discussions. Thanks for the V8-10, Plan-9 and Inferno notes - they are > >> relevant. > >> > >> Anyway, WRT to TUHS, I'm thinking that at least in the case of the Unix > >> style bits, I propose a small change to Waren's top-level directory. Add > >> a new dir called something like 'Legal Docs' or 'Copyrights+Licenses'. > >> Then move the Caldera document and Warren's current note into that area. > >> Then add copies of anything we can collect like the Dan Cross's V8-10, > >> anything WRT to Plan9/Inferno or anything we from the UNIX world - such as > >> something Sun, DEC or HP or like might have added. Maybe add a > >> subdirectory with the AT&T/USL case details. And maybe add a > >> sub-directory with known FOSS licenses used by the UNIX community and add a > >> copy of the 3-clause BSD and maybe even the two GPLs. > >> > >> Then update the README in the current top-level dir. Adding to the > >> contents something like "*the IP contained on this website is covered by > >> different licenses depending on the specific IP. Copies of these can be > >> found with the source code itself, but have also been all collected > >> together in the top-level directory: ...*." > >> > >> I think these all have both historical values, as well as practical > >> values. As I said, I was not sure myself and I think other would be less > >> ignorant if they could find it all easily. In the case of the practical, > >> a for instance, in an email with some lawyers last week, I had pointed them > >> at the Caldera document. I'ld have loved to have been able to say look in > >> this directory. The Caldera and later Nokia Licenses are what we are > >> considering as examples. > >> > >> Thoughts? > >> > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From mes at lazo.ca Sun Jul 3 09:01:43 2022 From: mes at lazo.ca (Mark Sutton) Date: Sat, 02 Jul 2022 16:01:43 -0700 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> Message-ID: <4FC15BF4-B7A8-4CE6-B3B8-FF52F1517219@lazo.ca> Thanks for asking Ori, I was just working up the courage to express my ignorance On July 1, 2022 6:05:30 AM PDT, Ori Idan wrote: >On Thu, Jun 30, 2022 at 7:38 PM Paul Winalski >wrote: > >> >> o why a memory access violation is reported as "segmentation fault" or >> "bus error", and the difference between the two >> >> o why CTRL/D is used to end a shell command line session > >I am not sure I know that, I'd be happy to know. > >> > > >> o why CTRL/S and CTRL/Q are used for flow control in a shell command >> line session >> >Also would be happy to know. > > >> >> o why an application memory dump after an application crash is called >> a core file >> >> -Paul W. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jul 3 09:54:02 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 2 Jul 2022 19:54:02 -0400 Subject: [TUHS] Thoughts on Licenses In-Reply-To: <20220702210244.GU11191@mcvoy.com> References: <20220702210244.GU11191@mcvoy.com> Message-ID: Agreed On Sat, Jul 2, 2022 at 5:03 PM Larry McVoy wrote: > If I were looking for licenses "Copyrights+Licenses" would make me > find, "metadata" I wouldn't think to look in. > > But I'm an old retired dude without many brain cells left. > > On Sat, Jul 02, 2022 at 02:57:31PM -0600, Warner Losh wrote: > > Before we go inventing our own thing, let's just add spdx tags and > > metadata..... there already is a standard for this. > > > > Warner > > > > On Sat, Jul 2, 2022, 1:09 PM Marc Donner wrote: > > > > > I would call that top level directory "metadata" ... the licensing > stuff > > > is quite relevant to the owner and operator of the system, but not > directly > > > relevant to any of its actual content or function. > > > ===== > > > nygeek.net > > > mindthegapdialogs.com/home > > > > > > > > > On Sat, Jul 2, 2022 at 2:17 PM Clem Cole wrote: > > > > > >> As part of some of simh work, I've been immersed in some licensing > > >> discussions. Thanks for the V8-10, Plan-9 and Inferno notes - they > are > > >> relevant. > > >> > > >> Anyway, WRT to TUHS, I'm thinking that at least in the case of the > Unix > > >> style bits, I propose a small change to Waren's top-level directory. > Add > > >> a new dir called something like 'Legal Docs' or 'Copyrights+Licenses'. > > >> Then move the Caldera document and Warren's current note into that > area. > > >> Then add copies of anything we can collect like the Dan Cross's V8-10, > > >> anything WRT to Plan9/Inferno or anything we from the UNIX world - > such as > > >> something Sun, DEC or HP or like might have added. Maybe add a > > >> subdirectory with the AT&T/USL case details. And maybe add a > > >> sub-directory with known FOSS licenses used by the UNIX community and > add a > > >> copy of the 3-clause BSD and maybe even the two GPLs. > > >> > > >> Then update the README in the current top-level dir. Adding to the > > >> contents something like "*the IP contained on this website is covered > by > > >> different licenses depending on the specific IP. Copies of these can > be > > >> found with the source code itself, but have also been all collected > > >> together in the top-level directory: ...*." > > >> > > >> I think these all have both historical values, as well as practical > > >> values. As I said, I was not sure myself and I think other would be > less > > >> ignorant if they could find it all easily. In the case of the > practical, > > >> a for instance, in an email with some lawyers last week, I had > pointed them > > >> at the Caldera document. I'ld have loved to have been able to say > look in > > >> this directory. The Caldera and later Nokia Licenses are what we are > > >> considering as examples. > > >> > > >> Thoughts? > > >> > > > > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -- Sent from a handheld expect more typos than usual -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sun Jul 3 10:08:25 2022 From: cowan at ccil.org (John Cowan) Date: Sat, 2 Jul 2022 20:08:25 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <4FC15BF4-B7A8-4CE6-B3B8-FF52F1517219@lazo.ca> References: <180245D1-0DCD-4C2C-A26A-EF68578FD548@canb.auug.org.au> <4FC15BF4-B7A8-4CE6-B3B8-FF52F1517219@lazo.ca> Message-ID: On Sat, Jul 2, 2022 at 7:02 PM Mark Sutton wrote: > /2 6:05:30 AM PDT, Ori Idan wrote: > >> >> On Thu, Jun 30, 2022 at 7:38 PM Paul Winalski >> wrote: >> >>> \ >> >> >>> o why CTRL/S and CTRL/Q are used for flow control in a shell command >>> line session >>> >> Also would be happy to know. >> > ASCII reserved four characters, ^Q through ^T, for unspecified device controls. The ASR 33 Teletype, which had a built-in paper tape reader and punch, allowed programmatic control of these devices using these characters: ^Q started the reader (assuming paper tape was in it) and ^S stopped it. In classic Teletype use, the protocol was bidirectional. (By the same token, ^R started the punch, which meant that characters sent to the terminal were punched as well as printed, and ^T stopped it. Some DEC OSes used ^T to print a single-line status of the current process. I do not know why ^C (end of text, as opposed to ^D which is end of transmission) took on its present role, but it was definitely already true in early DEC OSes. > >> >>> >>> o why an application memory dump after an application crash is called >>> a core file >>> >> See https://en.wikipedia.org/wiki/Magnetic-core_memory -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Sun Jul 3 10:22:00 2022 From: jpl.jpl at gmail.com (John P. Linderman) Date: Sat, 2 Jul 2022 20:22:00 -0400 Subject: [TUHS] "9 skills our grandkids won't have" - Is this a TUHS topic? In-Reply-To: <874jzz8fyc.fsf@vuxu.org> References: <874jzz8fyc.fsf@vuxu.org> Message-ID: But that's a common misconception and not how Ctrl-D works on Unix. Ctrl-D is part of the terminal discipline and causes an immediate stop of the current read(2) syscall. If nothing is in the input buffer, this causes a zero-length read which is detected as end of file. I once read a Patricia Cornwell novel in which the plot hinged around some crooked person typing cat > ttya Somebody is coming meaning to send a message to /dev/ttya, but instead, creating a file named "ttya". (I almost surely have the details wrong, but I'm too lazy to go searching for the real quote, which isn't relevant here.) Cornwell said the ttya file was of size 18, so, being an obsessive nit-picker, I sent her a letter saying that it could have been 18 bytes long, but that would imply that the sender terminated the message with CTRL-D rather than a newline and then terminating the command, the latter of which seemed much more plausible for a novice user. Rather than ignoring my letter, or telling me where to shove my letter, she sent me a gracious thank you note, and an FBI hat, which I still own. On Sat, Jul 2, 2022 at 3:37 PM Leah Neukirchen wrote: > Clem Cole writes: > > > On Fri, Jul 1, 2022 at 10:03 AM Steve Nickolas > wrote: > > > >> On Fri, 1 Jul 2022, Nelson H. F. Beebe wrote: > >> > >> > Ctrl-D signifies end of transmission. Some other O/Ses have used > >> > Ctrl-Z for that purpose, presumably because Z is the final letter > >> > of numerous alphabets. > >> > >> I thought only CP/M and its descendants did that. :o (Of course that > >> includes DOS and Windows) > >> > > Steve - The social disease spread of DOS-11, RT-11, CP/M, and MS/PS-DOS > > used ^Z as an EOF character in their text file format. The key is that > > they stored a block count, not a byte count in the META. Thus the last > > byte needs a marker to tell the OS to stop reading. [Early DEC OS's may > > have done that also, but I never looked at their FS formats]. > > > > Unix, of course, never made any distinction to the core OS WRT to 'type' > > [other than Regular/Directory/Special] and Ken stored a character count. > > So there was no need to signal EOF with a markered stored on disk.. > > > > A pipe or the shell on the other hand does have a need to signal the end > of > > a transaction, and 'End of Transmission,' as Nelson points out, is the > > ASCII character reserved for the same. > > But that's a common misconception and not how Ctrl-D works on Unix. > Ctrl-D is part of the terminal discipline and causes an immediate stop > of the current read(2) syscall. If nothing is in the input buffer, > this causes a zero-length read which is detected as end of file. > > You can verify this e.g. by typing "foo" into cat(1). It will > print "foo", but not exit. Another Ctrl-D will then quit cat(1) due > to the empty read. > > In no case, a ASCII Ctrl-D 0x4 is sent over a pipe or to a shell. > (Over the pty, yes.) > > cheers, > -- > Leah Neukirchen https://leahneukirchen.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sun Jul 3 12:03:12 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 2 Jul 2022 20:03:12 -0600 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220702210244.GU11191@mcvoy.com> Message-ID: With spdx it would go in neither place.. spdx is prescriptive about where the bom and such resides. But one of the big issues with thus stuff is things like USENIX tapes and other similar artifacts that have unclear or no license data still extant from the time, if there ever was. Or licenses that are poorly crafted. Some items have good and clear title, but many do not. Unix itself has an unclear chain of ownership at the time the ancient licenses were granted, especially in light of rulings in some court cases (some of which conflict in their finer points). We likely do not want to be in the business of judging things beyond "we have a good faith basis to think we can distribute this" So anything that goes beyond the simple spdx stuff, with our own extensions makes me nervous. Warner On Sat, Jul 2, 2022, 5:54 PM Clem Cole wrote: > Agreed > > On Sat, Jul 2, 2022 at 5:03 PM Larry McVoy wrote: > >> If I were looking for licenses "Copyrights+Licenses" would make me >> find, "metadata" I wouldn't think to look in. >> >> But I'm an old retired dude without many brain cells left. >> >> On Sat, Jul 02, 2022 at 02:57:31PM -0600, Warner Losh wrote: >> > Before we go inventing our own thing, let's just add spdx tags and >> > metadata..... there already is a standard for this. >> > >> > Warner >> > >> > On Sat, Jul 2, 2022, 1:09 PM Marc Donner wrote: >> > >> > > I would call that top level directory "metadata" ... the licensing >> stuff >> > > is quite relevant to the owner and operator of the system, but not >> directly >> > > relevant to any of its actual content or function. >> > > ===== >> > > nygeek.net >> > > mindthegapdialogs.com/home >> > > >> > > >> > > On Sat, Jul 2, 2022 at 2:17 PM Clem Cole wrote: >> > > >> > >> As part of some of simh work, I've been immersed in some licensing >> > >> discussions. Thanks for the V8-10, Plan-9 and Inferno notes - they >> are >> > >> relevant. >> > >> >> > >> Anyway, WRT to TUHS, I'm thinking that at least in the case of the >> Unix >> > >> style bits, I propose a small change to Waren's top-level >> directory. Add >> > >> a new dir called something like 'Legal Docs' or >> 'Copyrights+Licenses'. >> > >> Then move the Caldera document and Warren's current note into that >> area. >> > >> Then add copies of anything we can collect like the Dan Cross's >> V8-10, >> > >> anything WRT to Plan9/Inferno or anything we from the UNIX world - >> such as >> > >> something Sun, DEC or HP or like might have added. Maybe add a >> > >> subdirectory with the AT&T/USL case details. And maybe add a >> > >> sub-directory with known FOSS licenses used by the UNIX community >> and add a >> > >> copy of the 3-clause BSD and maybe even the two GPLs. >> > >> >> > >> Then update the README in the current top-level dir. Adding to the >> > >> contents something like "*the IP contained on this website is >> covered by >> > >> different licenses depending on the specific IP. Copies of these >> can be >> > >> found with the source code itself, but have also been all collected >> > >> together in the top-level directory: ...*." >> > >> >> > >> I think these all have both historical values, as well as practical >> > >> values. As I said, I was not sure myself and I think other would be >> less >> > >> ignorant if they could find it all easily. In the case of the >> practical, >> > >> a for instance, in an email with some lawyers last week, I had >> pointed them >> > >> at the Caldera document. I'ld have loved to have been able to say >> look in >> > >> this directory. The Caldera and later Nokia Licenses are what we are >> > >> considering as examples. >> > >> >> > >> Thoughts? >> > >> >> > > >> >> -- >> --- >> Larry McVoy Retired to fishing >> http://www.mcvoy.com/lm/boat >> > -- > Sent from a handheld expect more typos than usual > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Jul 3 12:27:43 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 2 Jul 2022 19:27:43 -0700 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220702210244.GU11191@mcvoy.com> Message-ID: <20220703022743.GA15738@mcvoy.com> So I have to say "who cares?" If we were talking about a modern multi threaded, scaled SMP, NUMA aware, knows all about the latest PCI, etc, OS, yes, whoever owns that might care. I love the early Unix releases because they were so simple, processors were simple then as well. Other than as a learning tool, which is a big deal but not a financial big deal, the early Unix versions have no value. Nobody cares other than us and we're, I dunno, but I would guess in the low thosands of people. I get that we all want the licenses to be above board but really, does it matter? Is anyone going to do anything with these early releases? I worked on SCO, it was early when SunOS was around and it was not friendly compared to SunOS and SunOS is long dead. I can promise you the number of people who care about SCO source are under 100. As in the people who would actually compile it, I bet it is under 10. I'm all for doing the right thing but some of the time when people talk about the licenses, I fail to see where a lawyer or a corporation is going to care. For them to care, they would need to see a way to make money. Nobody is going to make money off of 50 year old Unix releases. Heck, nobody is going to make money off of 20 year old Unix releases. As Rob Gingell said, bits rot. On Sat, Jul 02, 2022 at 08:03:12PM -0600, Warner Losh wrote: > With spdx it would go in neither place.. spdx is prescriptive about where > the bom and such resides. > > But one of the big issues with thus stuff is things like USENIX tapes and > other similar artifacts that have unclear or no license data still extant > from the time, if there ever was. Or licenses that are poorly crafted. Some > items have good and clear title, but many do not. Unix itself has an > unclear chain of ownership at the time the ancient licenses were granted, > especially in light of rulings in some court cases (some of which conflict > in their finer points). We likely do not want to be in the business of > judging things beyond "we have a good faith basis to think we can > distribute this" > > So anything that goes beyond the simple spdx stuff, with our own extensions > makes me nervous. > > Warner > > On Sat, Jul 2, 2022, 5:54 PM Clem Cole wrote: > > > Agreed > > > > On Sat, Jul 2, 2022 at 5:03 PM Larry McVoy wrote: > > > >> If I were looking for licenses "Copyrights+Licenses" would make me > >> find, "metadata" I wouldn't think to look in. > >> > >> But I'm an old retired dude without many brain cells left. > >> > >> On Sat, Jul 02, 2022 at 02:57:31PM -0600, Warner Losh wrote: > >> > Before we go inventing our own thing, let's just add spdx tags and > >> > metadata..... there already is a standard for this. > >> > > >> > Warner > >> > > >> > On Sat, Jul 2, 2022, 1:09 PM Marc Donner wrote: > >> > > >> > > I would call that top level directory "metadata" ... the licensing > >> stuff > >> > > is quite relevant to the owner and operator of the system, but not > >> directly > >> > > relevant to any of its actual content or function. > >> > > ===== > >> > > nygeek.net > >> > > mindthegapdialogs.com/home > >> > > > >> > > > >> > > On Sat, Jul 2, 2022 at 2:17 PM Clem Cole wrote: > >> > > > >> > >> As part of some of simh work, I've been immersed in some licensing > >> > >> discussions. Thanks for the V8-10, Plan-9 and Inferno notes - they > >> are > >> > >> relevant. > >> > >> > >> > >> Anyway, WRT to TUHS, I'm thinking that at least in the case of the > >> Unix > >> > >> style bits, I propose a small change to Waren's top-level > >> directory. Add > >> > >> a new dir called something like 'Legal Docs' or > >> 'Copyrights+Licenses'. > >> > >> Then move the Caldera document and Warren's current note into that > >> area. > >> > >> Then add copies of anything we can collect like the Dan Cross's > >> V8-10, > >> > >> anything WRT to Plan9/Inferno or anything we from the UNIX world - > >> such as > >> > >> something Sun, DEC or HP or like might have added. Maybe add a > >> > >> subdirectory with the AT&T/USL case details. And maybe add a > >> > >> sub-directory with known FOSS licenses used by the UNIX community > >> and add a > >> > >> copy of the 3-clause BSD and maybe even the two GPLs. > >> > >> > >> > >> Then update the README in the current top-level dir. Adding to the > >> > >> contents something like "*the IP contained on this website is > >> covered by > >> > >> different licenses depending on the specific IP. Copies of these > >> can be > >> > >> found with the source code itself, but have also been all collected > >> > >> together in the top-level directory: ...*." > >> > >> > >> > >> I think these all have both historical values, as well as practical > >> > >> values. As I said, I was not sure myself and I think other would be > >> less > >> > >> ignorant if they could find it all easily. In the case of the > >> practical, > >> > >> a for instance, in an email with some lawyers last week, I had > >> pointed them > >> > >> at the Caldera document. I'ld have loved to have been able to say > >> look in > >> > >> this directory. The Caldera and later Nokia Licenses are what we are > >> > >> considering as examples. > >> > >> > >> > >> Thoughts? > >> > >> > >> > > > >> > >> -- > >> --- > >> Larry McVoy Retired to fishing > >> http://www.mcvoy.com/lm/boat > >> > > -- > > Sent from a handheld expect more typos than usual > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From sjenkin at canb.auug.org.au Sun Jul 3 18:11:36 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sun, 3 Jul 2022 18:11:36 +1000 Subject: [TUHS] Thoughts on Licenses In-Reply-To: <20220703022743.GA15738@mcvoy.com> References: <20220702210244.GU11191@mcvoy.com> <20220703022743.GA15738@mcvoy.com> Message-ID: <93C473EA-F786-445D-9A03-FED3EBE4961A@canb.auug.org.au> > On 3 Jul 2022, at 12:27, Larry McVoy wrote: > > I love the early Unix releases because they were so simple, processors > were simple then as well. Bell’s Observation on Computer Classes has brought surprises - we’ve had some very popular new devices appear at the bottom end of the market and sell in the billions. Even 10yrs ago, I’d not have expected Apple to build their own Silicon & certainly not to make a high-performance system based on ARM. I’d expect more surprises will come, selling in huge numbers. An obvious application area is Networking + Storage, but many other possibilities exist. $10 interface for SATA drives to Ethernet would solve a lot of SOHO / SME storage problems, if only a local backup to the Cloud. MIT has produced ports of v6 for x86 & RISC-V - used for teaching purposes. Could a version of v6 or v7 run on a microcontroller? Perhaps. Not many versions of Linux run so leanly. If a product based on a microcontroller & v6/v7 became a very popular product, Copyright & Ownership might become an issue :( Even after the “SCO v IBM” case someone might see a payday. But why would anyone use "Version Zero" in what turned out to be quite a line of OS’s from Dept 1127 / CSRC?? Plan 9 or Inferno - born multi-processor, network aware and embedding 30+ years experience - would be the obvious platform for a “new small thing”. You’ve already covered on-list the Plan 9/ Inferno licensing, and there’s no impediment. While Vintage Cars are fascinating to gawk at and may be rewarding to repair & rebuild, they don’t include modern materials, designs, performance and safety. Fun for a hobby & special event, but not 1st choice for daily use. I think v6 on different platforms will have a very long life in a few areas, but is not what I’d choose for a commercial product. steve j -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From lm at mcvoy.com Mon Jul 4 00:39:06 2022 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 3 Jul 2022 07:39:06 -0700 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220702210244.GU11191@mcvoy.com> <20220703022743.GA15738@mcvoy.com> Message-ID: <20220703143906.GD18597@mcvoy.com> On Sun, Jul 03, 2022 at 05:55:15PM +1000, steve jenkin wrote: > > > On 3 Jul 2022, at 12:27, Larry McVoy wrote: > > > > I love the early Unix releases because they were so simple, processors > > were simple then as well. > > > Bell???s Observation on Computer Classes has brought surprises > - we???ve had some very popular new devices appear at the bottom end of the market and sell in the billions. Yes, and they all run Linux or some tiny OS. Has anyone ported v7 to any of these devices and seen it take off? Of course not, it doesn't have TCP/IP. From clemc at ccc.com Mon Jul 4 00:59:24 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 3 Jul 2022 10:59:24 -0400 Subject: [TUHS] Thoughts on Licenses In-Reply-To: <20220703143906.GD18597@mcvoy.com> References: <20220702210244.GU11191@mcvoy.com> <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> Message-ID: On Sun, Jul 3, 2022 at 10:39 AM Larry McVoy wrote: > Has anyone ported v7 to any of these devices and seen it take off? I agree with your observation BTW, but I will point out that every server based on Intel Si runs a V7 flavor called Minux in the IPMI node. WRT to Licenses - it does matter for a practical purpose. As Larry points out no one cares ... (until they do). Without going into specifics (this is a real example BTW), let's take a famous Science and Technology Museum in the EU that wants to use simh to put up a demo of traditional computing (in this case it's different from but let's say - using a PiDP-8 or PiDP-11 like display), they would like to know that it's a legitimate thing to do so. Lawyers are unlikely to look at the file called Metadata -- as I said, just last week, I would be easily able to point some of them to the top of Warren's tree for the Caldera license. The more licenses we have together in one place will make folks like that a lot more comfortable with proceeding. Again keeping the specific licenses with each release is probably a good thing (I would suggest links the master copy), just make it 100% clear we are *trying to do the right thing*. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Mon Jul 4 01:30:53 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 3 Jul 2022 10:30:53 -0500 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220702210244.GU11191@mcvoy.com> <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> Message-ID: <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> On Jul 3, 2022, at 9:59 AM, Clem Cole wrote: > > I agree with your observation BTW, but I will point out that every server based on Intel Si runs a V7 flavor called Minux in the IPMI node. You may be thinking of MINIX 1. It was a from-scratch implementation that was syscall compatible with V7 but IIRC it didn't have any sort of memory protection as it was designed to run on 8088. What runs on the Intel Management Engine is MINIX 3, a µkernel design with NetBSD userland. As Prof. Tanenbaum said, "MINIX 1 and MINIX 3 are related in the same way as Windows 3.1 and Windows XP are: same first name". From clemc at ccc.com Mon Jul 4 02:26:25 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 3 Jul 2022 12:26:25 -0400 Subject: [TUHS] Thoughts on Licenses In-Reply-To: <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> References: <20220702210244.GU11191@mcvoy.com> <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> Message-ID: On Sun, Jul 3, 2022 at 11:30 AM Bakul Shah wrote: > You may be thinking of MINIX 1. It was a from-scratch implementation that > was syscall compatible with V7 but IIRC it didn't have any sort of memory > protection as it was designed to run on 8088. Minux and specifically M1 was and always has been, a uK. And yes, M1 does not need an MMU - since it was designed to run on an 8088. IIRC this was Linus' original objection when he wanted to run on his 386-based PC (Wyse 32:16 box, IIRC). The key was Andy wanted to teach his students about V7 without running afoul of the AT&T license as Lions had with V6. What runs on the Intel Management Engine It's called the Intelligent Platform Management Interface - *a.k.a.* IPMI > is MINIX 3, ... with NetBSD userland. Actually, if you want to pick nits, neither statement is correct (remember for whom I work). MINIX 1 and MINIX 3 are related That's because M3 added the MMU support that M1 lacked. But there is nothing in M3 that IPMI is using other than it is the current version from Andy's team. What IPMI has as an underlying uK is heavily hacked and is a 'derivative work' - the local uk is basically providing V7 interfaces to some special programs. It made little sense to recreate something for the platform engine, and Minux was picked because it was smaller than any of the *BSDs and was not GPL'ed so Intel IP was still protected. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Mon Jul 4 02:55:04 2022 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Sun, 3 Jul 2022 09:55:04 -0700 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220702210244.GU11191@mcvoy.com> <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> Message-ID: On Sun, Jul 3, 2022 at 9:27 AM Clem Cole wrote: > > > On Sun, Jul 3, 2022 at 11:30 AM Bakul Shah wrote: > >> You may be thinking of MINIX 1. It was a from-scratch implementation that >> was syscall compatible with V7 but IIRC it didn't have any sort of memory >> protection as it was designed to run on 8088. > > Minux and specifically M1 was and always has been, a uK. And yes, M1 does > not need an MMU - since it was designed to run on an 8088. IIRC this was > Linus' original objection when he wanted to run on his 386-based PC (Wyse > 32:16 box, IIRC). The key was Andy wanted to teach his students about V7 > without running afoul of the AT&T license as Lions had with V6. > > What runs on the Intel Management Engine > > It's called the Intelligent Platform Management Interface > > - *a.k.a.* IPMI > IPMI is an entirely different subsystem from the ME. ME runs on one of at least two superfluous x86 cores within the CPU die of intel CPUs for a while that can run Intel and vendor supervisors. When this blew up in Intel’s face several years ago Minix 3 was the latest incarnation. https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/me_info.md IPMI is a sideband and could be anything including embedded Linux on a dedicated ARM SoC which is common in large scale installations. is MINIX 3, ... with NetBSD userland. > > Actually, if you want to pick nits, neither statement is correct (remember > for whom I work). > Maybe you are talking about something else. Minix 3 (Andy’s last OS) does indeed match this description, uK with NetBSD user. MINIX 1 and MINIX 3 are related > That's because M3 added the MMU support that M1 lacked. But there is > nothing in M3 that IPMI is using other than it is the current version from > Andy's team. What IPMI has as an underlying uK is heavily hacked and is a > 'derivative work' - the local uk is basically providing V7 interfaces to > some special programs. > > It made little sense to recreate something for the platform engine, and > Minux was picked because it was smaller than any of the *BSDs and was not > GPL'ed so Intel IP was still protected. > ᐧ > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Jul 4 03:15:42 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 3 Jul 2022 13:15:42 -0400 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220702210244.GU11191@mcvoy.com> <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> Message-ID: On Sun, Jul 3, 2022 at 12:55 PM Kevin Bowling wrote: > Maybe you are talking about something else. Minix 3 (Andy’s last OS) does > indeed match this description, uK with NetBSD user. > > Sigh .. I did not say it was not. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Mon Jul 4 03:48:02 2022 From: bakul at iitbombay.org (Bakul Shah) Date: Sun, 3 Jul 2022 12:48:02 -0500 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220702210244.GU11191@mcvoy.com> <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> Message-ID: <08E9845C-CA79-4CBD-B7F1-508F0E5D1AF6@iitbombay.org> On Jul 3, 2022, at 11:26 AM, Clem Cole wrote: > > > > On Sun, Jul 3, 2022 at 11:30 AM Bakul Shah > wrote: > You may be thinking of MINIX 1. It was a from-scratch implementation that was syscall compatible with V7 but IIRC it didn't have any sort of memory protection as it was designed to run on 8088. > Minux and specifically M1 was and always has been, a uK. And yes, M1 does not need an MMU - since it was designed to run on an 8088. IIRC this was Linus' original objection when he wanted to run on his 386-based PC (Wyse 32:16 box, IIRC). The key was Andy wanted to teach his students about V7 without running afoul of the AT&T license as Lions had with V6. Er.. a "microkernel" without an MMU is basically nothing more than a thread switcher (not unlike a variety of "realtime" embedded kernels like threadX and what not). > What runs on the Intel Management Engine > It's called the Intelligent Platform Management Interface - a.k.a. IPMI > is MINIX 3, ... with NetBSD userland. > Actually, if you want to pick nits, neither statement is correct (remember for whom I work). Not sure which statements you are talking about that are incorrect. Minix3 running on ME was in the news a few years back. See for instance: https://itsfoss.com/fact-intel-minix-case/ -- Websearch reveals many articles on IME + MINIX, hardly any to IPMI + MINIX. MINIX 3 + NetBSD userland is pretty much what minix3.org website says! [And no, I was not aware of who you work for.] In any case, sounds like you were talking about something not (well)known outside of Intel. > MINIX 1 and MINIX 3 are related > That's because M3 added the MMU support that M1 lacked. But there is nothing in M3 that IPMI is using other than it is the current version from Andy's team. What IPMI has as an underlying uK is heavily hacked and is a 'derivative work' - the local uk is basically providing V7 interfaces to some special programs. I think Tanenbaum's point was that MINIX3 is nothing like MINIX1 except in name. > It made little sense to recreate something for the platform engine, and Minux was picked because it was smaller than any of the *BSDs and was not GPL'ed so Intel IP was still protected. No argument here :-) > ᐧ > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gepoolejr at gmail.com Mon Jul 4 03:54:08 2022 From: gepoolejr at gmail.com (Geoff Pool) Date: Sun, 3 Jul 2022 10:54:08 -0700 Subject: [TUHS] Research Datakit notes Message-ID: I've enjoyed reading this thread as networking has always been a passion of mine. Lawrence Livermore had, at one time, their own networking system they called Spider. Is this the same Spider technology that Sandy Fraiser references in his Datakit notes? Geoff -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Jul 4 05:48:33 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 3 Jul 2022 15:48:33 -0400 Subject: [TUHS] Thoughts on Licenses In-Reply-To: <08E9845C-CA79-4CBD-B7F1-508F0E5D1AF6@iitbombay.org> References: <20220702210244.GU11191@mcvoy.com> <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> <08E9845C-CA79-4CBD-B7F1-508F0E5D1AF6@iitbombay.org> Message-ID: On Sun, Jul 3, 2022 at 1:48 PM Bakul Shah wrote: > Er.. a "microkernel" without an MMU is basically nothing more than a > thread switcher (not unlike a variety of "realtime" embedded kernels like > threadX and what not). > Argue with Andy and not me and read his book. Andy calls it a message-based uK. Given how they structured it. I would agree. > > I think Tanenbaum's point was that MINIX3 is *nothing* like MINIX1 except > in name. > Having talked to Andy about this in person, as well as looking at the code, I think I differ with your interpretation yes, M3 supports a ton of things M1 did not. But the core API and KPI are supersets. I also know a bit about what Intel uses for the IPMI support as part of my $ day job. Let's just say this is a great deal that is known outside of Intel and a good bit that is not and/or misunderstood. My point that started this rat hole was that Larry made a comment about V7 having little value. I know for a fact Larry's observation was not true. And how we use the core Minix subsystem (*as a basic V7 platform for a single custom application* that allows us to manage the server - as I said to Larry think the LS1-11 on the Vax and the 11/40 on the KL processors) and offered it as a counter-example. It could have been almost anything that you called a thread switcher. A simple V7 was 'good enough' and Minux supplied that for the team. In fact, I can think of other applications where V6 or V7 is more than enough for a lot of the tasks. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Mon Jul 4 06:32:06 2022 From: marc.donner at gmail.com (Marc Donner) Date: Sun, 3 Jul 2022 16:32:06 -0400 Subject: [TUHS] is networking different? Message-ID: On June 28 Rob Pike wrote: "One of the reasons I'm not a networking expert may be relevant here. With networks, I never found an abstraction to hang my hat on. Unlike with file systems and files, or even Unix character devices, which provide a level of remove from the underlying blocks and sectors and so on, the Unix networking interface always seemed too low-level and fiddly, analogous to making users write files by managing the blocks and sectors themselves." I've been ruminating on the question of whether networks are different from disks (and other devices). Here are a couple of observations: 1 - Two different packets may take two different paths from the sender to the receiver. 1a - The transit time for one packet may vary widely from that of the other. 1b - The two packets may arrive in an order different from the order in which they were transmitted. (Note - recently I have been reading Bob Gezelter's monograph [and PhD dissertation] and I've learned that modern high-performance disk systems behave more like networks in 1a and 1b.) 2 - A packet may never arrive. 3 - Behavior 2 not a sign of hard failure for networks, whereas it is generally considered so for other I/O devices. There is probably more to why networks are weird, but these are some of the big dissonances that seem to me to make Rob's comment resonate so loudly to me. Best, Marc ===== nygeek.net mindthegapdialogs.com/home -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.donner at gmail.com Mon Jul 4 06:34:28 2022 From: marc.donner at gmail.com (Marc Donner) Date: Sun, 3 Jul 2022 16:34:28 -0400 Subject: [TUHS] is networking different? In-Reply-To: References: Message-ID: Let's add: 0 - The two endpoints of a network connection may be (and usually are) under independent control from one another. ===== nygeek.net mindthegapdialogs.com/home On Sun, Jul 3, 2022 at 4:32 PM Marc Donner wrote: > On June 28 Rob Pike wrote: > > "One of the reasons I'm not a networking expert may be relevant here. With > networks, I never found an abstraction to hang my hat on. Unlike with file > systems and files, or even Unix character devices, which provide a level of > remove from the underlying blocks and sectors and so on, the Unix > networking interface always seemed too low-level and fiddly, analogous to > making users write files by managing the blocks and sectors themselves." > > I've been ruminating on the question of whether networks are different > from disks (and other devices). Here are a couple of observations: > > 1 - Two different packets may take two different paths from the sender to > the receiver. > > 1a - The transit time for one packet may vary widely from that of the > other. > > 1b - The two packets may arrive in an order different from the order in > which they were transmitted. > > (Note - recently I have been reading Bob Gezelter's monograph [and PhD > dissertation] and I've learned that modern high-performance disk systems > behave more like networks in 1a and 1b.) > > 2 - A packet may never arrive. > > 3 - Behavior 2 not a sign of hard failure for networks, whereas it is > generally considered so for other I/O devices. > > There is probably more to why networks are weird, but these are some of > the big dissonances that seem to me to make Rob's comment resonate so > loudly to me. > > Best, > > Marc > ===== > nygeek.net > mindthegapdialogs.com/home > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drsalists at gmail.com Mon Jul 4 06:57:30 2022 From: drsalists at gmail.com (Dan Stromberg) Date: Sun, 3 Jul 2022 13:57:30 -0700 Subject: [TUHS] is networking different? In-Reply-To: References: Message-ID: On Sun, Jul 3, 2022 at 1:33 PM Marc Donner wrote: > On June 28 Rob Pike wrote: > > "One of the reasons I'm not a networking expert may be relevant here. With > networks, I never found an abstraction to hang my hat on. Unlike with file > systems and files, or even Unix character devices, which provide a level of > remove from the underlying blocks and sectors and so on, the Unix > networking interface always seemed too low-level and fiddly, analogous to > making users write files by managing the blocks and sectors themselves." > > I've been ruminating on the question of whether networks are different > from disks (and other devices). Here are a couple of observations: > > 1 - Two different packets may take two different paths from the sender to > the receiver. > Yes, but it doesn't much matter. It's a solved problem. 1a - The transit time for one packet may vary widely from that of the other. > Yes, but it doesn't much matter. This too is a solved problem. 1b - The two packets may arrive in an order different from the order in > which they were transmitted. > Yes, but TCP will present the data they describe in order, or an error. (Note - recently I have been reading Bob Gezelter's monograph [and PhD > dissertation] and I've learned that modern high-performance disk systems > behave more like networks in 1a and 1b.) > > 2 - A packet may never arrive. > TCP will retry lost data, and if transmission continues failing, TCP'll give an error. 3 - Behavior 2 not a sign of hard failure for networks, whereas it is > generally considered so for other I/O devices. > Network API's and protocols aren't all the same. You seem to be thinking of UDP or IP or something. There is probably more to why networks are weird, but these are some of the > big dissonances that seem to me to make Rob's comment resonate so loudly to > me. > TCP really isn't that bad, and REST is simpler still. The chief problem with TCP that people get wrong is: https://stromberg.dnsalias.org/~strombrg/TCP/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at mbsks.franken.de Mon Jul 4 07:23:31 2022 From: m at mbsks.franken.de (Matthias Bruestle) Date: Sun, 3 Jul 2022 23:23:31 +0200 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> <08E9845C-CA79-4CBD-B7F1-508F0E5D1AF6@iitbombay.org> Message-ID: On Sun, Jul 03, 2022 at 03:48:33PM -0400, Clem Cole wrote: > single custom application* that allows us to manage the server - as I said > to Larry think the LS1-11 on the Vax and the 11/40 on the KL processors) I have a MicroVAXII with a KMV1A. Are you refering to such a card with the "LSI-11 on the Vax"? Does this mean there is a V7 running on it? I really don't know much about that card. Might have been used for I/O with an IBM 3090 in this computer. Matthias -- When You Find Out Your Normal Daily Lifestyle Is Called Quarantine From tuhs at tuhs.org Mon Jul 4 07:38:46 2022 From: tuhs at tuhs.org (Jay Logue via TUHS) Date: Sun, 3 Jul 2022 14:38:46 -0700 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: Message-ID: <165688432936.3454369.11344663867496707136@minnie.tuhs.org> I think it makes sense to place standalone documents like the Caldera license in a central location.  However I don't see a lot of value in placing copies of non-standalone license/copyright notices in a place other than their original locations, because all these texts have context ("/This /software is copyright ...."), which I think is important both historically and practically. Perhaps it would be better to create an index of license/copyright notices that appear in the source tree, including pointers to their containing files. Extra points for an historical analysis of the evolution/commonality of license texts as they appear over time and across Unix versions. --Jay On 7/2/2022 11:15 AM, Clem Cole wrote: > As part of some of simh work, I've been immersed in some licensing > discussions.  Thanks for the V8-10, Plan-9 and Inferno notes - they > are relevant. > > Anyway, WRT to TUHS, I'm thinking that at least in the case of the > Unix style bits, I propose a small change to Waren's top-level > directory.   Add a new dir called something like 'Legal Docs' or > 'Copyrights+Licenses'.   Then move the Caldera document and Warren's > current note into that area.  Then add copies of anything we can > collect like the Dan Cross's V8-10, anything WRT to Plan9/Inferno or > anything we from the UNIX world - such as something Sun, DEC or HP or > like might have added.  Maybe add a subdirectory with the AT&T/USL > case details.   And maybe add a sub-directory with known FOSS licenses > used by the UNIX community and add a copy of the 3-clause BSD and > maybe even the two GPLs. > > Then update the README in the current top-level dir.   Adding to the > contents something like "/the IP contained on this website is covered > by different licenses depending on the specific IP.  Copies of these > can be found with the source code itself, but have also been all > collected together in the top-level directory: .../." > > I think these all have both historical values, as well as practical > values. As I said, I was not sure myself and I think other would be > less ignorant if they could find it all easily.   In the case of the > practical, a for instance, in an email with some lawyers last week, I > had pointed them at the Caldera document.  I'ld have loved to have > been able to say look in this directory.  The Caldera and later > Nokia Licenses are what we are considering as examples. > > Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Mon Jul 4 07:55:22 2022 From: rich.salz at gmail.com (Richard Salz) Date: Sun, 3 Jul 2022 17:55:22 -0400 Subject: [TUHS] is networking different? In-Reply-To: References: Message-ID: I wanna live in Dan's world, or at least his network. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Mon Jul 4 08:40:18 2022 From: clemc at ccc.com (Clem Cole) Date: Sun, 3 Jul 2022 18:40:18 -0400 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> <08E9845C-CA79-4CBD-B7F1-508F0E5D1AF6@iitbombay.org> Message-ID: Sorry for some of us old guys vax = 780 ᐧ On Sun, Jul 3, 2022 at 5:30 PM Matthias Bruestle wrote: > On Sun, Jul 03, 2022 at 03:48:33PM -0400, Clem Cole wrote: > > single custom application* that allows us to manage the server - as I > said > > to Larry think the LS1-11 on the Vax and the 11/40 on the KL processors) > > I have a MicroVAXII with a KMV1A. Are you refering to such a card with > the "LSI-11 on the Vax"? Does this mean there is a V7 running on it? > I really don't know much about that card. Might have been used for I/O with > an IBM 3090 in this computer. > > Matthias > > -- > When You Find Out Your Normal Daily Lifestyle Is Called Quarantine > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Mon Jul 4 13:01:37 2022 From: norman at oclsc.org (Norman Wilson) Date: Sun, 03 Jul 2022 21:01:37 -0600 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> <08E9845C-CA79-4CBD-B7F1-508F0E5D1AF6@iitbombay.org> Message-ID: <293D45E44FDF19A10AF02A011D3B463C.for-standards-violators@oclsc.org> On July 3, 2022 4:40:18 p.m. MDT, Clem Cole wrote: >Sorry for some of us old guys vax = 780 Did you, like me, wonder why Trump wanted exactly an original-VAX-model-number of phony votes in Georgia? Maybe someone told him that the internal DEC name for VAX/VMS, at least during early development, was Starlet, and he wanted to grab it by the SYS$SPAWN. From paul.winalski at gmail.com Mon Jul 4 22:33:13 2022 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 4 Jul 2022 08:33:13 -0400 Subject: [TUHS] Thoughts on Licenses In-Reply-To: References: <20220703022743.GA15738@mcvoy.com> <20220703143906.GD18597@mcvoy.com> <5E49BE69-8869-473A-B3F5-6744566700F0@iitbombay.org> <08E9845C-CA79-4CBD-B7F1-508F0E5D1AF6@iitbombay.org> Message-ID: On 7/3/22, Matthias Bruestle wrote: > On Sun, Jul 03, 2022 at 03:48:33PM -0400, Clem Cole wrote: >> single custom application* that allows us to manage the server - as I >> said >> to Larry think the LS1-11 on the Vax and the 11/40 on the KL processors) > > I have a MicroVAXII with a KMV1A. Are you refering to such a card with > the "LSI-11 on the Vax"? Does this mean there is a V7 running on it? > I really don't know much about that card. Might have been used for I/O with > an IBM 3090 in this computer. Clem is referring to the VAX-11/780 (and its follow-ons the 782 and 785), which used a LSI-11 processor (PDP-11/03) to load its microcode on power-on. IIRC the LSI-11 front end also ran the system console device (originally a LA-36 DECwriter terminal). The third generation PDP-10 CPU (the KL10) similarly had a PDP-11/40 front end that did the bootstrap loading and also acted as a peripheral device controller. -Paul W. From tuhs at tuhs.org Tue Jul 5 06:09:52 2022 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Mon, 4 Jul 2022 22:09:52 +0200 Subject: [TUHS] Re.: is networking different? Message-ID: <72C18447-E565-4A02-84E2-BFB309E97330@planet.nl> > On Sun, Jul 3, 2022 at 1:33 PM Marc Donner wrote: > > I've been ruminating on the question of whether networks are different from > disks (and other devices). Here are a couple of observations: [...] From my perspective most of these things are not unique to networks, they happen with disks and/or terminals. Only out-of-order delivery seems new. However, in many early networking contexts (Spider/Arpanet/Datakit/UUCP) this aspect was not visible to the host (and the same holds for a single segment ethernet). To me, in some ways networks are like tty’s (e.g. completing i/o can take arbitrarily long, doing a seek() does not make sense), in other ways they are like disks (raw devices are organised into byte streams, they have a name space). Uniquely, they have two end-points, only one of which is local (but pipes come close). Conceptually, a file system does two things: (i) it organises raw blocks into multiple files; these are the i-nodes and (ii) it provides a name space; these are directories and the namei routine. A network stack certainly does the first: a raw network device is organised into multiple pipe-like connections; depending on the network, it optionally offers a naming service. With the first aspect one could refer to any file by “major device number, minor device number, i-node number”. This is not very different from referring to a network stream by “network number, host number, port number” in tcp/ip (and in fact this is what bind() and connect() in the sockets API do), or “switch / host / channel” in Datakit. For disks, Unix offers a clean way to organise the name spaces of multiple devices into a unified whole. How to do this with networks is not so easy, prior to the invention of the file system switch. Early on (Arpanet Unix), it was tried to incorporate host names into a net directory by name (RFC 681) but this is not scalable. Another way would be to have a virtual directory and include only names for active connections. The simple way would be to use a text version of the numeric name as described above - but that is not much of an improvement. Better to have a network variant of namei that looks up symbolic names in a hosts file or in a network naming service. The latter does not look very performant on the hardware of 40 years ago, but it appears to have worked well on the Alto / PuPs network at Xerox PARC. With the above one could do open(“/net/inet/org.tuhs.www:80”, O_RDWR | O_STREAM) to connect to the TUHS web server, and do open(“/net/inet/any:80”, O_RDWR | O_STREAM | O_CREAT, 0600) to create a ‘listening’ (rendez-vous) socket. Paul From lm at mcvoy.com Tue Jul 5 06:44:49 2022 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 4 Jul 2022 13:44:49 -0700 Subject: [TUHS] Re.: is networking different? In-Reply-To: <72C18447-E565-4A02-84E2-BFB309E97330@planet.nl> References: <72C18447-E565-4A02-84E2-BFB309E97330@planet.nl> Message-ID: <20220704204449.GT18597@mcvoy.com> On Mon, Jul 04, 2022 at 10:09:52PM +0200, Paul Ruizendaal via TUHS wrote: > With the above one could do > > open("/net/inet/org.tuhs.www:80", O_RDWR | O_STREAM) > > to connect to the TUHS web server, and do > > open("/net/inet/any:80", O_RDWR | O_STREAM | O_CREAT, 0600) > > to create a "listening" (rendez-vous) socket. Decades ago, I tried to make a library that worked like this and it was problematic. There are all sorts of setsockopt things that you sometimes need to set. I'd love to be wrong on this, if anyone has a working, for all of the normal use cases, library like this, I'd love to see it. From rminnich at gmail.com Tue Jul 5 07:17:24 2022 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Jul 2022 14:17:24 -0700 Subject: [TUHS] Re.: is networking different? In-Reply-To: <72C18447-E565-4A02-84E2-BFB309E97330@planet.nl> References: <72C18447-E565-4A02-84E2-BFB309E97330@planet.nl> Message-ID: Something like what you mention: open(“/net/inet/any:80”, O_RDWR | O_STREAM | O_CREAT, 0600), is actually to be found in an RFC from around that time. You can do that, but the 1980s tried it and it did not end well. What's it mean, for example, when you rename("/net/harv") to ("/net/google") -- close and reopen socket? (there's a Lost Talk from, I think, Rob, that addressed this very question) While it has its flaws, https://9p.io/sys/doc/net/net.html in my view is the best example to date of how to get it right. Addresses are strings, just like paths -- well, they *are* paths in fact. Some of this path-like nature can be seen in the Go net package today. Oh, and, as regards how the synthetic file system looks: you never, never, ever, put an address in the pathname. That's important. Also consider that if you get it right, you can do all the network IO you want with cat and echo -- people have written telnet in Plan 9 with those two commands. And, if you get it wrong, well -- you get socat. On Mon, Jul 4, 2022 at 1:10 PM Paul Ruizendaal via TUHS wrote: > > > On Sun, Jul 3, 2022 at 1:33 PM Marc Donner wrote: > > > > I've been ruminating on the question of whether networks are different from > > disks (and other devices). Here are a couple of observations: > > [...] > > From my perspective most of these things are not unique to networks, they happen with disks and/or terminals. Only out-of-order delivery seems new. However, in many early networking contexts (Spider/Arpanet/Datakit/UUCP) this aspect was not visible to the host (and the same holds for a single segment ethernet). > > To me, in some ways networks are like tty’s (e.g. completing i/o can take arbitrarily long, doing a seek() does not make sense), in other ways they are like disks (raw devices are organised into byte streams, they have a name space). Uniquely, they have two end-points, only one of which is local (but pipes come close). > > Conceptually, a file system does two things: (i) it organises raw blocks into multiple files; these are the i-nodes and (ii) it provides a name space; these are directories and the namei routine. A network stack certainly does the first: a raw network device is organised into multiple pipe-like connections; depending on the network, it optionally offers a naming service. > > With the first aspect one could refer to any file by “major device number, minor device number, i-node number”. This is not very different from referring to a network stream by “network number, host number, port number” in tcp/ip (and in fact this is what bind() and connect() in the sockets API do), or “switch / host / channel” in Datakit. For disks, Unix offers a clean way to organise the name spaces of multiple devices into a unified whole. How to do this with networks is not so easy, prior to the invention of the file system switch. > > Early on (Arpanet Unix), it was tried to incorporate host names into a net directory by name (RFC 681) but this is not scalable. Another way would be to have a virtual directory and include only names for active connections. The simple way would be to use a text version of the numeric name as described above - but that is not much of an improvement. Better to have a network variant of namei that looks up symbolic names in a hosts file or in a network naming service. The latter does not look very performant on the hardware of 40 years ago, but it appears to have worked well on the Alto / PuPs network at Xerox PARC. > > With the above one could do > > open(“/net/inet/org.tuhs.www:80”, O_RDWR | O_STREAM) > > to connect to the TUHS web server, and do > > open(“/net/inet/any:80”, O_RDWR | O_STREAM | O_CREAT, 0600) > > to create a ‘listening’ (rendez-vous) socket. > > Paul > > > > > > > > > > > > From tuhs at tuhs.org Tue Jul 5 07:31:15 2022 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Mon, 4 Jul 2022 23:31:15 +0200 Subject: [TUHS] Re.: is networking different? In-Reply-To: <20220704204449.GT18597@mcvoy.com> References: <72C18447-E565-4A02-84E2-BFB309E97330@planet.nl> <20220704204449.GT18597@mcvoy.com> Message-ID: > On 4 Jul 2022, at 22:44, Larry McVoy wrote: > > On Mon, Jul 04, 2022 at 10:09:52PM +0200, Paul Ruizendaal via TUHS wrote: >> With the above one could do >> >> open("/net/inet/org.tuhs.www:80", O_RDWR | O_STREAM) >> >> to connect to the TUHS web server, and do >> >> open("/net/inet/any:80", O_RDWR | O_STREAM | O_CREAT, 0600) >> >> to create a "listening" (rendez-vous) socket. > > Decades ago, I tried to make a library that worked like this and it > was problematic. There are all sorts of setsockopt things that > you sometimes need to set. > > I'd love to be wrong on this, if anyone has a working, for all of the > normal use cases, library like this, I'd love to see it. Wouldn’t setsockopt map nicely to ioctl when there is a file system switch? The ioctl would switch into the network stack specific version naturally. setsockopt(sd, SOL_SOCKET, SO_BROADCAST, &val, sizeof(int)) would become ioctl(sd, SO_BROADCAST, &val) More generally, the issue of meta-data and avoiding that ioctl becomes an intractable dumping ground is not easy to solve. From phil at ultimate.com Tue Jul 5 07:33:46 2022 From: phil at ultimate.com (Phil Budne) Date: Mon, 04 Jul 2022 17:33:46 -0400 Subject: [TUHS] Re.: is networking different? In-Reply-To: <20220704204449.GT18597@mcvoy.com> References: <72C18447-E565-4A02-84E2-BFB309E97330@planet.nl> <20220704204449.GT18597@mcvoy.com> Message-ID: <202207042133.264LXkeA074138@ultimate.com> Larry McVoy wrote: > Decades ago, I tried to make a library that worked like this and it > was problematic. There are all sorts of setsockopt things that > you sometimes need to set. > > I'd love to be wrong on this, if anyone has a working, for all of the > normal use cases, library like this, I'd love to see it. The DEC's TOPS-20 TCP/IP interface (coded on top of a set of new system calls that implemented the BBN (original) TCP/IP interface for TENEX/TOPS-20, since system calls could make system calls) was like that. BUT the TENEX/TOPS-20 system call to pass a pathname into the system allowed "attributes" to be appended to paths as ";ATTR[:VALUE]"(*), which was used to determine whether it was an active (connect) or passive (listen) open. TCP was implemented as a logical device: TCP:[LOCAL_HOST][-LOCAL_PORT[#]].[FOREIGN_HOST][-FOREIGN_PORT][;A1..] For details see: https://www.rfc-editor.org/ien/ien176.txt And http://www.bitsavers.org/pdf/dec/pdp10/TOPS20/V7/JSYS_REFERENCE.MEM.txt (JSYS is the machine instruction used for system calls) A full set of attribute keywords at page 3-170 (search text document) and description of TCP: device as implemented in section 2.4.10 NOTE! The original text file undoubtedly had bare carriage return characters for overstrikes (bold and underscore). A feature of this interface is that you can fully specify the four-tuple of the connection when doing a passive open, which ISTR was used by FTP (the client listened for a connection on the same local address and port as the command connection, from the foreign address and FTP-DATA port of the server, and the PORT command was not necessary. An even more obscure implementation is in my port of the original Bell Labs (Holmdel, that is) implementation of SNOBOL4, where I implemented tcp connections (active only) as /tcp/HOSTNAME/SERVICE[/ATTR]... where ATTR can be used to set various setsockopts: http://www.regressive.org/snobol4/csnobol4/curr/doc/snobol4io.1.html (search for tcp). From pnr at planet.nl Tue Jul 5 09:37:52 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 5 Jul 2022 01:37:52 +0200 Subject: [TUHS] is networking different? In-Reply-To: References: <72C18447-E565-4A02-84E2-BFB309E97330@planet.nl> Message-ID: <7E3B9D54-8D4A-495F-9548-CA4B1B285BE4@planet.nl> Thank you for sharing experiences on what worked and what did not. Much appreciated! As I’m now too much on a tangent of what might have been versus what once was, I’ll follow up with a PM. > On 4 Jul 2022, at 23:17, ron minnich wrote: > > Something like what you mention: open(“/net/inet/any:80”, O_RDWR | > O_STREAM | O_CREAT, 0600), is actually to be found in an RFC from > around that time. > > You can do that, but the 1980s tried it and it did not end well. > What's it mean, for example, when you rename("/net/harv") to > ("/net/google") -- close and reopen socket? (there's a Lost Talk from, > I think, Rob, that addressed this very question) > > While it has its flaws, https://9p.io/sys/doc/net/net.html in my view > is the best example to date of how to get it right. Addresses are > strings, just like paths -- well, they *are* paths in fact. Some of > this path-like nature can be seen in the Go net package today. > > Oh, and, as regards how the synthetic file system looks: you never, > never, ever, put an address in the pathname. That's important. > > Also consider that if you get it right, you can do all the network IO > you want with cat and echo -- people have written telnet in Plan 9 > with those two commands. And, if you get it wrong, well -- you get > socat. From cowan at ccil.org Tue Jul 5 13:02:53 2022 From: cowan at ccil.org (John Cowan) Date: Mon, 4 Jul 2022 23:02:53 -0400 Subject: [TUHS] is networking different? In-Reply-To: <7E3B9D54-8D4A-495F-9548-CA4B1B285BE4@planet.nl> References: <72C18447-E565-4A02-84E2-BFB309E97330@planet.nl> <7E3B9D54-8D4A-495F-9548-CA4B1B285BE4@planet.nl> Message-ID: > On 4 Jul 2022, at 23:17, ron minnich wrote: > > > You can do that, but the 1980s tried it and it did not end well. > > What's it mean, for example, when you rename("/net/harv") to > > ("/net/google") -- close and reopen socket? (there's a Lost Talk from, > > I think, Rob, that addressed this very question) > Why shouldn't it just fail with EXDEV "No cross-device links"? > Also consider that if you get it right, you can do all the network IO > > you want with cat and echo -- people have written telnet in Plan 9 > > with those two commands. Well, not really. You need at least sed to convert 0xFF to 0xFF 0xFF on the wire and back again, at least if you are talking to a conformant implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Jul 7 04:16:31 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 06 Jul 2022 12:16:31 -0600 Subject: [TUHS] Stuart Feldman's EFL Message-ID: <202207061816.266IGVAA002244@freefriends.org> Hi. EFL was definitely a part of BSD Unix. But I don't see it in the V7 stuff in the TUHS archives. When did it first appear? Was it part of 32V and I should look there? It is definitely in the V8 and V10 stuff. Did anyone actually use it? I have the feeling that ratfor had already caught on and spread far, and that it met people's needs, and so EFL didn't really catch on that much, even though it provided more features on top of Fortran. Thanks, Arnold From lm at mcvoy.com Thu Jul 7 04:30:38 2022 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 6 Jul 2022 11:30:38 -0700 Subject: [TUHS] Stuart Feldman's EFL In-Reply-To: <202207061816.266IGVAA002244@freefriends.org> References: <202207061816.266IGVAA002244@freefriends.org> Message-ID: <20220706183038.GE31996@mcvoy.com> On Wed, Jul 06, 2022 at 12:16:31PM -0600, arnold at skeeve.com wrote: > Hi. > > EFL was definitely a part of BSD Unix. But I don't see it in the V7 > stuff in the TUHS archives. When did it first appear? Was it part > of 32V and I should look there? > > It is definitely in the V8 and V10 stuff. > > Did anyone actually use it? I have the feeling that ratfor had already > caught on and spread far, and that it met people's needs, and so > EFL didn't really catch on that much, even though it provided more > features on top of Fortran. The only thing I see in tuhs.org:/var/www that is related is ./TUHS/Archive/Documentation/Manuals/Unix_4.0/Volume_1/D.2.3_EFL.pdf but I'm still learning the layout on tuhs.org, might be somewhere else? From clemc at ccc.com Thu Jul 7 05:13:49 2022 From: clemc at ccc.com (Clem Cole) Date: Wed, 6 Jul 2022 15:13:49 -0400 Subject: [TUHS] Stuart Feldman's EFL In-Reply-To: <202207061816.266IGVAA002244@freefriends.org> References: <202207061816.266IGVAA002244@freefriends.org> Message-ID: Arnold -- good memory. It was in 4BSD (see disk1 of the McKusick disks) but it is not in 3BSD. I agree with you, it was not in V7 or 32v (but was in later BSD 2.9/10/11 releases). Frankly, I have memories of Ratfor in V7 on the PDP-11 [and used as part of my thesis on the Vax]. IIRC to use ratfor on the 11, you needed the V7addenda that had a bunch of F77 fixes. I have memories of EFL and reading the doc. But I have no memories of ever using it - although Hilfinger may have talked about it in the UCB grad comparative languages seminar maybe in 81/82 timeframe (my memory is hazy - I know it was there that Paul was the one that taught me to not hate Ada so much and understand why Ada was like it was). What I can not place is where I first saw EFL. My WAG would be UCB. FWIW: Stu did a sabbatical at UCB when I was a grad student. I'm going to guess maybe he brought it with him during that time. On Wed, Jul 6, 2022 at 2:16 PM wrote: > Hi. > > EFL was definitely a part of BSD Unix. But I don't see it in the V7 > stuff in the TUHS archives. When did it first appear? Was it part > of 32V and I should look there? > > It is definitely in the V8 and V10 stuff. > > Did anyone actually use it? I have the feeling that ratfor had already > caught on and spread far, and that it met people's needs, and so > EFL didn't really catch on that much, even though it provided more > features on top of Fortran. > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at quintile.net Thu Jul 7 06:15:33 2022 From: steve at quintile.net (Steve Simon) Date: Wed, 6 Jul 2022 21:15:33 +0100 Subject: [TUHS] EFL In-Reply-To: <165713492731.3454377.3885165155504978115@minnie.tuhs.org> References: <165713492731.3454377.3885165155504978115@minnie.tuhs.org> Message-ID: I remember reading the EFL docs in the paper manuals for a sysv.3.2 honeywell 68k tower machine i worked on circa 1987. i never tried it though. From fariborz.t at gmail.com Thu Jul 7 09:53:47 2022 From: fariborz.t at gmail.com (Skip Tavakkolian) Date: Wed, 6 Jul 2022 16:53:47 -0700 Subject: [TUHS] Stuart Feldman's EFL In-Reply-To: <202207061816.266IGVAA002244@freefriends.org> References: <202207061816.266IGVAA002244@freefriends.org> Message-ID: In mid 80's I worked at Microrim for a short time. There was an effort to port R:Base (in Fortran) to Unix (especially Xenix). There was a Fortune Systems 32:16 machine running For:Pro (v7). It had EFL. I vaguely recall a discussion about going the Fortran->EFL->(might be easier to port to)->C route. I was there to help, but was a greenhorn and way in over my head. On Wed, Jul 6, 2022, 11:17 AM wrote: > Hi. > > EFL was definitely a part of BSD Unix. But I don't see it in the V7 > stuff in the TUHS archives. When did it first appear? Was it part > of 32V and I should look there? > > It is definitely in the V8 and V10 stuff. > > Did anyone actually use it? I have the feeling that ratfor had already > caught on and spread far, and that it met people's needs, and so > EFL didn't really catch on that much, even though it provided more > features on top of Fortran. > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Jul 7 16:20:25 2022 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 07 Jul 2022 00:20:25 -0600 Subject: [TUHS] Stuart Feldman's EFL In-Reply-To: <20220706183038.GE31996@mcvoy.com> References: <202207061816.266IGVAA002244@freefriends.org> <20220706183038.GE31996@mcvoy.com> Message-ID: <202207070620.2676KP0e011582@freefriends.org> Larry McVoy wrote: > On Wed, Jul 06, 2022 at 12:16:31PM -0600, arnold at skeeve.com wrote: > > Hi. > > > > EFL was definitely a part of BSD Unix. But I don't see it in the V7 > > stuff in the TUHS archives. When did it first appear? Was it part > > of 32V and I should look there? > > > > It is definitely in the V8 and V10 stuff. > > > > Did anyone actually use it? I have the feeling that ratfor had already > > caught on and spread far, and that it met people's needs, and so > > EFL didn't really catch on that much, even though it provided more > > features on top of Fortran. > > The only thing I see in tuhs.org:/var/www that is related is > > ./TUHS/Archive/Documentation/Manuals/Unix_4.0/Volume_1/D.2.3_EFL.pdf > > but I'm still learning the layout on tuhs.org, might be somewhere else? It's in /usr/src/cmd/efl in the V8 and V10 trees and IIRC in /usr/src/usr.bin/efl in the 4.3 BSD tree. It helps to have a local copy of the archive (obtainable via rsync) to browse locally. Arnold From meillo at marmaro.de Fri Jul 8 17:47:01 2022 From: meillo at marmaro.de (markus schnalke) Date: Fri, 08 Jul 2022 09:47:01 +0200 Subject: [TUHS] ed: multiple addresses (with semicolons) Message-ID: <1o9ihZ-3C2-00@marmaro.de> Hoi, via a recent message from Chris Pinnock to the list I became aware of the book ``Ed Mastery'' by Michael W. Lucas. At once I bought and read it. Although it is not on the mastery level it claims and I would have liked it to be, it still was fun to read. This brought me back to my ed interest. I like ed a lot and despite my young age, I've actually programmed with ed for fun and have prepared the troff slides for a talk on early Unix tools (like ed) with ed alone. I use the Heirloom version of ed. Anyways, I wondered about the possibility to give multiple addresses ... more than two for relative address searches. For example, to print the context of the first occurance of `argv' within the main function, you can use: /^main(/;/\/-2;+4n For the last occurance it's even one level more: /^main(/;/^}/;?\?-2;+4n (The semicolons mean that the next search or relative addressing starts at the result of the previous one. I.e. in this case: We go to the `main' function, from there go to the function end, then backwards to `argv' minus two lines and print (with line numbers) this line and four lines more.) The manpage of 6th Edition mentiones this possibility to give more than two addresses: Commands may require zero, one, or two addresses. Commands which require no addresses regard the presence of an address as an error. Commands which accept one or two addresses assume default addresses when insufficient are given. If more addresses are given than such a command requires, the last one or two (depending on what is accepted) are used. http://man.cat-v.org/unix-6th/1/ed You can see it in the sources as well: https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/ed.c (Search for ';' to find the line. There's a loop processing the addresses.) V5 ed(1) is in assembler, however, which I cannot read. Thus there must have been a complete rewrite, maybe introducing this feature at that point. (I don't know where to find v5 manpage to check that as well.) I wonder how using multiple addresses for setting starting points for relative searches came to be. When was it implemented and what use cases drove this features back in the days? Or was it more an accident that was introduced by the implementation, which turned out to be useful? Or maybe it existed already in earlier versions of ed, althoug maybe undocumented. For reference, POSIX writes: Commands accept zero, one, or two addresses. If more than the required number of addresses are provided to a command that requires zero addresses, it shall be an error. Otherwise, if more than the required number of addresses are provided to a command, the addresses specified first shall be evaluated and then discarded until the maximum number of valid addresses remain, for the specified command. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html Here more explanation rom the rationale section: Any number of addresses can be provided to commands taking addresses; for example, "1,2,3,4,5p" prints lines 4 and 5, because two is the greatest valid number of addresses accepted by the print command. This, in combination with the delimiter, permits users to create commands based on ordered patterns in the file. For example, the command "3;/foo/;+2p" will display the first line after line 3 that contains the pattern foo, plus the next two lines. Note that the address "3;" must still be evaluated before being discarded, because the search origin for the "/foo/" command depends on this. As far as I can see, multiple addresses make only sense with the semicolon separator, because the comma separator does not change the state, thus previous addresses can have no effect on later addresses. The implementation just does not forbid them, for simplicity reasons. meillo From meillo at marmaro.de Fri Jul 8 18:09:47 2022 From: meillo at marmaro.de (markus schnalke) Date: Fri, 08 Jul 2022 10:09:47 +0200 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: <1o9ihZ-3C2-00@marmaro.de> References: <1o9ihZ-3C2-00@marmaro.de> Message-ID: <1o9j3b-3aR-00@marmaro.de> Hoi, now I did find nroff sources to the manpages of earlier editions -- still learning about the organization of the code on the TUHS website. Already in the 1st Edition the ed(1) manpage writes: Commands may require zero, one, or two addresses. Commands which require no addresses regard the presence of an address as an error. Commands which require the presence of one address all assume a default address (often ".") but if given more than one address ignore any extras and use the last given. Commands which require two addresses have defaults in the case of zero or one address but use the last two if more than two are given. Hence this features was already present from the beginning. My question must thus shift to QED: Was it present there as well or was it newly introduced to ed? As it is not listed as a differences to QED, it seems to have been taken from there unchanged. My interest in general use cases and stories around the feature is still present. ;-) meillo [2022-07-08 09:47] markus schnalke > > Hoi, > > via a recent message from Chris Pinnock to the list I became aware > of the book ``Ed Mastery'' by Michael W. Lucas. At once I bought > and read it. Although it is not on the mastery level it claims and > I would have liked it to be, it still was fun to read. > > This brought me back to my ed interest. I like ed a lot and despite > my young age, I've actually programmed with ed for fun and have > prepared the troff slides for a talk on early Unix tools (like ed) > with ed alone. I use the Heirloom version of ed. > > Anyways, I wondered about the possibility to give multiple > addresses ... more than two for relative address searches. > > For example, to print the context of the first occurance of `argv' > within the main function, you can use: > > /^main(/;/\/-2;+4n > > For the last occurance it's even one level more: > > /^main(/;/^}/;?\?-2;+4n > > (The semicolons mean that the next search or relative addressing > starts at the result of the previous one. I.e. in this case: We go > to the `main' function, from there go to the function end, then > backwards to `argv' minus two lines and print (with line numbers) > this line and four lines more.) > > > The manpage of 6th Edition mentiones this possibility to give more > than two addresses: > > Commands may require zero, one, or two addresses. Commands > which require no addresses regard the presence of an address > as an error. Commands which accept one or two addresses > assume default addresses when insufficient are given. If > more addresses are given than such a command requires, the > last one or two (depending on what is accepted) are used. > > http://man.cat-v.org/unix-6th/1/ed > > You can see it in the sources as well: > https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/ed.c > (Search for ';' to find the line. There's a loop processing the > addresses.) > > V5 ed(1) is in assembler, however, which I cannot read. Thus there > must have been a complete rewrite, maybe introducing this feature > at that point. (I don't know where to find v5 manpage to check > that as well.) > > > I wonder how using multiple addresses for setting starting points > for relative searches came to be. When was it implemented and what > use cases drove this features back in the days? Or was it more an > accident that was introduced by the implementation, which turned > out to be useful? Or maybe it existed already in earlier versions > of ed, althoug maybe undocumented. > > > > > For reference, POSIX writes: > > Commands accept zero, one, or two addresses. If more than the > required number of addresses are provided to a command that > requires zero addresses, it shall be an error. Otherwise, if more > than the required number of addresses are provided to a command, > the addresses specified first shall be evaluated and then discarded > until the maximum number of valid addresses remain, for the > specified command. > > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html > > Here more explanation rom the rationale section: > > Any number of addresses can be provided to commands taking > addresses; for example, "1,2,3,4,5p" prints lines 4 and 5, because > two is the greatest valid number of addresses accepted by the print > command. This, in combination with the delimiter, > permits users to create commands based on ordered patterns in the > file. For example, the command "3;/foo/;+2p" will display the first > line after line 3 that contains the pattern foo, plus the next two > lines. Note that the address "3;" must still be evaluated before > being discarded, because the search origin for the "/foo/" command > depends on this. > > As far as I can see, multiple addresses make only sense with the > semicolon separator, because the comma separator does not change > the state, thus previous addresses can have no effect on later > addresses. The implementation just does not forbid them, for > simplicity reasons. > > > > meillo > From douglas.mcilroy at dartmouth.edu Fri Jul 8 23:23:14 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 8 Jul 2022 09:23:14 -0400 Subject: [TUHS] ed: multiple addresses (with semicolons) Message-ID: The interpretation of a string of addresses separated by commas and/or semicolons was already defined in the v1 man page for ed. Ed was essentially a stripped-down version of Multics qed. The latter was originally written by Ken. Unfortunately the "Multics Condensed Guide" online at multicians.org describes how strings of addresses were interpreted only by canonical examples for the various editing requests. I have no specific memory of semicolons in qed. I have a vague recollection that semicolons originated in ed, however you should put no trust in this. Maybe Ken remembers. Doug From kenbob at gmail.com Sat Jul 9 02:01:43 2022 From: kenbob at gmail.com (Ken Thompson) Date: Fri, 8 Jul 2022 09:01:43 -0700 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: References: Message-ID: On Fri, Jul 8, 2022 at 6:24 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > The interpretation of a string of addresses separated by commas and/or > semicolons was already defined in the v1 man page for ed. > > Ed was essentially a stripped-down version of Multics qed. The latter > was originally > written by Ken. Unfortunately the "Multics Condensed Guide" online at > multicians.org describes how strings of addresses were interpreted > only by canonical examples for the various editing requests. > > I have no specific memory of semicolons in qed. I have a vague > recollection that semicolons originated in ed, however you should put > no trust in this. Maybe Ken remembers. > > Doug > String of addresses was same for qed and ed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From meillo at marmaro.de Sat Jul 9 05:13:17 2022 From: meillo at marmaro.de (markus schnalke) Date: Fri, 08 Jul 2022 21:13:17 +0200 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: References: Message-ID: <1o9tPh-48W-00@marmaro.de> Hoi, thanks for your replies, Doug and Ken. Unfortunately I wasn't able to find the ``Multics Condensed Guide'' on multicians.org. Can someone please provide a link? Interrestingly, I discovered that qed had double quotes (") as a comment command, which simply ignores the rest of the line. As far as I know, there's no way to comment ed scripts. Why was that dropped? In ex(1) the " comment command reappeared. I've always wondered why it used this character for comments. Seems it comes from qed, leaping over ed, but reappearing in ex. meillo [2022-07-08 09:01] Ken Thompson > On Fri, Jul 8, 2022 at 6:24 AM Douglas McIlroy > wrote: > > The interpretation of a string of addresses separated by commas and/or > semicolons was already defined in the v1 man page for ed. > > Ed was essentially a stripped-down version of Multics qed. The latter > was originally > written by Ken. Unfortunately the "Multics Condensed Guide" online at > multicians.org describes how strings of addresses were interpreted > only by canonical examples for the various editing requests. > > I  have no specific memory of semicolons in qed. I have a vague > recollection that semicolons originated in ed, however you should put > no trust in this. Maybe Ken remembers. > > Doug > > String of addresses was same for qed and ed. > From douglas.mcilroy at dartmouth.edu Sat Jul 9 07:36:18 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 8 Jul 2022 17:36:18 -0400 Subject: [TUHS] ed: multiple addresses (with semicolons) Message-ID: > I wasn't able to find the ``Multics Condensed Guide'' on multicians.org multicians.org points to http://www.bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condensed-guide.pdf It also has https://www.multicians.org/mspm/bx-9-06.681115.qed-editor.pdf Amusingly, the "condensed guide" is many pages longer than the MSPM (Multics system programmer's manual--the gospel) Neither tells about extra address fields or semicolons > In ex(1) the " comment command reappeared. And in sed the y command reappeared. Doug From tuhs at tuhs.org Sat Jul 9 08:58:10 2022 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sat, 9 Jul 2022 08:58:10 +1000 Subject: [TUHS] Documents for UNIX Collections Message-ID: All, Matt e-mailed this to me and the TUHS list, but it doesn't seem to have made it through so I'm punting on a copy ... Warren ----- Forwarded message from Matt Gilmore ----- Subject: Documents for UNIX Collections Good afternoon everyone, my name is Matt Gilmore, and I recently worked with some folks here to help facilitate the scanning and release of the "Documents for UNIX" package as well as a few odds and ends pertinent to UNIX/TS 4.0. I've been researching pretty heavily the history of published memoranda and how they ultimately became the formal documents that Western Electric first published with UNIX/TS 5.0 and System V. Think the User's Guide, Graphics Guide, etc. In my research, I've found that document sets in a similar spirit have been published since at least Research Version 6. I've been able to track down a few that are on the TUHS source archive in original *ROFF format (Links given as path in the tree to avoid hyperlink mangling): Research V6: V6/usr/doc Mini-UNIX: Mini-Unix/usr/doc PWB/UNIX 1.0: PWB1/usr/man/man0/documents (note, I'm not sure where the actual docs are, this is just a TOC, Operators Manual is in op in the base man folder) Wollongong 7/32 Version: Interdata732/usr/doc (only 7/32 relevant docs, allegedly) Research V7: V7/usr/doc UNIX/32V: 32V/usr/doc There are probably others, but these are the ones I'm aware of on the archive for Bell-aligned revisions prior to the commercialization of UNIX/TS as System III. On the note of System III, I seem to have an archive that is slightly different than what is on TUHS, namely in that it has this same documents collection. I can't find it in the System III section on the site, so I'm assuming it isn't hosted anywhere presently. One of the projects I'm working on (slowly) is comparing these documents with the 4.0 docs I scanned for Arnold and making edits to the *ROFF sources with the hopes I could then use them to produce 1:1 clean copies of the 4.0 docs, while providing an easy means for diff'ing the documents as well (to flush out changes between 3.0 and 4.0). Happy to provide this dump to Warren for comparison with what is currently hosted. Usenix also published documentation sets for 4.2 and 4.3BSD in the 80's which served the same purpose for BSD users. There seems to be a 4.4BSD set as well, although I haven't looked at these yet, I've got a random smattering between 4.2 and 4.3 of the comb-bound Usenix manuals, but I assume the 4.4 set is in a similar vein, with reference guides and supplementary documents. Looks like a lot of the same, but with added documents regarding developments at Berkeley. Now for my reasons for mailing, there are a couple: 1. Is anyone aware of whether similar document sets were compiled for MERT, UNIX/RT, USG Program Generic, or CB-UNIX? Or would users of those systems have simply been referred to the collection most closely matching the version they're forked from? 2. Was there ever any such document set published in this nature as "Documents for UNIX" consistent of memoranda for 5.0/System V? Or did USG immediately begin by providing just the published trade manuals? The implication here is if USG published no such documents, then the Documents for UNIX 4.0 represents the last time USG compiled the memoranda as they were written (of course with version-related edits) with original authorship and references as a documentation set. 3. Have there been any known efforts to analyze the history and authorship of these documents, explicitly denote errata and revisions, and map out the evolution of the system from a documentation perspective like this? Thanks for any insight anyone can provide! - Matt G. P.S. I'd be interested in doing more preservation work, if anyone else has documents that need preserving, I'll happily coordinate shipment and scanning. P.P.S. Ccing Warren, I don't know if I'm able to send emails to this list or not, so pardon the extraneous email if not necessary. ----- End forwarded message ----- From g.branden.robinson at gmail.com Sat Jul 9 10:40:14 2022 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 8 Jul 2022 19:40:14 -0500 Subject: [TUHS] Retypesetting Unix documents (was: Documents for UNIX Collections) In-Reply-To: References: Message-ID: <20220709004014.jakdxeqmpsvwrlvj@illithid> [not CCing Matt because his address didn't come through to the list] Hi Matt, At 2022-07-09T08:58:10+1000, Warren Toomey via TUHS wrote: > ----- Forwarded message from Matt Gilmore ----- > > Subject: Documents for UNIX Collections > > Good afternoon everyone, my name is Matt Gilmore, and I recently > worked with some folks here to help facilitate the scanning and > release of the "Documents for UNIX" package as well as a few odds and > ends pertinent to UNIX/TS 4.0. I've been researching pretty heavily > the history of published memoranda and how they ultimately became the > formal documents that Western Electric first published with UNIX/TS > 5.0 and System V. Think the User's Guide, Graphics Guide, etc. That's excellent work--thank you for doing it! > One of the projects I'm working on (slowly) is comparing these > documents with the 4.0 docs I scanned for Arnold and making edits to > the *ROFF sources with the hopes I could then use them to produce 1:1 > clean copies of the 4.0 docs, while providing an easy means for > diff'ing the documents as well (to flush out changes between 3.0 and > 4.0). Are you using groff to do your rendering? If so, please consider me a resource; I've been the most active groff developer for the past 4 years. (I am, however, not the release manager--we're feeling heavily pregnant with groff 1.23, 3.5 years in the making.) Some of the following issues may be familiar to you; I apologize if I wear a rut in well-trodden ground here. I am wondering what you mean by "1:1 clean copies". I embarked on a similar exercise only about a week ago with the Kernighan & Cherry document "Typesetting Mathematics -- User's Guide (Second Edition)", which was part of Volume 2 of the V7 Unix Programmer's Manual. In the course of that effort I learned several things. I identified (and fixed) bugs in groff's ms(7) implementation, and to my surprise also discovered one in, apparently, V7 troff that caused an equation at the bottom of a column to go missing. Because groff was independently developed, the equation sprung back to life in its rendering. You can find a narrative of my experiences at the following thread, along with commentary from others. https://lists.gnu.org/archive/html/groff/2022-07/msg00000.html Pixel-perfect matching of C/A/T (or APS-5, etc.) output will be impossible because the fonts are different. More than that, the font _metrics_ are different, which means lines will not always fill the same when comparing historical typesetter output and a modern implementation's (this will be true even if you use Heirloom Doctools Troff, which is descended from V7 Unix, but has seen many changes over the years, starting with Kernighan's revision for device-independence ca. 1980, plus many changes for the commercial Documenter's Workbench product, and then many more by Gunnar Ritter and his successors in the Heirloom project). Beyond that, Unix troff and groff use different hyphenation systems. I don't know how stable Unix troff's was over time. All of that said, with the Kernighan and Cherry document, by spending just a few minutes eyeballing old scans and groff PostScript output, flicking between two fullscreen viewers like an ersatz blink comparator, and using binary search to tweak the ms(7) LL, PO, and MINGW registers, I was able to _almost_ perfectly match column and page breaks between the two renderings, which was a higher fidelity of reproduction than I expected. The risen equation noted above was the most dramatic change. Encouraged by that experience, I also reset the V7 Unix version of the article "A System for Typesetting Mathematics". This apparently was _not_ published in the Programmer's Manual, possibly because much of its content was duplicated in the user's guide. But the amount of effort required of me was shockingly low. On the other hand, for this I didn't have an authentically typeset copy to compare to, so all I did was look for what I would consider rendering errors as opposed to cosmetic changes. (Maybe this the standard you want to apply in your own work?) I'm attaching a diff. Another apparent difference arises between V7 Unix eqn and groff eqn; in eqn input such as "lim from {x-> pi /2} ( tan~x) sup{sin~2x}~=~1", V7 eqn will recognize "->" as beginning a new token and convert it to a right arrow glyph in the output, despite the manual (as I understand it) implying that it won't. groff eqn _does_ require token separation in this case. I say that differences are "apparent", rather than making the stronger claim of outright bugs in V7 Unix tools mainly because I don't have a cat2dit(1) tool I can run in my V7 Unix environment in SIMH. In my opinion such a tool (in K&R C, of course) would be well worth having. Right now, to satisfy myself of V7 Unix troff behavior I have to produce an octal dump of the typesetter output, pull it out of the emulation environment with copy-and-paste, undump it with a custom program (xxd is not helpful), and then give the reconstructed C/A/T stream to an interpreter written by John Garder in JavaScript. John's tool (and his personal assistance) has proven invaluable, but it's a component of a larger project of his that renders device-independent troff output in a Web browser window. For this to be practical he has to introduce additional device-independent troff commands into the output. I'd prefer something more rabidly puritan (and, if I'm honest, something written in a more traditional Unix system programming language). https://github.com/Alhadis/Roff.js/ The big advantage of a V7 Unix/PDP-11 cat2dit(1) would be that device-independent troff output is plain text and much easier to spirit out of the emulated environment to the host system. Also, some people, who may be pitied, have taught themselves to read it, making more observations possible and hypotheses testable within the PDP-11 environment. (In principle, this is also true of C/A/T command streams, whether raw or octal-encoded, but I'll just let the pity roll downhill.) Thanks largely to Henry Spencer, the information to write a new cat2dit(1) from scratch is available. Eventually, if no one else does so, I will undertake it myself; but my queue is deep (mostly with groff defect reports and feature requests). https://github.com/Alhadis/otroff/blob/92683053f9aad5b926fc447843bf2092ad59cebf/cat.5 Dan Plassche pointed me toward Adobe Transcript, but my understanding is that it falls short of my needs in 3 ways: it produces PostScript, which I can't easily read, not device-independent troff output (which I can); it's not available in a version ready to run in a modern Unix environment; and it has a licensing encumbrance. I'd like a cat2dit(1) we can all trade around libre and gratis. Alternatively, if someone leaked the troff sources from UNIX/TS 4.0, that would bring a grin of Jack Nicholsonian proportions to my face. That should be buildable in vivo on a PDP-11 and would facilitate much other historical research besides. (With it, someone could annotate a diff of the troff/nroff source trees between V7 and UNIX/TS 4.0, which I wager constitutes a highly positive and teachable moment in software design and engineering.) Okay, brain dump terminated. Please let me know if I can help. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: eqn.diff Type: text/x-diff Size: 10526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From sjenkin at canb.auug.org.au Sat Jul 9 18:10:46 2022 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Sat, 9 Jul 2022 18:10:46 +1000 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: <1o9tPh-48W-00@marmaro.de> References: <1o9tPh-48W-00@marmaro.de> Message-ID: > On 9 Jul 2022, at 05:13, markus schnalke wrote: > > Unfortunately I wasn't able to find the ``Multics Condensed Guide'' > on multicians.org. Can someone please provide a link? Couldn’t find the Condensed Guide on the Multicians site. There was a thread on QED, October 2018 Starts here: This message has the bitsavers link at end: This from O.P. QED editor - thanks! Tracking through the thread, there’s software & git repos. HTH steve =========== On the Multician site, there was information about qedx - a reimplementation, if I read correctly. Ken is noted as the author of QED, but no docs are linked. Dev Docs Library • AW17: Multics Commands and Active Functions pocket guide (101K, 04/01/80, posted 12/18/21) • AG91: Multics Programmers' Manual: Reference Guide Table of Contents (128K, 1984, posted 04/27/21) • Multics System Programmer's Manual Table of Contents (224K, posted 06/05/22, 838 sections, 821 online) Early Multics Development and the MSPM • BX.9.06 qed Text Editor, 11/15/68, K. L. Thompson QED CTSS editor written by Ken Thompson. This line-oriented editor was influenced by the character-oriented QED editor on the SDS-940; one of Ken's major additions was regular expression searching and substitution. Ported to Multics BCPL by Ken and Dennis Ritchie. Bob Daley then wrote Multics qedx as a less functional but faster version. Both qed and qedx are programmable: they support multiple buffers, and a user can execute the contents of a buffer containing editor commands. Doug McIlroy wrote a version of tic-tac-toe in qed. Qedx was the standard editor for most of the Multics development community throughout the 70s. Info segment for qedx command See ted. [BSG] The qedx language was unambiguously optimized for interactive line-editing, not programming, thus writing non-trivial QEDX "macros" (programs) was a black art whose results where very ugly and non-maintainable and often bordered on black humor. Compare TECO. ted, adding many more commands, is one direction of solution. edm, having no programming language, is another. [perl, with no editing language, is another point on the scale -- THVV] Having entirely distinct command and extension languages is now almost universally considered to be the correct solution to problems of this sort (e.g., Emacs). [THVV] A nice history of QED, its descendants, and the use of regular expressions is in Russ Cox's article. Russ Cox Regular Expression Matching Can Be Simple And Fast qedx Info page 03/03/83 qedx, qx Syntax: qx {-control_args} {macro_path} {macro_args} Function: The qedx editor is used to create and edit ASCII segments. This description summarizes the editing requests and addressing features provided by qedx. Complete tutorial information on qedx is available in the qedx Text Editor Users' Guide, Order No. CG40. [linked from Multician biblio page] - not QED, qedx MULTICS qedx TEXT EDITOR USER'S GUIDE =========== Page: V1-2 Rev 2 06019 TEXT ADDRESSING QED accepts commands and text as a stream of characters from the console. Text within the current buffer is specified by (1) line addresses or (2) strings (regular-expressions) in the text 1 ine. Lines in the current buffer may be addressed in the following ways: 1. by current line number 2. by absolute line number 3. by the value of the current line (".") 4. by the special character (“$”) 5. by context 6. by additive combinations of methods 1. to 5. =========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From robpike at gmail.com Sat Jul 9 18:22:27 2022 From: robpike at gmail.com (Rob Pike) Date: Sat, 9 Jul 2022 18:22:27 +1000 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: References: <1o9tPh-48W-00@marmaro.de> Message-ID: Wasn't quick enough to grab a photo, but saw a car today with the license plate reading ED 8080 including the space. -rob On Sat, Jul 9, 2022 at 6:11 PM steve jenkin wrote: > > > > On 9 Jul 2022, at 05:13, markus schnalke wrote: > > > > Unfortunately I wasn't able to find the ``Multics Condensed Guide'' > > on multicians.org. Can someone please provide a link? > > Couldn’t find the Condensed Guide on the Multicians site. > > There was a thread on QED, October 2018 > > > Starts here: > > > This message has the bitsavers link at end: > > > This from O.P. > > QED editor - thanks! > < > https://minnie.tuhs.org/pipermail/tuhs/2018-October/016619.html> > > Tracking through the thread, there’s software & git repos. > > HTH > steve > > =========== > > On the Multician site, there was information about qedx - a > reimplementation, if I read correctly. > Ken is noted as the author of QED, but no docs are linked. > > Dev Docs Library > > • AW17: Multics Commands and Active Functions pocket guide (101K, > 04/01/80, posted 12/18/21) > • AG91: Multics Programmers' Manual: Reference Guide Table of > Contents (128K, 1984, posted 04/27/21) > • Multics System Programmer's Manual Table of Contents (224K, > posted 06/05/22, 838 sections, 821 online) > > > Early Multics Development and the MSPM > > • BX.9.06 qed Text Editor, 11/15/68, K. L. Thompson > > > > > QED > CTSS editor written by Ken Thompson. This line-oriented editor was > influenced by the character-oriented QED editor on the SDS-940; one of > Ken's major additions was regular expression searching and substitution. > Ported to Multics BCPL by Ken and Dennis Ritchie. Bob Daley then wrote > Multics qedx as a less functional but faster version. Both qed and qedx are > programmable: they support multiple buffers, and a user can execute the > contents of a buffer containing editor commands. Doug McIlroy wrote a > version of tic-tac-toe in qed. Qedx was the standard editor for most of the > Multics development community throughout the 70s. Info segment for qedx > command See ted. > > [BSG] The qedx language was unambiguously optimized for interactive > line-editing, not programming, thus writing non-trivial QEDX "macros" > (programs) was a black art whose results where very ugly and > non-maintainable and often bordered on black humor. Compare TECO. ted, > adding many more commands, is one direction of solution. edm, having no > programming language, is another. [perl, with no editing language, is > another point on the scale -- THVV] Having entirely distinct command and > extension languages is now almost universally considered to be the correct > solution to problems of this sort (e.g., Emacs). > > [THVV] A nice history of QED, its descendants, and the use of regular > expressions is in Russ Cox's article. > > > Russ Cox > Regular Expression Matching Can Be Simple And Fast > > > > qedx Info page > < > https://web.mit.edu/multics-history/source/Multics/doc/info_segments/qedx.info > > > 03/03/83 qedx, qx > > Syntax: qx {-control_args} {macro_path} {macro_args} > > > Function: The qedx editor is used to create and edit ASCII > segments. > This description summarizes the editing requests and addressing > features provided by qedx. Complete tutorial information on qedx > is > available in the qedx Text Editor Users' Guide, Order No. CG40. > > > [linked from Multician biblio page] - not QED, qedx > > > MULTICS > qedx TEXT EDITOR USER'S GUIDE > < > http://www.bitsavers.org/pdf/honeywell/multics/CG40-01_qedx_Feb83.pdf> > > > =========== > > < > http://www.bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condensed-guide.pdf > > > > Page: V1-2 Rev 2 06019 > > TEXT ADDRESSING > > QED accepts commands and text as a stream of characters from the console. > Text within the current buffer is specified by (1) line addresses or (2) > strings (regular-expressions) in the text 1 ine. > > Lines in the current buffer may be addressed in the following ways: > 1. by current line number > 2. by absolute line number > 3. by the value of the current line (".") > 4. by the special character (“$”) > 5. by context > 6. by additive combinations of methods 1. to 5. > > =========== > > -- > Steve Jenkin, IT Systems and Design > 0412 786 915 (+61 412 786 915) > PO Box 38, Kippax ACT 2615, AUSTRALIA > > mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Jul 10 01:57:50 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 09 Jul 2022 15:57:50 +0000 Subject: [TUHS] Retypesetting Unix documents (was: Documents for UNIX Collections) In-Reply-To: <20220709004014.jakdxeqmpsvwrlvj@illithid> References: <20220709004014.jakdxeqmpsvwrlvj@illithid> Message-ID: Thanks for all of the background Branden. I would be using Groff so this is all very valuable information, I'm glad someone with expertise is watching! I have already noticed the differences in width, but haven't looked to far into it yet. The effort would likely involve two phases: one to apply changes to the 3.0 docs to match the content of 4.0, then once the content is updated, the remaining matter is formatting consistency (as much as possible) with the typeset documents we have scans of. If it ain't perfect, that's alright. The implication would be that the original 3.0 documents on the Autologic system would be formatted similarly, so the edits would produce *ROFF input that, back then, would spit these documents out. Perhaps identical typesetting would be a bit ambitious, but failing that, content modification shouldn't be as difficult. Plus, processing the 3.0 docs today with Groff would produce documents with the same alignment, so for comparison purposes it'd all still be very useful. Thanks again for the reply, I'll have to reach out when I'm more regularly working on this again, work and summer have been my primary time sinks lately :) - Matt G. ------- Original Message ------- On Friday, July 8th, 2022 at 5:40 PM, G. Branden Robinson wrote: > [not CCing Matt because his address didn't come through to the list] > > Hi Matt, > > At 2022-07-09T08:58:10+1000, Warren Toomey via TUHS wrote: > > > ----- Forwarded message from Matt Gilmore ----- > > > > Subject: Documents for UNIX Collections > > > > Good afternoon everyone, my name is Matt Gilmore, and I recently > > worked with some folks here to help facilitate the scanning and > > release of the "Documents for UNIX" package as well as a few odds and > > ends pertinent to UNIX/TS 4.0. I've been researching pretty heavily > > the history of published memoranda and how they ultimately became the > > formal documents that Western Electric first published with UNIX/TS > > 5.0 and System V. Think the User's Guide, Graphics Guide, etc. > > > That's excellent work--thank you for doing it! > > > One of the projects I'm working on (slowly) is comparing these > > documents with the 4.0 docs I scanned for Arnold and making edits to > > the *ROFF sources with the hopes I could then use them to produce 1:1 > > clean copies of the 4.0 docs, while providing an easy means for > > diff'ing the documents as well (to flush out changes between 3.0 and > > 4.0). > > > Are you using groff to do your rendering? If so, please consider me a > resource; I've been the most active groff developer for the past 4 > years. (I am, however, not the release manager--we're feeling heavily > pregnant with groff 1.23, 3.5 years in the making.) > > Some of the following issues may be familiar to you; I apologize if I > wear a rut in well-trodden ground here. > > I am wondering what you mean by "1:1 clean copies". I embarked on a > similar exercise only about a week ago with the Kernighan & Cherry > document "Typesetting Mathematics -- User's Guide (Second Edition)", > which was part of Volume 2 of the V7 Unix Programmer's Manual. > > In the course of that effort I learned several things. I identified > (and fixed) bugs in groff's ms(7) implementation, and to my surprise > also discovered one in, apparently, V7 troff that caused an equation at > the bottom of a column to go missing. Because groff was independently > developed, the equation sprung back to life in its rendering. You can > find a narrative of my experiences at the following thread, along with > commentary from others. > > https://lists.gnu.org/archive/html/groff/2022-07/msg00000.html > > Pixel-perfect matching of C/A/T (or APS-5, etc.) output will be > impossible because the fonts are different. More than that, the font > metrics are different, which means lines will not always fill the same > when comparing historical typesetter output and a modern > implementation's (this will be true even if you use Heirloom Doctools > Troff, which is descended from V7 Unix, but has seen many changes over > the years, starting with Kernighan's revision for device-independence > ca. 1980, plus many changes for the commercial Documenter's Workbench > product, and then many more by Gunnar Ritter and his successors in the > Heirloom project). > > Beyond that, Unix troff and groff use different hyphenation systems. I > don't know how stable Unix troff's was over time. > > All of that said, with the Kernighan and Cherry document, by spending > just a few minutes eyeballing old scans and groff PostScript output, > flicking between two fullscreen viewers like an ersatz blink comparator, > and using binary search to tweak the ms(7) LL, PO, and MINGW registers, > I was able to almost perfectly match column and page breaks between > the two renderings, which was a higher fidelity of reproduction than I > expected. The risen equation noted above was the most dramatic change. > > Encouraged by that experience, I also reset the V7 Unix version of the > article "A System for Typesetting Mathematics". This apparently was > not published in the Programmer's Manual, possibly because much of its > content was duplicated in the user's guide. But the amount of effort > required of me was shockingly low. On the other hand, for this I didn't > have an authentically typeset copy to compare to, so all I did was look > for what I would consider rendering errors as opposed to cosmetic > changes. (Maybe this the standard you want to apply in your own work?) > I'm attaching a diff. > > Another apparent difference arises between V7 Unix eqn and groff eqn; in > eqn input such as "lim from {x-> pi /2} ( tan~x) sup{sin~2x}~=~1", V7 > > eqn will recognize "->" as beginning a new token and convert it to a > > right arrow glyph in the output, despite the manual (as I understand it) > implying that it won't. groff eqn does require token separation in > this case. > > I say that differences are "apparent", rather than making the stronger > claim of outright bugs in V7 Unix tools mainly because I don't have a > cat2dit(1) tool I can run in my V7 Unix environment in SIMH. In my > opinion such a tool (in K&R C, of course) would be well worth having. > Right now, to satisfy myself of V7 Unix troff behavior I have to produce > an octal dump of the typesetter output, pull it out of the emulation > environment with copy-and-paste, undump it with a custom program (xxd is > not helpful), and then give the reconstructed C/A/T stream to an > interpreter written by John Garder in JavaScript. John's tool (and his > personal assistance) has proven invaluable, but it's a component of a > larger project of his that renders device-independent troff output in a > Web browser window. For this to be practical he has to introduce > additional device-independent troff commands into the output. I'd > prefer something more rabidly puritan (and, if I'm honest, something > written in a more traditional Unix system programming language). > > https://github.com/Alhadis/Roff.js/ > > The big advantage of a V7 Unix/PDP-11 cat2dit(1) would be that > device-independent troff output is plain text and much easier to spirit > out of the emulated environment to the host system. Also, some people, > who may be pitied, have taught themselves to read it, making more > observations possible and hypotheses testable within the PDP-11 > environment. (In principle, this is also true of C/A/T command streams, > whether raw or octal-encoded, but I'll just let the pity roll downhill.) > > Thanks largely to Henry Spencer, the information to write a new > cat2dit(1) from scratch is available. Eventually, if no one else does > so, I will undertake it myself; but my queue is deep (mostly with groff > defect reports and feature requests). > > https://github.com/Alhadis/otroff/blob/92683053f9aad5b926fc447843bf2092ad59cebf/cat.5 > > Dan Plassche pointed me toward Adobe Transcript, but my understanding is > that it falls short of my needs in 3 ways: it produces PostScript, which > I can't easily read, not device-independent troff output (which I can); > it's not available in a version ready to run in a modern Unix > environment; and it has a licensing encumbrance. I'd like a cat2dit(1) > we can all trade around libre and gratis. > > Alternatively, if someone leaked the troff sources from UNIX/TS 4.0, > that would bring a grin of Jack Nicholsonian proportions to my face. > That should be buildable in vivo on a PDP-11 and would facilitate much > other historical research besides. (With it, someone could annotate a > diff of the troff/nroff source trees between V7 and UNIX/TS 4.0, which I > wager constitutes a highly positive and teachable moment in software > design and engineering.) > > Okay, brain dump terminated. Please let me know if I can help. > > Regards, > Branden From nobozo at gmail.com Sun Jul 10 13:50:06 2022 From: nobozo at gmail.com (Jon Forrest) Date: Sat, 9 Jul 2022 20:50:06 -0700 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: References: <1o9tPh-48W-00@marmaro.de> Message-ID: On 7/9/2022 1:22 AM, Rob Pike wrote: > Wasn't quick enough to grab a photo, but saw a car today with the > license plate reading > > ED 8080 This is slightly off topic but back in the 80s I saw a license plate reading IEFBR14 This won't mean anything to you unless you've used IBM software. Jon From aap at papnet.eu Sun Jul 10 19:25:19 2022 From: aap at papnet.eu (Angelo Papenhoff) Date: Sun, 10 Jul 2022 11:25:19 +0200 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: References: Message-ID: On 08/07/22, Douglas McIlroy wrote: > Ed was essentially a stripped-down version of Multics qed. The latter > was originally written by Ken. Does anyone know if this version has survived? Current Multics has qedx, but it seems to be a stripped down version of qed as well. In fact I find Unix ed nicer to use than qedx. And a question about pronunciation: I've heard qedx pronounced as "queddix" and I know ed is "ee dee". What about qed? aap From ralph at inputplus.co.uk Sun Jul 10 19:59:43 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 10 Jul 2022 10:59:43 +0100 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: References: Message-ID: <20220710095943.D8455220F9@orac.inputplus.co.uk> Hi Angelo, > What about qed? I've assumed it was deliberately named after ‘Q.E.D.’ and so read as individual letters. https://en.wiktionary.org/wiki/Q.E.D.#English -- Cheers, Ralph. From meillo at marmaro.de Tue Jul 12 00:40:45 2022 From: meillo at marmaro.de (markus schnalke) Date: Mon, 11 Jul 2022 16:40:45 +0200 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: References: Message-ID: <1oAuab-7jq-00@marmaro.de> Hoi, thanks to everyone helping me with links. As you already mentioned: [2022-07-08 23:36] Douglas McIlroy > > Neither tells about extra address fields or semicolons The best I could find was this paper by DMR: https://www.bell-labs.com/usr/dmr/www/qedman.html There he writes: Sequences of two or more addresses are separated either by "," or by ";". In the latter case "." is set to the preceding address before the succeeding address is evaluated. The semicolon is used mostly to control the starting line for context searches. Later in the bootstrapping explanation appears a command with an address chain: O;/./;.mf "move filename (if there) to bf I couldn't really understand this stuff. It seems to be specific to this version of qed and the underlying operating system. Nevermind, this leaves my focus of interest. More was I curious about the documentation of address chains in books. - ``The Unix Programming Environment'' does neither mention address chains nor semicolon separators. - SRB's ``The Unix System'' (an often overlooked but great book) explains the semicolon separator in a one-paragraph section on page 33. - ``Software Tools'' goes into the most detail that I could find. On pages 170 f. (section 6.2) it explains the semicolon separator and address chains with this example: /#/;//;//;//;//p prints from the third succeeding line containing # to the fourth, inclusive. Right thereafter (pages 172 and 173; section 6.3) the implementation of getlist() -- collect line numbers -- follows, which, as expected, is in a similar style as the actual implementation in Unix at that time (v6): https://www.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/ed.c See function commands() meillo From douglas.mcilroy at dartmouth.edu Tue Jul 12 03:30:56 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 11 Jul 2022 13:30:56 -0400 Subject: [TUHS] ed: multiple addresses (with semicolons) Message-ID: > More was I curious about the documentation of address chains in books. It was even discussed in Lomutu and Lomuto, "A Unix Primer", a pleasant book whose level is accurately described in the title. Doug From gctersteeg at gmail.com Tue Jul 12 05:47:11 2022 From: gctersteeg at gmail.com (Gavin Tersteeg) Date: Mon, 11 Jul 2022 14:47:11 -0500 Subject: [TUHS] LSX issues and musing Message-ID: Hello, and greetings! I guess as this is my first post here, I should give some background on what I have been working on. Last summer I spent a lot of time getting UNIX V6 working on my PDP-11/23 system. It took a lot of tinkering with the kernel and drivers to make it work in the way I wanted to, but in the end I was left with a system that ran well enough to do some demonstrations at VCFMW. This year I want to do more stuff with 1970s era UNIX, but now with even more technical restrictions. I have had a Heathkit H-11 (consumer grade PDP-11/03) for a while now, and I have been looking for something interesting to do with it. From my research, it seems like there were two different UNIX variants that could run on a system like this. These variants were LSX and MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like a RK05 and some porting to work on an 11/03, while LSX is designed to work on exactly the hardware specs that I have on hand. So on to the actual issues I am having at the moment: I have put together a SIMH instance to get the ball rolling in building a kernel that will boot on my EIS-less 11/03, but I am having significant difficulty actually getting the kernel to build. The first issue is that the C compiler will randomly spit out a "0: Missing temp file" when attempting to compile something. This is annoying, but circumventable by just running the same command over and over until it works. The second issue, however, is much more of a road block for me. I can't seem to get the kernel to actually link together once everything is compiled. When the final "ld -X" is executed, I always get the following errors: " Undefined: _end _edata _decmch " (This is from the build script found in the "shlsx" file) https://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/shlsx I am assuming that this is some sort of issue with the object file orderings, but I simply do not know enough about V6 ld to properly debug this issue. I am hoping that somebody here has already run into this issue, and knows what I am doing wrong. If I can get this working, I have a long laundry list of modifications and experiments that I want to run with LSX, but as it stands, this is where I am stuck at. Thank you, Gavin -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jul 12 06:01:47 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 11 Jul 2022 14:01:47 -0600 Subject: [TUHS] LSX issues and musing In-Reply-To: References: Message-ID: On Mon, Jul 11, 2022, 1:48 PM Gavin Tersteeg wrote: > Hello, and greetings! > > I guess as this is my first post here, I should give some u background on > what I have been working on. Last summer I spent a lot of time getting UNIX > V6 working on my PDP-11/23 system. It took a lot of tinkering with the > kernel and drivers to make it work in the way I wanted to, but in the end I > was left with a system that ran well enough to do some demonstrations at > VCFMW. > > This year I want to do more stuff with 1970s era UNIX, but now with even > more technical restrictions. I have had a Heathkit H-11 (consumer grade > PDP-11/03) for a while now, and I have been looking for something > interesting to do with it. From my research, it seems like there were two > different UNIX variants that could run on a system like this. These > variants were LSX and MINI-UNIX. MINI-UNIX seems to require a decent > mass-storage device like a RK05 and some porting to work on an 11/03, while > LSX is designed to work on exactly the hardware specs that I have on hand. > > So on to the actual issues I am having at the moment: I have put together > a SIMH instance to get the ball rolling in building a kernel that will boot > on my EIS-less 11/03, but I am having significant difficulty actually > getting the kernel to build. The first issue is that the C compiler will > randomly spit out a "0: Missing temp file" when attempting to compile > something. This is annoying, but circumventable by just running the same > command over and over until it works. The second issue, however, is much > more of a road block for me. I can't seem to get the kernel to actually > link together once everything is compiled. When the final "ld -X" is > executed, I always get the following errors: > > " > Undefined: > _end > _edata > _decmch > " > (This is from the build script found in the "shlsx" file) > https://minnie.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/shlsx > > I am assuming that this is some sort of issue with the object file > orderings, but I simply do not know enough about V6 ld to properly debug > this issue. I am hoping that somebody here has already run into this issue, > and knows what I am doing wrong. > _end is the end of the text segment. _edata same for the data. You can create these two by just creating a file that defines them as symbols = . And global. And link that file last. Though crt is supposed to have that. _decmch is likely in m.s so maybe that's not included. Iirc it should be next to last... You might already have files with these symbols... nm is your friend here... Warner If I can get this working, I have a long laundry list of modifications and > experiments that I want to run with LSX, but as it stands, this is where I > am stuck at. > > Thank you, > Gavin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jul 12 06:26:57 2022 From: clemc at ccc.com (Clem Cole) Date: Mon, 11 Jul 2022 16:26:57 -0400 Subject: [TUHS] LSX issues and musing In-Reply-To: References: Message-ID: @Warner Losh On Mon, Jul 11, 2022 at 4:03 PM Warner Losh wrote: > > _end is the end of the text segment. _edata same for the data. You can > create these two by just creating a file that defines them as symbols = . > And global. And link that file last. Though crt is supposed to have that. > Hmmm -- I might have miss remembered this... but I'm pretty sure the way ld(1) worked is that it supplied _edata, _etext, and _end automagically by ld(1) IIF, there are no other undefined symbols. Adding them into a file is probably not going to get what you want. > > _decmch is likely in m.s so maybe that's not included. Iirc it should be > next to last... > My bet is this key to the whole issue he is having. If Gavin can figures out what gives WRT _decmch, I bet it links. @Gavin Tersteeg < gctersteeg at gmail.com> -- I would trust Warner's memory more than mine since he tries to keep 2.9BSD alive, but he knows I go back to V5 and the early/mid 70s; but bits in my memory have decayed over the years. Suggestion, take a quick peek in the sources to ld.c and look for it hard coding the check for those three symbols. They will look up as undefined originally, then latter get set to values only if there are no other UNDEFINED symbols. > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Jul 12 06:30:48 2022 From: imp at bsdimp.com (Warner Losh) Date: Mon, 11 Jul 2022 14:30:48 -0600 Subject: [TUHS] LSX issues and musing In-Reply-To: References: Message-ID: On Mon, Jul 11, 2022 at 2:27 PM Clem Cole wrote: > @Warner Losh > > On Mon, Jul 11, 2022 at 4:03 PM Warner Losh wrote: > >> >> _end is the end of the text segment. _edata same for the data. You can >> create these two by just creating a file that defines them as symbols = . >> And global. And link that file last. Though crt is supposed to have that. >> > Hmmm -- I might have miss remembered this... but I'm pretty sure the way > ld(1) worked is that it supplied _edata, _etext, and _end automagically > by ld(1) IIF, there are no other undefined symbols. Adding them into a file > is probably not going to get what you want. > Oh right, _etext, _edata and _end are supposed to be linker creatures (created by the linker), but I can't recall when the linker started doing that... > >> _decmch is likely in m.s so maybe that's not included. Iirc it should be >> next to last... >> > My bet is this key to the whole issue he is having. If Gavin can figures > out what gives WRT _decmch, I bet it links. > That's the area I'd try first... But I'd expect both data and bss symbols to be scattered in many of the other files though... It may be something as simple as an empty .o file from those compiler runs that failed... > @Gavin Tersteeg <+gctersteeg at gmail.com> -- I would trust Warner's memory > more than mine since he tries to keep 2.9BSD alive, but he knows I go back > to V5 and the early/mid 70s; but bits in my memory have decayed over the > years. Suggestion, take a quick peek in the sources to ld.c and look for > it hard coding the check for those three symbols. They will look up as > undefined originally, then latter get set to values only if there are no > other UNDEFINED symbols. > 2.11BSD, but who's counting :) Warner > ᐧ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Tue Jul 12 06:37:43 2022 From: phil at ultimate.com (Phil Budne) Date: Mon, 11 Jul 2022 16:37:43 -0400 Subject: [TUHS] LSX issues and musing In-Reply-To: References: Message-ID: <202207112037.26BKbhKN050709@ultimate.com> A quick google for _decmch found: https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/low.s ..... .if DEC .if EIS-1 .globl _decmch rxcs = 177170 rxdb = 177172 _decmch: mov r2,-(sp) mov $rxdb,r1 mov 4(sp),r0 asl r0 add 4(sp),r0 clr r2 ..... From jnc at mercury.lcs.mit.edu Tue Jul 12 07:06:55 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Jul 2022 17:06:55 -0400 (EDT) Subject: [TUHS] LSX issues and musing Message-ID: <20220711210655.0E7EF18C096@mercury.lcs.mit.edu> It would be really appreciated if people replying to messages like this would take 10 minutes (or so - that's about how lonfg it took me to find the actual answer to this person's question) to do some research, instead of just replying off the top of their heads with whatever they happen to think they know. > From: Gavin Tersteeg > I can't seem to get the kernel to actually link together once > everything is compiled. When the final "ld -X" is executed, I always > get the following errors: > "Undefined: > _end > _edata > _decmch" The first two are automagically defined by the linker after a successful read-through of the files+libraries, i.e. when then are no un-defined symbols. Ignore them; they will go away when you fix the problem. The real issue is the missing 'decmch'. That apparently comes from decfd.c, which I assume is the DEC floppy disk driver. Depending on the setting of the EIS conditional compilation flag (a different one for C files, from the PDP-11 assembler files, please note - and I haven't worked out what its definitiion means; whether if defined, it means the machine _does_ have the EIS, or _does not_x), it will be called for. 'decmch' is in low.s (rather oddly; that usualy holds just interrupt vectors and interrupt toeholds), conditionally assembled on: .if DEC .if EIS-1 The first line presumably adds it if there _is_ a DEC floppy disk, the second I don't know _for sure_ the sense of (although I'm guessing that EIS=1 means there _is_ an EIS chip, so this line says 'assemble if there it _not_ an EIS chip'). Although you'd think that whatever calculation it is doing, it would need to do if there's an EIS chip or not, so with an EIS chip it must calculate it some other way; you'll have to read decfd.c and see how it works. Note that you'll have to make sure the EIS flags (note plural) are set to the same sense, when compiling the C and assembler files... Let me send this off, and I'll reply to some other points in a separate message. Noel From jnc at mercury.lcs.mit.edu Tue Jul 12 07:24:13 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Jul 2022 17:24:13 -0400 (EDT) Subject: [TUHS] LSX issues and musing Message-ID: <20220711212413.29B5618C097@mercury.lcs.mit.edu> > From: Gavin Tersteeg > I spent a lot of time getting UNIX V6 working on my PDP-11/23 system. > It took a lot of tinkering with the kernel and drivers to make it work > in the way I wanted to You must have made a lot of changes for it to take "a lot of tinkering". Bringing V6 up on the /23 has been done several times, and when I did it, it only took about 2 dozen lines of code in about 2 files. What all did you wind up changing? > From my research, it seems like there were two different UNIX variants > that could run on a system like this. These variants were LSX and > MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like > a RK05 and some porting to work on an 11/03, while LSX is designed to > work on exactly the hardware specs that I have on hand. Bringing up MINI-UNIX on the /03 has been done at least twice; once historically (now lost, AFAIK), and again recently: http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html I'm not sure what you're basing the "MINI-UNIX seems to require a decent mass-storage device like a RK05" on - it should run as well on whatever you're running LSX on as LSX does. I haven't run LSX myself, but from what I've seen, the only significant difference between the two is that LSX will run with less main memory than MINI-UNIX (which really kind of needs 56KB; LSX you can probably get away with 40KB).That was a significant issue when the LSI-11 was originally released, but these days one has to really work to have a QBUS PDP-11 with less than 56KB. > my EIS-less 11/03 EIS chips can be found on eBait for not much money (I just bought a couple myself), and it's worth investing in one, so on can dispense with the emulator, which takes real memory for which a better use can be found. > The first issue is that the C compiler will randomly spit out a "0: > Missing temp file" when attempting to compile something. This is > annoying, but circumventable by just running the same command over and > over until it works. Schaeffer's Law (from Larry Niven): anything you don't understand might be dangerous. I'd track down why this is happening. Noel From gctersteeg at gmail.com Tue Jul 12 07:37:32 2022 From: gctersteeg at gmail.com (Gavin Tersteeg) Date: Mon, 11 Jul 2022 16:37:32 -0500 Subject: [TUHS] LSX issues and musing In-Reply-To: <20220711212413.29B5618C097@mercury.lcs.mit.edu> References: <20220711212413.29B5618C097@mercury.lcs.mit.edu> Message-ID: A lot of it was me just learning how V6 works in general. Getting V6 to boot on a simulated 11/23 was pretty easy (I had some issues getting it to compile at first, but it worked after I got that sorted out). Adding the RL02 and RX02 drivers was a tiny bit more difficult. I would say that the most difficult part was writing a RX02 boot program, trying to fit that into 512 bytes with interleave code took a few days. You were right about the source of the issue. I incorrectly assumed that the EIS flag was only set in header.lsx.s, but it is also set in param.h. The default param.h has the EIS symbol define commented out, while header.lsx.s has it uncommented. By uncommenting the define in param.h and recompiling decfd.c, it allows the kernel to be successfully linked. The current kernel that builds is too big to be used with a 16K kernel size, but I think I just need to recompile everything with the new param.h, and maybe adjust a few other parameters. I will look into getting an EIS chip. I'm probably going to move up to the 20K kernel size regardless, as I need the extra memory for changes that I want to make to the kernel. I am betting that the "0: Missing temp file" thing is due to some sort of file I/O issue, so I'll read into the compiler source to see what is generating it. On Mon, Jul 11, 2022 at 4:24 PM Noel Chiappa wrote: > > From: Gavin Tersteeg > > > I spent a lot of time getting UNIX V6 working on my PDP-11/23 system. > > It took a lot of tinkering with the kernel and drivers to make it > work > > in the way I wanted to > > You must have made a lot of changes for it to take "a lot of tinkering". > Bringing V6 up on the /23 has been done several times, and when I did > it, it only took about 2 dozen lines of code in about 2 files. What all > did you wind up changing? > > > > From my research, it seems like there were two different UNIX > variants > > that could run on a system like this. These variants were LSX and > > MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device > like > > a RK05 and some porting to work on an 11/03, while LSX is designed to > > work on exactly the hardware specs that I have on hand. > > Bringing up MINI-UNIX on the /03 has been done at least twice; once > historically (now lost, AFAIK), and again recently: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html > > I'm not sure what you're basing the "MINI-UNIX seems to require a decent > mass-storage device like a RK05" on - it should run as well on whatever > you're running LSX on as LSX does. > > I haven't run LSX myself, but from what I've seen, the only significant > difference between the two is that LSX will run with less main memory than > MINI-UNIX (which really kind of needs 56KB; LSX you can probably get away > with 40KB).That was a significant issue when the LSI-11 was originally > released, but these days one has to really work to have a QBUS PDP-11 with > less than 56KB. > > > > my EIS-less 11/03 > > EIS chips can be found on eBait for not much money (I just bought a couple > myself), and it's worth investing in one, so on can dispense with the > emulator, which takes real memory for which a better use can be found. > > > The first issue is that the C compiler will randomly spit out a "0: > > Missing temp file" when attempting to compile something. This is > > annoying, but circumventable by just running the same command over > and > > over until it works. > > Schaeffer's Law (from Larry Niven): anything you don't understand > might be dangerous. I'd track down why this is happening. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Jul 12 07:47:02 2022 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Mon, 11 Jul 2022 23:47:02 +0200 Subject: [TUHS] LSX issues and musing Message-ID: <678A3A5F-07C5-4F68-82F2-7308CD21B17C@planet.nl> > If I can get this working, I have a long laundry list of modifications and > experiments that I want to run with LSX, but as it stands, this is where I > am stuck at. Once upon a time there was a Soviet home computer that was based on the PDP-11, the BK0010: https://en.wikipedia.org/wiki/Electronika_BK (it is actually mostly a copy of the Terak 8510a -- https://en.wikipedia.org/wiki/Terak_8510/a ) The guy that found the surviving floppy with LSX source code (Leonid Broukhis) for the PDP-11 immediately ported it to the BK0010 and created a fair amount of infrastructure around it: https://github.com/ignusius/bkunix He used the 2.11BSD toolchain to create a cross-compiler. As that compiler had progressed significantly from the 5th Edition era compiler, the kernel became smaller and he could squeeze some stripped functionality back in. The repo says that the code there still works on a normal PDP-11. I’ve never communicated with Leonid, but maybe Warren has contact details for him. Also, the person who created LSX unix (Heinz Lycklama) is reading this list -- but of course it has been 40+ years since he last touched the code. Note that LSX only holds one process in core and swaps other processes (NPROC = 3) out to floppy. It reportedly took several hours for the Terak to self-compile LSX from source. At one point I added debugger support to my own port of LSX to a TI-990 with just floppies ... let’s just say, now I understand deeply why the original Unix debug interface was an improvement opportunity :^) From jnc at mercury.lcs.mit.edu Tue Jul 12 09:47:29 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Jul 2022 19:47:29 -0400 (EDT) Subject: [TUHS] LSX issues and musing Message-ID: <20220711234729.2E9F418C096@mercury.lcs.mit.edu> > From: Paul Ruizendaal > Note that LSX only holds one process in core and swaps other processes > (NPROC = 3) out to floppy. It reportedly took several hours for the > Terak to self-compile LSX from source. If one is working in a simulator, and not a real hardware PDP-11, there's a 'trick' one can use to make life a lot easier - for MINI-UNIX, at least; I'll comment on LSX below. As I report in the MINI-UNIX Computer History Wiki article: "MINI-UNIX uses the same file system as V6; this allows MINI-UNIX packs to be 'mounted' on V6 systems (either real, or simulated), which is very convenient for working on them." So just spin up a V6 in the simulator, mount the LSX/MINI-UNIX pack, and away you go. The V6 toolchain can be used to compile/link kernels; to link user commands one will need to import the LSX/MINI-UNIX loader (which, since V6 is source compatible with LSX/MINI-UNIX, is trivial). LSX is potentially more complex, as it supports _two different_ file system formats: the standard V6 one, and a 'contiguous' one which is very similar to the V6 one (rdwri.c has no conditionals on CONTIG; not so alloc.c, though), but is not fully compatible. So non-contiguous LSX file systems can be mounted under V6, but not contiguous ones. Noel From lars at nocrew.org Thu Jul 14 21:08:51 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 14 Jul 2022 11:08:51 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? Message-ID: <7wmtdcx870.fsf@junk.nocrew.org> Hello, Unix V8 has some code for Chaosnet support. There is a small hobbyist Chaos network going with Lispm, PDP-10, PDP-11, and Berkeley Unix nodes. Is there anyone who would be interested in trying to see if the V8 code is in a workable state, and get it running? Best regards, Lars Brinkhoff From john at jfloren.net Fri Jul 15 02:37:17 2022 From: john at jfloren.net (John Floren) Date: Thu, 14 Jul 2022 16:37:17 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <7wmtdcx870.fsf@junk.nocrew.org> References: <7wmtdcx870.fsf@junk.nocrew.org> Message-ID: <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> On 7/14/22 04:08, Lars Brinkhoff wrote: > Hello, > > Unix V8 has some code for Chaosnet support. There is a small hobbyist > Chaos network going with Lispm, PDP-10, PDP-11, and Berkeley Unix nodes. > Is there anyone who would be interested in trying to see if the V8 code > is in a workable state, and get it running? > > Best regards, > Lars Brinkhoff A network of lisp machines and PDP-10/11 systems seems pretty cool... is there a web site for the network? john From lars at nocrew.org Fri Jul 15 03:00:36 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 14 Jul 2022 17:00:36 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> (John Floren's message of "Thu, 14 Jul 2022 16:37:17 +0000") References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> Message-ID: <7wa69by6h7.fsf@junk.nocrew.org> John Floren wrote: > A network of lisp machines and PDP-10/11 systems seems pretty > cool... is there a web site for the network? Yes, it's here: https://chaosnet.net/ And there's a GitHub organization: https://github.com/Chaosnet/ To keep this on topic, known Unix implementations of Chaosnet include 4.1BSD (up and running), V8 (available but not running), and V7 (not found yet). From tuhs at tuhs.org Fri Jul 15 03:51:39 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 14 Jul 2022 17:51:39 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <7wa69by6h7.fsf@junk.nocrew.org> References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> <7wa69by6h7.fsf@junk.nocrew.org> Message-ID: Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD. What sort of help are you looking for? I've got idle fingers in the evenings lately, if you just need some code junkies to work on things I'm happy to throw my hat in the ring. - Matt G. ------- Original Message ------- On Thursday, July 14th, 2022 at 10:00 AM, Lars Brinkhoff wrote: > John Floren wrote: > > > A network of lisp machines and PDP-10/11 systems seems pretty > > cool... is there a web site for the network? > > > Yes, it's here: > https://chaosnet.net/ > > And there's a GitHub organization: > https://github.com/Chaosnet/ > > To keep this on topic, known Unix implementations of Chaosnet include > 4.1BSD (up and running), V8 (available but not running), and V7 (not > found yet). From ron at ronnatalie.com Fri Jul 15 04:19:33 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 14 Jul 2022 18:19:33 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> <7wa69by6h7.fsf@junk.nocrew.org> Message-ID: Note, I don’t know what you’re planning, but Chaos couldn’t take any propagation delay. It’s really limited to a LAN implementation as originally designed. From lars at nocrew.org Fri Jul 15 05:36:54 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 14 Jul 2022 19:36:54 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: (segaloco@protonmail.com's message of "Thu, 14 Jul 2022 17:51:39 +0000") References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> <7wa69by6h7.fsf@junk.nocrew.org> Message-ID: <7w1qunxz8p.fsf@junk.nocrew.org> segaloco wrote: > What sort of help are you looking for? I've got idle fingers in the > evenings lately, if you just need some code junkies to work on things > I'm happy to throw my hat in the ring. I'm mainly curious if the V8 code works. I haven't examined it at all, so I have no idea. For reference, I have a disk image with 4.1BSD patched and ready to run with SIMH here: http://lars.nocrew.org/tmp/Chaotic-4.1BSD.tar.bz2 I collected all the bits and pieces here and intended to make an expect script to install, patch, and build everything. I didn't the script but all the stuff should be here: https://github.com/Chaosnet/Chaosnet-for-4.1BSD From tjteixeira at earthlink.net Fri Jul 15 06:32:55 2022 From: tjteixeira at earthlink.net (Tom Teixeira) Date: Thu, 14 Jul 2022 16:32:55 -0400 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> <7wa69by6h7.fsf@junk.nocrew.org> Message-ID: On 7/14/22 2:19 PM, Ron Natalie wrote: > Note, I don’t know what you’re planning, but Chaos couldn’t take any > propagation delay.   It’s really limited to a LAN implementation as > originally designed. > It definitely had subnet routing, and as I recall, the KL10's and other machines with front end I/O processors generally used chaosnet routing between the host itself and the rest of the network. i.e. the I/O processor was on one subnet, the host on a second subnet and the rest of the "LAN" was on the other side of the I/O processor. My recollection is that unlike an IP router, a Chaosnet node had only one address, and routing tables determined which device to send the data on. And LCS definitely had multiple coax cable runs with each run a subnet with routing between. But with a maximum of 256 subnets, routing was much simpler. I wonder how much benefit is available from using network switches rather than collision detection and retransmit, though the virtual token was supposed to reduce collisions somewhat. From ron at ronnatalie.com Fri Jul 15 06:39:44 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 14 Jul 2022 20:39:44 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> <7wa69by6h7.fsf@junk.nocrew.org> Message-ID: It can do subnets, but it can’t deal with long haul (over the greater internet) time delays. ------ Original Message ------ >From "Tom Teixeira" To tuhs at tuhs.org Date 7/14/2022 4:32:55 PM Subject [TUHS] Re: Unix V8 Chaosnet, any takers? >On 7/14/22 2:19 PM, Ron Natalie wrote: >>Note, I don’t know what you’re planning, but Chaos couldn’t take any propagation delay. It’s really limited to a LAN implementation as originally designed. >> >It definitely had subnet routing, and as I recall, the KL10's and other machines with front end I/O processors generally used chaosnet routing between the host itself and the rest of the network. i.e. the I/O processor was on one subnet, the host on a second subnet and the rest of the "LAN" was on the other side of the I/O processor. My recollection is that unlike an IP router, a Chaosnet node had only one address, and routing tables determined which device to send the data on. > >And LCS definitely had multiple coax cable runs with each run a subnet with routing between. But with a maximum of 256 subnets, routing was much simpler. > >I wonder how much benefit is available from using network switches rather than collision detection and retransmit, though the virtual token was supposed to reduce collisions somewhat. > From tuhs at tuhs.org Fri Jul 15 07:50:53 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 14 Jul 2022 21:50:53 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <7w1qunxz8p.fsf@junk.nocrew.org> References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> <7wa69by6h7.fsf@junk.nocrew.org> <7w1qunxz8p.fsf@junk.nocrew.org> Message-ID: This looks like it might be exactly what you're looking for: http://9legacy.org/9legacy/doc/simh/v8 Steps to start with a 4.1BSD base in simh and use that to ultimately produce a V8 system. I haven't audited these instructions myself, so YMMV, but I suspect someone wouldn't go through the hard work if this didn't do anything. That said, your original posting mentions the PDP-11, but also "Berkeley Unix Nodes". For the latter, do you mean VAX? These instructions are for VAX too, I don't know whether V8 ran on PDP-11 or not, but if that's your intent, you may want to start with a 2.xBSD or V7 as a base instead. - Matt G. ------- Original Message ------- On Thursday, July 14th, 2022 at 12:36 PM, Lars Brinkhoff wrote: > segaloco wrote: > > > What sort of help are you looking for? I've got idle fingers in the > > evenings lately, if you just need some code junkies to work on things > > I'm happy to throw my hat in the ring. > > > I'm mainly curious if the V8 code works. I haven't examined it at all, > so I have no idea. > > For reference, I have a disk image with 4.1BSD patched and ready to > run with SIMH here: > http://lars.nocrew.org/tmp/Chaotic-4.1BSD.tar.bz2 > > I collected all the bits and pieces here and intended to make > an expect script to install, patch, and build everything. I didn't > the script but all the stuff should be here: > https://github.com/Chaosnet/Chaosnet-for-4.1BSD From tuhs at tuhs.org Fri Jul 15 10:33:28 2022 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 14 Jul 2022 18:33:28 -0600 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> <7wa69by6h7.fsf@junk.nocrew.org> Message-ID: <654a4152-2bad-86fd-fc3c-528330e6e093@spamtrap.tnetconsulting.net> On 7/14/22 2:39 PM, Ron Natalie wrote: > It can do subnets, but it can’t deal with long haul (over the greater > internet) time delays. I wonder if there is an opportunity for something that pretends to be the remote side locally, sends the data via some other non-latency-sensitive protocol to a counter part where the counter part pretends to be the near side. Local / / [A]----[B]==/==[C]---[D] / / Remote Where ---- is Chaosnet over a short distance and ==/== is something else over a long distance. B would pretend to be D so that A could talk to D' in a timely manner and conversely C would pretend to be A so that A' could talk to D in a timely manner. I've seen such spoofing / emulation in other protocols. Maybe the prior art can work for Chaosnet. P.S. Hopefully my ASCII art will survive the trip. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From fair-tuhs at netbsd.org Fri Jul 15 14:29:36 2022 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Thu, 14 Jul 2022 21:29:36 -0700 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <654a4152-2bad-86fd-fc3c-528330e6e093@spamtrap.tnetconsulting.net> References: Message-ID: <24949.1657859376@cesium.clock.org> Grant, You've just described a useful piece of old ARPANET hardware: the Advanced Communications Corp (ACC) Error Control Unit (ECU). ARPANET IMP 1822 (serial) interface could be "local host" (30 feet, unbalanced serial), or "distant host" (up to 2,000 feet, balanced serial). One used a pair of ACC ECUs - one at the IMP end, one at the host end, with potentially arbitrary distance inbetween the ECUs, so as to obviate the 1822 LH/DH limits. I managed such a setup at LLNL in 1986 (MILNET, IMP #21): when I was hired, the group I hired into (well, put under contract to by CDC Professional Services) was on-site at the lab, but as the wires ran between the old AEC instrument trailer that was our machine room for a VAX-11/780 and PDP-11/70 (both running BSD, natch) and the Magnetic Fusion Energy Computer Center (MFE CC) where the IMP was located was rather longer than 1822 DH could handle. A 3002 circuit ("dry" pairs) and a pair of LADDS high-speed modems did the trick there. Later, my group moved to the Hacienda Business Park in Pleasanton, some miles away; we set up a Pac*Bell 56Kb/s (DS0) leased line with standard CSU/DSUs to connect the ACC ECUs and in turn the host (well, router) to our port on the IMP. I had some trouble getting that one going again because the ACC ECU manuals were ... disjoint: simple recipies for setting DIP switches (with no explanation of why), and a complete schematic in the back, which was useless to me because I'm not an EE, but the documented switch settings for our desired setup didn't work. ACC sent two engineers to our site from Santa Barbara to solve the problem - the senior one was the last engineer to issue an Engineering Change Order (ECO) on the ECUs. To bring this back to a Unix context, that sort of "spoofers in the middle" was also the shtick of Telebit Trailblazer modems for the UUCP "g" protocol in UUCP/USENET days - 19.2Kb/s in one direction at a time, and the modems "knew" the "g" protocol and spoofed it for maximum speed in one direction, which was the way UUCP worked too: file transfers were handled one direction at a time, and just ACKs coming back. Internally, they effectively provided an optimized UUCP tunnel atop their quite tenacious Packetized Ensemble Protocol (PEP). Erik From gctersteeg at gmail.com Fri Jul 15 18:07:58 2022 From: gctersteeg at gmail.com (Gavin Tersteeg) Date: Fri, 15 Jul 2022 03:07:58 -0500 Subject: [TUHS] LSX issues and musing In-Reply-To: <20220711234729.2E9F418C096@mercury.lcs.mit.edu> References: <20220711234729.2E9F418C096@mercury.lcs.mit.edu> Message-ID: Well, I have spent a few more days tentatively messing around with LSX, and I have noticed a few things. First off, the C compiler is not the only program to have occasional issues. Sometimes the "mv" command also fails with the oh-so-descriptive "?" error. By the looks of it, this error is caused by something going wrong with a fork() and subsequent wait() syscall. That recurring error in the C compiler is also caused by the 2nd pass of the C compiler not being able to find a temporary file created by the 1st pass. If the 1st pass was failing to run, then that would explain why the 2nd pass isn't able to find that temporary file. This has me guessing that there may be something wrong with fork() or exec(). Whenever it is, it doesn't dumpster memory or blow up the filesystem. For all I know, it may be an emulation issue too, but I have no way of testing it right now. The current kernel I am building is under 16KB at the moment. My goal is to be able to recreate the stock (semi?) functional kernel, and then do modifications from there. This goal has not been reached, as this kernel simply crashes on startup. It is either a HALT instruction or a stack issue depending on if the kernel has been stripped or not. I bet I am building it wrong again :/, it doesn't need to be reloc'd after the "ld -X" does it? Has anyone actually been able to get a system to build with the archived LSX disks? I have poured over the config files many times, but I feel like I am missing something painfully obvious... On Mon, Jul 11, 2022 at 6:47 PM Noel Chiappa wrote: > > From: Paul Ruizendaal > > > Note that LSX only holds one process in core and swaps other > processes > > (NPROC = 3) out to floppy. It reportedly took several hours for the > > Terak to self-compile LSX from source. > > If one is working in a simulator, and not a real hardware PDP-11, there's a > 'trick' one can use to make life a lot easier - for MINI-UNIX, at least; > I'll > comment on LSX below. > > As I report in the MINI-UNIX Computer History Wiki article: "MINI-UNIX uses > the same file system as V6; this allows MINI-UNIX packs to be 'mounted' on > V6 > systems (either real, or simulated), which is very convenient for working > on > them." So just spin up a V6 in the simulator, mount the LSX/MINI-UNIX pack, > and away you go. The V6 toolchain can be used to compile/link kernels; to > link user commands one will need to import the LSX/MINI-UNIX loader (which, > since V6 is source compatible with LSX/MINI-UNIX, is trivial). > > LSX is potentially more complex, as it supports _two different_ file system > formats: the standard V6 one, and a 'contiguous' one which is very similar > to the V6 one (rdwri.c has no conditionals on CONTIG; not so alloc.c, > though), but is not fully compatible. So non-contiguous LSX file systems > can be mounted under V6, but not contiguous ones. > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jul 15 18:51:34 2022 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Fri, 15 Jul 2022 10:51:34 +0200 Subject: [TUHS] Unix V8 Chaosnet, any takers? Message-ID: > Message: 6 > Date: Thu, 14 Jul 2022 17:51:39 +0000 > From: segaloco > > Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD. I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base. As I currently understand it, the V8 kernel: - is a further development from 32V - retains the code organisation of the V5..32V versions - adds virtual memory code from BSD - adds select() from BSD and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.) In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based). Paul From jnc at mercury.lcs.mit.edu Fri Jul 15 20:25:37 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 15 Jul 2022 06:25:37 -0400 (EDT) Subject: [TUHS] Unix V8 Chaosnet, any takers? Message-ID: <20220715102537.22E9018C080@mercury.lcs.mit.edu> > From: Lars Brinkhoff > There is a small hobbyist Chaos network going What encapsulation are they using to transmit CHAOS packets (over the Internet, I assume)? I know there was an IP protocol number assigned for CHAOS (16.), but I don't recall if there was ever a spec? (Which is kind of amusing, since in 'Assigned Numbers', the person responsible for 16. is .... me! :-) There was a spec for encapsulating IP in CHAOS, and that actually _was_ implemented at MIT BITD; it was used for a while to get IP traffic to a Unix machine (V7, IIRC) over on main campus, at a stage when only CHAOS hardware (very confusing that the same name was applied to hardware, and a protocol suite) ran across to main campus from Tech Square. > From: Grant Taylor > I wonder if there is an opportunity for something that pretends to be > the remote side locally, sends the data via some other > non-latency-sensitive protocol to a counter part where the counter part > pretends to be the near side. Let's think through the details. The near-end 'invisibility box' (let's call it) is going to have to send acks to the original source machine, otherwise that will time out, abort the connection, etc. The originating machine is its own thing, and this behaviour can't be controlled/stopped. (This, BTW, shows a key difference between 'local' and 'across network' modes, a recent topic here; in a situation where two distinct machines are cooperating across a network, the other machine is its own entity, and can't be expected/guaranteed to do anything in particular at all.) In addition, the near-end invisibility box is going to have to keep a copy of each packet, until the destination machine sends an ack to the invisibility box - because if the packet is lost, the invisibility box is going to have to retransmit it. (The original source is not going to - it's already gotten an ack, so as far as it's concerned, that packet is done and dusted.) And the near-end invisibility box is also going to have to have to have a time-out timer, so that when the ack isn't seen, it will know to retransmit the packet. There's no point to _also_ sending the acks on to the originating machine; they won't do anything useful, and might just confuse it. So, let's see now: the near-end invisibility box buffers the packet, looks for an ack, times out when it doesn't see it, re-transmits the packet - that sounds familiar? Oh, right, it's a reliable connection. And presumably there's an invisibility box at the far end too, so the same can happen for any data packets the destination machine sends. The only question is whether, when doing the detailed design, there's any point to having the destination machine's acks sent to the near-end invisibility box - or just use them at the far-end invisibility box. (I.e. create three reliable connections: i) a CHAOS connection originating machine<->near-end invisibility box; ii) {whatever} near-end invisibility ox<->far-end invisibility box; iii) CHAOS far-end invisibility box<->original destination machine - and glue them together.) That is in some sense simpler than creating an extra-ordinary mechanism to have a 'helper' box in the middle of the connection (to terminate the CHAOS connection from the original machine, and have another CHAOS connection, but with an enhanced time-out mechanism which can cope with larger RTT's, from there to the original destination); and the same in the other direction. The amusing thing is that the CHAOS protocol stack actually already had something very similar to this, BITD. If one were sitting at a machine that only had CHAOS, and one wanted to (say) TELNET to an ARPANET host, there was a CHAOS service which ARPANET hosts on the CHAOSNET provided: open a CHAOS connection to that serrver, and it would open an NCP connection to one's intended ultimate destination, and glue the byte streams together. (The ultimate destination was passed as data over the CHAOS connection, when opening it.) Noel From tytso at mit.edu Fri Jul 15 21:53:36 2022 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 15 Jul 2022 07:53:36 -0400 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <20220715102537.22E9018C080@mercury.lcs.mit.edu> References: <20220715102537.22E9018C080@mercury.lcs.mit.edu> Message-ID: On Fri, Jul 15, 2022 at 06:25:37AM -0400, Noel Chiappa wrote: > > There was a spec for encapsulating IP in CHAOS, and that actually _was_ > implemented at MIT BITD; it was used for a while to get IP traffic to a Unix > machine (V7, IIRC) over on main campus, at a stage when only CHAOS hardware > (very confusing that the same name was applied to hardware, and a protocol > suite) ran across to main campus from Tech Square. As I recall it was possible to access Chaosnet from Project Athena VAX/750's running BSD 4.3, so presumably Chaosnet was ported into the BSD 4.3 kernel at one point. It wasn't used for anything official, but there were folks who were using it to access Tech Square machines from the SIPB office in 11-205 (on the main campus) as late as 1991 or so. - Ted From ron at ronnatalie.com Fri Jul 15 21:55:38 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 15 Jul 2022 11:55:38 +0000 Subject: [TUHS] ECU In-Reply-To: References: Message-ID: I had an ECU connecting the BRL-GATEWAY to the Imp in another building. Rutgers also used an ECU to get their internet connection of the Columbia IMP. When visiting BBN’s NOC I noted little red squares on the network map for my site. I was told these signified an ECU and it is because it causes problems when the host crashes. Let me explain this quaint piece of operation. Both the IMP and the LH or DH host interface have a relay that indicates the interface is powered up. The idea is that if you shutdown the machine (or the imp) the relay fails open. That’s fine for a gross shutdown, but let’s say the machine just hangs. The IMP has a feature called “TARDY DOWN.” If you stop accepting packets for a while, the thing declares you “TARDY DOWN” (effectively down for the rest of the net). This is signified on the later C-30 imps by the display register bit for that host flashing. Now the IMP says, “Hey, let me try to wake this guy up.” It does this by dropping its relay for a second hoping to trick the host into thinking it has rebooted and it should reinitialize. Of course, this gambit rarely works, but if the host did wake up, if it starts processing messages again, the IMP says “All is well” and declares the host up. Now, what if you had an ECU. Well, when the IMP flaps it’s relay, the ECU says “Hey, something happened to the IMP.” I better reset everything including any buffered packets. The ECU actually buffers three packets or so while it is transferring them to the other end. Well, now that the buffer is empty, it can take three more packets. The IMP declares it up. Of course, the host isn’t really there, so the packets just stay there and then the ECU fills up and stops answering the IMP and the IMP eventually declares it TARDY DOWN again. Lather, Rinse, Repeat. This wouldn’t be so bad except that every time there’s a transition a message is printed out in the NOC. So a dead host on an ECU causes a couple of messages to be printed every three minutes until someone does something about it. Later, we had similar fun and games with the EGP protocol. The protocol suggest you not declare the peer up until after you receive n (where n = 3) hello messages. I’m more optimistic than that. My implementation sent a “OK, You’re up” response after a single HELLO. Of course, this pissed off some other client who said, I can’t be up after only one HELLO, I better start the whole thing over again. Lather, Rinse, Repeat. From tuhs at tuhs.org Sat Jul 16 03:15:31 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 15 Jul 2022 17:15:31 +0000 Subject: [TUHS] V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?) Message-ID: <2hK72A6Itq5yUS4eqzueKuU8hSC1JCR3XQbiHWTXnp-VS1V-eItyJ1gscCj2QR-0knXF7ukWVBxxzrC6e4TaN86l_2WAYK1eGrae2cskPb4=@protonmail.com> Re-subject'd as this part of the conversation diverges. Found the quote that I was thinking of when I said that: https://yarchive.net/comp/bsd.html "Research Unix 8th Edition started from (I think) BSD 4.1c, but with enormous amounts scooped out and replaced by our own stuff." - Dennis Ritchie The "I think" adds some murkiness for sure. There's definitely a good chunk of code from 4BSD. Compare init, getty, locore.c (as opposed to .s in V7 back). Heck, even the main.c between the two kernels are more similar to each other than V7. I would almost opt towards calling that being rebased on 4BSD rather than V7 with bits and pieces of BSD added. I could see it being more beneficial to start with 4BSD and tack on necessary Bell bits rather than take V7/32V and try and shoehorn in the VM implementation for VAX. The 4.1cBSD copy on the archive does appear to be pretty different, so in terms of raw comparison, I suspect the basis is 4BSD rather than 4.1cBSD. I don't know that we have a clean copy of 4.1BSD gold, I'd be interested to see if the structure of the source code changed between 4.1 and 4.1c, as 4.1c does exhibit the new organization by the BSD folks, 4BSD still shows folders like cmd, lib, and so on. Not trying to be combative by any means, but I've been doing a bit of research lately into when V8 was snapped from BSD and where Bell and Berkeley then diverged from that last major confluence, especially with a focus on init and other early stages of userland. - Matt G. ------- Original Message ------- On Friday, July 15th, 2022 at 1:51 AM, Paul Ruizendaal via TUHS wrote: > > Message: 6 > > Date: Thu, 14 Jul 2022 17:51:39 +0000 > > From: segaloco segaloco at protonmail.com > > > > Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD. > > > I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base. > > As I currently understand it, the V8 kernel: > > - is a further development from 32V > - retains the code organisation of the V5..32V versions > - adds virtual memory code from BSD > - adds select() from BSD > > and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.) > > In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based). > > Paul From imp at bsdimp.com Sat Jul 16 03:50:51 2022 From: imp at bsdimp.com (Warner Losh) Date: Fri, 15 Jul 2022 11:50:51 -0600 Subject: [TUHS] V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?) In-Reply-To: <2hK72A6Itq5yUS4eqzueKuU8hSC1JCR3XQbiHWTXnp-VS1V-eItyJ1gscCj2QR-0knXF7ukWVBxxzrC6e4TaN86l_2WAYK1eGrae2cskPb4=@protonmail.com> References: <2hK72A6Itq5yUS4eqzueKuU8hSC1JCR3XQbiHWTXnp-VS1V-eItyJ1gscCj2QR-0knXF7ukWVBxxzrC6e4TaN86l_2WAYK1eGrae2cskPb4=@protonmail.com> Message-ID: On Fri, Jul 15, 2022 at 11:15 AM segaloco via TUHS wrote: > Re-subject'd as this part of the conversation diverges. > > Found the quote that I was thinking of when I said that: > > https://yarchive.net/comp/bsd.html > > "Research Unix 8th Edition started from (I think) BSD 4.1c, but with > enormous amounts scooped out and replaced by our own stuff." - Dennis > Ritchie > > The "I think" adds some murkiness for sure. There's definitely a good > chunk of code from 4BSD. Compare init, getty, locore.c (as opposed to .s > in V7 back). Heck, even the main.c between the two kernels are more > similar to each other than V7. I would almost opt towards calling that > being rebased on 4BSD rather than V7 with bits and pieces of BSD added. I > could see it being more beneficial to start with 4BSD and tack on necessary > Bell bits rather than take V7/32V and try and shoehorn in the VM > implementation for VAX. > > The 4.1cBSD copy on the archive does appear to be pretty different, so in > terms of raw comparison, I suspect the basis is 4BSD rather than 4.1cBSD. > I don't know that we have a clean copy of 4.1BSD gold, I'd be interested to > see if the structure of the source code changed between 4.1 and 4.1c, as > 4.1c does exhibit the new organization by the BSD folks, 4BSD still shows > folders like cmd, lib, and so on. > > Not trying to be combative by any means, but I've been doing a bit of > research lately into when V8 was snapped from BSD and where Bell and > Berkeley then diverged from that last major confluence, especially with a > focus on init and other early stages of userland. > The biggest differences between BSD4.1 and BSD4.1c were the addition of FFS in 4.1b (we have 4.1a from Kirk's DVD, as well as 4.1 and two versions of 4.1c). There's no ufs that I can detect in V8 though. If we look at the vm, the 4.1c.2 files are from 83, the 4.1 files are from 80 and the v8 files are from 81. Kirk's DVD has a 4.1.snap on it that lines up more closely with at least the vm files. I don't recall what these files are from. It's not present in the TUHS archives that I see. This snapshot is about a year after 4.1BSD release, but maybe 18 months before the 4.1a snapshot. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Jul 16 04:41:53 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 15 Jul 2022 18:41:53 +0000 Subject: [TUHS] V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?) In-Reply-To: References: <2hK72A6Itq5yUS4eqzueKuU8hSC1JCR3XQbiHWTXnp-VS1V-eItyJ1gscCj2QR-0knXF7ukWVBxxzrC6e4TaN86l_2WAYK1eGrae2cskPb4=@protonmail.com> Message-ID: Thanks for the insight, definitely a stronger case for 4.1BSD being involved in some way, shape, or form. Here are a few SCCS strings from V8 vs 4BSD and 4.1(c)BSD. init: V8 - "@(#)init.c 4.3 (Berkeley) 10/13/80" 4BSD - "@(#)init.c 4.3 (Berkeley) 10/13/80" 4.1cBSD - "@(#)init.c 4.10 (Berkeley) 12/22/82" getty: V8 - "@(#)getty.c 4.1 (Berkeley) 10/1/80" 4BSD - "@(#)getty.c 4.1 (Berkeley) 10/1/80" 4.1cBSD - "@(#)getty.c 4.9 4.9 82/12/23" Locore (not an SCCS string, but comment at top): V8 - "Locore.c 4.11 81/05/15" 4BSD - "Locore.c 4.4 11/10/80" 4.1BSD - "Locore.c 4.11 81/05/15" (Note, used the BBN VAX version here, I couldn't find the kernel sources in the 4.1cBSD on the archive...) Main (kernel): V8 - "main.c 4.14 81/04/23" 4BSD - "main.c 4.2 11/9/80" 4.1BSD - "main.c 4.14 81/04/23" crt0: This one doesn't have SCCS info, is identical between V8 and 4BSD in ASM. The crt0 in 4.1cBSD is in C instead, so not really comparable. doprnt (c library): V8 - "@(#)doprnt.s 4.3 (Berkeley) 3/22/81" 4BSD - No string... 4.1cBSD - "@(#)doprnt.s 4.4 (Berkeley) 11/25/81" Granted, this isn't exhaustive by any means, but everything I've checked has shown a much stronger 4 through 4.1cBSD character than V7/32V. It's too bad the march from V7 to V8 isn't more documented, what I'm starting to see here is a incremental approach where perhaps 4BSD was picked up, started to be modified into a research version, and as useful developments were made at Berkeley, they continued to merge in as well as make local changes until V8 was born. This is all speculation on my part though, I don't want to establish history I wasn't there for, but there is a strong case for V8 starting possibly as 4BSD with a pretty open door to continuing to pull from BSD for a little while. Specifically, I've seen more 4BSD alignment in userland, more 4.1BSD alignment in the kernel, but it's all, as Dennis put it, "pretty eclectic". - Matt G. ------- Original Message ------- On Friday, July 15th, 2022 at 10:50 AM, Warner Losh wrote: > > > On Fri, Jul 15, 2022 at 11:15 AM segaloco via TUHS wrote: > > > Re-subject'd as this part of the conversation diverges. > > > > Found the quote that I was thinking of when I said that: > > > > https://yarchive.net/comp/bsd.html > > > > "Research Unix 8th Edition started from (I think) BSD 4.1c, but with enormous amounts scooped out and replaced by our own stuff." - Dennis Ritchie > > > > The "I think" adds some murkiness for sure. There's definitely a good chunk of code from 4BSD. Compare init, getty, locore.c (as opposed to .s in V7 back). Heck, even the main.c between the two kernels are more similar to each other than V7. I would almost opt towards calling that being rebased on 4BSD rather than V7 with bits and pieces of BSD added. I could see it being more beneficial to start with 4BSD and tack on necessary Bell bits rather than take V7/32V and try and shoehorn in the VM implementation for VAX. > > > > The 4.1cBSD copy on the archive does appear to be pretty different, so in terms of raw comparison, I suspect the basis is 4BSD rather than 4.1cBSD. I don't know that we have a clean copy of 4.1BSD gold, I'd be interested to see if the structure of the source code changed between 4.1 and 4.1c, as 4.1c does exhibit the new organization by the BSD folks, 4BSD still shows folders like cmd, lib, and so on. > > > > Not trying to be combative by any means, but I've been doing a bit of research lately into when V8 was snapped from BSD and where Bell and Berkeley then diverged from that last major confluence, especially with a focus on init and other early stages of userland. > > > The biggest differences between BSD4.1 and BSD4.1c were the addition of FFS in 4.1b (we have 4.1a from Kirk's DVD, as well as 4.1 and two versions of 4.1c). There's no ufs that I can detect in V8 though. > > If we look at the vm, the 4.1c.2 files are from 83, the 4.1 files are from 80 and the v8 files are from 81. > > Kirk's DVD has a 4.1.snap on it that lines up more closely with at least the vm files. I don't recall what these files are from. It's not present in the TUHS archives that I see. This snapshot is about a year after 4.1BSD release, but maybe 18 months before the 4.1a snapshot. > > Warner From lars at nocrew.org Sat Jul 16 16:38:33 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 16 Jul 2022 06:38:33 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: (segaloco@protonmail.com's message of "Thu, 14 Jul 2022 21:50:53 +0000") References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> <7wa69by6h7.fsf@junk.nocrew.org> <7w1qunxz8p.fsf@junk.nocrew.org> Message-ID: <7wlestwoie.fsf@junk.nocrew.org> segaloco wrote: > This looks like it might be exactly what you're looking for: > http://9legacy.org/9legacy/doc/simh/v8 Thanks! > That said, your original posting mentions the PDP-11, but also > "Berkeley Unix Nodes". For the latter, do you mean VAX? Yes, they are VAX-11/780 SIMH instances running 4.1BSD + MIT patches. > I don't know whether V8 ran on PDP-11 or not, but if that's your > intent, you may want to start with a 2.xBSD or V7 as a base instead. The Chaosnet documentation says there were PDP-11 Unix V7 nodes on the network. That code has not been found though. Same goes for VAX/VMS. From lars at nocrew.org Sat Jul 16 16:59:52 2022 From: lars at nocrew.org (Lars Brinkhoff) Date: Sat, 16 Jul 2022 06:59:52 +0000 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <20220715102537.22E9018C080@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri, 15 Jul 2022 06:25:37 -0400 (EDT)") References: <20220715102537.22E9018C080@mercury.lcs.mit.edu> Message-ID: <7wh73hwniv.fsf@junk.nocrew.org> Noel Chiappa wrote: > > There is a small hobbyist Chaos network going > What encapsulation are they using to transmit CHAOS packets (over the > Internet, I assume)? There are several methods to encapsulate packets for transmission locally or over the Internet: - EtherType 0x0804 - IP protocol 0x10 (yours!) - Unix domain socket - UDP - TLS over TCP/IP (preferred transport across Internet) There is a bridge/router that understands all these, written by professor Björn Victor. Various computer hardware and emulators support different encapsulations: real Lispms use Ethernet, an LMI Lambda emulator uses IP, KLH10 and SIMH use the UDP method, and the PDP-10/X FPGA uses a Unix socket. From pnr at planet.nl Sat Jul 16 19:31:34 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 16 Jul 2022 11:31:34 +0200 Subject: [TUHS] V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?) In-Reply-To: <2hK72A6Itq5yUS4eqzueKuU8hSC1JCR3XQbiHWTXnp-VS1V-eItyJ1gscCj2QR-0knXF7ukWVBxxzrC6e4TaN86l_2WAYK1eGrae2cskPb4=@protonmail.com> References: <2hK72A6Itq5yUS4eqzueKuU8hSC1JCR3XQbiHWTXnp-VS1V-eItyJ1gscCj2QR-0knXF7ukWVBxxzrC6e4TaN86l_2WAYK1eGrae2cskPb4=@protonmail.com> Message-ID: > On 15 Jul 2022, at 19:15, segaloco wrote: > Not trying to be combative by any means, but I've been doing a bit of research lately into when V8 was snapped from BSD and where Bell and Berkeley then diverged from that last major confluence, especially with a focus on init and other early stages of userland. Not taken as combative - always working on the basis of my 'current understanding’ and that is evolving continuously as new views and facts present themselves. My comments were intended around the kernel code, not the userland. That said, I’ve looked into this a bit more and I think you were more right than I was. > "Research Unix 8th Edition started from (I think) BSD 4.1c, but with enormous amounts scooped out and replaced by our own stuff." - Dennis Ritchie That is a good quote, but I think there is a better way to look at this, which is Warren’s tool to establish similarity between files (it is integrated with the Unix Tree webpage on TUHS). > There's definitely a good chunk of code from 4BSD. Compare init, getty, locore.c (as opposed to .s in V7 back). Heck, even the main.c between the two kernels are more similar to each other than V7. I would almost opt towards calling that being rebased on 4BSD rather than V7 with bits and pieces of BSD added. I could see it being more beneficial to start with 4BSD and tack on necessary Bell bits rather than take V7/32V and try and shoehorn in the VM implementation for VAX. Looking at various kernel files in the V8 tree, it would seem that the most comparable file in the TUHS database (and excluding V9-V10) would typically be “BBN-TCP”, closely followed by “4BSD”. This BBN-TCP kernel code is based on a snapshot of BSD from August 1980 (see its history file). Joy sent it to Gurwitz for integration of the BBN TCP stack with the BSD kernel. I think it is (or is close to) 4.1BSD. From the output of Warren’s tool, it also seems that 4.1c deviated/evolved considerably from that base. It would require a more in-depth comparison to say more, but based on this quick check I think it is reasonable to say that V8 started from 4.1BSD (and not 32V as I thought, or 4.1c as dmr remembered). It would be interesting to see what the "enormous amounts scooped out” exactly were -- but maybe this refers more to the userland than the kernel. Some bits - like select() - were not in 4.1BSD and would have come from 4.1c. The V8 kernel still has a lowcore.s (next to lowcore.c). Interestingly, this has the best match with later BSD versions. In all likelihood, there was cross-fertilisation after the initial code fork. > The 4.1cBSD copy on the archive does appear to be pretty different, so in terms of raw comparison, I suspect the basis is 4BSD rather than 4.1cBSD. I don't know that we have a clean copy of 4.1BSD gold, I'd be interested to see if the structure of the source code changed between 4.1 and 4.1c, as 4.1c does exhibit the new organization by the BSD folks, 4BSD still shows folders like cmd, lib, and so on. Yes, we have (now) reached the same conclusion, but don’t forget that V8 adds a lot of innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.). Networking in the V8 kernel (including Chaos) is organised very differently from 4.1cBSD. Paul From robpike at gmail.com Sat Jul 16 20:31:10 2022 From: robpike at gmail.com (Rob Pike) Date: Sat, 16 Jul 2022 20:31:10 +1000 Subject: [TUHS] V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?) In-Reply-To: References: <2hK72A6Itq5yUS4eqzueKuU8hSC1JCR3XQbiHWTXnp-VS1V-eItyJ1gscCj2QR-0knXF7ukWVBxxzrC6e4TaN86l_2WAYK1eGrae2cskPb4=@protonmail.com> Message-ID: That sounds mostly right, from memory. V8 was definitely adapted from some 4BSD, not 32V - there was major internal friction on that decision. I will admit to being a defender of Reiser and London's VAX port, which was screamingly fast. However. Regarding select, I recall that Dennis implemented it and passed it to Berkeley*, but maybe not. He certainly had a hand in its design; I distinctly remember talking to him about it after one of his trips out west. -rob A note for the historians: Bell Labs's Unix Support Group (USG), which did development work for Unix, and was not even in the same building as Research, was run by Berkley (sic) Tague. Thus we had Berkeley Unix and Berkley's Unix and no end of fun and confusion on that score. On Sat, Jul 16, 2022 at 7:32 PM Paul Ruizendaal wrote: > > > > > On 15 Jul 2022, at 19:15, segaloco wrote: > > > Not trying to be combative by any means, but I've been doing a bit of research lately into when V8 was snapped from BSD and where Bell and Berkeley then diverged from that last major confluence, especially with a focus on init and other early stages of userland. > > Not taken as combative - always working on the basis of my 'current understanding’ and that is evolving continuously as new views and facts present themselves. > > My comments were intended around the kernel code, not the userland. That said, I’ve looked into this a bit more and I think you were more right than I was. > > > "Research Unix 8th Edition started from (I think) BSD 4.1c, but with enormous amounts scooped out and replaced by our own stuff." - Dennis Ritchie > > That is a good quote, but I think there is a better way to look at this, which is Warren’s tool to establish similarity between files (it is integrated with the Unix Tree webpage on TUHS). > > > There's definitely a good chunk of code from 4BSD. Compare init, getty, locore.c (as opposed to .s in V7 back). Heck, even the main.c between the two kernels are more similar to each other than V7. I would almost opt towards calling that being rebased on 4BSD rather than V7 with bits and pieces of BSD added. I could see it being more beneficial to start with 4BSD and tack on necessary Bell bits rather than take V7/32V and try and shoehorn in the VM implementation for VAX. > > Looking at various kernel files in the V8 tree, it would seem that the most comparable file in the TUHS database (and excluding V9-V10) would typically be “BBN-TCP”, closely followed by “4BSD”. This BBN-TCP kernel code is based on a snapshot of BSD from August 1980 (see its history file). Joy sent it to Gurwitz for integration of the BBN TCP stack with the BSD kernel. I think it is (or is close to) 4.1BSD. > > From the output of Warren’s tool, it also seems that 4.1c deviated/evolved considerably from that base. It would require a more in-depth comparison to say more, but based on this quick check I think it is reasonable to say that V8 started from 4.1BSD (and not 32V as I thought, or 4.1c as dmr remembered). It would be interesting to see what the "enormous amounts scooped out” exactly were -- but maybe this refers more to the userland than the kernel. > > Some bits - like select() - were not in 4.1BSD and would have come from 4.1c. The V8 kernel still has a lowcore.s (next to lowcore.c). Interestingly, this has the best match with later BSD versions. In all likelihood, there was cross-fertilisation after the initial code fork. > > > The 4.1cBSD copy on the archive does appear to be pretty different, so in terms of raw comparison, I suspect the basis is 4BSD rather than 4.1cBSD. I don't know that we have a clean copy of 4.1BSD gold, I'd be interested to see if the structure of the source code changed between 4.1 and 4.1c, as 4.1c does exhibit the new organization by the BSD folks, 4BSD still shows folders like cmd, lib, and so on. > > Yes, we have (now) reached the same conclusion, but don’t forget that V8 adds a lot of innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.). Networking in the V8 kernel (including Chaos) is organised very differently from 4.1cBSD. > > Paul > From imp at bsdimp.com Sun Jul 17 00:05:02 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 16 Jul 2022 08:05:02 -0600 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <7wlestwoie.fsf@junk.nocrew.org> References: <7wmtdcx870.fsf@junk.nocrew.org> <0ba593c4-db60-1bc8-2531-c64e4937f285@jfloren.net> <7wa69by6h7.fsf@junk.nocrew.org> <7w1qunxz8p.fsf@junk.nocrew.org> <7wlestwoie.fsf@junk.nocrew.org> Message-ID: On Sat, Jul 16, 2022, 12:38 AM Lars Brinkhoff wrote: > segaloco wrote: > > This looks like it might be exactly what you're looking for: > > http://9legacy.org/9legacy/doc/simh/v8 > > Thanks! > > > That said, your original posting mentions the PDP-11, but also > > "Berkeley Unix Nodes". For the latter, do you mean VAX? > > Yes, they are VAX-11/780 SIMH instances running 4.1BSD + MIT patches. > > > I don't know whether V8 ran on PDP-11 or not, but if that's your > > intent, you may want to start with a 2.xBSD or V7 as a base instead. > > The Chaosnet documentation says there were PDP-11 Unix V7 nodes on the > network. That code has not been found though. Same goes for VAX/VMS. > V7 could mean a modification of net unix or using that as a starting point. But without code that's just wild speculation on my part. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Jul 17 01:51:21 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 16 Jul 2022 11:51:21 -0400 (EDT) Subject: [TUHS] Unix V8 Chaosnet, any takers? Message-ID: <20220716155121.4873618C087@mercury.lcs.mit.edu> > From: Warner Losh > V7 could mean a modification of net unix What's "net unix" anyway? I know of the Net releases from CSRG, but this much precedes that. What did people with PDP-11 V7 who wanted TCP/IP do, anyway? Noel From imp at bsdimp.com Sun Jul 17 03:02:06 2022 From: imp at bsdimp.com (Warner Losh) Date: Sat, 16 Jul 2022 11:02:06 -0600 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <20220716155121.4873618C087@mercury.lcs.mit.edu> References: <20220716155121.4873618C087@mercury.lcs.mit.edu> Message-ID: On Sat, Jul 16, 2022 at 9:51 AM Noel Chiappa wrote: > > From: Warner Losh > > > V7 could mean a modification of net unix > > What's "net unix" anyway? I know of the Net releases from CSRG, but this > much precedes that. > I'm referring to the University of Illinois distribution that's in TUHS as Distributions/Early_Networking/NOSC. Steve Holmgren led the effort, and it was quite popular. It was V6 based (it came out in late V5 time frame, just before V6 was released and quickly updated, the version we have appears to be based on a pure V6 release). I have seen references to it in the ARPAnet census documents running on both V6 and V7 (though mostly they were silent about which version). It was NCP, not TCP/IP. I thought this was the normal nomenclature of the time, but I may be mistaken. > What did people with PDP-11 V7 who wanted TCP/IP do, anyway? > We also have BBN's stack as well in Distributions/Early_Networking/BBN. It appears to be for an 11/40, 11/45 or 11/70, though that's based purely on different files having '70', '45' and '40' in their name. These are also based on V6 (at least the code we have has a V6 layout and the few files I diff'd to V6 were pretty close). There's also an early VAX version in that directory as well. One could adapt either of these to V7, and I seem to recall seeing references to people that did that in the stuff I read for some of my early Unix talks, but I can't seem to find it right now. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Sun Jul 17 05:27:12 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 16 Jul 2022 21:27:12 +0200 Subject: [TUHS] V8 4BSD or 32V Based? (was: Unix V8 Chaosnet, any takers?) Message-ID: <4FE61203-9EDB-4984-B062-00D62215C248@planet.nl> > Regarding select, I recall that Dennis implemented it and passed it to > Berkeley*, but maybe not. He certainly had a hand in its design; I > distinctly remember talking to him about it after one of his trips out > west. That is an interesting comment. DMR was on the steering committee for what would become 4.2BSD. I once spoke with Kirk McKusick about the origins of the sockets API and I think he told me that there was a lot of debate in the committee whether descriptor readiness API should be stateful (like Haverty’s await() https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/ken/awaitr.c ) or stateless (like select). According to Sam Leffler (who I think added select() to 4.1c BSD) the select system call was somewhat modelled after the ADA select statement. I am speculating now, but I would not be surprised if dmr favoured the stateless design and contributed to its design. Paul From pnr at planet.nl Sun Jul 17 06:02:18 2022 From: pnr at planet.nl (Paul Ruizendaal) Date: Sat, 16 Jul 2022 22:02:18 +0200 Subject: [TUHS] Unix V8 Chaosnet, any takers? Message-ID: Apologies for being off-topic > What did people with PDP-11 V7 who wanted TCP/IP do, anyway? Taking it slightly broader (PDP-11 instead of V7), there is a lot of discussion about that on Mike Meuss’ TCP-digest mailing list: https://ftp.ripe.net/rfc/museum/tcp-ip-digest/ There is a 1985 index of available implementations as well ( https://ftp.ripe.net/rfc/museum/tcp-ip-implementations.txt.1 ). It includes the following options for PDP-11 systems: 1.7.5. UNIX 2.9BSD DESCRIPTION: 2.9BSD TCP/IP is an adaptation of Berkeley's original VAX TCP/IP (running under BSD 4.1B UNIX) which in turn is an offshoot of BBN's VAX TCP/IP. 2.9BSD TCP/IP runs on PDP-11/44s and PDP-11/70s. The 2.8 version from SRI was adapted by Bill Croft (formerly at SRI), then Tektronix adapted it for 2.9. Berkeley took over modification of the software and brought it back to SRI where Dan Chernikoff and Greg Satz adapted it for a later release of 2.9. In addition to TCP/IP, UDP, ARP and the raw packet interface is available. ICMP redirects are not supported. User software implementations include Telnet and FTP, plus Berkeley-developed local net protocols, RWHO, RSH, RLOGIN, and RCP. 2.9BSD with TCP/IP support could probably be made to run on smaller PDP-11s although the address space would be very tight and might present problems. 1.7.6. Venix/11 TCP/IP DESCRIPTION: This is based on the "PDP-11/45" implementation available from the MIT Laboratory for Computer Science. It has been ported to a V7 UNIX system, in particular VenturCom's Venix/11 V2.0. As little of the processing as possible takes place in the kernel, to minimize the code space required. It fits comfortably on I&D machines, but is almost hopeless on the smaller machines. The kernel includes a proNET device driver, IP fragment reassembly, IP header processing, local-net header processing, and simple routing. The rest of the IP processing, and all of the UDP and TCP functions, are in user libraries. The psuedo-teletype driver is also in the kernel, and is used by Server TELNET. User programs handle ICMP processing; User and Server TELNET, SMTP, TFTP, Finger, and Discard. There are User programs for Nicname and Hostname. IEN-116 nameservers are used by all programs, and an IEN-116 nameserver is also provided. The TCP used is very simple, not very fast, and lies about windows. No FTP is available, nor is one currently planned. 1.7.8. BBN-V6-UNIX DESCRIPTION: This TCP/IP/ICMP implementation runs as a user process in version 6 UNIX, with modifications obtained from BBN for network access. IP reassembles fragments into datagrams, but has no separate IP user interface. TCP supports user and server Telnet, echo, discard, internet SMTP mail, and FTP. ICMP generates replies to Echo Requests, and sends Source-Quench when reassembly buffers are full. 1. Hardware - PDP-11/70 and PDP-11/45 running UNIX version 6, with BBN IPC additions. 2. Software - written in C, requiring 25K instruction space, 20K data space. Supports 10 connections (including "listeners"). 3. Unimplemented protocol features: - TCP - Discards out-of-order segments. - IP - Does not handle some options and ICMP messages. 1.7.9. v 3COM-UNET DESCRIPTION: UNET is a communication software package which enables UNIX systems to communicate using TCP/IP protocols. UNET will utilize any physical communications media, from low speed links such as twisted pair RS-232C to high speed coaxial links such as Ethernet. All layers of the UNET package are directly available to the user. The highest layer provides user programs implementing ARPA standard File Transfer Protocol (UFTP), Virtual Terminal Protocol (UVTP), and Mail Transfer Protocols (UMTP). These programs in turn utilize the virtual circuit services of the TCP. The TCP protocol is implemented on top of the IP. Finally, IP can simultaneously interface to multiple local networks. UNET implements 5 of the 7 layers of the International Standards Organization Open Systems Interconnection Reference Model, layers 2 through 6: Link, Network, Transport, Session, and Presentation. Features of TCP 6 not yet implemented are Precedence and Security, End-of-Letter, and Urgent. Feature of IP 4 not yet implemented is Options. Of these, we have 2.9BSD and (a forerunner of) BBN-V6-Unix available on the TUHS Unix Tree. The Venix/11 source and the 3COM source appear lost. These (unfortunately) are the ones that were implemented on top of V7. Also, BBN back-ported the TCP/IP code of BBN VAX-TCP to V7 for their C/70 Unix. From jnc at mercury.lcs.mit.edu Mon Jul 18 09:39:59 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 17 Jul 2022 19:39:59 -0400 (EDT) Subject: [TUHS] Unix V8 Chaosnet, any takers? Message-ID: <20220717233959.E5C6018C09B@mercury.lcs.mit.edu> > From: Warner Losh >> What's "net unix" anyway? > I'm referring to the University of Illinois distribution Ah, OK. > I have seen references to it in the ARPAnet census documents running on > both V6 and V7 (though mostly they were silent about which version). Well, V7 came out in January, 1979, and NCP wasn't turned off until January, 1983, so people had a lot of time to get it running under V7. > I thought this was the normal nomenclature of the time, but I may be > mistaken. I'm not sure what it was usually called; we didn't have much contact with it at MIT (although I had the source; I'm the one that provided it to TUHS). The problem was that although MIT had two IMPs, all the ports on them were spoken for, for big time-sharing mainframes (4 PDP-10's running ITS; 1 running TWENEX; a Multics), so there were no ports available to plug in a lowly PDP-11. (We were unable to get an IP gateway (router) onto the ARPANET until MIT got some of the first C/30 IMPs.) So we had no use for the NCP Unix (which I vaguely recall was described as 'the ARPANET Unix from UIll'). Noel From ron at ronnatalie.com Mon Jul 18 11:01:21 2022 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 17 Jul 2022 21:01:21 -0400 Subject: [TUHS] Unix V8 Chaosnet, any takers? In-Reply-To: <20220717233959.E5C6018C09B@mercury.lcs.mit.edu> References: <20220717233959.E5C6018C09B@mercury.lcs.mit.edu> Message-ID: <989584CD-08CF-465B-88D1-8C0711B50D11@ronnatalie.com> We had NCP running on the JHU kernel which essentially a V6 kernel with extra stuff (including the ability to mount both V6 and V7 disks). This was done on an 11/34 at Xmas time 1982 when the Arpanet went to long leaders and the UofIll ANTS we had became obsolete. > On Jul 17, 2022, at 19:40, jnc at mercury.lcs.mit.edu wrote: > >  >> >> From: Warner Losh > >>> What's "net unix" anyway? > >> I'm referring to the University of Illinois distribution > > Ah, OK. > >> I have seen references to it in the ARPAnet census documents running on >> both V6 and V7 (though mostly they were silent about which version). > > Well, V7 came out in January, 1979, and NCP wasn't turned off until January, > 1983, so people had a lot of time to get it running under V7. > >> I thought this was the normal nomenclature of the time, but I may be >> mistaken. > > I'm not sure what it was usually called; we didn't have much contact with it > at MIT (although I had the source; I'm the one that provided it to TUHS). > > The problem was that although MIT had two IMPs, all the ports on them were > spoken for, for big time-sharing mainframes (4 PDP-10's running ITS; 1 > running TWENEX; a Multics), so there were no ports available to plug in a > lowly PDP-11. (We were unable to get an IP gateway (router) onto the ARPANET > until MIT got some of the first C/30 IMPs.) So we had no use for the NCP Unix > (which I vaguely recall was described as 'the ARPANET Unix from UIll'). > > Noel From meillo at marmaro.de Mon Jul 18 20:52:01 2022 From: meillo at marmaro.de (markus schnalke) Date: Mon, 18 Jul 2022 12:52:01 +0200 Subject: [TUHS] ed: multiple addresses (with semicolons) In-Reply-To: References: Message-ID: <1oDOM5-6wl-00@marmaro.de> Hoi. [2022-07-11 19:30] Douglas McIlroy > > > More was I curious about the documentation of address chains in books. > > It was even discussed in Lomutu and Lomuto, "A Unix Primer", a pleasant > book whose level is accurately described in the title. Thanks for the recommendation of this book. I now have a copy and am looking forward to reading it. It must have been a great book for users at the time (mainly covers editing and formatting) and now it looks to be a great book for someone interested in understanding how the experience of using Unix must have been to normal users back then. Although the semicolon address separator is explained in section 10.2.1 (page 143), I couldn't find address chains or supplying more addresses than necessary to commands mentioned in the book. Of course, as I haven't fully read it yet, I could have missed it, although I checked the relevant pages. Nonetheless, I'm happy with this new (old) book, which I luckily received in nearly mint condition. :-) meillo From jnc at mercury.lcs.mit.edu Tue Jul 19 03:07:35 2022 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 18 Jul 2022 13:07:35 -0400 (EDT) Subject: [TUHS] Unix V8 Chaosnet, any takers? Message-ID: <20220718170735.1401D18C08E@mercury.lcs.mit.edu> > From: Ron Natalie > We had NCP running on the JHU kernel Which NCP implementation was that, the one from UIUC, or something else? (I'm curious about the one that someone here - I forget who - mentioned, where IIRC they thought it was a new one, not the UIUC one. I'm a little boggled that with so little use for one - there weren't many NCP sites - someone would have gone to all the work to do another one. But it's possible...) If you all used the UIUC one, what did you call it? I looked through the email about releases from NOSC (who seemed to be the focal point for maintaining it at one point): https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/new/dist.log but it doesn't give a name for it. The documentation: https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/doc/IllinoisNCP.nr doesn't either (other than 'Illinois NCP'). It does seem that they were semi-using V7; see e.g.: https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/green/c.c but the code looks very V6-ish; see e.g.: https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/text.c Noel From meillo at marmaro.de Sat Jul 23 02:17:52 2022 From: meillo at marmaro.de (markus schnalke) Date: Fri, 22 Jul 2022 18:17:52 +0200 Subject: [TUHS] ed: f command (facts vs. file) In-Reply-To: <1oDOM5-6wl-00@marmaro.de> References: <1oDOM5-6wl-00@marmaro.de> Message-ID: <1oEvLc-6uI-00@marmaro.de> Hoi. [2022-07-18 12:52] markus schnalke > [2022-07-11 19:30] Douglas McIlroy > > > > Lomutu and Lomuto, "A Unix Primer" > > Thanks for the recommendation of this book. I now have a copy and > am looking forward to reading it. Now I enjoy reading through the book. Thereby I came across this piece of information (section 7.3.3, p. 87): (Historically, f stands for ``facts'', but most people prefer to think of it as an abbreviation for ``file''.) Why ``facts''? The manpage in 1st Edition does not list an f command at all. The manpage in 3rd Edition explains f as ``the filename command''. Assember and C sources of various editions all talk about filename and none about facts. Neither does ``facts'' seem to come from qed. I couldn't find an f command there at all. https://www.multicians.org/mspm/bx-9-06.681115.qed-editor.pdf http://www.bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condensed-guide.pdf What's the background for the comment about ``facts''? meillo From phil at ultimate.com Sat Jul 23 03:14:33 2022 From: phil at ultimate.com (Phil Budne) Date: Fri, 22 Jul 2022 13:14:33 -0400 Subject: [TUHS] ed: f command (facts vs. file) In-Reply-To: <1oEvLc-6uI-00@marmaro.de> References: <1oDOM5-6wl-00@marmaro.de> <1oEvLc-6uI-00@marmaro.de> Message-ID: <202207221714.26MHEX7W016226@ultimate.com> > What's the background for the comment about ``facts''? https://www.bell-labs.com/usr/dmr/www/qedman.pdf (for DMR's QED for GE-TSS on the GE 635): _History of QED_ The original QED was implemented at the University of California, Berkeley [4]. Substantially redesigned versions were written by the second author (KLT) for the CTSS system at MIT [1] and in BCPL for MULTICS. The latter version has also been available under GE-TSS using I/O routines supplied by A. W. Winikoff. _This version of QED_ The present incarnation of QED was implemented in GMAP by the first author (DMR). It offers noticeable improvements in speed, program size, and text packing density over the BCPL version, of which it is a direct descendant. New facilities include a redesigned Global command and a numerical capability The F(acts) command appears on page 9 (pdf page 10) The F command causes QED to type out 1) the number of words on QED's "free list", 2) the highest memory location used for text storage, and 3) the current core allocation. When the third number gets near 32K, take care not to exceed the core maximum. From tuhs at tuhs.org Sat Jul 23 12:57:47 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 23 Jul 2022 02:57:47 +0000 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? Message-ID: I've been looking into the history of the nl command lately, which has gotten me curious as to what facilities folks have used at various points in UNIX history for line numbering. The earliest version of nl I've found is in System III, and it does not derive from Research, PWB, or CB. Neither does it come from BSD, although BSD has the num command which, according to the source commentary, aims to replicate the '#' behavior of ex. Were there any other facilities for printing back arbitrary lines from a file with line numbers? Also, would anyone happen to know if the above appearance of nl might have been from the USG line given none of the others feature it? It neither seems to be in V8-V10. nl has managed to find its way into the POSIX standard, so it definitely has some staying power wherever it came from. - Matt G. From meillo at marmaro.de Sat Jul 23 15:47:05 2022 From: meillo at marmaro.de (markus schnalke) Date: Sat, 23 Jul 2022 07:47:05 +0200 Subject: [TUHS] ed: f command (facts vs. file) In-Reply-To: <202207221714.26MHEX7W016226@ultimate.com> References: <1oDOM5-6wl-00@marmaro.de> <1oEvLc-6uI-00@marmaro.de> <202207221714.26MHEX7W016226@ultimate.com> Message-ID: <1oF7yj-4s4-00@marmaro.de> Thanks, that explains it. meillo [2022-07-22 13:14] Phil Budne > > > What's the background for the comment about ``facts''? > > https://www.bell-labs.com/usr/dmr/www/qedman.pdf > (for DMR's QED for GE-TSS on the GE 635): > > _History of QED_ > The original QED was implemented at the University of > California, Berkeley [4]. Substantially redesigned versions > were written by the second author (KLT) for the CTSS system > at MIT [1] and in BCPL for MULTICS. The latter version has > also been available under GE-TSS using I/O routines supplied > by A. W. Winikoff. > > _This version of QED_ > The present incarnation of QED was implemented in GMAP by > the first author (DMR). It offers noticeable improvements > in speed, program size, and text packing density over the > BCPL version, of which it is a direct descendant. New > facilities include a redesigned Global command and a > numerical capability > > The F(acts) command appears on page 9 (pdf page 10) > > The F command causes QED to type out > 1) the number of words on QED's "free list", > 2) the highest memory location used for text storage, and > 3) the current core allocation. > > When the third number gets near 32K, take care not to exceed the core > maximum. > From meillo at marmaro.de Sat Jul 23 15:56:06 2022 From: meillo at marmaro.de (markus schnalke) Date: Sat, 23 Jul 2022 07:56:06 +0200 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: Message-ID: <1oF87S-4zW-00@marmaro.de> Hoi. [2022-07-23 04:57] segaloco via TUHS > > Were there any other facilities for printing back arbitrary lines > from a file with line numbers? As I'm currently thinking a lot about ed, this comes to mind: echo 23,42n | ed - file meillo From tuhs at tuhs.org Sat Jul 23 17:55:59 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sat, 23 Jul 2022 07:55:59 +0000 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: <1oF87S-4zW-00@marmaro.de> References: <1oF87S-4zW-00@marmaro.de> Message-ID: <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> > On Friday, July 22nd, 2022 at 10:56 PM, markus schnalke wrote: > > As I'm currently thinking a lot about ed, this comes to mind: > > echo 23,42n | ed - file The n rule is actually what lead me to studying nl. It's also supported in System III but not V7, although ed's n does show up in V8-V10. The implementation looks similar although integrated slightly differently. Probably from the same source though. There's also an implementation in 4.4BSD-Lite, although plan old 4.4 with the AT&T encumbered ed doesn't implement n. So a rough timeline I can see for line number filters based on source code, old docs, etc: 1977 - num and ex's '#' commands are introduced for 2BSD release 1980 - nl and ed's 'n' commands are introduced in System III 1980 - num's trail goes dark between 4 and 4.1c BSD 1982 - System V adopts ex, including '#' 1985 - Research has adopted ed with n by now as well as ex, never adopts nl 1992 - POSIX.2 is released, codifying nl, ed with n, and ex with # 1992 - nl appears in GNU fileutils 1994 - 4.4BSD-Lite ed includes n 1999 - NetBSD 1.4 adds nl 2002 - FreeBSD 4.5 adds nl 2005 - MacOSX 10.4 with text_cmds-47 adds nl 2013 - MINIX 3.2.1 adopts NetBSD nl 2014 - OpenBSD 5.5 adds nl So all in all, num was an attempt that petered out, but # stayed in ex. System III and 4.4BSD-Lite ed derivatives implement n, and nl was introduced in System III for the AT&T line and slowly cropped up elsewhere. System V picked up ex in 1982, allowing nl, ed with n, and ex with # in the AT&T line. GNU had one out of the gate when POSIX hit. BSDs were late to the party with regards to both ed with n as well as nl, with nl only being adopted after the last Berkeley releases and subsequent fracturing. So thus far it seems the earliest line numberer to see wide use was probably ex's #. System III's nl became the ubiquitous tool for the job and was then slowly adopted elsewhere. Ed rides a fine middle ground with the n command that saw wider adoption earlier. I still have to wonder if there was something earlier though. - Matt From crossd at gmail.com Sat Jul 23 21:01:33 2022 From: crossd at gmail.com (Dan Cross) Date: Sat, 23 Jul 2022 07:01:33 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> Message-ID: On Sat, Jul 23, 2022, 3:56 AM segaloco via TUHS wrote: > [snip] > So all in all, num was an attempt that petered out, but # stayed in ex. > System III and 4.4BSD-Lite ed derivatives implement n, and nl was > introduced in System III for the AT&T line and slowly cropped up > elsewhere. System V picked up ex in 1982, allowing nl, ed with n, and ex > with # in the AT&T line. GNU had one out of the gate when POSIX hit. BSDs > were late to the party with regards to both ed with n as well as nl, with > nl only being adopted after the last Berkeley releases and subsequent > fracturing. > It may be worth noting that BSD had `cat -n` in 4BSD by October, 1980: https://minnie.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/man/man1/cat.1 That may explain the relatively late incorporation of `nl` in, at least, the BSD lineage. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Jul 23 21:20:40 2022 From: cowan at ccil.org (John Cowan) Date: Sat, 23 Jul 2022 07:20:40 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> Message-ID: On Sat, Jul 23, 2022 at 7:03 AM Dan Cross wrote: > It may be worth noting that BSD had `cat -n` in 4BSD by October, 1980: > https://minnie.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/man/man1/cat.1 > > That may explain the relatively late incorporation of `nl` in, at least, > the BSD lineage. > An obvious approach, which would leave no real traces in documentation, would be: $ awk '{print NR, $0}' A more precise emulation would be more of a pain to type: $ awk '{printf("%6d\t%s\n", NR, $0)}' but perfectly usable in a script. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Sat Jul 23 22:00:10 2022 From: crossd at gmail.com (Dan Cross) Date: Sat, 23 Jul 2022 08:00:10 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> Message-ID: On Sat, Jul 23, 2022 at 7:20 AM John Cowan wrote: > On Sat, Jul 23, 2022 at 7:03 AM Dan Cross wrote: >> It may be worth noting that BSD had `cat -n` in 4BSD by October, 1980: https://minnie.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/man/man1/cat.1 >> >> That may explain the relatively late incorporation of `nl` in, at least, the BSD lineage. > > An obvious approach, which would leave no real traces in documentation, would be: > > $ awk '{print NR, $0}' > > A more precise emulation would be more of a pain to type: > > $ awk '{printf("%6d\t%s\n", NR, $0)}' > > but perfectly usable in a script. Yes, but awk wasn't widely available until 7th edition. I imagine work on it began before `num` in 2BSD, but few outside of Bell Labs would have seen it prior to 1978 or so. I wonder if the use-case was just sufficiently rare that no one felt like building a special tool and it was just done on an ad-hoc basis, if necessary. - Dan C. From norman at oclsc.org Sat Jul 23 22:49:44 2022 From: norman at oclsc.org (Norman Wilson) Date: Sat, 23 Jul 2022 08:49:44 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> Message-ID: <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> I had a vague memory that pr could be made to number lines, but a quick check of the 7/e manual says no. I expect Dan's right, and none of the 127 folks felt much need to number lines on printouts so nobody wrote the obvious simple tool. Ironic, since the Unix PDP-11 used by the patent licensing office (and I think shared with the research group, and that was how their first PDP-11 was justified and funded) happened because the patent folks needed line-numbered output and roff was easily modified to do that. Maybe Doug or Ken or Steve has first-hand memories. Norman Wilson Toronto ON (on a train shuffling toward Buffalo) From robpike at gmail.com Sat Jul 23 23:20:04 2022 From: robpike at gmail.com (Rob Pike) Date: Sat, 23 Jul 2022 23:20:04 +1000 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> Message-ID: Very odd. I thought so too, but the 8th Edition manual says pr -n prints in n columns, while the 9th and 10th say it numbers the lines. No memory, if I ever knew, of what triggered that change. -rob On Sat, Jul 23, 2022 at 10:50 PM Norman Wilson wrote: > > I had a vague memory that pr could be made > to number lines, but a quick check of the 7/e > manual says no. > > I expect Dan's right, and none of the 127 folks > felt much need to number lines on printouts > so nobody wrote the obvious simple tool. > > Ironic, since the Unix PDP-11 used by the patent > licensing office (and I think shared with the > research group, and that was how their first > PDP-11 was justified and funded) happened > because the patent folks needed line-numbered > output and roff was easily modified to do that. > > Maybe Doug or Ken or Steve has first-hand > memories. > > Norman Wilson > Toronto ON > (on a train shuffling toward Buffalo) From ralph at inputplus.co.uk Sat Jul 23 23:36:56 2022 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 23 Jul 2022 14:36:56 +0100 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> Message-ID: <20220723133656.E196821CB6@orac.inputplus.co.uk> Hi Rob, > Very odd. I thought so too, but the 8th Edition manual says pr -n > prints in n columns, while the 9th and 10th say it numbers the lines. 8th Edition's pr.c has -n and -x which both turn on line numbers. The optional argument gives the width used for the line number. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/pr.c case 'n': case 'x': /* retained for historical reasons */ ++Lnumb; if ((Numw = intopt(argv, &Nsepc)) <= 0) Numw = NUMW; if (Lnumb && C != EOF && (colno == 0 || Multi == 'a')) { if (Page >= Fpage) { putspace(); printf("%*ld", Numw, Buffer ? Colpts[colno].c_lno++ : Lnumb); Outpos += Numw; put(Nsepc); } ++Lnumb; } I think -n and -x are undocumented in the matching man page. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V8/usr/man/man1/pr.1 The -n you're referring to is an italic ‘n’, e.g. -3 for three columns. .TP .BI \- n Produce .IR n -column output. -- Cheers, Ralph. From cowan at ccil.org Sun Jul 24 00:33:09 2022 From: cowan at ccil.org (John Cowan) Date: Sat, 23 Jul 2022 10:33:09 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> Message-ID: On Sat, Jul 23, 2022 at 9:21 AM Rob Pike wrote: Very odd. I thought so too, but the 8th Edition manual says pr -n > prints in n columns, I'm almost certain that -n here means that -2 is 2 columns, -3 columns, etc., and that there is no actual -n switch. In Posix as well as more modern man pages this is spelled -COLUMNS: see man.cat-v.org. > while the 9th and 10th say it numbers the lines. > I think this may have come from BSD; it is now part of Posix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sun Jul 24 03:35:43 2022 From: clemc at ccc.com (Clem Cole) Date: Sat, 23 Jul 2022 13:35:43 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> Message-ID: Norman - I think your memory is fine. pr -n (lower case) was an addition early on with pr +1 or pr +2 *etc* also parsed. I'm going to guess that addition was either a local hack done by a lot of people or maybe on the Harvard Tape and distributed from there. It certainly worked that way in the CMU v6 and later v7. But I also remember that I had to reprogram my fingers to pr -N (capital N) when I hit other versions ??maybe AT&T Sys III??. I also remember that at CMU, tjk did not like it / was not needed because he contended we already had num(1) already on the EE systems (but not CS BTW). Ifwe had had shell aliases in those days, I might have agreed with him. But given that it was not part of v5, v6 or v7, that we only had a num(1) on the EE and Mellon systems and not generally rippled to the other CMU UNIX systems around campus, I going to take a WAG that Ted brought num(1) with him from UoMich (- which would make sense - because the BSD history says Joy wrote it). So maybe ??probably?? the origin story for num(1) is that it came to UCB from Umich when Bill and Ted were undergrads there. FWIW: pr -n is what macOS does today. ᐧ On Sat, Jul 23, 2022 at 8:50 AM Norman Wilson wrote: > I had a vague memory that pr could be made > to number lines, but a quick check of the 7/e > manual says no. > > I expect Dan's right, and none of the 127 folks > felt much need to number lines on printouts > so nobody wrote the obvious simple tool. > > Ironic, since the Unix PDP-11 used by the patent > licensing office (and I think shared with the > research group, and that was how their first > PDP-11 was justified and funded) happened > because the patent folks needed line-numbered > output and roff was easily modified to do that. > > Maybe Doug or Ken or Steve has first-hand > memories. > > Norman Wilson > Toronto ON > (on a train shuffling toward Buffalo) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Sun Jul 24 04:40:36 2022 From: phil at ultimate.com (Phil Budne) Date: Sat, 23 Jul 2022 14:40:36 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> Message-ID: <202207231840.26NIea2P042721@ultimate.com> If the object is to print all lines with a number, I've always used "grep -n ." From beebe at math.utah.edu Sun Jul 24 04:51:00 2022 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Sat, 23 Jul 2022 12:51:00 -0600 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: <202207231840.26NIea2P042721@ultimate.com> Message-ID: Phil Budne suggests "grep -n ." to print numbered lines. That mostly works, but loses blank lines, although they are properly counted. I typically use awk '{print FNR ":" $0}' instead, which reports all lines, regardless of contents. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From douglas.mcilroy at dartmouth.edu Sun Jul 24 05:07:25 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 23 Jul 2022 15:07:25 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <202207231840.26NIea2P042721@ultimate.com> Message-ID: Did you use "grep -n '.' "? grep -n '^' matches blank lines, too. Doug On Sat, Jul 23, 2022 at 2:51 PM Nelson H. F. Beebe wrote: > > Phil Budne suggests "grep -n ." to print numbered > lines. > > That mostly works, but loses blank lines, although they are properly > counted. I typically use > > awk '{print FNR ":" $0}' > > instead, which reports all lines, regardless of contents. > > ------------------------------------------------------------------------------- > - Nelson H. F. Beebe Tel: +1 801 581 5254 - > - University of Utah - > - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - > - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - > - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - > ------------------------------------------------------------------------------- From douglas.mcilroy at dartmouth.edu Sun Jul 24 12:42:02 2022 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 23 Jul 2022 22:42:02 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? Message-ID: I've not seen an earlier post of mine on this topic; apologies if this is a duplicate. Roff was probably the earliest way to get a line-numbered file listing. Of course it took a bit of chicanery to apply it to a roff input file, but even that was not a big shell script. As has often been told, Joe Ossanna used to promise of line numbers (required by USPTO) to attract the Bell Labs patent department as the first Unix "customer". Doug From rtomek at ceti.pl Mon Jul 25 05:02:53 2022 From: rtomek at ceti.pl (Tomasz Rola) Date: Sun, 24 Jul 2022 21:02:53 +0200 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> Message-ID: <20220724190253.GA23421@tau1.ceti.pl> On Sat, Jul 23, 2022 at 08:00:10AM -0400, Dan Cross wrote: > On Sat, Jul 23, 2022 at 7:20 AM John Cowan wrote: [...] > > An obvious approach, which would leave no real traces in documentation, would be: > > > > $ awk '{print NR, $0}' > > > > A more precise emulation would be more of a pain to type: > > > > $ awk '{printf("%6d\t%s\n", NR, $0)}' > > > > but perfectly usable in a script. > > Yes, but awk wasn't widely available until 7th edition. I imagine work > on it began before `num` in 2BSD, but few outside of Bell Labs would > have seen it prior to 1978 or so. > > I wonder if the use-case was just sufficiently rare that no one felt like > building a special tool and it was just done on an ad-hoc basis, if > necessary. My sed-fu is only rudimentary but after banging my head against monitor a bit, I came up with this: $ wc -l c.lisp 90 c.lisp $ cat c.lisp | sed -e '{=;}' | sed -e 'N;s/\n/ /' Seems to print what is needed. Now, just embed it in sh script. A program in C could be longer, and required a compiler. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From imp at bsdimp.com Mon Jul 25 05:45:52 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 24 Jul 2022 13:45:52 -0600 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> Message-ID: By 1984 (so some years after the formative stage in the era between 4.2BSD and 4.3BSD), there were a number of different programs on the net (USENET's source groups) to pretty print things on laser or line printers: grind, tgrind, vgrind, ete. These all had a dozen different ways to gaudy up the output (err, present the listing in a more aesthetically pleasing way): Line numbers, line numbers every 5 or 10 lines, line spacing tweaks, keywords as bold or italics, frames around the output, "two up" printing, various special behavior for functions (grey bands for start of functions, function definitions in bold, etc), as well as specialized options for assembler / object renderings, etc. Most were targeted at laser printers, but some were a better version of pr/lpr for line printer output. Some targeted postscript directly, while others used TeX, troff, etc in a pipeline to gain some device independence. Oh what a long way from pr -n these were. But at the time it really helped me to understand the power of the unix philosophy because these 'all in' approaches were great until you wanted to get a few steps beyond the beaten path and then it became impossible (given the great number of combinatorics for these options, many of the programs produced odd results for some combinations of options). For day to day stuff, I hated these and used simpler options. But for producing nice looking listings for appendixes for papers / reports / assignments I'd written for school they weren't half bad if you avoided the worst of the gaudiness options. :) Warner On Sat, Jul 23, 2022 at 7:21 AM Rob Pike wrote: > Very odd. I thought so too, but the 8th Edition manual says pr -n > prints in n columns, while the 9th and 10th say it numbers the lines. > > No memory, if I ever knew, of what triggered that change. > > -rob > > On Sat, Jul 23, 2022 at 10:50 PM Norman Wilson wrote: > > > > I had a vague memory that pr could be made > > to number lines, but a quick check of the 7/e > > manual says no. > > > > I expect Dan's right, and none of the 127 folks > > felt much need to number lines on printouts > > so nobody wrote the obvious simple tool. > > > > Ironic, since the Unix PDP-11 used by the patent > > licensing office (and I think shared with the > > research group, and that was how their first > > PDP-11 was justified and funded) happened > > because the patent folks needed line-numbered > > output and roff was easily modified to do that. > > > > Maybe Doug or Ken or Steve has first-hand > > memories. > > > > Norman Wilson > > Toronto ON > > (on a train shuffling toward Buffalo) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Jul 25 06:33:05 2022 From: tuhs at tuhs.org (segaloco via TUHS) Date: Sun, 24 Jul 2022 20:33:05 +0000 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> Message-ID: All this discussion is making me incredibly glad I posed the question, as it does indeed seem that before num and nl, line numbering was more of a "to each their own" rather than there being a canonical best practice. By the way, what inspired the whole quandary in the first place was doing some editing on a V6 UNIX system and realizing I hadn't the foggiest idea of how to get the system to spit back line numbers to remind myself what addresses to supply to various ed commands. I suppose at the time using a context search was such an effective means of getting ed's cursor where you wanted it that having a means to number lines wasn't crucial to effectively working in ed, so long as one was good with their regex and searching. I'm realizing I might need to reach out to the maintainer of the nl manpage in FreeBSD (and perhaps other OSs and distros) as the history section of the page posits that nl was first introduced in SVR2, when in reality the earliest public offering was System III, although the trail goes cold at that point, I can only assume it came from USG. - Matt G. From imp at bsdimp.com Mon Jul 25 07:04:05 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 24 Jul 2022 15:04:05 -0600 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <83CADD1C2866986767CAF9251E6EF882.for-standards-violators@oclsc.org> Message-ID: On Sun, Jul 24, 2022 at 2:33 PM segaloco wrote: > All this discussion is making me incredibly glad I posed the question, as > it does indeed seem that before num and nl, line numbering was more of a > "to each their own" rather than there being a canonical best practice. > > By the way, what inspired the whole quandary in the first place was doing > some editing on a V6 UNIX system and realizing I hadn't the foggiest idea > of how to get the system to spit back line numbers to remind myself what > addresses to supply to various ed commands. I suppose at the time using a > context search was such an effective means of getting ed's cursor where you > wanted it that having a means to number lines wasn't crucial to effectively > working in ed, so long as one was good with their regex and searching. > > I'm realizing I might need to reach out to the maintainer of the nl > manpage in FreeBSD (and perhaps other OSs and distros) as the history > section of the page posits that nl was first introduced in SVR2, when in > reality the earliest public offering was System III, although the trail > goes cold at that point, I can only assume it came from USG. > I can update it. Done. https://cgit.freebsd.org/src/commit/?id=8a02ea1dbc139862456f488464072719341658d7 Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Mon Jul 25 07:04:46 2022 From: imp at bsdimp.com (Warner Losh) Date: Sun, 24 Jul 2022 15:04:46 -0600 Subject: [TUHS] Mailing list archives Message-ID: So where are the mailing list archives? I found one with google on minnie, but it stops a few weeks ago... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Mon Jul 25 08:53:52 2022 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 25 Jul 2022 08:53:52 +1000 Subject: [TUHS] Mailing list archives In-Reply-To: References: Message-ID: On Sun, Jul 24, 2022 at 03:04:46PM -0600, Warner Losh wrote: > So where are the mailing list archives? I found one with google on > minnie, but it stops a few weeks ago... > Warner The mailman3 TUHS archive is at https://minnie.tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/ The mailman2 archive is at https://minnie.tuhs.org/pipermail/tuhs/ But for some reason I had to kick mailman2 as it had stopped archiving a couple of weeks ago. Wish I knew the reason for this :-( It's the second time I've had to kick it. Cheers, Warren From michel at ngelo.eu Mon Jul 25 13:44:05 2022 From: michel at ngelo.eu (Michelangelo De Simone) Date: Sun, 24 Jul 2022 20:44:05 -0700 Subject: [TUHS] RUNCOM and Multics: the origin of "rc" file Message-ID: Hi, long time lurker here. Today I ended up on an article by Christian Lee Seibold about the origin of shells [1]. Coincidentally the article explained how the “rc” files came to be and why they’re called “rc”: everything started with RUNCOM and Multics. An excerpt from the article: ==== Unix Shells have had a very long history, and it all starts with a program written by Louis Pouzin for the MIT CTSS Operating System, called RUNCOM (which stood for “run commands”). It executed commands from a file, called “a runcom”. According to Kernighan and Ritchie[1], “rc” configuration files from Unix descended from this. Tom Van Vleck also gives origins of Unix’s use of “rc” to RUNCOM [2], and notes that the first time he read the term “shell” was from Multics documentation created by Doug Eastwood. According to Louis Pouzin, he coined the word “shell”. ==== Well, now I know… [1] https://portal.mozz.us/gemini/auragem.space/~krixano/ShellHistory-Unix.pdf — Michelangelo From gctersteeg at gmail.com Wed Jul 27 18:02:01 2022 From: gctersteeg at gmail.com (Gavin Tersteeg) Date: Wed, 27 Jul 2022 03:02:01 -0500 Subject: [TUHS] LSX issues and musing In-Reply-To: References: <20220711234729.2E9F418C096@mercury.lcs.mit.edu> Message-ID: Well, it has been almost 2 weeks since my last post on this thread. Since there is so little information about LSX online, I might as well post all that I have done / noticed. First things first, the kernel building issue was as simple as I was expecting. All of the build scripts are meant for an external V6 system, and do not work on LSX itself. I forgot that the LSX linker defaults to 040000 instead of 0 which obviously broke my kernel. Setting the "-a" flag on the linker and fixing config stuff in param.h, header.s, and mch.s was all that was needed to make it work. Next up was converting the userspace from 16K to 20K. I tried to use an external compiler as little as possible and was mostly successful doing so. "ed.c" needed to be broken up into 2 different files, but everything else worked. The only thing that needed to be cross compiled was the C compiler itself. As it turns out, the stock C compiler that LSX comes with does not have enough "OSSIZ" in order to build the 2nd pass of the compiler. Interestingly enough, compiling it with the full space only makes the 2nd pass go up to 23K-ish size. It just barely fits in the userspace, but it does work. I don't know why the original creators of the root image didn't start with this. Speaking of the C compiler, mounting the "cc.dsk" file from the archives on LSX is a bad idea. Unlike every other image, it is formatted for 500 blocks instead of 400. Trying to write to this filesystem will cause the swap space to get overwritten, which is generally not a good thing. After the kernel and userspace were working, I went ahead and started making modifications to the kernel. The first goal involved re-adding the RAW tty mode. Turns out, this was super simple and only took like 10 minutes of copying "if" statements. After that, my custom V6 screen editor compiled and worked flawlessly. Finally, tonight I was able to get a RK05 driver to work alongside the default RX01 driver. This one was a little bit more of a challenge, as all of the block device switch code has been ripped out of LSX. Device drivers also work slightly differently, as some driver support functions are removed and "buf.h" is set up to only use 8-bit dev IDs. After adding back a simplified "bdevsw[]", some modifications to "bio.c", and a whole lot of tinkering I was able to get RK0 auto-mounted on "/mnt". Should make moving lots of files *much* easier, plus it will facilitate my future plans for the project. I think my next goal is to add back the "mount" and "umount" syscalls. I got about 2200 bytes free of kernel space, so that should be more than enough room to add those functions in. After that, i'll just need to write a RX02 driver and make the jump over to real hardware. Of course, the mystery swap bug still persists. Thanks for reading, Gavin On Fri, Jul 15, 2022 at 3:07 AM Gavin Tersteeg wrote: > Well, I have spent a few more days tentatively messing around with LSX, > and I have noticed a few things. > > First off, the C compiler is not the only program to have occasional > issues. Sometimes the "mv" command also fails with the > oh-so-descriptive "?" error. By the looks of it, this error is caused by > something going wrong with a fork() and subsequent wait() syscall. That > recurring error in the C compiler is also caused by the 2nd pass of the C > compiler not being able to find a temporary file created by the 1st pass. > If the 1st pass was failing to run, then that would explain why the 2nd > pass isn't able to find that temporary file. This has me guessing that > there may be something wrong with fork() or exec(). Whenever it is, it > doesn't dumpster memory or blow up the filesystem. For all I know, it may > be an emulation issue too, but I have no way of testing it right now. > > The current kernel I am building is under 16KB at the moment. My goal is > to be able to recreate the stock (semi?) functional kernel, and then do > modifications from there. This goal has not been reached, as this kernel > simply crashes on startup. It is either a HALT instruction or a stack issue > depending on if the kernel has been stripped or not. I bet I am building it > wrong again :/, it doesn't need to be reloc'd after the "ld -X" does it? > > Has anyone actually been able to get a system to build with the archived > LSX disks? I have poured over the config files many times, but I feel like > I am missing something painfully obvious... > > On Mon, Jul 11, 2022 at 6:47 PM Noel Chiappa > wrote: > >> > From: Paul Ruizendaal >> >> > Note that LSX only holds one process in core and swaps other >> processes >> > (NPROC = 3) out to floppy. It reportedly took several hours for the >> > Terak to self-compile LSX from source. >> >> If one is working in a simulator, and not a real hardware PDP-11, there's >> a >> 'trick' one can use to make life a lot easier - for MINI-UNIX, at least; >> I'll >> comment on LSX below. >> >> As I report in the MINI-UNIX Computer History Wiki article: "MINI-UNIX >> uses >> the same file system as V6; this allows MINI-UNIX packs to be 'mounted' >> on V6 >> systems (either real, or simulated), which is very convenient for working >> on >> them." So just spin up a V6 in the simulator, mount the LSX/MINI-UNIX >> pack, >> and away you go. The V6 toolchain can be used to compile/link kernels; to >> link user commands one will need to import the LSX/MINI-UNIX loader >> (which, >> since V6 is source compatible with LSX/MINI-UNIX, is trivial). >> >> LSX is potentially more complex, as it supports _two different_ file >> system >> formats: the standard V6 one, and a 'contiguous' one which is very similar >> to the V6 one (rdwri.c has no conditionals on CONTIG; not so alloc.c, >> though), but is not fully compatible. So non-contiguous LSX file systems >> can be mounted under V6, but not contiguous ones. >> >> Noel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heinz at osta.com Thu Jul 28 02:24:26 2022 From: heinz at osta.com (Heinz Lycklama) Date: Wed, 27 Jul 2022 09:24:26 -0700 Subject: [TUHS] LSX issues and musing In-Reply-To: References: <20220711234729.2E9F418C096@mercury.lcs.mit.edu> Message-ID: <9293a145-bdd1-bd79-0977-6f825da56093@osta.com> Gavin, looks like you have figured most things out about LSX and Mini-Unix (both of which I am the other of while at BTL). There are some similarities between the two but LSX is more complex because it supports some real-time features and contiguous files. I was able to compile the operating system source code for both running on themselves while at BTL. I'm not familiar with all of the work done by others since then, but there is some original documentation for each of the systems still available. LSX is documented in the BSTJ, and there is a memo on MIni-UNIX online here:     1. http://www.tavi.co.uk/unixhistory/mini-unix/Mini-UNIX_Memo.txt         [Explains mods made to programs. Much of this applies to LSX]     2. https://www.tuhs.org/cgi-bin/utree.pl?file=Mini-Unix/usr/doc/new/     3. https://gunkies.org/wiki/MINI-UNIX You can also find my original memo on Mini-UNIX [titled TM-77-1352-1_The_MINI-UNIX_19770103.pdf] in this online directory of my Technical Memos.     4. https://tuhs.pdp-11.org.ru/Documentation/TechReports/Heinz_Tech_Memos/ The files in #4 also used to be online in https://tuhs.org/ but I can't seem to find them at this time. Hope this is all helpful to you. Heinz On 7/27/2022 1:02 AM, Gavin Tersteeg wrote: > Well, it has been almost 2 weeks since my last post on this thread. > Since there is so little information about LSX online, I might as well > post all that I have done / noticed. > > First things first, the kernel building issue was as simple as I was > expecting. All of the build scripts are meant for an external V6 > system, and do not work on LSX itself. I forgot that the LSX linker > defaults to 040000 instead of 0 which obviously broke my kernel. > Setting the "-a" flag on the linker and fixing config stuff in > param.h, header.s, and mch.s was all that was needed to make it work. > > Next up was converting the userspace from 16K to 20K. I tried to use > an external compiler as little as possible and was mostly successful > doing so. "ed.c" needed to be broken up into 2 different files, but > everything else worked. The only thing that needed to be cross > compiled was the C compiler itself. As it turns out, the stock C > compiler that LSX comes with does not have enough "OSSIZ" in order to > build the 2nd pass of the compiler. Interestingly enough, compiling it > with the full space only makes the 2nd pass go up to 23K-ish size. It > just barely fits in the userspace, but it does work. I don't know why > the original creators of the root image didn't start with this. > > Speaking of the C compiler, mounting the "cc.dsk" file from the > archives on LSX is a bad idea. Unlike every other image, it is > formatted for 500 blocks instead of 400. Trying to write to this > filesystem will cause the swap space to get overwritten, which is > generally not a good thing. > > After the kernel and userspace were working, I went ahead and started > making modifications to the kernel. The first goal involved re-adding > the RAW tty mode. Turns out, this was super simple and only took like > 10 minutes of copying "if" statements. After that, my custom V6 screen > editor compiled and worked flawlessly. > > Finally, tonight I was able to get a RK05 driver to work alongside the > default RX01 driver. This one was a little bit more of a challenge, as > all of the block device switch code has been ripped out of LSX. Device > drivers also work slightly differently, as some driver support > functions are removed and "buf.h" is set up to only use 8-bit dev IDs. > After adding back a simplified "bdevsw[]", some modifications to > "bio.c", and a whole lot of tinkering I was able to get RK0 > auto-mounted on "/mnt". Should make moving lots of files *much* > easier, plus it will facilitate my future plans for the project. > > I think my next goal is to add back the "mount" and "umount" syscalls. > I got about 2200 bytes free of kernel space, so that should be more > than enough room to add those functions in. After that, i'll just need > to write a RX02 driver and make the jump over to real hardware. Of > course, the mystery swap bug still persists. > > Thanks for reading, > Gavin > > On Fri, Jul 15, 2022 at 3:07 AM Gavin Tersteeg > wrote: > > Well, I have spent a few more days tentatively messing around with > LSX, and I have noticed a few things. > > First off, the C compiler is not the only program to have > occasional issues. Sometimes the "mv" command also fails with the > oh-so-descriptive "?" error. By the looks of it, this error is > caused by something going wrong with a fork() and subsequent > wait() syscall. That recurring error in the C compiler is also > caused by the 2nd pass of the C compiler not being able to find a > temporary file created by the 1st pass. If the 1st pass was > failing to run, then that would explain why the 2nd pass isn't > able to find that temporary file. This has me guessing that there > may be something wrong with fork() or exec(). Whenever it is, it > doesn't dumpster memory or blow up the filesystem. For all I know, > it may be an emulation issue too, but I have no way of testing it > right now. > > The current kernel I am building is under 16KB at the moment. My > goal is to be able to recreate the stock (semi?) functional > kernel, and then do modifications from there. This goal has not > been reached, as this kernel simply crashes on startup. It is > either a HALT instruction or a stack issue depending on if the > kernel has been stripped or not. I bet I am building it wrong > again :/, it doesn't need to be reloc'd after the "ld -X" does it? > > Has anyone actually been able to get a system to build with the > archived LSX disks? I have poured over the config files many > times, but I feel like I am missing something painfully obvious... > > On Mon, Jul 11, 2022 at 6:47 PM Noel Chiappa > wrote: > >     > From: Paul Ruizendaal > >     > Note that LSX only holds one process in core and swaps > other processes >     > (NPROC = 3) out to floppy. It reportedly took several > hours for the >     > Terak to self-compile LSX from source. > > If one is working in a simulator, and not a real hardware > PDP-11, there's a > 'trick' one can use to make life a lot easier - for MINI-UNIX, > at least; I'll > comment on LSX below. > > As I report in the MINI-UNIX Computer History Wiki article: > "MINI-UNIX uses > the same file system as V6; this allows MINI-UNIX packs to be > 'mounted' on V6 > systems (either real, or simulated), which is very convenient > for working on > them." So just spin up a V6 in the simulator, mount the > LSX/MINI-UNIX pack, > and away you go. The V6 toolchain can be used to compile/link > kernels; to > link user commands one will need to import the LSX/MINI-UNIX > loader (which, > since V6 is source compatible with LSX/MINI-UNIX, is trivial). > > LSX is potentially more complex, as it supports _two > different_ file system > formats: the standard V6 one, and a 'contiguous' one which is > very similar > to the V6 one (rdwri.c has no conditionals on CONTIG; not so > alloc.c, > though), but is not fully compatible. So non-contiguous LSX > file systems > can be mounted under V6, but not contiguous ones. > >         Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtomek at ceti.pl Thu Jul 28 10:30:14 2022 From: rtomek at ceti.pl (Tomasz Rola) Date: Thu, 28 Jul 2022 02:30:14 +0200 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: <20220724190253.GA23421@tau1.ceti.pl> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> Message-ID: <20220728003014.GB6195@tau1.ceti.pl> On Sun, Jul 24, 2022 at 09:02:53PM +0200, Tomasz Rola wrote: > On Sat, Jul 23, 2022 at 08:00:10AM -0400, Dan Cross wrote: > > On Sat, Jul 23, 2022 at 7:20 AM John Cowan wrote: > [...] > > > An obvious approach, which would leave no real traces in documentation, would be: > > > > > > $ awk '{print NR, $0}' [...] > > > $ awk '{printf("%6d\t%s\n", NR, $0)}' [...] > > Yes, but awk wasn't widely available until 7th edition. I imagine work > > on it began before `num` in 2BSD, but few outside of Bell Labs would > > have seen it prior to 1978 or so. [...] > $ cat c.lisp | sed -e '{=;}' | sed -e 'N;s/\n/ /' Ok, so maybe this is no longer very interesting subject, but I recalled there was once a language named SNOBOL. Wikipedia says, sed was written around 1974 [1] and about SNOBOL it says, the language was being taught [2] in the late 1960s and early 1970s in universities, so I guess it was quite popular. I wonder if it was ported to Unix early enough to help before sed became available? Anyway, I have got Phil Budne's implementation [3] and after usual drill (configure, make, make install, stow) I could do this: $ snobol4 -b -L ./numlines02.sno < numlines02.sno 1 lnum = 0 2 loop lnum = lnum + 1 3 output = lnum " " input :s(loop) 4 end The first version did not work so well: $ snobol4 -b -L ./numlines01.sno < numlines01.sno | head -8 1 lnum = 0 2 LOOP line = INPUT 3 * Here: detect EOF (how?) and jump to : END 4 lnum = lnum + 1 5 OUTPUT = lnum " " line : S(LOOP) 6 END 7 END 8 END As I already have understood, even after reaching end of input, the INPUT statement keeps returning last line read, counter keeps increasing and last line is being written out for infinity. I have not read any serious docs on SNOBOL yet, so I have no idea how to make the '01' version work, but this is of rather small importance to the list. However, since [2] claims SNOBOL was written in Bell Labs, just like AWK and sed, so perhaps they could be using SNOBOL? [1] https://en.wikipedia.org/wiki/Sed [2] https://en.wikipedia.org/wiki/SNOBOL [3] http://www.regressive.org/snobol4/ -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From phil at ultimate.com Thu Jul 28 11:03:35 2022 From: phil at ultimate.com (Phil Budne) Date: Wed, 27 Jul 2022 21:03:35 -0400 Subject: [TUHS] Line Numbers Before SysIII nl? BSD num? In-Reply-To: <20220728003014.GB6195@tau1.ceti.pl> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> Message-ID: <202207280103.26S13ZL5059300@ultimate.com> > Anyway, I have got Phil Budne's implementation C'est moi! SNOBOL came out of Bell Labs in Holmdel NJ. There was a SNOBOL3 implementation in Unix 6th Edition days called "sno". As far as I know Macro SNOBOL4 (that my CSNOBOL4 is a port of) never was ported to the PDP-11 (just not enough address space), but there was a proposal (at least) for a SNOBOL4 implementation for the '11 called ELFBOL. Macro SPITBOL (a faster implementation of SNOBOL4) was available on the Research Unix VAXen (Andrew Koenig did a C-like preprocessor called SNOCONE -- SNOBOL with some sugar). Phil From whm at msweng.com Thu Jul 28 14:13:04 2022 From: whm at msweng.com (William H. Mitchell) Date: Wed, 27 Jul 2022 22:13:04 -0600 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <202207280103.26S13ZL5059300@ultimate.com> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> Message-ID: <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> If memory serves, Ralph Griswold once told me that the four versions of SNOBOL, culminating with SNOBOL4, took, respectively, a day, a week, a month, and year to implement. Related to SNOBOL, something I’ve wondered about for years is whether I may have been the only regular user of RATSNO, which Dave Hanson created as a test of RATFOR’s retargetability. I stumbled across RATSNO on the Icon V2 tape, and used it for quite a bit of my undergraduate programming at NC State in 1980-81. Phil Budne: Thanks for your CSNOBOL4 implementation! I’ve used it to show students SNOBOL4 in a comparative languages class at the U of Arizona. (I was thinking your name sounded familiar!) > On Jul 27, 2022, at 7:03 PM, Phil Budne wrote: > >> Anyway, I have got Phil Budne's implementation > > C'est moi! SNOBOL came out of Bell Labs in Holmdel NJ. > There was a SNOBOL3 implementation in Unix 6th Edition days called "sno". > > As far as I know Macro SNOBOL4 (that my CSNOBOL4 is a port of) never > was ported to the PDP-11 (just not enough address space), but there > was a proposal (at least) for a SNOBOL4 implementation for the '11 > called ELFBOL. > > Macro SPITBOL (a faster implementation of SNOBOL4) was available on > the Research Unix VAXen (Andrew Koenig did a C-like preprocessor > called SNOCONE -- SNOBOL with some sugar). > > Phil From stuff at riddermarkfarm.ca Fri Jul 29 10:22:14 2022 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Thu, 28 Jul 2022 20:22:14 -0400 Subject: [TUHS] SNOBOL and progeny [Was: Re: Re: Line Numbers Before SysIII nl? BSD num?] In-Reply-To: <202207280103.26S13ZL5059300@ultimate.com> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> Message-ID: <19b82d6e-6b8e-7b49-69ca-e63d0e3c5856@riddermarkfarm.ca> On 2022-07-27 21:03, Phil Budne wrote: >> Anyway, I have got Phil Budne's implementation > C'est moi! SNOBOL came out of Bell Labs in Holmdel NJ. > There was a SNOBOL3 implementation in Unix 6th Edition days called "sno". > > As far as I know Macro SNOBOL4 (that my CSNOBOL4 is a port of) never > was ported to the PDP-11 (just not enough address space), but there > was a proposal (at least) for a SNOBOL4 implementation for the '11 > called ELFBOL. > > Macro SPITBOL (a faster implementation of SNOBOL4) was available on > the Research Unix VAXen (Andrew Koenig did a C-like preprocessor > called SNOCONE -- SNOBOL with some sugar). > > Phil I recall seeing ICEBOL card packs at the U. of Toronto Computing Centre decades ago but I know nothing more. N. From dave at horsfall.org Fri Jul 29 14:28:19 2022 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 29 Jul 2022 14:28:19 +1000 (EST) Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> Message-ID: I did get SPITBOL to work past its expiry date on OS/360 :-) It was dubbed as the "Superzap of the year" by one of my CompSci lecturers (Dr. G.McMahon, UNSW). The first couple of time-bombs were easy to find, but not so the rest (long story). Probably belongs over on COFF now... -- Dave From sauer at technologists.com Fri Jul 29 15:01:48 2022 From: sauer at technologists.com (Charles H. Sauer) Date: Fri, 29 Jul 2022 00:01:48 -0500 Subject: [TUHS] SNOBOL and progeny [Was: Re: Re: Line Numbers Before SysIII nl? BSD num?] In-Reply-To: <19b82d6e-6b8e-7b49-69ca-e63d0e3c5856@riddermarkfarm.ca> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <19b82d6e-6b8e-7b49-69ca-e63d0e3c5856@riddermarkfarm.ca> Message-ID: A few experiences as SNOBOL/Icon enthusiast, not expert, ending with limited tie back to Unix: o Introduced to SNOBOL4 in introductory programming languages course summer 1971 U.T. Austin o ca 1976 used SNOBOL4 on VM/370 to build Fortran to PL/I translator "The elapsed time between beginning work on the translator and getting a running PL/I version of APLOMB was approximately two weeks, and this achievement was a great relief to those who anticipated a much, much larger effort." https://technologists.com/sauer/The_Evolution_of_the_Research_Queueing_Package.pdf o ca 1985 (with minimal effort) modified/built Icon to run on PC/IX, began emailing with Ralph Griswold o Discovered IBM colleague Viktors Berstis and his SNOBOL advocacy/expertise (http://berstis.com/ ) o ca 1986 "With help from an ISC colleague, I created a PL.8 to C translator using Icon, that was used to facilitate some of the rewriting. [of the RT/PC VRM]" https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 web: https://technologists.com/sauer/ Facebook/Google/Skype/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtomek at ceti.pl Fri Jul 29 15:07:49 2022 From: rtomek at ceti.pl (Tomasz Rola) Date: Fri, 29 Jul 2022 07:07:49 +0200 Subject: [TUHS] SNOBOL and RATSNO In-Reply-To: <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <1E44D7CE-CC4D-4F86-97CC-208E3972A785@msweng.com> Message-ID: <20220729050748.GB12246@tau1.ceti.pl> On Wed, Jul 27, 2022 at 10:13:04PM -0600, William H. Mitchell wrote: > [...] > Phil Budne: Thanks for your CSNOBOL4 implementation! I’ve used it to show students SNOBOL4 in a comparative languages class at the U of Arizona. (I was thinking your name sounded familiar!) > > > On Jul 27, 2022, at 7:03 PM, Phil Budne wrote: > > > >> Anyway, I have got Phil Budne's implementation > > > > C'est moi! SNOBOL came out of Bell Labs in Holmdel NJ. > > There was a SNOBOL3 implementation in Unix 6th Edition days called "sno". [...] Yes, I have had a look and it seems to be very nicely written project. Oh, and there is plenty of Snobol4 code to look at, too... Thank you. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From cowan at ccil.org Sat Jul 30 00:07:33 2022 From: cowan at ccil.org (John Cowan) Date: Fri, 29 Jul 2022 10:07:33 -0400 Subject: [TUHS] SNOBOL and progeny [Was: Re: Re: Line Numbers Before SysIII nl? BSD num?] In-Reply-To: References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <19b82d6e-6b8e-7b49-69ca-e63d0e3c5856@riddermarkfarm.ca> Message-ID: On Fri, Jul 29, 2022 at 1:02 AM Charles H. Sauer wrote: > A few experiences as SNOBOL/Icon enthusiast, not expert, ending with > limited tie back to Unix: > o Introduced to SNOBOL4 in introductory programming languages course > summer 1971 U.T. Austin > o ca 1976 used SNOBOL4 on VM/370 to build Fortran to PL/I translator "The > elapsed time between beginning work on the translator and getting a running > PL/I version of APLOMB was approximately two weeks, and this achievement > was a great relief to those who anticipated a much, much larger effort." > https://technologists.com/sauer/The_Evolution_of_the_Research_Queueing_Package.pdf > o ca 1985 (with minimal effort) modified/built Icon to run on PC/IX, began > emailing with Ralph Griswold > o Discovered IBM colleague Viktors Berstis and his SNOBOL > advocacy/expertise (http://berstis.com/) > o ca 1986 "With help from an ISC colleague, I created a PL.8 to C > translator using Icon, that was used to facilitate some of the rewriting. > [of the RT/PC VRM]" > https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ > > Let us not forget Icon , Ralph Griswold's own successor to Snobol. Well-structured, portable to Posix and Windows, "Prolog from another point of view" (the Icon implementation is very much like the WAM). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at plonka.us Sat Jul 30 01:37:38 2022 From: dave at plonka.us (Dave Plonka) Date: Fri, 29 Jul 2022 10:37:38 -0500 Subject: [TUHS] SNOBOL and progeny [Was: Re: Re: Line Numbers Before SysIII nl? BSD num?] In-Reply-To: <19b82d6e-6b8e-7b49-69ca-e63d0e3c5856@riddermarkfarm.ca> References: <1oF87S-4zW-00@marmaro.de> <8NgHeeJiYEBE0zhtd9RdKIeYWcAwtxsnAj7YhVIvLpz-yt0__LeFvVzNNGgSNTeDGnVQy-qxkoHWvmRi84ybYyNAiMRDJuVoAaEG96UAu4s=@protonmail.com> <20220724190253.GA23421@tau1.ceti.pl> <20220728003014.GB6195@tau1.ceti.pl> <202207280103.26S13ZL5059300@ultimate.com> <19b82d6e-6b8e-7b49-69ca-e63d0e3c5856@riddermarkfarm.ca> Message-ID: SNOBOL influenced Dick Haight's bs(1) programming language which includes some SNOBOL features, a replacement, written in C, for Ken Thompson's bas(1) BASIC implementation, written in assembly language. bs (programming language) https://en.wikipedia.org/wiki/Bs_(programming_language) BS: a mysterious Unix programming language! https://www.youtube.com/watch?v=ELICIa3L22o Although I know of no applications written in bs(1), it remains to this day in licensed System V Unix variants such as HP-UX and AIX. Peace, Dave On Thu, Jul 28, 2022 at 7:22 PM Stuff Received wrote: > > On 2022-07-27 21:03, Phil Budne wrote: > >> Anyway, I have got Phil Budne's implementation > > C'est moi! SNOBOL came out of Bell Labs in Holmdel NJ. > > There was a SNOBOL3 implementation in Unix 6th Edition days called "sno". > > > > As far as I know Macro SNOBOL4 (that my CSNOBOL4 is a port of) never > > was ported to the PDP-11 (just not enough address space), but there > > was a proposal (at least) for a SNOBOL4 implementation for the '11 > > called ELFBOL. > > > > Macro SPITBOL (a faster implementation of SNOBOL4) was available on > > the Research Unix VAXen (Andrew Koenig did a C-like preprocessor > > called SNOCONE -- SNOBOL with some sugar). > > > > Phil > > I recall seeing ICEBOL card packs at the U. of Toronto Computing Centre > decades ago but I know nothing more. > > N. -- dave at plonka.us http://www.cs.wisc.edu/~plonka/ From gctersteeg at gmail.com Sat Jul 30 14:39:28 2022 From: gctersteeg at gmail.com (Gavin Tersteeg) Date: Fri, 29 Jul 2022 23:39:28 -0500 Subject: [TUHS] LSX issues and musing In-Reply-To: <9293a145-bdd1-bd79-0977-6f825da56093@osta.com> References: <20220711234729.2E9F418C096@mercury.lcs.mit.edu> <9293a145-bdd1-bd79-0977-6f825da56093@osta.com> Message-ID: Thank you for the documents. The information there about continuous files and the background process will be extremely helpful if I ever try to make those work in the future. Right now I have "mount" and "umount" successfully implemented (I think). This leaves me with about 1.9kb of space left in the kernel for additional drivers, which I am pretty happy with. I also implemented /etc/rc support in the LSX init program so I didn't have to manually mount everything each reboot. Unfortunately, my good luck ends here. In my attempt to create a single RK05 disk with all of the system and userspace source, I noticed that the LSX "mkfs" was hardcoded to create filesystems with 6 blocks of inodes. This maxed the number of files on a disk to 96, but even with the maximum circumvented LSX would only tolerate a maximum of 101 files. A fresh filesystem that was mkfs'd on stock V6 can be mounted on LSX, but any attempt to create files on it will fail. Interestingly enough, existing large V6 RK05 images can be mounted, read from, and written to. The only limitations on these pre existing images is that if enough files are deleted, the system will randomly crash. Obviously something is seriously wrong, but I can't seem to find out what it is. I do not have any of the special LSX filesystem options enabled on the kernel or mkfs. The good news is that the fork issue seems to be tied to hitting the backspace key. If backspace is hit during any line input, the next program that tries to use fork will fail. I haven't really looked into why as I am trying to figure out this mkfs stuff first. On Wed, Jul 27, 2022 at 11:25 AM Heinz Lycklama wrote: > Gavin, looks like you have figured most things out about LSX > and Mini-Unix (both of which I am the other of while at BTL). > There are some similarities between the two but LSX is more > complex because it supports some real-time features and > contiguous files. I was able to compile the operating system > source code for both running on themselves while at BTL. > > I'm not familiar with all of the work done by others since then, > but there is some original documentation for each of the > systems still available. LSX is documented in the BSTJ, and > there is a memo on MIni-UNIX online here: > 1. http://www.tavi.co.uk/unixhistory/mini-unix/Mini-UNIX_Memo.txt > [Explains mods made to programs. Much of this applies to LSX] > 2. https://www.tuhs.org/cgi-bin/utree.pl?file=Mini-Unix/usr/doc/new/ > 3. https://gunkies.org/wiki/MINI-UNIX > You can also find my original memo on Mini-UNIX [titled > TM-77-1352-1_The_MINI-UNIX_19770103.pdf] in this > online directory of my Technical Memos. > 4. > https://tuhs.pdp-11.org.ru/Documentation/TechReports/Heinz_Tech_Memos/ > The files in #4 also used to be online in https://tuhs.org/ > but I can't seem to find them at this time. > > Hope this is all helpful to you. > > Heinz > > On 7/27/2022 1:02 AM, Gavin Tersteeg wrote: > > Well, it has been almost 2 weeks since my last post on this thread. Since > there is so little information about LSX online, I might as well post all > that I have done / noticed. > > First things first, the kernel building issue was as simple as I was > expecting. All of the build scripts are meant for an external V6 system, > and do not work on LSX itself. I forgot that the LSX linker defaults to > 040000 instead of 0 which obviously broke my kernel. Setting the "-a" flag > on the linker and fixing config stuff in param.h, header.s, and mch.s was > all that was needed to make it work. > > Next up was converting the userspace from 16K to 20K. I tried to use an > external compiler as little as possible and was mostly successful doing so. > "ed.c" needed to be broken up into 2 different files, but everything else > worked. The only thing that needed to be cross compiled was the C compiler > itself. As it turns out, the stock C compiler that LSX comes with does not > have enough "OSSIZ" in order to build the 2nd pass of the compiler. > Interestingly enough, compiling it with the full space only makes the 2nd > pass go up to 23K-ish size. It just barely fits in the userspace, but it > does work. I don't know why the original creators of the root image didn't > start with this. > > Speaking of the C compiler, mounting the "cc.dsk" file from the archives > on LSX is a bad idea. Unlike every other image, it is formatted for 500 > blocks instead of 400. Trying to write to this filesystem will cause the > swap space to get overwritten, which is generally not a good thing. > > After the kernel and userspace were working, I went ahead and started > making modifications to the kernel. The first goal involved re-adding the > RAW tty mode. Turns out, this was super simple and only took like 10 > minutes of copying "if" statements. After that, my custom V6 screen editor > compiled and worked flawlessly. > > Finally, tonight I was able to get a RK05 driver to work alongside the > default RX01 driver. This one was a little bit more of a challenge, as all > of the block device switch code has been ripped out of LSX. Device drivers > also work slightly differently, as some driver support functions are > removed and "buf.h" is set up to only use 8-bit dev IDs. After adding back > a simplified "bdevsw[]", some modifications to "bio.c", and a whole lot of > tinkering I was able to get RK0 auto-mounted on "/mnt". Should make moving > lots of files *much* easier, plus it will facilitate my future plans for > the project. > > I think my next goal is to add back the "mount" and "umount" syscalls. I > got about 2200 bytes free of kernel space, so that should be more than > enough room to add those functions in. After that, i'll just need to write > a RX02 driver and make the jump over to real hardware. Of course, the > mystery swap bug still persists. > > Thanks for reading, > Gavin > > On Fri, Jul 15, 2022 at 3:07 AM Gavin Tersteeg > wrote: > >> Well, I have spent a few more days tentatively messing around with LSX, >> and I have noticed a few things. >> >> First off, the C compiler is not the only program to have occasional >> issues. Sometimes the "mv" command also fails with the >> oh-so-descriptive "?" error. By the looks of it, this error is caused by >> something going wrong with a fork() and subsequent wait() syscall. That >> recurring error in the C compiler is also caused by the 2nd pass of the C >> compiler not being able to find a temporary file created by the 1st pass. >> If the 1st pass was failing to run, then that would explain why the 2nd >> pass isn't able to find that temporary file. This has me guessing that >> there may be something wrong with fork() or exec(). Whenever it is, it >> doesn't dumpster memory or blow up the filesystem. For all I know, it may >> be an emulation issue too, but I have no way of testing it right now. >> >> The current kernel I am building is under 16KB at the moment. My goal is >> to be able to recreate the stock (semi?) functional kernel, and then do >> modifications from there. This goal has not been reached, as this kernel >> simply crashes on startup. It is either a HALT instruction or a stack issue >> depending on if the kernel has been stripped or not. I bet I am building it >> wrong again :/, it doesn't need to be reloc'd after the "ld -X" does it? >> >> Has anyone actually been able to get a system to build with the archived >> LSX disks? I have poured over the config files many times, but I feel like >> I am missing something painfully obvious... >> >> On Mon, Jul 11, 2022 at 6:47 PM Noel Chiappa >> wrote: >> >>> > From: Paul Ruizendaal >>> >>> > Note that LSX only holds one process in core and swaps other >>> processes >>> > (NPROC = 3) out to floppy. It reportedly took several hours for the >>> > Terak to self-compile LSX from source. >>> >>> If one is working in a simulator, and not a real hardware PDP-11, >>> there's a >>> 'trick' one can use to make life a lot easier - for MINI-UNIX, at least; >>> I'll >>> comment on LSX below. >>> >>> As I report in the MINI-UNIX Computer History Wiki article: "MINI-UNIX >>> uses >>> the same file system as V6; this allows MINI-UNIX packs to be 'mounted' >>> on V6 >>> systems (either real, or simulated), which is very convenient for >>> working on >>> them." So just spin up a V6 in the simulator, mount the LSX/MINI-UNIX >>> pack, >>> and away you go. The V6 toolchain can be used to compile/link kernels; to >>> link user commands one will need to import the LSX/MINI-UNIX loader >>> (which, >>> since V6 is source compatible with LSX/MINI-UNIX, is trivial). >>> >>> LSX is potentially more complex, as it supports _two different_ file >>> system >>> formats: the standard V6 one, and a 'contiguous' one which is very >>> similar >>> to the V6 one (rdwri.c has no conditionals on CONTIG; not so alloc.c, >>> though), but is not fully compatible. So non-contiguous LSX file systems >>> can be mounted under V6, but not contiguous ones. >>> >>> Noel >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: