On Tue, Aug 02, 2005 at 01:10:08PM -0400, Paul A Houle wrote:
People are willing to pay $$ to get an "enterprise"
product which is
reliable, and supported, but this is another case where the generic
product turns out to be more reliable than the branded product,
This is entirely subjective. Look at the bugzilla stats for proof of this.
Open kernel bugs:
RHEL4 bugs get fixed very quickly. It being a supported product,
engineers devote time to fixing those problems. Fedora bugs have no
guarantee of being fixed in the next update, or even the next
release. A lot of Fedora bugs that get closed happen just due to
the rebasing to a newer upstream release.
Looking at the numbers month over month, Fedora bugs go up, RHEL bugs go down.
This may disappoint a lot of Fedora users, but this is the harsh reality.
A lot of the kernel bugs filed against Fedora are also bugs that
are relevant upstream. More recently, I've been pushing these bugs
to their upstream maintainers in an attempt to try and beat down
the volume. (Things were actually even worse a few months back).
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.
and looking at what's happening with Fedora, I've got a lot
of concern that
RH's pursuit of innovation will always lead to a kernel long on gee-whiz
features and short on reliability.
gee-whiz features ? Exec-shield and Tux are the only real big-ticket
items we carry these days in Fedora, and they're in RHEL too.
Fedora kernels are a lot closer to mainline than any of the RHL kernels were.
I think there are two reasons for the RHEL 4 instability: (i) the
quarterly release cycle means that I have to wait for bug fixes
We do push out interim updates for really important problems
(typically dataloss/corruption/security issues).
if you're running a non-x86 architecture, it seems like 2.6 is shaking
out bugs at a high rate,
upstream is also introducing regressions at a high rate.
After rebasing the FC3 kernel last week to 2.6.12, from 2.6.11,
~50 bugs got closed, and ~50 new ones got filed.
This pattern has been going on for the last few releases.
Some releases are worse than others, and we get more new issues
than we get closed issues.
and (ii) RH is aggressively pushing new features.
Such as ?
I really don't know what's in RHEL 4 (it would take me
more time to
look at the patches than it would to revert to mainstream)
The GA release was very close to a Fedora kernel circa FC3.
Subsequent updates have diverged.
but the activation of 4KSTACKS in Fedora is one of those changes
Funny, our evidence shows the contrary.
FC2 was plagued with VM problems that magically went away when we moved
to 4K stacks, and separate interrupt stacks. The fact is that on 32bit x86,
you never had all of that 8kb stack anyway.
I've been looking, and I've never found out what benefit
4KSTACKS has for end users.
Better reliability under load.
I start to wonder if
it's just a vindicitive attempt to put an end to ndiswrappers. (I'd
really love to see an explanation of the benefits of 4KSTACKS)
If you're using ndiswrapper, there's your problem right there.
Windows drivers expect a 12KB stack. So in certain circumstances,
you're out of luck even with 4k stacks disabled.