The best solution for almost all Linux users is to just use the kernel from your favorite Linux distribution. Personally, I prefer the community based Linux distributions that constantly roll along with the latest updated kernel and it is supported by that developer community. Distributions in this category are Fedora, openSUSE, Arch, Gentoo, CoreOS, and others.
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!
I would put Debian Testing on that list. Although it's called "testing", it's at least as much stable as Arch and very suitable for the desktop user, Debian's "edge" release is unstable (codename sid).
Why is Debian testing lagging behind with uploading newer kernels? There is already 4.18.4 upstream release, and Debian unstable / testing still don't have any options past release candidate from experimental.
my understanding is that Debian/Ubuntu preference ABI stability within a release - and that ABI stability is not guaranteed going between kernel branches. I believe this is also the case with CentOS/RHEL too.
I don't know specifically about why 4.18.x hasn't entered sid (unstable) yet but generally this means that uploading to sid may break other packages in some way, or the new version has something new that is still not packaged, integrated and tested properly with the rest of unstable packages.
> Personally, I prefer the community based Linux distributions that constantly roll along with the latest updated kernel and it is supported by that developer community. Distributions in this category are Fedora
Hmm. Fedora only sort of does this. Those kernels in full:
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:
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?
Fedora regularly rebases to the latest stable kernel, usually by .2 or .3 release; but 4.18 has had quite a busy series of rapid fire updates, so it's already at 4.18.5. I expect to see that in Fedora 27 and 28 updates-testing this week.
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
Very interesting to see Greg’s perspective on upstream LTS kernels vs. what he calls “traditional” distributions with their own downstream LTS, like RHEL, Centos, Ubuntu-LTS etc.
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.
Don't see much of a market for that. Ubuntu LTS is new enough and the kernel is upgraded frequently enough, that there isn't much point in going with something slightly newer than that and expecting enterprise support.
What does enterprise-grade support for a kernel look like?
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).
> What does enterprise-grade support for a kernel look like
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.
Obviously not, though you don't need to hear the answer nor ask the question.
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.
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!