Linux 3.14 out | Hacker News Reader

Linux 3.14 out

lwn.net

158 pointsarunc61 comments

Not updated yet, but here it goes: http://kernelnewbies.org/Linux_3.14, with the caveat that:

> /!\ /!\ /!\ WARNING /!\ /!\ /!\ : This page is not complete and it's missing lots of critical information.

Also: https://lwn.net/Articles/581657/, https://lwn.net/Articles/582352/, https://lwn.net/Articles/583681/, http://www.phoronix.com/scan.php?page=news_item&px=MTYzNDg and http://www.reddit.com/r/linux/comments/21sxiw/linux_314_rele....

http://kernelnewbies.org/Linux_3.14#head-72b295b09fea85de2e8...

zram swap has really sped up my workstation laptop, so I'm pleased to see it in 3.14. I've been running zram in place of a swap partition for about three weeks now. I notice Vim opens faster, as do Chromium bookmarks.

Right now I'm having to use an unofficially supported shell script to get zramswap [1]. Hoping official support is on the way.

1: https://aur.archlinux.org/packages/zramswap

That's a much more compelling-looking changelog! Good to see the anti-bufferbloat work proceeding apace.

Hey, the first kernel release with a patch from me in it! It's just a typo fix in a comment, but hey, it's a start.

At least you can put "Linux Kernel Contributor" on your CV now.

Ah, you've seen that comic come by on reddit too, eh?

http://i.imgur.com/6KQCx89.jpg

Excellent! My code will now finally work as intended! I used: `uname -r` * r * r and 2 * `uname -r` * r .

`tex --version` may be a better choice.

This should've been in my never-ending history:

  $ tex -v | head -n1 | awk '{print $2}'
  3.1415926

but it wasn't (I distinctly remember using this line to prove a point a few months ago).

I wonder if this means that 3.14 will make it into Ubuntu 14.04. Would be nice not to have a franken-kernel for a LTS release.

Ubuntu 14.04 already uses 3.14 kernel in daily images. You can download the .deb from here. http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-trusty/

It's possible, as the Kernel Freeze is on April 3rd (https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule).

I would assume that 3.12 would be used instead since it's the latest long-term stable release of the kernel.

If they don't use 3.14 they won't have complete Intel broadwell support. Since those chips will come out and be the primary source of new 14.04 installs, they either need to release a point release with a new kernel around the product launch or get 3.14 in now.

Of course they could backport those patches to their kernel.

The kernel and X stack get regular backports over the life of the LTS release (since Precise):

https://wiki.ubuntu.com/Kernel/LTSEnablementStack

I think that would then be the first time that Ubuntu LTS is piggybacking on an LTS kernel. With 3.12 already 6 months old that seems unlikely to me given Ubuntu's usual attempts to support modern hardware.

FWIW I'm already using 14.04 beta2, and the kernel there is 3.13.0-20. This means the stable version will be 3.14, doesn't it?

Kernel freeze is April second so this means that they "should" be able to update the kernel to 3.14 but its Ubuntu and you never know.

Why would you conclude that?

I remembered odd versions were unstable, but looking at the kernel info, 3.13 is a stable version. So I'm guessing they'll stick with that.

> I remembered odd versions were unstable

this stopped being true very long ago (with the beginning of the 2.6 series)

TIL :)

I upgraded to the 14.04 LTS beta and uname -r returns 3.13.0-19-lowlatency for me.

Not according to http://www.phoronix.com/scan.php?page=news_item&px=MTY0NTc

No risks for an LTS release I guess.

Bummer. On the flip side, maintaining a franken kernel for multiple years isn't fun either so one would think this be a pro in favor of 3.14.

Oh well, at least OpenSSH 6.6 made it in.

LTS releases should probably stick to a kernel that will have long-term stable support. One example is GKH's (Greg Kroah-Hartman's) stability kernels: http://www.linuxfoundation.org/news-media/blogs/browse/2013/...

Understandably launching ubuntu 14.04 with and older kernel is less than ideal, but launching on a kernel that will lose support in 6 months is probably a worse idea.

The first change:

> make prepend_name() work correctly when called with negative *buflen

Reminds me a lot of a different article in this week's LWN: http://lwn.net/Articles/591959/

which I would describe as exceedingly disconcerting. An excerpt:

> So areas like huge pages, page migration, and the mbind() system call have been fertile ground. In the case of mbind(), it turned out that all callers were going through a user-space library. That library did argument checking, so, naturally, the system call itself did not.

Finally good kernel for docker with AUFS.

Also, we're possibly one step nearer to Plan9's portable /bin concept (where each user overlays her binaries with those provided by the system).

So I tried looking around for info on this but my Google-fo is kind of weak. If you are still following these comments can you expound on this? It sounds very, very interesting.

Try this to start:

http://plan9.bell-labs.com/sys/doc/names.html

What do you mean by this? AUFS wasn't merged in this release cycle.

Is it me or they accelerated the pace of Linux kernel releases ?

It's because our silly little brains think there is a bigger difference between 3.12 and 3.14 than between 2.6.30 and 2.6.32.

When really the prefixes 2.6 and 3 are equivalent in meaning, and the real difference between 12 and 14 and 30 and 32 is also exactly the same.

Human brains seem to be evolved to think about numbers in a logarithmic fashion. We stop to think for a long while to debate whether to spend 50 or 75 bucks on a piece of clothing, while we can't perceive the difference between spending 50,000 or 50,025 thousand on a car. The difference would have to be 50,000 to 75,000 thousand for us to perceive it equally.

> We stop to think for a long while to debate whether to spend 50 or 75 bucks on a piece of clothing, while we can't perceive the difference between spending 50,000 or 50,025 thousand on a car. The difference would have to be 50,000 to 75,000 thousand for us to perceive it equally.

A bit off-topic, but I've read about this irrational thought pattern before, and it strikes me that it's not that irrational. In general, one buys a car far less frequently than one buys a piece of clothing, so saving 25 bucks every time one buys a piece of clothing is going to add up to a lot more than saving 25 bucks every time one buys a car. The expense of a purchase correlates with how rare that type of purchase is, so it seems sensible to me.

It's you. Linux has followed a bi-monthly schedule for quite a while now.

FYI: https://en.wikipedia.org/wiki/Linux_kernel#Maintenance

While this is true, I have the same feeling as jmnicolas since Linus released version 3. I guess it's because of the new release numbering scheme. Let's not forget that we had 2.6 for close to 8 years!

I see more posts about it in Hacker News and Reddit, but other than that nothing much has changed since 3.0 regarding version numbering and scheduling and that was in 2011.

I always like Linux kernel names, but can't find this one. Does it have a name?

Shuffling Zombie Juror (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...)

From the RC1 announcement (http://lwn.net/Articles/583929/):

  I realize that as a number, 3.14 looks familiar to people, and I had
  naming requests related to that. But that's simply not how the
  nonsense kernel names work. You can console yourself with the fact
  that the name doesn't actually show up anywhere, and nobody really
  cares. So any pi-related name you make up will be *quite* as relevant
  as the one in the main Makefile, so don't get depressed.

  Besides, any self-respecting geek will know pi to twenty decimal
  places from their dorky youth, so 3.14 isn't really *that* close, is
  it?

Aww, it could at least have been named "Shuffling Zombie Pie"!

Well, the 3.14 series (including RCs) is all named the same it seems:

Shuffling Zombie Juror

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

Ah okay, thought the RC version was different. Thanks!

A round of congratulations pies around!

Does this mean that all future Linux releases will have version numbers converging towards Pi, like TeX?

No, the next one will be 3.15!

Deleted comment

the same reason every other big software release is news

Did this reach HN's front page due to it being "Linux π", or is there some particular significance to this realease?

3.14 = pi which is always a special number. Who knows.

Besides Linux powers almost everything on the internet, (almost) all of the world's smartphones and tablets, routers, NASes, millions and millions of embedded devices, not to mention desktops, Chromebooks, clouds and developer machines.

If you raise your focus up past your hipster Macbook and decaffed latte, even a small Linux release is a pretty big thing.

> (almost) all of the world's smartphones and tablets

Almost none of which will ever run this particular Linux kernel release.

Given the regularity of the kernel release schedule, it seems to me that a release would have to include something particularly interesting (not just support for yet another processor and yet another file system) in order to qualify as newsworthy on a general interest news site like this one.

If you think that Hacker news is a "general interest news" site then you clearly have no idea what the general public is actually interested in.

I can see the point of having a Macbook but what's the point of a decaffed latte? Surely it is just like drinking milk? There's no caffeine power to be extracted!

> If you raise your focus up past your hipster Macbook and decaffed latte, even a small Linux release is a pretty big thing.

Oh, burn!

It's Linux :) Usually every release get on the frontpage.

Anyway, yes, I'd say that this one is a pretty big release, if only for the several BTRFS patches, DEADLINE mainlained, DPM support for newer AMD gpus and Intel Broadwell graphics (hd 6000?) support considered stable.

is btrfs production quality yet ?

According to the documentation, no:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

"Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review. The Btrfs disk format is not yet finalized."

That said, I know lots of people use it day-to-day just fine. I think some distros even default to it these days.

That file is a bit old, it hasn't been updated since 2009 - While it might not be production-ready, it's not as bad as it does sound (for example, the disk format is finalized, and shouldn't get any changes in the future).

Something a bit more up to date (but still a bit old) can be found on the btrfs wiki: https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.... and https://btrfs.wiki.kernel.org/index.php/Main_Page#Stability_...

As for the distros, I think none of the big ones default to it yet, but it's definitely a first-class citizen in OpenSUSE (and should be the default fs in OpenSUSE 13.2, according to the official plains).

The wiki hasn't been updated for the last few kernel versions either. I think the only place to get good information right now is the IRC channel, #btrfs on freenode. webchat.freenode.net/?channels=%23btrfs

I sure don't know - I've been using it for a while on my desktop system without any problem, but my usage is pretty light (compress/autodefrag enabled, snapshots with snapper before and after every system update, beside that I just use it as a normal filesystem).

For what it's worth, it's considered production quality by SuSE with SLES.

It's incredibly relevant to the half of us here who care more about technology than acquisitions.

Reply on news.ycombinator.com