3 ms·
I do not understand the: "don't customize your VIM, what if you have to use vi/vim on a server?" trope. I submit that if you're having to log into individual
by Tehchops 8y ago
I do not understand the:
"don't customize your VIM, what if you have to use vi/vim on a server?" trope.
I submit that if you're having to log into individual servers enough to make those kinds of changes, you're already engaged in a systems management anti-pattern.
Code up some CM/automation to handle that.
You can probably write that code from your workstation, with your more customized Vim. :-)
- kbenson 8y agoWell, part of the reason you are having trouble understanding it is that you've simplified it all the way down to a trope, which necessarily misses a lot of the nuance of what I sad. I mean, I don't even agree with "don't customize your VIM, what if you have to use vi/vim on a server?", so why would I expect anyone else to? If I had to distill my point down to a sentence, it would be "be cognizant of your tools and their usage paradigms, and whether large customizations to one paradigm and how it might affect the overall usability, or your perception thereof, of the others." Yes, it's wordy, but that's simply because not everything is easily reduced to a pithy one-liner, at least not without a large loss of context.
- Tehchops 8y agoI don't think I'm missing any nuance. You wrote: > For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior Am I reading that wrong? "Don't customize the default behavior if you're a sysadmin" Do you not agree with what you wrote? I'm simply arguing that, as a sysadmin today, you're far better served eliminating the need for N node access to make changes, and using your customized local config to push changes to a repository that is applied by a CM-esque system.
- kbenson 8y agoThe entire sentence was (including typo of "trade odd" instead of "trade off"): For anyone who is primarily a sysadmin, I would recommend sticking with the default behavior (which is rich, and lends itself to being more and more useful and they become familiar with more an more commands), and making a minimum of local config changes and plugins to suit their needs (it's a trade odd. Just choose wisely). The key (corrected) part you're missing is "it's a trade off. Just choose wisely." I go into more detail on that in subsequent comments to other replies. > I'm simply arguing that, as a sysadmin today, you're far better served eliminating the need for N node access to make changes, and using your customized local config to push changes to a repository that is applied by a CM-esque system. That good for many things, but not really an adequate solution for diagnosing a problem under stress.