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

Gerardo Exequiel Pozzi vmlinuz386 at yahoo.com.ar
Sun Apr 26 16:45:12 EDT 2009


Thomas Bächler 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?
>
Personally (as "desktop" user), I use linux-2.6.27.21 without any
patches (I am in planing to jump directly to 2.6.30.2 when it is
released), with my custom config. It is the only piece of software that
I maintain some respect and do not update after a certain time.

In my oponión as I said before, I think this is the perfect upload limit
of 2.6.16 to 2.6.22, which is the minimum version that udev needs to
run. Unless there is any user who uses an old udev, or use a static /dev.

-- 
Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C 330D



More information about the arch-general mailing list