Kernel Longevity - Making the same mistakes again?
 

Back when Slackware 13.1 was in the process of being built, I raised a query on these forums about why current was going with 2.6.33.y when 2.6.32.y had just been announced as a long-term supported kernel that was likely to have much longer longevity once Slackware 13.1 was released (*). In all the excitement and joy at seeing current move again, I hadn't noticed until now that we are in the same situation again.

Given that 3.0 has been announced as a long-term kernel by Greg K-H and will be supported for at least 2 years, wouldn't it make sense to stick with this as the official stock kernel in current, and provide any later ones in extra/ ?

Whether the next release finally ships with 3.2, 3.3, or even 3.4 the chances are that non of them will receive updates from upstream for very long after the release goes live.

edit:
(*) Yes, I know Greg later also decided to declare 33.y as a long-term kernel because it was in use in quite a few distros, so the decision in 13.1 happened to work out ok, but it wasn't declared as such at the time and there's no guarantee anything like that will happen for any of the 3.2-3.4 kernels.

Slackware's development model is not taking into account "long-lived" kernels. We take a kernel which works best at the time for the software stack built on it, and which results in as little bugs reported as possible.

Slackware traditionally does not offer kernel updates to stable releases - if you want or need a new kernel it is easy to grab the latest kernel sources, use an older Slackware .config file as the base and compile your own.

Eric

Yep, I appreciate that Eric and I generally build my own and follow the mainline kernel updates.

However, I do remember how nice it was when the chosen kernel of Slackware 12.2: 2.6.27 just happened to coincide with the long-term upstream kernel. It meant that users could apply upstream security/maintenance updates without fear of any API or other kernel level changes that a move to a new branch could bring. While updating your kernel to the latest kernel branch to get security updates is a viable approach, in practice there have been times when this has broken compatibility with things like the nvidia drivers or other low level system tools such as dhcpcd, thus forcing additional updates to those too in order to regain functionality. Shipping against the latest long-term branch would allow people a less invasive way of applying kernel security updates themselves post release.

While I guess one could also downgrade the kernel locally, because the slackware shipped headers and libc will be built against the newer kernel headers, they could potentially include functionality not in the older kernel and could result in breakage when building something which may use those features, which is why I tend to shy away from that idea.

Anyway, just thought it was worth raising the idea. If the dev team doesn't think it's worth considering such an approach then so be it.

Remember that Greg KH is only one person, and his choice for long term support is probably driven by the interest of _some_ people. Kernel 3.0 isn't going to be the only kernel version where people are going to look to for support. Just take this for example:
http://www.linuxtoday.com/infrastruc...11000139NWKNRL

So who's to say that 3.0, 3.1, or 3.2, or even 3.3 isn't going to get looked at even if Greg hasn't exactly blessed it, I would definitely go with the best kernel for the job. At least if you aren't the last one to use a particular version that is, but that usually is never a problem for a long time, since there are many variants of distros, even the big ones.

I think that 3.2 is a better choice than 3.0, mostly because of the major performance benefits of 3.2. It doesn't matter what one guy says about which kernel is long term support. If the kernel is good and works well, I don't see any real reason not to use it.

I have compiled my own kernels, but, now I use the kernels provided with slackware-stable and slackware-current. I am liking 3.2.2. :)

Yes, 3.2.y does seem to be a good one, but at some point fairly soon its support is going to end.

My point was not so much which is best now, but what happens later. Let's say Slackware 13.4 goes live with 3.2.y and shortly thereafter upstream release 3.3.0 and EOL the 3.2.y branch. Now, if you want security updates for your kernel from that point onwards you will need to go to the new 3.3 branch. But what if 3.3 is one of the stinkier ones, or is otherwise unsuitable in some way or other? You have to pray that .3.4 will be a good one and stay on the vulnerable 3.2.y until it comes out.

Now contrast with shipping 3.0.y. It will get security updates for the next 2 years, you can still install 3.2/3.3 from extra/ (if provided) or upstream if you want, but you have the fallback of following the 3.0 branch if a stinky one happens to come along at any point.

This is why I was suggesting the approach of shipping a 3.0.y kernel and glibc/headers built against it and a 3.2.y (or later) in extra/ for those who want it.

You can't know that for sure.

You make a good point, but, I am comfortable with the kernel choices that are made by the Slackware team. I have two -current boxes that are running well now with the 3.2.2 kernel and I predict that they will also run well when new kernels are added to the -current mirrors. I'm also running three 13.37 work stations which will be upgraded to (14.0?) when it is released. I don't run a stable release for several years, but, always upgrade as new releases come out.

Yes I can. Direct from the horses mouth:
http://article.gmane.org/gmane.linux.kernel/1237185


Anyway, I suspect the dev team are unlikely to downgrade now that 3.2 is already in current so it's probably too late for any of this, whether it's a good idea or not.

Again, that's Greg KH speaking.

I'll tell you what--I'll use what Pat V says to use, and you can use what Greg KH says to use.

:D

Well, Greg is the upstream stable kernel maintainer, so I'm inclined to pay attention to what he says, but fair enough. :)

It is likely that other distros who have their own kernel teams will maintain their own patch-sets, but I don't think many Slackers are likely to use a Redhat or Canonical patch-set over a kernel.org kernel, but I guess it is possible. :)

If that happens, I'd go to the next minor version.


I'm not a kernel/libc guy. May I know why libc/headers must match the minor kernel version?

I actually like 2.6.38.8 most because after removal of the BKL my harddisk suffers from a 20~25% performance penalty. Is it reasonable that I ask Slackware to stay with 2.6.38.8?

Usually userspace functions are backward compatible, but there is incompatibility with pthreads from kernel 2.4 to 2.6
(NPTL, Native POSIX Thread Library http://en.wikipedia.org/wiki/Native_...Thread_Library)

http://212.182.0.171/cgi-bin/dwww/us...ibc6/README.gz
(or /usr/doc/glibc-<your glibc version>/README :))

This rarely happens. And for this specific case it's not only libc which has problems but also the applications. Why should we only blame libc to be incompatible?

Here is the solution:
http://www.akkadia.org/drepper/assumekernel.html