-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 26 September 2002 22:17, you wrote: > 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 ;-)
I think you have a very problematic undestanding of what a troll is. I was stating my opinions. If you think > > > 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. Wrong. That is probably why MS windows is better on i386 than Linux right ?!? Every evidence shows that open source systems which are portable can certainly compete with the "native" operating system and sometimes out do them. This will much lower source size and much better in code architecture. > > > 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? You are kidding me right ? Most BSDs are MORE portable than Linux. These NetBSD supports 39 architectures (and this is architectures supported INSIDE their source tree - I don't know how many more are supported outside). > > > 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. Redhat didn't fork. They applied patches. Note the difference. So did Apple. They did not continue development of their tree (Are YOU trolling ?!?). > > > 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? You obviously haven't been in the open source scene for long. In these types of discussions WITHIN the Linux community commercial means a distribution which makes money off of Linux compared to the community which doesnt make moeny. Open source here denotes the community. > > > 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. Again, see comment above. > > > 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. You say exactly what I did but claim by point is flawed. Are you trolling again ? > > > 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? Nothing. Just stating a fact. > > > 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? YES IT DID. What in "worked much better" didn't you understand ? > > 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. I did not , at any point, claim that EVERY vanilla is better than ANY redhat. If you do not understand that this debate is statistical please stay out of it. > > > 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. A lot of work has already been done in this direction (the linux hardware database being the most notable). There will surely be more. The easiest thing to do is state the problems. Go code something. > > > 9. If they fix them it means that they know HOW to fix them!!! > > Are you suggesting they don't? I didn't suggest they don't. I suggest that it's problematic. Please read to the end before you criticize. > > > 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? Do you want me to get mad ?!? that's why there are -pre and -ac. They are tested!!! > > > 10. What (9) means > > IMHO, it doesn't. No offence meant. Yesterday you deliberately changed what I stated in a quote. I was especially agitated by it. don't do it again. > > I am out of troll grub (pun intended). Me too. Mark. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9k2p0xlxDIcceXTgRAsGmAKCpGMe0WrSHSqOvFgRZS8X1NxPj1QCfbhZL 6A5IpdeI3SP7cm+f1c4C734= =go9s -----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]
