FYI there's a well-starred, corporate-backed, similar functionality, Nix-based product with the same name: https://github.com/jetify-com/devbox https://www.jetify.com/devbox
Show HN: Devbox – Containers for better dev environments
11–20 of 65 posts
Re: Show HN: Devbox – Containers for better dev environments
#12Earlier quoted context omitted.
Yep, also Microsoft Dev Box: https://azure.microsoft.com/en-us/products/dev-box
I am not affiliated with Microsoft and I anal but I think dev box is fine. What we want to avoid is the term dev containers. https://containers.dev/
Both projects even use devbox.json for their definitions, for crying out loud. If your usage is not compatible with Jetpack's devbox.json, please switch to a different filename ASAP.
Re: Show HN: Devbox – Containers for better dev environments
#13I've worked on projects where the original dev has used containers for everything. It's super clunky and annoying. I don't want to use a different bash config just for working on that project. I've set my own up for a reason. All it makes me wonder is what are you afraid of? Why do you feel the need to isolate dev projects to this extent?
Re: Show HN: Devbox – Containers for better dev environments
#14I always like to see new projects using containers. Two questions: - how is your devbox.json file different from a Dockerfile/Containerfile? - does your project attempt to provide any isolation security-wise?
Considering that they provide Docker-in-Docker by default, this would have to be a "no" right now. Having the ability to launch Docker containers is equivalent to having root access on the Docker host by default.
Re: Show HN: Devbox – Containers for better dev environments
#15Re: Show HN: Devbox – Containers for better dev environments
#16We've been using devcontainers for this, as it's already got good support in vscode. Could you perhaps "elevator pitch" the main differences between devbox and devcontainers?
But having tried Devcontainers a lot, it feels like its probably a complex specification since outside of VSCode every implementation has issues.
The CLI on Mac has weird user permission issues. Cursor's implementation is very flaky. Zed doesn't implement it yet.
So maybe there's space for more solutions in the same space but Devcontainers are very feature rich. And not to mention they have a huge user base via VSCode.
Re: Show HN: Devbox – Containers for better dev environments
#17We've been using devcontainers for this, as it's already got good support in vscode. Could you perhaps "elevator pitch" the main differences between devbox and devcontainers?
Yes, it feels very similar to Devcontainers. But having tried Devcontainers a lot, it feels like its probably a complex specification since outside of VSCode every implementation has issues. The CLI on Mac has weird user permission issues. Cursor's implementation is very flaky. Zed doesn't implement it yet. So maybe there's space for more solutions in the same space but Devcontainers are very feature rich. And not to…
Re: Show HN: Devbox – Containers for better dev environments
#18Re: Show HN: Devbox – Containers for better dev environments
#19I don't get how containers address "dependency hell". Is there some language that only supports installing libraries system wide? I've used a lot of different languages and yet to come across one. I've worked on projects where the original dev has used containers for everything. It's super clunky and annoying. I don't want to use a different bash config just for working on that project. I've set my own up for a reaso…
Not impossible, just not easy to comprehend by an average dev.
Re: Show HN: Devbox – Containers for better dev environments
#20Earlier quoted context omitted.
Yep, also Microsoft Dev Box: https://azure.microsoft.com/en-us/products/dev-box
I am not affiliated with Microsoft and I anal but I think dev box is fine. What we want to avoid is the term dev containers. https://containers.dev/
There has to be a better way to phrase this