On Thu, 26 Sep 2002, Mark Veltzer wrote: > -----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).
Didn't the late NT/alpha and NT/MIPS share the same codebase as NT/i386? What about the late BeOS (PowerPC and i386, IIRC)? > 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). > Linux is distributed under the terms of the GPL. Everyone is free to fork, but if the forked modifications are distributed, ten so must their sources be. If those changes will have something useful, it will find its way (e.g: through vendor kernels) to the main kernel tree. > 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 > It is a bit difficult to show the QA work. So I'll give a simple example to one side-asspect of it. Below is a link to the archives of redhat's enigma-list, which is the list for public discussions of matters regarding redhat's before-latest beta. Public beta is not exactly internal QA (everything found there is something that was not found in QA) but still it saves many thing from paying costumers. > 5. Then why has RH decided to specifically QA the kernel ? You may claim, > rightly, that the kernel is the most important component. A kernel is just one of the "important component, without which a linux distro can't function" > 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. 2.4.9 was labeled as a "security fix". It also included some bug fixes, I figure. Recall that at the time of 2.4.x (for a small enough x) people were complaining about problems with vanilla kernels, and not about RH kernels. > 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. Please explain how would such a voting concider issues of different hardwares, and different usage patterns. > The "oops" kernels would > stand up like flag poles. What about those generated by hardware problems? > 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. But by the time you would have the results, development would have moved on. What if you want a relieble kernel *and* support for the latest controller? > 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 ? Redaht (and SuSE, and Mandrake, and most other distros) add some patches that Marcelo has not put in (or not yet put in). Some are experimental patches that the distro's kernel maintainer believes are worth going in, even though Marcelo believes otherwise. For instance, I find it very helpful to have the alsa patches applied. This is a feature that was accepted by distros long before linus. Dcent sound suport is something distros needed. It was less a priority forLinux and Marcelo. > 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 KERNELHACKERS 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. e. If you have to apply half the patches redhat had applied on a vanilla kernel anyway, to get some extra features you need. This will make your kernel less "stable" even if the vanilla kernel is "stable". -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir ================================================================= 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]
