Live data from Hacker News

Codespaces but open-source, client-only, and unopinionated

devpod.sh

131–140 of 157 posts

Re: Codespaces but open-source, client-only, and unopinionated

#131

I'm glad this space is expanding. This is created by the authors of Loft.sh and Devspaces, both really great solutions to the most common problems of developing natively in a K8s cluster. DevPod is basically Vagrant but with containers, which brings a ton of benefits over the former VM-centric design. You can maintain an entire team (or organization) with one immutable development environment, to get away from the co…

Curious if you tried the devcontainer cli [1] to build your devcontainer.json?

DevPod is another implementation of the devcontainer spec, the most used one being the aforementioned devcontainer cli which vscode uses, or supplies, via its integration.

If you’re having problems with DevPod while they iron out the kinks you might want to try the devcontainer cli, which can build the images, and run them.

1. https://github.com/devcontainers/cli

Re: Codespaces but open-source, client-only, and unopinionated

#132
post #59

> Mac (Silicon) Huh? Yes, it contains silicon.

Short for "Apple Silicon", the marketing name for Apple's own series of ARM CPUs used in Macs since 2020.

It's approximately like shortening "Processor made by Apple" to "Processor". The important bit is gone.

Re: Codespaces but open-source, client-only, and unopinionated

#133

I'm likely not the target audience, but I personally see "client-only" as a disadvantage. Ultimately I use VS Code to stand up devcontainers on my laptop, but I sometimes need to do dev work on my iPad and don't want to pay for Github Codespaces. Gitpod has worked for me in the past and I've gotten Coder setup. Maybe this will be nice to get Jetbrains IDEs working with the devcontainer standard, since IIRC they don't…

Although they've basically closed source it since release, Jetbrains Projector was a fantastic tool I've used a lot in the past for that - Just spin up a docker container on my home server and pull out my ipad keyboard

https://github.com/JetBrains/projector-docker

Unfortunately, It's hard to tell if JetBrains Gateway will keep all of the remote dev features or not.

Re: Codespaces but open-source, client-only, and unopinionated

#135
Trying this out, and a word of caution if you use the SSH provider: it does not check host SSH keys, which is sort of a no-no:

    [15:25:45] debug Run command provider command: ssh -oStrictHostKeyChecking=no
It also seems to rely on the remote server having passwordless sudo, which is... interesting.

Edit: I've managed to make it work with my own solution (https://github.com/rcarmo/azure-dev-bootstrap). It works OK, but since I'm used to provisioning the back-end boxes by myself and using VS Code Remote, there's little practical difference (also, my setup adds the dev box to my Tailscale network).

Would be really nice if the baseline SSH provider (and assumptions as to how the remote SSH server is set up) were fixed, and if I could get it to work on an iPad with Blink shell (edge use case, I know, but I do use that a lot, or just an RDP on Linux desktop).

Oh, and add B-series VMs to the Azure provider. For burstable use like coding, testing, etc., those are much more cost effective.

Re: Codespaces but open-source, client-only, and unopinionated

#137
post #135

Trying this out, and a word of caution if you use the SSH provider: it does not check host SSH keys, which is sort of a no-no: [15:25:45] debug Run command provider command: ssh -oStrictHostKeyChecking=no It also seems to rely on the remote server having passwordless sudo, which is... interesting. Edit: I've managed to make it work with my own solution ( https://github.com/rcarmo/azure-dev-bootstrap ). It works OK, b…

> it does not check host SSH keys

Otherwise DX would be totally ruined. Totally.

> work on an iPad

I never tried, but from the distance it looks like _working_ on such kind of devices is a torture, what's are your impressions, effectiveness comparison to working on laptop (desktop) with real keyboard?

Re: Codespaces but open-source, client-only, and unopinionated

#138
post #59

Earlier quoted context omitted.

Short for "Apple Silicon", the marketing name for Apple's own series of ARM CPUs used in Macs since 2020.

It's approximately like shortening "Processor made by Apple" to "Processor". The important bit is gone.

Fine.

“Mac (Apple)”

Re: Codespaces but open-source, client-only, and unopinionated

#139
post #135

Trying this out, and a word of caution if you use the SSH provider: it does not check host SSH keys, which is sort of a no-no: [15:25:45] debug Run command provider command: ssh -oStrictHostKeyChecking=no It also seems to rely on the remote server having passwordless sudo, which is... interesting. Edit: I've managed to make it work with my own solution ( https://github.com/rcarmo/azure-dev-bootstrap ). It works OK, b…

> it does not check host SSH keys Otherwise DX would be totally ruined. Totally. > work on an iPad I never tried, but from the distance it looks like _working_ on such kind of devices is a torture, what's are your impressions, effectiveness comparison to working on laptop (desktop) with real keyboard?

I prefer iPad over a laptop for a number of reasons:

- My main machine is a Mac desktop. I am not looking to add another powerful machine to the mix that I'm not going to use regularly. The iPad (or even another high quality laptop) would be just used as another beautiful screen, to work or watch Netflix on.

- I have a high quality, ergonomic Bluetooth keyboard that I pair with my both my Mac and my iPad. This means my ergonomics with my iPad is better than using a laptop with it's attached keyboard.

- I'm not looking to do long work sessions on these devices, although I honestly could. It's more for one off things, for updating my org-notes, for having a quick cafe work session, etc.

Re: Codespaces but open-source, client-only, and unopinionated

#140
post #129
post #126

Earlier quoted context omitted.

creating the workspace is based on docker but within the workspace you're free to do whatever you want, no need to use docker-compose there

But then how is this so different from running "docker-compose" and then do whatever you want withing the container? Is the difference just that they provide ready-made Docker images for certain environments so that you don't have to create your own? Can I get the same images on Dockerhub then?

+1, trying to put it my head (disclaimer - I'm a rare user of local docker, as not being developer), hoping to get some insights which may be helpful in better setup for dev team
Post reply on HN