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