Linux 4.12 Released
lkml.org
lkml.org
v4.7..v4.8:
14552
1331854 5068427 42175318
11363 files changed, 627754 insertions(+), 279373 deletions(-)
6657 files changed, 329595 insertions(+), 167605 deletions(-)
v4.8..v4.9:
17392
1419476 5372905 44206994
11179 files changed, 632159 insertions(+), 354871 deletions(-)
5993 files changed, 214842 insertions(+), 120945 deletions(-)
v4.9..v4.10:
14249
1463146 5668517 49833479
11726 files changed, 744012 insertions(+), 249810 deletions(-)
5884 files changed, 329130 insertions(+), 115189 deletions(-)
v4.10..v4.11:
13891
1227388 4763853 39671475
12506 files changed, 530154 insertions(+), 232410 deletions(-)
6230 files changed, 209555 insertions(+), 95502 deletions(-)
v4.11..v4.12:
15736
2025692 7383431 88754335
12396 files changed, 1300537 insertions(+), 267064 deletions(-)
5829 files changed, 215764 insertions(+), 124745 deletions(-)
parallel -k 'r=v4.$(({}-1))..v4.{} ; echo $r: ; (git rev-list $r | wc -l; git -c diff.renameLimit=10240 diff $r | wc; git -c diff.renameLimit=10240 diff --shortstat $r ; git -c diff.renameLimit=10240 diff --shortstat $r -- ":!drivers/") | sed -r "s/^ *//; s/^/ /"' ::: {8..12}https://packages.ubuntu.com/artful/all/linux-firmware/downlo...
When going latest kernel it makes sense to have the latest firmware otherwise certain kernel features wont work.
Those Linus tirades about We Dont Break Userland are why. The only way application interact with the kernel is via SystemCalls, which once they go public are -never- retracted, and never significantly change.
This is why the kernel has system calls like 'mlock' and 'mlock2', because the first call ended up being incorrect but YOU CANT TURN BACK NOW! Or a better example `stat`, `stat64`, and `statx`
Well yes, but more than the syscall contracts are e.g. the layout of /proc and /sys. Which have broken userspace before.
Aside the obvious manual download and installation, if you use ZFS and Ubuntu LTS for example, it's messy, because the shipped ZFS version won't support the most recent kernel, so you'll have to separately download the ZFS packages from the most recent Ubuntu. This is just an edge case of course.
Also, distributions like Ubuntu LTS now provide stable kernel upgrades, so that you're not significantly far from the latest versions (16.04.3 will ship shortly, and will likely have 4.10 or more recent).
Ultimately, it really depends on your machine. If you have recent hardware (eg. Skylake), then definitely new versions will bring compatibility (along with updated `linux-firmware` package).
I've been using mainline versions for the last years, due to recent hardware, and didn't have any problems (aside the ZFS issue, which made me move to BTRFS).
There is a small chance that something will break, which is usually either the wifi or graphics drivers on desktop systems.
Now let me ask you, is there any _reason_ for you to upgrade? Another poster mentions better laptop battery life but it could easily go the other way on some systems. Are you having trouble with any hardware? Unsupported webcam, etc? If not, then you're encouraged to upgrade the kernel as a learning experience but if your priority is stability and you don't have an evening to risk investing, then you should probably wait for Ubuntu to provide the update.
If you are relying on some hacks or proprietary drivers for wifi support or GPU support (as is normal in Linux world), it might break.
(Might contain traces of hyperbole—still; Linus' behaviour is largely unacceptable nonetheless)
The kernel shouldn't let bad code into the tree just because the author is inexperienced. Subsystem maintainers are supposed to be a very thorough filter, so that the patches reaching Linus are up to standard. When bad code makes it to Linus, it's his job to complain about it. And based on that thread, it looks like he was complaining about it, and was not directing the complaints at the original author but at the people who were responsible for reviewing and testing the code.
Yep, that's right: "I'm upset, because I expect better quality control. In fact, I expect some qualitty[sic] control."
It is a time-tested leadership method to make an example out of a hapless mistake-maker to keep the rest of the herd in line. And it isn't like that sort of thing doesn't happen in the corporate world; it is just that corporate dressings down (down-dressings?) don't happen on public mailing lists.
Not my preferred tactic, but in the odd world of Linux kernel development, it certainly works.
I also think that the scant, ineffectual pushback against his unprofessionalism-- especially when considering the fame and size of the Linux community-- serves to emphasize the much greater significance of his "don't break userspace" dogma.
"Don't break userspace" keeps developers from rationalizing regressions as a necessary step in the service of progress.
"Don't break userspace" allows little players to leverage Linux without worrying about a big player making problems (purposely or not) for their use case.
"Don't break userspace" keeps big players from leveraging usage statistics as a weapon against little players.
"Don't break userspace" has probably streamlined development discussion during every tenuous period in Linux' history by taking a class of bikeshedding off the table.
"Don't break userspace" neutralizes paranoiacs who would otherwise conclude that fixing a broken interface was really just an excuse for [insert three letter government agency here] to [insert insidious plan here].
"Don't break userspace" essentially disarms the entire Linux community and provides a path to a surprisingly fast development cycle.
If you think I'm exaggerating, look at the outrage against systemd where the (development community) rhetoric isn't nearly as coarse or abusive. Or even look at the discussion on the SVG list around Chromium deprecating the awful SMIL interface (which was never even in IE or Edge and never will be). You would have thought Google was was suspending habeus corpus for all the rhetoric around that decision.
That is how important "don't break userspace" is to a healthy, functioning development model. Have only that and a license like the GPLv2 and you can apparently choose the least professional communication style-- littered with cursewords and personal insults-- and still maintain one of the most successful open source communities in the world.
If Linus didn't occasionally get angry about it the people below wouldn't take it as seriously, and the kernel wouldn't as stable a target.
This is silly. Linus has written (tens of?) thousands of completely "professional" messages. A few outbursts over the 25 years of kernel development are not a choice of "the least professional communication style".
They are a beautiful thing. People may not like it, but the efficacy is beyond doubt.
linux-headers-4.12.0-041200_4.12.0-041200.201707022031_all.deb
linux-headers-4.12.0-041200-generic_4.12.0-041200.201707022031_amd64.deb
linux-image-4.12.0-041200-generic_4.12.0-041200.201707022031_amd64.deb
then just $ sudo dpkg -i *.deb in the folder containing the files, and then a reboot, and $ uname -a to verify you're on the correct kernel
For reasons unknown Fedora's RawhideKernelNodebug repo includes that package but Ubuntu's doesn't :)
Apparently 4.12 fixes a VRAM detection issue. I guess regarding the shenanigans by NVIDIA where they put 3.5 GB on this gfx card, and then 0.5 GB more in a slower variant (that I supposed is presented differently to the kernel). They went into a lot of trouble and bad PR for that so I think it's safe to say they won't do it again anytime soon.
Here's the bug thread: https://bugs.freedesktop.org/show_bug.cgi?id=89664
https://lwn.net/Articles/601799/
tl;dr:
> CFQ separates each process's I/O requests into a separate queue, then rotates through the queues trying to divide the available bandwidth as fairly as it can.
> The BFQ I/O scheduler also maintains per-process queues of I/O requests, but it does away with the round-robin approach used by CFQ. Instead, it assigns an "I/O budget" to each process.
nvm: http://www.phoronix.com/scan.php?page=article&item=linux-412...
You would want to see something that shows 99th percentile latency of individual reads/writes.
http://marc.info/?t=149861183900003&r=1&w=2 http://marc.info/?t=149864742900002&r=1&w=2
Oh and the one that got fixed:
Not the one downvoting you but: are you sure?