Ok, I took at look here at the sort of data loss they work with. They mention logical failures and mechanical failures. They don't mention deliberate overwriting. Everything on this page discusses just how hard it is to find the bit you're looking for, and how Ontrack has all sorts of expertise in coaxing the drive to do what they asked to at least get something out of it.
So far I haven't seen anything to suggest they can recover deliberately overwritten data. In fact, their data analysis page says:
Although electronic evidence is especially fragile - prone to erasure, destruction and tampering
Everything on the site points to being able to recover files that are inaccessible either due to drive failure (including mechanical damage) or being deleted without being overwritten. If you can find somewhere where they claim that they can recover overwritten data (as opposed to merely inaccessible data), I'd love to see it. Otherwise, you haven't disproved the notion that recovering overwritten data on a modern drive is an urban legend.
Your comment made me chuckle, because I agree with it's intent wholeheartedly. "Rocket science" is the reference it is for a reason. Heck, the equations describing rocket flight aren't exactly basic algebra, even. If your burn rate is quick enough, both the mass and the mass distribution (center of gravity, moment of inertia) of the rocket will be changing fairly quickly as the rocket accelerates.
Right, because a swarm of mindless, vermin carrying and quickly multiplying rodents (rats in your cellar) is an accurate model of misdirected intellectual energy (someone figuring out how to break your security system in order to wipe your hard drives). So, yes, you should apply the same reasoning and same solutions to both.
Unfortunately, the rules for double extensions quickly become untenable. I see a lot of files with names like "Release plan for v2.3.doc". Is that a double extension? What about "Status report 10.5.09.doc?"
How does it become untenable? Windows already only hides extensions that it knows about, as opposed to "any string of characters after a period is an extension." If I name a file "Release plan for v2.3" without the.doc, it won't hide the ".3". So, only apply the double-extension rule to things with two or more recognized extensions.
If people have extensions hidden then seeing a file show up as partyinvite.doc doesn't imply any particular safety, because they never expect to see partyinvite.exe.
I'm not sure I follow your reasoning here. If someone sees "partyinvite.doc", they are likely to think it's a Word DOC file, whether or not it is. If someone sees "partyinvite.doc.exe", that's clearly unusual. At no point did I suggest that Windows might display "partyinvite.exe". You're right, nobody expects that one.
I would actually go a step further: If Windows notices a double-extension, where last extension is an executable type (.com,.exe,.scr,.bat,.inf,.dll, etc. etc.), pop up a warning if the user tries to run the file saying "WARNING: This is an executable file. This is not a insert name of registered file type for second extension file. Continue launching? If you are unsure, click No." Make the definition of "executable" sufficiently broad to cover all bases.
I guess you're saying that if the file were named "partyinvite.exe", Windows machines that hide the extension would simply show it as "partyinvite". Calling it "partyinvite.doc.exe" so it shows up as "partyinvite.doc" seems to be gilding the lily a bit. My counterargument is that seeing ".doc" (without seeing ".exe") can lull a user into thinking any generic warning they see about "executable file" is in error. That's why I suggest the much more sternly worded warning that says "Seriously, this file is NOT what you think it is."
I always run with extensions visible myself. But even for the crowd that runs with extensions hidden, it seems like it still ought to be trivial for Microsoft to add a rule to expose extensions (and maybe even highlight in some other way) files with double-extensions, such as the example file "partyinvite.doc.exe".
That is, if you ever see a "double extension", don't hide anything, and perhaps highlight it. Thus, instead of showing up as "partyinvite.doc.exe", it'd show up as "partyinvite.doc.exe".
Microsoft put all their Excel formulas into a private namespace. This is almost as bad as, say, writing a compiler that claims to be a C compiler, but really, all it does is validate the syntax of the C program and then look for C comments containing Pascal code, then compiling the Pascal code instead.
/*
BEGIN
writeln("Microsoft rules!");
END
*/
int main(int argc, char *argv[])
{
printf("This is standard C code.\n")
}
Is it a problem with the C standard that I can embed Pascal in a C comment?
The whole album has lyrics and themes that justify a mature content label. It's not just "Closer." And don't forget, they actually played Closer on the radio.
...which was basically just a 6502 with an extra I/O port. FWIW, most people think of the Atari 2600 as using the 6502, when really it used a 6507. All that was was the same die with fewer address lines pinned out.
(Yes, DOS 3.3 kept its "Volume Table of Contents" (TOC) on track 17 (aka, $11). You know, I never really looked closely at this code. This code seems to be doing something wacky with an extended 80-column card. It's moving 1K worth of stuff to "AUXMEM" (the ext 80 column card space). Why? I don't know. I do know that POKEing the right location can move the VTOC's sector, and is a fun and cheap way to "protect" a disk from amateur eyes. I have a few of those that I made myself.)
I started building such a thing myself, but I used a 4 bit binary counter, 74138 decoder and some XOR gates. The 4 bit counter always up-counted, and you just XOR the 4th bit with the other three to get the back/forth oscillation. The whole thing drove some super-bright LEDs. And, of course, a 555 provided the clock.
I never finished them, though I do still have the parts somewhere. I breadboarded the digital section and verified it, and soldered together a few LEDs worth of the analog portion.
Yes, I actually built an analog fade circuit for each LED based around a Darlington-pair PNP (yes, you read that right) driver for pull-down to light the LED, and then an RC circuit to give a lamp-like fade. The resistor had a diode across it to give it a fast charge time and slow discharge, so that the high-lumen LEDs looked like lamps coming on and fading slowly.
If I were to do it again, I'd just use a microcontroller and apply PWM to the LEDs. I've written that code a dozen times over in other projects for status display on bar-graph LCDs.
Oh, and to those who remind about "red lights are illegal on the front of a non-emergency vehicle", that's true on public motorways, but if you only light them on private property you're fine. Plus, mine were going to be concealed under the hood anyway.
I'm not convinced. Some of these were just lucky, and rode the wave when the world shook, as opposed to shaking the world. The 555? Yes, truly sublime. The 741 op-amp? So fundamental, you couldn't imagine the world without it. But the 6502? A lucky near-clone of the 6800 that was popular not because it was particularly innovative, but because it was cheap. The 8088? The bastard stepchild of the 8086 which lucked out in getting picked over the 68000 in the IBM PC.
Others are just interesting historical detours. Deep Blue and Transmeta Crusoe both were very interesting technologically, but they are in some sense interesting historical cul de sacs. The Explorer and related LISP machines, Intel's iAPX432, and the INMOS Transputer also hang out in this neighborhood.
DMD? Ok... that one always felt as if it was a project that succeeded only by application of the principle that with sufficient thrust, any pig will fly.
Anyway... I guess any list like this is subjective.
Fun fact: Wired Ethernet (before the wide adoption of switches) used to be a broadcast protocol also.:-) That's what that red "collision" light was for.
(Thankfully, switches are plentiful these days. They weren't during the heyday of 10baseT / 10base2. *shudder*)
How is bubble sort not obvious? You bubble the smallest element to the front of the list, then the next smallest, and then the next smallest. How do you know what the smallest element is? Take the last one and compare it to the one previous. If the last element is smaller than the one before it, swap. Otherwise leave them as they are. Now the second-from-last element is the smallest element so far. Repeat this with the second-from-last and the one before it, until you get up to the top. Tada, you've "bubbled up" the smallest value from the unsorted part of the list.
I actually learned bubble sort in junior high in a beginner's BASIC book.
1000 FOR I = 1 TO N-1
1010 FOR J = N-1 TO I STEP -1
1020 IF A(J) < A(J+1) THEN 1040
1030 T = A(J+1) : A(J+1) = A(J) : A(J) = T
1040 NEXT J
1050 NEXT I
Oh, and I forgot... heap sorts do have one place where they truly shine: Priority queues. The incremental O(log(n)) update to rectify the heap after an insert makes it a perfect candidate for priority queues.
Of course, if you didn't take data structures and basic algorithms, how would you know this?:-)
I guess if someone gave you a bag of higher level algorithms (STL and Boost come to mind in the C++ world) documented with big-Oh on all the pieces, you could still get by quite well without knowing the lower level details. Somebody implemented STL and Boost though.
Quicksort can be made to avoid the O(n*n) pretty easily (randomly selected pivot goes a long, long way very cheaply), and in my experience it tended to be around 2x as fast for typical data. Of course, I haven't measured in a while.
On deeply pipelined yet highly parallel machines, if you're sorting lots of small things, a modified merge sort combined with loopless sorting networks for the "leaves" (ie. subdivide only down to, say 16 elements and use a sorting network for the rest) can actually work better because of the inherent parallelism across the bushy parts of the tree.
That bug predates WoW. I remember witnessing several people getting bitten by this bug while playing MUDs on serial terminals back in the 1992-93 time frame.
There was an old BBS door, Caribbean Contraband, that had a similar bug. You could buy and sell negative quantities of the various items you were running around. Since the buy and sell code only checked maximums, you could "sell" a negative quantity to buy more than your plane could hold. (I don't remember if you could "buy" a negative quantity to sell more merchandise than you were carrying.) All I do know is that I ran up a bank account of around $2B before I quit.
Needless to say, the BBS operator got wise to these shenanigans pretty quick, and I only did it once.:-) He was a good sport about it and thought it was pretty clever.
Whaddaya know, a link to it! I wonder if the "overflow" bug mentioned in the WHATSNEW.TXT is the same bug? They don't mention the bug I found by name at least. It may still exist in there, who knows?
Here's a couple from the Intellivision that my brother and I discovered:
In Utopia, it's possible to sail off screen if you know how to manipulate your boat near the lower right corner. If you sail far enough south (with a few zigs and zags to dodge unseen off-screen barriers), you'll eventually sail back onscreen from the top. In this mode, you can't park your boat, but you can still fish, and you can sail on land. Not useful, but funny.
In Advanced Dungeons & Dragons: Cloudy Mountain, it's possible to navigate your party off the top left of the screen by pressing the "Go Northwest" button. Press it a second time and you'll come up in the middle of the map. Sometimes it'll save you time, most of the time it'll screw you.
In Advanced Dungeons & Dragons: Treasure of Tarmin, there are minor glitches in the display update. The pictures associated with sprites don't get updated in sync with the display backdrop. It's possible to see what's lurking behind a door by placing an object on the floor, turn faced to the right of a door, and then "glance left." The object on the floor will sometimes take on the picture of what's waiting behind the door.
Also, the Sega Genesis game Phantasy Star II, one of the best games I've ever played on the system, had a few bugs, some of them useful. My brother and I had catalogued 10 or so. Here's a couple:
First, a silly bug: You can press B while paused to get a slow motion mode. That's not the bug though. If you use the slow-motion mode to walk between zones with different music, when you unpause, you'll have the same music that was playing when paused, as opposed to the music you should have for that zone.
Use Shir to steal the Visiphone from the storage room in Paseo. Once you have the Visiphone, arrange for it to be in Ralf's pack as the first item. Now, you can press "A" repeatedly to get a quick save from just about anywhere in a dungeon. (Especially useful if you have a turbo-fire you can switch on.) Do this every few steps and you can avoid being attacked. If you do get attacked, it's easy to roll back to your last save. The bug is that accessing the menu often seems to reset the "how likely you'll have an encounter" stats, making it easy to limp out of a dungeon and back to a town when your HP's low and you don't have enough TP to warp out.
Perhaps the most important bug: If you press B + C together while in your backpack, it's possible to equip an item, but have the "E" denoting what item was equipped to show up on the next item in your pack. So, suppose you want to equip that Laconia Shield you just paid over 10,000 meseta for, but you really want to get your money's worth? Rearrange your pack to have a 10 MST Monomate sitting after the Laconia Shield, and press B + C to equip. If you did it right, your stats page will change to reflect the shield, but the Monomate will show as being equipped. Now you can hand the shield to another character and they can do the same, or you can sell it and get some meseta back. Just be careful to exit out of the menu system entirely between each use of this trick: If you do it too many times in a row, you can get stuck in a loop where the menu system won't let you exit out completely, and the only way out of that is to reset.
I've heard a DRAM guy claim that the higher chance of a bit cell flipping state due to a particle interaction as bit cell size drops is counteracted to some extent by the fact that the bit cells are smaller targets and therefore less likely to actually get hit.
I've heard that also. The flip-side (pun intended) is that it doesn't take as much energy to flip a bit, so it seems like the number of particle interactions with sufficient energy to cause a problem ought to increase also.
Of course, we build systems with a hell of a lot more bits of DRAM than 10 years ago, so the window of time in which one expects at least one bit error in a system is probably the same or shorter, and therefore ECC is just as important as ever.
Indeed. I've heard "1 flip per gigabyte per month" as a rough estimate of DRAM's SER. If that's the case, then my machine should be getting almost 1 flip per week, since it's always-on and it has 4GB of RAM. I wonder if there's some way to get the count... (I see this edac-utils mentioned on the web, but it doesn't seem to be installed at the moment. Will have to play with that later.)
(BTW, multibit flips from one event are mitigated by interleaving words in the DRAM array such that no two bits in one word are adjacent, or even very close to each other. If they didn't do that, single error correct / double error detect ECC wouldn't be good enough.)
Yes, the interleaving does help. It's partly a consequence of how the sense amps work (at least in an SRAM)--you have all these columns coming down to a mux, and then the sense amp is after the mux. You have one sense amp for each bit coming out of the memory.
If your mux factor is, say, 8, that means you have 8 different words all interleaved among different columns coming to that same sense amp. A high-energy event might take out several things in the same row, but it'll be spread across the columns. Rows are also naturally at different addresses, so you're safe in both dimensions. A column-wise strike that hits multiple rows still spreads the error out.
Slashdot Mirror
Ok, I took at look here at the sort of data loss they work with. They mention logical failures and mechanical failures. They don't mention deliberate overwriting. Everything on this page discusses just how hard it is to find the bit you're looking for, and how Ontrack has all sorts of expertise in coaxing the drive to do what they asked to at least get something out of it.
So far I haven't seen anything to suggest they can recover deliberately overwritten data. In fact, their data analysis page says:
Everything on the site points to being able to recover files that are inaccessible either due to drive failure (including mechanical damage) or being deleted without being overwritten. If you can find somewhere where they claim that they can recover overwritten data (as opposed to merely inaccessible data), I'd love to see it. Otherwise, you haven't disproved the notion that recovering overwritten data on a modern drive is an urban legend.
Who do I look like? Wernher von Braun? ;-)
Your comment made me chuckle, because I agree with it's intent wholeheartedly. "Rocket science" is the reference it is for a reason. Heck, the equations describing rocket flight aren't exactly basic algebra, even. If your burn rate is quick enough, both the mass and the mass distribution (center of gravity, moment of inertia) of the rocket will be changing fairly quickly as the rocket accelerates.
Right, because a swarm of mindless, vermin carrying and quickly multiplying rodents (rats in your cellar) is an accurate model of misdirected intellectual energy (someone figuring out how to break your security system in order to wipe your hard drives). So, yes, you should apply the same reasoning and same solutions to both.
How does it become untenable? Windows already only hides extensions that it knows about, as opposed to "any string of characters after a period is an extension." If I name a file "Release plan for v2.3" without the .doc, it won't hide the ".3". So, only apply the double-extension rule to things with two or more recognized extensions.
I'm not sure I follow your reasoning here. If someone sees "partyinvite.doc", they are likely to think it's a Word DOC file, whether or not it is. If someone sees "partyinvite.doc.exe", that's clearly unusual. At no point did I suggest that Windows might display "partyinvite.exe". You're right, nobody expects that one.
I would actually go a step further: If Windows notices a double-extension, where last extension is an executable type (.com, .exe, .scr, .bat, .inf, .dll, etc. etc.), pop up a warning if the user tries to run the file saying "WARNING: This is an executable file. This is not a insert name of registered file type for second extension file. Continue launching? If you are unsure, click No." Make the definition of "executable" sufficiently broad to cover all bases.
I guess you're saying that if the file were named "partyinvite.exe", Windows machines that hide the extension would simply show it as "partyinvite". Calling it "partyinvite.doc.exe" so it shows up as "partyinvite.doc" seems to be gilding the lily a bit. My counterargument is that seeing ".doc" (without seeing ".exe") can lull a user into thinking any generic warning they see about "executable file" is in error. That's why I suggest the much more sternly worded warning that says "Seriously, this file is NOT what you think it is."
I always run with extensions visible myself. But even for the crowd that runs with extensions hidden, it seems like it still ought to be trivial for Microsoft to add a rule to expose extensions (and maybe even highlight in some other way) files with double-extensions, such as the example file "partyinvite.doc.exe".
That is, if you ever see a "double extension", don't hide anything, and perhaps highlight it. Thus, instead of showing up as "partyinvite.doc.exe", it'd show up as "partyinvite.doc.exe".
Microsoft put all their Excel formulas into a private namespace. This is almost as bad as, say, writing a compiler that claims to be a C compiler, but really, all it does is validate the syntax of the C program and then look for C comments containing Pascal code, then compiling the Pascal code instead.
BEGIN
writeln("Microsoft rules!");
END
*/
int main(int argc, char *argv[])
{
printf("This is standard C code.\n")
}
Is it a problem with the C standard that I can embed Pascal in a C comment?
The whole album has lyrics and themes that justify a mature content label. It's not just "Closer." And don't forget, they actually played Closer on the radio.
...which was basically just a 6502 with an extra I/O port. FWIW, most people think of the Atari 2600 as using the 6502, when really it used a 6507. All that was was the same die with fewer address lines pinned out.
Can we stop splitting hairs now?
Whaddaya mean? You could triple-fault a 286 to get back to real mode, so I hear. You didn't need to ask the keyboard controller to reset you.
That wasn't the 6502's fault, it was Nibble Magazine's! They really shouldn't have been messing around with the DOS 3.3 disk catalog.
(Yes, DOS 3.3 kept its "Volume Table of Contents" (TOC) on track 17 (aka, $11). You know, I never really looked closely at this code. This code seems to be doing something wacky with an extended 80-column card. It's moving 1K worth of stuff to "AUXMEM" (the ext 80 column card space). Why? I don't know. I do know that POKEing the right location can move the VTOC's sector, and is a fun and cheap way to "protect" a disk from amateur eyes. I have a few of those that I made myself.)
What if I know what both are? Do I win a prize or something?
I started building such a thing myself, but I used a 4 bit binary counter, 74138 decoder and some XOR gates. The 4 bit counter always up-counted, and you just XOR the 4th bit with the other three to get the back/forth oscillation. The whole thing drove some super-bright LEDs. And, of course, a 555 provided the clock.
I never finished them, though I do still have the parts somewhere. I breadboarded the digital section and verified it, and soldered together a few LEDs worth of the analog portion.
Yes, I actually built an analog fade circuit for each LED based around a Darlington-pair PNP (yes, you read that right) driver for pull-down to light the LED, and then an RC circuit to give a lamp-like fade. The resistor had a diode across it to give it a fast charge time and slow discharge, so that the high-lumen LEDs looked like lamps coming on and fading slowly.
If I were to do it again, I'd just use a microcontroller and apply PWM to the LEDs. I've written that code a dozen times over in other projects for status display on bar-graph LCDs.
Oh, and to those who remind about "red lights are illegal on the front of a non-emergency vehicle", that's true on public motorways, but if you only light them on private property you're fine. Plus, mine were going to be concealed under the hood anyway.
I'm not convinced. Some of these were just lucky, and rode the wave when the world shook, as opposed to shaking the world. The 555? Yes, truly sublime. The 741 op-amp? So fundamental, you couldn't imagine the world without it. But the 6502? A lucky near-clone of the 6800 that was popular not because it was particularly innovative, but because it was cheap. The 8088? The bastard stepchild of the 8086 which lucked out in getting picked over the 68000 in the IBM PC.
Others are just interesting historical detours. Deep Blue and Transmeta Crusoe both were very interesting technologically, but they are in some sense interesting historical cul de sacs. The Explorer and related LISP machines, Intel's iAPX432, and the INMOS Transputer also hang out in this neighborhood.
DMD? Ok... that one always felt as if it was a project that succeeded only by application of the principle that with sufficient thrust, any pig will fly.
Anyway... I guess any list like this is subjective.
Fun fact: Wired Ethernet (before the wide adoption of switches) used to be a broadcast protocol also. :-) That's what that red "collision" light was for.
(Thankfully, switches are plentiful these days. They weren't during the heyday of 10baseT / 10base2. *shudder*)
See, they didn't have the Internet on computers back then, so they had to share their music over regular mail, not email. *d'oh*
How is bubble sort not obvious? You bubble the smallest element to the front of the list, then the next smallest, and then the next smallest. How do you know what the smallest element is? Take the last one and compare it to the one previous. If the last element is smaller than the one before it, swap. Otherwise leave them as they are. Now the second-from-last element is the smallest element so far. Repeat this with the second-from-last and the one before it, until you get up to the top. Tada, you've "bubbled up" the smallest value from the unsorted part of the list.
I actually learned bubble sort in junior high in a beginner's BASIC book.
1000 FOR I = 1 TO N-1
1010 FOR J = N-1 TO I STEP -1
1020 IF A(J) < A(J+1) THEN 1040
1030 T = A(J+1) : A(J+1) = A(J) : A(J) = T
1040 NEXT J
1050 NEXT I
Oh, and I forgot... heap sorts do have one place where they truly shine: Priority queues. The incremental O(log(n)) update to rectify the heap after an insert makes it a perfect candidate for priority queues.
Of course, if you didn't take data structures and basic algorithms, how would you know this? :-)
I guess if someone gave you a bag of higher level algorithms (STL and Boost come to mind in the C++ world) documented with big-Oh on all the pieces, you could still get by quite well without knowing the lower level details. Somebody implemented STL and Boost though.
Quicksort can be made to avoid the O(n*n) pretty easily (randomly selected pivot goes a long, long way very cheaply), and in my experience it tended to be around 2x as fast for typical data. Of course, I haven't measured in a while.
On deeply pipelined yet highly parallel machines, if you're sorting lots of small things, a modified merge sort combined with loopless sorting networks for the "leaves" (ie. subdivide only down to, say 16 elements and use a sorting network for the rest) can actually work better because of the inherent parallelism across the bushy parts of the tree.
I guess they still haven't fixed this bug in the MUDs yet?
That bug predates WoW. I remember witnessing several people getting bitten by this bug while playing MUDs on serial terminals back in the 1992-93 time frame.
There was an old BBS door, Caribbean Contraband, that had a similar bug. You could buy and sell negative quantities of the various items you were running around. Since the buy and sell code only checked maximums, you could "sell" a negative quantity to buy more than your plane could hold. (I don't remember if you could "buy" a negative quantity to sell more merchandise than you were carrying.) All I do know is that I ran up a bank account of around $2B before I quit.
Needless to say, the BBS operator got wise to these shenanigans pretty quick, and I only did it once. :-) He was a good sport about it and thought it was pretty clever.
Whaddaya know, a link to it! I wonder if the "overflow" bug mentioned in the WHATSNEW.TXT is the same bug? They don't mention the bug I found by name at least. It may still exist in there, who knows?
--Joe
Actually, no, going over 127 lives makes your count negative, and will give you game over the next time you die.
Here's a couple from the Intellivision that my brother and I discovered:
Also, the Sega Genesis game Phantasy Star II, one of the best games I've ever played on the system, had a few bugs, some of them useful. My brother and I had catalogued 10 or so. Here's a couple:
Right, but Apple's ][GS floppy drives were rather different than the PCs. They even spin the disk at variable speeds to store more on the outer tracks. (The article says inner tracks, but it's got the story backwards.)
I've heard that also. The flip-side (pun intended) is that it doesn't take as much energy to flip a bit, so it seems like the number of particle interactions with sufficient energy to cause a problem ought to increase also.
Indeed. I've heard "1 flip per gigabyte per month" as a rough estimate of DRAM's SER. If that's the case, then my machine should be getting almost 1 flip per week, since it's always-on and it has 4GB of RAM. I wonder if there's some way to get the count... (I see this edac-utils mentioned on the web, but it doesn't seem to be installed at the moment. Will have to play with that later.)
Yes, the interleaving does help. It's partly a consequence of how the sense amps work (at least in an SRAM)--you have all these columns coming down to a mux, and then the sense amp is after the mux. You have one sense amp for each bit coming out of the memory.
If your mux factor is, say, 8, that means you have 8 different words all interleaved among different columns coming to that same sense amp. A high-energy event might take out several things in the same row, but it'll be spread across the columns. Rows are also naturally at different addresses, so you're safe in both dimensions. A column-wise strike that hits multiple rows still spreads the error out.