-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here are my thoughts on the matter (as if anyone cares what they are...:):
1. No commercial company has EVER produced a portable kernel (a real portable
kernel - no branches like solaris or windows on alpha). This is probably due
to the patience one has to have by letting fixes in not-so-hot architectures
break things (sometimes or even by accident) in architectures which are of
importance. For instance - Linus will admit a change which will make
architecture dealing more flexible because of requirement from the alpha team
thereby forcing the i386 to flex development effort even though the 386 code
doesnt need that fine granularity (it works fine without it). NO
ADMINISTRATOR in a commercial company will EVER do that (meaning risk
breaking the code on the most used platform because of an almost non existant
number of users on a almost unknown platform). That is why commercial
comapanies never develop portable kernels. Plus the long boot time for such a
project (A company will rarely invest money in something it will only see
returns on 10 years down the line - maybe).
2. Due to (1) we now conclude that commecial companies COULD HAVE NEVER
produced a product similar to Linux in capability. The only products that are
equivalent are the BSD kernels which are open source too.
3. Nor do commercial companies able to support it on their own (Just as a
fact up till now no commercial company has forked Linux and tried to take it
into one of their developers hands - you may claim that this is due to the
fact that they think the followers will stay with Linus but when you think of
it none of them will dare do that on a TECHNICAL level).
4. Since free source produces better operating systems than commercial
companies why should we assume that open source does worse on QA ? I claim
that open source does BETTER on QA. You don't see RH doing QA on a lot of
other products (if you divide their staff by number of packages you will have
to reach a situation where every QA guy is in charge of about 50 packages).
They are not. Why ? open source is good enough. The most they do is packaging
and sometimes security fixes. Most bugs work themselves out the usual free
source way. The QA RH does is overall QA to make sure that the combinations
of products they select do not interfere one with the other. If they do QA on
a specific product then they
5. Then why has RH decided to specifically QA the kernel ? You may claim,
rightly, that the kernel is the most important component. It is also a
component which is always "running" and therefore each bug in the kernel is
much more important than in some application. You would also be right. That
is probably the reason. Plus the fact that RH has clients with hardware that
is not currently supported in the kernel and they want the kernel to support
it and therefore they add drivers which sometimes even demand deeper changes.
Once you start doing that you risk breaking something REALY important and
presto - you HAVE to have your own QA team to make sure you didn't do that.
6. The open source way of QA is totally different. Don't change anything of
importance and fix bugs all the time (that is what is being done on the
stable branch). I think that the stable branch is quite conservative in what
is accepted there (I think much more outrageous patches are accepted by the
distributions). The distributions can also have different kernel sources for
different architectures (i386,sparc etc...) which open source doesn't do (the
whole point is to have 1 source tree).
7. Now lets look at the numbers. Redhat released 2 kernels for my platform
(RH7.2). 2.4.7 and 2.4.9. The first was a total disaster. The vanilla 2.4.7
worked much better (although, it too, had it's problems). In this case RH
botched up. Even with QA. Not very good track record.
8. A simple system (which should have been in place long ago) where people
vote on the stability of kernels or an automatic system where your kernel
reports up time to some website (ONLY if you enable that explicitly ofcourse)
could be built up. The statistics that we would get should show the best
vanilla stable kernel with NO problem what so ever. The "oops" kernels would
stand up like flag poles. This type of system will provide much better
kernels than RH QA. All that a distribution would have to do is look at the
last N stable kernels and pick the best one. Presto.
9. And here is the real issue: once RH dabbles inside the kernel they are not
only making it more stable - they are also risking introducing subtle bugs.
If RH QA doesnt find anything wrong with the vanilla kernels we can sack them
all since what good are they ? the whole point of QA is to find bugs and fix
them. If QA doesn't find any bugs there is no need for them. If RH QA is
indeed working then it must find bugs. And if it doesn't fix them it is as
useless as no QA. Then it must fix them. If they fix them it means that they
know HOW to fix them!!! Very interesting. This means that these should be
very competent people. I know that RH has some very good kernel hackers
working for it but the thing is EVEN KERNEL HACKERS DISAGREE ON HOW TO FIX
STUFF. EVEN KERNEL HACKERS SUBMIT FIXES WHICH INTRODUCE BUGS WHICH ARE MUCH
MORE TERRIBLE. that's why we have the kernel development process with plenty
of eyes looking at the kernel and plenty of people testing the -pre. So
should we trust a bug fix that Alan Cox wrote which has not been reviewed by
kernel development and was integrated into the official RH kernel just
because release date of RH 8.0 is in a month ?!? Suddenly things become quite
murky in squiky clean QA land.
10. What (9) means is that RH kernels will be more stable than vanilla
kernels only if:
a. RH don't do a lot of changes.
b. the changes are not of great depth.
c. the fixes are obvious.
d. most of the fixes are for drivers.
If this is the case then indeed RH kernels could be better than vanilla. But
what these conditions actually mean is that RH is NOT FAR from vanilla. This
probably means that the vanilla version is pretty good as well!!! Funny how
life is...
Regards,
Mark.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9k02IxlxDIcceXTgRAqOLAKDTdoEjADoGG6w+Ff4ElHS6vFxR8QCeMdtZ
4dnr7Gl7kopz+d/6ZmUyf9A=
=3529
-----END PGP SIGNATURE-----
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
