Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Re: Best Desktop Patchset for kernel
Date: Wed, 05 Oct 2005 18:30:23
Message-Id: pan.2005.10.05.18.24.08.612183@cox.net
In Reply to: Re: [gentoo-amd64] Re: Best Desktop Patchset for kernel by "Hemmann
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