Hacker News new | past | comments | ask | show | jobs | submit login
Linux 4.12 Released (lkml.org)
208 points by slyzmud on July 3, 2017 | hide | past | favorite | 74 comments



Linus says it's a large release, here's a numeric breakdown of recent kernel releases, showing number of commits, diff | wc, and a diffstat with/without the drivers/ directory:

    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(-)
Via:

    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}


That is to say, a net addition of over a million lines in one release.


If you use ubuntu, install the kernel from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12/


And don't forget about the updated firmware drivers

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.


Shameless plug: I wrote a small tool which allows users to update the kernel to the latest version or rc build, since this is not really a ppa exposed as apt repository:

https://github.com/cristim/kernel-update


I have always been tempted. Is there any reason not to?


Not Ubuntu, but Debian: have been running Debian stable with unstable kernels for a while. Never saw any issues. Application packages generally do not have hard dependencies on specific kernel versions but, as always, YMMV.


I do the same, haven't had any issues so far.


No, you generally should.

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`


> The only way application interact with the kernel is via SystemCalls

Well yes, but more than the syscall contracts are e.g. the layout of /proc and /sys. Which have broken userspace before.


I hear what you are saying but I wouldn't say that stat vs stat64 is incorrect or wrong. It is due to 32 vs 64 bit fields inside of the stat struct. But yeah, it all comes down to maintaining ABI and not breaking userland.


Drivers might break though.


In real world, it may give you zero tanglible improvements (only virtual ones), against a variable amount of maintenance overhead.

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).


> I have always been tempted. Is there any reason not to?

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.


Marvell mwifiex cards seem to be broken past ~4.9. git.marvell.com is down so I can't check for new firmware, either.


I wonder this as well. Might a kernel update not break some applications or make the system less stable?


Linus is pretty big on kernel updates not breaking userland it's been the topic of several flames. Not that that's perfect or a guarantee but it is a priority among the devs.


Yes, he hates that with a vengeance, here's the classic thread. https://lkml.org/lkml/2012/12/23/75


That's actually a bit recent to be "classic" but it is a great example.


It's probably safe since rolling release distributions upgrade just the kernel and work fine. I'd watch out for the graphics drivers though--sometimes you need to recompile them with the new kernel headers or just use the DKMS version.


I've bought new laptop recently with Kaby Lake processor and put Ubuntu 17.04 on it, so the kernel upgrade was kind of necessity. No adverse effects observed, and on the plus side: somewhat better battery life, Asus USB-C docking station working correctly, including Gigabit Ethernet port, resolved issues with sleep/resume.


What laptop if you don't mind me asking?


Dell XPS 13 (9360). I know, they sell those with Ubuntu pre-installed, but they are hard to come by in my country, so i bought Win10 version and installed Linux myself


It can happen. There are a bunch of bots that do regression tests, Fedora's Rawhide provides daily debug builds of the kernel with merges in-between the rc's, so there are are some real humans also using the kernel through its development. If you check the 4.11.1 changelog as an example you can see the kinds of things that can crop up. Fedora current releases tend to rebase around x.y.2. So you could use that as a way to weigh your kernel conservatism.


It might make some hardware unusable.

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.


So maybe a stupid question for me - but since all the answers here say that new kernels generally don't break userland, then... what do I get from an update? Security fixes? Faster syscalls? Because otherwise I can't think of changes that would affect me in any way without updating rest of the userland.


Major distros backport security fixes. I'd say improved hardware support is 90% the reason to upgrade to a new kernel. Algorithmic improvements (like bfq) and new syscalls/subsystems are infrequent and one might not be able to make use of them immediately unless libs/userland adapt quickly.


I have been consistently updating linux kernels on by ubuntu machines. Apart from docker images going awry. I haven't experienced any other issue.


Linus Torvalds breaks into a childish tantrum of (edit: correction: swearing rants are technically coherent), public swearing at people whenever anyone anywhere in Linux kernel development breaks any userspace app. As a consequence, userspace regressions are rare.

(Might contain traces of hyperbole—still; Linus' behaviour is largely unacceptable nonetheless)


Linus is very well known for his rants, but you've definitely mischaracterized them. He's seldom incoherent, and the ones that are vulgar enough to make for juicy sensationalized "news" are only ever directed at contributors who are experienced enough to know better than to break userspace or something badly wrong like that. His more level-headed corrections of well-meaning inexperienced developers don't make the news.


"only ever directed at contributors who are experienced enough". That's not strictly true, see e.g. https://lists.freedesktop.org/archives/dri-devel/2017-Februa...


I'm not seeing where the ire was directed at anybody new. The two messages Linus sent were in reply to a pull request from Dave Airlie, a very high-level and extremely experienced developer. Daniel Vetter tried to chastise Linus for chewing out some new contributor named Noralf, but it appears that the real problem is that the problems with Noralf's code went unfixed by intermediaries like Vetter and Airlie and made it all the way to Linus.

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.


Props to Daniel for defending the contributor, as I'm guessing they wouldn't feel comfortable arguing back with Linus.


To me it reads like redirecting blame to the contributor by appearing to "defend" him. Linus was obviously replying (and chastising) the person who sent him the code, and who was supposed to review it beforehand, not the original author.


https://lists.freedesktop.org/archives/dri-devel/2017-Februa...

Yep, that's right: "I'm upset, because I expect better quality control. In fact, I expect some qualitty[sic] control."


Ah, I guess I should have read the previous emails that led up Daniel's response


You might not like his method of cat-herding, but historically, it has worked pretty well. That summarizes the way I feel about them.

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 think Linus' method of communication is unnecessarily coarse and sometimes abusive.

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.


I think you're conflating two different things. Yes, Linus is very strict about not breaking userspace. But the swearing doesn't come from some void somewhere: it is directly aimed at enforcing the rules of not breaking userspace.

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.


you can apparently choose the least professional communication style-- littered with cursewords and personal insults

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".


Please, the rants are most definitely completely coherent.


M code isn't up to snuff, but I still check the mailing lists - just to see his rage manifest. As near as I can tell, you're mostly okay so long as you don't break userspace. Mostly...

They are a beautiful thing. People may not like it, but the efficacy is beyond doubt.


Well, sometimes there could be a bug lingering around. But that could be the case with any software. Probably just keep the old kernel around as well. Just in Case.


for anyone needing further instructions, you'll want the generic .deb files for your architecture (not low-latency unless you know what that is):

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


This lacks linux-tools and thus breaks cpu frequency and cpu governor management tools (cpupower, TLP, etc).

For reasons unknown Fedora's RawhideKernelNodebug repo includes that package but Ubuntu's doesn't :)


Thank you, exactly what I needed.


sudo apt add-repo'able? thanks for pointing this out


you can download "ubuntu kernel update utility" (ukuu) for an easier way to install and remove kernels, but you likely won't find a PPA that'll deliver you point releases as they come for the latest mainline


Yay! I think this is the one that means unusually much to me, as the nouveau NVIDIA GTX 970 fix is part of it. Pretty much all popular Linux distros "fails" (black screen on boot unless the nomodeset boot option is used) on this fairly common graphics card, until proprietary drivers are installed.

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


I had to disable my GPUs and use Intel so I could get inside and manually install NVIDIA driver. I don't have much experience with setting boot options. Shouldn't have to take 2 years to fix, though, but I guess it was a weird card.


Could someone say something about the new "BFQ I/O scheduler"? I was not aware of the work being done, and the goal to have a more reponsive desktop


http://algo.ing.unimo.it/people/paolo/disk_sched/

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.


CFQ is best for mechanical hard drives not sure if it is updated for SSDs, deadline and noop seem better for SSD


There's another new IO scheduler for SSDs: Kyber,

https://patchwork.kernel.org/patch/9672023/


anyone do benches say using fio with this vs. the default scheduler?

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


Aiui kyber is designed for providing consistently low latency, e.g. for desktop users. And maybe specific user-facing server workloads? Those benchmarks mostly seem to test throughput, so are not good at showing the intended effect.

You would want to see something that shows 99th percentile latency of individual reads/writes.


yeah i came to that same conclusion. I may need to do my own testing using Fio.


Why is this being downvoted? AFAIK, this is mostly true.


Random OT question: how can you tell when a comment that isn't yours is being downvoted? I've seen comments like yours a few times before, but I can't see the karma on individual posts. Is there a karma threshold for being able to see this (like the 500 karma threshold for being able to downvote)?


You can tell because the font color starts to fade out till you can barely read the text.


Interesting; I'm unable to notice this on the comment being discussed with my current setup (Firefox on Linux)


That's because it was upvoted back to black since then :)


Haha fair enough


wasn't the downvoter, but general statements like that don't include context of workload (i.e. is it a desktop or server, gaming pc, etc.) so different i/o schedulers would be optimal for different scenarios


I think atomic mode-setting for the intel DRM driver being default now is the most interesting feature for my configurations: https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Atomi...


Breaks rr I believe :(. In fact there were two regressions of that sort introduced this release cycles. One was caught early enough to get fixed, I guess the other wasn't.


Where can I read of the details of that. RR has always seemed like magic to me as a non-systems programming amateur.


Mailing List threads:

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:

http://marc.info/?t=149609949000002&r=1&w=2


Unfortunately, proper AMD Vega support didn't make it in.


> In the diff department, 4.12 is also very big, although the reason there isn't just that there's a lot of development, we have the added bulk of a lot of new header files for the AMD Vega support

Not the one downvoting you but: are you sure?


Only headless support did. So if you want to play games - no dice. That's why I said proper above.


I believe that is just header files. Actual support comes after.


This is a bit... opaque. Here is a lot of more-readable information about what's in the release, and some links to more editorial content. https://kernelnewbies.org/Linux_4.12


Thanks, we've updated the link from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... to the official release announcement.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: