dolinsky

"It depends"

As someone who has gone through this for some 20 yrs, it's usually a faster commute to travel from Hoboken to pretty much anywhere along/south of the PATH line during peak hours (so 34th down to the southern tip of Manhattan) versus a starting point of the UES/UWS (which is where the comparable housing exists).

My commute from Hoboken to various startup locations in NYC was consistently ~45 minutes door to door, versus an hour for my friends on the UES/UWS.

forgiveness > permission

An A for effort considering it's an April Fools joke.

If that were the case then wouldn't a more appropriate solution be to lock commenting altogether after a particular time since thread creation (or an expiry after falling off of the front page?).

Fall back - spring ahead

> Tags point to branches, but they don't get updated.

Did you mean to say tags point to a commit?

remote branches can also be achieved with one flag by using `-r` ( git branch -r ). Neat note about the reasoning behind stash.

I assume you're referring to the use of the different flags?

For the latter two, no disagreement there. For the former two, there is a difference between returning a verbose response within the context queried and expanding the inclusive parameters of the query. 'git remote -a' makes no sense as all remotes are equivalent (there is no such thing as a local remote).

To clarify (and answer @sureshv), Varnish allocates one worker-thread per session (active connection), but those threads are pooled by the managed thread pool @sureshv referred to. It's recommended to leave the thread_pool value at 2 and scale the thread_pool_min and _max values to suit your traffic.

As for the handling of the websockets, setting the pipe_timeout variable in the vcl file would release any persistent, yet silent, connections.

Overall I enjoyed reading the article and the specific tradeoffs you had to consider when comparing Riak to Mongo for your specific use cases. I'm curious if you had any problems w/r/t the 3 items you highlighted above when using Mongo, as none of those were mentioned in the linked article.

(these points are for MongoDB 2.0+)

1. Adding a new shard in Mongo will cause the data to be automatically rebalanced in the background. No application-level intervention required.

2. Node failure (primary in a RS) is handled without intervention by the rest of the nodes in the cluster. Network partitions can be handled depending on what the value set for 'w' is (in practice it's not an isolated problem with a specific solution).

3. Using mongos abstracts the need to know what node any data is on as each mongos keeps an updated hash of the shard keys. Queries will be sent directly to the node with the requested data.