Show HN: Lapdev, a new open-source remote dev environment management software
1–10 of 71 posts
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#2This looks pretty good. Being able to use devcontainers on local server hardware without monthly fees (and/or hetzner servers) sounds great.
Up until now we’d been making do with docker-compose and JetBrains’s remote SSH dev; this should be significantly better.
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#3I'm very interested to learn more about this class of tool. I had seen[0] Coder including alpha support for .devcontainer, but I'm not aware of other OSS options.
0. https://coder.com/docs/v2/latest/templates/devcontainers#dev...
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#4[dead]
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#5This looks pretty good. Being able to use devcontainers on local server hardware without monthly fees (and/or hetzner servers) sounds great. Up until now we’d been making do with docker-compose and JetBrains’s remote SSH dev; this should be significantly better.
I spent more than a year living with the numerous downsides of high level CDE (containerized development environment) tools. I must admit that I am very skeptical about all options available right now and that I have rolled back to using plain, old school, docker compose based CDE.
Both .devcontainers and .devfile managed to create more effort than they took away. Some key points:
- long lived containers
- abstracting away the fact that you run stuff inside containers in the IDE and abstracting away the container life cycle
- cryptic error states and error messages, especially when setting up new projects from scratch. This often boiled down to bad plugins (even Microsoft's own VSCode plugins wet the bed often)
- only superficial support for podman
- bad support for arm based HW (and arch translation issues, like a tool requesting arm containers but the host running docker is x64)
At this point I consult teams to try out a plain compose.yml as a CDE and skip the "enterprise" stuff.
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#6I don't understand. It's installed on a remote server, okay.
But does it provide remote environments or local environments ?
And what's an environment in this context ? A Docker compose file and a .env? Code or vim settings ? A vm à la vagrant ?
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#7It's open-core https://github.com/lapce/lapdev/blob/8eeb3cc3cbbf4c5bf4e7928... , if you care about that.
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#8So, I know very little about this devcontainer spec.
Can I just ask, what value does this spec provide that a simple docker image containing the necessary tools does not already provide?
Why do we need another layer on top? What am I missing?
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#9I don't understand. It's installed on a remote server, okay. But does it provide remote environments or local environments ? And what's an environment in this context ? A Docker compose file and a .env? Code or vim settings ? A vm à la vagrant ?
Hi, Lapdev dev here. Let me try to answer your question.
It's installed on a remote server so it provides remote environments. If you use VSCode remote, then you can "open" it through VSCode remote ssh.
The environment that Lapdev provides essentially is a container (other format is on the roadmap) with things pre-installed as defined in Devcontainer(https://containers.dev/) format.
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#10So, I know very little about this devcontainer spec. Can I just ask, what value does this spec provide that a simple docker image containing the necessary tools does not already provide? Why do we need another layer on top? What am I missing?
JSON, everything has to either be YAML or JSON.
If I didn't invent the thing, then we shouldn't use the thing. Dockerfiles fall into this class too, they are just a shitty homegrown DSL.