Hacker Newsnew | past | comments | ask | show | jobs | submit | vulf's commentslogin

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


I'm still trying to figure out exactly what the sequence of events was there.

As best I've been able to work out, whatever juvenile oaf created the "dongml" repo added Shaw to it in order to harass him somehow, and Shaw responded by writing a script to constantly commit changes to the repo which essentially rendered it empty, which seems reasonable both as retaliation in that specific case, and for general reasons of good taste. Then, in response, Github added a feature so that the "dongml" infant could block Shaw.

Would anyone with closer to firsthand knowledge of the incident care to let me know whether I'm on the warm side or the cold?


You're close. Someone added Zed to the dongml repo just to be annoying, and Zed removed himself. But the inviter just added him again, and Zed complained that there isn't any sort of confirmation to indicate, "yes, I'd like to be part of this project," so people can add you against your will, which happened repeatedly to Zed with dongml. Eventually, Zed retaliated with his commit bot, and github apparently looked at that situation and decided that it would be best if they added a feature that let you block other users. However, the idea wasn't that dongml would block Zed's malicious commits, it was that Zed would be able to block the person that kept adding him to dongml. In other words, the github feature wasn't to prevent Zed's malicious checkins directly, but rather block the behavior that annoyed him into making them in the first place.

Zed wrote up a long blog post telling the whole story but I think it's been deleted since.


> Zed wrote up a long blog post telling the whole story but I think it's been deleted since.

The internet has a way of unshutting the whole thing up: https://web.archive.org/web/20130117043748/http://sheddingbi...

and the followup https://web.archive.org/web/20120619005253/http://sheddingbi...


Ah. Judging from the followup, and Zed seemed to be satisfied, I think I was wrong about GutHub: they handled this very well.


Ah. I think I read about it before they'd done that. Thanks for the update.


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.



Heh. Favorited by Tom's wife.


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


I stand corrected.


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.


Except the NSA party...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: