Personally, I love crap like that. Because it's cool to demonstrate to people that such software exists today.
Think about it -- how difficult is that software to write? You just described its functional specifications and wrapped them in a single paragraph, including complaints. Sure, it would need to be customized on a city-by-city basis, but for a city the size of New York it wouldn't be impossible.
As a matter of fact, I thought the whole idea was so cool I just now googled for more info. I found searching for the terms AeroTriangulation found a few software vendors who have products that combine maps and photos. Rockware seems to sell a lot of it. And I remembered that in a previous Slashdot story that there's a company performing a photolocation service! Here's the article.
So, isn't it actually even cooler that the technology you reported them using was actually lower tech than the current state of the art in photolocation software? In reality nobody has to click on the Empire State Building, because the software already recognizes it! How cool is that?
Can I have aflash on my pin hole camera also please?
So, you have a Sony Ericsson T637, too?
Maybe they need to specify a "quality" at which a flash is required. I know that my camera is such a piece of crap that unless the phone were within a meter of your face, you'd be completely unrecognizable.
Besides, they're just digital images. If someone is going to be embarrased by a digital photo in a public place, then I could photoshop a much higher quality picture of them into the same setting, with just as much validity.
Oooh, it also has "Sound Activity Detector" -- it records sound only when there is sound to record. So you can place it in the boss's office before he gets there in the morning, have it record the secret meeting with the director, then pick it up after work.
Now, if you could just get it to take pictures when it hears a sound...
You're welcome. If it's any consolation, what you're trying to accomplish is a very difficult problem to secure.
Something else that you might consider that isn't necessarily going to help much is to add a secret key as an Initialization Vector (IV) to the hash. An attacker simply observing the system can watch "12345" go in and see "aBcDe-NaCl" come out ("NaCl" is the salt:-), and build his dictionary that way, without performing a single cryptographical attack. Of course, this requires more active participation than simple analysis of a stolen database, so you'll have to judge your risk tolerance level for yourself. If you trust your computing environment can't be compromised (and you're trusting of your insiders) then it may be an acceptable risk.
Keep in mind that there are many ways of attacking this stuff: using his own personal Visa card just prior to stealing a copy of your database, an attacker can make an educated guess that the newest-timestamped row in the table is his own card, giving him a known plaintext wedge. Even if your rows aren't time stamped (not even in the super-secret hidden system columns), the addition of the row may end up in a SQL recovery journal file somewhere, and the attacker might reasonably expect his data to be at or near the end of this log file.
( Yes, all these are the tricks of a psychotically determined attacker, but what other kind are you protecting against? )
And my earlier analysis was pessimistic, by the way. My desktop can search a single bankcard's entire 10^11 account number space in about 156 seconds, or just under two and a half minutes. That means I could perform an exhaustive dictionary attack on all 750 billion* potentially valid Visa account numbers in about 2.5 hours.
* based on a not-publicly-available 2003 list of valid Visa bankcard ranges.
I'm assuming they don't like it because it promotes "intimate" knowledge of the object.
If you have a rule object whose job is to compute the scoring moves of a game, you shouldn't be asking it "what is the score of a headshot?" You should be telling it "I made a headshot" and let it worry about the score.
If you start having other parts of the app getting that intimate knowledge, your app "crusts over". Now, if you change the scoring rules regarding headshots, not only do you have a rules engine to update but you may have to hunt down other classes that were foolish enough to get that data.
This generic rule doesn't really apply to the case of a simple storage class. There, the whole idea of a storage class is to use getters and setters to validate the data. This maxim applies more to rules and business logic.
You're absolutely right in that an adversary can play one system off the other. Having the strings hashed with MD5 is your weak point.
You mentioned that these strings are "short". "Short" means the string space can be brute forced much easier than the hash. Lets say that an attacker concludes these short strings you're encoding map to Visa account numbers (a typical application.) A Visa number, for example, has only 14 unique bytes to brute force, and even then the search space drops to 11 digits when you factor in 4 digit bank numbers (there are even 6 digit bank numbers, but I'll stick to 4 for the example. And since many bank cards are regionally based, if a ZIP code field is present there's a reasonable chance that one of that ZIP code's regional banks may have issued the card.) So 10 possible values for 11 digits yields 10^11 possible values. 10^11 is not a particularly large number of MD5 hashes to generate to determine if a value was encoded -- a high-end dual Xeon desktop could probably search an entire bank's account number space in about six minutes or so. Picking the top 5 national Visa bank numbers plus the top 5 local-to-the-ZIP-code bank numbers means a reasonable chance at a break in about an hour.
I really don't know anything about OAEP (other than that this RSA page says, "This means that to construct a valid OAEP encoded message, an adversary must know the original plaintext." That doesn't bode well for you. If the attacker just figured it out the plaintext by a brute force search of the account number space, then he's got a new wedge into your systems.
That's why mixing crypto systems without a full understanding can seriously weaken security, rather than enhance it.
If your data is truly random, the starting point will be irrelevant to the security of the scheme. Therefore, in the interest of key maintenance, it would be best to start at the beginning with the first message, and always begin the next message at the point where you previously left off. This ensures that you use all the key material once and only once, and as soon as you run out you destroy the disks.
If you were to accidentally reuse a piece of the key, the plaintext would be quite easy to recover. For more on the subject, and how the FBI knew that the Rosenbergs were guilty, see the NSA's Venona site. For an easier-to-read treatment of the subject, I strongly recommend a third party analysis, such as Venona: Decoding Soviet Espionage in America by John Earl Haynes and Harvey Klehr (Yale, 1999.) In it, the authors explain why the Soviets probably re-used their one-time-pads.
What is also interesting to note is the authors' conclusion that the 'code names' the Soviet agents used actually turned out to be one of the best security measures they used. The people in the messages were identifed by a tedious procedure of compiling a list of suspects, then finding additional information that pinpointed their suspect. Julius and Ethel Rosenberg were identified by their relationship to Ethel's brother, David Greenglass, in a background 'biography' sent to the KGB by their handler. There were at least 20 other moles in the Venona decrypts that were never publicly identified because the NSA could not deduce their real identity from their cover names.
Except the average manager won't be able to stay awake for much longer than a one page article. If the author of the article had actually had known what he was talking about and put in some actual facts instead of that completely erroneous paragraph about 128-bit vs 1024-bit (in which he completely demonstrated his lack of understanding) it might have been a useful executive primer on encryption.
As it is, I'm harming lots of electrons here discussing a valueless document.
Oh, and you're right about those books being excellent. But you should really warn people that The Codebreakers is about 1200 pages of excellence, and not exactly a bedtime tale.
Actually, Practical Cryptography is probably more useful to most people. In that book, Bruce provides real-world examples of security needs and then details how the protocols should be implemented so as to preserve that security. He leaves the math alone, and discusses the protocols and data instead.
He wrote it after realizing how poorly people had misunderstood his warnings in Applied Cryptography (as documented in Secrets and Lies.) I thought his warnings were plain enough, but apparently too many people just plopped in some encryption because they "needed" some, and Blowfish was printed right there in the appendix.
Well, there once was a hole or two in PGP that exploited the insecurity of the session key also. As I recall (mind you, I have a pretty poor recollector) the session key was stored in the clear, and the session key generator was a PRNG that could be "wound forward" given a previous session key. Both of those allowed an attacker a way to use a "known" value of the session key to run the PRNG forward and backward, trying all possible session keys on the message to see if they worked.
This was cured by encrypting the session key file and I think they used some kind of a stronger PRNG to create new session keys every time.
You can use a secret-key algorithm as a proof to the other holders of the key that you know the key by using it as a secure hash algorithm. But you're right, you can't use a private key algorithm as publicly-verifiable proof of a signature.
For example: Alice can encrypt each block of data in the document with her secret key, and XOR them all together. She then sends Bob the value along with the document.
Bob can take the document and perform the same hash function using his secret key. If they match, Bob knows the signature on the document came from someone else who knows the secret key.
This probably doesn't meet your requirement as a signature in that a third party can't tell Bob's signature from Alice's. They can send a challenge to both Alice and Bob asking them to sign the document after appending a random nonce and validating that the received signatures match. But as long as Bob and Alice can be sure that the document was signed by an authorized key holder, they may not care which keyholder performed the signature. It's application dependent.
Of course the third party can't be more involved anyway since in order to validate a signature they would have to know the key. So, its real only use is as a tamper-proof seal that Alice and Bob can use between themselves, perhaps a convoluted proof that an archived document hasn't been tampered with.
This is very similar to a recent Minnesota Public Radio discussion on the effects of doctors doing their residencies at hospitals that required constant 16-32 hour shifts in the E.R. They had a guy on who was trumpeting a study proving that sleep-deprived doctors make lots of mistakes, and that the whole system needs to be changed for our health.
The guy was completely right, yet he was a complete idiot.
I don't think there's a profession with a higher amount of arrogance than that of physician (yes, even we software developers aren't as arrogant as doctors.) And everyone who has been promoted to "head of surgery" or whatever the lead doctor is called is cut from the same cloth, and shares the common training history. So they're going to sit in their oak-paneled offices and say "we survived our 24x7 residencies, you better too or you won't cut the mustard as a REAL doctor." Their arrogance will blind them to the study this guy had, the training regimen will never change, and about the only outcome I forsee is this guy getting trapped in whatever hospital he practices in. Perhaps in 20 years his message will sink in, but today's pre-med students certainly should not be looking for any changes.
Fortunately, EA is not the only shop in town, even though it may seem like it in today's economy. Not every employer is willing to subject their employees to this same kind of torture, so it's not likely to catch on as an industry standard. And not every potential employee is willing to put up with this kind of treatment, so there's a real likelihood of change as the pool of talented yet desperate people shrinks.
He sounds kind of touchy. Personally I don't care if bug reports that get to me used the word "suck", other than I probably would need more specific information as to what specifically sucked (jerky, aliased, shaded wrong, wireframe showing.) Suck is simply too generic, it sounds too much like "my internet is broken, fix it."
Except now, it's almost unimportant to know this stuff.
Many CSci majors being cranked out these days don't know what the technology is behind the hardware. RAM is something you buy sticks of, and your technology choices there are PC-2100 or PC-3200. Some of the more technical people can tell you what SPD means and what it does, fewer are be able to explain why there are different delays or clock timings. And even fewer are able to explain WHY memory needs refreshing, because they don't know the nature of the electronic actions on the chip.
That said, how many CSci majors will actually need to know this? Think about it -- a computer still "works" whether or not you understand how bits are stored as tiny amounts of stray capacitance, or if the bits are stored as magnetic fields in ferrous donuts threaded on tiny wires.
Of course if you're a serious overclocker, you'll learn more about refresh and how to push the timings to eke the best possible performance out of every component. In order to take full advantage of any system, full knowledge of the system is required, regardless of whether we're discussing computers or cars or boats. But this detailed knowledge now is relegated to EE majors, not CSci majors.
Personally, I don't like the thought of computer scientists having no understanding of the physical processes occuring inside their computer cabinets. I think anyone who wants to be taken seriously should understand this stuff to some degree. But it's certainly not required in order to use a computer, and I don't think it's even being taught any more except in the most general sense of "this is RAM, this is disk, any questions?"
People put more faith in the exit polls being correct than the counting of the actual ballots.
No kidding. Most of the people I talked to who were polled after voting told me they lied to the exit poll takers. So they either lied to me or they lied to CNN -- either way, they lied. I tend to believe many people lied to CNN because of some of the statistics I saw on election day. One example was "% of people claiming to be liberal voting for Bush: 81%" and "% of people claiming to be conservative voting for Kerry: 75%"
Now, most people who consider themselves "liberal" didn't vote for Bush. As evidence, you may recall that many of Bush's attack ads went out of the way to use the phrase "John Kerry and his liberal allies in the Senate..." The word "liberal" was not used as a positive modifier in the context of a George Bush-approved advertisement. Yet CNN's exit polls show the "liberals" claiming to have heavily voted for Bush, and the "conservatives" to have voted for Kerry.
I have no way of knowing how many people gamed the CNN polls. I certainly feel that the right to secrecy in voting grants me the right to tell the poll takers that I voted for Phillip J. Fry, if I want. Yet when CNN presents the numbers, I tend to forget that many people share my views on the invalidity of exit polling, and tend to believe them anyway. Color me human.
True, but I'd pick a different example than Circuit Shitty. I have been so disappointed every single time I've walked through their doors that I may never bother returning.
I've gotten in the habit of going to the local stores first, then Best Buy as a second choice (only if I need to.) I'm spending more money in some cases, and less money in others, but my overall satisfaction with my purchases is much higher.
And while some people seem to enjoy the game of shopping in a store with a knowledgable staff, then purchasing the product online at a steep discount, I'm not one of them. I know that when I went to National Camera to purchase my Canon G2 that the salesman helped me for over an hour (even while the store was packed with customers.) He showed me the details of each camera, options, discussed battery life, etc. I know I received at least $60 worth of advice from him that day, and purchasing the camera from him at their retail price was very much worth it to me.
The same experience has been true for me at other stores as well. I'm willing to pay for service, and I give out my recommendations commesurate with my experiences. As the family's "Tech Guru" my recommendations do carry some financial weight. Best Buy simply isn't my first choice for anything other than a simple "just get a little 13" TV at Best Buy" type recommendation.
Since I usually find the Best Buy sales help to be more "in your face" than actually "helpful", maybe I should wear a name tag saying "Hi, my name is Devil Customer". At least then they'd leave me alone rather than try to offer me a heat sink with an extended warranty when I'm just looking for a USB cable.
Agreed completely. We experienced this exact behavior less than two hours ago. When my wife called to cancel our Long Distance service now that Quest has decided to start charging a monthly fee, the customer service representative actually said these words: "Since other long distance carriers are now charging outrageous fees, Quest is now charging a monthly fee in order to remain competetive."
They may "remain competetive," but with an approach like that I have no idea how they intend to "remain in business."
"Bury and forget" is pretty much a design requirement. It has to be placed somewhere so inaccessible that it can't be retrieved with current or forseeable small-scale technology.
Remember, it will be dangerous for the next 20,000 years. It's not up to us to tell our great-great-grandchildren to stand guard over our poopy diapers. No civilization has ever lasted on a time scale like that, and it would be the ultimate in hubris to think we're somehow different. So guards will eventually fail. Monitors will stop being monitored. Buildings will crumble. Governments will collapse. We can't even hope to post a sign on the site that will last more than a few centuries, as our language may evolve beyond the point where that ancient writing hold any meaning to our grandkids.
The best we can hope for is to plant this stuff very deep in the earth, in a place where it can't be extracted without notice, and where future generations will probably never "bump into".
My first choice would be to use the deep well drilling techniques used by the petroleum industry, and inject the stuff a kilometer or more down into some very stable layers. But drilling rigs are only a few inches in diameter, and the storage requirements are vast. Some of the liquid waste (such as what is being held at Hanford) could be pumped down those holes. But spent fuel rods wouldn't fit as-is, and I don't know if it can be adequately liquified to pump down there. Yucca Mountain still seems like a not-bad choice, since we have to deal with this crap anyway.
First, spent nuclear fuel is extremely heavy -- uranium is more dense than lead. Next, you can't just launch it into orbit. Orbits decay over time, and this isn't something you want coming back as a giant asteroid of doom. So you actually have to get it to the sun for proper disposal. Low Earth Orbit launchers (such as the space shuttle, or the Atlas series of rockets) are inadequate to the task. It will require rockets the size of the old Saturn launchers to boost this material to the sun. So the cost will be enormous -- I think a billion dollars per ton is a conservative estimate.
The bigger problem is that rockets are far from perfect. Would you want to be anywhere on the planet if a Saturn V carrying six tons of depleted uranium exploded at 50 miles up? The waste would be dispersed across an area covering several states.
A space elevator might make space-based nuclear waste disposal a possibility, some day. But for now, rockets are not a viable disposal option.
Currently most, if not all power generators are storing their spent fuel in "temporary" storage facilities. One I am familiar with is the Prairie Island plant in Minnesota (along the Mississippi river), who filled their temporary storage to their licensed capacity a few years back, and the energy company had to ask the state to license them more capacity. The local native American tribes were unhappy, the environmentalists were unhappy, and the politicians had to make an unpopular compromise. But they're now storing more spent fuel on site, and they still have no final disposal site.
After removal from the reactor, the spent fuel itself is temporarily stored in pools of water in concrete tanks, awaiting shipment to a final disposal site. Those temporary tanks are now full to capacity, and they are degrading quite rapidly (continual neutron bombardment is not healthy for things like concrete.)
All the power plant operators in the country are pretty much hoping that a national disposal site like Yucca Mountain will be opened to them soon for storing their spent fuel. But dealing with nuclear waste is quite literally a "hot" potato for any politican. Nobody wants to store it short term in their back yard, nobody wants to store it long term in their state, and the states in between the plants and the waste site don't even want the trains of waste to cross their state.
Yucca Mountain has long been talked about as a national disposal site, but the native Americans in the area are opposed to the idea. (They were once in favor of selling the site to the federal government, but have since changed their mind.) The proposal is to dig tunnels under the mountain, load in the waste, and backfill the tunnels with concrete.
There have been other interesting proposals to permanently store the waste. One is to bury it in the sea bottom, using drilling rigs similar to that used for off shore oil drilling. They'd plant the waste several hundred feet below the sea floor, and backfill them with the naturally present clay. Models show that the radiation would leach no further than a few dozen feet from each glass log, even after 20,000 years. But try to imagine the reaction when you tell the Greenpeace organization that you want to study planting radioactive waste under the ocean. Not a popular proposal.
Spent reactor fuel has a fairly long half life, and it will take 20,000 years for the radiation levels to drop to "safe" levels. Humans have never built a structure designed to last 20,000 years. Modern engineers realize they have no way to build anything that permanent; and even more so they know they cannot build a structure that would be able to withstand continual radiation for 20,000 years. The best they can hope for is to bury the waste deeply in an area that is as inaccessible as possible.
So, the "temporary" storage tanks remain full, and there are no current plans to empty them because there is no final disposal site. But there needs to be.
Slashdot Mirror
Personally, I love crap like that. Because it's cool to demonstrate to people that such software exists today.
Think about it -- how difficult is that software to write? You just described its functional specifications and wrapped them in a single paragraph, including complaints. Sure, it would need to be customized on a city-by-city basis, but for a city the size of New York it wouldn't be impossible.
As a matter of fact, I thought the whole idea was so cool I just now googled for more info. I found searching for the terms AeroTriangulation found a few software vendors who have products that combine maps and photos. Rockware seems to sell a lot of it. And I remembered that in a previous Slashdot story that there's a company performing a photolocation service! Here's the article.
So, isn't it actually even cooler that the technology you reported them using was actually lower tech than the current state of the art in photolocation software? In reality nobody has to click on the Empire State Building, because the software already recognizes it! How cool is that?
So, you have a Sony Ericsson T637, too?
Maybe they need to specify a "quality" at which a flash is required. I know that my camera is such a piece of crap that unless the phone were within a meter of your face, you'd be completely unrecognizable.
Besides, they're just digital images. If someone is going to be embarrased by a digital photo in a public place, then I could photoshop a much higher quality picture of them into the same setting, with just as much validity.
Now, if you could just get it to take pictures when it hears a sound ...
The problem is the agents had put black tape over the flash so they wouldn't be noticed...
Something else that you might consider that isn't necessarily going to help much is to add a secret key as an Initialization Vector (IV) to the hash. An attacker simply observing the system can watch "12345" go in and see "aBcDe-NaCl" come out ("NaCl" is the salt :-), and build his dictionary that way, without performing a single cryptographical attack. Of course, this requires more active participation than simple analysis of a stolen database, so you'll have to judge your risk tolerance level for yourself. If you trust your computing environment can't be compromised (and you're trusting of your insiders) then it may be an acceptable risk.
Keep in mind that there are many ways of attacking this stuff: using his own personal Visa card just prior to stealing a copy of your database, an attacker can make an educated guess that the newest-timestamped row in the table is his own card, giving him a known plaintext wedge. Even if your rows aren't time stamped (not even in the super-secret hidden system columns), the addition of the row may end up in a SQL recovery journal file somewhere, and the attacker might reasonably expect his data to be at or near the end of this log file.
( Yes, all these are the tricks of a psychotically determined attacker, but what other kind are you protecting against? )
And my earlier analysis was pessimistic, by the way. My desktop can search a single bankcard's entire 10^11 account number space in about 156 seconds, or just under two and a half minutes. That means I could perform an exhaustive dictionary attack on all 750 billion* potentially valid Visa account numbers in about 2.5 hours.
* based on a not-publicly-available 2003 list of valid Visa bankcard ranges.
If you have a rule object whose job is to compute the scoring moves of a game, you shouldn't be asking it "what is the score of a headshot?" You should be telling it "I made a headshot" and let it worry about the score.
If you start having other parts of the app getting that intimate knowledge, your app "crusts over". Now, if you change the scoring rules regarding headshots, not only do you have a rules engine to update but you may have to hunt down other classes that were foolish enough to get that data.
This generic rule doesn't really apply to the case of a simple storage class. There, the whole idea of a storage class is to use getters and setters to validate the data. This maxim applies more to rules and business logic.
You mentioned that these strings are "short". "Short" means the string space can be brute forced much easier than the hash. Lets say that an attacker concludes these short strings you're encoding map to Visa account numbers (a typical application.) A Visa number, for example, has only 14 unique bytes to brute force, and even then the search space drops to 11 digits when you factor in 4 digit bank numbers (there are even 6 digit bank numbers, but I'll stick to 4 for the example. And since many bank cards are regionally based, if a ZIP code field is present there's a reasonable chance that one of that ZIP code's regional banks may have issued the card.) So 10 possible values for 11 digits yields 10^11 possible values. 10^11 is not a particularly large number of MD5 hashes to generate to determine if a value was encoded -- a high-end dual Xeon desktop could probably search an entire bank's account number space in about six minutes or so. Picking the top 5 national Visa bank numbers plus the top 5 local-to-the-ZIP-code bank numbers means a reasonable chance at a break in about an hour.
I really don't know anything about OAEP (other than that this RSA page says, "This means that to construct a valid OAEP encoded message, an adversary must know the original plaintext." That doesn't bode well for you. If the attacker just figured it out the plaintext by a brute force search of the account number space, then he's got a new wedge into your systems.
That's why mixing crypto systems without a full understanding can seriously weaken security, rather than enhance it.
For truly random data, a Geiger counter is indeed a great device to use. John Walker has built and documented a device called "Hotbits" which he uses to generate truly random numbers.
If you were to accidentally reuse a piece of the key, the plaintext would be quite easy to recover. For more on the subject, and how the FBI knew that the Rosenbergs were guilty, see the NSA's Venona site. For an easier-to-read treatment of the subject, I strongly recommend a third party analysis, such as Venona: Decoding Soviet Espionage in America by John Earl Haynes and Harvey Klehr (Yale, 1999.) In it, the authors explain why the Soviets probably re-used their one-time-pads.
What is also interesting to note is the authors' conclusion that the 'code names' the Soviet agents used actually turned out to be one of the best security measures they used. The people in the messages were identifed by a tedious procedure of compiling a list of suspects, then finding additional information that pinpointed their suspect. Julius and Ethel Rosenberg were identified by their relationship to Ethel's brother, David Greenglass, in a background 'biography' sent to the KGB by their handler. There were at least 20 other moles in the Venona decrypts that were never publicly identified because the NSA could not deduce their real identity from their cover names.
As it is, I'm harming lots of electrons here discussing a valueless document.
Oh, and you're right about those books being excellent. But you should really warn people that The Codebreakers is about 1200 pages of excellence, and not exactly a bedtime tale.
He wrote it after realizing how poorly people had misunderstood his warnings in Applied Cryptography (as documented in Secrets and Lies.) I thought his warnings were plain enough, but apparently too many people just plopped in some encryption because they "needed" some, and Blowfish was printed right there in the appendix.
This was cured by encrypting the session key file and I think they used some kind of a stronger PRNG to create new session keys every time.
For example: Alice can encrypt each block of data in the document with her secret key, and XOR them all together. She then sends Bob the value along with the document.
Bob can take the document and perform the same hash function using his secret key. If they match, Bob knows the signature on the document came from someone else who knows the secret key.
This probably doesn't meet your requirement as a signature in that a third party can't tell Bob's signature from Alice's. They can send a challenge to both Alice and Bob asking them to sign the document after appending a random nonce and validating that the received signatures match. But as long as Bob and Alice can be sure that the document was signed by an authorized key holder, they may not care which keyholder performed the signature. It's application dependent.
Of course the third party can't be more involved anyway since in order to validate a signature they would have to know the key. So, its real only use is as a tamper-proof seal that Alice and Bob can use between themselves, perhaps a convoluted proof that an archived document hasn't been tampered with.
The guy was completely right, yet he was a complete idiot.
I don't think there's a profession with a higher amount of arrogance than that of physician (yes, even we software developers aren't as arrogant as doctors.) And everyone who has been promoted to "head of surgery" or whatever the lead doctor is called is cut from the same cloth, and shares the common training history. So they're going to sit in their oak-paneled offices and say "we survived our 24x7 residencies, you better too or you won't cut the mustard as a REAL doctor." Their arrogance will blind them to the study this guy had, the training regimen will never change, and about the only outcome I forsee is this guy getting trapped in whatever hospital he practices in. Perhaps in 20 years his message will sink in, but today's pre-med students certainly should not be looking for any changes.
Fortunately, EA is not the only shop in town, even though it may seem like it in today's economy. Not every employer is willing to subject their employees to this same kind of torture, so it's not likely to catch on as an industry standard. And not every potential employee is willing to put up with this kind of treatment, so there's a real likelihood of change as the pool of talented yet desperate people shrinks.
He sounds kind of touchy. Personally I don't care if bug reports that get to me used the word "suck", other than I probably would need more specific information as to what specifically sucked (jerky, aliased, shaded wrong, wireframe showing.) Suck is simply too generic, it sounds too much like "my internet is broken, fix it."
Many CSci majors being cranked out these days don't know what the technology is behind the hardware. RAM is something you buy sticks of, and your technology choices there are PC-2100 or PC-3200. Some of the more technical people can tell you what SPD means and what it does, fewer are be able to explain why there are different delays or clock timings. And even fewer are able to explain WHY memory needs refreshing, because they don't know the nature of the electronic actions on the chip.
That said, how many CSci majors will actually need to know this? Think about it -- a computer still "works" whether or not you understand how bits are stored as tiny amounts of stray capacitance, or if the bits are stored as magnetic fields in ferrous donuts threaded on tiny wires.
Of course if you're a serious overclocker, you'll learn more about refresh and how to push the timings to eke the best possible performance out of every component. In order to take full advantage of any system, full knowledge of the system is required, regardless of whether we're discussing computers or cars or boats. But this detailed knowledge now is relegated to EE majors, not CSci majors.
Personally, I don't like the thought of computer scientists having no understanding of the physical processes occuring inside their computer cabinets. I think anyone who wants to be taken seriously should understand this stuff to some degree. But it's certainly not required in order to use a computer, and I don't think it's even being taught any more except in the most general sense of "this is RAM, this is disk, any questions?"
Don't argue ancient computer history with me, young man. I lived through most of it!
Anyway, the big advantage of this book is that it may show some of you kids the kind of drivel we had to learn from back then. :-)
No kidding. Most of the people I talked to who were polled after voting told me they lied to the exit poll takers. So they either lied to me or they lied to CNN -- either way, they lied. I tend to believe many people lied to CNN because of some of the statistics I saw on election day. One example was "% of people claiming to be liberal voting for Bush: 81%" and "% of people claiming to be conservative voting for Kerry: 75%"
Now, most people who consider themselves "liberal" didn't vote for Bush. As evidence, you may recall that many of Bush's attack ads went out of the way to use the phrase "John Kerry and his liberal allies in the Senate ..." The word "liberal" was not used as a positive modifier in the context of a George Bush-approved advertisement. Yet CNN's exit polls show the "liberals" claiming to have heavily voted for Bush, and the "conservatives" to have voted for Kerry.
I have no way of knowing how many people gamed the CNN polls. I certainly feel that the right to secrecy in voting grants me the right to tell the poll takers that I voted for Phillip J. Fry, if I want. Yet when CNN presents the numbers, I tend to forget that many people share my views on the invalidity of exit polling, and tend to believe them anyway. Color me human.
I've gotten in the habit of going to the local stores first, then Best Buy as a second choice (only if I need to.) I'm spending more money in some cases, and less money in others, but my overall satisfaction with my purchases is much higher.
And while some people seem to enjoy the game of shopping in a store with a knowledgable staff, then purchasing the product online at a steep discount, I'm not one of them. I know that when I went to National Camera to purchase my Canon G2 that the salesman helped me for over an hour (even while the store was packed with customers.) He showed me the details of each camera, options, discussed battery life, etc. I know I received at least $60 worth of advice from him that day, and purchasing the camera from him at their retail price was very much worth it to me.
The same experience has been true for me at other stores as well. I'm willing to pay for service, and I give out my recommendations commesurate with my experiences. As the family's "Tech Guru" my recommendations do carry some financial weight. Best Buy simply isn't my first choice for anything other than a simple "just get a little 13" TV at Best Buy" type recommendation.
Since I usually find the Best Buy sales help to be more "in your face" than actually "helpful", maybe I should wear a name tag saying "Hi, my name is Devil Customer". At least then they'd leave me alone rather than try to offer me a heat sink with an extended warranty when I'm just looking for a USB cable.
They may "remain competetive," but with an approach like that I have no idea how they intend to "remain in business."
Remember, it will be dangerous for the next 20,000 years. It's not up to us to tell our great-great-grandchildren to stand guard over our poopy diapers. No civilization has ever lasted on a time scale like that, and it would be the ultimate in hubris to think we're somehow different. So guards will eventually fail. Monitors will stop being monitored. Buildings will crumble. Governments will collapse. We can't even hope to post a sign on the site that will last more than a few centuries, as our language may evolve beyond the point where that ancient writing hold any meaning to our grandkids.
The best we can hope for is to plant this stuff very deep in the earth, in a place where it can't be extracted without notice, and where future generations will probably never "bump into".
My first choice would be to use the deep well drilling techniques used by the petroleum industry, and inject the stuff a kilometer or more down into some very stable layers. But drilling rigs are only a few inches in diameter, and the storage requirements are vast. Some of the liquid waste (such as what is being held at Hanford) could be pumped down those holes. But spent fuel rods wouldn't fit as-is, and I don't know if it can be adequately liquified to pump down there. Yucca Mountain still seems like a not-bad choice, since we have to deal with this crap anyway.
First, spent nuclear fuel is extremely heavy -- uranium is more dense than lead. Next, you can't just launch it into orbit. Orbits decay over time, and this isn't something you want coming back as a giant asteroid of doom. So you actually have to get it to the sun for proper disposal. Low Earth Orbit launchers (such as the space shuttle, or the Atlas series of rockets) are inadequate to the task. It will require rockets the size of the old Saturn launchers to boost this material to the sun. So the cost will be enormous -- I think a billion dollars per ton is a conservative estimate.
The bigger problem is that rockets are far from perfect. Would you want to be anywhere on the planet if a Saturn V carrying six tons of depleted uranium exploded at 50 miles up? The waste would be dispersed across an area covering several states.
A space elevator might make space-based nuclear waste disposal a possibility, some day. But for now, rockets are not a viable disposal option.
I think they were 166 MHz. I don't know anything about any cache they may or may not have had.
After removal from the reactor, the spent fuel itself is temporarily stored in pools of water in concrete tanks, awaiting shipment to a final disposal site. Those temporary tanks are now full to capacity, and they are degrading quite rapidly (continual neutron bombardment is not healthy for things like concrete.)
All the power plant operators in the country are pretty much hoping that a national disposal site like Yucca Mountain will be opened to them soon for storing their spent fuel. But dealing with nuclear waste is quite literally a "hot" potato for any politican. Nobody wants to store it short term in their back yard, nobody wants to store it long term in their state, and the states in between the plants and the waste site don't even want the trains of waste to cross their state.
Yucca Mountain has long been talked about as a national disposal site, but the native Americans in the area are opposed to the idea. (They were once in favor of selling the site to the federal government, but have since changed their mind.) The proposal is to dig tunnels under the mountain, load in the waste, and backfill the tunnels with concrete.
There have been other interesting proposals to permanently store the waste. One is to bury it in the sea bottom, using drilling rigs similar to that used for off shore oil drilling. They'd plant the waste several hundred feet below the sea floor, and backfill them with the naturally present clay. Models show that the radiation would leach no further than a few dozen feet from each glass log, even after 20,000 years. But try to imagine the reaction when you tell the Greenpeace organization that you want to study planting radioactive waste under the ocean. Not a popular proposal.
Spent reactor fuel has a fairly long half life, and it will take 20,000 years for the radiation levels to drop to "safe" levels. Humans have never built a structure designed to last 20,000 years. Modern engineers realize they have no way to build anything that permanent; and even more so they know they cannot build a structure that would be able to withstand continual radiation for 20,000 years. The best they can hope for is to bury the waste deeply in an area that is as inaccessible as possible.
So, the "temporary" storage tanks remain full, and there are no current plans to empty them because there is no final disposal site. But there needs to be.