Live data from Hacker News

Show HN: Devbox – Containers for better dev environments

devbox.ar0.eu

11–20 of 65 posts

Re: Show HN: Devbox – Containers for better dev environments

#11
post #5

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

I usually don't take name clashes as seriously as some people here do, but when it's even in the same general niche, then that's not really a good look. It means the author failed to check the prior art - which is still fine for a (n+1)th hobby project, but not really for something more serious.

Re: Show HN: Devbox – Containers for better dev environments

#12
post #7
post #6

Earlier 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/

The overlap with Jetpack's devbox name is not fine. Not morally, given the massive overlap in functionality between the two implementations. At the very least, their existence will prevent you from getting a trademark.

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

#13
I 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 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

#14

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

> 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

#16

We'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 mention they have a huge user base via VSCode.

Re: Show HN: Devbox – Containers for better dev environments

#17
post #16

We'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…

The killer combo for us is remote+devcontainers. We use this for GPU access, so you can run a project on one or more GPUs that are on a remote server. You can spin up LLM stuff from a mac air and get the best of both worlds.

Re: Show HN: Devbox – Containers for better dev environments

#19

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

C libraries are easiest to install system wide. The situation with multiple versions of libc is tricky to work with.

Not impossible, just not easy to comprehend by an average dev.

Re: Show HN: Devbox – Containers for better dev environments

#20
post #7
post #6

Earlier 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/

> I anal

There has to be a better way to phrase this

Post reply on HN