In my experience, using public DNS has solved far more problems. Quite often ISP DNS servers are slower to respond, do nasty things like wildcard unresolvable addresses to some dumb search page, and, as you mention, cause CDN requests to be directed to overloaded and bandwidth starved edge servers (and the YouTube CDN in particular when the ISP has its own video service...).

Since Bitcoin is deflationary, it makes more sense to stockpile (or hoard) it than to spend it. That is also what makes it more like a commodity than a currency.

But what is the point of stockpiling something if you never intend to use it? You're making the same argument as waiting until next year to buy a computer because it will be cheaper, but for some reason people buy computers anyway. At some point the holder of Bitcoins will value whatever can be bought with those Bitcoins more than the Bitcoins and an exchange will happen -- with another person who values Bitcoins more for what can or could be bought with them at a later date. Bitcoins are a de facto currency, regardless of what anyone wants them to be.

Call me a skeptic all you want, but I'm telling you, if you put your money into Cobalt60 now, you'll be lucky to even have half five years from now. The value of the USD may be eroding, but not at 13% per year! Stay away from it like it were radioactive!

Coins are old school. The future is in gaseous money! And you'll like this: it's also blue! That's right friends, the future is Iodine131! You can't spend it fast enough! There is so much demand for it that you can't keep it around! Not only that, it doesn't weight down your pockets like Cobalt60, no, you can keep it in your lungs!

I was just about to post that video. A summary from the YouTube video description:

12 things to prevent colony collapse disorder:

#1 general approach: use organic practices
#2 general approach: strengthen bee immune system instead of "attack and kill" what nature uses to remove weak bees
#3 don't use insecticide (for mite control or any other insect problem) inside of hives - bees are insects!
#4 allow bees to create their own cell size (typically smaller) - no more pre-made foundation or cells
#5 genetics based on "survival of the fittest" is superior to genetics resulting from mass production where the weak are medicated
#6 swarming is the natural way to good genetics
#7 local bees have adapted to challenges in your area
#8 stop moving hives
#9 feed bees honey, not sugar water
#10 feed bees polyculture blossoms, not monoculture
#11 stop using insecticides on crops - bees are insects!
#12 raise hives off the ground

You are not alone. I've spent more on games in the last 2 months than I had in the prior 15 years. All thanks to Steam on Linux.

Oh Sn-ap!

Hey man, it's funny if you look on the lighter side.

The Fairview Terminal in Prince Rupert, BC, is undergoing expansion and will be able to handle those ships. It's not in the US, but it's much closer sailing and it's connected to the continental railway network over the lowest (shallowest grade) railway pass (Yellowhead) over the Rocky Mountains.

20 ms from Toronto.

The one other thing I missed is to also think of designing a service oriented architecture. Every role that your system has, such as authentication (I'd use OAuth2), should be its own service. By using clearly defined APIs, it will make it easier to replace pieces of your system with new ones (even written in new languages), and it will give you an interface to write tests against for your tests.

As someone who has written an application that scales to over 1 billion requests per day, let me offer my thoughts.

Scaling your application should be as trivial as launching more application server nodes. If you can't add/remove application nodes painlessly, you've probably done something wrong like keep state on them (this includes sessions).

Don't worry about scaling your application layer at all (within reason). You can always throw more machines at the application side in a pinch, and for a long while it will be cheaper to add servers than to hire someone. When your application servers are costing you more than a salary, hire someone to find the hotspots in the code and make them faster. Until then it's a waste of your time.

Scaling state, aka your datastores, is where the challenge lies. You need to spend a large amount of time sitting down and analysing every operation you plan to do with your data. SQL is great for a lot of things, but you will eventually run into a point where heavy updates make SQL difficult to scale. Mind you, decent hardware (lots of cores, RAM, and SSD) running MySQL should scale to several thousand active users if your queries are not expensive. The Galera patches to MySQL (incorporated into Percona XtraDB Cluster and MariaDB) can give you true high-availability, but you will still have write-throughput limitations.

I would also highly recommend you look into Cassandra (especially 1.2+, with CQL 3), which was built from the ground up to scale thousands of low end machines that often fail (if you can't tolerate hardware failure, you messed up). Cassandra is more limited in the kinds of queries you can execute, more relaxed with data consistency, and more thought is needed ahead of time. On the other hand, it can also be used for global replication, which is something you are interested in. At the very least, having a good understanding of its data and query model will open your mind to the kinds of tradeoffs that must be made to enabling scaling.

Contrary to what others are saying, you are correct to think about scaling now before you even start! Doing a rewrite is costly and expensive in money and time. Why set yourself up for that? Planning for scale before you start is the best time! If you start with a scalable datastore like Cassandra, and structure all your queries to work within its model, it is no more work than doing things in SQL, and you're way ahead of the game!

The most important part is spending time modeling how you will access your data. Think about how you'll avoid hot spots (which make scaling writes difficult), and think about how to make reads fast by reading as little as possible. Think about caching, and how you'll invalidate the cache of a piece of your data without having to invalidate caches for things that didn't change. (Think about updating on data ingestion instead of running statistics later.) If you can't avoid hot spots, make only small reads, and cache independently, you are not done.

Good luck!

Even the high reading of 2.9 microsieverts/hour in that video isn't that bad for a short duration.

The naturally radioactive beaches of Guarapari, Brazil are 10-15 times hotter than that: http://www.youtube.com/watch?v=RvgAx1yIKjg

Even in a large plane passengers make up a significant percentage of the total flying weight. Airline companies just average the cost.

There is gold everywhere, but yes, fault lines are a great way to find certain kinds of gold deposits. If you want more information on why gold ends up where it does, I highly recommend a series of videos put out by the Sprott Group on ore deposists.

SpaceX has uploaded the CRS-2 launch video.