[TUHS] INed/Rand Editor/Ned [was Re: My EuroBSDcon talk (preview for commentary)

[G. Branden Robinson]

At 2019-09-17T08:33:29+1000, George Michaelson wrote:
> On Tue, Sep 17, 2019 at 6:47 AM Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > Since we like debating the merits of old technology, somebody can kick off
> > a termcap versus terminfo discussion :-)
> >
> 
> Felt like of-its-time NIH.

I certainly would not defend USG on those grounds.  Many poor decisions
seem to have been taken in the name of attempting to gain a commercial
advantage, or of an effort to present the industry with a fait accompli
that you just HAD to go along with and therefore HAD to fork over a
license fee.

This is only my impression from reading histories and retrospectives; I
came of age just as the Unix wars were winding down and Microsoft showed
that they were the most competitive at being anti-competitive.

> Since the codes to drive an ADM5 were the same in either source, and
> since the intent was the same, it was just a giant *why* for me.

For me, the mnemonic value of the capability names is important, though
terminfo didn't leverage that advantage nearly as much as they could and
should have.  5 characters was better than 2 but still too short.  And
in many cases they just reused the termcap capability names as-is, e.g.,
'am', 'll'.

But one example is enough to point up the advantage.  By what name do
you look up the "bold" capability?  In terminfo, it's called...'bold'.

In termcap, what's your bet?  'bd'?  Nope.  'bo'?  Nope.

'md'.

> I didn't get why binary file either. If the cost of reading the
> termcap DB was a significant hit on your program, I think you just
> proved you were a robot and would be defeated by a captcha. Having to
> compile things is a drag.

This is an implementation detail that _should_ have been transparent to
the user.  No one should have needed to care what the on-disk or
in-memory representation of the terminal capability list was.

But...it was the '80s.  My guess is that encapsulation to that degree
smacked of object-orientation, possibly, and therefore was always going
to be a performance disaster, the same way no one was ever going to need
more than 640KiB or how microkernels were always going to be slow at
context-switching.

Or maybe it just came down to lazy implementation.

> It was probably a side effect of the sequence of universities and
> institutions I worked at (York, Leeds, York, UCL, CSIRO, UQ) that they
> were almost exclusively v7->32V->BSD->SunOS shops and so the emergence
> of SYSV was basically occluded to me, and so SYSV-isms (with the
> exception of RFS and the pre-gnu getopt() which leaked into UUCP
> newsgroups I read somehow).
> 
> Terminfo just didn't feel very *relevant*

Yes--what good ideas AT&T commercial Unix had, they seemed determined to
ensure people never found out about except via capture of standards
bodies followed by mandatory licensing.  To me this would explain the
reasoning behind the Sun/AT&T corrupt bargain that led to Solaris (of
which Larry has written here).  People were enthusiastic about SunOS.
Obviously the thing to do with such an enthusiastic user base is buy
access to it and force them to eat whatever you feed them.  They will
remin your thralls and sing your praises for free, because all
consumer preferences are ultimately mindless questions of fashion.

Worked brilliantly, didn't it?

It can.  If you're Steve Jobs.

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://minnie.tuhs.org/pipermail/tuhs/attachments/20190917/ba76256c/attachment.sig>