Scifi.com is also announcing today that Wonderfalls has been cancelled after only four episodes. The creators are hoping to find a way to eventually distribute the remaining eps.
Similarly, Century City (about a law firm set in 2030) was also cancelled this week after four episodes. It's getting to be a real sink or swim world.
Blocking port 25 is only a short term fix. There's no law that says email has to be sent on port 25. Wiith spammers increasingly using cracked PCs running SOCKS proxies and the like, these can be on any port whatsoever.
Spammers are quick to adopt countermeasures to simple technical efforts to thwart them. Anyone who receives email will have noticed how much the content of spam has changed in just the past year, in order to evade the new filtering technologies. The same thing will happen as port 25 blocking becomes widespread.
To put it into perspective, out of 1269 Bluetooth enabled phones detected, only 46 were vulnerable to the attack. And the manufacturers are upgrading the firmware so that newer models are immune.
Wouldn't it be more helpful, not to mention better motivation to purchase his own security toolkit...
Cryptlib is GPL'd, although you can buy a commercial license as well. But you don't have to pay anything if you are using it in a GPL project.
Another thing not noted in the review, the book is actually Peter's PhD thesis. It's pretty technical; I looked through a draft at a crypto conference. I don't think it would be of interest other than to the kind of person who might be wanting to implement a crypto library. Just my opinion.
What about the DMCA? Doesn't it make reverse engineering a patented process illegal?
No, you're wrong three ways. First, the DMCA says nothing about patents. Second, the DMCA criminalizes defeating measures that protect copyrights, which file sharing networks do not do. Third, and most surprising, the DMCA has an exemption for reverse engineering! That's right, the DMCA's treatment of reverse engineering is exactly the opposite of what most people think. It specifically says that defeating a copyright protection measure is legal if it is part of a reverse engineering effort aimed at creating a compatible product.
But that part's not even relevant here since KaZaa's technology cannot be reasonably construed as a copyright protection measure.
Ironically, the original goal of FreeS/WAN was not support of VPNs. It was to implement John "Suspected Terrorist" Gilmore's goal of "encrypting 5% of the Internet by Christmas". The idea was that if two systems went to talk to each other with an ordinary net connection, and both happened to be running FreeS/WAN or compatible software, they would automatically and transparently negotiate IPSec encryption and use that for the connection. This is what they called Opportunistic Encryption. The goal of the project was to get some substantial fraction of internet traffic to be encrypted by this mechanism, thereby increasing privacy and decreasing the effectiveness of net-wide surveillance and monitoring tools.
Sounds like a good idea to me. Are either of these new FreeS/WAN offshoots, or any other comparable project, trying to achieve Opportunistic Encryption? Or are they just for VPNs?
I'd like to tell people about this, but I don't want to sound too clueless. How do you pronounce CASSHERN? Is it Cass-Hern? Or Cash-Hern? Do they say it in the trailer? Does Japanese even use the SH sound?
It's not a robot if it's remote controlled. It's an RC toy. A robot should be autonomous and use AI to control itself. That's a totally different technological problem.
It won't be an issue until they find a Kuiper object that is bigger than Pluto. Then they'll have an awkward situation. Making Pluto a planet when this bigger object isn't one doesn't make sense; nobody wants to add a new planet, because in retrospect it was a mistake to make Pluto a planet, and adding another Kuiper object would just compound it; and removing Pluto from the list of planets offends tradition.
Everyone wants to push this off as long as possible, so if the new object is really smaller than Pluto, they'll breathe a sigh of relief and go on with things as they are.
Actually, DARPA did hold out tomorrow as an alternate date in case the event couldn't be held today. And I'll bet some of the teams would be up for it!
Team DAD has just gone Disabled (ie DQ'd) after sitting unmoving for at least an hour (some of that time in the DARPA-commanded PAUSE state).
Meanwhile Golem hasn't moved for 15 minutes. The Mindtel site shows it alternating between PAUSE and RUN but it ain't going nowhere. Maybe it and DAD had trouble recovering from the PAUSE command?
TerraMax is now the only other officially RUNNING team besides Golem, and it hasn't moved for an hour either. Looks like this may be as far as anyone's going to get, unless Golem wakes up.
oh boy, using your app is incredibly difficult in OSX. Where do I begin...
I agree 100%. I just went through all this, and it still didn't work. The QT window comes up, said Connecting for a few seconds, then says Ready, with an animating "Cylon/Knight Rider" bump moving back and forth. If I click the pause button it says "Live Broadcast - Paused" and then when I click Play it goes back to Ready.
I'm concerned that the spin on this event from much of the news media is negative. It's starting to look like DARPA will end up with egg on their face if none of the vehicles do well.
What these writers forget is that the event was intentionally designed to be incredibly difficult. In earlier news releases, the idea was expressed that this would be something that would be run every year until a robot manages to win it. This is in the spirit of other super-difficult prize competitions, like the X-Prize or the ancient quest to develop a method to compute the geographic longitude of a ship.
It's too bad that an inventive, flexible and interesting approach by DARPA is being spun as a failure just because the first tries haven't been all that successful. I'm really hoping that no teams win and that DARPA does run it again next year, because by then we'll have many more good contestants. This year's entries will have gotten the basic bugs out of their systems and be genuinely ready to tackle the course; and there will be a few new entrants as well, finishing up at the last minute and just hoping that they have something that will run. Each year will see improvement. To me that would be far more interesting and enlightening than a one shot deal.
I think this was the whole idea, DARPA wants to make sure they have some kind of "race" on their hands, not just one team putting along till the end.
Keep in mind that they're doing sequential starts. So it won't really be a race, just a long course with a few vehicles strung out one behind another. Far behind. And lots of disabled vehicles which have been shut down and pushed off the course (those few which even made it out of the starting gate).
DARPA is setting up a live update page where you'll be able to get a map of the course and watch in real time where the vehicles are during the race.
According to this schedule the first vehicle (which will be CMU's Sandstorm) is scheduled to depart at 6:15 AM PST on Saturday.
I wonder if the CMU vehicle really steered itself. Maybe their vaunted mapping team just scouted out the track on Monday, noted the locations of the obstacles, and designed a path for the vehicle that would go around everything. Could that have happened? You should ask them.
The Wired article was written on Tuesday night; the Caltech and Ohio State teams went ahead and qualified on Wednesday. At the time Wired was writing, it was correct that only one team had qualified. As of last night, three teams have done so. See the DARPA media page for updates on who has made it so far.
The Wired article also speculates that even teams which don't complete the qualifier will be allowed to try the race, but I haven't seen any confirmation of that on the DARPA site. Of course, if a robot can't make it through a one mile practice track, it's unlikely to get across 150 miles of desert. But letting them try would make for a more exciting race day.
Even with paper ballots, the poll workers could have given out the wrong ballot to the voters. It wouldn't have made a difference in the results.
Exactly. And paper would have been just as anonymous, too, so there would still have been no way to go back and try to guess which votes in a given precinct were valid and which were invalid. The whole paper-vs-evoting thing is a total red herring in this situation.
If we'd been using e-voting for a hundred years and only now were switching to paper, the volunteers manning these booths would have made just as many mistakes in the transition. Any time you have a new system, people have trouble adapting. Surely we have all seen examples of this in our own experiences. The fact that many poll workers are retirees makes it that much harder for them to learn new procedures.
I'm disappointed that there is not more information available about this event as it happens. I've been following it vicariously for months, and now I'd like to hear about what is happening at the speedway in Fontana. How many teams showed up? How many tried out today? Which passed, which failed? I haven't been able to find out any of that information.
The so-called Science Blog article was from February 10! That's not exactly timely, is it?
Nagle's later posting here does present some information about Caltech. The Caltech team web page provides the same basic info, with a little different spin. But I guess we're lucky they posted today; the previous entry on the team's news page was dated November 16, 2003.
CMU has been updating almost every day, but their last entry was Saturday, saying "The curtain goes up Monday morning". Again, what happened?
You'd think in this age of bloggers, when every windbag on the net sees fit to tell us what he had for lunch that day, someone would be watching this event and posting some updates in the evening. If this isn't happening, I beg anyone who is attending to step up and start writing! Maybe I'm spoiled by the usual instant access to information, but I'm passionately interested in this event and starving for news.
It was the inability to build the RAM-based directory structure of the files in the Flash memory.
Fine, but the point remains that it was a major screwup on NASA's part. They never communicated the fact that the memory-clearing download had failed and therefore the flash was still full of many more files (from the original launch OS image) than the rest of the team thought. That's why the flash was allowed to fill up (in terms of file count or data, it's not important). The engineers are very careful not to exceed the limits of their flash file system, but they were misinformed about what those limits were, since they had not been told that the erasure download had failed.
It was not Murphy's Law, it was not a fail to simulate or verify or test the software. It was a simple internal communications failure, where the right hand didn't know what the left hand was doing. The article lets NASA off too lightly by not emphasizing this failure (which is ultimately management's fault for not making sure that everyone on the team is aware of all crucial data).
Here's what happened according to the article. They launched the ship with an OS image in flash, and soon realized that they needed to update it. So shortly after launch they sent another complete OS image. They knew they'd have to delete the first image, but they didn't do it right away. At that point there was plenty of room in the flash memory so having two OS images was not a problem.
After a few days on Mars, they were starting to fill up the flash, so they planned to go ahead and delete the old launch OS image, its directories and files. This is a complicated process so they uploaded a special program to do it on Sol 15. And apparently they informed the rest of the team that the memory would be free and available after that point, so the rest of the team made plans to start filling it up with pictures.
However, the upload on sol 15 failed, and was rescheduled for sol 19. Now, here's the big mistake (which the article glosses over): They forgot to tell the rest of the team that all that memory wasn't going to be freed up as planned, not for a few more days. So instead, Spirit is moving around now, taking lots of pictures, storing them in flash, and all the people involved with that think they have plenty of room. Little do they know that they are running out of flash space. Finally, the morning of Sol 19, shortly before the memory cleaning program was going to be sent down, it happened. The flash memory was exhausted. This triggered a sequence of events which put the craft into a failure loop.
The big problem here, then, was the failure on the part of the group which was supposed to clean out the launch OS image to tell the rest of the team that it wasn't going to happen as scheduled, so the memory wasn't going to be available. It wasn't really Murphy's Law, but rather a failure to communicate among the team. This is an institutional problem which will hopefully be fixed.
Barr writes, in his article, "The United States position, formed at the behest of the Business Software Alliance, CompTIA, and other organizations dedicated to maintaining the status quo and curtailing the growth of free software, is that no software development methodology -- closed and proprietary versus open source -- be recommended over any other."
And later, "Shipman told me, 'The U.S. view is that we don't want to see government, or in this case, the World Summit, advocate one type of software over another.'"
In other words, the U.S. is being even-handed and supporting both closed and open source equally. But the tone of the whole article is that the Americans are anti-open-source and are pushing proprietary solutions. How is that consistent with these quotes?
How quickly we forget the history. I guess we remember what we want to believe rather than the truth.
First, the truth is that CSS was not reverse engineered, rediscovered, or reimplemented in a legal way. It was leaked. The Xing DVD player failed to implement its contractual obligation to obfuscate the CSS algorithm and key. This failure played a crucial role in the public discovery and publication of this information. It was Xing's failure to guard the trade secret information that allowed it to leak out and led to DeCSS.
Second, the algorithm was not broken by a teenager. Rather, once it was extracted from Xing's software, professional cryptographers were able to identify weaknesses in CSS that let disks be played even without a player key. Some cryptographers have opined that it might have been possible to break the algorithm even without access to the trade-secret source code. But this opinion comes with 20-20 hindsight. It is absolutely the case that no one broke CSS before the source code was published, despite claims that it was absurdly weak.
To me, this report doesn't really make sense. The current policy is that the shuttle will always go to the space station. There it will be inspected to make sure that the tiles are good before it goes back for reentry. Such an inspection would have detected the Columbia problem. Then in the unlikely case that there is damage, the crew could stay at the station on an emergency basis while another shuttle is launched.
No such actions are possible on a mission to the Hubble. Because of the orbital parameters, it is impossible for the shuttle to be able to go to both places on one mission. So any inspection, repair or wait-for-rescue would have to occur right there at the telescope.
Now, the report claims that NASA plans "eventually" to create additional facilities for these operations, other than at the space station. But that's obviously going to take a great deal of time. For one thing, just consider building the docking mechanism to allow two shuttles to connect and transfer crews from one to the other. No such thing has ever been designed, while such facilities already exist at the space station. Plus, the space station has additional supplies and space to let the crew wait safely for rescue. And it can hold inspection and repair equipment.
So while NASA may eventually create off-station repair facilities, that won't happen for a long time. Their initial efforts will be very properly focused on getting these abilities set up at the space station itself. And that means that no such facilities can be available by 2006, when the mission to Hubble is needed.
While the precision of the grating is to within a few nanometers, the actual spacing is hundreds of nanometers, or equivalently, tenths of microns. That's not all that small compared to the.13 or.09 micron processes currently used in Pentium and other high end chips.
The key to the grating is not how fine it is, because it's not, but how accurate it is over such a large scale. It's not nanotech, but a very precise microtech.
Slashdot Mirror
Scifi.com is also announcing today that Wonderfalls has been cancelled after only four episodes. The creators are hoping to find a way to eventually distribute the remaining eps.
Similarly, Century City (about a law firm set in 2030) was also cancelled this week after four episodes. It's getting to be a real sink or swim world.
Blocking port 25 is only a short term fix. There's no law that says email has to be sent on port 25. Wiith spammers increasingly using cracked PCs running SOCKS proxies and the like, these can be on any port whatsoever.
Spammers are quick to adopt countermeasures to simple technical efforts to thwart them. Anyone who receives email will have noticed how much the content of spam has changed in just the past year, in order to evade the new filtering technologies. The same thing will happen as port 25 blocking becomes widespread.
To put it into perspective, out of 1269 Bluetooth enabled phones detected, only 46 were vulnerable to the attack. And the manufacturers are upgrading the firmware so that newer models are immune.
Wouldn't it be more helpful, not to mention better motivation to purchase his own security toolkit...
Cryptlib is GPL'd, although you can buy a commercial license as well. But you don't have to pay anything if you are using it in a GPL project.
Another thing not noted in the review, the book is actually Peter's PhD thesis. It's pretty technical; I looked through a draft at a crypto conference. I don't think it would be of interest other than to the kind of person who might be wanting to implement a crypto library. Just my opinion.
What about the DMCA? Doesn't it make reverse engineering a patented process illegal?
No, you're wrong three ways. First, the DMCA says nothing about patents. Second, the DMCA criminalizes defeating measures that protect copyrights, which file sharing networks do not do. Third, and most surprising, the DMCA has an exemption for reverse engineering! That's right, the DMCA's treatment of reverse engineering is exactly the opposite of what most people think. It specifically says that defeating a copyright protection measure is legal if it is part of a reverse engineering effort aimed at creating a compatible product.
But that part's not even relevant here since KaZaa's technology cannot be reasonably construed as a copyright protection measure.
Ironically, the original goal of FreeS/WAN was not support of VPNs. It was to implement John "Suspected Terrorist" Gilmore's goal of "encrypting 5% of the Internet by Christmas". The idea was that if two systems went to talk to each other with an ordinary net connection, and both happened to be running FreeS/WAN or compatible software, they would automatically and transparently negotiate IPSec encryption and use that for the connection. This is what they called Opportunistic Encryption. The goal of the project was to get some substantial fraction of internet traffic to be encrypted by this mechanism, thereby increasing privacy and decreasing the effectiveness of net-wide surveillance and monitoring tools.
Sounds like a good idea to me. Are either of these new FreeS/WAN offshoots, or any other comparable project, trying to achieve Opportunistic Encryption? Or are they just for VPNs?
I'd like to tell people about this, but I don't want to sound too clueless. How do you pronounce CASSHERN? Is it Cass-Hern? Or Cash-Hern? Do they say it in the trailer? Does Japanese even use the SH sound?
It's not a robot if it's remote controlled. It's an RC toy. A robot should be autonomous and use AI to control itself. That's a totally different technological problem.
It won't be an issue until they find a Kuiper object that is bigger than Pluto. Then they'll have an awkward situation. Making Pluto a planet when this bigger object isn't one doesn't make sense; nobody wants to add a new planet, because in retrospect it was a mistake to make Pluto a planet, and adding another Kuiper object would just compound it; and removing Pluto from the list of planets offends tradition.
Everyone wants to push this off as long as possible, so if the new object is really smaller than Pluto, they'll breathe a sigh of relief and go on with things as they are.
That was so much fun...
Let's do it again tomorrow!
Actually, DARPA did hold out tomorrow as an alternate date in case the event couldn't be held today. And I'll bet some of the teams would be up for it!
Team DAD has just gone Disabled (ie DQ'd) after sitting unmoving for at least an hour (some of that time in the DARPA-commanded PAUSE state).
Meanwhile Golem hasn't moved for 15 minutes. The Mindtel site shows it alternating between PAUSE and RUN but it ain't going nowhere. Maybe it and DAD had trouble recovering from the PAUSE command?
TerraMax is now the only other officially RUNNING team besides Golem, and it hasn't moved for an hour either. Looks like this may be as far as anyone's going to get, unless Golem wakes up.
oh boy, using your app is incredibly difficult in OSX. Where do I begin...
I agree 100%. I just went through all this, and it still didn't work. The QT window comes up, said Connecting for a few seconds, then says Ready, with an animating "Cylon/Knight Rider" bump moving back and forth. If I click the pause button it says "Live Broadcast - Paused" and then when I click Play it goes back to Ready.
Is anyone successfully watching this broadcast?
I'm concerned that the spin on this event from much of the news media is negative. It's starting to look like DARPA will end up with egg on their face if none of the vehicles do well.
What these writers forget is that the event was intentionally designed to be incredibly difficult. In earlier news releases, the idea was expressed that this would be something that would be run every year until a robot manages to win it. This is in the spirit of other super-difficult prize competitions, like the X-Prize or the ancient quest to develop a method to compute the geographic longitude of a ship.
It's too bad that an inventive, flexible and interesting approach by DARPA is being spun as a failure just because the first tries haven't been all that successful. I'm really hoping that no teams win and that DARPA does run it again next year, because by then we'll have many more good contestants. This year's entries will have gotten the basic bugs out of their systems and be genuinely ready to tackle the course; and there will be a few new entrants as well, finishing up at the last minute and just hoping that they have something that will run. Each year will see improvement. To me that would be far more interesting and enlightening than a one shot deal.
I think this was the whole idea, DARPA wants to make sure they have some kind of "race" on their hands, not just one team putting along till the end.
Keep in mind that they're doing sequential starts. So it won't really be a race, just a long course with a few vehicles strung out one behind another. Far behind. And lots of disabled vehicles which have been shut down and pushed off the course (those few which even made it out of the starting gate).
DARPA is setting up a live update page where you'll be able to get a map of the course and watch in real time where the vehicles are during the race.
According to this schedule the first vehicle (which will be CMU's Sandstorm) is scheduled to depart at 6:15 AM PST on Saturday.
Only CMU is doing well.
I wonder if the CMU vehicle really steered itself. Maybe their vaunted mapping team just scouted out the track on Monday, noted the locations of the obstacles, and designed a path for the vehicle that would go around everything. Could that have happened? You should ask them.
The Wired article was written on Tuesday night; the Caltech and Ohio State teams went ahead and qualified on Wednesday. At the time Wired was writing, it was correct that only one team had qualified. As of last night, three teams have done so. See the DARPA media page for updates on who has made it so far.
The Wired article also speculates that even teams which don't complete the qualifier will be allowed to try the race, but I haven't seen any confirmation of that on the DARPA site. Of course, if a robot can't make it through a one mile practice track, it's unlikely to get across 150 miles of desert. But letting them try would make for a more exciting race day.
I run one of the Grand Challenge teams, Team Overbot...
6 386 from March 8 and http://slashdot.org/comments.pl?sid=83384&cid=7297 464 from October 23. The actual author is John Nagle, aka Animats. Please mod it down (and then you can mod this down too.)
This is a karma troll; it's been reposted every time we discuss this race. See http://slashdot.org/comments.pl?sid=99774&cid=850
Even with paper ballots, the poll workers could have given out the wrong ballot to the voters. It wouldn't have made a difference in the results.
Exactly. And paper would have been just as anonymous, too, so there would still have been no way to go back and try to guess which votes in a given precinct were valid and which were invalid. The whole paper-vs-evoting thing is a total red herring in this situation.
If we'd been using e-voting for a hundred years and only now were switching to paper, the volunteers manning these booths would have made just as many mistakes in the transition. Any time you have a new system, people have trouble adapting. Surely we have all seen examples of this in our own experiences. The fact that many poll workers are retirees makes it that much harder for them to learn new procedures.
I'm disappointed that there is not more information available about this event as it happens. I've been following it vicariously for months, and now I'd like to hear about what is happening at the speedway in Fontana. How many teams showed up? How many tried out today? Which passed, which failed? I haven't been able to find out any of that information.
The so-called Science Blog article was from February 10! That's not exactly timely, is it?
Nagle's later posting here does present some information about Caltech. The Caltech team web page provides the same basic info, with a little different spin. But I guess we're lucky they posted today; the previous entry on the team's news page was dated November 16, 2003.
CMU has been updating almost every day, but their last entry was Saturday, saying "The curtain goes up Monday morning". Again, what happened?
You'd think in this age of bloggers, when every windbag on the net sees fit to tell us what he had for lunch that day, someone would be watching this event and posting some updates in the evening. If this isn't happening, I beg anyone who is attending to step up and start writing! Maybe I'm spoiled by the usual instant access to information, but I'm passionately interested in this event and starving for news.
It was the inability to build the RAM-based directory structure of the files in the Flash memory.
Fine, but the point remains that it was a major screwup on NASA's part. They never communicated the fact that the memory-clearing download had failed and therefore the flash was still full of many more files (from the original launch OS image) than the rest of the team thought. That's why the flash was allowed to fill up (in terms of file count or data, it's not important). The engineers are very careful not to exceed the limits of their flash file system, but they were misinformed about what those limits were, since they had not been told that the erasure download had failed.
It was not Murphy's Law, it was not a fail to simulate or verify or test the software. It was a simple internal communications failure, where the right hand didn't know what the left hand was doing. The article lets NASA off too lightly by not emphasizing this failure (which is ultimately management's fault for not making sure that everyone on the team is aware of all crucial data).
Here's what happened according to the article. They launched the ship with an OS image in flash, and soon realized that they needed to update it. So shortly after launch they sent another complete OS image. They knew they'd have to delete the first image, but they didn't do it right away. At that point there was plenty of room in the flash memory so having two OS images was not a problem.
After a few days on Mars, they were starting to fill up the flash, so they planned to go ahead and delete the old launch OS image, its directories and files. This is a complicated process so they uploaded a special program to do it on Sol 15. And apparently they informed the rest of the team that the memory would be free and available after that point, so the rest of the team made plans to start filling it up with pictures.
However, the upload on sol 15 failed, and was rescheduled for sol 19. Now, here's the big mistake (which the article glosses over): They forgot to tell the rest of the team that all that memory wasn't going to be freed up as planned, not for a few more days. So instead, Spirit is moving around now, taking lots of pictures, storing them in flash, and all the people involved with that think they have plenty of room. Little do they know that they are running out of flash space. Finally, the morning of Sol 19, shortly before the memory cleaning program was going to be sent down, it happened. The flash memory was exhausted. This triggered a sequence of events which put the craft into a failure loop.
The big problem here, then, was the failure on the part of the group which was supposed to clean out the launch OS image to tell the rest of the team that it wasn't going to happen as scheduled, so the memory wasn't going to be available. It wasn't really Murphy's Law, but rather a failure to communicate among the team. This is an institutional problem which will hopefully be fixed.
Barr writes, in his article, "The United States position, formed at the behest of the Business Software Alliance, CompTIA, and other organizations dedicated to maintaining the status quo and curtailing the growth of free software, is that no software development methodology -- closed and proprietary versus open source -- be recommended over any other."
And later, "Shipman told me, 'The U.S. view is that we don't want to see government, or in this case, the World Summit, advocate one type of software over another.'"
In other words, the U.S. is being even-handed and supporting both closed and open source equally. But the tone of the whole article is that the Americans are anti-open-source and are pushing proprietary solutions. How is that consistent with these quotes?
How quickly we forget the history. I guess we remember what we want to believe rather than the truth.
First, the truth is that CSS was not reverse engineered, rediscovered, or reimplemented in a legal way. It was leaked. The Xing DVD player failed to implement its contractual obligation to obfuscate the CSS algorithm and key. This failure played a crucial role in the public discovery and publication of this information. It was Xing's failure to guard the trade secret information that allowed it to leak out and led to DeCSS.
Second, the algorithm was not broken by a teenager. Rather, once it was extracted from Xing's software, professional cryptographers were able to identify weaknesses in CSS that let disks be played even without a player key. Some cryptographers have opined that it might have been possible to break the algorithm even without access to the trade-secret source code. But this opinion comes with 20-20 hindsight. It is absolutely the case that no one broke CSS before the source code was published, despite claims that it was absurdly weak.
To me, this report doesn't really make sense. The current policy is that the shuttle will always go to the space station. There it will be inspected to make sure that the tiles are good before it goes back for reentry. Such an inspection would have detected the Columbia problem. Then in the unlikely case that there is damage, the crew could stay at the station on an emergency basis while another shuttle is launched.
No such actions are possible on a mission to the Hubble. Because of the orbital parameters, it is impossible for the shuttle to be able to go to both places on one mission. So any inspection, repair or wait-for-rescue would have to occur right there at the telescope.
Now, the report claims that NASA plans "eventually" to create additional facilities for these operations, other than at the space station. But that's obviously going to take a great deal of time. For one thing, just consider building the docking mechanism to allow two shuttles to connect and transfer crews from one to the other. No such thing has ever been designed, while such facilities already exist at the space station. Plus, the space station has additional supplies and space to let the crew wait safely for rescue. And it can hold inspection and repair equipment.
So while NASA may eventually create off-station repair facilities, that won't happen for a long time. Their initial efforts will be very properly focused on getting these abilities set up at the space station itself. And that means that no such facilities can be available by 2006, when the mission to Hubble is needed.
While the precision of the grating is to within a few nanometers, the actual spacing is hundreds of nanometers, or equivalently, tenths of microns. That's not all that small compared to the .13 or .09 micron processes currently used in Pentium and other high end chips.
The key to the grating is not how fine it is, because it's not, but how accurate it is over such a large scale. It's not nanotech, but a very precise microtech.