Category: Open Source

Here at Mozilla, we are the first to admit the internet isn’t perfect, but we know the internet is pretty darn magical. The internet opens up doors and opportunities, allows for human connection, and lets everyone find where they belong — their corners of the internet. We all have an internet story worth sharing. In […]

The post Slate’s ICYMI hosts on their online obsessions and wildest 2025 predictions  appeared first on The Mozilla Blog.

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:

First, thank-you to everyone who made the effort to fill out the survey. For a volunteer community project it’s fantastic to see over 900 people took part. It’s notable that 150 people took the survey who were previous users or contributors — it’s really great that people are willing to make this effort to share their experiences — thanks so much!

With this many participants we can see the range of view points and experience across our whole community, many of the comments were enlightening and are worth reading. There are links in many of the questions so anyone that’s interested can go through them.

As the results are extensive I’ve split them into three separate posts, in this post we’ll focus on the first 10 questions of the survey which focused on how users learnt about Guix and their experiences adopting it.

User backgrounds and experience

The survey started by asking participants, How knowledgeable a Linux are you? (Q1).

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

Figure 1 shows this graphically:

The next question (Q2) was, How long have you been using Guix?

Figure 2 shows these results as a bar chart:

These two questions already tell us some interesting things about Guix users:

• Guix users generally have a lot of Linux experience: 50% said they were Intermediates who were “comfortable with the command-line and configuring many aspects“. A further 26% said they were Advanced, and 22% said they were experts.
• Conversely, very few users (~4%) are beginners or exploring Linux users.
• Many Guix users are new to Guix itself.
• Guix’s user-base is growing! Almost 75% of the user-base are recent converts to Guix, having used it for less than 4 years.
• It’s a similar distribution of users to Nix’s. Their 2024 survey showed dramatic growth (~65%) in users from 0-2 years, Guix’s is 49%.
• It’s fantastic to see new users are exploring and trying out Guix.
• Unfortunately, 9% of users are no longer using Guix, but care enough to fill out the survey – so what can be done to help them come back?!

Adopting Guix

The next few questions explored how participants adopted Guix. It’s important that new users have a great adoption experience so they’ll keep using Guix. Conversely, if the initial experience is too difficult, they may simply move onto something else without seeing it’s benefits!

The first question asked, (Q4) Why were you initially interested in Guix?

This question tells us what users had heard about Guix, and what they discovered during their initial investigation. The answers could impact how the project talks about Guix’s strengths and capabilities.

For this question users could select more than one answer and many did so. The most selected choice was “Declarative configuration” where 82% of participants were interested in Guix because it had this quality. The option “Scheme, Guile, and Lisp are cool” was second, where 72% of the survey’s participants were intrigued by Guix because of this aspect. The “Reproducibility” choice came third with 70% interested in this capability. The detailed results were:

There were 110 choices of ‘Other’ where participants could add their own comments, they’re all available to read. Looking through them some themes came through:

• Development environments:
  • “General solution to rvm,pyenv etc”
  • “As a Docker replacement for software development”
• Documentation:
  • “Initial interest in Nix, but hearing about Guix having more pleasant documentation also swayed me towards using Guix instead”
  • “Documentation (not exhaustive but well-structured), simplicity of the CLI”
• Free Software & GNU:
  • “The possibility of releasing the GNU operating system version 1.0
  • “100% free software yes, FSF no (FSFE are fine)”
  • “Being a GNU project helped me decide between Guix and Nix.”
• Use for Continuous Integration:
  • “used for CI, replacing docker with free software and user control”
• Sandboxes and security:
  • “Sandbox environment”
  • “Security: containerized environments integrated in the OS.”
• Package definitions:
  • “Writing packages for GNU Guix seemed more intuitive than for Gentoo Linux (Guix’s hashes > Gentoo’s slots)”
  • “Ease of packaging”
• An alternative to Nix:
  • “Wanted to check out alternatives to Nix. Particularly interested in 1) grafting, 2) measures against ld.so stat storm, 3) performant guix packs without proot”
  • “Use Nix a lot, want to explore that design space more”
• Guile Scheme and Lisp:
  • “One language for everything”
  • “Not nixlang”
  • “homogeneity of the configuration (one language for everything)”
• Full source:
  • “Full Source Bootstrap & Strict Policy to compile all software from source”
  • “Full source auditability”

The next question the survey asked was, Which aspect of Guix did you initially adopt? (Q5). This is users initial entry point into using Guix.

The detailed results were:

Figure 3 shows this as a bar chart:

The summary is that almost 50% of users initially experienced Guix as a GNU/Linux distro: 44% in a graphical desktop configuration and a further 5% in a server configuration. Just over a third of users (36%) initial experience Guix as a package manager on top of another Linux distro. I found this surprising as I’d expected most users to use Guix as a hosted package manager first, what an interesting result! We can also see there’s lots of room to develop Guix Home as an adoption path.

Adoption challenges

Adopting any new technology is difficult and time-consuming, so discovering what elements users find difficult is important. Q7 delved into this by asking, What were the biggest challenges getting started with Guix?

The results were:

Figure 4 shows this as a bar chart:

As we can see the biggest challenge is a Shortage of examples (e.g examples of usage). And, if we consider shortage of how-to tutorials (32%) to be similar then overall we can see there’s a clear need for focused goal-orientated documentation with examples. Inexperience with Lisp syntax and or Guile Scheme and Differences between Guix’s approach and other Linux distros both speak to the unique nature of Guix and the approach it takes: perhaps there are implications for how Guix’s tooling can make initial adoption as easy as possible.

There were 218 comments, which are worth reading through. I’ve summarised them into broad themes:

• Conceptual complexity: comments about the overall knowledge required being too much. Examples are:
• “Understanding the concepts on which guix runs”
• “managing storage space, generations, GC roots, profiles; generally grasping the concepts”
• “Some interesting free software is only available for other distros, it’s hard to adapt to a system without file system hierarchy”
• Lack of drivers: issues caused by drivers not being available. Examples are:
• “can’t really use linux-libre on the machine I installed it on (lack drivers)”
• “Getting an initial installation with working non-free wifi”
• “hiding nonguix”
• Efficiency: comments regarding overall resource usage making Guix slow or unusable. Example comments are:
• “The evaluation of Guix is slow and resource-intensive. My laptop was no match for it, I had to change it.”
• “Guix experimentation is still too slow. Make experimenting faster for new users by identifying rate limiting steps and speeding them up”
• “Slow network when download guix substitute”
• Missing packages and services: issues where Guix doesn’t contain a required package or service.
• “missing packages I needed and getting them upstreamed after I packaged them”
• “Unpackaged free software, and nonfree software”
• “Coming from Nix: smaller, less up-to-date package set, substantially fewer home services”
• Quality and reliability: issues of quality and reliability that made Guix difficult to use. Some comments:
• “hard time fixing config errors with reports”
• “Broken integration between some components (packages and services)”
• “Basic setup is pretty easy on paper, but in practice sometimes it breaks my system and I need to fiddle with shell profiles and environment variables and installing extra packages to get Guix programs play nice with native programs. And I feel like this kind of breakage isn’t acknowledged or addressed enough.”
• Practical guides, how-to’s and examples: situations where a lack of direct instructions or examples made Guix difficult to use.
• “Guix-unique bugs and issues that I can’t find an answer to online”
• “Lack of docs mostly, common patterns, the fact that’s it’s a pain the butt to make things works for some ecosystems on the Guix distro (e.g any app written in Golang, Rust, JS,TS..)”
• Error messages: poor experience caused by error messages that are difficult to understand. Example comments:
• “Horrible error messages”
• “Difficult guile scheme error messages!!”
• “Hard-to-understand error messages”
• Configuring on a hosted distribution): issues caused when using Guix on top of another distribution. Some comments:
• “I found the setting of numerous variables and the comments recommending I do so contradictory and so confusing”
• “SELinux blocked installation of packages: remount”
• “Problems using it on a foreign distro. Guix Home particularly assumes that you are using guix system, I had to tweak the .profile a lot to get it working.”
• Encrypted boot / LUKS: encryption in various forms unavailable or missing certain features:
• “Very poor support for full disk encryption.”
• “Also using a LUKS encrypted root file-system was a challenge at the time i started Guix”
• Language ecosystems (e.g. Rust, PHP): issues due to missing packages, or attempts to package, from certain language ecosystems.
• “Missing packages, and the difficulty of packaging rust or npm packages on guix dissuaded me from contributing them”
• Mac availability: situations where being unavailable on Mac meant Guix could not be adopted.
• “Linux only. nix has macos support too which would help adoption in a team environment.”
• “No MacOS official distribution”

Adoption satisfaction score

The survey asked (Q6), How satisfied were you with your experience adopting Guix?

This question explores the users overall satisfaction with the initial steps of researching, installing and initially using Guix. The question asked the participant to score their satisfaction on one of 5 levels.

See Figure 5 for a visual representation:

This is probably the most important question in the entire survey when it comes to growing the number of Guix users. Overall, it’s positive with Very Satisfied (24%) and Satisfied (43%) meaning that the majority of users are happy with their initial experience. The comments above show there’s lots of room to find small ways to move users initial experience from Satisfied to being overjoyed! Unfortunately, on the other end of the scale 14% of users who were unhappy and the 16% neutral show some of the bigger challenges!

Which GNU/Linux distribution do you use Guix on?

As we saw earlier just over a third of users (36%) initial adopt Guix as a package manager on top of another GNU/Linux distribution. Question 8 asked, Which GNU/Linux distribution did you use Guix on top of?

The results:

I errored when creating this question and somehow missed out Debian! Over 117 answers in the ‘Other’ category said Debian so it’s the most popular distribution to use Guix on, Ubuntu is second (111) and then Arch Linux was third (81). There were also plenty of mentions of OpenSUSE, RHEL/CentOS and Void Linux.

Why did you stop using Guix?

Question 9 was targeted at those that had previously used Guix but had stopped. It asked, You previously used Guix but stopped, why?

This was a comment question and we got some fantastic answers. There were 147 comments from participants, which lines up well with the 150 people who took the survey and classed themselves as a ‘Previous user’ or ‘Previous contributor’.

This was a free form text answer, the full comment are well worth a read through . As before I’ve clustered the comments into themes:

• Complexity of maintenance too high: many commented that the overall experience of using Guix was too time-consuming and complex. A slow configuration feedback loop, inefficiency, and the overall maintenance burden were all concerns. Example comments:
• “I needed to switch to a distribution that required less of my attention when I started my new job. I switched to NixOS with the intention of going back to Guix at a later date, but I am now reliant on so many parts of the nix ecosystem that I don’t think I’ll ever actually switch back.”
• “I was doing more work trying to make my setup perfect or fix issues with it rather than working on my other projects. A lot of things with my setup either broke with time or were just not compatible (My setup couldn’t handle printing, screen sharing, audio, suspending/hibernation and I just didn’t know how to fix all that) and I couldn’t deal with it any longer, I simply went back to whatever worked for me earlier.”
• Learning curve too difficult: many aspects of Guix are completely different from how other distributions achieve the same result. In some instances this learning curve was too difficult and/or there was not enough assistance. Example comments:
• “Mainly the learning curve is huge for a long-time *nix systems user. I knew it would be difficult to adapt, but for each and every little thing I would need to go dig how to fix something. Doing proper power management on my laptop, setting up mail (I’ve been using Gnus for years, but still…!), compile and test mainline kernels on my laptop, etc. It’s awesome to learn all those things, but they all require time. And that’s where I had to give up: I wanted a (reliable) system I could use for my day-to-day work, Guix would be great… if I could spend a few weeks only learning it (and Lisp!).”
• “But the problem ends up to be that the whole ecosystem around guix basically assumes super knowledge about what scheme is, how to use it and worse of all deep comfort and will to use emacs as the main interface to it all. It’s too high of a hurdle to dedicate when just wanting to write some files, evaluate them, declare some packages, shells, etc. I have zero interest and will to use or learn emacs and putting it so much upfront does a huge disservice to the whole project.”
• Lack of drivers within the distribution: the lack of drivers to enable hardware was the most commented on specific issue. Some examples of those comments:
• “As a long time Arch user I found it difficult to configure Guix for daily use. I need proprietary video drivers (and possibly other bits to get everything working?) and I don’t remember if I ever got those up and running.”
• “I have a lot of respect for the technical side of the project, but the politics of free software absolutism (to the point where we are supposed to tell people to replace perfectly functional hardware in order to use Guix, instead of telling them about Nonguix) and the user hostile email based contribution workflow made me realize Guix would likely never reach critical mass, so my time is best applied elsewhere.”
• Unavailable proprietary software: proprietary software not being available was also mentioned (not quite as much as drivers), often in comments that focused on Guix not being practical as a distribution for professional use. Some specific comments:
• “Lack of proprietary software, primarily CUDA, MKL, etc.”
• “Although I like FSF license purity, NixOS was much more amenable to get working on various hardware & did not preclude using Nvidia CUDA.”
• Efficiency and resource usage: there were comments about guix pull taking too long, whether this was actually the fault of Guix pull locally or remote servers, the overall experience was mentioned multiple times. Some example comments were:
• “The core tooling was far too slow (e.g. pulling updates, etc.); Nix is slow, but nowhere near as slow as Guix (was back then, but I’m not aware of the kind of order of magnitude improvements that would have been required). Core functionality was not reliable enough for a server operating system (shepherd, logging, system rollback). Arcane contribution requirements (no provisions for non-Emacs users, e.g. regarding code formatting; baroque and counterproductive changelog and commit factoring requirements); I didn’t mind the email/patch based workflow btw”
• “Guix pull is too slow. The guix ci servers are inaccessible from my location, requiring a proxy. Guix System does not have a large enough community to be reliable and universal enough for daily use (in my opinion)”
• Missing packages and services: there were lots of comments about both missing packages or services and this making it difficult to use Guix. Example comments:
• “Much of the software I needed wasn’t packaged, and it eventually became frustrating. I tried to package what I could, but some things felt extremely difficult, E.g., `jujutsu` `ghc`. However unfortunate it may be, I also rely on various pieces of nonfree software, and Guix was working against me in that regard. I do not like that I have to use nonfree software, but I often have no choice.”
• “Still use to some extent as package manager on foreign distro. For desktop use, waited for usable KDE Plasma packaging, and for laptop, coverage of working builds for ARM. Hoping to return; there is progress on both of these fronts. Size of store and speed of guix pull where also issues (on limited hardware).”
• Out of date packages: meaning that although there was a package within Guix it was lagging, with particular concern about security implications. Example comments:
• “Outdated or absent FOSS software (ex: Gnome, KDE, etc)”
• “Too many packages updates were lagging behind, this was raising concerns for me from a security point of view”
• Quality and reliability: general issues with quality and reliability that undermined the users belief that the project was ready for real use. Examples:
• “An upgrade broke the system and crippled it from booting. Moved on to other distribution”
• “I like the whole idea of guix. But it feels like it is not really ready.”
• Guix not fully supporting disk encryption: full disk encryption in a variety of forms came up multiple times as a Guix weakness. Examples:
• “Guix does not support an unencrypted /boot partition. But also does not fully support LUKS2 due to grub.”
• “I love Guix System, but it still misses a few quality-of-life improvements, such as better support for full disk encryption on install (entering two passwords!) and faster servers for South America. I kid you not, it takes me several hours to install a base system with MATE!”
• Missing guides/how-to’s and examples: we’ve already seen that lack of specific how-to documentation was an issue, there were various comments to that:
• “Examples were insufficient, documentation expected much more in-depth linux knowledge. I would like to try again using it, as I love the concepts of it and I find that I resonate with the people representing Guix, and while I am on NixOS currently I find some social aspects of the Nix project concerning.”
• “I switched back to NixOS due to more Community support”
• Free Software as a constraint: Free Software and GNU as an organisation were commented on as a constraint to having a practical, usable system that met user’s needs. Note that the next bullet is the reverse of this. Some example comments:
• “No ease of access to the tools I depend on without jumping through hoops. VSCode, Chrome, Discord, all required flatpaks. Gnome was extremely out of date and didn’t work well with flatpaks making it even harder to use them. NVIDIA drivers unavailable. I would have to work entirely around Guix to make it usable for the real world. I can’t just convince my friends to stop using Discord. I can’t just convince my job to not depend on VSCode extensions. I have spent my time using VSCode Calva for my personal Clojure projects as well. I would have to spend a lot of time creating my own repository and writing guix packages for everything just to make it usable for myself. The GNU should be trying to meet users where they are to help liberate them, instead of creating an alternate reality where user needs are not addressed. This is a non-starter in the year 2024.”
• “Exclusion of all references to non-free software (and no suggested step-by-step easy setup) made a full-featured initial installation untenable.”
• Not enough GNU: there were also some comments that the Guix project was 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.”
• “I stopped using Guix after it ran a campaign against Richard Stallman. I don’t plan to return back.”
• Language ecosystem issues: as tools like Docker, and languages like Go and Rust become more important, friction with them is more of an issue for users:
• “my use case is to package tooling for other distros and use it to build docker images reproducibly for use in CI environments. it does not work for this use case very well. can’t run guix daemon inside a container”
• “Lack of packages, stance on 100% reproducibility which makes packaging software with transitive dependencies hard, slow evaluator, obscure communication and collaboration mediums, patches take months to even get a review, cryptic error messages.”
• Nix is more modern or practical: many users seem to have explored Guix as an alternative to Nix. Example comments:
• “I looked at Guix as an alternative to NixOS, and like its design a lot, but struggle with the 100% free software approach as I need some non-free software (for various reasons, hardware support, required by work, etc.). I’m aware of the non-guix channel which mostly solves this, but having to compile most things myself got too cumbersome for me — I wish there was a more complete substitute server for that channel, or perhaps even a derivation based on guix with a less strict free-software policy more akin to those of NixOS or debian.”
• “There were too many packages missing or so out of date as to be de-facto missing. Using Guix was therefore much harder to use than Nix, where I had more packages (both Free and non-Free) and they were more up to date.”
• Old-fashioned communications: here were some comments about communications within the project being old-fashioned, both from general users and those that had tried to contribute:
• “There seems to be shortage of packages and slow development. Email or only free software is definitely an hindrance to many people to daily drive guix. It has become hit and miss for me, so staying with nixos as its rich and I can followup on its development easily on git repo, discourse, matrix and all.”
• “The main two reasons are that I find the irc/email/emacs flow very hard to work with and I do not feel safe in the mailing lists.”
• Unavailable on Mac OSX: there were a few comments that in a professional context the fact that Guix isn’t available for MacOS made it difficult to use:
• “Being unavailable on macOS. I have my nix home manager setup on both linux and macOS. Also the lack of a number of packages was a challenge. Like typst, bottom, hugo, tree, ruff, and sd for example. I am interested in becoming a maintainer but I want my setup to also work in macOS.”
• Incompatibility with hosting Linux distro: running Guix on top of another distribution was confusing, particularly for graphical programs:
• “Guix home breaking Fedora. Troubles with binary applications due to the non-fsh nature.”
• “Setting up the package manager & daemon was confusing. The command “guix pull” felt excessively slow. A lot of packages were not up to date. Breaking the FHS”
• Poor contributor experience: the patch process itself, slow reviews and inconsistency in response were all mentioned as issues. Examples:
• “I still use Guix, but am a previous contributor. Important patches (for me) which I submitted were/are ignored, so I’ve stopped contributing.”
• “Perceived Inconsistent patch reviews. I did create couple of patches for guix, I do believe to contribute to project that I use. Sometimes I see patches getting stuck without feedback on them (not necessarily mine), the process to review patches is unclear to me and most likely to most people. Also guix lack automation to help everyone understand what is going on, if patches break rules, if this trivial change could be merged easily, etc. maybe it’s there for you, but I dont see that.”
• “I was passed over for commit access (even though I surpassed the 50 commit requirement) because I could only find 2 people to vouch for me, not 3. Then my patches stopped being merged, and some 2-year-pending patches I sent were closed without good reason. With the way Guix is run and how they treat contributors, it is an insulting/degrading process that I am no longer willing to put myself through.”

As we can see there are a wide variety of reasons why users stopped using Guix, many of them are similar to the challenges that many users find, but they’re even more powerfully felt by these users. It’s really useful to have these themes and comments captured, as contributors may be able to pick up some of these issues and work to resolve them!

How important is Guix?

Focusing back on all users, the next question was, (Q10) How important is Guix in your computing environment?

There was a good range of answers:

A visual representation:

This is an interesting mixture which is probably reflective of many new users, and how Guix is used as a package manager on top of another distribution. Over a third of users consider it to be essential/important where it would be difficult to replace, while the bottom third are tinkering or exploring it.

Some thoughts

We’ve looked at the first 10 questions of the survey which covered the composition of the Guix community, initial adoption and satisfaction, and challenges that led to users moving away from Guix. The first thing to say is how fantastic the response has been to the survey, it’s amazing to have over 900 participants!

Some big take-aways:

• Interest in declarative configuration, reproducibility along with Scheme, Guile and Lisp are bringing in lots of new user – around 50% have been using Guix for less than 2 years
• Guix users are knowledgable Linux users who are comfortable being hands-on with their system
• Around 50% of users adopt Guix as a GNU/Linux distribution, 36% as a hosted package manager on top of another Linux distro
• The survey produced great feedback from current and previous users on areas where the project can improve
• Around 67% of users were satisfied (or very satisfied) with their initial adoption experience
• Guix is essential or important for over a third of users, part of their environment for the next third, and being explored by the last 27% of users

The next post will cover more of the survey — which parts of Guix are most used, what sorts of deployments are being used, architectures and drivers details, and how users view contributing to the project financially.