The Guix-HPC team writes about GNU Guix for high-performance computing: reproducible research, package tuning, Jupyter notebooks and performance debugging.
HN commenters cite its posts on using Guix without root and on what is in a package, the latter in a debate about building packages.
I didn't know what was guix so I clicked on the "About" page (https://hpc.guix.info/about/).
> Guix-HPC is an effort to optimize [GNU Guix] for reproducible scientific workflows in high-performance computing (HPC).
Ok this is like GNU Guix, but for HPC systems (which are helpfully defined). But what is "GNU Guix", though? Ok I will click the link (https://guix.gnu.org/) :
> *Liberating*. Guix is an advanced distribution of the [GNU operating system] developed by the GNU Project—which respects the freedom of computer users.
I happen to know what GNUOS is, otherwise I would have to click on yet another link to find out what it is (the name at least suggests it's an Operative System).
Guix needs extra help on the initial copy page though. Is "more advanced" than GNUOS... does that mean that GNUOS isn't "advanced" (How so)? It also says that Guix "respects the freedom of computer users". That seems to imply that GNUOS does not. Is that the case?
TL;DR: The "about" page in guix-hpc and guix should start with "Guix/Guix-hpc is an operative system." Then they can talk about how they're based on this and that. And Guix's first page copy text needs to be completely rewritten.
You might be interested in using Guix [1] for reproducible research, as is reported earlier (for genomics analysis) [2] and still actively developed [3].
As a bonus, Guix and Nix [4] allow for modular and composable pipelines, where you can swap different components (such as to upgrade Python from 3.8 to 3.9, or to enable certain optimizations for some Python libraries, or to run on MacOS and Linux while keeping the whole stack more or less the same), which would be more difficult to do reproducibly with other tools such as Docker (composing Guix or Nix functions are easier than composing DOCKERFILE or Docker Compose).
[1]: https://ambrevar.xyz/guix-advance/
[2]: https://academic.oup.com/gigascience/article/7/12/giy123/5114263
[3]: https://hpc.guix.info/blog/2020/11/hpc-reproducible-research-in-guix-1.2.0/
[4]: https://builtwithnix.org/
The answer is "all of the above". Guix is largely community-driven, but receives donations[0] as well as sponsored work like the NLnet grant mentioned in the article. In addition some research institutions employ Guix developers[1].
Personally I have used Guix to convert a CentOS "appliance" into a full-blown desktop system, on a professional contract[2].
0: https://guix.gnu.org/blog/2018/gnu-guix-receives-donation-from-the-handshake-project/
1: https://hpc.guix.info/
2: https://guix.gnu.org/blog/2019/running-a-guix-xfce-desktop-on-centos-7/
Containers as a technology are nice, but it's easy to fall back into the same traps that make software non-reproducible using containers as well. You can precisely specify all your dependencies, but it often takes a lot of effort to make that happen.
I'm a fan of the approach Guix developers are taking for scientific computing, because it makes reproducible software simple enough for people to use without too many headaches: https://hpc.guix.info/blog/2019/10/towards-reproducible-jupyter-notebooks/
Apart from the fact building it the 'non-C way' results in a magic meat package that you have no idea what it contains: https://hpc.guix.info/blog/2021/09/whats-in-a-package/
Guix is also a distro that allows for any number of versions of the same package globally, something that language specific dependancy managers do not.
Distors are there for a reason, and anyone who doesn't understand that reason is just another contributor to the ongoing collapse of the tower of abstractions we've built.
On a tangent -- You might want to look into Guix (at least just the package manager, if not the whole system/distribution); it seems quite popular for similar use cases. See, eg: https://hpc.guix.info/about/
Also, with regards to linux, what stops you from making that the default that students onboard to? I would imagine that something like this becomes quite easy if you have a culture where group members help onboard the new ones into the ways of doing things.