You have described the Truy Ergonomic keyboard. Really, that's the brand name they picked. Not buckling spring, but still mechanical keys, noise optional (Cherry MX Blue or Brown). Not cheap at $250, but the most appealing design I've seen yet.
I did own a Kinesis Classic years ago. Crazy arrangement as Average mentions, very different. If you have RSI concerns, different is exactly what you want. I used to switch back and forth every once in a while, just to change up the motion. I can't say I ever really liked the bowl though, and I eventually gave it away (which I now regret). The real keys use the same Cherry Brown key switches as the unfortunately-named Truly Ergonomic. The rubber function "keys" are pure rubbish though.
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.
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.
Those who can, do; those who can't, simulate.