And we don't have to use Highlander Rules when considering drive technologies. There's no reason that one has to build a storage array right now out of purely SSD or purely HDD. Sun showed in some of their storage products that by combining a few SSDs with several slower, large capacity HDDs and ZFS, they could satisfy many workloads for a lot less money. (Pretty much the only thing a hybrid storage pool like that can't do is sustain very high IOPS of random reads across a huge pool of data with no read locality at all.)

I hope we see more filesystems support transparent hybrid storage like this...

For $26, you can measure the power of each device on and off and figure out who the actual power hogs are:

http://www.newegg.com/Product/Product.aspx?Item=N82E16882715001

Then at least you'll save wear-and-tear on your plugs for devices that are really off when turned off. (Like your washer and dryer, for example. I would be surprised if they draw power when off.)

Wow, you definitely win there. :)

Because recoil due to conservation of momentum, not conservation of energy. The "projectiles" (ok, summing over many, many projectiles with the laser) leave with the same kinetic energy, but the rest mass of the photon is zero. Since we're dealing with photons, we would really need to do the math with conservation of relativistic 4-momentum to get the right answer. (Newtonian conservation of momentum says there would be no recoil at all from a laser, but that's not quite true. It's just really, really tiny.)

Gah, total format failure. Forgot I was in HTML mode. You get the idea, though.

Minor nit: Mac OS X (until Snow Leopard) had to deal with 4 architectures $ file /usr/lib/libbz2.dylib /usr/lib/libbz2.dylib: Mach-O universal binary with 4 architectures /usr/lib/libbz2.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/lib/libbz2.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64 /usr/lib/libbz2.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/lib/libbz2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

I don't see this as an either/or proposition. Backing up protects you from data loss, which comes in many forms:

* Sudden hardware or software failure
* Silent hardware/software failure (or user failure) resulting in corruption you only discover later
* Theft/fire/natural disaster

At the same time you want:
* Easy backup procedure (if it is too hard, you won't do it)
* Fast restore procedure

A sensible backup plan needs to address all of these needs. Incremental tape backups with rotation to an offsite vault is one option which covers most of these things, but isn't particularly easy or automated. RAID is very easy and convenient, but only covers a very narrow range of hardware failures. (If you listen closely, you can hear the screams in the distance of a RAID user who just lost data to software-induced filesystem corruption. Hence the mantra "RAID is not backup.")

Network (blah, blah, "cloud," blah) backup services are a great option for cheap offsite backup that is extremely convenient and continuous. But you should supplement it with some kind of local, fast backup as well. That way you can recover quickly from hard drive failure and corrupted filesystems, but still have a Plan B if your house floods. (Or if you local backup turns out not to be broken when you need it!) Moreover, many network backup services will mail a hard drives for a fee if disaster strikes and you need to restore everything.

In my case, I use CrashPlan and Time Machine to do this. CrashPlan backs up changed files every 15 minutes to several offsite locations. I also plug a Time Machine disk into my laptop periodically to make a local snapshot. Restoration is quick in the common case, but I also have coverage for extraordinary events as well as backups when I travel without my external disk.

I think often people confuse "altruism" with "long term self-interest," and that may be the issue Google is considering here. In the short term, you can make it hard for tenants to move out, and maybe gain a little bit of rent that you would not have otherwise gotten. However, people talk and, in the long term, behavior like that can lose you potential customers. You will be forced to drop your rent in order to keep your units full.

(This relates to the best description of "business ethics" I've heard: Ethical business requires that you balance the needs of and try to act in the best interest of your owners, employees and customers. Otherwise, in the long run, you will find yourself without capital, labor, or revenue. Thus, business ethics is about long term self-interest, not some kind of abstract altruism. Sometimes the "long run" takes a really long time, encouraging people to risk unethical behavior, of course.)

Making it easier to leave Google applications helps grow your potential customer base in the future (such as those who are wary of lock in), at the risk of losing current customers who are unhappy with your service. That is a motivation well-rooted in self-interest, as long as you think your product is better than everyone else's.

The GeForce 9 series was a rebrand/die shrink of GeForce 8, but the GTX 200 series has some major improvements under the hood:

* Vastly smarter memory controller including better batching of reads, and the ability to map host memory into the GPU memory space
* Double the number of registers
* Hardware double precision support (not as fast as single, but way faster than emulating it)

These sorts of things probably don't matter to people playing games, but they are huge wins for people doing GPU computing. The GTX 200 series has also seen a minor die shrink during the generation, so I don't know if the next generation will be more of a die shrink or actually include improved performance. (Hopefully the latter to keep up with Larrabee.)

From the page: "Sloppy reduction allowed us to make our code branch-free and thereby very efficient on the PS3's 4-way SIMD Synergistic Processing Units (SPUs)." This sounds promising for CUDA. If this code is really branch-free, it should fly on a GTX 285. NVIDIA's GT200 chips have a lot more raw compute power, but less flexibility, than the Cell processor on the PS3. The usual CUDA performance killer is irregular memory read patterns and highly divergent branching.