The biggest thing to remember is that any command you run will be in a local context. For example, if you want to do things like updating a SVN repo that's located on the server you've mounted, you should SSH directly into the server and perform it. Otherwise, your _local_ SVN software will try to read in tons of files FROM the server to establish changes in the checkout before it can even try to commit. This can be very slow!

^^Very good point.

On OSX with MacFuse and SSHFS, I've done plenty of remote work before on LAN servers and "internet" servers. It definitely works, but is slow. But for being able to open up a "local" file in Vim/text editor and then save it, the only time you are hitting the network is during the save and that can be slow.

Transmit 4 integrated this functionality into their FTP client, auto-mounting of SSH connections, but it definitely seems more crashy than MacFuse to me.

If remote editing vim is your only requirement, it should be noted that up-to-date versions of vim will handle scp://, as in "vim scp://hostname/file_to_edit". (Emacs users have Fish) (you should already have ssh keys setup)

Thanks for that. You've just removed 90% of my use cases for opening an actual shell on the remote server.

I've been using vim for a decade or more. I guess it's a salutary lesson for experienced users. I should read the Changelog more carefully when upgrading.

As already noted, commands that deal with a lot of data will copy that data to your machine to process, and copy it back. This is a drawback of both NFS and sshfs.

NFS, however, doesn't encrypt, while sshfs does, so if you don't care about encryption, NFS will be a lot faster.

The proper way to do what you want is to install those desktop tools on the remote machine, and then use ssh X forwarding (ForwardX11 and ForwardX11Trusted in the manual, also -X and -Y) to have those programs run on the remote machine, but display their GUIs on your local desktop. This way you get the nice graphical interfaces while still doing all the hard work on the remote machine, without copying tons of data back and forth.

I have never managed to make sshfs properly handle network problems (at least as well as NFS), especially after suspend & resume, I'd quite too often end with unusable machine where half of all desktop apps are hanging on some blocking syscall via that sshfs, that will _never_ timeout. Also, sshfs is quite inefficient. It's main advantage is being almost setupless, both client- and serverside. But you don't need that if you want to permanently mount your servers somewhere. I think that properly setting up NFS is worth it, in your case.

A dead NFS server can also stall a local desktop. This was a huge issue at Google, where homedirs are mounted on NFS. Turns out almost all window managers need frequent access to dotfiles or they will freeze. This is stupid.

Sure, but it can at least timeout, reutrn EIO, seamlessly reconnect when the connection is reestablished and few other remedies (you can't really do anything else, if this happens), something that I've never managed to make sshfs do properly.

A lot of window managers don't really deal with NFS timeouts/errors very well. One solution is something like AFS, but that comes with a whole host of issues.