Linux has one 'survival of the fittest' characteristic that guarantees its long term success. It is open source and has a real community behind it.

To briefly address your other flamebait points:

IBM is not the only major contributor to Linux. Major corporate contributors include lots of well known names. In fact, Linux development is largely corporate contributors.

As for the obvious troll is obvious point about SCO, I would just say that SCO turned out to be little more than a bump in the road. A pimple on the butt of closed source software. Your mention of SCO seems unconnected to what leads in to it.

The EU investigates Apple. And Toyota investigates Hovercars.

Hey now, a C64 can run a small TCP implementation with a Finger daemon.

You could offer the ARM-only and Intel-only APK's on Google Play store, and then offer the larger combined APK file on other stores that do not support processor specific binaries. Make the app version number somehow indicate which one it is, maybe with a one letter value in the version. Then insert these lines into your header files...
#define struct union
#define while if

That argument works both ways. Microsoft has had some very serious security bugs. Therefore, using your logic, all Microsoft software should not now or ever again be trusted. Think Code Red and others. In 1999 on a fully patched NT box you could compromise it with regular HTTP requests to IIS by just using pathnames with dot-dot-backslash and then working your way down the WINDOWS System CMD.EXE and then using it to run TFTP.EXE which was a standard part of the install. You could make the server TFTP down a bad exe from your own server, and then a second carefully crafted Http request to CMD.EXE could execute it for you. Game over.

Microsoft then fixed this by not allowing IIS to accept the dot-dot-backslash business. But you could use percent-sign-hex characters to represent the dot-dot-backslash. Microsoft then fixed that in IIS, but the filesystem would still accept the percent-hex-code characters. So you could double-escape them to get the filesystem to walk you to the CMD.EXE. Eventually they got this right and it was fixed. But there were many other holes. And who's stupid idea was it to run a server process, basically with root privileges?

I could go on. Even recently there was a major IE vulnerability that affected current and past versions.

Heartbleed was one instance of a lapse in security.

> Money saved by the government never translates into money put back in the pocket of the tax payers.

So instead of saving it, the money should just go to vendors?

The money may not go into the pocket of taxpayers, but some or all of it may go into other government expenses. So that $67 million to Microsoft could either lower the budget by $67 million, which you say never happens, and it might not, or it could be spent on other items in the budget. That seems better than wasting it.

> Proper action would be to mandate the government to use the best software for the task at hand.
> That might be open source software. It might be Microsoft software. Let the technical merits decide.

Freedom and cost are technical merits.

Closed source software is not forbidden, just not preferred. If other factors outweigh freedom and cost, then so be it. But if other factors are the same, then freedom and cost seem to be reasonable factors upon which to have a preference.

Microsoft would also never have debug symbols called NSAKEY either. Nope, never.

The Microsoft
Is Your Friend
Trust The Microsoft

Not going to happen.

The distance between Earth and Mars varies widely and Pavement is rigid and non flexible.

The assumption of hotness would instantly disappear upon discovering her true gender.

Excel makes a great database. But to avoid any possible confusion, be sure that there is only one copy of the spreadsheet file in existence.

Not a book to read, but read about Unicode and learn that Characters are != Bytes.

Bytes are 8-bit machine values.

Characters are part of human languages. The old ASCII coding where a char is a byte is just one (primitive) method of encoding characters into bytes.

The important thing is that whenever you need to convert or store characters into bytes, you must use a function to convert chars to bytes. Conversely, when you need to convert bytes into characters, you need an inverse function to do so. Think of it like if you had to convert between bizarre languages like Klingon and Canadian, you would use a pair of translation functions between the two. You could not just access values from Klingon and assume they are valid values in Canadian.

The conversion from Chars to Bytes and vice versa takes an additional parameter that indicates which Character Encoding to use. There are several to pick from. US-ASCII, UTF8, UTF16, etc. But UTF8 is a very good default because it is very much like ASCII, but will properly convert characters in any human or alien language between Unicode and bytes. The functions that convert from Bytes to Characters on your system may very well offer a function that does not need a character encoding parameter (eg, UTF8) but will figure out which encoding the bytes represent and then decode them into characters for you.

It is difficult, I know. The notion that chars == bytes is deeply embedded. But it is easy to break. And once you do, it's really easy to understand that they are different and they must always be converted using a pair of functions. So for example, a function that compresses data would accept BYTES not characters and would return BYTES. A function that encodes data into Base64 would accept BYTES as input and would output CHARACTERS limited to the US-ASCII set of characters. But the characters could be embedded into anything that accepts character parameters, such as an email, output into a web page, etc. A function that parses JSON into a data structure accepts CHARACTERS as input, not bytes. An HTML output (or input) stream is characters, not bytes. A file on disk is bytes, not characters. But the byte stream can be passed through a reader that returns a character stream in order to read through the file as characters. Etc.

After The Little Schemer, read The Reasoned Schemer.

> Making it faster just encourages the cretins that write web apps to use even more javascript. Epic fail.

Well what do you expect since they took away our <BLINK> tag?

Is it newsworthy enough that I should be interested?