From moody at posixcafe.org Tue Oct 1 01:00:31 2024 From: moody at posixcafe.org (Jacob Moody) Date: Mon, 30 Sep 2024 10:00:31 -0500 Subject: [TUHS] On computerese In-Reply-To: References: <20240915214847.63D5F18C079@mercury.lcs.mit.edu> <1256d60f-5a1b-de93-6633-642b572aab35@horsfall.org> <20240916232457.GS29162@mcvoy.com> <202409170554.48H5sduP148200@freefriends.org> <202409300816.48U8GuKj303510@freefriends.org> Message-ID: <980281fd-8377-4780-bddc-cb0cd2ed6ff0@posixcafe.org> On 9/30/24 07:10, Russ Cox wrote: > On Mon, Sep 30, 2024 at 4:17 AM > wrote: > > > One of the tidyings I did during covid lockdown was to rewrite > > rc's parser not to use yacc anymore [1], specifically to make > > it easy to allow "foo x=y". As I wrote in the commit message, > > dd fans rejoice! (Also fans of -foo=bar flag syntax.) > > Very cool. Have other Plan 9 distros picked this up? Just wondering. > > > I looked at https://9p.io/plan9/ and also 9front and neither has the change. > I don't think either is particularly maintained at this point. Since (and including) 2020, 9front has averaged 700 commits a year to the project, a very large portion of that being bug fixes and upkeep. We've also been presenting some of the more interesting new work at recent IWP9 conferences, now that they've become a yearly occurrence again thanks to the Plan 9 Foundation. From my perspective things have been quite lively lately. We did take a look at your rc parser changes (closer to when they were first pushed to plan9port) but had decided not to adopt them at the time. Thank you, Jacob Moody From paul.winalski at gmail.com Tue Oct 1 01:49:28 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 30 Sep 2024 11:49:28 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928180559.GF9067@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180559.GF9067@mcvoy.com> Message-ID: [moving to COFF as this has drifted away from Unix] On Sat, Sep 28, 2024 at 2:06 PM Larry McVoy wrote: > I have a somewhat different view. I have a son who is learning to program > and he asked me about C. I said "C is like driving a sports car on a > twisty mountain road that has cliffs and no guard rails. If you want to > check your phone while you are driving, it's not for you. It requires > your full, focussed attention. So that sounds bad, right? Well, if > you are someone who enjoys driving a sports car, and are good at it, > perhaps C is for you." > > If you really want a language with no guard rails, try programming in BLISS. Regarding C and C++ having dangerous language features--of course they do. Every higher-level language I've ever seen has its set of toxic language features that should be avoided if you want reliability and maintainability for your programs. And a set of things to avoid if you want portability. Regarding managed dynamic memory allocation schemes that use garbage collection vs. malloc()/free(), there are some applications where they are not suitable. I'm thinking about real-time programs. You can't have your missle defense software pause to do garbage collection when you're trying to shoot down an incoming ballistic missile. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Oct 1 02:05:52 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 30 Sep 2024 12:05:52 -0400 Subject: [TUHS] On computerese In-Reply-To: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Sat, Sep 28, 2024 at 8:49 PM Aron Insinga wrote: > For the counter-example, I wonder if anyone ever tried to type very much > (verbose) DCL on VAX/VMS using a Teletype. :-) > > I had occasion to use an ASR model 33 Teletype with VAX/VMS. Hated it. The DECwriter LA36 was acceptable, though. While DCL commands generally involved complete words, they could be abbreviated to the smallest unique abbreviation. Thus one mostly typed DIR instead of DIRECTORY. Command keywords also were be required to be unique in the first 4 characters--the DCL parser ignored all but the first four. characters. The engineers at DEC's Marlboro MA facility named one of their networked machines TWINKIE so that to log into it they could type SET HOSTESS TWINKIE. The terse Unix command verb style can be a steep learning curve for beginners. How is one supposed to know that you say 'ls' to get a directory listing? And unfortunately man pages aren't very useful for beginners because you have to know what the command verb is in order to call up its man page. Unix lacks a place to ask questions such as "how do I get a directory listing?". -Paul W. -Paul W. > > On 9/15/24 16:43, sjenkin at canb.auug.org.au wrote: > > ... > For non touch typists, shorter commands & keywords are helpful. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Tue Oct 1 04:07:17 2024 From: crossd at gmail.com (Dan Cross) Date: Mon, 30 Sep 2024 14:07:17 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, Sep 30, 2024 at 1:22 PM Paul Winalski wrote: > On Sat, Sep 28, 2024 at 8:49 PM Aron Insinga wrote: >> For the counter-example, I wonder if anyone ever tried to type very much (verbose) DCL on VAX/VMS using a Teletype. :-) >> > I had occasion to use an ASR model 33 Teletype with VAX/VMS. Hated it. The DECwriter LA36 was acceptable, though. > > While DCL commands generally involved complete words, they could be abbreviated to the smallest unique abbreviation. Thus one mostly typed DIR instead of DIRECTORY. Command keywords also were be required to be unique in the first 4 characters--the DCL parser ignored all but the first four. characters. The engineers at DEC's Marlboro MA facility named one of their networked machines TWINKIE so that to log into it they could type SET HOSTESS TWINKIE. > > The terse Unix command verb style can be a steep learning curve for beginners. How is one supposed to know that you say 'ls' to get a directory listing? And unfortunately man pages aren't very useful for beginners because you have to know what the command verb is in order to call up its man page. Unix lacks a place to ask questions such as "how do I get a directory listing?". This makes me wonder when the `apropos` command was introduced; surely the name was also somewhat of an obscure joke ("what is apropos of listing a directory?" is not exactly the phrase that springs immediately to mind when wondering how to list a directory). But the other form of it, `man -k`, is reasonable. Plan 9 called the similar thing, `lookman`. - Dan C. From steffen at sdaoden.eu Tue Oct 1 05:12:16 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Sep 2024 21:12:16 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: Message-ID: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Rob Pike wrote in : |On Mon, Sep 30, 2024 at 2:56 AM Douglas McIlroy < |douglas.mcilroy at dartmouth.edu> wrote: |>>>> malloc(0) isn't undefined behaviour but implementation defined. |>>> |>>> In modern C there is no difference between those two concepts. |> |>> Can you explain more about your view |> |> There certainly is a difference, but in this case the practical |> implications are the same: avoid malloc(0). malloc(0) lies at the \ |> high end |> of a range of severity of concerns about implementation-definedness. \ |> At the |> low end are things like the size of ints, which only affects applications |> that may confront very large numbers. In the middle is the default |> signedness of chars, which generally may be mitigated by explicit type |> declarations. |> |> For the size of ints, C offers guardrails like INT_MAX. There is no test |> to discern what an error return from malloc(0) means. |> |> Is there any other C construct that implementation-definedness renders |> useless? |Gradually the writers of optimizing compilers have leaned so hard on the |implementation-defined and undefined behaviors that, while far from |useless, C and C++ have become non-portable and dangerously insecure, as |well as often very surprising to the point that the US government arguing |against using them. Never attribute to malice what can adequately be explained by incompetence. is the signature of Poul-Henning Kamp (whose email regarding that cstr list (i did not yet have TM-74-1273-1 aka the C Reference Manual as of 1974-01-15, thank you!) was forwarded by Warren). Only propaganda left everywhere, including here, namely for Rust. But your statement in particular reminds me of "Who's afraid of a big bad optimizing compiler?" of LWN.net, from July 15, 2019. It may be fun to read by some. (Offline, searching surely works.) It ends with Acknowledgments We owe thanks to a surprisingly large number of compiler writers and members of the C and C++ standards committees who introduced us to some of the things a big bad optimizing compiler can do,[.] But i think those eh people there (that US government) surely have been hammered with "memory-safe language" a thousand times, and noone ever told them that even the eldest C can be used in a safe way; on freebsd-hackers (PHK is an early FreeBSD committer) there was one of their bikeshed threads around September 5th, after several CVEs where fixed, and another long time major contributor started a thread saying things like |>|The real takeaway here is that C is no longer sufficient for writing |>|high quality code in the 2020s. Everyone needs to adapt their tools. which (also) i (not FreeBSD, only by heart, maybe) spoke against. He was hailing Option>> or Vec::with_capacity(262144) as solutions to the CVEs. (Which, as far as i looked, had nothing really to do with C as such; one "guilty" programmer said, as far as i understood that, the same for "his CVE".) Vectors and string "objects" with (optionally) checked index access and such are uncomfortable, but easy to do, also with C, and right from the start (i said). (P.S.: i miss bit enumerations in C and C++, as compilers get stricter and stricter (you cannot even enum1|enum2 without warnings no more, in i think C23; without cast, of course), but bit flags "can" only come in via preprocessor constants, and are completely unchecked. And enum1|enum2 *i* often have, if some subtype adds flags on top of a basic type, isn't that natural, no support on that front. And cast-less "super class casts". I had not downloaded cstr#108-the_c++_programming_language yet.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From henry.r.bent at gmail.com Tue Oct 1 05:15:27 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 30 Sep 2024 15:15:27 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > > This makes me wonder when the `apropos` command was introduced; surely > the name was also somewhat of an obscure joke ("what is apropos of > listing a directory?" is not exactly the phrase that springs > immediately to mind when wondering how to list a directory). > Looks like it was introduced in 2BSD, written by Bill Joy, though the 4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD source nor manpage are particularly enlightening about the choice of name. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From halbert at halwitz.org Tue Oct 1 06:00:55 2024 From: halbert at halwitz.org (Dan Halbert) Date: Mon, 30 Sep 2024 16:00:55 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On 9/30/24 15:15, Henry Bent wrote: > On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > > > This makes me wonder when the `apropos` command was introduced; surely > the name was also somewhat of an obscure joke ("what is apropos of > listing a directory?" is not exactly the phrase that springs > immediately to mind when wondering how to list a directory). > > > Looks like it was introduced in 2BSD, written by Bill Joy, though the > 4.4BSD manpage claims that it was introduced in 3BSD.  Neither the BSD > source nor manpage are particularly enlightening about the choice of name. I was one of the Berkeley grad students in the office with Bill Joy around this time. I think the name probably  come from the "apropos" command in Emacs. That command is mentioned here: https://worrydream.com/refs/Stallman_1979_-_EMACS,_The_Extensible,_Customizable,_Self-Documenting_Display_Editor.pdf, which is dated June 1979, but the Emacs command existed before that date. The Berkeley source code is dated 1979: https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/apropos.c I had used Emacs at MIT as an undergraduate. Bill would sometimes ask me, "how do they do that in Emacs", or ITS, and then riff on a feature and put it into vi or whatever. Whether I suggested an "apropos" Unix command or someone wanted something like that, or I said, "sounds like 'apropos' in Emacs", I don't remember. Dan H -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.salz at gmail.com Tue Oct 1 06:03:15 2024 From: rich.salz at gmail.com (Rich Salz) Date: Mon, 30 Sep 2024 16:03:15 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930191216.tIpea9lo@steffen%sdaoden.eu> References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso wrote > noone ever told them that even the eldest C can be used in a safe > way; Perhaps we have different meanings of the word safe. void foo(char *p) { /* interesting stuff here */ ; free(p); } void bar() { char *p = malloc(20); foo(p); printf("foo is %s\n", p); foo(p); } Why should I have to think about this code when the language already knows what is wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Tue Oct 1 06:11:27 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 30 Sep 2024 16:11:27 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, 30 Sept 2024 at 16:01, Dan Halbert wrote: > On 9/30/24 15:15, Henry Bent wrote: > > On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > >> >> This makes me wonder when the `apropos` command was introduced; surely >> the name was also somewhat of an obscure joke ("what is apropos of >> listing a directory?" is not exactly the phrase that springs >> immediately to mind when wondering how to list a directory). >> > > Looks like it was introduced in 2BSD, written by Bill Joy, though the > 4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD > source nor manpage are particularly enlightening about the choice of name. > > > I was one of the Berkeley grad students in the office with Bill Joy around > this time. I think the name probably come from the "apropos" command in > Emacs. That command is mentioned here: > https://worrydream.com/refs/Stallman_1979_-_EMACS,_The_Extensible,_Customizable,_Self-Documenting_Display_Editor.pdf, > which is dated June 1979, but the Emacs command existed before that date. > The Berkeley source code is dated 1979: > https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/apropos.c > > I had used Emacs at MIT as an undergraduate. Bill would sometimes ask me, > "how do they do that in Emacs", or ITS, and then riff on a feature and put > it into vi or whatever. Whether I suggested an "apropos" Unix command or > someone wanted something like that, or I said, "sounds like 'apropos' in > Emacs", I don't remember. > That definitely tracks with an outlier I turned up in my search of sources, an "apropos.doc" that appears on the CSRG DVD with the sources for CMU Emacs. It's just a list of mappings from commands to keybindings, for example: ... delete-next-character ^D delete-next-word ESC-D delete-other-windows ^X1 delete-previous-character ^H delete-previous-character RUBOUT ... I'm not particularly an Emacs person, but it looks like it could be the output from an "apropos" command, or perhaps the input to it. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rik at rikfarrow.com Tue Oct 1 06:14:48 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Mon, 30 Sep 2024 13:14:48 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240930191216.tIpea9lo@steffen%sdaoden.eu> References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: This is the 'problem' with C/C++: it's not the language itself so much as the people who are allowed, or forced, to use it. Many, if not all, of the people on this list have worked with great programmers, when most programmers are average at best. I saw some terrible things back when doing technical sales support for a startup selling a graphics library with C bindings. I came away convinced that most of the 'programmers' I was training were truly clueless. Rik On Mon, Sep 30, 2024 at 12:12 PM Steffen Nurpmeso > Never attribute to malice what can adequately be explained by > incompetence. > > is the signature of Poul-Henning Kamp (whose email regarding that > cstr list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Oct 1 06:39:07 2024 From: clemc at ccc.com (Clem Cole) Date: Mon, 30 Sep 2024 16:39:07 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: On Mon, Sep 30, 2024 at 4:01 PM Dan Halbert wrote: > I was one of the Berkeley grad students in the office with Bill Joy around > this time. > IIRC Dark curly hair, and I can not think of his name either. I bet if I saw a picture, I could identify him. apropos(1) was a great hack, but I always thought whoever came up with locate(1) really hit the jackpot. ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Oct 1 06:51:00 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Sep 2024 22:51:00 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Henry Bent wrote in : |On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: |> This makes me wonder when the `apropos` command was introduced; surely |> the name was also somewhat of an obscure joke ("what is apropos of |> listing a directory?" is not exactly the phrase that springs |> immediately to mind when wondering how to list a directory). |> | |Looks like it was introduced in 2BSD, written by Bill Joy, though the |4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD |source nor manpage are particularly enlightening about the choice of name. "a pro position" maybe. (Having said that #?0|kent:linux$ apropos 'directory list' CURLOPT_DIRLISTONLY (3) - ask for names only in a directory listing vs #?0|kent:linux$ apropos 'list directory' dir (1) - list directory contents ls (1) - list directory contents ls (1p) - list directory contents vdir (1) - list directory contents vs #?0|kent:linux$ apropos -a list directory chacl (1) - change the access control list of a file or directory CURLOPT_DIRLISTONLY (3) - ask for names only in a directory listing dir (1) - list directory contents ls (1) - list directory contents ls (1p) - list directory contents vdir (1) - list directory contents vs #?0|kent:linux$ apropos -a directory list ..same.. needs a "pro user" from the start; AI would instead and additionally clean your back i would assume. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From steffen at sdaoden.eu Tue Oct 1 07:15:39 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 30 Sep 2024 23:15:39 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <20240930211539.94nSvOdZ@steffen%sdaoden.eu> Rich Salz wrote in : |On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso wrote |> noone ever told them that even the eldest C can be used in a safe |> way; | |Perhaps we have different meanings of the word safe. | | void foo(char *p) { /* interesting stuff here */ ; free(p); } | void bar() { char *p = malloc(20); | foo(p); | printf("foo is %s\n", p); | foo(p); |} |Why should I have to think about this code when the language already knows |what is wrong. It can also be used in an unsafe way? O-ha. Sounds dangerous in my ears (given human behaviour in particular). I was so focused on winning against Putin, .. that i did realize this context. (Btw i like The Cures new song "Alone", after 14 years!, and its accompanying thrilling mega mega boom boom boom video.) P.S.: In the real world i would now, as the conservative and integer (up against the floating-point!) person that i am point "you" to C++, and simply pass a string object. But let us pass a reference so we gain compile-time non-NIL "meat" (vegan!!), and impressive state-of-the-art speed characteristics. Human behaviour can destroy everything: faster so with C++! --End of Btw i hate these random message-ids, they reveal nothing! Like in all those rooms i never visit. I am all for the wonderful Klaus von Dohnanyi, now also 96 years old, and his saying "Ach bitte, sagen Sie nicht Chatroom, sagen Sie Plauderstübchen" ("Oh please, do not say chatroom, just say [little talk chamber][ʃtyːpçən]" [1] (needs scripting-enabled browser). [1] https://translate.google.com/?sl=auto&tl=en&text=Plauderst%C3%BCbchen&op=translate --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From henry.r.bent at gmail.com Tue Oct 1 07:25:09 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 30 Sep 2024 17:25:09 -0400 Subject: [TUHS] On computerese In-Reply-To: <20240930205100.iOO2gbzi@steffen%sdaoden.eu> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Message-ID: On Mon, 30 Sept 2024 at 16:51, Steffen Nurpmeso wrote: > Henry Bent wrote in > : > |On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: > |> This makes me wonder when the `apropos` command was introduced; surely > |> the name was also somewhat of an obscure joke ("what is apropos of > |> listing a directory?" is not exactly the phrase that springs > |> immediately to mind when wondering how to list a directory). > |> > | > |Looks like it was introduced in 2BSD, written by Bill Joy, though the > |4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD > |source nor manpage are particularly enlightening about the choice of > name. > > "a pro position" maybe. > > needs a "pro user" from the start; AI would instead and > additionally clean your back i would assume. > Well, I no longer have institutional access to the full Oxford English Dictionary, but Merriam Webster is happy to provide an extended paragraph (!) on the etymology: -- *Apropos* wears its ancestry like a badge—or a beret. From the French phrase *à propos*, meaning “to the purpose,” the word’s emphasis lands on its last syllable, which ends in a silent “s”: \ap-ruh-POH. *Apropos* typically functions as an adjective describing what is suitable or appropriate (“an apropos comment”), or as a preposition (with or without *of*) meaning “with regard to,” as in “apropos (of) the decision, implementation will take some time.” The phrase “apropos of nothing” suggests that something does not relate to a specified topic. -- -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Tue Oct 1 08:00:35 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Oct 2024 00:00:35 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <20240930220035.3nZHrUot@steffen%sdaoden.eu> Rik Farrow wrote in : |On Mon, Sep 30, 2024 at 12:12 PM Steffen Nurpmeso  | || Never attribute to malice what can adequately be explained by || incompetence. | ||is the signature of Poul-Henning Kamp (whose email regarding that ||cstr list |This is the 'problem' with C/C++: it's not the language itself so much as |the people who are allowed, or forced, to use it. Many, if not all, of the |people on this list have worked with great programmers, when most |programmers are average at best. I saw some terrible things back when doing |technical sales support for a startup selling a graphics library with C |bindings. I came away convinced that most of the 'programmers' I was |training were truly clueless. I cannot comment on that, humans "get a good job with more pay you are ok", have interests here and there, have (unfulfilled) desires, problems with family or partner, aka "that sex machine", and so in the end one can be lucky if that was not Jeffrey Dahmer or something, and you do not end up as canned. "Or forced", yes! Here on this lists are (me aside) intellectual but especially witty people who love(d) their (likely) even-more-than-a-job, at the "top of the pyramid", Mr. McIlroy just again remembered an impressive scenario of how these people were (and are) self-driving up that spiral staircase with nothing but the help of their mind and a free library .. which was available for them. Other than that, you know, there are plenty of languages with plenty of support (syntax checks, sanitizers, "debug stuff"), far beyond vim(1), let that start with JAVA (documented pretty well right from the start as far as i know), and all the other options that arose since then, and in parts are used. I personally "go on the gums" if i have to work with OpenSSL, and image processing is no fun either, so it could be it was me who drove you down... (And complexity is never easy, i think, to noone.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Tue Oct 1 08:14:38 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 30 Sep 2024 15:14:38 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Sep 30, 2024, at 1:03 PM, Rich Salz wrote: > > > On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso wrote > noone ever told them that even the eldest C can be used in a safe > way; > Perhaps we have different meanings of the word safe. > > void foo(char *p) { /* interesting stuff here */ ; free(p); } > void bar() { char *p = malloc(20); > foo(p); > printf("foo is %s\n", p); > foo(p); > } > Why should I have to think about this code when the language already knows what is wrong. The language doesn't know! The compiler can't know without the programmer indicating this somehow, especially if foo() is an extern function. I am still interested in making C safer (to secure as best as possible all the zillions of lines of C code in OS kernels). The question is, can we retrofit safety features into C without doing major violence to it & turning it into an ugly mess? No idea if this is even feasible but seems worth exploring with possibly a great ROI. Take the above code as an example. It is "free()" that invalidates the value of its argument on return and this property is then inherited by its callers. One idea is to declare free as follows: void free(`zap void*ptr); // `zap is says *ptr will be invalid on return Now a compiler can see and complain that foo() will break this and insist that foo() too must express the same thing. So we change it to void foo(`zap char* p) { ... free(p); } Now the compiler knows p can't dereferenced after calling foo() and can complain on seeing p being printf'ed. This was just an example of an idea -- remains to be seen if it amounts to anything useful. In an earlier email I had explored bounds checking. Clearly all such extensions would have to play well together as well as with the existing language. My hope is that the language can be evolved in this way and gradually kernel code can be fixed up to benefit from it. Bakul From steffen at sdaoden.eu Tue Oct 1 08:38:00 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 01 Oct 2024 00:38:00 +0200 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Message-ID: <20240930223800.Z9vdkp7Q@steffen%sdaoden.eu> Henry Bent wrote in : |On Mon, 30 Sept 2024 at 16:51, Steffen Nurpmeso wrote: |> Henry Bent wrote in |> : |>|On Mon, 30 Sept 2024 at 14:08, Dan Cross wrote: |>|> This makes me wonder when the `apropos` command was introduced; surely |>|> the name was also somewhat of an obscure joke ("what is apropos of |>|> listing a directory?" is not exactly the phrase that springs |>|> immediately to mind when wondering how to list a directory). |>| |>|Looks like it was introduced in 2BSD, written by Bill Joy, though the |>|4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD |>|source nor manpage are particularly enlightening about the choice of |> name. |> |> "a pro position" maybe. |> |> needs a "pro user" from the start; AI would instead and |> additionally clean your back i would assume. | |Well, I no longer have institutional access to the full Oxford English |Dictionary, but Merriam Webster is happy to provide an extended paragraph |(!) on the etymology: Oh! Apropos is known in Germany as a (*that*) word, too, also commonly heard, even in the (upper) middle class, but sounding like "apro-poh" here. Ef "Apropos -- have i already" etc etc. I was "only leaving of the e of that creat", so to say. (I am not looking at the online "Duden" because they now require Javascript and tracking, if i recall correctly.) |-- |*Apropos* wears its ancestry like a badge—or a beret. From the French |phrase *à propos*, meaning “to the purpose,” the word’s emphasis lands on |its last syllable, which ends in a silent “s”: \ap-ruh-POH. *Apropos* |typically functions as an adjective describing what is suitable or |appropriate (“an apropos comment”), or as a preposition (with or without |*of*) meaning “with regard to,” as in “apropos (of) the decision, |implementation will take some time.” The phrase “apropos of nothing” |suggests that something does not relate to a specified topic. |-- | |-Henry --End of --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Tue Oct 1 08:46:44 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Mon, 30 Sep 2024 15:46:44 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <20240930205100.iOO2gbzi@steffen%sdaoden.eu> Message-ID: Apropos of apropos: https://www.etymonline.com/search?q=apropos etymonline.com is my goto etymological dictionary site. > On Sep 30, 2024, at 2:25 PM, Henry Bent wrote: > > On Mon, 30 Sept 2024 at 16:51, Steffen Nurpmeso > wrote: >> Henry Bent wrote in >> >: >> |On Mon, 30 Sept 2024 at 14:08, Dan Cross > wrote: >> |> This makes me wonder when the `apropos` command was introduced; surely >> |> the name was also somewhat of an obscure joke ("what is apropos of >> |> listing a directory?" is not exactly the phrase that springs >> |> immediately to mind when wondering how to list a directory). >> |> >> | >> |Looks like it was introduced in 2BSD, written by Bill Joy, though the >> |4.4BSD manpage claims that it was introduced in 3BSD. Neither the BSD >> |source nor manpage are particularly enlightening about the choice of name. >> >> "a pro position" maybe. >> >> needs a "pro user" from the start; AI would instead and >> additionally clean your back i would assume. > > Well, I no longer have institutional access to the full Oxford English Dictionary, but Merriam Webster is happy to provide an extended paragraph (!) on the etymology: > > -- > Apropos wears its ancestry like a badge—or a beret. From the French phrase à propos, meaning “to the purpose,” the word’s emphasis lands on its last syllable, which ends in a silent “s”: \ap-ruh-POH. Apropos typically functions as an adjective describing what is suitable or appropriate (“an apropos comment”), or as a preposition (with or without of) meaning “with regard to,” as in “apropos (of) the decision, implementation will take some time.” The phrase “apropos of nothing” suggests that something does not relate to a specified topic. > -- > > -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at ultimate.com Tue Oct 1 09:25:28 2024 From: phil at ultimate.com (Phil Budne) Date: Mon, 30 Sep 2024 19:25:28 -0400 Subject: [TUHS] Origins of "Unix Philosophy" Message-ID: <202409302325.48UNPSfs020034@ultimate.com> I'm wondering if there are places where people who were in the Unix Room wrote about the origins and evolution of what people (at least used to(*)) refer to as "Unix Philosophy", and since some are in THIS (TUHS) room, what they might have to say about it. How much was in reaction to the complexity of Multics, and how much was simply a response to the limited address spaces of available and affordable hardware? Eric S. Raymond wrote in "The Art of Unix Programming" quoting Doug McIlroy and Rob Pike: http://www.catb.org/esr/writings/taoup/html/ch01s06.html And I wonder if they care to comment on it? I have trouble taking ESR as authoritative, as, it seems to me that Research Unix was more a product of the "Cathedral" (or at least a contained community) than the "Bazaar" (at least the modern bazaar, where everyone needs to leave a new feature grafito on the town walls), and ESR A side question for Rob Pike, is the "Not only is UNIX dead, it's starting to smell really bad." quote accurate? Was it in reaction to BSD, GNU, or all of the above? (*) I say "used to", because, for the most part, minimalism seems to have left the building. I can't look at modern GNU utilities, and many, if not most open source packages and think they've gone WAY past classic Unix minimalism, especially since I remember hearing that Bell Research had happily stripped excess features (removal of "cat -s" sticks in my mind) from later day research Unix, and because Stallman is said to have coined the term "New Jersey" style as a synonym for what Richard P. Gabriel called "Worse is Better", which seems, an attack on minimalism (nothing less than "the right thing" is acceptable) Worse is.... readings: https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/RiseOfWorseIsBetter.html https://dreamsongs.com/Files/IsWorseReallyBetter.pdf https://dreamsongs.com/Files/worse-is-worse.pdf Anti-flamage disclainmers: Inclusion of links above does not imply any agreement on my part! My apologies in advance for any offense, misquote, or misunderstanding on my part. From flexibeast at gmail.com Tue Oct 1 11:42:00 2024 From: flexibeast at gmail.com (Alexis) Date: Tue, 01 Oct 2024 11:42:00 +1000 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: (Bakul Shah via TUHS's message of "Mon, 30 Sep 2024 15:14:38 -0700") References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <87setgzjiv.fsf@gmail.com> Bakul Shah via TUHS writes: > I am still interested in making C safer (to secure as best as > possible > all the zillions of lines of C code in OS kernels). The question > is, > can we retrofit safety features into C without doing major > violence to > it & turning it into an ugly mess? No idea if this is even > feasible > but seems worth exploring with possibly a great ROI. Related: Ten years ago, Pascal Cuoq, Matthew Flatt, and John Regehr proposed "Friendly C": > We are not trying to fix the deficiencies of the C language nor > making > an argument for or against C. Rather, we are trying rescue the > predictable little language that we all know is hiding within > the C > standard. This language generates tight code and doesn’t make > you feel > like the compiler is your enemy. We want to decrease the rate of > bit > rot in existing C code and also to reduce the auditing overhead > for > safety-critical and security-critical C code. The intended > audience > for -std=friendly-c is people writing low-level systems such as > operating systems, embedded systems, and programming language > runtimes. These people typically have a good guess about what > instructions the compiler will emit for each line of C code they > write, and they simply do not want the compiler silently > throwing out > code. If they need code to be faster, they’ll change how it is > written. -- https://blog.regehr.org/archives/1180 Some of the concrete features proposed included: > 1. The value of a pointer to an object whose lifetime has ended > remains the same as it was when the object was alive. > > 2. Signed integer overflow results in two’s complement wrapping > behavior at the bitwidth of the promoted type. > > 3. Shift by negative or shift-past-bitwidth produces an > unspecified > result. i seem to recall there have been other proposals in the vein of "Friendly C", but they're not coming to mind right now. Alexis. From lars at nocrew.org Tue Oct 1 14:31:12 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 01 Oct 2024 04:31:12 +0000 Subject: [TUHS] On computerese In-Reply-To: (Dan Halbert's message of "Mon, 30 Sep 2024 16:00:55 -0400") References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: <7w7caswijz.fsf@junk.nocrew.org> Dan Halbert wrote: > I had used Emacs at MIT as an undergraduate. Bill would sometimes ask > me, "how do they do that in Emacs", or ITS, and then riff on a feature > and put it into vi or whatever. Whether I suggested an "apropos" Unix > command or someone wanted something like that, or I said, "sounds like > 'apropos' in Emacs", I don't remember. I'm curious if you remember any other features that Bill might have picked up from Emacs or ITS? From you or anyone else. Another interesting example would be job control that was done by Jim Kulp. From lars at nocrew.org Tue Oct 1 14:44:47 2024 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 01 Oct 2024 04:44:47 +0000 Subject: [TUHS] Origins of "Unix Philosophy" In-Reply-To: <202409302325.48UNPSfs020034@ultimate.com> (Phil Budne's message of "Mon, 30 Sep 2024 19:25:28 -0400") References: <202409302325.48UNPSfs020034@ultimate.com> Message-ID: <7w34lgwhxc.fsf@junk.nocrew.org> Phil Budne wrote: > Stallman is said to have coined the term "New Jersey" style as a > synonym for what Richard P. Gabriel called "Worse is Better" Do you have a source for this? Gabriel does write "New Jersey Style" in his essay. Of course, he could have got it from Stallman anyway. From arnold at skeeve.com Tue Oct 1 22:43:20 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 06:43:20 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930003630.GE17434@mcvoy.com> Message-ID: <202410011243.491ChKiV419651@freefriends.org> Luther Johnson wrote: > 'Go' is also a pretty C-like advanced C kind of thing. What do Go > writers think of it vs. C, for safety, reliability, clarity of > expression, etc. ? I have what to say about the topics in this thread, but I wanted to answer this. I've been working in Go for about two years in my current $DAYJOB. I haven't done as much of it as I'd like. As preface, I've been programming (heavily) in C since 1983 and quite a fair amount in C++ since 1999 or so, with Python in the mix more recently. Overall, I like Go. The freedom from manual memory management takes some getting used to, but is very liberating once you do. I do find it too terse in some cases, mostly in the initialization syntax, and in the use of nested function objects. I also find Go modules to be totally opaque, I don't understand them at all. One thing I'm still getting used to is the scoping with := vs. =. Here's a nasty bug that I just figured out this week. Consider: var ( clientSet *kubernetes.Interface ) func main() { .... // set the global var (we think) clientSet, err := cluster.MakeClient() // or whatever .... } func otherfunc() { // use the global var (but not really) l := clientSet.CoreV1().NetworkPolicyList(ns).Items } In main(), I *think* I'm assigning to the global clientSet so that I can use it later. But because of the 'err' and the :=, I've actually created a local variable that shadows the global one, and in otherfunc(), the global clientSet is still nil. Kaboom! The correct way to write the code is: var err error clientSet, err = cluster.MakeClient() // or whatever "When the light went on, it was blinding." Of course, the Goland IDE actually warns me that this is the case, by changing the color of clientSet in the assignment, but it's an extremely subtle warning, and if you don't hover over it, and you're not paying a lot of attention to the coloring, you miss it. So, I like Go, and for a new project that I wouldn't write in Awk or Python, I would use Go. The time or two I've looked at Rust, it seemed to be just too difficult to learn, as well as still evolving too fast. It does look like Rust will eventually replace C and C++ for new systems level code. We can hope that will be a good thing. My two cents, Arnold From crossd at gmail.com Tue Oct 1 22:53:46 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Oct 2024 08:53:46 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Mon, Sep 30, 2024 at 4:22 PM Rik Farrow wrote: > This is the 'problem' with C/C++: it's not the language itself so much as the people who are allowed, or forced, to use it. Programmer ability is certainly an issue, but I would suggest that another goes back to what Rob was alluding to: compiler writers have taken too much advantage of UB, making it difficult to write well-formed programs that last. The `realloc` function I mentioned earlier is a good case in point; the first ANSI C standard says this: "If ptr is a null pointer, the realloc function behaves like the malloc function for the specified size. ... If size is zero and ptr is not a null pointer, the object it points to is freed." While the description of `malloc` doesn't say thing about what happens when `size` is 0, perhaps making `realloc(0, NULL)` nominally UB (??), the behavior of `realloc(0, ptr)` is clearly well defined when `ptr` is not nil, and it's entirely possible that programs were written with that well-defined behavior as an assumption. (Worth mentioning is that this language was changed in C99, and implementations started differing from there.) But now, C23 has made `realloc(0, ptr)` UB, regardless of the value of `ptr`, and since compiler writers have given themselves license to take an extremely broad view of what they can do if a program exhibits UB, programs that were previously well-defined with respect to C90 may well stop working properly when compiled with modern compilers. I don't think this is a hypothetical; C programs that appear to be working as expected for years have, and will continue, to suddenly break when compiled with a newer compiler, because the programmer tripped a UB trigger somewhere along the way, likely without even recognizing it. Moreover, I don't believe that there are any non-trivial C programs out there that don't have such timebombs lurking throughout. How could they not, if things that were previously well-defined can become UB in subsequent revisions of the standard? Perhaps I've mentioned it before, but a great example of the surprising nature of UB is the following program: unsigned short mul(unsigned short a, unsigned short b) { return a * b; } Is this tiny function always well-defined? Sadly, no, at least not on most common platforms where `int` is 32 bits and `short` is 16. On such platforms, the "usual arithmetic conversions" will kick in before the multiplication, and the values will be converted to _signed_ ints and _then_ multiplied; the product will then be converted back to `unsigned short`. And while the type conversion process both ways is well-defined, there exist values a,b of type unsigned short so that a*b will overflow a signed 32-bit int (consider 0xffff*0xffff), and signed integer overflow is UB; a compiler would be well within its rights to assume that such overflow can never occur and generate, say, a saturating multiplication instruction if it so chose. This would work, be perfectly legal, and almost certainly be surprising to the programmer. The fix is simple, of course: unsigned short mul(unsigned short a, unsigned short b) { unsigned int aa = a, bb = b; return aa * bb; } But one would have to know to write such a thing in the first place. > Many, if not all, of the people on this list have worked with great programmers, when most programmers are average at best. I saw some terrible things back when doing technical sales support for a startup selling a graphics library with C bindings. I came away convinced that most of the 'programmers' I was training were truly clueless. My sense is that tossing in bad programmers is just throwing gasoline onto a dumpster fire. Particularly when they look to charlatans like Robert Martin or Allen Holub as sources of education and inspiration instead of seeking out proper sources of education. - Dan C. From arnold at skeeve.com Tue Oct 1 23:13:04 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 07:13:04 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20240928180138.aygrwqdwrvq3n6xt@illithid> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> Message-ID: <202410011313.491DD4ac421643@freefriends.org> This is long, my apologies. "G. Branden Robinson" wrote: > [ screed omitted ] Branden, as they say, Hindsight is 20-20. But one needs to take into account that Unix and C evolved, and in particular on VERY small machines. IIRC the original Unix PDP-11s didn't even have split I/D spaces. Getting a decent compiler into that small an address space isn't easy (and by now is a lost art). The evolution was gradual and, shall we say "organic", without the pretension and formalisms of a language committee, but simply to meet the needs of the Bell Labs researchers. The value of a high level language for OS work was clear from Multics. But writing a PL/1 compiler from scratch for the tiny PDP-11 address space made no sense. Thus the path from BCPL to B to C. Today, new languages are often reactions to older ones. Java, besides the JVM portability, tried to clean up the syntax of C / C++ and add some safety and modernism (graphics, concurrency). C# was a reaction to (and a way to compete with) Java. Go was very clearly in reaction to current C++, but headed back in the direction of simplicity. Successfully, IMHO. Would the word have been better off if Ada had caught on everywhere? Probably. When I was in grad school studying language design, circa 1982, it was expected to do so. But the language was VERY challenging for compiler writers. C was easy to port, and then Unix along with it. C'est la vie. Larry wrote: > I have a somewhat different view. I have a son who is learning to program > and he asked me about C. I said "C is like driving a sports car on a > twisty mountain road that has cliffs and no guard rails. If you want to > check your phone while you are driving, it's not for you. It requires > your full, focussed attention. So that sounds bad, right? Well, if > you are someone who enjoys driving a sports car, and are good at it, > perhaps C is for you." This goes back to the evolution thing. At the time, C was a huge step up from FORTRAN and assembly. Programmers who moved to C appreciated all it gave them over what they had at the time. C programmers weren't wizards, they were simply using the best available tool. Going from a bicycle to an automobile is a big jump (to continue Larry's analogy). Larry again: > I ran a company that developed a product that was orders of magnitude more > complex than the v7 kernel (low bar but still) all in C and we had *NONE* > of those supposed problems. We were careful to use stuff that worked, > I'm "famous" in that company as the guy was viewed as "that was invented > after 1980 so Larry won't let us use it". Not true, we used mmap and used > POSIX signals, but mostly true. If you stick to the basics, C just works. > And is portable, we supported every Unix (even SCO), MacOS, Windows, and > all the Linux variants from ARM to IBM mainframes. This is also my experience with gawk, which runs on everything from ARM (Linux) to Windows to mac to VMS to z/OS (S/390x). OS issues give me more grief than language issues. > All that said, I get it, you want guard rails. You are not wrong, the > caliber of programmers these days are nowhere near Bell Labs or Sun or > my guys. This is a very important, key point. As more and more people have entered the field, the quality / education / knowledge / whatever has gone down. What was normal to learn and use back in 1983 is now too difficult for many, if not most, people, even good ones, in the field now. The people I work with here (Israel) don't know who Donald Knuth is. Two of the people in my group, over 40, didn't know what Emacs is. Shell scripting seems to be too hard for many people to master, and I see a huge amount of Cargo Cult Programming when it comes to things like scripts and Unix tools. Thus Go and Rust are good things, taking the sharp tools out of the hands of the people who aren't qualified to use them. Same thing Python. But for me, and I think others of my vintage, this state of affairs seems sad. My 4 cents, Arnold From lm at mcvoy.com Tue Oct 1 23:32:31 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Oct 2024 06:32:31 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: <20241001133231.GE13777@mcvoy.com> On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: > Would the word have been better off if Ada had caught on everywhere? > Probably. When I was in grad school studying language design, circa 1982, > it was expected to do so. But the language was VERY challenging for > compiler writers. Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. It was the compilers course (701) and the really hard compilers course (702) at the time. The first course was to write a compiler for a subset of Ada and the second on increased the subset to be almost complete. We were supposed to do it on an IBM mainframe because the professor had his own version of lex/yacc there. Rob had a 3b1 and asked if we could do it there if he rewrote the parser stuff. Prof said sure. In one semester we had a compiler, no optimizer and not much in the way of graceful error handling, but it compiled stuff that ran. We did all of Ada other than late binding of variables (I think that was Ada's templates) and threads and probably some other stuff I don't remember. Rob is pretty smart, went on to be a tenured prof at Brown before going back to industry. Maybe he did all the heavy lifting, but I didn't find that project to very challenging. Did I miss something? > This is a very important, key point. As more and more people have > entered the field, the quality / education / knowledge / whatever > has gone down. What was normal to learn and use back in 1983 is > now too difficult for many, if not most, people, even good ones, in > the field now. > > But for me, and I think others of my vintage, this state of affairs > seems sad. 100% agree. A sharp young kid I know is/was working on finding bugs in binaries. He came to me for some insight and I had to understand what he was doing and when I did, I kept saying "just hire people that don't do this stupid stuff" and he kept laughing at me and said it was impossible. I don't consider myself to be that good of a programmer, I can point to dozens of people my age that can run circles around me and I'm sure there are many more. But apparently the bar is pretty low these days and I agree, that's sad. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From halbert at halwitz.org Tue Oct 1 23:36:37 2024 From: halbert at halwitz.org (Dan Halbert) Date: Tue, 1 Oct 2024 09:36:37 -0400 Subject: [TUHS] On computerese In-Reply-To: <7w7caswijz.fsf@junk.nocrew.org> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <7w7caswijz.fsf@junk.nocrew.org> Message-ID: <96dd889c-5749-48dc-8ea5-8910f51ca966@halwitz.org> On 10/1/24 00:31, Lars Brinkhoff wrote: > Dan Halbert wrote: >> I had used Emacs at MIT as an undergraduate. Bill would sometimes ask >> me, "how do they do that in Emacs", or ITS, and then riff on a feature >> and put it into vi or whatever. Whether I suggested an "apropos" Unix >> command or someone wanted something like that, or I said, "sounds like >> 'apropos' in Emacs", I don't remember. > I'm curious if you remember any other features that Bill might have > picked up from Emacs or ITS? From you or anyone else. > > Another interesting example would be job control that was done by Jim > Kulp. A lot of the vi visual-mode commands were inspired by emacs, like forward/back words, sentences/statements, paragraphs/functions. I specifically remember explaining the hierarchy of  ctrl-f, meta-f, ctrl-meta-f, etc., and then Bill went off and put in '{' and '}' and similar commands. And the "yank" commands were named after ctrl-Y and other "yank" commands in emacs. Those are on the 2BSD tape. Earl Cohen did the "finger" command quite soon after our class of first year grad students arrived at UCB. It's in 2BSD. I did "more" really early (https://danhalbert.org/more.html), but my very simple version did not get back into the sources, and the reworked "more" that Eric Shienbrood did is in 3BSD but not 2BSD. Dan From arnold at skeeve.com Tue Oct 1 23:47:10 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 07:47:10 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001133231.GE13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> Message-ID: <202410011347.491DlAsJ423777@freefriends.org> Larry McVoy wrote: > On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: > > Would the word have been better off if Ada had caught on everywhere? > > Probably. When I was in grad school studying language design, circa 1982, > > it was expected to do so. But the language was VERY challenging for > > compiler writers. > > Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. > It was the compilers course (701) and the really hard compilers course (702) > at the time. The first course was to write a compiler for a subset of Ada > and the second on increased the subset to be almost complete. > > We were supposed to do it on an IBM mainframe because the professor had his > own version of lex/yacc there. Rob had a 3b1 and asked if we could do it > there if he rewrote the parser stuff. Prof said sure. > > In one semester we had a compiler, no optimizer and not much in the > way of graceful error handling, but it compiled stuff that ran. We did > all of Ada other than late binding of variables (I think that was Ada's > templates) and threads and probably some other stuff I don't remember. Did you do generics? That and the run time, which had some real-time bits to it (*IIRC*, it's been a long time), as well as the cross object code type checking, would have been real bears. Like many things, the first 90% is easy, the second 90% is hard. :-) > I don't consider myself to be that good of a programmer, I can point to > dozens of people my age that can run circles around me and I'm sure there > are many more. You are undoubtedly better than you give yourself credit for, even if there were people who could run circles around you. I learned a long time ago, that no matter how good you are, there's always someone better than you at something. I decided long ago to not try to compete with Superman. > But apparently the bar is pretty low these days and I agree, that's sad. And it makes it much less fun to be out in the working world. :-( Arnold From lm at mcvoy.com Wed Oct 2 00:01:02 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Oct 2024 07:01:02 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011347.491DlAsJ423777@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> Message-ID: <20241001140101.GG13777@mcvoy.com> On Tue, Oct 01, 2024 at 07:47:10AM -0600, arnold at skeeve.com wrote: > Larry McVoy wrote: > > > On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: > > > Would the word have been better off if Ada had caught on everywhere? > > > Probably. When I was in grad school studying language design, circa 1982, > > > it was expected to do so. But the language was VERY challenging for > > > compiler writers. > > > > Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. > > It was the compilers course (701) and the really hard compilers course (702) > > at the time. The first course was to write a compiler for a subset of Ada > > and the second on increased the subset to be almost complete. > > > > We were supposed to do it on an IBM mainframe because the professor had his > > own version of lex/yacc there. Rob had a 3b1 and asked if we could do it > > there if he rewrote the parser stuff. Prof said sure. > > > > In one semester we had a compiler, no optimizer and not much in the > > way of graceful error handling, but it compiled stuff that ran. We did > > all of Ada other than late binding of variables (I think that was Ada's > > templates) and threads and probably some other stuff I don't remember. > > Did you do generics? That and the run time, which had some real-time > bits to it (*IIRC*, it's been a long time), as well as the cross > object code type checking, would have been real bears. None of those ring a bell so > Like many things, the first 90% is easy, the second 90% is hard. :-) I guess we did the easy stuff :-( > > I don't consider myself to be that good of a programmer, I can point to > > dozens of people my age that can run circles around me and I'm sure there > > are many more. > > You are undoubtedly better than you give yourself credit for, even > if there were people who could run circles around you. I learned > a long time ago, that no matter how good you are, there's always > someone better than you at something. I decided long ago to not > try to compete with Superman. Funny, I've come to the same conclusion, both in programming and my retirement hobby. There is always someone way better than me, but you are correct, that doesn't mean I'm awful. Just have more to learn. A buddy pointed out that I was probably better than 80% of the people leaving the dock, it's just I fish with a guy who is better than pretty much everyone. > > But apparently the bar is pretty low these days and I agree, that's sad. > > And it makes it much less fun to be out in the working world. :-( As a guy in his 2nd retirement (1st didn't stick) I can tell you I am so happy not having to deal with work stuff. My buddies who are still working tell me stories I find difficult to believe. They all say I'm so politically incorrect that I wouldn't last a week in today's world. If their stories are true, yeah, that's not for me. Weird politics and crappy programmers, count me out. From arnold at skeeve.com Wed Oct 2 00:18:34 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 08:18:34 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001140101.GG13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> Message-ID: <202410011418.491EIYYp426442@freefriends.org> Closing off the thread... > > Did you do generics? That and the run time, which had some real-time > > bits to it (*IIRC*, it's been a long time), as well as the cross > > object code type checking, would have been real bears. > > None of those ring a bell so > > > Like many things, the first 90% is easy, the second 90% is hard. :-) > > I guess we did the easy stuff :-( Even the easy stuff is good learning. > Funny, I've come to the same conclusion, both in programming and my > retirement hobby. There is always someone way better than me, but > you are correct, that doesn't mean I'm awful. Just have more to > learn. Right. > > > But apparently the bar is pretty low these days and I agree, that's sad. > > > > And it makes it much less fun to be out in the working world. :-( > > As a guy in his 2nd retirement (1st didn't stick) I can tell you I am > so happy not having to deal with work stuff. My buddies who are still > working tell me stories I find difficult to believe. They all say I'm > so politically incorrect that I wouldn't last a week in today's world. > If their stories are true, yeah, that's not for me. > > Weird politics and crappy programmers, count me out. I don't have to deal with the politics, and my team is good, but the company has a lot of crappy code. I am planning to retire quite soon, too. :-) Arnold From luther.johnson at makerlisp.com Wed Oct 2 00:25:04 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Tue, 1 Oct 2024 07:25:04 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001140101.GG13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> Message-ID: <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> I think because the of the orders of magnitude increase in the demand for programmers, we now have a very large number of programmers with little or no math and science (and computer science doesn't count in the point I'm trying to make here, if that's your only science, you're not going to have the models in your head from other disciplines to give you useful analogs) background, and that's a big change from 40 years ago. So that has had an effect on who is programming, how they think about it, and how languages have been marketed to that programming audience. IMHO. On 10/01/2024 07:01 AM, Larry McVoy wrote: > On Tue, Oct 01, 2024 at 07:47:10AM -0600, arnold at skeeve.com wrote: >> Larry McVoy wrote: >> >>> On Tue, Oct 01, 2024 at 07:13:04AM -0600, arnold at skeeve.com wrote: >>>> Would the word have been better off if Ada had caught on everywhere? >>>> Probably. When I was in grad school studying language design, circa 1982, >>>> it was expected to do so. But the language was VERY challenging for >>>> compiler writers. >>> Huh. Rob Netzer and I, as grad students, took cs701 and cs702 at UW Madison. >>> It was the compilers course (701) and the really hard compilers course (702) >>> at the time. The first course was to write a compiler for a subset of Ada >>> and the second on increased the subset to be almost complete. >>> >>> We were supposed to do it on an IBM mainframe because the professor had his >>> own version of lex/yacc there. Rob had a 3b1 and asked if we could do it >>> there if he rewrote the parser stuff. Prof said sure. >>> >>> In one semester we had a compiler, no optimizer and not much in the >>> way of graceful error handling, but it compiled stuff that ran. We did >>> all of Ada other than late binding of variables (I think that was Ada's >>> templates) and threads and probably some other stuff I don't remember. >> Did you do generics? That and the run time, which had some real-time >> bits to it (*IIRC*, it's been a long time), as well as the cross >> object code type checking, would have been real bears. > None of those ring a bell so > >> Like many things, the first 90% is easy, the second 90% is hard. :-) > I guess we did the easy stuff :-( > >>> I don't consider myself to be that good of a programmer, I can point to >>> dozens of people my age that can run circles around me and I'm sure there >>> are many more. >> You are undoubtedly better than you give yourself credit for, even >> if there were people who could run circles around you. I learned >> a long time ago, that no matter how good you are, there's always >> someone better than you at something. I decided long ago to not >> try to compete with Superman. > Funny, I've come to the same conclusion, both in programming and my > retirement hobby. There is always someone way better than me, but > you are correct, that doesn't mean I'm awful. Just have more to > learn. > > A buddy pointed out that I was probably better than 80% of the people > leaving the dock, it's just I fish with a guy who is better than pretty > much everyone. > >>> But apparently the bar is pretty low these days and I agree, that's sad. >> And it makes it much less fun to be out in the working world. :-( > As a guy in his 2nd retirement (1st didn't stick) I can tell you I am > so happy not having to deal with work stuff. My buddies who are still > working tell me stories I find difficult to believe. They all say I'm > so politically incorrect that I wouldn't last a week in today's world. > If their stories are true, yeah, that's not for me. > > Weird politics and crappy programmers, count me out. > From crossd at gmail.com Wed Oct 2 00:56:13 2024 From: crossd at gmail.com (Dan Cross) Date: Tue, 1 Oct 2024 10:56:13 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: On Tue, Oct 1, 2024 at 10:32 AM Luther Johnson wrote: > I think because the of the orders of magnitude increase in the demand > for programmers, we now have a very large number of programmers with > little or no math and science (and computer science doesn't count in the > point I'm trying to make here, if that's your only science, you're not > going to have the models in your head from other disciplines to give you > useful analogs) background, and that's a big change from 40 years ago. > So that has had an effect on who is programming, how they think about > it, and how languages have been marketed to that programming audience. IMHO. I've found a grounding in mathematics useful for programming, but beyond some knowledge of the physical constraints that the universe places on us and a very healthy appreciation for the scientific method, I'm having a hard time understanding how the hard sciences would help out too much. Electrical engineering seems like it would be more useful, than, say, chemistry or geology. I talk to a lot of academics, and I think they see the situation differently than is presented here. In a nutshell, the way a lot of them look at it, the amount of computer science in the world increases constantly while the amount of time they have to teach that to undergraduates remains fixed. As a result, they have to pick and choose what they teach very, very carefully, balancing a number of criteria as they do so. What this translates to in the real world isn't that the bar is lowered, but that the bar is different. - Dan C. From stuff at riddermarkfarm.ca Wed Oct 2 01:08:06 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Tue, 1 Oct 2024 11:08:06 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: [-->COFF] On 2024-10-01 10:56, Dan Cross wrote (in part): > I've found a grounding in mathematics useful for programming, but > beyond some knowledge of the physical constraints that the universe > places on us and a very healthy appreciation for the scientific > method, I'm having a hard time understanding how the hard sciences > would help out too much. Electrical engineering seems like it would be > more useful, than, say, chemistry or geology. I see this as related to the old question about whether it is easier to teach domain experts to program or teach programmers about the domain. (I worked for a company that wrote/sold scientific libraries for embedded systems.) We had a mixture but the former was often easier. S. > > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. > > - Dan C. From lm at mcvoy.com Wed Oct 2 01:20:33 2024 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 1 Oct 2024 08:20:33 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: <20241001152033.GH13777@mcvoy.com> On Tue, Oct 01, 2024 at 10:56:13AM -0400, Dan Cross wrote: > On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson > wrote: > > I think because the of the orders of magnitude increase in the demand > > for programmers, we now have a very large number of programmers with > > little or no math and science (and computer science doesn't count in the > > point I'm trying to make here, if that's your only science, you're not > > going to have the models in your head from other disciplines to give you > > useful analogs) background, and that's a big change from 40 years ago. > > So that has had an effect on who is programming, how they think about > > it, and how languages have been marketed to that programming audience. IMHO. > > I've found a grounding in mathematics useful for programming, but > beyond some knowledge of the physical constraints that the universe > places on us and a very healthy appreciation for the scientific > method, I'm having a hard time understanding how the hard sciences > would help out too much. Electrical engineering seems like it would be > more useful, than, say, chemistry or geology. > > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. I really wish that they made students take something like the PDP-11 assembly class - it was really systems architecture, you learned the basic idea of a computer: a CPU, a bus to talk to memory, a bus to talk to I/O, how a stack works, ideally how a context switch works though that kinda blows minds (I personally don't think you are a kernel programmer if you haven't implemented swtch() or at least walked the code and understood all of it). I did all that and developed a mental model of all computers that has helped me over the last 4 decades. Yes, my model is overly simplistic but it still works, even on the x86 craziness. I don't know how you could get to that mental model with x86, x86 is too weird. I don't really know which architecture is close to the simplicity of a PDP-11 today. Anyone? If I were teaching it, I'd just get a PDP-11 simulator and teach on that. Maybe. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed Oct 2 01:38:04 2024 From: tuhs at tuhs.org (=?utf-8?b?UGV0ZXIgV2VpbmJlcmdlciAo5rip5Y2a5qC8KSB2aWEgVFVIUw==?=) Date: Tue, 1 Oct 2024 11:38:04 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241001152033.GH13777@mcvoy.com> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> <20241001152033.GH13777@mcvoy.com> Message-ID: Each generation bemoans the qualities of following generations. (Perhaps justifiably in this case, but we're acting out a stereotyped pattern.) Having a mental model of a computer is a good idea, but I'd rather not have to teach the details of PDP-11 condition codes (which changed in unexpected ways over time) Now caches loom large, and should such a course provide a mental model of smart phones? [I think it should, and the course should cover secure boot, but that leaves lots less time for assembly language.] On Tue, Oct 1, 2024 at 11:20 AM Larry McVoy wrote: > > On Tue, Oct 01, 2024 at 10:56:13AM -0400, Dan Cross wrote: > > On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson > > wrote: > > > I think because the of the orders of magnitude increase in the demand > > > for programmers, we now have a very large number of programmers with > > > little or no math and science (and computer science doesn't count in the > > > point I'm trying to make here, if that's your only science, you're not > > > going to have the models in your head from other disciplines to give you > > > useful analogs) background, and that's a big change from 40 years ago. > > > So that has had an effect on who is programming, how they think about > > > it, and how languages have been marketed to that programming audience. IMHO. > > > > I've found a grounding in mathematics useful for programming, but > > beyond some knowledge of the physical constraints that the universe > > places on us and a very healthy appreciation for the scientific > > method, I'm having a hard time understanding how the hard sciences > > would help out too much. Electrical engineering seems like it would be > > more useful, than, say, chemistry or geology. > > > > I talk to a lot of academics, and I think they see the situation > > differently than is presented here. In a nutshell, the way a lot of > > them look at it, the amount of computer science in the world increases > > constantly while the amount of time they have to teach that to > > undergraduates remains fixed. As a result, they have to pick and > > choose what they teach very, very carefully, balancing a number of > > criteria as they do so. What this translates to in the real world > > isn't that the bar is lowered, but that the bar is different. > > I really wish that they made students take something like the PDP-11 > assembly class - it was really systems architecture, you learned the > basic idea of a computer: a CPU, a bus to talk to memory, a bus to > talk to I/O, how a stack works, ideally how a context switch works > though that kinda blows minds (I personally don't think you are a > kernel programmer if you haven't implemented swtch() or at least > walked the code and understood all of it). > > I did all that and developed a mental model of all computers that > has helped me over the last 4 decades. Yes, my model is overly > simplistic but it still works, even on the x86 craziness. I don't > know how you could get to that mental model with x86, x86 is too > weird. I don't really know which architecture is close to the > simplicity of a PDP-11 today. Anyone? > > If I were teaching it, I'd just get a PDP-11 simulator and teach > on that. Maybe. > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Wed Oct 2 01:44:12 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Tue, 1 Oct 2024 08:44:12 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> > Thus Go and Rust are good things, taking the sharp tools out of the > hands of the people who aren't qualified to use them. Same thing Python. Sounds like boomer mentality... Kids these days... :-) Also sounds like the kind of arguments assembly language programmers presented when *we* were the "kids" trying out "structured programming"! From rminnich at gmail.com Wed Oct 2 01:50:58 2024 From: rminnich at gmail.com (ron minnich) Date: Tue, 1 Oct 2024 08:50:58 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> <20241001152033.GH13777@mcvoy.com> Message-ID: by the way, if you are hankering to do bare metal programming again, and you're done with C, tinygo is great, and it works on 200 or so boards, from the bbc micro on up. tinygo gives you all the nice bits from go, and uses llvm as the backend, so programs can be very small. Tamago is also bare metal go, using the standard Go compiler, and has even flown in space. I had thought Rust and C would always be the only path to very low level programming in tiny environments, but it turned out I was too pessimistic. https://docs.google.com/presentation/d/1nqZicux6SloS8AynBu0B7cJYxw5pKu4IfCzq_vqWccw/edit?usp=sharing It's been years now since I used C on bare metal; it's Rust or Go for me. These languages give me all I ever needed for "first instruction after reset" programming. On Tue, Oct 1, 2024 at 8:38 AM Peter Weinberger (温博格) via TUHS < tuhs at tuhs.org> wrote: > Each generation bemoans the qualities of following generations. > (Perhaps justifiably in this case, but we're acting out a stereotyped > pattern.) > > Having a mental model of a computer is a good idea, but I'd rather not > have to teach the details of PDP-11 condition codes (which changed in > unexpected ways over time) Now caches loom large, and should such a > course provide a mental model of smart phones? [I think it should, and > the course should cover secure boot, but that leaves lots less time > for assembly language.] > > On Tue, Oct 1, 2024 at 11:20 AM Larry McVoy wrote: > > > > On Tue, Oct 01, 2024 at 10:56:13AM -0400, Dan Cross wrote: > > > On Tue, Oct 1, 2024 at 10:32???AM Luther Johnson > > > wrote: > > > > I think because the of the orders of magnitude increase in the demand > > > > for programmers, we now have a very large number of programmers with > > > > little or no math and science (and computer science doesn't count in > the > > > > point I'm trying to make here, if that's your only science, you're > not > > > > going to have the models in your head from other disciplines to give > you > > > > useful analogs) background, and that's a big change from 40 years > ago. > > > > So that has had an effect on who is programming, how they think about > > > > it, and how languages have been marketed to that programming > audience. IMHO. > > > > > > I've found a grounding in mathematics useful for programming, but > > > beyond some knowledge of the physical constraints that the universe > > > places on us and a very healthy appreciation for the scientific > > > method, I'm having a hard time understanding how the hard sciences > > > would help out too much. Electrical engineering seems like it would be > > > more useful, than, say, chemistry or geology. > > > > > > I talk to a lot of academics, and I think they see the situation > > > differently than is presented here. In a nutshell, the way a lot of > > > them look at it, the amount of computer science in the world increases > > > constantly while the amount of time they have to teach that to > > > undergraduates remains fixed. As a result, they have to pick and > > > choose what they teach very, very carefully, balancing a number of > > > criteria as they do so. What this translates to in the real world > > > isn't that the bar is lowered, but that the bar is different. > > > > I really wish that they made students take something like the PDP-11 > > assembly class - it was really systems architecture, you learned the > > basic idea of a computer: a CPU, a bus to talk to memory, a bus to > > talk to I/O, how a stack works, ideally how a context switch works > > though that kinda blows minds (I personally don't think you are a > > kernel programmer if you haven't implemented swtch() or at least > > walked the code and understood all of it). > > > > I did all that and developed a mental model of all computers that > > has helped me over the last 4 decades. Yes, my model is overly > > simplistic but it still works, even on the x86 craziness. I don't > > know how you could get to that mental model with x86, x86 is too > > weird. I don't really know which architecture is close to the > > simplicity of a PDP-11 today. Anyone? > > > > If I were teaching it, I'd just get a PDP-11 simulator and teach > > on that. Maybe. > > -- > > --- > > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Oct 2 02:40:32 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 1 Oct 2024 12:40:32 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011313.491DD4ac421643@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> Message-ID: On Tue, Oct 1, 2024 at 9:13 AM wrote: > This goes back to the evolution thing. At the time, C was a huge > step up from FORTRAN and assembly. > Certainly it's a step up (and a BIG step up) from assembly. But I'd say C is a step sidewise from Fortran. An awful lot of HPTC programming involves throwing multidimensional arrays around and C is not suitable for that. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Oct 2 02:49:10 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 1 Oct 2024 12:49:10 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011347.491DlAsJ423777@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> Message-ID: On Tue, Oct 1, 2024 at 10:07 AM wrote: [regarding writing an Ada compiler as a class project] > Did you do generics? That and the run time, which had some real-time > bits to it (*IIRC*, it's been a long time), as well as the cross > object code type checking, would have been real bears. > > Like many things, the first 90% is easy, the second 90% is hard. :-) > > I was in DEC's compiler group when they were implementing Ada for VAX/VMS. It gets very tricky when routine libraries are involved. Just figuring out the compilation order can be a real bear (part of this is the cross object code type checking you mention). >From my viewpoint Ada suffered two problems. First, it was such a large language and very tricky to implement--even more so than PL/I. Second, it had US Government cooties. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Oct 2 05:04:36 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 13:04:36 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <20241001133231.GE13777@mcvoy.com> <202410011347.491DlAsJ423777@freefriends.org> <20241001140101.GG13777@mcvoy.com> <024bd803-2852-c0d0-5f15-30ec65c45cb4@makerlisp.com> Message-ID: <202410011904.491J4aOY448275@freefriends.org> Dan Cross wrote: > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. You also have a lot of self-taught programmers, and graduates of bootcamp programs, getting into programming. From arnold at skeeve.com Wed Oct 2 05:07:04 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 13:07:04 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> Message-ID: <202410011907.491J74wT448406@freefriends.org> Bakul Shah via TUHS wrote: > > > Thus Go and Rust are good things, taking the sharp tools out of the > > hands of the people who aren't qualified to use them. Same thing Python. > > Sounds like boomer mentality... Kids these days... :-) Also sounds like > the kind of arguments assembly language programmers presented when *we* > were the "kids" trying out "structured programming"! It's not that they're intrinsically unqualified. They were never taught, so they don't know what they're doing. I'm unqualified to fly a plane because I never learned or practiced, not because I'm not intelligent enough. Same thing for many of today's programmers and C / C++. From tuhs at tuhs.org Wed Oct 2 05:46:50 2024 From: tuhs at tuhs.org (Chet Ramey via TUHS) Date: Tue, 1 Oct 2024 15:46:50 -0400 Subject: [TUHS] Fwd: Trove of CSTR's In-Reply-To: References: Message-ID: <36800a31-cea8-4b74-a34b-2069d031945e@case.edu> On 9/28/24 7:38 PM, Warren Toomey via TUHS wrote: > ----- Forwarded message from Poul-Henning Kamp ----- > > I stumbled over this: > > https://www.telecomarchive.com/lettermemo.html > > is the TUHS crew aware of that resource ? This is an incredible resource as well: https://www.telecomarchive.com/bstj.html From 1922 to 1996. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From rik at rikfarrow.com Wed Oct 2 06:34:26 2024 From: rik at rikfarrow.com (Rik Farrow) Date: Tue, 1 Oct 2024 13:34:26 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410011907.491J74wT448406@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> Message-ID: And my comment about seeing code produced by programmers while doing sales support dates from 1990. This isn't something new, from my perspective. I was working in a small programming shop where there were a handful of excellent programmers, and then sent out to help customers get started using their libraries. That's when I experienced seeing things that still make me cringe. Rik On Tue, Oct 1, 2024 at 12:07 PM wrote: > Bakul Shah via TUHS wrote: > > > > > > Thus Go and Rust are good things, taking the sharp tools out of the > > > hands of the people who aren't qualified to use them. Same thing > Python. > > > > Sounds like boomer mentality... Kids these days... :-) Also sounds like > > the kind of arguments assembly language programmers presented when *we* > > were the "kids" trying out "structured programming"! > > It's not that they're intrinsically unqualified. They were never > taught, so they don't know what they're doing. I'm unqualified to > fly a plane because I never learned or practiced, not because I'm not > intelligent enough. Same thing for many of today's programmers > and C / C++. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Oct 2 10:55:58 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 02 Oct 2024 02:55:58 +0200 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> Message-ID: <20241002005558.TiqDHtEk@steffen%sdaoden.eu> Rik Farrow wrote in : |On Tue, Oct 1, 2024 at 12:07 PM wrote: |> Bakul Shah via TUHS wrote: ... |>> Sounds like boomer mentality... Kids these days... :-) Also sounds like |>> the kind of arguments assembly language programmers presented when *we* |>> were the "kids" trying out "structured programming"! |> |> It's not that they're intrinsically unqualified. They were never |> taught, so they don't know what they're doing. I'm unqualified to |> fly a plane because I never learned or practiced, not because I'm not |> intelligent enough. Same thing for many of today's programmers |> and C / C++. |And my comment about seeing code produced by programmers while doing sales |support dates from 1990. This isn't something new, from my perspective. I |was working in a small programming shop where there were a handful of |excellent programmers, and then sent out to help customers get started |using their libraries. That's when I experienced seeing things that still |make me cringe. Btw the "official Linux firmware" https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary introduced a dependency for the "rdfind" utility i think ~two years ago (it was later made optional) for this code: $verbose "Finding duplicate files" rdfind -makesymlinks true -makeresultsfile false "$destdir" >/dev/null find "$destdir" -type l | while read -r l; do target="$(realpath "$l")" $verbose "Correcting path for $l" ln -fs "$(realpath --relative-to="$(dirname "$(realpath -s "$l")")" "$target")" "$l" done I proposed (because it really drove me mad, i have nothing to do with Linux kernel stuff etc shall you think that) ( cd "$destdir" && find . -type f | xargs cksum | sort | { ls= lf= while read s1 s2 f; do s="$s1 $s2" #$verbose $s $f if [ "$s" = "$ls" ] && cmp "$lf" "$f"; then $verbose 'duplicate '"${lf##*/}" "${f#./*}" rm -f "$f" #ln -s "${lf#./*}" "${f#./*}" ln -s "${lf##*/}" "${f#./*}" else ls=$s lf=$f fi done } ) (as a draft, with only light testing, but it is not far from doing it at maximum) which only uses POSIX default tools etc, but these guys from very big companies (RedHat; the guy who did *that* is from AMD) did not even respond, at least to that. (At times i tried to get rid of rsync dependency of kernel makefile officially, as that can also be done via plain shell tools, they at least answered "what is wrong with rsync".) Maybe because the patch also included - compress="zstd --compress --quiet --stdout" + compress="zstd -T0 --ultra -22 --compress --quiet --stdout" but that only brought the firmware into line with the normal Linux kernel make zstd usage. I will never know. I think what i am trying to say is that maybe "time is money" in addition to anything else. (I never heard about rdfind though. Btw its manual (it has one!) says SEE ALSO md5sum, sha1sum, find, symlinks were cksum is a standard tool. So it is. Everyone its own infrastructure, how large it is; you all only get the binary updates anyway, my Linux distribution compiles from source; and what the mesa library alone has grown in new dependencies that are mostly never needed let alone at runtime, like YAML, that has been done at release-tarball-creation time in the past. At least here.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From arnold at skeeve.com Wed Oct 2 15:49:33 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 01 Oct 2024 23:49:33 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> Message-ID: <202410020549.4925nXHf489153@freefriends.org> Rik Farrow wrote: > And my comment about seeing code produced by programmers while doing sales > support dates from 1990. This isn't something new, Also true. In the late 80s I was a sysadmin at Emory U. We had a Vax connected to BITNET with funky hardware and UREP, the Unix RSCS Emulation Program, from the University of Pennsylvania. Every time I had to dive into that code, I felt like I needed a shower afterwards. :-) Arnold From crossd at gmail.com Thu Oct 3 06:42:59 2024 From: crossd at gmail.com (Dan Cross) Date: Wed, 2 Oct 2024 16:42:59 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410020549.4925nXHf489153@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> Message-ID: On Wed, Oct 2, 2024 at 2:27 AM wrote: > Rik Farrow wrote: > > And my comment about seeing code produced by programmers while doing sales > > support dates from 1990. This isn't something new, > > Also true. In the late 80s I was a sysadmin at Emory U. We had a > Vax connected to BITNET with funky hardware and UREP, the Unix RSCS > Emulation Program, from the University of Pennsylvania. Every time > I had to dive into that code, I felt like I needed a shower afterwards. :-) Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I must point out that UREP wasn't from the University of Pennsylvania, but rather, from The Pennsylvania State University (yes, "The" is part of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State (psu.edu) is a state school in University Park, which is next to State College (really, that's the name of the town) with satellite campuses scattered around the state. - Dan C. From marc.donner at gmail.com Thu Oct 3 07:54:06 2024 From: marc.donner at gmail.com (Marc Donner) Date: Wed, 2 Oct 2024 17:54:06 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> Message-ID: RSCS. Sigh. Remote Spooling Communications Subsystem. I suppose I could praise it for its elegant layering of abstractions ... just send a virtual card deck to the virtual card reader on the virtual machine being used by your correspondent. Or I could curse it for its absurdity - really, a virtual card deck? 80 character EBCDIC records. An amazing concept. ===== nygeek.net mindthegapdialogs.com/home On Wed, Oct 2, 2024 at 4:43 PM Dan Cross wrote: > On Wed, Oct 2, 2024 at 2:27 AM wrote: > > Rik Farrow wrote: > > > And my comment about seeing code produced by programmers while doing > sales > > > support dates from 1990. This isn't something new, > > > > Also true. In the late 80s I was a sysadmin at Emory U. We had a > > Vax connected to BITNET with funky hardware and UREP, the Unix RSCS > > Emulation Program, from the University of Pennsylvania. Every time > > I had to dive into that code, I felt like I needed a shower afterwards. > :-) > > Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I > must point out that UREP wasn't from the University of Pennsylvania, > but rather, from The Pennsylvania State University (yes, "The" is part > of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State > (psu.edu) is a state school in University Park, which is next to State > College (really, that's the name of the town) with satellite campuses > scattered around the state. > > - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Sat Oct 5 07:42:50 2024 From: tuhs at tuhs.org (Jacobson, Doug W [E CPE] via TUHS) Date: Fri, 4 Oct 2024 21:42:50 +0000 Subject: [TUHS] Old troff files (1988-2007) Message-ID: Folks: Long story short, I have a unpublished manuscript that a faculty member in my department wrote late 1980's early 2000's. He did the entire thing in troff, eqn, and pic. The faculty member is still alive. A publisher is interested in the manuscript. I have all of the source files on an old unix machine that still has troff, eqn and pic. It also has groff. This issue is that the pic commands are bracketed by .G1 and .G2 not .PS & .PE. The original machine he would have used would have ran AT&T Sys V on an AT&T 3B20. Below is one of the files. Any thoughts on the .G1 .G2? I can get the files that have only eqn and troff to create postscript, but the .G1/.G2 is not understood by pic. I tried replacing the .G1/.G2 with .PS/PE and it failed. I must be missing another program that uses the .G1/2 Thanks .sp -3.5 .fp 1 Z .fp 2 XI .ps 11 .tl ' ' '1-10' .EQ delim $$ gsize 11 .EN .po 0.9i .vs 15 .G1 frame wid 5.7 ht 6.0 invis coord x 0.2, 100 y -40, +22 log x grid left from -30 to +20 by 10 "" grid left from -40.04 to +19.96 by 10 "" grid left from -39.96 to +20.04 by 10 "" grid left from -39 to +22 by 1 "" grid bot from 0.4 to 40 by *10 "" grid bot from 1 to 100 by *10 "" grid bot from 0.2 to 20 by *10 "" grid bot from 0.3 to 30 by *10 "" grid bot from 0.5 to 50 by *10 "" grid bot from 0.6 to 60 by *10 "" grid bot from 0.7 to 70 by *10 "" grid bot from 0.8 to 80 by *10 "" grid bot from 0.9 to 90 by *10 "" ticks out left from -40 to +20 by 10 ticks out bot from 0.2 to 20 by *10 ticks out bot from 0.4 to 40 by *10 ticks out bot from 1 to 100 by *10 draw solid 0.2 19.93 2 19.93 10 5.97 100 -34.02 new solid 0.2 20.07 2 20.07 10 6.05 100 -33.95 new dotted for i=0.45 to 23 by *1.05 do { w=i*i f=200/sqrt(w*w+104*w+400) next at i,20*log(f) } label left "\u\udB \d\d" label bot "\(*w, rad/s" .G2 .in 2 Fig. 1.4. Graph of the magnitude in dB of $H(s)~=~200 over{s sup 2~+~12^s~+~20}^,$$~s~=~j^omega$. Doug Jacobson University Professor, Dept. Electrical & Computer Engineering Sunil & Sujata Gaitonde Professorship in Cybersecurity Director: ISU Center for Cybersecurity Innovation and Outreach Mail Address: 2520 Osborn Dr, 2215 Coover Hall Iowa State University PH: (515) 294-8307 Fax (515) 294-8432 Office: 371 Durham Hall Center web site: http://www.cyio.iastate.edu/ Personal web site: http://www.dougj.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyndon at orthanc.ca Sat Oct 5 07:50:34 2024 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE7TFX/VE6BBM)) Date: Fri, 04 Oct 2024 14:50:34 -0700 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: Doug, .G1/.G2 are bookmarks for the grap pre-processor. --lyndon From tuhs at tuhs.org Sat Oct 5 07:52:06 2024 From: tuhs at tuhs.org (Jacobson, Doug W [E CPE] via TUHS) Date: Fri, 4 Oct 2024 21:52:06 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: Cool now I need to get grap running :) Doug -----Original Message----- From: Lyndon Nerenberg (VE7TFX/VE6BBM) Sent: Friday, October 4, 2024 4:51 PM To: Jacobson, Doug W [E CPE] ; tuhs at tuhs.org Subject: Re: [TUHS] Old troff files (1988-2007) Doug, .G1/.G2 are bookmarks for the grap pre-processor. --lyndon From tuhs at tuhs.org Sat Oct 5 08:10:59 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Fri, 4 Oct 2024 15:10:59 -0700 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: It's in plan9port. https://github.com/9fans/plan9port > On Oct 4, 2024, at 2:52 PM, Jacobson, Doug W [E CPE] via TUHS wrote: > > Cool now I need to get grap running :) > > Doug > > > -----Original Message----- > From: Lyndon Nerenberg (VE7TFX/VE6BBM) > Sent: Friday, October 4, 2024 4:51 PM > To: Jacobson, Doug W [E CPE] ; tuhs at tuhs.org > Subject: Re: [TUHS] Old troff files (1988-2007) > > Doug, .G1/.G2 are bookmarks for the grap pre-processor. > > --lyndon -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Oct 5 09:01:44 2024 From: clemc at ccc.com (Clem Cole) Date: Fri, 4 Oct 2024 19:01:44 -0400 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: There part of heirloom troff distribution and are likely to just work on a modern Unix https://n-t-roff.github.io/heirloom/doctools.html Sent from a handheld expect more typos than usual On Fri, Oct 4, 2024 at 5:52 PM Jacobson, Doug W [E CPE] via TUHS < tuhs at tuhs.org> wrote: > Cool now I need to get grap running :) > > Doug > > > -----Original Message----- > From: Lyndon Nerenberg (VE7TFX/VE6BBM) > Sent: Friday, October 4, 2024 4:51 PM > To: Jacobson, Doug W [E CPE] ; tuhs at tuhs.org > Subject: Re: [TUHS] Old troff files (1988-2007) > > Doug, .G1/.G2 are bookmarks for the grap pre-processor. > > --lyndon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Oct 5 09:16:18 2024 From: clemc at ccc.com (Clem Cole) Date: Fri, 4 Oct 2024 19:16:18 -0400 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: Btw. The heirloom version of troff is from Solaris SVR4 which should be quite close the version from the 3B20 Sent from a handheld expect more typos than usual On Fri, Oct 4, 2024 at 7:01 PM Clem Cole wrote: > There part of heirloom troff distribution and are likely to just work on a > modern Unix > > https://n-t-roff.github.io/heirloom/doctools.html > > > Sent from a handheld expect more typos than usual > > > On Fri, Oct 4, 2024 at 5:52 PM Jacobson, Doug W [E CPE] via TUHS < > tuhs at tuhs.org> wrote: > >> Cool now I need to get grap running :) >> >> Doug >> >> >> -----Original Message----- >> From: Lyndon Nerenberg (VE7TFX/VE6BBM) >> Sent: Friday, October 4, 2024 4:51 PM >> To: Jacobson, Doug W [E CPE] ; tuhs at tuhs.org >> Subject: Re: [TUHS] Old troff files (1988-2007) >> >> Doug, .G1/.G2 are bookmarks for the grap pre-processor. >> >> --lyndon >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sat Oct 5 10:14:33 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 4 Oct 2024 19:14:33 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: Message-ID: <20241005001433.7hukoga5bbbb3ygl@illithid> Hi Doug, At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote: > Folks: > > Long story short, I have a unpublished manuscript that a faculty > member in my department wrote late 1980's early 2000's. He did the > entire thing in troff, eqn, and pic. The faculty member is still > alive. A publisher is interested in the manuscript. I have all of > the source files on an old unix machine that still has troff, eqn and > pic. It also has groff. This issue is that the pic commands are > bracketed by .G1 and .G2 not .PS & .PE. As others noted, those are the characteristic preprocessor tokens used by grap(1). groff(1) says: A free implementation of the grap preprocessor, written by Ted Faber ⟨faber at lunabase.org⟩, can be found at the grap website ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩. groff supports only this grap. Distributors often have a package of Faber's grap. I'm not aware of any other in circulation. (Happy to be corrected here.) Please contact the groff list, groff at gnu dot org, if you have any problems using it to format these documents and/or to note formatting discrepancies between Unix troff and groff. There will likely be some. I've noted differences between DWB troff and Heirloom troff, so using the latter does not guarantee identical rendering, and moreover DWB/System V troff has some bugs/limitations that Heirloom and/or GNU troffs have fixed, and some of these can affect formatting. Here's a list from groff's tbl(1) man page, for example. GNU tbl enhancements In addition to extensions noted above, GNU tbl removes constraints endured by users of AT&T tbl. • Region options can be specified in any lettercase. • There is no limit on the number of columns in a table, regardless of their classification, nor any limit on the number of text blocks. • All table rows are considered when deciding column widths, not just those occurring in the first 200 input lines of a region. Similarly, table continuation (.T&) tokens are recognized outside a region’s first 200 input lines. • Numeric and alphabetic entries may appear in the same column. • Numeric and alphabetic entries may span horizontally. One can imagine how a 200+-row table could format differently between DWB/System V and GNU tbl, without either being "wrong". 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 peter.martin.yardley at gmail.com Sat Oct 5 14:09:54 2024 From: peter.martin.yardley at gmail.com (Peter Yardley) Date: Sat, 5 Oct 2024 14:09:54 +1000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241005001433.7hukoga5bbbb3ygl@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> Message-ID: <3064B620-86EA-4F79-A440-536425FFE2D7@gmail.com> This isn’t helpful, but the .G1 .G2 look a lot like Gerber codes used in NC machine tools. Sent from my iPhone > On 5 Oct 2024, at 1:52 pm, G. Branden Robinson wrote: > > Hi Doug, > > At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote: >> Folks: >> >> Long story short, I have a unpublished manuscript that a faculty >> member in my department wrote late 1980's early 2000's. He did the >> entire thing in troff, eqn, and pic. The faculty member is still >> alive. A publisher is interested in the manuscript. I have all of >> the source files on an old unix machine that still has troff, eqn and >> pic. It also has groff. This issue is that the pic commands are >> bracketed by .G1 and .G2 not .PS & .PE. > > As others noted, those are the characteristic preprocessor tokens used > by grap(1). > > groff(1) says: > A free implementation of the grap preprocessor, written by Ted > Faber ⟨faber at lunabase.org⟩, can be found at the grap website > ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩. groff > supports only this grap. > > Distributors often have a package of Faber's grap. I'm not aware of any > other in circulation. (Happy to be corrected here.) > > Please contact the groff list, groff at gnu dot org, if you have any > problems using it to format these documents and/or to note formatting > discrepancies between Unix troff and groff. There will likely be some. > > I've noted differences between DWB troff and Heirloom troff, so using > the latter does not guarantee identical rendering, and moreover > DWB/System V troff has some bugs/limitations that Heirloom and/or GNU > troffs have fixed, and some of these can affect formatting. > > Here's a list from groff's tbl(1) man page, for example. > > GNU tbl enhancements > In addition to extensions noted above, GNU tbl removes constraints > endured by users of AT&T tbl. > > • Region options can be specified in any lettercase. > > • There is no limit on the number of columns in a table, > regardless of their classification, nor any limit on the number > of text blocks. > > • All table rows are considered when deciding column widths, not > just those occurring in the first 200 input lines of a region. > Similarly, table continuation (.T&) tokens are recognized > outside a region’s first 200 input lines. > > • Numeric and alphabetic entries may appear in the same column. > > • Numeric and alphabetic entries may span horizontally. > > One can imagine how a 200+-row table could format differently between > DWB/System V and GNU tbl, without either being "wrong". > > Regards, > Branden From sjenkin at canb.auug.org.au Sat Oct 5 16:55:46 2024 From: sjenkin at canb.auug.org.au (sjenkin at canb.auug.org.au) Date: Sat, 5 Oct 2024 16:55:46 +1000 Subject: [TUHS] UNIX NEWS, volumes 1-7 out there? Message-ID: In Sept 2019 Warner Losh was looking for copies of the first volumes of UNIX NEWS / Login. Clem Cole noted that the Usenix Archives were also looking. Kurt H Maier, noted he had pages from 1976, Volume 1, Number 4. Jeremy C. Reed pointed to multiple items available online. His email appears in a separate email thread on TUHS. I stumbled on UNIX NEWS Number 1 in the Internet Archive Which is from a near complete Usenix collection of ‘;login' from 1975 to 2000 . 1979 (Volume 4) is missing from the series [ as at Oct 2024 ] I wasn’t able to navigate the Usenix website to find the Archives Clem Cole mentioned, to confirm they also had copies. I also stumbled on a pointer to “John Gilmore’s original scans” from 1975 - 1978, presumably the base for the Usenix / Archive.org set. It’s seems that the call for materials was pretty successful. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From clemc at ccc.com Sat Oct 5 23:14:27 2024 From: clemc at ccc.com (Clem Cole) Date: Sat, 5 Oct 2024 09:14:27 -0400 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241005001433.7hukoga5bbbb3ygl@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> Message-ID: Branden. Thank you. FWIW I have generally found heirloom to be good enough for rendering most old troff on modern systems such that I can reasonably read the text. But I suspect your detail is useful to know in some cases. As they say YMMR. That said I often use the groff tools kits since it’s what comes with things like brew on my Mac but it burps on certain macros, particularly when I want to render old man pages or doc files from old Unix versions with things like .UX macro (which is a PITA). Thanks again, Clem Sent from a handheld expect more typos than usual On Fri, Oct 4, 2024 at 8:14 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > Hi Doug, > > At 2024-10-04T21:42:50+0000, Jacobson, Doug W [E CPE] via TUHS wrote: > > Folks: > > > > Long story short, I have a unpublished manuscript that a faculty > > member in my department wrote late 1980's early 2000's. He did the > > entire thing in troff, eqn, and pic. The faculty member is still > > alive. A publisher is interested in the manuscript. I have all of > > the source files on an old unix machine that still has troff, eqn and > > pic. It also has groff. This issue is that the pic commands are > > bracketed by .G1 and .G2 not .PS & .PE. > > As others noted, those are the characteristic preprocessor tokens used > by grap(1). > > groff(1) says: > A free implementation of the grap preprocessor, written by Ted > Faber ⟨faber at lunabase.org⟩, can be found at the grap website > ⟨http://www.lunabase.org/~faber/Vault/software/grap/⟩. groff > supports only this grap. > > Distributors often have a package of Faber's grap. I'm not aware of any > other in circulation. (Happy to be corrected here.) > > Please contact the groff list, groff at gnu dot org, if you have any > problems using it to format these documents and/or to note formatting > discrepancies between Unix troff and groff. There will likely be some. > > I've noted differences between DWB troff and Heirloom troff, so using > the latter does not guarantee identical rendering, and moreover > DWB/System V troff has some bugs/limitations that Heirloom and/or GNU > troffs have fixed, and some of these can affect formatting. > > Here's a list from groff's tbl(1) man page, for example. > > GNU tbl enhancements > In addition to extensions noted above, GNU tbl removes constraints > endured by users of AT&T tbl. > > • Region options can be specified in any lettercase. > > • There is no limit on the number of columns in a table, > regardless of their classification, nor any limit on the number > of text blocks. > > • All table rows are considered when deciding column widths, not > just those occurring in the first 200 input lines of a region. > Similarly, table continuation (.T&) tokens are recognized > outside a region’s first 200 input lines. > > • Numeric and alphabetic entries may appear in the same column. > > • Numeric and alphabetic entries may span horizontally. > > One can imagine how a 200+-row table could format differently between > DWB/System V and GNU tbl, without either being "wrong". > > Regards, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Oct 6 03:45:13 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 05 Oct 2024 11:45:13 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> Message-ID: <202410051745.495HjDFu829152@freefriends.org> Dan Cross wrote: > On Wed, Oct 2, 2024 at 2:27 AM wrote: > > Rik Farrow wrote: > > > And my comment about seeing code produced by programmers while doing sales > > > support dates from 1990. This isn't something new, > > > > Also true. In the late 80s I was a sysadmin at Emory U. We had a > > Vax connected to BITNET with funky hardware and UREP, the Unix RSCS > > Emulation Program, from the University of Pennsylvania. Every time > > I had to dive into that code, I felt like I needed a shower afterwards. :-) > > Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I > must point out that UREP wasn't from the University of Pennsylvania, > but rather, from The Pennsylvania State University (yes, "The" is part > of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State > (psu.edu) is a state school in University Park, which is next to State > College (really, that's the name of the town) with satellite campuses > scattered around the state. > > - Dan C. Ooops. My bad. Thanks Dan, for the correction. Either way, the code was awful. :-) Arnold From rich.salz at gmail.com Sun Oct 6 05:44:53 2024 From: rich.salz at gmail.com (Rich Salz) Date: Sat, 5 Oct 2024 15:44:53 -0400 Subject: [TUHS] 30 days of awktober Message-ID: Someone is trying to write something interesting about awk every day of this month. The thread starts here: https://mastodon.mit.edu/@eichin/113240121988228925 -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Oct 6 08:22:07 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 5 Oct 2024 17:22:07 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> Message-ID: <20241005222207.eerdrgtsttmx42kb@illithid> Hi Clem, At 2024-10-05T09:14:27-0400, Clem Cole wrote: > Branden. Thank you. FWIW I have generally found heirloom to be > good enough for rendering most old troff on modern systems such that I > can reasonably read the text. I generally get good results with it as well. I frequently compare the behaviors of DWB 3.3 troff and Heirloom troff with 2-3 versions of GNU troff (1.22.4 [2018], 1.23.0 [2023], and bleeding-edge development). Setting aside the issue of extensions (whether to the *roff language, to preprocessors, or to macro packages), I find that Heirloom fixes many DWB bugs. I think GNU troff can boast of slightly better terminal support, although nroff veterans are sometimes scandalized by GNU troff's terminal output driver (grotty(1)) assuming that it's _not_ talking to a Teletype Model 37, but rather a more-or-less ECMA-48 video terminal. To brutally abbreviate the history, for $reasons Unix nroff got frozen in amber in 1978 with respect to terminal support, and continues to live in a world where the termcap and terminfo libraries were never written. Unfortunately, the maintainer of the less(1) pager still presumes (prefers?) that world. A previous groff maintainer observed that few of our users operate paper terminals. (Nevertheless grotty retains support for them with its `-c` option.) Anton Shepelev wrote a summary I find admirably concise and blunt: "`grotty' is not an appendix to a pager, but a program for printing direct to the terminal. Most terminals support those basic ANSI control sequences, and many console programs freely use them. If a pager cannot transparently forward them to the terminal, it is a problem of the pager, not of `grotty', and having a broken -man configuration by default to just to appease `less' is stupid." > That said I often use the groff tools kits since it’s what comes with > things like brew on my Mac but it burps on certain macros, > particularly when I want to render old man pages or doc files from old > Unix versions with things like .UX macro (which is a PITA). Yes. Our ms(7) manual ("ms.ms"), originally by Larry Kollar, concedes its limitations. --- snip --- 7.1. Unix Version 7 ms macros not implemented by groff ms Several macros described in the Unix Version 7 ms documentation are unimplemented by groff ms because they are specific to the requirements of documents produced internally by Bell Laboratories, some of which also require a glyph for the Bell System logo that groff does not sup‐ port. These macros implemented several document type formats (EG, IM, MF, MR, TM, TR), were meaningful only in conjunction with the use of certain document types (AT, CS, CT, OK, SG), stored the postal addresses of Bell Labs sites (HO, IH, MH, PY, WH), or lacked a stable definition over time (UX). To compatibly render historical ms documents using these macros, we advise your documents to invoke the rm request to re‐ move any such macros it uses and then define replacements with an au‐ thentically typeset original at hand.[10] For informal purposes, a sim‐ ple definition of UX should maintain the readability of the document’s substance. ┌───────────────┐ │ .rm UX │ │ .ds UX Unix\" │ └───────────────┘ ─────────── [10] The removal beforehand is necessary because groff ms aliases these macros to a diagnostic macro, and you want to redefine the aliased name, not its target. --- end snip --- The point of the `UX` macro was to abstract away the problem of sticking a footnote at the bottom of the page to acknowledge (or in the Labs' case, announce) the holder of the Unix trade mark on its first occurrence. I suspect the CSRC did not anticipate that the trade mark would ever change hands, let alone how many times... 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 steffen at sdaoden.eu Sun Oct 6 08:23:25 2024 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sun, 06 Oct 2024 00:23:25 +0200 Subject: [TUHS] 30 days of awktober In-Reply-To: References: Message-ID: <20241005222325.imlGrAhy@steffen%sdaoden.eu> Rich Salz wrote in : |Someone is trying to write something interesting about awk every day of |this month. The thread starts here: |https://mastodon.mit.edu/@eichin/113240121988228925 The good thing is that find(1) now has + standardized. Ie his find /tmp --print0 | xargs -0 stat --format "%s %n" can now be find /tmp -exec stat --format "%s %n" {} + And the POSIX core developers mention (APPLICATION USAGE) It should be noted that using find with −print0 to pipe input to xargs −r0 is less safe than using find with −exec because if find −print0 is terminated after it has written a partial pathname, the partial pathname may be processed as if it was a complete pathname. Heh! Other than that, off-topic to this thread i am afraid, but should be posted to another, .. but now that i am here, you know, we all owe thanks to Geoff Clare and Andrey Josey (and Eric Blake of RedHat, but really, the Linux approach to this problem makes me sick, it really should have to work as shown in RFC 2553->3493), as only thanks to these people the BSD socket API is still compatible with ISO C .. at least on POSIX systems! And here is how: In stating these field mapping requirements when a cast operator is applied to the various socket address structures, the standard defines the behavior in circumstances where the behavior is undefined in the ISO C standard. The onus is on implementations to ensure that these mappings are as described in the standard, making use of implementation-specific extensions if necessary, even though this is not stated explicitly. and the solution is On page 386 line 13115 section DESCRIPTION, change: When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. to: When a pointer to a sockaddr_storage structure is cast as a pointer to a sockaddr structure, or vice versa, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a pointer to a sockaddr_storage structure is cast as a pointer to a protocol-specific address structure, or vice versa, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. When a pointer to a sockaddr structure is cast as a pointer to a protocol-specific address structure, or vice versa, the sa_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol’s address family. Additionally, the structures shall be defined in such a way that the compiler treats an access to the stored value of the sa_family_t member of any of these structures, via an lvalue expression whose type involves any other one of these structures, as permissible, despite the more restrictive expression rules on stored value access as stated in the ISO C standard. as well as this RATIONALE addition: Note that defining the sockaddr_storage and sockaddr structures using only mechanisms defined in early editions of the ISO C standard may produce aliasing diagnostics when applications use casting between pointers to the various socket address structures. Because of the large body of existing code utilizing sockets in a way that could trigger undefined behavior due to strict aliasing rules, this standard mandates that these structures can alias each other for accessing the sa_family_t member of the structures, so as to preserve well-defined semantics. An implementation's header files may need to use anonymous unions, or even an implementation-specific extension, to comply with the requirements of this standard. I love this standard. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From g.branden.robinson at gmail.com Sun Oct 6 15:53:20 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 6 Oct 2024 00:53:20 -0500 Subject: [TUHS] Why groff ms doesn't completely support historical documents In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> Message-ID: <20241006055320.wlo3syvcbma6wzk2@illithid> Someone on the TUHS list mailed me privately, prompting me to write this lengthy apology (in the classical sense) of why groff doesn't make a certain application easier. I have slightly revised my response. This message also may serve as a summary of the challenges that need to be overcome if someone else wants to tackle the job, and potentially contribute it to groff. [person creates PDFs of historical Unix documents (many of which are written using the ms macros) and wishes groff ms made the task easier] I sympathize. I sometimes render historical documents, so I prescribed in groff ms's documentation the approach that I take myself. I decided against trying to support a "-matt" or "-msatt" option in groff because it's flatly impossible to know which definition of `UX` to use. Even a date declaration in the document sheds little light, as we then have to consider the question of whether we want fidelity to the actual state of the mark at the time of that declared date, or to what would have been rendered in the author's environment--and they may have been using an ms that wasn't "up to date" in the same respect. That information, too, is not recorded in the document.[1] Providing all the macros _except_ `UX` didn't seem likely to satisfy users since that's the most important one! It shows up in body text whereas all the others seldom do--if you can live without the cover page then, often, you're golden. Except for `UX`. Finally there is the name collision problem with Berkeley. 4.2BSD and later ms defined `CT` and `TM` macros (aspects of their "thesis mode") and once again there's no declarator within the document to tell you which dialect of ms is in use. This one can be heuristically figured out with pretty good odds, I suspect, but troff works as a filter--what was I going to do, write a preprocessor just for this? (Hmm, maybe grog(1) could do it, and that would be in its wheelhouse. But there's no point until and unless we reimplement support for Berkeley thesis mode in the first place [so that grog has an option argument to report], and that is an undertaking I have demurred.[2]) It seemed like a moderate amount of work for almost zero upside. It's also hard to validate/verify my work. The only historical troffs to which I have access are Seventh Edition Unix troff (1979, before Kernighan) and DWB 3.3 (early 1990s). It's a right pain in the butt to inspect typesetter output on V7 because I have nothing that emulates a C/A/T or translates it to device-independent troff output for a "ditroff"-style device description that Kernighan troff, DWB/Hierloom Doctools troff, or GNU troff could use. And even if I had either of those, they'd have to be vetted to a _high_ degree of quality before they'd be fit for purpose; else I wouldn't know whether I was chasing bugs in the groff ms macros or the C/A/T emulator/translator. So, to summarize, I confine my compatibility efforts to _nroff_ output, and rule the Bell Labs "site" macros out of scope. I feel there is not much more I can do, and have confidence my results, without resources that I'm lacking. I hope this sheds some light on my reasoning. Regards, Branden [1] Still, if someone wants to start, I'd start here. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/vol2/ms/tmac.s [2] One person, ever, has requested it, 20 years ago. And I have no specimens of input or corresponding model output rendered by an "authentic" BSD troff [formatter executable PLUS support files] against which to develop a reconstruction. (On the bright side, the Berkeley modifications to the once-encumbered AT&T "tmac.s" are, of themselves, presumably BSD-licensed.) https://savannah.gnu.org/bugs/?64455 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From crossd at gmail.com Sun Oct 6 22:20:55 2024 From: crossd at gmail.com (Dan Cross) Date: Sun, 6 Oct 2024 08:20:55 -0400 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <202410051745.495HjDFu829152@freefriends.org> References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> <202410051745.495HjDFu829152@freefriends.org> Message-ID: On Sat, Oct 5, 2024, 1:45 PM wrote: > Dan Cross wrote: > > > On Wed, Oct 2, 2024 at 2:27 AM wrote: > > > Rik Farrow wrote: > > > > And my comment about seeing code produced by programmers while doing > sales > > > > support dates from 1990. This isn't something new, > > > > > > Also true. In the late 80s I was a sysadmin at Emory U. We had a > > > Vax connected to BITNET with funky hardware and UREP, the Unix RSCS > > > Emulation Program, from the University of Pennsylvania. Every time > > > I had to dive into that code, I felt like I needed a shower > afterwards. :-) > > > > Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I > > must point out that UREP wasn't from the University of Pennsylvania, > > but rather, from The Pennsylvania State University (yes, "The" is part > > of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State > > (psu.edu) is a state school in University Park, which is next to State > > College (really, that's the name of the town) with satellite campuses > > scattered around the state. > > Ooops. My bad. Thanks Dan, for the correction. > > Either way, the code was awful. :-) > Ha, no worries; and I can well believe that the code was awful. I do wonder if a version of it has survived somewhere; I've personally never seen it, but there's very little information about it out there anymore. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Oct 6 22:29:44 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 06 Oct 2024 06:29:44 -0600 Subject: [TUHS] UREP code (was Re: Re: Minimum Array Sizes in 16 bit C (was Maximum)) In-Reply-To: References: <20240928165812.4uyturluj4dsuwef@illithid> <20240928180138.aygrwqdwrvq3n6xt@illithid> <202410011313.491DD4ac421643@freefriends.org> <8A3A3643-B1B2-4C41-A36F-BF00AF3C7020@iitbombay.org> <202410011907.491J74wT448406@freefriends.org> <202410020549.4925nXHf489153@freefriends.org> <202410051745.495HjDFu829152@freefriends.org> Message-ID: <202410061229.496CTird901191@freefriends.org> Dan Cross wrote: > I do wonder if a version of it has survived somewhere; I've personally > never seen it, but there's very little information about it out there > anymore. I don't have it. I think it was licensed software from Penn State. I don't remember a lot of details. It gave a similar experience to that on IBM systems; as your mail travelled point to point you got a message printed on your terminal as to what node it was going through. (Or something like that.) There was also a facility similar to write(1) that let you chat with someone on a remote BITNET site. Overall, it did work. Arnold From jaapna at xs4all.nl Sun Oct 6 22:54:59 2024 From: jaapna at xs4all.nl (Jaap Akkerhuis) Date: Sun, 6 Oct 2024 14:54:59 +0200 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241005222207.eerdrgtsttmx42kb@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> Message-ID: > On 6 Oct 2024, at 00:22, G. Branden Robinson wrote: > > Unix nroff got frozen > in amber in 1978 with respect to terminal support, and continues to live > in a world where the termcap and terminfo libraries were never written. Nroff did actually read in the output description from, if I remember correctly, /usr/lib/termtab/xxx with the argument -Txxx. these where stripped object files. I have made them for Diable daisy-wheel printers. Some could create bold characters by overprinting and we once had one with two print heads, the second head had an italics daisy-wheel mounted. jaap -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Mon Oct 7 01:11:33 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sun, 6 Oct 2024 10:11:33 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> Message-ID: <20241006151133.fbj6pmujpvuuo47d@illithid> Hi Jaap, At 2024-10-06T14:54:59+0200, Jaap Akkerhuis wrote: > > On 6 Oct 2024, at 00:22, G. Branden Robinson > > wrote: > > > > Unix nroff got frozen in amber in 1978 with respect to terminal > > support, and continues to live in a world where the termcap and > > terminfo libraries were never written. > > Nroff did actually read in the output description from, if I remember > correctly, /usr/lib/termtab/xxx with the argument -Txxx. Yes. When Kernighan refactored V7 troff/nroff for device-independence, he implemented a similar scheme for each. While for troff, this resulted in device and font description files, "DESC" and a motley variety of capitalized one-or-two letter names for fonts, for nroff they were termed "driving tables", a terminological choice that concealed how closely they resembled the troff scheme. Compare, for example: https://github.com/n-t-roff/DWB3.3/blob/master/postscript/devopost/DESC https://github.com/n-t-roff/DWB3.3/blob/master/postscript/devopost/R with: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/troff/tab.37 https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/troff/tab.450 ...and the family resemblance seems clear. > these where stripped object files. I have heard tell of a "binary format" for Kernighan troff device and font descriptions but never encountered it. groff never attempted to replicate it and I gather that Plan 9 troff also discarded it. > I have made them for Diable daisy-wheel printers. Some could create > bold characters by overprinting and we once had one with two print > heads, the second head had an italics daisy-wheel mounted. Right. The Diablo features heavily in early '80s Unix documentation. However none of this has much to do, in my opinion, with the _terminal capability databases_ offered by termcap and (later) terminfo. The whole point of these is to _query_ the user's terminal type, not have to be told it with some `-T` option. To my knowledge, no nroff has ever simply looked at "$TERM" and then decided how to format output. Approximately all other Unix software that writes to a terminal behaves that way. nroff didn't, and by God some Unix grognards would have it stay that way.[1][2] Mark Nudelman's less(1) is probably the foremost contributor of inertia here, since man(1) is far and away the leading application of nroff(1), and less(1) the victorious pager program after a long and bloody campaign of attrition. (This isn't a complaint; we could have done worse. most(1) could have won instead.[3]) Lennart Jablonka has contributed a patch to groff to resolve this longevous discrepancy. (It ended up on my slow path for integration because I decided I needed to understand terminfo much better, and that in turn led me to contribute a large volume of man page revisions to ncurses, many of which can be enjoyed(?) in its 6.5 release.[4]) https://savannah.gnu.org/bugs/?63583 Regards, Branden [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312935 [2] https://unix.stackexchange.com/questions/729124/linux-9-commands-send-ansi-color-sequences-to-monochrome-terminal [3] https://invisible-island.net/ncurses/ncurses-slang.html [4] https://invisible-island.net/ncurses/announce.html https://invisible-island.net/ncurses/man/ Despite his grognard standpoint with respect to grotty(1)'s default use of SGR escape sequences in output, I would emphasize that Thomas Dickey has been a pleasure to work with. It's difficult to imagine the same being true of Alan Curry. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ron at ronnatalie.com Mon Oct 7 02:21:44 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 06 Oct 2024 16:21:44 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241006151133.fbj6pmujpvuuo47d@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <20241006151133.fbj6pmujpvuuo47d@illithid> Message-ID: For years JHU had a KSR37 with a Greek box and nroff drove it direcly sending all those ESC-8 and ESC-9 things. There were some output filters that converted this to things like the Diablo daisy wheels and even the rather crude dot matrix lineprinter we had. Eventually, George Toth, one of our programmers came up with the idea of building a C/A/T simulator. He went to the Naval Research Lab and printed out a full typeface on film from their CAT. He then cut them out and glued them to the front of an oscilliscope, one letter at a time. There was a PDP-11/20 that ran a Scanning Transmission Electron Microscope (at the time one of the few in captivity). He would take the scanning driver cables from the microscope and put them on the X/Y of the oscilliscope and then took the sense wire and put it on a photomultiplier tube that was mounted in a scope camera. He then fired up the (DOS/BATCH) microscope software to tell it to do a scan. He’d then swap the RK05 packs and bring up Minunix and read his scanned character out of the frame buffer. One character at a time he accumulated an entire Roman, Bold, Italic, and Symbol set. He wrote the emulator and we could TROFF through his software to the Versatec lineprinter we had. The chemicals from those printers makes my skin break out just thinking about it. It was the only printer we had at BRL for political reasons for quite a while. It also would eat the ink of the government issued (made oddly by a workshop for the blind) pens. -Ron From leah at vuxu.org Tue Oct 8 00:50:48 2024 From: leah at vuxu.org (Leah Neukirchen) Date: Mon, 07 Oct 2024 16:50:48 +0200 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241005222207.eerdrgtsttmx42kb@illithid> (G. Branden Robinson's message of "Sat, 5 Oct 2024 17:22:07 -0500") References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> Message-ID: <87ploc2chj.fsf@vuxu.org> "G. Branden Robinson" writes: > Anton Shepelev wrote a summary I find admirably concise and blunt: > > "`grotty' is not an appendix to a pager, but a program for printing > direct to the terminal. Most terminals support those basic ANSI > control sequences, and many console programs freely use them. If a > pager cannot transparently forward them to the terminal, it is a > problem of the pager, not of `grotty', and having a broken -man > configuration by default to just to appease `less' is stupid." I don't see the problem, less supports -R for the last 25 years... -- Leah Neukirchen https://leahneukirchen.org/ From g.branden.robinson at gmail.com Tue Oct 8 16:45:08 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 8 Oct 2024 01:45:08 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <87ploc2chj.fsf@vuxu.org> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <87ploc2chj.fsf@vuxu.org> Message-ID: <20241008064508.vtcvijqmedztrfeb@illithid> Hi Leah, At 2024-10-07T16:50:48+0200, Leah Neukirchen wrote: > "G. Branden Robinson" writes: > > Anton Shepelev wrote a summary I find admirably concise and blunt: > > > > "`grotty' is not an appendix to a pager, but a program for printing > > direct to the terminal. Most terminals support those basic ANSI > > control sequences, and many console programs freely use them. If a > > pager cannot transparently forward them to the terminal, it is a > > problem of the pager, not of `grotty', and having a broken -man > > configuration by default to just to appease `less' is stupid." > > I don't see the problem, less supports -R for the last 25 years... Yeah. People's ire seems to rise from the fact that grotty's default is to assume SGR support and less's default is to not interpret SGR. I would prefer that `-R` were less's default; that would better serve the larger proportion of ECMA-48 video terminals using the pager versus those using it with (an emulator of) hardcopy terminals. Whatever transition process needs to commence for that to happen, I think it should. But in the meantime it's no great effort for me (nor for most people) to alias 'less' to 'less -R', write a shell function to do similarly, or just type three more characters. (For those requiring accessibility assistance, shell aliases and functions, programmable key bindings, and similar should serve as they do the merely impatient.) 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 tuhs at tuhs.org Tue Oct 8 20:33:35 2024 From: tuhs at tuhs.org (Jacobson, Doug W [E CPE] via TUHS) Date: Tue, 8 Oct 2024 10:33:35 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241008064508.vtcvijqmedztrfeb@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <87ploc2chj.fsf@vuxu.org> <20241008064508.vtcvijqmedztrfeb@illithid> Message-ID: Hello group: BTW:, I love all the comments and discussions this started. Using Groff (eqn+pic) + grap I was able to create a PDF of the book. It took about 8 hours part of which was figuring out the syntax differences. He had divided the book up into a file for each page or two, so 100+ files. I think he did that, so he did not waste paper since he had to print out the pages to see if they looked right, no display to view them. It was not perfect but is good enough for the publisher to review. The book is on filters (EE book) and is full of graphs, circuits, and equations. He used pic to draw the circuits, which was amazing. This was fun to take a forgotten manuscript written by a colleague and with luck maybe getting it published while he is still alive. If the publisher wants to publish it, I'm not sure how they will handle troff files :) Doug -----Original Message----- From: G. Branden Robinson Sent: Tuesday, October 8, 2024 1:45 AM To: Leah Neukirchen Cc: Clem Cole ; Jacobson, Doug W [E CPE] ; tuhs at tuhs.org; groff at gnu.org Subject: Re: [TUHS] Re: Old troff files (1988-2007) Hi Leah, At 2024-10-07T16:50:48+0200, Leah Neukirchen wrote: > "G. Branden Robinson" writes: > > Anton Shepelev wrote a summary I find admirably concise and blunt: > > > > "`grotty' is not an appendix to a pager, but a program for printing > > direct to the terminal. Most terminals support those basic ANSI > > control sequences, and many console programs freely use them. If a > > pager cannot transparently forward them to the terminal, it is a > > problem of the pager, not of `grotty', and having a broken -man > > configuration by default to just to appease `less' is stupid." > > I don't see the problem, less supports -R for the last 25 years... Yeah. People's ire seems to rise from the fact that grotty's default is to assume SGR support and less's default is to not interpret SGR. I would prefer that `-R` were less's default; that would better serve the larger proportion of ECMA-48 video terminals using the pager versus those using it with (an emulator of) hardcopy terminals. Whatever transition process needs to commence for that to happen, I think it should. But in the meantime it's no great effort for me (nor for most people) to alias 'less' to 'less -R', write a shell function to do similarly, or just type three more characters. (For those requiring accessibility assistance, shell aliases and functions, programmable key bindings, and similar should serve as they do the merely impatient.) Regards, Branden From g.branden.robinson at gmail.com Tue Oct 8 20:49:33 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Tue, 8 Oct 2024 05:49:33 -0500 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <87ploc2chj.fsf@vuxu.org> <20241008064508.vtcvijqmedztrfeb@illithid> Message-ID: <20241008104933.snbk6wxt4rpaahfl@illithid> [dropped Clem and Leah from CC] Hi Doug, At 2024-10-08T10:33:35+0000, Jacobson, Doug W [E CPE] wrote: > Using Groff (eqn+pic) + grap I was able to create a PDF of the book. > It took about 8 hours 8-O > part of which was figuring out the syntax differences. Oh, wall clock time including human engagement. That sounds really reasonable! I'm not sure I want to estimate how many hours I've put into revising groff's own documentation. Or ncurses's. Eight hours processing time on a modern machine (without inflooping) would be shocking to me. > He had divided the book up into a file for each page or two, so 100+ > files. I think he did that, so he did not waste paper since he had to > print out the pages to see if they looked right, no display to view > them. No PostScript or PDF preview program? I can think of a few: mupdf, evince, okular. Deri James (groff developer) can probably name a dozen. > It was not perfect but is good enough for the publisher to review. > The book is on filters (EE book) and is full of graphs, circuits, and > equations. He used pic to draw the circuits, which was amazing. This > was fun to take a forgotten manuscript written by a colleague and with > luck maybe getting it published while he is still alive. If the > publisher wants to publish it, I'm not sure how they will handle troff > files :) If you'd care to share it with me in my capacity as groff maintainer, I'd be interested to use it for unofficial regression testing. Alternatively, if you can't find an interested publisher, please consider asking the author (I assume he's also the copyright holder) to release it under a Creative Commons license so the whole world can enjoy. Also, so I can selfishly enjoy the pleasure of pointing to a sophisticated typeset work and saying, "look what groff can do!" ;-) (Just in case people aren't impressed enough with K&R or W. Richard Stevens.) 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 tuhs at tuhs.org Tue Oct 8 21:24:52 2024 From: tuhs at tuhs.org (Jacobson, Doug W [E CPE] via TUHS) Date: Tue, 8 Oct 2024 11:24:52 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: <20241008104933.snbk6wxt4rpaahfl@illithid> References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <87ploc2chj.fsf@vuxu.org> <20241008064508.vtcvijqmedztrfeb@illithid> <20241008104933.snbk6wxt4rpaahfl@illithid> Message-ID: Branden: 8 hours of my time, not computer time. The faculty member started this in 1988, and we (the department) did not have access to much in the way of visual previewing. He was an EE by training, and really latched onto Unix, vi, troff, etc. At the time we were running a series of AT&T 3B2/5, and a 3B20. My wife was sysadmin and I was on the faculty. We had a large number of faculty and staff using troff for editing and publishing. I remember my wife teaching Unix and Troff to faculty. We did have a few of the AT&T graphics terminal (I cannot remember the model number) Another fun thing, I used troff and vi (on a different) system to write my Ph.D. in 1985. I will reach out to you about the files etc. He is the copyright holder. His health is not good, and his family with the help of a former student is the one hoping to get it published. Doug -----Original Message----- From: G. Branden Robinson Sent: Tuesday, October 8, 2024 5:50 AM To: Jacobson, Doug W [E CPE] Cc: tuhs at tuhs.org; groff at gnu.org Subject: Re: [TUHS] Re: Old troff files (1988-2007) [dropped Clem and Leah from CC] Hi Doug, At 2024-10-08T10:33:35+0000, Jacobson, Doug W [E CPE] wrote: > Using Groff (eqn+pic) + grap I was able to create a PDF of the book. > It took about 8 hours 8-O > part of which was figuring out the syntax differences. Oh, wall clock time including human engagement. That sounds really reasonable! I'm not sure I want to estimate how many hours I've put into revising groff's own documentation. Or ncurses's. Eight hours processing time on a modern machine (without inflooping) would be shocking to me. > He had divided the book up into a file for each page or two, so 100+ > files. I think he did that, so he did not waste paper since he had to > print out the pages to see if they looked right, no display to view > them. No PostScript or PDF preview program? I can think of a few: mupdf, evince, okular. Deri James (groff developer) can probably name a dozen. > It was not perfect but is good enough for the publisher to review. > The book is on filters (EE book) and is full of graphs, circuits, and > equations. He used pic to draw the circuits, which was amazing. This > was fun to take a forgotten manuscript written by a colleague and with > luck maybe getting it published while he is still alive. If the > publisher wants to publish it, I'm not sure how they will handle troff > files :) If you'd care to share it with me in my capacity as groff maintainer, I'd be interested to use it for unofficial regression testing. Alternatively, if you can't find an interested publisher, please consider asking the author (I assume he's also the copyright holder) to release it under a Creative Commons license so the whole world can enjoy. Also, so I can selfishly enjoy the pleasure of pointing to a sophisticated typeset work and saying, "look what groff can do!" ;-) (Just in case people aren't impressed enough with K&R or W. Richard Stevens.) Regards, Branden From douglas.mcilroy at dartmouth.edu Tue Oct 8 22:21:54 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 8 Oct 2024 08:21:54 -0400 Subject: [TUHS] groff_man.7.man.in: Some remarks and editorial changes for this man page Message-ID: The titled post reminds me of Ted Dolotta, a guru of PWB Unix, whose eye for editorial detail was unsurpassed. He could spot the difference between italic and roman periods at twenty paces. Bjarni is in good company. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Tue Oct 8 22:24:51 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 8 Oct 2024 08:24:51 -0400 Subject: [TUHS] Fwd: groff_man.7.man.in: Some remarks and editorial changes for this man page In-Reply-To: References: Message-ID: Once again I emailed the wrong list, so here it is again, sent to both, since it touches on both groff and history. Sorry, Doug ---------- Forwarded message --------- From: Douglas McIlroy Date: Tue, Oct 8, 2024 at 8:21 AM Subject: Re: groff_man.7.man.in: Some remarks and editorial changes for this man page To: TUHS main list The titled post reminds me of Ted Dolotta, a guru of PWB Unix, whose eye for editorial detail was unsurpassed. He could spot the difference between italic and roman periods at twenty paces. Bjarni is in good company. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Oct 10 07:02:12 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 09 Oct 2024 21:02:12 +0000 Subject: [TUHS] Old troff files (1988-2007) In-Reply-To: References: <20241005001433.7hukoga5bbbb3ygl@illithid> <20241005222207.eerdrgtsttmx42kb@illithid> <20241006151133.fbj6pmujpvuuo47d@illithid> Message-ID: I got a chuckle because apparently an old quote of mine is enshrined in the GROFF documentation (under the debugging section): Standard troff voodoo, just put a power of two backslashes in front of it until it works and if you still have problems add a \c. — Ron Natalie Thanks, G. Branden Robinson, for calling it to my attention. More nroff fun and games: My first job out of college was working on a restricted government project on RSX-11/M. I’d been doing various UNIX and n/troff stuff for years at JHU. The QA people decided to go all PWB on this project using SCCS etc… I knew that Denis Mumaugh at the NSA had written nroff macros to do classification markings automatically. I asked for a copy, but he couldn’t figure out how to get a tape to me. I reimplemented it myself. Originally, I had the idea of processing each marked paragraph into a diversion but that was problematic. I then just output the footer and then “reverse fed” the paper back to the top to add the top classification. Of course, you had to run your nroff via col to get it to print right. I also fixed the line printer spooler to catch classification markings and mark them pages appropriately as well. All this I did while waiting the 11 months for my ‘beyond TS’ clearance to arrive. Seems like everybody on the project failed their polygraph the first time. Examiner must have had a hard seat on the bus from the east coast. This was also the project where I had this exchange: Bernie: What’s all this Bell System crud in the editor? Me: It’s UNIX. It’s all Bell System crud. I walk around to his terminal and see this: $ 1 One Bell System. It works. $ 1 One Bell System. It works. Me: You’re not in the editor, Bernie. After that the /usr/bin/1 command was changed to echo “You’re not in the editor, Bernie.” From tuhs at tuhs.org Thu Oct 10 12:26:38 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 10 Oct 2024 02:26:38 +0000 Subject: [TUHS] BTL Involvement in Publication Imagery? Message-ID: So in the course of AT&T's involvement with UNIX, a number of different images and motifs have graced advertisements and covers of literature, among them: - Letter Blocks (V7 HRW manuals, Release 4.0 Starter Packages) - Criss-crossing grid lines on a black background (Release 5.0/SVR1) - Variations on an image of earth with UNIX superimposed (SVR3/SVR4) - Covers mirroring publication motifs of other AT&T products and literature (SVR2/SVR3) Did the folks actually involved in the production of UNIX have any influence on the choice of design motifs for such materials, or would those sorts of decisions have been largely in the hands of marketing folks several layers removed from the Labs? My understanding is that this sort of visual branding started in the early 80s, with the earliest example of a printed piece of UNIX literature outside of generic Bell Laboratories covers I'm aware of being the "Starter Package" documents featuring UNIX spelled out on four letter blocks in primary colors. Everything I've seen branded predating these 1981 publications is either 8.5/11 pages in a Bell Labs or Western Electric report cover or the form factor of the Release 3.0 manual using generic Bell Labs covers. I'm certainly intrigued if anyone has any recollection of any sort of visual motifs in play prior to 1981. - Matt G. From douglas.mcilroy at dartmouth.edu Fri Oct 11 01:41:34 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 10 Oct 2024 11:41:34 -0400 Subject: [TUHS] BTL Involvement in Publication Imagery? Message-ID: Unix folk were barely involved in the branding or advertising of the system. I recall that we got to proofread and edit the first Unix ad, but essentially nothing later. Nor did we contribute to the cover designs of the 7th edition trade verson or the 8th-10th in-house versions of the manual. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Oct 11 02:07:48 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 10 Oct 2024 16:07:48 +0000 Subject: [TUHS] BTL Involvement in Publication Imagery? In-Reply-To: References: Message-ID: On Thursday, October 10th, 2024 at 8:41 AM, Douglas McIlroy wrote: > Unix folk were barely involved in the branding or advertising of the system. I recall that we got to proofread and edit the first Unix ad, but essentially nothing later. Nor did we contribute to the cover designs of the 7th edition trade verson or the 8th-10th in-house versions of the manual. > Doug Thanks Doug (and Arnold Robbins in another stream)!  Doug I tossed up the cover scans you sent me some time ago here: https://wiki.tuhs.org/doku.php?id=publications:manuals:research The other pages under publications:manuals that I've filled out also have photographs of covers from my bookshelf. I figured what you described was the case, I don't know anything about the "face" of our stuff at work until someone gives me a logo to put on a site or application somewhere, I can't imagine most technical folks give a hoot what mask their products wear when they step out in the world. - Matt G. From arnold at skeeve.com Sun Oct 13 15:46:49 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 12 Oct 2024 23:46:49 -0600 Subject: [TUHS] Copyright on 4.2BSD? Message-ID: <202410130546.49D5knwV1564291@freefriends.org> Hi All. I'm working on revising my book on basic *nix programming, and for the new chapter on sockets, I want to include some code from 4.2 BSD. Is there a copyright file somewhere for that code? I'm sure it's copyright the Regents of the University of California, but I'd like to include the text of the copyright in the book, so that everything's clear. Thanks! Arnold From arnold at skeeve.com Sun Oct 13 15:54:49 2024 From: arnold at skeeve.com (Aharon Robbins) Date: Sun, 13 Oct 2024 08:54:49 +0300 Subject: [TUHS] V8 and V9 manual covers Message-ID: Hello All, I took a picture of my V8 and V9 manuals the other day. It's available at https://www.skeeve.com/V8-V9-Covers.jpg. @segaloco: This one's for you. :-) Enjoy, Arnold From mvivirito at gmail.com Sun Oct 13 16:03:14 2024 From: mvivirito at gmail.com (Michael Vivirito) Date: Sat, 12 Oct 2024 23:03:14 -0700 Subject: [TUHS] V8 and V9 manual covers In-Reply-To: References: Message-ID: It says “forbidden” when I try to access -------------- next part -------------- An HTML attachment was scrubbed... URL: From stu at remphrey.net Sun Oct 13 16:11:23 2024 From: stu at remphrey.net (Stuart Remphrey) Date: Sun, 13 Oct 2024 16:11:23 +1000 Subject: [TUHS] V8 and V9 manual covers In-Reply-To: References: Message-ID: Ditto: Forbidden You don't have permission to access this resource. On Sun, 13 Oct 2024, 16:03 Michael Vivirito, wrote: > > It says “forbidden” when I try to access > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Sun Oct 13 16:16:34 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 13 Oct 2024 00:16:34 -0600 Subject: [TUHS] V8 and V9 manual covers In-Reply-To: References: Message-ID: <202410130616.49D6GYjG1567788@freefriends.org> Aharon Robbins wrote: > Hello All, > > I took a picture of my V8 and V9 manuals the other day. It's available > at https://www.skeeve.com/V8-V9-Covers.jpg. > > @segaloco: This one's for you. :-) > > Enjoy, > > Arnold Permissions on the file were booked. I just did a chmod 644 on it. "Sorry about that, Chief." Thanks to those who let me know, Arnold From fjarlq at gmail.com Sun Oct 13 17:40:52 2024 From: fjarlq at gmail.com (Matt Day) Date: Sun, 13 Oct 2024 01:40:52 -0600 Subject: [TUHS] Copyright on 4.2BSD? In-Reply-To: <202410130546.49D5knwV1564291@freefriends.org> References: <202410130546.49D5knwV1564291@freefriends.org> Message-ID: An interesting TUHS thread from 2022 about the origins of the BSD license: https://www.tuhs.org/mailman3/hyperkitty/list/tuhs at tuhs.org/thread/G354W5YHSHXY2NZ4BYJEKQECTUMK7X7I/#7EWKS5KWJAS7YWQ7AVXDME4Y5XGBXXM2 On Sat, Oct 12, 2024 at 11:47 PM wrote: > Hi All. > > I'm working on revising my book on basic *nix programming, and for > the new chapter on sockets, I want to include some code from 4.2 BSD. > > Is there a copyright file somewhere for that code? I'm sure it's > copyright the Regents of the University of California, but I'd like > to include the text of the copyright in the book, so that everything's > clear. > > Thanks! > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sun Oct 13 18:22:31 2024 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 13 Oct 2024 04:22:31 -0400 (EDT) Subject: [TUHS] Copyright on 4.2BSD? In-Reply-To: <202410130546.49D5knwV1564291@freefriends.org> References: <202410130546.49D5knwV1564291@freefriends.org> Message-ID: On Sat, 12 Oct 2024, arnold at skeeve.com wrote: > Hi All. > > I'm working on revising my book on basic *nix programming, and for > the new chapter on sockets, I want to include some code from 4.2 BSD. > > Is there a copyright file somewhere for that code? I'm sure it's > copyright the Regents of the University of California, but I'd like > to include the text of the copyright in the book, so that everything's > clear. > > Thanks! > > Arnold > >From what I would ascertain it would, logically, fall under a copyright to UCB if it comes from UCB, and under 32V's (questionable) copyright if not. Oldest BSD I have any sort of code for is 4.3 and at least by that point most of the Berkeley stuff is marked with this copyright string: /* * Copyright (c) 198x Regents of the University of California. * All rights reserved. The Berkeley software License Agreement * specifies the terms and conditions for redistribution. */ Some earlier stuff only has the first line. -uso. From arnold at skeeve.com Sun Oct 13 18:31:14 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 13 Oct 2024 02:31:14 -0600 Subject: [TUHS] Copyright on 4.2BSD? In-Reply-To: References: <202410130546.49D5knwV1564291@freefriends.org> Message-ID: <202410130831.49D8VENj1581180@freefriends.org> Steve Nickolas wrote: > On Sat, 12 Oct 2024, arnold at skeeve.com wrote: > > > Hi All. > > > > I'm working on revising my book on basic *nix programming, and for > > the new chapter on sockets, I want to include some code from 4.2 BSD. > > > > Is there a copyright file somewhere for that code? I'm sure it's > > copyright the Regents of the University of California, but I'd like > > to include the text of the copyright in the book, so that everything's > > clear. > > > > Thanks! > > > > Arnold > > > > From what I would ascertain it would, logically, fall under a copyright to > UCB if it comes from UCB, and under 32V's (questionable) copyright if not. > > Oldest BSD I have any sort of code for is 4.3 and at least by that point > most of the Berkeley stuff is marked with this copyright string: > > /* > * Copyright (c) 198x Regents of the University of California. > * All rights reserved. The Berkeley software License Agreement > * specifies the terms and conditions for redistribution. > */ > > Some earlier stuff only has the first line. > > -uso. Thanks. But, ... is there some sort of copying permissions to include also? Or is it the same as 32V and covered by Caldera license? Arnold From imp at bsdimp.com Mon Oct 14 00:51:58 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 13 Oct 2024 08:51:58 -0600 Subject: [TUHS] Copyright on 4.2BSD? In-Reply-To: <202410130831.49D8VENj1581180@freefriends.org> References: <202410130546.49D5knwV1564291@freefriends.org> <202410130831.49D8VENj1581180@freefriends.org> Message-ID: On Sun, Oct 13, 2024 at 2:31 AM wrote: > Steve Nickolas wrote: > > > On Sat, 12 Oct 2024, arnold at skeeve.com wrote: > > > > > Hi All. > > > > > > I'm working on revising my book on basic *nix programming, and for > > > the new chapter on sockets, I want to include some code from 4.2 BSD. > > > > > > Is there a copyright file somewhere for that code? I'm sure it's > > > copyright the Regents of the University of California, but I'd like > > > to include the text of the copyright in the book, so that everything's > > > clear. > > > > > > Thanks! > > > > > > Arnold > > > > > > > From what I would ascertain it would, logically, fall under a copyright > to > > UCB if it comes from UCB, and under 32V's (questionable) copyright if > not. > > > > Oldest BSD I have any sort of code for is 4.3 and at least by that point > > most of the Berkeley stuff is marked with this copyright string: > > > > /* > > * Copyright (c) 198x Regents of the University of California. > > * All rights reserved. The Berkeley software License Agreement > > * specifies the terms and conditions for redistribution. > > */ > > > > Some earlier stuff only has the first line. > > > > -uso. > > Thanks. But, ... is there some sort of copying permissions to > include also? Or is it the same as 32V and covered by Caldera license? > No. For 4.2BSD we're firmly in the 'we send this to anybody that has an AT&T license only; era, and in such an era, there's not going to be clarity.I don't think the regents have made a definitive statement regarding code from this era after the historic Unix license from Caldera. The next best thing is looking a the model license that most people signed ot get the 4.2BSD tapes and see what that says. A quick google search didn't turn up the model 4.2BSD license agreement, but it's likely similar to https://cm-bell-labs.github.io/who/dmr/bsdi/BSD_ATT_License.pdf which sets forth the terms of copying within AT&T, but is likely broadly similar to other licensees now that either there's no 32V copyright or there's permission to copy 32V for these purposes. The most salient part is likely: Proper Credit and Recognition. In the use of any part of 4.2 BSD and 4.3 BSD, AT&T will give appropriate credit to the University and the Electrical Engineering and Computer Sciences Department at the Berkeley Campus of the University of California and Other Contributors for their roles in its development and will require sublicensees to give such credit. If AT&T is providing documentation similar to that which is provided with 4.2 BSD and 4.3 BSD, notices similar to those included in that documentation suffice to satisfy this requirement. If AT&T is providing new documentation, this requirement will be satisfied if each document includes the following statement: 'This software and documentation is based in part on the Fourth Berkeley Software distribution under license from The Regents of the University of California. We acknowledge the following individuals and institutions for their role in its development: [insert names of individuals and institutions which appear in the documentation provided to AT&T as part of 4.2 BSD and 4.3 BSD for those portions of said Distribution used by AT&T.]' This suggests you should include the phrase above, or one that's similar to it that's more appropriate for the context, to comply with the spirit of what was most likely in those original 4.2BSD agreements. I don't think it will get any better clarity than guessing based on this document that came to light as part of the AT&T litigation. I believe this is independent of the 32V determination because the copyright to the changes hasn't ever been challenged. However, since it's just snippets of code that's otherwise available, and since you're using it in a work that's clearly an academic critique or criticism of a de-minimis portion of 4.2BSD, it may fall under 'fair use' and not need any specific permission. Given the release of 4.2BSD was 40 years ago or so, and the regents have generally been uninterested in policing the license compliance of 4.2 code, i suspect that an acknowledgement would suffice to keep them from doing anything. It would also comply with the general intent of the licenses and practices at the time and even if all that failed, there's several other reasons that would make such use in your book easily defensible. Sorry I didn't have a better, easy and clear answer. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Mon Oct 14 01:03:28 2024 From: aek at bitsavers.org (Al Kossow) Date: Sun, 13 Oct 2024 08:03:28 -0700 Subject: [TUHS] Copyright on 4.2BSD? In-Reply-To: References: <202410130546.49D5knwV1564291@freefriends.org> <202410130831.49D8VENj1581180@freefriends.org> Message-ID: <7682b07b-25d1-fdbb-dd6d-dc63ce19dea3@bitsavers.org> Has anyone gone back to the original BBN/ARPA code UCB started with to look for commonalities? Does it still exist? Does anyone care? From tuhs at tuhs.org Mon Oct 14 17:01:36 2024 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Mon, 14 Oct 2024 09:01:36 +0200 Subject: [TUHS] Copyright on 4.2BSD? In-Reply-To: <202410130546.49D5knwV1564291@freefriends.org> References: <202410130546.49D5knwV1564291@freefriends.org> Message-ID: On Sat, Oct 12, 2024 at 11:46:49PM -0600, arnold at skeeve.com wrote: > I'm working on revising my book on basic *nix programming, and for > the new chapter on sockets, I want to include some code from 4.2 BSD. Does 'code from 4.2 BSD' mean snippets of actual kernel code or more like examples of BSD-specific syscalls and networking (socket(), select()) and such? In the latter case you could see if you can still get a copy of the old (1986) book 'C Programming in the Berkeley Unix Environment' which was pretty much filled with BSD specific stuff and how that was perhaps done in attributing the correct parties: https://www.abebooks.com/9780131097605/Programming-Berkeley-Unix-Environment-Horspool-0131097601/plp Unfortunately my copy got lost over some moves, so I no longer have one to look it up... Bye, Arno. From andrew at humeweb.com Wed Oct 16 02:30:43 2024 From: andrew at humeweb.com (andrew at humeweb.com) Date: Tue, 15 Oct 2024 09:30:43 -0700 Subject: [TUHS] lilian schwartz has died Message-ID: <3B10A7A3-8D32-49E3-87ED-4BBC207E8050@humeweb.com> lilian worked at bell labs in the 80s (and maybe 90s) around tech and films and suchlike. From mrochkind at gmail.com Wed Oct 16 03:52:38 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Tue, 15 Oct 2024 11:52:38 -0600 Subject: [TUHS] lilian schwartz has died In-Reply-To: <3B10A7A3-8D32-49E3-87ED-4BBC207E8050@humeweb.com> References: <3B10A7A3-8D32-49E3-87ED-4BBC207E8050@humeweb.com> Message-ID: And here are some of her short films, on her website: http://lillian.com/films/ On Tue, Oct 15, 2024 at 10:37 AM andrew at humeweb.com wrote: > lilian worked at bell labs in the 80s (and maybe 90s) > around tech and films and suchlike. > > -- *My new email address is mrochkind at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Wed Oct 16 10:16:42 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 15 Oct 2024 20:16:42 -0400 Subject: [TUHS] lilian schwartz has died Message-ID: > lilian worked at bell labs in the 80s (and maybe 90s) > around tech and films and suchlike. Lillian was a real pioneer. She began collaborating at the Labs in the mid 1960s. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.txt at gmail.com Thu Oct 17 07:40:23 2024 From: anton.txt at gmail.com (Anton Shepelev) Date: Thu, 17 Oct 2024 00:40:23 +0300 Subject: [TUHS] Old troff files (1988-2007) References: Message-ID: <20241017004023.33ab14eb86c0dc85974b4f3c@gmail.com> Jacobson, Doug W: > Long story short, I have a unpublished manuscript that a fac- > ulty member in my department wrote late 1980's early 2000's. > He did the entire thing in troff, eqn, and pic. The faculty > member is still alive. A publisher is interested in the > manuscript. I have all of the source files on an old unix ma- > chine that still has troff, eqn and pic. It also has groff. *roff has so spectacular a backwards compatibiliy that its mod- ern implementaions will not only accept a source from the 1970s but actually produce a historically accurate rendition of it. Unlike MS Word, *roff the kind of software that you need not bother to keep an old version to open your old files. I therefore suggest that you install a modern *roff and seek as- sistance with your task in its community. GNU Troff is the only one I know and use (even for this e-mail), can recommend it for both hard (the program itself) and soft (the friendly community and great maintaner) qualities. They are also interested and successful in recreating historial documents, so feel free to ask in their mailing list. From anton.txt at gmail.com Thu Oct 17 08:30:10 2024 From: anton.txt at gmail.com (Anton Shepelev) Date: Thu, 17 Oct 2024 01:30:10 +0300 Subject: [TUHS] Can Ancient Unix be relicensed? Message-ID: <20241017013010.a40487c4e71937a5740caabf@gmail.com> Hello, all. In 2002, Caldera released Ancient Unix code under Caldera license: based on the four-clause BSD license: Consequently, it was used by derived projects, such as Traditional Vi: This proect having been abandoned and orphaned since 2005, I wanted to host it on GNU Savanna and there to breath some life into it. Unfortunately, the 4-clause BSD license is incompatible with GPL: The incompatibilty is due entirely to the infamous third clause about adverising. Three years prior to Caldera's release of old Unix code, The Berkley Univercity removed this clause, producing the GNU-compatible modified BSD License: They published a notice to that effect on their FTP: Although it has been taken down[1], copies exist all over the internet, e.g.: That said, is there a chance that the copyright holder of Ancient Will agree to release a similar note regarding everying released under Caldera license? If there is, whom shall I contact about it? It will benefit everybody using Ancient Unix code. ____________________ 1. Why the murrain of FTP servers all over the world? From imp at bsdimp.com Thu Oct 17 08:55:18 2024 From: imp at bsdimp.com (Warner Losh) Date: Wed, 16 Oct 2024 16:55:18 -0600 Subject: [TUHS] Can Ancient Unix be relicensed? In-Reply-To: <20241017013010.a40487c4e71937a5740caabf@gmail.com> References: <20241017013010.a40487c4e71937a5740caabf@gmail.com> Message-ID: On Wed, Oct 16, 2024, 4:30 PM Anton Shepelev wrote: > Hello, all. > > In 2002, Caldera released Ancient Unix code under Caldera > license: > > > > based on the four-clause BSD license: > > > > Consequently, it was used by derived projects, such as > Traditional Vi: > > > > This proect having been abandoned and orphaned since 2005, I > wanted to host it on GNU Savanna and there to breath some > life into it. Unfortunately, the 4-clause BSD license is > incompatible with GPL: > > > > The incompatibilty is due entirely to the infamous third > clause about adverising. Three years prior to Caldera's > release of old Unix code, The Berkley Univercity removed > this clause, producing the GNU-compatible modified BSD > License: > > > > They published a notice to that effect on their FTP: > > > > Although it has been taken down[1], copies exist all over > the internet, e.g.: > > < > https://raw.githubusercontent.com/abbrev/punix/refs/heads/master/README.Impt.License.Change > > > > That said, is there a chance that the copyright holder of > Ancient Will agree to release a similar note regarding > everying released under Caldera license? If there is, whom > shall I contact about it? It will benefit everybody using > Ancient Unix code. > That's a complicated question. Does 32V have a valid copyright? Maybe, maybe not. There is a preliminary ruling suggesting no that effectively forced AT&T to settle with the Regents, but it was never finalized. There's good reasons to believe its logic and fact pattern would apply to 7th edition and maybe 6th. Putting that aside, there has been a dispute over what copyrights transferred from Novell to SCO. A judge said no for System V, undermining SCO's case. But older copyrights weren't explivitly named, but the same thing: the facts patterns for System V likely applied to older Unix. So, Novell's assets have been sold 4 times or more. Finding the right people inside the current company to talk to is hard. It's not their promary business. It's not clear how many rights they have. It's hard to show how it could benefit them. And even if you could, another sale might happen in the mean time. People have been teying to get even a statement that old SCO legitimately granted the Ancient license to no avail. So I'm doubtful. Your best bet is to not make your changes available under the GPL. They cut against the spirit of 4 clause BSD and step in the middle of a very old Stallman vs Berkeley dispute from the 4.2 era... At this point, it's a mess Warner ____________________ > 1. Why the murrain of FTP servers all over the world? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.txt at gmail.com Thu Oct 17 09:34:14 2024 From: anton.txt at gmail.com (Anton Shepelev) Date: Thu, 17 Oct 2024 02:34:14 +0300 Subject: [TUHS] Can Ancient Unix be relicensed? References: <20241017013010.a40487c4e71937a5740caabf@gmail.com> Message-ID: <20241017023414.834be891f47301195bdfa510@gmail.com> Warner Losh to Anton Shepelev: > > In 2002, Caldera released Ancient Unix code under > > Caldera license: > > > > > > > > based on the four-clause BSD license: > > > > > > > > [...] > > Unfortunately, the 4-clause BSD license is incompatible > > with GPL: > > > > > > > > The incompatibilty is due entirely to the infamous third > > clause about adverising. Three years prior to Caldera's > > release of old Unix code, The Berkley Univercity removed > > this clause, producing the GNU-compatible modified BSD > > License: > > [...] > > That said, is there a chance that the copyright holder > > of Ancient Will agree to release a similar note > > regarding everything released under Caldera license? > > That's a complicated question. > [...snipped.but.read...] Complicated indeed, and to a degree I should not have expected. So it was not an arbitrary decision by Caldera to use the original BSD license? Can they have used the modern three- clause version with equal ease? > Finding the right people inside the current company to > talk to is hard. It's not their promary business. It's not > clear how many rights they have. It's hard to show how it > could benefit them. No worldly benefit; the bare goodwill is all I can hope for. > So I'm doubtful. Your best bet is to not make your changes > available under the GPL. The four-clause BSD license excludes not only GPL itself, but (I think) the many GPL-compatible licenses. The simplest thing for me to do is probably to keep the BSD-like Caldera license. Thanks for the feedback, Warner! From tuhs at tuhs.org Thu Oct 17 09:58:47 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 16 Oct 2024 23:58:47 +0000 Subject: [TUHS] Can Ancient Unix be relicensed? In-Reply-To: <20241017023414.834be891f47301195bdfa510@gmail.com> References: <20241017013010.a40487c4e71937a5740caabf@gmail.com> <20241017023414.834be891f47301195bdfa510@gmail.com> Message-ID: On Wednesday, October 16th, 2024 at 4:34 PM, Anton Shepelev wrote: > Warner Losh to Anton Shepelev: > > > > In 2002, Caldera released Ancient Unix code under > > > Caldera license: > > > > > > https://www.tuhs.org/Archive/Caldera-license.pdf > > > > > > based on the four-clause BSD license: > > > > > > https://spdx.org/licenses/BSD-4-Clause.html > > > > > > [...] > > > Unfortunately, the 4-clause BSD license is incompatible > > > with GPL: > > > > > > https://www.gnu.org/licenses/license-list.html#OriginalBSD > > > > > > The incompatibilty is due entirely to the infamous third > > > clause about adverising. Three years prior to Caldera's > > > release of old Unix code, The Berkley Univercity removed > > > this clause, producing the GNU-compatible modified BSD > > > License: > > > [...] > > > That said, is there a chance that the copyright holder > > > of Ancient Will agree to release a similar note > > > regarding everything released under Caldera license? > > > > That's a complicated question. > > [...snipped.but.read...] > > > Complicated indeed, and to a degree I should not have > expected. > > So it was not an arbitrary decision by Caldera to use the > original BSD license? Can they have used the modern three- > clause version with equal ease? > > > Finding the right people inside the current company to > > talk to is hard. It's not their promary business. It's not > > clear how many rights they have. It's hard to show how it > > could benefit them. > > > No worldly benefit; the bare goodwill is all I can hope for. > > > So I'm doubtful. Your best bet is to not make your changes > > available under the GPL. > > > The four-clause BSD license excludes not only GPL itself, > but (I think) the many GPL-compatible licenses. The > simplest thing for me to do is probably to keep the BSD-like > Caldera license. Thanks for the feedback, Warner! The devilish side of me often thinks of the concept of dereliction of copyright and the precedent for demonstrating something has passed hands enough and been publicized enough without demonstrably action by the legal copyright holder that any claim made all those years later is without standing; they have not over time demonstrated any efforts to effectively police their ownership of the property. I believe this is part of the tale with 32V. Given the lack of effort by post-Novell holders to even establish specific claims to UNIX copyrights...and the court agreeing way back when that Novell, not SCO, became the arbiter of UNIX System V, this has me wonder from time to time if someone just going out there and doing a published release of this stuff would materially amount to legal jeopardy. My take on this is there are three primary players in the question of System V ownership (ignoring all the sub-licensees and holders of copyright to individual files for a moment). On one hand, Bell Laboratories and Western Electric DNA lives on in Nokia. On another, USG/USL legacy passed hands from Novell to a holding company to MicroFocus, then to OpenText. Then there's the SCO track that ends at Xinuos today. Between Nokia, OpenText, and Xinuos, the latter is the only I see actively selling UNIX System V products (UnixWare), but also being that they descend from the SCO branch of the tree here, and SCO continues to fail to use UNIX as a vehicle for riches-through-litigation, I don't think anyone really needs to worry about Xinuos. Nokia spun down 5ESS stuff this past year or so, which was their most visible UNIX-adjacent thing (via UNIX-RTR). OpenText as an organization today seems focused on CMS solutions and MicroFocus, which it acquired, is most famous in my mind for their compilers, especially COBOL. Given this, I highly doubt Nokia or OpenText give a hoot about old UNIX code. Where they *may* care is getting subsequently sued by some copyright holder of a contributed piece that had specific terms on transferring or sharing their copyright with AT&T. Again though, then you just start recursing down the secondary, tertiary, etc. claimants, it all depends on the terms which may be obscure to all their legal folks by this point. Anywho, in this year of 2024, if you really wanted to get down and dirty with a bunch of lawyers and drive this one home, I suspect you'd want the ear of folks at Nokia, OpenText, and to a lesser extent (if they'd listen...) Xinuos. Of course there's then IBM, HP, Oracle, possibly Microsoft, really depends on the legal circumstances surrounding their (and others) involvement with commercial UNIX. Of course this is all my own research and I haven't consulted with any of these parties, so YMMV regarding taking my analysis as absolute truth. I make no claims to speak for the legal rights of any real or imaginary UNIX copyright holders. - Matt G. From g.branden.robinson at gmail.com Thu Oct 17 10:02:02 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Wed, 16 Oct 2024 19:02:02 -0500 Subject: [TUHS] Draft v5: London and Reiser's UNIX VAX port paper, reconstructed Message-ID: <20241017000202.5l5adjemjvqa4ilb@illithid> Hi folks, A few months ago I reported on my efforts to reconstruct London & Reiser's paper on their port of Unix to the VAX-11/780.[1] I formerly characterized this as "the UNIX/32V port", but since London & Reiser's paper predates the release of Seventh Edition Unix by about six months, UNIX/32V came _after_ Seventh Edition by about the same number of months, and the pace of Unix development was particularly ferocious in this period[2], I felt that my identification of London & Reiser's work with UNIX/32V may have been hasty. I also may have overinterpreted Dennis Ritchie's words on the subject. "Tom London and John Reiser, working from the 7th Edition and the Interdata 8/32 system, generated a VAX 11/780 version of the system, which, in its distribution format, would be called 32V." That phrase "in its distribution format" could cover a variety of changes, some of which perhaps did not match London & Reiser's intentions or views expressed in their paper. More conservative implications seemed prudent. I'd thus like to present what I consider to be my "final" draft, subject of course to feedback from these mailing lists. I'm pleased to report that I've addressed all of the XXX points I identified in the source of my first draft, points where I felt groff mm could be enhanced to aid the rendering of historical documents like this. I consequently expect groff 1.24's mm package to support several new features prompted specifically by this work. Quoting the forthcoming NEWS file... * The m (mm) macro package now supports a user-definable hook macro `AFX`, which if defined is called by `AF` in lieu of the latter's normal operation. Applications include customization of letterhead. * The m (mm) macro package now supports a user-definable hook macro `RPX`, which if defined is called by `RP` to format the reference list caption string `Rp` instead of the default formatting. * The m (mm) macro package now supports an `Aumt` string to suppress the appearance of positional arguments to the `AU` macro in the document heading used by memorandum types 0-3 and 6. By default, all such arguments appear, except the second (author initials). For example, a value of "3 4" more accurately reproduces London & Reiser's 1978 paper describing the porting of Unix to the VAX-11/780. * The m (mm) macro package now supports an `Rpfmt` string specifying the `LB` macro arguments that the package uses to format the items in a reference list. * The m (mm) macro package no longer superscripts _and_ brackets a reference mark (the `Rf` string). Instead, the new `Rfstyle` register controls its formatting. The default, 0, selects bracketing in nroff mode and superscripting in troff mode. Set `Rfstyle` to 3 in a document to obtain groff mm's previous mark formatting behavior. [I might still update or revert the changed default; I want to research the behavior of historical mm implementations.] The "32vscan.pdf" document from which I prepared this reconstruction is available at Dennis Ritchie's memorial home page.[3] I have attached the reconstructed mm source document and two PDFs, rendered with groff 1.23.0 (the current stable release), and groff Git HEAD (exercising the new features listed above).[4] I offer the caveat that these cannot be pixel-perfect recreations because (1) I have no information about the precise paper dimensions or margins London & Reiser used[5]; (2) the fonts employed in rendering the documents are not identical, metrically or otherwise; and (3) AT&T and GNU troffs use different hyphenation systems and therefore sometimes break words differently. These factors all impact the placement of line and page breaks, and these are avowedly and clearly distinguishable. There are furthermore a few discrepancies that I decided weren't worth the trouble at this time to reconcile, like selective encroachment of cover sheet material beyond the page margins. None affect the utility of the document (in my opinion). With that large disclaimer in place, I welcome feedback on the quality of the reproduction. Finally, I reiterate my encouragement that the document be _read_. In my opinion, the final two sections "Commands" and "Software portability" are well worth consideration in hindsight. To the extent that we continue to boast, sometimes glibly, of C as a "portable assembly language", be it in its current ISO C23 incarnation; as ANSI C89, the last revision blessed by Ritchie; or in the form used when London and Reiser wrote, their experiences and recommendations laid out a program of better delivering on that promise. Regards, Branden [1] https://www.tuhs.org/pipermail/tuhs/2024-June/030041.html [2] 1980, for example, saw releases of 3BSD, System III, PWB/UNIX 2.0, and 4BSD. [3] https://www.bell-labs.com/usr/dmr/www/portpapers.html [4] You may notice a difference in the sizes of the two PDFs, surprising in light of their shared source document. This is thanks to a new feature forthcoming in Deri James's gropdf(1) output driver: font subsetting. [5] ...or where, if anywhere, the authors "cheated" the margins temporarily, for instance with `ll` or `pl` requests. Even with mm macro package sources available, such things would be invisible to the reconstructor. -------------- next part -------------- A non-text attachment was scrubbed... Name: unix-vax-port-reconstructed-v5.mm Type: application/x-freemind Size: 56415 bytes Desc: unix-vax-port-reconstructed-v5.mm URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unix-vax-port-reconstructed-v5-groff-1.23.0.pdf Type: application/pdf Size: 355409 bytes Desc: unix-vax-port-reconstructed-v5-groff-1.23.0.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unix-vax-port-reconstructed-v5-groff-1.24.0pre.pdf Type: application/pdf Size: 105508 bytes Desc: unix-vax-port-reconstructed-v5-groff-1.24.0pre.pdf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From cmhanson at eschatologist.net Thu Oct 17 13:57:07 2024 From: cmhanson at eschatologist.net (Chris Hanson) Date: Wed, 16 Oct 2024 20:57:07 -0700 Subject: [TUHS] Can Ancient Unix be relicensed? In-Reply-To: <20241017023414.834be891f47301195bdfa510@gmail.com> References: <20241017013010.a40487c4e71937a5740caabf@gmail.com> <20241017023414.834be891f47301195bdfa510@gmail.com> Message-ID: <19851F5F-3C45-414F-A703-A1E51A6AE21F@eschatologist.net> On Oct 16, 2024, at 4:34 PM, Anton Shepelev wrote: > > So it was not an arbitrary decision by Caldera to use the > original BSD license? Can they have used the modern three- > clause version with equal ease? It was almost certainly *not* an arbitrary decision, and it is reasonable to assume that Caldera’s lawyers were quite aware of the variety of Open Source software licenses in existence at the time they made this decision. -- Chris From cmhanson at eschatologist.net Thu Oct 17 14:01:10 2024 From: cmhanson at eschatologist.net (Chris Hanson) Date: Wed, 16 Oct 2024 21:01:10 -0700 Subject: [TUHS] Can Ancient Unix be relicensed? In-Reply-To: <20241017013010.a40487c4e71937a5740caabf@gmail.com> References: <20241017013010.a40487c4e71937a5740caabf@gmail.com> Message-ID: <5AE15249-D6FA-4AE3-9D4B-FAEB1FFCAA20@eschatologist.net> On Oct 16, 2024, at 3:30 PM, Anton Shepelev wrote: > > The incompatibilty is due entirely to the infamous third > clause about adverising. Three years prior to Caldera's > release of old Unix code, The Berkley Univercity removed > this clause, producing the GNU-compatible modified BSD > License: There’s no such entity as The Berkeley University. It’s the University of California at Berkeley, one of many parts of the University of California system. This may be important if you’re trying to look up things in some databases, for example you may get hits that matter for “University of California” because the “at Berkeley” isn’t always added. -- Chris From robpike at gmail.com Thu Oct 17 19:40:45 2024 From: robpike at gmail.com (Rob Pike) Date: Thu, 17 Oct 2024 20:40:45 +1100 Subject: [TUHS] lilian schwartz has died In-Reply-To: References: Message-ID: I always forget that TUHS can't handle pictures. Perhaps Warren will let my post through, but in any case here's a link to the mail, reformatted but otherwise intact, with photos, on Mastodon. https://hachyderm.io/@robpike/113322062117546253 To pique your interest, here's the first paragraph. *In August 1981 we had a persistent problem with the RP06 on our PDP-11/70 crashing disks. It even crashed once while the DEC repairman was standing next to it trying to figure out why the previous pack had died. We collected a few dead packs, and they were forming a pile. Lillian, never one to miss an opportunity, suggested building a mobile.* -rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Oct 17 23:51:20 2024 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 17 Oct 2024 13:51:20 +0000 Subject: [TUHS] Can Ancient Unix be relicensed? In-Reply-To: <5AE15249-D6FA-4AE3-9D4B-FAEB1FFCAA20@eschatologist.net> References: <20241017013010.a40487c4e71937a5740caabf@gmail.com> <5AE15249-D6FA-4AE3-9D4B-FAEB1FFCAA20@eschatologist.net> Message-ID: The code is marked "Property of the Regents of the University of California." I was amused when I visited the campus years ago and found the same thing on the “no trespassing” signs on the building doors. ------ Original Message ------ >From "Chris Hanson" To "Anton Shepelev" Cc tuhs at tuhs.org Date 10/17/2024 12:01:10 AM Subject [TUHS] Re: Can Ancient Unix be relicensed? > >There’s no such entity as The Berkeley University. It’s the University of California at Berkeley, one of many parts of the University of California system. This may be important if you’re trying to look up things in some databases, for example you may get hits that matter for “University of California” because the “at Berkeley” isn’t always added. > > -- Chris > From woods at robohack.ca Fri Oct 18 06:08:49 2024 From: woods at robohack.ca (Greg A. Woods) Date: Thu, 17 Oct 2024 13:08:49 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: Catching up on the last month's worth of email.... At Mon, 30 Sep 2024 12:05:52 -0400, Paul Winalski wrote: Subject: [TUHS] Re: On computerese > > On Sat, Sep 28, 2024 at 8:49 PM Aron Insinga wrote: > > The terse Unix command verb style can be a steep learning curve for > beginners. How is one supposed to know that you say 'ls' to get a > directory listing? And unfortunately man pages aren't very useful for > beginners because you have to know what the command verb is in order to > call up its man page. Unix lacks a place to ask questions such as "how do > I get a directory listing?". Actually Unix has "always" (since 7th Edition at least) had a place to ask such questions! As a Unix beginner back in 1980, using 7th Edition, I was taught, right from the beginning, to use the permuted index to find things, which is essentially what BSD apropos(1) does. Of course anyone with even the tiniest smattering of academic experience would expect to have an index to use to find things, and for me taking this one step further with a permuted index using the keywords from the one-line descriptions of commands was a new and wonderful discovery. I think I had a printed copy of the Unix permuted index, though I don't remember for sure. You can find ls(1) in the 7th Edition permuted index in three places: ls list contents of directory....... ls(1) ls list contents of directory................... ls(1) ls list contents of directory.. ls(1) The manual page for ls(1) is unfortunately missing one useful keyword in the short description and using one less meaningful keyword. Perhaps the entry should have been more like: ls \- list the files in a directory Anyway folks in my first-year classes didn't need, or shouldn't have needed, to use the index to find ls(1) because we were given printed copies of the 7th Edition's "UNIX For Beginners Second Edition" by BWK. Perhaps the permuted index was included in the package. We were also using Multics, and had been given printed copies of a Multics new user help document as well. -- 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 aek at bitsavers.org Fri Oct 18 06:17:19 2024 From: aek at bitsavers.org (Al Kossow) Date: Thu, 17 Oct 2024 13:17:19 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: <4200f31d-f96d-b6d4-2152-20e055b31590@bitsavers.org> On 10/17/24 1:08 PM, Greg A. Woods wrote: > Of course anyone with even the > tiniest smattering of academic experience would expect to have an index > to use to find things I don't think this true any more for anyone younger than a college undergrad, is it? From tuhs at tuhs.org Fri Oct 18 06:37:35 2024 From: tuhs at tuhs.org (Bakul Shah via TUHS) Date: Thu, 17 Oct 2024 13:37:35 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> Message-ID: <332CA980-25D5-43B4-A6B6-F812FB975A94@iitbombay.org> On Oct 17, 2024, at 1:08 PM, Greg A. Woods wrote: > > I was taught, right > from the beginning, to use the permuted index to find things, which is > essentially what BSD apropos(1) does. Unfortunately things are a bit more complicated now! On freebsd: $ apropos ls | wc 1761 11158 121413 $ apropos ls | tail -1 refchan.tcl86, refchan(n) - command handler API of reflected channels Looks like it is matching "ls" in "channels". May be it should match full words? You can get this effect today with a bit more work: $ apropos '\' | wc 9 187 1260 But who'd remember to do that? And man pages themselves need some work: $ apropos tcl_fsdata Tcl_AllocStatBuf.tcl86, Tcl_FSAccess.tcl86, Tcl_FSChdir.tcl86, Tcl_FSConvertToPathType.tcl86, Tcl_FSCopyDirectory.tcl86, Tcl_FSCopyFile.tcl86, Tcl_FSCreateDirectory.tcl86, Tcl_FSData.tcl86, Tcl_FSDeleteFile.tcl86, Tcl_FSEqualPaths.tcl86, Tcl_FSEvalFile.tcl86, Tcl_FSEvalFileEx.tcl86, Tcl_FSFileAttrsGet.tcl86, Tcl_FSFileAttrsSet.tcl86, Tcl_FSFileAttrStrings.tcl86, Tcl_FSFileSystemInfo.tcl86, Tcl_FSGetCwd.tcl86, Tcl_FSGetFileSystemForPath.tcl86, Tcl_FSGetInternalRep.tcl86, Tcl_FSGetNativePath.tcl86, Tcl_FSGetNormalizedPath.tcl86, Tcl_FSGetPathType.tcl86, Tcl_FSGetTranslatedPath.tcl86, Tcl_FSGetTranslatedStringPath.tcl86, Tcl_FSJoinPath.tcl86, Tcl_FSJoinToPath.tcl86, Tcl_FSLink.tcl86, Tcl_FSListVolumes.tcl86, Tcl_FSLoadFile.tcl86, Tcl_FSLstat.tcl86, Tcl_FSMatchInDirectory.tcl86, Tcl_FSMountsChanged.tcl86, Tcl_FSNewNativePath.tcl86, Tcl_FSOpenFileChannel.tcl86, Tcl_FSPathSeparator.tcl86, Tcl_FSRegister.tcl86, Tcl_FSRemoveDirectory.tcl86, Tcl_FSRenameFile.tcl86, Tcl_FSSplitPath.tcl86, Tcl_FSStat.tcl86, Tcl_FSUnloadFile.tcl86, Tcl_FSUnregister.tcl86, Tcl_FSUtime.tcl86, Tcl_GetAccessTimeFromStat.tcl86, Tcl_GetBlocksFromStat.tcl86, Tcl_GetBlockSizeFromStat.tcl86, Tcl_GetChangeTimeFromStat.tcl86, Tcl_GetDeviceTypeFromStat.tcl86, Tcl_GetFSDeviceFromStat.tcl86, Tcl_GetFSInodeFromStat.tcl86, Tcl_GetGroupIdFromStat.tcl86, Tcl_GetLinkCountFromStat.tcl86, Tcl_GetModeFromStat.tcl86, Tcl_GetModificationTimeFromStat.tcl86, Tcl_GetSizeFromStat.tcl86, Tcl_GetUserIdFromStat.tcl86, Tcl_FSRegister, Tcl_AllocStatBuf, Tcl_FSAccess, Tcl_FSChdir, Tcl_FSConvertToPathType, Tcl_FSCopyDirectory, Tcl_FSCopyFile, Tcl_FSCreateDirectory, Tcl_FSData, Tcl_FSDeleteFile, Tcl_FSEqualPaths, Tcl_FSEvalFile, Tcl_FSEvalFileEx, Tcl_FSFileAttrsGet, Tcl_FSFileAttrsSet, Tcl_FSFileAttrStrings, Tcl_FSFileSystemInfo, Tcl_FSGetCwd, Tcl_FSGetFileSystemForPath, Tcl_FSGetInternalRep, Tcl_FSGetNativePath, Tcl_FSGetNormalizedPath, Tcl_FSGetPathType, Tcl_FSGetTranslatedPath, Tcl_FSGetTranslatedStringPath, Tcl_FSJoinPath, Tcl_FSJoinToPath, Tcl_FSLink, Tcl_FSListVolumes, Tcl_FSLoadFile, Tcl_FSLstat, Tcl_FSMatchInDirectory, Tcl_FSMountsChanged, Tcl_FSNewNativePath, Tcl_FSOpenFileChannel, Tcl_FSPathSeparator, Tcl_FSRemoveDirectory, Tcl_FSRenameFile, Tcl_FSSplitPath, Tcl_FSStat, Tcl_FSUnloadFile, Tcl_FSUnregister, Tcl_FSUtime, Tcl_GetAccessTimeFromStat, Tcl_GetBlocksFromStat, Tcl_GetBlockSizeFromStat, Tcl_GetChangeTimeFromStat, Tcl_GetDeviceTypeFromStat, Tcl_GetFSDeviceFromStat, Tcl_GetFSInodeFromStat, Tcl_GetGroupIdFromStat, Tcl_GetLinkCountFromStat, Tcl_GetModeFromStat, Tcl_GetModificationTimeFromStat, Tcl_GetSizeFromStat, Tcl_GetUserIdFromStat(3) - procedures to interact with any filesystem $ apropos tcl_fsdata|wc 1 119 2679 One very long line! Seems word search on unix for such things needs to be beefed up.... From boomer3200 at gmail.com Fri Oct 18 12:19:38 2024 From: boomer3200 at gmail.com (Dan Plassche) Date: Thu, 17 Oct 2024 21:19:38 -0500 Subject: [TUHS] v6 Unix Documents Message-ID: Hi, A scan of the printed UNIX Version 6 documents set is now online at the link below since last week. The set consists of documents accompanying the manual pages in the programmer's manual (similar to volume 2 in v7). https://www.computerhistory.org/collections/catalog/102659317 The [nt]roff user manual, tmg compiler-compiler, and m6 macro processor memos were previously missing from the distributions in TUHS and later efforts to re-create the documentation. I have been working on finding this documentation as part of researching roff history. Still interested in earlier copies of the internal memoranda from Ossanna that served as the NROFF User's Manual since v3, the TROFF User's Manual after v5, and TROFF Made Trivial starting around v4. Based on the manpage histories, the documentation was revised for v4, 5, and 6. Best, Dan Plassche From andrew at humeweb.com Fri Oct 18 12:30:35 2024 From: andrew at humeweb.com (andrew at humeweb.com) Date: Thu, 17 Oct 2024 19:30:35 -0700 Subject: [TUHS] lilian schwartz has died In-Reply-To: References: Message-ID: as i recall, the mobile lasted a fair while. presotto sometimes lifted it up at the top crossbar, but when we noticed that the top wire holding it up (into the ceiling) was noticeably stretching, it was taken down. > On Oct 17, 2024, at 2:40 AM, Rob Pike wrote: > > I always forget that TUHS can't handle pictures. Perhaps Warren will let my post through, but in any case here's a link to the mail, reformatted but otherwise intact, with photos, on Mastodon. > > https://hachyderm.io/@robpike/113322062117546253 > > To pique your interest, here's the first paragraph. > > In August 1981 we had a persistent problem with the RP06 on our PDP-11/70 crashing disks. It even crashed once while the DEC repairman was standing next to it trying to figure out why the previous pack had died. We collected a few dead packs, and they were forming a pile. Lillian, never one to miss an opportunity, suggested building a mobile. > > -rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Fri Oct 18 23:58:06 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 18 Oct 2024 08:58:06 -0500 Subject: [TUHS] v6 Unix Documents In-Reply-To: References: Message-ID: <20241018135806.ysgog7qde6xjodtu@illithid> Hi Dan, At 2024-10-17T21:19:38-0500, Dan Plassche wrote: > A scan of the printed UNIX Version 6 documents set is now online > at the link below since last week. The set consists of documents > accompanying the manual pages in the programmer's manual (similar > to volume 2 in v7). And Volume 2 in Research version 10! Bell Labs Unix published a Volume 2 for only three releases (per McIlroy), and it appears that all have now been recovered. This is a milestone--thank you! > https://www.computerhistory.org/collections/catalog/102659317 I do observe that this web page credits the publisher of the document as "Western Digital Corporation". Shouldn't that be "Western Electric Company"? (Apparently back in 1975, WD was making chips for calculators.) > The [nt]roff user manual, Noteworthy but frustrating here is that at this point, the forerunner of CSTR #54 was still titled simply "NROFF Users' Manual" (PDF pp. 173ff.). References to troff are present, but the typesetting program is not fully documented. Frustrating! Also we have here the (unnumbered) first edition of the eqn User's Guide (PDF pp. 269ff.). I haven't enumerated the language changes in nroff and eqn going from v6 to v7 yet, but for the formatter there seem to be at least a dozen, including numerous deletions. (If I tried to move groff that fast, I'd be dragged before a firing squad by the faculty of a German university!) The biggest nroff change that leaps out at me right now is that in V6 _special character escape sequences did not yet exist_. Given that the C/A/T typesetter had already been in use for years by 1975 (with eqn giving it strenuous exercise from early on), I find this fascinating. Evidence of the close relationship with the Teletype Model 37 is present, with the `\x` and `\y` escape sequences mapping to "ASCII Shift-out" and "ASCII Shift-in", respectively (PDF p. 177). Check out some of these other relics: .xh Extra half-line mode on. .ch -N -M Move trap by _position_, not name. .nc Number character. (From an interpreter writer's perspective, that one's _really_ interesting. I won't spoil its shocking semantics here.) .ar Arabic numbers. .ro Lower case roman numbers. .RO Upper case roman numbers. (The `af` request hadn't been developed yet. The me(7) package at Berkeley, which commenced development in 1978--_before_ Seventh Edition--helped people over the hump in the case of the first two.) .li Accept input lines literally. (That one survived, undocumented, into Seventh Edition.) .np Number parameters set or reset. \? Raw transmission indicator \: Generates ASCII ETX (003) for post processor use \l ASCII Delete I see that the `ad` request did not accept arguments "l" or "b", just "c" and "n". Since "b" and "l" were redundant, my imaginations conjures office arguments over the meaning of the word "adjustment". With the design in such flux, too bad I wasn't there to lobby for the separation of "alignment" and "adjustment". ;-) No worries, I'll be there soon! (Fifty years late but moving fast, as Douglas Adams might have said.) You could turn automatic hyphenation on or off, but there was only one hyphenation mode. Any color you want, so long as it's black! :) > tmg compiler-compiler, and m6 macro processor memos were previously > missing from the distributions in TUHS and later efforts to re-create > the documentation. I'm intensely interested in both of these from a personal perspective. I observe that the TMG and m6 documents appear may have been prepared by vintage 1972 and 1971 nroff, making them worthwhile exhibits on that basis alone (PDF pp. 211ff., 239ff., respectively). I wonder why they were never typeset. Would the document sources have required too much "porting" to troff? One more thing I noticed: in a first glance, it appears Room 127 got their hands on a sans-serif (Helvetica?) roman plate for the C/A/T prior to V5. We see it used in Ritchie's "C Reference Manual" (PDF pp. 31ff.) and Kernighan's "Programming in C — A Tutorial" (PDF pp. 61ff.). But Courier is nowhere in sight. In summary, there is a boatload of information here that is useful to me in understanding Why Things Look The Way They Do. > I have been working on finding this documentation as part of > researching roff history. Still interested in earlier copies of > the internal memoranda from Ossanna that served as the NROFF > User's Manual since v3, the TROFF User's Manual after v5, and > TROFF Made Trivial starting around v4. Based on the manpage > histories, the documentation was revised for v4, 5, and 6. Please keep the groff list apprised of further findings. Fascinating stuff. Good work! 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 aek at bitsavers.org Sat Oct 19 00:02:47 2024 From: aek at bitsavers.org (Al Kossow) Date: Fri, 18 Oct 2024 07:02:47 -0700 Subject: [TUHS] v6 Unix Documents In-Reply-To: <20241018135806.ysgog7qde6xjodtu@illithid> References: <20241018135806.ysgog7qde6xjodtu@illithid> Message-ID: <5d5713f8-bfb4-ec00-7cd6-1ffcefe3e2ab@bitsavers.org> On 10/18/24 6:58 AM, G. Branden Robinson wrote: >> https://www.computerhistory.org/collections/catalog/102659317 > > I do observe that this web page credits the publisher of the document as > "Western Digital Corporation". Shouldn't that be "Western Electric > Company"? > > (Apparently back in 1975, WD was making chips for calculators.) > typos happen email research at computerhistory.org and let them know you found an error From woods at robohack.ca Sat Oct 19 07:34:13 2024 From: woods at robohack.ca (Greg A. Woods) Date: Fri, 18 Oct 2024 14:34:13 -0700 Subject: [TUHS] On computerese In-Reply-To: <332CA980-25D5-43B4-A6B6-F812FB975A94@iitbombay.org> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <332CA980-25D5-43B4-A6B6-F812FB975A94@iitbombay.org> Message-ID: At Thu, 17 Oct 2024 13:37:35 -0700, Bakul Shah via TUHS wrote: Subject: [TUHS] Re: On computerese > > Unfortunately things are a bit more complicated now! > > On freebsd: > $ apropos ls | wc 1761 11158 121413 Someone forgot the "word" part of "keyword" I guess (but see below -- nothing new here). The same brain-damage happens on NetBSD (where all the manual page processing has had a rather obnoxious and unnecessary overhaul, for lack of a better description). BTW, the first keyword I might search for when looking to find something that does what ls(1) does would probably be "list", or maybe "files", but not "ls" itself obviously! (Thus my earlier complaint that "files" does not appear in the synopsis for ls(1).) > $ apropos '\' | wc 9 187 1260 So it seems FreeBSD's apropos(1) now allows regular expressions for the keyword argument! On my rather stock plain FreeBSD machine there are only two lines output for '\', and searching for '\' generates only 27 lines, all quite reasonable. At least this support for REs is well documented, assuming one would think to read the manual page for apropos(1) before using it, so knowing to use the RE word delimiters isn't too much of a stretch: ... uses case-insensitive extended regular expression matching over manual names and descriptions Use of word delimiters are even shown in some of the examples given. I still fail to see why the default isn't/wasn't to treat the keyword argument as only matching a whole word (+/- any suffixes). The new NetBSD implementation doesn't document what its arguments do, though a quick experiment shows it doesn't parse regular expressions. Sadly it doesn't handle its '-s' option properly either. > Seems word search on unix for such things needs to be beefed > up.... Indeed, though "beefed down" might be the better direction. It looks, on first glance, that the 4.4BSD apropos(1) was also very lax in matching keywords as well: Each word is considered separately and case of letters is ignored. Words which are part of other words are considered; when looking for “compile”, apropos will also list all instances of “compiler”. I think proper exclusion of normal word suffixes (and maybe prefixes) would suffice for a reasonable definition of "word", but a quick glance at the source suggests that's not what it does Note that all of this mess is partially because the makewhatis.sh script didn't make it into 4.4BSD (even though getNAME.c did), and furthermore the ed(1) script in it won't work with modern BSD ed(1) implementations. There was a makewhatis.sed script that is in 4.4BSD doesn't seem to do anything useful with modern "nroff -man" output either. Sigh. While looking up information about the different implementations I ran across the following slightly amusing but mostly sad description of ptx(1): ptx: an inscrutable abbreviation for a word-salad generator. PermuTed indeXes were tortuous concordances for manual pages back in the days before tools like apropos. The GNU version was created in 1999 as some sort of exercise in medieval reenactment. There's an embedded link therein to a somewhat more sedate description of the UNIX Reference Manual's permuted index: https://docstore.mik.ua/orelly/unix/upt/ch50_09.htm -- 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 woods at robohack.ca Sat Oct 19 07:39:49 2024 From: woods at robohack.ca (Greg A. Woods) Date: Fri, 18 Oct 2024 14:39:49 -0700 Subject: [TUHS] On computerese In-Reply-To: <4200f31d-f96d-b6d4-2152-20e055b31590@bitsavers.org> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <4200f31d-f96d-b6d4-2152-20e055b31590@bitsavers.org> Message-ID: At Thu, 17 Oct 2024 13:17:19 -0700, Al Kossow wrote: Subject: [TUHS] Re: On computerese > > On 10/17/24 1:08 PM, Greg A. Woods wrote: > > Of course anyone with even the > > tiniest smattering of academic experience would expect to have an index > > to use to find things > > I don't think this true any more for anyone younger than a college > undergrad, is it? Heh. Probably not. -- 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 jsg at jsg.id.au Sat Oct 19 13:36:05 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 19 Oct 2024 14:36:05 +1100 Subject: [TUHS] v6 Unix Documents In-Reply-To: <20241018135806.ysgog7qde6xjodtu@illithid> References: <20241018135806.ysgog7qde6xjodtu@illithid> Message-ID: On Fri, Oct 18, 2024 at 08:58:06AM -0500, G. Branden Robinson wrote: > > Noteworthy but frustrating here is that at this point, the forerunner of > CSTR #54 was still titled simply "NROFF Users' Manual" (PDF pp. 173ff.). > References to troff are present, but the typesetting program is not > fully documented. Frustrating! PWB was an early external distribution with troff. Documents for the PWB/UNIX Time-Sharing System https://datamuseum.dk/wiki/Bits:30007124 https://bitsavers.org/pdf/att/unix/PWB_UNIX/ NROFF/TROFF User's Manual October 11, 1976 datamuseum.dk, pp 325-357 bitsavers, pp 217-249 Addendum to the NROFF/TROFF User's Manual May 1977 datamuseum.dk, p 358 bitsavers, p 250 fonts described in: Administrative Advice for PWB/UNIX 23. PHOTOTYPESETTING EQUIPMENT AND SUPPLIES datamuseum.dk, p 647 From paul.winalski at gmail.com Sun Oct 20 00:55:57 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 19 Oct 2024 10:55:57 -0400 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <332CA980-25D5-43B4-A6B6-F812FB975A94@iitbombay.org> Message-ID: Regarding use of apropos as a way to answer "How do I do X?"-type questions, I've never had any joy with that. apropos has always returned pages and pages of irrelevant information. Maybe the direct answer is in there somewhere, but it's always been a needle-in-the-haystack situation for me. -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sun Oct 20 01:03:48 2024 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 19 Oct 2024 08:03:48 -0700 Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <332CA980-25D5-43B4-A6B6-F812FB975A94@iitbombay.org> Message-ID: <20241019150348.GB2194@mcvoy.com> I think as you move from OS to OS, there are basics. You seek those out. The thing I miss is a terminal room. That's where I really learned. You seek out the people who are the most productive and look over their shoulder. The first time I saw Udi do !}fmt my head exploded. That's been a vi mapping for decades. On Sat, Oct 19, 2024 at 10:55:57AM -0400, Paul Winalski wrote: > Regarding use of apropos as a way to answer "How do I do X?"-type > questions, I've never had any joy with that. apropos has always returned > pages and pages of irrelevant information. Maybe the direct answer is in > there somewhere, but it's always been a needle-in-the-haystack situation > for me. > > -Paul W. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From clemc at ccc.com Sun Oct 20 02:59:17 2024 From: clemc at ccc.com (Clem Cole) Date: Sat, 19 Oct 2024 12:59:17 -0400 Subject: [TUHS] On computerese In-Reply-To: <20241019150348.GB2194@mcvoy.com> References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <332CA980-25D5-43B4-A6B6-F812FB975A94@iitbombay.org> <20241019150348.GB2194@mcvoy.com> Message-ID: Yes, programming is often better when it's a more social enterprise. It's funny. I liked having an office for times when I wanted to think, but when I was batting an interesting issue or trying to remember something pretty obscure, the terminal room was the best. I also began to slowly realize my own knowledge base was improving when I was the one answering the question when someone asked, " Hey, does anybody have a good way to ..." ᐧ On Sat, Oct 19, 2024 at 11:09 AM Larry McVoy wrote: > I think as you move from OS to OS, there are basics. You seek those out. > > The thing I miss is a terminal room. That's where I really learned. > You seek out the people who are the most productive and look over their > shoulder. The first time I saw Udi do !}fmt my head exploded. That's > been a vi mapping for decades. > > On Sat, Oct 19, 2024 at 10:55:57AM -0400, Paul Winalski wrote: > > Regarding use of apropos as a way to answer "How do I do X?"-type > > questions, I've never had any joy with that. apropos has always returned > > pages and pages of irrelevant information. Maybe the direct answer is in > > there somewhere, but it's always been a needle-in-the-haystack situation > > for me. > > > > -Paul W. > > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sun Oct 20 04:16:05 2024 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 19 Oct 2024 14:16:05 -0400 (EDT) Subject: [TUHS] On computerese In-Reply-To: References: <58a1875a-9377-4b5b-ba03-e8dfcea8364e@insinga.com> <332CA980-25D5-43B4-A6B6-F812FB975A94@iitbombay.org> <20241019150348.GB2194@mcvoy.com> Message-ID: On Sat, 19 Oct 2024, Clem Cole wrote: > Yes, programming is often better when it's a more social enterprise. It's > funny. I liked having an office for times when I wanted to think, but when > I was batting an interesting issue or trying to remember something pretty > obscure, the terminal room was the best. I also began to slowly realize my > own knowledge base was improving when I was the one answering the question > when someone asked, " Hey, does anybody have a good way to ..." I notice I'm more motivated to work on a program when I'm not alone slogging through it. Of course a lot of my projects tend to fall into the "who cares?" category. Like trying to backport MS-DOS 6.2 functionality to the open-source 4, or create an alternate-universe OS where it was System V rather than BSD that got the Theseus treatment... -uso. From boomer3200 at gmail.com Sun Oct 20 19:12:32 2024 From: boomer3200 at gmail.com (Dan Plassche) Date: Sun, 20 Oct 2024 05:12:32 -0400 (EDT) Subject: [TUHS] v6 Unix Documents In-Reply-To: <20241018135806.ysgog7qde6xjodtu@illithid> References: <20241018135806.ysgog7qde6xjodtu@illithid> Message-ID: Hey Branden, Apologies for the duplicate message. I had a mailer issue this evening where the message did not reach TUHS. On Fri, 18 Oct 2024, G. Branden Robinson wrote: > I do observe that this web page credits the publisher of the document as > "Western Digital Corporation". Shouldn't that be "Western Electric > Company"? Yeah, Western Electric issued licenses and official printed documentation externally for Research Unix in the 1970s. I completely looked past that typo in the catalog amidst the thrill of obtaining the document! I've let an archivist at the CHM know of the correction. I found in the course of researching that most other catalogs list the documentation as a single serial item from 1971 onwards with Thompson and/or Ritchie as authors, so finding any specific item can be difficult. > > The [nt]roff user manual, > > Noteworthy but frustrating here is that at this point, the forerunner of > CSTR #54 was still titled simply "NROFF Users' Manual" (PDF pp. 173ff.). > References to troff are present, but the typesetting program is not > fully documented. Frustrating! We can trace the evolution using nroff as a starting point. Nroff appeared in v2 Unix in 1972 and the preceeding roff formatter did not change afterwards. The v3 manpage for nroff includes the first reference to the "NROFF User's Manual" (MM-73-1271-2) and a summary of all commands. The summary is available with each dated and revised manpage for nroff through v5. The v6 manual from 1975 is identified as the second edition of the "NROFF User's Manual" as revised in Sept. 1974. If the documentation and changes to the extant source code from v4 to v6 are in alignment, we should have a baseline history with a clear indication of differences across versions. I will send a summary with further details to the groff mailing list in the coming weeks. The development of troff before the rewrite to C between v6 and v7 is a lot less clear. Troff appears in v4 with a mention of a preliminary user's manual, but I suspect the manual is a summary of unique troff features that were not documented elsewhere until v7. The manpages only cover troff invocation. > Also we have here the (unnumbered) first edition of the eqn User's > Guide (PDF pp. 269ff.). ... > The biggest nroff change that leaps out at me right now is that in V6 > _special character escape sequences did not yet exist_. Given that the > C/A/T typesetter had already been in use for years by 1975 (with eqn > giving it strenuous exercise from early on), I find this fascinating. Perhaps special characters did exist for troff but were not documented in this v6 manual. It's not clear without seeing an earlier troff manual, but I'm staring to think that the v6 manual may be a continuation of the nroff manual alone. In that case, general users would have fallen back on overstrikes for most special characters. The greek characters in eqn and the various copyright symbols on earlier programmer's manuals seem to support the assumption that special characters were in use with troff. The documents and programmer's manuals were all printed with troff from v4 onwards. > Evidence of the close relationship with the Teletype Model 37 is > present, with the `\x` and `\y` escape sequences mapping to "ASCII > Shift-out" and "ASCII Shift-in", respectively (PDF p. 177). I was surprised to see the ribbon shift-in/out feature existed and then got removed, since it would seem that the command could have been reused for changing the typing element on Selectric consoles and daisywheel printers that were fairly widespread. > .xh Extra half-line mode on. Half line motions are surprisingly common on older documents and probably a major reason for using troff output that's setup to look like an nroff device. > I see that the `ad` request did not accept arguments "l" or "b", just > "c" and "n". Since "b" and "l" were redundant, my imaginations conjures > office arguments over the meaning of the word "adjustment". With the > design in such flux, too bad I wasn't there to lobby for the separation > of "alignment" and "adjustment". ;-) > > No worries, I'll be there soon! > (Fifty years late but moving fast, as Douglas Adams might have said.) The v6 design certainly seems clearer and in support of your cleanup. > > tmg compiler-compiler, and m6 macro processor memos were previously > > missing from the distributions in TUHS and later efforts to re-create > > the documentation. > > I'm intensely interested in both of these from a personal perspective. > > I observe that the TMG and m6 documents appear may have been prepared > by vintage 1972 and 1971 nroff, making them worthwhile exhibits on that > basis alone (PDF pp. 211ff., 239ff., respectively). I wonder why they > were never typeset. Would the document sources have required too much > "porting" to troff? I was very interested to find the papers as well. The output seems to be roff formatted like the v1 manual on TUHS and frozen from around 1972. > In summary, there is a boatload of information here that is useful to me > in understanding Why Things Look The Way They Do. > > Please keep the groff list apprised of further findings. Fascinating > stuff. > > Good work! > > Regards, > Branden Thank you for your feedback and the credit in re-creating the Unix porting paper, which I have been following with interest. I really appreciate all of the extra work you put in as maintainer to understand the history of roff design and output in order to better document, validate, and develop groff. Sincerely, Dan From jsg at jsg.id.au Sun Oct 20 19:39:15 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Sun, 20 Oct 2024 20:39:15 +1100 Subject: [TUHS] v6 Unix Documents In-Reply-To: References: <20241018135806.ysgog7qde6xjodtu@illithid> Message-ID: On Sun, Oct 20, 2024 at 01:23:23AM -0400, Dan Plassche wrote: > > On Sat, 19 Oct 2024, Jonathan Gray wrote: > > > PWB was an early external distribution with troff. > > > > Documents for the PWB/UNIX Time-Sharing System > > https://datamuseum.dk/wiki/Bits:30007124 > > https://bitsavers.org/pdf/att/unix/PWB_UNIX/ > > > > NROFF/TROFF User's Manual > > October 11, 1976 > > datamuseum.dk, pp 325-357 > > bitsavers, pp 217-249 > > > > Addendum to the NROFF/TROFF User's Manual > > May 1977 > > datamuseum.dk, p 358 > > bitsavers, p 250 > > > > fonts described in: > > Administrative Advice for PWB/UNIX > > 23. PHOTOTYPESETTING EQUIPMENT AND SUPPLIES > > datamuseum.dk, p 647 > > Thank you Jonathan. I was previously not sure where to place the > PWB documentation in the timeline but a clearer picture is > emerging. > > Based on the v6 "NROFF User's Manual" revised in 1974 and > published in 1975, I can now see that the PWB documentation with > the "NROFF/TROFF User's Manual" from 1976-77 has most of the > content that later appears in v7. The major change immediately > beforehand was the rewrite of troff into C.[1] Some clear > differences are the combination of nroff and troff manpages and > the addition of troff specific features like the special fonts > into the user's manual. > > [1]. Apparently in 1976: > https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description-troffsrc.tar.gz "It was rewritten in C around 1975" Kernighan in CSTR 97, A Typesetter-independent TROFF I've seen references to "Documents for Use with the Phototypesetter (Version 7)" which was likely distributed with the licensed phototypesetter tape in 1977. What may have been the manual distributed with that tape is also close to v7. https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/troff/doc https://www.tuhs.org/Archive/Distributions/Other/Interdata/ tuhs Applications/Spencer_Tapes/unsw3.tar.gz usr/source/formatters/troff/doc/ From boomer3200 at gmail.com Sun Oct 20 19:41:41 2024 From: boomer3200 at gmail.com (Dan Plassche) Date: Sun, 20 Oct 2024 05:41:41 -0400 (EDT) Subject: [TUHS] v6 Unix Documents In-Reply-To: References: <20241018135806.ysgog7qde6xjodtu@illithid> Message-ID: <570fea4e-58b9-9738-b8d7-9256bd74799c@gmail.com> Thanks Jonathan for the pointer. On Sat, 19 Oct 2024, Jonathan Gray wrote: > PWB was an early external distribution with troff. > > Documents for the PWB/UNIX Time-Sharing System > https://datamuseum.dk/wiki/Bits:30007124 > https://bitsavers.org/pdf/att/unix/PWB_UNIX/ > > NROFF/TROFF User's Manual > October 11, 1976 > datamuseum.dk, pp 325-357 > bitsavers, pp 217-249 > > Addendum to the NROFF/TROFF User's Manual > May 1977 > datamuseum.dk, p 358 > bitsavers, p 250 > > fonts described in: > Administrative Advice for PWB/UNIX > 23. PHOTOTYPESETTING EQUIPMENT AND SUPPLIES > datamuseum.dk, p 647 I was not previously certain where the PWB release fit into the troff timeline. Based on comparison to the v6 manual last updated in September 1974 and published in 1975, this manual revised in October 1976 and published in 1977 now integrates troff-specific content like the special fonts you mentioned under new title of "NROFF/TROFF User's Manual." The major change in the meantime was the rewrite of troff into C.[1] 1. Apparently from 1975-76 as noted in the 1992 revision of the manual and shown in the PWB 1.0 croff source code below: https://www.tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz Best, Dan From boomer3200 at gmail.com Mon Oct 21 10:30:47 2024 From: boomer3200 at gmail.com (Dan Plassche) Date: Sun, 20 Oct 2024 20:30:47 -0400 (EDT) Subject: [TUHS] Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents) In-Reply-To: References: <20241018135806.ysgog7qde6xjodtu@illithid> Message-ID: <179b0bb4-73d1-fc81-b2d3-68b651e58bbd@gmail.com> On Sun, 20 Oct 2024, Jonathan Gray wrote: > I've seen references to > "Documents for Use with the Phototypesetter (Version 7)" > which was likely distributed with the licensed phototypesetter tape in 1977. > > What may have been the manual distributed with that tape is also close to v7. > > https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/troff/doc > https://www.tuhs.org/Archive/Distributions/Other/Interdata/ > > tuhs Applications/Spencer_Tapes/unsw3.tar.gz > usr/source/formatters/troff/doc/ Looks we have the files from 1977! There are 3 distributions on TUHS that have the same general name and number of source files for the "typesetter c" compiler and the "new" troff in C: https://www.tuhs.org/Archive/Applications/Spencer_Tapes/unsw3.tar.gz ./usr/source/c_compiler ./usr/source/formatters/ https://www.tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz ./sys/c/c ./type/croff ./sys/source/s7/croff https://www.tuhs.org/Archive/Distributions/Other/Interdata/interdata_v6.tar.gz ./usr/source/c ./usr/source/troff The Spencer PWB tape appears to be 1.0. Dates on files from sccsid comments on nroff/troff and throughout the system are from early to mid-1977 making this the earliest set.[1] The files under the ./type/croff directory and ./sys/source/s7/croff are the same. The UNSW AUSAM tape has the same files as PWB. An initial check shows some feature flags and structs from PWB are missing for [nt]roff here. However, there are extra notes on the c changes and the October 1976 NROFF/TROFF manual source for content published in the PWB documentation. The latest dates on other files are from early to mid-1978.[2] The Interdata files have lots of added comments and changes with a late 1978 date listed in some files[3]. It does have extra READ_ME files confirming that this was pre-release v7 c compiler for v6, which helps validate the PWB and UNSW content. I'll work from the PWB and UNSW files with the plan to send troff details to the groff list and rebuild the compiler in the process. Glad to confirm if the build succeeds and I find out any further details about the compiler if relevant for TUHS. 1. Examples: ./usr/man/man0/introduction: May 1977 and ./usr/man/man0/documents: August 1977 2. As printed in the copy available at: http://www.bitsavers.org/pdf/att/unix/PWB_UNIX/Documents_for_the_PWB_UNIX_Time-Sharing_System_Edition_1.0_197710.pdf Updates like the January 1978 changes to the dz serial code provided by Dennis at ./usr/sys/dmr/dz.c. 3. Such as ./usr/doc/cman/cman1: June 1978. Best, Dan From jsg at jsg.id.au Mon Oct 21 12:47:43 2024 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 21 Oct 2024 13:47:43 +1100 Subject: [TUHS] Typesetter C Compiler and Troff (Re: Re: v6 Unix Documents) In-Reply-To: <179b0bb4-73d1-fc81-b2d3-68b651e58bbd@gmail.com> References: <20241018135806.ysgog7qde6xjodtu@illithid> <179b0bb4-73d1-fc81-b2d3-68b651e58bbd@gmail.com> Message-ID: On Sun, Oct 20, 2024 at 08:30:47PM -0400, Dan Plassche wrote: > > On Sun, 20 Oct 2024, Jonathan Gray wrote: > > > I've seen references to > > "Documents for Use with the Phototypesetter (Version 7)" > > which was likely distributed with the licensed phototypesetter tape in 1977. > > > > What may have been the manual distributed with that tape is also close to v7. > > > > https://www.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/source/troff/doc > > https://www.tuhs.org/Archive/Distributions/Other/Interdata/ > > > > tuhs Applications/Spencer_Tapes/unsw3.tar.gz > > usr/source/formatters/troff/doc/ > > Looks we have the files from 1977! > > There are 3 distributions on TUHS that have the same general name > and number of source files for the "typesetter c" compiler and > the "new" troff in C: > > https://www.tuhs.org/Archive/Applications/Spencer_Tapes/unsw3.tar.gz > ./usr/source/c_compiler > ./usr/source/formatters/ same contents in Distributions/UNSW/7/record0.tar.gz source/formatters/ > > https://www.tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz > ./sys/c/c > ./type/croff > ./sys/source/s7/croff > > https://www.tuhs.org/Archive/Distributions/Other/Interdata/interdata_v6.tar.gz > ./usr/source/c > ./usr/source/troff Applications/Usenix_77/ug091377.tar.gz 3/ken/nroff_manual/ 'NROFF/TROFF User's Manual' same as interdata troff doc, without some files > > The Spencer PWB tape appears to be 1.0. Dates on files from > sccsid comments on nroff/troff and throughout the system are from > early to mid-1977 making this the earliest set.[1] The files > under the ./type/croff directory and ./sys/source/s7/croff are > the same. > > The UNSW AUSAM tape has the same files as PWB. An initial check > shows some feature flags and structs from PWB are missing for > [nt]roff here. However, there are extra notes on the c changes > and the October 1976 NROFF/TROFF manual source for content > published in the PWB documentation. The latest dates on other > files are from early to mid-1978.[2] > > The Interdata files have lots of added comments and changes with > a late 1978 date listed in some files[3]. It does have extra > READ_ME files confirming that this was pre-release v7 c compiler > for v6, which helps validate the PWB and UNSW content. > > I'll work from the PWB and UNSW files with the plan to send troff > details to the groff list and rebuild the compiler in the > process. Glad to confirm if the build succeeds and I find out > any further details about the compiler if relevant for TUHS. I adapted Tim Newsham's v6 install scripts for PWB if you'd like to run it on simh. https://github.com/jonathangray/pwb/ Base system from the Bostic tapes, troff installed from the Spencer tape. > > 1. Examples: ./usr/man/man0/introduction: May 1977 and > ./usr/man/man0/documents: August 1977 > > 2. As printed in the copy available at: > > http://www.bitsavers.org/pdf/att/unix/PWB_UNIX/Documents_for_the_PWB_UNIX_Time-Sharing_System_Edition_1.0_197710.pdf > > Updates like the January 1978 changes to the dz serial code > provided by Dennis at ./usr/sys/dmr/dz.c. > > 3. Such as ./usr/doc/cman/cman1: June 1978. > > > Best, > > Dan > From tuhs at tuhs.org Tue Oct 22 09:36:52 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 21 Oct 2024 23:36:52 +0000 Subject: [TUHS] Other UNIX Archival Efforts? Message-ID: So with all that has happened with the Internet Archive lately, I do find myself a bit concerned regarding the UNIX materials that I know to only exist there. Selfishly, this includes my own uploads here: https://archive.org/details/@segaloco I was curious if anyone has any suggestions on places beyond just IA and TUHS where I could see about getting this stuff mirrored? Unfortunately my stuff runs afoul of bitsavers's DPI requirements, that's the only other source that immediately comes to mind where these materials would find home. Any thoughts? Warren, I know you had mentioned a "write only" archive you maintain regarding materials that need to be mothballed until legal understandings are reached, would you be comfortable with my contributing any of my materials the Caldera license does not apply to there? - Matt G. From gregg.drwho8 at gmail.com Tue Oct 22 09:50:00 2024 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Mon, 21 Oct 2024 19:50:00 -0400 Subject: [TUHS] Other UNIX Archival Efforts? In-Reply-To: References: Message-ID: Hello! I normally prefer to lurk in the background on this list, but, I agree with the gentleman asking that question. Warren I believe you mentioned such a storage place. Please do consider his request. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature was present when the impossible happened 23 years ago, twice." On Mon, Oct 21, 2024 at 7:37 PM segaloco via TUHS wrote: > > So with all that has happened with the Internet Archive lately, I > do find myself a bit concerned regarding the UNIX materials that > I know to only exist there. Selfishly, this includes my own > uploads here: https://archive.org/details/@segaloco > > I was curious if anyone has any suggestions on places beyond just > IA and TUHS where I could see about getting this stuff mirrored? > Unfortunately my stuff runs afoul of bitsavers's DPI requirements, > that's the only other source that immediately comes > to mind where these materials would find home. Any thoughts? > > Warren, I know you had mentioned a "write only" archive you > maintain regarding materials that need to be mothballed until legal > understandings are reached, would you be comfortable with my > contributing any of my materials the Caldera license does not apply > to there? > > - Matt G. From tuhs at tuhs.org Tue Oct 22 12:34:36 2024 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Tue, 22 Oct 2024 12:34:36 +1000 Subject: [TUHS] Other UNIX Archival Efforts? In-Reply-To: References: Message-ID: On Mon, Oct 21, 2024 at 11:36:52PM +0000, segaloco via TUHS wrote: > Warren, I know you had mentioned a "write only" archive you > maintain regarding materials that need to be mothballed until legal > understandings are reached, would you be comfortable with my > contributing any of my materials the Caldera license does not apply > to there? Absolutely. I'm always happy to tak additions to the Hidden Unix Archive :-) Cheers, Warren From arnold at skeeve.com Sun Oct 27 15:27:03 2024 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 26 Oct 2024 23:27:03 -0600 Subject: [TUHS] QED Archive updated Message-ID: <202410270527.49R5R3Pn920763@freefriends.org> Hi All. For anyone who's interested, my QED archive at https://github.com/arnoldrobbins/qed-archive has been updated. Changes were provided by Sean Jensen. The usenix-80-caltech subdirectory is now more complete and the README.md points at Sean's updated QED port which now works with Unicode. I thank him. Arnold