Many People seem to have the same misconception you've perpetuated here, that a reactor can be SCRAM'd just by dropping the rods into it. The fact of the matter is that a reactor has a MASSIVE latent heat of reaction (this doesn't tend to happen as much in military reactors because they are near weapons grade and thus have less radioactive by-products that need to decay). This heat MUST be dissipated or the core will melt. One way to get around this issue is to use a natural circulation reactor. Or to maintain an extra supply of coolent on a gravity feed.

Sometimes I wish we could mod up beyond 5

The fact of the matter as the parent post makes is that insecure password storage is a far larger issue, many many sites just store the passwords plaintext in a DB. If you're lucky they are bothering to use SHA1 on them first (without a salt). The website owner feeling smart adds salts but is still using SHA1 and a single round of hashing (cracking complexity... trivial). A real smart one decides he's going to use multi-round hashing, and perhaps even a stronger hash or better algorithm designed to be slower HMACSHA512 etc. If you're really really lucky they'll be a professional and use a third party module for authentication that implements PBKDF2/PKCS#5 using a really slow hash.

But lets be honest folks... security is always priority number 2, just like it's Safety Second in a dangerous workplace

Actually no it's not... Linux has that already and it works just fine, anyone who has gone through the pain of getting flash player to work before the x64 port can tell you. This is actually more similar (albeit with more restrictions) to setting the /LARGEADDRESSAWARE:NO option on the linker in Visual C++. An option you'll notice that comes with a significant warning about interoperability. Microsoft solved this problem by making pointer handling the developer's job, this meant that they could continue to use x86-64 libraries without an issue but all malloc operations would return addresses that are safe to sign extend.

The benefit on windows is that you:

1. Use less ram on an x64 bit OS than a corresponding x86 application would, this is because you won't have x64 threads for each x86 thread you have going, and won't have to load the thunking DLLs
2. In theory could interop with x86 code since your pointers are safe, however this is not supported

As a developer that is precisely the problem, the only consistent API in Linux is POSIX, and compared to say... WIN32 Core (minwin) that's fine. But as MinWin is essentially just Linux with Busy-box running on it, you have POSIX and nothing else. But as a developer to justify developing for Linux I need a set of rich distribution independent API's that are universal across the entirety of GNU/Linux, and not specific to a particular build of a particular distribution. Without that I'm left chasing distro install numbers to justify what I'm going to develop for or I have to trust that some downstream developer isn't going to screw up my code (See the Debian OpenSSL incident).

So what am I saying? I'm saying that very choice and customization that makes Linux the OS that so many love and cherish is what is preventing desktop development outside the tightly coupled applications that come with the various shells. Fundamentally I don't think that is an issue that can be addressed. Perhaps each shell could agree to make a subsystem to allow their apps to run on the other... (much like QuickTime allows Itunes on Windows) but that would require a lot of development for little payoff so I don't see it happening.

It's not treason since the Indian government is not an enemy of the United States. Furthermore to be charged with treason there has to be two eye witnesses, "No Person shall be convicted of Treason unless on the testimony of two Witnesses to the same overt act, or on confession in open court."

More likely someone will get charged under the Espionage Act, which has no such requirements... assuming of course that the US Government was not complicit in this.

I honestly think this is a special case, the Indian Government was essentially threatening to ban them from that market. To the fan bois out there that are touting FOSS as the solution... you might want to go read some of the security blogs before you go and do that. You'll quickly realize that it doesn't matter if the OS manufacturers make backdoors or not. ALL OSs have major security holes, Windows has a codebase stretching back nearly 30 years, as does Linux, I can guarantee that both have bugs that can lead to privilege escalation, some of which can be executed with remarkable reliability, e.g. Stuxnet.

My primary concern here is that this violates the Foreign Corrupt Practices Act, as giving the Indian Government the backdoor constitutes a bribe.

You however are making the assumption that everybody in Microsoft talks to each other. A most incorrect assumption. The reality is most likely that WinDiv (The division responsible for the OS) made the assumption that fonts would not be loaded from insecure sources, e.g. Word documents. The Office division however faced the problem of what do you do when some user uses a font that is not on another users system? So they made the decision to allow the embedding of fonts into the file format, along with a bunch of other really bad decisions in hindsight (remember the Melissa virus?) that would have been caught if they had had the same security reviews as WinDiv did. To compound the problem, Office used unpublished and most likely unhardened APIs (it probably still does in parts) that allowed it the capabilities to do things like on the fly font loading something that wasn't exposed to the rest of us until Windows 2000 (NT 5.0). My point being that at the time it WAS a safe decision as far as WinDiv was concerned. Should they have been a little more careful with those unpublished APIs... yes they should have, it would have prevented a lot of anti-trust issues, but they weren't. So here we are with yet another security bug.

Firefox is using:

Image (executables): 95,084K

Mapped File: 56,892K

Sharable Pages: 133,100k

Heap: 25,100K

Stack: 46,080K

Private Data (explicit mallocs): 205,280K

Page Table: 1,372K

Unusable (leftover area of explicitly allocated pages that were LESS than 64K): 9,440K

Only 10M unusable isn't bad on windows... (start inevitable trolling here) as the memory manager only allocates pages in increments on 64k