The real problem with that is some of the platform dependencies won't be clearly visible until you've ported the code to other platforms. You may have designed something that works very well with one platform, but is insupportable on another. I believe there is something akin to "the rule of 3", where you only know if something is truly portable if you have successfully ported it to at least 3 different platforms.

Wouldn't this also apply to Apple, who a few years ago declared they were expanding their campus? I believe there was a video of Jobs talking to the Cupertino council. Now their share price has had a meteoric rise.

If they innovated and provided compelling reasons to use their APIs, developers would not want to use a third party API that continued to lag behind. However, third parties are motivated by customer demand to keep up with the latest changes to the API (see MonoTouch). This argument is pretty much moot.

The real problem is NeHe's tutorials are painfully out of date. Modern OpenGL has deprecated or removed a lot of the functionality that is used in those tutorials, and there doesn't seem to be any update for OpenGL 3 or 4.

It's an election year, we Australians need to ensure he is not re-elected. I'm not sure how to go about this, but anyone who has an idea, I'd be willing to help.

That's not true. You have a choice as to what OS you want to run on your desk, and what machine you want to run it on. Mac OS X, Linux and Windows are officially supported - I haven't seen anything else.

Are these x86/x86-64 CPUs? It wasn't particularly clear to me.

You aim for 100% coverage.

There are also situations that force your hand. If you're using a C library, and you provide it callbacks, if the library wasn't compiled with exception handling support (very rare for C libraries to be on Linux), then you're out of luck. If you throw an exception your whole program fails, you have to longjmp() to a safe point inside your C++ code from where you can throw. I find I have this happen a lot with image libraries, e.g.: libpng and libjpeg.

Best solution is to have all your objects set up before your setjmp(), then when you longjmp() back and throw, your objects should be cleanly deallocated.

There are also advantages to Subversion that Linus states himself [1]. Really the only one of note is that Git isn't so great at having multiple projects in the one repository and the recommendation is to have one per repository and have a super-project that contains pointers to others - which isn't so great a solution.

[1] It was stated in relation to the layout of the KDE repository: http://git.or.cz/gitwiki/LinusTalk200705Transcript