Ext2/3/4 sucks as an interchange format. In short, it does too much. Any filesystem sufficiently complex to support real workloads is going to impose an excessive implementation burden for sneakernet. The bizarre thing is that we have a minimalist filesystem that can represent the file model with fidelity (large files, unicode names, etc) that is implemented in every modern OS: UDF. If it can read DVDs, it can read UDF and every general purpose OS released in the last decade can write to the appropriate version, 2.01. Not for nothing is it called the Universal Disk Format.

The real mystery is how did Microsoft con an industry into paying for such a lousy alternative to UDF. SDXC requires exFAT, so every new camera and anything else that hopes to read these high capacity sdcards has to cope with licensing requirements. WTF.

Help me out here: is it not blatantly obvious that the numbers in that strip assume randomly generated pass-phrases? I thought that that was 1/2 the point. With a 48-bit key mapped to four characters of a 12-bit symbol-set composed of English words, you can get keys that are both strong and easy for humans to remember. Let users choose the pass-phrase and you sacrifice the first part, and it's only the combination that's interesting.

I wouldn't presume to accuse the engineers behind SPDY of ignoring the existing work in the space. I did take exception to the immediate parent's dismissive and inaccurate characterization of SCTP. That protocol is a worthy attempt to solve real problems at the most technically desirable layer. SPDY looks to be a good piece of engineering, inventing only as much as necessary to achieve a well defined benefit. I cannot fault its creators for that.

I stand behind my assertion that SPDY will succeed at the expense of SCTP. There are finite resources available for such work and those two protocols are in direct competition. After all the investment by browser implementors, web server vendors, proxies, reverse proxies, etc to support the former, can you really see any interest in doing so all over again for only modest direct benefit? If you succeed, then that constituency will have been largely satisfied. The web will indeed be better off – no small thing! And it will be good enough. Good enough in the same way that HTTPS is good enough. The protocol is sufficiently extensible that new ciphers have been deployed without breaking older implementations, but the true weaknesses lie in the fundamentally flawed nature of the CA institution that it spawned: a social problem, one not readily susceptible to technical improvement. Only now that the weakness in the CA system have been exploited and publicized has there been much appetite for any innovation in that space whatsoever. DNSSec is only just now percolating up through the resolver to applications – how long before we can rely on a sound technical foundation for transport crypto such as the HIP protocol aims to provide? The shortcuts taken today will linger to haunt future generations.

Engineers solve real problems, affording us real, practical benefit. I get that. Please forgive me that I am sad that solving these problems one niche at a time means that we can't seem to pull together towards a general solution for a broader benefit. I don't want it to just work: I wish for the foundations to be sound.

Have you looked at SCTP at all? 90% of the problem that SPDY aims to solve is already addressed by SCTP. Message framing and multiplexing multiple streams over a single connection with different delivery guarantees are the standout features. SPDY main accomplishment is also its major drawback: it accepts as a design requirement TCP compatibility. It is a product of those who believe that the internet as originally conceived, is dead. Instead of a packet-switched network routed according to destination address, internet access has come to imply only outbound TCP session connectivity, with some UDP and ICMP if you're lucky. The fact that this is largely adequate for the way we use the network today should not be taken as an endorsement; our use today is limited to those aspects because we cannot do more. NAT and perimeter firewalls have effectively crippled the evolution of the global network. You can no longer upgrade only the endpoints: one must wait upon the whole of the network to join the transition. Innovation then is limited to layers above established protocols. Witness the madness that is IP-HTTPS. With that viewpoint in mind, I cannot celebrate the advent SPDY; I must lament it's significance.

Adding insult is that it is perhaps not too late. The endpoints which benefit most from these efforts are those on the proprietary networks of the mobile operators like AT&T and Verizon. Those operators have the control necessary to permit SCTP operation, and there is a marketable competitive advantage to be had in doing so. The other side of the equation does not have the same barriers. Google, Akamai, Amazon - these endpoints are entirely owned by parties with both the capability and the business interest to enable the technology.

SCTP has applications far beyond those that can be addressed by SPDY, but If SPDY succeeds, SCTP fails. They could have solved the problem on the internet. They chose to solve the problem on the web.

I'm a little more familiar with the C# .NET environment, but I don't see any reason you couldn't apply the idea to C code as well. LLVM bitcode already exists with both a container and a intermediate format corresponding to .NET's IL or Java's bytecode. LLVM is designed to be suitable for direct compilation down to machine code without the companion virtual machines that .NET and Java expect. If all you want to do is delay the platform-dependent compilation phase, LLVM looks perfect to me.

Weather kills people all the time. The forensics is a little trickier though: fewer fingerprints and more computer simulations, fewer explosives and more droughts. On the flip side, there's still plenty of expert testimony.