The single most important thing isn't about software engineering specifically, it's the ability to analyze a problem, break it down into it's component parts and work out a structure for your solution that solves the problem well. Just like the most important part of building a house isn't anything to do with actually building it, it's deciding what kind of house you're going to build, what rooms it's going to need and how they're going to be arranged. You need a very different house if you want it to support a family with 2 or 3 kids vs. just a single person or a couple without children. If you don't get that right, all the technical chops in the world later on won't help your having been hamstrung by a bad overall design. Lack of that ability has been the root cause behind something like 75% of the "software engineering" failures I've had to deal with.
What's more telling isn't the instances of bad cops. It's the fact that those bad cops aren't subject to any significant disciplinary action. There will always be bad cops, but when the good cops accept and tolerate them and do nothing to get rid of them it's indicative of a fundamental ethical problem. That's why I don't trust any part of law enforcement to act ethically and honestly.
In rebuttal to item five, I have to point out: Mike Nifong and the Durham Police Department in their handling of the Duke lacrosse team case. I also have to point out the behavior, documented on video, of the police in the numerous cases where they've been filmed physically beating suspects long after those suspects were physically incapable of resisting (or where the suspect wasn't resisting in the first place), threatening people and arresting them for documenting police activity while clearly not interfering with it, tazing someone who was bedridden and physically incapable of being any threat to the officers... the list of unreasonable activities just seems to grow. So when someone asks whether the police could be that corrupt, incompetent and/or malicious, I have to say the evidence doesn't support an answer in the negative.
I have one basic requirement before I'll use a logon credential system: I must be able to change the credential in the event it's compromised. If I can't recover from a compromise by changing the credential so it's no longer available to whoever compromised it, I won't use it. I never ever want to be in a position where my login has been compromised, I have to continue using it and I can't make it so the bad guy can't use it anymore.
The people pushing biometrics are handwaving away the difference between identification and authentication. Authentication usually requires identification as a first step, but it then requires a second step: proving that you truly are the person you've been identified as. Think of it like a safe-deposit box: the bank checks your driver's license to see who you are and from that which deposit box is yours. That's identification. But they won't open the box for you. You have to authenticate by making use of the key you were issued to open the box, which someone who was merely impersonating you wouldn't have. Western Union would be an example of a system of authentication without identification. When money's sent the sender can provide a question and answer instead of requiring identification. Anyone who can provide the correct answer to the question is authorized to pick up the money, identification not (normally) needed. That's a lifesaver for people who've eg. been robbed and whose ID was taken along with the wallet.
Or Tesla spins it as "We're incorporating a built-in fire-suppression system, the same as all race cars have had for the last 20 years or so. Why our competitors haven't done so by now,... you'll have to ask them, they're the ones who've been fielding the racing teams using this technology.".
Oh BTW, yes that means that public-key certificates issued by a certificate authority are also vulnerable. Not as vulnerable, but if you're depending on a CA to vouch for the validity of the certificate then the government can demand (and have demanded) that the CA turn over their root signing keys. At that point the government can issue themselves a certificate in your name, signing it with the CA's key, and their certificate will be accepted as valid by everyone allowing them to impersonate you. That's not quite as bad a compromise as them being able to eavesdrop on all your communications, but it's bad enough to be a problem.
It's not limited to just SSL. Any company that holds a copy of your encryption/decryption keys (a public certificate is OK, the matching private key that goes with it is the problem) can be ordered to turn them over. The only safe system is where the keys that secure the system never leave your possession.
For e-mail that means using S/MIME or OpenPGP with a self-signed certificate and a private key you generate yourself. For encrypted documents, the same. The e-mail and documents need to be encrypted on your end before they leave your computer. Be aware that if you're encrypting messages to someone else the security will be controlled by their handling of their keys. You're encrypting using their public key, there's no security implications from disclosure there. However, if the recipient's using a service where the provider has a copy of their private key (used to decrypt messages to them) then messages can potentially be eavesdropped on by outsiders who've compromised the provider and gotten the key. Be aware of this aspect and make sure you know how recipients are handling their own security.
Yes, the above means any and all web-based or hosted services are automatically vulnerable no matter how they're designed. The only secure systems are ones where you, or software running on your computer and that you control, does the encryption and decryption and the private keys are never disclosed to any other party.
Some of it could be due to attitudes changing after retirement. Before retirement the idea of having to put back savings for retirement and be careful not to blow your money because you're going to need it later colors your thinking. After retirement you don't need to save up for retirement, and you become very aware that you do not have an entire lifetime ahead of you to worry about anymore. That changes your evaluation of risk.
Because if something major does happen, an MSA won't cover it. I had a bout of pneumonia. That cost me 5 weeks in the critical-care unit in an induced coma, a month of inpatient rehab, another 6 months of outpatient physical therapy, plus a year of IV therapy to fix the immune-related problem triggered by something (they're still not sure what) during my stay in the CCU (which still hasn't completely resolved the problems, but they're down to the point where the pain can be managed by medication). The hospital bill alone came to $350K, the IV therapy came to in excess of a hundred grand, plus another fifty grand or so for the physical therapy. All told over half a mil, and that's at the rates the insurance companies pay. Without the insurance contracts, the rates would've been at least twice that. Now, how many people do you know of who can afford to put half a million dollars in a savings account?
And you seem to be under the impression that insurance acts like a savings account. It isn't. Insurance coverage is supposed to be a risk pool. You don't pay into it to withdraw what you paid in. You pay in to insure that if that massive bill hits that it's paid for. That's why insurance rates were never traditionally calculated based on individual risk. They were calculated by taking the total risk for the whole pool and dividing it by the number of people in the pool. So if you had a thousand people and one of them would get hit with that half-million-dollar bill every year, you charged everybody a $500/year premium. Each year the pool gets enough in premiums to cover the pay-outs, and each person gets a payment they can afford and the security of not having to gamble on the outcome.
No, but the person you're sending the e-mail to has. When you send physical mail to someone, you don't know if they've got a secretary opening and reading all their mail for them. They could even have an outside company doing it (what, you think Hollywood stars and politicians read and answer their own fan or constituent mail?). And the law has absolutely no problem with this, nor with the idea that if this will be a problem for you as the sender then it's your responsibility to sort this out with the recipient before sending your mail.
I think it says something about your viewpoint, and that of management in general, that you equate laying people off with backstabbing. Most people I know of outside of management don't. Management... seems not to get that it's the lying and misleading that anger employees most, not the layoffs.
As an IT professional, what angers me is mostly management lying and claiming everything's hunky-dory and then blindsiding me with layoffs. When they do it even once, it convinces me that I can't trust them ever again. That's not a problem if I'm one of the ones being shown the door, but companies rarely lay off everybody in a single pass and this creates if anything even worse trust issues with those who're still working. At the very least this behavior will turn me from someone who considers it only professional to give as much notice as possible if I decide to go elsewhere into someone who a) doesn't feel obligated to give any more notice than legally required since the company's shown that's what they'll do and b) is more likely to start looking before he gets caught in the next round of layoffs. Whereas if the heads-up is given, I'm less likely to worry and be looking to jump ship because I know I'll have advance warning next round too.
That no-advance-warning is only a good idea if you can't trust your IT people in the first place. And if you can't trust them, why are you trusting them to run your IT department?
That's because, if you look at your Google+ settings, it has a feature that lets you share your location with your circles and contacts. Whether your location is shared or not, and with who, is under your control, but Maps needs to read your contact list to know who's in it so it knows who's eligible to see your location since it's the app on the phone that handles monitoring and updating your location.
This can be both intrusive and useful. If I were making a cross-country trip I'd likely enable location sharing with a couple of friends. That way if anything happened they'd at least know where to start looking when I didn't check in.
The problem is that mostly this stuff is given voluntarily. It's just not given by you. You voluntarily connect with person A, for good reasons. And then person A for reasons that seem good to them (maybe because in their work the connections they have has an impact on their income) makes it public that they're connected to you. Then for good reasons they connect to person B. And person B is careless, or doesn't think, and they let a site siphon up their connections. Presto, that site now knows about your connection to person A.
The basic problem is that "voluntary" is transitive and "private" is not, but we treat it as if it's the other way around.
I know LinkedIn isn't doing it to me, because the IMAP/SMTP server I use for e-mail doesn't have my contacts on it. IMAP and SMTP don't even have the concept of contacts or an address book. End of problem.
Likely the LinkedIn users in question use a webmail service like GMail and gave LinkedIn access to their e-mail account to import their contacts. You get asked for this when setting up your LinkedIn account, and if you're using a browser that's logged into Google the LinkedIn site may try to get access directly and it's easy to give it access by mistake unless you're a professional paranoid like me whose default answer to every unexpected prompt is to close the browser down (I don't trust Close links in an HTML page to just close the page). Or someone the person corresponds with may have given LinkedIn access to their address book and found connections that way. Or LinkedIn may have scanned the user's public profile on Google+, gotten their publicly-listed circles and used the public profiles for those people to gain contact information. There's a lot of ways to gain access to this information that don't involve hacking an e-mail account. More likely the plaintiffs here have just been faced with incontrovertible proof that it really is as easy to find out this kind of stuff about them as their paranoid friends have been telling them and are trying to find any other explanation that lets them retain their warm fuzzy false view of the world.
That's their latest attempt to dig themselves out of the hole. But it's the same mistake they made at the beginning, only reversed: instead of making a phone that works like a desktop, they're trying to make desktops work like phones. At this point they can't fail to get the idea that people don't use phones the same way they use desktops, so I can't write this one off to just them being clueless.
Microsoft simply failed to recognize that people use phones differently than they use desktop computers. MS started by trying to make a desktop Windows run on a smartphone. That cratered because a UI that works on a desktop is awkward and hard to use on the small screen of a phone. Lack of touchscreen support didn't help one bit. And even after they got that concept, they've continued to try to force people into the Windows ecosystem rather than attempting to fit their phones into the existing ecosystems. People don't care much about Office on their phones beyond e-mail and for personal use Exchange integration is almost irrelevant because most people's e-mail accounts aren't Exchange, they're generic POP3/IMAP4 accounts or GMail. Now Microsoft is left with a minority position and an unwillingness to play in anyone else's sandbox, not to mention having actively torqued off the owner of one of the two biggest sandboxes out there (Google). Is it any wonder they're having a hard time gaining traction?
Point that needs to be considered: we don't explore just for the joy of exploring. Humans have always explored because we think we'll find something useful/exploitable out there we can bring back and get rich from. Most of the Americas got explored because Europeans wanted gold, lumber and such. Robots are all well and good, but they have a hard time finding anything they aren't designed to search for and most of the time we don't know exactly what we're looking for that we might want. Humans are the best tools we have for figuring out what unknown junk might be useful/profitable. And once we find something, humans are the best way of actually exploiting it and bringing it back home in a useful form. Which all means that sooner or later we're going to have to send people out there and keep them there for extended periods.
It's probably that the defendants, not being Cisco, will lack the detailed knowledge of how Cisco's products work internally to show that the products don't infringe the patents, and won't have the in-depth knowledge of the fields involved to uncover prior art or successfully demonstrate obviousness. If I were the defendants, I'd be moving to have the suits dismissed on the grounds that Cisco made the equipment and had a license for the patents and the defendants are merely using Cisco's equipment without adding anything to it, or alternatively if plaintiff claims Cisco didn't have a license to have Cisco joined as a co-defendant since plaintiff is accusing them of infringing on the patents.
So now instead of cutting off your finger so they can open the fingerprint locks, which involves physical assault, the thieves can just slap an EEG on your head for a few minutes, splice into the wiring and play the recording back after bypassing the sensors. Or they could take advantage of the ability to record more than one person's brainwaves to make themselves an authorized driver (cars will have to allow this because more than one person drives a given car). Or they could use the bypass built-in for letting someone borrow your car (which again will have to be allowed because people do let friends borrow their car for a quick trip to the store) to "borrow" your car. This won't slow the thieves down much, all it'll do is give car owners a false sense of security and make them more careless.
Myself, I favor a "make the car undrivable" approach, eg. if the ignition is triggered without a door having been opened with the key or the keyless remote, the ECU disables the fuel pump. The car's still vulnerable to thieves who just load it onto a flatbed tow truck, but nothing can really stop that.
No. RDRAND isn't software, it's an instruction on Intel CPUs to access the built-in hardware random number generator. The code in question is code to make use of RDRAND in cases where random numbers are needed regardless of whether there's sufficient entropy to generate good-quality random numbers. Using it doesn't degrade security because what it replaces would simply return poor-quality (ie. non-random) results if there wasn't sufficient entropy accumulated (which is the case during system startup when there just hasn't been enough time to accumulate significant entropy).
The random-number source here is separate from the regular/dev/random source used by most software, which guarantees good results even if it has to block and force your call to wait until enough entropy has been accumulated.
Why would you need to look at the code to find that? The compiler will flag that one (assignment within an 'if' statement test is extremely questionable, it's more likely a typo than correct code) and the code will be rejected as "Fails to compile cleanly.". Adding the pragma or compile option to suppress that warning likewise will get the code rejected because you shouldn't need to suppress that warning to get a clean compile.
That won't even make it through the casual review. Most project maintainers don't like code that's impenetrable. Unless it's a fix for a critical bug that nobody else even has a proposal for a fix for, they're going to take one look at obfuscated code and toss it back with a "No thanks.". Especially if it's coming from a source they don't recognize, because messy complex obfuscated code also tends to be buggy unreliable unmaintainable code and they don't want the headache.
It's possible the NSA did something bad to the code, but it's not likely and it won't last.
For the "not likely" part, code accepted into Linux projects tends to be reviewed. The NSA can't be too obvious about any backdoors or holes they try to put in, or at least one of the reviewers is going to go "Hey, WTF is this? That's not right. Fix it.". and the change will be rejected. That's even more true with the kernel itself where changes go through multiple levels of review before being accepted and the people doing the reviewing pretty much know their stuff. My bet would be that the only thing that might get through would be subtle and exotic modifications to the crypto algorithms themselves to render them less secure than they ought to be.
And that brings us to the "not going to last" part. Now that the NSA's trickery is known, the crypto experts are going to be looking at crypto implementations. And all the source code for Linux projects is right there to look at. If a weakness were introduced, it's going to be visible to the experts and it'll get fixed.
That leaves only the standard external points of attack: the NSA getting CAs to issue it valid certificates with false subjects so they can impersonate sites and servers, encryption standards that permit "null" (no encryption) as a valid encryption option allowing the NSA to tweak servers to disable encryption entirely, that sort of thing. There's no technical solution to those, but they're easier to monitor for.
Slashdot Mirror
The single most important thing isn't about software engineering specifically, it's the ability to analyze a problem, break it down into it's component parts and work out a structure for your solution that solves the problem well. Just like the most important part of building a house isn't anything to do with actually building it, it's deciding what kind of house you're going to build, what rooms it's going to need and how they're going to be arranged. You need a very different house if you want it to support a family with 2 or 3 kids vs. just a single person or a couple without children. If you don't get that right, all the technical chops in the world later on won't help your having been hamstrung by a bad overall design. Lack of that ability has been the root cause behind something like 75% of the "software engineering" failures I've had to deal with.
What's more telling isn't the instances of bad cops. It's the fact that those bad cops aren't subject to any significant disciplinary action. There will always be bad cops, but when the good cops accept and tolerate them and do nothing to get rid of them it's indicative of a fundamental ethical problem. That's why I don't trust any part of law enforcement to act ethically and honestly.
In rebuttal to item five, I have to point out: Mike Nifong and the Durham Police Department in their handling of the Duke lacrosse team case. I also have to point out the behavior, documented on video, of the police in the numerous cases where they've been filmed physically beating suspects long after those suspects were physically incapable of resisting (or where the suspect wasn't resisting in the first place), threatening people and arresting them for documenting police activity while clearly not interfering with it, tazing someone who was bedridden and physically incapable of being any threat to the officers... the list of unreasonable activities just seems to grow. So when someone asks whether the police could be that corrupt, incompetent and/or malicious, I have to say the evidence doesn't support an answer in the negative.
I have one basic requirement before I'll use a logon credential system: I must be able to change the credential in the event it's compromised. If I can't recover from a compromise by changing the credential so it's no longer available to whoever compromised it, I won't use it. I never ever want to be in a position where my login has been compromised, I have to continue using it and I can't make it so the bad guy can't use it anymore.
The people pushing biometrics are handwaving away the difference between identification and authentication. Authentication usually requires identification as a first step, but it then requires a second step: proving that you truly are the person you've been identified as. Think of it like a safe-deposit box: the bank checks your driver's license to see who you are and from that which deposit box is yours. That's identification. But they won't open the box for you. You have to authenticate by making use of the key you were issued to open the box, which someone who was merely impersonating you wouldn't have. Western Union would be an example of a system of authentication without identification. When money's sent the sender can provide a question and answer instead of requiring identification. Anyone who can provide the correct answer to the question is authorized to pick up the money, identification not (normally) needed. That's a lifesaver for people who've eg. been robbed and whose ID was taken along with the wallet.
Or Tesla spins it as "We're incorporating a built-in fire-suppression system, the same as all race cars have had for the last 20 years or so. Why our competitors haven't done so by now,... you'll have to ask them, they're the ones who've been fielding the racing teams using this technology.".
Oh BTW, yes that means that public-key certificates issued by a certificate authority are also vulnerable. Not as vulnerable, but if you're depending on a CA to vouch for the validity of the certificate then the government can demand (and have demanded) that the CA turn over their root signing keys. At that point the government can issue themselves a certificate in your name, signing it with the CA's key, and their certificate will be accepted as valid by everyone allowing them to impersonate you. That's not quite as bad a compromise as them being able to eavesdrop on all your communications, but it's bad enough to be a problem.
It's not limited to just SSL. Any company that holds a copy of your encryption/decryption keys (a public certificate is OK, the matching private key that goes with it is the problem) can be ordered to turn them over. The only safe system is where the keys that secure the system never leave your possession.
For e-mail that means using S/MIME or OpenPGP with a self-signed certificate and a private key you generate yourself. For encrypted documents, the same. The e-mail and documents need to be encrypted on your end before they leave your computer. Be aware that if you're encrypting messages to someone else the security will be controlled by their handling of their keys. You're encrypting using their public key, there's no security implications from disclosure there. However, if the recipient's using a service where the provider has a copy of their private key (used to decrypt messages to them) then messages can potentially be eavesdropped on by outsiders who've compromised the provider and gotten the key. Be aware of this aspect and make sure you know how recipients are handling their own security.
Yes, the above means any and all web-based or hosted services are automatically vulnerable no matter how they're designed. The only secure systems are ones where you, or software running on your computer and that you control, does the encryption and decryption and the private keys are never disclosed to any other party.
Some of it could be due to attitudes changing after retirement. Before retirement the idea of having to put back savings for retirement and be careful not to blow your money because you're going to need it later colors your thinking. After retirement you don't need to save up for retirement, and you become very aware that you do not have an entire lifetime ahead of you to worry about anymore. That changes your evaluation of risk.
Because if something major does happen, an MSA won't cover it. I had a bout of pneumonia. That cost me 5 weeks in the critical-care unit in an induced coma, a month of inpatient rehab, another 6 months of outpatient physical therapy, plus a year of IV therapy to fix the immune-related problem triggered by something (they're still not sure what) during my stay in the CCU (which still hasn't completely resolved the problems, but they're down to the point where the pain can be managed by medication). The hospital bill alone came to $350K, the IV therapy came to in excess of a hundred grand, plus another fifty grand or so for the physical therapy. All told over half a mil, and that's at the rates the insurance companies pay. Without the insurance contracts, the rates would've been at least twice that. Now, how many people do you know of who can afford to put half a million dollars in a savings account?
And you seem to be under the impression that insurance acts like a savings account. It isn't. Insurance coverage is supposed to be a risk pool. You don't pay into it to withdraw what you paid in. You pay in to insure that if that massive bill hits that it's paid for. That's why insurance rates were never traditionally calculated based on individual risk. They were calculated by taking the total risk for the whole pool and dividing it by the number of people in the pool. So if you had a thousand people and one of them would get hit with that half-million-dollar bill every year, you charged everybody a $500/year premium. Each year the pool gets enough in premiums to cover the pay-outs, and each person gets a payment they can afford and the security of not having to gamble on the outcome.
No, but the person you're sending the e-mail to has. When you send physical mail to someone, you don't know if they've got a secretary opening and reading all their mail for them. They could even have an outside company doing it (what, you think Hollywood stars and politicians read and answer their own fan or constituent mail?). And the law has absolutely no problem with this, nor with the idea that if this will be a problem for you as the sender then it's your responsibility to sort this out with the recipient before sending your mail.
I think it says something about your viewpoint, and that of management in general, that you equate laying people off with backstabbing. Most people I know of outside of management don't. Management... seems not to get that it's the lying and misleading that anger employees most, not the layoffs.
If you can't trust them then, you couldn't trust them before. You just didn't have any reason to think about it before.
As an IT professional, what angers me is mostly management lying and claiming everything's hunky-dory and then blindsiding me with layoffs. When they do it even once, it convinces me that I can't trust them ever again. That's not a problem if I'm one of the ones being shown the door, but companies rarely lay off everybody in a single pass and this creates if anything even worse trust issues with those who're still working. At the very least this behavior will turn me from someone who considers it only professional to give as much notice as possible if I decide to go elsewhere into someone who a) doesn't feel obligated to give any more notice than legally required since the company's shown that's what they'll do and b) is more likely to start looking before he gets caught in the next round of layoffs. Whereas if the heads-up is given, I'm less likely to worry and be looking to jump ship because I know I'll have advance warning next round too.
That no-advance-warning is only a good idea if you can't trust your IT people in the first place. And if you can't trust them, why are you trusting them to run your IT department?
That's because, if you look at your Google+ settings, it has a feature that lets you share your location with your circles and contacts. Whether your location is shared or not, and with who, is under your control, but Maps needs to read your contact list to know who's in it so it knows who's eligible to see your location since it's the app on the phone that handles monitoring and updating your location.
This can be both intrusive and useful. If I were making a cross-country trip I'd likely enable location sharing with a couple of friends. That way if anything happened they'd at least know where to start looking when I didn't check in.
The problem is that mostly this stuff is given voluntarily. It's just not given by you. You voluntarily connect with person A, for good reasons. And then person A for reasons that seem good to them (maybe because in their work the connections they have has an impact on their income) makes it public that they're connected to you. Then for good reasons they connect to person B. And person B is careless, or doesn't think, and they let a site siphon up their connections. Presto, that site now knows about your connection to person A.
The basic problem is that "voluntary" is transitive and "private" is not, but we treat it as if it's the other way around.
I know LinkedIn isn't doing it to me, because the IMAP/SMTP server I use for e-mail doesn't have my contacts on it. IMAP and SMTP don't even have the concept of contacts or an address book. End of problem.
Likely the LinkedIn users in question use a webmail service like GMail and gave LinkedIn access to their e-mail account to import their contacts. You get asked for this when setting up your LinkedIn account, and if you're using a browser that's logged into Google the LinkedIn site may try to get access directly and it's easy to give it access by mistake unless you're a professional paranoid like me whose default answer to every unexpected prompt is to close the browser down (I don't trust Close links in an HTML page to just close the page). Or someone the person corresponds with may have given LinkedIn access to their address book and found connections that way. Or LinkedIn may have scanned the user's public profile on Google+, gotten their publicly-listed circles and used the public profiles for those people to gain contact information. There's a lot of ways to gain access to this information that don't involve hacking an e-mail account. More likely the plaintiffs here have just been faced with incontrovertible proof that it really is as easy to find out this kind of stuff about them as their paranoid friends have been telling them and are trying to find any other explanation that lets them retain their warm fuzzy false view of the world.
That's their latest attempt to dig themselves out of the hole. But it's the same mistake they made at the beginning, only reversed: instead of making a phone that works like a desktop, they're trying to make desktops work like phones. At this point they can't fail to get the idea that people don't use phones the same way they use desktops, so I can't write this one off to just them being clueless.
Microsoft simply failed to recognize that people use phones differently than they use desktop computers. MS started by trying to make a desktop Windows run on a smartphone. That cratered because a UI that works on a desktop is awkward and hard to use on the small screen of a phone. Lack of touchscreen support didn't help one bit. And even after they got that concept, they've continued to try to force people into the Windows ecosystem rather than attempting to fit their phones into the existing ecosystems. People don't care much about Office on their phones beyond e-mail and for personal use Exchange integration is almost irrelevant because most people's e-mail accounts aren't Exchange, they're generic POP3/IMAP4 accounts or GMail. Now Microsoft is left with a minority position and an unwillingness to play in anyone else's sandbox, not to mention having actively torqued off the owner of one of the two biggest sandboxes out there (Google). Is it any wonder they're having a hard time gaining traction?
Point that needs to be considered: we don't explore just for the joy of exploring. Humans have always explored because we think we'll find something useful/exploitable out there we can bring back and get rich from. Most of the Americas got explored because Europeans wanted gold, lumber and such. Robots are all well and good, but they have a hard time finding anything they aren't designed to search for and most of the time we don't know exactly what we're looking for that we might want. Humans are the best tools we have for figuring out what unknown junk might be useful/profitable. And once we find something, humans are the best way of actually exploiting it and bringing it back home in a useful form. Which all means that sooner or later we're going to have to send people out there and keep them there for extended periods.
It's probably that the defendants, not being Cisco, will lack the detailed knowledge of how Cisco's products work internally to show that the products don't infringe the patents, and won't have the in-depth knowledge of the fields involved to uncover prior art or successfully demonstrate obviousness. If I were the defendants, I'd be moving to have the suits dismissed on the grounds that Cisco made the equipment and had a license for the patents and the defendants are merely using Cisco's equipment without adding anything to it, or alternatively if plaintiff claims Cisco didn't have a license to have Cisco joined as a co-defendant since plaintiff is accusing them of infringing on the patents.
So now instead of cutting off your finger so they can open the fingerprint locks, which involves physical assault, the thieves can just slap an EEG on your head for a few minutes, splice into the wiring and play the recording back after bypassing the sensors. Or they could take advantage of the ability to record more than one person's brainwaves to make themselves an authorized driver (cars will have to allow this because more than one person drives a given car). Or they could use the bypass built-in for letting someone borrow your car (which again will have to be allowed because people do let friends borrow their car for a quick trip to the store) to "borrow" your car. This won't slow the thieves down much, all it'll do is give car owners a false sense of security and make them more careless.
Myself, I favor a "make the car undrivable" approach, eg. if the ignition is triggered without a door having been opened with the key or the keyless remote, the ECU disables the fuel pump. The car's still vulnerable to thieves who just load it onto a flatbed tow truck, but nothing can really stop that.
No. RDRAND isn't software, it's an instruction on Intel CPUs to access the built-in hardware random number generator. The code in question is code to make use of RDRAND in cases where random numbers are needed regardless of whether there's sufficient entropy to generate good-quality random numbers. Using it doesn't degrade security because what it replaces would simply return poor-quality (ie. non-random) results if there wasn't sufficient entropy accumulated (which is the case during system startup when there just hasn't been enough time to accumulate significant entropy).
The random-number source here is separate from the regular /dev/random source used by most software, which guarantees good results even if it has to block and force your call to wait until enough entropy has been accumulated.
Why would you need to look at the code to find that? The compiler will flag that one (assignment within an 'if' statement test is extremely questionable, it's more likely a typo than correct code) and the code will be rejected as "Fails to compile cleanly.". Adding the pragma or compile option to suppress that warning likewise will get the code rejected because you shouldn't need to suppress that warning to get a clean compile.
That won't even make it through the casual review. Most project maintainers don't like code that's impenetrable. Unless it's a fix for a critical bug that nobody else even has a proposal for a fix for, they're going to take one look at obfuscated code and toss it back with a "No thanks.". Especially if it's coming from a source they don't recognize, because messy complex obfuscated code also tends to be buggy unreliable unmaintainable code and they don't want the headache.
It's possible the NSA did something bad to the code, but it's not likely and it won't last.
For the "not likely" part, code accepted into Linux projects tends to be reviewed. The NSA can't be too obvious about any backdoors or holes they try to put in, or at least one of the reviewers is going to go "Hey, WTF is this? That's not right. Fix it.". and the change will be rejected. That's even more true with the kernel itself where changes go through multiple levels of review before being accepted and the people doing the reviewing pretty much know their stuff. My bet would be that the only thing that might get through would be subtle and exotic modifications to the crypto algorithms themselves to render them less secure than they ought to be.
And that brings us to the "not going to last" part. Now that the NSA's trickery is known, the crypto experts are going to be looking at crypto implementations. And all the source code for Linux projects is right there to look at. If a weakness were introduced, it's going to be visible to the experts and it'll get fixed.
That leaves only the standard external points of attack: the NSA getting CAs to issue it valid certificates with false subjects so they can impersonate sites and servers, encryption standards that permit "null" (no encryption) as a valid encryption option allowing the NSA to tweak servers to disable encryption entirely, that sort of thing. There's no technical solution to those, but they're easier to monitor for.