How is Github a monopoly? Bitbucket, Google Code, and even junky old SourceForge are far from unpopular.

I think "monoculture" or just centralization in general would be a better name than "monopoly" for what the OP is getting at. Hacking is all about decentralization to ensure free access. If github implements a policy (surely there's some action permitted by TOS, perhaps which most people would like, that you wouldn't), UI change, etc., you have no real recourse outside of convincing them it's in their best interest to change it to how you like it. With a decentralized system where you run your own node you can modify the code and behavior at your discretion.

On top of the possibility for customization and extension, having more independent nodes means less chance of catastrophic failure. The cloud is remarkably unstable; look at heroku's uptime and at cascading failures even in redundant cloud systems for an example. It'd take the whole internet falling apart for thousands of individual hackers' repositories to all break down.

I don't disagree, but of course centralization is part of what has made github so successful.

There is always this thing about centralization. It makes initial social networks easier to form and the value comes from that.

And then we would like to see people eventually move to decentralized tools doing the same thing. But so far this second phase hasn't been easy. The reason is people building installing these decentralized tools.

We've spent the last 2 years building a platform that will make building and deploying decentralized apps in Node.js easy :)

A platform where one of your friends hosts something you like, you click a button and download and install it from them. Versions propagate throughout the system. The security is a key component -- you need to make sure it is signed by the developer. Also you can decentralize the app stores and centers of trust. If some of them are reporting the software as malicious, you will know.

That last part is hard. You are hosting the software on YOUR computer, so malicious software may be dangerous. It either has to run in a sandbox (as a website does in a browser) or it has to be proven to be safe by someone.

The same way Windows and Office are successful?

No, the way Facebook and eBay are successful.

While I agree that Bitbucket and Google Code are interesting competitors, I think the "popularity" of SourceForge is misleading.

SourceForge is only big because they are already hosting so many projects. I haven't seen any intresting new projects there. And those being there are would mostly be willing to switch to GitHub, if they had enough spare time for that (it's not just the project switch, but also the switch from CVS or Subversion to Git they would have to manage).

GitHub's social features don't extend outside GitHub, though.

Upvoted. They maintain it by introducing an endless stream of bugs and vulnerabilities.

People are upset because they wanted to be part of the elite club that maybe possibly would have had their DNT header honored, but now that it's likely that a huge percentage of other people on the web will have the header enabled, suddenly the header will be useless for sure.

If this header would have only been useful if it was only enabled by a small set of people, then it has always been stupid, and is in no way Microsoft's fault. Imagine a perfect world where everyone using IE organically decided to poke around in their browser settings, find, understand, and enable DNT. Are the trackers now somehow less justified when they ignore it in this perfect world? No, the motivator is the same — they want to track as many people as possible and "disabled by default" is just a thin excuse. People that are defending the idea of trackers ignoring DNT because of IE are engaging in some weird kind of corporatism.

Is anyone else disappointed that the best answer (the standard div() function) was passed over in favor of massively inefficient bit-twiddling wankery?

Yes! I was going to say exactly this. Know your standard library, citizen!

Maybe things are different on Dalvik, but javac for the Oracle JVM is about as braindead as a java compiler can get; all of the optimizing is done during JIT.

A rule for multiple output files:

    output1 output2: deps

Yes, you can do that, but it doesn't actually work the way it should. I don't remember the details any more, but it breaks in nonintuitive ways.

Here's a makefile: http://code.google.com/p/min-game/source/browse/makefile

Here's the dependency script: http://code.google.com/p/min-game/source/browse/dep.sh

Both inspired by code in "Recursive Make Considered Harmful", always worth a read: http://aegis.sourceforge.net/auug97.pdf

The built-in rules and variables for gnu make are worthless for anything but the most trivial project; don't bother with them. I'd be so happy if there was a makefile directive that forced make to run in "make -rR" mode.

"low-level rigid type system"

You've never written C.

Hmm... right, it was something with a C in it, but not sure what! Come on! Don't you have a constructive comment?

You still need entities for reserved characters like & and <

That's right. Totally forgot about those.

There's no difference between implementing method dispatch with multiple inheritance versus multiple interfaces. What do you think C++'s multiple inheritance problems are? As long as Oracle doesn't add data members to interfaces, Java won't get any new problems.

I might be missing something, but what I see as a problem is a situation where: class C implements interfaces IA and IB, which both contain method doSomething() with default implementations, class C doesn't overrides this method, so which implementation is going to be called when method doSomething() will be invoked on instance of C? Will it behave the same way if it is called as instance of C and as instance of IA or IB? Clearly, there are rules in C++ to handle such situations, one may argue that they are problematic.

If there is no way to break the ambiguity the compilation will fail and you will have to override that method (in 8.4.8.4 of the spec). You can use IA.super or IB.super to call one of the default methods if one of them works for you and you don't need your own bespoke implementation.

Thanks for clarifying; although I don't really like this feature, compilation failure seems to be the best solution (and well I guess I should have RTFM to begin with, sorry).

If it's an interface you have to override the method.

An abstract class you don't, but you can only inherit one anyway.