The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Larry McVoy <lm@mcvoy.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Subject: Re: [TUHS] DEC and Dave Cutler (was Re: The John Snow's of the UNIX family)
Date: Wed, 16 Jan 2019 17:09:32 -0500	[thread overview]
Message-ID: <20190116220932.GB9343@mit.edu> (raw)
In-Reply-To: <20190116172950.GL7733@mcvoy.com>

On Wed, Jan 16, 2019 at 09:29:50AM -0800, Larry McVoy wrote:
> 
> I have a different view, having been at Sun when Sun was eating DEC's
> lunch.  Sun made stuff that was just as good as what DEC built but they
> were cheaper.  DEC couldn't adapt to decent machines that didn't cost
> a big pile.
> 
> History repeats itself, Sun couldn't wean itself off $20,000 workstations
> when you could get an almost as fast PC for 1/4th or less of that price
> point.

This is applicable in the Open Source world as well, and there it's a
much more clearly an example of the "Better is Worse", "New Jersey
Style" vs. "The MIT Approach"/"The Right Thing" debate.

Example: Linux had PCMCIA support before the *BSD variants, and even
when the BSD's had PCMCIA support, the PCMCIA card (most commonly, for
WiFi) had to be plugged when the system was booted.  Where as for
years ahead of *BSD, Linux had hot-plug PCMCIA support --- but if you
ejected the card, there was a 30-50% chance the system would crash.
(Which could be lowered if you carefully shutdown the network, and
waited until all open/pending TCP connections that couldn't be closed
had timed out, etc.)  Eventually, the *BSD's pulled ahead of Linux,
and had rock-solid PC Card support, and it took a lot longer for
Linux's hot-eject support to be fully stable.

For most users, of couse, hot-pluggable PCMCIA was way more important
than stability problems when you ejected the card, especially when it
usually worked (especially if you were careful).  And if you have more
users, you are much more likely to get bug reports, and more likely to
recruit developers (which in the open source world, are more likely to
stick around if you are willing to accept less-than-perfect patches,
as opposed to insisting that they be picture-perfect before they can
be committed).  There's a downside with this approach, of course,
which is that it may take a lot longer to get the code cleaned up
after the 1.0 "launch" of the feature.

						- Ted

      parent reply	other threads:[~2019-01-16 22:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-16 16:55 Paul Winalski
2019-01-16 17:14 ` Clem Cole
2019-01-16 17:33   ` Larry McVoy
2019-01-16 17:29 ` Larry McVoy
2019-01-16 18:13   ` Clem Cole
2019-01-16 18:24     ` Larry McVoy
2019-01-16 18:32       ` Arthur Krewat
2019-02-02 14:34       ` Finn O'Leary
2019-02-02 21:22         ` Dave Horsfall
2019-02-03 19:57         ` Cág
2019-01-16 22:09   ` Theodore Y. Ts'o [this message]

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=20190116220932.GB9343@mit.edu \
    --to=tytso@mit.edu \
    --cc=lm@mcvoy.com \
    --cc=tuhs@tuhs.org \
    /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).