How long until they graduate to exploiting GitHub and securing proprietary code from private source repositories, or forging commits to critical repositories (how often do you verify that every commit in the repo with your name on it is definitively yours?)

But on a serious note, is DDoS'ing a server that serves mostly static content way too hard? I imagine taking out one of GitHub's ways of communicating what's going on is appealing.

But I can outline the two they discussed. The first is a "complex attack", which basically consists of doing things that make the server overload itself (repeatedly handshaking SSL, etc.), and that would be mitigated to some extent by reducing the complexity of the site (i.e. you can't SSL handshake with a server that only knows HTTP). Similarly, dynamic content could be an attack surface, so static content would make it more difficult to use such a complexity attack.

The other type of attack, a simple bandwidth attack, doesn't care if your server is a top-of-the-line quad-chip Xeon server or an RPi in your basement, because all it does is exploit the bottleneck that is bandwidth. This attack just pumps packets like mad in your direction, and your network will likely become congested (and eventually fail) at some level other than your server (i.e. router level, firewall can't handle 100 Gb/s so the packets never even make it to your server).

So, in light of the second there, DDoS'ing static content is just as easy as DDoS'ing dynamic content sites, as long as you're using a bandwidth type attack.

I encourage you to read the blog post when the site is back up, it's definitely worth a read!

[1] https://github.com/blog/1796-denial-of-service-attacks

http://webcache.googleusercontent.com/search?q=cache:KNnwGeD...

Anyway, I don't think we ugly bags of water have changed much in the last 20 or so years. I wouldn't read too much into this GitHub DDoS event.

Github is a noble company with noble end-goals, and collaborative open-source is a revolutionary "work" idea. To see someone smash a bottle on the counter and threaten the nicest guy in the room gives me rage.

Looks to me you are prone to violence.

But this may not be the sort of brute-force bandwidth DDoS that this was designed to handle either -- it could be a more targeted attack to existing bottlenecks in GitHub's architecture.

"The sight of her male coworkers leering at a group of women in the office was the last straw for Github’s first female hire."

Take a workplace with all-men, and due to sheer probability you're going to get a lot of leerers when any number of women walk in. That's really a bit unfair of an assessment. I'd like to see what happens when an attractive man walks into a workplace that is all-women.

I've been in this situation a few times and it makes me feel incredibly terrified.

I wouldn't have made that comment had I known that DDoSes on GitHub were not uncommon.

The point is that it should be acceptable in either circumstance, not that you shouldn't complain about what happens in an majority male environment because something analogous might happen in a majority female environment.

The important part you should consider is to switch go git. I'd recommend starting to use Github, and if you find that it's down too much, look at alternatives or at hosting a solution yourself.

It works well for us. We just have to pay the price of a VPS and updating the system occasionally.

That said, I have two pushes for two clients this morning that may not make it through in time for the status meetings.

If you have a company full of people, it may still be worthwhile to have a couple of them really learn git, and setup a git server internally.

[Edit: And my pushes made it through anyway. Still happy w/ github]

The big difference is that in the second case you can keep working on your local repo without touching the central repo, at any time add new remotes to your local repo and pull and push from your peers.

If GitHub is down, you just keep working. If your svn server is down, you just pile your local work waiting for it to come back up, the tool will not help you in that case.

Moving from svn to git is a no brainer, even if you keep using it as if it were svn most of the time.

Git has a file protocol so you can also just sync your changes between one another via a network share of your repo. Or SSH or email each other pull requests.

http://www.webupd8.org/2014/03/how-to-install-popcorn-time-f...

http://thinkprogress.org/economy/2014/03/19/3416013/github-j...

Everyone can keep working happily even using other syncing methods to collaborate.

At worst it messes with the issue queues and integration services.