Slashdot Mirror
Linux 3.7 Released
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."
Just proves what a wanker you are, then
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.
AntiFA: An abbreviation for Anti First Amendment.
Does it `Just Work' (tm)? I really want rolling snapshots ah la NetApp.
Sorry to be obtuse. Not much time for experiments.
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...
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
At that point you don't need the reliabilitiy and retransmission features of TCP. Once you stack the layers up, TCP will take care of that anyway, without running it over TCP again. Think IP: unreliable datagrams; you put TCP on it and presto: reliable, ordered, everything. Run a VPN, and you do it over UDP, and end up with something like IP -> UDP -> TCP, and then TCP again does its thing, without a care in the world about the layers below. Same principles apply with this new things too. If your underlying layers are flaky, you can't make them less flaky by adding more TCP to your cake. In effect, you make them even more flaky as each TCP layer tries to do its own retransmission and floods your line.
Question for religious people: where do unrepentant masochists go when they die?
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.
The ability to boot into different ARM systems using a single kernel is kind of cool, but the need to do it is kind of scary. Is ARM not actually a single instruction set architecture, and if so, what is it?
I used to run btrfs roughly a year ago for half a year and had no issues with data integrety etc whatsoever. The downside at that time was that performance for working with loads of small files was noticably worse than with ext4. The result of this was that a dist-upgrade took more than 4 hours instead of the expected 1.5 to 2 hours it takes with ext4. Apart from that I had no issues whatsoever; performance on other loads was decent.
I occasionaly look for benchmarks showing that the small files performance is up to par, but so far I have been unable to find them.
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.
Proud member of the Ferengi Socialist Party.
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
There is some interest in ARM for low-power servers and server appliances. Support for more than 4GB of ram would come in useful there.
Super Monkey Ball 2.
ironically enough the problematic area was games and the linux detractors never brought it up. Let us see what Valve comes up with.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
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.
Application
TCP (inner)
IP
Tunneling protocol
TCP (outer)
IP
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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).
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).
Question for religious people: where do unrepentant masochists go when they die?
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Haiku have active ports to PowerPC, ARM and x86-64 in progress.
So it's still a regression from 98?
Inheritance is the sincerest form of nepotism.
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.
The Tao of math: The numbers you can count are not the real numbers.
I can't speak to kernel development but I did develop a data processing engine in C that incorporated design features more traditionally suited to C++ development like polymorphism, interfaces, run-time loadable components, etc. The choice of C was meant to aid with future porting to systems for which C++ compilers were believed not to exist. The system worked but not without encountering instances where someone who developed a component for the system misunderstood some aspect of the architecture and implemented something incorrectly or deliberately took a shortcut that broke the model. To help keep things clean and orderly we had a very rigid coding standard that (most) people followed but it was still not as clear to follow as it would have looked coded in C++. Training developers to code for it who were familiar with C++ took a bit more effort as well. All that said, while I wish we had done it in C++ I don't relish the thought of re-writing it from scratch to use C++ constructs.
Account -> Discussions -> Disable Sigs
Not to mention the massive regression from 2000.
The Tao of math: The numbers you can count are not the real numbers.
1. thoroughly wash your bedsheets (or get new ones)
2. throw out your mattress, and any carpeting underneath
3. thoroughly vaccum the frame
4. buy new matress
5. learn personal hygiene.
6. most important: lose the neckbeard
NAT is and never was a stupid hack, people make the assumption it stemmed from the exhaustion of ipv4 , but that isnt true... as many people do, you've made the same invalid assumption as everyone else - and thats not meant to be an insult, just a fact of life. The reality is is that we've been working with nat so long that it really doesnt break much any more, and that which it does is work-around-able. Personally I come form the corporate enterprise world and nat is and always will be a reality there (for many reasons)... When you consider the various grades of people that use the internet (home users, geeks, corporates and ISPs, etc), everyone of them has no reason to fear nat, and ipv6 wont change anything about that... IPv6 wasnt designed with any notion around "lets make something that gets rid of nat", not even close. It certainly was intended to make the address space larger, but it wasnt aimed at nat.
The only diff between me (as a network engineer) and many other enterprise grade guys like me is that im dumb enough to say "nat is important, it has a purpose and i do like it" where most aren't dumb enough to say that on slashdot where the various puritan opinions will inevitably turn me into a troll.... which im really not meant to be...
But the fact remains - nat has a purpose, a valid purpose and it will be here forever.
Consider though - just because something is abundant, doesnt mean its necessarily available to you. By that I mean if your ISP decides to only give you one dynamic ipv6 /64 subnet, what then? most home consumers wont notice, but a networking nerd like me? well... there are lots of arguments you could enter into here like "find a new isp" - none of which are worth having. But a brief tour of the nasty things ISP's (not all) have tried to do to make a couple of extra dollar's would probably give a few hints as to why ipv6 nat (and its implementation in linux) is very very important.
You could also go and get a CCIE or JNCIE and start working in the corporate enterprise juganaut world for a decade and i guarantee when get to the end of that you'll change your tune....