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.

As far as I understand it, wake-on-lan would let me SSH into one computer so I can send a magic packet to my real to computer to wake it up, and then I can SSH in to the computer I wanted to in the first place.

Somniloquy gives the same functionality transparently, without needing that extra step, without any other network user being aware that the computer was asleep in the first place.

If you read the referenced paper, they do talk about why they don't like wake-on-lan in section 6.

The important part of this work isn't that there is another device to do your downloading. Yes, there are better devices for that.

What these guys have done is design one way to keep your PC in low power mode as long as possible. One reason that people keep their computers on is that they want network services to be available. (Some keep their computer on because it's downloading torrents. I keep my computer on because I might want to SSH in or access my files remotely.)

This device is one way to keep a computer network-accessible while it's in a low-power sleep. (Hence the name "Somniloquy": talking in one's sleep.) They do this by putting a proxy between the computer and the network. The computer can go to sleep and have the proxy take over network functions for it.

This turns out to be a very general approach. For some types of network access, this device can get away with ignoring the data. For other accesses (like when I try to SSH in), it can wake the computer from sleep to process the request. For some trivial protocols like ping, it's easy to let the proxy just respond.

They show that it's still possible to get some power saving in complex protocols. As an illustration of its generality, they were able to implement BitTorrent within this design. Other protocols may give similar benefits. But they aren't about to implement everything out there.

A different perspective. And maybe a less-confrontational attitude.

If your biggest problem is how to represent objects in a relational database, I'd say the foundation is solid enough.

More broadly, your problem is that we don't know exactly what we should be modeling with our computers, not questioning whether computers are capable of modeling it. That's progress.