There are actually 3 categories:

• Implementation Defined: the implementation (compiler, standard library, execution environment) has to document what happens. Code relying on this is not portable.
• Unspecified: the implementation can choose to do what makes sense, and not tell you. Even reverse-engineering and relying on what you found out, is unreliable. The actual address returned by malloc is unspecified; is it aligned? Does it always grow in value if nothing was free-ed? You shouldn't even care about this detail, so the standard leaves it unspecified.
• Undefined Behaviour: you wrote something that doesn't make sense, if you get lucky the compiler/standard library/operating system will react in a sensible way, but the standard says it's not the implementation's fault you get something wrong as a result. Things like reading variables before initializing them.

Diagnosing UB can be too demanding from the implementation, so the standard doesn't even require it. How would you diagnose incorrect usage of realloc? Add run-time checks? Write a special rule in the compiler so it knows about realloc? Extend the language with metadata? What if realloc is hidden behind a user-defined function? At some point you have to stop, otherwise you could even solve the halting problem.

Good troll, sir. Try removing everything except /boot, see how much your computer can do.

The gpuocelot project has been able to run CUDA in non-NVIDIA hardware for some time now, including x86 CPUs and AMD GPUs.

Too bad the CUDA compiler often segfaults on ordinary C++ libraries even when they are host-only (in which case nvcc is supposed to just forward it to GCC). Hopefully the LLVM-based compiler for OpenCL 2.0 won't be as buggy.

This. If it's your job to go and fix his mess, do it without complaining. And document all the effort you put into it, to avoid being labeled as someone that just rewrites code without adding anything.

If you are not responsible for cleaning after the senior, then don't do it, let it all rot until somebody (your boss, or even your colleague) makes the decision it's time to clean the mess.

Oh, I just looked up his info, the guys is a lawyer, so he's fully aware of the contradiction. He's either trolling or utterly incompetent in copyright law.

No, if there is no license, nobody is allowed to make use of the software. Look up what the word "license" means. Copyright laws assume that every creative work is fully protected unless explicitly stated otherwise.

In a world without copyright laws that would be feasible. But we don't, and it isn't. Commit code with no license and legally nobody is allowed to distribute your software. No company will ever willingly use your code, even if it does something unique and useful.

Grow up you hippie and accept that you have to learn something about laws before you interact with society.

ODE only does rigid body dynamics, no force fields. The guy just need a basic game dev tutorial on force integration.

Wrong. They use different kernel versions, with different kernel patches. And most importantly, the userland apps certainly differ here and there. The most important example is the Mandriva Control Center. It's task-oriented, making it far more friendly than searching for configuration tools by name - in particular, if you have a localized system, where translations are often arbitrary and non-intuitive.

For specific examples, check out Mandriva's wizards for video cards, disk partitioning, network setup, network sharing. Now try to setup those things under Ubuntu without hitting the Ubuntu forums first.

That said, network card compatibility is pretty much hit or miss, as they often depend on binary blobs (either proprietary or windows drivers) that break in different ways with different kernel versions. My dad's current laptop's wifi only works reliably with WEP, not WPA, while mine kernel-panics with WEP. I bet bugs would manifest themselves differently on Ubuntu.

CMake is there in the summary. Maven is not that popular probably due to its design to do "everything".

What seems to be really missing is autotools. Even if you don't want to admit it is better than most alternatives, it's the only one that really solves a ton of problems that no other tool is able to handle. Simply reading through the autoconf, automake and libtool manuals will teach you a lot about the many issues most other tools just ignore, or solve poorly.

Apparently, games where you launch deadly projectiles at enemies. I'm surprised they didn't have a "Jump" or "Save the world" genre to match that. Read it as "random genre because we don't actually play games so we have no clue".

It's funny how the so called "homebrew" community is quick to hand anyone's head in a plate, when these companies would very much like to hang them all together. It's not like the bits fail0verflow didn't break were any harder anyways. They brought the pirates 80% of the way in, Geohotz already had the last, say, 15%, only feasible because of the first 80%. And fail0verflow now claims they have no responsibility on the piracy matter.

I don't have anything against the fail0verflow dudes, but I'm sure I will have an ironic smile on my face once one of them gets canned in the same way.