4 ms·

I was an early and enthusiastic adopter of docker. I really liked how it would let me use layers to keep track of dependency between files. After spending a fe

I was an early and enthusiastic adopter of docker. I really liked how it would let me use layers to keep track of dependency between files. After spending a few years using nix, the docker image situation looks pretty bonkers. If two files end up in separate layers, the system assumes dependency so if the lower file changes you need to build a separate copy of the higher one just in case there's actual dependency there. Within nix you can be more precise about what depends on what, which is nice, but you do have to be thoughtful about it or you can summon the same footgun that got you with docker, just in smaller form. Because a nix derivation, while a box with nicely labeled inputs and output, is still a black box. If you insert a readme as an input to a derivation that does a build, nix will assume that the compiled binary depends on it and when you fix a typo in the readme and rebuild you'll end up with a duplicate binary build in the nix store despite the contents of the binary not actually depending on the text of the readme. > you can combine packages however you would like So this is true, more or less, but be aware that while nix lets you do this in ways that don't force needless duplication, it doesn't force you to avoid that duplication. Things carelessly packaged with nix can easily recreate the problem you mentioned with docker.

justincormack 11mo ago
The problem is that whiteouts are not commutative. If the layers you build turn out to be bit for bit identical the layers will be shared anyway, but its much mroe complex than Nix where the composition operation is commutative.
d3Xt3r 11mo ago
> If you insert a readme as an input to a derivation that does a build, nix will assume that the compiled binary depends on it and when you fix a typo in the readme and rebuild you'll end up with a duplicate binary build in the nix store despite the contents of the binary not actually depending on the text of the readme. One my issues with Nix is the black box that is the store, and maybe it's just my system, but over time I find it full of redundant files / orphans and no obvious way to flatten it or clean it safely without breaking something. I wonder how flox solves this.
- jeremy_flox 11mo ago
  Both fair points. The README rebuild issue is a Nix hiccup we don't solve; our quantized catalog reduces cascading rebuilds from upstream churn, but input over-specification is still there. On store bloat: Flox makes it clearer what's in use (explicit environments vs. implicit dependencies), but you still need nix-collect-garbage. The store accumulates cruft, that's Nix reality, we haven't changed it.
  - jeremy_flox 11mo ago
    Just to follow up on this, Flox puts packages in one group by default so they share dependencies, plus our quantized catalog means way less version spread than raw Nix. So I do think we still improve on the Nix story, here. We're also adding "stabilities" (downsample from daily to weekly/monthly snapshots) to reduce churn even more. Still need GC, but a lot fewer bags on trash day. .
- __MatrixMan__ 11mo ago
  Have you found that nix-store --gc breaks things, or are you concerned that it's not an aggressive enough garbage collection? When I have space problems, I run that and they're gone, then later I do it again. It could be that I'm just avoiding functionality that it breaks though.
  - d3Xt3r 11mo ago
    There's still leftovers. For me, it's not about space problem, but more of wanting to run a tight ship. Most recently, I tried running all the stuff on the wiki[1] but I still had leftovers that wouldn't go away no matter what (these were some CUDA dependencies, if it makes a difference). In the end I ended up blowing away my entire Nix install, manually deleting the store and reinstalling Nix - which isn't exactly ideal - considering that the whole point of Nix is to be deterministic and reproducible and all that jazz... so to me it doesn't make sense that it dirties the host and doesn't clean up after itself. Since then I've gone back to using containers as at least they don't pollute the host, and I feel like I'm in greater control over the entire environment. [1] https://nixos.wiki/wiki/Cleaning_the_nix_store https://nixos.wiki/wiki/Cleaning_the_nix_store

justincormack 11mo ago

The problem is that whiteouts are not commutative. If the layers you build turn out to be bit for bit identical the layers will be shared anyway, but its much mroe complex than Nix where the composition operation is commutative.

d3Xt3r 11mo ago

> If you insert a readme as an input to a derivation that does a build, nix will assume that the compiled binary depends on it and when you fix a typo in the readme and rebuild you'll end up with a duplicate binary build in the nix store despite the contents of the binary not actually depending on the text of the readme. One my issues with Nix is the black box that is the store, and maybe it's just my system, but over time I find it full of redundant files / orphans and no obvious way to flatten it or clean it safely without breaking something. I wonder how flox solves this.

jeremy_flox 11mo ago
Both fair points. The README rebuild issue is a Nix hiccup we don't solve; our quantized catalog reduces cascading rebuilds from upstream churn, but input over-specification is still there. On store bloat: Flox makes it clearer what's in use (explicit environments vs. implicit dependencies), but you still need nix-collect-garbage. The store accumulates cruft, that's Nix reality, we haven't changed it.
- jeremy_flox 11mo ago
  Just to follow up on this, Flox puts packages in one group by default so they share dependencies, plus our quantized catalog means way less version spread than raw Nix. So I do think we still improve on the Nix story, here. We're also adding "stabilities" (downsample from daily to weekly/monthly snapshots) to reduce churn even more. Still need GC, but a lot fewer bags on trash day. .
__MatrixMan__ 11mo ago
Have you found that nix-store --gc breaks things, or are you concerned that it's not an aggressive enough garbage collection? When I have space problems, I run that and they're gone, then later I do it again. It could be that I'm just avoiding functionality that it breaks though.
- d3Xt3r 11mo ago
  There's still leftovers. For me, it's not about space problem, but more of wanting to run a tight ship. Most recently, I tried running all the stuff on the wiki[1] but I still had leftovers that wouldn't go away no matter what (these were some CUDA dependencies, if it makes a difference). In the end I ended up blowing away my entire Nix install, manually deleting the store and reinstalling Nix - which isn't exactly ideal - considering that the whole point of Nix is to be deterministic and reproducible and all that jazz... so to me it doesn't make sense that it dirties the host and doesn't clean up after itself. Since then I've gone back to using containers as at least they don't pollute the host, and I feel like I'm in greater control over the entire environment. [1] https://nixos.wiki/wiki/Cleaning_the_nix_store https://nixos.wiki/wiki/Cleaning_the_nix_store