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