My main computer with its 24-inch monitor is where I get my coding done. Specs: Core 2 Duo 3GHz w/ 4GB RAM. Its normal workload: xterm and a few emacs windows, with an occasional compile.

For everything else, the laptop on the side (with 12-inch display) runs my email, IM, IRC, RSS, iTunes, and calendar. Specs: 667 MHz PowerPC, 640 MB RAM. Yes, my workload is backwards :)

Reading the research paper, the 6% overhead looks like it comes from having the kernel call into the hypervisor every time it allocates or frees an object that contains a kernel hook (a.k.a. function pointer). The designers explicitly state that they use non-paged memory to store the protected kernel hooks.

It's a little disingenuous to label traveling through a wormhole as FTL travel. It's just taking a different, shorter route. What speed do you get if you shine a light through a wormhole?

To display an image, at some point in some program, you'll see, if image is PNG, send it to libpng; if image is jpeg, send it to libjpg; .... We're just arguing about where that code belongs.

You could put it in the browser. Then you get a program that links directly with libfoo to display all the images it wants. My guess is that browsers do this now. It'd be the same thing to have Firefox link directly to x264 and libogg to display movies.

The alternative is to use another layer of indirection. Have a new library/system service that a browser can throw a buffer at and say "go render this." The service then discovers its type and calls libpng, libavg, .... This would be something like linking with VLC.

Any time you read about a product that guarantees perfect fault tolerance, there is always a list of constraints that must be met for that claim to hold. You probably won't ever see this list marketed, but it's there somewhere.

I haven't looked into this, but it sounds like ZFS is fault-tolerant given a system model where data can change once it's on-disk, but otherwise system components are fail-stop. So if you ask a hard disk to perform a write barrier and flush its data to disk, the disk will either do so and report success, it will issue an I/O error, or it will catch on fire. Any way, ZFS will handle the situation correctly.

Of course, the immediate next question is whether that failure model is realistic. Turns out it isn't. Some hardware will report 'write barrier complete' when it still has unwritten data in its buffer.

If you can't count on your hard disk to flush its caches or even order writes correctly, I don't think it's possible to build any fault-free file system on top of the drive.