vulf

Based on the history of communication with Gruber, they should probably assume no reply means it's NOT okay... but then no progress would be made, ever.

That's also $50/mo minimum to use a custom domain. Github's static page hosting is free.

commit history, push log, and all issues and pull requests

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.

GitHub should have implemented a blocking mechanism to stop people inviting Zed to 'dick' projects

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...

It's not throwing him under the bus. It's distancing him from the investigation. That's both to protect him, in case things favor his story, and to protect the company, if it turns out he was in the wrong.

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.

How? Easily. If you're investigating the matter you want to distance all parties involved from the situation, so that they cannot influence the outcome. If Julie was still employed there, she would have certainly been put on leave as well.

Yes: https://twitter.com/pjhyett/status/89064336454201346

PJ Hyett has been married for many years: https://twitter.com/pjhyett/status/89064336454201346

This may sound extra paranoid, but I've locked myself out of 2FA'd accounts before and recovery is not fun, so I go out of my way to keep the recovery codes secured but available to me in case of catastrophe.

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 could just use the SMS option instead of the app one when you turn on github's 2fa. Then no 3rd party will have access to the secret.

I do believe using Dropbox for distro is against their TOS.

> should be producing small files

You'd be amazed how even small zip files can quickly make a repo an unruly monster. Tread carefully if you take that route.

That's using the zips github generates for every repo, not the downloads section of the repo.

When github says "We are disrupting how software is written in the enterprise", the very first thing that comes to my mind is not catering to companies that won't give up IE6.

That went away some time ago, when the latest redesign of the page was put up.

> Bootstrapping in business means starting a business without external help or capital.

Keyword: "starting". GitHub has long moved out of the "starting" phase, which has always been bootstrapped for them.

When you are just starting out and have no real leverage in the deal, sure. But it sounds like the GitHub guys were the ones holding all the cards in this deal, maybe they made sure the terms of the deal excluded that "general rule".

Did you at least try to contact their support? If "someone is in on it" and they're all laughing at you already, yea, nothing would happen. But what if you're just making assumptions about them for no reason? it's hard to cry that they hate you and won't do anything if you didn't try official channels to get shit fixed.

HN has a rather specific audience though. Reddit and 4chan have a fairly general audience in comparison.

Indeed, this was pulled how long ago?

I would guess that github doesn't consider themselves legal experts and does not want to get involved... if they comply with the takedown they get immunity from liability here. The DMCA allows the allegedly infringing party to file counter-notice if they feel they are not infringing and the takedown notice was in error, I would bet github is leaving it to those users to defend themselves.

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.

You should report to security@github.com next time.

Users can add a pledgie donate button to their repos: http://github.com/devinross/tapkulibrary Looks like it's bigger than that signup button too...

Indeed, GitHub's terms even state "GitHub does not warrant that ... (ii) the service will be uninterrupted..."

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.

I've actually been in that exact situation. Yes, the unit test should expect that once it offloads the message to the SMTP server that everything works correctly, but there should also be another set of tests that ensures the app fails gracefully when the SMTP server is not there. Once you have that, then you should find a more reliable solution to the STMP server failures.

The spelling/grammer issues just add to the feel that your post was a pissed off rant. My own typing goes to crap if I'm in a rage. The key is to wait a period of time to cool off and go back over the post and fix the errors before you send it, that's all.

How would they do that though? If you look at the details of what cause the outage, it was not a matter of free vs. paid users. Even if they added extra redundancy for paid users that they didn't give free users, that wouldn't do any good in the case of a site-wide failure, which is what they had.

For that matter, I don't think they've ever had an issue that could be isolated to affect only free users, have they?

The electric company analogy is a good one, but I don't think you're looking at it correctly.

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.