The main reason for not making GUI part of the standard is that there are already plenty of GUI libraries for C++, and nobody on the standards committee will be able to agree on which one should be used. This is in contrast with, say, file-based IO, which is implemented in roughly the same way on all platforms.
There are plenty of features that I would say are a lot more important than a GUI framework. A standard way to convert C style FILE pointers into an iostream would be a great feature, one that several vendors already implement as extensions. Even a standard way to open a network connection and represent it as an iostream would be a good thing to have, with the heavy focus on network applications these days. Also, move allocators out of the template argument list for containers, and representing them as class members instead -- if ever there was a perfect case for preferring composition, it is this. Also, improved i18n/l10n support (C++ is better than C in this regard, but there is a lot that remains to be done).
No you need to calm down and thing about the previous designations of C and C++ standards: C++98, C99, etc. C++0x was intended to be a C++ standard released between 2000 and 2009; at this point, it looks like it is actually going to be released in 2010, and we'll all be calling it C++10.
I should probably have been more specific about that -- I was referring to Internet P2P networks, where every user's computer is a node on the network, as opposed to Usenet as it is today, where the nodes are NNTP servers that the users connect to.
I am just going to take a shot in the dark here, and guess that a typical exchange with an old friend you find on Facebook goes something like this:
Add the person to your friends list
Send message to the person, catch up with a quick exchange of 3-4 messages
Never speak to the person again
Maybe it is different for you, but that seems to be the general trend that I have noticed. People find these old friends on Facebook, but never seem to really communicate with then for very long. I would guess that if it really was so important to talk to someone, you could have called or emailed them; there are a few exceptional cases where a person really did vanish for a few years and nobody knew how to get in touch with them, but that is not as common as people seem to think it is.
As a case-in-point, a friend of mine from high school who had been unreachable for 4 years because of her drug problems contacted me on AIM a few months ago; we reconnected with no social networking site, just using the same communication system we had been using before. I still have hundreds of email addresses, phone numbers, and screen names of people I was friends with at one point or another, most of whom are still reachable through those channels, who I simply do not talk to. Social networking websites do not solve this problem.
With regard to events that you would not have known about...well, unless those events were not happening before the advent of social networking services, I strongly doubt that Facebook really made you more aware of the events or more able to find them. I still manage to find out about relevant events by email, phone calls, and word of mouth, just like people did 10, 50, and 100 years ago. Can you honestly say that you go to events that you would not have heard about except over Facebook? That you did not receive any emails, phone calls, or hear any of your friends (in real life) talking about? Maybe you can; that would make you an exceptional case, at least from what I have encountered over the past few years.
It's not that I am too cool for social networking sites; I just do not use them, and that has not been a problem for me.
Actually, just the fact that Twitter is a centralized service makes it easier to block. If I were looking for a channel that was "unblockable," the first thing I would look at is P2P networking, followed by Usenet, followed by email. Only if all else failed would I start looking at the Web or SMS.
Who the hell modded that "funny?" Nothing of value was lost -- social networking is about as important as celebrity gossip. The only actual loss to social is the lost revenue that these websites will experience, which will hardly be a blip on the radar.
It is very easy to accidentally "tweet" some information that can be used to infer your location. A blog post could be read by anyone, including the intelligence operations of another nation; a simple written letter is a bit harder for a foreign nation to get its hands on.
The overwhelming majority of the "patch" is invisible, composed of very tiny particles the size of plankton. It turns out plastic actually can degrade over time -- not biodegrade, but photodegrade. When plastic floating in the ocean is bombarded with sunlight, it breaks down into smaller and smaller particles, which is what most of this garbage patch currently consists of.
I have to wonder if the "sponge effect" of the patch -- the way it absorbs high concentrations of DDT and other chemical threats to marine life -- is necessarily bad; perhaps if the patch can be removed, scrubbed, and reinserted, the levels of these chemicals in ocean waters could be lowered.
The last thing anyone needs is a netbook that is running an OS that was intended for a full-power PC. The latest Ubuntu, Fedora, OpenSuse, etc. all ship with features and software that expect lots of memory and CPU time -- not something you are likely to have on a netbook. What should really happen is for the distro maintainers to create their own netbook spins, which cut out a lot of the features that are unneeded on a netbook and slim down the OS.
No. Linux is a kernel that implements some common Unix features (like a single root filesystem), but not all of them. When you run GNU on top of Linux, you get a Unix clone, but there are plenty of people who are not running GNU on top of Linux, or who are only using small pieces of GNU like the linker. Even though the OLPC is running Linux, and has a fairly significant portion of GNU, I would hardly say that an OLPC is running a Unix variant or clone -- it is running what is best described as Sugar/Linux + 1/2GNU.
If anything is to be called a Unix variant, it is GNU, since GNU implements (mostly) everything that is "Unix."
Someone has to have the job of managing backups and replacing faulty hardware. Those would be the first class of employees I would look for: the people who actually walk through Google's server farms. If not them, then I would next look at the people who have any sort of login privileges on those servers (e.g. a sysadmin), who could potentially open a covert channel. A moderate payment of $200000 to have one of those guys make an extra copy of some data or leak it into an account I control? Certainly worth it in a multimillion dollar case.
Even in a local case, if it is worth enough money, I would not count out a corrupt party paying off a Google IT worker. Keeping everything in-house is not a cure-all, and there have certainly been cases of corrupt employees within law firms, but just the number of IT workers at Google, even the number who might have access to the data from Google Apps, is cause for some alarm. There are just too many employees, and too little in the way of data security, to have much faith in Google's ability to guard high profile data.
One step Google should take is allowing someone to designate certain data as requiring extra protection -- they could charge a small fee for this to prevent people from doing so when there is no such requirement -- and create some sort of MLS system that only allows higher-ranking (and presumably more trustworthy) IT staff to handle that data or access the systems that store it, and encrypts the data on disc. That would go a long way toward building trust in their ability to securely store high profile data, as long as you trust Google to properly implement such a system.
It would be a massive risk of confidentiality breaches. I would rather only have to trust the people working for the law firm to prevent a data leak than have to trust them and the thousands upon thousands of IT workers at Google. Legal files could easily become high-profile overnight, especially if there are special interests who think they can them as a case-in-point for whatever agenda they have; an IT worker at Google might be paid off to leak some files, and with so many IT workers, the chances of finding one who is corrupt or desperately needs money are fairly good.
What you forget is the number of IT guys at Google, who could potentially be bought, especially if the information is very high-profile. I do not know Google's security policies, but I doubt that they are impossible for a corrupt IT worker to defeat, and if it is worth it to pay off an IT worker to leak some data, that is what will happen. A doctor or lawyer may have files that appear to not be worth that much at the time they are created, but any moment, that could change; why chance it by entrusting it to some third party? Keep it in house, and hire a security expert to design an appropriate MLS policy and auditing system; at the very least, you will be able to keep track of everyone who was ever involved with the data.
As Bruce Schnier said, "Only amateurs attack machines; professionals target people."
Well, if your voicemail was intended to be 1:55, and you have to wait an extra 15 seconds, you will be charged 3 minutes instead of 2. That does not amount to much for most people, but it does add up, and cell carriers do make a decent amount of money by forcing everyone to use extra minutes like that. I have to wonder why no price fixing investigations have ever been taken up in response to that sort of behavior.
Actually, Unix was a rewrite from scratch (of Multics but simpler), as was C (of B but more expressive), and Multics did see some use once it was completed, mostly in mainframes and systems that required a high degree of reliability. Hurd did not fail so horribly because it was a rewrite, it failed because something else came along sooner (Linux), which itself had been written from scratch. Plan 9 was intended to be a research system for exploring new concepts.
The point still remains: it was a poorly planned move to take code that was designed for environments where everyone could be trusted, and use it in an environment where that was not the case. Worse still was using a system based on combining various other systems, each of which had different security goals, for things like banking and other security-sensitive applications -- e.g. what we did with the Internet. The move to e-commerce over the Web happened too quickly and with too little planning, and was built on marketing hype from software companies and consultants.
Yes; the PASCAL style, which have the added benefit of very efficient length checking. The only downside is that strings longer than 256 chars would have to use more than one byte for storing length; all of the other advantages are maintained.
More likely, it was chosen because of the storage saving, and because there was not a risk of hackers trying to cause strings to misbehave by passing null characters in the wrong places. C and Unix were originally used in environments where people were not trying to attack each other, and security systems were in place just to prevent common user errors from destroying others' work. The real "idiot" move was taking the same hunks of code from the age where everyone could trust each other, and trying to use it in an age where some people cannot be trusted.
The problem is that there was no known material that would act as a laser diode that emits green light -- that is, the materials which emit green light as LEDs are not suitable for emitting lasers.
How do you loot academic works? What is wrong with copying a journal article and giving it to someone else? There is already a system to prevent plagiarism in academia, copyright only serves to cut the masses, who cannot afford to pay for journal subscriptions, off from the vast collection knowledge that is published each year. Worse still, not all universities are subscribed to all journals, so students at smaller, less prestigious institutions are unable to gain access to certain academic works.
Instead of fearing the widespread dissemination of knowledge over the Internet, we should be embracing it. If academic institutions are unwilling to appropriately license their publications, then they should lose copyrights entirely to stop them from holding back the real, tangible progress that the Internet could bring about. Research articles are not creative works, and they should not be published for the purpose of enriching journals or universities (it is not as if researchers are being enriched; I have been published and have not seen a penny of the fees that the journal charges).
Sadly, these days people seem to think everything is a business, and that the market should determine the price of knowledge, and would hold back society in the interest of allowing more money to be back and more markets to be opened.
Facebook's entire reason for existing is collecting advertising information and making advertisements more effective. Why would you act like it is terribly misguided to declare that by using Facebook, people are asking to be subjected to this kind of stupidity? The entire setup of Facebook is designed to extract as much information about you and how you interact with your friends as possible.
There are plenty of cases where a single system must handle multiple classification levels. For example, a manager at the CIA may need to handle TOP SECRET information about a spy in a hostile nation, and also UNCLASSIFIED information about some new equipment that is being procured in his department. It would be economical to have a single desktop for that manager to do his work, but since that range of information crosses all four classification levels, that is not allowed; it would be highly economical for all the employees in the agency to be given only one desktop, especially at the end of an upgrade cycle (in the NSA, it is typical for analysts to have two computers on their desks, one connected to the Internet and used for unclassified data, the other connected to a secure internal network and used for SECRET and TOP SECRET data). There is also the issue of servers; the government uses NAS, databases, and application servers just like everyone else, but needs to spend more because of a need to keep different classification levels on physically separated systems.
Encryption is important in these systems, but it is not the whole story. SECRET data should be encrypted, but in order to work with it, it must be decrypted at some point and displayed to the user. A careless (or malicious) user might copy a section of that SECRET data into an UNCLASSIFIED document, thus breaking the entire security system if the different classification levels are not enforced by physically separate systems. There is also a frequent need for UNCLASSIFIED data to be included as part of a classified report -- at some point, that data must be moved between classification levels. In multilevel security, one would usually use a "data diode" for that process -- a specially designed system (hardware or software) that is only capable of copying data up the classification chain.
The question of security in the government is more than just a question of keeping hackers out. A bigger question is keeping data under control, and making sure that sensitive information remains classified. Even if an operating system is polished to the point where it is impossible to gain unauthorized access, it could still be completely unsuitable for government work if it lacks mandatory ACLs (which is what SELinux provides) and various other necessary features for data oriented security. The reason no system has ever been approved to process all classification levels is primarily a concern about covert channels -- they are unavoidable, and there tends to be higher bandwidth available on a single computer system than on physically separated systems. In fact, it is entirely plausible for someone looking to steal classified data to try and get a patch in that increases the bandwidth of a covert channel; even a 1% increase could be highly valuable for a spy.
Systems rated at EAL4 and higher are scrutinized for more than just predictable behavior; they are required to have various mechanisms designed to protect data from slipping into lower classification levels. Windows 2000 was certified at EAL4 for that very reason: it includes a security policy mechanism that allows administrators to create MLS policies; likewise, RHEL5 was also certified at EAL4, because of its inclusion of SELinux (the reason that other distros which include SELinux do not have that certification is probably because they never submitted their system for such certification; there are also other criteria concerning the storage of encryption keys and the ability to instantly revoke a specific user's access to the system). The criteria and motivation for the criteria can be found on the NSA/NIST websites, if you feel like reading a few hundred pages of technical material (you can also check out Security Engineering by Ross Andersen, which has a chapter devoted to MLS).
The last time I checked, the NSA still had not approved any single system to handle data at all four levels of classification, and they required that a single physical system could only handle two "consecutive" classification levels at a time (that is, one level directly below the other, so that TOP SECRET and SECRET could be processed on a single system, but TOP SECRET and CLASSIFIED could not). I would be very surprised if that has changed, since protecting against a covert channel puts requirements on the hardware, regardless of what software is running on the system.
That is a lot of code to try to audit, especially when a backdoor may be spread across many different modules. I saw an entry to the underhanded C coding contest that hid an information leak across 5 different sections of the program; the leak happened 0.5% of the time the code was run (on average), but it involved leaking the secret key for a block cipher. It could been even more well hidden, had there been more code available, as there would outside the constraints of a contest.
"Security professionals" cannot necessarily spot a well engineered, well hidden backdoor in millions of lines of code, as there might be in the Linux kernel. Given the widespread use of Linux in banks and governments, it would not surprise me if different groups of people have been busy trying to hide some sort of vulnerability.
This is not to say that commercial software is not vulnerable. It is just as easy to bribe a programmer at some major proprietary software house to introduce code as it is to sneak code in through patches in an open source project. The real issue here is introducing third party code, that you have not overseen from its inception, into a high-security environment and trusting it. This is the reason why the NSA has never approved any computer system for handling all classification levels -- it is not economical to develop a custom system, but it is not secure to trust a third party system, so the compromise is keeping top secret data on a physically separate computer from unclassified data.
I am not trying to imply that some hacker is going to be able to take over the military's computer systems -- that only happens in Hollywood. More likely, if such a vulnerability were to be introduced, it would involve weakening a random number generator, or an encryption implementation, or perhaps even making it easier to create a covert channel without being caught. Even just slightly weakening the security could have far reaching consequences for an espionage campaign -- and slightly weakening the security would also make detection that much harder.
It is funny that people assume that open source means more secure. It means more potential for security, since you can undertake an enormous, in-depth code review, but given the amount of code in some projects (the Linux kernel, Apache, etc.), that is not something that is likely to happen. It is not terribly difficult to hide a defect in some code -- a cool example of this is the Underhanded C Coding Contest, where the goal is to introduce a vulnerability in such a way that reading through the source does not give an obvious indication of what happened.
Now, if the military is controlling the code that is committed to certain projects, that is another story. Then they can see enhanced security from day 1, by ensuring that every patch is thoroughly reviewed -- a much smaller task than trying to re-verify years of review from some other project.
The main reason for not making GUI part of the standard is that there are already plenty of GUI libraries for C++, and nobody on the standards committee will be able to agree on which one should be used. This is in contrast with, say, file-based IO, which is implemented in roughly the same way on all platforms.
There are plenty of features that I would say are a lot more important than a GUI framework. A standard way to convert C style FILE pointers into an iostream would be a great feature, one that several vendors already implement as extensions. Even a standard way to open a network connection and represent it as an iostream would be a good thing to have, with the heavy focus on network applications these days. Also, move allocators out of the template argument list for containers, and representing them as class members instead -- if ever there was a perfect case for preferring composition, it is this. Also, improved i18n/l10n support (C++ is better than C in this regard, but there is a lot that remains to be done).
No you need to calm down and thing about the previous designations of C and C++ standards: C++98, C99, etc. C++0x was intended to be a C++ standard released between 2000 and 2009; at this point, it looks like it is actually going to be released in 2010, and we'll all be calling it C++10.
I should probably have been more specific about that -- I was referring to Internet P2P networks, where every user's computer is a node on the network, as opposed to Usenet as it is today, where the nodes are NNTP servers that the users connect to.
Maybe it is different for you, but that seems to be the general trend that I have noticed. People find these old friends on Facebook, but never seem to really communicate with then for very long. I would guess that if it really was so important to talk to someone, you could have called or emailed them; there are a few exceptional cases where a person really did vanish for a few years and nobody knew how to get in touch with them, but that is not as common as people seem to think it is.
As a case-in-point, a friend of mine from high school who had been unreachable for 4 years because of her drug problems contacted me on AIM a few months ago; we reconnected with no social networking site, just using the same communication system we had been using before. I still have hundreds of email addresses, phone numbers, and screen names of people I was friends with at one point or another, most of whom are still reachable through those channels, who I simply do not talk to. Social networking websites do not solve this problem.
With regard to events that you would not have known about...well, unless those events were not happening before the advent of social networking services, I strongly doubt that Facebook really made you more aware of the events or more able to find them. I still manage to find out about relevant events by email, phone calls, and word of mouth, just like people did 10, 50, and 100 years ago. Can you honestly say that you go to events that you would not have heard about except over Facebook? That you did not receive any emails, phone calls, or hear any of your friends (in real life) talking about? Maybe you can; that would make you an exceptional case, at least from what I have encountered over the past few years.
It's not that I am too cool for social networking sites; I just do not use them, and that has not been a problem for me.
Actually, just the fact that Twitter is a centralized service makes it easier to block. If I were looking for a channel that was "unblockable," the first thing I would look at is P2P networking, followed by Usenet, followed by email. Only if all else failed would I start looking at the Web or SMS.
Who the hell modded that "funny?" Nothing of value was lost -- social networking is about as important as celebrity gossip. The only actual loss to social is the lost revenue that these websites will experience, which will hardly be a blip on the radar.
It is very easy to accidentally "tweet" some information that can be used to infer your location. A blog post could be read by anyone, including the intelligence operations of another nation; a simple written letter is a bit harder for a foreign nation to get its hands on.
The overwhelming majority of the "patch" is invisible, composed of very tiny particles the size of plankton. It turns out plastic actually can degrade over time -- not biodegrade, but photodegrade. When plastic floating in the ocean is bombarded with sunlight, it breaks down into smaller and smaller particles, which is what most of this garbage patch currently consists of.
I have to wonder if the "sponge effect" of the patch -- the way it absorbs high concentrations of DDT and other chemical threats to marine life -- is necessarily bad; perhaps if the patch can be removed, scrubbed, and reinserted, the levels of these chemicals in ocean waters could be lowered.
The last thing anyone needs is a netbook that is running an OS that was intended for a full-power PC. The latest Ubuntu, Fedora, OpenSuse, etc. all ship with features and software that expect lots of memory and CPU time -- not something you are likely to have on a netbook. What should really happen is for the distro maintainers to create their own netbook spins, which cut out a lot of the features that are unneeded on a netbook and slim down the OS.
And Minix is Unix clone, which would basically make Linux (assuming GNU is included) a Unix clone as well.
No. Linux is a kernel that implements some common Unix features (like a single root filesystem), but not all of them. When you run GNU on top of Linux, you get a Unix clone, but there are plenty of people who are not running GNU on top of Linux, or who are only using small pieces of GNU like the linker. Even though the OLPC is running Linux, and has a fairly significant portion of GNU, I would hardly say that an OLPC is running a Unix variant or clone -- it is running what is best described as Sugar/Linux + 1/2GNU.
If anything is to be called a Unix variant, it is GNU, since GNU implements (mostly) everything that is "Unix."
Someone has to have the job of managing backups and replacing faulty hardware. Those would be the first class of employees I would look for: the people who actually walk through Google's server farms. If not them, then I would next look at the people who have any sort of login privileges on those servers (e.g. a sysadmin), who could potentially open a covert channel. A moderate payment of $200000 to have one of those guys make an extra copy of some data or leak it into an account I control? Certainly worth it in a multimillion dollar case.
Even in a local case, if it is worth enough money, I would not count out a corrupt party paying off a Google IT worker. Keeping everything in-house is not a cure-all, and there have certainly been cases of corrupt employees within law firms, but just the number of IT workers at Google, even the number who might have access to the data from Google Apps, is cause for some alarm. There are just too many employees, and too little in the way of data security, to have much faith in Google's ability to guard high profile data.
One step Google should take is allowing someone to designate certain data as requiring extra protection -- they could charge a small fee for this to prevent people from doing so when there is no such requirement -- and create some sort of MLS system that only allows higher-ranking (and presumably more trustworthy) IT staff to handle that data or access the systems that store it, and encrypts the data on disc. That would go a long way toward building trust in their ability to securely store high profile data, as long as you trust Google to properly implement such a system.
It would be a massive risk of confidentiality breaches. I would rather only have to trust the people working for the law firm to prevent a data leak than have to trust them and the thousands upon thousands of IT workers at Google. Legal files could easily become high-profile overnight, especially if there are special interests who think they can them as a case-in-point for whatever agenda they have; an IT worker at Google might be paid off to leak some files, and with so many IT workers, the chances of finding one who is corrupt or desperately needs money are fairly good.
What you forget is the number of IT guys at Google, who could potentially be bought, especially if the information is very high-profile. I do not know Google's security policies, but I doubt that they are impossible for a corrupt IT worker to defeat, and if it is worth it to pay off an IT worker to leak some data, that is what will happen. A doctor or lawyer may have files that appear to not be worth that much at the time they are created, but any moment, that could change; why chance it by entrusting it to some third party? Keep it in house, and hire a security expert to design an appropriate MLS policy and auditing system; at the very least, you will be able to keep track of everyone who was ever involved with the data.
As Bruce Schnier said, "Only amateurs attack machines; professionals target people."
What if a bug is discovered in the boot code?
Well, if your voicemail was intended to be 1:55, and you have to wait an extra 15 seconds, you will be charged 3 minutes instead of 2. That does not amount to much for most people, but it does add up, and cell carriers do make a decent amount of money by forcing everyone to use extra minutes like that. I have to wonder why no price fixing investigations have ever been taken up in response to that sort of behavior.
Actually, Unix was a rewrite from scratch (of Multics but simpler), as was C (of B but more expressive), and Multics did see some use once it was completed, mostly in mainframes and systems that required a high degree of reliability. Hurd did not fail so horribly because it was a rewrite, it failed because something else came along sooner (Linux), which itself had been written from scratch. Plan 9 was intended to be a research system for exploring new concepts.
The point still remains: it was a poorly planned move to take code that was designed for environments where everyone could be trusted, and use it in an environment where that was not the case. Worse still was using a system based on combining various other systems, each of which had different security goals, for things like banking and other security-sensitive applications -- e.g. what we did with the Internet. The move to e-commerce over the Web happened too quickly and with too little planning, and was built on marketing hype from software companies and consultants.
Yes; the PASCAL style, which have the added benefit of very efficient length checking. The only downside is that strings longer than 256 chars would have to use more than one byte for storing length; all of the other advantages are maintained.
More likely, it was chosen because of the storage saving, and because there was not a risk of hackers trying to cause strings to misbehave by passing null characters in the wrong places. C and Unix were originally used in environments where people were not trying to attack each other, and security systems were in place just to prevent common user errors from destroying others' work. The real "idiot" move was taking the same hunks of code from the age where everyone could trust each other, and trying to use it in an age where some people cannot be trusted.
The problem is that there was no known material that would act as a laser diode that emits green light -- that is, the materials which emit green light as LEDs are not suitable for emitting lasers.
How do you loot academic works? What is wrong with copying a journal article and giving it to someone else? There is already a system to prevent plagiarism in academia, copyright only serves to cut the masses, who cannot afford to pay for journal subscriptions, off from the vast collection knowledge that is published each year. Worse still, not all universities are subscribed to all journals, so students at smaller, less prestigious institutions are unable to gain access to certain academic works.
Instead of fearing the widespread dissemination of knowledge over the Internet, we should be embracing it. If academic institutions are unwilling to appropriately license their publications, then they should lose copyrights entirely to stop them from holding back the real, tangible progress that the Internet could bring about. Research articles are not creative works, and they should not be published for the purpose of enriching journals or universities (it is not as if researchers are being enriched; I have been published and have not seen a penny of the fees that the journal charges).
Sadly, these days people seem to think everything is a business, and that the market should determine the price of knowledge, and would hold back society in the interest of allowing more money to be back and more markets to be opened.
Facebook's entire reason for existing is collecting advertising information and making advertisements more effective. Why would you act like it is terribly misguided to declare that by using Facebook, people are asking to be subjected to this kind of stupidity? The entire setup of Facebook is designed to extract as much information about you and how you interact with your friends as possible.
There are plenty of cases where a single system must handle multiple classification levels. For example, a manager at the CIA may need to handle TOP SECRET information about a spy in a hostile nation, and also UNCLASSIFIED information about some new equipment that is being procured in his department. It would be economical to have a single desktop for that manager to do his work, but since that range of information crosses all four classification levels, that is not allowed; it would be highly economical for all the employees in the agency to be given only one desktop, especially at the end of an upgrade cycle (in the NSA, it is typical for analysts to have two computers on their desks, one connected to the Internet and used for unclassified data, the other connected to a secure internal network and used for SECRET and TOP SECRET data). There is also the issue of servers; the government uses NAS, databases, and application servers just like everyone else, but needs to spend more because of a need to keep different classification levels on physically separated systems.
Encryption is important in these systems, but it is not the whole story. SECRET data should be encrypted, but in order to work with it, it must be decrypted at some point and displayed to the user. A careless (or malicious) user might copy a section of that SECRET data into an UNCLASSIFIED document, thus breaking the entire security system if the different classification levels are not enforced by physically separate systems. There is also a frequent need for UNCLASSIFIED data to be included as part of a classified report -- at some point, that data must be moved between classification levels. In multilevel security, one would usually use a "data diode" for that process -- a specially designed system (hardware or software) that is only capable of copying data up the classification chain.
The question of security in the government is more than just a question of keeping hackers out. A bigger question is keeping data under control, and making sure that sensitive information remains classified. Even if an operating system is polished to the point where it is impossible to gain unauthorized access, it could still be completely unsuitable for government work if it lacks mandatory ACLs (which is what SELinux provides) and various other necessary features for data oriented security. The reason no system has ever been approved to process all classification levels is primarily a concern about covert channels -- they are unavoidable, and there tends to be higher bandwidth available on a single computer system than on physically separated systems. In fact, it is entirely plausible for someone looking to steal classified data to try and get a patch in that increases the bandwidth of a covert channel; even a 1% increase could be highly valuable for a spy.
Systems rated at EAL4 and higher are scrutinized for more than just predictable behavior; they are required to have various mechanisms designed to protect data from slipping into lower classification levels. Windows 2000 was certified at EAL4 for that very reason: it includes a security policy mechanism that allows administrators to create MLS policies; likewise, RHEL5 was also certified at EAL4, because of its inclusion of SELinux (the reason that other distros which include SELinux do not have that certification is probably because they never submitted their system for such certification; there are also other criteria concerning the storage of encryption keys and the ability to instantly revoke a specific user's access to the system). The criteria and motivation for the criteria can be found on the NSA/NIST websites, if you feel like reading a few hundred pages of technical material (you can also check out Security Engineering by Ross Andersen, which has a chapter devoted to MLS).
The last time I checked, the NSA still had not approved any single system to handle data at all four levels of classification, and they required that a single physical system could only handle two "consecutive" classification levels at a time (that is, one level directly below the other, so that TOP SECRET and SECRET could be processed on a single system, but TOP SECRET and CLASSIFIED could not). I would be very surprised if that has changed, since protecting against a covert channel puts requirements on the hardware, regardless of what software is running on the system.
That is a lot of code to try to audit, especially when a backdoor may be spread across many different modules. I saw an entry to the underhanded C coding contest that hid an information leak across 5 different sections of the program; the leak happened 0.5% of the time the code was run (on average), but it involved leaking the secret key for a block cipher. It could been even more well hidden, had there been more code available, as there would outside the constraints of a contest.
"Security professionals" cannot necessarily spot a well engineered, well hidden backdoor in millions of lines of code, as there might be in the Linux kernel. Given the widespread use of Linux in banks and governments, it would not surprise me if different groups of people have been busy trying to hide some sort of vulnerability.
This is not to say that commercial software is not vulnerable. It is just as easy to bribe a programmer at some major proprietary software house to introduce code as it is to sneak code in through patches in an open source project. The real issue here is introducing third party code, that you have not overseen from its inception, into a high-security environment and trusting it. This is the reason why the NSA has never approved any computer system for handling all classification levels -- it is not economical to develop a custom system, but it is not secure to trust a third party system, so the compromise is keeping top secret data on a physically separate computer from unclassified data.
I am not trying to imply that some hacker is going to be able to take over the military's computer systems -- that only happens in Hollywood. More likely, if such a vulnerability were to be introduced, it would involve weakening a random number generator, or an encryption implementation, or perhaps even making it easier to create a covert channel without being caught. Even just slightly weakening the security could have far reaching consequences for an espionage campaign -- and slightly weakening the security would also make detection that much harder.
It is funny that people assume that open source means more secure. It means more potential for security, since you can undertake an enormous, in-depth code review, but given the amount of code in some projects (the Linux kernel, Apache, etc.), that is not something that is likely to happen. It is not terribly difficult to hide a defect in some code -- a cool example of this is the Underhanded C Coding Contest, where the goal is to introduce a vulnerability in such a way that reading through the source does not give an obvious indication of what happened.
Now, if the military is controlling the code that is committed to certain projects, that is another story. Then they can see enhanced security from day 1, by ensuring that every patch is thoroughly reviewed -- a much smaller task than trying to re-verify years of review from some other project.