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.

Modern operating systems get around this issue with a disk cache. In reality, 100 files will be read off the disk for the first compile, and the rest of the compiles will just access the cached copy in memory (unless memory is in short supply on your system).