It's open-core https://github.com/lapce/lapdev/blob/8eeb3cc3cbbf4c5bf4e7928... , if you care about that.
[deleted]
Show HN: Lapdev, a new open-source remote dev environment management software
11–20 of 71 posts
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#12So, 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?
Well, developers seem to love writing "configuration" rather than "code" these days. But basically a container + the necessary tools IS a devcontainer. It's just a way of automating the "putting in the necessary tools" part especially if you need things that might need to be added to a base container, or services that need to be configured differently based on the external environment that you don't want to bake in for some reason.
If you've ever had to cut and paste a 50 line docker run command snippet but you forgot that one volume mount or port or ENV var that someone added a dependency on last week then you pretty quickly realize just doing complex docker things by hand is a pain. Another example, if you have a script that you want to run to fetch the latest authentication token from a vault after the container launches because you don't want to store it inside the container. Sure, you could write a bash script to run all these steps inside the container after you launch it but it's nice to have a config file to share with another dev and just say: use this.
And the secondary benefit is that having a config file for the editor (like VSCode) so that plugins can manage all of that stuff better. Generally a dev container runs the VSCode Server, and they know how to talk to each other which can make remote development easier. For example, now I can launch the same dev environment locally or on the 56 core xeon 1TB ram server at the office and it's exactly the same as far as the editor is concerned.
It looks like this project is an alternative to the VSCode Server. My team generally uses docker-compose for this since not everyone uses VSCode.
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#13A lot of remote dev environments have limitations when it comes to certain types of development. For example, ios and android app development can be tricky. Or game development where you need to have GPUs and build artifacts may be slow to download to your machine.
Are there any guidances for how to fix this?
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#14So, 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?
It makes it easy to point the tool at a Git repo, have it automagically create a containerized environment for that repo with all its dependencies, and open Visual Studio Code on the codebase inside that remote containerized environment.
Devcontainer was created by Microsoft to support Visual Studio Code's remote development features, so it works best in Visual Studio Code. Inasmuch as other IDEs support it, that's up to the IDE vendor.
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#15This 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 - abstractin…
This seems to be podman focused from what I see.
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#16This 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.
> JetBrains’s remote SSH dev;
Does that require a static ip on remote?
I have skimmed the Jetbrain FAQ [1] and it says "no relay servers are involved"
[1] https://www.jetbrains.com/help/idea/faq-about-remote-develop...
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#17A lot of remote dev environments have limitations when it comes to certain types of development. For example, ios and android app development can be tricky. Or game development where you need to have GPUs and build artifacts may be slow to download to your machine. Are there any guidances for how to fix this?
You can access GPUs within containers using CDI (Container Device Interface):
https://docs.nvidia.com/datacenter/cloud-native/container-to...
No additional tools (e.g., nvidia-ctk) are needed.
Docker has recently added support for CDI in version 25.0.
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#18So, 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?
Well, developers seem to love writing "configuration" rather than "code" these days. But basically a container + the necessary tools IS a devcontainer. It's just a way of automating the "putting in the necessary tools" part especially if you need things that might need to be added to a base container, or services that need to be configured differently based on the external environment that you don't want to bake in f…
For the first bit, all I can think is a compose file. Also podman can run k8s configs locally, which I personally hope all of that eventually washes into the same thing. It feels like we already have the tools to make this a "solved" problem, is what I'm trying to say. I just include an additional .env that the compose file pulls in so it's not committed to git.
For the second point, ok this makes a little bit more sense, I've heard of Codespaces or OpenShift Dev Spaces but I guess I still question the value of additional complexity on top of the container (a simple dockerfile in my mind) your vscode instance's terminal is running in.
Thanks for the info.
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#19So, 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?
It makes it easy to point the tool at a Git repo, have it automagically create a containerized environment for that repo with all its dependencies, and open Visual Studio Code on the codebase inside that remote containerized environment. Devcontainer was created by Microsoft to support Visual Studio Code's remote development features, so it works best in Visual Studio Code. Inasmuch as other IDEs support it, that's u…
So this is a config standard for the infrastructure underneath something like remote vscode / devcontainers?
Re: Show HN: Lapdev, a new open-source remote dev environment management software
#20This 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.
> JetBrains’s remote SSH dev; Does that require a static ip on remote? I have skimmed the Jetbrain FAQ [1] and it says "no relay servers are involved" [1] https://www.jetbrains.com/help/idea/faq-about-remote-develop...
No, it's able to use your local ssh_config. For example, I use this to connect to a host running on aws via ssm. The vm isn't reachable at all directly.
You can use something like the following in your ~/.ssh/config:
Host devhost
ProxyCommand aws --profile DevProfile ssm start-session --target i-0123456789abcdef0 --document-name AWS-StartSSHSession --parameters "portNumber=22"