NB: marked OT with respect to the actual topic of the thread. Not entirely OT for the list, I suppose.
Mark Veltzer <[EMAIL PROTECTED]> writes: .. and I will continue feeding trolls who contribute to the kernel ;-) > 1. No commercial company has EVER produced a portable kernel I would give commercial companies the benefit of the assumption that whatever they produce or distribute is portable at least to all the officially supported platforms. Now, assume RH - the vendor in question - only support x86. They would be perfectly right in favoring things beneficial to x86 even when they are detrimental to other architectures. I see nothing wrong here. > 2. Due to (1) we now conclude that commecial companies COULD HAVE NEVER > produced a product similar to Linux in capability. I don't see how you arrived at this conclusion. I'd say just the opposite is true: a vendor that focuses on a particular architecture is likely to succeed in producing a *more capable* product for that platform. > The only products that are equivalent are the BSD kernels which are > open source too. I have little experience with BSD. Please enlighten me, what other architectures besides x86 are supported? > 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). Well, apparently RH did ;-). Another example of a fork by a commercial company is BSD-related - OS X. Both are apparently successful. > 4. Since free source produces better operating systems than commercial > companies why should we assume that open source does worse on QA ? I don't understand why you are going down this road. RH are commercial *and* open source - which category do you put them in? > I claim that open source does BETTER on QA. Better than RH? They are open source, and have probably the largest user base. I'd say it is natural to assume they do *at least* as well as non-commercial open source, because in addition to the common open source QA they also pay people to do extra QA for them. > 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). This point is also flawed. It would make perfect sense to RH to specifically QA what they change. If they put an add-on package foo into the distro and do nothing to it but create an rpm, then they would probably QA the rpm, but not foo itself. I see bugs in various software I use. I don't blame RH for those bugs, and don't send them bug reports. I send reports to developers/maintainers of the software. > 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. True. What's wrong with that? > 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. Did vanilla 2.4.7 or 2.4.9 work much better for you? Unless the answer is yes, you cannot claim that it was RH who botched the job, can you? IIRC RH 7.2 never went beyond 2.4.9 because they did not quite trust the new VM at the time. Along the way they avoided the disastrous 2.4.15 (by your argument, you would assume it was better than anything RH were likely to produce and would install it), and shipped 7.3 with 2.4.18 which, by all accounts, is better than any of the previous 2.4 series. > 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. Easier said than done. You will have to set up this experiment very carefully and in a controlled environment, with no forced reboots, scheduled or otherwise, same rate of power failures, similar loads of various types. Otherwise, your statistics will be meaningless. > 9. If they fix them it means that they know HOW to fix them!!! Are you suggesting they don't? > 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 ?!? Should we trust a bug fix by Mark Veltzer that got into the -pre?-ac? tree (see subject) just because Alan Cox, who was busy at the time fixing a bug in the upcoming RH kernel, didn't see anything wrong with it at a perfunctory glance? > 10. What (9) means IMHO, it doesn't. No offence meant. I am out of troll grub (pun intended). -- Oleg Goldshmidt | [EMAIL PROTECTED] ================================================================= "... Of theoretical physics and programming, programming embodied the greater intellectual challenge." [E.W.Dijkstra, 1930 - 2002.] ================================================================= 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]
