Guix

Guix User and Contributor Survey 2024: The Results (part 2)

Steve George — 24. januari, 2025

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

Guix usage

The middle section of the Survey explored how users relationship with Guix matured, which parts they used and where they struggled. Question 11 asked, Which parts of Guix have you used on top of another Linux distribution?

As a reminder a third (36%) of participants adopted Guix by using it as a package manager on top of another GNU/Linux distribution. The detailed results were:

Note that all the percentages in this table, and throughout the posts are rounded to make them easier to refer to.

The next question (Q12) asked participants, Which parts of Guix have you used on top of Guix System?

As a reminder, an earlier question (Q5) determined that 46% initially adopted Guix as a GNU/Linux distro in a graphical desktop configuration, and 5% as a GNU/Linux distro in a server configuration. The results:

This gives us an interesting picture of how Guix usage develops:

• From the first table (Table 10) I was very surprised by the way that Guix users manage their packages. It shows that 24% of users that use Guix on top of another Linux distribution don't use `guix package`. Clearly, many of these users have switched to a declarative package management approach using manifests or Guix Home.
• Guix Home is popular with users of Guix System. It's a relatively new capability in Guix, and there's lots of opportunity to encourage its use on top of another GNU/Linux distribution. It could be a great on-ramp into using Guix generally.
• Guix Shell is very popular both when used in a hosted set-up and on Guix System. There are requests in other parts of the survey for missing features from Nix Shell, so perhaps those are some ways to increase its popularity.
• I was really surprised by how many users are packaging their own software projects, about 40% of Guix System users, and almost a third of hosted users.
• Guix's suite of deployment tools is the least used part of the capabilities. They may not have been utilised by the majority of users yet, but some people find them very useful. There were comments in the survey that these tools drove usage as both a CI and Docker deployment tool.

Guix System usage

The survey then asked (Q15), How have you run Guix System?

This was a multiple choice question, so in total there were 1508 answers from the 943 participants, consequently we can assume that some users deploy Guix System in multiple configurations:

In the Other category there were mentions of using it on different SOC boards (e.g. RockPro64), on WSL2 and on different hosting providers (e.g. Digital Ocean, Hetzner).

Figure 7 shows the break down as a bar chart:

Some thoughts from this question:

• It's notable that the vast majority of users are using Guix as some form of graphical desktop (whether on their own hardware or in a VM). This could have implications for the priority of both graphical environment packaging and testing.
• Roughly, a third of users are deploying Guix as a server (445) out of the total (1508). This is a big increase from the initial adoption phase (Q5) where 5% of users were adopting Guix as a server. It seems that users often adopt Guix as a graphical desktop and then as they become more familiar with it they start to use it as a server as well.
• We can't know how many specific deployments there are as the survey didn't ask how many desktops or servers each user actually deployed. But, the change in the mixture of deployments is interesting. It might be that improving the capabilities, documentation and popularity of the deployment tools (Q15) would also increase the server usage pattern. There are also comments elsewhere in the survey about missing server packages and services.
• Only a small number of users are using Guix as a containerization system or in the public cloud. These are significant areas for professional development and deployment, so an area of Guix that further development could focus on.

Architectures

The survey then asked (Q16), Which architectures do you use Guix on?

Again this was multiple choice, there were 1192 answers from 943 completed surveys:

As we might expect x86_64 is the most popular, but there are quite a few AArch64 users as well. There are various comments in the survey about challenges when using different architectures (e.g substitute availability, cross-compiling challenges), see the linked comments throughout these posts for more.

Proprietary drivers

Proprietary drivers is an interesting topic in the Guix community. For Q17 the survey asked, Do you use proprietary drivers in your Linux deployments?

The goal was to understand driver usage across all Linux usage, whether when using Guix or another Distribution. As this was a multiple choice question, there were 1275 answers from the 943 participants.

Figure 8 shows it as a bar chart:

• From this we can conclusively say that the majority of Guix users do use proprietary drivers. Although hardware that respects Freedom is available, hardware requiring proprietary drivers is sadly the norm.

Other applications

The next question was (Q18), Do you use other methods and channels to install applications?

One of the advantages of Guix is that it's a flexible system where users can create their own packages and share them with the community. Additionally, there are other methods for installing and using applications such as Flatpak. However, we already know that during adoption some users struggle to find the applications that they need. This question explores whether that changes as usage matures.

The results were:

Figure 9 shows this visually:

Some thoughts:

• Overall, we can conclude that the vast majority of users are using applications using multiple different methods as there were 2634 answers in total!
• 607 participants, out of the 943, selected that they use the Nonguix channel, so 64% overall. This is a similar level of usage for applications as drivers. At the other end 234 only use applications from Guix, ~25% of users. This is a great demonstration that Guix attracts a broad range of users — some users who solely use Free Software, as well as those that need or want software that's under a wider set of licenses.
• A large number of users package and use their own Guix channel, 442 which is 47% — this seems inline with the earlier questions about how Guix is used.
• There were quite a few different options in the Other category including Distrobox, RDE and guixrus, Docker, Conda, Homebrew, AppImage, Pip and Nix.

Overall satisfaction

The survey asked participants (Q19), How satisfied are you with Guix as a Guix user?

This is probably the most important question in the entire survey, since happy users will continue to use and contribute to the project.

The bar chart is Figure 10:

• Overall, this is a really good result with 655 of the 943 participants clearly satisfied or very satisfied, ~70%. This is a good number that shows many users have a really great experience with Guix.
• It also echos what we saw with the adoption satisfaction question.
• The middle portion who are neutral is bigger that I personally would like to see. This is commonly a group that is not really happy with a product, but for various reasons don't want to say so. There's definitely some areas the project can work on to help users to continue enjoying using Guix.
• At the other end of the scale the very dissatisfied and Dissatisfied are 108, so 11%. We've seen some of the challenges in earlier questions, and the next question explores these further.

Limiters of satisfaction

For Q20 the survey asked, Which areas limit your satisfaction with Guix?

The detailed results:

As a visual graph:

The first thing to note is that there were 2765 entries from our 943 survey completions, so users have challenges in multiple categories.

• About 48% of participants have issues with Guix's runtime performance. It's the biggest issue that users face and shows up in other survey data and comments.
• The second biggest challenge is with missing or incomplete services, where 39% of participants struggle with this.
• The shortage of informal guides, examples and videos is the next biggest challenge, this also came through in the adoption question (Q7).
• Tied with it is the difficulty of understanding error messages and debugging. We didn't ask about this in the adoption question (Q7), but there are comments throughout the survey where users struggle with debugging due to poor error messages.
• The fifth biggest problem is that hardware drivers that users need are not included, with 33% of users hitting this problem.

There were also 213 comments in the Other category, the full list of comments is available. As before I've grouped the comments — at this point we're starting to see consistency in the grouping so to avoid a lot of repetition I've only put in one example from each one:

• Complexity of maintenance: where the overall experience of using Guix was too time-consuming and complex.
• "Time/complexity of managing declarative configuration, handling problems that occur due to package updates/conflicts, creating custom packages and keeping them updated"
• Learning curve: where learning Guix's unique approach was too difficult.
• "I really love the idea, but it's extremely difficult to use, especially for beginners"
• Lack of drivers within the distribution: issues where users couldn't use their hardware.
• "Guix is unusable without nonguix / proprietary drivers"
• Proprietary software: missing proprietary software that was required.
• "Limitations in FHS emulation for proprietary programs"
• Efficiency and resource usage: where overall resource usage made the experience slow or unusable.
• "cicd and other infrastructure (global mirrors)"
• Missing packages and services: where Guix didn't have a package or service the user needed.
• "Some buggy services, which are hard to patch without knowledge and proper documentation"
• Out of date packages: issues where Guix's packages were not up-to-date.
• "Many packages are severely out of date, some break often during routine upgrades (build failures), many things missing and have sat on the Guix Wishlist for years"
• Quality and reliability: general issues of quality and reliability that undermined the users belief that Guix was ready for use.
• "master is often broken and patches for these issues get ignored so I have to use a temporary fork of the main guix repo with the patches applied"
• Encrypted boot and disks: issues arising from missing encryption capabilities.
• "Setting up full disk encryption for multiple disks or unusual arrays of disks and then secure boot issues"
• Practical guides, how-to's and examples: issues where there were no direct instructions or examples, as compared to reference documentation.
• "examples, a show of how a task is done in Debian or OpenSUSE and contrast it with how the task is done in guix would be helpful"
• Free Software as a constraint: limitations and concerns about Free Software and GNU as an organisation constraining practical user freedom.
• "The hard stance of the GNU project on non-free software makes it hard to find "whats out there""
• Not enough GNU: limitations and concerns that Guix is not sufficiently supportive of GNU and/or Richard Stallman.
• "I am disappointed that you veered off the course of freedom and added nonguix. Also that you hate on RMS."
• Language ecosystem issues: problems packaging or using Guix with ecosystems like Docker, Go and Rust.
• "Packaging nightmares won't let us have nice things"
• Unavailable on Mac OSX: inability to use Guix as it's not available for Mac.
• "No macOS official distribution"
• Incompatibility with hosting Linux distro: difficulties using Guix on top of another Linux distribution, particularly using graphical programs.
• "Some DEs don't integrate as well as they do on other distros."
• Error messages: challenges debugging issues due to difficult to use error messages.
• "guix is very-very slow and consumes too much memory and CPU for what it's doing. also error messages are the worst i've seen in my 10 years of programming"
• Poor contributor experience: comments caused by contributions not being reviewed or other poor experiences.
• "Slow, or sometimes inexistent, feedback for submitted patches and issues"

Not all comments fit into a specific theme, I've pulled out some other interesting ones:

1. Shepherd as a constraint: some users love that Guix doesn't use Systemd, but there are some comments worrying about compatibility and migration.
• "I'd like to be able to use systemd. I like that Guix is doing the work so that we break the init system monoculture though. But I'd like systemd to be an alternative. The term service is overloaded which is confusing. I also think that some developer (in-repo) documentation is missing. Specifally regarding packages that need a special boostrapping process such as node or bqn"
• "lack of features comparing to systemd"
2. Reproducibility challenges: reproducing Guix set-ups when using channels or other issues.
• "Guix is pretty perfect, but there are breaking changes between channels, would love for the channel to pin to specific guix commit when building it's packages and have a warning if the commit is outdated by x days"
• "not reproducible due to ~/.config/guix and channels not pinned easily"
3. Releases and stable channel: a few users have concerns about a lack of new releases, or wanting to use a more stable release channel.
• "Some kind of LTS release that I can pin my work to would be great. Maintaining my own channels for work/personal use is good but sometimes guix updates cause things to break so I need to pay attention to keep things working. A more stable release with better probability of substitute hits would be nice."
• "No new release in over 2 years"
4. Running compiled binaries: situations where the user wants to run a compiled binary that's expecting a 'standard' Linux.
• "Running Software not in channel like: Compilers for embedded systems (avr), proprietary software (matlab)"
5. Architecture issues: there's a few comments about issues using alternative architectures, particularly about substitute availability.
• "Aarch64 seems like it gets less love and x86. Takes time for broken packages to get fixed on aarch64"

What should Guix improve?

The survey then asked, (Q21) Which areas should Guix's developers improve so you can use Guix more?

This question was done as a ranking question where participants had to prioritise their top 3. The rationale for asking it in this way was to achieve clarity over prioritisation.

It's useful to look at this in two ways, first the table where participants ranked their highest priority:

This second table shows how each element was ranked across all positions, reordered to show the overall prioritisation:

Some thoughts on what this means:

• We can see that Performance and tuning (faster guix pull) consistently shows up as an area Guix users would like to see improved.
• The second highest priority, Make Guix easier to learn (more docs!) is also consistent, as we've seen from other comments the main desire is for more instructions and examples.
• In third place is, Making the latest versions of packages available (package freshness). It's a little less consistent, notice that it's the highest priority concern for users (Table 18), but drops a little amongst later priorities.
• Next is More packages (more is better!), and we've seen that missing packages is a limit to adopting or using Guix.
• The fifth highest priority is Package reliability (e.g. installs and works), this seems to be more important in lower ranks. We've seen lots of comments about packages that have issues, require further configuration or don't integrate well (particularly in a hosted set-up). This one is intriguing as one possibility would be to focus on a smaller set of packages, yet Focused high-quality packages (fewer is better!) consistently came last.
• The sixth is Hardware support (drivers), again it's less important at later ranks. This one is also interesting as in the adoption questions, and in many of the comments about challenges it's consistently mentioned as a significant challenge. It may be reflecting that users who are using Guix must have solved their driver problems, so it's slightly less important if your machine works!

Guix sustainability

The next section of the survey was for Contributors, we'll cover that in the third post in the series. After the contribution section Q32 asked all users, How likely are you to financially support the Guix project?

As a volunteer project, with no corporate sponsors, the rationale for asking this question is that some aspects of the project (e.g. infrastructure and sponsored work) require finance. The results were:

As a graphical bar chart:

The results tell us that about 50% of users would be willing and able to financially contribute to Guix. There's also a significant set of users who are unable to do so, and one of the clear benefits of Free Software is that we can all use it without charge!

❤️ Love Guix!

Having asked lots of structured questions and ones about challenges the last question (Q33) was, What do you love about Guix?

There were 620 answers, so 65% of the participants wrote something — that's a lot of love for Guix!

There were lots of positive comments about how friendly and helpful the Guix community is; the joys of using Scheme/Lisp and Guile; the importance of user-focused Free Software; and the benefits of the declarative approach.

All the comments are available to read, and I encourage you to have a scroll through them as they're very uplifting!

A few I pulled out:

• "I enjoy the commitment, patience (!), and friendliness of so many in the community!"
• "Scheme! That Guix fits my preference for declarative, functional and minimalist computing! And it’s friendly and helpful community, of course!"
• "Guix provides reproducibility that I think is invaluable for scientific computing. There are many brilliant community members who spend their time improving Guix and helping other users. Diverse opinions are tolerated on the mailing lists. I like how the project's community and leadership have responded to users who express discontent on the mailing lists -- respectfully and openly, but wary of making radical changes that might jeopardise the project."
• "Community (people) by far, focus on free software, Scheme, reproducibility, flexibility. Guix is one of the hidden gems of the free software world."
• "Friendly community, GNU project"
• "I really appreciate everything you do, and I really hope the process for contributors can be modernized with Codeberg or similar forges which is second nature to most developers."
• "Reproducibility and providing a way for people for being technologically independent and free."
• "There's many things to love, but most important (and perhaps unloved to a certain extent) is the ability to create Guix channels for any and every purpose. As an effort to package the whole free software world, the community also feels quite diverse, with people and teams often working on vastly different things that somehow come together under one big umbrella."
• "Guix pack is amazing and allowed me to run some exotic guix packages on foreign systems, and guix system is really cool in general, tons of packages, the best gnu certified distro in general."
• "Having all my system configuration in one place allow me to remember what changes I did to my system at a glance. I can't imagine going back to a distribution where all the changes I make to a system would need to be done again if I swapped machine."
• "Freedom! The four software freedoms, plus freedom from side-effects."

Key insights

In this post we've looked at the questions the survey asked participants about their use of Guix. And as a reminder, there were over 900 participants who completed the survey.

The main conclusions I draw from this part are:

• There's a high level of satisfaction amongst Guix users: about 70% were very satisfied or satisfied. This is really positive as happy users are more likely to continue to use Guix, and may become contributors!
• When used on top of another GNU/Linux distribution (hosted) Guix's package management and development environments capabilities are the most utilised parts. When used as a GNU/Linux distribution package management and home environment are the most used parts.
• The majority of Guix System users are using it in a graphical desktop configuration, as they become familiar with it they start to use it as a server.
• There's lots of great feedback on areas where users would like to see improvements. One thing to bear in mind is that as a volunteer project there may not be people with the time or interest to work on these areas — but nonetheless, consistent feedback is useful for Guix's developers.
• Many users would be happy to donate to Guix to support its mission.

If you missed it, the first post in this series covers how users adopt Guix. And, the next post will cover how Contributors interact with the project.