The Many New Features & Improvements Of The Linux 4.5 Kernel

[AJSB]

You must be running really old hardware then as there's a ton of exciting stuff if you're using a lot of latest hardware.

I agree and even for "old" hardware there's important things like the rework done with PS/2 mouses.
Yeah, i game with a PS/2 mouse, everybody that's not a noob gamer knows:

PS/2 > USB
CRT > LCD

OLED might finally give the colour quality and fast response of a CRT but i have concerns about durability, colour shifting during lifetime...and price 8O

[andre30correia]

after a great 4.4 a weak 4.5

[tajjada]

Stop exaggerating. Many new features ? Many bits here and there, but rarely something noteworthy, especially not something that would be really significant for some particular machine. I'm not criticising, just stating the obvious. Gone are the days when we updated to each new kernel the day it was released. I'm still on 4.1.15 and I estimate that I won't have reason to upgrade at least to 5.0, if not later.

Just because it is not interesting for you doesn't mean that others don't find it noteworthy. Everyone has different use cases and preferences.

I, for one thing, am very excited for 4.5 because of the ARM stuff and the NVMe, f2fs, and btrfs stuff.

I frequently find myself eager to upgrade to a new kernel the day it is released, because there is almost always something interesting for me. The exceptions were 4.2 and 4.3, which had a nasty bug with affected me, which got fixed in 4.4. That bug was forcing me to stay with 4.1 for a while, even though I wanted to upgrade. (again, personal, highly-specific use case, probably not relevant to many other people, some of whom must have been really excited for these kernel versions, for their own reasons)


tl;dr: not everyone cares or uses the same features as you

[pjezek]

after a great 4.4 a weak 4.5

Bowl!

[ewheelerinc]

Hi Michael,

I know you tried to benchmark bcache some time ago, and it had some serious bugs that made that difficult---but those have been fixed!

Would you consider a SSD caching benchmark of bcache, dm-cache (both smq and mq policies) now that bcache should be stable in 4.5? We've been running these patches since 3.17 and its solid. It even does journal replay in the event of a crash (which would be interesting to compare against dm-cache).

Since these improvements make the difference between usable and unusable, would you consider adding bcache to the list of improvements on your two posts here?

http://www.phoronix.com/scan.php?page=article&item=linux-45-features

and here

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.5-Kernel-Week-One

?

See git log 2ef9ccbfcb90cf84bdba320a571b18b05c41101b~1..627ccd 20b4ad3ba836472468208e2ac4dfadbf03

-Eric

[rob11311]

I, for one thing, am very excited for 4.5 because of the ARM stuff and the NVMe, f2fs, and btrfs stuff.

I frequently find myself eager to upgrade to a new kernel the day it is released, because there is almost always something interesting for me. The exceptions were 4.2 and 4.3, which had a nasty bug with affected me, which got fixed in 4.4. That bug was forcing me to stay with 4.1

Great post! I think it's simply HOT that work's going into BTRFS freespace code for fileystems > 30TB. I remember having my hands on the first (IBM) 1GB HDD, which seemed incredibly vast at the time; I can remember capacities of 20MB and such, L3 caches are almost as big now

Be brave, do yourself and everyone else a favour, when Linus say.. here is an rc kernel, try and give it a spin, perhaps at rc2 or rc3 stage. The reason is, IF they break your hardware, you want to pipe up and say you have a REGRESSION. Major distro's are generally good at having optionally installable bleeding edge kernels available, as their kernel teams are keen to facilitate wider spread of testing (developers tend to have mostly similar nice new shiny stuff). Compiling from source, is doable but frankly less recommended, you may be relying on hardware drivers or features your distro patched in. Generally not though, it's just a pain to compile these days on a typical desktop machine, thanks to the huge amount of source & modules built.

[tajjada]

Great post! I think it's simply HOT that work's going into BTRFS freespace code for fileystems > 30TB. I remember having my hands on the first (IBM) 1GB HDD, which seemed incredibly vast at the time; I can remember capacities of 20MB and such, L3 caches are almost as big now

Be brave, do yourself and everyone else a favour, when Linus say.. here is an rc kernel, try and give it a spin, perhaps at rc2 or rc3 stage. The reason is, IF they break your hardware, you want to pipe up and say you have a REGRESSION. Major distro's are generally good at having optionally installable bleeding edge kernels available, as their kernel teams are keen to facilitate wider spread of testing (developers tend to have mostly similar nice new shiny stuff). Compiling from source, is doable but frankly less recommended, you may be relying on hardware drivers or features your distro patched in. Generally not though, it's just a pain to compile these days on a typical desktop machine, thanks to the huge amount of source & modules built.

I always configure and compile my own kernels. Mostly because I have had to do it so many times in the past (for all kinds of hardware platforms, including non-x86 embedded systems) that the process is very familiar to me and doesn't take much time and effort. My PC is also quite fast; I typically only have to wait around 1 min to build a kernel with all the modules I want.

That said, I would not test a -rc kernel on my main machine. While I do have backups of my important stuff that I care about the most, I just can't keep *recent, up to date backups* of absolutely everything, and I also have a lot of data that I do not necessarily care a lot about, but would still prefer not to lose. I don't want to risk installing something that can break all my stuff. It would certainly *not* be doing myself a favour (as you were saying).

On other systems, though, yeah sure. My laptop (Acer Chromebook 13 running Gentoo, NVIDIA Tegra K1 ARM SoC/processor) is my main experimental machine, and I do all kinds of crazy things there (and report bugs when they don't work).

Recently I built a Gentoo system based on musl libc rather than glibc (I love musl ... the RAM usage (or rather, lack of it) was astonishing, my system with all the daemons I wanted, etc, used only 9MB of ram), running kernel 4.5-rc5. Something went wrong at some point, and the btrfs rootfs on my sdcard got corrupted. I could not manage to gather enough information for a bug report, have no idea what actually happened; it happened somewhat randomly after a few unclean poweroffs and doing all kinds of things to the filesystem on my desktop (with an older kernel) as well as on the laptop. Too many variables to know anything for sure.

[cb88]

I always configure and compile my own kernels. Mostly because I have had to do it so many times in the past (for all kinds of hardware platforms, including non-x86 embedded systems) that the process is very familiar to me and doesn't take much time and effort. My PC is also quite fast; I typically only have to wait around 1 min to build a kernel with all the modules I want.

That said, I would not test a -rc kernel on my main machine. While I do have backups of my important stuff that I care about the most, I just can't keep *recent, up to date backups* of absolutely everything, and I also have a lot of data that I do not necessarily care a lot about, but would still prefer not to lose. I don't want to risk installing something that can break all my stuff. It would certainly *not* be doing myself a favour (as you were saying).

On other systems, though, yeah sure. My laptop (Acer Chromebook 13 running Gentoo, NVIDIA Tegra K1 ARM SoC/processor) is my main experimental machine, and I do all kinds of crazy things there (and report bugs when they don't work).

Recently I built a Gentoo system based on musl libc rather than glibc (I love musl ... the RAM usage (or rather, lack of it) was astonishing, my system with all the daemons I wanted, etc, used only 9MB of ram), running kernel 4.5-rc5. Something went wrong at some point, and the btrfs rootfs on my sdcard got corrupted. I could not manage to gather enough information for a bug report, have no idea what actually happened; it happened somewhat randomly after a few unclean poweroffs and doing all kinds of things to the filesystem on my desktop (with an older kernel) as well as on the laptop. Too many variables to know anything for sure.

9Mb is still alot really... Linux 2.x or so I believe it was used to run in 4Mb with X. I've heard people say musl can still boot in 4Mb so you must have quite a few services running there (if they are small or maybe a big/medium sized one)