Linux Kernel 4.14 Reaches End of Life After More Than Six Years of Maintenance (9to5linux.com) 22
prisoninmate shares a report: Originally released on November 12th, 2017, the long-term supported (LTS) Linux 4.14 kernel series has now reached its end of supported life after being maintained for more than six years. Renowned kernel developer Greg Kroah-Hartman announced today on the Linux kernel mailing list the release of Linux 4.14.336 as what appears to be the last maintenance update to the long-term supported Linux 4.14 kernel series, which is now marked as EOL (End of Life) on the kernel.org website. "This is the LAST 4.14.y kernel to be released. It is now officially end-of-life. Do NOT use this kernel version anymore, please move to a newer one, as shown on the kernel.org releases page," said Greg Kroah-Hartman. "If you are stuck at this version due to a vendor requiring it, go get support from that vendor for this obsolete kernel tree, as that is what you are paying them for."
Linux may not be the answer, but ... (Score:2)
... the "internet of things" and other embedded-but-connected hardware needs a widely-supported free/open/libre software stack that will be supported for the life - or at least the "online/connected" part of the life - of the hardware.
Otherwise it's a security disaster waiting to happen.
Re:Linux may not be the answer, but ... (Score:4, Insightful)
This kind of sentiment is pretty common amongst people who don't understand how software works, and how the kernel gets updated.
You're making a mountain out of a mole hill and, frankly, being a bit of a troll.
This is the kernel.org kernel being EOL'd. Ignoring for a second that this is a full 6 years of support for 4.17, and almost 10 years for the 4.x kernels through kernel.org, which is substantial. Can you name anything else receiving updates that long? Mind you, there's little reason why you couldn't upgrade to a 5.x or even 6.x kernel, and the only thing I'm aware of running 4.x kernels at this point are EOL'd RedHat/CentOS distributions which backwards companies seem to want to continue to run due to legacy requirements of their applications.
Compare this list: https://en.wikipedia.org/wiki/Linux_kernel_version_history to this list for FreeBSD: https://en.wikipedia.org/wiki/FreeBSD_version_history - kernel.org maintains kernels far, far longer.
And of course, there is nothing preventing companies or individuals from patching and maintaining 4.x or even 3.x further, either. I've done it myself on embedded systems which no longer had official support: it's linux, just rebuild the kernel with appropriate patches applied.
Re: (Score:2)
'Enterprise' distros will continue to maintain and backport security fixes from modern kernels.
What this might hurt is projects such as LineageOS where the vendor (you, Lenovo) abandoned updates long ago. Google and its partners keep promising to move to a mainline model through GKI but I have yet to purchase such a device.
Re: (Score:2)
We have products we sell that should have a twenty year life. Sure, updates will be hard in that time frame, and we're not Linux (far far too bulky), but there are long lasting products out there. We definitely have had to support systems where the firmware was at least ten years old; mostly that involved trying to find workarounds if possible so that they didn't have to upgrade firmware and hardware, but it's still "support". Ten years is a very short period of time for many products, no matter how often
Re: (Score:2)
Even for physical products, 10 years is actually fairly on the outside of things.
Take, for instance, Coleman fuel stoves. You'd think they'd all have fairly universal parts, and that they'd be readily available from Coleman - but they're not. Models that're only 10 or so years old need replacement parts from third party sources. This is more common than not.
Are there products requiring more than 10 years of support? Absolutely. But they're outliers unless you're talking about industrial control components a
Re: (Score:2)
We have products we sell that should have a twenty year life.
Not consumer products running Linux we don't. We do have corporate industrial products, and guess what, their vendors support them for that long, and are more than capable of doing so without requiring the kernel team to keep patching some outdated kernel.
Re: (Score:3)
Re: (Score:2)
That's reasonable. (Score:4, Interesting)
Let's face it. Lots of folks are sitting on old apps with neither the inclination or the resources to retire/replace them. It's a fundamental problem, especially when somebody technically astute passes through an organization and moves on. Sustainment wasn't on their mind when they cobbled together a working system that fit the need. So you live with the risk. If you have the wherewithal, you keep the box running or delegate an "old" VM to the task, put it behind all the firewalls and protections you can, and just let it be. Think 20 year old Oracle Forms and Reports, and Oracle 9i servers. Too many companies don't realize that rolling their own will leave them exactly in this place.
Lots of companies suffer from DPS syndrome - "Delicate Precious Snowflake". It's the idea that their version of business is so qualitatively different that they can't possibly use off the shelf software. In fact, most business is exactly the same - and SHOULD be done the same as most everybody else. There's no competitive edge in how you do your payroll. It's less risky to align your processes to industry standard than it is to bastardize software into acting like your wonky internals. Save custom building for the really, truly necessary things.
The maintainers aren't wrong. If it really is problematic, pay somebody else to make the problem go away. If you offer enough money, somebody will make it happen. Or at least they'll pretend they can.
Re: (Score:3)
Most business processes which become snowflakes became that way due to a combination of:
* cost
* familiarity
* inertia
"It just works" is a very valuable thing to hold onto, particularly when it doesn't have monthly maintenance costs, expensive contracting, and substantial disruption for changing to something else - even if that "something else" is what everyone else is using fluidly. THere are some very large companies using some very outdated and very kludged business processes and tools simply because the c
Re: (Score:2)
Many companies have line of business apps that start out small and then grew to become a piece of software that the business depends on. And chances are, because it probably started as a "let's just automate a bit of my job" style application, the source code was neve
Re: (Score:2)
Exactly. I've seen this repeatedly in my career. My favorite was seeing an old mainframe app that was ported to sparc Solaris and then had a web interface implemented for it... it ended up running in a VM with QEMU, and faster than it had before at that.
Re: (Score:2)
Ignoring for the moment that a lot of off-the-shelf software is objectively awful, stability is a huge problem. Not just for large companies either. Some years ago I helped a company through an upgrade to Windows 7. The problem was that they were dependent on a 30-year-old DOS application that 7 didn't like. We ended up using a custom version of dosbox together with a little bespoke application to handle printing and data sharing while they transitioned to a new system, if you're curious.
Keeping them on
6 whole years... (Score:3)
Is that a long time now?
It's no wonder kids don't care about quality. The maintenance phase has been canceled.
Re: (Score:2)
Re: (Score:2)
In most cases, you can just move to a newer kernel and not change userspace at all.
Re: (Score:2)
Yeah it is absolutely a long time to maintain a non-current point release of a single component. Just upgrade to 4.19 and you're good to go for another year and it's no more difficult than applying security patches to the kernel you already ran.
This is a complete non-issue for anyone. The only people affected are those people running products that are out of vendor support... and if they were out of vendor support then they weren't getting security backports anyway so even they are unaffected.
"support" (Score:1)
lots of current mainstream gear can run old kernels just fine, do I really need "support" for private stuff or mom and pop shop stuff?
new lines of kernels introduce new stuff that takes months or years to stabilize, after all...