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."
Improved SAMBA client support? (Score:5, Informative)
experimental SMBv2 protocol support;
This can't come soon enough for Linux clients. SAMBA already has SMBv2+ server-side support, with SAMBA 4 apparently even supported SMB 3.0. This is especially true for a high-latency connection through the VPN where the reduced chattiness of newer SMB protocols gives a nice performance bump.
You can post all day & all night about how NFS/CODA/GlusterFS/etc./etc. is better, but at the end of the day the CIFS protocols are supported by every Windows machine out there and should be supported by Linux too. Plus, if you are a free-software purist, then you could setup a 100% GPL'd installation with SAMBA servers and Linux clients, so it would totally make sense for the Linux clients to actually support the modern protocols.
Re:Is Btrfs for real yet? (Score:3, Informative)
SUSE enterprise linux has offered BTRFS as a supported option since Feb.
Conservative folk wont touch it until they know its been used by millions of people for many years.
I use it with backups on ext4.
Re:DRM (Score:5, Informative)
Module signing has been in place with Fedora 18 and Ubuntu 12.10 as it's required to be compliant and get a signature on the bootloader for Secure Boot. I assume the code was backported.
Re:How fractured is ARM? (Score:5, Informative)
There are variants in the instruction set (just like there are in the x86 world, where i686 is a superset of i383 for example). However, that isn't the big problem with ARM; there isn't a single-standard way of booting like there is with x86 (where most things are IBM PC BIOS compatible, with some now moving to EFI/UEFI). Also, there's no device enumeration like ACPI; lots of ARM vendors build their own kernel with a static compiled-in list of devices, rather than having an easy way to probe the hardware at run-time.
Re:How fractured is ARM? (Score:2, Informative)
Re:UDP ... (Score:4, Informative)
I agree with your comments but want to add a clarification to your last paragraph for the benefit of all /. readers.
TCP needs enough buffer that it can hold a copy of each packet sent until it receives an acknowledgment because it may need to re-transmit the packet if it gets lost. Once the packet is acknowledged as having been received, TCP frees up the space. As such, there is a straight forward way of computing how much buffer TCP needs if you want to fully utilize the bandwidth of the bottleneck link along the path.
The amount of buffer is twice the round-trip time multiplied by the bandwidth of the bottleneck link (aka, "the bandwidth delay product"). More that this is a waste as it won't be used. Now, the effective round-trip time will increase if you have packet loss along the path. And congestion in the network (possibly made worse by the buffer bloat the previous post points out) will also increase the round-trip time. And the bandwidth of the bottleneck link is probably not directly knowable by the end hosts (although it can be reasonably estimated). Thus the amount of buffer space can be estimated a priori.
Note: you will still have to have this much buffer space to achieve full performance even if you tunnel TCP through UDP. It is just that you won't have to have much more than that amount. Also, having inner and outer TCP connections result in them fighting against each other, as you point out. (That is why it is not a good idea to tunnel TCP over TCP, not primarily because of buffer concerns.)
Note: you do need to have sufficient space for the inner TCP or it won't be able to operate at full speed. But you won't need double the space as you would with TCP within TCP (assuming you could solve the fighting among themselves issue).
Re:kernel in c++? (Score:5, Informative)
And you need a kernel in C++ why? Because you can't get your head around objects that aren't enforced by the language? Or you can't get your head around doing error cleanup without exceptions enforced by the language? The Linux kernel even does reference counting without explicit support from the language.
Just to get a complete picture, I looked at some competing kernels (I skimmed over the source really quickly):
FreeBSD kernel - C, with objects and refcounts, similar to Linux
OpenBSD kernel - C, but I have a hard time finding their equivalent to objects and refcounts, and I gave up looking
GNU Hurd - C, and I'm not even going to bother looking around too much
XNU - C, but with I/O Kit in C++ - works only with Apple software?
Haiku kernel - C++, which is interesting in itself - but supports only IA-32?
Plan9 kernel - C
OpenSolaris kernel - C
I think it's pointless to look at the rest. All the others listed by Wikipedia are even more obscure than some of the above.
C seems to dominate the kernel arena, so Next time you post, I'd like to know what you think C++ would bring to the party. No, really. I've seen many dismiss that Linux isn't written in C++, but haven't seen a single one of these trolls (yes, I'm feeding you) say what that would accomplish, and I'm really really really curious. I'll throw a bone from the XNU Wikipedia article: "helping device drivers be written more quickly and using less code", and that seems to be the only bit written in C++, yet Linux does pretty well without, and apparently so do the majority (see above).
Re:kernel in c++? (Score:5, Informative)
IIRC modern windows is a mixture of C and C++.
As to what C++ achives it's the automation of tedious and error-prone boilerplate. Rather than manually incrementing and decrementing reference counts you can have it happen automatically as values are copied and overwritten. Rather than manually building procedure address tables for polymorphism you can get the compiler to do it for you.
Re:kernel in c++? (Score:4, Informative)
Haiku have active ports to PowerPC, ARM and x86-64 in progress.