I prefer to use the Long Term Stable (LTS) kernels rather than the newest kernel. I am wondering if I am the only Gentoo user that feels this way. I like the fact that Gentoo in the most flexible Linux distro around. However when I am in IRC, people think that I am nuts for using an older kernel.

The main reason I use LTS kernels is, I want a kernel that is well vetted. In the early kernel days, there was the even/odd kernel pyridine where 2.0, 2.2 and 2.4 were production level (well tested) kernels and odd number kernels were reserved for more adventurous users. When the kernel moved to the 2.6 the pyridine shifted. Now the official Linux release of the newest kernel is essentially the same as an old "Odd number" kernel. Now it is the responsibility of the distribution keepers to provide it's users with production level kernels. I have noticed that I have used "Gentoo" kernels, I have found bugs that caused previously working bit of hardware stops working after a kernel upgrade. Using Google and my own exploration, I have traced the problem to a kernel bug. It seems to me that when Gentoo is the ONLY source of vetting a kernel that there are many pieces of hardware "Especially" older hardware that falls through the cracks.

This is why I prefer the LTS kernels because there is a wider source of vetting, When done properly, all distros send there confirmed bugs upstream. So Gentoo, RedHat, SUSE and Ubuntu all send there bugs to the kernel developers and these bugs are dealt with with no mater which distro discovers the bug. The only drawback is delay that happens because of this extended vetting process. By this time, the head of the Linux development has moved on and introduces new bugs into the source.

My main rebuttal, the the objection that LTS kernels don't have the newest features, is that I usually don't need the newest features. I am running some old hardware and find that it satisfies my needs. If I were to purchase some newer hardware, I would coincider switching kernels if it were required for the newer hardware, however I don't have a lot of money for hardware purchases. In my situation, I would be best off with more memory and upgrading the processor while sticking with the same mobo.

The main reason I use LTS kernels is, I want a kernel that is well vetted. In the early kernel days, there was the even/odd kernel pyridine where 2.0, 2.2 and 2.4 were production level (well tested) kernels and odd number kernels were reserved for more adventurous users. When the kernel moved to the 2.6 the pyridine shifted. Now the official Linux release of the newest kernel is essentially the same as an old "Odd number" kernel. Now it is the responsibility of the distribution keepers to provide it's users with production level kernels. I have noticed that I have used "Gentoo" kernels, I have found bugs that caused previously working bit of hardware stops working after a kernel upgrade.

No, the newest kernel is now equivalent to the old even numbered releases. The need for odd-numbered "dev" major versions went away with the ancient development practice of working around a deficient version control system by doing all new development on mainline.

If your old hardware's broken in newer kernels, no-one with said hardware cares enough to file a bug report about it, or test it with new kernel RCs ahead of time.

However when I am in IRC, people think that I am nuts for using an older kernel.

I think you misinterpret. People in IRC do not think you are nuts for using an older kernel. They think you are nuts for using an older kernel and come chatting in IRC...

As a matter of fact, if you plan to enter whatever long term project or simply use your system for actually working on it, my opinion is that you would be nuts for not choosing a LTS branch.
Who, in this situation gets the manpower to afford the configuration / testing / qualification that would require a kernel branch update ?

BTW... when you are in such a situation... you don't get the time for chatting on IRC either... do you ?

As far as I am concerned, I think that a couple of my systems wont quit the 3.4 before... hmmm... at best... next year ?

And this... even in the case... udev's KV_MIN reaches 3.5 ! _________________

TheLexx, I used to keep my kernel much more current, until I learned enough about building and updating kernels and got bored. Then, my couch gene took over, and now I stick with LTS kernels that work with my hardware (why o why o iwlwifi???).

Recently, I even stopped using portage to get kernels and just started using git directly, just because it's quicker to update my kernel tree in-place.

I have an old laptop that's used as a server that's stuck on 3.0. I suspect it's old PATA disk will die well before I feel the inclination to update it. But, if I got a new machine, I'd probably be unable to resist putting the latest and therefore possibly maybe greatest kernel on it, then waiting for LTS to catch up. That's what happened last time, anyway.

Don't put off getting more memory for your main machine, if you're running 64 bit and using < 8G memory you're really missing out. Your machine really will be snappier just because most programs will never get turfed from cache and the big hoggy browsers get to be happy fat old pigs.

Myself, I find IRC causes grinding in the knees and weakness of the pineal gland. They think I'm crazy too!

I always stay off the bleeding-edge as much as I can. "Software like fine wine ... let it age." Not that the latest kernels aren't stable and all that ... usually, they are ... it's just that being slightly behind the cue-ball, using a version that's trusted to be stable, is frankly more convenient.

I always stay off the bleeding-edge as much as I can. "Software like fine wine ... let it age." Not that the latest kernels aren't stable and all that ... usually, they are ....

Yes, vanilla<3.7.6 had some serious issues, there came patches I wonder why my machine didn't crash.
But:
I wouldn't run old Linux kernels having "EOL" at kernel.org. I don't like them ever being assigned a "stable" attribute by Gentoo maintainers. Such a policy is not in sync with upstream statements. I doubt there is enough Gentoo developer power to fill that gap._________________fun2gen2

I wouldn't run old Linux kernels having "EOL" at kernel.org. I don't like them ever being assigned a "stable" attribute by Gentoo maintainers. Such a policy is not in sync with upstream statements. I doubt there is enough Gentoo developer power to fill that gap.

1/ I do not personally understand The upstream-EOL and the Gentoo-stable qualifiers as mutually exclusive.
Look on lkml.org, even upstream-EOL is not incompatible with upstream-stable. The 3.6.11 and the 3.5.7 are both upstream-stable and upstream-EOL.
Each qualifier is attributed if the associated set of criteria are met. And the criteria for stable differ from the criteria for EOL.

2/ Why should the Gentoo-stable attribute be in sync with upstream statements ?
If, as an example, one of the important meaning of Gentoo-Stable is : Is perfectly compatible with any other Gentoo-Portage-Package keyworded Gentoo-Stable
For an * source package, it would mean a guarantee that the kernel can be built with latest Gentoo-Stable toolchain.
Then this is a valuable information for the Gentoo-user that has absolutely nothing to do with whatever upstream consideration.

This is my understanding of these words :

a/- Upstream EOL means that the branch will no longer benefice from any patch, this including bug fixes, new drivers, security fixes.
b/- Gentoo-Stable means no known regression from preceding Gentoo-Stable and compatible with the other Gentoo-Portage-Packages keyworded Gentoo-Stable.

I know many embedded / networkless projects which do not care a damn of a/ and do care about b/

EDIT : BTW, I think that the lack of resources is more responsible for the lack of Gentoo-Stable keywording than for the lack of Gentoo-Stable-Keyword removal._________________

a/- Upstream EOL means that the branch will no longer benefice from any patch, this including bug fixes, new drivers, security fixes.
b/- Gentoo-Stable means no known regression from preceding Gentoo-Stable and compatible with the other Gentoo-Portage-Packages keyworded Gentoo-Stable.

Uuups, but Gentoo+stable also fixes security issues?

It is not that often an issue regarding the kernel. But if? If Gentoo has to mask a stable kernel line. As consequence, think of this case:

If you installed a server machine, where you build some special inhouse software stacks then
you would have better selected a longtime maintained kernel tree as your building block.

But I must admit implementing such a project had a deliberate decission process regarding the choosen kernel tree. You surely would not select the most recent Gentoo stable with blind eyes ....

[edit]Another example: Think of a several thousands of Samsung laptops deployed using Linux-3.5.7 in Efi mode._________________fun2gen2

Just a question out of curiosity:
How is "LTS" identified? on kernel.org I can see "mainline" and "stable". But neither there nor in the faq is anything mentioning LTS._________________systemd - The biggest fallacies

Just a question out of curiosity:
How is "LTS" identified? on kernel.org I can see "mainline" and "stable". But neither there nor in the faq is anything mentioning LTS.

The LTS would be certain kernels like 3.4.30, 3.2.38, 3.0.63, etc, which are old kernel releases but which regularly receive backported fixes. They are all labeled as "stable" in kernel.org, and are maintained for several years beyond their first 3.x.0 release. In contrast you will see that 3.5.x and 3.6.x are not LTS and are already marked as EOL in the website. This means that they won't receive any further backports and/or bugfixes.

About the original question, sticking with LTS kernels is a good idea. If all your current hardware is working well, then there is no point in upgrading the kernel to a new version (but of course, installing newer revisions is encouraged). Quite often 3.x.0 and the next few revisions are not that well flushed. It's only by some later revision that the kernel starts becoming very stable. Many times, some drivers catch up with the kernel changes only after several revisions have passed by. Personally, I value stability more than being on the bleeding edge of every package._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

Just a question out of curiosity:
How is "LTS" identified? on kernel.org I can see "mainline" and "stable". But neither there nor in the faq is anything mentioning LTS.

... at least another one shares your opinion that things are a bit... confusing !

GKH wrote:

I'm doing this as it's just way too confusing to try to explain to
people exactly what kernels are being maintained longer than others, and
why they are being maintained. Not to mention the confusion on the
kernel.org web site where it's hard to tell what kernel release is
currently being maintained or not.

Unfortunately... stable@kernel.org seems quite dead and more accurate informations about this can be found on... wikipedia : http://en.wikipedia.org/wiki/Linux_kernel#Maintenance where you can additionally discover that you get LTS, LTS and... LTS... I mean GKH-LTS / Other-LTS / Unofficially LT Supported... _________________

Just a question out of curiosity:
How is "LTS" identified? on kernel.org I can see "mainline" and "stable". But neither there nor in the faq is anything mentioning LTS.

The LTS would be certain kernels like 3.4.30, 3.2.38, 3.0.63, etc, which are old kernel releases but which regularly receive backported fixes. They are all labeled as "stable" in kernel.org, and are maintained for several years beyond their first 3.x.0 release. In contrast you will see that 3.5.x and 3.6.x are not LTS and are already marked as EOL in the website. This means that they won't receive any further backports and/or bugfixes.

About the original question, sticking with LTS kernels is a good idea. If all your current hardware is working well, then there is no point in upgrading the kernel to a new version (but of course, installing newer revisions is encouraged). Quite often 3.x.0 and the next few revisions are not that well flushed. It's only by some later revision that the kernel starts becoming very stable. Many times, some drivers catch up with the kernel changes only after several revisions have passed by. Personally, I value stability more than being on the bleeding edge of every package.

A bit unfortunate is that gentoo-sources do not usually track updates to LTS kernels in the stable branch

Just a question out of curiosity:
How is "LTS" identified? on kernel.org I can see "mainline" and "stable". But neither there nor in the faq is anything mentioning LTS.

The LTS would be certain kernels like 3.4.30, 3.2.38, 3.0.63, etc, which are old kernel releases but which regularly receive backported fixes. They are all labeled as "stable" in kernel.org, and are maintained for several years beyond their first 3.x.0 release. In contrast you will see that 3.5.x and 3.6.x are not LTS and are already marked as EOL in the website. This means that they won't receive any further backports and/or bugfixes.

About the original question, sticking with LTS kernels is a good idea. If all your current hardware is working well, then there is no point in upgrading the kernel to a new version (but of course, installing newer revisions is encouraged). Quite often 3.x.0 and the next few revisions are not that well flushed. It's only by some later revision that the kernel starts becoming very stable. Many times, some drivers catch up with the kernel changes only after several revisions have passed by. Personally, I value stability more than being on the bleeding edge of every package.

I have to disagree, the kernel does more than just run your hardware. Theres lots of reasons to upgrade a kernel that arent hardware related.

remember the ~200 line kernel patch a few years ago that really increased dekstop responsiveness even under heavy cpu load?_________________A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.

I have to disagree, the kernel does more than just run your hardware. Theres lots of reasons to upgrade a kernel that arent hardware related.

remember the ~200 line kernel patch a few years ago that really increased dekstop responsiveness even under heavy cpu load?

Yes, but important patches are usually backported to LTS kernels (that's their definition). At the same time the very next version of the kernel is not always an improvement, cases of regression are not infrequent. Which on a balance makes sensible to stick to what you have already proven to work for your setup.
Of course, if you suffer from some problem, you'll be looking for solution.

Last edited by dmpogo on Sat Feb 16, 2013 5:40 pm; edited 1 time in total

I have to disagree, the kernel does more than just run your hardware. Theres lots of reasons to upgrade a kernel that arent hardware related.

remember the ~200 line kernel patch a few years ago that really increased dekstop responsiveness even under heavy cpu load?

Patches like the 200 line one happens once in a blue moon. On the other hand regressions happen more often. The last time I had a decent hibernate with a kernel was the 2.6.38 because I could use the tuxonice patches and hibernate worked reliably. I stayed with that version for over two years. It was one of the most stable kernels I had on my system.

The typical way my laptop runs is that I login once and then don't logout for weeks, let alone reboot. I use suspend very frequently, and had configured hibernate to kick in if I was on very low battery power. If you use your desktop/laptop like this you will find bugs. I have found memory leaks in nvidia drivers which manifests after several days of remaining logged in. I have found X bugs with the mouse that manifested after weeks of remaining logged in.

With a usage like this, I find it much more necessary to have a stable kernel with good support. Once the kernel and my system runs reliably I rarely make major upgrades. This is why I stayed with .38 for such a long time - it was stable and it gave me reliable hibernate when used with tuxonice. The in-kernel hibernate is a joke compared to what tuxonice does. Similarly, it irks me that some basic system packages undergo such major changes so often. The procedure for mounting has changed like 3-4 times in past 3 years. It is irritating because I have to make major changes to my scripts every couple of months. And something changed again recently with udisks2. I have now masked all these upgrades; I don't have time to fool around with broken systems. Thankfully, Gentoo allows for such fine grained control._________________emerge --quiet redefined | E17 vids: I, II | Now using e17 | e18, e19, and kde4 sucks :-/

Theres lots of reasons to upgrade a kernel that arent hardware related.
remember the ~200 line kernel patch a few years ago that really increased dekstop responsiveness even under heavy cpu load?

Do you really mean that 200 lines of kernel code achieving the equivalent of what you can obtain thanks to half a dozen of lines in userspace is a valid reason for upgrading a kernel ?_________________

I have to disagree, the kernel does more than just run your hardware. Theres lots of reasons to upgrade a kernel that arent hardware related.

remember the ~200 line kernel patch a few years ago that really increased dekstop responsiveness even under heavy cpu load?

Patches like the 200 line one happens once in a blue moon. On the other hand regressions happen more often. The last time I had a decent hibernate with a kernel was the 2.6.38 because I could use the tuxonice patches and hibernate worked reliably. I stayed with that version for over two years. It was one of the most stable kernels I had on my system.

Quite agree here, circa 2.6.38 was the best experience with my laptop that I had. However, afterwards I was able to get tuxonice work reliably on 3.2.x series kernels, but not on 3.4 . Haven't tried later ones, am sticking to 3.2 right now, since hibernation is the most important aspect for me as well.

Theres lots of reasons to upgrade a kernel that arent hardware related.
remember the ~200 line kernel patch a few years ago that really increased dekstop responsiveness even under heavy cpu load?

Do you really mean that 200 lines of kernel code achieving the equivalent of what you can obtain thanks to half a dozen of lines in userspace is a valid reason for upgrading a kernel ?

no i dont, i think those 200 lines of code was a valid reason for finding that patch and applying it myself cause it was so new i didnt want to wait for Linus to close the window and put the kernel up on kernel.org _________________A process cannot be understood by stopping it. Understanding must move with the flow of the process, must join it and flow with it.

i run 2.4.22.... i mean 3.7.9 lol i like finding broken garbage and crying about it on forums. ive had uptimes of over 350 days, my daily pc gets beatup frequently, and updated frequently and broken frequently.

My production notebook is mostly always on latest upstream stable kernel regardless of what Gentoo deems stable, sometimes even _rc{6,7,8} are used. The reason for that is simple: Since using that system beginning with 2.6.27 every kernel version had left something to be desired for my graphics chip, so I was hoping for change and always kept 1 to 5 kernel patches or even the whole drm-next branch in addition.

On headless server it currently is 3.0, soon 3.4, only LTS accepted there._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

I follow the "if it aint broke - Don't fix it" thinking along with the "KISS" (keep it simple stupid) principle. This means my system tends to go 12-18 months between world updates though I will update an installed package if there's a critical issue.

Simply put, my system tends to follow server config methods - Install the absolute minimum to do the job and the way I do this is by using USE="-* mmx sse sse2" (cpu specific flags) being set. Everyting else is in /etc/portage/package.use, which helps by kicking unneded dependencies out the door. Some apps tend to get cranky about optional dependencies and I'll file bugs that suggest they be added as must have instead.

Right now I've gotten my desktop systems installations down to the point that everything can fit onto a live-dvd w/o compression - that's 4GB for the entire installation and with a bit of work, I can actually fit everything down into just over 1GB for a useable system (think tablets and the early EEE-PC's). To me it's fun getting a full featured system in as little space as possible and it's Gentoo that makes it feasible.

Just a question out of curiosity:
How is "LTS" identified? on kernel.org I can see "mainline" and "stable". But neither there nor in the faq is anything mentioning LTS.

When I originally posted this back in February, Yamakuzure's concerns were quite an issue, because which kernels were being maintained was up-in-the air, as far as the user could tell. For a while we had to parse through mailing list and blog post to find the difference between maintained and unmaintained kernels marked stable.

Since then, 2013-05-16 to be exact kernel.org has revised the way it tracks LTS kernels. For details read. This is a step forward for those of who prefer to use the LTS kernels.

Looking to the Wayback Machine, I see that longterms were tracked prior to my original post HERE. however, "longterm" was not well defined. Now the time-line and definition are better. Also, the longterms are now included in the RSS feed

On a personal note I upgraded to the 3.4 kernel series which is the latest LTS kernel. In the past few months 3.4 has received many updates.