4KSTACKS et al...

[Paul A Houle]

Dave Jones wrote:

>
>Your complaint seems to be that some bug you hit was fixed upstream,
>but not in RHEL, yet at the same time you mention that you never
>filed a RHEL bug on this.  We'll work on psychic-bug-reporting
>for RHEL5, but in the meantime, we need to know when things break
>to fix them. Whilst we watch upstream, and backport some fixes,
>with upstream committing ~4000 changes per point release, its
>not feasible to catch everything. Changes also need to be evaluated
>in terms of risk before they go into a RHEL release.
>
>  
>
    It would have taken me a great deal of time to have filed a useful 
bug report.  I had no stack trace and I can say little more about it 
than has already been said,  other than the hardware details of the 
machine.  The only cheap way that you could (possibly) resolve the 
problem for me is to send me a kernel that has more recent patches from 
upstream and hope that the problem goes away.  (Maybe that's what you do 
-- if you do,  than it might ~not~ be a waste of time for me to go 
through your process.)

    On the other hand,  my experience is that going straight to upstream 
solves problems rapidly and lets me go back to work.  Yes,  I can be an 
'altruist' and spend more of my time helping RH fix a product that costs 
$2000 per server,  or I can get the job done.

    If my quick method didn't resolve my problem then I'd have the 
choice of going to LKML with a mainstream kernel (meaning I can have an 
e-mail message read by someone who knows how to fix a race condition) or 
submitting a bug report to RH (which starts with a password reset for my 
redhat.com account,  and,  if RH is like any other vendor,  having to 
explain my problem several times to people who don't know how to fix 
race conditions.)

   I'll consider going back to an RHEL kernel if the machine in question 
has problems that I can't fix my way,  and then I'll try your process.

>We do push out interim updates for really important problems
>(typically dataloss/corruption/security issues).
>
>  
>
    That's great,  but it doesn't solve my problem.

    Anyway,  I know that these problems aren't easy,  and they are 
things that don't really fit into one box (reliability of RHEL,  Fedora 
and the Linux kernel) but I've really got a lot of concerns about 
reliability and there are days that I envy the guys in the other office 
who work with a SPARC/Solaris stack.  I've got concerns that bad things 
are going to come in the upstream kernel -- for instance,  there's a lot 
of cleanup and simplification of the network stack in 2.6.13 that will 
be nice a year from now,  but they'll probably drop something on the 
floor,  so I'll probably wait until 2.6.13.something to upgrade.

    The funny thing is that the world is increasingly believing the 
Linux is "ready for the enterprise" in a time that I'm questioning my faith.