There seems to be a problem with the power consumption requirement of 3 MW, which is stated in the presentation material. If you estimate that each of the 2200 cpus consumes 100 W, that makes only 0.22 MW, a factor of 10 difference. Where is the rest (90%) of the electrical power needed?

I was a bit sceptical about the latency and speed of the communications network, but there is some serious technology involved. According to an expert, the Infiniband technology is in the same class as Myrinet - in the middle category both in speed and price. It will be interesting to see how the communications scales up in the G5 cluster.

Here is some background in the partnership of the project where Virginia Tech Builds Top 10 InfiniBand SuperComputer for $5M: "Virginia Tech[base ']s partners for building this supercomputer in less than three months are Apple, Mellanox, Cisco, and Liebert. Mellanox is the leading provider of the InfiniBand semiconductor technology, the primary communications fabric, drivers, cards, and switches for the project. Cisco[base ']s Gigabit Ethernet switches were the choice for the secondary communications fabric to interconnect the cluster. Cisco provided a significant educational discount to support the project. Liebert, a division of Emerson Network Power, known for its comprehensive range of protection systems for sensitive electronics, provided the cooling system."

But what is "Déjà vu", which was reported to make it possible to carry on computations even when a node of the system fails. It seems that Déjà vu is a migratable version of MPI, and allows a task to be migrated to another node of the system. (See a pdf presentation about this.)

On the Cray T3E supercomputer there was this possibility: you could migrate tasks between nodes, and also suspend task when a higher-priority task had to be started. (An example: the weather forecast system has to be executed several times a day within a certain time limit.) If Déjà vu really works and does not need programmer intervention, this is really great news for all computational clusters.

In any case, it is time to forget the notion that Apple hardware is more expensive than other brands. When comparing similarly configured high-end systems, Apple may turn up cheaper, because a lot of the required functionality comes as options on other systems.

There is a lot of data available about the Virginia Tech G5 cluster at the Terascale Cluster page. If you are interested in technical details, see the slides (in PDF).

Dell joins UT's $38M supercomputer project: "With the purchase of 300 computer servers from Round Rock-based Dell Inc., the new "Lonestar" computing cluster gives UT scientists and engineers the power of more than 3 trillion computer operations per second, or 3 teraflops." See also: Cost of supercomputer only part of $38 million.

Here are my choices: Linux kernel development, Mozilla, XFree86, Apache, and OpenSSH. On the other hand, all these are doing rather well already.

How about, for example, the SourceForge projects for posting Xmeeting and MPlayer to Mac OS X, or the Fink and DarwinPorts projects?

A company might not be interested in the MPlayer port, depending of course on the business it is involved in. The other projects are good investment choices for almost any enterprise, even for Microsoft.

1 - The artifacts in software projects often aren't as visible or well-understood as in other projects...

[Kind of like any project of discovery - FP]

2 - The end state of a software project is often a lot more speculative than with other projects...

[Ditto - FP]

3 - There is an incredible variability in what we call "software" and projects called "software development." Designing a Formula-1 racer is different from designing next year's Camry which is different from designing GM's new fuel-cell multi-vehicle platform. They all have to do with designing cars yet we treat them like vastly different activities. Somehow we try to treat making software as the same when the products are as different as Camrys, racers, and platforms...

4 - The production chain from feature to code to executing stuff varies wildly in throughput, availability, reliability and even variability itself. Software production varies from one application technology to another, from one platform to another, and even between deployments of the same production chain...

[All the more reason to understand the potential of that variable variation - FP]

5 - Producing code varies wildly in the character of the work. Code production can be mostly any one of: discovery, investigation, design and creation, generation of code, integration, or something else...

6 - Software production involves a lot more than producing software. Production processes on the front-end (before features) and back-end (after something that executes) are more variable than code production, and often dominate the project schedule, risk and variability. Non-production activities can also dominate the project, like organizational change, team formation and technology adoption...

[Amen. - FP]

7 - There aren't any software-only projects...

[Amen again. - FP]

8 - Software development capability is usually a limited, shared resource...

[And amen one more time. Most IT projects are in multi-project, multi-responsibility environments. - FP]

9 -The tools and methods in software projects are tunable. So, if rebuilding the software every five minutes helps code production, adjust your environment to do that...I like to iterate processes and methods with each project increment - "How can we do the next one better, faster, cheaper?" then track process or method changes explicitly on the project plan...

[I love it when a plan comes together. I love it more when it changes due to learning. - FP]

10- A software project manager is employed for a reason. Projects this challenging need leaders and managers, not just administrators. You are there to manage the project and support the people who will have to deal with changing targets, multiple demands, variable production, accidental (or deliberate) changes to their world, multitasking, new methods and so on. There is a tremendous temptation for project (and line) management to retreat into administration:The methodology said . . . Those bad and evil customers, developers, vendors, agitated ghosts said. . . The PMO requires . . .It's too hard, complicated, confusing, obscure . . . It's your job to make it happen. If you can't figure that out (maybe by finding a trusted adviser) then your job description is inoperative...