Nonsense. Unlike the iPhone, Android has always allowed installation of apps without going through the store. You can download them through the web browser, install them from the SD card, and there are 3rd party market apps that compete with the Google market.

1998 called. It wants its flamewar back.

One of the primary reasons manual memory management sucks is even if your code is beautiful and perfect and doesn't let a single byte slip by, you might be required to interface with a library written by a neanderthal that codes by beating his club on the keyboard and creates all sorts of incidental memory errors that don't affect the immediate functioning of the library, but have side effects for your program as a whole (memory leaks especially). Memory safe, garbage collected languages dramatically reduce these sorts of problems.

I've always wondered what would happen if you were to encrypt a file over and over again, with different keys.

You get Triple-DES.

Also, consider that encryption algorithms are not magic. Having no distinguishable pattern to attacker is the goal, but the data is not actually random! Encryption comes down to applying a set of mathematical transformations on your data which leaves "fingerprints" in the cyphertext if you know what to look for. Applying more than one algorithm or the same algorithm more than once at best adds a security-through-obscurity aspect to hinder reverse engineering, at worst may introduce patterns that make your cyphertext easier to attack compared to simply increasing the key size used with a single well designed algorithm.

IANASR (I am not a security researcher)

I had higher hopes for the original article in discussing specific technical reasons for choose one API over the other aside from the issue of platform support.

From my perspective, the the controversy boils down to a handful of actual issues:
  * Quality of drivers. D3D drivers have historically been more solid than OpenGL drivers on Windows. This is less of an issue these days with Nvidia. Unfortunately ATI OpenGL drivers remain a bit flaky.

  * Market. I believe that the very high end graphics workstation market (think Hollywood CGI artists, CAD, etc) is still invested heavily Unix (Linux) based tools. Nvidia has a much bigger foothold in this market than ATI which explains why Nvidia has superior X.org drivers and better OpenGL support all around.

  * Bleeding edge technical features, if you are trying to achieve some advantage in rendering quality over your competitors. This makes sense in the graphical arms race of gaming, but most of the rest of the visual simulation industry (3D modeling, CAD, scientific computing, government/military, etc) don't care about the cutting edge as much.

  * What your 3D engine of choice supports. Writing a whole 3D engine from scratch is going to be silly most of the time with the many commercial and open source 3D engines now available, so you are not going to be writing a whole lot of bare D3D or OpenGL code.

Like a lot of other areas, Microsoft's development solutions work great if you stay in the Microsoft ecosystem. As a pure business decision sometimes it makes sense.

What irks people (including me) is when Microsoft deliberately or de factor freezes out the competition; this is where we end up with frustrating situations like the case of ATI having inferior support for OpenGL on Windows. There's no technical reason for it, just someone manager's decision on how to allocate developer resources. Longtime Linux users know this is a story that has played out with many devices; usually there is no technical reason a piece of hardware can't be used on Linux, it is simply a matter of the manufacture choosing whether or not to devote additional resources to supporting platforms other than the one with the biggest market share.

So ultimately it is about mindshare and putting pressure on Nvidia and ATI step up to the plate to have good OpenGL support, and encourage Microsoft it is not in their best interests to screw over Windows OpenGL users.

(did I mention enough times how much ATI OpenGL driver quirks annoy me?)

WebGL is a canvas drawing API (basically a binding of OpenGL ES 2 into Javascript) and not a document format (the equivalent document format would be something like X3D). You could probably implement a SVG viewer in Javascript that rendered to the canvas tag, but Internet Explorer doesn't support the HTML5 canvas, either.

America's Army licenses the Unreal engine.

The closest I know of to a general purpose engine intended for military simulation apps would be Delta 3D (http://delta3d.org) but that is more of a small-scale academic project than a robust product effort aimed at developing a product.

Open Scene Graph (http://openscenegraph.org) is pretty widespread in the visual simulation industry, but hasn't gotten much traction in PC/console games sector.

The Army deals a lot with modeling real-world places based on GIS data, which creates a whole slew of toolchain and scale requirements that are not typical in the entertainment industry, where you get to make stuff up.

Also, personally I think Army sims should invest more in graphics quality to improve immersion, but the management usually see it as a waste of money when you could be madly cramming more features into the product instead. Pretty much the same issue with any other software development, actually.

From experience, working on an Android app in my spare time -

1) The SDK runs on Windows, Linux and OS X. This is a big plus since you can do development using desktop platform of your choice.

2) Android is Java based, which is a relatively civilized language compared to C/C++/Objective C (the relatively safe memory model of Java avoids whole classes of bugs based on memory mismanagement, buffer overflows or wild pointers).

3) Eclipse is a pretty powerful development environment. Having not used it prior to Android development, I'm pretty impressed at its ability to detect and offer to fix syntax errors automatically.

4) Running and debugging your app in the simulator Just Works

5) Access to existing Java class libraries and ability to share code with desktop apps (with some reservations, as android does not support the entire java.* standard library)

6) Multiple ways to install your app on an actual device without going through the Market (can download the .apk over WiFi with HTTP, for example)

Overall, I would say the development experience is pretty close to normal desktop app development. There isn't a big feeling of "going without" that I would have expected from embedded development - the one exception being filesystem storage, as users cannot be expected to download and install hundreds of megabytes of data required by your app as might be the case on the desktop.