Please create an account to participate in the Slashdot moderation system


Forgot your password?
Open Source Upgrades Linux

Linux 3.7 Released 151

The wait is over; diegocg writes "Linux kernel 3.7 has been released. This release adds support for the new ARM 64-bit architecture, ARM multiplatform — the ability to boot into different ARM systems using a single kernel; support for cryptographically signed kernel modules; Btrfs support for disabling copy-on-write on a per-file basis using chattr; faster Btrfs fsync(); a new experimental 'perf trace' tool modeled after strace; support for the TCP Fast Open feature in the server side; experimental SMBv2 protocol support; stable NFS 4.1 and parallel NFS; a vxlan tunneling protocol that allows to transfer Layer 2 ethernet packets over UDP; and support for the Intel SMAP security feature. Many small features and new drivers and fixes are also available. Here's the full list of changes."
This discussion has been archived. No new comments can be posted.

Linux 3.7 Released

Comments Filter:
  • by Anonymous Coward on Tuesday December 11, 2012 @12:43PM (#42251463)

    Does it `Just Work' (tm)? I really want rolling snapshots ah la NetApp.

    Sorry to be obtuse. Not much time for experiments.

  • Re:UDP ... (Score:5, Interesting)

    by vlm ( 69642 ) on Tuesday December 11, 2012 @12:48PM (#42251533)

    Why does vxlan transfer L2 packets using UDP and not TCP? I have also seen this on other L2 protocols like L2TP and PPTP ... just curious ...

    TCP has a feedback loop when packets are lost... So you'd have that at both layers, the actual session and the tunnel.

    Its an engineering thing where if you embed a feedback loop inside a feedback loop, things will be OK if you're VERY careful but most are not and you'll make a lovely oscillator and just blow it all to bits.

    Fundamentally, UDP doesn't guarantee delivery so its OK to shove it inside UDP, and TCP has its own repair mechanism so you don't need to guarantee its sub-layers, so its not like you're missing anything.

    Finally it just kills performance because TCP loves big buffers for each connection so you need megatons of ram until you start dropping packets and letting TCP police itself. Which meanwhile results in horrific latency. But if you tunnel over UDP, you don't really need much of a buffer on the tunneler itself and you'll overall end up with better latency specs. So its cheaper and works better. Hard to beat that combo...

  • Btrfs finally ready? (Score:2, Interesting)

    by javilon ( 99157 ) on Tuesday December 11, 2012 @12:51PM (#42251557) Homepage

    Is it finally ready for prime time? any one with experiences/horror stories?

  • by Anonymous Coward on Tuesday December 11, 2012 @12:57PM (#42251625)

    The SUSE implementation of Btrfs is quite good. It's quite a bit ahead of the Btrfs support I've seen on other distributions and setting it up is pretty much automated by the installer. I agree Btrfs isn't stable yet and so shouldn't be used in production yet, but it looks like it is getting closer.

  • Re:DRM (Score:5, Interesting)

    by leromarinvit ( 1462031 ) on Tuesday December 11, 2012 @01:02PM (#42251673)

    Only when you control the kernel/boot loader. I have a feeling that this will be used a lot by vendors to lock you out of your own devices, e.g. Android phones etc.

    I'm as paranoid as the next geek, and the idea of secure boot etc. appeals a lot to me if done correctly. As in, if it's MY device, then I get to decide what runs on it, and no one else. But it's a tool, and as such it can be used both for you and against you. There can't be a technical solution, technology is dumb. We need a legal solution, either in the form of regulation or widespread adoption (and enforcement) of the GPLv3.

  • Re:UDP ... (Score:5, Interesting)

    by vlm ( 69642 ) on Tuesday December 11, 2012 @01:04PM (#42251701)

    I forgot to mention one real life situation where UDP over TCP does not work.. UDP conceptually works pretty well with real time live streaming. "Here's 5 seconds of audio of the ball game". 5 seconds later, if lost, that packet is meaningless, don't bother re-sending it, the RX will just output 5 secs of silence or whatever. TCP does not understand that at all, so you can get serious problems with live streaming if you try to stick that inside TCP and experience significant network congestion. Buffers get bigger until they pop, "live" becomes randomly "tape delayed" based on recipient... Also TCP doesn't understand variable bit rate, so its ideas about buffer allocation bear little resemblance to what the codec actually wants to do.

  • by diegocg ( 1680514 ) on Tuesday December 11, 2012 @01:04PM (#42251703)

    a dist-upgrade took more than 4 hours instead of the expected 1.5 to 2 hours it takes with ext4.

    That's not due to poor small file performance in Btrfs, it's due to poor fsync() performance (which package tools like rpm and dpkg use quite a lot). In this new kernel version the Btrfs fsync() implementation is a lot faster.

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell