Hacker News new | ask | show | jobs
by nixosbestos 210 days ago
So, nix-snapshotter? Also, Flox going all in on "environments" seems like such a choice. I'm sure that Flox is not encouraging shipping a binary-in-a-devshell to Prod, so it seems an interesting branding decision.

It's hard for me to understand if I should be excited about this. I think companies do themselves such huge disservices from not being transparent to the nerds that WILL be the ones helping choose/implement these things. Instead of the current feeling I have, there could be three sentences that explains what Flox is offering here beyond what *anyone* can go do right now with nix-snapshotter.

If it's ecosystem stuff (you get Flox's CI, or CLI, or whatever else), that's not very well sold to me on the landing page. Otherwise I'm feeling left empty-handed.

1 comments

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 "environments": these aren't devshells-as-prod, they're the actual runtime; same as 'flox activate' works everywhere. You're shipping a declarative, hash-pinned runtime that happens to also work great in dev/CI

And yeah, we should have been upfront that this is alpha and we're planning to open source it after vetting at KubeCon.

You're right that we're doing ourselves a disservice not being transparent with the technical crowd. What specific technical details would help you evaluate this?

Hard to say because I'm a bit ignorant of the edges of Flox right now! This comment is great though. :) And even more exciting to hear it will be OSS'd. Appreciate your replies here, good luck!