ronef

Your title is verbatim how Nix made me feel when I first started years ago. It does so many small things in a pure format that it was hard to immediately come up with the "key ROI" the larger industry expected. Did it just speed up dev envs? Did it just make my builds faster? Back then, a lot of folks barely cared or understood the impact of the deterministic and reproducible foundation using Nix sets. I used to hear a lot of "but that's a day 100 issue", "docker/(insert other tool) solved all of this already". "less afraid" was the easiest way to put it :) Disclosure, fully Nix pilled Ron here from flox.dev and the NixOS foundation.

Loving this. Honestly I keep encouraging folks to just TRY native Nix for dev environments. So easy to set up and get value on day 1 that you'd be shocked. Also models/LLMs have made lightyear strides in the last few months to help with everything around it. We've been building up Nix based skill systems into our Flox skill and it's been super meaningful both on adoption and when we need to scale it up. (disclaimer I do Flox.dev which is Nix based and we do cool Nix stuff)

For anyone reading this and jumping to a broader conclusion: the Nixpkgs core team disbanding does not mean Nixpkgs or Nix is dying. It does mean that this particular structure was not sustainable, very important contributors burnt out and we need to do better, faster. We need to continue learning from this and continue building a stronger ecosystem that prioritizes the contributors who are the only reason any of this is possible.

Personally, I'm sorry and grateful. Sorry that it ended in core folks being burnt out. Grateful since they did some of the most amazing work, more than anyone can imagine two people doing.

Huge plus to anyone interested in the space to check out what Graham built here!

If anyone is also interested on Nix/CUDA/Capital Markets/Flox, we recently did another case study in the space - https://flox.dev/blog/deploying-hardened-flox-nvidia-cuda-st...

Sharing something I'm personally excited about that's made possible with a lot of Nix/NixOS (nixpkgs) in the background by the Flox eng team. Was initially built for devX but is having a lot of pull for establishing agent infra!

We've been working quite a bit on bringing in Nix/Nixpkg/Nixos based architecture into the space of bringing in determinism to the baseline infrastructure of our AI stacks. This also leans into the conversation around sovereign AI and how Nix is letting us own more of that stack.

Asking this with a bias since I work on Nixos.org and Flox.dev - How is the team thinking about the infra layers underneath these models? Any priority or reason to imbed determinism/reproducibility at the bottom of the stack?

What's the best practice right now for setting these up? We've been primarily using Nix/Flox to set up the models pretty quickly and at least with minimized amount of commands(biased Nix/Floxer) here and found it useful

A small note of amazement from Nix/Flox person here. Incredible to see this release and congrats! Mike, you're an allstar for so many years of contributions!

I.e. is this overhyped?

I feel we should definitely be digging way beyond the SBOM... but also wondering if the forecasting in the general ecosystem is on point or not.

Ron from Flox here. We recently wrote this piece on how Nix can address the emerging CVE remediation problem. We are curious to hear any feedback on our approach.

[Disclaimer: biased Flox/Nix person]

There's a lot of reasons to use Nix instead of or WITH Homebrew depending on your exact needs.

Where it’s paid off for me (and where I think it actually wins) is when the problem is recreating environments: multiple machines, teammates, CI, nasty native deps, CUDA stacks, etc. At that point you’re choosing where entropy lives: in invisible drift (brew/manual installs) or in a repo you can diff/rollback.

Also, you don’t always need to go full “immutable everything.” Really depends on your needs here. Hybrid tends to be another sane path. In certain situations this can get you 80% of the upside without having to rip it all out. So kinda the "good enough" which I've seen a lot of folks do.

We (Flox) actually worked on this with Kelsey Hightower a while back - https://bsky.app/profile/kelseyhightower.com/post/3ld2rsccls...

Highly recommend to check this out, the blog/Arnoult does an amazing job in very succinctly breaking down the aspects of SBOMs in a Nix based infra approach. We can go way beyond the current SLSA levels and provide full provenance at the atomic level of the supply chain for when it's needed. And as Arnoult points out, prune when it's not. There's good work being done on this across the Nix ecosystem and we have also seen a lot of use for it come in through Flox as well!

And I'm back in the land of the living. Can't really beat a response from Justin Cormack!

Jotting down a few quick thoughts here but we can totally go deep. This is something Michael Brantley started working on a few months ago to test out how to make it super easy to ease and leverage existing Nix & Flox architecture. One of the core differences from my quick perspective is that it specifically leverages the unique way that Flox environments are rendered without performing a nix evaluation, making it safe and optimally performant for the k8s node to realize the packages directly on the node, outside of a container.

online community love was not in my cards going into day 3 of a newborn but I'll take it + definitely needed! thank you!

Yes, this hits the nail on the head. We’ve seen the same explosion in image size and rebuild complexity, especially with AI/ML workloads where Python + CUDA + random pip wheels + system libs = image bloat and massive rebuilds.

With the Kubernetes shim, you can run the hash-pinned environments without building or pulling an image at all. It starts the pod with a stub, then activates the exact runtime from a node-local store.

Going to sound weird but with both my hats on I super appreciate this perspective. I can only speak to some areas of Nix and Flox obviously and I know folks are looking into doing this to your point a whole lot better. Zooming in way more into solving for us that just want to run and fix it fast when it breaks.

Also, think it's a huge ecosystem win for FreeBSD pushing on reproducibility too. I think we are trending in a direction where this just becomes a critical principle for certain stacks. (also needed when you dive into AI stacks/infra...)

Ron from Flox here, woke up to feed a brand new 3 day old to see this here! On about 3 hours of sleep (over the lat 48 hours) but excited to try and answer some questions! Feel free to also drop any below <3

We did just launch this last week after a good bit of work from the team. Steve wrote up a deeper technical dive here if anyone is interested - https://flox.dev/blog/kubernetes-uncontained-explained-unloc...

+1 to Farid, great write-up! What you’re seeing is the long-standing “deriver” mismatch: fixed-output derivations can change their .drv without changing the output path. Eelco is calling it out as well in the comment below. I believe the idea behind the path forward is there but happy to hear more!

Also. Check out Farid's other posts.

Bellroy is. very cool and deep in tech. We actually did a Nix in the Wild with them a while back! https://flox.dev/nixinthewild/nix-in-the-wild-bellroy/