The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: clemc@ccc.com (Clem Cole)
Subject: [TUHS] environments/universes (was: Unix v6 problem with /tmp)
Date: Fri, 29 Jul 2016 10:14:47 -0400	[thread overview]
Message-ID: <CAC20D2Mb1=nxgGTrdWCPx-tOEqg+4XoL2scBVZmrdxFmNqMQag@mail.gmail.com> (raw)
In-Reply-To: <201607290305.u6T355aq009962@freefriends.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]

On Thu, Jul 28, 2016 at 11:05 PM, <arnold at skeeve.com> wrote:

> DMR visited one time
> and spoke; I remember him saying that he thought what Pyramid had done
> was an awful idea... :-)
>

​He was right technically/theoretically, but wrong in practice for economic
reasons.

​
Yes, I remember talking to him about the idea at dinner at a USENIX.
​  And I understood and agree the crude and somewhat confusing nature of
the solution.

​T​
he basic argument behind them was practicality of porting code from the
different flavors
​ (much less being "finger ROM" compatible for users like me)​
.  At this time System III/V and BSD were very much on divergent paths.
Larger firms like DEC and HP-UX took a stand being either BSD or System V
flavored (Sun started one way, sold there soul, then started to add all the
BSD stuff back into SVR4).
​AT&T was making such a ruckus about "Consider it Standard" - but remember
dmr never used ISV code, he wrote his own.

So the problem was that s
maller firms like Masscomp, P
​yra​
​
mid
​, Sequent did not have the leverage that HP, IBM or DEC thought they had
with the ISVs​ (they did originally but time would change as Alpha/Tru64
proved).   Being technically correct was not "good enough" - being
economically for the ISVs and End users was important.  Universes brought
the price of porting code way down, because it allowed the AT&T "standard"
or sort of be true, but still allowing a smaller firm to how their
own extensions/differentiation and provide the "comforts" of BSD.

In the end, it did not matter to the ISVs and why the UNIX "systems"
vendors eventually failed.  It was all about volume and the left UNIX for
Winders when that that system could support their codes and became more
economical.    I remember having the conversation with one of the DEC EVPs
explaining why even the Digitial Equipment Corp could not keep the ISVs on
Alpha/Tru64.  Being only technically correct/great was not a recipe for
financial success of a firm.

​Anyway, he's not here to defend his technical position, but I do think dmr
understood why it was the way it was.​  As you said, he did not like it.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160729/b017dc70/attachment.html>


  reply	other threads:[~2016-07-29 14:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27 20:28 [TUHS] Unix v6 problem with /tmp Mark Longridge
2016-07-27 20:31 ` William Pechter
2016-07-27 20:57   ` Clem Cole
2016-07-27 21:01     ` Clem Cole
2016-07-27 21:10     ` William Pechter
2016-07-28  0:49       ` Clem cole
2016-07-28  1:03         ` William Pechter
2016-07-28 11:23           ` [TUHS] History repeating itself (was: Unix v6 problem with /tmp) Michael Kjörling
2016-07-28 12:18             ` Tony Finch
2016-07-28 13:57             ` John Cowan
2016-07-30  7:56               ` Greg 'groggy' Lehey
2016-07-30 11:41                 ` William Cheswick
2016-07-30 23:28                   ` Greg 'groggy' Lehey
2016-07-30 23:50                     ` scj
2016-08-01 11:36                   ` Tony Finch
2016-07-30 14:15                 ` John Cowan
2016-07-30 15:30                   ` [TUHS] History repeating itself Michael Kjörling
2016-07-28  1:03       ` [TUHS] Unix v6 problem with /tmp Clem cole
2016-07-28 23:16     ` [TUHS] environments/universes (was: Unix v6 problem with /tmp) Sven Mascheck
2016-07-29  3:05       ` arnold
2016-07-29 14:14         ` Clem Cole [this message]
2016-07-29 13:55       ` Clem Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2Mb1=nxgGTrdWCPx-tOEqg+4XoL2scBVZmrdxFmNqMQag@mail.gmail.com' \
    --to=clemc@ccc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).