Linux Distributors' Alliance Continues Long-Term Support for Linux 4.14

"Until recently, Linux kernel developers have been the ones keeping long-term support (LTS) versions of the Linux kernel patched and up to date," writes ZDNet.

"Then, because it was too much work with too little support, the Linux kernel developers decided to no longer support the older kernels." Greg Kroah-Hartman, the Linux kernel maintainer for the stable branch, announced that the Linux 4.14.336 release was the last maintenance update to the six-year-old LTS Linux 4.14 kernel series. It was the last of the line for 4.14. Or was it?

Kroah-Hartman had stated, "All users of the 4.14 kernel series must upgrade." Maybe not. OpenELA, a trade association of the Linux distributors CIQ (the company backing Rocky Linux), Oracle, and SUSE, is now offering — via its kernel-lts — a new lease on life for 4.14.

This renewed version, tagged with the following format — x.y.z-openela — is already out as v4.14.339-openela. The OpenELA acknowledges the large debt they owe to Kroah-Hartman and Sasha Levin of the Linux Kernel Stable project but underlines that their project is not affiliated with them or any of the other upstream stable maintainers. That said, the OpenELA team will automatically pull most LTS-maintained stable tree patches from the upstream stable branches. When there are cases where patches can't be applied cleanly, OpenELA kernel-lts maintainers will deal with these issues. In addition, a digest of non-applied patches will accompany each release of its LTS kernel, in mbox format.
"The OpenELA kernel-lts project is the first forum for enterprise Linux distribution vendors to pool our resources," an Oracle Linux SVP tells ZDNet, "and collaborate on those older kernels after upstream support for those kernels has ended." And the CEO of CIQ adds that after community support has ended, "We believe that open collaboration is the best way to maintain foundational enterprise infrastructure.

"Through OpenELA, vendors, users, and the open source community at large can work together to provide the longevity that professional IT organizations require for enterprise Linux."

All users of the 4.14 kernel series must upgrade

[Valgrus Thunderaxe]

Sorry, I don't take orders for you, Mr. Hartman.

Re:

[backslashdot]

At your own risk. You trust Oracle to give a shit about you? Hahaha. They're only doing this to keep making money, they don't want their customers to re-evaluate their spending decisions. No way the OpenELA companies are going to put their best and brightest on it. Do you think their best and brightest want to work on maintaining old shit?

Re:

[bill_mcgonigle]

Maintenance work requires different people vs new product development:

O: Low, High
C: High, Medium
E: Low, Medium
A: High, Low
N: High, Low

There is nothing wrong with either type!

We should care less about new hotness and realize that a washer that lasts twenty years is more valuable than one that can play Doom.

Re:

[HiThere]

I totally agree that software shouldn't be upgraded at the cost of working versions.

OTOH, I also feel that anyone who trusts Oracle is crazy.
(That said, my computer is only a bit over a decade old, but I'm starting to think about replacing it.)

Re:

[backslashdot]

Not following how the OCEAN traits thing matches and why.. can you clarify.

Re:

[gweihir]

You are apparently also incapable of understanding the language used. Because that was not an order. That was a strongly worded reminder that 4.14 is out of maintenance, nothing else.

Re:

[Cyberax]

Sorry, I don't take orders for you, Mr. Hartman.

Greg KH (the maintainer of the stable kernels) used to work as a bouncer in a bar. Just saying. You might want to heed his "advice".

Re:

[Cyberax]

A very obscure LKML post: https://lwn.net/Articles/44221... [lwn.net]

I can easly handle such people, being a bit bigger than that, and lots of experience being a bouncer at a punk-rock bar for a number of years.

Re:

[thegarbz]

Sorry, I don't take orders for you, Mr. Hartman.

It wasn't an order. It was a requirement if you wanted to receive security updates. You're more than welcome to continue to work against your own self interest.

Yep

[Anonymous Coward]

I maintain several older kernels.

The problem is that the newer the kernels get, the less quality there is. That's in addition to the bloat that creeps in. Newer kernels are actually completely broken on some hardware that Linux used to (or is suppose to) support.

Part of the problem is due to the work from 3rd party developers. Sometimes they half-ass implement something then never fix it so now the kernel is stuck with garbage (eg. Skylake).

Re:

[djgl]

And since there is someone who maintains the old version the people that need these old kernels for their hardware never put any effort in making their hardware work with the current version.

Re: Yep

[jrnvk]

Not only that, but there is also a bit of a blind trust issue with respect to the Linux kernel specifically. While in the older days, it was relatively easy to spot major issues with code, the sheer number of changes submitted makes this an impossible endeavor. Very little is scrutinized when it should be, sometimes because the reviewer trusts the source.

4.x ? We maintain 2.x and 1.3, bruh, no sweat.

[Seven Spirals]

I've backported many patches to 2.6 kernels from much newer source trees, mostly security-related stuff. This is because we support a lot of customers who run RHEL6 and didn't want to upgrade to RHEL7. I know "the buzz" was all around System==D and such, but it appears quite a few folks (mostly in government and Fortune-100 companies) just demured. I cannot talk about most of the environments because they are NDA'd or part of government contracts. We have people who run Red Hat Linux, too (not RHEL or RHAS, the original Red Hat). Some people don't want to upgrade and just don't have to. They'd rather have someone like me port critical patches and just let the systems run, more or less. I know this makes some folks head's explode and I love that. It's the most satisfying type of trolling I've ever experienced.

Re:

[djgl]

What makes you sure that you backported _all_ critical patches?

Re:

[Seven Spirals]

How do I know I "got them all" ? I don't and I didn't care, either (still don't). The issues we backported fixes for were the ones the customer cared about based on CVE issues they were required to fix because of their security policies. I didn't make the call on what they wanted, neither did Greg KH, they decided what they cared about (imagine that!). Most of the stuff is ridiculously hard to exploit or is still theoretical (crypto changes) anyway. It's hard for me to take 90% of it seriously but that's ok

Why don't they volunteer

[szo]

to maintain those old releases? I'm sure it can be arranged to be maintained in-tree, why do it in a seperate location?