All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hubert Mantel <mantel@suse.de>
To: reiserfs-list@namesys.com
Subject: Re: when distros do not support official Marcelo kernels they are not being team players (was Re: reiserfs on redhat advanced server?)
Date: Wed, 5 Feb 2003 09:34:03 +0100	[thread overview]
Message-ID: <20030205083402.GA11363@suse.de> (raw)
In-Reply-To: <3E403488.9050408@namesys.com>

Hi Hans,

On Wed, Feb 05, Hans Reiser wrote:

> >>A Marcelo kernel is NOT a randomly patched kernel.  It is the OFFICIAL 
> >>kernel that the community has picked to be the official kernel.  SuSE 
> >>and RedHat should be team players, and act accordingly. 
> >
> >SuSE and Red Hat cannot use the official kernel, because it falls apart in 
> >certain scenarios and is lacking lots of features and drivers.
> >
> >All the needed fixes and features are available. I would be happy if all 
> >this stuff would be in the official kernel, so I would not need to 
> >maintain several hundreds of patches.
> >
> Has Namesys just been lucky in regards to how responsive Marcelo has 
> been for us?  In my interactions with him, he has never once 
> unreasonably rejected a patch or ignored a patch.

Every time an official kernel is released, I can see postings to this list 
asking for new versions of various patches (data-logging, quota for 
reiserfs and so on). So apparently there are users who cannot use the 
vanilla kernel but need a patched one. So this is not really different 
from the situation distributors are in.

This does not imply that Marcelo is doing a bad job. The opposite is true. 
There might be good reasons not to include every new feature into the 
official kernel (if it is only because there are more urgent things that 
get higher priority).

And the distributors really do help the development of the kernel and thus 
the whole community. Take for example the highmem-I/O feature: This is 
something that is strictly needed when you want to run Linux on some 
larger machines. We have been shipping it for about two years now and 
finally it was included in 2.4.20. I assume the fact that it has been in 
use by distributions for quite some time was proof enough that this 
feature is needed and stable, so finally it got in. I'm not sure if this 
had happened if it hadn't been used in distributions before.

Btw, same happened with reiserfs itself. If SuSE had always shipped the 
official kernel, reiserfs probably hadn't made its way into 2.4. So you 
are yourself profiting from distributors shipping patched kernels ;)

And things move on. For example we need the pte-highmem feature. In the 
official kernel ptes cannot live in highmem, which means that Oracle is 
unusable on bigger machines. On a box with way 32 GB of RAM, Oracle simply 
will run out of memory (in reality it "only" runs out of ptes, but the 
result is the same).

There are lots of similar examples.

[...]

> The ability to download the latest official stable kernel is one of the 
> great things about Linux.  There are times when the latest official 
> kernel is behind SuSE or RedHat, and there are times when it is ahead, 
> as a result of different release schedules if nothing else.

Users are always able to download the official kernel. And they are free 
to use it. The question is whether a distributor can officially support 
those kernels. Problem is that nobody is willing to pay the price for this 
service. It _IS_ expensive. As Chris pointed out, this is a great 
opportunity for independent Linux gurus who can sell this kind of service 
to people who are willing to pay for it.

But distributors really need to restrict official support to the kernel 
they ship. I'm in this business for about 10 years now and have seen so 
many cases where people have screwed their system by just recompiling the 
kernel and forgetting some important config option. This simply cannot be 
supported by the price of a CD box.

All this does not make the official kernel useless. It is a great 
reference kernel and THE major synchronisation point. It is very valuable 
for distributors to get a report of the form "I have a problem with your 
distro kernel, but the official kernel works fine", because this restricts 
the source of the problem and makes it easier to fix. And when we update 
our kernel to some new official version, every time lots of patches become 
obsolete, which is great. I'm not really eager to maintain hundreds of 
patches. If we would be able to just use the official kernel, I would be a 
very happy guy.

> It seems that what RedHat puts on its Advanced Server CD is a kernel no 
> reiserfs user would want to use if he had a choice.  What SuSE has put 

Yes, but Red Hat always has made it very clear that they are not a big 
supporter of reiserfs and prefer ext3 instead. It's their default 
filesystem and chances are high that ext3 in RH is better than in the 
standard kernel. If people really care about support they should use what 
the distributor recommends and supports.

You should realize that you (and probably most of the people on this list) 
are not representative for the people just using Linux to get their work 
done. For those people support is some kind of insurance. They are willing 
to pay money just in order to be sure somebody will solve their problems 
when they arise. They will just use what they think is best supported, so 
they should (and most of them will) use ext3 when deploying RHAS.

The sysadmin of some big bank NEVER will use some "inofficial" kernel, 
because his boss will kill him as soon as something breakes. He will not 
even use something different than the default filesystem of the product, 
because he wants to be safe. He gets paid for this.

> on its CD is at the moment probably a faster and more stable for 
> reiserfs kernel than the official kernel (I hope we will change that 
> soon, but....).  ReiserFS is just one kernel feature, and what is best 
> for users is going to vary all over the place.  Sometimes the distro 
> kernel is more advanced for some feature, sometimes the official kernel 
> is more advanced.
> 
> If we as a community fragment for the purpose of experimenting, then it 
> is healthy.  However, there needs to be one kernel branch that the 
> entire community backs up and says "we stand behind this except when we 
> are motivated by its specific flaws for the particular user in question 
> to not do so". 

This is exactly what's happening. The official kernel is the one that 
mandates the release number. It is the major synchronization point every 
distributor bases its kernel on. And the official kernel benefits from the 
work the distributors are doing.

> Maintainers need to be able to send their patches to Marcelo, and know 
> that now they can tell any Linux user of any distro to just upgrade to 
> the latest official stable kernel and case closed.

An user who has spent lots of money for his IT infrastructure WANTS an 
official kernel from the distributor. If a bug is present in the distro 
kernel but not in the official one, they will not use the official kernel, 
but demand that the fix goes into the distro kernel.

> Consider my situation with the user of the RedHat 2.4.9 based kernel, 
> because it has the advantage of not being a SuSE related problem.;-)
> 
> ReiserFS users should not use a 2.4.9 based kernel, they should use 
> 2.4.18 or later.  It is wrong that RedHat won't support him if he 
> upgrades to the official kernel.  In this case, the official kernel is 
> more advanced for his needs.  It removes one of the great advantages of 
> the open source methodology compared to proprietary OSes if he can't 
> download kernels from the net.  What should I say to him (other than 
> switch his whole distro to SuSE;-) )?

There is nothing other that you can say. If the user wants RHAS and wants
the support (hey, he is paying quite some money for it), he really should
use what the distributor recommends, tests and certifies, which is ext3 in
the case of RHAS.

> The official kernel is our kernel community's only chance to overcome 
> its fragmentation.  We need to support it.  All of us, regardless of 
> what camp we are in.   It should never be the discouraged officially 
> unsupported branch of the kernel (except when specific flaws relevant to 
> the usage of the user in question are present, and even then it should 
> be with an attitude of "the patch you need isn't yet in the official 
> kernel, try the distro kernel and things will work").
> 
> Let's all work as a team.

I think this is the case. And it works pretty well.

> Hans
                                                                  -o)
    Hubert Mantel              Goodbye, dots...                   /\\
                                                                 _\_v

  parent reply	other threads:[~2003-02-05  8:34 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-30 16:35 reiserfs on redhat advanced server? Jure Pecar
2003-01-30 17:30 ` Vitaly Fertman
2003-01-30 19:16 ` Hans Reiser
2003-01-30 22:41   ` Ragnar Kjørstad
2003-01-31 11:39     ` Hans Reiser
2003-01-31 11:53       ` Lars Marowsky-Bree
2003-01-31 12:08         ` Alexander Lyamin
2003-01-31 12:20           ` Hans Reiser
2003-01-31 12:29             ` Lars Marowsky-Bree
2003-02-01 10:09             ` Alexander Lyamin
2003-01-31 12:29           ` Yury Umanets
2003-01-31 15:22           ` Valdis.Kletnieks
2003-01-31 12:10         ` Hans Reiser
2003-01-31 12:21           ` Lars Marowsky-Bree
2003-01-31 12:35             ` Hans Reiser
2003-01-31 12:39               ` Lars Marowsky-Bree
2003-01-31 13:06                 ` Oleg Drokin
2003-01-31 13:55                   ` Chris Mason
2003-01-31 13:58                     ` Russell Coker
2003-01-31 14:14                       ` Chris Mason
2003-01-31 14:23                         ` Hans Reiser
2003-01-31 14:20                       ` Hans Reiser
2003-01-31 14:45                         ` Russell Coker
2003-01-31 14:08                     ` Oleg Drokin
2003-01-31 14:23                       ` Chris Mason
2003-01-31 16:16                         ` Brian Tinsley
2003-01-31 14:15                     ` Hans Reiser
2003-01-31 14:23                       ` Ookhoi
2003-01-31 14:37                       ` Chris Mason
2003-01-31 15:00                       ` Russell Coker
2003-01-31 15:22                         ` Chris Mason
2003-01-31 16:21                           ` Russell Coker
2003-01-31 18:03                       ` Dieter Nützel
2003-01-31 18:32                         ` Hans Reiser
2003-01-31 12:40               ` Oleg Drokin
2003-02-01 10:58                 ` Alexander Lyamin
2003-02-03 12:38               ` Juan Quintela
2003-02-03 14:20                 ` when distros do not support official Marcelo kernels they are not being team players (was Re: reiserfs on redhat advanced server?) Hans Reiser
2003-02-03 14:53                   ` Chris Mason
2003-02-03 18:51                     ` Hans Reiser
2003-02-03 19:18                       ` Valdis.Kletnieks
2003-02-03 19:38                         ` Hans Reiser
2003-02-03 19:32                       ` Chris Mason
2003-02-03 19:50                         ` Hans Reiser
2003-02-03 20:34                           ` Lars Marowsky-Bree
2003-02-04  1:55                             ` when distros do not support official Marcelo kernels they are not being team players Matthias Andree
2003-02-04  2:24                               ` Valdis.Kletnieks
2003-02-04  2:35                                 ` Brian Tinsley
2003-02-04  2:41                                   ` Chris Mason
2003-02-04  2:56                                     ` Matthew Johnson
2003-02-04  3:54                                       ` Matthias Andree
2003-02-04 16:27                                     ` Hubert Mantel
2003-02-04  4:03                                   ` Matthias Andree
2003-02-04 10:09                                     ` Hans Reiser
2003-02-04 11:17                                       ` Matthias Andree
2003-02-04  3:32                                 ` Matthias Andree
2003-02-03 20:40                           ` when distros do not support official Marcelo kernels they are not being team players (was Re: reiserfs on redhat advanced server?) Chris Mason
2003-02-04  0:46                             ` Hans Reiser
2003-02-04  2:02                               ` Chris Mason
2003-02-04  9:53                                 ` Hans Reiser
2003-02-04 13:46                                   ` when distros do not support official Marcelo kernels they are not being team players Juan Quintela
2003-02-04 16:36                               ` when distros do not support official Marcelo kernels they are not being team players (was Re: reiserfs on redhat advanced server?) Hubert Mantel
2003-02-04 20:55                                 ` Valdis.Kletnieks
2003-02-04 21:47                                   ` Hans Reiser
2003-02-04 21:45                                 ` Hans Reiser
2003-02-04 22:22                                   ` Chris Mason
2003-02-04 22:57                                     ` Hans Reiser
2003-02-06 18:06                                     ` Bernd Schubert
2003-02-05  8:34                                   ` Hubert Mantel [this message]
2003-02-05 12:04                                     ` when distros do not support official Marcelo kernels they are not being team players Juan Quintela
2003-01-31 12:35             ` reiserfs on redhat advanced server? Oleg Drokin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030205083402.GA11363@suse.de \
    --to=mantel@suse.de \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.