What stable kernel should I use?
kroah.com
kroah.com
Note the lack of RedHat, CentOS, Oracle, SLES int al from this list because:
Lots of people seem to like the old, “traditional” model of a distribution and use RHEL, SLES, CentOS or the “LTS” Ubuntu release. Those distros pick a specific kernel version and then camp out on it for years, if not decades. They do loads of work backporting the latest bugfixes and sometimes new features to these kernels, all in a Quixote quest to keep the version number from never being changed, despite having many thousands of changes on top of that older kernel version.
For many years I used to roll my own and actually enjoyed going through menuconfig. My first was make config on a Slackware distro (or was it Yggdrasil?) kernel version 1.99-alpha or something from memory but looking at the WP page I had an old distro then judging by the timescale. I think it was a CDROM off the back of a book. make config took about 20-30 mins on a 2.2 kernel (from memory). I've still got a couple of Gentoo systems with kernels that were carefully genkernel'd from around 2.4 or perhaps 2.6 32 bit through to 64 bit systems today. They are classic examples of "Trigger's Broom": https://en.wikipedia.org/wiki/List_of_Ship_of_Theseus_exampl...
Nowadays apt and pacman and co do the job for me. However, I know I can still always crank out the source into /usr/src/linux (symlink) and roll my own - smashing!
Hmm. Fedora only sort of does this. Those kernels in full:
https://fedoraproject.org/wiki/Kernel
Note that the only way to get the latest stable kernel (4.18.x) is to use Rawhide, the development version of Fedora, which is very much not suitable for everyone:
https://fedoraproject.org/wiki/Releases/Rawhide#Audience
If you do the normal user thing of using the latest release version, currently F28, then you get kernel 4.17.x - i think it's currently 4.17.17. That's an EOL stable kernel, and you're not even getting the latest patch version (yet - 4.17.19 went into testing half an hour ago).
Happily, it looks like that minor version is still getting patches (kernel.org shows the last update as being on the 24th of August, the same day as the current stable, and the changelogs are very similar - the current stable has a few more patches).
However, AIUI, the kernel developers could stop patching 4.17.x at any time now, and that means that F28 would not receive any further kernel fixes.
Perhaps this is just a necessary consequence of Fedora's release model. Or perhaps not. Is there a good reason they couldn't change minor versions of the kernel in the updates to an existing release?
Usually it's possible to get a build of current stable or mainline kernel in a day or two on Fedora, through koji. And through updates-testing repo (opt in) a few days later. And through updates (enabled by default) anywhere from 1-5 days later. The system depends on testers using updates-testing repo to give +/- points to each tested package, and the kernel comes with a higher than usual minimum number of points and time delay to avoid regressions.
You can (manually) install kernels in Koji which don't always show up right away in the updates-testing repo. So you'll see 4.18.5 there for fc29 which can be installed on Fedora 28 (I've been doing this for weeks). And you can also manually install 4.17.19 which is already built there, just not yet in updates-testing. https://koji.fedoraproject.org/koji/packageinfo?packageID=8
4.17.18 has already gone stable in the updates repo, so anyone doing a 'dnf update' now will get it. https://bodhi.fedoraproject.org/updates/?packages=kernel
I might be totally wrong about this.
The latest and LTS kernels are both a tyre fire of routine, often serious regressions.
Are there any good providers of enterprise-grade support for upstream LTS kernels, the way Red Hat and Canonical support theirs? I could see that as a viable (and perhaps cheaper?) alternative to a RHEL license in some cases.
RedHat and Canonical provide support for a distribution. As part of that support, they maintain a kernel.
If you are actually in a position where you need support for the kernel as a standalone component, you probably would be better off working with the upstream developers anyway (or hiring someone to work on the LTS release to address your specific needs).
Stable mature device drivers for one. You might have petabytes of data connected and want to ensure it is stable as possible. So the vendor makes sure that the right kernel and and right device driver works with exactly your device firmware etc.
The BSDs had a major head start on Linux 20-25 years ago but they just sat back became lazy & laughed at Linux, while Linux ate their lunch.
;)
This comment adds no value. No one would seriously wonder that, nor would anyone endorse it, nor does it need to be discussed because all of that's so obvious.