I'm not sure it's practical to take into account all the expected sources, but a far advanced civilization may be able to communicate by converting energy to mass and back to create a gravitational signal that presumably travels faster than light.

I don't think that makes sense... If they're leaving resi's at IPv4, to speak seemlessly with IPv6 servers would mean NAT that doctors DNS in both directions at least.

Been waiting to see mention of this without having to read up on nosql yet =) it seems there could be a db engine that provides sql features backed by nosql data stores when things mature there.

My opinion is the best bang-for-the-buck would be to integrate RAM into the CPU. Perhaps a decent GPU with lightweight CPU added in would make sense if netbook continues as a separate niche, but again it might be better to put the RAM in as well. Between allowing multiple memory paths (no longer restricted by pins on the chip as much) and presumably lower power required to access the bits, it seems like a reasonable path to take. Imagine if the RAM were fast enough that little cache were needed on the CPU for added benefit.

The one idea I've not seen talked about that seems like it'd help magnetic disks is to just store the first megabyte or so in cache, so that the disk can seek to the next part of a file and read at whatever expected transfer speed. In other words, cache away the seek time and live with the transfer. It seems like a nice match for an SSD cache if the goal is to pretend you have a huge SSD storage but can't afford it. It'd stretch the cache across a whole lot more files, so that almost all files could appear to live in cache. Well, if the number turned out to be as high as 1 MB than I guess 16000 files could live in it, not accounting for smaller libraries that could fully fit within it.

I can't find it now (can't remember the name used) but I had referenced a webpage for an online authen system awhile back that "solved" that problem nicely. I'm probably going to mess up a step by rushing but it went something like this:

• 1. Server sends tokenA and tokenB to client
• 2. Client returns hmac(password, tokenA), and hash(hmac(password, tokenB).
• 3. Server verifies hash of the first part matches what is stored, and stores the second part for next time.

So the hash on the server changes everytime the login is successful, without changing the password, and it doesn't inconvience users. Also there's nice javascript libraries for things like md5/sha that do not take noticeable time on any client I've tried.

Almost sounds like any app launcher could be a door and the exit widget a back door.