tomberek

The ability to quickly try out and verify ideas is valuable. This would have taken immensely more time to get to a stage to reasonable verify or dismiss as an idea otherwise. This saves time for builders.

The author cares; this is not a post-a-quick-project-as-slop-to-get-cred situation.

The Nixpkgs Core team was established in Sept 2025 (https://discourse.nixos.org/t/establishing-the-nixpkgs-core-...), so it is a fairly new concept and idea. They've accomplished some good things as highlighted in the post, but are now stepping down. Yes, we'd prefer for the team to exist, but we've also functioned without one for ~20 years. It may take multiple iterations to bootstrap the concept and to figure out the right structure - or we may find it isn't needed. So no, this is not a critical emergency. It's a return to the status quo of late last year.

That being said, I think it is still a concept worth pursuing.

Perhaps give boats some advantage in capacity.

Presumably this would support a big improvement to both SBOM generation as well as various UX features and workflow improvements.

Trading perfect reproducibility for usability: a pragmatic look at Flox's new features

This is exactly how I can rapidly prototype things. Once proficient with this tooling is becomes very easy to quickly spin up services and PoCs. Managing it and iterating is also a breeze.

Random thought. Another commenter worried about the runtime of the program becoming mangled and performing destructive operations on your machine. What if you run the reducer as a source-to-source Nix derivation? Protects against dangerous things, and can be easily distributed to remote builders.

Agreed. Packaging is different than deployment. Devs should return to the art of packaging, such that their software can be then deployed into containers, VMs, micro VMs, whatever. That is what packaging allows, re-use.

This is the sort of behavior Nix encourages (disclaimer: I work at https://flox.dev , using Nix as our baseline tech). Docker as both a packaging and deployment format can carry a bit of weight, but can quickly get out of hand.

This is excellent. Have you considered making a presentation or a write-up of the experience?

A similar article for bringing Ruby into the Nix ecosystem: https://flox.dev/blog/flox-and-ruby

This is an excellent pattern. Nix uses it to allow one to create a full transitive build graph, serialized that plan, move it around, and execute it in a distributed and reproducible fashion.

There are always temptations to loosen the constraints this imposes, but they nearly always come at a cost of undermining the value of the pattern.

`flox` needs Nix to function. So the rpm/dev/OSX installers first install Nix, and then installs flox itself.

If you have Nix already, you can try it out as described here: https://flox.dev/docs/install-flox/#install-with-existing-ni....

side-note: with further improvements to Nix as a library, it may be possible to make installing Nix not necessary for flox to function, but this is on a longer time horizon... don't hold your breath

That link in hub.flox.dev is wrong. The link at https://flox.dev/terms-conditions is correct. Fixing.... thanks!

The python ecosystem will require specific support, so at the moment we recommend using `flox` to get all of the other things that might not be managed by an existing Python package manager, and/or to install that package manager itself.

Being a general solution, `flox` cannot directly provide the same level of integration as a python-specific tool, but we CAN make it easier to use those other tools, and bring in others.

Yes. We have designs to allow for more powerful configuration for experts. A good example of this is let people use alternative manifest representations; JSON, Nix, etc.

Yes, I'm also a Nix maintainer. `nix develop` does many other things, originally based on re-creating the build environment of a derivation. This means that it is not ideal for the case of development environments that must support more than just building.

Yes. For limited situations it provides a simpler interface. Flox won't provide exactly the same feature set, but there are many situations where home-manager is too much.

You can consider the current `flox` environment to be similar to a declarative profile, conceptually positioned between home-manager and devShells.

Supporting rollback and history means disks can fill up. With Nix, this is usually due to a bunch of GC roots pointing to profiles and packages that then cannot be cleaned up. Our environments are not just symlinks, but have a declarative format (under the hood, flakes) so one can remove them, but also reproduce them as needed. So GC'ing them is less destructive than with using `nix-env`/`nix profile`. This allows us to be more aggressive in cleaning up old generations.

So the strategy is to ensure there is always a declarative+reproducible way to recover the things you clean up, then we can apply various heuristics to avoid disks from filling up; free space, age, least-recently-used, least-frequently-used - are all being considered.

Nix runs alongside other distributions in various OSs, including OSX. (Windows is being looked at, do not hold your breath.)

The cross-platform capability of `flox` comes from our usage of Nixpkgs, which includes allowance for some of the differences between platforms and makes them less of an issue.

If some piece of software has a specific difference when run on different platforms and you rely upon that difference, then your need to use that platform in some way: native, VM, translator, etc. Nix does make it easier to manage, build, distribute, multiple kinds of software.

Flox environments leverage this same foundation to expose the same environment on multiple systems and we plan to work on this more. What in particular would you be looking for?

It's not necessarily that one is better than another; it can be complementary. I tend to think that Nix makes many of the reasons to use a container superfluous, but there still remain other reasons to use containers.

For example, a talk about using both Docker and Nix (yep, that's me ;) ): https://www.youtube.com/watch?v=l17oRkhgqHE

> What's your story for dropping down into 'real Nix' if required?

We already have talked about this and plan to allow using Nix itself in those cases where someone needs the additional power. The current thought is to have allow a either a reference to a flake for specific fields or to have an Nix-style entrypoint.

This is not yet exposed or documented. Stay tuned.

aside: absolutely agree that there is a fine line between hiding complexity and exposing power

I understand that Nix solves many problems and indeed bet on its ability to do so. It is why I've put so much effort into Nix itself.

However, Nix poses a relatively steep learning curve being built up from first principles making it very general. Flox aims at simplifying this by narrowing the problem field and providing specialized abstractions and interfaces for those who want to benefit from nix' capabilities without needing to becoming a nix expert at day 0.

(flox employee)

It is to lower the barrier for people who care about geospatial software, but may not be (and don't have to be!) Nix experts.

Thanks for building trystero. Fun and easy p2p in browser.

That seems to be what the article is trying to avoid saying. I'm surprised there is no mention of Haskell; a place where much of this has been experimented and explored. It's fine to redesign the wheel, but take a look at older designs first, and acknowledge them.

I'm a huge fan of the Nix shebang, and we now have a variant of it for the new CLI. Feedback on it would be appreciated.

Governance has been a difficult thing to make progress on. I can say that we did discuss recently cleaning up some of these old solutions and making official approaches clearly marked as such.

I work on Nix and think this paradigm has already impacted and will continue to influence software devopment in general. I want to make it easier for organizations/companies/groups to adopt it. Ideas and questions are welcome.

As a CEO of htmx, I second this appreciation. Well done!

There is a naming problem here where "Nix" is often easily confused with the state management pieces (home-manager, NixOS, etc). The underlying Store abstraction provides the concepts of various kinds of addressing. This is independent of the Nix language and we are currently trying to expose each of these layers more directly so it can be re-used in other contexts.

The piece that might be of interest to you is the interaction between content-addressed and input-addressed content in light of build systems+software+compilers that are not bit-reproducible. There is also the bookkeeping to ensure auditability by third-parties; anyone else can run the same builds and expect the same outcome, or close enough that the differences become easy to find and report upstream (https://r13y.com/), but the system doesn't require bit-reproducibility from day1 because that would be impractical. Of course substituting from a cache is exact, made possible by the signatures.

Remote builds: https://nixos.org/manual/nix/stable/advanced-topics/distribu...

Signing (i'll amend my claim above to be only 1 decade). These are either signatures of a CA path, or for input-addressed things it can be seen as a claim by the signer that the producing build recipe (we call it "derivation") has this particular binary output.

- https://nixos.org/manual/nix/stable/command-ref/nix-store/ge...

- https://nixos.org/manual/nix/stable/advanced-topics/post-bui...

- https://nixos.org/manual/nix/stable/command-ref/conf-file.ht...

- https://nixos.org/manual/nix/stable/command-ref/conf-file.ht...

- example: see the Signatures line for an example that this this specific provenance produced this specific binary output: https://trusted-friendly-sesame.glitch.me/view.html?cache_ba... or https://cache.nixos.org/7ghhnlwla2mddkg7hgqa5v0sr8g5hga8.nar...