Nope.

Agreed!

If your system has a complexity of X to build, and using a traditional RDBMS solves Y% up front, it adds an ongoing Z complexity overhead in growing/maintaining the system over time. NoSQL may have a lower Y, but it 's goal is to also have a lower Z, and can often win out in the bigger picture even without talking about massive scale. It's not true all the time, but in my experience it's been the general rule :)

In any sufficiently complex system a combination of both usually work well together. I heard a good offhand comment this week of "80% of the structure should be in an RDBMS and 80% of the data should be via NoSQL" which makes a lot of sense to me.

The first artificial signal we've received via a medium we're only just discovering, perhaps? :)

This thing is amazing, as long as the kids don't start watching youtube :)

I love the allusions, ties to earthly terminology, familiar yet alien setting, deep history and constant geeking out. It's a tremendous book so don't listen to the reviewer. Imagine it as an alien story that someone actually translated/localized in every way possible, then consider what math and theory as a fundamental religion might do for long term stability.

We also already have one of these in the US, a decommissioned underground facility converted to an ultra-secure datacenter with green power, http://usshc.com/ who also hosts a number of open source projects like http://jabber.org/ and has stellar service and commodity rates.

Maybe you should have tried reading the "What's in the box" section:

• Micro-DVI to DVI adapter
• Micro-DVI to VGA adapter

That lets you connect an Off-the-shelf MacBook Air to anything you can connect an Off-the-shelf MacBook Pro.

I'm not saying you won't get nibbled to death in other places (*cough* iTunes rentals *cough*), but this isn't one of them.

Massive polling for updates leads to scalability problems? Big surprise! We need to learn that HTTP is not always the best technology for the job. Just-in-time content delivery requires a different set of tools. There's already an Internet-Draft for sending Atom feeds over XMPP (a.k.a. Jabber), and the same "publish-subscribe" technology could be used for RSS (or a smart service could translate to Atom so your client doesn't need to parse all those RSS formats). Check out PubSub.com for a real-life implementation of the basic concept (they track 3+ million feeds and notify you when a feed you're interested in has changed, and even do handy keyword-based monitoring). And one added benefit of using the XMPP pubsub extension is that these are all open protocols with many open-source implementations. In this problem-space at least, HTTP is so second-millennium!

Exodus is my personal favorite. Clean interface that is similar to most email clients.

The allegation that Jabber, Inc. "has patents on stuff you need to implement jabber" is absurd and ill informed. Jabber, Inc. did not even exist when Jabber started, and because Jabber has kept everything in the public eye, and basically put the protocol in the public domain, it's near impossible for Jabber, Inc. to actually own any part of it. Yes, they own the trademark, but as stpeter pointed out it is being transferred to the JSF. It's also true that Jabber, Inc. has many commercial products, but the open source community has something equivalent to most of them.

As to their commitment to the open source community they have people such as myself and stpeter on their payroll that really only work on open source projects and tools. Neither of us have worked on any of the commercial projects in quite a long time.