Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


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 rubycodez ( 864176 ) on Tuesday December 11, 2012 @12:57PM (#42251627)

    purists can also get Linux into the door at the clients with windows desktops, the basics of authentication, file and print sharing are enough for most small/medium business. I've done that a few times over the last five years, clients are still happy as the server just works,and are adopting more Linux boxes including some desktops.

  • Re:UDP ... (Score:4, Insightful)

    by petermgreen ( 876956 ) <plugwashNO@SPAMp10link.net> on Tuesday December 11, 2012 @01:39PM (#42252059) Homepage

    TCP tries to (and usually succeeds in) trasfer a stream of bytes reliablly and in the right order over an unreliable packet based system.

    To achieve this two things have to happen
    1: the sender must resend lost packets
    2: the recipiant must hold packets after

    However there is no way for a sender to determine if a packet has actually been lost or just delayed. So the sender must use a timeout to deem a packet as lost and retransmit it.

    Now suppose someone builds a tunnel using TCP and runs TCP over that tunnel so your stack looks something like.

    TCP (inner)
    Tunneling protocol
    TCP (outer)
    underlying network

    Everything works fine as long as no packets are lost. However when a packet is lost by the underlying network the outer TCP layer freezes all transmissions through the tunnel until it has retransmitted the packet. During this time it is likely that the innner TCP layer will also deem the packet(s) lost and try to retransmit them (possiblly more than once due to the auto-adjusting timeouts used by TCP). Then when the outer TCP does recover it will deliver both the original packet and the retransmission from the outer TCP. This behaviour is very similar to what happens when a network is congested and make cause the inner TCP to unnessacerally back off the data rate.

  • Re:kernel in c++? (Score:3, Insightful)

    by maxwell demon ( 590494 ) on Tuesday December 11, 2012 @04:16PM (#42253669) Journal

    For any reasonable C++ compiler and well-written program, the cost is exactly the same as if you do it manually.

    In some cases it will even be less because the compiler knows what's going on and can use that knowledge in optimization, e.g. replace indirect calls by direct calls where it knows exactly the dynamic type of an object, which is generally not possible for hand-written call tables.

In seeking the unattainable, simplicity only gets in the way. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982