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
your bug.

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
my recollection.



On Thu, Sep 8, 2022 at 7:43 AM Paul Winalski <paul.winalski@gmail.com>
wrote:

> On 9/7/22, Steve Jenkin <sjenkin@canb.auug.org.au> 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.
>