Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The classic Unix horror story

lug.wsu.edu

Post reply on HN
Print view View original

21–30 of 54 posts

Re: The classic Unix horror story

#21

Post by die_sekte »

lanstein wrote: post #18
watmough wrote: post #10

My terrible UNIX, or really SunOS/Solaris moments have been: o typing 'halt' into the wrong xterm, shutting down well planners o and likely on the same network, jacking up the NIS+ on Solaris It's been a constant itch that I never did manage to understand what I was doing wrong, such that NIS+ wouldn't restart correctly.

My marquee move is to shut down the ethernet interface of a box I'm SSHed into.

I used iptables to block all incoming traffic. While SSHed into the server. Thankfully, Linode's out of band console works (slow and painful, but it worked).

Re: The classic Unix horror story

#22

Post by randrews »

naner wrote: post #20
randrews wrote: post #9

I've never actually been bitten by rm (or done anything remotely this badass) but in college I did have a bad Unix moment: Late at night, I was tarring up a finished project right before emailing it to my professor. I ran: tar -cvf *.cpp *.h something.tar instead of: tar -cvf something.tar *.cpp *.h It happily wrote most of my project into a tar file on top of the first source file, then complained that something.tar…

Writing this comment, I had to look up the order of the parameters to tar; I still can't remember. Stupid tar. The -f (--file) flag takes an argument. So you could do: tar -cf *.cpp -f something.tar It is easier to remember order if you know what the flags mean.

It's true, and I'll probably remember it now. But, since I have every single time used the -f flag, it would make a lot more sense for it to say "you asked me to compress a file that doesn't exist and ends in .tar; I bet that's what you meant the -f parameter to use" and fix it for me.

Re: The classic Unix horror story

#24

Post by blantonl »

Vivtek wrote: post #14
jff wrote: post #6

Man, how many times is this story going to be submitted?

As often as it's still badass.

I get goosebumps every time I read it, and I read it every time it is submitted.

You'll know that "head-in-hands" feeling if you've done it before, and it is quite the experience.

That's why this story will draw you back every time.

Re: The classic Unix horror story

#25

Post by blantonl »

mkramlich wrote: post #15
quanticle wrote: post #11

Earlier quoted context omitted.

Yes, but too bad that frequent offsite automated backups were still at least a decade off in 1986. At the very least, the network bandwidth just simply wasn't there. Heck, at this stage of the game, 1Mbps was considered to be blazing fast on a LAN. Even Internet backbones were 56k.

i know for a fact that backups were possible in 86 and that's all that would be needed to turn an accidental deletion into a non-disaster but you're right, networking speed/bandwidth has gotten better since then, but that's irrelevant and I never claimed it hadn't. my point was that there is a simple, well-known solution/palliative for this, so no need for this kind of drama going forward.

the article clearly describes how they used backups to turn an accidental deletion into a non-disaster, in 1986.

Re: The classic Unix horror story

#26

Post by _cbsz »

jjcm wrote: post #19
_cbsz wrote: post #4

Is there a "social news sites classics" directory yet? I would love to see reposts of oldies no longer justified due to a good directory of these things, prominently linked. Pretty please do not create such a directory in this comments thread.

http://catb.org/~esr/jargon/html/ The Hacker Jargon page would probably be the best index of the so called "classics", although it hasn't been updated in years.

Too narrow. I was referring to stories that crop up on social news sites over and over, not UNIX arcana.

Re: The classic Unix horror story

#27

Post by mkramlich »

blantonl wrote: post #25
mkramlich wrote: post #15

Earlier quoted context omitted.

i know for a fact that backups were possible in 86 and that's all that would be needed to turn an accidental deletion into a non-disaster but you're right, networking speed/bandwidth has gotten better since then, but that's irrelevant and I never claimed it hadn't. my point was that there is a simple, well-known solution/palliative for this, so no need for this kind of drama going forward.

the article clearly describes how they used backups to turn an accidental deletion into a non-disaster, in 1986.

yes, and it's funny how your statement is consistent with my assertion that backups existed in 86, and that backups are a good thing. i love "arguments on the Internet" sometimes! :)

Re: The classic Unix horror story

#28

Post by mkramlich »

die_sekte wrote: post #21
lanstein wrote: post #18

Earlier quoted context omitted.

My marquee move is to shut down the ethernet interface of a box I'm SSHed into.

I used iptables to block all incoming traffic. While SSHed into the server. Thankfully, Linode's out of band console works (slow and painful, but it worked).

funny but that sounds like a rite of passage when learning how to configure iptables :)

Re: The classic Unix horror story

#29

Post by xyzzyz »

Oh, how many of us (including myself) experienced such things, and yet we're unwilling to admit that there is something fundamentally wrong with tools that just do what we tell them to.

Re: The classic Unix horror story

#30

Post by devicenull »

die_sekte wrote: post #21
lanstein wrote: post #18

Earlier quoted context omitted.

My marquee move is to shut down the ethernet interface of a box I'm SSHed into.

I used iptables to block all incoming traffic. While SSHed into the server. Thankfully, Linode's out of band console works (slow and painful, but it worked).

I've started using CSF instead of iptables since it's default adds the IP you installed it from to it's whitelist. Along with it's "testing" mode which clears the iptables rules by default every 5 minutes, it's pretty hard to lock yourself out with it.
Post reply on HN