4 ms·

I don't know what the alternative would be here. VSCode's SSH edit works surprisingly well, and I stopped fiddling with vim, nano, or micro on my remote machine

I don't know what the alternative would be here. VSCode's SSH edit works surprisingly well, and I stopped fiddling with vim, nano, or micro on my remote machines long ago. The agent gets out of my way and lets me work in peace. It almost feels like I'm working from my local machine—a huge win in my book. This could be a security risk, but the development experience is unmatched. I couldn't care less which other editor VSCode is killing, as I mostly don't care about my tools as long as they get out of the way and let me do my job.

otabdeveloper4 2y ago
> I don't know what the alternative would be here. Emacs' TRAMP is pretty crap but still more reliable and user-friendly than the hot mess of VSCode remote editing.
- rednafi 2y ago
  > Hot mess of VSCode editing Okay. I have been using VSCode remote session since its inception and it works well for my case. Also, Vim/Emacs aren’t my cup of tea, so it’s not like that I have many options.
  - otabdeveloper4 2y ago
    > and it works well for my case Yes, if you're using a Microsoft (c) approved and tested system configuration.
    - int_19h 2y ago
      I'm using it daily on a variety of Linux distros and macOS.
spacemanspiff01 2y ago
The security risk comes from all those unvetted plugins, that have unrestricted access to the editor.
- rednafi 2y ago
  Yeah, I'm all in for a more secure option as long as it allows me to do everything that VSCode's SSH agent does. But if the devex goes down the drain because of "security" then I'm good for now.
- shipp02 2y ago
  That's an issue with any plugin system, right? AFAIK no IDE has a plugin system with capabilities or a sandboxed interpreter. VSCode does have a thing where it's like do you trust the authors of this project. Not sure what it does because I've never had to use it. From StackOverflow[1]: >If you select No, I don't trust the authors, Visual Studio Code will open the workspace in 'restricted mode'. This is the default for all new workspaces. It lets you safely browse through code but disables some editor feature, including debugging, tasks, and many extensions. However, keep in mind that 'restricted mode' is all you need for many use cases. Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs. [1]:https://stackoverflow.com/a/67914669/11422647 https://stackoverflow.com/a/67914669/11422647 [2]:https://code.visualstudio.com/docs/editor/workspaces/workspace-trust#_restricted-mode https://code.visualstudio.com/docs/editor/workspaces/workspa...
  - vlovich123 2y ago
    > Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs. Unfortunately, it’s not. Restricted mode is VSCode without any plugins. That means that unless you’re doing very basic TS development (I think that’s the only language VSCode supports out of the box), then you’re kinda hosed.
  - retsl 2y ago
    There's a feature request from 2018 to add a proper permission model for plugins in VSCode: https://github.com/microsoft/vscode/issues/52116 https://github.com/microsoft/vscode/issues/52116 Sadly it doesn't seem to make any progress.
    - 3eb7988a1663 2y ago
arp242 2y ago
> I don't know what the alternative would be here I'm not sure what features VSCode offers exactly, but I find sshfs works quite well for remote editing of a bunch of stuff. I think it should basically be the same as VSCode?
- rednafi 2y ago
  One fewer tool to think about. It remembers the connections and instantly gives you access to a full-fledged editor on a remote server. It just works, and I don’t think about it twice, which is a huge win in my book. I’m good with the trade-offs.
  - arp242 2y ago
    Okay fair enough; just saying it seems like a reasonable alternative if you want to avoid fiddling with editors on remote machines.
    - vlovich123 2y ago
      It’s still not quite the same thing because it feels like you’re literally sitting at the remote machine; the code completion is there using an LSP that doesn’t have to pay a network cost, executables run locally which means you can be on a local Windows and remote Linux or vice-versa, and all in a super easy to use package that auto-restores the session whenever you come back even if you’ve put the machine to sleep. By comparison, I’d say doing things over sshfs and terminals is the fiddling part.
- sunshowers 2y ago
  You really want your LSPs to run on the remote, especially with high-latency connections.
  - Dylan16807 2y ago
    Why is that? How much data are we expecting the LSP to ingest? For most projects my expectation is that all the source code gets quickly cached on my machine, and from then on querying a local LSP is much faster. Especially with high-latency connections.
saulrh 2y ago
The alternative is suggested by tramp, which from what I know treats the remote as a network filesystem instead of an execution host. I don't believe that tramp deploys any binaries: it reads and writes bytes over pipes and all meaningful execution happens locally. Notably, it does not achieve persistence, because there's a difference between "VSCode plugins have access while you're SSH'd in" and "VSCode plugins have access forever".
- rednafi 2y ago
  Persistence is important to me, and making it read-only significantly reduces its usefulness. I regularly SSH into a dev machine to run scripts and update configurations. As long as a tool lets me do that without getting in my way, I'm good with any solution that works.
  - skydhash 2y ago
    Then tramp would be a perfect fit for you as long as you’re willing to learn emacs. If you open a remote file, almost all actions when that buffer is selected will execute in the remote context (launching commands, visiting directories, opening a shell,…)
    - rednafi 2y ago
      Yep. I, for one, couldn’t care less about picking up Emacs, Vim, or any of these modal editors. So, VSCode it is.
      - eru 2y ago
        Emacs is not a modal editor.
      - homebrewer 2y ago
        You don't know what you're missing then and I'm not sure such opinions count. It's probably for the best to refrain from criticizing things one has no experience in.
sevensor 2y ago
From what I’ve seen, my colleagues using vscode are hampered in ways they don’t recognize because they have no concept of how good things could be. Working with multiple remotes, they’re often completely unaware of which one they’re connected to or what state their connection is in. Their terminals are laggy and session state persistence is inconsistent. It’s just a massively worse experience than tmux + a real text editor. Plus the server is a real pig and they often end up running half a dozen server instances because the server doesn’t terminate properly. And then, half the updates break and they lose an hour because they don’t know how to ssh into the host with a real ssh client and clean up the busted vscode server.
mixmastamyk 2y ago
Me, me, me, got it. Unfortunately there are other folks in the world. ;-) Students need to focus on fundamentals, not the fanciest automatic whiz-bang tools available. Why we learn arithmetic before allowing calculators.

otabdeveloper4 2y ago

> I don't know what the alternative would be here. Emacs' TRAMP is pretty crap but still more reliable and user-friendly than the hot mess of VSCode remote editing.

rednafi 2y ago
> Hot mess of VSCode editing Okay. I have been using VSCode remote session since its inception and it works well for my case. Also, Vim/Emacs aren’t my cup of tea, so it’s not like that I have many options.
- otabdeveloper4 2y ago
  > and it works well for my case Yes, if you're using a Microsoft (c) approved and tested system configuration.
  - int_19h 2y ago
    I'm using it daily on a variety of Linux distros and macOS.

spacemanspiff01 2y ago

The security risk comes from all those unvetted plugins, that have unrestricted access to the editor.

rednafi 2y ago
Yeah, I'm all in for a more secure option as long as it allows me to do everything that VSCode's SSH agent does. But if the devex goes down the drain because of "security" then I'm good for now.
shipp02 2y ago
That's an issue with any plugin system, right? AFAIK no IDE has a plugin system with capabilities or a sandboxed interpreter. VSCode does have a thing where it's like do you trust the authors of this project. Not sure what it does because I've never had to use it. From StackOverflow[1]: >If you select No, I don't trust the authors, Visual Studio Code will open the workspace in 'restricted mode'. This is the default for all new workspaces. It lets you safely browse through code but disables some editor feature, including debugging, tasks, and many extensions. However, keep in mind that 'restricted mode' is all you need for many use cases. Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs. [1]:https://stackoverflow.com/a/67914669/11422647 https://stackoverflow.com/a/67914669/11422647 [2]:https://code.visualstudio.com/docs/editor/workspaces/workspace-trust#_restricted-mode https://code.visualstudio.com/docs/editor/workspaces/workspa...
- vlovich123 2y ago
  > Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs. Unfortunately, it’s not. Restricted mode is VSCode without any plugins. That means that unless you’re doing very basic TS development (I think that’s the only language VSCode supports out of the box), then you’re kinda hosed.
- retsl 2y ago
  There's a feature request from 2018 to add a proper permission model for plugins in VSCode: https://github.com/microsoft/vscode/issues/52116 https://github.com/microsoft/vscode/issues/52116 Sadly it doesn't seem to make any progress.
  - 3eb7988a1663 2y ago

arp242 2y ago

> I don't know what the alternative would be here I'm not sure what features VSCode offers exactly, but I find sshfs works quite well for remote editing of a bunch of stuff. I think it should basically be the same as VSCode?

rednafi 2y ago
One fewer tool to think about. It remembers the connections and instantly gives you access to a full-fledged editor on a remote server. It just works, and I don’t think about it twice, which is a huge win in my book. I’m good with the trade-offs.
- arp242 2y ago
  Okay fair enough; just saying it seems like a reasonable alternative if you want to avoid fiddling with editors on remote machines.
  - vlovich123 2y ago
    It’s still not quite the same thing because it feels like you’re literally sitting at the remote machine; the code completion is there using an LSP that doesn’t have to pay a network cost, executables run locally which means you can be on a local Windows and remote Linux or vice-versa, and all in a super easy to use package that auto-restores the session whenever you come back even if you’ve put the machine to sleep. By comparison, I’d say doing things over sshfs and terminals is the fiddling part.
sunshowers 2y ago
You really want your LSPs to run on the remote, especially with high-latency connections.
- Dylan16807 2y ago
  Why is that? How much data are we expecting the LSP to ingest? For most projects my expectation is that all the source code gets quickly cached on my machine, and from then on querying a local LSP is much faster. Especially with high-latency connections.

saulrh 2y ago

The alternative is suggested by tramp, which from what I know treats the remote as a network filesystem instead of an execution host. I don't believe that tramp deploys any binaries: it reads and writes bytes over pipes and all meaningful execution happens locally. Notably, it does not achieve persistence, because there's a difference between "VSCode plugins have access while you're SSH'd in" and "VSCode plugins have access forever".

rednafi 2y ago
Persistence is important to me, and making it read-only significantly reduces its usefulness. I regularly SSH into a dev machine to run scripts and update configurations. As long as a tool lets me do that without getting in my way, I'm good with any solution that works.
- skydhash 2y ago
  Then tramp would be a perfect fit for you as long as you’re willing to learn emacs. If you open a remote file, almost all actions when that buffer is selected will execute in the remote context (launching commands, visiting directories, opening a shell,…)
  - rednafi 2y ago
    Yep. I, for one, couldn’t care less about picking up Emacs, Vim, or any of these modal editors. So, VSCode it is.
    - eru 2y ago
      Emacs is not a modal editor.
    - homebrewer 2y ago
      You don't know what you're missing then and I'm not sure such opinions count. It's probably for the best to refrain from criticizing things one has no experience in.

sevensor 2y ago

From what I’ve seen, my colleagues using vscode are hampered in ways they don’t recognize because they have no concept of how good things could be. Working with multiple remotes, they’re often completely unaware of which one they’re connected to or what state their connection is in. Their terminals are laggy and session state persistence is inconsistent. It’s just a massively worse experience than tmux + a real text editor. Plus the server is a real pig and they often end up running half a dozen server instances because the server doesn’t terminate properly. And then, half the updates break and they lose an hour because they don’t know how to ssh into the host with a real ssh client and clean up the busted vscode server.

mixmastamyk 2y ago

Me, me, me, got it. Unfortunately there are other folks in the world. ;-) Students need to focus on fundamentals, not the fanciest automatic whiz-bang tools available. Why we learn arithmetic before allowing calculators.