Computer Voodoo?
jbeaupre asks: "A corollary to 'Any sufficiently advanced technology is indistinguishable from magic' is that sometimes users have to resort to what I call 'computer voodoo.' You don't know why it works, you barely care how it works, but you find yourself doing the strangest things because it just seems to work. I'm talking about things like: smacking a PC every 5 seconds for an hour to keep it from stalling on a hard drive reformat (with nary a problem after the reformat); or figuring out the only way to get a PC partially fried by lightning to recognize an ethernet card, after booting into Windows, is to start the computer by yanking the card out and shoving it back in (thereby starting the boot processes). What wacky stuff have you done that makes no obvious sense, but just works?"
For most problems, I find smacking the user is more effective than smacking the computer.
I had to code a standards compliant page with Dreamweaver ... now THAT'S voodoo
When somebody has a problem that they want me to fix, my mere presence and their attempt to repeat the problem makes it go away.
Usually whenever it would start going on the fritz a good punch or kick to the tower would get it going again. And also stop that damn whirring noise. It always makes me laugh when I'd see people hitting the monitor. Because THAT is where everything is XD
In my repair monkey days, my shop used to handle data recovery jobs of all kinds. The problems ranged from minor filesystem corruption or unbootable drives to physical damage - heads, and even a bullet through a hard drive (No, I wasn't able to get anything off that one).
We had a variety of methods for dealing with the physically damaged drives that had suffered a head crash, but my boss had a technique he called the 'massage'. A clicking or noisy drive would be rotated around its various axes until the BIOS would recognize it on boot. Sometimes the clicking would stop and he would sit there holding the drive in that position or prop it up to keep it there.
Another method we used was to freeze the drives for a period of 15 minutes to 6 or 8 hours. Sometimes this allowed enough contraction to let the tracks line up again, and we'd get as much data as we could with the drive cold. Once, we even froze a drive between two ziploc bags of water with IDE and power cables hanging out the edge to keep the drive colder longer. It worked!
-- Shade
Technology tips and tricks.
-- Shade
Technology tips and tricks.
On the first pc I built one of the best ways to keep it in line in its last few weeks with me was to randomly yell and smack the pc, it didnt know when it would happen so it didnt risk crapping out on me :P
Nah, Ive never had to rely on any voodoo to keep my pc running .. but to eliminate some annoying buzzing sounds from fans nothing beats a swift smack on the top left corner of the case.
I had a roommate that smacked his pc cause it wasnt working the way he wanted it to .. but it was working perfectly fine (no hardware or software issues - all user issues) .. I told him I'd have to start a support group for his electronics (he hit everything) if he kept it up. Electronic Victims of **** still lives to this day (name censored so he doesnt come after me :P)
If it takes effort to do, let someone else do it.
real nerds dont code html by hand, they write a script to code the html for them
back in the day we didnt have no old school
Got to love old school hacking
I have mod points and I am not afraid to use them
Here's how it works.
:)
IDE drives keep a list of spare sectors to be used if one of the "primary" ones gets damaged. However, if a sector gets damaged and it already contained data, the drive won't reallocate it, because it would have no way of recovering the information. So it keeps "hoping" that some day the data will be readable again, and when that happens, it'll reallocate the sector. However, it never happens.
When you overwrite a defective sector, the drive says "aha! since the user overwrote the information, it means it's not important anymore; so I'll go ahead, mark the sector as bad and replace it with a spare". That's why overwriting gives the drive a chance to remap all bad sectors to clean ones.
This is a trick I learned by reading the documentation on smartd; if SMART reports defective or unreadable sectors, there's a way to figure out which files reside in those sectors and overwrite them with zeroes; the file will of course be lost, but by overwriting you let the drive reassign the sector and everything is peachy again.
By the way, if you reformat the drive with the destructive verification option (-c -c) it's likely that when the test overwrites to verify readability, the same reassigning process will take place; the standard "-c" test is a read-only test that's why you're unable to format a drive without the overwriting procedure.
So you see, not voodoo.
This trick even works non-destructively: dd if=/dev/hda of=/dev/hda bs=512 A friend of mine showed me this method a few years ago and it has helped recover failing drives over a dozen times since.
I used to have a Performa 5200 back when I started college, and if you're not familiar with the machine, it's arguably the worst Macintosh ever made. Ever. The only thing it excelled at was displaying grainy TV on the TV tuner card you could get for it.
Read that second link for all the gory details of why the follow scenario works, and you'll shudder.
I used to note in college that when doing particularly fast FTP transfers that saturated by 10-Base-T card that the machine would often lock up within a minute of starting the transfer. For months, I fiddled around and noticed that if I was actively working that this didn't happen. Eventually, I found the article I mentioned and realized that if I kept moving the mouse constantly, the machine wouldn't get in whatever weird state locked up the machine and I could finish my transfers. That's right -- to run FTP (or any other sustained, saturated transfer), I had to sit there moving the mouse in circles through the entire transfer.
Essentially, the "Left 32" bus described in the article was shared by the 16-bit Apple Desktop Bus (for mouse and keyboard) and the 16-bit networking card (as well as audio and the 8-bit SCSI controller). So long as I kept interrupting the bus with input from ADB, the networking card was unable to flood the controller that had to make sense of all the different bit-widths and clock speeds between the various busses hanging off of it, and the machine wouldn't lock up.
Now how's that for some serious computer voodoo?
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
Do you mean the first time or the second time?
"Not an actor, but he plays one on TV."
The hard drives do a dynamic re-mapping of bad sectors to a different area. If you write an entire sector, and the sector was already marked a 'unreadable', the drive has an opportunity of using the 'secret' sector area instead. From then on, reads for this sector will come from the secret area. There are a limited number of secret tracks.
This is one of the 'gotchas' with multimedia content. A hard drive may have fast access times and a fast bus, but if there are persistent CRC errors (and there is quite often CRC errors on a non-failing drive!), then the drive may have to take 15 or so separate reads of the track to reconstruct - It may also temporarily move the surrounding tracks to the secret area, then zero out the surrounding tracks in order to reduce track-to-track crosstalk.
All of this takes time, and quite often any real time media bandwidth budgets get blown when this happens.
The neat thing is, when this does happen, it is never an error. The program does finally get the data, but it just takes longer than expected. Typically one way to find out if the drive has remapped tracks on you is to have a program which measures track to track access time sequentially, and find the track boundaries that take a lot longer than a move from adjacent tracks should.
Jeff
ipv6 is my vpn
I knew a guy who could only log into the network while sitting down. If he was standing up when he tried to log in, no dice.
Turns out he touch typed while sitting, but had to look at the keyboard while standing - and since he "cleaned" his keyboard and put a few key tops back in the wrong places, he was mis-typing has password if he was standing up.