-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 26 September 2002 21:50, you wrote:
> 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?
No they didn't. The alpha got forked off quite early. That's why MS dumped
the alpha road (it was getting a burden to fix bugs for a minority of users).
>
> What about the late BeOS (PowerPC and i386, IIRC)?
This one I don't know. My bet: Different source trees.
>
> > 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
My point was that they DONT fork. Why are they NOT forking when they can ?
This is in effect an admittion that open source hackers can do better than
they are.
.
>
> > 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.
I agree. But as you can see most are integration bugs which is what RH does.
Integration.
>
> > 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"
I agree. But it does not change my conclusions validity.
>
> > 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.
2.4.9 was a performance fix. I don't care what it was labeled. It prevented
my machine from swapping like crazy. The vanilla 2.4.7 was better than RH
2.4.7.
>
> > 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.
Do you use the linux hardware database ? This is exactly it. It may be
inaccurate. Some entries may be out of date. It may lag behind latest and
greatest. All of that said - it is better than nothing.
>
> > The "oops" kernels would
> > stand up like flag poles.
>
> What about those generated by hardware problems?
If many people vote than these would be noise. The easiest way is to say this
cannot be done. It can. And it should.
>
> > 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?
There is always a price to pay. You cannot have everything. If you want
latest (meaning - right out of the oven) then you are giving up on stable and
on having the reliability of many users who said that it works well. You can
choose. You can always get the latest from the development site but you
should have method of getting NOT latest but STABLEST in the past 6 months.
>
> > 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.
I agree that there are conflicts of interest here and that is the most
important issue. Distribution care less about the architecture of the kernel
and more for features (they are customer driven). There is a tension here.
The fact that the distributions did not fork is evidence that they think that
in the long run architecture descisions by Linus and the commnity are right.
On the other hand they are willing to put patches before "straightening out
all the wrinkles" architecture wise. That is the reason that I think that as
far as SERVER stability goes vanilla kernels are better. I have yet to see
numbers to prove otherwise and the numbers I collected from my personal
experiece prove this.
>
> > 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".
I agree.
Regards,
Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9k2YwxlxDIcceXTgRAubcAJ9fvTtcOS64r9qsxV90JpvM1oigfACeMNCJ
k3ZXxaiZhuoEYLIy9LKGFIc=
=9gyP
-----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]
