3 ms·

> Why is VS code the defacto answer nowadays? For what I do, there's no reasonable alternative at the moment. I'm sure someone will correct me, but it's the o

by DrBazza 9mo ago

> Why is VS code the defacto answer nowadays? For what I do, there's no reasonable alternative at the moment. I'm sure someone will correct me, but it's the only editor that correctly (for some definition of correct) allows remote editing and devcontainers: [desktop OS] -> ssh -> [dest box] [desktop OS] -> [devcontainer] [desktop OS] -> ssh -> [dest box] -> [devcontainer] [desktop OS] -> ssh (jumphost) -> [dest box] -> [devcontainer] I won't name and shame other editors (or IDEs), but either they simply can't do that, or their performance is absolutely, shockingly, abysmal.

boomlinde 9mo ago
I would rather solve file access at an entirely different level. A filesystem is a reasonable, editor-agnostic abstraction for this, and I can use sshfs to mount a remote directory over SSH in a way that's invisible to whatever tools I prefer to use to edit the files. If you have a jumphost chain, you can configure that in the SSH config. I don't know what a devcontainer is exactly, but if it's a container in the sense that it runs a Linux development system, I would investigate whether that, too, could easily be set up for access via SSH or mounted locally through some other mechanism.
- DrBazza 9mo ago
  File access isn't the same as tool access. You need to run tools on your ssh host as well. And a devcontainer does indeed equal a (docker) container. The name is very specific and describes shipping a full developer environments so that 'you' do not have to install gcc-toolset-15, or boost 1.83, or mold, or python 3.11, and so on. https://containers.dev/ https://containers.dev/
  - boomlinde 9mo ago
    > File access isn't the same as tool access. Running tools remotely isn't the same as remote editing, so you'll have to forgive the misunderstanding. > You need to run tools on your ssh host as well. `ssh user@remote tool`. Indeed, the tool you run on the remote host could be a text editor in itself.
    - DrBazza 9mo ago
      Interesting. Something to think about. Thanks.

by DrBazza 9mo ago

boomlinde 9mo ago

I would rather solve file access at an entirely different level. A filesystem is a reasonable, editor-agnostic abstraction for this, and I can use sshfs to mount a remote directory over SSH in a way that's invisible to whatever tools I prefer to use to edit the files. If you have a jumphost chain, you can configure that in the SSH config. I don't know what a devcontainer is exactly, but if it's a container in the sense that it runs a Linux development system, I would investigate whether that, too, could easily be set up for access via SSH or mounted locally through some other mechanism.

DrBazza 9mo ago
File access isn't the same as tool access. You need to run tools on your ssh host as well. And a devcontainer does indeed equal a (docker) container. The name is very specific and describes shipping a full developer environments so that 'you' do not have to install gcc-toolset-15, or boost 1.83, or mold, or python 3.11, and so on. https://containers.dev/ https://containers.dev/
- boomlinde 9mo ago
  > File access isn't the same as tool access. Running tools remotely isn't the same as remote editing, so you'll have to forgive the misunderstanding. > You need to run tools on your ssh host as well. `ssh user@remote tool`. Indeed, the tool you run on the remote host could be a text editor in itself.
  - DrBazza 9mo ago
    Interesting. Something to think about. Thanks.