Linux Kernel 4.5 Officially Released
prisoninmate writes: Yes, you're reading it right, after being in development for the past two months, Linux kernel 4.5 is finally here in its final production version. It is internally dubbed "Blurry Fish Butt" and received a total of seven RC builds since January 25, 2016. Prominent features of Linux kernel 4.5 include the implementation of initial support for the AMD PowerPlay power management technology, bringing high performance to the AMDGPU open-source driver for Radeon GPUs, scalability improvements in the free space handling of the Btrfs file system, and better epoll multithreaded scalability. The sources are now available for download from kernel.org.
Update: 03/14 13:24 GMT by T : Reader diegocg lists some other notable features (a new copy_file_range() system call that allows to make copies of files without transferring data through userspace; support GCC's Undefined Behavior Sanitizer (-fsanitize=undefined); Forwarded Error Correction support in the device-mapper's verity target; support for the MADV_FREE flag in madvise(); the new cgroup unified hierarchy is considered stable; scalability improvements for SO_REUSEPORT UDP sockets; scalability improvements for epoll, and better memory accounting of sockets in the memory controller), and links to an explanation of the changes at Kernel Newbies.
I recently did a quick survey in Reddit on people's experience on suspend/hibernate, and I may summarize it simply by saying that Linux is not the best performer in this area. :D It's a shame that such an important laptop feature works so poorly. Some might say that it's because OEMs do not "support ACPI spec properly", but in practice most PCs don't... It could be more practical to just find the patterns that Windows uses, and imitate them.
One really weird thing is also that backlight adjustment requests are sent to both ACPI and GPU, which causes double backlight adjustment events on many laptops.
People fight about SystemD, various open source licenses, differences between DEs, filesystems, but at the same time there's these fundamental problems which should get way more attention. Sometimes it feels like we are in a house arguing what kind of wallpapers bring the best experience, while that same wall is infested with mold inside.
Some people still talk like this is supposed to be the hi-tech kernel that breathes new life to my PC. Are they blind to all this stuff happening?
Linux does not come with stable driver interface, so drivers supplied by vendors would rot quickly. It's more practical to just bundle everything with the kernel, update the driver interfaces there, and recompile. However this has the additional benefit that one does not have to hunt drivers around Internet, so if you have the most recent kernel, you also have all the most recent drivers.
Are you seriously still complaining about this?
The last odd kernel was released in 2003. In 2.6 stable and unstable merged. Kernel 3.0 wasn't even a drastic change.
https://lkml.org/lkml/2011/7/2...
Between 2.4 and 2.6 linux was drastically overhauled. We really don't need separate non stable versions anymore. Plus version control is far better now.
It is internally dubbed "Blurry Fish Butt"
Rumor has it that the next kernel will be named "Lennart's buttery balloon knot".
Oh dear, I definitely feel old age sneaking up on me; I just don't find these names funny any more. If ever I did. I'm all for having a sense of humour, but it would be refreshing if it wasn't always stuck up our own backsides. Can't we raise the level a bit? (Groan, I shouldn't have said that - now it's going to be about tits instead, isn't it?)
You are confusing things. The drivers are part of the kernel's sources, but you can either build them compiled-in or as modules that are then loaded when needed.
Thanks for the link. I actually read through that, and while some of the arguments were certainly valid, some of them sounded an awful lot like simple justification for how Linux chooses to do things. For example, rapidly changing internal API interfaces is something of a self-fulfilling prophecy when you assume you can just change the interface of any drivers for which you have the source. He acknowledges that it would be more work to maintain older, depreciated interfaces, and claims that they couldn't impose such a burden on volunteer programmers. It may be true in some cases, but that argument seems a little weak with the knowledge that these days most contributors today are actually paid by a corporation for their work on the kernel.
This sentence is of particular note: "...get your kernel driver into the main kernel tree (remember we are talking about GPL released drivers here, if your code doesn't fall under this category, good luck, you are on your own here, you leech)..."
This attitude is both the strength and weakness of Linux. It works FOR Linux as an open platform, but certainly AGAINST it as a commercial one, if a manufacturer doesn't wish to open-source their drivers - and that unfortunately includes video card manufacturers, which is also a major issue for Linux. If a commercial vendor feels unable to release open source drivers for their proprietary hardware for whatever reason, then Linux is simply *never* going to work reliably on their hardware.
More importantly, because client machines tend to be much more reliant on the subtle interfaces and behaviors of many complex drivers (headless servers don't have to worry about nearly as much), I believe that this philosophy is a large part of why Linux remains something of a second-class citizen on the desktop. I'm not saying this philosophy is necessarily wrong, but I think it's important to understand that it definitely comes with some tradeoffs.
Irony: Agile development has too much intertia to be abandoned now.
As I recall, the older versions of the kernel added some features and offered others as third party patches. The 2.0.x, 2.2.x, 2.4.x, and 2.6.x branches were supported for a very long time, (...) This was a very successful development model for over a decade and I don't understand why that's changed. Arguably, it would require fewer work since there wouldn't be as many branches to maintain.
Actually it wasn't. Distros were massively cherry-picking from the odd-numbered branches creating huge variations from the stock kernel, creating strange bugs and making the big jumps was a huge pain because the more relaxed requirements to put it in a development branch led to poor quality. Linus tightened ship and basically said do development in your own branch, when it's ready merge it to the released kernel and ~2 months after the merge window closes it'll be released instead of years like the old kernel. No more hodge-podge development kernels full of half-assed changes. It got distros to work more on the upstream kernel than their own variations, leading to more manpower and higher quality in the core project. It was a great success.
Live today, because you never know what tomorrow brings
I don't think Lennart's got tits. But, he does have nipples. Lennart's Nubian Third Nipple...
Hmm... Nope, still not funny. Maybe they'll aim higher?
"So long and thanks for all the fish."
One can obviously debate the value of this; but my impression is that, while in an ideal world they'd like to be able to support more hardware, when it comes down to it the Linux project really isn't interested in just providing a cheap OS for people to put on top of their giant heap of binary blobs. They certainly aren't as hardline as the FSF; but even the 'engineer-pragmatist' types see binary blobs as an impediment to their work(that's why the kernel taint flag exists: if your system crashes, you have a potentially interesting bug report; but if it was 30% Nvidia blackbox by weight at the time, they don't want to waste their time shooting in the dark).
no doubt you've been testing the next LTS version in the mean time, you can move to that
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
I don't think Lennart's got tits. But, he does have nipples. Lennart's Nubian Third Nipple...
Hmm... Nope, still not funny. Maybe they'll aim higher?
"Lennart's Tiny Head" : Linux 4.7, includes the systemd NFSA io secheduler, the systemd NFSA job scheduler, as well as the systemd "do it all as init 1" replacement for the Linux graphical subsystem. Enjoy.
Yeah, but does it run Linux?
As of last week, "Does it run MS SQL Server?" is the new "does it run linux".