From tuhs at tuhs.org Wed Oct 1 01:22:18 2025 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Tue, 30 Sep 2025 15:22:18 +0000 Subject: [TUHS] Interesting MIT links In-Reply-To: <735ea170-d408-73e5-9307-067e5d4ed53b@bitsavers.org> (Al Kossow via TUHS's message of "Mon, 29 Sep 2025 11:19:59 -0700") References: <7wikh15g5b.fsf@junk.nocrew.org> <735ea170-d408-73e5-9307-067e5d4ed53b@bitsavers.org> Message-ID: <7w7bxg3qz9.fsf@junk.nocrew.org> Al Kossow wrote: > Did all the file recovery documents (like the system names) make it > into what the MIT Archives have, or just the tape images? I didn't seem. Often I had to infer which system a tape came from from its contents. Some tapes have photos of the label. > There are problems with the images as well, like John Bordynuik > inventing his own .tap format with bad blocks handled differently, all > undocumented... I have seen many variants in there, such as little or big endian record size, records padded to 16 bits or not. Some records have frames dropped from the beginning or the end. Also old ITS backup tapes were transferred from low density tapes to a fewer number of high density tapes in the 80s, so sometimes same file appear in multiple savesets on a single tape. From tuhs at tuhs.org Wed Oct 1 01:29:48 2025 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Tue, 30 Sep 2025 15:29:48 +0000 Subject: [TUHS] Interesting MIT links In-Reply-To: (Rich Salz via TUHS's message of "Mon, 29 Sep 2025 11:57:06 -0400") References: Message-ID: <7w34843qmr.fsf@junk.nocrew.org> Rich Salz wrote: > There *must* be Unix stuff in the MIT collection. One unusual thing I found was a copy of Harris HCX/UX. It's their Unix port for the "Tahoe" architecture; you know as in 4.3BSD-Tahoe. I don't know what to do about this. From tuhs at tuhs.org Wed Oct 1 08:55:14 2025 From: tuhs at tuhs.org (jslee via TUHS) Date: Wed, 01 Oct 2025 08:55:14 +1000 Subject: [TUHS] Interesting MIT links In-Reply-To: <7w34843qmr.fsf@junk.nocrew.org> References: <7w34843qmr.fsf@junk.nocrew.org> Message-ID: <5a5b2deb-bf64-4695-bd55-f7cc88ebf17b@app.fastmail.com> Hi, On Wed, 1 Oct 2025, at 01:29, Lars Brinkhoff via TUHS wrote: > Rich Salz wrote: >> There *must* be Unix stuff in the MIT collection. > > One unusual thing I found was a copy of Harris HCX/UX. I had never heard of the Harris before today. I’d heard of BSD Tahoe (I think Rich Stevens may have mentioned it in one of his books? Or maybe I just saw it in a family tree…) but not the machine Anyway mainly posting as after some googling I found this blogue poste: https://virtuallyfun.com/2017/02/24/the-harris-hcx-9-aka-tahoe-platform/ One commenter mentions that Dayton University also had one of these machines. John From tuhs at tuhs.org Fri Oct 3 11:33:25 2025 From: tuhs at tuhs.org (christopher fujino via TUHS) Date: Thu, 2 Oct 2025 18:33:25 -0700 Subject: [TUHS] The origins of portability in C Message-ID: I have often read things like, "`int`s in C are of unfixed size so that Unix could be ported." So I was surprised to read in Dennis Ritchie's "The Development of the C Language" that: PL/I, the implementation language of Multics, was not much to our > tastes, but we were also using other languages, including BCPL, and we > regretted losing the > advantages of writing programs in a language above the level of assembler, > such as ease of writ- > ing and clarity of understanding. At the time we did not put much weight > on portability; interest > in this arose later. > Brian Kernighan quotes Steve Johnson in "Unix: A History and a Memoir": There was another pressure to make Unix portable. A number of DEC's > competitors were beginning to grumble that regulated AT&T had too cozy a > relationship with DEC. We pointed out that there were no other machines > like the PDP-11 on the market, but this argument was getting weaker. > Dennis hooked me into the portability effort with one sentence: 'I think > that it would be easier to move Unix to another piece of hardware than to > rewrite an application to run under a different operating system.' I was > all in from that point on. A few questions: 1. Was Johnson's Portable C Compiler developed explicitly to port Unix, or was it already around? 2. And if it was already around, what was the initial motivation for creating a portable C compiler? 3. Am I right to assume that prior to the Portable C Compiler, C's primitives were thought of as PDP-11 specific? Thanks! Chris From tuhs at tuhs.org Fri Oct 3 11:52:00 2025 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Fri, 3 Oct 2025 11:52:00 +1000 Subject: [TUHS] The origins of portability in C In-Reply-To: References: Message-ID: It was done for the port to the Interdata. To answer question 3, I often heard (and early on, believed) that things like *p++ were invented for the addressing modes on the PDP-11, but was told by Ken and Dennis that they were not original. -rob On Fri, Oct 3, 2025 at 11:34 AM christopher fujino via TUHS wrote: > I have often read things like, "`int`s in C are of unfixed size so that > Unix could be ported." So I was surprised to read in Dennis Ritchie's "The > Development of the C Language" that: > > PL/I, the implementation language of Multics, was not much to our > > tastes, but we were also using other languages, including BCPL, and we > > regretted losing the > > advantages of writing programs in a language above the level of > assembler, > > such as ease of writ- > > ing and clarity of understanding. At the time we did not put much weight > > on portability; interest > > in this arose later. > > > > Brian Kernighan quotes Steve Johnson in "Unix: A History and a Memoir": > > There was another pressure to make Unix portable. A number of DEC's > > competitors were beginning to grumble that regulated AT&T had too cozy a > > relationship with DEC. We pointed out that there were no other machines > > like the PDP-11 on the market, but this argument was getting weaker. > > Dennis hooked me into the portability effort with one sentence: 'I think > > that it would be easier to move Unix to another piece of hardware than to > > rewrite an application to run under a different operating system.' I was > > all in from that point on. > > > A few questions: > > 1. Was Johnson's Portable C Compiler developed explicitly to port Unix, or > was it already around? > 2. And if it was already around, what was the initial motivation for > creating a portable C compiler? > 3. Am I right to assume that prior to the Portable C Compiler, C's > primitives were thought of as PDP-11 specific? > > Thanks! > > Chris > From tuhs at tuhs.org Fri Oct 3 13:02:47 2025 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Fri, 3 Oct 2025 13:02:47 +1000 (EST) Subject: [TUHS] The origins of portability in C In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025, Rob Pike via TUHS wrote: > It was done for the port to the Interdata. To answer question 3, I often > heard (and early on, believed) that things like *p++ were invented for > the addressing modes on the PDP-11, but was told by Ken and Dennis that > they were not original. I believe the same thing was said about the SOB instruction too. -- Dave From tuhs at tuhs.org Fri Oct 3 14:30:53 2025 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Thu, 2 Oct 2025 21:30:53 -0700 Subject: [TUHS] The origins of portability in C In-Reply-To: References: Message-ID: if an instruction named SOB had not existed, it would have been necessary to create one. On Thu, Oct 2, 2025 at 8:14 PM Dave Horsfall via TUHS wrote: > On Fri, 3 Oct 2025, Rob Pike via TUHS wrote: > > > It was done for the port to the Interdata. To answer question 3, I often > > heard (and early on, believed) that things like *p++ were invented for > > the addressing modes on the PDP-11, but was told by Ken and Dennis that > > they were not original. > > I believe the same thing was said about the SOB instruction too. > > -- Dave > From tuhs at tuhs.org Sat Oct 4 00:12:01 2025 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Fri, 3 Oct 2025 10:12:01 -0400 Subject: [TUHS] The origins of portability in C External Inbox Forums Message-ID: Portability of Fortran code was a major theme at Bell Labs. Phyllis Fox oversaw the creation of the Port library of numerical software, which became publicly available upon the advent of the internet. Before the Port library, Stan Brown, Barbara Rider, and Andy Hall had been central to an ambitious portability effort for Altran, a symbolic-algebra language. They identified Pfort, a subset of Fortran that was portable except for issues of data representation. In particular, Altran implemented multiple-precision integers. A verifier to assure that Fortran code complied with Pfort was written in Pfort. The M6 macroprocessor, also written in Pfort, was created to deal with adjusting Fortran code that depended on word size or character code. The Altran compiler itself was written in Pfort tailored by a set of M6 definitions for each machine architecture. Of course making C portable was a bigger deal than doing it for Altran. C had to compile to different instruction sets, while Altran always compiled to Pfort. But the Altran portability effort certainly fed into the C project, particularly via Steve Johnson, who worked on both. One notable congruence is their use of macro preprocessors. Doug From tuhs at tuhs.org Sun Oct 5 06:38:00 2025 From: tuhs at tuhs.org (David Barto via TUHS) Date: Sat, 4 Oct 2025 13:38:00 -0700 Subject: [TUHS] inode - does it have a meaning? Message-ID: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> In a blog post today I read: In most modern file systems, those data structures are known as inodes, and their numbers are inode numbers, sometimes shortened to inodes. The term is thought to be a contraction of index node, which certainly makes sense, but is lost in the mists of time. This was written by a fellow who is reasonably smart and knows his way around things MacOS, though not things UNIX. So before I go and tell him that inode really does mean ‘index node’, I’m checking here to clear the “mists of time.” I’ve always understood it to be a shortening of ‘index node’. Wikipedia (https://en.wikipedia.org/wiki/Inode) says There has been uncertainty on the Linux kernel mailing list about the reason for the "i" in "inode". In 2002, the question was brought to Unix pioneer Dennis Ritchie, who replied:[4] In truth, I don't know either. It was just a term that we started to use. "Index" is my best guess, because of the slightly unusual file system structure that stored the access information of files as a flat array on the disk, with all the hierarchical directory information living aside from this. Thus the i-number is an index in this array, the i-node is the selected element of the array. (The "i-" notation was used in the 1st edition manual; its hyphen was gradually dropped.) Further the Wikipedia article states that Bach says that the word ‘inode’ is a contraction of the term index node. So is there a ‘definitive’ answer for this, or is it really lost in the mists of time? David Men always learn from their mistakes how to make new ones. A.J.P. Taylor David Barto barto at kdbarto.org From tuhs at tuhs.org Sun Oct 5 07:15:28 2025 From: tuhs at tuhs.org (Jim Mellander via TUHS) Date: Sat, 4 Oct 2025 14:15:28 -0700 Subject: [TUHS] PDP-11/70 in Cory Hall, Berkeley '74 or 75 Message-ID: Hi all: I had the occasion to use the PDP-11/70 on the ground floor of Cory Hall. I was not a student, but was in the Navy stationed at Treasure Island, but groked Unix & visited there on my time off to tinker, among other things. I always have wondered who were the long hairs who were working inside the glass partition on the system. Also, I played with a PDP-11/45 in Evans Hall. I'm interested in any information anyone has about those times and places. Thanks in advance, Jim Mellander From tuhs at tuhs.org Sun Oct 5 07:57:15 2025 From: tuhs at tuhs.org (steve jenkin via TUHS) Date: Sun, 5 Oct 2025 08:57:15 +1100 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: <0BD89802-685A-4416-9527-5CF39F0274B6@canb.auug.org.au> In 1989, Ken was interviewed by Mike Mahoney of Princeton, as part of the “Unix Oral History Project”. It seems ‘inode’ was being used from 1969 when Ken & Dennis were doing design, with Rudd Canaday in his office. ====================== Princeton have removed the original site. Copes can be found at: An edited summary by Mahoney: ====================== Ken’s Interview of "9-6-89" Thompson: Yeah. I was doing it on the 635 at the time. Yeah . I got these exponential curves where before it would get into trouble it would go way out and get lots and lots of simultaneous accesses going… I was playing with a disk sorting algorithms and caching algorithms at the time. All of those actually went into UNIX. Um. MSM: This would be the research aspect of the work? Thompson: Yeah. Then in the actual design. At that point, it just went to… There was a model of a user and a model of this, and they generated activities, and the activity went into the disks that were sorted and things like that. Um, um. It was never down to a design to the point of where you put the addresses, how you expand files and things like that. It was never down to that level. It was always at some higher level. I think it was just like one or two meetings, Dennis and Canaday and myself. Was just discussing these ideas of the general nature of keeping the files out of each other's hair and the nitty-gritty of expanding. Of the real implementation, where you put the block addresses, where you put this and this. I remember, um, we did it in Canaday's office. At the end of this discussion Canaday picked up the phone, and there was a new service in Bell Laboratories, dictation, where you call up essentially a tape recorder and you give notes, and then the next morning notes are typed and sent to you. The next day, these notes came back and the acronyms were butchered, like "inode" was "eyen" (Laughing). ====================== > On 5 Oct 2025, at 07:38, David Barto via TUHS wrote: > > In a blog post today I read: > > In most modern file systems, those data structures are > known as inodes, and their numbers are inode numbers, > sometimes shortened to inodes. The term is thought > to be a contraction of index node, which certainly > makes sense, but is lost in the mists of time. > > This was written by a fellow who is reasonably smart and knows > his way around things MacOS, though not things UNIX. So before > I go and tell him that inode really does mean ‘index node’, I’m > checking here to clear the “mists of time.” > > I’ve always understood it to be a shortening of ‘index node’. > > Wikipedia (https://en.wikipedia.org/wiki/Inode) says > > There has been uncertainty on the Linux kernel mailing list > about the reason for the "i" in "inode". In 2002, the question > was brought to Unix pioneer Dennis Ritchie, who replied:[4] > > In truth, I don't know either. It was just a term that we > started to use. "Index" is my best guess, because of the > slightly unusual file system structure that stored the > access information of files as a flat array on the disk, > with all the hierarchical directory information living > aside from this. Thus the i-number is an index in this array, > the i-node is the selected element of the array. > (The "i-" notation was used in the 1st edition manual; > its hyphen was gradually dropped.) > > Further the Wikipedia article states that Bach says that the word ‘inode’ > is a contraction of the term index node. > > So is there a ‘definitive’ answer for this, or is it really lost in > the mists of time? > > David > > Men always learn from their mistakes how to make new ones. > A.J.P. Taylor > > David Barto > barto at kdbarto.org > > > -- 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 tuhs at tuhs.org Sun Oct 5 08:54:30 2025 From: tuhs at tuhs.org (Steffen Nurpmeso via TUHS) Date: Sun, 05 Oct 2025 00:54:30 +0200 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: <20251004225430.mp_rFBJr@steffen%sdaoden.eu> David Barto via TUHS wrote in <143E170E-F64F-4AEE-83B1-BAB134267099 at kdbarto.org>: |In a blog post today I read: | | In most modern file systems, those data structures are | known as inodes, and their numbers are inode numbers, | sometimes shortened to inodes. The term is thought | to be a contraction of index node, which certainly | makes sense, but is lost in the mists of time. | |This was written by a fellow who is reasonably smart and knows |his way around things MacOS, though not things UNIX. So before |I go and tell him that inode really does mean ‘index node’, I’m |checking here to clear the “mists of time.” | |I’ve always understood it to be a shortening of ‘index node’. | |Wikipedia (https://en.wikipedia.org/wiki/Inode) says | | There has been uncertainty on the Linux kernel mailing list | about the reason for the "i" in "inode". In 2002, the question | was brought to Unix pioneer Dennis Ritchie, who replied:[4] | | In truth, I don't know either. It was just a term that we | started to use. "Index" is my best guess, because of the | slightly unusual file system structure that stored the | access information of files as a flat array on the disk, | with all the hierarchical directory information living | aside from this. Thus the i-number is an index in this array, | the i-node is the selected element of the array. | (The "i-" notation was used in the 1st edition manual; | its hyphen was gradually dropped.) | |Further the Wikipedia article states that Bach says that the word ‘inode’ |is a contraction of the term index node. | |So is there a ‘definitive’ answer for this, or is it really lost in |the mists of time? Sure is to me only that in 4.2BSD the "A Fast File System for UNIX" paper (share/doc/smm/05.fastfs/) talks +Every file has a descriptor associated with it called an +.I "inode". +The inode contains information describing ownership of the file, +time stamps marking last modification and access times for the file, +and an array of indices that point to the data blocks for the file. +For the purposes of this section, we assume that the first 8 blocks +of the file are directly referenced by values stored +in the inode structure itself*. Node with array of indices. Isn't this an influential paper? Not mentioned in Wikipedia. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Sun Oct 5 09:04:47 2025 From: tuhs at tuhs.org (Jon Forrest via TUHS) Date: Sat, 4 Oct 2025 16:04:47 -0700 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: On 10/4/25 1:38 PM, David Barto via TUHS wrote: > In a blog post today I read: > > In most modern file systems, those data structures are > known as inodes, and their numbers are inode numbers, > sometimes shortened to inodes. The term is thought > to be a contraction of index node, which certainly > makes sense, but is lost in the mists of time. The "provably secure" version of Unix, called KSOS, used "jnodes" instead of "inodes". I think this was because the main architect of KSOS was Jay McCauley, and he named them after himself. Jon From tuhs at tuhs.org Sun Oct 5 09:16:32 2025 From: tuhs at tuhs.org (Noel Chiappa via TUHS) Date: Sat, 4 Oct 2025 19:16:32 -0400 (EDT) Subject: [TUHS] inode - does it have a meaning? Message-ID: <20251004231632.77B4418C077@mercury.lcs.mit.edu> > From: Steffen Nurpmeso > Isn't this an influential paper. Written well over a decade after initial UNIX. The chances that anyone there knew anything about very early UNIX (especially as old documents had not yet started to show up on the early Internet, back then) are zero. Noel From tuhs at tuhs.org Sun Oct 5 09:24:01 2025 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Sat, 4 Oct 2025 17:24:01 -0600 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <20251004231632.77B4418C077@mercury.lcs.mit.edu> References: <20251004231632.77B4418C077@mercury.lcs.mit.edu> Message-ID: On Sat, Oct 4, 2025 at 5:16 PM Noel Chiappa via TUHS wrote: > > From: Steffen Nurpmeso > > > Isn't this an influential paper. > > Written well over a decade after initial UNIX. The chances that anyone > there > knew anything about very early UNIX (especially as old documents had not > yet > started to show up on the early Internet, back then) are zero. > Yet they could have had it from oral history, given Ken's 1975 sabbatical to Berkeley, no? And the paper pre-dates his later recollections, and surely he reviewed it and would have raised an objection if he knew it was wrong. Kirk McKusick, the author, is on this list, I think. Though, I will grant it's not primary evidence. Warner From tuhs at tuhs.org Sun Oct 5 14:57:03 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 5 Oct 2025 14:57:03 +1000 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: On Sat, Oct 04, 2025 at 01:38:00PM -0700, David Barto via TUHS wrote: > In a blog post today I read: > > In most modern file systems, those data structures are > known as inodes, and their numbers are inode numbers, > sometimes shortened to inodes. The term is thought > to be a contraction of index node, which certainly > makes sense, but is lost in the mists of time. This is in the 197 CACM paper: A directory entry contains only a name for the associated file and a pointer to the file itself. This pointer is an integer called the i-number (for index number) of the file. When the file is accessed, its i-number is used as an index into a system table (the i-list) stored in a known part of the device on which the directory resides. The entry thereby found (the file’s i-node) contains the description of the file ... But an earlier version of the paper has this: A directory entry contains only a name for the associated file and a pointer to the file itself. This pointer is an integer called the i-number (for identification number) of the file. See https://github.com/DoctorWkt/unix_timesharing_paper/blob/master/filesystem.md So you could argue that, at the time of this draft, the wording implies "identification node" for i-node. Cheers, Warren From tuhs at tuhs.org Mon Oct 6 07:45:12 2025 From: tuhs at tuhs.org (Eric Allman via TUHS) Date: Sun, 5 Oct 2025 14:45:12 -0700 Subject: [TUHS] PDP-11/70 in Cory Hall, Berkeley '74 or 75 In-Reply-To: References: Message-ID: <2b5e581d-24cc-42fa-bac2-8618e1f753aa@eric.allman.name> On 10/4/25 14:15, Jim Mellander via TUHS wrote: > Hi all: > > I had the occasion to use the PDP-11/70 on the ground floor of Cory Hall. I > was not a student, but was in the Navy stationed at Treasure Island, but > groked Unix & visited there on my time off to tinker, among other things. I believe that would have been the instructional PDP-11/70. There was also an 11/45 that was, to the best of my knowledge, shared by CS, Math, and Statistics. Math and Stat wanted to run the vendor OS but CS wanted to run UNIX, so ⅓ of the time it ran UNIX and 2/3 of the time it ran something else, maybe RSTS. I worked on the INGRES project, which eventually got their own PDP-11/70, which was on the 4th floor of Cory. There were a few guest accounts, but it wasn't an instructional machine other than for the graduate DBMS class. My recollection is that Berkeley was running 5th Edition when I got my first account, but that didn't last long. I was mostly insulated from the transition to 6th Edition, but I remember that it required a lot of changes in INGRES due to changes in both the libraries and the C language itself. I was not insulated from the transition to 7th Edition, which was a lot of work but easier to work with. There were other transitions when the VAXen started to appear, but those were later. > I always have wondered who were the long hairs who were working inside the > glass partition on the system. These were probably the usual suspects: Bill Joy and Chuck Haley (certainly), Bob Fabry (who convinced the department to run UNIX in the first place), Ken Thompson (when he was on sabbatical while at Berkeley), Jeff Shriebman, and many others that I'm forgetting at the moment. There were also a lot of other folks who weren't doing a lot of kernel work like Ken Arnold, Kirk McKusick (who shared an office with Bill), Tom Ferrin (UCSF, but spent time in Berkeley working with other UNIX folks), Eric Schmidt, Kurt Shoens, etc. For the most part they were not working inside the glass box. Bonus recollection: Ken Thompson gave a free evening class that was a walk-through of the v6 kernel. I think about a dozen people showed up. The Computer History Museum in Mountain View has an audio recording of the talk and an annotated listing with my personal notes. Yes, I held on to that listing for almost 50 years. > > Also, I played with a PDP-11/45 in Evans Hall. > > I'm interested in any information anyone has about those times and places. You might also want to check out videos of Kirk McKusick's talks on the history of UNIX at Berkeley. A search for "Kirk McKusick Berkeley UNIX history" should do the trick, or check out his Youtube channel at https://www.youtube.com/@marshallkirkmckusick1756. > > Thanks in advance, > > Jim Mellander eric From tuhs at tuhs.org Mon Oct 6 09:55:35 2025 From: tuhs at tuhs.org (Marc Donner via TUHS) Date: Sun, 5 Oct 2025 19:55:35 -0400 Subject: [TUHS] inode - does it have a meaning? In-Reply-To: References: <143E170E-F64F-4AEE-83B1-BAB134267099@kdbarto.org> Message-ID: Pedant alert: inode - does it have an etymology. We know what it *MEANS* ... that's in some man page.\ ===== mindthegapdialogs.com north-fork.info On Sun, Oct 5, 2025 at 1:04 AM Warren Toomey via TUHS wrote: > On Sat, Oct 04, 2025 at 01:38:00PM -0700, David Barto via TUHS wrote: > > In a blog post today I read: > > > > In most modern file systems, those data structures are > > known as inodes, and their numbers are inode numbers, > > sometimes shortened to inodes. The term is thought > > to be a contraction of index node, which certainly > > makes sense, but is lost in the mists of time. > > This is in the 197 CACM paper: > > A directory entry contains only a name for the associated file and > a pointer to the file itself. This pointer is an integer called the > i-number (for index number) of the file. When the file is accessed, its > i-number is used as an index into a system table (the i-list) stored in > a known part of the device on which the directory resides. The entry > thereby found (the file’s i-node) contains the description of the file > ... > > But an earlier version of the paper has this: > > A directory entry contains only a name for the associated file and > a pointer to the file itself. This pointer is an integer called the > i-number (for identification number) of the file. > > See > https://github.com/DoctorWkt/unix_timesharing_paper/blob/master/filesystem.md > > So you could argue that, at the time of this draft, the wording implies > "identification node" for i-node. > > Cheers, Warren > From tuhs at tuhs.org Mon Oct 6 10:21:49 2025 From: tuhs at tuhs.org (Jim Mellander via TUHS) Date: Sun, 5 Oct 2025 17:21:49 -0700 Subject: [TUHS] PDP-11/70 in Cory Hall, Berkeley '74 or 75 In-Reply-To: <2b5e581d-24cc-42fa-bac2-8618e1f753aa@eric.allman.name> References: <2b5e581d-24cc-42fa-bac2-8618e1f753aa@eric.allman.name> Message-ID: Thanks! A little more of my experiences with Unix in those days: I was 18 and too clever for my own good. Not being a student, I managed to "get" a student's account by looking over their shoulder surreptitiously. I then wrote a trivial C program to mimic the login prompt and harvested a few other accounts. I created a hidden dot directory for my experiments, which mainly consisted of writing chess and checker programs for my own amusement. I devoured the thick white Unix manual of the day, and, I hesitate to admit, wrote a trivial shell fork bomb which just spawned additional copies of itself in the background. I remember firing it up on an ASR-33, and it printed out the PIDs slower and slower until the system froze. I tore off the printout and left. The next time I showed up, the aforementioned long-hairs approached me, and told me that they knew what I had done. In contrast to what would happen today, they told me that they would give me a guest account for my enjoyment if I promised to stay in my lane. I took their words to heart and continued tinkering with my programs for the rest of my time stationed in the Bay Area. I also got an account somehow on the CDC-6400 in the basement of Evans Hall, and ran a few interesting batch-mode programs from punch cards. I often wondered who those guys were, since their kindness actually pointed me on the straight and narrow. Probably my fork bomb caused them to re-engineer the process table, so that could be my minor contribution to Unix. My career ended up in cybersecurity, of course (it takes a thief...) at LBL right up the hill from the Berkeley campus, so it all worked out OK. As an aside to the discussion about 'true', it seems reasonable that in the usual case ("while true"), the shell version wouldn't be significantly, if any, slower than a separate binary, since the shared libraries would already be in core. On my apple silicon mac 'true' is a 84128 byte dual architecture binary..... Thanks to all the Unix pioneers! Jim Mellander On Sun, Oct 5, 2025 at 2:45 PM Eric Allman wrote: > > On 10/4/25 14:15, Jim Mellander via TUHS wrote: > > Hi all: > > > > I had the occasion to use the PDP-11/70 on the ground floor of Cory > Hall. I > > was not a student, but was in the Navy stationed at Treasure Island, but > > groked Unix & visited there on my time off to tinker, among other things. > > I believe that would have been the instructional PDP-11/70. There was > also an 11/45 that was, to the best of my knowledge, shared by CS, Math, > and Statistics. Math and Stat wanted to run the vendor OS but CS wanted > to run UNIX, so ⅓ of the time it ran UNIX and 2/3 of the time it ran > something else, maybe RSTS. > > I worked on the INGRES project, which eventually got their own > PDP-11/70, which was on the 4th floor of Cory. There were a few guest > accounts, but it wasn't an instructional machine other than for the > graduate DBMS class. > > My recollection is that Berkeley was running 5th Edition when I got my > first account, but that didn't last long. I was mostly insulated from > the transition to 6th Edition, but I remember that it required a lot of > changes in INGRES due to changes in both the libraries and the C > language itself. I was not insulated from the transition to 7th Edition, > which was a lot of work but easier to work with. > > There were other transitions when the VAXen started to appear, but those > were later. > > > I always have wondered who were the long hairs who were working inside > the > > glass partition on the system. > > These were probably the usual suspects: Bill Joy and Chuck Haley > (certainly), Bob Fabry (who convinced the department to run UNIX in the > first place), Ken Thompson (when he was on sabbatical while at > Berkeley), Jeff Shriebman, and many others that I'm forgetting at the > moment. There were also a lot of other folks who weren't doing a lot of > kernel work like Ken Arnold, Kirk McKusick (who shared an office with > Bill), Tom Ferrin (UCSF, but spent time in Berkeley working with other > UNIX folks), Eric Schmidt, Kurt Shoens, etc. For the most part they were > not working inside the glass box. > > Bonus recollection: Ken Thompson gave a free evening class that was a > walk-through of the v6 kernel. I think about a dozen people showed up. > The Computer History Museum in Mountain View has an audio recording of > the talk and an annotated listing with my personal notes. Yes, I held on > to that listing for almost 50 years. > > > > > Also, I played with a PDP-11/45 in Evans Hall. > > > > I'm interested in any information anyone has about those times and > places. > > You might also want to check out videos of Kirk McKusick's talks on the > history of UNIX at Berkeley. A search for "Kirk McKusick Berkeley UNIX > history" should do the trick, or check out his Youtube channel at > https://www.youtube.com/@marshallkirkmckusick1756. > > > > > Thanks in advance, > > > > Jim Mellander > > eric > > From tuhs at tuhs.org Mon Oct 6 14:04:06 2025 From: tuhs at tuhs.org (Thalia Archibald via TUHS) Date: Mon, 06 Oct 2025 04:04:06 +0000 Subject: [TUHS] Unix gre, forgotten successor to grep (was: forth on early unix) In-Reply-To: References: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> Message-ID: <70D71E86-7484-4BB6-AF0C-2FFC1FC9B710@archibald.dev> Ken, Your email reminds me of a comment you made in a 1989 interview with Mike Mahoney, that suggests something earlier than QED: > I did a lot of compiling. Even in college and out of college I did a lot of > on-the-fly compilers. Ah. ah. I wrote a GREP-like program. It would... You > type in …, you’d say what you wanted it to look for, and a sed-like thing > also. That you’d say, I want to do a substitute of A for B or some block of > text. What it would do is compile a program that would look for A and > substitute in B and then run the compiled program so that one level removed > from it do I direct my (unclear) and the early languages, the regular > expression searching stuff in ED and its predecessors on CTSS and those things > were in fact compilers for searches. They in fact compiled regular... https://www.tuhs.org/Archive/Documentation/OralHistory/transcripts/thompson.htm By anyone's history of regular expressions, your matcher in QED was the first software implementation of regular expressions. Was this grep-like program you wrote in college something earlier than that? Could you share more about it? Do you somehow still have the source for these? I'd love to study it. Thalia On Sep 23, 2025, at 11:40, Ken Thompson wrote: > i think the plan9 grep is the fastest. > it is grep, egrep, fgrep also. > i think it is faster than boyer-moore. > the whole program is a jit dfa > > read block > for c in block > { > s=s.state[c] > if s == nil do something occasionally > } > > it is a very few cycles per byte. all of the > time is reading a block. i cant imagine b/m > could be faster. the best b/m could do is > calculate the skip and then jump over > bytes that you have already read. > > > russ cox used it to do the (now defunct) code > search in google. From tuhs at tuhs.org Tue Oct 7 03:42:00 2025 From: tuhs at tuhs.org (David Barto via TUHS) Date: Mon, 6 Oct 2025 10:42:00 -0700 Subject: [TUHS] PDP-11/70 in Cory Hall, Berkeley '74 or 75 / fork bomb In-Reply-To: References: <2b5e581d-24cc-42fa-bac2-8618e1f753aa@eric.allman.name> Message-ID: > On Oct 5, 2025, at 5:21 PM, Jim Mellander via TUHS wrote: > > I devoured the thick white Unix manual of the day, and, I hesitate to > admit, wrote a trivial shell fork bomb which just spawned additional copies > of itself in the background. I remember firing it up on an ASR-33, and it > printed out the PIDs slower and slower until the system froze. I tore off > the printout and left. > Back in the late 70’s (78-79) I wrote a shell script to process some files I had on sdcsvax. Shell functions where new and by mistake I used the script name as a function name. I ran my test and it did what I expected, so I logged out. Little did I know at the time that the script had forked itself and was now on a runaway path to take the machine down. Next time I logged in I had receive a message from Brian Kantor (the sdcsvax admin at the time) with a listing of processes running on the machine and the admonition: Don’t do this again. A humbling experience. David The two most common elements in the universe are Hydrogen and Stupidity - Harlan Ellison David Barto barto at kdbarto.org From tuhs at tuhs.org Tue Oct 7 07:23:19 2025 From: tuhs at tuhs.org (Adam Thornton via TUHS) Date: Mon, 6 Oct 2025 14:23:19 -0700 Subject: [TUHS] Unix gre, forgotten successor to grep (was: forth on early unix) In-Reply-To: <70D71E86-7484-4BB6-AF0C-2FFC1FC9B710@archibald.dev> References: <96A17F58-C1D8-4CA6-BF2F-EABDE17DF02C@archibald.dev> <70D71E86-7484-4BB6-AF0C-2FFC1FC9B710@archibald.dev> Message-ID: I'll raise a glass to Professor Mahoney's memory when I get off work. He was my thesis advisor (I never finished the Ph.D.) and it's always nice to see him cited and realize that there are still people who value his work. Adam On Sun, Oct 5, 2025 at 9:14 PM Thalia Archibald via TUHS wrote: > Ken, > > Your email reminds me of a comment you made in a 1989 interview with Mike > Mahoney, that suggests something earlier than QED: > >