Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 09 Jan 1998 11:19:29 -0500
From:      dennis <dennis@etinc.com>
To:        Jamie Bowden <jamie@itribe.net>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: FreeBSD Netcards
Message-ID:  <3.0.32.19980109111929.00e5a310@etinc.com>

next in thread | raw e-mail | index | archive | help
At 09:29 AM 1/9/98 -0500, you wrote:
>On Fri, 9 Jan 1998, John Peter DeVale wrote:
>
>> On Fri, 9 Jan 1998, Jamie Bowden wrote:
>
>> Well, the benchmarks are not about performance as we really think of it -
>> as in faster is better.  These benchmarks are about how well the system
>> stands up to rocks beting thrown at it.  Meaning, does the system casue
>> the process to abort (ungracefully) when it should return an error code
>> and terminate the process in a controlled fashion.  In some systems, the
>> entire OS can be crashed via user code - most notably Irix 6.2 or 6.3, or
>> whatever the latest irix is.
>> 
>> Network performance isn't an issue, except since I didn't have a freeBSD
>> disc, I needed the network up to ftp the install binaries.
>> 
>> So, as far as that goes, freeBSD was, to my surprise, one of the worst
>> offenders.  Linux, on the other hand, did very well in our tests.  I have
>> given it alot of thought, and I think I know why this is.  I think that
>> the average freeBSD user is in general a more advanced computer person,
>> who knows how to operate a system, and programs well (excluding you of
>> course on the last item :) ).  Thus when her/his program aborts
>> catastrophically, they debug it, and feel stupid that they did something
>> like pass NULL to atoi (which actually causes an abort in freeBSD).  The
>> linux users, on the other hand, can't figure it out, or bitch and whine,
>> and as a result, the system call is fixed to return an error code instead
>> of an abort.  Since you have to know about these bugs to fix them, it
>> seems likely that freeBSD users/programmers just do fewer stupid things.

a couple of years ago I suggested a serious look at all this stuff, but making
'BSD unix crash proof doesn' t seem to be a major criteria.  Any system that 
panics when an invalid raw socket command is issued is in serious need of
work.

There are MANY instances where panics are used inappropriately...where
an error return or warning would keep a system from crashing.

Dennis



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19980109111929.00e5a310>