Folks, you are missing a major point: if the hack was originated from China, then the grunt of consequences will be on cleared Chinese Americans. You see, most of them still have family members back home thus they're incredibly exposed to manipulation. And U.S. is well aware of that. So government might start dropping those clearances - people's jobs will be in jeopardy.
... AMD has a chance for survival. I think.
Basically every few additional percentage points in performance cost untold billions in investment. Thus it is possible to tailgate market leader by producing something only a little bit slower by spending half the money. As long as performance/watt, performance/rack are not outrageously bad (so data centers will not shun you) AND Intel does not engage in monopolistic tactics (big question mark here) it's possible to make a decent living.
Simple - wolves are useful even in untamed form for defense: put one on a chain (well, rope) to growl at everybody approaching.
Then allow captive ones to breed because capture is labor intensive. Then ask your kids who are playing with pups which one to keep (cute, friendly and cuddly of course) ....and BAM! You've got a dog!
And that's the problem - they _were_ fun in Cryptonomicon. But not because of being tangents but because of being wonderfully geeky. Alas, Neal decided that the fun of side stories are side stories themselves - not their content. As a result - his later books can be cut to 1/3 and be a much better read.
I would recommend waiting for an abridged version. Otherwise most people will pull aloud WTF! and close the book for good while slogging through one of (_many_) extremely boring and only marginally related to the main story tangents.
Replying to myself: actually one can easily exploit embedded flash size limitation. Simply make new firmware huge and uncompressable. Attacker will ran out of place to hide (without creating timing side effects e.g. storing stuff on platters)
Actually, writing a verification firmware is possible (assuming, that it was written after attacking code was written and writer was not NSLed) Simply because attack code doesn't know what output verification code must produce. It either must execute new code (will be busted) or not (will be busted). Putting a full blown interpreter (or some trap mechanism on flash access) will screw timing - again it will be busted.
I think Apple's unwillingness to admit their bugs, dishonest reviewers and apple's fanboys happily squashing all discontent on message boards etc. combined creating a situation when people simply refuse to upgrade/patch their apple gear.
I mean look, when I first upgraded my perfectly nice iPad Air to iOS 8, it's Wi-Fi become practically unusable (had to reconnect every 5 minutes). Rendering iPad useless for several weeks. And it's not like I didn't check online reviews beforehand... None of them (sellouts!) mentioned this shit. Only _after_ I knew what's wrong with the update I was able to find those huge message board threads full of pissed-off users wenting.
Now, with the new update for iOS 8 I'm sitting this one out. Or at least waiting until other people upgraded and google got the message indexed so I can find it...
Interesting. But (I'm not an expert though) it might be that one cannot mothball those things for very long - you pump it or you lose it.
Additionally, even if it does not work for already producing assets, it as sure as hell will clamp down on new investments. And, maybe, that is just good enough of an outcome.
Interesting, how many times Saudis will have to spank new drillers so nobody will risk to make large investments into new wells any more. Unless some government intervenes with some kind of minimal price guarantee or something.
No, you simply didn't get the point. Google can't push the patch to those devices (unless they are from Nexus line). Samsung, LG, etc. must do the pushing. But they wont.
That was my point - this way you eat only one recursive call, not two. And in general case (or naive qsort implementation) one recursive call is enough to burn (on bad input) through all your allowed stack.
Interesting. But just as a side note: I thought that people generally stopped rolling their own linear algebra code and started to use precanned one from Intel,amd,nVidia etc. I'm sure matlab is that way.
Yes, but they are clever about what and when they put on that stack. In their case it's indeed no more than log base 2 frames (non overlapping intervals with biggest one larger than the rest combined with the "rest" following the same pattern)
Sure, but that would also mean that debug compiled code, optimized code, ported code - all would behave too differently. Which, again, not a sound engineering practice.
Very deterministic. Thus, easy to screw with. Just populate sample points with that worst case pivot value and voilà. Well... it needs to be done for all consecutive rounds so it's not completely trivial but doable.
If the algorithm is made very unlucky with selection of the pivot, then it will need one stack frame per each 2 data elements. So yeah, I think it's doable (if pivot selection is stupid in some predictable way)
WTF?! We're talking about general recursion, not some stupid, easily avoidable cases. Even in the case of qsort - you need to make 2 (not one) recursive calls one for left and one for right, and you need to keep the midpoint somewhere on the stack... Basically it's easier to roll your own, totally heap based accounting than try to be clever with stack frames. Plus GP explicitly said that there is recursion and your c compiler does not do tail recursion anyway (or you can't count on it)
Slashdot Mirror
Folks, you are missing a major point: if the hack was originated from China, then the grunt of consequences will be on cleared Chinese Americans. You see, most of them still have family members back home thus they're incredibly exposed to manipulation. And U.S. is well aware of that. So government might start dropping those clearances - people's jobs will be in jeopardy.
Only parts that are vital for the organism are preserved (more or less). Everything else is trashed or/and cut out completely.
... AMD has a chance for survival. I think.
Basically every few additional percentage points in performance cost untold billions in investment. Thus it is possible to tailgate market leader by producing something only a little bit slower by spending half the money. As long as performance/watt, performance/rack are not outrageously bad (so data centers will not shun you) AND Intel does not engage in monopolistic tactics (big question mark here) it's possible to make a decent living.
My understanding is that Microsoft is still fighting that one. Let's hope they will prevail.
Simple - wolves are useful even in untamed form for defense: put one on a chain (well, rope) to growl at everybody approaching. Then allow captive ones to breed because capture is labor intensive. Then ask your kids who are playing with pups which one to keep (cute, friendly and cuddly of course) . ...and BAM! You've got a dog!
Thus it would be a surprise if dog domestication happened only once.
Does it throttle under heavy use? My concern is that it's rather small and without heat sinks...
And that's the problem - they _were_ fun in Cryptonomicon. But not because of being tangents but because of being wonderfully geeky. Alas, Neal decided that the fun of side stories are side stories themselves - not their content. As a result - his later books can be cut to 1/3 and be a much better read.
I would recommend waiting for an abridged version. Otherwise most people will pull aloud WTF! and close the book for good while slogging through one of (_many_) extremely boring and only marginally related to the main story tangents.
Replying to myself: actually one can easily exploit embedded flash size limitation. Simply make new firmware huge and uncompressable. Attacker will ran out of place to hide (without creating timing side effects e.g. storing stuff on platters)
Actually, writing a verification firmware is possible (assuming, that it was written after attacking code was written and writer was not NSLed)
Simply because attack code doesn't know what output verification code must produce. It either must execute new code (will be busted) or not (will be busted). Putting a full blown interpreter (or some trap mechanism on flash access) will screw timing - again it will be busted.
I think Apple's unwillingness to admit their bugs, dishonest reviewers and apple's fanboys happily squashing all discontent on message boards etc. combined creating a situation when people simply refuse to upgrade/patch their apple gear.
I mean look, when I first upgraded my perfectly nice iPad Air to iOS 8, it's Wi-Fi become practically unusable (had to reconnect every 5 minutes). Rendering iPad useless for several weeks. And it's not like I didn't check online reviews beforehand... None of them (sellouts!) mentioned this shit. Only _after_ I knew what's wrong with the update I was able to find those huge message board threads full of pissed-off users wenting.
Now, with the new update for iOS 8 I'm sitting this one out. Or at least waiting until other people upgraded and google got the message indexed so I can find it...
Interesting. But (I'm not an expert though) it might be that one cannot mothball those things for very long - you pump it or you lose it.
Additionally, even if it does not work for already producing assets, it as sure as hell will clamp down on new investments. And, maybe, that is just good enough of an outcome.
Interesting, how many times Saudis will have to spank new drillers so nobody will risk to make large investments into new wells any more. Unless some government intervenes with some kind of minimal price guarantee or something.
No, you simply didn't get the point. Google can't push the patch to those devices (unless they are from Nexus line). Samsung, LG, etc. must do the pushing. But they wont.
You are wrong. They don't want electric vehicles. And that simply because there is no money (or much, much less) in post sale maintenance.
That was my point - this way you eat only one recursive call, not two. And in general case (or naive qsort implementation) one recursive call is enough to burn (on bad input) through all your allowed stack.
Interesting. But just as a side note: I thought that people generally stopped rolling their own linear algebra code and started to use precanned one from Intel,amd,nVidia etc. I'm sure matlab is that way.
On stack size issue - the point was about a case of malicious/pathological input.
Yes, but they are clever about what and when they put on that stack. In their case it's indeed no more than log base 2 frames (non overlapping intervals with biggest one larger than the rest combined with the "rest" following the same pattern)
Sure, but that would also mean that debug compiled code, optimized code, ported code - all would behave too differently. Which, again, not a sound engineering practice.
I would guess that that "custom stack" lives in the heap, so in that case the limitation on program's stack size does not apply.
Very deterministic. Thus, easy to screw with. Just populate sample points with that worst case pivot value and voilà. Well... it needs to be done for all consecutive rounds so it's not completely trivial but doable.
If the algorithm is made very unlucky with selection of the pivot, then it will need one stack frame per each 2 data elements. So yeah, I think it's doable (if pivot selection is stupid in some predictable way)
WTF?! We're talking about general recursion, not some stupid, easily avoidable cases. Even in the case of qsort - you need to make 2 (not one) recursive calls one for left and one for right, and you need to keep the midpoint somewhere on the stack... Basically it's easier to roll your own, totally heap based accounting than try to be clever with stack frames. Plus GP explicitly said that there is recursion and your c compiler does not do tail recursion anyway (or you can't count on it)