4 ms·

>Remote editing does not work on Windows (its not implemented at all), so if you are on windows, you cannot ssh into anything with the editor remote editing fea

>Remote editing does not work on Windows (its not implemented at all), so if you are on windows, you cannot ssh into anything with the editor remote editing feature. This means you cannot use your PC as a thin client to the actual chunky big work machine like you can with vscode. Does this work on anything other than VSCode ? I have been trying to use JetBrains stuff for this but it has been bad for years with little improvement. Honestly JetBrains feels like they are falling behind further and further in terms of adapting to providing a modern workflow - bad remote work, bad gen AI integration. I'm using VS code even where I wouldn't consider it before because of this, and I would like to see what the alternatives have to offer because VSCode is not perfect either.

lionkor 2y ago
Works on JetBrains, vscode, any terminal editor (neovim, vim, nano, etc.). Is it any good? It's fine on JetBrains, great on vscode, the rest is more or less great. Zed does not have it. You want to edit a remote file? You download it, edit it, upload it. That's much worse than a half baked implementation.
- spmurrayzzz 2y ago
  For clarity, this does work with the mac os version of Zed. I use it frequently to work on my GPU nodes. The one tradeoff that is a bit of a smell for me is that the preview version of the feature requires you talk to a centralized broker on Zed's servers rather than fully p2p between your local IDE and your own server. This is supposedly temporary though IIRC (may even be changed already in a dev branch, not sure).
pjmlp 2y ago
As someone that is old enough to have used UNIX development servers for the whole company, with PC thin clients, reading about remote development as modern workflow is kind of hilarious.
- scottlamb 2y ago
  The remote development feature implemented in VS Code—and I believe also in beta in Zed—is a million times better than what you're used to. The UI is local, the storage and computation (including the language server) are remote. This takes away the lag when connected to a far-away server while still allowing things like platform-dependent compilation to work correctly and efficiently.
  - pjmlp 2y ago
    For the last 35 years, X Windows, Citrix and RDP have done the job just fine, in what I am concerned. No, they aren't anything better than what I am used to. Also, as compromise, a cloud shell, browser based IDE setup, and dev containers, also does the job in what concerns cloud deployments, which should be driven from CI/CD and don't have shells on containers anyway.
    - scottlamb 2y ago
      Good for you, I guess? For me, regressing to having a round trip between a keypress and its result would be completely unacceptable. The speed of light in a vacuum doesn't change; paths are not getting significantly more direct; the improved index of refraction from switching to hollow-core fiber or low-orbit satellites could in theory help but is a one-time, limited improvement that has yet to be delivered to my fingertips. Having the network boundary in the correct place to account for the fundamental physics of the situation is the only real answer.
      - makapuf 2y ago
        Winscp open file + copy back on write detect was very useful for local-speed relote editing 10 years ago. Only issue now would be no lsp.
      - pjmlp 2y ago
        Also using gold audio cables, I guess. Lets not let go aways of those Hz that hardly any human notices.
MobiusHorizons 2y ago
It’s not exactly the same paradigm as remote editing, but neovim in tmux accessed over mosh is my preferred way of accomplishing the same task. I have also gotten a neovim gui to connect with a neovim instance over ssh, which worked pretty well until the ssh connection broke. But I prefer my editor in a terminal rather than terminals in my editor, so I switched back to my tmux based workflow.
- jwiz 2y ago
  If you are already using tmux, what is the value of using mosh? Sincere question.
  - MobiusHorizons 2y ago
    Basically the benefit is not losing context when I close my laptop lid or if I lose network briefly. I actually use multiple tmux sessions in my workflow, so it also saves me having to remember which one I was working in. This is especially useful if I am on a spotty connection such as tethered through my phone.
  - attentive 2y ago
    tmux is session management. Mosh is low latency udp transport.

lionkor 2y ago

Works on JetBrains, vscode, any terminal editor (neovim, vim, nano, etc.). Is it any good? It's fine on JetBrains, great on vscode, the rest is more or less great. Zed does not have it. You want to edit a remote file? You download it, edit it, upload it. That's much worse than a half baked implementation.

spmurrayzzz 2y ago
For clarity, this does work with the mac os version of Zed. I use it frequently to work on my GPU nodes. The one tradeoff that is a bit of a smell for me is that the preview version of the feature requires you talk to a centralized broker on Zed's servers rather than fully p2p between your local IDE and your own server. This is supposedly temporary though IIRC (may even be changed already in a dev branch, not sure).

pjmlp 2y ago

As someone that is old enough to have used UNIX development servers for the whole company, with PC thin clients, reading about remote development as modern workflow is kind of hilarious.

scottlamb 2y ago
The remote development feature implemented in VS Code—and I believe also in beta in Zed—is a million times better than what you're used to. The UI is local, the storage and computation (including the language server) are remote. This takes away the lag when connected to a far-away server while still allowing things like platform-dependent compilation to work correctly and efficiently.
- pjmlp 2y ago
  For the last 35 years, X Windows, Citrix and RDP have done the job just fine, in what I am concerned. No, they aren't anything better than what I am used to. Also, as compromise, a cloud shell, browser based IDE setup, and dev containers, also does the job in what concerns cloud deployments, which should be driven from CI/CD and don't have shells on containers anyway.
  - scottlamb 2y ago
    Good for you, I guess? For me, regressing to having a round trip between a keypress and its result would be completely unacceptable. The speed of light in a vacuum doesn't change; paths are not getting significantly more direct; the improved index of refraction from switching to hollow-core fiber or low-orbit satellites could in theory help but is a one-time, limited improvement that has yet to be delivered to my fingertips. Having the network boundary in the correct place to account for the fundamental physics of the situation is the only real answer.
    - makapuf 2y ago
      Winscp open file + copy back on write detect was very useful for local-speed relote editing 10 years ago. Only issue now would be no lsp.
    - pjmlp 2y ago
      Also using gold audio cables, I guess. Lets not let go aways of those Hz that hardly any human notices.

MobiusHorizons 2y ago

It’s not exactly the same paradigm as remote editing, but neovim in tmux accessed over mosh is my preferred way of accomplishing the same task. I have also gotten a neovim gui to connect with a neovim instance over ssh, which worked pretty well until the ssh connection broke. But I prefer my editor in a terminal rather than terminals in my editor, so I switched back to my tmux based workflow.

jwiz 2y ago
If you are already using tmux, what is the value of using mosh? Sincere question.
- MobiusHorizons 2y ago
  Basically the benefit is not losing context when I close my laptop lid or if I lose network briefly. I actually use multiple tmux sessions in my workflow, so it also saves me having to remember which one I was working in. This is especially useful if I am on a spotty connection such as tethered through my phone.
- attentive 2y ago
  tmux is session management. Mosh is low latency udp transport.