Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • It's not something I thought about until one of our R&D engineers mentioned the idea of a "universal undo". For example at the site I work at, we build medical infusion pumps - one end has drugs in a syringe the other end has you. Death by decimal, as it's called is a serious issue and the R&D types take it very seriously. For example if you switch our pumps off it doesn't actually switch off or say "Are you sure?" is starts a count down which the user needs to keep hold of the off button or it carr

    -- "It's not magic, it's work..."
    • Killing the patient is the one thing you can't undo.

      As for universal undo, I've seen elements of this. VMS' versioned filesystem (every time you write to a file it saves a new copy). Smalltalk's everything-is-an-object gives you interesting opportunities for universal undo like a paint program where every brush stroke is stored as a separate object that can be manipulated after the fact. No having to plan out your layers before hand. Emacs' obscenely large kill buffer is another, other apps have that as

      • Killing people is bad, our sales don't do well at all if that happens. Ironically the marketing droids boast about how complex our proprietary software is, when in fact that's probably not something that is not a good feature - thankfully the software is actually quite simple and there is less to go wrong which is actually not bad at all. Obviously we do make it better every release...

        Continuous Data Protection is a trendy form of backup - every change to the filesystem is logged and can be rolled back. Sup

        -- "It's not magic, it's work..."
  • You can't protect the stupid and/or the impatient from themselves. :) For everyone else, there are snapshots and backups. :) Natch.
    • It's important to realize that the user is not stupid, the interface (and by extension, the designer) is. "The user is an idiot" is all too often a way to avoid looking a bad design in the face. This is the overarching theme of The Design Of Everyday Things []. It's like a self-help book for battered users. It's not your fault the computer beats you.

      But users are impatient, and rightfully so. Computers are there to make the user's life easier, not vice-versa. They have better things to do. If anyone kee

      • This can be solved with better tools []. I haven't used that particular one, but I've seen other variations on the concept. If you delete your important file, restore it.

        And, of course, do not under-estimate the value of using a revision control system for system administration...

      • Actually, in most well run userland systems, snapshots and restores are available for the users to do for themselves. I've always aliased rm and a few other commands as it's inevitable that I'm going to fuck up at some point. The downside of command-line power is having the power to do just what you describe. Every Yin has it's Yang.

        And if computers were here to make our lives easier and to give us so much free time then why does it seem like we give them more of our time with each passing year and where

        • And if computers were here to make our lives easier and to give us so much free time then why does it seem like we give them more of our time with each passing year

          BECAUSE THE INTERFACES SUCK! DOET has a chapter on computers that was written, IIRC, in the 80s laying out all the interface design mistakes they're making and why they're so hard to use. Reading it in 2008 is painful because we're still making those same mistakes.

          And where is our star trek future?

          iPhone. It's the closest thing to the ST:TNG PADD [] yet. I just noticed Donald Norman has a new book, The Invisible Computer [] which probably addresses exactly that.

  • The trash can concept is such a useful idea, adopted by all the major desktop operating systems.

    It perhaps says something about geek culture that it is not yet built into major command line interfaces. I wish it was.

  • Obviously the trash can approach is a good one, but it does have its limitations. For example, if this is not your server, then who will take care of emptying the trash on a regular basis? Or, if you use the mv --backup approach, then what if your mv doesn't support the --backup option or if you don't want to see numbered backups of each file in your directory?

    I've taken a different approach, which I haven't seen anyone mention anywhere else and which is universal across all unixes: I alias rm to a sho

    • The point was not the details of the implementation, you can write trash dozens of different ways and trash automation isn't necessary its just convenient. The point is the interface, what its training the user to do and if its really protecting against the consequences of slips.

      Your solution still contains the key problem: training the user to ignore the prompt. It just reduces it somewhat, but the really annoying case remains: the big list of prompts. Yes. Yes! YES! YES!!

      Slips are something that hap