Live data from Hacker News

Viewing profile — jeremy_flox

jeremy_flox

HN member
Joined
Sun, Nov 16, 2025, 6:15 PM UTC
HN karma
6
Public activity
9 items

About jeremy_flox

No profile information was provided.

Recent public activity

  1. story
  2. comment
    Comment #45950522

    We don't currently scrape R, it's on the list, for sure.

  3. 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…

  4. 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 --…

  5. 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…

  6. 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…

  7. 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…

  8. 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…

  9. 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…