[arch-general] [arch-dev-public] gcc-4.4.0 toolchain rebuild with query about gcc-gcj and related packages

[Dan McGee]

On Sun, Apr 26, 2009 at 7:43 AM, Daenyth Blank <daenyth+arch at gmail.com> wrote:
> On Sun, Apr 26, 2009 at 05:27, Thomas Bächler <thomas at archlinux.org> wrote:
>> Allan McRae schrieb:
>>>
>>> Hmmm...   I thought about bumping this to 2.6.18 this time round (based on
>>> nothing better that when good kernel headers became available) but decided
>>> not to as 2.6.16 is still widely used given it had a backport branch open
>>> for a long time (and maybe still does?).
>>
>> 2.6.27 will also be maintained for a few years now (no reference, I read
>> this on lkml in a comment).
>>
>> I think among the Arch userbase, virtually nobody uses anything older than
>> 2.6.27. We always announce to be "bleeding-edge", so IMO there should be no
>> problem in supporting newer kernels only.
>>
>>> I guess what I think the decision comes down to is:  Are the speed gains
>>> from this actually noticeable?  I'm skeptical but there are a fair number of
>>> workarounds removed doing that so maybe they are.
>>
>> The resulting code will probably be cleaner. I am always in favour of
>> dropping legacy support.
>>
>> To everyone reading this: Do you use an exceptionally old kernel (say, older
>> than 2.6.27) on Arch and why? Or do you know anyone who does?
>>
>>
>
> Shared hosting sites use kernels as old as .24 iirc.

Slicehost provides me with a .24 kernel. Thus the reason the bump to
2.6.22 seemed acceptable to at least me, but going all the way to .27
will not work at all.

-Dan