From dave at horsfall.org Tue Feb 11 07:00:39 2025 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 11 Feb 2025 08:00:39 +1100 (AEDT) Subject: [TUHS] In some cults... Message-ID: ... it is possible to kill a person if you know his true name. I'm trying to find the origin of that phrase (which I've likely mangled); V5 or thereabouts? -- Dave From stewart at serissa.com Tue Feb 11 07:09:59 2025 From: stewart at serissa.com (Lawrence Stewart) Date: Mon, 10 Feb 2025 16:09:59 -0500 Subject: [TUHS] In some cults... In-Reply-To: References: Message-ID: <12BE330F-A47D-49C4-88F2-9CB8CDB2EB2A@serissa.com> > On Feb 10, 2025, at 16:00, Dave Horsfall wrote: > > ... it is possible to kill a person if you know his true name. > > I'm trying to find the origin of that phrase (which I've likely mangled); > V5 or thereabouts? > > —Dave Here’s a stackexchange page about it. https://literature.stackexchange.com/questions/1724/where-did-the-idea-of-a-true-name-come-from From crossd at gmail.com Tue Feb 11 07:56:45 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 10 Feb 2025 16:56:45 -0500 Subject: [TUHS] In some cults... In-Reply-To: <12BE330F-A47D-49C4-88F2-9CB8CDB2EB2A@serissa.com> References: <12BE330F-A47D-49C4-88F2-9CB8CDB2EB2A@serissa.com> Message-ID: On Mon, Feb 10, 2025 at 4:10 PM Lawrence Stewart wrote: > > On Feb 10, 2025, at 16:00, Dave Horsfall wrote: > > ... it is possible to kill a person if you know his true name. > > > > I'm trying to find the origin of that phrase (which I've likely mangled); > > V5 or thereabouts? > > Here’s a stackexchange page about it. > > https://literature.stackexchange.com/questions/1724/where-did-the-idea-of-a-true-name-come-from Meta note: I think Dave meant a quote in a comment in Unix somewhere, not the origin of the True Name myth. :-) - Dan C. From fair-tuhs at netbsd.org Tue Feb 11 08:14:22 2025 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Mon, 10 Feb 2025 14:14:22 -0800 Subject: [TUHS] In some cults... In-Reply-To: <12BE330F-A47D-49C4-88F2-9CB8CDB2EB2A@serissa.com> References: Message-ID: <13592.1739225662@cesium.clock.org> Shriekback - "Gunning for the Buddha" https://www.youtube.com/watch?v=WLG92w1SfqI https://www.dailybuddhism.com/archives/670 Erik From tuhs at tuhs.org Tue Feb 11 08:22:46 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 10 Feb 2025 22:22:46 +0000 Subject: [TUHS] In some cults... In-Reply-To: <13592.1739225662@cesium.clock.org> References: <13592.1739225662@cesium.clock.org> Message-ID: On Monday, February 10th, 2025 at 2:14 PM, Erik E. Fair wrote: > Shriekback - "Gunning for the Buddha" https://www.youtube.com/watch?v=WLG92w1SfqI > > https://www.dailybuddhism.com/archives/670 > > Erik Looks to be ps(I) introduced in V4: https://www.tuhs.org/cgi-bin/utree.pl?file=V4/man/man1/ps.1 The quote is describing the fields printed, among them: "The process unique number (as in certain cults it is possible to kill a process if you know its true name)." - Matt G. From reed at reedmedia.net Tue Feb 11 08:27:46 2025 From: reed at reedmedia.net (Jeremy C. Reed) Date: Mon, 10 Feb 2025 22:27:46 +0000 (UTC) Subject: [TUHS] In some cults... In-Reply-To: References: Message-ID: <357d90a5-4e4f-3739-82e6-911030641e20@reedmedia.net> On Tue, 11 Feb 2025, Dave Horsfall wrote: > ... it is possible to kill a person if you know his true name. > > I'm trying to find the origin of that phrase (which I've likely mangled); > V5 or thereabouts? v5 ps manual (v5man.pdf page 94) The process unique number (as in certain cults it is possible to kill a process if you know its true name). v7 usr/man/man1/ps.1 .TP PID The process ID of the process; as in certain cults it is possible to kill a process if you know its true name. From dave at horsfall.org Tue Feb 11 16:12:15 2025 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 11 Feb 2025 17:12:15 +1100 (AEDT) Subject: [TUHS] In some cults... In-Reply-To: References: <12BE330F-A47D-49C4-88F2-9CB8CDB2EB2A@serissa.com> Message-ID: <6ceefa9a-f29f-7e85-b4a3-37775c6a3d52@horsfall.org> On Mon, 10 Feb 2025, Dan Cross wrote: > Meta note: I think Dave meant a quote in a comment in Unix somewhere, > not the origin of the True Name myth. :-) And you win the lollipop :-) 'Twas the "ps(1)" command... -- Dave From jpl.jpl at gmail.com Tue Feb 11 21:15:59 2025 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 11 Feb 2025 06:15:59 -0500 Subject: [TUHS] In some cults... In-Reply-To: <6ceefa9a-f29f-7e85-b4a3-37775c6a3d52@horsfall.org> References: <12BE330F-A47D-49C4-88F2-9CB8CDB2EB2A@serissa.com> <6ceefa9a-f29f-7e85-b4a3-37775c6a3d52@horsfall.org> Message-ID: On Tue, Feb 11, 2025 at 1:12 AM Dave Horsfall wrote: > On Mon, 10 Feb 2025, Dan Cross wrote: > > > Meta note: I think Dave meant a quote in a comment in Unix somewhere, > > not the origin of the True Name myth. :-) > > And you win the lollipop :-) 'Twas the "ps(1)" command... > > -- Dave > On a faux-cultural note, Arthur C Clark wrote the "Nine Billion Names of God" in the 50s. When you got all 9 billion names, EVERYBODY got killed. 9 billion would have been more than adequate to hit all possible process IDs. -- jpl -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Wed Feb 12 02:05:25 2025 From: norman at oclsc.org (Norman Wilson) Date: Tue, 11 Feb 2025 11:05:25 -0500 (EST) Subject: [TUHS] In some cults... Message-ID: John P. Linderman (not the JPL in Altadena): On a faux-cultural note, Arthur C Clark wrote the "Nine Billion Names of God" in the 50s. === Ken wishes he'd spelled it Clarke, as the author did. Norman Wilson Toronto ON From g.branden.robinson at gmail.com Wed Feb 12 04:15:16 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 11 Feb 2025 12:15:16 -0600 Subject: [TUHS] In some cults... In-Reply-To: References: Message-ID: <20250211181516.uz6hc53sodb3jxs2@illithid> At 2025-02-11T11:05:25-0500, Norman Wilson wrote: > John P. Linderman (not the JPL in Altadena): > > On a faux-cultural note, Arthur C Clark wrote the "Nine Billion > Names of God" in the 50s. > > === > > Ken wishes he'd spelled it Clarke, as the author did. So you're saying "Clarke" is like "create()"... I surmis that Ken was on a wortwhil cours to mak the English languag simpl. W should declin to writ the ultimat "e" in a word everywher possibl. 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 rik at rikfarrow.com Wed Feb 12 04:18:45 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Tue, 11 Feb 2025 11:18:45 -0700 Subject: [TUHS] In some cults... In-Reply-To: <20250211181516.uz6hc53sodb3jxs2@illithid> References: <20250211181516.uz6hc53sodb3jxs2@illithid> Message-ID: On Tue, Feb 11, 2025 at 11:15 AM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2025-02-11T11:05:25-0500, Norman Wilson wrote: > > John P. Linderman (not the JPL in Altadena): > > > > On a faux-cultural note, Arthur C Clark wrote the "Nine Billion > > Names of God" in the 50s. > > > > === > > > > Ken wishes he'd spelled it Clarke, as the author did. > > So you're saying "Clarke" is like "create()"... > > I surmis that Ken was on a wortwhil cours to mak the English languag > simpl. W should declin to writ the ultimat "e" in a word everywher > possibl. > After reading the thread about how Doug McIlroy learned how to compress the spell dictionary, I stopped wondering about why it was creat()... Rik -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 12 05:33:19 2025 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 12 Feb 2025 06:33:19 +1100 (AEDT) Subject: [TUHS] In some cults... In-Reply-To: References: <12BE330F-A47D-49C4-88F2-9CB8CDB2EB2A@serissa.com> <6ceefa9a-f29f-7e85-b4a3-37775c6a3d52@horsfall.org> Message-ID: On Tue, 11 Feb 2025, John P. Linderman wrote: > On a faux-cultural note, Arthur C Clark wrote the "Nine Billion Names of > God" in the 50s. When you got all 9 billion names, EVERYBODY got killed. > 9 billion would have been more than adequate to hit all possible process > IDs. -- jpl And a great story too; read it :-) -- Dave, who hopes the stars won't go out... From steffen at sdaoden.eu Wed Feb 12 07:21:32 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 11 Feb 2025 22:21:32 +0100 Subject: [TUHS] In some cults... In-Reply-To: References: <12BE330F-A47D-49C4-88F2-9CB8CDB2EB2A@serissa.com> <6ceefa9a-f29f-7e85-b4a3-37775c6a3d52@horsfall.org> Message-ID: <20250211212132.avrinvHj@steffen%sdaoden.eu> segaloco via TUHS wrote in : |On Monday, February 10th, 2025 at 2:14 PM, Erik E. Fair wrote: |> Shriekback - "Gunning for the Buddha" https://www.youtube.com/watch?v=WL\ |> G92w1SfqI |> |> https://www.dailybuddhism.com/archives/670 |> |> Erik | |Looks to be ps(I) introduced in V4: https://www.tuhs.org/cgi-bin/utree.p\ |l?file=V4/man/man1/ps.1 | |The quote is describing the fields printed, among them: | |"The process unique number (as in certain cults it is possible to kill \ |a process if you know its true name)." Dave Horsfall wrote in : |On Tue, 11 Feb 2025, John P. Linderman wrote: | |> On a faux-cultural note, Arthur C Clark wrote the "Nine Billion Names of |> God" in the 50s. When you got all 9 billion names, EVERYBODY got killed. |> 9 billion would have been more than adequate to hit all possible process |> IDs. -- jpl | |And a great story too; read it :-) | |-- Dave, who hopes the stars won't go out... Now, then, with this, i have to. I cannot give the real source of the quote (someone may know it!!), but a buddhistic teacher told his scholars ~"When they slice you in pieces, suffer in silence." This (surely, definitely) referred to Lingchi, and the honest and innocent soul surely adhered to the teacher's advice. --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 steffen at sdaoden.eu Wed Feb 12 07:45:13 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 11 Feb 2025 22:45:13 +0100 Subject: [TUHS] In some cults... In-Reply-To: <20250211212132.avrinvHj@steffen%sdaoden.eu> References: <12BE330F-A47D-49C4-88F2-9CB8CDB2EB2A@serissa.com> <6ceefa9a-f29f-7e85-b4a3-37775c6a3d52@horsfall.org> <20250211212132.avrinvHj@steffen%sdaoden.eu> Message-ID: <20250211214513.vWiFJ9Ep@steffen%sdaoden.eu> Steffen Nurpmeso wrote in <20250211212132.avrinvHj at steffen%sdaoden.eu>: |segaloco via TUHS wrote in | : ||On Monday, February 10th, 2025 at 2:14 PM, Erik E. Fair wrote: ||> Shriekback - "Gunning for the Buddha" https://www.youtube.com/watch?v=WL\ ||> \ ||> G92w1SfqI ||> ||> https://www.dailybuddhism.com/archives/670 ... ||-- Dave, who hopes the stars won't go out... ... |Now, then, with this, i have to. |I cannot give the real source of the quote (someone may know |it!!), but a buddhistic teacher told his scholars ~"When they |slice you in pieces, suffer in silence." This (surely, |definitely) referred to Lingchi, and the honest and innocent soul |surely adhered to the teacher's advice. Ie .. it is likely that master Linji quoted by the linked page from Erik Fair is the namesake for Lingchi (from my superficial western point of understanding), and that very likely "milks the transcendency out of every being", and, likely, can kill Buddha. (Some lucky get around the actual thing, like the German Jesuit who reformed the Chinese calendar [1], he then died by natural causes one year thereafter, may his soul rest in heavenly peace. Now that also was in 1666, which is three times six, hm-hm-hm, but only to mention it.) [1] https://en.wikipedia.org/wiki/Johann_Adam_Schall_von_Bell --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 jpl.jpl at gmail.com Wed Feb 12 10:03:14 2025 From: jpl.jpl at gmail.com (John P. Linderman) Date: Tue, 11 Feb 2025 19:03:14 -0500 Subject: [TUHS] In some cults... In-Reply-To: <20250211181516.uz6hc53sodb3jxs2@illithid> References: <20250211181516.uz6hc53sodb3jxs2@illithid> Message-ID: On Tue, Feb 11, 2025 at 1:15 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2025-02-11T11:05:25-0500, Norman Wilson wrote: > > John P. Linderman (not the JPL in Altadena): > > > > On a faux-cultural note, Arthur C Clark wrote the "Nine Billion > > Names of God" in the 50s. > > > > === > > > > Ken wishes he'd spelled it Clarke, as the author did. > > So you're saying "Clarke" is like "create()"... > > I surmis that Ken was on a wortwhil cours to mak the English languag > simpl. W should declin to writ the ultimat "e" in a word everywher > possibl. > > Regards, > Branden > The e was not only silent, it was invisible. Except to those who are exceptionally ... -- jpl -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 12 10:48:35 2025 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 12 Feb 2025 11:48:35 +1100 (AEDT) Subject: [TUHS] In some cults... In-Reply-To: References: <20250211181516.uz6hc53sodb3jxs2@illithid> Message-ID: <8ed202a1-2e5a-3013-4715-97579b1d31aa@horsfall.org> On Tue, 11 Feb 2025, John P. Linderman wrote: > The e was not only silent, it was invisible. Except to those who are > exceptionally ... -- jpl Silent, like the "p" in swimming? :-) -- Dave From kenbob at gmail.com Wed Feb 12 10:57:46 2025 From: kenbob at gmail.com (Ken Thompson) Date: Tue, 11 Feb 2025 16:57:46 -0800 Subject: [TUHS] In some cults... In-Reply-To: References: <20250211181516.uz6hc53sodb3jxs2@illithid> Message-ID: dam wright On Tue, Feb 11, 2025 at 4:10 PM John P. Linderman wrote: > > > On Tue, Feb 11, 2025 at 1:15 PM G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > >> At 2025-02-11T11:05:25-0500, Norman Wilson wrote: >> > John P. Linderman (not the JPL in Altadena): >> > >> > On a faux-cultural note, Arthur C Clark wrote the "Nine Billion >> > Names of God" in the 50s. >> > >> > === >> > >> > Ken wishes he'd spelled it Clarke, as the author did. >> >> So you're saying "Clarke" is like "create()"... >> >> I surmis that Ken was on a wortwhil cours to mak the English languag >> simpl. W should declin to writ the ultimat "e" in a word everywher >> possibl. >> >> Regards, >> Branden >> > > The e was not only silent, it was invisible. Except to those who are > exceptionally ... -- jpl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Feb 12 11:55:53 2025 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Wed, 12 Feb 2025 07:25:53 +0530 Subject: [TUHS] In some cults... In-Reply-To: References: <20250211181516.uz6hc53sodb3jxs2@illithid> Message-ID: <0024997C-8441-4F22-BE61-9749B137B3B7@iitbombay.org> On Feb 12, 2025, at 5:33 AM, John P. Linderman wrote: > > The e was not only silent, it was invisible. Except to those who are exceptionally ... Sounds like the first sentence of a sci-fi story.... From norman at oclsc.org Wed Feb 12 12:10:29 2025 From: norman at oclsc.org (Norman Wilson) Date: Tue, 11 Feb 2025 21:10:29 -0500 (EST) Subject: [TUHS] In some cults... Message-ID: Dave Horsfall: Silent, like the "p" in swimming? :-) === Not at all the same. Unix smelled much better than its competitors in the 1970s and 1980s. Norman Wilson Toronto ON From dave at horsfall.org Wed Feb 12 14:42:38 2025 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 12 Feb 2025 15:42:38 +1100 (AEDT) Subject: [TUHS] In some cults... In-Reply-To: References: Message-ID: <1de2aae9-291a-00cf-0159-555956345652@horsfall.org> On Tue, 11 Feb 2025, Norman Wilson wrote: > Dave Horsfall: > > Silent, like the "p" in swimming? :-) > > === > > Not at all the same. Unix smelled much better than its competitors in > the 1970s and 1980s. Don't get me wrong; I still remember RSX-11 and RSTS etc... Although RT-11 wasn't too bad (I used to be a contract programmer in my CompSci days). Heck, there was PICK (anyone remember Dick Pick?), and BOS... -- Dave From g.branden.robinson at gmail.com Thu Feb 13 11:21:07 2025 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Wed, 12 Feb 2025 19:21:07 -0600 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: <6jefoqbmf6fwzjjvonee7npjvpvwayksydqjcouijbfufipn4z@adrjauck4ov4> Message-ID: <20250213012107.urh4ndk4tnnzm3wx@illithid> [looping in TUHS so my historical mistakes can be corrected] Hi Alex, At 2025-02-13T00:59:33+0100, Alejandro Colomar wrote: > Just wondering... why not build a new PDF from source, instead of > scanning the book? A. I don't think we know for sure which version of troff was used to format the V10 manual. _Probably_ Kernighan's research version, which was similar to a contemporaneous DWB troff...but what "contemporaneous" means in the 1989-1990 period is a little fuzzy. Also, Kernighan may not have a complete source history of his version of troff, it is presumably still encumbered by AT&T copyrights, and he's been using groff for at least his last two books (his Unix memoir and the 2nd edition of the AWK book). B. It is hard to recreate a Research Unix V10 installation. My understanding is that Unix V8-V10 were not full distributions but patches. And because troff was commercial/proprietary software at that (the aforementioned DWB troff), I don't know if Kernighan's "Research troff" escaped Bell Labs or how consistently it could be expected to be present on a system. Presumably any of a variety of DWB releases would have "worked fine". How much they would have varied in extremely fiddly details of typesetting is an open question. I can say with some confidence that the mm package saw fairly significant development. Of troff itself (and the preprocessors one bumps into in the Volume 2 white papers) I'm much more in the dark. C. Getting a scan out there tells us at least what one software configuration deemed acceptable by producers of the book generated, even if it's impossible to identify details of that software configuration. That in turn helps us to judge the results of _known_ software configurations--groff, and other troffs too. D. troff is not TeX. Nothing like trip.tex has ever existed. A golden platonic ideal of formatter behavior does not exist except in the collective, sometimes contentious minds of its users. > Doesn't groff(1) handle the Unix sources? Assuming the full source of a document is available, and no part of its toolchain requires software that is unavailable (like Van Wyk's "ideal" preprocessor) then if groff cannot satisfactorily render a document produced by the Bell Labs CSRC, then I'd consider that presumptively a bug in groff. It's a rebuttable presumption--if one document in one place relied upon a _bug_ in AT&T troff to produce correct rendering, I think my inclination would be to annotate the problem somewhere in groff's documentation and leave it unresolved. For a case where groff formats a classic Unix document "better" (in the sense of not unintentionally omitting a formatted equation) than AT&T troff, see the following. https://github.com/g-branden-robinson/retypesetting-mathematics > I expect the answer is not licenses (because I expect redistributing > the scanned original will be as bad as generating an apocryphal PDF in > terms of licensing). I've opined before that the various aspects of Unix "IP" ownership appear to be so complicated and mired in the details of decades-old contracts in firms that have changed ownership structures multiple times, that legally valid answers to questions like this may not exist. Not until a firm that thinks it holds the rights decides it's worth the money to pay a bunch of archivists and copyright attorneys to go on a snipe hunt. And that decision won't be made unless said firm thinks the probability is high that they can recover damages from infringers in excess of their costs. Otherwise the decision simply sets fire to a pile of money. ...which isn't impossible. Billionaires do it every day. > I sometimes wondered if I should run the Linux man-pages build system > on the sources of Unix manual pages to generate an apocryphal PDF book > of Volume 1 of the different Unix systems. I never ended up doing so > for fear of AT&T lawyers (or whoever owns the rights to their manuals > today), but I find it would be useful. It's the kind of thing I've thought about doing. :) If you do, I very much want to know if groff appears to misbehave. 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 lm at mcvoy.com Thu Feb 13 11:45:22 2025 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 12 Feb 2025 17:45:22 -0800 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: <20250213012107.urh4ndk4tnnzm3wx@illithid> References: <6jefoqbmf6fwzjjvonee7npjvpvwayksydqjcouijbfufipn4z@adrjauck4ov4> <20250213012107.urh4ndk4tnnzm3wx@illithid> Message-ID: <20250213014522.GF31438@mcvoy.com> On Wed, Feb 12, 2025 at 07:21:07PM -0600, G. Branden Robinson wrote: > > Doesn't groff(1) handle the Unix sources? > > Assuming the full source of a document is available, and no part of its > toolchain requires software that is unavailable (like Van Wyk's "ideal" > preprocessor) then if groff cannot satisfactorily render a document > produced by the Bell Labs CSRC, then I'd consider that presumptively a > bug in groff. In my experience, groff has handled decades old troff source and done a great job. I'd not be surprised if there was something that didn't work, but the vast majority of the stuff I've tried has worked just fine. --lm From norman at oclsc.org Thu Feb 13 11:52:45 2025 From: norman at oclsc.org (Norman Wilson) Date: Wed, 12 Feb 2025 20:52:45 -0500 (EST) Subject: [TUHS] Unix V10 Volume 2 PDFs Message-ID: For the non-TUHS folks who don't know me, I worked in Center 1127 (the Bell Labs Computing Science Research Center) 1984-1990, and had some hand in 9th and 10th Edition Manuals and what passed for the V8-V10 `distributions.' To answer Branden's points: A. I do know what version of troff was used to typeset the 8th through 10th Edition manuals. It was the version we were using in 1127 at the time, which was indeed Kernighan's. The macro packages probably matter more than the particular troff edition. For the 10th Edition (which files I have at hand), there was an individual mkfile (mk(1)) for each paper, so in principle there was no fixed formatting package, but in practice everything appears to have used troff -mpm, with various preprocessors according the paper: prefer, tbl, pic, ideal, and in some cases additional macros and even odds and ends of sed and awk. If you wanted to re-render things from scratch you'd want all the tools. But if you have the real troff sources you'll have all the mkfiles--things were stored one paper per directory. -mpm (mpm(6) in 10/e vol 1) was a largely ms-compatible package with special expertise in page layout. B. There was no such thing as a `release' after V7. In fall 1984 we made a single V8 snapshot. Making that involved a lot of fiddly work, because we didn't normally try to build systems from scratch; when we brought in a new computer we cloned it from an existing one. So there was lots of fiddly work to make sure every program in /bin and /usr/bin on the tape compiled correctly from the source code that would be on the tape when the cc and as and ld and libraries on the tape were used. We sent V8 tapes to about a dozen external places, few of which did anything with it (many probably never even installed it). Which makes sense, by then we really weren't a central source for Unix even within AT&T, let alone to the world. Neither did we want the support burden that would have carried--the group's charter was research, after all, not software support. So the 9th and 10th editions existed as manuals, but not as releases. We did occasionally make one-off snapshots for other parts of AT&T, and maybe for a university or two. (I definitely remember taking a snapshot to help the official AT&T System N Unix people set up a Research system at one point, and have a vague memory that I may have carried a tape to a university under a special one-off license letter.) On the other hand, troff wasn't a rapid moving target, and unlike the stars of the modern software world, we tried not to break things unless there was a real reason to do so. So I suspect the troff from any system of that era would render the Volume 2 papers properly, and am all but certain the 10th-edition-era troff would do so even for older manuals. C. Just to be clear, the official 10th Edition manuals published by Saunders College Publishing were made from camera-ready copy prepared by us in 1127 (Doug McIlroy did all the final work, I think) and printed on our phototypesetter. We didn't ship them troff source, nor even Postscript. We did everything including the tables of contents and indexes and page numbering. D. troff is indeed not TeX, and some of us think of that as a feature, not a bug. I think the odds are fairly good (but not 100%) that groff would do a reasonable job of rendering the papers; as I said, the hard part is the macro packages. I'm not sure -mpm ever made it out of Research. And there are probably copyright issues not just with the software but with the papers themselves. The published manuals bear a copyright notice, after all. Norman Wilson Toronto ON (A much nicer place than suburban NJ, which is why I left the Labs when I did) From robpike at gmail.com Thu Feb 13 12:34:50 2025 From: robpike at gmail.com (Rob Pike) Date: Thu, 13 Feb 2025 13:34:50 +1100 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: References: Message-ID: Doug was part of the story but the 10th edition manual was mostly my effort to herd the cats into production, including finding and working with the publisher. -rob On Thu, Feb 13, 2025 at 12:52 PM Norman Wilson wrote: > For the non-TUHS folks who don't know me, I worked in > Center 1127 (the Bell Labs Computing Science Research > Center) 1984-1990, and had some hand in 9th and 10th > Edition Manuals and what passed for the V8-V10 > `distributions.' > > To answer Branden's points: > > A. I do know what version of troff was used to typeset > the 8th through 10th Edition manuals. It was the version > we were using in 1127 at the time, which was indeed > Kernighan's. The macro packages probably matter more > than the particular troff edition. > > For the 10th Edition (which files I have at hand), there > was an individual mkfile (mk(1)) for each paper, so > in principle there was no fixed formatting package, > but in practice everything appears to have used troff -mpm, > with various preprocessors according the paper: prefer, > tbl, pic, ideal, and in some cases additional macros and even > odds and ends of sed and awk. > > If you wanted to re-render things from scratch you'd > want all the tools. But if you have the real troff > sources you'll have all the mkfiles--things were stored > one paper per directory. > > -mpm (mpm(6) in 10/e vol 1) was a largely ms-compatible > package with special expertise in page layout. > > B. There was no such thing as a `release' after V7. > In fall 1984 we made a single V8 snapshot. Making > that involved a lot of fiddly work, because we didn't > normally try to build systems from scratch; when we > brought in a new computer we cloned it from an existing > one. So there was lots of fiddly work to make sure > every program in /bin and /usr/bin on the tape compiled > correctly from the source code that would be on the tape > when the cc and as and ld and libraries on the tape were > used. > > We sent V8 tapes to about a dozen external places, few > of which did anything with it (many probably never even > installed it). Which makes sense, by then we really > weren't a central source for Unix even within AT&T, let > alone to the world. Neither did we want the support > burden that would have carried--the group's charter was > research, after all, not software support. So the 9th > and 10th editions existed as manuals, but not as releases. > We did occasionally make one-off snapshots for other parts > of AT&T, and maybe for a university or two. (I definitely > remember taking a snapshot to help the official AT&T System N > Unix people set up a Research system at one point, and have > a vague memory that I may have carried a tape to a university > under a special one-off license letter.) > > On the other hand, troff wasn't a rapid moving target, and > unlike the stars of the modern software world, we tried not > to break things unless there was a real reason to do so. > So I suspect the troff from any system of that era would > render the Volume 2 papers properly, and am all but certain > the 10th-edition-era troff would do so even for older manuals. > > C. Just to be clear, the official 10th Edition manuals > published by Saunders College Publishing were made from > camera-ready copy prepared by us in 1127 (Doug McIlroy > did all the final work, I think) and printed on our > phototypesetter. We didn't ship them troff source, nor > even Postscript. We did everything including the tables > of contents and indexes and page numbering. > > D. troff is indeed not TeX, and some of us think of that > as a feature, not a bug. > > I think the odds are fairly good (but not 100%) that > groff would do a reasonable job of rendering the papers; > as I said, the hard part is the macro packages. I'm > not sure -mpm ever made it out of Research. > > And there are probably copyright issues not just with > the software but with the papers themselves. The published > manuals bear a copyright notice, after all. > > Norman Wilson > Toronto ON > (A much nicer place than suburban NJ, which is why > I left the Labs when I did) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Feb 13 12:45:49 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 12 Feb 2025 21:45:49 -0500 Subject: [TUHS] Unix V10 Volume 2 PDFs Message-ID: > My understanding is that Unix V8-V10 were not full distributions but patches. "Patch" connotes individually distributed small fixes, not complete working systems. I don't believe Brendan meant that v8 was only a patch on v7, but that's the natural interpretation of the statement. V8-v10 were snapshots, yes, possibly not perfectly in sync with the printed editions. But this was typical of Research editions, and especially of Volujme 2, which was originally called something like "Documents for Use with Unix". Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Feb 14 00:53:31 2025 From: crossd at gmail.com (Dan Cross) Date: Thu, 13 Feb 2025 09:53:31 -0500 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: References: Message-ID: On Thu, Feb 13, 2025 at 8:05 AM Norman Wilson wrote: >[snip] > -mpm (mpm(6) in 10/e vol 1) was a largely ms-compatible > package with special expertise in page layout. > > [snip] > > I think the odds are fairly good (but not 100%) that > groff would do a reasonable job of rendering the papers; > as I said, the hard part is the macro packages. I'm > not sure -mpm ever made it out of Research. If it's the one I'm thinking about, then it did make it out in drips and drabs on Plan 9; it was in the 1st and 2nd Edition distributions. However, to be used to its full effect, -mpm also required a postprocessor, called `pm`, which was written in C++ and built with cfront. Probably for that reason, it was not distributed with Plan 9 3rd edition or later (the later versions of Plan 9, available under an Open Source license, did not include cfront). All of the historical Plan 9 editions are now available under the MIT license and available for download from the Plan 9 Foundation. I just checked and it appears that mpm is in the tar archive for the 2nd edition; one can download that here: https://p9f.org/dl/index.html (It's probably in the tarball for the 1st edition too, but I didn't look.) Note that the source files for sys/src/cmd/pm are all named "whatever.c", but are C++ code in disguise. At one point I took a swing at trying to rewrite it in C, because the idea seemed cool, but other things took precedence and I never got back to it. I haven't tried to build it with a modern C++ compiler, but it probably wouldn't be _that_ much work for someone motivated to do so. - Dan C. From tuhs at tuhs.org Sat Feb 15 06:36:45 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 14 Feb 2025 20:36:45 +0000 Subject: [TUHS] The Case of UNIX vs. The UNIX System Message-ID: So in most technical circles and indeed in the research communities surrounding UNIX, the name of the system was just that, UNIX, prefixed often with some descriptor of which stream, be it Research, USG, BSD/Berkeley, but in any case the name UNIX itself was descriptive of the operating system for many of its acolytes and disciples. However, in AT&T literature and media, addition of "System" to the end of the formal name seemed to become de facto if not de jure. This can be seen for instance in manual edits in the early 80s with references to just "UNIX" being replaced with variations on "The UNIX System", sometimes haphazardly as if done via a search and replace with little review. This too is evident in some informative films published by AT&T, available on YouTube today as "The UNIX Operating System" and "UNIX: Making Computers Easier to Use"[1][2]. Discrepancies in the titles of the videos notwithstanding, throughout it seems there are several instances where audio of an interviewee saying "The UNIX System" were edited over what I presume were instances of them simply saying UNIX. I'm curious if anyone has the scoop on whether this was an attempt to echo the "One Bell System" and related terminology, marketing tag lines like "The System is the Solution", and/or the naming of the revisions themselves as "System ". On the other hand, could it have simply been for clarity, with the uninitiated not being able to glean from the product name anything about it, making the case for adding "System" in formal descriptions to give them a little bit of a hint. Bell Labs folks especially, was there ever some grand thou shalt call it "The UNIX System" in all PR directive or was it just something that organically happened over time as bureaucratic powers at be got their hands on a part of the steering wheel? - Matt G. [1] - https://www.youtube.com/watch?v=tc4ROCJYbm0 [2] - https://www.youtube.com/watch?v=XvDZLjaCJuw From brantley at coraid.com Sat Feb 15 06:40:35 2025 From: brantley at coraid.com (Brantley Coile) Date: Fri, 14 Feb 2025 20:40:35 +0000 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: Message-ID: <1C17A8F8-B8C2-40FA-B904-71416CF78876@coraid.com> UNIX is a trademark and as such, it's an adjective and needs a noun to go with it. Unix operating system is okay. Unix system is more descriptive. It's a intellectual property thing. Brantley > On Feb 14, 2025, at 3:36 PM, segaloco via TUHS wrote: > > So in most technical circles and indeed in the research communities surrounding > UNIX, the name of the system was just that, UNIX, prefixed often with some > descriptor of which stream, be it Research, USG, BSD/Berkeley, but in any case > the name UNIX itself was descriptive of the operating system for many of its > acolytes and disciples. > > However, in AT&T literature and media, addition of "System" to the end of the > formal name seemed to become de facto if not de jure. This can be seen for > instance in manual edits in the early 80s with references to just "UNIX" being > replaced with variations on "The UNIX System", sometimes haphazardly as if done > via a search and replace with little review. This too is evident in some > informative films published by AT&T, available on YouTube today as > "The UNIX Operating System" and "UNIX: Making Computers Easier to Use"[1][2]. > Discrepancies in the titles of the videos notwithstanding, throughout it seems > there are several instances where audio of an interviewee saying > "The UNIX System" were edited over what I presume were instances of them simply > saying UNIX. > > I'm curious if anyone has the scoop on whether this was an attempt to echo the > "One Bell System" and related terminology, marketing tag lines like > "The System is the Solution", and/or the naming of the revisions themselves as > "System ". On the other hand, could it have simply been for clarity, with > the uninitiated not being able to glean from the product name anything about it, > making the case for adding "System" in formal descriptions to give them a little > bit of a hint. > > Bell Labs folks especially, was there ever some grand thou shalt call it > "The UNIX System" in all PR directive or was it just something that organically > happened over time as bureaucratic powers at be got their hands on a part of the > steering wheel? > > - Matt G. > > [1] - https://www.youtube.com/watch?v=tc4ROCJYbm0 > [2] - https://www.youtube.com/watch?v=XvDZLjaCJuw From rik at rikfarrow.com Sat Feb 15 06:57:08 2025 From: rik at rikfarrow.com (Rik Farrow) Date: Fri, 14 Feb 2025 13:57:08 -0700 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: <1C17A8F8-B8C2-40FA-B904-71416CF78876@coraid.com> References: <1C17A8F8-B8C2-40FA-B904-71416CF78876@coraid.com> Message-ID: You've got that right, although I learned that from a different perspective. A Unix magazine I contracted for was contacted more than once by AT&T legal saying "Unix" is an adjective, not a noun. I didn't know about the connection with copyright. Rik On Fri, Feb 14, 2025 at 1:40 PM Brantley Coile wrote: > UNIX is a trademark and as such, it's an adjective and needs a noun to go > with it. Unix operating system is okay. Unix system is more descriptive. > It's a intellectual property thing. > > Brantley > > > On Feb 14, 2025, at 3:36 PM, segaloco via TUHS wrote: > > > > So in most technical circles and indeed in the research communities > surrounding > > UNIX, the name of the system was just that, UNIX, prefixed often with > some > > descriptor of which stream, be it Research, USG, BSD/Berkeley, but in > any case > > the name UNIX itself was descriptive of the operating system for many of > its > > acolytes and disciples. > > > > However, in AT&T literature and media, addition of "System" to the end > of the > > formal name seemed to become de facto if not de jure. This can be seen > for > > instance in manual edits in the early 80s with references to just "UNIX" > being > > replaced with variations on "The UNIX System", sometimes haphazardly as > if done > > via a search and replace with little review. This too is evident in some > > informative films published by AT&T, available on YouTube today as > > "The UNIX Operating System" and "UNIX: Making Computers Easier to > Use"[1][2]. > > Discrepancies in the titles of the videos notwithstanding, throughout it > seems > > there are several instances where audio of an interviewee saying > > "The UNIX System" were edited over what I presume were instances of them > simply > > saying UNIX. > > > > I'm curious if anyone has the scoop on whether this was an attempt to > echo the > > "One Bell System" and related terminology, marketing tag lines like > > "The System is the Solution", and/or the naming of the revisions > themselves as > > "System ". On the other hand, could it have simply been for > clarity, with > > the uninitiated not being able to glean from the product name anything > about it, > > making the case for adding "System" in formal descriptions to give them > a little > > bit of a hint. > > > > Bell Labs folks especially, was there ever some grand thou shalt call it > > "The UNIX System" in all PR directive or was it just something that > organically > > happened over time as bureaucratic powers at be got their hands on a > part of the > > steering wheel? > > > > - Matt G. > > > > [1] - https://www.youtube.com/watch?v=tc4ROCJYbm0 > > [2] - https://www.youtube.com/watch?v=XvDZLjaCJuw > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuff at riddermarkfarm.ca Sat Feb 15 07:46:09 2025 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Fri, 14 Feb 2025 16:46:09 -0500 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: <1C17A8F8-B8C2-40FA-B904-71416CF78876@coraid.com> References: <1C17A8F8-B8C2-40FA-B904-71416CF78876@coraid.com> Message-ID: <7d97a0eb-8b70-b07d-b6fa-eef263f94e73@riddermarkfarm.ca> On 2025-02-14 15:40, Brantley Coile wrote: > UNIX is a trademark and as such, it's an adjective and needs a noun to go with it. Unix operating system is okay. Unix > system is more descriptive. It's a intellectual property thing. This is correct. UNIX is currently listed as a trademark of the Open Group in the USPTO (https://tsdr.uspto.gov/#caseNumber=87120150&caseSearchType=US_APPLICATION&caseType=DEFAULT&searchType=documentSearch) with the following statement: "The certification mark, as used by persons authorized by the certifier, certifies that the goods have met the specifications and standards identified in the certifier's Product Standard." Incidentally, if you search for unix, you find boatloads of Unix trademarks that have nothing to do with s/w (such as sunglasses, zippers, drawing instruments, ...) S. > > Brantley > >> On Feb 14, 2025, at 3:36 PM, segaloco via TUHS wrote: >> >> So in most technical circles and indeed in the research communities surrounding >> UNIX, the name of the system was just that, UNIX, prefixed often with some >> descriptor of which stream, be it Research, USG, BSD/Berkeley, but in any case >> the name UNIX itself was descriptive of the operating system for many of its >> acolytes and disciples. >> >> However, in AT&T literature and media, addition of "System" to the end of the >> formal name seemed to become de facto if not de jure. This can be seen for >> instance in manual edits in the early 80s with references to just "UNIX" being >> replaced with variations on "The UNIX System", sometimes haphazardly as if done >> via a search and replace with little review. This too is evident in some >> informative films published by AT&T, available on YouTube today as >> "The UNIX Operating System" and "UNIX: Making Computers Easier to Use"[1][2]. >> Discrepancies in the titles of the videos notwithstanding, throughout it seems >> there are several instances where audio of an interviewee saying >> "The UNIX System" were edited over what I presume were instances of them simply >> saying UNIX. >> >> I'm curious if anyone has the scoop on whether this was an attempt to echo the >> "One Bell System" and related terminology, marketing tag lines like >> "The System is the Solution", and/or the naming of the revisions themselves as >> "System ". On the other hand, could it have simply been for clarity, with >> the uninitiated not being able to glean from the product name anything about it, >> making the case for adding "System" in formal descriptions to give them a little >> bit of a hint. >> >> Bell Labs folks especially, was there ever some grand thou shalt call it >> "The UNIX System" in all PR directive or was it just something that organically >> happened over time as bureaucratic powers at be got their hands on a part of the >> steering wheel? >> >> - Matt G. >> >> [1] - https://www.youtube.com/watch?v=tc4ROCJYbm0 >> [2] - https://www.youtube.com/watch?v=XvDZLjaCJuw > From kenbob at gmail.com Sat Feb 15 08:45:54 2025 From: kenbob at gmail.com (Ken Thompson) Date: Fri, 14 Feb 2025 14:45:54 -0800 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: <1C17A8F8-B8C2-40FA-B904-71416CF78876@coraid.com> Message-ID: the bell labs legal vacillated between 1company private, 2 intellectual property 3 trademark. 1 is a secret, 2 is noun and 3 is an adjective. each change came with replacing a thousand notices in the code. On Fri, Feb 14, 2025 at 12:57 PM Rik Farrow wrote: > You've got that right, although I learned that from a different > perspective. A Unix magazine I contracted for was contacted more than once > by AT&T legal saying "Unix" is an adjective, not a noun. I didn't know > about the connection with copyright. > > Rik > > > On Fri, Feb 14, 2025 at 1:40 PM Brantley Coile > wrote: > >> UNIX is a trademark and as such, it's an adjective and needs a noun to go >> with it. Unix operating system is okay. Unix system is more descriptive. >> It's a intellectual property thing. >> >> Brantley >> >> > On Feb 14, 2025, at 3:36 PM, segaloco via TUHS wrote: >> > >> > So in most technical circles and indeed in the research communities >> surrounding >> > UNIX, the name of the system was just that, UNIX, prefixed often with >> some >> > descriptor of which stream, be it Research, USG, BSD/Berkeley, but in >> any case >> > the name UNIX itself was descriptive of the operating system for many >> of its >> > acolytes and disciples. >> > >> > However, in AT&T literature and media, addition of "System" to the end >> of the >> > formal name seemed to become de facto if not de jure. This can be seen >> for >> > instance in manual edits in the early 80s with references to just >> "UNIX" being >> > replaced with variations on "The UNIX System", sometimes haphazardly as >> if done >> > via a search and replace with little review. This too is evident in >> some >> > informative films published by AT&T, available on YouTube today as >> > "The UNIX Operating System" and "UNIX: Making Computers Easier to >> Use"[1][2]. >> > Discrepancies in the titles of the videos notwithstanding, throughout >> it seems >> > there are several instances where audio of an interviewee saying >> > "The UNIX System" were edited over what I presume were instances of >> them simply >> > saying UNIX. >> > >> > I'm curious if anyone has the scoop on whether this was an attempt to >> echo the >> > "One Bell System" and related terminology, marketing tag lines like >> > "The System is the Solution", and/or the naming of the revisions >> themselves as >> > "System ". On the other hand, could it have simply been for >> clarity, with >> > the uninitiated not being able to glean from the product name anything >> about it, >> > making the case for adding "System" in formal descriptions to give them >> a little >> > bit of a hint. >> > >> > Bell Labs folks especially, was there ever some grand thou shalt call it >> > "The UNIX System" in all PR directive or was it just something that >> organically >> > happened over time as bureaucratic powers at be got their hands on a >> part of the >> > steering wheel? >> > >> > - Matt G. >> > >> > [1] - https://www.youtube.com/watch?v=tc4ROCJYbm0 >> > [2] - https://www.youtube.com/watch?v=XvDZLjaCJuw >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sat Feb 15 08:47:33 2025 From: robpike at gmail.com (Rob Pike) Date: Sat, 15 Feb 2025 09:47:33 +1100 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: Message-ID: The lawyers insisted that Unix be upper case and only used as an adjective. Also, to attempt to make others go along, they applied the rule to other companies' trademarks too. At one point we were putting together a commemorative issue of the Bell Labs Technical Journal to include some old papers that would do well collected together, and the lawyers tried to edit the old papers to honor the new rules. Dennis objected furiously: their coinage of "PDP-11 computer system UNIX System file system" was multiple bridges too far. It was hard to rile Dennis, and eventually they realized this and pulled back. But sheesh, that was inane. "The UNIX Programming Environment" was the title of bwk's and my book, and that took some doing too. I spent literal years of my time at Bell Labs dealing with lawyers. Years. Only to have others tell me that I should have asked the lawyers to do something different, assuming I hadn't tried. It could make one cry in frustration. -rob On Sat, Feb 15, 2025 at 7:37 AM segaloco via TUHS wrote: > So in most technical circles and indeed in the research communities > surrounding > UNIX, the name of the system was just that, UNIX, prefixed often with some > descriptor of which stream, be it Research, USG, BSD/Berkeley, but in any > case > the name UNIX itself was descriptive of the operating system for many of > its > acolytes and disciples. > > However, in AT&T literature and media, addition of "System" to the end of > the > formal name seemed to become de facto if not de jure. This can be seen for > instance in manual edits in the early 80s with references to just "UNIX" > being > replaced with variations on "The UNIX System", sometimes haphazardly as if > done > via a search and replace with little review. This too is evident in some > informative films published by AT&T, available on YouTube today as > "The UNIX Operating System" and "UNIX: Making Computers Easier to > Use"[1][2]. > Discrepancies in the titles of the videos notwithstanding, throughout it > seems > there are several instances where audio of an interviewee saying > "The UNIX System" were edited over what I presume were instances of them > simply > saying UNIX. > > I'm curious if anyone has the scoop on whether this was an attempt to echo > the > "One Bell System" and related terminology, marketing tag lines like > "The System is the Solution", and/or the naming of the revisions > themselves as > "System ". On the other hand, could it have simply been for clarity, > with > the uninitiated not being able to glean from the product name anything > about it, > making the case for adding "System" in formal descriptions to give them a > little > bit of a hint. > > Bell Labs folks especially, was there ever some grand thou shalt call it > "The UNIX System" in all PR directive or was it just something that > organically > happened over time as bureaucratic powers at be got their hands on a part > of the > steering wheel? > > - Matt G. > > [1] - https://www.youtube.com/watch?v=tc4ROCJYbm0 > [2] - https://www.youtube.com/watch?v=XvDZLjaCJuw > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Feb 15 08:55:57 2025 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 14 Feb 2025 22:55:57 +0000 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: Message-ID: The lawyers insisted that Unix be upper case and only used as an adjective. That is required for trademarks. A trademark has to be an adjective describing a generic noun. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Feb 15 09:14:17 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 14 Feb 2025 23:14:17 +0000 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: Message-ID: <8xGmxcgzn7Cqbsa7mAb5ZKO7Kqpw6Cuz9g4qxuc-mjtgQuA9sBpJ5qLCxLgqSWWlFjSVMlfHK0DQFKINaTKKjvv_xpJO2n2ecN_J3FaDkk8=@protonmail.com> On Friday, February 14th, 2025 at 2:55 PM, Ron Natalie wrote: > The lawyers insisted that Unix be upper case and only used as an adjective. > > > That is required for trademarks. A trademark has to be an adjective describing a generic noun. I'm now reminded of Streams vs STREAMS. The current project I'm working on at work is similarly shouted when written despite internal references being an old crusty name in more natural casing that we all still use within the team. This is why I love the UNIX story, it helps me rationalize things in my day to day...or perhaps understand others rationale which is anything but to me... - Matt G. From robpike at gmail.com Sat Feb 15 09:16:19 2025 From: robpike at gmail.com (Rob Pike) Date: Sat, 15 Feb 2025 10:16:19 +1100 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: Message-ID: The adjective story is neither a fact nor a law codified by statute. It is just one approach lawyers use to try to prevent trademarks becoming generic. There are others. Also, I probably left some ™ markers out of the coinage I quoted. -rob On Sat, Feb 15, 2025 at 9:55 AM Ron Natalie wrote: > *The lawyers insisted that Unix be upper case and only used as an > adjective.* > > That is required for trademarks. A trademark has to be an adjective > describing a generic noun. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Sat Feb 15 10:38:56 2025 From: brantley at coraid.com (Brantley Coile) Date: Fri, 14 Feb 2025 19:38:56 -0500 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: Message-ID: <6EF9E7F7-F777-4FC3-8C5A-7A7F3DC6037F@coraid.com> An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sat Feb 15 23:11:44 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 15 Feb 2025 08:11:44 -0500 Subject: [TUHS] The Case of UNIX vs. The UNIX System Message-ID: Although I edited the v7 through v10 manuals, I have no recollection of why "system" crept into the title between v7 and v8. Resistance to trademark edicts did grow. In v10, the cover and the man pages proclaimed "Unix". However, the fossilized spelling, "UNIX", still appeared in the introduction to Volume 1 and scattered throughout Volume 2. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Sun Feb 16 04:51:55 2025 From: rich.salz at gmail.com (Rich Salz) Date: Sat, 15 Feb 2025 13:51:55 -0500 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: References: Message-ID: >However, to be used to its full effect, -mpm also required a > postprocessor, called `pm`, A troff post-processor? What did it do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Sun Feb 16 06:49:15 2025 From: robpike at gmail.com (Rob Pike) Date: Sun, 16 Feb 2025 07:49:15 +1100 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: Message-ID: And despite what I wrote before, I was confusing the Plan 9 printed manuals with the Unix v10 ones, perhaps because they both used the same publisher. I was not principal in the v10 books. Someone should start a mailing list so we can record the history for those who can't remember what happened or weren't there. -rob On Sun, Feb 16, 2025 at 12:12 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > Although I edited the v7 through v10 manuals, I have no recollection of > why "system" crept into the title between v7 and v8. Resistance to > trademark edicts did grow. In v10, the cover and the man pages proclaimed > "Unix". However, the fossilized spelling, "UNIX", still appeared in the > introduction to Volume 1 and scattered throughout Volume 2. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sun Feb 16 07:27:41 2025 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Sun, 16 Feb 2025 07:27:41 +1000 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: Message-ID: <603B528C-24C6-43EF-8107-09FA03662A5F@tuhs.org> On 16 February 2025 6:49:15 am AEST, Rob Pike wrote: >Someone should start a mailing list so we can record the history for those >who can't remember what happened or weren't there. > >-rob I might get around to doing that one day :-) -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From crossd at gmail.com Sun Feb 16 08:41:46 2025 From: crossd at gmail.com (Dan Cross) Date: Sat, 15 Feb 2025 17:41:46 -0500 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: References: Message-ID: On Sat, Feb 15, 2025 at 1:52 PM Rich Salz wrote: > >However, to be used to its full effect, -mpm also required a > > postprocessor, called `pm`, > > A troff post-processor? What did it do? As I understood it, it took directives embedded in troff's output and used those to perform better vertical justification and image layout, so that things like the page ends matched across facing pages in a printed book and so forth. Oh, I just realized that this _has_ been ported to modern machines. Perhaps ironically, it's part of plan9port, the port of (most of) plan9 to Unix: https://github.com/9fans/plan9port/tree/master/src/cmd/mpm A paper about it was in the Volume 2 of the 10th Ed manual; I was just looking to see if a PDF of that was floating around when I ran across this: https://archive.org/details/unixresearchsystemprogrammersmanualtentheditionfixed/mode/2up I'm not sure who this person is, but it seems like they've uploaded some cool stuff. https://archive.org/details/@yehudahamakabi Anyway, I didn't find a PDF of Vol2, but I did find this: https://github.com/Alhadis/Research-Unix-v10/tree/master/docs/vol2/pm (of course, the V10 source is available, but this is easy to grab). Running it through `groff -ms` gives output that's imperfect, but intelligible to get the main gist. Hmm, it doesn't seem to mention the post-processor at all; maybe that didn't come until later? Ken, Rob, do either of you remember? - Dan C. From dave at horsfall.org Sun Feb 16 09:25:28 2025 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 16 Feb 2025 10:25:28 +1100 (AEDT) Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: References: Message-ID: <020525ea-53d2-4ce8-b7dd-f76d0986ba76@horsfall.org> On Fri, 14 Feb 2025, Ron Natalie wrote: > The lawyers insisted that Unix be upper case and only used as an adjective. > > That is required for trademarks.   A trademark has to be an adjective > describing a generic noun. And you wonder why humans hate lawyers... -- Dave From gregg.drwho8 at gmail.com Sun Feb 16 12:23:41 2025 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Sat, 15 Feb 2025 21:23:41 -0500 Subject: [TUHS] The Case of UNIX vs. The UNIX System In-Reply-To: <603B528C-24C6-43EF-8107-09FA03662A5F@tuhs.org> References: <603B528C-24C6-43EF-8107-09FA03662A5F@tuhs.org> Message-ID: Hello! Then count me in as an observer. This is turning into an interesting discussion. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature was still fighting the timewars, Time and again." On Sat, Feb 15, 2025 at 4:35 PM Warren Toomey via TUHS wrote: > > > > On 16 February 2025 6:49:15 am AEST, Rob Pike wrote: > >Someone should start a mailing list so we can record the history for those > >who can't remember what happened or weren't there. > > > >-rob > > I might get around to doing that one day :-) > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From arnold at skeeve.com Sun Feb 16 17:52:48 2025 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 16 Feb 2025 00:52:48 -0700 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: References: Message-ID: <202502160752.51G7qmK0190936@freefriends.org> I think there was also a paper about it in the Computing Systems journal that USENIX did for a while. Arnold Dan Cross wrote: > On Sat, Feb 15, 2025 at 1:52 PM Rich Salz wrote: > > >However, to be used to its full effect, -mpm also required a > > > postprocessor, called `pm`, > > > > A troff post-processor? What did it do? > > As I understood it, it took directives embedded in troff's output and > used those to perform better vertical justification and image layout, > so that things like the page ends matched across facing pages in a > printed book and so forth. > > Oh, I just realized that this _has_ been ported to modern machines. > Perhaps ironically, it's part of plan9port, the port of (most of) > plan9 to Unix: https://github.com/9fans/plan9port/tree/master/src/cmd/mpm > > A paper about it was in the Volume 2 of the 10th Ed manual; I was just > looking to see if a PDF of that was floating around when I ran across > this: > https://archive.org/details/unixresearchsystemprogrammersmanualtentheditionfixed/mode/2up > > I'm not sure who this person is, but it seems like they've uploaded > some cool stuff. > https://archive.org/details/@yehudahamakabi > > Anyway, I didn't find a PDF of Vol2, but I did find this: > https://github.com/Alhadis/Research-Unix-v10/tree/master/docs/vol2/pm > (of course, the V10 source is available, but this is easy to grab). > Running it through `groff -ms` gives output that's imperfect, but > intelligible to get the main gist. > > Hmm, it doesn't seem to mention the post-processor at all; maybe that > didn't come until later? > > Ken, Rob, do either of you remember? > > - Dan C. From jaapna at xs4all.nl Sun Feb 16 22:31:07 2025 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Sun, 16 Feb 2025 13:31:07 +0100 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: <202502160752.51G7qmK0190936@freefriends.org> References: <202502160752.51G7qmK0190936@freefriends.org> Message-ID: <146074A2-A294-42C8-8A3D-366961614270@xs4all.nl> > On 16 Feb 2025, at 08:52, arnold at skeeve.com wrote: > > I think there was also a paper about it in the Computing Systems > journal that USENIX did for a while. Yup: http://www.usenix.org/publications/compsystems/1989/spr_kernighan.pdf jaap -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaapna at xs4all.nl Sun Feb 16 22:31:07 2025 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Sun, 16 Feb 2025 13:31:07 +0100 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: <202502160752.51G7qmK0190936@freefriends.org> References: <202502160752.51G7qmK0190936@freefriends.org> Message-ID: <146074A2-A294-42C8-8A3D-366961614270@xs4all.nl> > On 16 Feb 2025, at 08:52, arnold at skeeve.com wrote: > > I think there was also a paper about it in the Computing Systems > journal that USENIX did for a while. Yup: http://www.usenix.org/publications/compsystems/1989/spr_kernighan.pdf jaap -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Mon Feb 17 02:30:12 2025 From: rich.salz at gmail.com (Rich Salz) Date: Sun, 16 Feb 2025 11:30:12 -0500 Subject: [TUHS] Unix V10 Volume 2 PDFs In-Reply-To: <146074A2-A294-42C8-8A3D-366961614270@xs4all.nl> References: <202502160752.51G7qmK0190936@freefriends.org> <146074A2-A294-42C8-8A3D-366961614270@xs4all.nl> Message-ID: > > Yup: http://www.usenix.org/publications/compsystems/1989/spr_kernighan.pdf > Thanks for that. It was a fun read -- switching to two columns and the slight dig (" Good page makeup cannot be defined in terms of purely numerical properties of the input ") -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Feb 18 04:58:54 2025 From: crossd at gmail.com (Dan Cross) Date: Mon, 17 Feb 2025 13:58:54 -0500 Subject: [TUHS] Unix page at the Multicians web site. Message-ID: Tom Van Vleck just posted to the multicians mailing list that he is doing an update to the Unix page at multicians.org and is soliciting feedback. I figure some folks here may have useful suggestions. His draft is here: https://multicians.org/unix2.html Comments directly to Tom, I suppose, but if interested parties would rather discuss here I'd be happy to summarize and send to him as well. - Dan C. From tuhs at tuhs.org Tue Feb 18 19:31:55 2025 From: tuhs at tuhs.org (Yufeng Gao via TUHS) Date: Tue, 18 Feb 2025 09:31:55 +0000 Subject: [TUHS] 1972 UNIX V2 "Beta" Resurrected Message-ID: Hi everyone, First-time poster here. Near the end of last year, I did some forensic analysis on the DMR tapes (https://www.tuhs.org/Archive/Applications/Dennis_Tapes) and had some fun playing around with them. Warren forwarded a few of my emails to this list at the end of last year and the beginning of this year, but it was never my intention for him to be my messenger, so I'm posting here myself now. Here's an update on my work with the s1/s2 tapes - I've managed to get a working system out of them. The s1 tape is a UNIX INIT DECtape containing the kernel, while s2 includes most of the distribution files. The s1 kernel is, to date, the earliest machine-readable UNIX kernel, sitting between V1 and V2. It differs from the unix-jun72 kernel in the following ways: - It supports both V1 and V2 a.outs out of the box, whereas the unmodified unix-jun72 kernel supports only V1. - The core size has been increased to 16 KiB (8K words), while the unmodified unix-jun72 kernel has an 8 KiB (4K word) user core. On the other hand, its syscall table matches that of V1 and the unix-jun72 kernel, lacking all V2 syscalls. Since it aligns with V1 in terms of syscalls, has the V2 core size and can run V2 binaries, I consider it a "V2 beta". login: root root # ls -la total 42 41 sdrwrw 7 root 80 Jan 1 00:02:02 . 41 sdrwrw 7 root 80 Jan 1 00:02:02 .. 43 sdrwrw 2 root 620 Jan 1 00:01:30 bin 147 l-rwrw 1 root 16448 Jan 1 00:33:51 core 42 sdrwrw 2 root 250 Jan 1 00:01:51 dev 49 sdrwrw 2 root 110 Jan 1 00:01:55 etc 54 sdrwrw 2 root 50 Jan 1 00:00:52 tmp 55 sdrwrw 7 root 80 Jan 1 00:00:52 usr # ls -la usr total 8 55 sdrwrw 7 root 80 Jan 1 00:00:52 . 41 sdrwrw 7 root 80 Jan 1 00:02:02 .. 56 sdrwrw 2 28 60 Jan 1 00:02:22 fort 57 sdrwrw 2 jack 50 Jan 1 00:02:39 jack 58 sdrwrw 2 6 30 Jan 1 00:02:36 ken 59 sdrwrw 2 root 120 Jan 1 00:00:52 lib 60 sdrwrw 2 sys 50 Jan 1 00:02:45 sys 142 s-rwrw 1 jack 54 Jan 1 00:52:29 x # ed a main() printf("hello world!\n"); . w hello.c 33 q # cc hello.c I II # ls -l a.out total 3 153 sxrwrw 1 root 1328 Jan 1 00:02:12 a.out # a.out hello world! # It's somewhat picky about the environment. So far, aap's PDP-11/20 emulator (https://github.com/aap/pdp11) is the only one capable of booting the kernel. SIMH and Ersatz-11 both hang before reaching the login prompt. This makes installation from the s1/s2 tapes difficult, as aap's emulator does not support the TC11. The intended installation process involves booting from s1 and restoring files from s2. What I did was I extracted the files from the s1 tape and placed them on an empty RF disk, then installed the unix-jun72 kernel. After booting from the RF under SIMH, I extracted the remaining files from s2. Finally, I replaced the unix-jun72 kernel with the s1 kernel using a hex editor, resulting in an RF disk image containing only files from s1/s2. This RF image is bootable under aap's emulator but not SIMH. The RF disk image can be downloaded from here (https://github.com/TheBrokenPipe/Research-UNIX-V2-Beta): Direct link - https://github.com/TheBrokenPipe/Research-UNIX-V2-Beta/raw/refs/heads/main/s1s2unix_rf.img Interestingly, its init(7) program does not mount the RK to /usr, suggesting that /usr was stored on the RF. Sincerely, Yufeng From aap at papnet.eu Tue Feb 18 19:52:41 2025 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 18 Feb 2025 10:52:41 +0100 Subject: [TUHS] 1972 UNIX V2 "Beta" Resurrected In-Reply-To: References: Message-ID: This is very exciting news! I have to say i'm a bit surprised my emulator of all things can run it. It's not terribly flexible and doesn't have a lot of features. So the next step would be to restore the assembly source? :) cheers, aap On 18/02/25, Yufeng Gao via TUHS wrote: > Hi everyone, > > First-time poster here. Near the end of last year, I did some forensic analysis on the DMR tapes (https://www.tuhs.org/Archive/Applications/Dennis_Tapes) and had some fun playing around with them. Warren forwarded a few of my emails to this list at the end of last year and the beginning of this year, but it was never my intention for him to be my messenger, so I'm posting here myself now. > > Here's an update on my work with the s1/s2 tapes - I've managed to get a working system out of them. The s1 tape is a UNIX INIT DECtape containing the kernel, while s2 includes most of the distribution files. > > The s1 kernel is, to date, the earliest machine-readable UNIX kernel, sitting between V1 and V2. It differs from the unix-jun72 kernel in the following ways: > > - It supports both V1 and V2 a.outs out of the box, whereas the unmodified unix-jun72 kernel supports only V1. > - The core size has been increased to 16 KiB (8K words), while the unmodified unix-jun72 kernel has an 8 KiB (4K word) user core. > > On the other hand, its syscall table matches that of V1 and the unix-jun72 kernel, lacking all V2 syscalls. Since it aligns with V1 in terms of syscalls, has the V2 core size and can run V2 binaries, I consider it a "V2 beta". > > login: root > root > # ls -la > total 42 > 41 sdrwrw 7 root 80 Jan 1 00:02:02 . > 41 sdrwrw 7 root 80 Jan 1 00:02:02 .. > 43 sdrwrw 2 root 620 Jan 1 00:01:30 bin > 147 l-rwrw 1 root 16448 Jan 1 00:33:51 core > 42 sdrwrw 2 root 250 Jan 1 00:01:51 dev > 49 sdrwrw 2 root 110 Jan 1 00:01:55 etc > 54 sdrwrw 2 root 50 Jan 1 00:00:52 tmp > 55 sdrwrw 7 root 80 Jan 1 00:00:52 usr > # ls -la usr > total 8 > 55 sdrwrw 7 root 80 Jan 1 00:00:52 . > 41 sdrwrw 7 root 80 Jan 1 00:02:02 .. > 56 sdrwrw 2 28 60 Jan 1 00:02:22 fort > 57 sdrwrw 2 jack 50 Jan 1 00:02:39 jack > 58 sdrwrw 2 6 30 Jan 1 00:02:36 ken > 59 sdrwrw 2 root 120 Jan 1 00:00:52 lib > 60 sdrwrw 2 sys 50 Jan 1 00:02:45 sys > 142 s-rwrw 1 jack 54 Jan 1 00:52:29 x > # ed > a > main() printf("hello world!\n"); > . > w hello.c > 33 > q > # cc hello.c > I > II > # ls -l a.out > total 3 > 153 sxrwrw 1 root 1328 Jan 1 00:02:12 a.out > # a.out > hello world! > # > > It's somewhat picky about the environment. So far, aap's PDP-11/20 emulator (https://github.com/aap/pdp11) is the only one capable of booting the kernel. SIMH and Ersatz-11 both hang before reaching the login prompt. This makes installation from the s1/s2 tapes difficult, as aap's emulator does not support the TC11. The intended installation process involves booting from s1 and restoring files from s2. > > What I did was I extracted the files from the s1 tape and placed them on an empty RF disk, then installed the unix-jun72 kernel. After booting from the RF under SIMH, I extracted the remaining files from s2. Finally, I replaced the unix-jun72 kernel with the s1 kernel using a hex editor, resulting in an RF disk image containing only files from s1/s2. This RF image is bootable under aap's emulator but not SIMH. > > The RF disk image can be downloaded from here (https://github.com/TheBrokenPipe/Research-UNIX-V2-Beta): > Direct link - https://github.com/TheBrokenPipe/Research-UNIX-V2-Beta/raw/refs/heads/main/s1s2unix_rf.img > > Interestingly, its init(7) program does not mount the RK to /usr, suggesting that /usr was stored on the RF. > > Sincerely, > Yufeng From jnc at mercury.lcs.mit.edu Wed Feb 19 01:34:05 2025 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 18 Feb 2025 10:34:05 -0500 (EST) Subject: [TUHS] 1972 UNIX V2 "Beta" Resurrected Message-ID: <20250218153405.2DB3A18C09E@mercury.lcs.mit.edu> > From: Yufeng Gao > The s1 kernel is, to date, the earliest machine-readable UNIX kernel, > sitting between V1 and V2. It will be interesting to see what it reveals, as it's in the UNIX 'dark age' between V1 and V4. Working from hints and clues in the extant 'UNIX Programmer's Manual: Second Edition', I had tried to figure out how V2 differed from V1: https://gunkies.org/wiki/UNIX_Second_Edition but I was mostly interested in 'big picture' issues (like how a process'es address space was laid out), not details like 'the foo() call was added', or 'how exec() differs'. (If someone _does_ create lists of the calls in V1 and V2, and their details, and compares them, that _will_ be of value, don't get me wrong; I was mostly just trying to work out how the mysterious KS11 worked.) > It's somewhat picky about the environment. So far, aap's PDP-11/20 > emulator .. is the only one capable of booting the kernel. SIMH and > Ersatz-11 both hang before reaching the login prompt. It would be very interesting to know what fails. By 'hang', do you mean 'ceases making progress', or 'halts'? If the former, since I've almost always had good experiences with Ersatz-11, my _guess_ would be a problem with the RF11 emulation. (The RF11 was a very early, and smalll, disk, so I wouldn't be surprised if there hasn't been a lot of software run on those emulators that uses it, to flush out bugs. It's also kind of an odd duck; it's word-oriented, not block-orientd.) So, for instance, a 'lost' disk interrupt would produce this symptom. Are there any RF11 diagnostics online? That would be the thing I would start with. And I guess this system doesn't include the KS11; a pity, code that uses it would allow re-creation of the programming manual (the way the: https://gunkies.org/wiki/ANTS/ISI_IMP_Interface programming instructions were re-created). > From: Angelo Papenhoff > So the next step would be to restore the assembly source? :) Having only the binary to work from (to start with) is not optimal; those early versions of UNIX ran on a number of very different hardware configurations (e.g. with or without the KS11), with conditional assembly to handle different configurations. Having only the dis-assembled code for _this_ configuration would obviously leave the code for the others missing. Still, having _this_ source _would_ be useful; e.g. the 'hang-up' problem above; the easiest way to debug that would to put 'print' statements in the code, where a disk operation was started, and completes. If it's 'losing' a disk interrupt completion, that will show right up. (Been there, done that, on the RK11 hardware emulator Bridgham and I built, when UNIX wouldn't boot, just hung.) Although I suppose one could put break-points there. Trying to debug it any other way would be painfu beyond belief. Noel From tuhs at tuhs.org Wed Feb 19 02:36:46 2025 From: tuhs at tuhs.org (Yufeng Gao via TUHS) Date: Tue, 18 Feb 2025 16:36:46 +0000 Subject: [TUHS] 1972 UNIX V2 "Beta" Resurrected In-Reply-To: <20250218153405.2DB3A18C09E@mercury.lcs.mit.edu> References: <20250218153405.2DB3A18C09E@mercury.lcs.mit.edu> Message-ID:    > From: Angelo Papenhoff    > So the next step would be to restore the assembly source? :) It would be a fun project restoring the source code (there's a warm and a cold kernel, so they can be diffed to work out the ifdefs). In fact, I did disassemble vcboot and bos, as well as half the warm UNIX kernel, but in my infinite wisdom, I decided to name the IDA databases f1/f2/f3 and accidentally deleted them while cleaning up my desktop :((.     > From: Noel Chiappa     > It will be interesting to see what it reveals, as it's in the UNIX 'dark age'     > between V1 and V4. Working from hints and clues in the extant 'UNIX     > Programmer's Manual: Second Edition', I had tried to figure out how V2     > differed from V1: I have some UNIX V2, V3 and V4 binaries (no kernels) recovered from DMR's DECtapes, plus a kernel driver or two from slightly earlier than nsys. Also, I have a few V4 distribution documents. I'm still slowly recovering stuff from those tapes, but most of what I've recovered is here (https://www.tuhs.org/Archive/Applications/Dennis_Tapes/Gao_Analysis/) (thank you Warren for hosting them!) if they interest you.     > I was mostly just trying to work out how the mysterious KS11     > worked. Sadly, this kernel does not have the KS11 stuff. The last1120c tape has binaries from a (or the, since there was only one?) machine with the KS11, as well as an earlier C compiler still called "nc". Of course, they're effectively V3+ binaries that use the EAE, so they won't really help with knowing how the KS11 worked.     > It would be very interesting to know what fails. By 'hang', do you mean     > 'ceases making progress', or 'halts'? Don't quote me on this, but I think under E11, it hangs in a loop before getting to init(7), and under SIMH, it bus errors while running init(7). Though I'll need to double-check SIMH because I may have used unix-jun72's /etc/init instead of the one from s2. Sincerely, Yufeng From tuhs at tuhs.org Wed Feb 19 02:42:04 2025 From: tuhs at tuhs.org (Yufeng Gao via TUHS) Date: Tue, 18 Feb 2025 16:42:04 +0000 Subject: [TUHS] Typesetting ROFF/NROFF Documents Message-ID: Hi everyone, I've cobbed together a crude Teletype Model 37 emulator that generates PDF files (https://github.com/TheBrokenPipe/Teletype-37-PDF). It produces sane-looking PDFs for most (all?) of the early UNIX ROFF/NROFF documents. The biggest advantage of this over something like "roff $1 | enscript -c -f Courier12 -l -M Letter --margins=67:-9:0:-9 -p $1.ps -s -0.05" is it supports half (forward/reverse) line feeds which enscript does not. Early ROFF stuff like the UNIX manuals and memos made extensive use of subscripts (and superscripts), making them rather painful to typeset. As an experiment, I re-set Ken Thompson's "Users' Reference to B" memo from early 1972 (https://github.com/TheBrokenPipe/kbman-reset). I picked this one because it contains a BNF-alike description of the grammar as well as fractions in code comments, both of which make extensive use of sub/superscripts. I went to the extent of overlaying the re-set pages on top of the originals to make sure everything lined up. I'd really appreciate it if someone could review my work on the B manual. If everything looks good, I may tackle other documents, starting with low hanging fruits like the "V0" manual and potentially moving on to re-setting the V1 and V2 manuals in the future (building on aap's work). Sincerely, Yufeng From tuhs at tuhs.org Wed Feb 19 03:06:33 2025 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 18 Feb 2025 17:06:33 +0000 Subject: [TUHS] 1972 UNIX V2 "Beta" Resurrected In-Reply-To: References: <20250218153405.2DB3A18C09E@mercury.lcs.mit.edu> Message-ID: Sent with Proton Mail secure email. On Tuesday, February 18th, 2025 at 8:36 AM, Yufeng Gao via TUHS wrote: > > From: Angelo Papenhoff > > > So the next step would be to restore the assembly source? :) > > > It would be a fun project restoring the source code (there's a warm and a cold kernel, so they can be diffed to work out the ifdefs). In fact, I did disassemble vcboot and bos, as well as half the warm UNIX kernel, but in my infinite wisdom, I decided to name the IDA databases f1/f2/f3 and accidentally deleted them while cleaning up my desktop :((. > > > > From: Noel Chiappa > > > > It will be interesting to see what it reveals, as it's in the UNIX 'dark age' > > > between V1 and V4. Working from hints and clues in the extant 'UNIX > > > Programmer's Manual: Second Edition', I had tried to figure out how V2 > > > differed from V1: > > > I have some UNIX V2, V3 and V4 binaries (no kernels) recovered from DMR's DECtapes, plus a kernel driver or two from slightly earlier than nsys. Also, I have a few V4 distribution documents. I'm still slowly recovering stuff from those tapes, but most of what I've recovered is here (https://www.tuhs.org/Archive/Applications/Dennis_Tapes/Gao_Analysis/) (thank you Warren for hosting them!) if they interest you. > > > I was mostly just trying to work out how the mysterious KS11 > > > worked. > > > Sadly, this kernel does not have the KS11 stuff. The last1120c tape has binaries from a (or the, since there was only one?) machine with the KS11, as well as an earlier C compiler still called "nc". Of course, they're effectively V3+ binaries that use the EAE, so they won't really help with knowing how the KS11 worked. > > > It would be very interesting to know what fails. By 'hang', do you mean > > > 'ceases making progress', or 'halts'? > > > Don't quote me on this, but I think under E11, it hangs in a loop before getting to init(7), and under SIMH, it bus errors while running init(7). Though I'll need to double-check SIMH because I may have used unix-jun72's /etc/init instead of the one from s2. > > Sincerely, > Yufeng For the record, I've done a bit of disassembly/restoration work on bits from these tapes, the following two Git repos have some of this work (along with Angelo's V2 B application restorations): https://gitlab.com/segaloco/v2src https://gitlab.com/segaloco/v1man https://gitlab.com/segaloco/v2man Above are source code restorations of some commands and a roff restoration of the V1/V2 manuals. I'm happy to hand these repos over to some larger effort as seed stuff for further V2 restoration efforts. - Matt G. P.S. While my own work on this stuff has stalled out as I work on some other projects, I am happy to contribute further if someone else is interested in taking over, I just don't see myself able to lead this effort in the near term. From phil at ultimate.com Wed Feb 19 04:14:23 2025 From: phil at ultimate.com (Phil Budne) Date: Tue, 18 Feb 2025 13:14:23 -0500 Subject: [TUHS] Typesetting ROFF/NROFF Documents In-Reply-To: References: Message-ID: <202502181814.51IIENBN092887@ultimate.com> Looking at https://github.com/TheBrokenPipe/Teletype-37-PDF/blob/main/.images/test.png My recall is that the TTY33 I used had "vertical stops" set to every 6 lines (like the HT calculation but with a different constant), so VT was equal to between 1 and 5 LF's. In my mind I can hear, "feed feed feed (small delay) feed feed feed feed feed" (that is, the first VT could be fewer lines), but I might be thinking of VT followed by FF. So it's also possible it was always 5/6 LF's, my memory is from almost 50 years ago, the TTY37 could have been different, or the particular TTY37's in use on early UNIX systems could have been set up differently! Back in the day, line printers had carriage control punched tape loops which allowed different format effectors in column 1 of the output to have different stops, 1 was FF, it never occurred to me that HT on a TTY with green/white striped paper could have advanced two (three line) stripes (or that TTY vertical spacing was remotely accurate enough to have it work!) Are there any font files with the needed characters (with or without imperfections) and realistic character shapes? Gratuitous links on line printer carriage control (the has a program to take (simple) ASCII files and produce PDFs) http://www.urbanjost.altervista.org/LIBRARY/libGPF/EXE/ASA/html/asa_carriage_control.html https://en.wikipedia.org/wiki/ASA_carriage_control_characters https://en.wikipedia.org/wiki/Carriage_control_tape From tuhs at tuhs.org Thu Feb 20 14:58:33 2025 From: tuhs at tuhs.org (Yufeng Gao via TUHS) Date: Thu, 20 Feb 2025 04:58:33 +0000 Subject: [TUHS] 1972 UNIX V2 "Beta" Resurrected In-Reply-To: References: <20250218153405.2DB3A18C09E@mercury.lcs.mit.edu> Message-ID: Hi, So I've tested SIMH again with my reconstructed RF disk image, and this time it worked. I must have used the s1 kernel and the unix-june72 init(7) when I previously tested it, my bad. sim> dep system sr 173700 sim> go 173700 :login: root root # ls -la total 42 41 sdrwrw 7 root 80 Jan 1 00:02:02 . 41 sdrwrw 7 root 80 Jan 1 00:02:02 .. 43 sdrwrw 2 root 620 Jan 1 00:01:30 bin 147 l-rwrw 1 root 16448 Jan 1 00:33:51 core 42 sdrwrw 2 root 250 Jan 1 00:01:51 dev 49 sdrwrw 2 root 110 Jan 1 00:01:55 etc 54 sdrwrw 2 root 50 Jan 1 00:00:52 tmp 55 sdrwrw 7 root 80 Jan 1 00:00:52 usr # It's great that it works under SIMH... However, this still does not help with installing this version of UNIX the intended way. The intended way is to boot from the s1 tape, which would load the cold kernel, initialise the RF, and provide you with a minimal set of tools so that you could use tap(1) to restore the distribution from the s2 tape. The showstopper here is the s1 tape - it is missing /etc/passwd, so you will not be able to login when booted from s1. sim> dep system sr 1 sim> boot tc0 HALT instruction, PC: 000414 (JSR R0,10762) sim> c :login: root root Can't open password file :login: Since you can't login, there's not much you can do :(. For now, my hand-rolled RF disk image is the only way to get a working copy. My SIMH config file: set cr disabled set xq disabled set rk disabled set hk disabled set rha disabled set tm disabled set rx disabled set rl disabled set tq disabled set dci disabled set cpu 11/20 set cpu 32K set ke enabled set rf 2p set rf enabled att rf s1s2unix_rf.img <-- RF disk image set tc enabled set tc locked att tc s1.itp <-- s1 tape load m792low.load <-- Modified UNIX ROM from unix-june72 project dep system sr 173700 go 73700 <-- Low address used by the modded ROM P.S. This kernel is unmodded, which means it supports only LF, not CR, so use ^J for ENTER. Sincerely, Yufeng From tuhs at tuhs.org Thu Feb 20 17:03:12 2025 From: tuhs at tuhs.org (Yufeng Gao via TUHS) Date: Thu, 20 Feb 2025 07:03:12 +0000 Subject: [TUHS] Pre-Struct C Compiler with Funny Syntax Resurrected Message-ID: Hi again, I've recently brought the "prestruct-c" compiler back to "life" (https://github.com/TheBrokenPipe/C-Compiler-Dec72) and thought it might be worth documenting here. One thing I have to say first - it's barely working and probably never worked to begin with. There were some efforts in the distant past to revive this compiler; however, the compiled compiler never worked. The reasons are as follows: - The compiled executable is too big (exceeds 32K, making pointers effectively negative). This triggers a bug in the liba I/O routines. - The compiler assumes an origin of 0 and writes temp data at the NULL pointer. Without an MMU, this kills the interrupt vectors and possibly the kernel on the 11/20. - The compiler is missing ALL code/tables written in assembly language. This is pretty fatal, and internal changes rendered files from the last1120c compiler incompatible. - Calling convention changes make the s2/last1120c libc library incompatible. I'm a big fan of the C programming language, and the reason I was so insistent on getting this compiler to work is that it has a funny struct syntax not seen in any other C compiler. Structs are defined like: struct name ( type field; ... ); ... with round brackets (parentheses) instead of curly braces. Another notable thing introduced in this compiler is that certain things are no longer lvalues. In the past (B and last1120c), functions, labels, and arrays were lvalues, meaning they could be assigned. For instance, this code: func1() { return (1); } func2() { return (2); } main() { printf("func1() = %d\n", func1()); printf("func2() = %d\n", func2()); printf("func1 = func2\n"); func1 = func2; printf("func1() = %d\n", func1()); } produces the output: func1() = 1 func2() = 2 func1 = func2 func1() = 2 This code: main() { second = first; goto second; first: printf("first\n"); second: printf("second\n"); } produces the output: first second And this code: main(argc, argv) { int arr1[10]; int arr2[10]; arr1[0] = 5; arr2[0] = 8; printf("arr1[0] = %d\n", arr1[0]); printf("arr2[0] = %d\n", arr2[0]); printf("arr1 = arr2\n"); arr1 = arr2; printf("arr1[0] = %d\n", arr1[0]); } produces the output: arr1[0] = 5 arr2[0] = 8 arr1 = arr2 arr1[0] = 8 Now, the rules of the game have changed with the prestruct-c compiler, and these are no longer lvalues. I don't know why this change was made, but if I had to guess, speed was probably the biggest driving factor, with security also playing a role. Anyhow, they're no longer lvalues, so there's now one less level of indirection involving functions and labels. This means the codegen tables from last1120c have to be modified to suit this compiler change. However, even with it generating the correct code, there is still one fatal problem - the libc. The libc from s2/last1120c was designed for the older compiler and therefore has one extra layer of indirection for functions. Luckily, the source code of the libc is available on the last1120c tape, and it wasn't too much work to remove the indirection manually. Okay, what else? Well, this compiler also seems to be the first to introduce the "modern" pointer syntax. Before this compiler, pointers were declared using the same syntax as arrays/vectors, like "char name[];". This compiler introduced the "modern" syntax of "char *name;". No big deal, right? Well, the compiler itself was written using the old syntax, meaning it cannot compile itself. I think this indicates that this compiler (or the new syntax) was so unstable that the production compiler still used the old syntax. With everything carefully put back into place, I managed to get this to work: struct foo ( char x; int y; char *z; ); main(argc, argv) char **argv; { struct foo bruh; bruh.x = 'C'; bruh.y = 123; bruh.z = "test"; printf("x = '%c', y = %d, z = \"%s\"\n", bruh.x, bruh.y, bruh.z); } However, if I rename the variable "bruh" to something like "bar", it throws the error "Unimplemented pointer conversion". I have no clue why. I've also never gotten struct pointers to work - it always complains about "Illegal structure ref" when I try to use "->". It also seems to accept "." on structure pointers (and does not actually dereference the pointer when accessing the members), so something is probably very wrong with referencing and dereferencing. Anyway, there are plenty of other issues with the compiler, like the code may not compile correctly with pointers and switch statements. I'm not sure if the issues are caused by my poor reconstruction of the assembly tables, or if the compiler itself never worked properly in the first place (or both). Either way, I've managed to get it to spit out a correct hello world, as well as the struct test above, so I think I've fulfilled my goal of seeing this compiler "work". The code, build instructions and pre-built binaries are here: https://github.com/TheBrokenPipe/C-Compiler-Dec72 Ideally, it runs under a PDP-11/45 environment with 0 as the origin and generates code for the PDP-11/45. However, I made it target the 11/20 since I couldn't get the 11/45 toolchain to work, and I haven't implemented 11/45 instructions in my simulator yet. If anyone wants to pick up the baton and get it working for the 11/45 or fix my bugs, be my guest! Sincerely, Yufeng From douglas.mcilroy at dartmouth.edu Fri Feb 21 01:00:47 2025 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 20 Feb 2025 10:00:47 -0500 Subject: [TUHS] Pre-Struct C Compiler with Funny Syntax Resurrected Message-ID: Yufeng, > I've recently brought the "prestruct-c" compiler back to "life" Great archeology! It seems you've unearthed a snapshot from the brief period when Dennis was struggling to reconcile byte addressing with BCPL pointers--the seminal innovation of C. In characteristic Unix fashion, he was trying out his ideas as they developed. I had forgotten that product types were under con-struct-ion at the same time. That really was a big bang. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From babydr at baby-dragons.com Thu Feb 27 12:23:24 2025 From: babydr at baby-dragons.com (babydr DBA James W. Laferriere) Date: Wed, 26 Feb 2025 17:23:24 -0900 (AKST) Subject: [TUHS] Having dickens of a time compiling gcc-4.4.7 on tru64 . Message-ID: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> Hello Anyone interested in this silliness , I am just recently trying to reacquaint myself with this os . Which I had a decent passing knowledge of at one time . Not any real OS level or driver coding , But was least decently acquainted . Now on with the preliminaries ... Any good software items to update on this ol'thing that give me a better chance of completing this task , Greatly welcome . I have folowed , ths article which is a copy from (imo) several places , tho all of them are using a axp-Emulator . I am using (I'll admit) a REAL AlphaStation 200 (4/100) with 384MB main memory & three disks all are U160's 2x4G+1x72G , OS is installed on the 72G(now) & has a /home dir for users rather that the default location . See info & error during make of gcc . Those numbers for the allocation & total have been exactly the same accross many iterations of attempts in that exact file . # sizer -v HP Tru64 UNIX V5.1B (Rev. 2650); Sun Feb 23 19:43:32 AKST 2025 It is at patch level 008 . and had successfully compiled & installed all the prerequisites shown in the article mentioned above . It Seems the OS doesn't know how to access the swap properly . root at as200:/home/buildnfs/gcc-4.4.7# env PATH=/usr/local/bin:/sbin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/dt/bin:~/bin:. make ... many lines snipped ... /home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/xgcc -B/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/ -B/usr/local/alpha-dec-osf5.1b/bin/ -c -g -$ cc1: out of memory allocating 135816 bytes after a total of 796519376 bytes make[3]: *** [fold-const.o] Error 1 make[3]: Leaving directory `/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/buildnfs/gcc-4.4.7' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/buildnfs/gcc-4.4.7' make: *** [all] Error 2 # swapon -s Swap partition /dev/disk/dsk2g: Allocated space: 249774 pages (1.91GB) In-use space: 1520 pages ( 0%) Free space: 248254 pages ( 99%) Swap partition /dev/disk/dsk1b: Allocated space: 49152 pages (384MB) In-use space: 1630 pages ( 3%) Free space: 47522 pages ( 96%) Swap partition /dev/disk/dsk0b: Allocated space: 49152 pages (384MB) In-use space: 1618 pages ( 3%) Free space: 47534 pages ( 96%) Total swap allocation: Allocated space: 348078 pages (2.66GB) In-use space: 4768 pages ( 1%) Available space: 343310 pages ( 98%) # hwmgr show scsi SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH ------------------------------------------------------------------------- 42: 0 as200 cdrom none 0 1 cdrom0 [0/4/0] 43: 1 as200 disk none 2 1 dsk0 [1/0/0] 44: 2 as200 disk none 2 1 dsk1 [1/1/0] 45: 3 as200 disk none 2 1 dsk2 [1/2/0] # hwmgr -view dev HWID: Device Name Mfg Model Location ------------------------------------------------------------------------------ 3: /dev/dmapi/dmapi 4: /dev/scp_scsi 5: /dev/kevm 29: /dev/disk/floppy0c 3.5in floppy fdi0-unit-0 42: /dev/disk/cdrom0c TOSHIBA DVD-ROM SD-M1401 bus-0-targ-4-lun-0 43: /dev/disk/dsk0c IBM DDRS-34560D bus-1-targ-0-lun-0 44: /dev/disk/dsk1c COMPAQ BD07286224 bus-1-targ-1-lun-0 45: /dev/disk/dsk2c COMPAQ ST34371W bus-1-targ-2-lun-0 46: /dev/random 47: /dev/urandom Tia , JimL -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml at system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+ From tuhs at tuhs.org Thu Feb 27 16:52:03 2025 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Thu, 27 Feb 2025 07:52:03 +0100 Subject: [TUHS] Having dickens of a time compiling gcc-4.4.7 on tru64 . In-Reply-To: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> Message-ID: On 27/02/2025 3:23 am, babydr DBA James W. Laferriere wrote: > It Seems the OS doesn't know how to access the swap properly . Wild guess incoming... My active experience on HP stuff ends with HP9000's and HPUX, but could it be an ulimit settings perhaps? The article doesn't seem to set anything to 'unlim' or similar. Older UNIX versions tend to limit process sizes, open files and such and especially compiling GCC and the like tends to munch address space... So it may 'want' to page out, but is limited by the max process size and can't malloc anymore. Bye, Arno. From tuhs at tuhs.org Thu Feb 27 17:43:42 2025 From: tuhs at tuhs.org (Arrigo Triulzi via TUHS) Date: Thu, 27 Feb 2025 08:43:42 +0100 Subject: [TUHS] Having dickens of a time compiling gcc-4.4.7 on tru64 . In-Reply-To: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> Message-ID: On 27 Feb 2025, at 03:28, babydr DBA James W. Laferriere wrote: > cc1: out of memory allocating 135816 bytes after a total of 796519376 bytes That’s an “easy one”: you have to turn off the preallocation and run lazy memory allocation. “Digital UNIX has two paging modes, lazy and conservative. Conservative means that paging space is allocated as memory is allocated, guaranteeing that there is always somewhere to page to. This limits VM to the size of the paging partitions, but makes for a very robust system. Lazy is more like what people are used to with Unix - paging space is allocated when needed for paging out, you can run more jobs, but you're in big trouble when everything fills up. By default, Digital UNIX comes up in the conservative mode. Removing theswapdefaults file changes the system to lazy mode.” Cheers, Arrigo (old OSF/1 hand since T1.0) From babydr at baby-dragons.com Fri Feb 28 06:45:49 2025 From: babydr at baby-dragons.com (babydr DBA James W. Laferriere) Date: Thu, 27 Feb 2025 11:45:49 -0900 (AKST) Subject: [TUHS] Having dickens of a time compiling gcc-4.4.7 on tru64 . In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> Message-ID: Hello Arno , Arrigo & Kenneth , Arno Hit it on the head with the ulimit . After I had sent the missive I again went looking for the original url that had successfully complied tthis version of GCC & founfd it , & of course the one item missing from the other copies is the 'ulimit -d unlimited' & checking to what it was set too . Arrigo mentioned a known difficulty with paging on Tru64 systems , Which I had set as he suggested , tho still had the same out of memory . Kenneth , I had gone thru the install putting on the LAST Known patch to Tru64 before I started even setting up , But I am still not complete sure if there might be another newer one floating out there somewhere . THANK YOU All for your responses !-) I (after the above) started another build & this time had it dumping all output (2>&1) to a file , This AM (here in AK) , I did a grep for the offending file & low and behold it compiled error free & is approriately archived . Now I have to await (Hopefully) for the completion of the CC portion & THEN The C++ which according to WILL take a considerable amount of time to complete , IF it does . ((*)beebe at math.utah.edu) Thank You All agn , JimL On Thu, 27 Feb 2025, Arno Griffioen via TUHS wrote: > On 27/02/2025 3:23 am, babydr DBA James W. Laferriere wrote: >> It Seems the OS doesn't know how to access the swap properly . > > Wild guess incoming... > > My active experience on HP stuff ends with HP9000's and HPUX, but could > it be an ulimit settings perhaps? > > The article doesn't seem to set anything to 'unlim' or similar. > > Older UNIX versions tend to limit process sizes, open files and such > and especially compiling GCC and the like tends to munch address space... > > So it may 'want' to page out, but is limited by the max process size > and can't malloc anymore. > Bye, Arno. -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml at system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+ From phil at ultimate.com Fri Feb 28 08:06:10 2025 From: phil at ultimate.com (Phil Budne) Date: Thu, 27 Feb 2025 17:06:10 -0500 Subject: [TUHS] Having dickens of a time compiling gcc-4.4.7 on tru64 . In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> Message-ID: <202502272206.51RM6AUB026294@ultimate.com> Arrigo Triulzi wrote: > “Digital UNIX has two paging modes, lazy and conservative. Conservative means that paging space is allocated as memory is allocated, guaranteeing that there is always somewhere to page to. This limits VM to the size of the paging partitions, but makes for a very robust system. Lazy is more like what people are used to with Unix - paging space is allocated when needed for paging out, you can run more jobs, but you're in big trouble when everything fills up. My recall is that 4.2BSD would only give you (writable) memory it could allocate swap space for. I think of the penchant for "overcommitting" memory (and the cold hand of the OOM killer) as Linuxisms From henry.r.bent at gmail.com Fri Feb 28 08:55:49 2025 From: henry.r.bent at gmail.com (Henry Bent) Date: Thu, 27 Feb 2025 17:55:49 -0500 Subject: [TUHS] Having dickens of a time compiling gcc-4.4.7 on tru64 . In-Reply-To: <202502272206.51RM6AUB026294@ultimate.com> References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> Message-ID: On Thu, Feb 27, 2025, 17:07 Phil Budne wrote: > Arrigo Triulzi wrote: > > “Digital UNIX has two paging modes, lazy and conservative. Conservative > means that paging space is allocated as memory is allocated, guaranteeing > that there is always somewhere to page to. This limits VM to the size of > the paging partitions, but makes for a very robust system. Lazy is more > like what people are used to with Unix - paging space is allocated when > needed for paging out, you can run more jobs, but you're in big trouble > when everything fills up. > > My recall is that 4.2BSD would only give you (writable) memory it > could allocate swap space for. > > I think of the penchant for "overcommitting" memory > (and the cold hand of the OOM killer) as Linuxisms > Yes, this is the case for Ultrix, and I can imagine that it survived into Tru64 (I don't have my Alphaserver up right now). You need to have disk space allocated to swap for any memory that you want to map, regardless of how much physical memory you have. -Henry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From babydr at baby-dragons.com Fri Feb 28 13:49:45 2025 From: babydr at baby-dragons.com (babydr DBA James W. Laferriere) Date: Thu, 27 Feb 2025 18:49:45 -0900 (AKST) Subject: [TUHS] Having dickens of a time compiling gcc-4.4.7 on tru64 . In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> Message-ID: <3d1b0414-176e-e1ff-2738-bf4bdb09c37d@baby-dragons.com> Hello All , Just to tidy up this thread , VVVV LIne number in logfile . 2012:cc -c -g -DIN_GCC -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include ../.././gcc/fold-const.c -o fold-const.o 4640:/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/xgcc -B/home/buildnfs/gcc-4.4.7/host-alpha-dec-osf5.1b/prev-gcc/ -B/usr/local/alpha-dec-osf5.1b/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include ../.././gcc/fold-const.c -o fold-const.o Successful build to this point NOW for the loonngggg Wait for the rest of the story ;-) . Hopefully tomorrow a completed build of GCC, c&c++ . Thank you all again . JimL On Thu, 27 Feb 2025, babydr DBA James W. Laferriere wrote: > Hello Arno , Arrigo & Kenneth , > Arno Hit it on the head with the ulimit . After I had sent the > missive I again went looking for the original url that had successfully > complied tthis version of GCC & founfd it , & of course the one item missing > from the other copies is the 'ulimit -d unlimited' & checking to what it was > set too . > > Arrigo mentioned a known difficulty with paging on Tru64 systems , > Which I had set as he suggested , tho still had the same out of memory . > > Kenneth , I had gone thru the install putting on the LAST Known > patch to Tru64 before I started even setting up , But I am still not > complete sure if there might be another newer one floating out there > somewhere . > > THANK YOU All for your responses !-) I (after the above) started > another build & this time had it dumping all output (2>&1) to a file , This > AM (here in AK) , I did a grep for the offending file & low and behold it > compiled error free & is approriately archived . Now I have to await > (Hopefully) for the completion of the CC portion & THEN The C++ which > according to WILL take a considerable amount of time to complete , IF it does > . > > ((*)beebe at math.utah.edu) > > Thank You All agn , JimL > > On Thu, 27 Feb 2025, Arno Griffioen via TUHS wrote: >> On 27/02/2025 3:23 am, babydr DBA James W. Laferriere wrote: >>> It Seems the OS doesn't know how to access the swap properly . >> >> Wild guess incoming... >> >> My active experience on HP stuff ends with HP9000's and HPUX, but could >> it be an ulimit settings perhaps? >> >> The article doesn't seem to set anything to 'unlim' or similar. >> >> Older UNIX versions tend to limit process sizes, open files and such >> and especially compiling GCC and the like tends to munch address space... >> >> So it may 'want' to page out, but is limited by the max process size >> and can't malloc anymore. >> Bye, Arno. > > > -- +---------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network & System Engineer | 3237 Holden Road | Give me Linux | | jiml at system-techniques.com | Fairbanks, AK. 99709 | only on AXP | +---------------------------------------------------------------------+ From woods at robohack.ca Fri Feb 28 15:08:46 2025 From: woods at robohack.ca (Greg A. Woods) Date: Thu, 27 Feb 2025 21:08:46 -0800 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> Message-ID: At Thu, 27 Feb 2025 17:55:49 -0500, Henry Bent wrote: Subject: [TUHS] Re: Having dickens of a time compiling gcc-4.4.7 on tru64 . > > On Thu, Feb 27, 2025, 17:07 Phil Budne wrote: > > > Arrigo Triulzi wrote: > > > > My recall is that 4.2BSD would only give you (writable) memory it > > could allocate swap space for. > > > > I think of the penchant for "overcommitting" memory > > (and the cold hand of the OOM killer) as Linuxisms I'm pretty sure over-commit in virtual memory systems is older than linux, and of course it's common in the BSDs now too. Windows-NT did it, as did early AIX. IBM'S VM does it, as do many other virtual machine supervisors. Unix System V may even have done it. I don't know where it originated, and I couldn't find a quick reference online just now to give a history of it, but likely someone here does. AIX also had an "OOM" killer (but I think it was the paging system itself, no a user-level process) -- which in early releases (the first version 3 on RS/6000 in 1989 or 1990) just tromped on the biggest process, which was usually the Xserver. I seem to remember the system rebooting if X died too. Even earlier (for the RT) IBM had invented SIGDANGER to warn of a pending OOM condition. Big users of memory could catch SIGDANGER and know they had to release some memory if they could. I think catchers of SIGDANGER would avoid the early SIGKILLs too, but I don't believe the Xserver tried to catch SIGDANGER, at least not in early releases. Some systems, e.g. macOS (nee OS X) somewhat solved the problem by simply adding more swap space dynamically by creating files in the root filesystem (until the disk fills). -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From usotsuki at buric.co Fri Feb 28 16:12:50 2025 From: usotsuki at buric.co (Steve Nickolas) Date: Fri, 28 Feb 2025 01:12:50 -0500 (EST) Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> Message-ID: Random but related. I've always called the OOM killer the Grim Memory Reaper; is that weird? -uso. From lars at nocrew.org Fri Feb 28 16:55:57 2025 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 28 Feb 2025 06:55:57 +0000 Subject: [TUHS] VM over-commit (and the OOM killers) In-Reply-To: (Steve Nickolas's message of "Fri, 28 Feb 2025 01:12:50 -0500 (EST)") References: <47fd2ec1-5896-31a4-8dd5-b91a1c0f8354@baby-dragons.com> <202502272206.51RM6AUB026294@ultimate.com> Message-ID: <7wbjumlfr6.fsf@junk.nocrew.org> Steve Nickolas wrote: > I've always called the OOM killer the Grim Memory Reaper; is that weird? No, it's not weird. Elsewhere in computer history there was also the "Grim File Reaper" (or often just "GFR"), which took care of moving rarely used files from disk to tape storage. I think it's appropriate to honor this usage.