You are exactly right, this is a serious accusation and he should have contacted Tandberg before making claims like this. And if he had done so he would have found out that the code that the patent was based on was checked in to the Tandberg repository more than half a year before the code in x264 was checked in. Tandberg is preparing an official statement about this as we speak. Making serious accusations like this without first contacting Tandberg is irresponsible and unprofessional.

I would disagree and say that making a good API instead of just exposing the underlying architecture directly is an art. With experience you start to see how people often go wrong in the same ways when trying to use your API and it becomes a game of trying to make the API in such a way that 1) all errors are caught 2) all the possible ways you can use the API which is not an error actually work and 3) that it's relatively intuitive to write good code with good performance.

You forgot:

6) Paid a lot of money to do it.

http://arstechnica.com/microsoft/news/2009/09/first-look-microsoft-security-essentials-impresses.ars

An in-depth look at Microsoft Security Essentials, it made me decide to try it out on my girlfriend's laptop (I run OS X myself) and it's worked great.

The computers just brute-force chess, but a team of human+computer (look up "Advanced Chess") is much stronger than just a computer. This is because humans have much better chess intuition, so if they can rely on the computer to double-check that they haven't missed some tactic twenty moves deep in the position they can do really well. It's a bit like using a calculator when you do maths, you can avoid basic errors and do the basic calculations faster but you still need to come up with a plan of how you arrive at the solution.

Needless to say, in the game of Go computers are still pretty pathetic.

You do realise that the SxS cache is primarily used for system libraries like the C runtime, MFC and ATL? I've yet to see any third party ship their libraries as SxS assemblies. I think it's probably quite important that it's hard to compromise the system DLLs, and since almost all programs use them it's a huge win to have them in the SxS cache instead of distributing them in each application's directory.

You think public key signatures of the executable and it's dependencies is not real security? ... Then what is?

if one of your DLLs were complied with one version of the datastructure and the other with another version, how else would you try to run this? Do you think the libtool system can solve this? ... Of course it goes wrong if your application starts sending datastructures between DLL A and DLL B which are using different major versions of DLL C, but you can actually code around this. It's better to upgrade your dependencies so they use the same version of DLL C, but sometimes that's just not possible so you have to work with what you've got.

This was a _minor_ version update which means that the newer library gets loaded even for DLLs that reference the older version. So I think your points are all not valid. It's just that this guy forgot to include the runtime libraries in the installer or had some kind of weird setup where he was not including the patched version of the runtime libraries even after his build machine had been patched.

Why do you think it's a hack? I mean, the manifest files used by the SxS assembly system are much more expressive than the three digits used by libtool versioning to tell which shared libraries can be loaded for a specific process. Also note that two DLLs loaded into a process can reference different major versions of the same third DLL without a name clash (leading to two versions of it being loaded), while that's AFAIK not possible with shared libraries.

http://www.freesoftwaremagazine.com/books/agaal/building_shared_libraries_once_using_autotools

The SxS system also has some additional security since it uses signatures for the DLLs when loading your process, so it's much harder for a hacker to replace the library you're using behind your back (by setting LD_LIBRARY_PATH for example).

Everybody who developes applications for the Windows platform should know that you need to include the merge module for the C/C++ runtime libraries in your installer. You've just been luck so far that other applications have installed the DLL's you needed for you. Try your app the way it is on a clean install of Windows XP without the service packs and see how well that goes :P

In fact the SxS assembly system in windows is the only real way out of DLL hell, much better than the versioning scheme for shared libraries used in Linux. Get your facts straight before posting.

... with the ability, knowledge and inclination. The real problem is that they can all make twice or more money by doing some other line of work. This is a matter of paying what is necessary to compete with the other possibilities open to mathematically able, knowledgeable and inclined people.

There is no doubt that multi-core, multi-cpu programming is the future, but at the moment the tools are bascially crap. At least with CUDA there's a programming paradigm that's actually usable, but there is still no way to debug your program. Well, you can run in emulation mode, but your code will run so slow it never gets to the point where the bug occurs -- and anyway if you have a non-trivial bug it won't behave the same. And CUDA has the _best_ of these next generation toolchains. Until you have real debugging and profiling capabilities, even the best programmers won't be able to reach the level of productivity they can on more mature platforms...