jeremy_flox

3 ms·

1.
by jeremy_flox 11mo ago
We don't currently scrape R, it's on the list, for sure.
2.
by jeremy_flox 11mo ago
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 on either side. Initial selection matters (pick compatible ve
3.
by jeremy_flox 11mo ago
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 -- no eval needed, ever. The k8s node fetches t
4.
by 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
5.
by 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&#x
6.
by jeremy_flox 11mo ago
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 result (ie exact store paths) in FloxHub. The k8s nod
7.
by jeremy_flox 11mo ago
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 catalog means everything shares base deps). On "enviro
8.
by jeremy_flox 11mo ago
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 This is original work, though very much built on prior inno