On Mon, Sep 16, 2013 at 8:59 PM, Brian F. G. Bidulock <bidulock@openss7.org> wrote:
If you look at https://www.kernel.org/category/releases.html you will see that 3.2.x is LTS with EOL 2016, whereas 3.10.x is EOL Sept, 2015. (Obviously 3.0.x is EOL Oct 2013, next month, so some change is necessary.)
When we moved from 2.6.32 lts to 3.0 lts, it was because gcc header files needed a minimum kernel above 2.6.34. I was wondering whether there was a similar technical reason for the 3.10.x choice over 3.2.x, or whether I can just as easily run a 3.2.x kernel on an otherwise Plain Jane and current Arch Linux build?
Off the top of my head, the discussion in arch-dev-public went about two main points: 1:) Arch is a distribution that prides itself in being on the bleeding edge of technology. If there is a new LTS kernel since now and September 2015, be sure it will replace the present version unless there are apocalyptic reasons not to do it. 2.) The 3.10 kernel has much better hardware support and gives access to a lot of newer technology that LTS users might want to use. On my side, I can see a very important and beneficial side effect of using 3.10 as LTS kernel: It is very well integrated with systemd. In fact it has already part of the work that supports the new hirearchical cgroups world, therefore it will be more compatible with future systemd versions. Furthermore, the technological advance in file-systems, virtualization and graphics support from 3.2 to 3.10 is not something to ignore. Perhaps I ought to point out that a kernel.org LTS is a bug-fix only affair unless there is an obvious need to correct a glaring mistake, new features are not added lightly. That's not the case with vendor kernels. They choose to add the support and backport the features they want, that is: those kernels are Frankenstein monsters. A RHEL 5 2.6.17 kernel is really made out of the corpses of all kernels up to 3.8 at this time ---taking an educated guess--- and that is without taking into consideration all the out-of-tree additions that are not either in Torvald's nor linux-next trees. -- http://about.me/palopezv