Slashdot Mirror
Linux Kernel 3.18 Reaches End of Life (softpedia.com)
prisoninmate quotes a report from Softpedia: Linux kernel 3.18.48 LTS is here and it's the last in the series, which was marked for a January 2017 extinction since mid-April last year. According to the appended shortlog, the new patch changes a total of 50 files, with 159 insertions and 351 deletions. It brings an updated networking stack with Bluetooth, Bridge, IPv4, IPv6, CAIF, and Netfilter improvements, a couple of x86 fixes, and a bunch of updated USB, SCSI, ATA, media, GPU, ATM, HID, MTD, SPI, and networking (Ethernet and Wireless) drivers. Of course, this being the last maintenance update in the series, you are urged to move to a newer LTS branch, such as Linux kernel 4.9 or 4.4, which are far more secure and efficient than Linux 3.18 was. But Linux 3.18 appears to be used by Google and other vendors on a bunch of Android-powered devices, and even some Chromebooks use Linux kernel 3.18 on Chrome OS, so here's what the kernel developer suggests you do if you can't upgrade. "If you are _stuck_ on 3.18 (/me eyes his new phone), well, I might have a plan for you, that first involves you yelling very loudly at your hardware vendor and refusing to buy from them again unless they cut this crap out. After you properly vent to them, drop me an email and let's see what we can come up with, you aren't in this sinking ship alone, and it's obvious your vendor isn't going to help out," said Greg Kroah-Hartman in the mailing list announcement.
First we lose Richard Hatch; now it's Linux kernel 3.18. Man...
#DeleteChrome
Last I checked the Linux kernel had 4672 bugs. Something is clearly wrong with the release process. Imagine if it took an airline 1-2 years to return your lost luggage?
From The Fucking Dictionary:
Performant
Adjective:
1. Capable of or characterized by an adequate or excellent level of performance or efficiency.
"Our software is more performant than our competitor's."
Now, if you'll excuse me, I have backups to corrupt.
That's not a fair comparison. Releases are done very differently now. Also version schemes of old kernels don't match version schemes since 3.0, so that might mislead younger people.
Also the 2.4 kernel was the one that just wouldn't die. It was maintained until 2011. I guess 2.6 was just too drastic of a change for some folks.
Most distros will support their long-term kernels well after kernell.org moves on. For example, Red Hat Enterprise, released in 2007, with kernel 2.6.18, has some support from Red hat until November 30, 2020.
RHEL 6,RHEL 7, and their debranded CentOS twins provide important security updates for ten years. I use CentOS 6, kernel 2.6.32, supported from 2010 to 2020. I'll probably switch to CentOS 7 (or 8) in 2018 or so.
"yelling very loudly at your hardware vendor and refusing to buy from them again unless they cut this crap out"
3.18 was released slightly over 2 years ago (7 Dec 2014). It went LTS 3 months later (2015/3/11). At the time, "it will be supported with patches for at least two more years from today." Now it's gone, less than 2 years later. And, 2 years isn't "long term" by any reasonable definition to begin with. Don't yell loudly at anyone who used it, yell loudly at Greg Kroah-Hartman and the other kernel maintainers for over-promising and under-delivering, who think 2 years is a long time and won't even keep that commitment. 3.16 (LTS) is projected to go to 2020, when it's 5 1/2 years old (kudos to Ben Hutchings, who's a bit more realistic about what "long term" means).
(and of course, anyone the size of Google should be able to put their own resource on maintaining a kernel they chose to use for longer if need be, not that they've figured out how to keep Android devices up-to-date anyway)
"National Security is the chief cause of national insecurity." - Celine's First Law
Don't phone manufactures base their kernels on the ones provided by the SoC supplier, like Qualcomm, etc?
What's the process for determining what version of Linux Slashdot runs on?
> so I don't have to think about security patches. ...
> cPanel/WHM
If you care *at all* about security and are running Cpanel or even worse Plesk, you probably want to make to turn off SuExec. Both php suexec and cgi suexec. Basically what suexec does is give all visitors to your site *permission* to change all of your files. In all likelihood one of your PHP scripts gives them the *mechanism* to do so.
Suexec was designed for servers with a thousand hosting customers who have $20/year hosting accounts all on the same server. It has some marginal utility in such a case, protecting customers from each other, though the documentation opens with a warning from the suexec developers "you shouldn't even consider enabling suexec unless you thoroughly understand the security risks". It can't possibly do any good whatsoever on a dedicated server running one site (unless you're planning to attack yourself).
Unfortunately, Cpanel made it easy to enable, after a developer there failed to read even the first few sentences of the suexec documentation.
If it's enabled, your file permissions amd owmership are a little screwed up. Files written by the web server are owned by your login and chmod 644. (That appears to make them unwriteable by visitors, but remember suexec basically bypasses permissions). After disabling suexec, files which *should* be writable by scripts need to be chmod 666, marking those files (and *only* those files) as writeable.
I can tell by your Nick that your an intelligent, smooth-spoken and reasonable individual.
Who cares about EOL, when the firmware of your device includes a fixed kernel image which won't be updated, ever?
I mean, my current Android phone (using Marshmallow) employs a kernel 3.4.42, released on April 2013. The current version of the 3.4 branch is 3.4.113 (source), released on October 2016. I don't know if there are any critical (security, performance) improvements from 3.4.42 to 3.4.113, but I simply don't care becase I know the manufacturer won't publish an updated version of the firmware with a recent kernel. If a serious kernel security bug appears and it is solved in a new kernel version, it won't be solved in my device. The situation is way better when you consider Linux desktop distributions, but still...
What I mean is that for at least 99% of the people, the kernel is an atomic part of the firmware of their device (phone) and they won't bother about updating it. With this in mind, there should be no recommendations to the final users ("yelling very loudly" because your Android phone employs a given kernel version, haha), EOL is only significant for upgradeable systems. Not even phone designers need to worry about using LTS: they know they will never update their kernel.
So basically you remember the present?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Yes, Enterprise Linux 6 (Red Hat, CentOS, Scientific Linux, Oracle, others) is still supported, and run 2.6.32
The rapid change in kernels with incompatibilities between versions has become a big problem, especially in business settings. Software like VMware is unlikely to work after upgrades, and not just because kernel modules have to be recompiled, but because they won't recompile.
Then the business choice becomes "don't upgrade the kernel", and choosing distros that won't upgrade them and only backport critical patches.
Something happened with the transition from 2.4 to 2.6. When distros started shipping with 2.6, linux stopped being the answer to using old hardware. It fell as slow and sluggish as any other OS would (except maybe DOS). My fathers Celeron 300A was a great illustration of such, as well as the Compaq laptop my nephew once owned.
I think the bigger kicker was 2.6 wasn't drop in compatible to 2.4. A lot of things changed (like linuxthreads->NPTL) and with it, so did the libraries that shipped with it. Old applications (Kylix) were dead in the water
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson