That's still weak.

A non-profit's charter can evolve. Consider if the FSF merges with a different organization with a different charter; like the often more corporate-friendly Open Source Initiative.

Would be nice if such a guarantee could be written into the license itself.

Glad I moved to PostgreSQL.

(Nothing to do with Oracle screwing it up - I moved back around the 6.4 relase. IMHO Postgres was always better on Linux/Unix, and MySQL's popularity is really only due to it having a Windows installer first.)

If it were widely known to be not regulated, the insurance companies could have (a) done more proper due-dillegence, and (b) could have set appropriate premiums.

Probably is that the insurance companies were under the impression that there was regulation in place that Goldman knew how to bypass.

Same with most of your examples.

Same situation as any physical-world mining company.

However an oil exploration company accounts for costs related to test wells that ran dry, the same logic should apply to bitcoin blocks.

You might be kidding -- but it seems a great way to handle it in real life.

WoW could even handle withholding so people aren't stuck having to do quarterly estimated taxes, etc.

And if the IRS objects that the withholded-copper isn't worth much, well.......

People keep saying that HFT needs to be regulated to avoid crazy spikes and crashes due to algorithms with stupid positive feedback loops.

I think the opposite would actually work better.

If the official rules stated "HFT is totally *un*regulated --- feel free to run your buggies, most insane, glitchy, and flawed HFT software" --- immediately all the other HFT software systems would be coded to watch for crazy non-justified buying&selling.

With all this regulation, if one bank's trading software starts going insane, the other banks start following them (and creat a positive feedback loop) under the assumption that in such a regulated industry the insane software must know something. If it were further de-regulated, the other software would assume the other software was poorly coded, and basically LOL at the bugs and profit from it until someone pulled the plug on the bad algorithm. And with that risk - I imagine a *lot* of interested would be in automating such plug-pulling checks so they happen in a very small number of miliseconds so the market can't crash too far before the kill switch hits.

You're still welcome to run a ddt-wrt box *behind* your ISPs router (not unlike what you're already doing). They just want to put one more of their routers on your side of the last-mile.

In many corporate environments it's far easier to get approval for a browser plug-in (simply because old IE already requires so many browser plugins to get useful stuff done) than an entire replacement browser.

Some of our customers have annoyingly "standardized" on IE; yet permit "browser plugins" including Chrome Frame.

We use this to deliver the WebGL parts of our apps to them.

Hope Google changes their mind on this.

Did you look hard?

Try this: http://www.phoronix.com/scan.php?page=news_item&px=MTM2ODM

Linux 3.10 Kernel Integrates BCache HDD/SSD Caching

...

BCache comes down to being a Linux kernel block layer cache where one or more SSDs (or other fast storage devices) can act as a cache for slower rotating disk drives, in somewhat a similar manner to some of the "SSHD" hybrid drives now on the market. BCache is similar to the L2Arc feature exposed on Oracle's ZFS file-system, but with being at the block device level, it's file-system agnostic.

Yes; but it's still like 5-500x faster than spinning disks too (obviously depending on if you're talking sequential I/O, or random-acces).

As the link to Netflix pointed out -- they benchmarked the entire system with the same REST API in front.

They configured one cluster of SSD-based servers; which another cluster of spinning-disk-with-large-RAM-based servers. It took a cluster of 15 SSD-backed servers to match the throughput of 84 RAM+Spinning servers. With throughput matched, the SSD-based cluster provided better latency and lower cost.

TL/DR: "Same Throughput, Lower Latency, Half Cost".

Even low-end (dual-CPU 2-U) servers these days support either 192 or 256GB. It's not that hard or expensive to get 4 256GB or 6 192GB servers.

But as that link to Netflix's' blog points out - SSDs can have better price/performance than DRAM at the moment if you need a lot.

This blog article's very relevant: http://techblog.netflix.com/2012/07/benchmarking-high-performance-io-with.html

TL/DR: "The relative cost of the two configurations shows that over-all there are cost savings using the SSD instances"

at least for their use-case (Cassandra).

At work we also use SSDs for a couple terabyte Lucene index with great success (and far cheaper than getting a couple TB of DRAM spread across the servers instead)

ISTM data should be encrypted *before* it goes to the cloud.

That has some UI implications (i.e. gmail can't search the bodies of your encrypted emails). But still seems like a better idea to have your email on your client anyway; so why not have the search index there as well.