1. 20
  1.  

  2. 5

    Reminds me too of how on Macs the hotkey for “close this window” (Ctrl-w) is right next to the hotkey for “close this application and lose all tabs/unsaved work/context/everything” (Ctrl-q).

    At least Chrome prompts you to hold the Ctrl-q hotkey down to confirm you really meant to suddenly lose everything.

    1. 1

      Separately, now I’m imagining a CLI help text linter that looks for confusable flags (based on common keyboard layout adjacency, homoglyphs, or common confusables like ‘I’ and ‘l’) and recommends changing them.

      1. 1

        This made a lot of sense in 1984, when if you hit Cmd-Q by accident, you’d just be prompted to save unsaved changes in the document you were editing, and even if you had enough RAM to hold two or three unmodified documents open at the same time and hit Cmd-Q, it wasn’t a big deal to find and re-open them among the dozen or so documents that fit on your floppy disk.

        This all changed in the mid-to-late 90s with web-browsers, where suddenly web browser applications had “documents” that couldn’t be modified (so the “unsaved changes” dialog was no longer a protection against losing state), and you might have a dozen documents open, chosen from among uncountable billions.

        1. 1

          I don’t know about Chrome, but Safari will reopen all tabs. It’s still annoying because I might be logged out.

        2. 4

          I think one possible lesson to take from this is that it’s worthwhile to lock down our access to production systems as much as possible, and make it inconvenient to do dangerous things. Now I’m wondering how I can meaningfully do that in my tiny company, where I’m currently the only dev and sysadmin.

          1. 1

            Have a separate dev/ testing and production system.

            Having to use a different machine for production things makes it harder.

            1. 1

              You take the example of the article, someone looks at the logs on prod, runs the command on the same host, done.

              Having separate environments is good, but doesn’t solve this problem.

              Having logs ingested into your monitoring platform for query would have 1. Parsed the date and 2. Avoided the employee to connect to the host.

              1. 1

                As the only person on the servers, you either automate prod stuff away or you reduce the chance of error to only one person anyway

          2. 4

            My common typo used to be crontab -r instead of crontab -e

            1. 2

              A couple of lessons I remember from AWS:

              1. Destructive commands should have destructive names.
              2. Operational tools must be code reviewed just like production code.
              1. 2

                That issue with date reminds me of a case with the hostname command where at some point we noticed that the hostname of one of the Solaris servers had got changed to -d. The assumption was that someone’s Linux specific script was trying to get the fully-qualified hostname but was setting it on Solaris.