Viewing profile — jeremy_flox
jeremy_flox
HN member- Joined
- Sun, Nov 16, 2025, 6:15 PM UTC
- HN karma
- 6
- Public activity
- 9 items
- HN profile
- View on Hacker News ↗
About jeremy_flox
No profile information was provided.
Recent public activity
- story
-
comment
Comment #45950522
We don't currently scrape R, it's on the list, for sure.
-
comment
Comment #45949807
You pin the CUDA toolkit version compatible with your driver; manifest.lock ensures zero drift. Driver version is host-managed (stable), toolkit is hash-pinned (stable). No drift o…
-
comment
Comment #45948549
Correction: we don't eval when you create environments. Our catalog continuously pre-evaluates nixpkgs in the background. 'flox install' just selects from pre-evaluated packages --…
-
comment
Comment #45948515
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 thi…
-
comment
Comment #45947752
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 sti…
-
comment
Comment #45947577
Yeah, it's essentially cached eval, the key being where/how that eval is stored. When you create a Flox environment, we evaluate the Nix expressions once and store the concrete res…
-
comment
Comment #45947222
Totally valid - we buried the lede here. Quick version: Not nix-snapshotter because we skip Nix eval entirely and get way better cache sharing across unrelated workloads (quantized…
-
comment
Comment #45947205
Jeremy from Flox, here, I want to chime in here so Ron can be with his family, even though he will no doubt be right back on here: Re: Relationship to nix-snapshotter and prior art…