… and I wonder whether it wouldn’t be better to use singularity-tools.buildImage to create a Singularity image with all our software, rather than trying to create a Singularity image containing Nix and build our software within it.
I’m only aware of the existence of docker/singularity buildImage, but have never used them.
As a grid manager myself I completely agree with @mjlbach that asking a beleaguered administrator to manage Nix installations across hundreds of machines is a very hard sell. I’d also agree with @teh that it takes the strongest of Nix advocates to provide the leadership required to successfully introduce Nix-based workflows into an organization.
I would surely have given up on Nix myself if not for the promise of correctness, hermetic reproducible builds, and the incredibly vast and fresh set of curated build expressions in the Nixpkgs collection. We created flox with the express goals of managing Nix at scale and lowering the adoption barrier for Nix in an enterprise setting, and for us it has addressed most of the issues raised in this thread. (Thanks @JosW for making the connection!)
We’re really interested to see how what we’ve built can be of use in other HPC environments, and to that end I’d invite everyone to sign up for our open beta and give it a go.
Amen.
FWIW, from my perspectives as
I am unlikely to find the time and motivation to take a deeper look at flox unless and until it is open-sourced.
Thanks @jacg for the feedback - flox wouldn’t be possible without Nix and countless other open source projects, so we’re thrilled to give back to the open source community by sharing flox. For now we’re just asking for everyone’s patience and feedback as we navigate the [mostly legal] intricacies of a new project. With respect to open sourcing, all options remain on the table as we work to figure out the next steps in our journey.
Whatever form flox may take, I hope it will at least provide a fresh perspective on architectural issues that I think may be hampering Nix adoption. In my experience these were the key design choices that made it possible for us to deploy Nix at scale:
The first of these is simply an idea/architecture, and it’s not even unique - I recall listening to Pierre-Antoine Bouttier at NixCon 2018 as he described the GRICAD HPC center’s approach of sharing out /nix as managed from “head” nodes over NFS, and wondering why more people didn’t deploy Nix in that way. The second is available for all to explore on the flox beta, and the third is just Hydra as driven by our “nixexprs” framework.
… and that’s it really. Of course, while this approach has worked for us it may not work for everyone, which is why we want to work with the community to figure out how flox can help Nix gain a foothold in more companies.
I think the only machine that doesn’t have SSE4.2 instructions in wendy, which should be retired by the end of the year.
For distributing CUDA and other packages that are unfree but redistributable, see https://github.com/NixOS/nixpkgs/issues/83884
I’m confident that arguments for supporting science and some firmware bring enough benefits that we can get this merged, but someone will have to do the diligence work and create PRs.
I’m happy to say that Graham made wendy build only big-parallel jobs so SSE4.2 issue is resolved!
https://github.com/NixOS/nixos-org-configurations/issues/146
Thanks! That is great news!
Indeed 
It seems that the biggest two blockers are:
a) licencing issues
b) getting started tutorial
I’d like to make a case for a) if someone can help. For b) I’d like to hear how data scientists use Nix today so that we find a simple way for newcomers to join!
I’d like to invite those that are willing to help or needing help to join us on slack at GitHub - nix-community/nix-data-science: Standard set of packages and overlays for data-scientists [maintainer=@tbenst]
The Slack link returns “This link is no longer active. To join this workspace, you’ll need to ask the person who originally invited you for a new link.”. I would also suggest having a dedicated SIG here on Discourse. Slack could be problematic on corporate networks/laptops/etc.
Conda has cross platform dependency files. Something like this should be used in the future for all languages. But nix is a deterministic distribution system avoiding side effects.
What to use depends on your target. Sometimes packaging something for nix takes some time cause you’re missing N dependencies.
So eventually use best tool for your task at hand.
Beside deterministic sandboxed builds nix allows to copy built packages with dependencies to other machines etc.
Blasting valuable information into the slackhole seems like an unnecessary sacrifice. I’d rather have those conversations in a more durable place like Discourse or Zulip that have permanence, tags, search, etc.
There’s a search feature in discord with unlimited history plan.
Setting up Discourse is quite some work and it’s not possible to have it freely run anymore as NixOS did back in the days.
I don’t think the current slack setup is perfect, but the goal is to get people talking and document things into more permanent forms like READMEs.
Setting up Discourse is quite some work and it’s not possible to have it freely run anymore as NixOS did back in the days.
Why? I thought it is open source?
this book written in 1998, Internet Economics
taught me some of the basic economic theory of the internet, over the traditional leased line, circuit based, non-packet communication we had before IP.
Internet routing and switch equipment has improved, but there are less players (ISP’s) now, but the main concepts still hold fast. Power, Bandwidth, Compute, Storage Fibre, Copper, land rights, maintenance. It all has a cost. Hence once a open source platform or project gets significantly large , these costs spiral out of control, thus many projects ‘are purchased’ by large corporate entities…
I’ve seen it many many times before. I currently have a proposal in the pipe to avoid nixos going down the same route… but i fear it may have a fallen on deaf ears, or ears that don’t really understand that these negative outcomes are real for linux operating systems that get popular, they become ripe for the picking!