Guix-HPC is a collaborative effort to bring reproducible software deployment to scientific workflows and high-performance computing (HPC). Guix-HPC builds upon the GNU Guix software deployment tools and aims to make them useful for HPC practitioners and scientists concerned with dependency graph control and customization and, uniquely, reproducible research.
Today we're looking at the results from the Contributor section of the Guix User and Contributor Survey (2024). The goal was to understand how people contribute to Guix and their overall development experience. A great development experience is important because a Free Software project's sustainability depends on happy contributors to continue the work! See Part 1 for insights about Guix adoption, and Part 2 for users overall experience. With over 900 participants there's lots of interesting insights! Contributor community The survey defined someone as a Contributor if they sent patches of…
The results from the Guix User and Contributor Survey (2024) are in and we're digging into them in a series of posts! Check out the first post for the details of how users initially adopt Guix, the challenges they find while adopting it and how important it is in their environment. In this part, we're going to cover how use of Guix matures, which parts are the most loved and lots of other details. As a reminder there were 943 full responses to the survey, of this 53% were from users and 32% were from…
Next week will be FOSDEM time for Guix! As in previous years , a sizable delegation of Guix community members will be in Brussels. Right before FOSDEM, about sixty of us will gather on January 30–31 for the now traditional Guix Days! In pure unconference style, we will self-organize and discuss and/or hack on hot topics: drawing lessons from the user & contributor survey , improving the contributor workflow, sustaining our infrastructure, improving governance and processes, writing the build daemon in Guile, optimizing guix pull , Goblinizing the Shepherd… there’s…
Guix channels let communities develop and maintain their own package collection at their own pace. As users of Guix in high-performance computing (HPC) and computational sciences, we have been developing several such channels. Those channels live under the Guix-Science umbrella, which recently moved to Codeberg. Over the last couple of months, we’ve been using this migration as an opportunity to strengthen scientific channels, both socially—by welcoming more contributions—and technically—by setting up infrastructure to improve the contribution and maintenance workflows.
The results from the Guix User and Contributor Survey (2024) are in! This is the first time the Guix community has run this type of survey, and we're excited to share the results. The goal of the survey was to collect the views of both users and contributors, understanding how people adopt Guix, what they love and they're experiences contributing to the project. There were 943 full responses to the survey, of this 53% were users and 32% were contributors. The table of survey participants is as follows: Table 1: Participant breakdown …
Today I had to setup a Nextcloud instance on a cloud server. A completely scripted approach (e.g. via Ansible or OpenTofu) felt a bit over-engineered in my particular case, so I went for a semi-manual installation.
It is possible to contribute to improving #guix as the need for new functionalities, packages, fixes or upgrades arise. This is one of the strongest points in open communities: the possibility to participate on the development and continuous improvement of the tool. Let’s see how it goes when it comes to guix.
Guix is a huge project which follows closely the #freesoftware paradigm, and collaboration works in two directions. You take advantage of other developers contributions to guix, while you participate yourself to improving guix repositories with your fixes, updates or new features, once they have been tested. In a first approach, from my own experience, one may create a personal local repository of package definitions, for a personal use. As a second step, it is possible to create a public guix channel, in parallel to contributing upstream.
Contributing your code to guix comes to sending #email with your patches attached, it’s that simple. Don't be intimidated by the details (this is used by lots of open communities, after all). Once your patches are submitted, a review of your code follows, see details. Some tools, like mumi, are helpful to that purpose.
This is a painful post to write. It's about a choice one should never have to make, the choice between software freedom and security.
Remote #ci is the way to go in #modernhw digital design testing. In this #ciseries, let’s see how to implement it with detail using sourcehut and a real world example.
Sourcehut is a lightweight #gitforge where I host my #git repositories. Not only it is based on a paradigm perfectly adapted to #modernhw, but also its builds service includes support for guix (x86_64) images. This means that we will be able to execute all of our testing online inside guix profiles, shells or natively on top of the bare-bones image.