Earlier quoted context omitted.
> I anal There has to be a better way to phrase this
I think it’s reasonable. What’s another way, “I’m into backdoor stuff”?
hey, I mean, buttplug.io could always use the contributors
Show HN: Devbox – Containers for better dev environments
31–40 of 65 posts
Re: Show HN: Devbox – Containers for better dev environments
#32I 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…
Isolation works both ways.
By isolating your dev project, you don't expose your host to the mess the project can create... and you don't expose your project to the mess that can exist on your host.
With dev containers, you can define your ENV VAR, your aliases... independently from what exists on your host. And it will exists straight out the box: you checkout the project, launch the dev container and you're ready to go. As soon as you're done with this project, you delete the container and not a single trace of the project exists on your host. No matter how many custom things the project required to run.
Re: Show HN: Devbox – Containers for better dev environments
#33We'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…
This has been my experience. I don't use VSCode and every time I've attempted to play with devcontainers I've just given up and gone back to a docker compose file. I love that they tried to extract the feature out into a stand alone thing, but the juice doesn't seem to be worth the squeeze yet.
Re: Show HN: Devbox – Containers for better dev environments
#34Plugging my own tool. I use it for development and running semi-trusted or temporary tools, mounts the current/project dir for isolation, and shuts down automatically when it can.
Container Shell - https://github.com/jrz/container-shell
Re: Show HN: Devbox – Containers for better dev environments
#35erm, that name is already taken. https://jetify-com.vercel.app/docs/devbox/
Re: Show HN: Devbox – Containers for better dev environments
#36OP should consider changing their alias.
Re: Show HN: Devbox – Containers for better dev environments
#37I had a very strong personal opinion that, unless you expect frequent migrations or horizontal scaling, Docker is overkill and could be considered as bloat in many instances. After I joined my new company, I found out about devbox, and I love it. Now I use it for almost every personal project. It helps you to make the environment reproducible without sacrificing performance.
However, I use https://www.jetify.com/devbox.
Re: Show HN: Devbox – Containers for better dev environments
#38I 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…
Isolation works both ways. By isolating your dev project, you don't expose your host to the mess the project can create... and you don't expose your project to the mess that can exist on your host. With dev containers, you can define your ENV VAR, your aliases... independently from what exists on your host. And it will exists straight out the box: you checkout the project, launch the dev container and you're ready to…
And since you have everything in a configuration file, it is breeze to transform your dev container in a production one.
Re: Show HN: Devbox – Containers for better dev environments
#39How does this compare to toolbx? ( https://containertoolbx.org/ )
And Distrobox: https://distrobox.it
One obvious one is that Toolbx and Distrobox are based on Podman, for one.
Re: Show HN: Devbox – Containers for better dev environments
#40Would love to use something like this for NixOS as an escape hatch, but its debian only. DistroBox always gives me trouble.