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

Show HN: Devbox – Easy, predictable shells and containers

github.com

Post reply on HN
Print view View original

71–80 of 196 posts

Re: Show HN: Devbox – Easy, predictable shells and containers

#71

Post by the_duke »

dloreto wrote: post #23
ignoramous wrote: post #18

Thanks. > Devbox was originally developed by jetpack.io and is internally powered by nix. If this wasn't mentioned, I'd have easily mistaken devbox to be an escaped implementation of Brazil VersionSets and Apollo VersionFilters (used internally at Amazon). If I may, in the near-term does jetpack.io plan to continue to use and sponsor devbox's development? And, in the long-term, does jetpack plan to monetize this proj…

Yes, we use it internally for all of our development and plan to continue actively maintaining it. If there's enough interest from the community we would love to make it a Cloud Native Computing Foundation project.

Small bit of feedback: as a Nix fan and user I love to see a more usable veneer over nix tooling, but I feel the repo should give a bit more credit to Nix and explain how Devbox works.

Re: Show HN: Devbox – Easy, predictable shells and containers

#72

Post by pxc »

honkler wrote: post #70
pxc wrote: post #32

Earlier quoted context omitted.

It uses the Docker CLI to build container images out of the Nix shells it creates, if you ask it to export one to a Docker image for you. Otherwise it just uses Nix locally, no virtualization. I wonder if it takes this approach because there's some issue with using Nixpkgs' dockerTools on macOS— those tools let you create Docker/OCI images without even having Docker installed.

docker is not virtualization either

1. Yes it is— there are many kinds of virtualization other than machine virtualization. Containers are a form of operating system virtualization.

2. Docker on non-Linux also requires machine virtualization; the `docker` CLI connects to a `dockerd` daemon running on a virtual machine.

The question I posed earlier is motivated by understanding this and knowing that on macOS, the binaries that devbox runs on your local machine are completely different (of a different architecture, even) than the binaries that devbox will pack into a Docker image. Since it uses Nix to build them, it either needs to run Nix in a virtual Linux guest (which it does using the guest that Docker for Mac sets up) or have its Mac-bound Nix build Linux binaries.

Using `docker buildx` obviates the need to set up devbox's own Linux VM to target as a remote builder, or, alternatively, cross compile the required Nix packages. But it comes at the cost of adding a dependency on Docker even though devbox doesn't use the Docker runtime for its shells

Re: Show HN: Devbox – Easy, predictable shells and containers

#73

Post by pxc »

abathur wrote: post #46
pxc wrote: post #32

Earlier quoted context omitted.

It uses the Docker CLI to build container images out of the Nix shells it creates, if you ask it to export one to a Docker image for you. Otherwise it just uses Nix locally, no virtualization. I wonder if it takes this approach because there's some issue with using Nixpkgs' dockerTools on macOS— those tools let you create Docker/OCI images without even having Docker installed.

https://nix.dev/tutorials/building-and-running-docker-images... asserts that you'd need a remote builder or cross-compiling. So it seems possible (unless maybe there are still enough cross-compile issues?)

Can cross builds hit the main binary caches or is that awaiting Hydra support for content-addressed derivations? Are there big caches for cross-compiled packages?

Re: Show HN: Devbox – Easy, predictable shells and containers

#74

Post by amir-h »

Looks really nice! I'm wondering though whether this is luring me into a dangerous complexity cliff.

It seems easy to start using, but will I run into some issues a few months down the line like a package that's not available through Nix, or some Nix issue, and then I'm back to dealing with Nix's complexity only that I got there while staying clueless about Nix.

Re: Show HN: Devbox – Easy, predictable shells and containers

#77

Post by gitgud »

throwaway892238 wrote: post #47

Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022. We developers don't have internet connections; even when we do, our internet is off most of the time, and we can barely transfer 1.25 megabytes per second. How could we possibly use an IDE and filesystem monitor to copy a 10kB source file when we write to it, t…

> Maybe in another 30 years, we will have gained the technological insight to be able to figure out how to have a team full of people to work on a single server at the same time

Single repository, yes. Single development environment, no.

Development environments should be isolated, so developers don't step on each other's toes...

Also, centralised cloud development machines are by definition, a single point of failure, with small gains in consistency in development experience...

> all connected to a network over an internet connection, with some crazy interface that keeps their shell session alive even if their internet disconnects.

You know what's better than this? Not relying on the internet connection at all!...

Decentralized development on local machines is simply a better experience and relies less on a giant cloud infrastructure

Re: Show HN: Devbox – Easy, predictable shells and containers

#78

Post by denkmoon »

throwaway892238 wrote: post #47

Extremely, violently unpopular opinion: a team of people developing on their laptops is an anti-pattern. I know what you're gonna say. You'll say, "It's 2022. We developers don't have internet connections; even when we do, our internet is off most of the time, and we can barely transfer 1.25 megabytes per second. How could we possibly use an IDE and filesystem monitor to copy a 10kB source file when we write to it, t…

I've certainly had internet outages where I've continued to work on my laptop.

I can't even imagine how expensive it would be to run like this. Sharing an environment is a _terrible_ idea, you need isolated environments.

Post reply on HN