From emu at e-bbes.com Sun Jun 11 22:46:58 2023 From: emu at e-bbes.com (emanuel stiebler) Date: Sun, 11 Jun 2023 08:46:58 -0400 Subject: [COFF] Esix SVR4 Message-ID: <962767dd-df8f-256c-15a6-764870b70ea0@e-bbes.com> Hi, anybody still has the install media for that? We used it in the office long ago, but I lost the install disk in my last moving :( THANKS! From sauer at technologists.com Mon Jun 12 00:42:39 2023 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Sun, 11 Jun 2023 09:42:39 -0500 Subject: [COFF] Esix SVR4 In-Reply-To: <962767dd-df8f-256c-15a6-764870b70ea0@e-bbes.com> References: <962767dd-df8f-256c-15a6-764870b70ea0@e-bbes.com> Message-ID: On 6/11/2023 7:46 AM, emanuel stiebler wrote: > Hi, > anybody still has the install media for that? > We used it in the office long ago, but I lost the install disk in my > last moving :( > > THANKS! I don't think I ever saw Esix hands on, but if memory serves, we at Dell considered Esix the most serious & respectable rival to our SVR4. Dell SVR4 images are readily available at various places. See https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/ Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From emu at e-bbes.com Mon Jun 12 19:07:45 2023 From: emu at e-bbes.com (emanuel stiebler) Date: Mon, 12 Jun 2023 05:07:45 -0400 Subject: [COFF] Esix SVR4 In-Reply-To: References: <962767dd-df8f-256c-15a6-764870b70ea0@e-bbes.com> Message-ID: On 2023-06-11 10:42, Charles H Sauer (he/him) wrote: > I don't think I ever saw Esix hands on, but if memory serves, we at Dell > considered Esix the most serious & respectable rival to our SVR4. Dell > SVR4 images are readily available at various places. See > https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/ I liked that one in your notes: "Dell SVR4 finally seemed like real UNIX on a PC" :) From clemc at ccc.com Tue Jun 13 08:39:32 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Jun 2023 18:39:32 -0400 Subject: [COFF] [TUHS] Re: crt0 -- what's in that name? In-Reply-To: <20230612213912.mywv5znz66pk3n5q@illithid> References: <20230612213912.mywv5znz66pk3n5q@illithid> Message-ID: Apologies to TUHS - other than please don't think Fortran did not impact UNIX and its peers. We owe that community our jobs, and for creating the market in that we all would build systems and eventually improve. Note: I'm CCing COFF - you want to continue this... On Mon, Jun 12, 2023 at 5:39 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > It's an ill wind that blows a Fortran runtime using the same convention. > Be careful there, weedhopper ... Fortran gave a lot to computing (including UNIX) and frankly still does. I did not write have too much Fortran as a professional (mostly early in my career), but I did spent 50+ years ensuring that the results of the Fortran compiler ran >>really well<< on the systems I built. As a former collegiate of Paul W and I once said, "*Any computer executive that does not take Fortran seriously will not have their job very long.* It pays our salary." It's still the #1 language for science [its also not the same language my Father learned in the late 50s/early 60s, much less the one I learned 15 years later - check out: In what type of work is the Fortran Programming Language most used today , Is Fortran still alive , Is Fortran obsolete FWIW: These days, the Intel Fortran compiler (and eventually the LLVM one, which Intel is the primary developer), calls the C/C++ common runtime for support. Most libraries are written in C, C++, (or assembler in some very special cases) - so now it's C that keeps Fortran alive. But "in the beginning" it was all about Fortran because that paid the bills then and still does today. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Tue Jun 13 08:50:13 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 12 Jun 2023 17:50:13 -0500 Subject: [COFF] [TUHS] Re: crt0 -- what's in that name? In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> Message-ID: <20230612225013.ru6jfhv2tmjjftxn@illithid> Hi Clem, At 2023-06-12T18:39:32-0400, Clem Cole wrote: > Apologies to TUHS - other than please don't think Fortran did not > impact UNIX and its peers. We owe that community our jobs, and for > creating the market in that we all would build systems and eventually > improve. Absolutely. Fortran (77) was the first language this weedhopper learned after BASIC (which, while much despised by the sorts of people who update jargon files, _also_ had early support in CSRC Unix). While I intensely disliked the fixed-source format (a defect Fortran 90 remedied), I acquired it more easily than C, to the relief of the guys on my class project team who already knew C and _hated_ Fortran. My wisecrack was not meant as a derogation of Fortran in any way, but rather as a sly (not really) allusion to a word also appearing in your expansion of the COFF list's name as seen above... Best regards to you and to Fortran, and a nod to the copy of Metcalf/Reid/Cohen on my bookshelf, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From clemc at ccc.com Tue Jun 13 08:57:25 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Jun 2023 18:57:25 -0400 Subject: [COFF] [TUHS] Re: crt0 -- what's in that name? In-Reply-To: <20230612225013.ru6jfhv2tmjjftxn@illithid> References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612225013.ru6jfhv2tmjjftxn@illithid> Message-ID: Fair enough 👍 ᐧ On Mon, Jun 12, 2023 at 6:50 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > Hi Clem, > > At 2023-06-12T18:39:32-0400, Clem Cole wrote: > > Apologies to TUHS - other than please don't think Fortran did not > > impact UNIX and its peers. We owe that community our jobs, and for > > creating the market in that we all would build systems and eventually > > improve. > > Absolutely. Fortran (77) was the first language this weedhopper learned > after BASIC (which, while much despised by the sorts of people who > update jargon files, _also_ had early support in CSRC Unix). While I > intensely disliked the fixed-source format (a defect Fortran 90 > remedied), I acquired it more easily than C, to the relief of the guys > on my class project team who already knew C and _hated_ Fortran. > > My wisecrack was not meant as a derogation of Fortran in any way, but > rather as a sly (not really) allusion to a word also appearing in your > expansion of the COFF list's name as seen above... > > Best regards to you and to Fortran, and a nod to the copy of > Metcalf/Reid/Cohen on my bookshelf, > Branden > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Jun 13 09:04:31 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 12 Jun 2023 19:04:31 -0400 Subject: [COFF] [TUHS] Re: crt0 -- what's in that name? In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> Message-ID: On 6/12/23, Clem Cole wrote: > > On Mon, Jun 12, 2023 at 5:39 PM G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > >> It's an ill wind that blows a Fortran runtime using the same convention. >> > Be careful there, weedhopper ... I don't think this remark was intended to denigrate Fortran in any way. I took it as a wryly humorous way to make the observation that C and Fortran have different program startup semantics, and that there is other stuff that has to be done when firing up a program written wholly or partially in Fortran beyond what is needed to start up a C application. Most operating system ABIs, Unix included, don't have a formalized mechanism for dealing with the differences between startup semantics of various programming languages. They deal with the problem in an ad-hack fashion. The one exception that I know of is VMS (now OpenVMS). Tom Hastings was the architect who designed the original VAX/VMS ABI. He was aware from the get-go that several programming languages had to be supported and he made sure that his design was general enough to allow programmers to write routines in the most suitable language for them, to mix and match modules written in different languages in the same program, and to easily make calls from one language to another. It was a stroke of genius and I haven't seen its like in any other OS (several times I've wished it was there, though). Further discussion in COFF. -Paul W. From g.branden.robinson at gmail.com Tue Jun 13 09:49:53 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 12 Jun 2023 18:49:53 -0500 Subject: [COFF] [TUHS] Re: crt0 -- what's in that name? In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> Message-ID: <20230612234953.pwu7oi6hyglsaqzs@illithid> [Clem and TUHS dropped from CC] Hi Paul, At 2023-06-12T19:04:31-0400, Paul Winalski wrote: > I don't think this remark was intended to denigrate Fortran in any > way. I took it as a wryly humorous way to make the observation that C > and Fortran have different program startup semantics, and that there > is other stuff that has to be done when firing up a program written > wholly or partially in Fortran beyond what is needed to start up a C > application. 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. > Most operating system ABIs, Unix included, don't have a formalized > mechanism for dealing with the differences between startup semantics > of various programming languages. They deal with the problem in an > ad-hack fashion. The one exception that I know of is VMS (now > OpenVMS). Tom Hastings was the architect who designed the original > VAX/VMS ABI. He was aware from the get-go that several programming > languages had to be supported and he made sure that his design was > general enough to allow programmers to write routines in the most > suitable language for them, to mix and match modules written in > different languages in the same program, and to easily make calls from > one language to another. It was a stroke of genius and I haven't seen > its like in any other OS (several times I've wished it was there, > though). 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From grog at lemis.com Tue Jun 13 09:57:08 2023 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 13 Jun 2023 09:57:08 +1000 Subject: [COFF] Weedhopper? (was: crt0 -- what's in that name?) In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> Message-ID: <20230612235708.GI83871@eureka.lemis.com> On Monday, 12 June 2023 at 18:39:32 -0400, Clem Cole wrote: > On Mon, Jun 12, 2023 at 5:39 PM G. Branden Robinson wrote: > >> It's an ill wind that blows a Fortran runtime using the same convention. > > Be careful there, weedhopper ... Now there's a word I have never heard before. Neither have my dictionaries, and Google gets sidetracked. What's the meaning and the background? On the other hand, I have heard of BSS and BES. It was in the DDP-516 (basis for the IMP) assembler. Is that how it found its way into Unix? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From g.branden.robinson at gmail.com Tue Jun 13 10:30:35 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 12 Jun 2023 19:30:35 -0500 Subject: [COFF] Weedhopper? (was: crt0 -- what's in that name?) In-Reply-To: <20230612235708.GI83871@eureka.lemis.com> References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612235708.GI83871@eureka.lemis.com> Message-ID: <20230613003035.adjty5npcpxfa6a3@illithid> At 2023-06-13T09:57:08+1000, Greg 'groggy' Lehey wrote: > On Monday, 12 June 2023 at 18:39:32 -0400, Clem Cole wrote: > > On Mon, Jun 12, 2023 at 5:39 PM G. Branden Robinson wrote: > > > >> It's an ill wind that blows a Fortran runtime using the same convention. > > > > Be careful there, weedhopper ... > > Now there's a word I have never heard before. Neither have my > dictionaries, and Google gets sidetracked. What's the meaning and the > background? I interpreted it as a coinage based on the old _Kung Fu_ television series (where David Carradine's youthful and callow character was called "grasshopper" by his sensei), hybridized with a suggestion that, to speak ill of Fortran, I must be stoned out of my gourd. ;-) 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 clemc at ccc.com Tue Jun 13 13:05:37 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Jun 2023 23:05:37 -0400 Subject: [COFF] Weedhopper? (was: crt0 -- what's in that name?) In-Reply-To: <20230612235708.GI83871@eureka.lemis.com> References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612235708.GI83871@eureka.lemis.com> Message-ID: On Mon, Jun 12, 2023 at 7:57 PM Greg 'groggy' Lehey wrote: > On Monday, 12 June 2023 at 18:39:32 -0400, Clem Cole wrote: > > On Mon, Jun 12, 2023 at 5:39 PM G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > > > >> It's an ill wind that blows a Fortran runtime using the same convention. > > > > Be careful there, weedhopper ... > > Now there's a word I have never heard before. Neither have my > dictionaries, and Google gets sidetracked. What's the meaning and the > background? > I was making a joke from those times -- sorry it fell flat [The Kung Fu series that airs from 1972 to 1975, a young character is taught by an old blind master, who he called "grasshopper."] > > On the other hand, I have heard of BSS and BES. It was in the DDP-516 (basis > for the IMP) assembler. Is that how it found its way into Unix? > As I said, it was originally from the United Aircraft assembler and released to the IBM SHARE community in the late 1950s, which Doug verified. As Paul said, in those days, you did not want to waste cycles setting up memory if you did not need to, and security was not an issue, so have the assembler/compiler reserve "block common" after it loaded the code and initialized data. To younger programmers, these machines (including the variable S/360) do not have a stack. They used it as a calling convention that saves things in what IBM called the "push down save area." Like Paul, while I learned assembler first on the S/360, I don't remember if a BAL for TSS/360 directive called BSS, but I certainly remember being taught about the idea of Block Storage and having it drilled into my brain by my Kung Fu master at the time, Don Gregg. I've now forgotten what it did or the special rules for it. Still, I do remember that the APL system had to be careful about what was in what 'SECT' and, early on, screwing something up in one of my first assembler tweaks of the APL system and getting an 'education' about the errors of my way by my master - thus being taught the differences.😉 Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Tue Jun 13 13:07:04 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Jun 2023 23:07:04 -0400 Subject: [COFF] Weedhopper? (was: crt0 -- what's in that name?) In-Reply-To: <20230613003035.adjty5npcpxfa6a3@illithid> References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612235708.GI83871@eureka.lemis.com> <20230613003035.adjty5npcpxfa6a3@illithid> Message-ID: On Mon, Jun 12, 2023 at 8:30 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > At 2023-06-13T09:57:08+1000, Greg 'groggy' Lehey wrote: > > On Monday, 12 June 2023 at 18:39:32 -0400, Clem Cole wrote: > > > On Mon, Jun 12, 2023 at 5:39 PM G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > > > > > >> It's an ill wind that blows a Fortran runtime using the same > convention. > > > > > > Be careful there, weedhopper ... > > > > Now there's a word I have never heard before. Neither have my > > dictionaries, and Google gets sidetracked. What's the meaning and the > > background? > > I interpreted it as a coinage based on the old _Kung Fu_ television > series (where David Carradine's youthful and callow character was called > "grasshopper" by his sensei), hybridized with a suggestion that, to > speak ill of Fortran, I must be stoned out of my gourd. ;-) > Ah, the intended audience did catch the reference -- well done. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Tue Jun 13 13:26:24 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 12 Jun 2023 20:26:24 -0700 Subject: [COFF] Weedhopper? (was: crt0 -- what's in that name?) In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612235708.GI83871@eureka.lemis.com> Message-ID: On Jun 12, 2023, at 8:05 PM, Clem Cole wrote: > > On Mon, Jun 12, 2023 at 7:57 PM Greg 'groggy' Lehey > wrote: >> On Monday, 12 June 2023 at 18:39:32 -0400, Clem Cole wrote: >> > On Mon, Jun 12, 2023 at 5:39 PM G. Branden Robinson > wrote: >> > >> >> It's an ill wind that blows a Fortran runtime using the same convention. >> > >> > Be careful there, weedhopper ... >> >> Now there's a word I have never heard before. Neither have my >> dictionaries, and Google gets sidetracked. What's the meaning and the >> background? 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!] -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Wed Jun 14 02:28:45 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Tue, 13 Jun 2023 12:28:45 -0400 Subject: [COFF] [TUHS] Re: crt0 -- what's in that name? In-Reply-To: <20230612234953.pwu7oi6hyglsaqzs@illithid> References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612234953.pwu7oi6hyglsaqzs@illithid> Message-ID: On 6/12/23, G. Branden Robinson wrote: > > 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. IMO, one area where Unix is severely deficient is online help for the novice or casual user. man pages are fine if you already know the command you want to use and just need to know details about options and switches. But man pages are utterly useless if your question is "what command do I need to use to do X?" The Unix problem of non-obvious command names is made worse by some of the commands whose names are obscure in-jokes. The worst offender is probably the biff utility. This is the command that lets you set notifications for incoming email. Why biff? Because a friend of the guy who wrote the utility had a dog named Biff who used to bark at the mailman. > >> Most operating system ABIs, Unix included, don't have a formalized >> mechanism for dealing with the differences between startup semantics >> of various programming languages. They deal with the problem in an >> ad-hack fashion. The one exception that I know of is VMS (now >> OpenVMS). Tom Hastings was the architect who designed the original >> VAX/VMS ABI. He was aware from the get-go that several programming >> languages had to be supported and he made sure that his design was >> general enough to allow programmers to write routines in the most >> suitable language for them, to mix and match modules written in >> different languages in the same program, and to easily make calls from >> one language to another. It was a stroke of genius and I haven't seen >> its like in any other OS (several times I've wished it was there, >> though). > > 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 Try "openvms common language environment" in Google. The Common Language Environment (CLE) is the official name for the architectural rules that facilitate multi-language programming. VMS (officially OpenVMS; I hated that marketing name when it was first proposed and I hate it now) is still alive and supported by a company called VMS Software, Inc. (VSI). Here is a pointer to their document OpenVMS Programming Concepts, Volume II, which describes the CLE in detail: https://vmssoftware.com/docs/VSI_PROGRAM_CONCEPTS_VOL_II.pdf -Paul W. From clemc at ccc.com Wed Jun 14 03:02:36 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 13 Jun 2023 13:02:36 -0400 Subject: [COFF] UNIX and its users - new or old In-Reply-To: <20230612234953.pwu7oi6hyglsaqzs@illithid> References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612234953.pwu7oi6hyglsaqzs@illithid> Message-ID: On Mon, Jun 12, 2023 at 7:50 PM G. Branden Robinson < g.branden.robinson at gmail.com> wrote: > 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. > 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. > > 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. > 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. > > ... when Bell Labs got the Blit, the limitations that motivated the > original terseness were not only not discarded, but > retained and doubled down on. > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Wed Jun 14 03:04:39 2023 From: coff at tuhs.org (segaloco via COFF) Date: Tue, 13 Jun 2023 17:04:39 +0000 Subject: [COFF] [TUHS] Re: crt0 -- what's in that name? In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612234953.pwu7oi6hyglsaqzs@illithid> Message-ID: > But man pages are utterly useless if your question is > "what command do I need to use to do X?" 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. From clemc at ccc.com Wed Jun 14 03:32:52 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 13 Jun 2023 13:32:52 -0400 Subject: [COFF] [TUHS] Re: crt0 -- what's in that name? In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612234953.pwu7oi6hyglsaqzs@illithid> Message-ID: On Tue, Jun 13, 2023 at 1:05 PM segaloco via COFF wrote: > The permuted index is surprisingly useful in this regard but isn't always > there in manpage sources, you'd have to generate it. > Indeed. @Doug do you know who was the brilliant person that came up with that tool and built the first UNIX PTX? I always felt they should be lauded for that piece of work! It was something that when I first learned about UNIX that I did like. I was primarily coming from TOPS and TSS, and UNIX was strange when I first saw it -- cat instead of print or type, of course, being the first roadblock. But when I found the PTX was one of the first times that "light dawned on marble head." I saw UNIX long before "learn" was released, but I certainly had helped enough new users by the time it was available that the "learn" tool, a printed copy of the man pages, and PTX were where I told "newbies" to start. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Jun 14 23:33:42 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 14 Jun 2023 09:33:42 -0400 Subject: [COFF] UNIX and its users - new or old In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612234953.pwu7oi6hyglsaqzs@illithid> Message-ID: On Tue, Jun 13, 2023 at 1:03 PM Clem Cole wrote: > On Mon, Jun 12, 2023 at 7:50 PM G. Branden Robinson wrote: >> 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. > > 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. Forgive me, Clem, but I'm going to push back on this a little bit. The TL;DR of my position is, "guides, yes; guilds, no." I agree with the idea that having a friendly guide to help one acclimate to a system is really useful: provided that guide is actually friendly and helpful. I find that the interaction works best when people regard each other as peers, with one imparting specific knowledge to the other to fill in gaps in the latter's experience. I find it works very poorly when one side is arrogant and belittling towards the other. I believe that the "guild" mentality encourages the latter behavior, with an "in-group" that demands unearned respect. Mutual respect works much better. Moreover, adoption of this guild model (really, the mentality) with partitioning people into groups of "apprentices", "journeymen" and "masters" has allowed for the rise of charlatans and cranks across the industry. Consider people like Robert Martin: he's become known as a "master software craftsman", has published many books that sell well, and speaks at conferences across the industry. And yet, near as I can tell, he hasn't actually written all that much software; certainly not much that is publicly available. What is there shows that he is a middling programmer at best; certainly not worthy of the accolades heaped on him. Same with people like Allen Hollub, who's biggest claim to fame seems to be writing a book on compilers that is mostly material regurgitated from the Dragon Book (but in poorly-written C), and who infamously rails against things like issue trackers (seriously: tell me you've never worked on a big project without telling me that you've never worked on a big project). Then there's the rest of the agile influencer cult; mostly more of the same. >> 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. > > 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. There is a qualitative difference here. Being willing to mentor and (importantly) providing access to learning materials is very different from being disdainful for those who don't already "have a clue". Being friendly and helpful is also qualitatively different from demanding groveling behavior from the "apprentice" caste before they can be allowed some scraps from the table. I argue that the "guild" mentality leads to the latter. > 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. ...and that person is not a jerk to you for daring to ask a question they don't already know the answer to. That, I think, is the fundamental difference that G. Branden was trying to highlight. - Dan C. From clemc at ccc.com Thu Jun 15 01:39:45 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 14 Jun 2023 11:39:45 -0400 Subject: [COFF] UNIX and its users - new or old In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612234953.pwu7oi6hyglsaqzs@illithid> Message-ID: 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 wrote: > On Tue, Jun 13, 2023 at 1:03 PM Clem Cole wrote: > > On Mon, Jun 12, 2023 at 7:50 PM G. Branden Robinson < > g.branden.robinson at gmail.com> wrote: > >> 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. > > > > 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. > > Forgive me, Clem, but I'm going to push back on this a little bit. The > TL;DR of my position is, "guides, yes; guilds, no." > > I agree with the idea that having a friendly guide to help one > acclimate to a system is really useful: provided that guide is > actually friendly and helpful. I find that the interaction works best > when people regard each other as peers, with one imparting specific > knowledge to the other to fill in gaps in the latter's experience. I > find it works very poorly when one side is arrogant and belittling > towards the other. I believe that the "guild" mentality encourages the > latter behavior, with an "in-group" that demands unearned respect. > Mutual respect works much better. > > Moreover, adoption of this guild model (really, the mentality) with > partitioning people into groups of "apprentices", "journeymen" and > "masters" has allowed for the rise of charlatans and cranks across the > industry. Consider people like Robert Martin: he's become known as a > "master software craftsman", has published many books that sell well, > and speaks at conferences across the industry. And yet, near as I can > tell, he hasn't actually written all that much software; certainly not > much that is publicly available. What is there shows that he is a > middling programmer at best; certainly not worthy of the accolades > heaped on him. > > Same with people like Allen Hollub, who's biggest claim to fame seems > to be writing a book on compilers that is mostly material regurgitated > from the Dragon Book (but in poorly-written C), and who infamously > rails against things like issue trackers (seriously: tell me you've > never worked on a big project without telling me that you've never > worked on a big project). Then there's the rest of the agile > influencer cult; mostly more of the same. > > >> 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. > > > > 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. > > There is a qualitative difference here. Being willing to mentor and > (importantly) providing access to learning materials is very different > from being disdainful for those who don't already "have a clue". Being > friendly and helpful is also qualitatively different from demanding > groveling behavior from the "apprentice" caste before they can be > allowed some scraps from the table. I argue that the "guild" mentality > leads to the latter. > > > 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. > > ...and that person is not a jerk to you for daring to ask a question > they don't already know the answer to. That, I think, is the > fundamental difference that G. Branden was trying to highlight. > > - Dan C. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Jun 15 08:13:19 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 14 Jun 2023 18:13:19 -0400 Subject: [COFF] UNIX and its users - new or old In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612234953.pwu7oi6hyglsaqzs@illithid> Message-ID: On Wed, Jun 14, 2023 at 11:40 AM Clem Cole wrote: > 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. Indeed! And I apologize if it came across as if I were directing any criticism at you (or anyone else on this list); that wasn't my intention at all. Really, I only wanted to point out a subtlety in what (I think) G. Branden was saying that I thought was (inadvertently) overlooked. > 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. I have a problem with this, too, but I think that's a bit orthogonal to what was under discussion. Of course, in any of these interactions, one hopes that the other party actually wants to learn and is willing to put in the effort! > 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 how 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. Absolutely! I'm sure we have all run into the issue of, "I've got a problem and simply don't know where to start: what's your advice?" before and I try (and, I admit, sometimes fail) at being receptive to that for others as well. It can be hard to ask, because it can feel embarrassing, but we've all been there before. > 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. Absolutely. > WRT to respect each other and look at each other as peers. Amen. Indeed. And I'd like to reiterate that I generally feel like this list and this community is very good at that. However, the charlatan effect with the Martins, Holubs, Jeffries, etc, of the world is very real. Curiously, Holub is listed as a technical reviewer on K&R2! (No idea how that happened....) > 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. That's really kind of you to say, Clem. Honestly, I didn't catch that it was a weed joke (despite "weedhopper" literally containing the word "weed") until G. Branden pointed it out. I guess that says something about the kinda rock I live under these days.... - Dan C. From athornton at gmail.com Thu Jun 15 14:20:32 2023 From: athornton at gmail.com (Adam Thornton) Date: Wed, 14 Jun 2023 21:20:32 -0700 Subject: [COFF] UNIX and its users - new or old In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612234953.pwu7oi6hyglsaqzs@illithid> Message-ID: On Wed, Jun 14, 2023 at 3:14 PM Dan Cross wrote: > That's really kind of you to say, Clem. Honestly, I didn't catch that > it was a weed joke (despite "weedhopper" literally containing the word > "weed") until G. Branden pointed it out. I guess that says something > about the kinda rock I live under these days.... > > > So that'd be a crack rock then? -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Jun 15 22:13:02 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 15 Jun 2023 08:13:02 -0400 Subject: [COFF] UNIX and its users - new or old In-Reply-To: References: <20230612213912.mywv5znz66pk3n5q@illithid> <20230612234953.pwu7oi6hyglsaqzs@illithid> Message-ID: On Thu, Jun 15, 2023 at 12:20 AM Adam Thornton wrote: > On Wed, Jun 14, 2023 at 3:14 PM Dan Cross wrote: >> That's really kind of you to say, Clem. Honestly, I didn't catch that >> it was a weed joke (despite "weedhopper" literally containing the word >> "weed") until G. Branden pointed it out. I guess that says something >> about the kinda rock I live under these days.... > > So that'd be a crack rock then? Don't judge me.... - Dan C. From coff at tuhs.org Fri Jun 16 06:55:50 2023 From: coff at tuhs.org (segaloco via COFF) Date: Thu, 15 Jun 2023 20:55:50 +0000 Subject: [COFF] White Backgrounds on GUIs after Dark Backgrounds on Terminals? Message-ID: Good afternoon everyone. I've been thinking about the color/contrast landscape of computing today and have a bit of a nebulous quandary that I wonder if anyone would have some insight on. So terminals, they started as typewriters with extra steps, a white piece of paper on a reel being stamped with dark ink to provide feedback from the machine. When video terminals hit the market, the display was a black screen with white, orange, green, or whatever other color of phosphor they bothered to smear on the surface of the tube. Presumably this display style was chosen as on a CRT, you're only lighting phosphor where there is actually an image, unlike the LCD screens of today. So there was a complete contrast shift from dark letters on white paper to light letters on an otherwise unlit pane of glass. Step forward to graphical systems and windows on the Alto? Light background with dark text. Windows on the Macintosh? Light background with dark text. Windows on MS Windows? Light backgrounds with dark text. Default HTML rendering in browsers? Light backgrounds with dark text. Fast forward to today, and it seems that dark themes are all the rage, light characters on an otherwise dark background. This would've made so much sense during the CRT era as every part of the screen representing a black pixel is getting no drawing, but when CRTs were king, the predominant visual style was dark on light, like a piece of paper, rather than light on dark, like a video terminal. Now in the day and age of LCDs, where every pixel is on regardless, now we're finally flipping the script and putting light characters on dark backgrounds, long after any hardware benefit (that I'm aware of) would be attained by minimizing the amount of "lit surface" on the screen. Anyone know if this has all been coincidental or if the decision for graphical user interfaces and such to predominantly use white/light colors for backgrounds was a relatively intentional measure around the industry? Or is it really just that that's how Xerox's system looked and it was all domino effect after that? At the end of the day I'm really just finding myself puzzling why computing jumped into the minimalism seen on terminal screens, keeping from driving CRTs super hard but then when GUIs first started appearing, they didn't just organically align with what was the most efficient for a CRT. I recognize this is based largely in subjective views of how something should look too, so not really expecting a "Person XYZ authoritatively decided on that GUI elements shall overwhelmingly only be dark on light", just some thoughts on how we got going down this path with color schemes in computing. Thanks all! - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Jun 16 11:24:57 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 15 Jun 2023 19:24:57 -0600 Subject: [COFF] White Backgrounds on GUIs after Dark Backgrounds on Terminals? In-Reply-To: References: Message-ID: On Thu, Jun 15, 2023, 2:56 PM segaloco via COFF wrote: > Good afternoon everyone. I've been thinking about the color/contrast > landscape of computing today and have a bit of a nebulous quandary that I > wonder if anyone would have some insight on. > > So terminals, they started as typewriters with extra steps, a white piece > of paper on a reel being stamped with dark ink to provide feedback from the > machine. When video terminals hit the market, the display was a black > screen with white, orange, green, or whatever other color of phosphor they > bothered to smear on the surface of the tube. Presumably this display style > was chosen as on a CRT, you're only lighting phosphor where there is > actually an image, unlike the LCD screens of today. So there was a complete > contrast shift from dark letters on white paper to light letters on an > otherwise unlit pane of glass. > Many terminal had a reverse video setting even in advance of the graphical interfaces Step forward to graphical systems and windows on the Alto? Light background > with dark text. > Windows on the Macintosh? Light background with dark text. > Windows on MS Windows? Light backgrounds with dark text. > Default HTML rendering in browsers? Light backgrounds with dark text. > You can add x10/x11 to the early list... as well as decwindows on the VAX station ii era... Fast forward to today, and it seems that dark themes are all the rage, > light characters on an otherwise dark background. This would've made so > much sense during the CRT era as every part of the screen representing a > black pixel is getting no drawing, but when CRTs were king, the predominant > visual style was dark on light, like a piece of paper, rather than light on > dark, like a video terminal. Now in the day and age of LCDs, where every > pixel is on regardless, now we're finally flipping the script and putting > light characters on dark backgrounds, long after any hardware benefit (that > I'm aware of) would be attained by minimizing the amount of "lit surface" > on the screen. > > Anyone know if this has all been coincidental or if the decision for > graphical user interfaces and such to predominantly use white/light colors > for backgrounds was a relatively intentional measure around the industry? > Or is it really just that that's how Xerox's system looked and it was all > domino effect after that? At the end of the day I'm really just finding > myself puzzling why computing jumped into the minimalism seen on terminal > screens, keeping from driving CRTs super hard but then when GUIs first > started appearing, they didn't just organically align with what was the > most efficient for a CRT. I recognize this is based largely in subjective > views of how something should look too, so not really expecting a "Person > XYZ authoritatively decided on that GUI elements shall > overwhelmingly only be dark on light", just some thoughts on how we got > going down this path with color schemes in computing. Thanks all! > Dark on light was to mimic paper. I'm also skeptical that light on dark uses less power or was easier to implement except maybe in the very earliest vector displays... Warner - Matt G. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Fri Jun 16 12:57:39 2023 From: athornton at gmail.com (Adam Thornton) Date: Thu, 15 Jun 2023 19:57:39 -0700 Subject: [COFF] White Backgrounds on GUIs after Dark Backgrounds on Terminals? In-Reply-To: References: Message-ID: I would, however, assume that given that there's bleed (or maybe it's "bloom"? IDK) on a CRT, light-on-dark is more readable. I think Dark Mode is just because the kids these days have become troglodytes whose only interaction with other beings is mediated through their screens, and they keep themselves in the dark because the light, it burns us, it burns us, my precioussss. At least I no longer have to worry about them getting off my lawn. On Thu, Jun 15, 2023 at 6:25 PM Warner Losh wrote: > > > On Thu, Jun 15, 2023, 2:56 PM segaloco via COFF wrote: > >> Good afternoon everyone. I've been thinking about the color/contrast >> landscape of computing today and have a bit of a nebulous quandary that I >> wonder if anyone would have some insight on. >> >> So terminals, they started as typewriters with extra steps, a white piece >> of paper on a reel being stamped with dark ink to provide feedback from the >> machine. When video terminals hit the market, the display was a black >> screen with white, orange, green, or whatever other color of phosphor they >> bothered to smear on the surface of the tube. Presumably this display style >> was chosen as on a CRT, you're only lighting phosphor where there is >> actually an image, unlike the LCD screens of today. So there was a complete >> contrast shift from dark letters on white paper to light letters on an >> otherwise unlit pane of glass. >> > > Many terminal had a reverse video setting even in advance of the graphical > interfaces > > Step forward to graphical systems and windows on the Alto? Light >> background with dark text. >> Windows on the Macintosh? Light background with dark text. >> Windows on MS Windows? Light backgrounds with dark text. >> Default HTML rendering in browsers? Light backgrounds with dark text. >> > > You can add x10/x11 to the early list... as well as decwindows on the VAX > station ii era... > > Fast forward to today, and it seems that dark themes are all the rage, >> light characters on an otherwise dark background. This would've made so >> much sense during the CRT era as every part of the screen representing a >> black pixel is getting no drawing, but when CRTs were king, the predominant >> visual style was dark on light, like a piece of paper, rather than light on >> dark, like a video terminal. Now in the day and age of LCDs, where every >> pixel is on regardless, now we're finally flipping the script and putting >> light characters on dark backgrounds, long after any hardware benefit (that >> I'm aware of) would be attained by minimizing the amount of "lit surface" >> on the screen. >> >> Anyone know if this has all been coincidental or if the decision for >> graphical user interfaces and such to predominantly use white/light colors >> for backgrounds was a relatively intentional measure around the industry? >> Or is it really just that that's how Xerox's system looked and it was all >> domino effect after that? At the end of the day I'm really just finding >> myself puzzling why computing jumped into the minimalism seen on terminal >> screens, keeping from driving CRTs super hard but then when GUIs first >> started appearing, they didn't just organically align with what was the >> most efficient for a CRT. I recognize this is based largely in subjective >> views of how something should look too, so not really expecting a "Person >> XYZ authoritatively decided on that GUI elements shall >> overwhelmingly only be dark on light", just some thoughts on how we got >> going down this path with color schemes in computing. Thanks all! >> > > Dark on light was to mimic paper. > > I'm also skeptical that light on dark uses less power or was easier to > implement except maybe in the very earliest vector displays... > > Warner > > - Matt G. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sat Jun 17 02:08:21 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 16 Jun 2023 12:08:21 -0400 Subject: [COFF] White Backgrounds on GUIs after Dark Backgrounds on Terminals? In-Reply-To: References: Message-ID: On 6/15/23, segaloco via COFF wrote: > > So terminals, they started as typewriters with extra steps, a white piece of > paper on a reel being stamped with dark ink to provide feedback from the > machine. When video terminals hit the market, the display was a black screen > with white, orange, green, or whatever other color of phosphor they bothered > to smear on the surface of the tube. Presumably this display style was > chosen as on a CRT, you're only lighting phosphor where there is actually an > image, unlike the LCD screens of today. So there was a complete contrast > shift from dark letters on white paper to light letters on an otherwise > unlit pane of glass. The phosphors on CRT screens don't last forever. You only want to light them when necessary. CRTs also suffer from the problem of burn-in. If you keep the same picture illuminated for a long period of time that pixel pattern gets burned into the phosphors. This is why the later GUI CRTs had screen saver software that displayed an ever-changing picture to prevent burn-in. This isn't a problem with the modern, non-cathode-ray displays. Good ol' flying toasters. -Paul W. From coff at tuhs.org Sat Jun 17 02:44:06 2023 From: coff at tuhs.org (segaloco via COFF) Date: Fri, 16 Jun 2023 16:44:06 +0000 Subject: [COFF] White Backgrounds on GUIs after Dark Backgrounds on Terminals? In-Reply-To: References: Message-ID: > The phosphors on CRT screens don't last forever. You only want to > light them when necessary. So once upon a time I went to one of our labs for an implementation project. One of the local techs was showing me around the server room and among the various bits was a probably early 2000s CRT that was just collecting dust. It was an eMachines flat screen with the silver bezel. Well, being the proud owner of a silver-bezeled Trinitron, I asked if I could take it off their hands on the way back and have myself a decent CRT monitor again to match my TV. I was told no can do, and in the process learned why it was sitting there. It had been a display for a piece of equipment that ran all sorts of radiochemistry stuff and had been on so frequently that critical identifying information re: the lab was burned into it from the LIMS system landing page that was on the screen daily for years. They legally had to destroy it at some point and just kept it around as a test monitor in the meantime. I've heard similar stories with screens used in sensitive sites like military installations, that the retentive properties of the phosphor screen made them a legitimate security concern. - Matt G. From clemc at ccc.com Sat Jun 17 02:51:41 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 16 Jun 2023 12:51:41 -0400 Subject: [COFF] White Backgrounds on GUIs after Dark Backgrounds on Terminals? In-Reply-To: References: Message-ID: Matt, I take a small stab at this. Like most of us, I don't know the exact reason, but having lived the time, I'll point out a few things. 1.) At the start (60s and 70s), I suspect that economics drove light pixels on dark backgrounds as the high-order bit. 2.) Xerox PARC developed Alto was driven by their research in the Electronic Office -- remember Xerox made its money selling coping >>paper<<. The black-on-white was a specific choice by their researcher as they tried to convince their management of the idea. 3.) High-resolution monitors were costly until the late 1980s (regardless of BW or Color) 4.) Early phosphors tubes suffered from burn, so turning on display "pixels" for long times was bad. That said, TV was constantly changing so it was less of an issue for them, but not for terminals where the dots were the same part of the screen over and over. 5.) "Glass Terminal" designed until the later 1970s were SSI/MSI TTL, with few if any VLSI except for maybe the WD1402A UART 6.) Memory costs per bit compared to today are still high. Remember in 1980, when the CMU "SPICE" proposal came out for the infamous 3M system, we priced the cost of 1MByte of memory (only) which it needed (using Tektronix's volume pricing) at > $3K [BTW: this was the same year that Jake Grimes stood on a take at the Asilomar Microprocessor Workshop and declared memory as being "free" - and compared just a few years previous -- it was]. I observe a few things with those points as a place to start. If you look at the early "glass ttys" like the DEC VT05 and even later the LSI ADM3A - there is nary a microprocessor inside. It's a huge board with lots of TTL [the ADM 3A often came as a kit - you had to solder them yourself]. The other thing to remember, in those days, NTSC in the US and PAL in Europe for TVs was the primary driver for CRTs. So if you were making a display, you had to at least buy the tube from one of a small number of tube manufacturers [IIRC Phillps in the EU was the leader, and GE, RCA, and Raytheon fought it out in the US -- Sony would come later] - (I'm also not sure Magnovox made its own tubes). For instance, I believe DEC bought the tube for the VT05 from Raytheon; who made them locally ??Lowell, MA maybe?? and continued for a while [maybe even through the VT-100]. So remember, for a 25x80 terminal -- that's 2KBytes of memory just for the video [without "attributes"]. So that's also big. IIRC, the VT05, and ADM 3A used early Intel 1103 1Kx1 DRAM. So the eight memory chips are the highest cost part of the logic board. Because of the design, I suspect the turn-on-the-beam logic for a 'dot time" was all the designers cared about. Light on dark fell out of the ease of design, and they had limited BW on the tubes. Even with that, I believe the VT05 was in the $3-5K range in the late 1960s when it was sold for the PDP-8 or the like. I remember in the late 1970s when the $1K glass TTY (the cost of the ADM 3A kit) or the Pekin Elmer "Fox" terminals appeared. So between tubes and logic, it took at least ten years to drive the price down by a factor of 3-5. My friend and former cubical mate at Tektronix, Roger Bates designed the display in the Alto [side tidbit - he has the patent on the loadable curser - which was initially a martini glass, not an hourglass to show time]. Roger told me the monitor they used was a "special order" and was fairly expensive. But it was a definite choice to do black on white -- they wanted to represent paper. FWIW: a great deal of the monitor logic is done in microcode [the infamous BITBLT being an example] because they were already logic constrained. He and Thacker were using huge boards for the processor, and it was all SSI/MSI. *I think it's safe to suggest that Xerox was where the idea/first use of dark on light began.* FWIW, in 1979/80, when he and I were working on Magnolia at Tektronix, Roger had to get the tube from the Sony/Tektronix folks -- it was a special order. Tek itself did not make one that was high enough BW. Roger had just finished designing the 3D frame buffer for Teklabs and had used a Sony/Tek Trinitron color tube in that system - which I remember was one of the most expensive parts of the FB. Roger used its BW cousin for Magnolia, which was cheaper, but the tube and hard disk were the two most expensive parts in Magnolia. Roll the clock forward only 2-5 years. When Apollo, Masscomp, and later Sun started to make workstations, there tended to be three types of display -- a low-resolution BW, a 'paper white" high resolution, and eventually a color tube. Also in the late 70s, Motorola created the 6845 video chip, which along with a micro such as a 6502/6800/Z80, became the de jure standard for most terminals. It. and 8 2102's SRAM chips, and you had a simple (white on dark) display that worked with low-end tubes. Also, the displays were pretty expensive when IBM released the first VGA for its PC/AT. It took the VGA market taken off to start to drive the cost of the monitors down. But anything over 12-15 inches was still pretty expensive, and you needed VRAM to drive it, *etc*. My point is that Black on White does not take off with hockey stick-style growth until after the "workstations." FWIW: the 1980s Mac original display is small and not extremely high resolution compared to what would quickly come to expect. So while people liked the Xerox idea of blank on white, it was not economical. I personally did not get to start using the 'paper' paradigm until the time of the Sun-3 and like (~1985/6). As an engineer, I also remember having the default display resolution - we had more program memory, *etc*., but the tech writer would get a high-end black and white because they were working with text [*i.e*., Framemaker pages] for documents. It was in the mid-1990s that having a solid color display with high resolution became the default. But the cost of the silicon to drive it had to come down, and the market for high-end displays needed to appear. BTW: what happened? LCD came out --- why it used Silicon manufacturing techniques. So once it was perfected, the ability to make a high BW display quickly overtook the analog tube schemes. As for the current light on dark, I wonder if this is just a new set of engineers making their mark. I'm sure it's better. The cost is the same, so now it's just marketing and a way to show off being different - *e.g.*, new/cool. ᐧ On Thu, Jun 15, 2023 at 4:56 PM segaloco via COFF wrote: > Good afternoon everyone. I've been thinking about the color/contrast > landscape of computing today and have a bit of a nebulous quandary that I > wonder if anyone would have some insight on. > > So terminals, they started as typewriters with extra steps, a white piece > of paper on a reel being stamped with dark ink to provide feedback from the > machine. When video terminals hit the market, the display was a black > screen with white, orange, green, or whatever other color of phosphor they > bothered to smear on the surface of the tube. Presumably this display style > was chosen as on a CRT, you're only lighting phosphor where there is > actually an image, unlike the LCD screens of today. So there was a complete > contrast shift from dark letters on white paper to light letters on an > otherwise unlit pane of glass. > > Step forward to graphical systems and windows on the Alto? Light > background with dark text. > Windows on the Macintosh? Light background with dark text. > Windows on MS Windows? Light backgrounds with dark text. > Default HTML rendering in browsers? Light backgrounds with dark text. > > Fast forward to today, and it seems that dark themes are all the rage, > light characters on an otherwise dark background. This would've made so > much sense during the CRT era as every part of the screen representing a > black pixel is getting no drawing, but when CRTs were king, the predominant > visual style was dark on light, like a piece of paper, rather than light on > dark, like a video terminal. Now in the day and age of LCDs, where every > pixel is on regardless, now we're finally flipping the script and putting > light characters on dark backgrounds, long after any hardware benefit (that > I'm aware of) would be attained by minimizing the amount of "lit surface" > on the screen. > > Anyone know if this has all been coincidental or if the decision for > graphical user interfaces and such to predominantly use white/light colors > for backgrounds was a relatively intentional measure around the industry? > Or is it really just that that's how Xerox's system looked and it was all > domino effect after that? At the end of the day I'm really just finding > myself puzzling why computing jumped into the minimalism seen on terminal > screens, keeping from driving CRTs super hard but then when GUIs first > started appearing, they didn't just organically align with what was the > most efficient for a CRT. I recognize this is based largely in subjective > views of how something should look too, so not really expecting a "Person > XYZ authoritatively decided on that GUI elements shall > overwhelmingly only be dark on light", just some thoughts on how we got > going down this path with color schemes in computing. Thanks all! > > - Matt G. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Sat Jun 17 03:33:24 2023 From: coff at tuhs.org (segaloco via COFF) Date: Fri, 16 Jun 2023 17:33:24 +0000 Subject: [COFF] White Backgrounds on GUIs after Dark Backgrounds on Terminals? In-Reply-To: References: Message-ID: <3j50sQfrIaP4KY538ptQg5480Fc8VW-NLkOlqM5hOrMo3sE8orBUPg3bxKnX3LtYZBV76G4K5elmvePm-OI-L3VlIFcOy8fk9uDY0Ro5gOs=@protonmail.com> > As for the current light on dark, I wonder if this is just a new set of engineers making their mark. I'm sure it's better. The cost is the same, so now it's just marketing and a way to show off being different - e.g., new/cool. That kinda gets at the root of what I'm puzzling on too. At times where a dark color scheme would've had some, if even minor, technical benefit, it was stepped away from (as you said, Xerox is a paper company, that all makes perfect sense), however, now we're seeing the pendulum swing at a time where any amount of phosphor relief or other potential power savings from not driving visual content are lost on modern display technologies. And I'll be the first to admit the difference is probably negligible, it's not like I've done a power consumption analysis on a tube, although in this discussion it has made me curious if a noticable difference in power consumption could be measured between two tubes powered up to the same state but one has zero drawing going on (i.e. no electrons beaming to the screen) whereas the other one is on full blast bright white. I'll add it to the list of experiments for this winter... > side tidbit - he has the patent on the loadable curser - which was initially a martini glass, not an hourglass to show time I was waiting for a work conference to kick off as I was reading this email, shared this tidbit. Our resident COBOL/dinosaur era guy just remarked if programming at the time didn't drive you to drink there was something wrong with you. - Matt G. From rtomek at ceti.pl Sat Jun 17 15:28:36 2023 From: rtomek at ceti.pl (Tomasz Rola) Date: Sat, 17 Jun 2023 07:28:36 +0200 Subject: [COFF] White Backgrounds on GUIs after Dark Backgrounds on Terminals? In-Reply-To: <3j50sQfrIaP4KY538ptQg5480Fc8VW-NLkOlqM5hOrMo3sE8orBUPg3bxKnX3LtYZBV76G4K5elmvePm-OI-L3VlIFcOy8fk9uDY0Ro5gOs=@protonmail.com> References: <3j50sQfrIaP4KY538ptQg5480Fc8VW-NLkOlqM5hOrMo3sE8orBUPg3bxKnX3LtYZBV76G4K5elmvePm-OI-L3VlIFcOy8fk9uDY0Ro5gOs=@protonmail.com> Message-ID: On Fri, Jun 16, 2023 at 05:33:24PM +0000, segaloco via COFF wrote: > > As for the current light on dark, I wonder if this is just a new > set of engineers making their mark. I'm sure it's better. The cost > is the same, so now it's just marketing and a way to show off being > different - e.g., new/cool. But, there is also a benefit - we save the planet, or at least we show. And, perhaps nowadays it is fashionable to hint that one is a haxors. As of me, the first (probably) thing I do with newly installed system is go through various options and choose dark theme that pleases me. Otherwise I would be afraid of my eyes bleeding out of my head. > That kinda gets at the root of what I'm puzzling on too. At times > where a dark color scheme would've had some, if even minor, > technical benefit, it was stepped away from (as you said, Xerox is a > paper company, that all makes perfect sense), however, now we're > seeing the pendulum swing at a time where any amount of phosphor > relief or other potential power savings from not driving visual > content are lost on modern display technologies. I would blame, in no particular order, fashion, marketing propaganda, revolutionary new designs which want to be different from the interfaces of dark era of computers, troglodyte gurus banging their text into terminals versus hip guys delicately and finely soft touching their ideas into colorful whatever... In the past, I guess the reasons had more to do with economy, as Clem pointed. Closer to today, I imagine it is all about being hip and modern (as defined by the hip and the modern). > And I'll be the first to admit the difference is probably > negligible, it's not like I've done a power consumption analysis on I recall some scientists ~8 years ago were able to conclude which movie one was watching by measuring soft differences of electric power eaten by monitor (changing patterns on the display resulted in changing power consumption). So, yes, the electricity bill would be almost the same (because the differences were really small and detecting them required sensitive equipment, from what I remember). But, perhaps things can be different with OLED - I understand it shines only the pixels which are meant to shine. So, terminal emulation with OLED should make a more visible difference, but then again, leds draw so little energy that it may not really matter. > > side tidbit - he has the patent on the loadable curser - which was > > initially a martini glass, not an hourglass to show time > > I was waiting for a work conference to kick off as I was reading > this email, shared this tidbit. Our resident COBOL/dinosaur era guy > just remarked if programming at the time didn't drive you to drink > there was something wrong with you. I would like to believe times have changed. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From coff at tuhs.org Tue Jun 20 05:38:55 2023 From: coff at tuhs.org (segaloco via COFF) Date: Mon, 19 Jun 2023 19:38:55 +0000 Subject: [COFF] WECo/Bell Branded Computer Hardware Message-ID: Hello, I've got a question I'm puzzling on that someone here may have some info on. Are there any known lists/promo material/price sheets from between 80-83 regarding WECo computing hardware such as the 3B20D and 3B20S? More broadly, is it documented at all what hardware models made it out before the removal of the Bell logo and transition from WECo to AT&T ownership of the 3B and related technologies? Aside from the cover illustration of a 3B20S on the UNIX 4.1 manual and having seen a MAC-Tutor on eBay once, I can't say I've seen any other WECo branded computation hardware with Bell logos. The only photos I can find of a 3B20D are a later AT&T branded issue. Any leads? Would it have just been BellMAC stuff and 3B20 systems before the change in logo? Based on the manual I recently received, the 3B5 may have also made it out during the WECo period but after dropping the Bell logo, somewhere between the consent degree being produced and the completion of divesting WECo. - Matt G. P.S. In the bigger picture, I'm slowly starting to aggregate info together on Bell/WECo's computer hardware activities tangential to but distinct from UNIX developments. Stuff like the 3B computers, BellMAC stuff, etc. If there's already a community/resources in this focused area I'd happily divert those efforts to a more focused collective. From mparson at bl.org Wed Jun 21 02:02:33 2023 From: mparson at bl.org (Michael Parson) Date: Tue, 20 Jun 2023 11:02:33 -0500 (CDT) Subject: [COFF] Reading PDFs on a mobile. (Was: Requesting thoughts on extended regular expressions in grep.) In-Reply-To: <20230304101533.D9CCF2021A@orac.inputplus.co.uk> References: <8d1de5c8-1f34-3d37-395d-0f1da7b062ec@spamtrap.tnetconsulting.net> <20230303105928.E88AB215AA@orac.inputplus.co.uk> <20230303134215.3ED63215AA@orac.inputplus.co.uk> <21e8477c-c388-7b90-ed10-21c7f76f0892@spamtrap.tnetconsulting.net> <20230304101533.D9CCF2021A@orac.inputplus.co.uk> Message-ID: <36b395af-caa2-f685-cc54-5f193cd8b1e2@bl.org> On Sat, 4 Mar 2023, Ralph Corderoy wrote: > Date: Sat, 4 Mar 2023 04:15:33 > From: Ralph Corderoy > To: coff at tuhs.org > Subject: [COFF] Reading PDFs on a mobile. (Was: Requesting thoughts on > extended regular expressions in grep.) > > Hi, > > Grant wrote: >> Even inventorying and keeping track of the books can be time >> consuming. -- Thankfully I took some time to do exactly that and have >> access to that information on the super computer in my pocket. > > I seek recommendations for an Android app to comfortably read PDFs on > a mobile phone's screen. They were intended to be printed as a book. > In particular, once I've zoomed and panned to get the interesting part > of a page as large as possible, swiping between pages should persist > that view. An extra point for allowing odd and even pages to use > different panning. Sorry for responding to an old thread got behind on my list-mail reading, but I wanted to share my $.02. Someone else mentioned an e-book reader app, and I second that, mostly...Moon+ Reader on Android is the e-book reader I've been using for a while and it does a good job with standard e-book formats as well as PDF files, IF the PDF is a PDF of formatted text. It even has a mode where it will do a pretty decent job of on-the-fly converting/reformatting the text of the PDF to something that can actually be read on a small (phone) screen. However, if the PDF is just a bunch of 1 image per page wrapped in a PDF container, you're out of luck and back to zoom/pan around the page. For most of my digtal book reading these days, I use a Boox e-ink reader. It runs Android, so, I can use the same e-book reader I used on my phone. It can even sync where you're at in the book/document via dropbox and you can move between multiple devices if needed. If I want to mark-up the PDF, the built-in stuff on the Boox handles that nicely. If I'm on my phone, I use an app called Xodo. -- Michael Parson Pflugerville, TX From rtomek at ceti.pl Wed Jun 21 07:26:53 2023 From: rtomek at ceti.pl (Tomasz Rola) Date: Tue, 20 Jun 2023 23:26:53 +0200 Subject: [COFF] Reading PDFs on a mobile. (Was: Requesting thoughts on extended regular expressions in grep.) In-Reply-To: <36b395af-caa2-f685-cc54-5f193cd8b1e2@bl.org> References: <8d1de5c8-1f34-3d37-395d-0f1da7b062ec@spamtrap.tnetconsulting.net> <20230303105928.E88AB215AA@orac.inputplus.co.uk> <20230303134215.3ED63215AA@orac.inputplus.co.uk> <21e8477c-c388-7b90-ed10-21c7f76f0892@spamtrap.tnetconsulting.net> <20230304101533.D9CCF2021A@orac.inputplus.co.uk> <36b395af-caa2-f685-cc54-5f193cd8b1e2@bl.org> Message-ID: On Tue, Jun 20, 2023 at 11:02:33AM -0500, Michael Parson wrote: > On Sat, 4 Mar 2023, Ralph Corderoy wrote: > > > Date: Sat, 4 Mar 2023 04:15:33 > > From: Ralph Corderoy > > To: coff at tuhs.org > > Subject: [COFF] Reading PDFs on a mobile. (Was: Requesting thoughts on > > extended regular expressions in grep.) > > > > Hi, > > > > Grant wrote: > > > Even inventorying and keeping track of the books can be time > > > consuming. -- Thankfully I took some time to do exactly that and have > > > access to that information on the super computer in my pocket. > > > > I seek recommendations for an Android app to comfortably read PDFs on > > a mobile phone's screen. They were intended to be printed as a book. > > In particular, once I've zoomed and panned to get the interesting part > > of a page as large as possible, swiping between pages should persist > > that view. An extra point for allowing odd and even pages to use > > different panning. > > Sorry for responding to an old thread got behind on my list-mail > reading, but I wanted to share my $.02. > > Someone else mentioned an e-book reader app, and I second that, > mostly...Moon+ Reader on Android is the e-book reader I've been using > for a while and it does a good job with standard e-book formats > as well as PDF files, IF the PDF is a PDF of formatted text. It > even has a mode where it will do a pretty decent job of on-the-fly > converting/reformatting the text of the PDF to something that can > actually be read on a small (phone) screen. However, if the PDF is just > a bunch of 1 image per page wrapped in a PDF container, you're out of > luck and back to zoom/pan around the page. > > For most of my digtal book reading these days, I use a Boox e-ink > reader. It runs Android, so, I can use the same e-book reader I used > on my phone. It can even sync where you're at in the book/document via > dropbox and you can move between multiple devices if needed. > > If I want to mark-up the PDF, the built-in stuff on the Boox handles > that nicely. If I'm on my phone, I use an app called Xodo. > > -- > Michael Parson > Pflugerville, TX Hello Michael, I am not challenging your choices (to each his/her own), but to add some alternative, my own preferences go toward: a. have sd card slot in a reader (I mean hardware with e-ink, not some app on a phone). This means a card can be slipped into the box without opening it. This means the box is not water-proof. However, I had a look inside and I suspect it can still be water-prooved with duct tape, if someone wants it so much. b. so far I was rather happy with Linux custom made by manufacturer, but not an Android - I am yet to try Android based ebook reader (but maybe not too fast). Phones with A* are rather lousy at keeping their batteries loaded, I wonder how eink devices fare - do they, too, need to be recharged every day? My reader is recharged every 2-3 weeks, when batt drops to about 70%, while I keep using it at least every second day for few hours at a time. I had once (many years go, when I was to buy my first reader) a dream of browsing web pages with it. However, built in browser in non-A* reader proved to be lousy, equally lousy to browser in A* phones that I have tried. So, my current ereader was never connected to the net because I see no point. Of course each model nowadays comes with wi-fi, it just does not add anything useful so no need to even configure it on home router etc. Nowadays, I would rather convert whatever to pdf or epub and upload to the reader. Reading wikipedia pages printed to pdf saved me plenty of grief, as opposed to trying them in a (builtin) browser. I suspect elinks could look much better, but trying this requires some free time (compiling/porting, uploading). As a side note, I have observed that some pdfs do not render too well on my reader - it seems that they make this software "too new" to be solid & fast nowadays. Same pdfs converted to djvu read like a dream, however. Having more than few supported book formats is nice. My reader also comes with BT, possibly meant to connect headphones but perhaps usable for BT keyboard. Might be a thing to try in a future (or not), I mention it to let others know there may be such an option in case they care about it (I really do not, but I do not make those things so what can I do...). HTH -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola at bigfoot.com ** From mparson at bl.org Fri Jun 23 01:45:43 2023 From: mparson at bl.org (Michael Parson) Date: Thu, 22 Jun 2023 10:45:43 -0500 (CDT) Subject: [COFF] Reading PDFs on a mobile. (Was: Requesting thoughts on extended regular expressions in grep.) In-Reply-To: References: <8d1de5c8-1f34-3d37-395d-0f1da7b062ec@spamtrap.tnetconsulting.net> <20230303105928.E88AB215AA@orac.inputplus.co.uk> <20230303134215.3ED63215AA@orac.inputplus.co.uk> <21e8477c-c388-7b90-ed10-21c7f76f0892@spamtrap.tnetconsulting.net> <20230304101533.D9CCF2021A@orac.inputplus.co.uk> <36b395af-caa2-f685-cc54-5f193cd8b1e2@bl.org> Message-ID: <4dcc6c-4689-3fd6-5438-c8c4bba7f0f6@bl.org> On Tue, 20 Jun 2023, Tomasz Rola wrote: > On Tue, Jun 20, 2023 at 11:02:33AM -0500, Michael Parson wrote: >> Sorry for responding to an old thread got behind on my list-mail >> reading, but I wanted to share my $.02. >> >> Someone else mentioned an e-book reader app, and I second that, >> mostly...Moon+ Reader on Android is the e-book reader I've been using >> for a while and it does a good job with standard e-book formats >> as well as PDF files, IF the PDF is a PDF of formatted text. It >> even has a mode where it will do a pretty decent job of on-the-fly >> converting/reformatting the text of the PDF to something that can >> actually be read on a small (phone) screen. However, if the PDF is just >> a bunch of 1 image per page wrapped in a PDF container, you're out of >> luck and back to zoom/pan around the page. >> >> For most of my digtal book reading these days, I use a Boox e-ink >> reader. It runs Android, so, I can use the same e-book reader I used >> on my phone. It can even sync where you're at in the book/document via >> dropbox and you can move between multiple devices if needed. >> >> If I want to mark-up the PDF, the built-in stuff on the Boox handles >> that nicely. If I'm on my phone, I use an app called Xodo. >> > Hello Michael, > > I am not challenging your choices (to each his/her own), but to add > some alternative, my own preferences go toward: > > a. have sd card slot in a reader (I mean hardware with e-ink, not some > app on a phone). This means a card can be slipped into the box without > opening it. This means the box is not water-proof. However, I had a > look inside and I suspect it can still be water-prooved with duct > tape, if someone wants it so much. (For the record, the "device" I'm discussing is my Boox Nova Air 7.8" E Ink tablet, Amazon product B09FQ14Z6N.) What are you wanting/needing an SD card for? Extra storage? File-transfer? For what I use this device for, the built-in storage (32GB) has been more than enough to hold the books & notes I need it to. For file transfer, the USB Type-C port on it goes both ways, you can connect it to a computer and move files that way, or you can get a Type-C SD card reader. Plus there's wifi for network transfers. I store my e-books in Calibre on my Linux desktop, which has a web-server that the software on the device knows how to talk to, or I can connect the device and my Linux box together over USB and Calibre recognizes it as an e-reader device and can push/pull books via its interface. This device does not advertise any water-proofing at all. > b. so far I was rather happy with Linux custom made by manufacturer, > but not an Android - I am yet to try Android based ebook reader (but > maybe not too fast). Phones with A* are rather lousy at keeping their > batteries loaded, I wonder how eink devices fare - do they, too, need > to be recharged every day? My reader is recharged every 2-3 weeks, > when batt drops to about 70%, while I keep using it at least every > second day for few hours at a time. Out of the box, this device has very aggressive power-saving modes. If the screen is left off for more than something like 10 minutes, it would do a full shutdown, which means the next time you hit the power button, it does a full boot. To be fair, it boots much faster than my phone, about 15 seconds from hitting the power button to asking me to unlock the screen. Default settings also turn off the wifi & bluetooth when the screen is off. In this mode, yeah, it will last a few weeks. I disabled the shutdown bits, I want to have that "instant on" experience. Well, as instant as things get with E-Ink. From what I've noticed, the biggest battery drain seems to be if I use the backlight or not. I mostly don't, but it's there when other light isn't available. With my usage patterns and device settings, I probably charge it up to full once or twice a week, but that's plugging it in when it gets to about 50% battery. If I left the wifi off, I could probably extend it even more. To be completely honest, I've not worried too much about how long things keep a charge, as long as it can stay charged long enough for me to use it for what I want to do with it. I have lots of USB chargers spread around my house, which means that I can tend to have something charging and still be nearby. The exception to this is my watch. I have a Fossil Hybrid smart-watch. It's an analog watch with an e-ink background that can show me alerts/info from my phone. It only needs to be charged about once every 10 days or so. I don't want a watch that I'd have to recharge daily. > I had once (many years go, when I was to buy my first reader) a > dream of browsing web pages with it. However, built in browser in > non-A* reader proved to be lousy, equally lousy to browser in A* > phones that I have tried. So, my current ereader was never connected > to the net because I see no point. Of course each model nowadays > comes with wi-fi, it just does not add anything useful so no need > to even configure it on home router etc. Nowadays, I would rather > convert whatever to pdf or epub and upload to the reader. Reading > wikipedia pages printed to pdf saved me plenty of grief, as opposed to > trying them in a (builtin) browser. I suspect elinks could look much > better, but trying this requires some free time (compiling/porting, > uploading). I don't do a lot of web browsing on the device, but when I do, it's using firefox, not the vendor-provided browser. I'm all-in on the FF ecosystem, have an FF account, all my systems have their browsers logged into my FF account, I can send tabs between devices/desktops/laptops easily, etc. I'm sure the same can be done with Chrome. Firefox on Android also has a "Desktop site" slider that will re-render the page like a desktop browser would instead of a mobile one. This is nice on bigger screen Android devices. That being said. The latest update to the firmware on this device has added per-app E-ink refresh settings. So, for reading books in the book-reader app, I have it set on one of the higher-quality, but slower refresh modes. I read my books like books, page at a time, generally little to no scrolling. This is harder to do when browsing the web, so, I have Firefox set to the lower-quality but faster refresh mode. Yeah, there is a little ghosting after the scrolling stops, but it's more like the faint bleed-through you get when reading a newspaper. > As a side note, I have observed that some pdfs do not render too well > on my reader - it seems that they make this software "too new" to be > solid & fast nowadays. Same pdfs converted to djvu read like a dream, > however. Having more than few supported book formats is nice. I mostly only deal with epub, mobi, and PDF. The blurb on Amazon says that it handles "PDF(reflowable), PPT, EPUB, TXT, DJVU, HTML, RTF, FB2, DOC, MOBI, CHM..." > My reader also comes with BT, possibly meant to connect headphones but > perhaps usable for BT keyboard. Might be a thing to try in a future > (or not), I mention it to let others know there may be such an option > in case they care about it (I really do not, but I do not make those > things so what can I do...). Yup, this device has BT as well, since being an Android device, you can listen to MP3s, or stream from Pandora/Spotify/etc. I've never set that up on here, I have other devices that can already do that. The only BT I've hooked up is a keyboard, and that was mostly for a bit of fun. I installed an ssh-client on there and spent a few hours logged into my Linux box reading email. I still kinda want a laptop with an e-ink display. The other thing I use this device for is for hand-written notes and sketches. Writing on the screen with the stylus feels a lot like writing with a pencil on paper. I'm not an artist by any stretch, but sometimes writing things out and using boxes, circles, helps sort things out in my head, or sometimes I'll sketch things out while working on a design I eventually want to 3d print. All stuff I'd historically done in a paper notebook, but now I have similarly-sized electronic notepad where I can erase mistakes, have layers to my drawings (like photoshop/gimp/etc), zoom in/out, etc. The notepad app is also linked to my DropBox account, so when I'm done with whatever doodles/notes/sketches, I can then load them up on one of my other systems as PDFs. I've even toyed with the idea of writing letters out in long-hand in the notepad and then emailing the resulting PDFs to people, since the practice of hand-written letters has gone by the wayside, I thought this would be an entertaining way to bring that back. :) If what you're looking for is an E-reader that can also do the note-taking (Or a note-taking device that also functions as an e-reader), and not really much else, I've heard good things about the Remarkable tablets. One of the things they advertise is it being a distraction-free device, no alerts from the socials medias, emails, etc, since the device flat doesn't do those things. I've never used one, but I've seen people at my $DAYJOB say they really like theirs. I'm not saying this is the perfect device, or that it will fill the needs of anyone else. It doesn't solve every need I have either, which is why I have multiple devices (phone, this e-reader tablet, personal laptop, work laptop, personal desktop, scattered Raspberry Pis, etc). -- Michael Parson Pflugerville, TX From coff at tuhs.org Fri Jun 23 09:54:02 2023 From: coff at tuhs.org (segaloco via COFF) Date: Thu, 22 Jun 2023 23:54:02 +0000 Subject: [COFF] Marketplaces for Vintage Tech Books, Etc.? Message-ID: Good afternoon folks, I just wanted to ask if anyone is aware of online marketplaces I should be looking at in my constant scouring for historical documentation materials? Presently I've got a policy of checking eBay and Biblio pretty regularly for UNIX material, occasionally searching for a few other odds and ends subject-wise, but I'm starting to wonder if there are other avenues flying under my radar where folks might be more likely to be selling for instance 70s and 80s UNIX manuals, paper copies of old standards, hardware docs from IBM and DEC, etc. If you have any suggestions, especially those that don't require me to setup yet another account to keep track of, I'd surely appreciate it. Also consider this my way of saying if you​ have something to sell, I'll gladly consider it, although I am being pretty selective on matters of historical/research significance that are currently obscure, so sorry if I won't buy your twelfth copy of KnR C, even if it is signed! - Matt G. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Sat Jun 24 13:59:25 2023 From: coff at tuhs.org (Grant Taylor via COFF) Date: Fri, 23 Jun 2023 22:59:25 -0500 Subject: [COFF] Marketplaces for Vintage Tech Books, Etc.? In-Reply-To: References: Message-ID: <56f5e266-a008-5e69-5722-91f565c7f465@tnetconsulting.net> On 6/22/23 6:54 PM, segaloco via COFF wrote: > If you have any suggestions, especially those that don't require me to > setup yet another account to keep track of, I'd surely appreciate it. I use saved searches on the following three platforms: - eBay - Chraigslist - Mercari I usually have good luck, even on rarer things. The fact that the platform does searches daily means that I'll be notified of new things that I might not find myself. I've also heard tell of people finding a few things on Etsy, but I've not done much with it yet. Grant. . . . From ken.unix.guy at gmail.com Sun Jun 25 09:49:47 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Sat, 24 Jun 2023 19:49:47 -0400 Subject: [COFF] Marketplaces for Vintage Tech Books, Etc.? In-Reply-To: <56f5e266-a008-5e69-5722-91f565c7f465@tnetconsulting.net> References: <56f5e266-a008-5e69-5722-91f565c7f465@tnetconsulting.net> Message-ID: Grant, Thanks for the tip. I went on Mercari and picked up a couple of Unix/Linux things like a sealed 4 CD set of FreeBSD 32bit 2.2.1 and a set of old Linux Format mags. Ken On Sat, Jun 24, 2023 at 12:01 AM Grant Taylor via COFF wrote: > On 6/22/23 6:54 PM, segaloco via COFF wrote: > > If you have any suggestions, especially those that don't require me to > > setup yet another account to keep track of, I'd surely appreciate it. > > I use saved searches on the following three platforms: > > - eBay > - Chraigslist > - Mercari > > I usually have good luck, even on rarer things. > > The fact that the platform does searches daily means that I'll be > notified of new things that I might not find myself. > > I've also heard tell of people finding a few things on Etsy, but I've > not done much with it yet. > > > > Grant. . . . > -- End of line JOB TERMINATED -->> Okey Dokey, OK Boss -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Tue Jun 27 07:29:45 2023 From: coff at tuhs.org (Grant Taylor via COFF) Date: Mon, 26 Jun 2023 16:29:45 -0500 Subject: [COFF] Marketplaces for Vintage Tech Books, Etc.? In-Reply-To: References: <56f5e266-a008-5e69-5722-91f565c7f465@tnetconsulting.net> Message-ID: <0c5f8795-40ca-df6f-b4ac-d96f966954d1@tnetconsulting.net> On 6/24/23 6:49 PM, KenUnix wrote: > Thanks for the tip. You're welcome. > I went on Mercari and picked up a couple of Unix/Linux things like a > sealed 4 CD set of FreeBSD 32bit 2.2.1 and a set of old Linux z > Format mags. Cool! I'm glad that you found them to be useful. Grant. . . . From bill at CORCORAN.LIFE Tue Jun 27 08:37:17 2023 From: bill at CORCORAN.LIFE (William Corcoran) Date: Mon, 26 Jun 2023 22:37:17 +0000 Subject: [COFF] Esix SVR4 Message-ID: <9CAA682C-1E4A-48C2-9689-385EC9224D1E@corcoran.life> Hi Emanuel, I believe I may have the install disks for ESIX, SVR4. It actually was distributed in this beautiful box with over 100 5.25” floppy disks. As things progressed, ESIX was distributed on a streaming tape cartridge. That was so much faster than swapping floppy disks for the install. The nice thing about the ESIX SVR4 was the documentation. It was essentially the AT&T SVR4 books with a white ESIX cover slapped on it. If you want to copy the disks and make them accessible to our UNIX community, let me know. Since it’s part of my collection I would ask that you return them to me. Send me an email directly if you’re interested and I will see if I can locate them for you. Bill Corcoran > On Jun 11, 2023, at 8:47 AM, emanuel stiebler wrote: > Hi, > anybody still has the install media for that? > We used it in the office long ago, but I lost the install disk in my last moving :( > > THANKS! From sjenkin at canb.auug.org.au Tue Jun 27 09:09:36 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Tue, 27 Jun 2023 09:09:36 +1000 Subject: [COFF] Shell script advice: using 'dd' to write multiple media Message-ID: Apropos the ESIX SVR4 distro on floppies or streaming tape mentioned by Bill Corcoran In the mid 1980’s I worked for a small Australian outfit that did “Unix”. One of the things we did was distributing software, which required writing to many media. There was a very clever script that broke the distribution into many parts, if needed, to suit the size of the distribution media. [ tape, 3.5” floppy, 2.5” floppy, etc ] Over the years I’ve tried to recreate a version and not succeeded :( There was a ‘create the distro’ step of the pipeline which gathered the input, followed by a loop that used ‘dd’ to block the stream into media-sized parts. I’ve never figured out how to use ‘dd’ so it returns after a single block is written doesn’t close the input, killing the pipeline, or cause the rest of the data to be discarded. The script let our admin staff reliably create distros on whatever media was requested. Any suggestions or hints? I’m thinking this is obvious, but in the man pages i’ve read, not found an answer. It could be modern versions of ‘dd’ don’t have this behaviour. cheers steve -- 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 dave at horsfall.org Tue Jun 27 09:21:39 2023 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 27 Jun 2023 09:21:39 +1000 (EST) Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023, steve jenkin wrote: > In the mid 1980’s I worked for a small Australian outfit that did > “Unix”. Neology? Softway? > One of the things we did was distributing software, which required > writing to many media. [...] > There was a ‘create the distro’ step of the pipeline which gathered the > input, followed by a loop that used ‘dd’ to block the stream into > media-sized parts. Sounds like you want to put "dd" into a loop, driven by the block size and the media size, then using the "iseek" option on the input file to burrow through it. I would use "expr" for the arithmetic because I've never bothered to learn the Bash syntax :-) Or have I missed something? -- Dave From clemc at ccc.com Tue Jun 27 09:32:37 2023 From: clemc at ccc.com (Clem Cole) Date: Mon, 26 Jun 2023 19:32:37 -0400 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: References: Message-ID: On Mon, Jun 26, 2023 at 7:09 PM steve jenkin wrote: > > > I’ve never figured out how to use ‘dd’ so it returns after a single block > is written > doesn’t close the input, killing the pipeline, or cause the rest of the > data > to be discarded. > The trick here is understanding how ibs & obs, EOF is handled and probably osync, then how to use iseek (iskip in modern versions). It's not that hard. Its been done many times. One of the more interesting issues with dd is most versions still are single threaded which sucks for most media - particularly f you want to stream things. There was a wonderful hack to dd done in the. early 1980s by Tapani Lindgren ddd - double dd - which used two processes and a pipe to control them, so one process was always reading while the other was writing. You can one it Volume 14, issue 85 in the comp.sources.unix archives. Years ago, I hacked up a version using threads to do the same thing with a mutex to protect everything (It ever ran on Windows at some point). ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjenkin at canb.auug.org.au Tue Jun 27 09:44:04 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Tue, 27 Jun 2023 09:44:04 +1000 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: References: Message-ID: Dave, I’ve tried doing the ‘dd’ in a for or while loop many ways, many times. Perhaps you could write & yesy a little demo script for me. Say, “ls -1 | for (); do dd bs=10b; done” cheers steve > On 27 Jun 2023, at 09:21, Dave Horsfall wrote: > > Sounds like you want to put "dd" into a loop, driven by the block size and > the media size, then using the "iseek" option on the input file to burrow > through it. > > I would use "expr" for the arithmetic because I've never bothered to > learn the Bash syntax :-) > > Or have I missed something? > > -- Dave -- 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 bakul at iitbombay.org Tue Jun 27 09:44:07 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Mon, 26 Jun 2023 16:44:07 -0700 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: References: Message-ID: <950C04A3-3D30-48ED-B956-74EDB7C910E3@iitbombay.org> On Jun 26, 2023, at 4:09 PM, steve jenkin wrote: > > There was a ‘create the distro’ step of the pipeline which gathered the input, > followed by a loop that used ‘dd’ to block the stream into media-sized parts. If space is not an issue, you can use split(1) to divide the input in N pieces and then use a separate loop to copy them to the media. If you want to stream the distribution on stdin but still copy to N disks or whatever, you can write a simple C program that will prompt the user to switch media, print out checksum etc. If you want to *not* split files across media (and no file is greater than media size), you can use makekit from Rich Salz's cshar (comp.sources.unix Volume 15). From coff at tuhs.org Tue Jun 27 10:25:10 2023 From: coff at tuhs.org (segaloco via COFF) Date: Tue, 27 Jun 2023 00:25:10 +0000 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: References: Message-ID: > There was a ‘create the distro’ step of the pipeline which gathered the input, > followed by a loop that used ‘dd’ to block the stream into media-sized parts. If you were taking a stream and breaking it up arbitrarily with dd, does that imply that filesystem data defining the contents were isolated to the first volume (or however many it took to describe the contents)? Or is there something you could do with dd in that circumstance to amount to more than just bytes in bytes out to prop up a filesystem superblock on each individual volume? Granted, I don't have a lot of experience in this area, so I could be comparing apples to your oranges for all I know. - Matt G. From sjenkin at canb.auug.org.au Tue Jun 27 13:47:22 2023 From: sjenkin at canb.auug.org.au (Steve Jenkin) Date: Tue, 27 Jun 2023 13:47:22 +1000 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: <950C04A3-3D30-48ED-B956-74EDB7C910E3@iitbombay.org> References: <950C04A3-3D30-48ED-B956-74EDB7C910E3@iitbombay.org> Message-ID: <5C26BE4B-2E6C-4E02-9536-3EA774FB6B47@canb.auug.org.au> > On 27 Jun 2023, at 09:44, Bakul Shah wrote: > > f space is not an issue, you can use split(1) to divide > the input in N pieces and then use a separate loop to copy > them to the media. If you want to stream the distribution > on stdin but still copy to N disks or whatever, you can > write a simple C program that will prompt the user to switch > media, print out checksum etc. If you want to *not* split > files across media (and no file is greater than media size), > you can use makekit from Rich Salz's cshar (comp.sources.unix > Volume 15). Bakul, Thanks for the note. I’d not heard of “makeit” before, will go hunt it down. 1. this was the 1980’s, space was always an issue :) 2. There are many cases where you’ve only got a stream. This distributions were the first time I hit this problem type. 3. The distributions were a compressed tar or cpio of a directory structure, to be exploded at destination. There wasn’t a need to fit files onto media. cheers steve j -- 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 sjenkin at canb.auug.org.au Tue Jun 27 14:43:35 2023 From: sjenkin at canb.auug.org.au (Steve Jenkin) Date: Tue, 27 Jun 2023 14:43:35 +1000 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: References: Message-ID: <30A876C5-8200-401F-A207-8DA31BEAE233@canb.auug.org.au> > On 27 Jun 2023, at 09:32, Clem Cole wrote: > > The trick here is understanding how ibs & obs, EOF is handled and probably osync, then how to use iseek (iskip in modern versions). > It's not that hard. Its been done many times. > > One of the more interesting issues with dd is most versions still are single threaded which sucks for most media - particularly f you want to stream things. > There was a wonderful hack to dd done in the. early 1980s by Tapani Lindgren ddd - double dd - which used two processes and a pipe to control them, so one process was always reading while the other was writing. You can one it Volume 14, issue 85 in the comp.sources.unix archives. > > Years ago, I hacked up a version using threads to do the same thing with a mutex to protect everything (It ever ran on Windows at some point). > ᐧ Clem, Thanks very much for the note & comments. Of course, amongst the many fine things you’ve done, you’d written a proper, high-quality solution to this problem. I’d expect no less :) I take your point: ‘dd’ is a beast, very subtle with lots of options. Very good idea to use ‘osync’ to pad the last block written out to same size. [ I’ve never though to do that ] What I remember about the script is that ‘dd’ didn’t have to be told the number of media to be written. It detected ‘End of File’ on the input (pipe) and terminated the loop. It’s this action I’ve never solved. There were a few other things done in the body of the loop: writing to the operator the number of the media, to label it reading a response from /dev/tty, to allow the operator to change media eg: read -p "OK? " resp References: Message-ID: <20230627062316.858C6220E5@orac.inputplus.co.uk> Hi Steve, > I’ve never figured out how to use ‘dd’ so it returns after a single > block is written doesn’t close the input, killing the pipeline, or > cause the rest of the data to be discarded. I think this meets your description and complies with POSIX's dd(1p) here. $ seq 33 126 | sed 's/$/P/' | dc | > while :; do > LC_ALL=C dd bs=10 count=1 2>dd.err | sed -n l > grep -q '^[^0].* records in$' dd.err || break > done !"#$%&'()*$ +,-./01234$ 56789:;<=>$ ?@ABCDEFGH$ IJKLMNOPQR$ STUVWXYZ[\\$ ]^_`abcdef$ ghijklmnop$ qrstuvwxyz$ {|}~$ $ $ rm dd.err I set the locale so the format of dd's stderr report is known. -- Cheers, Ralph. From athornton at gmail.com Tue Jun 27 16:28:24 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 26 Jun 2023 23:28:24 -0700 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: <20230627062316.858C6220E5@orac.inputplus.co.uk> References: <20230627062316.858C6220E5@orac.inputplus.co.uk> Message-ID: My approach would have been to use "split" on the original file and then dd the resulting files. But now I find myself wondering how old "split" is. It was certainly already a well-established thing by the early 90s. On Mon, Jun 26, 2023 at 11:23 PM Ralph Corderoy wrote: > Hi Steve, > > > I’ve never figured out how to use ‘dd’ so it returns after a single > > block is written doesn’t close the input, killing the pipeline, or > > cause the rest of the data to be discarded. > > I think this meets your description and complies with POSIX's dd(1p) > here. > > $ seq 33 126 | sed 's/$/P/' | dc | > > while :; do > > LC_ALL=C dd bs=10 count=1 2>dd.err | sed -n l > > grep -q '^[^0].* records in$' dd.err || break > > done > !"#$%&'()*$ > +,-./01234$ > 56789:;<=>$ > ?@ABCDEFGH$ > IJKLMNOPQR$ > STUVWXYZ[\\$ > ]^_`abcdef$ > ghijklmnop$ > qrstuvwxyz$ > {|}~$ > $ > $ rm dd.err > > I set the locale so the format of dd's stderr report is known. > > -- > Cheers, Ralph. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Tue Jun 27 16:33:04 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 27 Jun 2023 07:33:04 +0100 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: References: <20230627062316.858C6220E5@orac.inputplus.co.uk> Message-ID: <20230627063304.5E1ED220E5@orac.inputplus.co.uk> Hi Adam, > My approach would have been to use "split" on the original file I think it's already been said that the input is a stream and the chunks should be written to the output media on the fly. -- Cheers, Ralph. From sjenkin at canb.auug.org.au Tue Jun 27 17:53:41 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Tue, 27 Jun 2023 17:53:41 +1000 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: <20230627062316.858C6220E5@orac.inputplus.co.uk> References: <20230627062316.858C6220E5@orac.inputplus.co.uk> Message-ID: Ralph, Nice solution: examine dd’s STDERR then ‘break’. Thanks for the test script - I like your generation of characters using ‘dc’. cheers! steve > On 27 Jun 2023, at 16:23, Ralph Corderoy wrote: > > Hi Steve, > >> I’ve never figured out how to use ‘dd’ so it returns after a single >> block is written doesn’t close the input, killing the pipeline, or >> cause the rest of the data to be discarded. > > I think this meets your description and complies with POSIX's dd(1p) > here. > > $ seq 33 126 | sed 's/$/P/' | dc | >> while :; do >> LC_ALL=C dd bs=10 count=1 2>dd.err | sed -n l >> grep -q '^[^0].* records in$' dd.err || break >> done > !"#$%&'()*$ > +,-./01234$ > 56789:;<=>$ > ?@ABCDEFGH$ > IJKLMNOPQR$ > STUVWXYZ[\\$ > ]^_`abcdef$ > ghijklmnop$ > qrstuvwxyz$ > {|}~$ > $ > $ rm dd.err > > I set the locale so the format of dd's stderr report is known. > > -- > Cheers, Ralph. -- 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 steffen at sdaoden.eu Wed Jun 28 02:07:17 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 27 Jun 2023 18:07:17 +0200 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: <20230627155001.KTa3w%steffen@sdaoden.eu> References: <950C04A3-3D30-48ED-B956-74EDB7C910E3@iitbombay.org> <5C26BE4B-2E6C-4E02-9536-3EA774FB6B47@canb.auug.org.au> <20230627155001.KTa3w%steffen@sdaoden.eu> Message-ID: <20230627160717.1ppNv%steffen@sdaoden.eu> And i'd wish the shell had "set -o pipefail" much much earlier. So you (sometimes) do things like #(set -o pipefail) >/dev/null 2>&1 && set -o pipefail es=$(exec 3>&1 1>&2; { the_worker "$cmd"; echo $? >&3; } | mytee | mymail) that are super neat (ie that this is possible syntax-wise!), but terrible and cryptical and surely error-prone to do. --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 Wed Jun 28 01:50:01 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 27 Jun 2023 17:50:01 +0200 Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: <5C26BE4B-2E6C-4E02-9536-3EA774FB6B47@canb.auug.org.au> References: <950C04A3-3D30-48ED-B956-74EDB7C910E3@iitbombay.org> <5C26BE4B-2E6C-4E02-9536-3EA774FB6B47@canb.auug.org.au> Message-ID: <20230627155001.KTa3w%steffen@sdaoden.eu> Steve Jenkin wrote in <5C26BE4B-2E6C-4E02-9536-3EA774FB6B47 at canb.auug.org.au>: |> On 27 Jun 2023, at 09:44, Bakul Shah wrote: |> f space is not an issue, you can use split(1) to divide |> the input in N pieces and then use a separate loop to copy |> them to the media. If you want to stream the distribution I had act mkdir -p "$target" act btrfs send $parent "$this" '|' \ zstd -zc -T0 $ZSTD_LEVEL '|' \ '('cd "$target" '&&' \ echo "$this" '>' .stamp '&&' \ split -a 4 -b 2000000000 -d -')' ) || exit $? for splitting BTRFS snapshots to VFAT filesystems. You then did act cat "$ball"/"$mydir"/* '|' zstd -dc '|' btrfs receive . to receive them. (Where "act" is act() { if [ -n "$DEBUG" ]; then echo eval "$@" else eval "$@" if [ $? -ne 0 ]; then echo 'PANIC: '$* exit 1 fi fi } ). I dropped that "ball" support, all my backup media now uses EXT4 or simply BTRFS directly. (Thing was that Linux cannot drive some external Seagate USB disks in a way that allows EXT4 or BTRFS on them, the "final sync" or fails, will all kernels tried, and some USB hints, too. MacOS X could create HFS?? just like that.) (That ".stamp" was if [ -f "$ball"/"$mydir"/.stamp ]; then snap=$(cat "$ball"/"$mydir"/.stamp) ... cd snapshots/"$mydir" || exit 11 if [ -d "$snap" ]; then echo '=== '$mydir': snapshot '$snap' already exists' exit 0 fi .). --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 dave at horsfall.org Wed Jun 28 07:01:18 2023 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 28 Jun 2023 07:01:18 +1000 (EST) Subject: [COFF] Shell script advice: using 'dd' to write multiple media In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023, steve jenkin wrote: > I’ve tried doing the ‘dd’ in a for or while loop many ways, many times. > > Perhaps you could write & yesy a little demo script for me. > > Say, “ls -1 | for (); do dd bs=10b; done” The problem is the pipe, of course; no Unix I know will allow a seek on a pipe (?), so it will have to be buffered somehow. I'm a bit tied up right now, so I'll take a look later. In the meantime you seem to have lots of responses... -- Dave From krewat at kilonet.net Fri Jun 30 07:29:41 2023 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 29 Jun 2023 17:29:41 -0400 Subject: [COFF] Esix SVR4 In-Reply-To: <9CAA682C-1E4A-48C2-9689-385EC9224D1E@corcoran.life> References: <9CAA682C-1E4A-48C2-9689-385EC9224D1E@corcoran.life> Message-ID: There was a Consensys SVR4.2 as well, which I have a copy of. It involved a pile of 3.5" disks, and hopefully an Adaptec 1520 ISA SCSI adapter. Or a WD compatible MFM/RLL controller. I had it running on VirtualBox once, but no network. Back in the day, I ran Consensys SVR4.2 for a three-line UUNET node. kilowatt This reminds me, I have the base install floppies, but not the entire suite. Time to get on that. ak On 6/26/2023 6:37 PM, William Corcoran wrote: > Hi Emanuel, > > I believe I may have the install disks for ESIX, SVR4. It actually was distributed in this beautiful box with over 100 5.25” floppy disks. > > As things progressed, ESIX was distributed on a streaming tape cartridge. That was so much faster than swapping floppy disks for the install. > > The nice thing about the ESIX SVR4 was the documentation. It was essentially the AT&T SVR4 books with a white ESIX cover slapped on it. > > If you want to copy the disks and make them accessible to our UNIX community, let me know. Since it’s part of my collection I would ask that you return them to me. Send me an email directly if you’re interested and I will see if I can locate them for you. > > Bill Corcoran > >> On Jun 11, 2023, at 8:47 AM, emanuel stiebler wrote: >> Hi, >> anybody still has the install media for that? >> We used it in the office long ago, but I lost the install disk in my last moving :( >> >> THANKS! From krewat at kilonet.net Fri Jun 30 08:48:21 2023 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 29 Jun 2023 18:48:21 -0400 Subject: [COFF] [JUNK] Re: Esix SVR4 In-Reply-To: References: <9CAA682C-1E4A-48C2-9689-385EC9224D1E@corcoran.life> Message-ID: Meant to say I have the base floppies *on disk **as images*, but not the entire pile. On 6/29/2023 5:29 PM, Arthur Krewat wrote: > This reminds me, I have the base install floppies, but not the entire > suite. Time to get on that. -------------- next part -------------- An HTML attachment was scrubbed... URL: