Linux 4.4-rc7 Kernel Officially Released

[phoronix]

Phoronix: Linux 4.4-rc7 Kernel Officially Released

Linus Torvalds has taken a break from the holidays to announce the seventh weekly release candidate for the Linux 4.4 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.4-rc7-Released

[blackiwid]

hmm is that not first a bit less to make a story of, but ok thats subjective.

But I have problems to see a tagging of a "release candidate" to be a release. Isnt it the idea that its only a candidate that could maybe be the release? But if you mix in even the Officialy it gets even more weard.

I try to make sense of it in my main language, would I say, "Ein kandidat fuer eine Veroeffentlichung, wurde veroeffentlicht" I doubt that, maybe its because english has not anough alternative words for release, but tagged is what its called under git, and why not take that. also there is no word about the Release Information in this linked mail, you call it that way, maybe I overanalyse your chosen words a bit, but having a news about a candidate of a release is weared enough, choosing this wording seems to me, a way to make look more reasonable.

Correct me if I am wrong and that words makes more sense for native english speakers, just again if somebody dont know rc is the shortform of release candidate.

[Azrael5]

I don't know if it is question of kernel but X-FI xtremegamer and similia have BUS MUSTERING disabled on linux systems, so audio is stated as DUMMY OUTPUT from audio console.

Audio processor used by these kind of cards is EMU20K1 (CA20K1)

[Dea1993]

Archlinux still using kernel 4.2, 4.3 still in testing repo..
It is taking time very

[Benjamin_L]

Archlinux still using kernel 4.2, 4.3 still in testing repo..
It is taking time very

yet you could compile 4.4rc6 (soon rc7) from the AUR

[Dea1993]

yet you could compile 4.4rc6 (soon rc7) from the AUR

i know but i don't want compile.. it take too time

[darkbasic]

Is it possible to know which bug is holding 4.3 in Arch? It usually takes much less time.

[haagch]

For archlinux "Miffe" has a linux-mainline package with rcs:

http://arch.miffe.org/README.html

[SystemCrasher]

i know but i don't want compile.. it take too time

Yet ubuntu users can grab Michael's kernel. Or just kernel from PPA. Isn't it funny ubuntu can beat Arch in terms of fresh stuff without compiling it? Yet, compiling kernel isn't really hard (just grab working config file as starting point) and some tweaks could be fairly interesting. E.g. maintainers are trying to target some average case, but one size poorly fits all. And actually, it can make a lot of sense to review kernel settings used by maintainers. As example, ubuntu's "low latency" kernels aren't that low latency and using intermediate settings. I.e. only voluntary kernel preemption. However, full preemption is better in terms of latency and I failed to notice any issues or performance degradation. Or, say, decompressing LZMA kernel takes 1 second. Sounds fast? Not when whole boot sequence ends in below 5 seconds thanks to SSD, hence 20% of wasted time getting noticeable. Changing just 1 option to make it LZ4 squashes down 1 second. Not too bad, eh? And pays for itself in just few boots - it is really fast to toggle kernel compression method during other changes . And it also nice if I can sign modules with my own key and show my middle finger to kernel mode rootkits. This way I can both freely tinker since I posess private key, and attackers can't load their modules since I've really forgot to give 'em my kernel signing key build system has created for me . And last but not least, waiting for releases and even RCs could be lame & boring.

[SystemCrasher]

Is it possible to know which bug is holding 4.3 in Arch?

Not sure about arch, but overall kernel 4.4 proven to be quite a bumpy ride. E.g. they introduced new memory security feature meant to detect if kernel attempts to access user-mode memory. While it supposed to catch breakins, it also broke my legit ARM systems. I've had quite hard time figuring out what has fell apart - my ARM systems are usually set up to panic and autoreboot on any noticeable problem, resuming service from known good state, because I'm not a big fan of running system with potentially corrupted RAM data/code, and this thing counts as noteworthy kernel problem as well, so it caused fancy random reboots, without being obvious why and it took quite some time to figure it out. Then some staging drivers proven to be broken up to degree it is FTBFS. Whoa, this was literally first time git Linux kernel gave me FTBFS kind of error. Not really hard to chop off offending driver, but still it takes attempt to build it and investigation why this attempt has failed. Ironically, I've corrected problem like an order of magnitude faster than ubuntu team did. Hopefully it explains why I could be ok with building kernels myself - waiing maintainers can get annoying, dammit