Linux 4.3 Reached End of Life; Users Need To Move To Linux 4.4
prisoninmate writes: As some of you may know, Linux 4.3 was not an LTS (Long Term Support) release, so the last maintenance build is now Linux kernel 4.3.6, as announced earlier by Greg Kroah-Hartman, a renowned kernel developer and maintainer. While he's telling users of the Linux 4.3 series to update to the 4.3.6 point release, he also urges them, especially OS vendors, to move to the most advanced stable series, in this case, Linux kernel 4.4 LTS, which just received its second point release the other day. However, it appears that Linux kernel 4.3.6 is quite an update, as it changes a total of 197 files, with 2310 insertions and 963 deletions, bringing some much-needed improvements.
In the old days anybody who ran linux knew that updates were the source of new bugs. They also damage uptime.
Seriously now, who here is stupid enough to run an update only because it is new, or because they're asked to update frequently?
Why would you ever release the 4.3 branch of GNU/Linux if you have no intention of supporting it for more than a couple of months? The GNU/Linux kernel is going the way of Firefox and this is bad for users. Frequent updates that are untested reduce the quality of the software. I remember back when GNU/Linux 2.2 was rock solid and pretty much nothing could bring such a system down. The stability of the kernel has suffered in recent years, parts of the code are a mess, and this is a big reason why. Enterprise users should switch away from GNU/Linux if their software won't be supported for a reasonable amount of time and they can't trust it to be stable.
If you approach information that says a different thing than you expected, the first response should probably be to ask what you don't know, not just wave your hands and presume it is "silly." Worse, you should avoid embarrassing yourself with the claim that it is "plain" silly, because actually it is a mainstream argument that is a standard, traditional corollary to the point you did hear about that mention.
Yes, over time bugs are better known. That means they've already been mitigated. The new bugs that you don't know about, haven't been mitigated. In old-school *nix, it was normal to have ancient bugs in software specifically because it was very important to the security of the system and the known holes all had mitigation strategies.
It is still applicable. The reason a lot of youngsters these days are confused by the whole situation is that general purpose workstations that are frequently updated because they have applications that get updated, well those systems aren't locked down in the way a server is; those systems have poor security practices generally, because of the tradeoff between security and convenience. A person who doesn't care about the app updates can use the old system, and will likely be more secure even with the old bugs, if they're mitigating the ones that need mitigation.
If you ever meet a BOFH who manages secure routers, you should bring this up and ask them about it. You'll find out that the theory is well established, very strict, and has a great track record.
This is why many banks still have important code written in cobol running on `70s minicomputers. It isn't because they can't afford the upgrades, or don't like upgrading equipment; it is because the code is too important to introduce uncertainties, including the ones that fix bugs. Now, maybe you think that mainstream engineering practices that banks use is just silly stuff, not suited for serious professionals, but I would have to insist on differing.
The FCC is busy putting an end to that.
Sorry, you don't get to decide what is right for me.
If I want upstream to decide over the end user I would allow Microsoft to push Windows 10 to my Windows 7 machine.
Also, not every machine is connected to internet. If I use an old kernel on my CNC machine in the basement then not breaking microsecond timings is way more important than the next security fix. If the next security fix breaks anything I might just as well throw the machine in the dumpster. The risk of hacking is insignificant compared to being able to use the machine for its intended purpose.
Functionality first, security second. If you do it the other way around and doesn't get a brick without any form of connector you are doing it wrong.