Hacker News Reader

Comment by carterehsmith | Hacker News Reader

Nah, I've seen people downloading their preferred configs right to the production server, because they, understandably, feel more comfy with that.

But, it may not be for everyone.

Where I work, we are in the process of reaching some compliance targets, and all this downloading unknown stuff from unknown servers is out the window. For the best, I think.

View on HN

How much editing do people need to do on the production server in the context of developing software?

Incidentally one can mount a remote filesystem via ssh and edit the files as if they were local with any editor.

With Emacs you can skip a step and directly point your editor to the remote file via tramp.

People need to stop editing directly on servers. Vim's netrw can write out over scp, use your configured vim on your desktop to edit the files on the server.

The problem is browsing files, for me. I can't use fzf, nerdtree, nnn.vim, whatever. I much prefer sshfs and treating the remote file system like a local one.

But I'm not really familiar with netrw other than just:

:e scp://host/path/file

I've never used any of those plugins, but the built in netrw has a directory browser that works.

On vanilla vim if you :e scp://host// you should get the built in netrw browser working over scp.

This is one of the reasons my preferred implementation of Vi is Evil -- the TRAMP network layer in Emacs does exactly what you want: let you treat any remote file system as local. It even does multi-hop access through e.g. bastion machines. It is great.

It's unfortunate that in this day and age we still have people who directly access and touch a production server at all, ever. There is zero need.

This sounds nice until you have to debug a crazy error that only happens in production.

Wouldn't this represent 0.1% of your usage? Meanwhile the thinking portion is 99% of the job and the act of using the UI to enact the changes on any editor is the other 1%.

Making 1% of 1/10 of 1% more effecient seems like a curious optimization.

Honestly, if you have to hop on production to debug a crazy error, you have two bugs. The infrastructure being so different on production compared to development or local is a fixable issue. As are any other differences between production and local that make difficult to debug in these special cases. It takes a long time. It's a substantial effort. But it is worth while.

You're quite green, aren't you?

It may seem that way, but no I've crossed that chasm long ago. I've debugged on production more than I would ever care to remember. But in all honesty it is easier than ever to stay completely off of production. It's also extremely cost effective. It's not simple and it is work, but it has never been easier to actually be successful at staying off if production.

Easier then ever maybe but still probably impossible to avoid. It's not that anyone wants to mess up with live, it's more like you don't have a choice.

Really? I haven't allowed people to log directly only a production environment in almost 10 years. There is definitely a choice.

Reply on news.ycombinator.com