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.

I usually use the this extension: https://marketplace.visualstudio.com/items?itemName=Kelvin.v...

Which doesn't starts up any server on the remote server.

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.

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.

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!

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.

Relatedly, iTerm's tmux integration[1] pairs very well with this setup.

[1]: https://iterm2.com/documentation-tmux-integration.html

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.

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.

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?

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.

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.

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.

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.

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.

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

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.

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.

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.

It is, I have used it and it works great on a pi3.

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?

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

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.

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.

I used this setup a lot myself and it worked great except that name completions, intellisense didn't work as expected.

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

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.

And you can run the debugger!