10 Computer Mishaps

Ant writes "ZDNet UK posted Ontrack Data Recovery's 2004 list of the 10 strangest and funniest computer mishaps... Some of them are funny!" My best mishap was installing the alpha video driver on an NT 3.51 box thinking that it was just an alpha driver. Of course since this Alpha meant DEC and this was an x86 box, the server barfed pretty hard. Also the time I spilled an 8oz glass of water on my laptop and lost all my email from 1994 to 1999 and my backup was corrupted. That I liked too.

Dull dull dull

[MullerMn]

Not to sound like a miserable bastard, but exactly which of these are supposed to be funny? This article is really lame, uninformative and about as funny as colon cancer.

The first item on the list takes the piss out of some guy for putting a HD in the freezer in an attempt to get it to work, when that is well known for sometimes working in temporarily resuscitating dead drives, if the death is due to a mechanical fault.

Also, the link for page two seems to keep taking me back to the first page in Firefox.

<insert misc comment about /. going downhill>

Bah. Humbug.

Re:Dull dull dull

[Pig Hogger]

Not to sound like a miserable bastard, but exactly which of these are supposed to be funny? This article is really lame, uninformative and about as funny as colon cancer.

That's not the idea. The idea is to have slashdotter contribute their own stories which are bound to be orders of magnitude better than the lame stuff in the original article...

Re:Arguments becoming options

[Pxtl]

And yet *nix users continue to insist that command-line tools and bizarro naming conventions are a good thing.

To me, this is an example of catastrophically bad platform design.

Re:#1 Works!

[Anonymous Coward]

what a twat.

Re:Arguments becoming options

[greed]

How is "programmer failing to check error status" or "protect arguments" a sign of bad platform design?

Especially when UNIX shells provide paranoia flags for preventing exactly this kind of disaster:

#!/bin/sh -e

Now any failing command in a script started like that will cause the script to bail. This should be your standard way of writing a shell script.

The only commands allowed to fail will be those that are the condition of an if or while statement, or are part of a command-chain using the short-circuit operators && or ||.

Further, any POSIX-compliant command has an "end of options" indicator, --. Sure, it's annoying to type on the command line, but when you're writing a script to run unattended, you need to protect it against anticipated situations.

It's not as if having the "remove" command be called "rm" was the cause of this problem.

Really, the use of wildcards in script that run unattended is just dangerous... if you're doing it, re-code.

Like this:

find "${DATADIR}" -type f -exec rm {} \;

If you need to nuke subdirs too, that's easy--if you do it separately:

find "${DATADIR}" -type d -mindepth 1 -depth -exec rmdir {} \;

Anyone who doesn't get heart palpitations when writing rm commands to be run by a script as root is either inexperienced or unimaginative.

Ask the guys at Apple who had to pay for forensic recovery of customer's hard drives when a badly-written rm command in an early iTunes update clobbered hard drives because it didn't handle spaces-in-filenames.

Re:Arguments becoming options

[frodo from middle ea]

I once knew a guy who tried to drive his bike (at night time ) in between , what he thought were two other approaching bikes from the opposite direction.

turns out , they were headlights of a 18 wheeler, who would have thunk ? Now there's an example of a catastrophically badly designed headlight system for a 18 wheeler.

Re:My best...

[Anonymous Coward]

. . .and because your friend was an unsecured creditor, he promptly got to write a check for $50,000.00 to the Bankrutpcy Trustee because that was a PREFERENTIAL TRANSFER and therefore not legal under bankruptcy law (in the US at least).

The unique spelling of "check" - i.e. "cheque" would suggest this took place outside of US Bankruptcy jursidiction.

Re:Arguments becoming options

[morgan_greywolf]

Yes.

1. Always check the syntax of your commands before executing them. 'man rsync' would have been helpful.

2. Don't run things in '/' as root unless you need to. (Hint: most of the time, you don't need to)

3. Don't export filesystems as rw with root squash turned off unless absolutely necessary (hint: most times it's not necessary)

4. If you are going to mount things via NFS, add them to the fstab.

5. Add some error checking in your scripts. Changing from

cd /foo
rm -f *

to

cd /foo && rm -f *

would have made a BIG difference.

6. Files named '-r' should not be in the root directory.

7. Make sure your backups are good. ;)

Did I miss anything?

Re:My ones

[IngramJames]

These [rinkworks.com] aren't my ones, but I once lost a day's productivity when I found the site.

Mixed bag, but don't read in any circumstances where you can't afford to laugh out loud and squirt coffee through your nostrils.

Re:My ones

[coronaride]

why is this insightful? oh right..i would have never guessed that that would have hurt..

Re:My ones

[pla]

Ofcause you have to remember to do everything in a single command otherwise if you delete the old version you cannot run anything else.

It amazes me that every single Linux distro doesn't just come with statically linked /bin and /sbin utilities (along with a few in the similar /usr dirs (such as ldd, nm, and a small editor like nano).

Modern HDDs have oodles of space. Wasting a few extra megs in exchange for an almost-worst-case recoverable installation seems like a no-brainer to me.

Of course, I can (and do) install exactly such statically linked utils as my first task after a new install, but I shouldn't need to... Not to mention, many of the basic Linux programs take a whole lot more than just passing a "--enable-static" to the configure script or passing in an "LDFLAGS=-static".

They're *not* funny...

[xwizbt]

Is it just me who doesn't find them remotely amusing in any way possible? I mean, it's not like their baby accidentally ate the computer, or a flock of flying monkeys swept in and deleted everything. They reinstalled. Oh, the hilarity!

And wait... someone reversed over a computer. Hilarious! Must go and find duct tape; sides in need of repair...

Re:#1 Works!

[Fishstick]

Yeah, I was waiting for the insane laughter at someone else's expense, but was sadly dissapointed.

Not really strange or funny, kinda just stupid, actually.

Re:My ones

[ZosX]

Don't know why I'm responding to this AC, but anyways, I can't really imagine throwing a computer out of the window after it clears a POST but refuses to boot. A simple chain of logic would conclude that the hard drives or the IDE interface was at fault by first trying to BOOT without the HDs plugged in and then removing and/or disabling the IDE interface in BIOS. If you can't boot, it really is best to start out at the BARE minimum and work it up from there. Typically all you need to get past a POST is a video card, a working processor, and working sticks of RAM. If you aren't getting power or the power light comes on and fades, then your power supply is of course suspect. If the computer will not do this, then rule out the video card and possibly AGP slot by placing a PCI card in if you can or at least try some sort of other video, then move on to the memory, by using some that you know for a fact should work in the motherboard you are testing. Density matters, especially on older machines. A few old sticks of 16-32 megs work great to have on hand for the odd P2 or P-III you may come across. Next, of course, you have to rule out the CPU. Of course, if you get error beeps, it is best to figure out WTF they mean and most BIOS manufacturers have pretty standard beep codes for their whole product lines.

So you get past POST? Good. Now go take a freaking break or something if you are truly frustrated. Your core components at least still work. Next attach all PCI cards and boot after each new one is added. Some cards like to sit in a master PCI slot, but most usually do not care. If you don't know what your master is, generally the first PCI slot is a good master. Once you have your cards sorted out and everything is still working you need to plug your drives back in. If you got this far, chances are you have a hard drive problem. Generally a computer should get past the POST and start looking at drives, but if you just changed your drive configuration and have master and slave set wrong (ahem parent), typically the IDE light will just light up solid when you hit the power. That's not so terrible really. You just need to make sure that each cable is aligned with pin 1 on the drive, that the slave is the second drive on the chain, and that their jumpers are all set correctly. Of course if you use a regular IDE cable and not the slim ATA cable with your hard drive, you will not be potentially utilizing the ATA capabilities of your drive. Generally a lot of computers come with two cables. One for your drives and one for your CD-ROM/RW/DVD/ETC. Honestly I don't know if the newer CD-ROM drives will take the faster cables, but if it really concerns you, you could easily search on google or hell, experiment.

Just don't throw working computers out the window. That is truly wasteful and a poor showing of geekness. The true geek would be soldering a new IDE interface (on the motherboard no less) if he needed to. Allright. Maybe not, but I digress. The point is that you destroyed a perfectly good PC because you were frustrated. I imagine that your life must be very expensive.

Re:#1 Works!

[OwlofCreamCheese]

NO! don't go! your beautiful and important and we all beg you to stay because your so awesome and your so great that we would hate to lose you!

Re:My ones

[iwan-nl]

Bah, agression against computers... I bet you also smash your windshield with a baseball bat when your car has a flat tier.