From tuhs at tuhs.org Wed Jan 1 02:37:22 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 31 Dec 2024 11:37:22 -0500 Subject: [TUHS] "Webster's Second on the Head of a Pin"? In-Reply-To: References: Message-ID: On 12/29/24 8:44 AM, Douglas McIlroy wrote: > I can supply a copy if no one else has beaten me to it. > > Ron Hardin subsequently pushed the limit even further. Unfortunately, > I do not have a record of that work. Along these same lines, does anyone on the list have a copy of "J. A. Reeds, /bin/sh: The biggest UNIX security Loophole, 11217-840302-04TM, AT&T Bell Laboratories, Murray Hill, NJ (1984)"? Years ago, in another lifetime, I wrote and asked him for a copy, but never got a reply. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Wed Jan 1 07:46:28 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 1 Jan 2025 07:46:28 +1000 Subject: [TUHS] Fwd: dmr DECtape Analysis, part N Message-ID: All, Yufeng Gao has done more amazing work at extracting binaries, source code and text documents from the DECtapes that Dennis Ritchie provided for the Unix Archive: https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ His latest e-mail is below. I've temporarily placed his attachments here: https://minnie.tuhs.org/wktcloud/index.php/s/aWkck2Ljay6c5sB He needs some help with formatting old *roff documents. If someone could offer him help, that would be great. His e-mail address is yufeng.gao AT uq.edu.au Cheers, Warren ----- Forwarded message from Yufeng Gao ----- Date: Tue, 31 Dec 2024 Subject: RE: UNIX DECtapes from dmr Hi Warren, Happy New Year! Here's another update. I found more UNIX bins on another tape ('ken-sky'). They appear to be between V3 and V4. I have attached them as "ken_sky_bins.tar". I have also attached an updated tarball of the V2/V3 bins recovered from the 'e-pi' tape (with a few names corrected), see "identified_v2v3_bins_r2.tar". So far, the rough timeline of UNIX binaries (RTM hereinafter refers to the exact version of the OS described by the preserved manuals) is as follows: Sys: V1 RTM <= unix-study-src < s1/s2 < V2 RTM < V3 RTM < nsys < V4 RTM Bin: V1 RTM < s1/s2 < epi-V2 < epi-V3 < ken-sky-bins < V4 RTM There is a possibility that the V2 bins from the 'e-pi' tape belong to V2 RTM, as they're all PDP-11/20 bins with V2 headers. In contrast, most of the bins from the s1/s2 tapes are V1 bins. Some of them are identical to those from the 's2' tape, and if the timestamps from the 's2' tape can be trusted, they're from May/June 1972. The V3 bins from the 'e-pi' tape are most likely from late 1972 or early 1973, but no later than Feb 1973, as they've been overwritten by files from Feb 1973. This suggests they're from a V3 beta, supported by the fact that some features described in the V3 manual are missing. The files were laid out in perfect alphabetical order on the tape. The bins from the 'ken-sky' tape fall somewhere between V3 RTM and V4 RTM. The directory structure and other elements match the V3 manual, as do the syscalls (e.g., the arguments for kill(2) differ between V3 and V4, and these bins use the V3 arguments). The features, however, are closer to V4. For example, nm(1) had already been rewritten in C and matches the V4 manual's description. The assembler also matches the V4 manual in terms of the number of temp files, and the C compiler refers to the assembler as 'nas.' The assembler is located physically between files starting with "n" and "o," and the files around it follow a weak alphabetical order, so it is logical to assume that it was named "nas". It is a bit difficult to version these binaries, especially without any timestamps. The lines between versions for early UNIX are blurry, and modern software versioning terms like "beta" and "RTM" don't really apply well. If these binaries are to be preserved (which I hope they will be, even though the kernels are long gone), I'd put the V2 bins from 'e-pi' under V2, the V3 bins from 'e-pi' under V3, and the bins from 'ken-sky' under V4 (I'd argue that nsys also falls under V4, as the biggest change between V3 and V4 was the kernel being rewritten in C). There are other overwritten files on the tapes, and I will address them later. There are quite a few patents, papers, and memos in *roff format, but I'm not entirely sure what to do with them. Among those, I have picked out some V4 distribution documents and attached them as a ZIP folder :-). If you know of ways to generate PDFs from these ancient *roff files accurately, please lend a hand - I'm struggling to get accurate results from groff. Sincerely, Yufeng ----- End forwarded message ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: identified_v2v3_bins_r2.tar Type: application/x-tar Size: 267264 bytes Desc: identified_v2v3_bins_r2.tar URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ken_sky_bins.tar Type: application/x-tar Size: 61440 bytes Desc: ken_sky_bins.tar URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: v4_dist_docs.zip Type: application/x-zip-compressed Size: 6959 bytes Desc: v4_dist_docs.zip URL: From tuhs at tuhs.org Wed Jan 1 07:52:13 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 1 Jan 2025 07:52:13 +1000 Subject: [TUHS] Fwd: dmr DECtape Analysis, part N In-Reply-To: References: Message-ID: On Wed, Jan 01, 2025 at 07:46:28AM +1000, Warren Toomey via TUHS wrote: > All, Yufeng Gao has done more amazing work at extracting binaries, > source code and text documents from the DECtapes that Dennis Ritchie > provided for the Unix Archive: The file `setup` in Yufeng's file `v4_dist_docs.zip` has this interesting end: If you would like to share any UNIX compatible software with others, please let us know about it. If you find bugs in the software or the documentation, again let us know. And finally if you need any help that we can provide we'll do all we can. We expect to have a UNIX seminar early in 1974. .pg Good luck. .br Ken Thompson .br Dennis Ritchie .br Bell Telephone Labs .br Murray Hill, NJ 07974 From yuyi15968 at gmail.com Wed Jan 1 10:41:05 2025 From: yuyi15968 at gmail.com (Jackson Helie G) Date: Wed, 1 Jan 2025 08:41:05 +0800 Subject: [TUHS] B programming language interpreter Message-ID: I am currently looking for an interpreter for the B programming language. Can anyone provide one? -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Wed Jan 1 11:37:53 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 31 Dec 2024 19:37:53 -0600 Subject: [TUHS] Fwd: dmr DECtape Analysis, part N In-Reply-To: References: Message-ID: <20250101013753.souswbbrnwbutwbc@illithid> At 2025-01-01T07:46:28+1000, Warren Toomey via TUHS wrote: > All, Yufeng Gao has done more amazing work at extracting binaries, > source code and text documents from the DECtapes that Dennis Ritchie > provided for the Unix Archive: > https://www.tuhs.org/Archive/Applications/Dennis_Tapes/ > > His latest e-mail is below. I've temporarily placed his attachments > here: https://minnie.tuhs.org/wktcloud/index.php/s/aWkck2Ljay6c5sB > > He needs some help with formatting old *roff documents. If someone > could offer him help, that would be great. His e-mail address is > yufeng.gao AT uq.edu.au [...] > There are other overwritten files on the tapes, and I will address > them later. There are quite a few patents, papers, and memos in > *roff format, but I'm not entirely sure what to do with them. Among > those, I have picked out some V4 distribution documents and > attached them as a ZIP folder :-). If you know of ways to generate > PDFs from these ancient *roff files accurately, please lend a hand > - I'm struggling to get accurate results from groff. Hi Yufeng, I maintain groff. How can I be of assistance? Is there an exhibit of a troublesome document you'd like me to inspect? (It's possible given the era that you have some roff(1) documents rather than nroff(1) or troff(1) ones.) Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From douglas.mcilroy at dartmouth.edu Thu Jan 2 01:02:12 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 1 Jan 2025 10:02:12 -0500 Subject: [TUHS] "Webster's Second on the Head of a Pin"? In-Reply-To: References: Message-ID: I have it and will try to scan it in the next few days. Bug me if it doesn't appear. Doug On Tue, Dec 31, 2024 at 11:37 AM Chet Ramey wrote: > > On 12/29/24 8:44 AM, Douglas McIlroy wrote: > > I can supply a copy if no one else has beaten me to it. > > > > Ron Hardin subsequently pushed the limit even further. Unfortunately, > > I do not have a record of that work. > > Along these same lines, does anyone on the list have a copy of > > "J. A. Reeds, /bin/sh: The biggest UNIX security Loophole, > 11217-840302-04TM, AT&T Bell Laboratories, Murray Hill, NJ (1984)"? > > Years ago, in another lifetime, I wrote and asked him for a copy, but > never got a reply. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From rik at rikfarrow.com Thu Jan 2 04:11:13 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Wed, 1 Jan 2025 11:11:13 -0700 Subject: [TUHS] "Webster's Second on the Head of a Pin"? In-Reply-To: References: Message-ID: I wonder what Reeds meant. I know there are issues. For example, the 3B2 I administered for a while in the late 80s had multiple accounts with rsh, the restricted shell, as the login shell. That was okay, unless you used su and then had access to a root shell. HP/UX was way worse, with over 120 SUID shell scripts in the 90s. A much more interesting example of insecurity. But somehow, I'm guessing that's not what Reeds wrote about. Rik On Wed, Jan 1, 2025 at 8:02 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > I have it and will try to scan it in the next few days. Bug me if it > doesn't appear. > > Doug > > On Tue, Dec 31, 2024 at 11:37 AM Chet Ramey wrote: > > > > On 12/29/24 8:44 AM, Douglas McIlroy wrote: > > > I can supply a copy if no one else has beaten me to it. > > > > > > Ron Hardin subsequently pushed the limit even further. Unfortunately, > > > I do not have a record of that work. > > > > Along these same lines, does anyone on the list have a copy of > > > > "J. A. Reeds, /bin/sh: The biggest UNIX security Loophole, > > 11217-840302-04TM, AT&T Bell Laboratories, Murray Hill, NJ (1984)"? > > > > Years ago, in another lifetime, I wrote and asked him for a copy, but > > never got a reply. > > > > -- > > ``The lyf so short, the craft so long to lerne.'' - Chaucer > > ``Ars longa, vita brevis'' - Hippocrates > > Chet Ramey, UTech, CWRU chet at case.edu > http://tiswww.cwru.edu/~chet/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Jan 2 13:05:38 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 1 Jan 2025 22:05:38 -0500 Subject: [TUHS] "Webster's Second on the Head of a Pin"? In-Reply-To: References: Message-ID: I think $IFS ranks at the top of Jim's cabinet of horrors. For our multilevel-secure Unix (https://www.cs.dartmouth.edu/~doug/IX), he took almost everything out of the administrative shell, nosh (the no-shell shell), The classic /bin/sh was not endowed with any of the capabilities necessary to override Bell-LaPadula-Biba secrecy or integrity constraints. On Wed, Jan 1, 2025 at 1:11 PM Rik Farrow wrote: > > I wonder what Reeds meant. I know there are issues. For example, the 3B2 I administered for a while in the late 80s had multiple accounts with rsh, the restricted shell, as the login shell. That was okay, unless you used su and then had access to a root shell. > > HP/UX was way worse, with over 120 SUID shell scripts in the 90s. A much more interesting example of insecurity. But somehow, I'm guessing that's not what Reeds wrote about. > > Rik > > > On Wed, Jan 1, 2025 at 8:02 AM Douglas McIlroy wrote: >> >> I have it and will try to scan it in the next few days. Bug me if it >> doesn't appear. >> >> Doug >> >> On Tue, Dec 31, 2024 at 11:37 AM Chet Ramey wrote: >> > >> > On 12/29/24 8:44 AM, Douglas McIlroy wrote: >> > > I can supply a copy if no one else has beaten me to it. >> > > >> > > Ron Hardin subsequently pushed the limit even further. Unfortunately, >> > > I do not have a record of that work. >> > >> > Along these same lines, does anyone on the list have a copy of >> > >> > "J. A. Reeds, /bin/sh: The biggest UNIX security Loophole, >> > 11217-840302-04TM, AT&T Bell Laboratories, Murray Hill, NJ (1984)"? >> > >> > Years ago, in another lifetime, I wrote and asked him for a copy, but >> > never got a reply. >> > >> > -- >> > ``The lyf so short, the craft so long to lerne.'' - Chaucer >> > ``Ars longa, vita brevis'' - Hippocrates >> > Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From tuhs at tuhs.org Thu Jan 2 17:17:04 2025 From: tuhs at tuhs.org (durtal via TUHS) Date: Thu, 2 Jan 2025 18:17:04 +1100 (AEDT) Subject: [TUHS] Bergson Quote, Forward, BSTJ, 57:6 1978 Message-ID: I am curious about the apposite Bergson quote (intelligence...tools) found at the beginning of the Forward mentioned in the subject. Specifically, I am wondering if the quote was originally discovered in _Creative Evolution_ as a part of a course or through private reading. I am interested in the diffusion of Continental ideas concerning technology in English speaking countries during the 20th Century. Dr Rick Hayes durtal at sdf.org SDF Public Access UNIX System - https://sdf.org From arnold at skeeve.com Thu Jan 2 22:40:39 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 02 Jan 2025 05:40:39 -0700 Subject: [TUHS] Was the compressed dictionary used? Message-ID: <202501021240.502CedNC1415325@freefriends.org> Hi. The paper on compressing the dictionary was interesting. In the day of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is a big savings. Was the compressed dictionary put into use? I could imaging that spell(1) at least would have needed some library routines to return a stream of words from it. Just wondering. Thanks, Arnold From tuhs at tuhs.org Fri Jan 3 00:22:54 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Thu, 2 Jan 2025 09:22:54 -0500 Subject: [TUHS] "Webster's Second on the Head of a Pin"? In-Reply-To: References: Message-ID: On 1/1/25 1:11 PM, Rik Farrow wrote: > I wonder what Reeds meant. I know there are issues. I've wondered myself. I am curious how many of these issues POSIX addresses (and bash, too, of course). > For example, the 3B2 I > administered for a while in the late 80s had multiple accounts with rsh, > the restricted shell, as the login shell. That was okay, unless you used su > and then had access to a root shell. That's an administrator problem. Part of setting up a restricted shell environment is creating a directory of necessary binaries and setting PATH appropriately. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri Jan 3 00:28:16 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Thu, 2 Jan 2025 09:28:16 -0500 Subject: [TUHS] "Webster's Second on the Head of a Pin"? In-Reply-To: References: Message-ID: <229f78c9-d0a8-4897-a66b-d047206965b7@case.edu> On 1/1/25 10:05 PM, Douglas McIlroy wrote: > I think $IFS ranks at the top of Jim's cabinet of horrors. Well, the Bourne shell's combination of importing IFS from the environment and then using it to split all words was particularly lethal. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From douglas.mcilroy at dartmouth.edu Fri Jan 3 00:51:10 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 2 Jan 2025 09:51:10 -0500 Subject: [TUHS] Was the compressed dictionary used? In-Reply-To: <202501021240.502CedNC1415325@freefriends.org> References: <202501021240.502CedNC1415325@freefriends.org> Message-ID: I am not aware that the compressed dictionary was used for anything. Steve Johnson's first shell-script spelling-checker did make a pass over a dictionary, but not Webster's second, which would have caused lots of false negatives because it contains so many exotic small words that could result from typos. My production spell aggresively stripped affixes and used hashing and other coding tricks to keep its "dictionary" in the limited memory of a PDP-11. (The whole story is told in https://www.cs.dartmouth.edu/~doug/spell.pdf and insightfully described by Jon Bentley in https://dl.acm.org/doi/pdf/10.1145/3532.315102.) When larger memory became available, these heroics were replaced by basic common-prefix coding patterned after Morris and Thompson, just as Arnold surmised. On Thu, Jan 2, 2025 at 7:41 AM wrote: > > Hi. > > The paper on compressing the dictionary was interesting. In the day > of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is > a big savings. > > Was the compressed dictionary put into use? I could imaging that > spell(1) at least would have needed some library routines to return > a stream of words from it. > > Just wondering. Thanks, > > Arnold From imp at bsdimp.com Fri Jan 3 01:12:45 2025 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Jan 2025 08:12:45 -0700 Subject: [TUHS] Was the compressed dictionary used? In-Reply-To: References: <202501021240.502CedNC1415325@freefriends.org> Message-ID: On Thu, Jan 2, 2025, 7:51 AM Douglas McIlroy wrote: > I am not aware that the compressed dictionary was used for anything. > Steve Johnson's first shell-script spelling-checker did make a pass > over a dictionary, but not Webster's second, which would have caused > lots of false negatives because it contains so many exotic small words > that could result from typos. Where did the Websters Second file come from? Did the labs give the public domain paper dictionary to the equivalent of a typing pool and had them enter it? It did it come from elsewhere? Or something else? How was it checked for accuracy? Warner My production spell aggresively stripped > affixes and used hashing and other coding tricks to keep its > "dictionary" in the limited memory of a PDP-11. (The whole story is > told in https://www.cs.dartmouth.edu/~doug/spell.pdf and insightfully > described by Jon Bentley in > https://dl.acm.org/doi/pdf/10.1145/3532.315102.) When larger memory > became available, these heroics were replaced by basic common-prefix > coding patterned after Morris and Thompson, just as Arnold surmised. > > On Thu, Jan 2, 2025 at 7:41 AM wrote: > > > > Hi. > > > > The paper on compressing the dictionary was interesting. In the day > > of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is > > a big savings. > > > > Was the compressed dictionary put into use? I could imaging that > > spell(1) at least would have needed some library routines to return > > a stream of words from it. > > > > Just wondering. Thanks, > > > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jan 3 01:13:40 2025 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Thu, 2 Jan 2025 09:13:40 -0600 Subject: [TUHS] Was the compressed dictionary used? In-Reply-To: <202501021240.502CedNC1415325@freefriends.org> References: <202501021240.502CedNC1415325@freefriends.org> Message-ID: On 1/2/25 6:40 AM, arnold at skeeve.com wrote: > The paper on compressing the dictionary was interesting. In the day > of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is a > big savings. It's even more important when sending data across the wire. > Was the compressed dictionary put into use? I could imaging that > spell(1) at least would have needed some library routines to return > a stream of words from it. I couldn't help but think about the DNS on wire compression format which will re-use part of the existing query name to de-duplicate later parts of the same query name. I know it's not the same, but it felt un-ignorably close in both purpose and method. -- Grant. . . . unix || die From arnold at skeeve.com Fri Jan 3 02:20:03 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 02 Jan 2025 09:20:03 -0700 Subject: [TUHS] Was the compressed dictionary used? In-Reply-To: References: <202501021240.502CedNC1415325@freefriends.org> Message-ID: <202501021620.502GK3U91432598@freefriends.org> Douglas McIlroy wrote: > My production spell aggresively stripped > affixes and used hashing and other coding tricks to keep its > "dictionary" in the limited memory of a PDP-11. (The whole story is > told in https://www.cs.dartmouth.edu/~doug/spell.pdf and insightfully > described by Jon Bentley in > https://dl.acm.org/doi/pdf/10.1145/3532.315102.) When larger memory > became available, these heroics were replaced by basic common-prefix > coding patterned after Morris and Thompson, just as Arnold surmised. But all this would have been in the C code for spell, and not in the dictionary used, right? Thanks, Arnold P.S. A few years ago I made the v10 spell available for today's systems, see https://github.com/arnoldrobbins/v10spell. From douglas.mcilroy at dartmouth.edu Fri Jan 3 03:20:41 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 2 Jan 2025 12:20:41 -0500 Subject: [TUHS] Was the compressed dictionary used? In-Reply-To: References: <202501021240.502CedNC1415325@freefriends.org> Message-ID: The word list of Webster's 2nd came from an Air Force project along with several other files, including a medical dictionary and an alphabetical list of tetragrams found in Web2--something one would expect to create for oneself nowadays. The files were freely distributed with no strings attached. We have not noticed any mistakes. The list includes 76205 entries that contain blanks or hyphens; these were omitted from the pinhead exercise. Doug On Thu, Jan 2, 2025 at 10:13 AM Warner Losh wrote: > > > > On Thu, Jan 2, 2025, 7:51 AM Douglas McIlroy wrote: >> >> I am not aware that the compressed dictionary was used for anything. >> Steve Johnson's first shell-script spelling-checker did make a pass >> over a dictionary, but not Webster's second, which would have caused >> lots of false negatives because it contains so many exotic small words >> that could result from typos. > > > Where did the Websters Second file come from? Did the labs give the public domain paper dictionary to the equivalent of a typing pool and had them enter it? It did it come from elsewhere? Or something else? How was it checked for accuracy? > > Warner > > >> My production spell aggresively stripped >> affixes and used hashing and other coding tricks to keep its >> "dictionary" in the limited memory of a PDP-11. (The whole story is >> told in https://www.cs.dartmouth.edu/~doug/spell.pdf and insightfully >> described by Jon Bentley in >> https://dl.acm.org/doi/pdf/10.1145/3532.315102.) When larger memory >> became available, these heroics were replaced by basic common-prefix >> coding patterned after Morris and Thompson, just as Arnold surmised. >> >> On Thu, Jan 2, 2025 at 7:41 AM wrote: >> > >> > Hi. >> > >> > The paper on compressing the dictionary was interesting. In the day >> > of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is >> > a big savings. >> > >> > Was the compressed dictionary put into use? I could imaging that >> > spell(1) at least would have needed some library routines to return >> > a stream of words from it. >> > >> > Just wondering. Thanks, >> > >> > Arnold From rik at rikfarrow.com Fri Jan 3 04:13:22 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Thu, 2 Jan 2025 11:13:22 -0700 Subject: [TUHS] "Webster's Second on the Head of a Pin"? In-Reply-To: References: Message-ID: On Thu, Jan 2, 2025 at 7:23 AM Chet Ramey wrote: > On 1/1/25 1:11 PM, Rik Farrow wrote: > > For example, the 3B2 I > > administered for a while in the late 80s had multiple accounts with rsh, > > the restricted shell, as the login shell. That was okay, unless you used > su > > and then had access to a root shell. > > That's an administrator problem. Part of setting up a restricted shell > environment is creating a directory of necessary binaries and setting > PATH appropriately. > > Each of these special accounts did have a home directory with a .profile to set up the restricted environment, then run a shell script to perform some task as root. For example, logging in as 'backup' would run /user/backup/.profile and allow a non-privileged user to run a backup script as root. But typing "su backup" produced a root-owner shell without restrictions. You need to type "su - " to run the account's .profile script. Rik -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Jan 3 05:47:26 2025 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Thu, 2 Jan 2025 14:47:26 -0500 Subject: [TUHS] "Webster's Second on the Head of a Pin"? In-Reply-To: References: Message-ID: <17895df2-19e5-45a0-aa7b-68af93522396@case.edu> On 1/2/25 1:13 PM, Rik Farrow wrote: > > > On Thu, Jan 2, 2025 at 7:23 AM Chet Ramey > wrote: > > On 1/1/25 1:11 PM, Rik Farrow wrote: > > For example, the 3B2 I > > administered for a while in the late 80s had multiple accounts with > rsh, > > the restricted shell, as the login shell. That was okay, unless you > used su > > and then had access to a root shell. > > That's an administrator problem. Part of setting up a restricted shell > environment is creating a directory of necessary binaries and setting > PATH appropriately. > > Each of these special accounts did have a home directory with a .profile to > set up the restricted environment, then run a shell script to perform some > task as root. For example, logging in as 'backup' would run /user/ > backup/.profile and allow a non-privileged user to run a backup script as root. > > But typing "su backup" produced a root-owner shell without restrictions. > You need to type "su - " to run the account's .profile script. OK, I thought you meant the other way, breaking out of a restricted environment. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From imp at bsdimp.com Fri Jan 3 07:19:58 2025 From: imp at bsdimp.com (Warner Losh) Date: Thu, 2 Jan 2025 14:19:58 -0700 Subject: [TUHS] Was the compressed dictionary used? In-Reply-To: References: <202501021240.502CedNC1415325@freefriends.org> Message-ID: The BSDs since 4.4lite have added a lot of missing words, but few corrections. From FreeBSD: Capitalized Transvaal, fixed 'stock certificate' to have a 't' and preconsoidate -> preconsolidate Ahtena, freen, unknowen and structurelessness were removed corelate (etc) and freend were removed as typos and only thinly supported variants. Not bad for 50 years of nit-pickers pouring over the file. Warner On Thu, Jan 2, 2025 at 10:20 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > The word list of Webster's 2nd came from an Air Force project along > with several other files, including a medical dictionary and an > alphabetical list of tetragrams found in Web2--something one would > expect to create for oneself nowadays. The files were freely > distributed with no strings attached. We have not noticed any > mistakes. The list includes 76205 entries that contain blanks or > hyphens; these were omitted from the pinhead exercise. > > Doug > > On Thu, Jan 2, 2025 at 10:13 AM Warner Losh wrote: > > > > > > > > On Thu, Jan 2, 2025, 7:51 AM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> > >> I am not aware that the compressed dictionary was used for anything. > >> Steve Johnson's first shell-script spelling-checker did make a pass > >> over a dictionary, but not Webster's second, which would have caused > >> lots of false negatives because it contains so many exotic small words > >> that could result from typos. > > > > > > Where did the Websters Second file come from? Did the labs give the > public domain paper dictionary to the equivalent of a typing pool and had > them enter it? It did it come from elsewhere? Or something else? How was it > checked for accuracy? > > > > Warner > > > > > >> My production spell aggresively stripped > >> affixes and used hashing and other coding tricks to keep its > >> "dictionary" in the limited memory of a PDP-11. (The whole story is > >> told in https://www.cs.dartmouth.edu/~doug/spell.pdf and insightfully > >> described by Jon Bentley in > >> https://dl.acm.org/doi/pdf/10.1145/3532.315102.) When larger memory > >> became available, these heroics were replaced by basic common-prefix > >> coding patterned after Morris and Thompson, just as Arnold surmised. > >> > >> On Thu, Jan 2, 2025 at 7:41 AM wrote: > >> > > >> > Hi. > >> > > >> > The paper on compressing the dictionary was interesting. In the day > >> > of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is > >> > a big savings. > >> > > >> > Was the compressed dictionary put into use? I could imaging that > >> > spell(1) at least would have needed some library routines to return > >> > a stream of words from it. > >> > > >> > Just wondering. Thanks, > >> > > >> > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Fri Jan 3 09:32:41 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 2 Jan 2025 18:32:41 -0500 Subject: [TUHS] Was the compressed dictionary used? In-Reply-To: References: <202501021240.502CedNC1415325@freefriends.org> Message-ID: Warner, Thanks for those bugs. Here's a similar list for lucky owners of Webster's 7th Collegiate: dissymmettric brecia belicoseness assaugement A space is missing in the pronunciation field for Ouija. There must be more bugs in other fields, which constitute the bulk of the Web7 files. Doug On Thu, Jan 2, 2025 at 4:20 PM Warner Losh wrote: > > The BSDs since 4.4lite have added a lot of missing words, but few corrections. From FreeBSD: > > Capitalized Transvaal, fixed 'stock certificate' to have a 't' and preconsoidate -> preconsolidate > > Ahtena, freen, unknowen and structurelessness were removed > > corelate (etc) and freend were removed as typos and only thinly supported variants. > > Not bad for 50 years of nit-pickers pouring over the file. > > Warner > > On Thu, Jan 2, 2025 at 10:20 AM Douglas McIlroy wrote: >> >> The word list of Webster's 2nd came from an Air Force project along >> with several other files, including a medical dictionary and an >> alphabetical list of tetragrams found in Web2--something one would >> expect to create for oneself nowadays. The files were freely >> distributed with no strings attached. We have not noticed any >> mistakes. The list includes 76205 entries that contain blanks or >> hyphens; these were omitted from the pinhead exercise. >> >> Doug >> >> On Thu, Jan 2, 2025 at 10:13 AM Warner Losh wrote: >> > >> > >> > >> > On Thu, Jan 2, 2025, 7:51 AM Douglas McIlroy wrote: >> >> >> >> I am not aware that the compressed dictionary was used for anything. >> >> Steve Johnson's first shell-script spelling-checker did make a pass >> >> over a dictionary, but not Webster's second, which would have caused >> >> lots of false negatives because it contains so many exotic small words >> >> that could result from typos. >> > >> > >> > Where did the Websters Second file come from? Did the labs give the public domain paper dictionary to the equivalent of a typing pool and had them enter it? It did it come from elsewhere? Or something else? How was it checked for accuracy? >> > >> > Warner >> > >> > >> >> My production spell aggresively stripped >> >> affixes and used hashing and other coding tricks to keep its >> >> "dictionary" in the limited memory of a PDP-11. (The whole story is >> >> told in https://www.cs.dartmouth.edu/~doug/spell.pdf and insightfully >> >> described by Jon Bentley in >> >> https://dl.acm.org/doi/pdf/10.1145/3532.315102.) When larger memory >> >> became available, these heroics were replaced by basic common-prefix >> >> coding patterned after Morris and Thompson, just as Arnold surmised. >> >> >> >> On Thu, Jan 2, 2025 at 7:41 AM wrote: >> >> > >> >> > Hi. >> >> > >> >> > The paper on compressing the dictionary was interesting. In the day >> >> > of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is >> >> > a big savings. >> >> > >> >> > Was the compressed dictionary put into use? I could imaging that >> >> > spell(1) at least would have needed some library routines to return >> >> > a stream of words from it. >> >> > >> >> > Just wondering. Thanks, >> >> > >> >> > Arnold From johnl at taugh.com Fri Jan 3 13:14:43 2025 From: johnl at taugh.com (John Levine) Date: 2 Jan 2025 22:14:43 -0500 Subject: [TUHS] Was the compressed dictionary used? In-Reply-To: References: <202501021240.502CedNC1415325@freefriends.org> Message-ID: <20250103031443.F13C0B1C8B4A@ary.qy> It appears that Grant Taylor via TUHS said: >On 1/2/25 6:40 AM, arnold at skeeve.com wrote: >> The paper on compressing the dictionary was interesting. In the day >> of 20 meg disks, compressing a ~ 2.5 meg file down to ~ .5 meg is a >> big savings. > >It's even more important when sending data across the wire. > >> Was the compressed dictionary put into use? I could imaging that >> spell(1) at least would have needed some library routines to return >> a stream of words from it. > >I couldn't help but think about the DNS on wire compression format which >will re-use part of the existing query name to de-duplicate later parts >of the same query name. > >I know it's not the same, but it felt un-ignorably close in both purpose >and method. Lempel and Ziv published the LZ77 paper in 1977 (hence the name) which uses back pointers into a sliding window of text. Later tweaks brought us LZ78 and compress and gzip. There's really only two ways to compress data: use a variable length coding scheme with the shortest codes for the most common tokens, or a dictionary that uses pointers to repeated strings. Huffman invented the former in 1951, Lempel and Ziv the latter in 1977, although as we've seen people did special purpose versions of the dictionary approach like this one. Modern schemes use combinarions of both. The DNS data formats were invented in about 1982 but I have no idea whether Mockapetris was familar with LZ. I suppose I could ask him. R's, John From rminnich at gmail.com Sat Jan 4 08:17:01 2025 From: rminnich at gmail.com (ron minnich) Date: Fri, 3 Jan 2025 14:17:01 -0800 Subject: [TUHS] userland exec -- wasn't exec that way originally? Message-ID: Do I remember correctly that the early linux exec as a userland exec? I think this came up before, I just can't recall. I just learned about: https://github.com/hardenedlinux/userland-exec -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Tue Jan 7 07:20:41 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Jan 2025 21:20:41 +0000 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? Message-ID: The sound situation in the UNIX world to me has always felt particularly fragmentary, with OSS offering some glimmer of hope but faltering under the long shadow of ALSA, with a hodge podge of PCM and other low level interfaces littered about other offerings. Given AT&T's involvement with the development of just about everything "sound over wires" for decades by the time UNIX comes along, one would suspect AT&T would be quite invested in standardizing interfaces for computers interacting with audio signals on copper wire. Indeed much of the ESS R&D was taking in analog telephone signals, digitizing them, and then acting on those digitized results before converting back to analog to send to the other end. Where this has me curious is if there were any efforts in Bell Labs, prior to other industry players having their hands on the steering wheel, to establish an abstract UNIX interface pattern for interacting with streams of converted audio signal. Of course modern formats didn't exist, but the general idea of PCM was well established, concepts like sampling rates, bit depths, etc. could be used in calculations to interpret and manipulate digitized audio streams. Any recollections? Was the landscape of signal processing solutions just so particular that trying to create a centralized interface didn't make sense at the time? Or was it a simple matter of priorities, with things like language development and system design taking center stage, leaving a dearth of resources to direct towards these sorts of matters? Was there ever a chance of seeing, say, the 5ESS handling of PCM, extended out to non-switching applications, or was that stuff firmly siloed over in the switching groups, having no influence on signal processing outside? - Matt G. From steffen at sdaoden.eu Tue Jan 7 07:51:43 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 06 Jan 2025 22:51:43 +0100 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? In-Reply-To: References: Message-ID: <20250106215143.b3Q14AL1@steffen%sdaoden.eu> segaloco via TUHS wrote in : |The sound situation in the UNIX world to me has always felt particularly |fragmentary, with OSS offering some glimmer of hope but faltering under \ |the long |shadow of ALSA, with a hodge podge of PCM and other low level interfaces |littered about other offerings. Oh, but *how* great it was when FreeBSD came on over with those "virtual sound devices", in 4.7 or 4.9 i think it was. Ie instead of one blocking device, one could open dev.1 and dev.2 and it was multiplexed in the kernel. It did some format conversion in the kernel alongside this. It was *fantastic*!, and i had a recording program sitting on a Cyrix 166+ and it took me ~1.5 percent of (single) CPU to record our then still great Hessenradio HR3 for long hours (Clubnight with worldwide known DJs, Chill with great sets in the Sunday mornings), and oh yes HR2 with the wonderful Mr. Paul Bartholomäi in "Notenschlüssel" (classical music), and the fantastic "Voyager" hour with Robert Lug on Sunday evening. It cannot be any better. I could code and compile and there was no stuttering alongside. 1.5 percent of CPU, honestly! I say this because FreeBSD has replaced that very code last year, if i recall correctly. It now all scales dynmically, if i read the patches that flew by right. (So it may be even better as of now, but by then, over twenty years ago, it blew my mind. And the solution was so simple, you know. The number of concurrent devices was a compile time constant if i recall correctly, four by default.) I also say this because today i am lucky i can use ALSA on Linux, and apulse for the firefox i have to use (and do use, too .. i also browse the internet in such a monster, and at least in parts still like that). I always hated those server solutions, where those masses of audio data flow through several context switches. What for? I never understood. Someone convinced me to try that pulseaudio server, but i think it was about 20 percent of CPU for a simple stream, with a terrible GUI, and that on a i5-8250U CPU @ 1.60GHz with up to 3.4 Ghz (four core; the four HT are alwys disabled). 20 percent!! ... |Any recollections?[.] Sorry, the above is totally apart, but for me the above is still such a tremendous thing that someone did; and for free. Whoever it was (i actually never tried to check it, now that i track their git for so many years), *thank you*! (And that includes the simple usual format conversions in between those 22050/44100 etc etc. Just like that -- open a device and read it, no thousands of callbacks, nothing. And 1.5 percent CPU. Maybe it is not good/exact enough for studio level audio editing. But i still have lots of those recordings, except that the "Balkan piss box" chill somehow disappeared. (Sorry Pedja, shall you read this.)) --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) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear From stewart at serissa.com Tue Jan 7 09:42:52 2025 From: stewart at serissa.com (Serissa) Date: Mon, 6 Jan 2025 18:42:52 -0500 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? Message-ID: <6214AA9A-3A53-46C0-83E2-10171C07D10A@serissa.com>  In the lost-in-time department, my group at Digital Cambridge Research lab in 1993 did an audio interface patterned after the X Window system. Paper in the Summer USENIX: https://www.usenix.org/legacy/publications/library/proceedings/cinci93/gettys.html For extra fun, the lab director of CRL at the time was Vic Vyssotsky. But there must have been some Bell work, because around 1983 (?) when I was doing Etherphone at PARC I visited John DeTreville at Holmdel. He was building a voice - over - Ethernet system as well. -Larry > On Jan 6, 2025, at 4:51 PM, Steffen Nurpmeso wrote: > segaloco via TUHS wrote in > GXac7wymRCtifnU9VKnlsrJCrKFqGZSgM6-0=@protonmail.com>: > |The sound situation in the UNIX world to me has always felt particularly > |fragmentary, with OSS offering some glimmer of hope but faltering under \ > |the long > |shadow of ALSA, with a hodge podge of PCM and other low level interfaces > |littered about other offerings. > > Oh, but *how* great it was when FreeBSD came on over with those > "virtual sound devices", in 4.7 or 4.9 i think it was. Ie instead > of one blocking device, one could open dev.1 and dev.2 and it was > multiplexed in the kernel. It did some format conversion in the > kernel alongside this. > > It was *fantastic*!, and i had a recording program sitting on > a Cyrix 166+ and it took me ~1.5 percent of (single) CPU to record > our then still great Hessenradio HR3 for long hours (Clubnight > with worldwide known DJs, Chill with great sets in the Sunday > mornings), and oh yes HR2 with the wonderful Mr. Paul Bartholomäi > in "Notenschlüssel" (classical music), and the fantastic "Voyager" > hour with Robert Lug on Sunday evening. It cannot be any better. > I could code and compile and there was no stuttering alongside. > 1.5 percent of CPU, honestly! > > I say this because FreeBSD has replaced that very code last year, > if i recall correctly. It now all scales dynmically, if i read > the patches that flew by right. (So it may be even better as of > now, but by then, over twenty years ago, it blew my mind. And the > solution was so simple, you know. The number of concurrent > devices was a compile time constant if i recall correctly, four by > default.) > > I also say this because today i am lucky i can use ALSA on Linux, > and apulse for the firefox i have to use (and do use, too > .. i also browse the internet in such a monster, and at least in > parts still like that). I always hated those server solutions, > where those masses of audio data flow through several context > switches. What for? I never understood. Someone convinced me to > try that pulseaudio server, but i think it was about 20 percent of > CPU for a simple stream, with a terrible GUI, and that on > a i5-8250U CPU @ 1.60GHz with up to 3.4 Ghz (four core; the four > HT are alwys disabled). 20 percent!! > > ... > |Any recollections?[.] > > Sorry, the above is totally apart, but for me the above is still > such a tremendous thing that someone did; and for free. Whoever > it was (i actually never tried to check it, now that i track their > git for so many years), *thank you*! > (And that includes the simple usual format conversions in between > those 22050/44100 etc etc. Just like that -- open a device and > read it, no thousands of callbacks, nothing. And 1.5 percent CPU. > Maybe it is not good/exact enough for studio level audio editing. > But i still have lots of those recordings, except that the "Balkan > piss box" chill somehow disappeared. (Sorry Pedja, shall you read > this.)) > > --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) > | > |In Fall and Winter, feel "The Dropbear Bard"s pint(er). > | > |The banded bear > |without a care, > |Banged on himself for e'er and e'er > | > |Farewell, dear collar bear -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrochkind at gmail.com Tue Jan 7 11:16:25 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Mon, 6 Jan 2025 18:16:25 -0700 Subject: [TUHS] A Retrospective on the Source Code Control System Message-ID: I mentioned a few weeks ago that I was writing this invited paper for an upcoming 50-year anniversary of the first issue of IEEE Transactions on Software Engineering. The paper has now been accepted for publication and here's a preprint version of it: https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Jan 7 11:49:19 2025 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 6 Jan 2025 17:49:19 -0800 Subject: [TUHS] A Retrospective on the Source Code Control System In-Reply-To: References: Message-ID: <20250107014919.GE13346@mcvoy.com> Nice. For what it is worth, your SCCS supports merging just fine. We used SCCS to do merges without copying by using your includes. If SCCS had had a -m for merge, it would have included the branch but then all the other deltas going up to the GCA. Much like the tip means the tip but all the other deltas going back to 1.1. SCCS was a big contribution to the state of the art, I am forever grateful that you did it. To this day I don't think people know what you did. When we were a business, every time some SCM came out, Rick or I would ask "is there a weave" like you had done, if not, we didn't care. That weave format that you did 50 years ago is awesome. On Mon, Jan 06, 2025 at 06:16:25PM -0700, Marc Rochkind wrote: > I mentioned a few weeks ago that I was writing this invited paper for an > upcoming 50-year anniversary of the first issue of IEEE Transactions on > Software Engineering. > > The paper has now been accepted for publication and here's a preprint > version of it: > > https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf > > Marc -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From mrochkind at gmail.com Tue Jan 7 11:55:55 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Mon, 6 Jan 2025 18:55:55 -0700 Subject: [TUHS] A Retrospective on the Source Code Control System In-Reply-To: <20250107014919.GE13346@mcvoy.com> References: <20250107014919.GE13346@mcvoy.com> Message-ID: Thanks for the kind words, Larry. Marc On Mon, Jan 6, 2025 at 6:49 PM Larry McVoy wrote: > Nice. > > For what it is worth, your SCCS supports merging just fine. We used > SCCS to do merges without copying by using your includes. If SCCS had > had a -m for merge, it would have included the branch but then all the > other deltas going up to the GCA. Much like the tip means the tip > but all the other deltas going back to 1.1. > > SCCS was a big contribution to the state of the art, I am forever > grateful that you did it. To this day I don't think people know > what you did. When we were a business, every time some SCM came out, > Rick or I would ask "is there a weave" like you had done, if not, > we didn't care. That weave format that you did 50 years ago is > awesome. > > > On Mon, Jan 06, 2025 at 06:16:25PM -0700, Marc Rochkind wrote: > > I mentioned a few weeks ago that I was writing this invited paper for an > > upcoming 50-year anniversary of the first issue of IEEE Transactions on > > Software Engineering. > > > > The paper has now been accepted for publication and here's a preprint > > version of it: > > > > https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf > > > > Marc > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -- Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luther.johnson at makerlisp.com Tue Jan 7 12:50:04 2025 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Mon, 6 Jan 2025 19:50:04 -0700 Subject: [TUHS] A Retrospective on the Source Code Control System In-Reply-To: <20250107014919.GE13346@mcvoy.com> References: <20250107014919.GE13346@mcvoy.com> Message-ID: I never knew the technical details of what you had done, but I enjoyed using SCCS in the mid-80's when I started using UNIX, and it helped me develop an understanding of source code management disciplines. Sometimes I had to use RCS when SCCS wasn't available, later I used everything else, as we all did, but I always liked the way SCCS worked on those first SunOS and Ultrix systems where I encountered it, especially when it was well understood by the make utility. Thank you for this great contribution, and I enjoyed reading your paper just now. On 01/06/2025 06:49 PM, Larry McVoy wrote: > Nice. > > For what it is worth, your SCCS supports merging just fine. We used > SCCS to do merges without copying by using your includes. If SCCS had > had a -m for merge, it would have included the branch but then all the > other deltas going up to the GCA. Much like the tip means the tip > but all the other deltas going back to 1.1. > > SCCS was a big contribution to the state of the art, I am forever > grateful that you did it. To this day I don't think people know > what you did. When we were a business, every time some SCM came out, > Rick or I would ask "is there a weave" like you had done, if not, > we didn't care. That weave format that you did 50 years ago is > awesome. > > > On Mon, Jan 06, 2025 at 06:16:25PM -0700, Marc Rochkind wrote: >> I mentioned a few weeks ago that I was writing this invited paper for an >> upcoming 50-year anniversary of the first issue of IEEE Transactions on >> Software Engineering. >> >> The paper has now been accepted for publication and here's a preprint >> version of it: >> >> https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf >> >> Marc From arnold at skeeve.com Tue Jan 7 19:01:04 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 07 Jan 2025 02:01:04 -0700 Subject: [TUHS] A Retrospective on the Source Code Control System In-Reply-To: References: Message-ID: <202501070901.507914wk2068428@freefriends.org> Marc Rochkind wrote: > I mentioned a few weeks ago that I was writing this invited paper for an > upcoming 50-year anniversary of the first issue of IEEE Transactions on > Software Engineering. > > The paper has now been accepted for publication and here's a preprint > version of it: > > https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf > > Marc This is a nice paper. Marc, I think you're a little too hard on your 24-year old self. To have created the weave at the age of 24 indicates (to me) that you were certainly a well above average programmer / computer scientist. Many of the other things you criticize could be attributed to simply not knowing better (= not having yet had enough experience). My two cents, anyway. Again, a nice paper. Arnold From douglas.mcilroy at dartmouth.edu Wed Jan 8 00:42:14 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 7 Jan 2025 09:42:14 -0500 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? Message-ID: > Was the landscape of signal processing solutions just so > particular that trying to create a centralized interface didn't make sense at > the time? Or was it a simple matter of priorities, with things like language > development and system design taking center stage, leaving a dearth of resources > to direct towards these sorts of matters? Was there ever a chance of seeing, > say, the 5ESS handling of PCM, extended out to non-switching applications, In the early days of Unix there were intimate ties between CS Research and Visual and Acoustic Research. V&A were Bell Labs' pioneer minicomputer users because they needed interactive access to graphics and audio, which would have been prohibitively expensive on the Labs' pre-timesharing mainframes. Also they generally had EE backgrounds, so were comfortable working hands-on with hardware, whereas CS had been largely spun off from the math department. Ed David, who led Bell Labs into Multics, without which Unix might not have happened, had transferred from V&A to CS. So had Vic Vyssotsky and Elliot Pinson (Dennis's department head and coauthor with me of the introduction to the 1978 BSTJ Unix issue). John Kelly, a brilliant transferee who died all too young pre-Unix, had collaborated with Vic on BLODI, the first dataflow language, which took digital signal processing off breadboards and into computers. One central member of the Unix lab, Lee McMahon, never left V&A. The PDP-7 of Unix v0 was a hand-me-down from Pinson's time in V&A. And the PDP-11 of v1 was supported by a year-end fund surplus from there. People came from V&A to CS because their interests had drifted from signal processing to computing per se. With hindsight, one can see that CS recruiting--even when it drew on engineering or physics talent--concentrated on similarly motivated people. There was dabbling in acoustics, such as my "speak" text-to-speech program. And there were workers dedicated to a few specialties, such as Henry Baird in optical character recognition. But unlike text processing, say, these fields never reached a critical mass of support that might have stimulated a wider array of I/O drivers or full toolkits to use them. Meanwhile, in V&A Research linguists adopted Unix, but most others continued to roll their own one-off platforms. It's interesting to speculate whether the lack of audio interfaces in Unix was a cause or a result of this do-it-yourself impulse. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Wed Jan 8 01:22:34 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 7 Jan 2025 09:22:34 -0600 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? In-Reply-To: References: Message-ID: <20250107152234.uodqvpi3hgb4vxaj@illithid> At 2025-01-07T09:42:14-0500, Douglas McIlroy wrote: > The PDP-7 of Unix v0 was a hand-me-down from Pinson's time in V&A. And > the PDP-11 of v1 was supported by a year-end fund surplus from there. Hi Doug, This seems to clarify something I'm a bit murky on in early Unix/nroff history, because I have read (and repeated, in groff's roff(7), the claim that revenue from internal AT&T deployments of nroff were a major aid to getting the CSRC on its feet hardware-wise. But that's in some tension with the story of Ossanna being able to deliver to the patent application typists a new line numbering feature in the (n)roff formatter "by tomorrow" if it was only after nroff's success that these revenues showed up. I also seem to remember from the preface to the v3 or v4 manual that the CSRC was trying to get itself and its Unix users everywhere away from the PDP-11/20 as fast as possibly, because that model didn't have memory protection. I thus have these questions: What model of PDP-11 was v1 Unix developed and run on at the CSRC? What model did the CSRC acquire next? Specifically, which one did (n)roff make possible? Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From imp at bsdimp.com Wed Jan 8 02:37:15 2025 From: imp at bsdimp.com (Warner Losh) Date: Tue, 7 Jan 2025 09:37:15 -0700 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? In-Reply-To: <20250107152234.uodqvpi3hgb4vxaj@illithid> References: <20250107152234.uodqvpi3hgb4vxaj@illithid> Message-ID: On Tue, Jan 7, 2025 at 8:22 AM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2025-01-07T09:42:14-0500, Douglas McIlroy wrote: > > The PDP-7 of Unix v0 was a hand-me-down from Pinson's time in V&A. And > > the PDP-11 of v1 was supported by a year-end fund surplus from there. > > Hi Doug, > > This seems to clarify something I'm a bit murky on in early Unix/nroff > history, because I have read (and repeated, in groff's roff(7), the > claim that revenue from internal AT&T deployments of nroff were a major > aid to getting the CSRC on its feet hardware-wise. But that's in some > tension with the story of Ossanna being able to deliver to the patent > application typists a new line numbering feature in the (n)roff > formatter "by tomorrow" if it was only after nroff's success that these > revenues showed up. > > I also seem to remember from the preface to the v3 or v4 manual that the > CSRC was trying to get itself and its Unix users everywhere away from > the PDP-11/20 as fast as possibly, because that model didn't have memory > protection. > Yes. V1 and V2 ran on the 11/20 without an MMU, while V3 and later was the port to the 11/45 with an MMU. I touch on these transitions in my history of unix talk. And I didn't know the connections that Douglas just relayed before my talk. It would have made it more interesting to include. Unix has always been about making it easier to collaborate and collaboration has a multiplier effect. > I thus have these questions: > > What model of PDP-11 was v1 Unix developed and run on at the CSRC? > > What model did the CSRC acquire next? Specifically, which one did > (n)roff make possible? > I'd love to hear this info first hand too. I've delved and discovered what I think the answers are, but I have no primary sources for them. Warner > Regards, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Wed Jan 8 03:53:22 2025 From: phil at ultimate.com (Phil Budne) Date: Tue, 07 Jan 2025 12:53:22 -0500 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? In-Reply-To: <20250107152234.uodqvpi3hgb4vxaj@illithid> References: <20250107152234.uodqvpi3hgb4vxaj@illithid> Message-ID: <202501071753.507HrMwZ043959@ultimate.com> G. Branden Robinson wrote: > What model of PDP-11 was v1 Unix developed and run on at the CSRC? For what it's worth, there is a roff.s in the PDP-7 sources. The command list: https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/roff.s#L189 > What model did the CSRC acquire next? Specifically, which one did > (n)roff make possible? The first was an 11/20, initially, I seem to recall running without any MMU (I remember a story that it was customary to yell out "a.out" in the terminal room before running a newly compiled binary to give everyone a chance to save their files). I believe the step up was to the high-end 11/45, which I believe came out before the 11/40 (a mid-range system with MMU but not separate Instruction & Data spaces). See https://gunkies.org/wiki/PDP-11 From lars at nocrew.org Wed Jan 8 04:19:25 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 07 Jan 2025 18:19:25 +0000 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? In-Reply-To: (Warner Losh's message of "Tue, 7 Jan 2025 09:37:15 -0700") References: <20250107152234.uodqvpi3hgb4vxaj@illithid> Message-ID: <7wjzb6bi6q.fsf@junk.nocrew.org> Warner Losh wrote: > Yes. V1 and V2 ran on the 11/20 without an MMU, while V3 and later was > the port to the 11/45 with an MMU. Aren't you skipping over the KS11? From sjenkin at canb.auug.org.au Wed Jan 8 05:05:50 2025 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Wed, 8 Jan 2025 06:05:50 +1100 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? In-Reply-To: References: Message-ID: A reminder of 2 stories of CS Research’s long running interest in Music and Audio: (much) “better than MP3” - Rob Pike on Plan 9’s CD-ROM (not) being filled with compressed music, including new works from Lou Reed & Debby Harry - In a comment, Ken’s 400MB disk full of compressed music & his talking about his work at conferences. "And that, my friends, is why MP-3 took off instead of the far better follow-on system we were on the cusp of getting out the door.” > On 8 Jan 2025, at 01:42, Douglas McIlroy wrote: > > In the early days of Unix there were intimate ties between CS Research and Visual and Acoustic Research. V&A were Bell Labs' pioneer minicomputer users because they needed interactive access to graphics and audio, which would have been prohibitively expensive on the Labs' pre-timesharing mainframes. Also they generally had EE backgrounds, so were comfortable working hands-on with hardware, whereas CS had been largely spun off from the math department. > > Ed David, who led Bell Labs into Multics, without which Unix might not have happened, had transferred from V&A to CS. So had Vic Vyssotsky and Elliot Pinson (Dennis's department head and coauthor with me of the introduction to the 1978 BSTJ Unix issue). John Kelly, a brilliant transferee who died all too young pre-Unix, had collaborated with Vic on BLODI, the first dataflow language, which took digital signal processing off breadboards and into computers. One central member of the Unix lab, Lee McMahon, never left V&A. > > The PDP-7 of Unix v0 was a hand-me-down from Pinson's time in V&A. And the PDP-11 of v1 was supported by a year-end fund surplus from there. > > People came from V&A to CS because their interests had drifted from signal processing to computing per se. With hindsight, one can see that CS recruiting--even when it drew on engineering or physics talent--concentrated on similarly motivated people. There was dabbling in acoustics, such as my "speak" text-to-speech program. And there were workers dedicated to a few specialties, such as Henry Baird in optical character recognition. But unlike text processing, say, these fields never reached a critical mass of support that might have stimulated a wider array of I/O drivers or full toolkits to use them. > > Meanwhile, in V&A Research linguists adopted Unix, but most others continued to roll their own one-off platforms. It's interesting to speculate whether the lack of audio interfaces in Unix was a cause or a result of this do-it-yourself impulse. > > Doug -- 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 rik at rikfarrow.com Wed Jan 8 11:40:14 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Tue, 7 Jan 2025 18:40:14 -0700 Subject: [TUHS] A Retrospective on the Source Code Control System In-Reply-To: References: Message-ID: Very nicely written history, as well as explanation of how systems differed. I appreciated reading this, but especially enjoyed one of the closing paragraphs on the future: How am I supposed to know? AI is already doing some coding. Maybe in ten or twenty years it will do all of it. Will AI need version control? If it does, will it be the latest version of Git, or maybe something invented by AI? Thanks Marc Rik On Mon, Jan 6, 2025 at 6:16 PM Marc Rochkind wrote: > I mentioned a few weeks ago that I was writing this invited paper for an > upcoming 50-year anniversary of the first issue of IEEE Transactions on > Software Engineering. > > The paper has now been accepted for publication and here's a preprint > version of it: > > https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf > > Marc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrochkind at gmail.com Wed Jan 8 13:01:34 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Tue, 7 Jan 2025 20:01:34 -0700 Subject: [TUHS] A Retrospective on the Source Code Control System In-Reply-To: References: Message-ID: Glad you liked that paragraph, Rik. I had that section head in my outline and when I got there I had no idea what to type. Got away with it! ;-) Marc On Tue, Jan 7, 2025, 6:40 PM Rik Farrow wrote: > Very nicely written history, as well as explanation of how systems > differed. I appreciated reading this, but especially enjoyed one of the > closing paragraphs on the future: > > How am I supposed to know? AI is already doing some coding. Maybe in ten > or twenty years it will do all of it. Will AI need version control? If it > does, will it be the latest version of Git, or maybe something invented by > AI? > > Thanks Marc > Rik > > > On Mon, Jan 6, 2025 at 6:16 PM Marc Rochkind wrote: > >> I mentioned a few weeks ago that I was writing this invited paper for an >> upcoming 50-year anniversary of the first issue of IEEE Transactions on >> Software Engineering. >> >> The paper has now been accepted for publication and here's a preprint >> version of it: >> >> https://www.mrochkind.com/mrochkind/docs/SCCSretro2.pdf >> >> Marc >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Jan 9 03:15:58 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 8 Jan 2025 12:15:58 -0500 Subject: [TUHS] "/bin/sh: the biggest Unix security loophole" Message-ID: I have sent a scan of Jim Reeds's 1984 technical memorandum on Bourne-shell security risks to Warren Toomey for posting in the TUHS archives. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Jan 9 06:58:29 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Thu, 9 Jan 2025 06:58:29 +1000 Subject: [TUHS] "/bin/sh: the biggest Unix security loophole" In-Reply-To: References: Message-ID: <9f184736-5140-4100-8757-c04282a62d4c@tuhs.org> On 9/1/25 03:15, Douglas McIlroy wrote: > I have sent a scan of Jim Reeds's 1984 technical memorandum on > Bourne-shell security risks to Warren Toomey for posting in the TUHS > archives. > > Doug It's now available at https://www.tuhs.org/Archive/Documentation/TechReports/Bell_Labs/ReedsShellHoles.pdf Thanks Doug! Cheers,       Warren From mrochkind at gmail.com Thu Jan 9 07:57:39 2025 From: mrochkind at gmail.com (Marc Rochkind) Date: Wed, 8 Jan 2025 14:57:39 -0700 Subject: [TUHS] "/bin/sh: the biggest Unix security loophole" In-Reply-To: <9f184736-5140-4100-8757-c04282a62d4c@tuhs.org> References: <9f184736-5140-4100-8757-c04282a62d4c@tuhs.org> Message-ID: Very interesting and readable paper! No way systems inferior to UNIX could get into such glorious levels of trouble. ;-) Marc On Wed, Jan 8, 2025 at 1:58 PM Warren Toomey via TUHS wrote: > On 9/1/25 03:15, Douglas McIlroy wrote: > > I have sent a scan of Jim Reeds's 1984 technical memorandum on > > Bourne-shell security risks to Warren Toomey for posting in the TUHS > > archives. > > > > Doug > > It's now available at > > https://www.tuhs.org/Archive/Documentation/TechReports/Bell_Labs/ReedsShellHoles.pdf > > Thanks Doug! > > Cheers, > > Warren > > -- Subscribe to my Photo-of-the-Week emails at my website mrochkind.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sat Jan 11 08:05:18 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 10 Jan 2025 23:05:18 +0100 Subject: [TUHS] Bell-Era UNIX Audio/DSP Interfaces? In-Reply-To: <20250106215143.b3Q14AL1@steffen%sdaoden.eu> References: <20250106215143.b3Q14AL1@steffen%sdaoden.eu> Message-ID: <20250110220518.r8yTvN4z@steffen%sdaoden.eu> P.S.: Steffen Nurpmeso wrote in <20250106215143.b3Q14AL1 at steffen%sdaoden.eu>: |segaloco via TUHS wrote in | : ||The sound situation in the UNIX world to me has always felt particularly ||fragmentary, with OSS offering some glimmer of hope but faltering under \ ||the long ||shadow of ALSA, with a hodge podge of PCM and other low level interfaces ||littered about other offerings. | |Oh, but *how* great it was when FreeBSD came on over with those |"virtual sound devices", in 4.7 or 4.9 i think it was. Ie instead |of one blocking device, one could open dev.1 and dev.2 and it was |multiplexed in the kernel. It did some format conversion in the |kernel alongside this. | |It was *fantastic*![.] For the younger and overall clarification. Around Y2K many programs -- audio players, but also early desktop environment "betas" of GNOME and KDE unless my memory fools me completely (i used such by then, at least at times, when not under FreeBSD cons25 or Linux then framebuffer!) -- had fixed paths built-in, for example /dev/dsp or /dev/pcm or /dev/audio or whatever it actually was (for real). There may have been multiple dev files, actually, ie, /dev/dsp1/2/3 etc, but the path was built-in, and it would not multiplex: if you opened /dev/dsp1 you had /dev/dsp1, but /dev/dsp and that thing was in use, and could not be used for any other purpose, at all. With the FreeBSD change program 1 could open "/dev/dsp", but 2 could open it, too, because it internally multiplexed to the virtual .1 .2 .3 etc. This was a tremendous improvement! --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) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear From tuhs at tuhs.org Mon Jan 13 15:11:21 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Mon, 13 Jan 2025 15:11:21 +1000 Subject: [TUHS] A Unix Code Walkthrough by Ken Thompson In-Reply-To: References: Message-ID: On Sun, Dec 29, 2024 at 07:40:15AM +1000, Warren Toomey via TUHS wrote: > Hi all, I've just received a set of MP3 recordings from Bob Kridle. He says: > > These are recordings of Ken Thompson doing a read through of one of > an early UNIX kernel code listing with a group of grad students at > UC Berkeley while he was a visiting prof. there. > > The date is roughly 1975. I've put the recordings here along with his > e-mails about the recordings: > > https://www.tuhs.org/Archive/Recordings/1975_Unix_Code_Walkthru/ Eric Allman has kindly supplied a scan of the source code that ken provided for the walkthrough. I've added it to the above location. It's interesting in that there are comments at the start of each function - the existing 5th Edition code that we have does not have these comments. Cheers & thanks Eric! Warren From jsg at jsg.id.au Mon Jan 13 16:23:11 2025 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 13 Jan 2025 17:23:11 +1100 Subject: [TUHS] A Unix Code Walkthrough by Ken Thompson In-Reply-To: References: Message-ID: On Mon, Jan 13, 2025 at 03:11:21PM +1000, Warren Toomey via TUHS wrote: > On Sun, Dec 29, 2024 at 07:40:15AM +1000, Warren Toomey via TUHS wrote: > > Hi all, I've just received a set of MP3 recordings from Bob Kridle. He says: > > > > These are recordings of Ken Thompson doing a read through of one of > > an early UNIX kernel code listing with a group of grad students at > > UC Berkeley while he was a visiting prof. there. > > > > The date is roughly 1975. I've put the recordings here along with his > > e-mails about the recordings: > > > > https://www.tuhs.org/Archive/Recordings/1975_Unix_Code_Walkthru/ > > Eric Allman has kindly supplied a scan of the source code that ken > provided for the walkthrough. I've added it to the above location. > It's interesting in that there are comments at the start of each > function - the existing 5th Edition code that we have does not > have these comments. With alloc.c the comments are there in v6 and the copyright line removal matches the changes between v5 and v6. The code appears to be somewhere between v6 and the "50 changes" tape described by Mike O'Brien in: Applications/Spencer_Tapes/unsw3.tar.gz usr/sys/v6unix/changenotes Some of the pages are dated 1976, and sysent[] on p 87 has post v6 system calls: access(), alarm(), pause(). Thanks to all involved for making this available.