5 ms·
You've got an additional problem though, which is that this tells us you have two support channels: one that doesn't work (i.e. yours, the one you built), and o
by rdiddly 7y ago
You've got an additional problem though, which is that this tells us you have two support channels: one that doesn't work (i.e. yours, the one you built), and one that does (Twitter-shaming). The first channel represents how you act when no one's watching; the second, how you act when they are. Most people prefer to deal with people for whom those two are the same.
- buzzerbetrayed 7y agoAs someone who has been blown off by DO support, you hit the nail on the head.
- deleted 7y ago[deleted]
- dkersten 7y agoAs a DO user who was planning on ramping up usage in the coming weeks and months, this is what scares me and what is making me seriously reconsider.
- xvector 7y agoDo not use DO. The very fact that their default response to suspected spam is to cause prod downtime is so bizarre and unacceptable that it does not make any sense whatsoever for a business to rely on them.
- dkersten 7y agoThanks, I’ll stick with AWS then.
- sneak 7y agohttps://github.com/fog/fog/issues/2525 https://github.com/fog/fog/issues/2525 https://news.ycombinator.com/item?id=6983097 https://news.ycombinator.com/item?id=6983097 Running anything business or privacy critical on DO is madness.
- nathan-io 7y agoIndeed, this was bad. I assume they were trying to extend SSD lifetime by reducing writes. It's fair to note that scrubbing is now the default behavior when a droplet is destroyed, so they did listen to the feedback. https://ideas.digitalocean.com/ideas/DO-I-1947 https://ideas.digitalocean.com/ideas/DO-I-1947
- sneak 7y agoThe SSD thing is a red herring. You do not need to scrub or write anything to not provide user A’s data to user B in a multi-tenant environment. Sparse allocation can easily return nulls to a reader even while the underlying block storage still contains the old data. They were just incompetent. On top of all of that, when I pointed out that what they were doing was absolute amateur hour clownshoes, they oscillated between telling me it was a design decision working as intended (and that it was fine for me to publicize it), and that I was an irresponsible discloser by sharing a vulnerability. Then they made a blog post lying about how they hadn’t leaked data when they had. Nope.
- iamaelephant 7y agoI think it says a lot that this CTO joker flew in, regurgitated the standard-issue "we will endeavor to do better" apology and left without answering any of the very legitimate follow-up questions. I would never deal with an organisation that behaves like these guys.
- thanatos_dem 7y agoIs there any response that would satisfy you?
- perlgeek 7y agoHow about "we will reimburse the company for any damages if we found it was our fault"?
- isoprophlex 7y agoIt's been 7 hours, some follow up answers would be nice...
- skywhopper 7y agoYou are being unreasonable here. He promised a postmortem. I’d much rather wait a few days to get a clearly written, comprehensive analysis of the problems than to get an immediate stream of confusing and contradictory raw data. If you have ever been involved in post facto analysis of a process breakdown like this you know how hard it is to get the full picture immediately. Rushing something out does no one any favors.
- thanatos_dem 7y ago7 hours, on a Friday night in the headquarters time zone. This issue is resolved and is clearly not wide spread, so does getting a response on Monday or Tuesday vs right now make any difference? Companies are made of people. Let the people have a life. Their night is shitty enough as is after this, I guarantee you.
- 7y ago
- mekane8 7y agoSo well written. This is exactly what's so scary about this whole thing.