• TR (unregistered)

    Wtf? These things happen. It's called learning..

  • The OLD Geek (unregistered)

    Ah, the days when the Iron was Big, the code was small, Memory was limited, and programmers were REAL programmers - and yeah, I still have a few boxes fo punch cards - I use them as scratch paper, and to leave notes on peoples desks

  • nub (unregistered)

    Yes, but you usually want to learn these things BEFORE you bring an entire mainframe to a screeching halt. Meaning, if you've never done it before, let someone else show you how, especially if you're dealing with system critical production servers...

  • bramster (unregistered) in reply to nub

    It's not a WTF. It's an "Oh, Shit"

  • (cs)

    Typos are dangerous. I had a former co-worker who was learning SQL. Instead of using the pretty web based interface, he decided to login to the server and feed it a manual delete command. He wanted to format his code nicely but wasn't familiar with line wrapping. Apparently he'd seen semicolons in SQL syntax before and wanted to give it a whirl

    DELETE FROM ip; WHERE ip='172.16.0.1'

  • regeya (unregistered)

    #rm -rf / tmp

    will ruin your whole day.

  • (cs) in reply to akatherder
    akatherder:
    DELETE FROM ip; WHERE ip='172.16.0.1'

    SQL Reeeeeeeally needs a SET DELETES_AND_UPDATES_REQUIRE_WHERE_CLAUSE 1 option.

    And it should be on by default.

  • Gotem (unregistered) in reply to Maurits

    what would that solve? you still ahve the problem when your where clause returns always true, the users need a SET THINK_BEFORE_YOU_HIT_ENTER 1

  • Maik (unregistered) in reply to regeya
    regeya:
    #rm -rf / tmp

    will ruin your whole day.

    Talk about deleting all "dot" files and folders in the current directory:

    rm -rf .*

  • AdT (unregistered) in reply to Maurits
    Maurits:
    akatherder:
    DELETE FROM ip; WHERE ip='172.16.0.1'

    SQL Reeeeeeeally needs a SET DELETES_AND_UPDATES_REQUIRE_WHERE_CLAUSE 1 option.

    And it should be on by default.

    That's simply why you do disable autocommit.

  • A non-e mouse operator (unregistered)

    Ha, ha. Reminds me of the 'old' days (note the absence of 'good').

    We used to accumulate dump reports from all the testing during the day, so they could be printed off in one run overnight. It was the operators duty to enter $oj1-9999 to release them.

    Damn Mr. Qwerty for designing a keyboard where the 'o' (for release) was so close to the 'p' (for purge, which deleted the data). Of course, I was the operator who had the misfortune to enter $pj1-9999 to purge not only the dumps, but delete all the operational output at the time, including some of the most critical reports.

  • jwilson (unregistered) in reply to akatherder

    Oh, I think I am going to be sick, give me a second....

  • Alex (unregistered) in reply to Maurits

    MySQL actually has exactly this. You get this behaviour when you start the server with the switch "--safe-updates" (or, very appropriately "--i-am-a-dummy")

    Very nicely written article, Alex!

  • Carl T (unregistered) in reply to Maik
    Maik:
    Talk about deleting all "dot" files and folders in the current directory:

    rm -rf .

    rm: cannot remove `.': No such file or directory

    This is the future. It's dull.

  • mickey (unregistered)

    love the reference

  • MadPad (unregistered)

    For a horrible moment I thought the title referred to the magic programming language http://www.trillium-sw.com/sorcerers_apprentice_referrals.htm

    I was once asked to switch from java to that, funny i dont work at that outfit anymore but i still get shudders at the mention of The Sorcerer's Apprentice.

    Now there was a real wtf of a language!

  • Frzr (unregistered)

    Quoth the Raven, "/CHE DUMPQ".

    captcha: tacos

  • PeriSoft (unregistered)

    Typos can be hell. One time, when I was learning GWBASIC, I typed "RUIN" instead of "RUN". It wasn't pretty.

  • (cs)

    That picture is hilarious. Nice job with the article, as usual.

  • Mikademus (unregistered)

    Highly entertaining, but as said above, not a wtf. Perhaps the site should be renamed "The Daily Anecdote From the Past", or maybe a new section (in green?) should be added alongsite the Daily WTF and Daily Code Snippet...

    Captcha: vern (the real WTF is that "Verne" is misspelled, but that's ok, he was never a coder)

  • (cs)

    Too bad crtl-z isn't a universal command...

  • Jeremy (unregistered) in reply to Maik
    Maik:
    Talk about deleting all "dot" files and folders in the current directory:

    rm -rf .*

    Ouch. I did that once when trying to clean out hidden files from a home directory for a defunct user account. I'm just really glad I didn't execute it as root! It dropped down to the /home directory and started giving permission errors before it hit my personal $HOME directory. It took a few minutes for my heart rate to return to normal when I realized what was going on!

  • no one in particular (unregistered)

    The original problem, the S106, is trivial anyway.

  • Anonymous (unregistered)

    Computers are not brute force machines. A insiginificant effort mean devastating effects (check the aforementioned rm commands). Thats equal to magic. And with magic come responsabilities.

    What is good about forcing a huge and powerfull machine to halt, is that the effort to fix and cleanup can be giganteous and still afordable, giganteous enough so newbies become veterans... and thats how we learn.

    What is sad, again, is that on the GUI style UI is much harded to fix a huge error. With Text UI you can mostly fix some errors with another commands, or perl scripts, but on a GUI a huge error mean hundreds of clicks on windows. And is not fun.

  • (cs) in reply to TR
    TR:
    Wtf? These things happen. It's called learning..

    Learning should be done on something small, and insignificant. Learning on a mission critical mainframe is dangerous. If he wanted to learn, I am sure the Sorcerer would have pointed him in the direction of the least significant terminal where he could get comfortable with the commands, before trying them out on the mainframe. But I do agree with you, messing things up is a fundamental part of learning.

  • steven22 (unregistered)

    what's a mainframe?

  • mdpdb (unregistered) in reply to wgh
    wgh:
    That picture is hilarious. Nice job with the article, as usual.

    yeah, Alex, i'd like to give you props for the amount of time you spend writing up (and sometimes visually enhancing) these WTFs. it's what sets this site apart from a random smattering of forum posts.

    CAPTCHA: waffles

  • Franz Kafka (unregistered) in reply to Maurits
    Maurits:
    akatherder:
    DELETE FROM ip; WHERE ip='172.16.0.1'

    SQL Reeeeeeeally needs a SET DELETES_AND_UPDATES_REQUIRE_WHERE_CLAUSE 1 option.

    And it should be on by default.

    Or you don't give delete privs to newbie sql programmers. Actually, running a delete on production data is almost always a mistake.

  • ringbark (unregistered) in reply to Jeremy

    I remember the days when people would find an unattended screen, and enter the command $ touch * and then clear the screen. Sooner or later, the hapless user would find the file created, notice that it was a useless file with no content, and delete it. Unfortunately, they sometimes didn't think through the consequences of their actions...

  • (cs) in reply to mdpdb

    I think that you aren't really experienced until you've accidentally managed to trash a {mainframe|db server|root file system|network config file|...}

    But I agree, Alex's writing is the best!

  • Zylon (unregistered) in reply to Mikademus
    Mikademus:
    Highly entertaining, but as said above, not a wtf.
    It's almost as if you think anybody cares.

    You laughed, be happy with that, STFU & GBTW.

  • Blake (unregistered)

    That's awesome, because anyone who has done systems work at some time has completely broken something early in their career. If you haven't, you actually just repressed the memory and don't realize what you did.

  • SwordfishBob (unregistered) in reply to snoofle
    snoofle:
    I think that you aren't really experienced until you've accidentally managed to trash a {mainframe|db server|root file system|network config file|...}
    .. or burnt out a $20,000 motor through poorly planned logic.
  • (cs) in reply to TR
    TR:
    Wtf? These things happen. It's called learning..

    Today, no big deal. 20+ years ago, he's lucky he kept his job. You're in a situation where you can cripple a system that has no backup, which will cost a literal fortune to repair, and will utterly shut down your business while it is off line...Back then, it wasn't like they could just do their work locally...Every damn machine that connected to that mainframe was a dumb terminal (or a printer), completely worthless without the mainframe.

    It's totally different these days, but back then, you damn well better not be learning on the mainframe if you don't damn well KNOW what you're doing.

  • Mike5 (unregistered) in reply to Maik
    Maik:
    regeya:
    #rm -rf / tmp

    will ruin your whole day.

    Talk about deleting all "dot" files and folders in the current directory:

    rm -rf .*

    Which reminds me... A nice thing to do (if you're so inclined and have such users) is to create a file in the user's home directory called "*". As someone else noticed, some people hit enter first, and think later :)

    Captcha: It wasn't me! "ninjas" made me do it...

  • (cs) in reply to SwordfishBob
    SwordfishBob:
    snoofle:
    I think that you aren't really experienced until you've accidentally managed to trash a {mainframe|db server|root file system|network config file|...}
    .. or burnt out a $20,000 motor through poorly planned logic.

    Or how about burning out the handbrake on a $100k Forklift simply because the lever worked opposite from the $30k forklift?

  • Anon (unregistered)

    Like one of my mentors used to say... this is a guy I want to hire because I'm guarenteed he'll never make that mistake again.

  • (cs) in reply to regeya
    regeya:
    #rm -rf / tmp

    will ruin your whole day.

    I've seen that one myself. That fricking SPACE...Especially when you're dumping a log directory or something, and you're using a hugely long directory name... rm -fr / usr/local/apps/parsers/cash_batch_parser/logs/ldirs/2005*...It's hard to see, especially when you're looking at the end of the string.

    That's why you don't run as root, and you only chmod as much as you absolutely have to...733 is your friend.

  • Mike5 (unregistered) in reply to Mike5
    Mike5:
    Which reminds me... A nice thing to do (if you're so inclined and have such users) is to create a file in the user's home directory called "*". As someone else noticed, some people hit enter first, and think later :)

    Ah well, someone beat me to it...

    You know what: muhahaha

  • Jeff Saxe (unregistered)

    I'm a network engineer, and I vividly remember executing one "oh, crap" maneuver that taught me to think before hitting Return. It was early on in my learning, and we had a remote call center that was doing IP and Voice over Frame Relay off our main headquarters. So basically one router here was a single-point-of-failure lifeline to over forty remote employees; hose up the router here, and all those customer phone conversations disappear and the agents' computers become useless.

    One day we were having a modest networking problem... I don't remember the details, but something on one side was persistently unable to talk to something on the other side, and I was trying to figure out why. There are many ways to investigate this, including several that are completely passive and do not involve messing with the equipment that's moving the packets. But I was young and stupid, and I didn't know any of those methods, but I did know something that looked cool when I'd read about in the documentation: "debug IP packet", which causes the router, while it's moving the packet from one place to another, to print out some details of the packet onto a terminal session, or to its console serial port. You Cisco experts out there know that the documentation also says, in big bold type, "Caution! Don't type this in on a production router on a busy network! Or at the very least restrict the debug with an access list so it shows you only a very small fraction of packets, not every single packet!", or something to that effect. I must not have noticed that part.

    At any rate, as soon as I entered the command, debug messages started flying up the screen, and although I knew I should type "undebug all" somehow, it was very difficult to type anything; the router was spending all its CPU preparing debug messages and desperately trying to route packets. (This wasn't one of those newfangled hardware-accelerated platforms, either... the main CPU moved pretty much every packet and voice frame.) I had to do something very intrusive like pull the Ethernet cable or reboot the router, and of course while the outage was occurring I couldn't call the users at the remote site to explain, because I had just busted their internal phones.

    So yeah, I did something dumb and inexperienced on a critical device in the middle of the day with nobody watching over my shoulder, and I turned a minor problem into a complete failure. It only took once, though... Now I'm appropriately careful.

  • fmtaylor (unregistered) in reply to Mike5

    My personal favorite trick is touch -i in /

    Saved me once or twice...

  • el jaybird (unregistered)

    Within my first two weeks on the job I managed to write a multi-threaded program that had a wee little bug.

    Strip out all the good stuff and my program ended up being:

    while(1) { fork(); }

    ... did I mention the entire floor uses the same server for everyone's software development?

    By the time I realized what was going on it was too late. The call from the IT guy came about 5 minutes later.

  • Gimpy (unregistered)

    Similar experience - working on a DOS mainframe (yes! It was an Amdahl), I was an operator for the summer working C shift. At the console, we would routinely hit the "J" key to clear the screen. I accidentally hit the "K" key which managed to dump working memory to the card reader queue. It took the graybeards about 7 days to figure out how to get it back. I was relegated to getting and mounting 9-track tapes for the next month.

  • JCMay (unregistered) in reply to KattMan

    Or how about making a 30-meter-diameter satellite dish jump because it has TWO elevation drive motors, each one with a brake, but only ONE gets energized?

  • JCMay (unregistered) in reply to KattMan
    KattMan:
    Or how about burning out the handbrake on a $100k Forklift simply because the lever worked opposite from the $30k forklift?

    Or how about making a 30-meter-diameter satellite dish jump because it has TWO elevation drive motors, each one with a brake, but only ONE gets energized?

  • (cs) in reply to Maurits

    A long time ago, my colleagues and I were tasked with implementing a distributed network monitoring behemouth. In those days, such commercial beasts were not quite up to what we were asked to build. In general, the team was pretty good, but one guy, The Wizard, was exceptionally brilliant (intentionally spelled with two i's).

    One of the requirements was that if one of the processes went down, the processes on the other nodes would negotiate to take control, and attempt to restart the failed process.

    Time passed, and it was Demo-Day. We set it up on all of our development workstations, and illustrated how, if a process failed (illustrated by a polite kill -9), it would automatically restart. The Powers That Be, and The Wizard were pleased.

    Then it was time to shut it off. The Wizard entered yet another kill -9, but the process kept reappearing, but with an increasing process id. Whoops! The only way to shut it down was to literally turn off all of the development workstations. Time to implement the shut-down-on-purpose command.

    It appears that brilliance and common sense are inversely proportional in some folks.

  • bofh69 (unregistered) in reply to ringbark
    I remember the days when people would find an unattended screen, and enter the command $ touch \* and then clear the screen. Sooner or later, the hapless user would find the file created, notice that it was a useless file with no content, and delete it. Unfortunately, they sometimes didn't think through the consequences of their actions...

    My favorite variation of this was:

    $ touch -- * -rf

    Which makes it just that much more destructive. Even if you didn't (initally) fall for the -rf file name, doing an

    $ rm *

    would still result in actually doing

    $ rm -rf *

    after wildcard expansion.

  • Reed H. (unregistered) in reply to Jerim

    "Learning should be done on something small, and insignificant. Learning on a mission critical mainframe is dangerous. If he wanted to learn, I am sure the Sorcerer would have pointed him in the direction of the least significant terminal where he could get comfortable with the commands, before trying them out on the mainframe. But I do agree with you, messing things up is a fundamental part of learning."

    The whole point of a powerful, capable, "main frame" design is that you only need to buy one.

  • (cs) in reply to steven22
    steven22:
    what's a mainframe?

    roflolpmp!

    Ah, so, you want to know what a mainframe is, do you?

    You know you're puny little PC that you are using now to read this message?

    Yes?

    Now, imagine about 10,000 of them bundled up into a single unit, running all text-based, in an OS that only a true sorcerer would appreciate--it doesn't even use ASCII, but something alien known as EBCDIC. Where if you want it to do anything, you've got to bundle that process in something known as JCL ("Job Control Language") so that it can run somewhere in the middle of thousands of other processes. Where you'd better brush up on your ability to read hex (and not just so that you can cast one).

    Ah, yes--the mainframe. You ever read "The Hitchhiker's Guide to the Galaxy?" Think of the mainframe as a baby "Deep Thought".

  • (cs) in reply to It's a Feature
    It's a Feature:
    steven22:
    what's a mainframe?
    ...Think of the mainframe as a baby "Deep Thought".

    You, Sir, have a way with words :)

    <edit> Ok, I give up: how do you enter html tags in this new forum software?

Leave a comment on “The Sorcerer's Apprentice”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article