Hacker News Reader

Comment by anotherhue | Hacker News Reader

If tickles your fancy may I also suggest trying Nix to build docker images?

Personally I've soured on the Dockerfile approach as it feels like we're just shuffling bytes around rather than composing something.

https://nix.dev/tutorials/nixos/building-and-running-docker-...

View on HN

I have completely soured on Dockerfiles. I view them as anathema.

The supposed "caching" of layers really doesn't work in practice unless you add a bunch of other infrastructure and third-party tooling to your build process. Getting truly incremental and reproducible layers into your build process is non-trivial, and the Dockerfile approach fails to take advantage of that work once you've done it.

You need to start with the right base. Here’s a container-first 100%-reproducible from-scratch base to build on.

[0] https://stagex.tools/

A surprising downside to Nix containers is that a majority of packages are not optimized for containers. For example, trying adding a dependency to `git` and see how big the container grows. Granted, the good packages (like git) allow customization, but it requires really digging into the code. Some packages just straight up ship with a ton of bloat and the only thing you can do is basically fork and maintain it yourself.

It's a problem of nixpkgs. It would be cool to have an Alpine-like alternative package set focused on minimal package size.

There is, isn't there? That's what `pkgsStatic` in Nixpkgs is. Statically compiled packages with small closures built with musl, just like Alpine

you could try to statically link them if the package support it, it does so by using musl

nix build github:NixOS/nixpkgs#pkgsStatic.git

return the pacakge as:

ls -lah git

-r-xr-xr-x 1 rucadi rucadi 5.1M Jan 1 1970 git

ldd git

$ not a dynamic executable

So you don't really need to really grow the container

Yeah, it's a problem on a package-per-package basis. My point isn't how to solve the git problem but that the experience can vary wildly depending on the package. It can be surprising and often comes at the expense of time trying to navigate the insanity that is nixpkgs :)

Nix is cool, but with Nix one needs to know Nix. Personally, I prefer just using scripting languages. LLM's made code cheaper, but debugging become expensive.

Reply on news.ycombinator.com