Using the latest linux-libre -- pros and cons
Hi! I've just installed the latest linux-libre kernel (4.2.2) in Trisquel 7 (from jxself.org), to replace the 3.16 version that's available in the official repos. I haven't experienced any improvements or regressions but I wonder if the upgrade was a good idea or not. In particular I wonder if there are any security and stability issues with using jxself's "vanilla" linux-libre. Has my upgrade disabled AppArmor? I should add that the computer is a Macbook2,1 with libreboot 20150518.
Hi there! Sort of unrelated question: how is the performance on your laptop with libreboot? We're maintaining a wiki entry on it, any feedback would be appreciated: https://trisquel.info/en/wiki/macbook
Pros? You get support for newer hardware. Someone with Skylake for example will need 4.2. Your Macbook is already well-supported by the Trisquel kernel though.
Another pro? Newer kernels bring interesting new features for programs to use.
But if your hardware is already well supported and you don't want/need/use newer features that newer kernels bring there is probably no reason to use it. At the same time there's no harm either.
Well, newer kernels mean less tested kernels, i.e., there is a higher probability to face stability issues.
On the contrary - The kernel named Linux gets extensive testing prior to release via a variety of methods and people. It is stable on release.
This is only true to some extent. Otherwise what are Greg Kroah-Hartman's stable kernels for?
You were talking of stability issues. Stability issues are (to me) along the lines of kernel panics and the like (i.e., something that brings down the entire system.) These should be exceedingly rare in released versions due to the extensive testing that goes on during development. Maybe you didn't mean stability issues? :)
What are Greg Kroah-Hartman's stable kernels for if not for stability?
We seem to be talking of different things here. Not all problems result in stability issues (i.e. a kernel panic that brings the entire system down.) That to me is a stability issue. Otherwise it is not a stability issue but something else - some other form of bug.
We are talking about the same thing. The third digit in Linux versions is incremented when Greg Kroah-Hartman releases more stable versions of Linux. That includes fixes to kernel panics. See for instance the release announcement for Linux 4.1.10 that "fix[es] panic in sock_diag_put_filterinfo" (among many other things): https://lwn.net/Articles/659078/
A deadlock is still present in that version though: https://lwn.net/Articles/658749/
Yes, note I didn't say kernel panics don't happen but they are rare. Most of the stuff that is submitted are not fixes for things that will crash the system and so aren't "stability issues" but other types of bugs (performance bugs, security bugs, etc.) But you seem to be operating under the impression that all bugs cause stability issues and that just isn't true: A box can be have bugs and still be stable. Not all bugs will result in a system crash... therefore are not stability issues, which are the vast majority of the stuff that goes into the point releases. So I stand by what I said: It is stable on release. That does not mean bug free. That does not mean there aren't security problems. That does not mean anything more than I said. It is stable. It can be built, it can run. 'nuff said.
I know that not all bugs in the kernel crash it. Anyway Greg Kroah-Hartman's kernels are called "*stable* kernels" for a reason. And the reason is they solve stability issues that were present in the original release. Including bugs causing the kernel to crash.
Those bugs obviously rarely reveal themselves. Most user would never face them (because the bug is triggered with a specific hardware, a specific kernel configuration, etc.). Anyway, they exist. You cannot deny them. I gave you above two bugs crashing the kernel in the 4.1.0 release. You can read other release announcements of new stable kernels and will find many other such examples of stability issues that are solved after Linus Torvalds releases a new kernel.
"You cannot deny them."
I'm not trying to, only pointing out that they're rare which you admit to (most people not seeing them.) So it can be considered stable on release. That does not meant free of bugs (and most bugs filed against the kernel are not of the system halting variety anyway) but
"there is a higher probability to face stability issues."
Being new doesn't make it any more likely than being old - 2.6.32 was released almost six years ago and the notes for 2.6.32.68 from this past September (the latest release) mention a panic so they are still found there even there today. So let's stop this okay? Thanks.
I've been talking to Bob at ThinkPenguin about that since the start of September and found that 3D accelerated graphics on Skylake works with the Linux-libre kernel, but they are degraded to the performance of 3rd / 4th gen graphics. Skylake is a step backwards, but it is not as bad as originally thought.
The nice thing about the 4.2 kernel is that all of the features of the Xbox 360 and Xbox One controllers work (rumble and LED support) via wired or wireless thanks to a patch that Valve pushed upstream. If you are a gamer, this is a great feature.
pizzaiolo: I know about the guide; I made a few changes to it yesterday. By the way, I answered you question in the other thread.
jxself:
Another pro? Newer kernels bring interesting new features for programs to use.
But if your hardware is already well supported and you don't want/need/use newer features that newer kernels bring there is probably no reason to use it. At the same time there's no harm either.
Yes, I know that there might be various device improvements. Actually I just noticed that the 4.2 kernel, in my case, mostly fixes an issue with waking up from hibernation.
So there is no harm at all in abandoning the custom kernels of the distro? For example, does the security module AppArmor continue to function with your binaries, without me having to rebuild the kernel manually?
AppArmor still works.