Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Lapdev, a new open-source remote dev environment management software

github.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Show HN: Lapdev, a new open-source remote dev environment management software

#31

Post by ninjha »

1shooner wrote: post #3

I'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...

Having deployed a few of these over the last month or so, I feel like the devcontainer spec is very annoying. The alternative is what Coder does -- write some arbitrary terraform to bring up or down a workspace. I think this is better because I tend to need other things to go in a workspace (like an IAM role to access dev databases, associated Kubernetes resources, etc). With terraform I can configure whatever infrastructure I want to go along with workspaces.

The main downside I can see is that users have to write their workspaces for a particular deployment target. This would be a problem for e.x. open source projects trying to check in a workspace definition file of some kind. We standardize on Kubernetes across clouds and bare metal so it's not an issue for us, but it makes sense that it would be an issue for other use cases.

Re: Show HN: Lapdev, a new open-source remote dev environment management software

#33

Post by rad_gruchalski »

zamalek wrote: post #10
salamander014 wrote: post #8

So, 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.

> If I didn't invent the thing, then we shouldn't use the thing.

What about Linux? Or... the internet?

Re: Show HN: Lapdev, a new open-source remote dev environment management software

#34

Post by johnchristopher »

lyang2821 wrote: post #9
johnchristopher wrote: post #6

I 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.

Ah, I see. Thanks for the explanation !

I haven't yet made the jump to remote/cloud development, I don't have a clear mental picture of how the pieces fit.

Re: Show HN: Lapdev, a new open-source remote dev environment management software

#36

Post by parentheses »

Eridrus wrote: post #22

I am interested in remote dev environments, but I'm not super excited about managing yet more software in the cloud. There were some headaches around the exact specifics since it wasn't designed for this, but I liked the idea of using skypilot to launch dev machines in the cloud since it has plugins to all the cloud APIs and so you don't need to manage a k8s cluster to launch a dev machine. Admittedly it worked bette…

there are products that do this out of the box fairly well. code spaces is an example with a single node but there are others - all of which are slightly different

Re: Show HN: Lapdev, a new open-source remote dev environment management software

#38

Post by lucw »

vladvasiliu wrote: post #20
algo_trader wrote: post #16

Earlier quoted context omitted.

> 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" You then tell intellij to connect to "de…

ipv6 is perfect for this use case, every development VM is directly reachable.

Re: Show HN: Lapdev, a new open-source remote dev environment management software

#39

Post by a_random_canuck »

Eridrus wrote: post #22

I am interested in remote dev environments, but I'm not super excited about managing yet more software in the cloud. There were some headaches around the exact specifics since it wasn't designed for this, but I liked the idea of using skypilot to launch dev machines in the cloud since it has plugins to all the cloud APIs and so you don't need to manage a k8s cluster to launch a dev machine. Admittedly it worked bette…

Sorry it’s not meant to be a dig at you, but in I wish we could stop talking about the “cloud” and software running “in the cloud”.

There is no cloud… it’s just software running on someone else’s computers that you don’t control. And that someone else is usually a megacorp like Microsoft or Amazon.

Re: Show HN: Lapdev, a new open-source remote dev environment management software

#40

Post by rovr138 »

johnchristopher wrote: post #34
lyang2821 wrote: post #9

Earlier quoted context omitted.

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.

Ah, I see. Thanks for the explanation ! I haven't yet made the jump to remote/cloud development, I don't have a clear mental picture of how the pieces fit.

Remote environment with a thin client that can interface with it. Client is local, but it all ends up running remotely.
Post reply on HN