>> This justification for bash has always been perplexing to me. If I’m operating in an environment where my ONLY reliable infra invariant is “bash will probabl

>> This justification for bash has always been perplexing to me. If I’m operating in an environment where my ONLY reliable infra invariant is “bash will probably work”, cleaning up the org’s infrastructure clusterfuck is probably my #1 priority. > That is not your job. This sort of thing is definitely your job have the word "Principal" in your job title, and probably also if the word "Senior is in there as well ;-) And in any case everyone is responsible for excellence in the milieu in which their team operates. If Senior or even fresh grad Jr. comes to me with a solid good idea I'll champion for it as if it were my own baby. And then recommend/fight for rapid promotion in the case of Jr or put in a good word for promotions for the Sr. If you recommend your org have standardized images with well-documented info about language versions etc. and the answer you get from your management/tech leadership is "not your job", I recommend finding a new job. > Adding a new package means going to the production committee with your proposal and justification and analysis of the increased threat surface. The context of my quote was "knowing which version of ruby/perl/python is installed". There's almost certainly a version of one of those on your standard linux machine, and everyone pushing to prod should damn well be able to look up exactly which one. > Adding a new package The general debate here goes way beyond adding a new package. Good infra needs WAY better invariants than "definitely bash is installed in the usual place". If a concern is "IDK which version of Ruby is installed on the machines I'm targeting" then either you're fighting fires and need to keep every intervention really damn simple or else your org as Real Issues. In either case, bash is the enemy. > The defaults are everything. Those defaults aren't handed down from Gods. Your org chooses them.