HN user
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:
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.
I wish the title wasn't so much about "Stop doing ___" but the contents of the article are good for people to be aware of.
These are little details of how systems work that are just brushed over too often but are important to get right.
This poll was created to gather feedback related to conversations on this thread: http://news.ycombinator.com/item?id=2445447
The role of timing is interesting. It makes me wonder if a time-of-day-and-week based weighting could help out to reduce the need for posters to be so concerned about when they are posting.
Campfire, not Basecamp.
...where is the API for stars?
Can you build Honeycomb?
I'm confused how charging $0.99 will solve the problem. If they're forced to charge anything through in-app purchasing, wouldn't it be the same prices they are charging on their pricing page on their website?
Small nit: You can download Oracle 11g (or 10g) strait off their website for free — you just need to sign up for a free developer account.
Here's a link: http://www.oracle.com/technetwork/database/enterprise-editio...
Because they don't really say this until you get to the 3rd or 4th page: This is a way that they can deploy your Java applications (packaged as a WAR) for you.
I've been wanting a Jawbone Jambox ever since I saw the video that @lonelysandwich did for them: http://www.youtube.com/watch?v=XgC3zjNH1oU
I've been very happy with Scout (http://scoutapp.com/) for monitoring. It's a nice mix of standard monitoring and a pretty simple plugin system for custom monitoring.
All of the plugins are written in Ruby and the interface for reporting data is pretty simple.
I'm using it for everything from monitoring the KB/s that systems are swapping (and alert if it's anything measurable) as well as custom things like job queue depths.
For the people who are unhappy about the lack of "attribution", it seems almost as silly as complaining you can't see what web browser was used to submit a tweet via the website.
While it may have been interesting to see, I think there is a perfectly reasonable argument to be made for simplifying an interface and removing as much noise as is possible (especially as they've added so much information/noise to the new interface).