1. 5

    We have commands that can cause harm require a captcha (i.e. “please type this random number and press enter”) when run in a production environment, but no captcha when run in a development environment.

    The idea is that if devops are conditioned to enter the captcha in a development environment, they will be likely to enter the captcha without thinking when running the command in a production environment.

    A similar argument can be made for --no-dry-run; if it is required even in a development environment, devops will be conditioned to always provide it, and the added safety of --no-dry-run will be negated.

    The captcha provides additional safety: it prevents a potentially unsafe command from being saved in the history.

    1. 1

      Do you also have a way to bypass the captcha in order to automate things? If not, this seems like a very poorly scaling solution.

      1. 1

        Yes, there is a way to bypass the captcha for automated tools. This is particularly important when building tools on top of existing tools (in the spirit of the so-called “unix philosophy”).

    1. 3

      How can st be so slow? It’s tiny and hardly does anything!

      1. 4

        Later in the article, the author mentions that it was running on a mac under xquartz, which may explain the latency.

        1. 5

          There is a linux-st entry in the graphs which is significantly faster