lindvall

> Not a fan of Java-based software either, to be honest.

It makes me sad to see this is still something people say. I hope you reconsider this sentiment and investigate some of the really great Java-based software out there, especially Zookeeper and Kafka.

It's worth checking out how Zookeeper and Kafka did in aphyr's testing:

http://aphyr.com/posts/291-call-me-maybe-zookeeper

http://aphyr.com/posts/293-call-me-maybe-kafka

The app looks pretty great. Being able to incorporate the geolocation data from foursquare, instagram, flickr, facebook, etc. would aid in not feeling like you have to think of your traveling as starting when you downloaded the app.

If you're interested in other examples of this sort of solution, this is how Shopify has tackled this problem: https://github.com/tobi/imagery

It looks like tobi also has played around with porting it to go as well: https://github.com/tobi/imagery-go

Ends up that passing the file directly to grep will allow it to use tricks to make processing faster than reading from a pipe.

Can you elaborate on the 4S battery life issue?

I've only had my iPhone 4S for a week, but I haven't noticed anything drastically worse than my iPhone 4.

It certainly hasn't ran out of power during the course of a day yet.

Based on what?

Building really cool technology that you decide to give a way sounds a lot like how many startups have failed.

You've attributed arbitrary value to peoples worth when you have absolutely no way to know if you are correct.

He smelled.

"PBKDF1 is recommended only for compatibility with existing applications since the keys it produces may not be large enough for some applications." — RFC 2898, September 2000

Why are they emailing developers out of the blue to "claim" their profile?

Please don't base your service off of crawling sites and emailing people who don't ask for either.

Really? What is it going to take to get beyond the stupid provocative titles?

Can we work on being constructive? It would be pretty sweet if people started writing post-mortems for crazy bugs they found the way people write them for outages.

What was the process you went through to track down this problem? Were there any interesting tools or processes you employed?

What was the final solution?

What can we (both you and your team and the community as a whole) do in the future to prevent this sort of thing from happening again?

So far I'm not really a fan of forking RubyGems, but I am concerned with the solution you mentioned for compatibility with Rails (which I take as a good metaphor for any large Ruby project) — a new point release. How is that going to work for people on Rails 2.2 or other projects with incompatibilities?

Has anyone discussed emailing the authors specified in the gemspecs of the gems that will be breaking with these upcoming changes?

This post is as vapid as any of the this-NoSQL-datastore-is-better-than-this-RDBMS posts that pop up weekly.

"Oracle also has a large number of background processes all competing for CPU (about 10 for a default installation). They are very efficient, but are still there – for every single database."

How is it at all relevant to start counting how many processes or threads that are being used? In what world is this useful for any conclusion?

I hope this point does not get lost in the shuffle. This whole issue is very much due to the fact that Dropbox did not handle the initial reporting of this problem when it was announced.

Their initial solution to the problem was updating the TOS and calling it a day. DropShip proved there was a deeper problem that needed to be addressed and the fact that their solution did not start and end with a fix to the problem in the code is mind-blowing. This isn't a huge enterprise company. These guys should know better.

Yep. And this may be one of those cases where they would have been better off ignoring their customer requests for the good of their reputation and their customers uptime.

I strongly believe one of the most positive aspects of EC2 was that it demonstrated a beautiful philosophy that a node and their disks should not be relied upon to always be around and pushed it into the mainstream.

Even for people who didn't use EC2 the existence of the platform caused more people to rethink their architectures to try to rely less on Important Nodes.

EBS is a step back from that philosophy and it's a point worth noting.

One of the great things this post does is enumerates some of the underlying reasons why relying on EBS will inevitably lead to more failures and in ways that are harder and harder to diagnose.

It's great to see sites like dribbble and forrst push to make money so relatively early in the life of the product. I can only imagine how hard it would be to make the leap to charge money for a service that could easy be characterized as fluff.

Another aspect of this thread that I find very refreshing is the fact that the previous implementation may have used magic numbers doesn't reduce anyones desire to actually understand what is going on going forward.

The realization that a magic number was already being used could have caused one of two outcomes:

a) justification for replacing one magic number with another

b) realization that more research needed to be done to understand exactly what was going on in the first place

I appreciate seeing (b) as the option chosen. We should all strive to be this diligent.

That is correct, but is based on a philosophy that the longer something has been in use, the less chance it has to demonstrate behavior that has not been previously observed — he even explains that in more detail in further posts where he discusses his desire to not cause regressions.