51–60 of 71 posts
It's open-core https://github.com/lapce/lapdev/blob/8eeb3cc3cbbf4c5bf4e7928... , if you care about that.
It's always interesting to see new approaches but I don't see this replacing Vagrant for my projects any time soon: - Vagrant already supports VM or Container environments, and has a well defined system for building and distributing "base" boxes; - Vagrant uses a Ruby file to define the environment, so it's much more powerful than a Yet Another Migraine Looming file.
Devcontainers bring notions such as configuring plugins for your IDE, getting « features » from other repos / registries, managing environment variables that you pass from host to devcontainer, and finally either code locally or in the context of a remote environment with more resources or just simply in the context of the rest of your application (very handy for complex network or security setups).
Like I said, a `Vagrantfile` is ruby, so besides having all the power of Vagrant and its plugins, you can also just do straight up ruby stuff, or even shell out to do other stuff.
This isn’t open source; one of the directories is licensed under a proprietary, subscriptionware nonfree license. The remainder is AGPL, which many people (including myself) consider nonfree as well.
Just two weeks ago we have outsourced Daytona (daytonaio) under an Apache license. We had long and deep discussions but finally decided that's the only thing that made sense.
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?
Another angle is rent-seeking and locking you into a proprietary, expensive ecosystem. Big Tech has successfully convinced most companies to overpay by orders of magnitude for compute and bandwidth, but so far local development machines were excluded. This aims to tackle that shortcoming and make sure you enjoy all the "benefits" of the cloud even during development.
Earlier quoted context omitted.
No, not really. A big part of the problem is half baked software on the client side. For devcontainers even the reference implementation CLI is significantly incomplete.
https://happihacking.com/blog/posts/2023/dev-containers-emac... Looks pretty useable to me...
[0]: https://github.com/devcontainers/cli?tab=readme-ov-file#cont...
Earlier quoted context omitted.
Just two weeks ago we have outsourced Daytona (daytonaio) under an Apache license. We had long and deep discussions but finally decided that's the only thing that made sense.
Unfortunately you've also started spamming people about it, including those who previously unsubscribed from your marketing comms.
What does this add, really? It’s not automation (I can automate a couple of clicks in Proxmox), it’s not resource management (Proxmox handles storage, etc.). Is it developer identity? Because that’s the only thing I’d need a (relatively simple) script to deploy SSH keys to an environment.
Nice, but with a Proxmox setup I can clone an existing VM/container (and there are already dozens of templates), point VSCode at it, and I’m done. What does this add, really? It’s not automation (I can automate a couple of clicks in Proxmox), it’s not resource management (Proxmox handles storage, etc.). Is it developer identity? Because that’s the only thing I’d need a (relatively simple) script to deploy SSH keys to…
Lap dev looks like a much simpler tool
Another implementation in that space is https://devpod.sh
This immediately killed it for me. I need to install a Postgres server just to try out a tool? And if I recommend it to my team, do we need to run and maintain a Postgres instance?
OP- you are creating too much work for me. And don’t ask me to use your hosted version, the easiest solution is to use Vs code devcontainers