As a customer, security is important when you are testing your internal, firewalled, infrastructure. This is one of the main reasons Sauce Labs (where I work) gives every test its own VM that's destroyed afterwards. Using a shared or reused VM opens the door to malicious code running in the background.
Interesting: thanks for that perspective; to be clear, the reason I commented on this at all is because the title didn't make it clear why the security was interesting and the title was different from the title of the article (which is part of a massive debate about whether editorializing of titles should happen on HN; currently, the rules say you shouldn't do it, but personally I think it might be important in numerous occasions), but then the article itself didn't seem to indicate that the security was actually that key to the whole thing. (In particular, the one phrase "highly secure" that is used in the first sentence of the last paragraph seems like a frill to make the sentence sound more awesome: it didn't come after any motivation about how this is a key problem with other solutions, or that that is why the "enterprise" tag is on the idea.) Again: thanks!
I use it every day, editing files locally in Sublime Text 2, and then cmd-tabbing to Terminal to run tests. It's fast enough that I never even think about the delay.
As the author of the article, I agree, it should be obvious. Unfortunately, the security implications of a service like ours is less appreciated by the general user community. Today, there are other services similar to Sauce Scout you can try where you'll see VMs getting reused and sometimes even catch a glimpse of the previous browser session. So we thought it would be helpful to outline our approach and why it matters.
Buildbot is used for continuous integration, which is a big step along the path to continuous deployment. A lot of companies are doing this today. Fewer are doing continuous deployment. kaChing has some posts about their setup:
Yeah, it's important to make the distinction between continuous deployment and continuous integration.
Continuous integration is a fairly simple thing: detect a new source commit, run a battery of tests on it, report back. Hudson is a really good one (of which the original author is a main contributor, and I did some plugin work for a while), and I use it as a fairly fancy looking cron as well.
Continuous deployment, as described in the article, is much more difficult. Not only do you have the slew of tests, but maybe you want more long-running tests that you don't care to run all the time. Maybe you want code reviews. You'll need to automate the actual deployment process and so on.
This is a nice overview of the iPhone vs AT&T debacle, but the conclusion is sensationalized. It may be that Apple and Google are helping the wireless carriers reach new levels of poor service, but the reality is the carriers have never been that good.
In the 10 years I've had a mobile phone, I can't think of any time when people weren't complaining about their carrier and wondering if any of the others were better. It didn't seem to matter who you were with. Like the Mutt motto: "All mobile carriers suck. This one just sucks less."
It's worth pointing out the one major relevant fact they didn't cover, that Fake Steve Jobs pointed out at the end of last year: every quarter after the first "iPhone Christmas" (4Q07, the first Christmas after the release of the first iPhone), AT&T's had lower wireless capital expenditures (capex): http://www.fakesteve.net/2009/12/att-by-the-numbers.html (through 3Q09 at least).
AT&T made a conscious choice to maintain its operating and net earnings at the expense of its quality of service (something we've heard detailed bits and pieces about, e.g. insufficient backhaul, like this article's comments on the not much used in the US market chip Apple used/uses). We'll see if that was a good choice as Verizon et. al. converge on LTE along with AT&T.
1 MW is the rated capacity. The actual amount of energy produced depends on where it is deployed. They go into detail about how much energy is produced on the "fundamentals" page:
There's an article devoted to this topic here:
Security Through Purity — http://sauceio.com/index.php/2011/09/security-through-purity...