From owner-freebsd-hackers  Mon Apr 28 18:47:32 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id SAA14159
          for hackers-outgoing; Mon, 28 Apr 1997 18:47:32 -0700 (PDT)
Received: from sendero.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA14124
          for <freebsd-hackers@FreeBSD.org>; Mon, 28 Apr 1997 18:47:28 -0700 (PDT)
Received: (qmail 2907 invoked by uid 1000); 29 Apr 1997 01:40:23 -0000
Message-ID: <XFMail.970428184023.Shimon@i-Connect.Net>
X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <9222.862201539@time.cdrom.com>
Date: Mon, 28 Apr 1997 09:42:48 -0700 (PDT)
Organization: iConnect Corp.
From: Simon Shapiro <Shimon@i-Connect.Net>
To: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Subject: Re: A Desparate Plea for Help...
Cc: freebsd-hackers@FreeBSD.org, Michael Smith <msmith@atrad.adelaide.edu.au>
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk


Hi Jordan K. Hubbard;  On 28-Apr-97 you wrote: 
> > > I need to solve this problem, not to be told 9indirectly) that it
> must be
> > > my fault, as it soes not happen on someone else's machine.
> > 
> > That's not what that response means.  "I can't make it happen here"
> > means "I can't work out what is wrong because I can't reproduce the
> > problem, and I need to reproduce the problem to have all the
> > information I need to hand".
> 
> Just to chime in here (and everything that Michael says is spot-on),
> it also means: "I can't make it happen here, please reduce the
> components in this system to the _bare minimum_ of what is needed to
> still provide services."
> 
> You wouldn't believe how often this oh-so-basic rule is violated by
> someone who's got everyting up to and including the kitchen sink in
> their kernel, leaving the unfortunate developer to ask "Uhhhhh.  You
> seem to have _everything_ in here, from a sound card to multicast
> routing to a /tmp mounted over MFS - have you never heard of
> SIMPLIFYING a situation you're trying to debug?  I don't want to have
> to chase down 7 different alleys at the same time so please - nuke the
> MFS "speed hacks" and get that stupid sound card out of your NFS
> fileserver!"
> 
> I'm not saying that this is true in Simon's case, but it's still
> a damn good general rule which gets forgotten more often than
> I care to think about.

Amen!  And it does apply in Simon's case :-)  The kitchen sink is still in
the
kitchen, but most everything else is there.  I will build a simple kernel
and
try to crash that.  It will probably work... (would not crash :-)

Simon