From: ron minnich <firstname.lastname@example.org>
To: Paul Winalski <email@example.com>
Cc: Steve Jenkin <firstname.lastname@example.org>, TUHS <email@example.com>
Subject: [TUHS] Re: Has this been discussed on-list? How Unix changed Software.
Date: Thu, 8 Sep 2022 08:04:07 -0700 [thread overview]
Message-ID: <CAP6exY+cpT3jU_tHVLMdSF-iEF-caxYC5r2w2Qv1i9SzmjfRtQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]
I remember a comment someone at UDEL made when we'd been working with v6
for a few years, starting in 1976. "v6 is fast as hell but it has its bugs."
It was a big deal, at least in 1976, to get through a week without a crash
of some sort. That's why we had all those pre-fsck programs for looking for
problems: icheck and ncheck existed for a reason.
The -11 also had its corners, e.g. alignment traps to snag the unwary, and
hardware that, in several cases, did not completely honor the unibus spec.
If the hardware has limits, or corners, and your kernel crashes because of
it, is it a bug that you did not accommodate the undocumented hardware
design? Given that you can't really go at your machine with a soldering
iron (well, not always; we all did some of that back then) it's arguably
Unix code was great, far better than a lot of what was out there, certainly
on the -11, but to say any of it shipped bug free certainly does not match
On Thu, Sep 8, 2022 at 7:43 AM Paul Winalski <firstname.lastname@example.org>
> On 9/7/22, Steve Jenkin <email@example.com> wrote:
> > Would your folk ship code with a list of outstanding bug reports?
> ** Everyone ** ships code with known bugs. If you insist on getting
> things perfect your code never gets out the door. At some point you
> have to decide that what you have is good enough to be released.
> The trick is to decide what constitutes "good enough". Some of it
> depends on your target application and user base. What's good enough
> for Hunt the Wumpus may well not be good enough for process control
> software for a pacemaker or nuclear reactor. And if you're producing
> software for commercial sale, marketing and business factors enter the
> mix as well.
> > I don’t think Ken & Dennis did that.
> OTOH I'm certain that they did.
> -Paul W.
[-- Attachment #2: Type: text/html, Size: 2442 bytes --]
next prev parent reply other threads:[~2022-09-08 15:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 15:07 Douglas McIlroy
2022-09-06 17:13 ` Larry McVoy
2022-09-07 1:40 ` steve jenkin
2022-09-07 2:33 ` segaloco via TUHS
2022-09-07 4:08 ` Steve Jenkin
2022-09-07 13:08 ` Steffen Nurpmeso
2022-09-07 14:56 ` Larry McVoy
2022-09-07 21:27 ` Steve Jenkin
2022-09-07 22:36 ` Larry McVoy
2022-09-08 14:42 ` Paul Winalski
2022-09-08 15:02 ` Larry McVoy
2022-09-08 15:04 ` ron minnich [this message]
2022-09-08 15:52 ` Warner Losh
2022-09-08 16:47 ` Paul Winalski
2022-09-08 16:50 ` segaloco via TUHS
2022-09-08 17:58 ` ron minnich
-- strict thread matches above, loose matches on Subject: below --
2022-09-06 19:04 Douglas McIlroy
2022-09-05 23:48 [TUHS] " steve jenkin
2022-09-06 16:09 ` [TUHS] " Marc Donner
2022-09-07 4:00 ` steve jenkin
2022-09-07 14:58 ` John Cowan
2022-09-07 17:13 ` Paul Winalski
2022-09-08 14:12 ` Paul Winalski
2022-09-07 5:15 ` steve jenkin
2022-09-07 13:20 ` Dan Cross
2022-09-07 13:52 ` Steve Nickolas
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).