> Benjamin Scott said:
>
> > On Fri, 26 Jan 2001, Jeffry Smith wrote:
> > > Hey, they never said there were any apps running!
> >
> > FWIW, we once setup an NT 4.0 SP6 server at a customer site, but due to a
> > SNAFU on their part, couldn't hook it up to the LAN for a couple weeks. All
> > it was running were the built-in file, print, DNS, DHCP, and WINS server
> > software. It crashed twice during that time. Just sitting there. (Since it
> > was hooked up to the LAN, it has been "fine" (knock on wood). Perhaps there
> > are bugs related to *lack* of demand in Windoze, too?)
That's the kind of thing that makes me wonder if the real culprit is h/w. I
started wondering about that when I attended a Red Hat seminar where some attendees
asked whether they'd fixed "stability" problems in certain areas, and other
audience members reported using the same s/w features in similar fashion without
encountering problems. It reminded me of my days developing proprietary o/s kernel
code and how often the really tough problems to debug turned out to be that the
silicon had a very very intermittent glitch (instruction decode timing interacting
with interrupt signal edginess, poor grounding or noise causing spurious
interrupts, etc.). Ben's comment about how that system's been "fine" since being
hooked up to the LAN might suggest that there's a glitch nesting in the NIC or
something similar, rather than a s/w bug.
FWIW, I've seen different o/s architectures respond differently to h/w faults, so
not crashing under Linux would not prove the h/w is clean. Incidentally, that
raises an interesting question for discussion, is it better for the o/s to be
fault-tolerant and run through problems or not? I'm ambivalent about that, I can
see arguments both ways on the question of whether if the h/w is unreliable should
it keep running?
--Bruce McCulley
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
