3 ms·

Some painpoints wrt DevPod: In order to get devpod ssh to work, DevPod injects itself into your host machine (where all the devcontainers run). When you ssh in

Some painpoints wrt DevPod: In order to get devpod ssh to work, DevPod injects itself into your host machine (where all the devcontainers run). When you ssh into your devcontainer, devpod's ssh implementation acts as a proxy into the container, allowing you to get an in-container shell without having to run sshd inside the container. But people are already injecting VS Code into remote machines, so maybe this doesn't matter to you. DevPod's ssh implementation does not handle newlines properly; full-screen displays can get garbled on many terminals. But most DevPod users are using the terminal inside VS Code, which seems to work fine.

fahhem 3y ago
Looking at my ssh config, devpod injected a Host and that's it there's nothing extra in the container. Instead, there's a ProxyCommand that runs devpod, which probably ends up in a docker exec somewhere. That's why you're having trouble with newline and larger terminals, I used to as well because the terminal escape codes for resizing weren't getting through to the shell inside the container. In the past, I had to resize the terminal once manually after execing in, but I think either docker or bash or something in the chain got an update in the past few years that fixed it to automatically work
- bitwize 3y ago
  Not in the container, in the host. If containers are running on your local PC, you'll be fine, but if you're logging in remotely DevPod will inject itself into your remote host. Do a 'ps -aux | less' while ssh'd in to your container sometime and be ready for a surprise.
  - fahhem 3y ago
    Ah, I never considered running it remotely. I'm not onboard the 'dev in the cloud' train, mainly because of round trip latency
    - bitwize 3y ago
      There's no round trip latency when you use VS Code's remote editing capability.
      - fahhem 3y ago
        You're right, though I didn't mean just the editing latency. For web projects, the latency is now between me and some dev server in the cloud vs localhost, and for CLI as well. For GUIs or anything that interacts with my OS (such as "applets") or my hardware devices now I have to download the program to test it. For web projects, I understand that latency should be considered, but I've learned what's important there and don't want to build/compile/minify my projects in development so I'm wasting time downloading the same MB's of JS over and over when only a few bytes changed so I'm not getting cache hits.

fahhem 3y ago

Looking at my ssh config, devpod injected a Host and that's it there's nothing extra in the container. Instead, there's a ProxyCommand that runs devpod, which probably ends up in a docker exec somewhere. That's why you're having trouble with newline and larger terminals, I used to as well because the terminal escape codes for resizing weren't getting through to the shell inside the container. In the past, I had to resize the terminal once manually after execing in, but I think either docker or bash or something in the chain got an update in the past few years that fixed it to automatically work

bitwize 3y ago
Not in the container, in the host. If containers are running on your local PC, you'll be fine, but if you're logging in remotely DevPod will inject itself into your remote host. Do a 'ps -aux | less' while ssh'd in to your container sometime and be ready for a surprise.
- fahhem 3y ago
  Ah, I never considered running it remotely. I'm not onboard the 'dev in the cloud' train, mainly because of round trip latency
  - bitwize 3y ago
    There's no round trip latency when you use VS Code's remote editing capability.
    - fahhem 3y ago
      You're right, though I didn't mean just the editing latency. For web projects, the latency is now between me and some dev server in the cloud vs localhost, and for CLI as well. For GUIs or anything that interacts with my OS (such as "applets") or my hardware devices now I have to download the program to test it. For web projects, I understand that latency should be considered, but I've learned what's important there and don't want to build/compile/minify my projects in development so I'm wasting time downloading the same MB's of JS over and over when only a few bytes changed so I'm not getting cache hits.