1 |
Hemmann, Volker Armin posted |
2 |
<200510051926.49092.volker.armin.hemmann@××××××××××××.de>, excerpted |
3 |
below, on Wed, 05 Oct 2005 19:26:49 +0200: |
4 |
|
5 |
> ok, coaranm aside - have you EVER seen a dev recommending love- or |
6 |
> nitro-sources? |
7 |
> |
8 |
> I have not! Never! Never ever! |
9 |
> |
10 |
> There seems to be a reason that a) no dev has recommended them so far and |
11 |
> b) they are not in portage. |
12 |
|
13 |
Actually, IIRC, love-sources was in portage back in the 2004.1 era. (I'm |
14 |
not positive on that as I developed the habit of downloading kernels |
15 |
straight from kernel.org back on Mandrake, and saw no need to change that, |
16 |
back when I switched to Gentoo around 2004.0/.1, but I'm quite certain I |
17 |
saw love-sources discussed on the user list and in portage at the time.) |
18 |
|
19 |
The reason love and others aren't (now) in portage now is that the Gentoo |
20 |
kernel team decided to simplify what they were managing, as they prepared |
21 |
to switch to 2.6 as the default. Noting that GregKH, one of Linus' |
22 |
"kernel lieutenants", is also a Gentoo (and SuSE, his paying job, IIRC) |
23 |
kernel dev, this was partly due to his encouragement and partly due to |
24 |
the new upstream kernel policy with 2.6, encouraging people to fold their |
25 |
patches back into the mainline kernels as quickly as possible, and doing |
26 |
continuing development thru -mm, keeping it well synced with 2.6 |
27 |
mainline/linus, rather than starting a new 2.7 development branch. |
28 |
|
29 |
With 2.4 and the 2.5 development tree (and with previous stable/devel |
30 |
splits), the stable kernel tended to stagnate to some degree, so many |
31 |
patched branches grew up with various degrees of backporting of |
32 |
development drivers, as well as other patches. Distributions likewise |
33 |
had their own kernels which differed often fairly substantially from |
34 |
mainline (to the point RH folks, for instance, often couldn't switch to |
35 |
non-RH kernels and continue to have a working system). With 2.6, there's |
36 |
much less need for that because the stable kernel doesn't get so out of |
37 |
sync with the development kernel -- all the new drivers and fixes get into |
38 |
stable relatively quickly. |
39 |
|
40 |
So... now the Gentoo kernel tree, formerly containing a rather larger |
41 |
kernel variety, now consists of only a few "main" kernels, including the |
42 |
Gentoo kernel, with it's own set of fairly small but sometimes significant |
43 |
patches, the vanilla/mainline/linus kernel, entirely unpatched, thus the |
44 |
"vanilla", the -mm kernel, now substituting for what would have been the |
45 |
development kernel in earlier incarnations, ck sources, for the |
46 |
low-latency crowd, and a whole bunch of arch-specific stuff. Love and |
47 |
others have been phased out as not mainline enough to be worth the trouble |
48 |
of continuing to maintain them, not necessarily due to any specific |
49 |
deficiencies in the various upstream versions. |
50 |
|
51 |
> And puulease.. nitro is nothing more than |
52 |
> ck+bootsplash+someotherunneededstuff. |
53 |
> |
54 |
> If you want the 'latency enhancement' of nitro, go directly to ck - Con |
55 |
> Kolivas knows what he does. |
56 |
|
57 |
I'd tend to agree, but some folks like the eye-candy of bootsplash, and |
58 |
the like. However, you make my point, that there's nothing necessarily |
59 |
/wrong/ with nitro, just that the Gentoo kernel devs, in large part due to |
60 |
GKH's influence (how many others are on the kernel team besides him, |
61 |
anyway?), have decided their time would be better spent less split on |
62 |
multiple "unnecessary" kernel variants. (I happen to agree with the |
63 |
general kernel policy and GKH on this, BTW.) |
64 |
|
65 |
As to Gentoo devs' recommendations, would /you/ recommend other |
66 |
non-portage packages in public, knowing that if you did, you'd end up |
67 |
being quoted, perhaps out of context, and ultimately either expected by |
68 |
some users taking you up on the recommendation to support it, or bad |
69 |
mouthing you for failing to do so? They recommend kernel versions that |
70 |
have packages existing in portage for one big reason: as with other |
71 |
packages in portage, there's an existing Gentoo support infrastructure if |
72 |
something goes wrong. It's the "safe" recommendation, one they can make |
73 |
without being expected to provide the support or being blamed for failure |
74 |
to do so, personally. |
75 |
|
76 |
That isn't to say that there might not be /other/ reasons, possibly some |
77 |
rather significant ones, why various sources aren't recommended or in |
78 |
portage, but just the fact that they aren't, doesn't mean there's |
79 |
something hugely wrong with them, either. It's certainly a factor that |
80 |
can and should be considered, but I'd call it a pretty small one in the |
81 |
scale of things. If there are significant reasons why another kernel |
82 |
might be better, and one realizes the fact that the kernel DOES contain |
83 |
stuff like file systems and hardware drivers that if they go wrong, could |
84 |
cause SERIOUS damage to an existing installation and is prepared to deal |
85 |
with unlikely possibility should it occur, then certainly, I'd call the |
86 |
mere fact of whether that particular kernel can be had from portage or |
87 |
must be downloaded from the particular kernel hacker's internet site, of |
88 |
little consequence. |
89 |
|
90 |
The open source community is a community where reputation is the currency |
91 |
of exchange. I'm just saying that there are other factors in the |
92 |
valuation of that reputation that are more important than portage tree |
93 |
inclusion, or direct public recommendation by Gentoo devs. By all means, |
94 |
check out the reputation of the particular kernel hacker who's kernels you |
95 |
are investigating, before simply randomly deciding to run it. However, |
96 |
that reputation comes from more than Gentoo devs and portage, which, in |
97 |
the overall scheme of things, play a rather small part in the communtiy |
98 |
recognition of a kernel hacker and their particular expertise in selecting |
99 |
and maintaining a particular group of patches. |
100 |
|
101 |
-- |
102 |
Duncan - List replies preferred. No HTML msgs. |
103 |
"Every nonfree program has a lord, a master -- |
104 |
and if you use the program, he is your master." Richard Stallman in |
105 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
106 |
|
107 |
|
108 |
-- |
109 |
gentoo-amd64@g.o mailing list |