5.4, 5.10, and 5.15 are all “LTS” kernels. So, yes, 5.15.25 is LTS.
However, lately I’ve been questioning what “LTS” even means in regards to kernel releases. Other than they are “supported” for more years, they don’t have the QA and minimal changes I had first assumed.
“LTS” means different things to different projects.
And this is why I am having second thoughts about the Linux kernel’s “LTS” moniker. Because such a bug (“feature”) did indeed get backported to 5.15 from changes made during 5.16/5.17 development.
The s2idle bug surprised unsuspecting laptop users when trying to suspend to RAM, causing a spectrum of issues, one of which was draining their battery life and overheating their laptops. (Using 5.15 was not a “safe haven” in this case, since it inherited changes done to newer kernel releases.)
Thankfully, the bug has been reverted in 5.17-rc7, and hopefully the same will be true of 5.15 when the next batch of Manjaro Stable updates are ready. (Perhaps kernel 5.15.27?)
Hence, why I said:
Because prior to this nasty backported “feature” (bug), I truly believed an LTS kernel was safe from such things.
## What does "stable/EOL" and "longterm" mean?
As kernels move from the "mainline" into the "stable" category, two things can happen:
1. They can reach "End of Life" after a few bugfix revisions, which means that kernel maintainers will release no more bugfixes for this kernel version, or
2. They can be put into "longterm" maintenance, which means that maintainers will provide bugfixes for this kernel revision for a much longer period of time.
If the kernel version you are using is marked "EOL," you should consider upgrading to the next major version as there will be no more bugfixes provided for the kernel version you are using.
So, this confirms my assumption that “longterm” (LTS?) is older than the “stable”, which is older than “mainline”, the earlier is supposed to be more stable, so even “longterm” is supposed to be the most stable.
Though I still don’t understand how can a feature/bug be backported from a newer version to an older version as @winnie mentioned. I am by no means understating what he mentioned, I just assume that debugging version 1 is absolutely separate from “developing” version 2.
Yeah so while it is under longterm support they do fix “bugs” and while they typically don’t back port features they do back port security fixes. So for example the latest spectre BHI vulnerabilities are patched in the latest kernel however they will back port those into the LTS kernels since they are still being supported when that happens it is always possible that when back porting bug/security fixes that it can create other issues, they of course try to thoroughly test everything but the world of computing and code evolves so rapidly it just isn’t possible to catch everything every time. Personally I typically run on the latest stable kernel myself but I always keep the 2 prior LTS kernels installed in case I need to fallback to them. The way I look at it is storage is relatively so cheap and a kernel in the grand scheme of storage is tiny.
You gave me some self confidence by your reply.
As I started programming as a hobby and doing little programs to help me at work since 1978 (Basic, Dbase III+ then Dbase IV and a little MS Access) and didn’t do any programming since 1997. I was thinking I am an old man and “programing” has changed over time and I know nothing today.
You gave me self confidence because I was believing the ABCs of programming should remain the same.
As you mentioned
This answers my question how it happens.
I owe you a dinner!
I believe I did something similar during my distrohopping, and I believe this is a very wise thing to do.
I will look somewhere here how to do it as all I remember I should update Grub but cant remember what commands or how to in detail (sorry a bit old man here, I’m 60 years “young”)
Sure, this is a rule of thumb in developing software/programming.
I always thought “programming” or writing code is mainly about “debugging”, while I was doing “programming” most of my time and effort was about debugging mainly.
The most user friendly way to change it via the GUI is to launch the Manjaro Settings Manager and then select Kernel.
That interface will show you all the current valid kernels you can have and the type of kernel (real-time, experimental, stable, LTS, etc). From that GUI interface you can easily Remove and Install multiple kernels.
You are right. But my experience if you could focus and look close, be sure you are handling only one single bug not the whole nest or part of it. If you played with the whole nest or part of it you will release most of the bugs!
Anyway programming/ software developing is more to debugging than coding. As far as I know there is no software that has no bugs, no matter how long it is being debugged. There are ALWAYS a bugs somewhere.
[sudo] password for limo:
Currently running: 5.15.25-1-MANJARO (linux515)
The following kernels are installed in your system:
especially after we discussed the bugs here and after viewing few posts here about people unable to boot after an update.
Rebooted a few times and switched between both kernels though it was not that easy to access the multiboot menu, it is like very sensitive about the timing of pressing the ESC button. But it is fine.
This is absolutely wonderful and easy anyway.
Thank you for your advice.