"I apologize. I offer a complete and utter retraction. The imputation was totally without basis in fact, was in no way fair comment, and was motivated purely by malice, and I deeply regret any distress that my remarks may have caused you, or your family, and I hereby undertake not to repeat such a slander at any time in the future."
Alan Turing's work continues to demonstrate "what a tremendous importance it has in the foundations" of computing technology in general, not just crypto.
Nowadays, IDE keeps a list of bad/remapped sectors and does all this in the background *as long as it's told to* -- if nobody ever reads offset 17543, nobody knows that is about to go bad (lets say ECC can correct for 1 in 96 bits, and right now there's an error in 1 of 108 bits), and over time, that will degrade to 1-in-96 at which time the data is lost. If SpinRite (or any other parity scrubber) reads the data while it's good, the drive electronics should notice the high error rate and refresh it. Some drives won't write the correct data back to the disk unless told to (it slows the drive down)...
I mostly agree with this. Sectors can degrade over time, so a "refresh" will essentially fix it. The problem is that drives don't necessarily do this (some drives have offline scans, but it's not guaranteed). As you've pointed out, a degrading sector can go unnoticed until someone actually requests to read that sector. And, perhaps this is where most people are frustrated with Spinrite's marketing. Just doing a read and then re-write to a sector isn't magic. The point is that when Spinrite encounters an error that it cannot read, it goes thru a series of steps to try and *enable* the HDD to read the sector. For example, it moves the actuator at varying distances from the target LBA to try and get it to seek settle at a slightly different location on the track. This is important because tracks are typically wider than the read head, so you can have different but acceptable actuator/head locations on the same track/sector.
My point about the ATA command is that Spinrite is only using standard commands; not undocumented commands or anything secret like that. However, what is "special" are the sequence of commands used to help the drive recover sectors that get a read error.
Ok, using what you just said, explain the "Dynastat Data Recovery" in Spinrite. To refresh your memory, that is where it claims to be working down to the bit level. You cannot address individual bits or even bytes on a drive, either with BIOS or direct ATA commands. And before you say something stupid about "averaging" or other mathematical BS, a modern drive can only return one of two things for a sector request. The correct data when the ecc matches, or an error.
I'm not sure what Spinrite is using, but there is a way to do this. It's not widely used, but there's a command called "Read Long", along with a complimentary "Write Long":
INT 13h AH=0Ah: Read Long Sectors From Drive (Reference: http://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D0Ah:_Read_Long_Sectors_From_Drive)
This returns data including bad data along with the ECC. This allows for error bits to be read along with the correction field. You can use this to essentially do offline error correction, but it will also give you the ability to get "parts of a sector".
+1. Moving to a different service port dropped my failed login attempt logs down to nothing (at least, for now). Prior to that, my logs still weren't too big because I block IPs after #MAX_ATTEMPTS within a 24 hour window. However, the attempts were coming in at a rate of 10 minutes apart. Still, they got blocked. It's just that the hacking community seems to be well aware of trying to keep the number of attempts / unit time down to avoid detection.
You seem to have it in for Spinrite, but it's not clear why. If you listen to Steve's podcast (Security Now), you'll know that he is very careful on how he describes the technical aspects of his products (including Spinrite). I'd be very surprised if you or anyone could point to any of GRC's literature on Spinrite that would prove he's "lying" about anything.
I'm not sure where Spinrite claims anything other than using Int13 commands. That's how it gets its minimalist compatibility with a DOS system using the system BIOS. For a SATA drive connected directly to the motherboard thru a standard SATA host adapter use regular ATA commands.
A USB connected SATA HDD simply gets help from the BIOS so that it can use Int13, converting to the USB commands, and then over the USB bridge, eventually going back to a standard ATA command (the only commands a SATA drive knows).
My point about the ATA command is that Spinrite is only using standard commands; not undocumented commands or anything secret like that. However, what is "special" are the sequence of commands used to help the drive recover sectors that get a read error.
Spinrite may do an OK job of exercising disks, but 90% of what it claims to do is BS.
This is a very uniformed opinion about Spinrite. Spinrite has a large population of testimonials that prove that "it works". It's main purpose is data recovery and data maintenance on magnetic-based rotational media.
Your example of a USB drive is just another way of saying "flash", for which Spinrite is not targeted to fix.
Indeed, there are no more "low level" commands like in the day of old HDD technology. However, Spinrite uses the standard ATA command set to do everything possible to get your data off your drive. It does this very well and you'll be hard pressed to find other programs that do it better that don't cost a lot, lot more money (think data recovery repair center).
It's also a terrible data recovery program, since it can only write recovered data back to the same disk
Spinrite doesn't target this case. Backing up is what you do *after* you use Spinrite to first correct the few sectors that are preventing your system from recognizing the disk in the first place.
You really need to review the product, what it's targeted to do, and the testimonials before you continue to bad mouth a product that has been shipping for as long as Spinrite has.
All right, all right, I apologize... I'm really really sorry... I apologize unreservedly... I offer a complete and utter retraction. The imputation was totally without basis in fact, was in no way fair comment, and was motivated purely by malice, and I deeply regret any distress that my remarks may have caused you, or your family, and I hereby undertake not to repeat such a slander at any time in the future.
I'm left handed and I'm accustomed to having to play some games that were made for right handers anyway. I mean, the location of the D-Pad on a NDS (as well as many other gaming controllers) is basically easier for a right hander to play. I still enjoy using / playing it.
I guess I've just adjusted to living in a (mostly) right-hander's world.
This is really too bad for us. I've been using GBS for about 2.5 years. When I first started trying different plug-ins to handle the bookmark sync problem, I found Google's browser sync to work the best for 2 primary reasons (1) The sync tool was seamless/simple and (2) the google servers were fast/reliable.
I'm hoping that Foxmarks or some other service provides me a good replacement as far as user experience is concerned. However, the fact that google is dropping this tool tells me that they really didn't care much about the user data in the first place. In other words, our bookmarks were not likely being used to learn trending or to gain business.
Foxmarks on the other hand appears to have a whole business model wrapped around this one plug-in. So you better believe that Foxmarks is taking direct advantage of our bookmarking trends, which is less attractive to me.
GBS is (was) a nice plug-in, and something that Google should have had more pride in.
In order to make everything fit, he had to sacrifice the WiFi and bluetooth cards, but considering the portable nature of the laptop, it is a small price to pay for being truly wireless Losing bluetooth is OK perhaps, but losing Wireless is far too big of a price to pay. Even the best connection via Verizon is slow, relative to wireless. Too bad
The Mythical Man Month tells us a lot about large scale projects. Written decades ago, it still holds true today.
Some key points:
+ Large scale projects that require a large resource pool will lose a significant % of man hours due to communication overhead
+ Adding resources to projects will cause the project to slow down before it will speed up
HDD manufacturers are looking to increase the amount of data stored on each platter. With larger sector sizes, the HDD vendor can use more efficient codes. This means better format efficieny and more bytes to the end user. The primary argument being that many OSes already use 4K clusters.
During the transition from 512-byte to 1K, and ultimately 4K sectors, HDDs will be able to emulate 512-byte modes to the host (i.e. making a 1K or 4K native drive 'look' like a standard 512-byte drive). If the OS is using 4K clusters, this will come with no performance decrease. For any application performing random single-block writes, the HDD will suffer 1 rev per write (for a read-modify-write operation), but that's really only a condition that would be found during a test.
Slashdot Mirror
Maybe they were both right and both wrong? http://en.wikipedia.org/wiki/W...
Good code vs. Bad Code
"I apologize. I offer a complete and utter retraction. The imputation was totally without basis in fact, was in no way fair comment, and was motivated purely by malice, and I deeply regret any distress that my remarks may have caused you, or your family, and I hereby undertake not to repeat such a slander at any time in the future."
Just one more reason to not buy any preview-infested Blu-Ray discs and just use my $$ to stream videos from the internet.
Alan Turing's work continues to demonstrate "what a tremendous importance it has in the foundations" of computing technology in general, not just crypto.
Nowadays, IDE keeps a list of bad/remapped sectors and does all this in the background *as long as it's told to* -- if nobody ever reads offset 17543, nobody knows that is about to go bad (lets say ECC can correct for 1 in 96 bits, and right now there's an error in 1 of 108 bits), and over time, that will degrade to 1-in-96 at which time the data is lost. If SpinRite (or any other parity scrubber) reads the data while it's good, the drive electronics should notice the high error rate and refresh it. Some drives won't write the correct data back to the disk unless told to (it slows the drive down)...
I mostly agree with this. Sectors can degrade over time, so a "refresh" will essentially fix it. The problem is that drives don't necessarily do this (some drives have offline scans, but it's not guaranteed). As you've pointed out, a degrading sector can go unnoticed until someone actually requests to read that sector. And, perhaps this is where most people are frustrated with Spinrite's marketing. Just doing a read and then re-write to a sector isn't magic. The point is that when Spinrite encounters an error that it cannot read, it goes thru a series of steps to try and *enable* the HDD to read the sector. For example, it moves the actuator at varying distances from the target LBA to try and get it to seek settle at a slightly different location on the track. This is important because tracks are typically wider than the read head, so you can have different but acceptable actuator/head locations on the same track/sector.
My point about the ATA command is that Spinrite is only using standard commands; not undocumented commands or anything secret like that. However, what is "special" are the sequence of commands used to help the drive recover sectors that get a read error.
Ok, using what you just said, explain the "Dynastat Data Recovery" in Spinrite. To refresh your memory, that is where it claims to be working down to the bit level. You cannot address individual bits or even bytes on a drive, either with BIOS or direct ATA commands. And before you say something stupid about "averaging" or other mathematical BS, a modern drive can only return one of two things for a sector request. The correct data when the ecc matches, or an error.
I'm not sure what Spinrite is using, but there is a way to do this. It's not widely used, but there's a command called "Read Long", along with a complimentary "Write Long":
INT 13h AH=0Ah: Read Long Sectors From Drive (Reference: http://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D0Ah:_Read_Long_Sectors_From_Drive)
This returns data including bad data along with the ECC. This allows for error bits to be read along with the correction field. You can use this to essentially do offline error correction, but it will also give you the ability to get "parts of a sector".
Anyone see these guys on a port other than 22?
+1. Moving to a different service port dropped my failed login attempt logs down to nothing (at least, for now). Prior to that, my logs still weren't too big because I block IPs after #MAX_ATTEMPTS within a 24 hour window. However, the attempts were coming in at a rate of 10 minutes apart. Still, they got blocked. It's just that the hacking community seems to be well aware of trying to keep the number of attempts / unit time down to avoid detection.
Spinrite is lying about even using ATA commands
You seem to have it in for Spinrite, but it's not clear why. If you listen to Steve's podcast (Security Now), you'll know that he is very careful on how he describes the technical aspects of his products (including Spinrite). I'd be very surprised if you or anyone could point to any of GRC's literature on Spinrite that would prove he's "lying" about anything.
I'm not sure where Spinrite claims anything other than using Int13 commands. That's how it gets its minimalist compatibility with a DOS system using the system BIOS. For a SATA drive connected directly to the motherboard thru a standard SATA host adapter use regular ATA commands.
A USB connected SATA HDD simply gets help from the BIOS so that it can use Int13, converting to the USB commands, and then over the USB bridge, eventually going back to a standard ATA command (the only commands a SATA drive knows).
My point about the ATA command is that Spinrite is only using standard commands; not undocumented commands or anything secret like that. However, what is "special" are the sequence of commands used to help the drive recover sectors that get a read error.
Spinrite may do an OK job of exercising disks, but 90% of what it claims to do is BS.
This is a very uniformed opinion about Spinrite. Spinrite has a large population of testimonials that prove that "it works". It's main purpose is data recovery and data maintenance on magnetic-based rotational media.
Your example of a USB drive is just another way of saying "flash", for which Spinrite is not targeted to fix.
Indeed, there are no more "low level" commands like in the day of old HDD technology. However, Spinrite uses the standard ATA command set to do everything possible to get your data off your drive. It does this very well and you'll be hard pressed to find other programs that do it better that don't cost a lot, lot more money (think data recovery repair center).
It's also a terrible data recovery program, since it can only write recovered data back to the same disk
Spinrite doesn't target this case. Backing up is what you do *after* you use Spinrite to first correct the few sectors that are preventing your system from recognizing the disk in the first place.
You really need to review the product, what it's targeted to do, and the testimonials before you continue to bad mouth a product that has been shipping for as long as Spinrite has.
All right, all right, I apologize... I'm really really sorry... I apologize unreservedly... I offer a complete and utter retraction. The imputation was totally without basis in fact, was in no way fair comment, and was motivated purely by malice, and I deeply regret any distress that my remarks may have caused you, or your family, and I hereby undertake not to repeat such a slander at any time in the future.
I'm left handed and I'm accustomed to having to play some games that were made for right handers anyway. I mean, the location of the D-Pad on a NDS (as well as many other gaming controllers) is basically easier for a right hander to play. I still enjoy using / playing it.
I guess I've just adjusted to living in a (mostly) right-hander's world.
Seems like reporters could share their line with others and share the cost along with it. 1 simple wireless router should do the trick.
This is really too bad for us. I've been using GBS for about 2.5 years. When I first started trying different plug-ins to handle the bookmark sync problem, I found Google's browser sync to work the best for 2 primary reasons (1) The sync tool was seamless/simple and (2) the google servers were fast/reliable.
I'm hoping that Foxmarks or some other service provides me a good replacement as far as user experience is concerned. However, the fact that google is dropping this tool tells me that they really didn't care much about the user data in the first place. In other words, our bookmarks were not likely being used to learn trending or to gain business.
Foxmarks on the other hand appears to have a whole business model wrapped around this one plug-in. So you better believe that Foxmarks is taking direct advantage of our bookmarking trends, which is less attractive to me.
GBS is (was) a nice plug-in, and something that Google should have had more pride in.
... then I would have just blamed the whole thing on Meatwad. Shake gets away with that kind of crap all the time.
The Mythical Man Month tells us a lot about large scale projects. Written decades ago, it still holds true today.
Some key points:
+ Large scale projects that require a large resource pool will lose a significant % of man hours due to communication overhead
+ Adding resources to projects will cause the project to slow down before it will speed up
Want to write a single byte? Then read 4MB, modify 1 byte, and write 4MB back to the disk.
HDD manufacturers are looking to increase the amount of data stored on each platter. With larger sector sizes, the HDD vendor can use more efficient codes. This means better format efficieny and more bytes to the end user. The primary argument being that many OSes already use 4K clusters.
During the transition from 512-byte to 1K, and ultimately 4K sectors, HDDs will be able to emulate 512-byte modes to the host (i.e. making a 1K or 4K native drive 'look' like a standard 512-byte drive). If the OS is using 4K clusters, this will come with no performance decrease. For any application performing random single-block writes, the HDD will suffer 1 rev per write (for a read-modify-write operation), but that's really only a condition that would be found during a test.