Now that you have $6 billion of our cash and spectrum allocation, why don't you take our customers too?

The best thing you can do about all this as an individual? TURN OFF THIRD-PARTY COOKIES. I've been browsing with third-party cookies disabled for the last six months, and am yet to find something I care about that doesn't work because I have them disabled. It protects your privacy and security, it eliminates various irritating bits of targeted advertising and the like, and most browsers have a "block third-party cookies" setting built in.

I'm not surprised, because it is eminently clear that Google wants to concentrate their social features on Plus (in effect, to compete with Facebook by cloning Facebook), but I am still disappointed.
I genuinely like Buzz; it aggregates activity from a whole range of services that I don't care to deal with (personal blogs, google reader, twitter, tumblr, etc.) for easy reading, instead of being another one of those services (Hi Plus!). It was even better because it used an open standard mechanism for identity management to do what it did.
Apparently the APIs for re-posting into Plus from external sites are starting to come together, so I guess that is the migration plan, even though it isn't as open or convenient. It would be nice if Google would set up rel=me peering behavior for plus to replace the functionality.

The implications of individuals, especially kids, having access to 3D printing is a pretty well-explored scifi trope. Cory Doctrow's Makers, and Bruce Sterling's Kiosk are both based on the concept, reasonably good, and make a solid starting point for implications.

I assume this is an epic troll, but am going to give an honest answer anyway, because there are some legitimate questions buried in there.

I work with a aggregate.org a university research group which has a decent claim to having built the very first Linux PC Cluster, set some records with them (KLAT2 and KASY0 were both ours), and still operates a number of Linux clusters, including some containing GPUs, so I feel like I have some idea of the lay of cluster technology. It is *way* overdue for an update (and one is in progress, we swear!), but we also maintain TLDP's widely circulated Parallel Processing HOWTO, which was the goto resource for this kind of question for some time.

In a cluster of any size, you do _not_ want to be handling nodes individually. There are several popular provisioning and administration systems for avoiding doing so, because every organization with a large number of machines needs such a tool. The clusters I deal with are mostly provisioned with Perceus with a few ROCKS holdovers, and I'm aware of a number of other solutions (xCat is the most popular that I've never tinkered with). Perceus can pass out pretty much any correctly-configured Linux image to the machines, although It is specifically tailored to work with Caos NSA (Redhat-like), or GravityOS (a Debian derivative) payloads. Infiscale, the company that supports Perceus, releases the basic tools and some sample modifiable OS images for free, and makes their money off support and custom images, so it is pretty flexible option in terms of required financial and/or personnel commitment. The various provisioning and administration tools are generally designed to interact with various monitoring tools (ex. Warewulf or Ganglia) and job management systems (see next paragraph).
Accounting and billing users is largely about your job management system. Our clusters aren't billed this way, so I can't claim to have be closely familiar with the tools, but most of the established job management systems like Slurm, and GridEngine (to name two of many) have accounting systems built in.
The "standard" images or image-building tools provided with the provisioning systems generally provide for a few nicely integrated combinations of tools, which make it remarkably easy to throw a functioning cluster stack together.

As for GPUs... be aware that the claimed performance for GPUs, especially in clusters, is virtually unattainable. You have to write code in their nasty domain-specific languages (CUDA or OpenCL for Nvidia, just OpenCL for AMD) and there isn't really any concept of IPC baked in to the tools to allow for distributed operations. Furthermore, GPUs are also generally extroridnarly memory and memory bandwidth starved (remember, the speed comes from there being hundreds of processing elements on the card, all sharing the same memory and interface), so simply keeping them fed with data is challenging. GPGPU is also an unstable area in both relevant senses: the GPGPU software itself has a nasty tendency to hang the host when something goes wrong (which is extra fun in clusters without BMCs), and the platforms are changing at an alarming clip. AMD is somewhat worse in the "moving target" regard - they recently deprecated all 4000 series cards from being supported by GPGPU tools, and have abandoned their CTM, CAL, and Brook+ environments before settling on OpenCL, and only OpenCL. Nvidia still supports both their CUDA environment and OpenCL environments, and (with some caveats) all the cards they have ever claimed to work for compute can still be used. Offsetting the somewhat easier and more flexible software situation on the Nvidia side, the AMD cards tend to offer peak FLOPS/dollar numbers something like 4x what the Nvidia cards can provide, which makes the various parts surprisingly well matched. Note that the difference between the special compute hardware ("Tesla" and "Firestream") and consumer cards tends to be that they have a little more memory, and are enormously more expensive , so the consumer cards are way ahead in terms of FLOPS per dollar. We're currently speccing out a 64-node cluster hosting Radeon HD5770s that will (in theory) peak a little above 85TeraFLOPS of GPU performance for less than $10k in GPUs. To head off a common "oops" moment, it sounds as though your machines will be "server style" (ie. rackmount, high reliability PSUs, etc.), which can be a challenge, since that kind of system is generally not designed for hosting physically enormous, power hungry PCIE cards like GPUs.

The questions posed in the OP are *very* early issues in the planning process for setting up a cluster, but enjoy your journey into the woods, this stuff is fun.

Uh... That's why they're professors. They DO know things you don't, and you are theoretically there to learn some of those things from them.

I wonder how the HPC community is going to respond; there is a not insubstantial community who heard "150Gflop/$400" and "Linux" and decided to build clusters from PS3s. Those machines can probably just have updates held back, but it makes replacement a problem. To forestall the inevitable "that isn't a serious use" argument, US Airforce owns Something like 2,500 PS3s for compute work.
Killing Linux on the PS3 also presents something of an issue for the other Cell "partners", who seem to be looking at the PS3 as a low-cost Cell development starter kit. The other Cell machines on the market are *much* more expensive (an IBM QS22 blade is $8-20k, depending on configuration, and Mercury Computer Systems doesn't even like talking about how much their Cell boards cost). Given that Cell is an enormously difficult architecture to target, having relatively inexpensive systems to test and train on is very desirable for the other vendors, especially now that so many of the HPC folks are fixated on GPGPU, which is also terrible to program for, but has a far lower cost of entry. It could be that IBM's decision not to pursue Cell in the HPC market is how it became politically tenable for Sony to kill off Linux on the PS3.

The idea that an interface can be entirely judged by how well a user handles it in the first few minutes of exposure is, in my opinion, one of the bigger *problems* with UI design of late. A quality interface should both be immediately accessible, and SCALE WELL TO MORE ADVANCED USE CASES. In my experience, Gnome, OS X, and the bundled native applications that come with each currently fail miserably at the latter. The former head of Apple's UI team makes a pretty good case for this being a problem here, although the article focuses specifically on a facet of the OS X design philosophy which causes scalability issues, rather than the problem in general. To borrow a line from the article: "The beginner today will be the expert of tomorrow. The user with 200 photos today will be the user with 2000 a year from now. The user with 10 songs today will be the user with 100 songs six months from now. The user with one or two extra apps on the iPhone will be the user with 100 apps three months from now."

I didn't have any luck with daemon tools under Windows 7 (32bit), but SlySoft Virtual Clonedrive (free, http://www.slysoft.com/en/virtual-clonedrive.html ) works fine for me. On a more general note, Windows 7 is making it not a chore to leave my usual Linux/XFCE environment, so they must have done something right.