lkml.org 
[lkml]   [2006]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.16-rc4: known regressions
On Wed, Feb 22 2006, Greg KH wrote:
> On Wed, Feb 22, 2006 at 08:29:48PM +0100, Arjan van de Ven wrote:
> > On Wed, 2006-02-22 at 11:18 -0800, Greg KH wrote:
> > > What about trying a stock 2.6.6 or so kernel? Does that work
> > > differently from 2.6.15?
> >
> > ... however it's very much designed only for the kernel that comes with
> > it (with "it's" I mean all the userspace infrastructure); all the
> > changes and additions since 2.6.9 aren't incorporated so you probably
> > really want new alsa, new initscripts, new mkinitrd, new
> > module-init-tools. some because of abi changes since 2.6.9, others
> > because the kernel grew capabilities that are really needed for "nice"
> > behavior.
>
> I totally agree. Distros are changing into two different groups these
> days:
> - everything tied together and intregrated nicely for a specific
> kernel version, userspace tool versions, etc.
> - flexible and works with multiple kernel versions, different
> userspace tools, etc.
>
> Distros in the first category are the "enterprise" releases (RHEL, SLES,
> etc.), as well as some consumer oriented distros (SuSE, Ubuntu, Fedora
> possibly.)
>
> More flexible distros that handle different kernel versions are Gentoo,
> Debian, and probably Fedora.
>
> And this is a natural progression as people try to provide a more
> complete "solution" for users.
>
> When people to complain that they can't run a "kernel-of-the-day" on
> their "enterprise" distro, they are not realizing that that distro was
> just not developed to support that kind of thing at all.

I have to disagree somewhat violently to that statement, I'm afraid :-)
At least for me, it's pretty much a requirement that I can put eg
2.6.18-rc2 on an enterprise install. It's a must to debug problems -
both ways, actually, testing both a new rc kernel on that enterprise
distro but also putting a vanilla kernel on the enterprise distro to
test something that fails with the distro kernel.

I'd absolutely hate if we got into a situation where you couldn't just
put a new vanilla kernel on SLESx. Calling it a complete solution to
just sounds like an excuse for breaking things that we don't have to.
Please lets not make things so fragile!

> So, in short, if you are going to do kernel development, pick a distro
> that handles different kernel versions. Likewise, if you are doing
> userspace development (X.org, HAL, KDE, Gnome, etc.) you pick a distro
> that allows you to change that level of the stack.

Everything doesn't fit into those two boxes.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-22 21:51    [W:0.244 / U:1.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site