vulf
A force push will still show up in the log. Issues and PRs aren't deletable, so that lends a bit of credibility to this. Sure, said engineer probably has access to erase the push log and delete the issues or PRs directly from the database, but parties involved would likely still have email notifications related to it.
They did: https://github.com/blog/862-block-the-bullies
They never admitted to it being a response to the incident with Zed, but the timing was too convenient. That blog post was dated 05/31/2011. Zed's commits to the repo in question happened on 05/28/2011: https://github.com/moron5/dongml/commit/f4b8df910e4048202768...
In both cases, they wouldn't want him having any potential influence on the investigation. To do that, his power within the company needs to be suspended until a conclusion is reached. The parties investigating (likely HR and the other founders) must be able to do their job without fear of retaliation from the accused founder, that would taint the decision.
First, I make an encrypted disk image with a very strong, unique passphrase (easy on OSX, not sure about windows). In this I put the QR setup codes and my recovery codes. I put a copy of this on every device I own, every computer I own, stash it in my home directory on my server, and put it on dropbox. I then share the dropbox copy to two friends, and instruct them to hold on to it in case I lose access to all my devices. Any time I enable 2FA on a new account, like I did today, I update the image and redistribute it.
I previously kept a copy on github as well as dropbox, but now that both are behind 2FA I wouldn't be able to recover from those sources if I lost all my devices. Maybe I should push a copy to pages.github.io under some secret path that only I knew.
Oh, and check out BitTorrent Sync, it makes it really easy to distribute among my computers and phone without worrying about dropbox somehow losing my files or preventing my access.
You'd be amazed how even small zip files can quickly make a repo an unruly monster. Tread carefully if you take that route.
Keyword: "starting". GitHub has long moved out of the "starting" phase, which has always been bootstrapped for them.
I am not a lawyer, but I would encourage the people targeted by these notices to find a lawyer and fight back.
Hell, that might just be what github is trying to encourage by open sourcing these notices, to get the community involved and defending against baseless DMCA takedowns.
If uptime was a serious factor for you, you'd probably pay for an SLA to ensure uptime and compensation for downtime... and a SLA wouldn't be cheap.
For that matter, I don't think they've ever had an issue that could be isolated to affect only free users, have they?
No service, not even electricity, has 100% uptime. If thinks are that mission critical, you need a backup plan. Should you disconnect from the grid and generate your own electricity? Probably not. But should you expect that it might go out at any time? Yes. If you are not running a UPS than no one is to blame except yourself. If things are so critical that a UPS won't last long enough, then you should have a generator backup.
In contrary, what would the poster have done if his power or internet had gone down when he needed to deploy? Would he be cancelling those services? For some reason I don't believe he would.
The real key to all of this is not a question of avoiding downtime, it's learning from it and avoiding a repeat of the same incident. I think GitHub has done a great job of this, and they're very clear about what happened and what they've done to avoid it in the future. The poster, however, fails at this point. Not only does he admit he doesn't have a backup plan for deploying when GitHub is down... he flat out states that he knows what he could have done, and REFUSES to do it. Instead he's just going to cut and run, thinking he'll find another service that somehow is somehow immune to unexpected downtime. I wish I could live in that world.