[gentoo-amd64] Re: Re: Best Desktop Patchset for kernel

[Duncan <1i5t5.duncan@cox.net>]

Hemmann, Volker Armin posted
<200510051926.49092.volker.armin.hemmann@tu-clausthal.de>, excerpted
below,  on Wed, 05 Oct 2005 19:26:49 +0200:

> ok, coaranm aside - have you EVER seen a dev recommending love- or
> nitro-sources?
> 
> I have not! Never! Never ever!
> 
> There seems to be a reason that a) no dev has recommended them so far and
> b) they are not in portage.

Actually, IIRC, love-sources was in portage back in the 2004.1 era.  (I'm
not positive on that as I developed the habit of downloading kernels
straight from kernel.org back on Mandrake, and saw no need to change that,
back when I switched to Gentoo around 2004.0/.1, but I'm quite certain I
saw love-sources discussed on the user list and in portage at the time.)

The reason love and others aren't (now) in portage now is that the Gentoo
kernel team decided to simplify what they were managing, as they prepared
to switch to 2.6 as the default.  Noting that GregKH, one of Linus'
"kernel lieutenants", is also a Gentoo (and SuSE, his paying job, IIRC)
kernel dev, this was  partly due to his encouragement and partly due to
the new upstream kernel policy with 2.6, encouraging people to fold their
patches back into the mainline kernels as quickly as possible, and doing
continuing development thru -mm, keeping it well synced with 2.6
mainline/linus, rather than starting a new 2.7 development branch.  

With 2.4 and the 2.5 development tree (and with previous stable/devel
splits), the stable kernel tended to stagnate to some degree, so many
patched branches grew up with various degrees of backporting of
development drivers, as well as other patches.  Distributions likewise
had their own kernels which differed often fairly substantially from
mainline (to the point RH folks, for instance, often couldn't switch to
non-RH kernels and continue to have a working system).  With 2.6, there's
much less need for that because the stable kernel doesn't get so out of
sync with the development kernel -- all the new drivers and fixes get into
stable relatively quickly.

So... now the Gentoo kernel tree, formerly containing a rather larger
kernel variety, now consists of only a few "main" kernels, including the
Gentoo kernel, with it's own set of fairly small but sometimes significant
patches, the vanilla/mainline/linus kernel, entirely unpatched, thus the
"vanilla", the -mm kernel, now substituting for what would have been the
development kernel in earlier incarnations, ck sources, for the
low-latency crowd, and a whole bunch of arch-specific stuff.  Love and
others have been phased out as not mainline enough to be worth the trouble
of continuing to maintain them, not necessarily due to any specific
deficiencies in the various upstream versions.

> And puulease.. nitro is nothing more than
> ck+bootsplash+someotherunneededstuff.
> 
> If you want the 'latency enhancement' of nitro, go directly to ck - Con
> Kolivas knows what he does.

I'd tend to agree, but some folks like the eye-candy of bootsplash, and
the like.  However, you make my point, that there's nothing necessarily
/wrong/ with nitro, just that the Gentoo kernel devs, in large part due to
GKH's influence (how many others are on the kernel team besides him,
anyway?), have decided their time would be better spent less split on
multiple "unnecessary" kernel variants.  (I happen to agree with the
general kernel policy and GKH on this, BTW.)

As to Gentoo devs' recommendations, would /you/ recommend other
non-portage packages in public, knowing that if you did, you'd end up
being quoted, perhaps out of context, and ultimately either expected by
some users taking you up on the recommendation to support it, or bad
mouthing you for failing to do so?  They recommend kernel versions that
have packages existing in portage for one big reason:  as with other
packages in portage, there's an existing Gentoo support infrastructure if
something goes wrong.  It's the "safe" recommendation, one they can make
without being expected to provide the support or being blamed for failure
to do so, personally.

That isn't to say that there might not be /other/ reasons, possibly some
rather significant ones, why various sources aren't recommended or in
portage, but just the fact that they aren't, doesn't mean there's
something hugely wrong with them, either.  It's certainly a factor that
can and should be considered, but I'd call it a pretty small one in the
scale of things.  If there are significant reasons why another kernel
might be better, and one realizes the fact that the kernel DOES contain
stuff like file systems and hardware drivers that if they go wrong, could
cause SERIOUS damage to an existing installation and is prepared to deal
with unlikely possibility should it occur, then certainly, I'd call the
mere fact of whether that particular kernel can be had from portage or
must be downloaded from the particular kernel hacker's internet site, of
little consequence.

The open source community is a community where reputation is the currency
of exchange.  I'm just saying that there are other factors in the
valuation of that reputation that are more important than portage tree
inclusion, or direct public recommendation by Gentoo devs.  By all means,
check out the reputation of the particular kernel hacker who's kernels you
are investigating, before simply randomly deciding to run it.  However,
that reputation comes from more than Gentoo devs and portage, which, in
the overall scheme of things, play a rather small part in the communtiy
recognition of a kernel hacker and their particular expertise in selecting
and maintaining a particular group of patches.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list