Fair enough 👍 ᐧ On Mon, Jun 12, 2023 at 6:50 PM G. Branden Robinson < g.branden.robinson(a)gmail.com&gt; wrote:

[Clem and TUHS dropped from CC] Hi Paul, At 2023-06-12T19:04:31-0400, Paul Winalski wrote: It was really just a fart joke--you know, "breaking wind" and all that. libcrt0.s -> libfrt0.s ... But you're getting at an actual problem I had when trying to learn linking and loading on Unix beyond the level of recipes keyed in by rote. (My upbringing was on systems with the most minimal conceivable object file formats, and your runtime support was in either in ROM or you provided it yourself.) Being of a certain age, 'crt0' (a name preserved by the GNU C compiler) looked to me for all the world like it must have had to do with driving a CRT. This made little sense to me, especially when the darn thing got shoved into computation-only programs that performed no I/O at all. I could find no documentation, nor at that time any local experts who could tell me what the heck "crt" was _for_. (The BSD advocates I knew back in the day suggested that this was my fault for not locating and apprenticing myself to such a master; the guild mentality was, and in some ways still is, powerful there.) I am probably not the only person who was sent down an incorrect chain of deductions by this "economical" naming convention; furthermore, one employed for the sake of a file name that almost no one ever typed anyway. To bang an old drum of mine, while Unix culture pats itself on the back for economizing keystrokes with an ad hoc compression scheme for every name in sight, it too often overlooks what discarded in pursuit of this form of minimality: clarity, lack of ambiguity, and ease of acquisition by newcomers. I get that Teletypes were hard to type on and baud rates were punitively low. But when Bell Labs got the Blit, the limitations that motivated the original terseness were not only not discarded, but retained and doubled down on. "We're going multi-architecture for Plan 9, so let's allocate every machine architecture we'll ever be presented with an identifier from a single-character alphanumeric namespace." Madness.[1] Decades after tcsh brought tab-completion to the shell-using masses, and just as many decades after this feature was cloned by every Unix shell that wasn't moribund, the defenders of keystroke minimality aren't content to cultivate their own private name space of single-letter shell functions, scripts, or aliases--instead they rebut the above by complaining that GNU-style architecture triples are way too long. Way too long for what? To type out in full? Sure. Too long to tell you what ABI the objects produced are going to use? No. At least APL chose sigils that were tough to confuse with other things. Thanks for mentioning this. I think you had pointed this out some months ago, but I had difficulty remembering the details of "who had solved the ABI problem the right way a long time ago", but could not remember enough of it to dredge it up even with repeated searches. Unfortunately Google remains stymied even by the quite explicit terms "tom hastings" vax vms abi ...do you have a link to a white paper I could read? I have an ecosystem in mind that might be receptive to the concept. Regards, Branden [1] NAME 0c, 1c, 2c, 5c, 6c, 7c, 8c, kc, qc, vc - C compilers [...] DESCRIPTION These commands compile the named C files into object files for the corresponding architecture. If there are multiple C files, the compilers will attempt to keep $NPROC compilations running con currently. Associated with each compiler is a string objtype, for example 0c spim little-endian MIPS 3000 family 1c 68000 Motorola MC68000 2c 68020 Motorola MC68020 5c arm little-endian ARM 6c amd64 AMD64 and compatibles (e.g., Intel EM64T) 7c alpha Digital Alpha APX 8c 386 Intel i386, i486, Pentium, etc. kc sparc Sun SPARC qc power Power PC vc mips big-endian MIPS 3000 family

The permuted index is surprisingly useful in this regard but isn't always there in manpage sources, you'd have to generate it. There are the technical memoranda too, starting with V6 those were distributed with the manpages from what I know. Research and BSD kept them packed in to the end but USG took them out starting with System V presumably to make more paper documentation sales. The technical papers still hold a lot of value imo and render much of the literature out there redundant. They're my preferred source of "how do I do xyz" even if 1000 books have been published on the same subject. - Matt G.

On Mon, Jun 12, 2023 at 7:50 PM G. Branden Robinson < g.branden.robinson(a)gmail.com&gt; wrote: This is a fair point and is actually true of almost any system or, for that matter social setting, if you have a guide it's a lot easier to know what to do or fool people into thinking you do; Liza Doolittle style. Again fair - which is why I think losing things like the old UNIX (I think bwk originated) 'learn system' from the stock releases is a little sad. I used to tell newcomers - to spend an AM with learn and go through the files/more files/vi scripts and then come back to me, and I'll try to help you. My line was that UNIX always had a more difficult learning curve than, say GUI based systems (or even some of the old DEC ones likes TOPS or VMS), but once you learned the tools and ideas, it was much simpler to use - made more sense (to me certainly). [Teach someone to fish, *vs.* give them one idea]. But as you point out, that only works if you have someone(s) to ask. Again a fair observation -- however, making_your_switches_so_verbose_no_one_can_remember_much_less_type_them_gnu style is just as bad. Developing "good taste" is sometimes difficult. I'll not defend the "Unix room culture" or the later Plan9 folks (many of whom are my friends) - but I also get it. They were making something for themselves. And here is where it gets tricky -- too many systems are designed to be the solution to too make problems by trying to learn and correct all past sins (Brook's "second-system effect") but fail because no one cares/uses them. The economics of switching are not there. Frankly, when you build for yourself or, better yet, use what Tektronix called the "next bench" [1] idea, you often can find that happy compromise. Simple enough to learn but not a burden to use. At least APL chose sigils that were tough to confuse with other things. True, but you have not lived until someone brings a yellow piece of ASR33 paper into your office, and they are using the APL replacement operations and telling you this is this life's work -- 200 lines of APL - they think there is something wrong with the system. You have to decode the program and tell them they used the wrong operator. ... or better, they actually were right but you can not reproduce the error without their program and datasets. Best wishes, Clem [1] Tektronix's "Next Bench" - was a simple idea. They were an instrumentation company made up of EE primarily. Everyone had work benches, not desks, to work on their projects. The idea was if you saw a colleague the "next bench over" struggling with solving a problem and you could think of a tool or test to help them solve it, chances are pretty good other people were having the same issue. So, if you make it easy to use and become available, you will have a product and it is likely to be popular. The key points: solve a problem, is easy to use, and made available.

Dan, I suspect that we are more in agreement than you might recognize. Your *Guide vs. Guild* is spot on. I don't have a problem asking questions, and as you know, I answer many newbie questions WRT SIMH, PiDP-x, and the like, as well as ask questions about stuff I am not familiar with. I have had an issue with a questioneer when the reply to the question is: "*Here is how to learn the answer* " (*i.e*.*, teach the questioneer how to find the solution),* but if said party is unwilling to do the background work (or the suggested work from the answer) - but just wants to be spoon-fed for that particular issue so they can move on, instead of* learning how to solve* it and hopefully the next issue themselves. Someone asking a question is fine with me. And answer from me, or you may offer a small reminder of *here is how to learn*. Asking -- "*Folks, I can't be the first person that ran into this ... what can I read'/where can I learn/is there a tutorial/book, etc. that explains/has an example on how to do X*" is a perfectly fine question (we get them on simh all the time as an example). Even "*I'm stuck, and I'm getting this result when I try ...*" So *h**ow you ask* your question helps, of course, that is, please try to demonstrate that you have done some work already but are currently running into a dead end. That said, as you point out, *how you answer* is just as important. RTFM or see-figure-one are not ok answers - tempting as they may seem to be. But I think it is ok to say: "*If you look here ... read this book/document, you should be able to figure it out*" is a fair reply and not acting like the "Guild" -- that, to me, is guiding. But if the same user just asked the same question on a different list when they were pointed to on how to find that answer, that is not the proper answer. The trick for the OP is to try to do your homework and show how/why you are stuck - what don't you understand - so you can be guided and demonstrate you actually want to learn. WRT to respect each other and look at each other as peers. Amen. For all my joking, I think it's great that you, Branden, et al. have taken the reins from folks like me and are keeping alive the ideas and techniques we started years before. I thank you both (and the others out there I have not directly recognized) for your efforts, and I think you two both do learn and look to lists like COFF and TUHS as amazing resources where you can both learn and contribute (as a peer). Note I learn from both lists all the time. But I do reserve the right to sometimes ask as a master, passing on knowledge (like why ignoring/denigrating Fortran is at your peril). I did try to do it humorously, and I'm even happier that Branden caught my probably bad/poor taste - Kung Fu joke. Respectfully, Clem ᐧ On Wed, Jun 14, 2023 at 9:34 AM Dan Cross &lt;crossd(a)gmail.com&gt; wrote:

On Wed, Jun 14, 2023 at 3:14 PM Dan Cross &lt;crossd(a)gmail.com&gt; wrote: So that'd be a crack rock then?

On Mon, Jun 12, 2023 at 8:30 PM G. Branden Robinson < g.branden.robinson(a)gmail.com&gt; wrote: Ah, the intended audience did catch the reference -- well done. ᐧ

On Jun 12, 2023, at 8:05 PM, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: You missed your chance to say "Patience, Young Grasshopper!" [I wonder if "Patience you must have, Young Padawan" has a connection to the above. Yoda must have watched Kung Fu!]