On Thu, Sep 8, 2022 at 9:05 AM ron minnich <rminnich@gmail.com> wrote:
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.

In addition, when Dennis would talk about Coherent and his evaluation of the source code, he said he used the known to him, but not widely known bugs in Unix to try to catch copying. If there was copying, those would be copied. If it was freshly implemented, there's a high likelihood that they wouldn't. His conclusion was that someone had access to a lot of knowledge about the Unix system given the fidelity of the implementation, but the lack of bugs and novel ways of doing it suggested independent implementation.

Warner
 

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.