Here's how to utilize lower-priced spot instances for scientific computing:

1. Set up one long-running, low-cost instance (a small is fine) that creates a distributed queue using Amazon's SQS, and adds jobs to the queue corresponding to each "unit" of the relevant computational problem of interest. New jobs can be added using a command line interface, or through a web interface.

2. Create a user start-up Bash script for the spot instances that runs your main program -- I prefer using Python and boto for simplicity. The main program should connect to the SQS queue, and begin an "infinite" while loop. Inside the loop, the next job off the queue is pulled, containing the input parameters that define the "unit" of the computational problem of interest. These input parameters are fed to the main algorithm, and the resulting output is uploaded to Amazon S3. The loop continues.

3. Any time the queue is empty or the spot instance remains idle for ~5 minutes, the spot instance then auto-terminates using EC2's command line interface.

4. Finally, just write a simple Python script to pull all the results off S3, combine & analyze them, and export to another useful format.

You'll also need to set up your spot instance price threshold, and make sure the queue has jobs to run. That's it, it's fairly simple.

"Because the effect of that would be to push even more transactions into unregulated "dark pools". Why do you believe that HFT is harmful? Do you have any evidence, other than fear of something you don't understand?"

Yes - (1) HFT has the potential to cause extreme volatility swings. (2) HFT essentially introduces a tax on every other buyer and seller in the market (because it actually widens the difference between the post and the offer).

On point #2, I'll just leave this here: http://qz.com/95088/high-frequency-trading-is-bad-for-normal-investors-researchers-say/

Emergent OOism -- that everything is an object, including the variable types -- can provide continual surprises of what is possible, even to veteran programmers in other languages. As you were developing and using Python, Guido, what was your favorite surprise? What was now easily possible using Python that would have been very difficult with another language (at the time, or even nowadays)?

Mine: a dictionary of lambda functions for parsing text, and writing a custom MapReduce capability for AWS in 372 lines.

Marriage is not a "human right".

Wrong. Universal Declaration of Human Rights, Article 16, section 1:
"Men and women of full age, without any limitation due to race, nationality or religion, have the right to marry and to found a family."

"We'll have +100 exaFLOP systems in five years" - that's totally untrue. There's an active debate going on in the field whether or not we'll be at 1 exaflop by 2020. We absolutely will not get to 100 before then.

It would be fairly easy to have DHS come up with a list of things (physical locations, services, etc) to designate as critical to national infrastructure. In fact, I'd be shocked if they don't already have such a list already.

The organization that runs these these locations/services would have to build into all of their software contracts a liability clause.

Problem solved.

That's just not true. The internet and world wide web both existed in the early 90s, and neither was critical to national infrastructure at the time.

Correction: I meant to said medicaid (which is for poor people), not medicare (which is for the elderly).

This is essentially a government subsidy to software companies that produce crappy code.

Look at Walmart. it pays its employees so little money that they have to use government assistance like foodstamps and medicare. Walmart shareholders reap the benefit, and the public is left taking care of their employees.

Here's a better idea - if a company is making software that's critical to national infrastructure, make them liable for any bugs that occur (and for smaller companies, require them to carry insurance up to a certain level of liability).

The 1200 was second gen Amiga. My first was a 1000 (with the optional 256k RAM module in front) and I preferred it to my Mac. I remember spending $600 for a RAM module the size of a hardback book that hooked to a huge port on the side and gave me (gasp) 1MB of RAM. That was enough to run the whole OS in RAM. This was my bbs machine, and my CI$ and Genie box. I used a C128 to run Quantum Link.

I got a 3000 in 1990 but soon went Mac and Linux for good.

Back when I worked for Supercomputing group at Los Alamos, the supercomputers were categorized into 'capacity' machines (the workhorses where they did most of the work, which typically run at near full utilization) and capability machines (the really big / cutting-edge / highly unstable machines that exist in order to push the edge of what is possible in software and hardware. One example of such an application would be high energy physics simulation) . It sounds like these machines fall into the latter category.

Withdrawing from a treaty is not the same as violating it. In international law, the rule of thumb is that a country is only obligated to comply with the laws (treaties) it has ratified, and is not bound by those that it has not ratified. (Note: One debatable exception to this is the Nuremberg Principles)

Furthermore, countries are free to withdraw from ("repudiate") any treaty at any time, unless that treaty has provisions that provide specific steps for (or prohibit) repudiation.

Just throwing this out there -- two of the major hurdles to doing this right are (a) that Wikipedia's syntax is not formally defined, and (b) that its current implementation is (as defined by the output of the MediaWiki parser) is not a context free grammar. Which means that writing robust, fast parser for it is very hard.