RHEL7 has another year[0] of support left (until August 30, 2021), and is based on kernel 3.10 [1], which was released in 2013 [2]
RHEL 8 is expected to see support through 2029, and is based on kernel 4.18, which was released in 2018.
Redhat does backport changes, but tends to avoid backporting feature changes.
If you want to be able to use "recent" features of software, you are probably not running running Redhat But, many companies prefer the stability of systems that have been battle tested, and so are perpetually years behind the bleeding edge in terms of features.
I don’t mean to start an off-topic debate on this, but I just have to say that personally, I run into issues caused by using old software on our EL7 boxes all the time. For example, cgroup memory limits are broken on Red Hat 7 kernels as far as I can tell (most versions have a memory leak, but iirc the most recent has a panic instead). They’re missing all sorts of features that are useful for usability or reliability.
I’m just personally not convinced we really win much with the trade off as a society :p
Memory control group code is replete with bugs throughout 4.x kernels, way beyond RHEL 7. This is one of the big problems with getting locked into "LTS" kernels. It takes a long time to discover all the nameplate features that don't actually work.
Are there any "RHEL considered harmful" posts? That project is one of the most damaging things for the Linux ecosystem IMO. It forces companies on to ancient outdated compilers and library versions that are full of bugs.
Well, when I quit the place we both worked, the production kernel was 3 years behind and rolling forward at .5 years/year, so that implies 6 years to get current.
The next company I joined is using RHEL's 2.6.32 in production, more than 10 years after its release.
Have you asked whether you're able to use newer kernels, at least on your subset of hosts?
I've been having pretty good luck at work just asking for kernel updates - though it helps that I'm willing to stare at oopses and kcore dumps and userspace regressions (they happen!) on the canary machines.
Ah, yes, but all software is 10 years old and full of exploitable security holes and weak algorithms if you're constrained to FIPS, so the kernel isn't a special case :)
Only if your organization submits to the stupidity of the FIPS 140-2 consultant scam. Google has this level of certification and they obviously aren't using vendor kernels (or vendor anything). At Google the production kernel was, in many ways, newer than the one you could download from kernel.org
you state that "Google has this level of certification" as if it is a certification which applies to organizations. It does not. Specific hardware and software cryptographic modules are given FIPS 140-2 certification. Google currently has 8 cryptographic modules which have active FIPS 140-2 certifications. 5 hardware and 3 software. The software modules are all versions of BoringSSL. Google can replace their kernel as they wish because they don't use the cryptographic api's in the kernel for anything which requires the use of a FIPS140-2 cryptographic module. Not everyone is in that position or they use a commercial Linux OS in which the non-kernel certified cryptographic module provided is available on only certain releases. If they want support for their OS they must therefore use the kernel provided with that release of the OS.
Thanks for expanding on my simplistic remark. Have you considered offering your services as a FIPS consultant? Because my ex-Google experience with this aspect of the industry is that management hires a consulting firm who come in and says things like everyone must use this RHEL kernel, this (incredibly broken) openssl and so forth. Those consultants are not offering the nuanced perspective to the management, who aren't technical enough to understand it anyway. So the word comes down from the top that we're married to kernel 4.15 until the end of days.
