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.
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.
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”).
How can st be so slow? It’s tiny and hardly does anything!
Later in the article, the author mentions that it was running on a mac under xquartz, which may explain the latency.
There is a linux-st entry in the graphs which is significantly faster