Comparing Nix and Conda

import nixpkgs { allowUnfree = true; …} and it’s ad hoc again

If you don’t want to allow all unfree packages you can whitelist specific packages with allowUnfreePredicate or licenses with whitelistedLicenses, as described in Nixpkgs 23.11 manual | Nix & NixOS.

Probably I don’t really understand what you mean by ”ad hoc“ here, but wouldn’t the only other solution be to allow all unfree packages by default?

I think, the overlaying is really handy but the mechanism via the fixed-point recursion mixed with the different callPackages and mixed with the non-recursive .override* overriding is confusing, also to many other people. Therefore, in order to not damage things one doesn’t fully understand, it is sometimes recommended to do things in a certain way which then seems ad hoc to me, and somehow defeats the argument for nix that I understand what happens in general because it’s based on principles. In practice it makes no large difference if things are indeterminstic or only fragile. At least, if one’s hobby is not to investigate such problems.

3 Likes

Thank you, I didn’t know about the allowUnfreePredicate!

What I had in mind saying “ad hoc” (and it may’ve been not exactly the appropriate language) was rather that flakes themselves discard the licensing info. There’s no way to mark a flake that it imports nixpkgs with allowUnfree, nor is there a way to configure the system to allow building/installing “unfree” flakes on it.

1 Like

Are you aware of anyone successfully running Nix inside Singularity? (So far, we [one other person on our project: I have not had the time to take a serious look yet] have failed to get it to work.)

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

4 Likes

Amen.

FWIW, from my perspectives as

  1. Nix hobbyist
  2. contributor to a relatively small publicly-funded scientific collaboration

I am unlikely to find the time and motivation to take a deeper look at flox unless and until it is open-sourced.

8 Likes

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:

  1. Centralizing all Nix processing and state (including profiles) on a single pair of fault-tolerant “storehouse” servers
  2. Creating a “nixexprs” framework for managing/simplifying Nix expressions in an enterprise setting
  3. Providing automatic and effective CI/CD

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.

2 Likes

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.

3 Likes

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

5 Likes

Thanks! That is great news!

Indeed :slight_smile:

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!

1 Like

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]

4 Likes

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.

2 Likes

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.

Thanks, there’s a new link: Slack

We also have #data-science channel on discord now!

3 Likes

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.

3 Likes

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.

1 Like

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?

1 Like
  1. The software is open source
  2. Using hosted discourse comes with a cost, as we left the bounds of the free tier
  3. Self hosting does cost money as well
2 Likes

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!

1 Like