Read the article here: Linux and Security: Mission Impossible?

Actually the article is spot on, and we must take care to separate our opinions on Linux from the technical fact that it is a general-purpose operating system that was not designed with security or robustness as a primary requirement. Of course Linus and all contributors work hard to make Linux more secure and more reliable, but if you've never gone through some of the specifications for safety critical (e.g. DO-178B) or robust (e.g. Common Criteria for particular PPs), you can't quite appreciate the difference between a desire for, a best effort towards and a formal proof of these requirements.

Answering the Guest's question of what it takes has been done, but it's worth another article to answer. The fact is that using Linux in an IT environment can indeed add diversity alongside BSD and even Windows, and where Windows PCs protect National secrets I believe (but I can not yet prove) that Linux is a better choice, but to Mr. Cole's point, no way am I getting on an airplane controlled by Linux. I have a hard enough time keeping an Android phone from rebooting and a Linux Web server from crashing.

Smaller, more purposefully designed RTOSs with formally applied methods are still better suited critical tasks. How long that remains true is up to how badly both the RTOS and GPOS camps want to play in each-other's spaces.

This article reads like a smear: distorting of the facts subtlety combined with emotionally laden bias.

Just exactly what high capability OS in broad use has NO CVE reports? Who would be irresponsible enough to incorporate a software product without waiting for a normal upstream maturation for issues related to security, reliability, and performance (latency, throughput, scalability)? When would an embedded product be developed without identifying the specific nature of the hardware, characterization of I/O, and constraining to required capabilities?

Even in the case of more general purpose computing application in secure contexts there are input and networking constraints; physical access constraints; and possibly even the need to operate in a Faraday cage. Furthermore, maturity of an upstream source (say RHEL5 a minimum of 18 months after release) combined with meticulous tracking of security issues; rapid incorporation or mitigation for solutions; custom high constraint security profiles (SELinux, standard security; constrained daemons; auditing; ACLs; etc.).

If my solution includes Linux in a embedded secure context I get the benefit of its extensive exposure to insane hardware configures; naive users; remote cracker hackers; complex daemon configurations; heavy loads; etc. These use cases provide focus for developing of constraints and system maturation which few solutions can match. Furthermore, I can look at tools like Coverity for doing my own security auditing.

None of the other RTOS solutions can make these claims since none of them have the level of resources and real world auditing to which Linux is exposed. OpenBSD can make some pretty good security claims due to the attention paid to auditing early in the process, but I don't see the proprietary commercial solutions matching the benefits of either one.

If someone discovers a bug in an X server I don't use (and doesn't exist on a competitive platform) when used in conjunction with a NIC driver I don't use (and also doesn't exist in the competition) along with a print driver solution that I don't use and a security configuration I don't use with a filesystem type that I don't use and kernel options that I don't use: should I consider the comparatively limited proprietary solutions to be superior or irrelevant?

The reason why General Purpose O/S are insecure isn't that complicated, Using C or low level languages alike is just fundamentally insecure (unless you are God).

If you want to see General Purpose O/S become secure, the entire paradigm which they lay upon will have to shift. I hate to admit it, but things like Java CPU would have to become mainstream, and even then, there is still the possibility of semantic flaws in code. Then after all that, you have to be able to trust 1) your O/S vendor, 2) your software vendors, 3) your hardware vendors. This is why I agree with the article.

I don't think truly secure GPOS will be possible until significant fundamental changes are made. I can see it becoming impossible for stack smashing bugs to happen, but vendor trust, how would that ever happen? Thousands of people work on systems such as Windows, *Nix, and *BSD. I'm sure a little evil code slips in every now and then.