Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 07 Dec 1999 20:40:27 +1100 (EST)
From:      Andrew Reilly <A.Reilly@lake.com.au>
To:        Wes Peters <wes@softweyr.com>
Cc:        freebsd-hackers@FreeBSD.ORG, Matthew Dillon <dillon@apollo.backplane.com>
Subject:   Bugs and their ubiquity (was an extended rant about PCI DMA)
Message-ID:  <XFMail.991207204027.A.Reilly@lake.com.au>
In-Reply-To: <384CBED6.FECBC219@softweyr.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Wes,

On 07-Dec-99 Wes Peters wrote:
> Andrew Reilly wrote:
>> 
>> On Sun, Dec 05, 1999 at 07:42:21PM -0700, Wes Peters wrote:
>> > Software
>> > is created by humans, and humans are fallible, therefore the
>> > software is also fallible.
>> 
>> No, that doesn't logically follow.  Just because it's possible
>> for humans to make mistakes doesn't mean that it's impossible to
>> do or make something (eventually) without mistakes.

> With the exception of TeX, *no* software is bug-free.  In my
> extensive experience, no software with the exception of TeX is free
> of serious bugs.

That's a little strong, don't you think?  I can't remember encountering
any bugs, serious or not, in any of the consumer electronics devices I
use on a day-to-day basis.  I've written a number of embedded
signal processing applications myself that do exactly what they're
supposed to, and don't ever break.  I suspect that it's probably easier
to be confident about code that does the same thing hundreds or
thousands of times a second than code that will (with good luck and
good management) never be run in anger, though.

Using the example of TeX, what do you consider is special about it?  A
happy accident?  Isn't it more likely that careful coding to a good
design, with well defined inputs and outputs, and subsequent exposure
to a great deal of peer review and testing has a little to do with it?

How are those conditions different from those faced by any of the
subsystems of FreeBSD, except perhaps by degree?

> Your belief or lack thereof doesn't change the existence of
> the bugs, it just leads YOU to be surprised when they crop up in the
> oddest ways, while I am not.

My beliefs haven't got much to do with it.  Most of my interaction with
my own software involves the belief that the subtle bugs are being
masked by the obvious bugs.  But I use the bugs that I find to teach me
about my code and the states that it can find itself in.  I leave
assertions and invariant checks behind to make sure that the eroneous
conditions don't re-occur, or re-design to accommodate them if they
represent legal states.  In my experience this beats any amount of
interactive debugger single-stepping or crash-dump analysis.

Remember: in the message that you quoted, I mentioned that the
desirable state was one where we were "surprised at a crash of any
sort", rather than "convinced by analytic proof that crashes were
impossible".  Sure, the difference between "surprised by crashes" and
"surprised by lack of crashes" is one of degree, but it's a pretty
important degree.  My personal perception is that FreeBSD is currently
much closer to the former state than the latter.

Andrew


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.991207204027.A.Reilly>