Slashdot Mirror
Github Under JS-Based "Greatfire" DDoS Attack, Allegedly From Chinese Government
An anonymous reader writes: During the past two days, popular code hosting site GitHub has been under a DDoS attack, which has led to intermittent service interruptions. As blogger Anthr@X reports from traceroute lists, the attack originated from MITM-modified JavaScript files for the Chinese company Baidu's user tracking code, changing the unencrypted content as it passed through the great firewall of China to request the URLs github.com/greatfire/ and github.com/cn-nytimes/. The Chinese government's dislike of widespread VPN usage may have caused it to arrange the attack, where only people accessing Baidu's services from outside the firewall would contribute to the DDoS. This wouldn't have been the first time China arranged this kind of "protest."
For the purported great and ancient wisdom of 5000-year-old Chinese civilization, they have pretty lousy leaders.
The West has leaders with minds like children too, but at least we can laugh at them, and eventually get rid of them. Must suck to be Chinese with these idiots in charge...
knock them off the web for 12 hours, open it up... if they continue, block 'em again...
if this is supposed to be a new economy, how come they still want my old fashioned money?
If our country weren't run by lawyers, we'd do what Russia and China do which is allow victims like GitHub to retaliate. Would be hilarious if GitHub contracted a few black hats to penetrate China's academic/military networks and give them a taste of the Wikileaks treatment.
Well considering that apparently f***en CHINA is DDOSing them and they are only experiencing intermittent downtime that is pretty impressive to me. More of reason to switch than a warning against it.
Still, no backups, no alternative plan, your coworker is an idiot.
Troll is not a replacement for I disagree.
Well, the acronym for Socialist In Name Only is "sino".
Not only do they see that message, but the alert pauses the loop that keeps loading the pages.
You put your local github repo on some server, and then have it push its updates to Github. Should anything happen to that server, you can use Github to get a copy. The chances of Github and your local server losing your data is clearly much lower than either on its own, hence it making sense. Or just hate on Github because you are scared and don't understand stuff. Whatever's easier.
You really don't understand what decentralized version control is, do you?
The whole point isn't to avoid any centralization at all, it's that you're not utterly reliant on it. It's somewhat similar to the argument between a big server and thin clients (where nearly all computation is on the server) and "thick clients" (PCs) and less-capable servers (for sharing files, etc.). With a big server, if that server goes down or the connection to it goes down, you're screwed, and can't do anything. With today's more common thick-client paradigm, if your office file server goes down, you can't easily share files with your coworkers and other things are inaccessible, but you can still get some work done using whatever local copies you have.
This is what DVCS is all about. With Git, you have a full copy of the repo just by virtue of having "checked out" a copy. You can still get some work done without access to the central server, whether it's down or your WiFi connection is down or your VPN is down. You can't do everything obviously, nor will you ever be able to, but that's not the point. And, in a worst-case scenario, if the central server just disappears one day without accessible backups, everyone with a copy checked out has the full repository, so it's possible to rebuild easily.
You heard; "We don't need a backup because GitHub is so awesome". That does sound scary.
However, the whole point of Git is everyone who cares about the project has the complete repository, usually with multiple backups, and works "off-line" as normal practice.
Github is just an awesome and easy place to share a copy of the repository. It's trivial to set up another shared repository or just share directly with those involved in the development.
With Git, you have a full copy of the repo just by virtue of having "checked out" a copy.
Quick nitpick: that would be a clone, not a checkout.
For the non-git-users among us:
git clone: copy that repository to my local file-system. (All branches are copied across. This is normally over ssh or https.)
git checkout: give me the specified branch. (Doesn't require use of the network.)
git fetch: update the local store of the repository to reflect the current state of the repository on the server.