Live data from Hacker News

The classic Unix horror story

lug.wsu.edu

51–54 of 54 posts

Re: The classic Unix horror story

#51

While part of a team of students at a hacking competition I was VNC'ed into an owned 2003 server, I was trying to get to the network settings properties menu, when my VNC session lagged and I clicked at the same time that my mouse reached the Disable interface. Yeah ... I didn't live that one down, lost my team some points.

I've seen that done on live remote Windows servers at work - lag causing someone to hit disable on the network, causing someone to hit 'bridge' on the network card, causing someone to hit 'shutdown' instead of 'restart'.

One reason I really prefer text commands, as the sequence is preferred, so they can be typed and "queued" to execute in order when they arrive.

Re: The classic Unix horror story

#52
post #44

This makes Unix's orthogonality really clear. I'm fascinated the system was still able to run after taking that kind of a hit. Imagine what would happen to WIndows (immediately) if half the system (including key system binaries) were destroyed.

I'm going to guess, if they're in use you wont be allowed to delete them, and then you'd be in a similar situation - things like notepad would be missing, various programs wont start due to missing dependencies. In fact, we can see from Youtube: Ubuntu: http://www.youtube.com/watch?v=D4fzInlyYQo Windows XP: http://www.youtube.com/watch?v=0aSo8-VDS8E XP appears to hold up slightly better - it doesn't ruin the fonts, a…

My overall point is that Windows (in my experience) breaks at the slightest registry change or missing DLL or config file. Linux/Unix try to be as loosely coupled as possible, which means you can still run your in-memory gnuemacs (as in the article) even when your /bin directory (presumably with supporting binaries for emacs) gets wiped out.

That kind of design takes a lot of thought and, as far as I know, doesn't hold true in DOS/Windows.

Re: The classic Unix horror story

#53
post #20
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 is too late to edit my above comment but I should point out that there is a typo there. That should be:

    tar -c *.cpp -f something.tar

Re: The classic Unix horror story

#54
The Unix Haters' Handbook is worth looking up. I think it is out of print but the PDF is available for download.

My favourite from USENET is cleaning out .o files after compiling C code but fat-fingering the SHIFT key and instead of typing

% rm -f \.o

,typing

% rm -f *>o

which gives you an empty directory and a zero length file called "o"

ah yes....

Post reply on HN