For those who want to explore the DNS based services there are a few options. These services seem to very similar and most of them are $5 a month.
I have been using http://playmo.tv for just over a year and I get my daily dose of Netflix, Hulu through my Apple TV.
Prior to discovering "geounblocking" I must admit how oblivous I was about the advances in streaming media :s I am happy to pay for the conveniences of streaming Netflix, etc.
There are a few options when it comes to geo unblocking dns services and I agree with harisenbon - although I am using http://playmo.tv (happily for over a year now)
Restricted access is all to familiar for me although the situation feels slightly better than in the rest of Europe.
A recent trend in bypassing geo-restricted content seems to be a DNS solution. I signed up for an account with playmoTV (http://playmo.tv/) a couple of months ago which has work quite well in streaming Hulu Plus, Netflix, Pandora and Spotify here in Iceland. In addition it's quite ironic to see DNS layer being used to grant access to restricted content while SOPA/PIPA plans to use it to restrict access even further.
Their focus is to enable access to US content but I have it confirmed from their help desk that UK support (BBC iPlayer, Sky Go and ITV) is soon to be announced. Might be something to look into for the Olympics.
The Python services probably end up getting rewritten at some point but I want to focus on delivering a product. Right now the Python services can easily be deployed as the don't have that many dependencies on other libs. All further development will be done in Clojure though.
Of course most things can bee pooled into a multiprocessing pool. It's just a matter of the pain you have to endure while doing so. For some tasks it's a straight forward process while for other tasks it can be pretty painful. The crawler is IO-bound but most of the collaborative filtering algorithms are CPU-bound and having nice concurrency constructions in the language is a bonus.
Thanks for some very spot on points. I do mention multiple processes in the blog: "Fortunately not all problems require concurrent solutions as they are either IO-bound or can be scaled by forking multiple processes." And this can be a solution to many of the scaling needs. Some of the challenges I'm facing are however more CPU oriented and it gives me a warm feeling to have a concurrency model like STM to lean on.
I totally agree with you on the point regarding worrying about delivering a product instead of rewiting the work. That's why the services already written will remain in place and I'll there fore be running Python alongside the Clojure/JVM stack.
Just to collaborate a little bit on this point. With leiningen things are not too bad.
A typical deployment instruction file (project.clj) looks like this and with "lein deps" you're all set up in a few seconds.
(defproject leiningen "0.5.0-SNAPSHOT"
:description "A build tool designed to not set your hair on fire."
:url "http://github.com/technomancy/leiningen
:dependencies [[org.clojure/clojure "1.1.0"]
[org.clojure/clojure-contrib "1.1.0"]]
:dev-dependencies [[swank-clojure "1.2.1"]])
To be honest I've never given F# much of a chance. Mainly because I do most of my development on Mac OS X or Linux. But I've seen some cool introductions on F# and the integration with Visual Studio (mainly from CUFP http://cufp.org/videos/keyword/59). I'll be keeping my I on it. Thanks.
https://github.com/zeromq/curvezmq
CurveZMQ was recently announced by Pieter Hintjens (one of the 0mq contributors) on his blog:
http://hintjens.com/blog:45