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.
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 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.
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.
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 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
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.
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.
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.
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.
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
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!
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).
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!
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.
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.
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.
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.
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.
I'm running a NixOS VM. I've tried to dockerize it before but inevitably something always failed - with the VM approach it is always much more stable.
I just run it right in VMware Fusion / Workstation, and it works great. Extremely reliable, very low overhead still. It just takes a lot of storage is all :) But everything is always reproducible given the nature of the VM, without needing to pass around snapshots or clones.
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.
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.
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.
> 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.
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.
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.
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?
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.
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.
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.
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.
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.
(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.
> (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.
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.
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!
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.
> 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.
- 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.
SSHFS caches reads on my machine. Here's a sequential timing of sha256sum operation on a ~10MiB file:
$ time sha256sum file
c2359f8b63dfef9f50e62b2e7b4ef2613c290c3a1ffa135cfa255b14eafd3ffb file
real 0m5,205s
user 0m0,127s
sys 0m0,011s
$ time sha256sum file
c2359f8b63dfef9f50e62b2e7b4ef2613c290c3a1ffa135cfa255b14eafd3ffb 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.
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.
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!
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?
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 :)
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.
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.
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.
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.
Actually, you're right. I just tested recursively grepping a remote directory with a thousand 16KiB files. The speed is completely catastrophic:
$ time grep -r foo test
...
real 7m36,154s
user 0m0,110s
sys 0m0,249s
The average download speed from remote host is ~2MiB/s, so it isn't a network issue - a thousand 16KiB files sum up to 16MiB so it shouldn't take more than ten seconds. Seven minutes is terrible.
I don't understand why is this happening. Is this an inherent limitation of remote filesystems or is sshfs implementation just sucky?
EDIT: parallelization seems to help - running 100 concurrent reads at a time uses up to ~1MiB bandwidth. I suppose ordinary unix tools don't play well with remote filesystems because they do stuff sequentially.
That being said, if JetBrains is struggling with SSHFS, then they really need to fix their file browsing code.
I think it's because it's not simply a file download but instead keeps on asking for file content or meta data making a roundtrip on each files to cause excessive latencies against many files.
All the tools are basically designed to work on local files and they tend to work bad interacting directly on mounted file systems.
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.
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.
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.
I've been using GH Codespaces for a side project when on the go for a while now. When I'm travelling or recently when moving house I've been able to use my terrible but light weight laptop with vscode + gh codespaces. It's been a complete dream! When running the same project locally on the laptop it's slow and makes development a real pain but codespaces has given the laptop a new lease of life.
I'm not sure if the price lines up well enough for a daily-drive for a company, but if I were managing dev environments for an org these days I'd probably jump to something similar. Perhaps something like a decent size EC2 on AWS where devs can tear it down and spin it up again to start from scratch within a couple minutes.
Throw away dev environments feels like a game changer having used it for the past 6 months on-the-go.
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.
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.
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)?
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.
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.
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.
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.
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.
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.
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..
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.
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).
...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.
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:
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.
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.
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 :-)
nano is a surprisingly capable code editor. I like using 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 (line based or more fine-grained), a very efficient search and replace that can cross files, syntax highlighting (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]
If you don't expect a very powerful editor, nano can be a good companion, but it is actually more powerful than most people think it is.
> 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.
Also think of using screen or tmux or one of their alternatives in case your session breaks. It's bad enough being slowed down by a flaky connection, losing the session is very disruptive even if they produce backup files. There's also Emacs which comes with a server, I would expect it to survive connection losses but don't quote me on that.
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".
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.
A coworker of mine works locally in $editor_of_choice (which is VS for C#, VSC for most others, some weird DB system for SQL), and has a window of Beyond Compare always on top; that allows him to see what files are different locally/remote and push them (he compiles/tests remotely). Might work for you too.
Another useful option, depends on your specifics, is the Plan 9 "cpu" command[0], available for Linux at [1]. It takes an unusual approach, which is IMHO superior for embedded machines, but which may work well for some other use cases (though not all).
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.
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.
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.
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.
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.
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.
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.
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
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.)
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.
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.
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.
If you have fast internet, I like X forwarding. I used to run IntelliJ on my work computer in the office and render the window on my home computer. Everything is running on my beefy work computer and is local in the office. If you can SSH you can add a few parameters to the SSH command to do X forwarding.
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.
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".
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.
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?
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.
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.
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.
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
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
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.
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.