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: <d020bc20-bf04-2776-9542-6ff1a0f61693@technologists.com>

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: <d020bc20-bf04-2776-9542-6ff1a0f61693@technologists.com>
References: <962767dd-df8f-256c-15a6-764870b70ea0@e-bbes.com>
 <d020bc20-bf04-2776-9542-6ff1a0f61693@technologists.com>
Message-ID: <bf12863b-0382-6fd3-4973-ff8481eafbab@e-bbes.com>

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: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
Message-ID: <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>

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
<https://www.quora.com/In-what-type-of-work-is-the-Fortran-programming-language-most-used-today/answer/Clem-Cole>
,  Is Fortran still alive
<https://www.quora.com/Is-Fortran-still-alive/answer/Clem-Cole>, Is Fortran
obsolete <https://www.quora.com/Is-Fortran-obsolete/answer/Clem-Cole>

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: <http://www.tuhs.org/pipermail/coff/attachments/20230612/f196aaa1/attachment-0001.htm>

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: <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
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: <http://www.tuhs.org/pipermail/coff/attachments/20230612/d972bcc2/attachment-0001.sig>

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: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <20230612225013.ru6jfhv2tmjjftxn@illithid>
Message-ID: <CAC20D2Obd0Cn07z6KumJcUDnNO6ZmXSwJGO1NB49EdHKC_Zqtw@mail.gmail.com>

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: <http://www.tuhs.org/pipermail/coff/attachments/20230612/ae1aa033/attachment-0001.htm>

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: <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
Message-ID: <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>

On 6/12/23, Clem Cole <clemc at ccc.com> 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: <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
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: <http://www.tuhs.org/pipermail/coff/attachments/20230612/d35ba3a5/attachment-0001.sig>

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: <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
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 <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?

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: <http://www.tuhs.org/pipermail/coff/attachments/20230613/86374a2f/attachment-0001.sig>

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: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <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 <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.  ;-)

Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tuhs.org/pipermail/coff/attachments/20230612/31ca21f9/attachment-0001.sig>

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: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <20230612235708.GI83871@eureka.lemis.com>
Message-ID: <CAC20D2NfOq2SPTikVny_+3LbDtZFvbYxLBQDjfYk6DGN3SzPLg@mail.gmail.com>

On Mon, Jun 12, 2023 at 7:57 PM Greg 'groggy' Lehey <grog at lemis.com> 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: <http://www.tuhs.org/pipermail/coff/attachments/20230612/099869ef/attachment-0001.htm>

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: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <20230612235708.GI83871@eureka.lemis.com>
 <20230613003035.adjty5npcpxfa6a3@illithid>
Message-ID: <CAC20D2Pp6Pso+=xtF5g76UhrqqdUJ1D_1ahS=OCuMUkP6fY2TQ@mail.gmail.com>

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: <http://www.tuhs.org/pipermail/coff/attachments/20230612/08155307/attachment-0001.htm>

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: <CAC20D2NfOq2SPTikVny_+3LbDtZFvbYxLBQDjfYk6DGN3SzPLg@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <20230612235708.GI83871@eureka.lemis.com>
 <CAC20D2NfOq2SPTikVny_+3LbDtZFvbYxLBQDjfYk6DGN3SzPLg@mail.gmail.com>
Message-ID: <B6D04E9D-B8E7-4BB4-9C45-271319AE60DF@iitbombay.org>

On Jun 12, 2023, at 8:05 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> On Mon, Jun 12, 2023 at 7:57 PM Greg 'groggy' Lehey <grog at lemis.com <mailto:grog at lemis.com>> 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 <mailto: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?

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: <http://www.tuhs.org/pipermail/coff/attachments/20230612/4c16b11a/attachment-0001.htm>

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: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
 <20230612234953.pwu7oi6hyglsaqzs@illithid>
Message-ID: <CABH=_VTv1g76MnHQpkOPXRu9WFe2Kc8qchJbAgTCMpv0bFzUrQ@mail.gmail.com>

On 6/12/23, G. Branden Robinson <g.branden.robinson at gmail.com> 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: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
 <20230612234953.pwu7oi6hyglsaqzs@illithid>
Message-ID: <CAC20D2Odpg_P6sxsb1U5_ZucAJA9x8HbecbQb-ewbHV=tdpEQg@mail.gmail.com>

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: <http://www.tuhs.org/pipermail/coff/attachments/20230613/7538bda2/attachment-0001.htm>

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: <CABH=_VTv1g76MnHQpkOPXRu9WFe2Kc8qchJbAgTCMpv0bFzUrQ@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
 <20230612234953.pwu7oi6hyglsaqzs@illithid>
 <CABH=_VTv1g76MnHQpkOPXRu9WFe2Kc8qchJbAgTCMpv0bFzUrQ@mail.gmail.com>
Message-ID: <u_dX3zKg0jmM7HQvXxjvZH3CLS9E4mHx4XgfpN3dK5c4hfXX8TJA9iqIdv-jeB_8BRfjNjCET9IGfk2fHJWOAcy2F7KkCDUSn51-GbLtkIE=@protonmail.com>

> 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: <u_dX3zKg0jmM7HQvXxjvZH3CLS9E4mHx4XgfpN3dK5c4hfXX8TJA9iqIdv-jeB_8BRfjNjCET9IGfk2fHJWOAcy2F7KkCDUSn51-GbLtkIE=@protonmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
 <20230612234953.pwu7oi6hyglsaqzs@illithid>
 <CABH=_VTv1g76MnHQpkOPXRu9WFe2Kc8qchJbAgTCMpv0bFzUrQ@mail.gmail.com>
 <u_dX3zKg0jmM7HQvXxjvZH3CLS9E4mHx4XgfpN3dK5c4hfXX8TJA9iqIdv-jeB_8BRfjNjCET9IGfk2fHJWOAcy2F7KkCDUSn51-GbLtkIE=@protonmail.com>
Message-ID: <CAC20D2Nvb0cEH0Zusfma6Hik25pNZPSU8snGGb0NoS9wfrQ2uA@mail.gmail.com>

On Tue, Jun 13, 2023 at 1:05 PM segaloco via COFF <coff at tuhs.org> 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: <http://www.tuhs.org/pipermail/coff/attachments/20230613/ecd055e1/attachment-0001.htm>

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: <CAC20D2Odpg_P6sxsb1U5_ZucAJA9x8HbecbQb-ewbHV=tdpEQg@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
 <20230612234953.pwu7oi6hyglsaqzs@illithid>
 <CAC20D2Odpg_P6sxsb1U5_ZucAJA9x8HbecbQb-ewbHV=tdpEQg@mail.gmail.com>
Message-ID: <CAEoi9W4zko=Tr_Q5fqG8e18c-PNqqZbdnTiMdhJddoHBNobQBA@mail.gmail.com>

On Tue, Jun 13, 2023 at 1:03 PM Clem Cole <clemc at ccc.com> 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.

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: <CAEoi9W4zko=Tr_Q5fqG8e18c-PNqqZbdnTiMdhJddoHBNobQBA@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
 <20230612234953.pwu7oi6hyglsaqzs@illithid>
 <CAC20D2Odpg_P6sxsb1U5_ZucAJA9x8HbecbQb-ewbHV=tdpEQg@mail.gmail.com>
 <CAEoi9W4zko=Tr_Q5fqG8e18c-PNqqZbdnTiMdhJddoHBNobQBA@mail.gmail.com>
Message-ID: <CAC20D2OH_w+RtQ6hZiABKZMtMAS_GPenp0GE6jPfXaWL1RcKRQ@mail.gmail.com>

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 <crossd at gmail.com> wrote:

> On Tue, Jun 13, 2023 at 1:03 PM Clem Cole <clemc at ccc.com> 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: <http://www.tuhs.org/pipermail/coff/attachments/20230614/acd0671a/attachment-0001.htm>

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: <CAC20D2OH_w+RtQ6hZiABKZMtMAS_GPenp0GE6jPfXaWL1RcKRQ@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
 <20230612234953.pwu7oi6hyglsaqzs@illithid>
 <CAC20D2Odpg_P6sxsb1U5_ZucAJA9x8HbecbQb-ewbHV=tdpEQg@mail.gmail.com>
 <CAEoi9W4zko=Tr_Q5fqG8e18c-PNqqZbdnTiMdhJddoHBNobQBA@mail.gmail.com>
 <CAC20D2OH_w+RtQ6hZiABKZMtMAS_GPenp0GE6jPfXaWL1RcKRQ@mail.gmail.com>
Message-ID: <CAEoi9W7BVDdS=Z=eO9YQrt1Jm6FQDudO_Jiaq5wC+dANCQkHhw@mail.gmail.com>

On Wed, Jun 14, 2023 at 11:40 AM Clem Cole <clemc at ccc.com> 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: <CAEoi9W7BVDdS=Z=eO9YQrt1Jm6FQDudO_Jiaq5wC+dANCQkHhw@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
 <20230612234953.pwu7oi6hyglsaqzs@illithid>
 <CAC20D2Odpg_P6sxsb1U5_ZucAJA9x8HbecbQb-ewbHV=tdpEQg@mail.gmail.com>
 <CAEoi9W4zko=Tr_Q5fqG8e18c-PNqqZbdnTiMdhJddoHBNobQBA@mail.gmail.com>
 <CAC20D2OH_w+RtQ6hZiABKZMtMAS_GPenp0GE6jPfXaWL1RcKRQ@mail.gmail.com>
 <CAEoi9W7BVDdS=Z=eO9YQrt1Jm6FQDudO_Jiaq5wC+dANCQkHhw@mail.gmail.com>
Message-ID: <CAP2nic1CcER0eaB2GqvcpQWv6CfFCTE-3JuecBdgYk=k9r+6eA@mail.gmail.com>

On Wed, Jun 14, 2023 at 3:14 PM Dan Cross <crossd at gmail.com> 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: <http://www.tuhs.org/pipermail/coff/attachments/20230614/8ac4ae0b/attachment-0001.htm>

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: <CAP2nic1CcER0eaB2GqvcpQWv6CfFCTE-3JuecBdgYk=k9r+6eA@mail.gmail.com>
References: <CAP6exYKUbHjLJm=PNuxtzF49NfOc3q1rpkRLeGqaPpp-=RwFTw@mail.gmail.com>
 <CAEoi9W4DJXEXfr=iMOnTQVedHzcOamPyvpWy413j3_=dXrMB1g@mail.gmail.com>
 <alpine.BSF.2.21.9999.2306130615560.16633@aneurin.horsfall.org>
 <CAC20D2PiOh-p48G83ChUYZnfHTdNXROcJsewwmbM1xnyrt4c9w@mail.gmail.com>
 <20230612213912.mywv5znz66pk3n5q@illithid>
 <CAC20D2MCf6bk9QeO3gV0FnkYmB8GV304aK8seY-tAOchEa6POA@mail.gmail.com>
 <CABH=_VQdmR8N_O1_w7LOiroeR06S_r9z3vFoVnyhp5u5pPG2Mw@mail.gmail.com>
 <20230612234953.pwu7oi6hyglsaqzs@illithid>
 <CAC20D2Odpg_P6sxsb1U5_ZucAJA9x8HbecbQb-ewbHV=tdpEQg@mail.gmail.com>
 <CAEoi9W4zko=Tr_Q5fqG8e18c-PNqqZbdnTiMdhJddoHBNobQBA@mail.gmail.com>
 <CAC20D2OH_w+RtQ6hZiABKZMtMAS_GPenp0GE6jPfXaWL1RcKRQ@mail.gmail.com>
 <CAEoi9W7BVDdS=Z=eO9YQrt1Jm6FQDudO_Jiaq5wC+dANCQkHhw@mail.gmail.com>
 <CAP2nic1CcER0eaB2GqvcpQWv6CfFCTE-3JuecBdgYk=k9r+6eA@mail.gmail.com>
Message-ID: <CAEoi9W5e2Pn2RM12VZxnwZ4OUhuF96K2Wc5oXDKbf9GZRwZsNg@mail.gmail.com>

On Thu, Jun 15, 2023 at 12:20 AM Adam Thornton <athornton at gmail.com> wrote:
> On Wed, Jun 14, 2023 at 3:14 PM Dan Cross <crossd at gmail.com> 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: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>

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 <date> 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: <http://www.tuhs.org/pipermail/coff/attachments/20230615/825c0a58/attachment-0001.htm>

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: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
References: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
Message-ID: <CANCZdfpHEv0FjOFUW6qBapp9HCoc5jU102qzZjd4x+DnukFLFQ@mail.gmail.com>

On Thu, Jun 15, 2023, 2:56 PM segaloco via COFF <coff at tuhs.org> 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 <date> 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: <http://www.tuhs.org/pipermail/coff/attachments/20230615/ea7de94e/attachment-0001.htm>

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: <CANCZdfpHEv0FjOFUW6qBapp9HCoc5jU102qzZjd4x+DnukFLFQ@mail.gmail.com>
References: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
 <CANCZdfpHEv0FjOFUW6qBapp9HCoc5jU102qzZjd4x+DnukFLFQ@mail.gmail.com>
Message-ID: <CAP2nic0LPYYvqtOx4P8NpwUfVpFb-e72t-AkT+6Uj_8yHsMJBQ@mail.gmail.com>

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 <imp at bsdimp.com> wrote:

>
>
> On Thu, Jun 15, 2023, 2:56 PM segaloco via COFF <coff at tuhs.org> 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 <date> 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: <http://www.tuhs.org/pipermail/coff/attachments/20230615/5a5cd82f/attachment-0001.htm>

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: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
References: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
Message-ID: <CABH=_VR-k2_OWtm7_oRzMK9jnq9j8aQGtmUxsu7TcycCZqRYdg@mail.gmail.com>

On 6/15/23, segaloco via COFF <coff at tuhs.org> 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: <CABH=_VR-k2_OWtm7_oRzMK9jnq9j8aQGtmUxsu7TcycCZqRYdg@mail.gmail.com>
References: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
 <CABH=_VR-k2_OWtm7_oRzMK9jnq9j8aQGtmUxsu7TcycCZqRYdg@mail.gmail.com>
Message-ID: <DT5dADkWG_tHEEmE_Y11KjHpQ5QSGwUkmKuS4eSU6YjXwQRi9IPBWXyIdrmAAmQPJGYogEI72KjbtZAOaUkEIIUGZWHs4P2mLqSj-wcaa7s=@protonmail.com>

> 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: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
References: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
Message-ID: <CAC20D2NgVdMEqyvje6nVaDU83wYoO2C3+-svyW4JWrURhLb8Gg@mail.gmail.com>

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
<https://streaklinks.com/BjB7EOaVlbWFCqrlggbSUziX/https%3A%2F%2Fspectrum.ieee.org%2Fchip-hall-of-fame-western-digital-wd1402a-uart>
 UART
<https://streaklinks.com/BjB7EOa5ed7SuU43lgrt-Chq/https%3A%2F%2Fspectrum.ieee.org%2Fchip-hall-of-fame-western-digital-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 <coff at tuhs.org> 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 <date> 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: <http://www.tuhs.org/pipermail/coff/attachments/20230616/4de3a6dc/attachment-0001.htm>

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: <CAC20D2NgVdMEqyvje6nVaDU83wYoO2C3+-svyW4JWrURhLb8Gg@mail.gmail.com>
References: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
 <CAC20D2NgVdMEqyvje6nVaDU83wYoO2C3+-svyW4JWrURhLb8Gg@mail.gmail.com>
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: <vIvtT738PyORxWFUpsDbn5Mw-22alGzJi8IgkPVXgKwhnqfRo29VZaMXLcRSeicCzARbhWjbiUDcmpOAh8uXwKKOJrbWx3SosIBZcZPaEpI=@protonmail.com>
 <CAC20D2NgVdMEqyvje6nVaDU83wYoO2C3+-svyW4JWrURhLb8Gg@mail.gmail.com>
 <3j50sQfrIaP4KY538ptQg5480Fc8VW-NLkOlqM5hOrMo3sE8orBUPg3bxKnX3LtYZBV76G4K5elmvePm-OI-L3VlIFcOy8fk9uDY0Ro5gOs=@protonmail.com>
Message-ID: <ZI1EhGx6i7hqLHw+@tau1.ceti.pl>

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: <O1LmKfy9Lew7ZdV9MRkyyt8bwjB9tGWbpoxrTkL2QgETFaNwyKufQWhFIVeCwuFcfmxvfiV5f7sm_rk8ygRZxfrCiFOES6jDDiBhQkrL0WM=@protonmail.com>

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>
 <CAEoi9W7D49pdoKXMruSLUp7QO7468FkmwL2E715Nu=DfSHWhmQ@mail.gmail.com>
 <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 <ralph at inputplus.co.uk>
> 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>
 <CAEoi9W7D49pdoKXMruSLUp7QO7468FkmwL2E715Nu=DfSHWhmQ@mail.gmail.com>
 <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: <ZJIZnWhrBQoYuJmn@tau1.ceti.pl>

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 <ralph at inputplus.co.uk>
> > 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: <ZJIZnWhrBQoYuJmn@tau1.ceti.pl>
References: <8d1de5c8-1f34-3d37-395d-0f1da7b062ec@spamtrap.tnetconsulting.net>
 <20230303105928.E88AB215AA@orac.inputplus.co.uk>
 <CAEoi9W7D49pdoKXMruSLUp7QO7468FkmwL2E715Nu=DfSHWhmQ@mail.gmail.com>
 <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> <ZJIZnWhrBQoYuJmn@tau1.ceti.pl>
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:

<snip>

>> 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: <CS_QMuWwWOOEpHRtngQ4WUDOVs_Nai6JmMTa_5f-096zDtWO5EF-FJLTSRue0_WWahJAObL-wX4ej5r_u6S-DOi0T-w0XL7ygkQ8RGpGJU0=@protonmail.com>

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: <http://www.tuhs.org/pipermail/coff/attachments/20230622/b93b2f73/attachment.htm>

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: <CS_QMuWwWOOEpHRtngQ4WUDOVs_Nai6JmMTa_5f-096zDtWO5EF-FJLTSRue0_WWahJAObL-wX4ej5r_u6S-DOi0T-w0XL7ygkQ8RGpGJU0=@protonmail.com>
References: <CS_QMuWwWOOEpHRtngQ4WUDOVs_Nai6JmMTa_5f-096zDtWO5EF-FJLTSRue0_WWahJAObL-wX4ej5r_u6S-DOi0T-w0XL7ygkQ8RGpGJU0=@protonmail.com>
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: <CS_QMuWwWOOEpHRtngQ4WUDOVs_Nai6JmMTa_5f-096zDtWO5EF-FJLTSRue0_WWahJAObL-wX4ej5r_u6S-DOi0T-w0XL7ygkQ8RGpGJU0=@protonmail.com>
 <56f5e266-a008-5e69-5722-91f565c7f465@tnetconsulting.net>
Message-ID: <CAJXSPs9Vr3f3xKjhk+-SQf-YtABaZv69yD9zrR5Caq4eFqoHOg@mail.gmail.com>

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 <coff at tuhs.org>
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: <http://www.tuhs.org/pipermail/coff/attachments/20230624/a1d4820a/attachment.htm>

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: <CAJXSPs9Vr3f3xKjhk+-SQf-YtABaZv69yD9zrR5Caq4eFqoHOg@mail.gmail.com>
References: <CS_QMuWwWOOEpHRtngQ4WUDOVs_Nai6JmMTa_5f-096zDtWO5EF-FJLTSRue0_WWahJAObL-wX4ej5r_u6S-DOi0T-w0XL7ygkQ8RGpGJU0=@protonmail.com>
 <56f5e266-a008-5e69-5722-91f565c7f465@tnetconsulting.net>
 <CAJXSPs9Vr3f3xKjhk+-SQf-YtABaZv69yD9zrR5Caq4eFqoHOg@mail.gmail.com>
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 <emu at e-bbes.com> 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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>

Apropos the ESIX SVR4 distro on floppies or streaming tape mentioned by Bill Corcoran

	<https://www.tuhs.org/mailman3/hyperkitty/list/coff at tuhs.org/message/WEJQQCJHH7BVVRGR4QNLS4AQ2OCAJRU7/>

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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
References: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
Message-ID: <alpine.BSF.2.21.9999.2306270916210.50080@aneurin.horsfall.org>

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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
References: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
Message-ID: <CAC20D2NEMStT9Fd2a4dDDxPHVwtWpz8K4Bc7Qe6U1NT_9HVt2Q@mail.gmail.com>

On Mon, Jun 26, 2023 at 7:09 PM steve jenkin <sjenkin at canb.auug.org.au>
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: <http://www.tuhs.org/pipermail/coff/attachments/20230626/0f3ecf75/attachment.htm>

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: <alpine.BSF.2.21.9999.2306270916210.50080@aneurin.horsfall.org>
References: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
 <alpine.BSF.2.21.9999.2306270916210.50080@aneurin.horsfall.org>
Message-ID: <A4FD2EBC-BF62-426E-B02C-1D37B3F0D7E4@canb.auug.org.au>

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 <dave at horsfall.org> 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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
References: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
Message-ID: <950C04A3-3D30-48ED-B956-74EDB7C910E3@iitbombay.org>

On Jun 26, 2023, at 4:09 PM, steve jenkin <sjenkin at canb.auug.org.au> 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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
References: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
Message-ID: <EXknJVcxk0KaYG8KiBGQtDSTGqr6jVut4JiG78HOi1KOWGfDAY2Oa1bF8KwvO8nFVRdcbjcxa3_1krpL3kmqIiv_MiUNR8gltbG1lIHZd34=@protonmail.com>

> 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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
 <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 <bakul at iitbombay.org> 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: <CAC20D2NEMStT9Fd2a4dDDxPHVwtWpz8K4Bc7Qe6U1NT_9HVt2Q@mail.gmail.com>
References: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
 <CAC20D2NEMStT9Fd2a4dDDxPHVwtWpz8K4Bc7Qe6U1NT_9HVt2Q@mail.gmail.com>
Message-ID: <30A876C5-8200-401F-A207-8DA31BEAE233@canb.auug.org.au>



> On 27 Jun 2023, at 09:32, Clem Cole <clemc at ccc.com> 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 </dev/tty 

I’ve constructed two examples below of splitting input into fixed blocks.
using the easiest repeatable & limited stream I thought of:
	ls -1

When I know the number of blocks, a for loop does exactly what I hope & expect.
Including the trailing short block.

But writing a ‘while’ loop with ‘dd’ as the condition - it’s an infinite loop.

Even though STDIN is exhausted and ‘dd’ knows it, read returns zero bytes,
and ‘dd' doesn’t return an error (because there’s no ‘read error’, just ’No Data').

This Mac example uses ‘bash’.

I think in 1985 it was Bourne shell, maybe Korn shell, definitely not ‘csh’.

cheers
steve

==========

iMac1:~/ steve$ ls -1 | wc -c
 1071404

iMac1:~/ steve$ ls -1 | for i in {1..108}; do dd of=/dev/null bs=10000 count=1;  done
1+0 records in
1+0 records out
10000 bytes transferred in 0.249052 secs (40152 bytes/sec)

… another 105 times

10000 bytes transferred in 0.000011 secs (911805217 bytes/sec)

0+1 records in
0+1 records out
1404 bytes transferred in 0.000007 secs (203062166 bytes/sec)

==========

iMac1:~/ steve$ ls -1 | while dd of=/dev/null bs=10000 count=1; do : ;  done	# ‘:’ is a null command within loop

1+0 records in
1+0 records out
10000 bytes transferred in 0.251171 secs (39813 bytes/sec)

… another 105 times

0+1 records in
0+1 records out
1404 bytes transferred in 0.000009 secs (154968495 bytes/sec)

0+0 records in
0+0 records out
0 bytes transferred in 0.000006 secs (0 bytes/sec)

0+0 records in
0+0 records out
0 bytes transferred in 0.000007 secs (0 bytes/sec)

… and it's an infinite loop, repeating the last group of lines :(

==========
--
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 ralph at inputplus.co.uk  Tue Jun 27 16:23:16 2023
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Tue, 27 Jun 2023 07:23:16 +0100
Subject: [COFF] Shell script advice: using 'dd' to write multiple media
In-Reply-To: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
References: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
 <20230627062316.858C6220E5@orac.inputplus.co.uk>
Message-ID: <CAP2nic33Y72qL3t=+t54tRzTwYGT4MhCz1qsg0cs5VaLg_f51Q@mail.gmail.com>

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 <ralph at inputplus.co.uk>
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: <http://www.tuhs.org/pipermail/coff/attachments/20230626/b3c8db39/attachment.htm>

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: <CAP2nic33Y72qL3t=+t54tRzTwYGT4MhCz1qsg0cs5VaLg_f51Q@mail.gmail.com>
References: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
 <20230627062316.858C6220E5@orac.inputplus.co.uk>
 <CAP2nic33Y72qL3t=+t54tRzTwYGT4MhCz1qsg0cs5VaLg_f51Q@mail.gmail.com>
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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
 <20230627062316.858C6220E5@orac.inputplus.co.uk>
Message-ID: <B0EDE921-CB6B-4517-B6D3-3831EF343AC9@canb.auug.org.au>

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 <ralph at inputplus.co.uk> 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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
 <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: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
 <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 <bakul at iitbombay.org> 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: <A4FD2EBC-BF62-426E-B02C-1D37B3F0D7E4@canb.auug.org.au>
References: <D0AEA7F2-9981-4AAF-8F52-3FCF79089394@canb.auug.org.au>
 <alpine.BSF.2.21.9999.2306270916210.50080@aneurin.horsfall.org>
 <A4FD2EBC-BF62-426E-B02C-1D37B3F0D7E4@canb.auug.org.au>
Message-ID: <alpine.BSF.2.21.9999.2306280657560.50961@aneurin.horsfall.org>

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: <efe937d5-9459-6888-8bc1-428c9ac18362@kilonet.net>

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 <emu at e-bbes.com> 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: <efe937d5-9459-6888-8bc1-428c9ac18362@kilonet.net>
References: <9CAA682C-1E4A-48C2-9689-385EC9224D1E@corcoran.life>
 <efe937d5-9459-6888-8bc1-428c9ac18362@kilonet.net>
Message-ID: <d33f044e-95ae-0f2b-bc58-1a3cff785d70@kilonet.net>

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: <http://www.tuhs.org/pipermail/coff/attachments/20230629/a2c60866/attachment.htm>