Black Holes radiate at least Hawking Radiation and that radiation is supposed to reflect the information inside the Black Hole (and thus the information of some photon or other).
Personally, I'd have thought it better to be able to daemonize a Java applet and have it be able to feed commands to Javascript. Reason being is that Java already supports sockets, both Java and Javascript are already in use, and protocols are better if not weighed down. You could do a lot more with a Java controller sitting on the webpage, new methods inevitably create new vulnerabilities, and those programmers able to use communications safely already know Java sockets whereas they don't know WebSockets.
For IPv0, you might have a case, as that was back in the DARPA days. IPv4 was intended to be a bit more flexible (and the networks in the US were mostly run by NSF by then, IPSS ran most of the connections elsewhere) and IPv6 is definitely post-DARPA.
For all that I disagree, I think the insults and troll mods are unreasonable. You were pointing out (quite reasonably and correctly) that there's quite a lot that has been used for things beyond the original purpose/intent. Your example was perhaps not the best and maybe you were a little too terse, but it's extremely hard to call what you said trolling.
I guess the first question is whether something can be truly opaque (zero light travels through) or whether all things are translucent if you've a sensitive enough detector.
Assuming that there are genuinely opaque objects, are there enough objects that are translucent (though not to the unaided eye) to make this technique interesting?
My guess is that almost everything will be translucent, though not everything. If the gaps between atoms is on the scale of the wavelength of light, then the atoms will act as a diffraction grating. Given the number of such gratings light has to pass through for any meaningful object, that's going to make a serious mess of the observations.
In order to be truly opaque, two criteria must be met - every photon has to intersect a particle and for every such intersection, the particle has to be able to absorb the photon. Since matter is mostly empty space, you'd need an awful lot of particles to absorb all photons. However, I can see no obvious reason why it would be impossible to have such an arrangement.
I did not say the Dutch did not write the virus, I said I was confident they weren't the target of it. Veeeery different things. If you want to critique my views, that's great and I learn a lot from people doing so. But it isn't terribly useful when you don't first read what it is you critique.
If an ISP is using per-flow UDP-aqare QoS, no flow can exceed the bandwidth allocated. True, this wouldn't stop an attack based on draining CPU cycles, but it would stop any attack based on network flooding.
If voting software on the host computer specifically filed the RSVP request (so the user has to do nothing and the user is aware of nothing - which is, sadly, likely the case anyway), then host-based resource allocation would not be an issue. Alternatively, let us say that the voting software mandates a permanent IP address that is also registered with the voting authority. Then the voting server can file the RSVP request when voting starts and terminate it when the vote is received or when voting ends.
I do NOT advocate any kind of voting from a dynamic IP address or from anywhere. Nor do I advocate a pure web-based voting system. They are not secure and there is essentially no authentication you can do that can truly prove the voter is who they say they are. (A home browser can have client-side digital certificates, for example, but you could not do that with a library computer. You can have the user install additional software to deal with spyware, keyloggers and rootkits - at home. Users couldn't do that at an Internet Cafe. The user can install the necessary RSVP or MPLS driver on their own machine and, provided the upstream ISP honored those protocols, the bandwidth reservation would be totally assured. Public WiFi links are most unlikely to support these.)
I would not consider electronic voting to be comparable to mail-in votes. (I regard mail-in voting as an evil that is only necessary because good electronic voting doesn't exist yet.) I consider electronic voting as being closer to an electronic version of a physical ballot box in an authorized location with all of the security and checks that are involved. Actually, because two-way authentication can take place efficiently electronically, it can have far more checks and be far more secure. At worst, though, it should be no worse than the physical system it is intended to be a substitute for.
To me, this is the biggest problem facing secure electronic voting systems - most of the systems in place (such as Diebold) or being developed are horribly fragile and/or insecure. They are barely adequate as a substitute for postal votes, and then only because the post is so vulnerable. That simply should not be considered as "good enough". As a nation becomes more dependent on electronic information over physical information, it is vital that the electronic information should become more reliable, not less, than the system it replaces. The moment "good enough" fails even to meet the previously-held standards is the moment you codify decline. When one technology replaces another, "good enough" should not only exceed the previous standards, it should exceed them by more than the previous standards with the old technology could have been updated through natural development.
Yes, yes, early versions are never going to be "good enough" according to such a standard. That's why we have prototypes, development cycles and the like. In software, this can be minimized by having competently-written specifications and proper testing. (Extreme Programming, where the tests are written first, is the ultimate form of Software Engineering.) You can use Release-Early, Release-Often (RERO) with Extreme Programming, because properly-modular software lets you release modules independent of one another. But you don't use a version on something mission-critical (such as a voting system in a Statewide or National election) until you're damn sure that the version is ready for mission-critical use.
Ok, in the case of the Diebold voting machines, they were barely ready for playtime voting, let alone anything serious. The use of them was a serious blunder that those in positions of authority had no business making as it was obvious they were not ready. I think that when it comes to ANY system that involves Government, each type of use should
Re:Never thought I would defend Iran, but...
on
Stuxnet Worms On
·
· Score: 1
The article on the Netherlands reports a satellite being knocked out of service. It may not be physical damage in the sense that you could go up there and hit the reboot switch, but short of a shuttle flight to rescue it, you can effectively consider that satellite to be destroyed. It's dead in space. Deceased. Bereft of life. Since it was probably a communications satellite, and thus a repeater, it's an ex-parrot.
Those marking me "troll" for having said earlier that other, definitely and unquestionably innocent, victims could happen, and then marked me "troll" for noting that the protections against such accidents didn't mean they wouldn't happen anyway, will doubtless ignore the fact that the Dutch are (a) not Iranian nuclear weapons scientists, and (b) that the only Iranian victims so far have been moderates who might have kept the program somewhat sane have now been arrested as spies. Iran is not known for treating those they suspect of spying very nicely.
It is indeed unclear who the worm was aimed at, but I'm confident that it wasn't the Dutch and I'm now more certain than ever that other innocent victims will turn up. We have proof now that the safeguards (however well-intentioned) did not work. Which is no great surprise - it's hard to have a failsafe weapon as there are so few scenarios in which you need a weapon that badly and have it be safe if it fails.
Not necessarily. It should be possible to devise an online voting system that worked securely and reliably. To defeat DoS/DDoS attacks, you would probably want to have virtual circuits (eg: MPLS) or bandwidth allocation (eg: RSVP) such that an attack cannot encroach on the voter's bandwidth. Alternatively, an ISP could run Snort or another NIDS system in such a manner as to detect a DDoS attack and block the source addresses. So long as it was done far enough upsteam that there was still available bandwidth, this would prevent an attack. Or they could use a packet-dropping scheme that is designed to handle "unresponsive flows" such as UDP and ICMP.
In the case of RSVP, there would be a certain bandwidth reservation (via UDP) between the client and the central server. This bandwidth is guaranteed by the protocol and the routers enforce this. Because it uses UDP, you have to then use a layer on top of that to provide the reliability. There are plenty of file-transfer protocols using UDP that have such layers, so the code is out there.
However, ALL of this requires cooperation by ISPs at one level or another. In other words, the ISP would need to be certified as capable of guaranteeing vote delivery in order to provide any kind of guarantee. This could be done. The ISPs won't like it, but it could be done.
If those awarding the Ig Nobels are themselves Nobel Prize Winners, if he wins another can he present the prize to himself? (Answers c/o Schrodinger's cat, P.O. Box 666.)
Seriously, graphene was a fascinating discovery - doubly so given the simplicity of its discovery. Anyone could have used pencil lead and sellotape, the way these guys did, to create graphene - and may well have done. The only real difference is these guys wondered what they had and took a look. (There have been many discoveries over time like that. I'm beginning to realize just how much genius depends on asking questions others could have - perhaps should have - asked but didn't.)
Problems with the best-known alternative to silicon (gallium arsenide) include that it's expensive, extremely toxic to make, result in much smaller wafers and have a much lower yield if you even get that far. It's also not very good at CMOS-style logic. However, silicon is already pushing the limits of what it can do so if you want faster computers, you have to have a good alternative lined up. Graphene may be a good option here, once it matures. Carbon is plentiful, there's no reason to believe the production of graphene will turn out to be hazardous, graphene transistors can be made to be faster than silicon ones and the IBM successfully used silicon fab tech to made it. What is not known is how to make anything complex or how it'll perform under such conditions.
One area that GaAs is major is the aerospace industry. GaAs is much more radiation-resistant than silicon, which means you don't have to do mind-boggling contortions in the circuitry or add in lead shielding (both techniques are used, although the shielding seems to only be used by a handful of companies, the rest opt for circuits from hell). I can find no information on how radiation-resistant graphene would be, but at a glance I would imagine it to be at least as good as silicon, maybe slightly better. It may displace silicon in the aerospace markets, then, but probably not GaAs unless it's a lot better than I'm thinking.
Since graphene has other properties that may be valuable (unusual strength for something one atom thick, interesting optical properties, weird magnetic properties, etc), it would not surprise me if it ends up being used in other industries for things that have no bearing on its semiconductor nature. It might be fun to speculate who can really exploit graphene in any practical way first.
I've mentioned them above, but you can do damn-near anything that Windows can do via either LinuxConf (for older distros) or Webmin/Usermin. (The option for file paths is in Usermin under "Operating System and Environment" and, frankly, I consider it infinitely superior to the way Windows displays the path.)
Yes, these are not "standard". Almost nothing in Linux is "standard" and that is a Good Thing. It allows you to have the system set up to match how you think rather than force how you think to match the system.
That would be one option. Another would be to be able to drive the GUI from a script (test systems such as Silk and Selenium already do this). Provided standard options were accessed in a standard way, there is nothing to stop you from driving things from this direction. Alternatively, have a configuration server that applications installed plug-ins for. The configuration server can then abstract out the nuances. You then feed it a script in the server's language and it takes care of the configuration details.
(This is where LinuxConf and Webmin fell down - they didn't really abstract out a whole lot and didn't allow this kind of autoconfiguring. Great tools for those scared of raw textfiles, though. I convinced more than a few Windows users that Linux wasn't this Big Bad Scary Monster with them.)
It looks like the kid got lucky - some doctors are willing to try highly experimental (and/or totally "unapproved") techniques that give the patient better odds of surviving in the medium term than doing nothing, even if it carries a higher risk of the patient dying in the short term. When you're faced with pretty-much certain death in the short term anyway, a little extra risk isn't much compared to the potential benefits.
As for mortality, the mortality for even ideal heart transplant patients isn't great. Still miles better than no transplant or artificial heart at all, sure, but it needs work. (Which it is getting. In the early days, survival for any such procedure was measured in months.)
Anyone upgrading (downgrading?) to Vista is a fool. Windows 7 is passable, but given that Windows 8 was announced a week or so before Windows 7 hit the shelves, even Microsoft looked at it as a stop-gap.
I would have thought that the key part of the Act was not the "commercial interest" but the fact that it requires that said interests be damaged by a competitor.
In this case, it is most unlikely Yahoo! is a competitor in the baby seal rescuing market. And to judge by past performance, it's hard to describe them as much of a competitor at all.
The advantage of that approach is that charities are quite significant businesses and those who are, in effect, charity celebrities have market value by right of being celebrities. That leaves the door open for an appeal and lawyers getting richer for no obvious benefit to anyone.
It is entirely in-line with the discovery of the Norwegian Blue parrot which was, indeed, dead. Very. Though nailing a fossil to the perch might have been difficult.
Excellent points, and you are quite right. Most of this is indeed stuff engineering solved in the middle ages - and software engineers re-solved (because they forgot) in the 80s. There is little excuse for economists not following suit.
Pfffft. There are attempts to build DeHavilland Mosquitos and nobody's quite sure if the blueprints still exist. Virtually everything has been reverse-engineered by the groups attempting this feat. (The specific technique used to triple-bind the various types of wood into a unified whole is bad enough - I couldn't tell you if even that knowledge still exists in its original form.)
There probably aren't that many innocent Iranians in the vicinity of Iranian reactors - at least in comparison to the number of innocent Britons living next to British nuclear reactors. The problem with the "innocent Iranians" argument is that there will be plenty of people who would argue that it was "for the greater good". On the other hand, an accident in Europe or America that was due to the virus is indisputably not for the "greater good". As I've said before, I have a serious problem with assassinations of any kind of anyone. I recognize that this opinion is not universally shared, so the logical thing to do is to look at whether this virus would potentially harm those whom all concerned would agree are not acceptable targets.
...was utterly unconcerned for any potential cost. Many countries use German-made equipment. A prior story covered an air crash in Spain caused by viruses on mission-critical computers, demonstrating that critical computers are poorly-secured. There are likely to be French and British nuclear reactors that use the specific machine targeted. The "collateral damage" could have been extensive. Whether the virus was written by a member of the security forces or a member of the general public, one single inadvertent contamination of the wrong machine could have cause a gigantic nuclear accident in some of the most densely-populated parts of Europe.
Is a temporary setback for Iran worth putting millions of European's live at risk over? (Yes, these countries ARE densely-populated. Britain isn't that much larger than Rhode Island but has over a quarter of the population of the entire United States. You don't need a hell of a lot to put a great many people in serious danger.)
As far as I am concerned, whoever wrote that virus is guilty of endangerment on a scale unimaginable by most people.
I'm not sure that the proposed solutions will fix the problem. I'd much rather a degradation in response times as a function of orders (so the more orders there are, the slower the system gets) rather than a temporary hold on that stock. Temporary holds assume that software won't do what it has always done in the past - try again until it gets through. If you flood the system with retries from enough computers, the results won't change. It will merely have short gaps in it. If you have gradual degradation, then flooding will slow things way down until the flood stops. The negative feedback loop will guarantee that a crash becomes impossible.
In fact, that is something the market could do with more of - negative feedback loops. It should be possible to prevent market bubbles as well as market bursts, as a bubble is just a positive feedback loop in the opposite direction.
Slashdot Mirror
Black Holes radiate at least Hawking Radiation and that radiation is supposed to reflect the information inside the Black Hole (and thus the information of some photon or other).
Personally, I'd have thought it better to be able to daemonize a Java applet and have it be able to feed commands to Javascript. Reason being is that Java already supports sockets, both Java and Javascript are already in use, and protocols are better if not weighed down. You could do a lot more with a Java controller sitting on the webpage, new methods inevitably create new vulnerabilities, and those programmers able to use communications safely already know Java sockets whereas they don't know WebSockets.
For IPv0, you might have a case, as that was back in the DARPA days. IPv4 was intended to be a bit more flexible (and the networks in the US were mostly run by NSF by then, IPSS ran most of the connections elsewhere) and IPv6 is definitely post-DARPA.
For all that I disagree, I think the insults and troll mods are unreasonable. You were pointing out (quite reasonably and correctly) that there's quite a lot that has been used for things beyond the original purpose/intent. Your example was perhaps not the best and maybe you were a little too terse, but it's extremely hard to call what you said trolling.
I guess the first question is whether something can be truly opaque (zero light travels through) or whether all things are translucent if you've a sensitive enough detector.
Assuming that there are genuinely opaque objects, are there enough objects that are translucent (though not to the unaided eye) to make this technique interesting?
My guess is that almost everything will be translucent, though not everything. If the gaps between atoms is on the scale of the wavelength of light, then the atoms will act as a diffraction grating. Given the number of such gratings light has to pass through for any meaningful object, that's going to make a serious mess of the observations.
In order to be truly opaque, two criteria must be met - every photon has to intersect a particle and for every such intersection, the particle has to be able to absorb the photon. Since matter is mostly empty space, you'd need an awful lot of particles to absorb all photons. However, I can see no obvious reason why it would be impossible to have such an arrangement.
I did not say the Dutch did not write the virus, I said I was confident they weren't the target of it. Veeeery different things. If you want to critique my views, that's great and I learn a lot from people doing so. But it isn't terribly useful when you don't first read what it is you critique.
If an ISP is using per-flow UDP-aqare QoS, no flow can exceed the bandwidth allocated. True, this wouldn't stop an attack based on draining CPU cycles, but it would stop any attack based on network flooding.
If voting software on the host computer specifically filed the RSVP request (so the user has to do nothing and the user is aware of nothing - which is, sadly, likely the case anyway), then host-based resource allocation would not be an issue. Alternatively, let us say that the voting software mandates a permanent IP address that is also registered with the voting authority. Then the voting server can file the RSVP request when voting starts and terminate it when the vote is received or when voting ends.
I do NOT advocate any kind of voting from a dynamic IP address or from anywhere. Nor do I advocate a pure web-based voting system. They are not secure and there is essentially no authentication you can do that can truly prove the voter is who they say they are. (A home browser can have client-side digital certificates, for example, but you could not do that with a library computer. You can have the user install additional software to deal with spyware, keyloggers and rootkits - at home. Users couldn't do that at an Internet Cafe. The user can install the necessary RSVP or MPLS driver on their own machine and, provided the upstream ISP honored those protocols, the bandwidth reservation would be totally assured. Public WiFi links are most unlikely to support these.)
I would not consider electronic voting to be comparable to mail-in votes. (I regard mail-in voting as an evil that is only necessary because good electronic voting doesn't exist yet.) I consider electronic voting as being closer to an electronic version of a physical ballot box in an authorized location with all of the security and checks that are involved. Actually, because two-way authentication can take place efficiently electronically, it can have far more checks and be far more secure. At worst, though, it should be no worse than the physical system it is intended to be a substitute for.
To me, this is the biggest problem facing secure electronic voting systems - most of the systems in place (such as Diebold) or being developed are horribly fragile and/or insecure. They are barely adequate as a substitute for postal votes, and then only because the post is so vulnerable. That simply should not be considered as "good enough". As a nation becomes more dependent on electronic information over physical information, it is vital that the electronic information should become more reliable, not less, than the system it replaces. The moment "good enough" fails even to meet the previously-held standards is the moment you codify decline. When one technology replaces another, "good enough" should not only exceed the previous standards, it should exceed them by more than the previous standards with the old technology could have been updated through natural development.
Yes, yes, early versions are never going to be "good enough" according to such a standard. That's why we have prototypes, development cycles and the like. In software, this can be minimized by having competently-written specifications and proper testing. (Extreme Programming, where the tests are written first, is the ultimate form of Software Engineering.) You can use Release-Early, Release-Often (RERO) with Extreme Programming, because properly-modular software lets you release modules independent of one another. But you don't use a version on something mission-critical (such as a voting system in a Statewide or National election) until you're damn sure that the version is ready for mission-critical use.
Ok, in the case of the Diebold voting machines, they were barely ready for playtime voting, let alone anything serious. The use of them was a serious blunder that those in positions of authority had no business making as it was obvious they were not ready. I think that when it comes to ANY system that involves Government, each type of use should
The article on the Netherlands reports a satellite being knocked out of service. It may not be physical damage in the sense that you could go up there and hit the reboot switch, but short of a shuttle flight to rescue it, you can effectively consider that satellite to be destroyed. It's dead in space. Deceased. Bereft of life. Since it was probably a communications satellite, and thus a repeater, it's an ex-parrot.
Those marking me "troll" for having said earlier that other, definitely and unquestionably innocent, victims could happen, and then marked me "troll" for noting that the protections against such accidents didn't mean they wouldn't happen anyway, will doubtless ignore the fact that the Dutch are (a) not Iranian nuclear weapons scientists, and (b) that the only Iranian victims so far have been moderates who might have kept the program somewhat sane have now been arrested as spies. Iran is not known for treating those they suspect of spying very nicely.
It is indeed unclear who the worm was aimed at, but I'm confident that it wasn't the Dutch and I'm now more certain than ever that other innocent victims will turn up. We have proof now that the safeguards (however well-intentioned) did not work. Which is no great surprise - it's hard to have a failsafe weapon as there are so few scenarios in which you need a weapon that badly and have it be safe if it fails.
Not necessarily. It should be possible to devise an online voting system that worked securely and reliably. To defeat DoS/DDoS attacks, you would probably want to have virtual circuits (eg: MPLS) or bandwidth allocation (eg: RSVP) such that an attack cannot encroach on the voter's bandwidth. Alternatively, an ISP could run Snort or another NIDS system in such a manner as to detect a DDoS attack and block the source addresses. So long as it was done far enough upsteam that there was still available bandwidth, this would prevent an attack. Or they could use a packet-dropping scheme that is designed to handle "unresponsive flows" such as UDP and ICMP.
In the case of RSVP, there would be a certain bandwidth reservation (via UDP) between the client and the central server. This bandwidth is guaranteed by the protocol and the routers enforce this. Because it uses UDP, you have to then use a layer on top of that to provide the reliability. There are plenty of file-transfer protocols using UDP that have such layers, so the code is out there.
However, ALL of this requires cooperation by ISPs at one level or another. In other words, the ISP would need to be certified as capable of guaranteeing vote delivery in order to provide any kind of guarantee. This could be done. The ISPs won't like it, but it could be done.
If those awarding the Ig Nobels are themselves Nobel Prize Winners, if he wins another can he present the prize to himself? (Answers c/o Schrodinger's cat, P.O. Box 666.)
Seriously, graphene was a fascinating discovery - doubly so given the simplicity of its discovery. Anyone could have used pencil lead and sellotape, the way these guys did, to create graphene - and may well have done. The only real difference is these guys wondered what they had and took a look. (There have been many discoveries over time like that. I'm beginning to realize just how much genius depends on asking questions others could have - perhaps should have - asked but didn't.)
Problems with the best-known alternative to silicon (gallium arsenide) include that it's expensive, extremely toxic to make, result in much smaller wafers and have a much lower yield if you even get that far. It's also not very good at CMOS-style logic. However, silicon is already pushing the limits of what it can do so if you want faster computers, you have to have a good alternative lined up. Graphene may be a good option here, once it matures. Carbon is plentiful, there's no reason to believe the production of graphene will turn out to be hazardous, graphene transistors can be made to be faster than silicon ones and the IBM successfully used silicon fab tech to made it. What is not known is how to make anything complex or how it'll perform under such conditions.
One area that GaAs is major is the aerospace industry. GaAs is much more radiation-resistant than silicon, which means you don't have to do mind-boggling contortions in the circuitry or add in lead shielding (both techniques are used, although the shielding seems to only be used by a handful of companies, the rest opt for circuits from hell). I can find no information on how radiation-resistant graphene would be, but at a glance I would imagine it to be at least as good as silicon, maybe slightly better. It may displace silicon in the aerospace markets, then, but probably not GaAs unless it's a lot better than I'm thinking.
Since graphene has other properties that may be valuable (unusual strength for something one atom thick, interesting optical properties, weird magnetic properties, etc), it would not surprise me if it ends up being used in other industries for things that have no bearing on its semiconductor nature. It might be fun to speculate who can really exploit graphene in any practical way first.
I've mentioned them above, but you can do damn-near anything that Windows can do via either LinuxConf (for older distros) or Webmin/Usermin. (The option for file paths is in Usermin under "Operating System and Environment" and, frankly, I consider it infinitely superior to the way Windows displays the path.)
Yes, these are not "standard". Almost nothing in Linux is "standard" and that is a Good Thing. It allows you to have the system set up to match how you think rather than force how you think to match the system.
That would be one option. Another would be to be able to drive the GUI from a script (test systems such as Silk and Selenium already do this). Provided standard options were accessed in a standard way, there is nothing to stop you from driving things from this direction. Alternatively, have a configuration server that applications installed plug-ins for. The configuration server can then abstract out the nuances. You then feed it a script in the server's language and it takes care of the configuration details.
(This is where LinuxConf and Webmin fell down - they didn't really abstract out a whole lot and didn't allow this kind of autoconfiguring. Great tools for those scared of raw textfiles, though. I convinced more than a few Windows users that Linux wasn't this Big Bad Scary Monster with them.)
It looks like the kid got lucky - some doctors are willing to try highly experimental (and/or totally "unapproved") techniques that give the patient better odds of surviving in the medium term than doing nothing, even if it carries a higher risk of the patient dying in the short term. When you're faced with pretty-much certain death in the short term anyway, a little extra risk isn't much compared to the potential benefits.
As for mortality, the mortality for even ideal heart transplant patients isn't great. Still miles better than no transplant or artificial heart at all, sure, but it needs work. (Which it is getting. In the early days, survival for any such procedure was measured in months.)
Anyone upgrading (downgrading?) to Vista is a fool. Windows 7 is passable, but given that Windows 8 was announced a week or so before Windows 7 hit the shelves, even Microsoft looked at it as a stop-gap.
I would have thought that the key part of the Act was not the "commercial interest" but the fact that it requires that said interests be damaged by a competitor.
In this case, it is most unlikely Yahoo! is a competitor in the baby seal rescuing market. And to judge by past performance, it's hard to describe them as much of a competitor at all.
The advantage of that approach is that charities are quite significant businesses and those who are, in effect, charity celebrities have market value by right of being celebrities. That leaves the door open for an appeal and lawyers getting richer for no obvious benefit to anyone.
And money. Rights and money. And soda machines.
It is entirely in-line with the discovery of the Norwegian Blue parrot which was, indeed, dead. Very. Though nailing a fossil to the perch might have been difficult.
You'll need to ask Agent Perry.
Excellent points, and you are quite right. Most of this is indeed stuff engineering solved in the middle ages - and software engineers re-solved (because they forgot) in the 80s. There is little excuse for economists not following suit.
Now that is a post well-worth the +5 rating.
The Internet Worm was programmed to not spread. Being programmed != being programmed correctly.
Pfffft. There are attempts to build DeHavilland Mosquitos and nobody's quite sure if the blueprints still exist. Virtually everything has been reverse-engineered by the groups attempting this feat. (The specific technique used to triple-bind the various types of wood into a unified whole is bad enough - I couldn't tell you if even that knowledge still exists in its original form.)
There probably aren't that many innocent Iranians in the vicinity of Iranian reactors - at least in comparison to the number of innocent Britons living next to British nuclear reactors. The problem with the "innocent Iranians" argument is that there will be plenty of people who would argue that it was "for the greater good". On the other hand, an accident in Europe or America that was due to the virus is indisputably not for the "greater good". As I've said before, I have a serious problem with assassinations of any kind of anyone. I recognize that this opinion is not universally shared, so the logical thing to do is to look at whether this virus would potentially harm those whom all concerned would agree are not acceptable targets.
...was utterly unconcerned for any potential cost. Many countries use German-made equipment. A prior story covered an air crash in Spain caused by viruses on mission-critical computers, demonstrating that critical computers are poorly-secured. There are likely to be French and British nuclear reactors that use the specific machine targeted. The "collateral damage" could have been extensive. Whether the virus was written by a member of the security forces or a member of the general public, one single inadvertent contamination of the wrong machine could have cause a gigantic nuclear accident in some of the most densely-populated parts of Europe.
Is a temporary setback for Iran worth putting millions of European's live at risk over? (Yes, these countries ARE densely-populated. Britain isn't that much larger than Rhode Island but has over a quarter of the population of the entire United States. You don't need a hell of a lot to put a great many people in serious danger.)
As far as I am concerned, whoever wrote that virus is guilty of endangerment on a scale unimaginable by most people.
I'm not sure that the proposed solutions will fix the problem. I'd much rather a degradation in response times as a function of orders (so the more orders there are, the slower the system gets) rather than a temporary hold on that stock. Temporary holds assume that software won't do what it has always done in the past - try again until it gets through. If you flood the system with retries from enough computers, the results won't change. It will merely have short gaps in it. If you have gradual degradation, then flooding will slow things way down until the flood stops. The negative feedback loop will guarantee that a crash becomes impossible.
In fact, that is something the market could do with more of - negative feedback loops. It should be possible to prevent market bubbles as well as market bursts, as a bubble is just a positive feedback loop in the opposite direction.