Thirst Labs (thirst.co) is a well funded startup aiming to make consuming social media easier by using natural language technology to understand what is being said.
We are looking to fill 3 positions - iOS developer, Rails developer, and Natural Language/Data scientist.
We offer competitive salary and equity, benefits, a ton of food and drinks at the office, and a great working environment.
really? I've noticed an increase in maintenance with Linode recently but they've always been really great with notice, so much so I am consistently surprised. If there is ever going to be planned downtime I've got an email at least a week in advance and it gives me the option to migrate my linode to another server at my own convenience if their schedule isn't compatible with my needs. Do you not get these emails and options?
For the scheduled ones, I think I did receive some prior notice, I might have gotten particularly unlucky with a bunch of emergency/network/etc. maintenance affecting many of my servers simultaneously.
My problem with them is they don't provide RFOs (Request for outage) because they can't give away any of the "propitiatory secretes" about their setup. I'd like to know what happened when it effects me. Also when it comes to replacing hardware or preforming maintenance, their priorities wont always line up with mine.
Interesting. We moved away from VPS.net for a similar reason. There were multiple occasions where hosts got shut down and support couldn't tell us the reason for it. Since we're using hand-rolled virtualization on top of a few rented servers, we're basically problem-free.
If you use DNS round robin, then you pretty much guarantee that everyone will be affected if just one hosting company is down. DNS round robin is not the tool for this job.
The github link is broken for me as well. Here is the direct link to the github project for anyone else looking for it https://github.com/cloudfuji/kandan
No, really, please don't turn every comment page into a pun thread that would be an end to HN as we know it. Please try to keep it serious and technical, and down-vote if you can this kind of conversation.
We have a variety of Redis machines, some of them are in a consistent hash ring (the ones we're using for caching); some are using modulo-based hashing (the ones where losing data on adding more machines isn't an option), and some are just single-node installs.
How do you handle write replication? I haven't found any good document on how to do this (meaning, if the Redis master goes down, a slave should be promoted to master immediately).
You can hypothetically use something like hearbeatd to do it; we run every Redis master with an attached slave and manually failover for now.
For a small team like ours, we prefer solutions that are easy to reason about and get back into a healthy state (it would take one server deploy to point all appservers at new Redis master), rather than fully automated failover and the "fun" split-brain issues that ensue. Of course that may change as we build out our Ops team, etc.
