Linux Kernel 3.18 Reaches End of Life (softpedia.com) 101
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.
Re: (Score:3)
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.
Re: (Score:3)
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 a
Re: (Score:1)
I mean, once you get to 2.99.99 then what? /p>
Then you get 2.100. Quite simple really.
Re: (Score:3)
So basically you remember the present?
Re: (Score:3)
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 c
Re:Process? (Score:2)
Re: (Score:2)
This is what I come to slashdot for. The intelligent and well articulated discussions about news for Nerds and Stuff that Matters.
Re: (Score:1)
Re: (Score:3)
I can tell by your Nick that your an intelligent, smooth-spoken and reasonable individual.
Re: (Score:2)
The Linux Colonel [imgur.com]
Re:Linux colonel - I like this better (Score:1)
Could this week get any worse? (Score:4, Funny)
First we lose Richard Hatch; now it's Linux kernel 3.18. Man...
Re: (Score:1)
Why don't you just go Make America Great Again.
Re: (Score:2)
You must be one of those misogynistic, fascist, racist Nazi individuals.
Re: (Score:2)
Re: (Score:2)
Mary Tyler Moore, etc. 2017 just started! :O
Linux Kernel release process is broken (Score:3, Insightful)
Re: (Score:2)
No, a pocket pussy.
Re: (Score:2)
Nah, ole slick carries a cigar.
Re: (Score:2)
When he grabs your pussy he Makes America Great Again!
Re: (Score:2)
Last I checked the Linux kernel had 4672 bugs. Something is clearly wrong with the release process.
Last I checked, Microsoft wouldn't tell us how many bugs the Windows kernel has. The safest thing is to assume that the number is infinite. Something is wrong with Microsoft's release process.
Re: (Score:1)
"Performant" (Score:2)
I like articles that use real words (ones in the dictionary). Acronyms for technical terms is one thing, and brand names as well, but this is neither.
Re: (Score:2)
It is in the dictionary
http://www.dictionary.com/brow... [dictionary.com]
It is to performer as informant is to informer.
Re: (Score:2)
Re: (Score:2)
It is in the dictionary
http://www.dictionary.com/brow... [dictionary.com]
It is to performer as informant is to informer.
The use of the word here is as an adjective.
Your definition is of a noun.
Re: "Performant" (Score:3)
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."
Re: (Score:2)
Hate to burst your bubble, but performant is in the dictionary.
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."
That is a very well-formatted dictionary entry.
Now, post the actual link to the actual source.
Re:dictionaries (Score:1)
3.18? That's pretty new. (Score:2)
My phone is stuck on 3.4.42. Thanks Google (and Lenovo now I guess)
I suppose it's still supported though, until April 2017
Re: (Score:2)
The problem is that Google doesn't mainline any of their changes. It rots in their "open source" repository and they reuse those code lines for new products long after it is wise to do so because some derivative hardware isn't supported by mainline.
Googles open source philosophy is far from collaborative. They unilaterally change things without any thought about how it might affect other people. That is incompatible with the Linux kernel development.
Re:3.18? That's pretty new. (Score:5, Insightful)
Don't phone manufactures base their kernels on the ones provided by the SoC supplier, like Qualcomm, etc?
Third Party Support (Score:1)
Linux is open source. Support doesn't have to come from kernel.org. Linaro are supporting 3.18 until December 2018 [linaro.org]. There may be other vendors committing to maintaining the kernel with at least security fixes for longer.
Distros. Red Hat supports 2.6.18 through 2020 (Score:4, Informative)
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.
Should say "RHEL *5*. Supported 2007-2020, 13 year (Score:2)
The second sentence is missing the version number. That should say:
For example, Red Hat Enterprise 5, released in 2007 with kernel 2.6.18, has some support from Red Hat until November 30, 2020.
For Red Hat 6 (kernel 2..32), they'll soon stop adding support for new hardware and it'll be security fixes and important bugs only. That may work for me until 8 is released. I prefer not to replace the OS more than once every ten years or so, so I'de prefer to skip version 7.
Re: Distros. Red Hat supports 2.6.18 through 2020 (Score:2)
I just set up a new server running CentOS 7, kernel 3.10. Good to know it will be well supported into the future. I also pay for KernelCare, so I don't have to think about security patches.
I still have a CentOS 6 server running 2.6.32 in a KVM virtual machine. It's thoroughly embedded with cPanel/WHM so upgrading it will be a pain in the butt.
I use Funtoo Linux everywhere else, and have recently deployed 4.9 across the board on all of my (in production) Funtoo servers.
Turn off SuExec (and fix your file permissions) (Score:3)
> 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 accou
Re: (Score:2)
Thanks for the advice.
The purpose of KernelCare is that they splice security patches into the kernel while it's running. That is what I was referring to in regards to not having to worry about security patches, and to further explain, I meant I don't have to worry about rebooting (and thus causing down time) after applying kernel security patches.
I'm well aware of the problems with suExec and suPHP (and suHosin, etc).
I used mod_ruid2 up until they finally incorporated support for ITK [sesse.net]. This specific server o
It seems I was unclear (Score:2)
It seems my post was unclear. It *may* also be that you are so comfortable with your current knowledge that you are somewhat resistant to unfamiliar ideas. If that's so, that's fine. I've made a LOT of money over the last 20 years cleaning up rooted servers run by people who thought they understood this issue.
> ITK. ... This allows each account to have permissions of 0600
Whether you do suexec using mod_suexec, php_suexec, mod_ruid2, or mpm_ik doesn't really matter, either way the *effective* permiss
Re: (Score:2)
I'm not certain you understand how MPM ITK works.
For each request, MPM-ITK will accept the incoming request, check the headers and determine which VirtualHost it belongs to. From there it will fork off a process and setuid/setgid's the process to the VirtualHost's defined uid/gid before handling the request. It's important to note that it uses setuid and setgid, NOT seteuid and setegid. Once that process is forked off, it's permissions are permanently set to the defined UID/GID.
It's important to note that a
Do you run FTP with no password? (Score:2)
It's your server, you can of course do what you want. I'm just giving you information about how 90% of malware infections occur on web sites. For twenty years I've been remediating compromised servers, and this is how it normally happens.
> From there it will fork off a process and setuid/setgid's the process to the VirtualHost's defined uid/gid .. which has full permission to change any and all the files on the site.
> It's important to note that all SSH, and FTP daemons work in a very similar way.
Do
Re: Do you run FTP with no password? (Score:2)
Adding a password doesn't inheritly make it any more secure.
We're talking about protocols and internet facing applications.
The daemons accept connections as a root user, then forks off another process and setuid/setgid the process before handling the request. In the specific cases of FTP and SSH, the authentication still done by the root user. If there is an exploit at this level, authentication does absolutely nothing.
With MPM-ITK, all it does at the root user level is accept the connection, then hands the
Re: (Score:2)
I think you seem to believe that having all user accounts readable by the apache process is a better security model.
Personally, I don't want all of the users able to snoop on each others files.
I would rather have a site be able to nuke its own files, but stay isolated to that uid/gid, than be able to read files in other accounts.
Proper offsite backups make this a non issue for my situation.
Re: (Score:2)
> I would rather have a site be able to nuke its own files, but stay isolated to that uid/gid, than be able to read files in other accounts.
Sounds like you understand the trade-off. For me, I know that 99.99% of files in document_root are there for the express purpose of being made available to the public - that's why they are on the web site. Therefore I'm not TOO worried that people who have FTP/ssh access on the server can read those files. I'm *much* more concerned that visitors can add malware to t
Re: Do you run FTP with no password? (Score:2)
> That's great that you have proper offsite backup which you test on a regular basis, and retain several copies of backups from different times, so you can restore to a copy that was made *before* the malware was added, the site deleted, etc.
Indeed. I do. Like I said, I'm not new to this.
> Since you have that, you may be able to fairly easily have the backup process report which files changed, filtering out the files that are supposed to change regularly. That way you won't be serving up malware for m
Re: Do you run FTP with no password? (Score:2)
*continued, accidentally tapped the submit button*
These aren't the 'cheap' hosts either. Some accounts were costing upwards of $25USD per month for less than 1GB of storage. I'm not sure if any of them are still around.
ATM? (Score:2)
They are still supporting ATM? I am really curious because I actually wrote ATM code. Fifteen years ago. Both device drivers and stack code. Great stuff, but that is ancient history. Can anyone tell what ATM has done in the last decade? Thanks!
Define "long term." (Score:5, Insightful)
3.18 was released slightly over 2 years ago (7 Dec 2014 [omgubuntu.co.uk]). It went LTS 3 months later (2015/3/11 [softpedia.com]). 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 [kernel.org], 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)
Re: (Score:3)
This, exactly. There's no reason to expect my phone or chromebook to need a new major kernel update within 2 years of purchase. Considering the development time in advance, I'd expect a tested kernel to be several months old before the device even launches.
Re: (Score:2)
This, exactly. There's no reason to expect my phone or chromebook to need a new major kernel update within 2 years of purchase.
Of course there is - 'it's the economy, stupid!'. Nobody who makes portable consumer electronics wants you to have the same hardware two years after you bought it - they want a new one in your hands and fresh money out of your bank account by then. Never mind what that does to the environment and to non-renewable resources, and never mind what kind of world we're leaving to our heirs.
Re: (Score:3)
Yelling is usually a sign a bad social skills, as is recommending to yell. It is just not how normal people behave.
And I agree he is just trying to detract from the fact that he promised something and did not deliver. 2 years is nothing - not enough even for the fast moving Ubuntu distribution, and certainly not enough for embedded development. Once the device is released, you usually do not want to change kernel versions, so 5 years would be more useful.
Here's my uname -a (Score:2)
Re: (Score:2)
ifconfig -a |wc -l
And the answer:
1
Re: (Score:2)
Whoopdedoo. Linux 2.2 still works fine AT THE BOTTOM OF THE OCEAN. Not much of an attack surface exposure down there. There are plenty of Windows XP boxes in labs, with well-controlled access and no exposure to the internet, doing in-house work, un-patched for many years and without any anti-virus, that are still perfectly reli
Who cares about Android updates (Score:2)
Who cares about Android updating beyond 3.18 if they aren't even updating the patches within 3.18?
Assume the OS you get when you buy your Android device is going to be the last update for it ever.
Who cares about EOL... (Score:3)
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 [kernel.org]. The current version of the 3.4 branch is 3.4.113 (source [kernel.org]), 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.
Re: (Score:2)