HBM1 gives 1GB and 128GB/s per stack, so 4GB and 512GB/s in this model with 4 stacks.

HBM2 will double both performance and capacity, and is expected some time next year.

But that's working with 32-terabit floating point values.

Yes. I think cooler heads will eventually prevail, and they'll reverse their knee-jerk decision to phase out nuclear. One only has to look at German CO2 emissions over the past few years to see why. Of course, until they do I'm sure the French and Czechs will be happy to sell Germany their surplus nuclear power.

I have native IPv6 on Time Warner. I just had to arrange a modem swap. Call 'em up and ask if you can get a DOCSIS 2 modem.

2: If IPv6 were backwards-compatible, we wouldn't. We could go from IPv4 to IPv6 just like going from CDs to DVDs to BluRay. But it isn't and therefore we won't ever replace that structure.

IPv6 is backwards-compatible in exactly the same way that BluRay is backwards-compatible with DVD.

Your BluRay player has a BluRay VM and Java VM, and uses H.264 encoded video. None of that is part of DVD playback. There's a totally separate stack of code that handles DVD menus, MPEG-2 video, and interleaved MPEG transport streams. Your separate DVD software stack and BluRay software stack sit on top of a single piece of hardware for reading data from the discs. The UI then makes the distinction largely invisible.

And similarly, my computer has an IPv4 stack and an IPv6 stack, and they both sit on the same network hardware that reads the packets. And the OS makes the distinction largely invisible to the end user.

These are small projects each focused on one specific detail, mostly modelling ways to predict and reduce sonic booms.

Also, the total amount is $5.7 million; I think the $2.3 million might be the first year.

Fastest Carrizo model (the FX-8800P) is 819GFLOPS.

According to the man page on my Mac:

          The getopt_long() and getopt_long_only() functions first appeared in GNU
          libiberty. The first BSD implementation of getopt_long() appeared in
          NetBSD 1.5, the first BSD implementation of getopt_long_only() in
          OpenBSD 3.3. FreeBSD first included getopt_long() in FreeBSD 5.0,
          getopt_long_only() in FreeBSD 5.2.

Not to mention SMS is not reliable. SMS messages are not guaranteed, they are delivered on a "best effort" basis. Your mobile network is free to drop them on the floor and not retry if your phone moves out of signal range, the network is congested, or any other reason they feel like. This is particularly prone to happening when messages have to go across network boundaries.

Obviously the person who wrote the summary was under the mistaken belief that SMS is designed to be reliable, just like lots of people believe that email is designed to be instant...

Speaking of the horrific consequences of nuclear weapons testing in the Pacific, a big one that's still with us today is the knee-jerk phobia of nuclear power, often by people who can't distinguish between the two. Along with wind and solar, nuclear power is one of our chief tools to mitigate global warming, which will in the long term prove to be far worse than weapons testing. It sure doesn't help that the US government lied through its teeth about atmospheric testing. I've been trying to find a copy of Joseph Rotblat's paper deducing that most of the yield of the Ivy Mike and Castle Bravo tests came from the fast fission of the U-238 tamper, revealing as a lie the government's claim that fusion bombs were inherently clean. Anybody know where I can find a copy?

And depending on how it goes about it, I may have no problem with that.

Learn Ruby. It's what Perl 6 should have been — the good stuff from Perl, but cleaned up.

Then you can either go the devops/sysadmin route — both Puppet and Chef are written in Ruby — or you can go the Rails or Sinatra route and head towards web services development.