[HN Gopher] Ask HN: Best practices for editing remote code locally?
___________________________________________________________________
Ask HN: Best practices for editing remote code locally?
Working on a remote codebase from a local computer accessible via
ssh, what's the best/easiest way to write, edit and test code?
Author : E_Evan
Score : 89 points
Date : 2022-04-11 12:28 UTC (10 hours ago)
| dncornholio wrote:
| I think we have a XY problem[1] here. Could you explain more
| details please? Writing, editing and testing on a remote machine
| seems like a bad practise.
|
| [1]: https://xyproblem.info/
| rvieira wrote:
| Couple of solutions (some already mentioned):
|
| - SSH remote editing (e.g. ssh + remote Emacs/Vim)
|
| - VS Code + Remote SSH
|
| - Emacs TRAMP
|
| - JetBrains Gateway
|
| - mutagen? (I haven't played with it, I'm not sure if it's
| suitable for your case)
| drewg123 wrote:
| Old unix tools like vi or emacs and "make" were built when nearly
| all computers were remote, and work really well for this.
| Especially when combined with something like "screen" to preserve
| multiple sessions..
| jitl wrote:
| - My preference is to run my IDE or editor on the remote, and
| only run a thin client (RDP > X11, mosh > ssh) on the local.
| Because I'm happy in nvim, I would just install nvim and my dot
| files on the remote and access it via mosh/tmux. But this is not
| for everyone; if you're doing Java an IDE is a must. So, try RDP
| or X11 forwarding for those.
|
| If you can't install software on the remote (or you can't install
| a GUI stack), read on:
|
| - Most IDEs like Intellij can be configured to do all their
| execution on a remote over SSH. I worked this way using PyCharm
| for my student job at UC Berkeley in 2012 and it worked great.
|
| - SSHFS is okay but not great because of slowness. It's fine for
| editing but sucks for running interpreted code locally. So, try
| to do all execution on the remote.
|
| - VS Code has handy support of editing on a remote without
| needing SSHFS
|
| - if permitted, a two-way file sync solution like Unison or
| Mutagen gets you native file system performance on the local. We
| used Unison for local editing with remote execution for Airbnb's
| Ruby codebase for several years (2015-2018+). But it's more
| fiddly to work with than SSHFS.
| paskozdilar wrote:
| SSHFS caches reads on my machine. Here's a sequential timing of
| sha256sum operation on a ~10MiB file: $ time
| sha256sum file c2359f8b63dfef9f50e62b2e7b4ef2613c290c3a
| 1ffa135cfa255b14eafd3ffb file real 0m5,205s
| user 0m0,127s sys 0m0,011s $ time
| sha256sum file c2359f8b63dfef9f50e62b2e7b4ef2613c290c3a
| 1ffa135cfa255b14eafd3ffb file real 0m0,221s
| user 0m0,093s sys 0m0,004s
|
| That should be enough to prevent slowness for interpreted code,
| since textual files are small anyway. SSHFS only needs to send
| edited files to the remote machine.
| mekster wrote:
| No one wants to open up project files over sshfs...
|
| Do a search on all files and you'll need a break.
|
| Code parsing definitely can take forever using JetBrains.
| paskozdilar wrote:
| Depends on the project size.
|
| My average project size ~12MiB - 19MiB when using vendor/
| directory with Golang. It's less than a minute wait on a
| 1MiB connection to load the whole directory and cache it.
|
| For compiled languages, binary size would be a problem so
| it's probably smart to write the compilation output
| somewhere outside sshfs-mounted directory and run it
| locally. For interpreted languages generally it shouldn't
| be a problem since everything is in memory. Python does
| write stuff in __pycache__/, but in my experience it's
| rarely more than a few hundred kilobytes per cache
| directory; it's also possible to turn off writing
| __pycache__/ with PYTHONDONTWRITEBYTECODE=1.
| rank0 wrote:
| Don't overthink it!
|
| Keep it traditional baby all you need is vim and tmux.
|
| The initial learning curve for these sorts of cli apps is a bit
| steep, but it's a lifelong skill and easily learnable for any
| competent developer.
|
| Writing code is 1000x more difficult than learning vim philosophy
| and memorizing some key bindings.
|
| Since I do all my editing in terminal, I just have a portable
| environment in a git repo. It has an install script that soft
| links all my scripts and config files to the appropriate
| locations. My work environment comes with me everywhere!
| linsomniac wrote:
| I'm a sys admin, but lately I've been doing a fair bit of my
| time developing tooling, and this is very similar to my
| workflow. And it's been working spectacularly!
|
| I've been using Nebula to be able to connect to my primary
| machine. Then I use mosh to connect, which works great when my
| laptop suspends, I move locations, etc... I just open up my
| laptop from the car while waiting for my daughter, over the
| cell phone, from bed, from the back yard if it's nice... Or my
| Chromebook. Or my backup chromebook.
|
| Lately I've been using LunarVim, which has a lot of enhanced
| functionality via TreeSitter and LSP. I use oh-my-tmux for
| settings and a few plugins for doing keyboard-based
| selection/cut/paste.
| rank0 wrote:
| I'll have to check out some of those tools! Never heard of
| nebula or lunarvim. I just have nvim and some minimal plugins
| and vanilla tmux. I find that lots of plugin functionality
| can be done with config changes.
| linsomniac wrote:
| Nebula is a peer-to-peer "overlay network" VPN, I'm
| trialing it to potentially run on all of our servers to
| secure the networking. It was developed at slack and
| deployed on all their servers.
|
| LunarVim is just an opinionated neovim setup with all the
| bells and whistles. I got tired of pushing along my 20 year
| old vi configs and trying to get various advanced features
| working through various plugins, so I started evaluating
| just using something else, including spacevim, kakoune,
| onivim2.. Ended up sticking with LunarVim.
| mekster wrote:
| What is the advantage of using vim these days over VS code,
| Sublime text or JetBrains to upload on save through ssh?
|
| Even if you took years to get vim right, I still don't think it
| matches to the other 3 for programming.
|
| What is your vim setup like?
|
| The only place I use vim is for config editing on servers but
| not for programming.
| xigoi wrote:
| (Neo)Vim starts up _much_ faster than every IDE, takes up way
| less RAM, doesn 't fill half your screen with buttons and
| toolbars, allows powerful modal editing with completely
| customizable keybindings, is very programmable, and can be
| used on pretty much anything that has a screen, including a
| phone.
| mekster wrote:
| > (Neo)Vim starts up much faster than every IDE, takes up
| way less RAM
|
| Why do you care how long it takes to start up? It's either
| few seconds or 15 seconds a few times a day.
|
| People usually have enough RAM with a machine bought in the
| last 5 years and I don't see any buttons that fill half the
| screen? Most of the screen estate is folder tree or the
| code.
|
| Vim key bindings are everywhere it's not just for vim and I
| never code on phone.
| xigoi wrote:
| 15 seconds may seem like not much, but it's enough to go
| from "I have an idea, let's code it up" to "okay, I've
| cooked some tea in the meantime... what did I want to do
| again?" And Neovim's instant startup enables a workflow
| where I can just shut it down when I don't need it.
|
| Good for you that you're not a student having to use a
| cheap laptop for everything and sometimes not having
| access to it at the moment. Not everyone is so fortunate.
|
| Look at the first screenshot in the official VSCode
| repository, for example:
| https://github.com/microsoft/vscode Only about 20% of the
| screen is taken up by code. That may still be somewhat
| usable if you keep it fullscreen, but I prefer to have a
| 50/50 split with the web browser.
|
| Most Vim binding plugins are a complete joke. I've heard
| that Emacs gets it right, but that's not what we're
| talking about.
|
| I forgot to mention, Vim can be used for _every_
| language, including very obscure ones. With JetBrains,
| you need a separate IDE for each language -- if there
| even is one.
| rank0 wrote:
| portability - vim works everywhere and my config is just a
| `git pull` away. VS code doesn't let you sync configs unless
| you sign in with github/microsoft account. Wack!
|
| flexibility - vim integrates very nicely with my terminal-
| heavy workflow. Its extremely hackable. I can zip around and
| pipe contents between my shell, unix tools, and vim buffers.
| For example, I can run a shell command from nvim and have its
| output automatically pasted into my current vim buffer at the
| cursors location.
|
| lightweight - It's a blazing fast tiny executable rather than
| a clunky resource hungry electron app.
|
| keyboard-centric - I enjoy my desktop the most when I don't
| have to move my hands from the keyboard. This is really just
| a personal preference. Also the vi keybindings are ubiquitous
| in unix tools and even some gui/web apps!
| mekster wrote:
| I get that portability makes sense if you're shipping a
| software but how many different uncontrollable environments
| are you going to face? It's usually only a few environments
| that's under your control.
|
| > VS code doesn't let you sync configs
|
| I thought it's just a JSON file.
|
| > It's a blazing fast
|
| This depends, if you make your vim full blown to match the
| feature (which is probably not even possible), vim tends to
| start up pretty slowly.
|
| Vim key bindings are pretty much available on most editors
| out there.
|
| And you'll be losing so much from the vast list of plugins
| available in vs code.
|
| You can't autocomplete table names in SQL strings like in
| JetBrains, I've quit using vim 15 years ago as my
| programming editor.
| rank0 wrote:
| > I get that portability makes sense if you're shipping a
| software but how many different uncontrollable
| environments are you going to face? It's usually only a
| few environments that's under your control.
|
| At my day job and for my personal infrastructure, I
| routinely edit files across a wide variety of shuffling
| environments. I am a pentester by trade and also enjoy
| homelabbing, embedded systems, and working on my ADHD-
| fueled inventory of fun projects. I am not a dedicated
| software engineer that has to write polished production-
| quality enterprise applications. All my shit is held
| together by duct tape and bubble gum. I 100% understand
| why you'd want a beefy dedicated IDE for a product you're
| working on full time.
|
| > I thought it's just a JSON file.
|
| If VSCode has changed in the past couple years to json
| file that's great! But last time I tried I wasn't able to
| move around my config easily without signing into some
| web service.
|
| > This depends, if you make your vim full blown to match
| the feature (which is probably not even possible), vim
| tends to start up pretty slowly.
|
| Absolutely right! I keep my plugins minimal. You can do
| _almost_ everything the plugins can with vanilla vim.
|
| > Vim key bindings are pretty much available on most
| editors out there.
|
| Also true! In my experience, its wonky and usually
| requires YET ANOTHER plugin. They're never at parity with
| all the vim actions.
|
| > And you'll be losing so much from the vast list of
| plugins available in vs code.
|
| > You can't autocomplete table names in SQL strings like
| in JetBrains, I've quit using vim 15 years ago as my
| programming editor.
|
| That's also fair, but I don't use most of those plugins.
| Only copilot (also available in nvim) and remote editing
| really amazed me from VSC. Everything else I can just do
| myself by spawning a shell, using pipes/redirects, and
| unix tools. For example, I don't need GUI elements for
| git baked into my editor...I just use the cli.
|
| You can definitely autocomplete SQL table names, but it
| would require some manual configuration. My autocomplete
| mostly pulls from strings in my open buffers.
|
| I'm not arguing that any either approach is inherently
| better, just stating my preference. And for the original
| topic of remote editing ssh+vim is my preferred solution.
| Absolutely language-specific IDEs have major benefits
| over a general purpose editor.
|
| There's also the FOSS philosophical argument but that's
| just a personal belief and really doesn't matter for all
| practical purposes.
| alkonaut wrote:
| So just because the code is remote one should edit in a
| terminal? Seems like the lowest common denominator, but a
| pretty bad one. And on Windows (the most common OS, even among
| developers) this is pretty painful even with WSL. As far as
| lowest common denominators for tooling goes, "terminal window"
| is pretty low.
| rank0 wrote:
| Idk man it's all preference. I'm way more comfortable in the
| terminal than in a gui editor. The flexibility I get from my
| shell, nvim and tmux is unmatched by any gui solution I've
| tried. If you don't like the terminal that's fine you can
| always just use git!
|
| It's lightweight, fast, and works on any machine. After years
| in VScode I got fed up with Microsoft lock in for things like
| syncing configs and remote editing extensions.
|
| Your point about windows may be true, but I've yet to work
| somewhere that hasn't let me use a MacBook.
|
| Also I'm a pentester at work, so I don't have to write
| production ready code...I can see why developers might want
| all the shiny features/integrations that come with a
| language-specific IDE.
|
| To each their own!
| jdauriemma wrote:
| I think they were commenting on the portability of terminal-
| based applications and describing remote editing as a use
| case. You may think it's "bad" but it's also ubiquitous,
| resource-efficient, and free. Can you explain to this non-
| Windows user why vim+tmux is painful in Windows (with or
| without WSL) in a local or remote setting?
| alkonaut wrote:
| I think it's painful because terminals and ssh are just
| second class citizens. Dotfiles, ssh key storage etc are
| just not a first class concept (at least not in the same
| way as on linux) etc. And also things like clipboards don't
| work - which to a linux user might seem like a non-issue
| (It just never worked well) but that's a much more painful
| experience if you are used to it working.
| jdauriemma wrote:
| Clipboards can be a hassle, for sure. Can you help me
| understand the impact of dotfiles / ssh key management
| not being a "first class concept?" How much of a time /
| productivity hit do you take? Thanks so much for helping
| me understand.
| alkonaut wrote:
| I mean the idea of config files is on one hand windows
| where some things work like a Linux user would expect
| (e.g a .gitconfig) while others obviously don't, e.g use
| registry or other settings storage. Next, wsl is separate
| so you aren't really sure which settings apply where. Are
| you using git from within wsl? Or a windows git? Is the
| credential manager the wsl one or one from windows?
| Unless one is ready to completely "jump into" wsl and
| ignore everything outside it has a chance of feeling
| coherent - but few windows users want that I'd guess.
| rank0 wrote:
| I don't work in windows but fwiw my clipboard and config
| files work flawlessly in mac and Linux. Last time I used
| WSL everything was working fine but it's been a few
| years.
| alkonaut wrote:
| In vim in a terminal too?
| ar_lan wrote:
| This is what I do 99% of the time (unless I drastically feel
| the need for a visual debugger as I'm not so familiar with CLI
| debugging just yet).
|
| I run a dev VM on any machine(s) I'm actively working on that
| all share the same setup - today, that's my Macbook and my
| desktop at home. They aren't necessarily in sync, but they do
| share the same dotfiles and versions of everything, so if I
| want to switch my dev work all I simply need to do is a `git
| pull` on whatever project I'm working on, and then everything
| is caught up between the two.
|
| With this, I just `mosh dev` (and then straight into `tmux`) on
| whatever computer I'm running into and just use `vim` for
| everything. If I really need a graphical debugger I can always
| open the VM graphically, but that's so rare that it hardly
| feels worth mentioning.
| rank0 wrote:
| Hell yeah! I wish more folks would appreciate how flexible
| and feature rich the old school cli tools can be.
|
| What's your VMM setup? I just edit right on the remote
| machine. Lately I've been playing around with lxd/lxc for
| persistent container dev environments. This way I can avoid
| the VM overhead and it "feels" the same...but I have yet to
| fully explore this approach.
| lta wrote:
| I would personally recommend something similar. Eternal
| Terminal in kitty has been quite nice for me over the last
| year. I use emacs as a daemon started by systemd with emacs
| client frame. but vim is obvious a great choice as well.
|
| What I like about this setup over tmux is that I feels a bit
| more integrated into my desktop environment, and I don't need
| as much keystrokes as with tmux. Tmux has a nice integration
| mode I've been using in the past but it's only supported by a
| few terminal.
|
| I work on a remote dev server for most of my stuff, by choice,
| which allows me to quickly pull images, dependencies and the
| rest regardless on the quality of the network I'm working from
| and I also get a small battery boost since most the of the
| heavy work is done on the server.
| rank0 wrote:
| Kitty is awesome I've been using it lately myself. I can't
| get myself fully off tmux into the native kitty panes because
| tmux is dank for multiplexed remote sessions and actually
| works everywhere.
|
| I still use kitty windows or just detach from tmux when I
| wanna do something that benefits from kittys beautiful
| display protocol.
| xur17 wrote:
| I do something similar, and I really do enjoy it for
| development. Being able to use mosh to shell into a fast
| development machine with high speed internet feels like a
| superpower. The time I put into learning tmux + vim was really
| well worth it.
|
| That said, don't underestimate the upfront cost of something
| like this. Getting the right plugins + getting comfortable took
| me a considerable amount of time.
| rank0 wrote:
| > That said, don't underestimate the upfront cost of
| something like this. Getting the right plugins + getting
| comfortable took me a considerable amount of time.
|
| This is definitely true. I've been a terminal guy for many
| years so its easy for me to recommend while I already have
| the muscle memory. It might be an uncomfortable few weeks,
| but I still argue that learning a new language or framework
| is MUCH harder than learning keybindings, coreutils, and
| shell operators.
| xur17 wrote:
| Yeah, in grad school I forced myself to learn vim + tmux,
| and it was definitely quite a few uncomfortable and slow
| weeks, but it has paid itself back in dividends since then.
| honkler wrote:
| `sshfs`, to mount a remote directory locally, then edit it with
| whatever tools you want.
| jpn wrote:
| For Sublime Text users, SFTP is super useful:
|
| https://codexns.io/products/sftp_for_sublime
| jve wrote:
| Something super-similar is available for VSCode too: SFTP
| https://marketplace.visualstudio.com/items?itemName=liximomo...
| sillycube wrote:
| jraph wrote:
| Kate is a fantastic code editor (if you don't need an IDE, though
| it gained support for LSP) and is able to edit files over SFTP
| (without having to mount anything with SSHFS, which would be less
| efficient anyway because Kate would not be aware it is editing a
| distant file this way). KDevelop can probably too, and it is an
| IDE. I'd try QtCreator too.
|
| In the same vain, Gedit and its forks can do this to if that's
| your cup of tea.
|
| or vim, emacs or nano through a traditional SSH session :-)
| mekster wrote:
| Does anyone seriously use nano for programming?
|
| Also I'd probably get pissed for using vim over ssh session to
| program when sometimes the network could sporadically slows
| down my cursor movement.
| jraph wrote:
| nano is a surprisingly capable code editor. I like to use it
| for quick edits or when I'm on a remote server. It's
| indentation can be configured (tab or space, how wide), it
| has optional line numbering, undo / redo, copy paste, a very
| efficient search and replace, syntax coloring (a bit limited
| at times). It's fast. I know how to use vim and like it but
| haven't become proficient with it and its modal editing still
| gets in my way. I haven't tried Emacs. I have written sizable
| chunks of code with nano. I usually prefer Kate most of the
| time though. I've tried VS Codium but I find it too sluggish.
| I'd use it for some refactoring tasks but with Kate gaining
| LSP support (and true multi cursor mode), I have even less
| incentive to use Codium now. My muscle memory has been
| trained with Kate for 15 years now.
|
| Rachel from rachelbythebay.com notoriously uses nano FWIW [1]
|
| [1] http://rachelbythebay.com/w/2018/12/21/env/
| hprotagonist wrote:
| i use emacs+TRAMP for vcs, mosh for remote terminal presence, and
| vscode+ssh or jetbrains gateway for dev.
| globular-toast wrote:
| Best practice is to write, test, build etc. locally using a
| version control system and deploy a tested bundle to the remote
| computer when ready.
|
| Editing code directly on a remote server is something I used to
| do in the 90s before git and other tools made good practices much
| easier.
| datalopers wrote:
| Best practice changes rapidly, local dev environments have
| proven to be an endless pain in the ass. Apple M1 silicon is
| the final nail.
|
| The next 10 years of "best practices" will return to dumb
| clients and dynamically provisioned dev environments. It's
| simply so much easier.
| globular-toast wrote:
| It sounds like the exact same thing but with added latency. I
| hate latency.
|
| It baffles me why anyone would choose an incompatible
| architecture only to run dumb clients on it. You might as
| well just save your money and run the dumb clients on 20 year
| old hardware.
|
| Or you could spend less money on a laptop that is actually
| compatible with whatever platform you are deploying to and
| enjoy low-latency local development.
| datalopers wrote:
| I'd try VSCode with Remote SSH. Maybe it's because I'm 10ms
| from my datacenter but I experience no lag and things have
| always felt just as speedy while on random public wifi.
| TameAntelope wrote:
| As someone who has responsibility over how shitty the local
| development experience is for my org, I recently saw GitHub
| Workspaces and am curious if that could be a viable option.
| ArcMex wrote:
| Oh, I love your response. Thank you.
|
| My workflow was as follows
|
| - Remote into server and develop from there
|
| - Git to different location, could even be same server
|
| - Occasionally pull on local machine for redundant backup
|
| This allowed me to
|
| - Segregate builds for my testing and the business's UAT
|
| - Allowed me to always have a stable build locally that I could
| look at from home
|
| Before, I did develop on my local machine and push to a server.
| Some part of me still thinks that's the proper way to do it.
|
| But I am always seeing what works best for the current
| situation and developing directly on my server served me well
| once upon a time.
| aardvark179 wrote:
| Emacs tramp can edit files over ssh very nicely, along with other
| things like editing files as another user through sudo.
| blunte wrote:
| I have recently built a dev server for myself using
| https://github.com/coder/code-server (VS Code in the browser,
| hosted on the remote server). With very little effort, you get an
| always-on dev environment with built in terminal so you don't
| even have to ssh in if you don't feel like it (if you're happy
| working within the editor's terminal window pane).
|
| As a bonus, I also setup openvnc, cloudflared (DNS over HTTPS),
| and pihole. And tmux and mosh of course.
|
| With this setup I can even do my work from an iPad (once you get
| the VPN setup correctly).
|
| It's nice to be able to reboot my laptop without losing my place
| in my work.
| qbasic_forever wrote:
| Yeah code-server is really nice and underrated as a remote
| coding option. The linuxserver.io docker container for it is
| super fast and easy to setup:
| https://docs.linuxserver.io/images/docker-code-server
| ipaddr wrote:
| You can still use dreamweaver mx, 7, etc.
|
| You can use intellj products
|
| Sublime ssh plugins, vs plugins
|
| On android you can use AWD - editor
| ddaalluu2 wrote:
| Idk if hn is psychic but I just thought how great it could be if
| I could use my workstation in the next room as a host for writing
| code on my phone. Because I can take my phone where I'm
| comfortable and hold it where I please and lay on the sofa,
| relaxed as opposed to sitting on a chair where blood flow to my
| feet is semi cut off. (How I would love one of those walk-
| apparatuses Linus Torvalds has).
|
| So sorry no answer, but also interested.
|
| I remember there were a few online code editors, but trust is an
| issue and they cost extra.
|
| The way you intend to use it though... I have done it in my PHP
| days, long ago. It's not good practice. Version control systems
| are a good invention, even if you sometimes just need a quick
| fix. Edit locally, push to repo, auto build or manually.
| icosahedron wrote:
| I do this periodically with my iPad. I use Textastic which is a
| decent editor with it's SSH mode.
|
| There is also ShellFish, which is an iOS SSH file provider. You
| can use it to access any files via SSH as if they were from
| iCloud or OneDrive, etc.
|
| Lastly, there is code-server, which is VS Code in a browser.
| I've used this from time to time, and it works well.
| yabones wrote:
| Ideally, just use a text editor on the remote machine such as
| Vim, Nano, or Emacs.
|
| If you want a full IDE, or just your set of extensions & tools,
| you could install it there and use X11 forwarding like so:
| ssh -X me@box /usr/bin/code
|
| I believe VSCode also has a remote mode, but I haven't used it.
| lf-non wrote:
| X11 forwarding was not a great experience last I tried it.
|
| Every now and then clipboard would stop working or resized
| windows would retain their original dimensions etc. Not
| entirely sure if it had to do with my setup or network.
|
| I switched to tmux+neovim a year ago and it has been a much
| better experience.
| pbsds wrote:
| Many editors support the rmate protocol, enabling you to open a
| remote file from a ssh session in your local editor.
| emacs28 wrote:
| I use Emacs but don't enjoy the latency of using a remote Emacs
| session or locally using tramp. Recently my solution is to edit
| locally, then whenever I need to run the codebase on the remote
| machine I wrap the run command in a script with two rsync
| commands. First (using rsync) it will sync the remote codebase
| with any local changes. Then when the remote command completes,
| any relevant result files I want to analyze locally after are
| synced back to the local machine (using rsync). Rsync is very
| flexible and has lots of options such as ignore filters.
| ctur wrote:
| Check out mutagen (discussion on
| https://news.ycombinator.com/item?id=30957156) -- it basically
| does bidirectional, background, transparent rsync. It also does
| port forwarding if you need that. It looks quite solid for the
| use case you describe.
| zamalek wrote:
| The first few minutes of this video[1] shows a typical approach
| using containers with TTY editors. If you use VSCode then you can
| take a look at "Visual Studio Code Remote - Containers", if you
| use JetBrains products then take a look at "Gateway" or
| "Projector".
|
| [1]: https://www.youtube.com/watch?v=XOOBL3bhFHs
| motoboi wrote:
| I have been using jetbrains gateway solution. I've seen lots of
| improvements but unfortunately it's still awful.
|
| I'm using mostly Visual Code + Remote SSH (which would be
| wonderful if visual code was a gread IDE, which it's not. A
| fine IDE, but not a gread IDE). For large java project I switch
| to Jetbrains Gateway, but the experience is too painful.
| gorjusborg wrote:
| I love jetbrains for the indexing magic they do across their
| products, but yeah, the remote development last time I
| checked was lackluster.
| zamalek wrote:
| That's disappointing, I've been waiting for it to land in
| Rider. I guess I'll need to double-down on polishing up
| VSCode as an IDE at work.
| mekster wrote:
| I guess they'll catch up with Fleet but it's still in
| private beta and not for use yet.
| michaelt wrote:
| I've seen some of my colleagues running 'Visual Studio Code
| remote' [1] which allowed them to edit source code on a remote
| machine with a native text editor; run the code and tests
| remotely with a local interactive debugger, and so on.
|
| I haven't tried it myself, but they seemed to like it.
|
| [1] https://code.visualstudio.com/docs/remote/ssh
| _wldu wrote:
| The most secure way to do this would be to run Qubes OS [1] and
| use a qube dedicated solely to your software development. You can
| do your random web browsing and other risky Internet based things
| (such as email) in other qubes (not your dev qube). IMPO,
| isolation is really the best defense we have against modern
| attacks (supply chain, water hole attacks, whale phishing, etc.)
|
| Hope this helps.
|
| [1] - https://www.qubes-os.org/
| ilovecaching wrote:
| The answer is so incredibly simple. SSH to the machine. Start vim
| or emacs. The end.
| mekster wrote:
| What if one wants to use other GUI editors?
| JamesMcMinn wrote:
| VS Code + The Remote SSH extension is a remarkable solution to
| developing code (not just editing!) on a remote machine.
|
| When Covid hit and my main work machine was still a desktop, I
| worked from my home using VS Code and the remote plugin. This
| lasted for 18 months, and the only time I ever had an issue was
| due to a power outage in the office. Data, code (everything,
| really) lived on my work desktop that was sat in an empty office
| while I was at home.
|
| There's no latency, the terminal opens as if you were on the
| remote machine, and ports are automatically forwarded. It runs
| code, tests, etc. all on the remote machine.
|
| If there's a better solution out there it's almost certainly down
| to IDE preference.
| baq wrote:
| switched to vscode from neovim in tmux a couple years ago,
| which used to be my weapon of choice for more than a decade
| (vim before neovim for the purists). practically haven't looked
| back. it really is amazing.
| blowfish721 wrote:
| How does it handle disconnects? With two kids and lots of
| interruptions my laptop is going to sleep a lot if I don't have
| it plugged in between sessions, does it reconnect everything
| automatically so you wouldn't notice it much?
| barefeg wrote:
| Make sure to add TCPKeepAlive yes into your ssh config so the
| ssh doesn't disconnect. Vscode will disconnect but then it's
| just a matter of clicking retry
| baq wrote:
| depends on length of the disconnect. it can be seamless and
| if it fails, it asks you to reload itself, conveniently
| placing a button to do just that in the same dialog window.
| rubicon33 wrote:
| Could this be used to do firmware development on Pi? One thing
| I've always hated was having to either SSH and use vim, or
| login directly to the Pi and use an IDE directly on it.
|
| I would love to use my main mac + VS Code to edit code and
| dispatch commands like compile / run
| tibyat wrote:
| npage97 wrote:
| I've done this exact setup (though not for firmware
| development). VS Code C/C++ extension also supports arm64 as
| well (https://devblogs.microsoft.com/cppblog/visual-studio-
| code-c-...). This works well with remote ssh.
| rubicon33 wrote:
| Thank you! I'm going to give it a try, sounds like it could
| be perfect for me to finally get deeper into firmware
| development. Just can't stand working directly on the Pi.
| ActorNightly wrote:
| VSCode install processes to support remote editing. I think
| PI is supported, but I know it had issues with certain
| architectures last year. Its very easy to try though.
| sschueller wrote:
| It is, I have used it and it works great on a pi3.
| swah wrote:
| I recently registered for a free VPS from Oracle and could get
| a box in my country - then those setups start working well.
|
| With my VPS from DigitalOcean the ping will be 170ms and then
| its no bueno.
| rhacker wrote:
| And you can run the debugger!
| tta wrote:
| Relatedly, iTerm's tmux integration[1] pairs very well with
| this setup.
|
| [1]: https://iterm2.com/documentation-tmux-integration.html
| flutetornado wrote:
| This is the best solution I have found so far being a long
| time vim user. ssh + tmux + vim is all you need. Least amount
| of potential problems in this setup. vim runs locally on the
| server where "remote development" is being done, so there is
| very little friction in terms of getting it to do what you'd
| like it to do given all the plugins you can add to it for
| beefing it up.
|
| I have heard stories from coworkers about work being lost
| when editing is done remotely instead of locally, so never
| ventured that way.
| eschneider wrote:
| I'm definitely team emacs -nw, but I use the same tmux
| setup. Tmux's ability to reconnect to a session after
| disconnect is definitely it's killer feature.
| lyrr wrote:
| Since you seem to know what you're talking about, I'm looking
| for some advice: I work for a large and very well known
| engineering company and currently our incredibly terrible
| workflow looks something like this: Develop locally using
| VStudio -> transfer repo to network drive -> login to tester
| via three layers of Remote Desktop Connections -> run and debug
| code live on tester RDC The tester setup is virtually all GUI
| based. It's also located on the other side of Asia which is the
| reason of logging in via RDC. Is there possibly a better way of
| making this workflow more contained in a terminal/single ide
| environment, without having to jump through the RDC loops?
| anecd0te wrote:
| rank0 wrote:
| Is there a way to do your testing without a gui? I have no
| idea what your testing setup requires, but is there some
| technical reason why tests are not done automatically in your
| ci/cd pipeline?
|
| If it must be done manually, can you just ssh/rdp directly
| into the testing box? The network where the testing box
| exists could use some tunneling protocol (stunnel, socks,
| wireguard, vpc peering...) to make it more accessible from
| your dev machine or your company VPN.
| wey-gu wrote:
| I had similar experiences but some layers are Citrix and
| others RDC. Seeing your situation brought back my anxiety on
| those connections. Sorry for this. Is there any terminal
| servers to be able to ssh port forwarding? Thus to reduce
| layers, while as the test setup is gui based at least one
| layer of RDC is required. Reducing nested Remote Desktop
| would for sure help with the experience. Sorry again for you
| situation.
| woopwoop wrote:
| Seconded. It is so seemless that it is literally possible to
| not notice which machine you are on if you are just firing up
| something new for quick exploration.
| atwebb wrote:
| Exactly what I was thinking, it really is crazy nice for
| development over SSH or within a container. The Live additions
| are neat for sharing as well though I've only dabbled in it.
| monkeybutton wrote:
| I use VS code with the same plugin for working remotely. I also
| use jupyter lab with port tunneling and there's no difference
| to what it was like working locally. My company issued computer
| is just a VM off in some cloud. Working like this has a oddly
| retro-futuristic feel to it. Like we've gone back to the days
| of mainframe development.
| aldanor wrote:
| Just a suggestion - VS Code (now) has a super nice support
| for jupyter. You don't have to start the server externally,
| vim mode and all your extensions like github copilot work
| fine, proper autocompleting works, etc. Debugging is
| absolutely amazing. I've recently switched myself and am
| never going back to browser-based jupyter.
| monkeybutton wrote:
| Debugging jupyter notebooks, as in you can set a breakpoint
| then shift-enter to run a cell and hit it? I'll have to
| give that a try!
| aldanor wrote:
| E.g., you can set up a breakpoint in your own local
| module that your notebook is importing and get the full
| vscode debugging experience by executing a cell.
| evilotto wrote:
| I like vscode + remote ssh a lot, but one thing to be aware of
| is that the node server that it installs on the remote can be a
| bit memory hungry if you're on a small machine (i.e., low-end
| droplet or vps). One of the rsync or sftp remote adapters is
| much nicer to such environments.
| vsgzusnex wrote:
| I started with this and still prefer it from a functionality
| stand point but the one use case where it falls apart for me is
| when you have an internet connection with occasional lag
| spikes.
|
| This could be a variety of scenarios like working remote on bad
| ISPs or cellular or a crappy VPN but all that matters is when
| it acts up it will cause lag, or dropped connections depending
| on severity. Too many interruptions while trying to focus.
|
| For this reason I keep everything local and use an rsync
| wrapper over my build system that streams output back. The
| added delay for each command disrupts workflow less than it
| happening during editing.
| posharma wrote:
| I used this setup a lot myself and it worked great except that
| name completions, intellisense didn't work as expected.
| qbasic_forever wrote:
| You might need to install all the language servers and
| extensions on the remote host too. Typically VS code realizes
| they're missing and prompts to install them. But if there's
| an issue you might need to dig around and see why it can't
| install the LSP services there (perhaps you don't have
| permission or access to get them).
| unmole wrote:
| Mosh + Tmux + Vim
| andi999 wrote:
| What is wrong with using ssh -X and the do the same workflow you
| would do if you were on premise?
| hexo wrote:
| sometimes it is just too slow or laggy. some software even
| refuses to run at all that way.
| aardvark179 wrote:
| It depends a lot on the application. Old apps that use old X
| fonts etc. work okay-ish, but by default a lot of modern apps
| will be pushing too much over the connection because they'll be
| doing the font rendering into a buffer.
| bayindirh wrote:
| Because we don't have gigabit symmetrical lines everywhere.
| yeetsfromhellL2 wrote:
| I've done X forwarding over slow wifi and it worked great. OP
| isn't editing video.
| bayindirh wrote:
| I'm doing X forwarding for 15 years and unless you have
| ~20mbps symmetrical lines, you can't do anything
| productive.
|
| However, if you absolutely must, use X2go.
| yeetsfromhellL2 wrote:
| I certainly haven't used it that much, but I never felt
| like the connection quality was a huge concern for a
| usable DE. It's something like 30 years old now isn't it?
| bayindirh wrote:
| The thing with X11Forwarding is, it's never designed to
| be ran over WAN or, slower connections to be precise. It
| carries X11 commands, not the video itself and is
| synchronous and doesn't compress anything. As a result it
| both needs low latency and saturates connections quickly.
|
| When the updates are occasional, fine, but when you call
| make or run something which updates fast/creates a lot of
| output, things get hairy, quick. Even on local networks
| with a couple of connections. Been there, tried that,
| experienced it all.
|
| X2Go transmits the image, compresses it, and can work
| with much slower and higher latency network connections.
| It can also resume sessions.
| throwaway71271 wrote:
| local emacs + TRAMP works really nice
| R0flcopt3r wrote:
| TRAMP has been too slow for me, and I've never had a reliable
| LSP session over it. Tried both eglot and lsp-mode. eglot is
| the better of the two for this.
|
| I ended up creating a "runtime" script that first rsync all the
| files over to my remote machine, then run whatever arguments,
| `runtime <host> 'make'`. there are some flags too like `-s` to
| have it not rsync, etc. This works very well. But then this is
| maybe cheating since my code is still local. The reason for
| this is my M1 mac can't build our gigantic C++ code base for a
| whole host of various insane reasons.
| dhosek wrote:
| I've had good luck with Tramp+Aquamacs myself. There might be
| a short delay at save time, but I can live with that.
| mjh2539 wrote:
| emacs-nox
| rubicks wrote:
| sshfs + $EDITOR
| warent wrote:
| I host my code on a server because the docker-compose required to
| run the whole stack takes more memory than my macbook can afford
| (Docker is very memory hungry on Mac and at the moment I "only"
| have 16gb).
|
| Basically just hosting an SMB server and then mounting it as a
| volume on my work computer. So it looks like a normal
| folder/directory but it's over a network.
|
| You can also get fancy and configure your NAT to only allow this
| over local connections, then spin up a VPN. In this way I'm able
| to securely work in my server from anywhere.
| Aperocky wrote:
| vim with good amount of plugin is my go to.
|
| My vim setup looks like atom in terms of interface:
| https://github.com/Aperocky/unix-setup/blob/master/.vimrc
|
| Very easy to setup, just add the .vimrc file and run the git
| clone commands after setting up pathogen (package interface).
| This setup is pretty nice to edit ts/js/py/rb and C family of
| languages (add plugin specific to language when you need it).
| This isn't just for SSH, this is my goto in local as well, but it
| behaves exactly the same either remote or local.
|
| This doesn't really work for any of the JVM languages however,
| those you probably want an IDE.. I tried my best in vim and it
| just don't work.
| Y-bar wrote:
| If you are on a Mac, using Transmit (https://panic.com/transmit/)
| you can mount a SSH/SFTP connection as a local disk and edit
| there in your editor of choice.
| mekster wrote:
| Do people who work over sshfs never search for a string over
| all files? Or your editor wants to parse codes from all files
| to find dependencies etc? Save on upload of a local copy is far
| superior.
| lfkdev wrote:
| VS Code with remote ssh. This is actually my default workflow. I
| always rent a small vps and work/code on it over the remote ssh
| plugin. Worke perfectly
| martopix wrote:
| I use Atom with an extension called ftp-remote-edit that works
| quite nicely.
| yangosoft wrote:
| Try NetBeans, works quite well for remote projects using SSH.
|
| Also found vscode + remote SSH very useful, as others users
| recommended.
| ris wrote:
| This is (partly) why I started using KDE's Kate as my editor.
| File access is all through a virtual io layer, which supports
| sftp amongst many others. And I've never switched away from it -
| long after that project - because it's "good enough".
| olekenneth wrote:
| Use Emacs. You have something called tramp. Which can connect
| with sftp/scp/more to remote server.
| Jaruzel wrote:
| As a Windows guy who uses Linux on servers only, I used to
| install samba onto the servers and map a drive to that (over a
| hardware VPN). These were servers that I had full control over.
| I'd use an IDE on Windows and directly edit the code. Save,
| reload in Browser, see changes.
|
| Now due to changes in where I host my stuff, I can't do that
| anymore, and I'm struggling to find a simple solution. I have
| recently discovered that WinSCP can 'edit' a file by pulling it
| locally into a temp folder, opening your IDE of choice, and then
| auto resyncing the file to remote server whenever the local copy
| changes. It's OK as a workflow, but not as flexible as having an
| open folder to just drop stuff into.
|
| I know the latest version of Dreamweaver has the same sort of
| thing built in which would be better... But as a hobbyist, I just
| can't afford that.
| mekster wrote:
| Copy project files locally and upload on save?
|
| This is just so simple and performing, not sure why anyone is
| struggling with other worse solutions. The only better method
| would be vscode remote editing plugin.
| louissan wrote:
| vi?
| maicro wrote:
| While there are plenty of other more powerful solutions suggested
| here, I prefer my fairly light weight option - WinSCP connecting
| to the remote server over SFTP, then opening the files I want to
| change in my preferred editor (Sublime Text). WinSCP handles
| uploading file changes to the remote server automatically; there
| might also be a way to trigger actions on upload, but that gets
| into specifics of how your codebase is setup / what you need to
| run to test changes. Bonuses of using WinSCP are drag-and-drop
| file transfers, and a pretty thorough site manager (/address book
| / credential storage / login manager, whatever you want to call
| it).
| Jaruzel wrote:
| Heh, I basically said exactly the same thing elsewhere in this
| thread and got voted down. I guess someone out there doesn't
| like WinSCP!
|
| (I'm voting you up, as I can't vote myself up)
| maicro wrote:
| ...there's no accounting for taste? It really is a great
| solution as long as you understand the limits - there are
| more powerful options, but this one is just so quick and easy
| to get set up if it's valid for your situation.
| ryangittins wrote:
| An important tool to find or write is one which will
| automatically sync your changes made locally (from the comfort of
| your IDE of choice) to the remote machine every time you save it.
|
| You want to be able to iterate quickly and not have to manually
| run a command every time you want to sync changes. It's also a
| huge help to tie this into a way to run the unit tests for files
| which have been changed so you can get feedback and quickly as
| possible.
|
| Ideally, everything should be made so automatic that you barely
| even notice the code isn't running on your machine.
| pbsds wrote:
| For this i combine entr and rsync
| hokumguru wrote:
| Nova (https://nova.app) has a remote file browser + terminal that
| I've found work surprisingly well, it has the advantage of being
| Mac native as well!
| ArcMex wrote:
| Thank you for sharing this. I will give the 30-day trial a
| shot. I find VSCode just fits my needs on my boxes (Mac, Win,
| Linux) but I am always open to try stuff.
| giobox wrote:
| Nova is nice, but its selection of plugins and integrations
| (things like linters, code syntax highlighting for specific
| languages etc) is just vastly behind VSCode. Mac native is nice
| to have, but the feature set in VSCode is so hard for a small
| competitor like Panic to beat now, especially when Nova is
| relatively exspensive.
|
| If you are purely doing web design work, I could maybe
| recommend Nova for its nice CSS/HTML tooling, but again you can
| recreate much of this with VSCode anyway. When you factor in
| Nova is 99 dollars this conversation becomes a lot more
| difficult when VSCode is such a strong free competitor.
|
| Nova has been through several iterations/product resets, I
| owned it back when it was called "Coda" too. VSCode by
| comparison has been relatively stable and its ecosystem a lot
| healthier.
|
| I'd actually recommend VSCode + another Panic Software app for
| remote file access on a Mac: Transmit. Transmit is mac native
| standalone remote filesystem access tool, its basically the
| tool they built into Nova as a standalone, and 45 bucks:
|
| https://panic.com/transmit/
|
| VSCode + Transmit is IMO the best in class tools on MacOS for
| this kind of remote access work, although you can easily
| substitute Transmit for a free tool like CyberDuck or similar
| too and keep software cost at zero.
| mekster wrote:
| Vscode being free, I suppose the only real contenders are
| Sublime Text or JetBrains. Everything else either free or
| paid seem like a non option.
| gotts wrote:
| local code editing + rsync command that you run manually or
| automatically(e.g. using fswatch)
| evocatus wrote:
| SSH in and use a terminal editor. Or, create an SMB/CIFS share
| and mount it locally.
| dezmou wrote:
| I am used to work with "remote - SSH" vs-code extension with a
| remote server and it work like a charm, you can't tell that you
| are not at home. I do all my coding this way BTW
| DaOne256 wrote:
| I wish that VS Code had a TUI (Text User Interface) with mouse
| support like mc to run it in a SSH console.
|
| Vim, emacs or nano are no alternatives for me as I need to browse
| large C/C++ legacy codebases and some newer JS. And I rely much
| on CTRL+mouseclick.
|
| Does anyone know a VS Code extension to use it in a shell instead
| of the desktop GUI?
| emacs28 wrote:
| Just out of curiosity, what does ctrl+mouseclick do in VSCode?
| I can almost guarantee there's a way to do it in Emacs :) If it
| has to do with looking up references, there's lsp-mode in emacs
| which gives it IDE capabilities for many languages.
| DaOne256 wrote:
| It's "go to definition", I think CTRL-mouseclick is a common
| setting in most modern IDEs. In Eclipse it's F3 if I
| remember.
|
| VS Code was the only editor or IDE I found for Linux that can
| be used to browse like that without much configuration.
| CodeLite worked sometimes but not reliably.
|
| I can just type "code ." in my src folder and can start
| browsing it. Most IDEs need to setup some kind of indexing.
| VS Code worked out of the box.
| qbasic_forever wrote:
| Try out the micro code editor, it has more generic/windows-like
| key conventions (i.e. Ctrl-C/Ctrl-V copy and paste), full mouse
| support, etc: https://micro-editor.github.io/
|
| It doesn't support everything VS code can do (notably it
| doesn't have LSP support), but it could be more accessible to
| you than vim or emacs.
| tpoacher wrote:
| ssh + byobu + your favourite terminal editor.
|
| bonus: collaborative coding by attaching to the same byobu
| session as your colleague
| chrisshroba wrote:
| Can you elaborate on the situation? Personally I'd just keep a
| local copy of the code and then use git or rsync to sync the
| remote system to my local version whenever I'm ready to.
|
| If it's just small things like a quick config change or
| something, I'd personally just ssh in and modify with vim.
|
| For testing, you probably shouldn't be doing that on a production
| system, perhaps you could stick the code in a docker container
| and run the tests locally? If you're familiar with docker, that
| shouldn't take more than a couple hours to set up, and likely
| much less time than that if the project isn't super complex.
|
| Feel free to explain your use case further and I bet people could
| give more targeted advice!
| [deleted]
| lyrr wrote:
| Since you seem to know what you're talking about, I'm looking
| for some advice: I work for a large and very well known
| engineering company and currently our incredibly terrible
| workflow looks something like this: Develop locally using
| VStudio -> transfer repo to network drive -> login to tester
| via three layers of Remote Desktop Connections -> run and debug
| code live on tester RDC The tester setup is virtually all GUI
| based. It's also located on the other side of Asia which is the
| reason of logging in via RDC. Is there possibly a better way of
| making this workflow more contained in a terminal/single ide
| environment, without having to jump through the RDC loops?
| chrisshroba wrote:
| I'm no networking wizard so this isn't really my area of
| expertise but I have a few thoughts and questions. Why do you
| need three layers of RDC? Is this due to networking
| constraints, where the ultimate server (I'll call it the prod
| server) you are trying to reach is unreachable from the
| internet directly? You _might_ be able to tunnel into the
| server using ssh tunnels (see this guide [1]) through an
| intermediate server which your computer and the prod server
| both have access to, and then you 'd be able to directly scp
| or rsync files to the server, as well as run commands over
| ssh, but this would be increasing your attack exposure from a
| security perspective, which folks may not be happy about
| since you're at a large engineering company.
|
| A few questions that would help me give more actionable
| advice: What is the "tester" you're using? Is it essential to
| interact with it via a GUI or does it have a command line
| interface you would prefer to use? Is the OS Linux or
| Windows? What are the the three layers of RDC?
|
| Feel free to email me at my hn username @gmail.com to discuss
| further since this is getting pretty specific to your setup!
| Sounds like a fun problem to try and solve :)
| bayindirh wrote:
| I personally prefer Eclipse Remote Development Tools, which can
| either work via a dedicated daemon, or SSH.
| qsort wrote:
| git?
|
| If it's impossible to clone the environment for some reason, VS
| Code and JetBrains IDEs have remote support. Even vim can edit
| remote files.
|
| It's not clear from your question what exactly is your problem,
| would you be willing to elaborate?
| paskozdilar wrote:
| Since I like my local development environment, I mostly use
| `sshfs`.
|
| It mounts a remote directory onto a local directory and lets you
| access remote files as if they're local, with slight latency.
| Then you can use whatever tools you use locally to
| edit/compile/run the software.
| ufo wrote:
| I also use this setup. Works well for editing and reading the
| files. But be aware that some file-intensive operations don't
| work as well. It is better to grep or git in the remore server
| instead of in the local mount. Be careful if your shell prompt
| is configured to show git status, because that won't be
| instantaneous.
| mekster wrote:
| sshfs works for only 10 files or less project.
| barefeg wrote:
| Has anyone tried something like codespaces? I use vscode with
| either ssh, container dev, or both. But I feel it's sometimes a
| bit slow. I'm wondering if a managed service could provide a
| better ux
| jve wrote:
| Visual Studio Code Remote SSH?
| https://code.visualstudio.com/docs/remote/ssh it will however
| install VS Code Server on target machine. So, for permanent
| development it is good. Not great if you only want to change one
| config file in PROD environment.
|
| > The Visual Studio Code Remote - SSH extension allows you to
| open a remote folder on any remote machine, virtual machine, or
| container with a running SSH server and take full advantage of VS
| Code's feature set. Once connected to a server, you can interact
| with files and folders anywhere on the remote filesystem.
|
| Once connected, even terminal runs on remote host. Moreover you
| get to forward ports from remote host to local using VSCode UI.
| dezmou wrote:
| It also do a lot of other stuff, for instance, if you have a
| python linter that need the python binary to check code, then
| you can specify the python path of the remote machine and vs-
| code will use it for linting, work also with other langages
| like C.
|
| Also you can use embeded terminal and type "code myfile.txt"
| and it will open the file.
|
| If used with windows, it also automaticaly remap localhost to
| the machine if you are launching a local server with your
| terminal (can be annoying tho)
|
| Basicaly it try to do everything to make you feel that you
| aren't on a remote ssh connexion and it work really well
| samwillis wrote:
| I have recently started using this for a project, I'm on a Mac
| and the legacy codebase only supports CentOS7... I have a VM
| setup on my machine and use VS Code to "remotely" develop on
| the VM. Works really well!
| captrb wrote:
| I'm experimenting with using this VSCode feature to edit code
| on a Spark master, with the code storage on an EFS volume. So
| far, this seems to be allowing me to have a local-feeling
| environment, with a well-factored codebase that I can reference
| from a Jupyter notebook (inside VSCode), that has high-
| bandwidth and low-latency access to our data repositories.
|
| I can also choose to temporarily vertically scale the remote
| host if I want to run single-node operations (ie Pandas).
| IE6 wrote:
| Is it possible to work locally doing all the fun stuff in a kind
| of "stage" env and then push via scp or some other ssh based
| mechanism to the remote?
| ChuckMcM wrote:
| That the answer isn't "well you just tunnel X11 and bring up your
| regular work flow." is interesting to me. Because for literally
| _decades_ this was a completely solved problem.
|
| That it is a question always makes me wonder what was in it for
| the purveyor's of OS software to make this so impossible to do.
| rank0 wrote:
| MacOS appears to make this intentionally difficult. I've tried
| with stuff like xQuartz but its finicky and Apple is extremely
| hostile to non-apple interoperability.
| Steltek wrote:
| Achieving tunneled X applications is not hard, as you said it's
| a solved problem, but I have never found it worth the effort
| either.
|
| 1. VNC has a "stable session" that doesn't collapse when SSH
| closes. Even between Linux machines, I chose VNC when needing a
| permanent remote GUI.
|
| 2. Remote machines don't always have your preferred
| applications or the associated preferred configuration. Copying
| a light .vimrc was always easier than trying to export-import a
| heavier app.
|
| 3. Performance always sucked. Even between machines sitting
| next to each other.
|
| 4. I didn't edit files with a GUI app anyway. Didn't everyone
| just use Vim, Emacs, or Nano? Was remote GUI apps ever anyone's
| preferred method (X11 or not)?
| ChuckMcM wrote:
| 4.) I typically just spawn a few xterms (edit, build/debug
| (typically using screen), and i/o).
|
| 3.) No, performance has been fine using X11 apps that were
| built with X11 in mind (vs Wayland or some sort of locally
| accelerated GPU helper(do you really need 25% transparent
| dialog boxes?))
|
| 2.) There is remote machine I own/control (it has all the
| things I need) and going into a system that someone else has
| asked me to develop on (then ANSI terminal tools over SSL are
| always working)
|
| 1.) VNC has always been hit or miss for me, I do typically
| use screen(1) to keep sessions alive if for some reason the
| network dies in the middle.
|
| But all fine points.
| qbasic_forever wrote:
| These days services are typically small containers with just
| enough binaries and dependencies to run the code, so bringing
| up a full X11 server session and tunneling it locally isn't
| really feasible or smart.
| kkfx wrote:
| If it's a serious, non casual/on-the-spot usage work on a local
| copy and sync it, it does not matter if it's a repo or something
| you rsync/unison that's the top performant, comfortable and safe
| way. Networked computing does not means do anything via network
| and desktops are not despite all tentative in this direction
| "endpoint" or modern dumb terminal of a remote mainframe-alike
| server.
|
| If it's casual edit you need to do ssh is enough, via TRAMP (who
| can work on various protocols transparently, not just ssh) if you
| are in Emacs or perhaps with sshfs for an editor-neutral solution
| (knowing it does not offer a full POSIX fs).
|
| For testing again ssh is a very common and friendly option.
| cudgy wrote:
| git clone
| karmakaze wrote:
| JetBrains IDEs (some/all?) have a menu option
| Tools->Deployment->Configuration where you can specify remotes
| via ssh and sync via rsync.
|
| I only use one-way sync from local to remote though 2-way is also
| supported. I simply git fetch/checkout on remote first, then git
| fetch/checkout the same branch on local. You can set up a local
| script to do both together.
|
| Once in that state, any locally changed files get sent to remote
| faster than I can switch focus to the terminal and enter a
| command/enter.
|
| There's also a Remote Development (beta) feature that essentially
| runs the JetBrains IDE headless on the remote and a local
| 'display server'. Performance largely depends on the performance
| of remote and network bandwidth much more than the Deployment
| Configuration rsync method.
| ghishadow wrote:
| Lapce (lapce.dev) remote development is pretty good, I wish
| Sublime Text has something like that, Lapce also has good
| integration with WSL. I tried Vscode but it doesn't work on
| Firefox level codebase.
___________________________________________________________________
(page generated 2022-04-11 23:02 UTC)