On Thu, Sep 8, 2022 at 9:05 AM ron minnich <rminnich(a)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(a)gmail.com>
wrote:
On 9/7/22, Steve Jenkin
<sjenkin(a)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.