Hacker News Reader

> I load main vim instance with a fair amount of specialization (but probably less than most)

Perhaps it's just that the people who diligently curate their .vimrcs are more prone to talk about it than people who use stock or minimally configured vim. I can tell you my .vimrc right now without looking at it.

    se sm
    se hls
    se number
    se ts=4
    se sw=4
    se expandtab

It's not very exciting. Nobody ever writes a blogpost on the virtues of a vimrc that looks like this one.

Ha, I see that your .vimrc is almost identical to mine in functionality, even if mine is riddled with mostly superfluous additions and lots of comments. What you've got there though is probably what I would consider the core things I would need to set in vim to get my desired experience on a new workstation if I didn't have my own .vimrc to download, all the way down to the number of spaces for expanded tabs.

The rest of the stuff I have boils down to history size, a fixup for backspace in insert, default paste mode and quick key to toggle it, how far from margins to start scrolling, and turning off swap files so editing very large files is easier. Oh, and the Pathogen init stuff, for which I have usually have no modules installed (but I test out stuff occasionally), but there it sits.

The minimalism reminds me of http://openbookproject.net/pybiblio/tips/elkner/vim4python.p... , which was written by my CS teacher from high school, and has survived me ~10 years.

I've got a decade-and-a-half .vimrc that I stopped using last year. I used to rsync it up to other machines before I would SSH into them.

Now that I've gotten out of it, I see that there are only a few small customizations that I really enjoy, but none that I need. And I can now use VIM on any machine.

Just to make it more efficient :)

"instead of se number

se nu

I thought that this would be the case and initially stuck mostly with defaults, but it didn't really turn out to be true. You won't forget how to use vanilla vim unless you really go crazy and replace all keystrokes. Turns out you don't forget how to play clarinet after learning saxophone.

I thought that this would be the case and initially stuck mostly with defaults, but it didn't really turn out to be true. You won't forget how to use vanilla vim unless you really go crazy and replace all keystrokes.

I’ve found this to be true. I’m getting a little annoyed with the narrative that it’s best not to customize Vim much because you won’t have those customizations on the generic boxes you’re working on.

You don’t forget vanilla Vim; to me, that’s kind of the point. You’d be surprised how much of generic Vim becomes muscle memory and you do things you haven’t thought about in a while. When you become a proficient Vim user, it kinda just happens.

However, I hardly ever read anything advocating for a different approach: using Vim’s netrw support for ssh, scp and several other protocols from your main machine, allowing you to use your fully configured Vim to edit files on those machines you’re performing sysadmin tasks on.

Once you’ve configured things, you can just

    vim scp://[user@]machine/path

Obviously this won’t always be an option, but when you can, why not? Netrw is a plugin that comes with Vim, so even Vim minimalists can use it even if they have zero 3rd-party plugins installed.

It’s even in Vim’s docs:

http://vimdoc.sourceforge.net/htmldoc/pi_netrw.html#netrw-ss...

http://vimdoc.sourceforge.net/htmldoc/pi_netrw.html#netrw-tr...

I didn't mean to give the impression that you forget vanilla Vim, more that it becomes somewhat painful to use as you deal with the absence of what you've come to expect.

It doesn't really matter much whether you use tabs or spaces, or how many spaces a tab key (or tab character) represents, but having to swap between them multiple times a day gets... tiresome. There's a fluidity that comes with your tool behaving how you expect, and a time of acclimation when it changes. Whether the benefits of either keeping your config close to stock to reduce this acclimation period or highly customizing your personal Vim to be as efficient as possible is the better solution probably depends on the individual and the relative amount of time spent in each environment.

I'm not really urging one approach over the other, but rather noting that one should be cognizant of this, as it may allow for better decisions at different times. I, for one, found certain Vim customizations to be not worth the effort at one point when I was doing a lot of remote Sysadmin work, but worth investigating more when my time in Vim shifted more towards being used in one main instance.

As a simple example, if you spend 80%-90% of your time on remote servers, how useful is it to install Nerdtree on your main instance and spend the time configuring and learning how to use it well? Are the keys to Vim split windows and resizing better, or perhaps figuring out how to do that in screen/tmux is more effective a that time (can that be assumed to be on the servers?).

If nothing else, I think it helps explain why some people are so enamored of some Vim plugins, while others try them and consider them "meh".

I’ve always found it rather trivial to scp my config onto the server, initialize the package manager and have it available everywhere.

It's a matter of scale. With a small amount of servers and people expected to be on them, it's not much of a problem. Once you scale to tens or hundreds of servers, and if you have multiple admins, if they don't each get their own account, you run into problems where pushing your config may conflict with someone else's config (or you must remember to set or push ENV vars on or after login).

1 admin with 1-10 servers is not much of a problem. As the number of admins and/or servers scales up, it starts becoming much more of a problem. I've worked in environments with 1-2 admins and <10 servers, and in environments with 20+ admins and hundreds of servers. In the latter environment, if you left an altered Vim config on a shared admin account, that's likely something you would be called out for, and rightly so. If anything doesn't look right when you're called onto a server at 3 AM to fix some random malfunction that's hard to diagnose, you start grasping at it as something that needs to be ruled out as part of the problem. Irate early morning emails from annoyed sysadmins over inconsistent server state are common.

> and if you have multiple admins, if they don't each get their own account

You really should have your own account on each machine. Deploy them via some push method like ansible, or some pull method like a daily cronjob. You can push a .vimrc out with them too.

You state that as if it's a given, but I find that any increase in deployment complexity should be carefully considered. Rarely have I found "we can do this, so let's do it." a useful strategy in the end.

As a very simple example of one of one possible downside of multiple accounts, consider an admin team with a high level of account additions and/or deletions (this does not mean quick turnover, it's also easily achieved through a large enough team). How robust are your routines for removing accounts when unused? How easy is it to check that every server is in a clean state? How much does it complicate and reporting of accounts on servers that have shells assigned to them or allow login?

Simplicity has it's own benefits. Sometimes additional features are well worth the complexity cost, other times they are not. This is basically the same theme I initially stated with regard to Vim customization itself. Another way to look at it is as the Waterbed Theory of Complexity.[1]

1: https://en.wikipedia.org/wiki/Waterbed_theory

> How robust are your routines for removing accounts when unused?

For our main corporate server list (about 1000 servers and 50 users), disable account in ldap and password authentication no longer works (so they lose sudo). Takes about 5 minutes to replicate I believe. If they have a .ssh key they can still log on until the local account is disabled, which runs daily.

The 100 or so servers outside the corporate walled garden, with 10 users, simply have to wait for a day for the account to be disabled - or run a bash script from rundeck to kick it off earlier. The CRL cache-time on their client certs is longer than that in any case so it's not top priority. I last did this 3 weeks ago. We didn't want central authentication for non-walled-garden machines as there's a good chance many of them may be used offline, both via ssh and local access.

It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog.

How do you prevent an ex-employee logging in without a generic account, other than changing credentials and authorized keys? I'm assuming it was a mutual termination and you don't need to worry about backdoors (because if you do, you're screwed regardless)

But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix?

> It's far easier and less error prone than having to change credentials and authorized_keys for generic accounts everytime someone leaves. You've also got the benefit of knowing who's logging in to each server, as I assume your auth.log is also fired off to syslog.

I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes. Access removal is removal of their key and running a command that uses scp to upload a new authorized_key file for all servers. Using xargs and parallel jobs, than can complete within a minute or two even for 1000+ servers, errors are easily visible, any problem in the process is easily troubleshot, and if worse comes to worse and the system isn't functioning, you can manually update the authorized_keys on a few servers that need it ASAP. No LDAP config, requires, and anyone with basic SSH understanding can diagnose and understand what's required to fix an error within a minute or two. Give me another 30-60 minutes and it would support a config file with user groups and assigning group or individual access to servers.

There are features you don't get with that, but it's dead simple and very robust. LDAP is good, but if all you need is to set up admin access to Linux/BSD servers, it also might be overkill and cause the occasional headache. There's a huge range between manually configuring every server for every change and using LDAP for account access.

> But forget nefarious purposes -- if you have a problem on a machine and you see that "admin" was logged on at the time the problem started, how do you know who "admin" was so you can work on the fix?

SSH allows environment vars to be passed along with the authorized key file. You can set your default EDITOR for example, but your push system can also append a specific variable that denotes who the actual user was that connected, and your login config can log it to a file as you connect. There are simple solutions for most things you would want in this space. Once there isn't a simple solution, then maybe the value of a centralized authorization system might show itself.

> I can write a system (and have, multiple times) that takes public keys from people in a file named by their users, aggregates them into a single authorized_keys file, and pushes it to the admin account on all the servers in a list in 5-10 minutes.

The modern way to do such a thing would be using ansible, which just as easily allows you to create/delete user accounts.

While custom vim settings per user are nice to haves, the biggest benefit is AAA. I'm not sure what type of auditing you can realistically do with, you'd have to trace through machine logs to find the IP of origin for a given pts, and hope that the dhcp server still has.

Yes, any Unix-like system will almost certainly have vi available. I'm a emacs use for 3 decades but I know enough vi to make small changes to config files.

Was never able to adopt it as my main editor. The bifurcated input/command modes always trip me up.

FWIW this article specifically is mainly for common traps (e.g. spamming arrow keys) in vanilla vim.

Yes, I changed my initial sentence slightly (you can see the difference in the quote of the original that vram22 included in their reply) to reflect my real intent is to call attention to the context many Vim articles and comments, and not necessarily this specific article. I didn't append an edit note as I often do (even though it was more than an hour after initially commenting) because I considered it a small clarification of my intent, but one was probably warranted. I'll consider your comment and this reply as that edit note now. :)

I agree. I prefer graphical IDEs which plays well with my operating system for software development. However, you still need to know just enough vi in case you are remoted into someone else's computer

Ubuntu 1804 comes with vim 8.0, rather than 7.4

Not sure if it's ubuntu or vim, but it comes with some really annoying changes that haevn't been this jarring since moving from solaris-vi to the vim bundled with ubuntu (vim-nox) over a decade ago.

The two most annoying things I really noticed and massively reduced my efficency

  1) Get about 6 lines from the bottom and the cursor no longer moves.
  2) Search moves the window as you're typing

It really pissed me off

1) That’s scrolloff, `set scrolloff=0` to remove this function altogether (I keep mine set to 2)

2) That’s incsearch, `set noincsearch` to turn it off.

Oh sure, but it means having to have a .vimrc for consistency.

My own desktop's vimrc has a few useful shortcuts (F5 for example to "compile" a graphviz file to dot -T x11 -- my VB3 roots showing), but the majority of vim use across the estate has never needed it before.

Fortunately I do have a facility to distribute .vimrc to undo these disastrous changes, but changing the default behaviour was rather annoying for an editor that is so ubiquitous.

I had the same initial reaction to 2) (incsearch) at first after having to work in a shared environment with it enabled. After a little while getting used to it I found it actually sped up my workflow quite a bit! YMMV, but you may find it worth the time to leave it on a little longer and see if it works for you.

I do a lot of sysadmin stuff and go crazy when I need to do anything except copy/paste, and insert. I really want to sit down and learn vim for those tasks but usually just end up opening nano and going about my business.

One problem I've found with vim is some weird character buffer thing happens where my text stops displaying or something. I've never investigated it but its probably SSH itself.

Do you accidentally press Ctrl+s to try and save? That tells the terminal to stop sending text (eg if a long command output was scrolling by). Try Ctrl+q to fix it next time it happens.

It is entirely possible. I'll have to be more cognizant next time it happens and catch myself if that's the case.

I believe this fixes that behavior while vi is open: https://github.com/fiddlerwoaroof/dotfiles/blob/master/zsh/z...

Newer versions of Nano actually do save the file on CTRL+S.

Didn't pico as well?

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. :-)

Well, 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.

I 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.

The 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.

>It's important to note the context of this article, and most the responses, which is Vim for developers (or at its most general, Vim for sustained local use). The reason I bring this up is that there's a whole other set us use that is often overlooked, which is Vim as a standard tool for sysadmins.

>Any system you connect to will have Vi, and probably Vim. This makes it an ideal tool for sysadmins that might need to connect to tens or hundreds of systems to know how to use, and to have a fairly standardized behavior. In those cases, having a customized config can actually be more of a hindrance, because switching from a highly customized local Vim instance to a stock remote Vi/Vim instance can be jarring.

That's a great point. I had mentioned something to the same effect, briefly, in the blurb for my vi quickstart tutorial, here:

https://gumroad.com/l/vi_quick

I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc.

Edit: Since vi is mostly a subset of vim, the tutorial works for vim too.

Regardless of customization points, I find using Vi after Vim quite confusing.

if you dump your customizations into github you can customize on whatever server pretty quick. or at least some subset of your settings that would be safe to pull down on the servers you work with.