The first version of LIPS Scheme had regex based tokenizer. It was using a single regex to split the input string into tokens. In this article I will show the internals of the new Lexer in LIPS Scheme.

A SRFI 9-style define-record-type is specified which allows subtyping while preserving encapsulation, in that the field structure of supertypes remains an implementation detail with which subtypes need not concern themselves.

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 any form. That includes changes to code, but also other improvements such as documentation and translations. Some Guix contributors have commit access to the Guix repository, but it's a much more extensive group than those with commit rights.

Of the survey's 943 full responses, 297 participants classified themselves as current contributors and 58 as previous contributors, so 355 participants were shown this section.

The first question was (Q22), How many patches do you estimate you've contributed to Guix in the last year?

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

The percentage is the percentage of contributors that sent patches in the last year. That means the 42 participants who were previous contributors have been excluded.

Figure 13 shows this visually:

As we can see many contributors send a few patches (61%), perhaps updating a package that they personally care about. At the other end of the scale, there are a few contributors who send a phenomenal number of patches.

Active contributors

It's interesting to investigate the size of Guix's contributor community. While running the survey I did some separate research to find out the total number of contributors. I defined an Active contributor as someone who had sent a patch in the last two years, which was a total of 454 people. I deduplicated by names, but as this is a count by email address there may be some double counting.

This research also showed the actual number of patches that were sent by contributors:

Figure 14 shows this:

Together this give us an interesting picture of the contributor community:

• There's a good community of active contributors to Guix: 300 in the survey data, and 454 from the direct research.
• A significant percentage of contributors send one, or a few patches. This reflects that packaging in Guix can be easy to get started with.
• The direct research shows an even distribution of contributors across the different levels of contribution. This demonstrates that there are some contributors who have been working on Guix for a long-time, as well as newer people joining the team. That's great news for the sustainability of the project!
• There are also some very committed contributors who have created a lot of patches and been contributing to the project for many years. In fact, the top 10 contributors have all contributed over 700 patches each!

Types of contribution

The survey also asked contributors (Q23), How do you participate in the development of Guix?

Figure 15 shows this as a pie chart (upping my game!):

Of course, the same person can contribute in multiple areas: as there were 531 responses to this question, from 355 participants, we can see that's happening.

Complex projects like Guix need a variety of contributions, not just code. Guix's web site needs visual designers who have great taste, and certainly a better sense of colour than mine! We need documentation writers to provide the variety of articles and how-tos that we've seen users asking for in the comments. The list goes on!

Unsurprisingly, Guix is code heavy with 60% of contributors focusing in this area, but it's great to see that there are people contributing across the project. Perhaps there's a role you can play? ... yes, you reading this post!

Paid vs unpaid contribution

FOSS projects exist on a continuum of paid and unpaid contribution. Many projects are wholly built by volunteers. Equally, there are many large and complex projects where the reality is that they're built by paid developers — after all, everyone needs to eat!

To explore this area the survey then asked (Q24), Are you paid to contribute to Guix?

The results show:

We can see this as Figure 16 :

Some thoughts:

• Guix is a volunteer driven project.
• The best way to work on Guix professionally is to find a way to make it part of your employment.
• For everyone involved in the project the fact that the majority of contributors are doing it in their spare time has to be factored into everything we do, and how we treat each other.

Previous contributors

Ensuring contributors continue to be excited and active in the project is important for it's health. Ultimately, fewer developers means less can be done. In volunteer projects there's always natural churn as contributor's lives change. But, fixing any issues that discourages contributors is important for maintaining a healthy project.

Question 25 was targeted at the 59 participants who identified themselves as Previous Contributors. It asked, You previously contributed to Guix, but stopped, why did you stop?

The detailed results are:

Figure 17 shows this graphically:

There were 80 answers from the 59 participants so some participants chose more than one reason.

• As we can see a change in external circumstances was the biggest reason and to be expected.
• The next reason was Response to contributions was slow and/or reviews arduous, as we'll see this repeatedly showed-up as the biggest issue.
• Next was The contribution process (e.g. email and patch flow) which also appears in many comments. Judging by the comments the email and patch flow may be a gateway factor that puts-off potential contributors from starting. There's no way for the survey to determine this as it only covers people that started contributing and then stopped, but the comments are interesting.

Future contributions

Q26 asked contributors to grade their likelihood of contributing further, this is essentially a satisfaction score.

The question was, If you currently contribute patches to Guix, how likely are you to do so in the future?

Figure 18 shows this graphically:

Out of the audience of current and previous contributors, 355 in total:

• The 35% of contributors who are 'Certain' they'll contribute is a great sign.
• The 31% that are 'Likely' shows that there's a good pool of people who could be encouraged to continue to contribute.
• We had 58 participants who categoried themselves as Previous Contributors and 41 answered this question with definitely or probably not, that's about 12%. That leaves the 80 (23%) who are loosely positive.

Improving contribution

The survey then explored areas of friction for contributors. Anything that reduces friction should increase overall satisfaction for existing contributors.

The question (Q27) was, What would help you contribute more to the project?

Figure 19 bar chart visualises this:

The 355 contributors selected 933 options for this question, so many of them selected multiple aspects that would help them to contribute more to the project.

Conclusions we can draw are:

• Ensuring there's Timely reviews and actions taken on contributions is the biggest concern for contributors, and as we saw also causes contributors to become demoralised and cease working on the project.
• The concern over both Debugging and error messages has been a consistent concern from contributors.
• Interestingly, documentation of Guix's internals is a priority in this list, but in other questions it doesn't appear as a high priority.

Comments on improving contribution

Jumping ahead, the last question of the contributor section (Q30) was a comment box. It asked, Is there anything else that you would do to improve contributing to Guix?

The full list of comments from Q27, and Q30 are available and worth reading (or at least scanning!).

Looking across all of them I've created some common themes - picking a couple of example comments to avoid repetition:

• Compensation for developers: there were comments from developers who want to work on Guix professionally, or people offering to donate.
• "[Part of a long comment] ... For me personally it really boils down to the review process. Some patches just hang there for many months without *any* reaction. That is quite discouraging to be honest. So if there would be fund raising, I think it should (for a large part) go to paying someone (maybe even multiple people?) to do code reviews and merge patches. And in general do the "gardening job" on the issue tracker."
• "I would be happy to contribute to some kind of fund, maybe by a monthly subscription, which would award stipends for experienced guix contributors to work on patch review."
• Complexity of contribution: where the overall set of steps required to contribute were too complex.
• "For occasional contributions, the threshold is higher than for most projects, in part due to less common tools used in the project (bugtracker for example)"
• "[long comment where the substance is] I'd rather spend my limited time contributing to a 100% free software project than reading 20 webpages on how to use all the CLI tooling."
• Issues with email-based contribution: concerns about the steps to create a patch, email it and so forth.
• "Difficult; I am not used to the email workflow and since I'm not contributing often it is close to rediscovering everything again which is annoying. There isn't a specific thing that could solve that I guess. apologies if this doesn't say much"
• "The GNU development process with mailing lists and email patches is the most difficult aspect."
• Issues with speed and capacity of patch reviews: this is the highest priority amongst contributors, so there were many comments about patches not being reviewed, or reviews taking a long time.
• "I really dislike that 70% of my patches don't get reviewed at all, how simple or trivial they may be. I do really test them and dogfood so contributing seems like a waste of time as someone without commit-access."
• "I already checked "timely reviews/actions", but I want to emphasize how demoralizing my contribution experience was. I was excited about how easy it was to make, test, and submit a patch; I would love to help improve the packaging situation for things that I use. But it's been about a year now since I submitted some patches and have received exactly 0 communication regarding what I submitted. No reviews, no comments, no merge, nothing. Really took the wind out of my sails"
• Automate patch testing and acceptance: suggestions to speed up the review pipeline by automating.
• "A bias for action. If no one shows interest in a patch, and it's constrained, it should just be landed."
• "Minimizing the required work needed to keep packages up to date. Most of the best developers in Guix are commiters and all the time they have to spend reviewing package update patches etc. is away from improving Guix's core. They should be able to focus on things like shepherd, bootloader configuration, guix-daemon in guile, distributed substitutes or a more modular system configuration (e.g. letting nginx know of certbot certificates without having to manually pass (ssl-certificate "/etc/...")).*"
• Adding more committers: comments that more contributors would increase project velocity, and general concerns about how difficult it is to become a committer.
• "Keep manual up to date, I think we need more committers doing reviews and give more love to darker corners."
• "All the best. The project might need more hands to review incoming patches."
• Addition of a pull requests workflow: specific comments requesting the addition of a Forge experience.
• "I would use Forgejo (either an instance or at codeberg) to simplify contributions and issue handling. In my humble and personal opinion the forge workflow makes it much easier to get an overview of what is going on and to interact with others on issues and PRs"
• "I think opening a pull request approach would really modernize the way of working and help welcome more people. We could still easily support patches too."
• Automating package builds and tests: comments relating to automation of building packages as part of the contribution flow.
• "We really need to improve the CICD situation. I see we have so many system tests that could catch issues. Let's make sure each patch has run at least against a couple of those system tests before it is being merged, or even before a reviewer has even looked at. Today a colleague of mine, who is just getting into Guix because I told him had issues with the u-boot-tools package not being built on a substitute server and being broken. Yeah, that can happen, but it happens all the time and it is such a bad experience for new and existing users."
• Bugtracker improvements: comments about improving the bug tracker.
• "A formal method to count the number of users affected by an issue so that developers know what to prioritize. For example, ubuntu's launchpad has a "bug heat" metric which counts the number of users that report they are affected by the bug."
• Debugging and error reporting: challenges debugging issues due to difficult error messages in Guix, or underlying Guile weaknesses.
• "The development workflow with Guile. I've recently switched to arei/ares, but I'm still a total newbie on how to effectively develop and navigate. I've used quite some Common Lisp, and I have my own channel with a handful packages, but it takes a long time to develop without the necessary knowledge of both Guile setup and Guix setup."
• "I just want to reiterate that the debugging process can be painful sometimes. Sometimes guile gives error messages that can be bewildering. As an example, I spent awhile debugging the error message "no value specified for service of type 'myservice'". The problem was that I omitted the default-value field in my service-type, but the error message could have included the default-value field."
• Runtime performance and resource usage: where it makes the experience of building and testing Guix slow or unusable.
• "Foremost faster guix evals. I forget what I was doing while it runs."
• "Building guix takes too long time for packagers. It is not clear why everything needs to be compiled when only contributing a package. Why does the documentation need to be built when adding a package?"
• Practical guides, how-tos and examples: requests for direct instructions or examples, as compared to reference documentation.
• "Improve the documentation on how to contribute. It is currently very hard to follow, some sections are simply in the wrong order, others presuppose the reader wants to evaluate several different alternatives instead of pointing to one simple way of doing things. And steps that though simple are unusual and will seem complicated to most people don't get explained in sufficient detail and examples."
• FSF association as a constraint: concerns about Free Software and GNU as an organisation constraining practical user freedom.
• "*Drop GNU and drop the hardline stance against discussing any proprietary software. It doesn't have to be supported directly, but at least have a link to Nonguix or something. Or have a feature flag like Nixpkgs. Who cares if the distro is certified by an organization that is pretty much irrelevant, actually giving people agency over their tech is what should be the number one goal."
• "Guix is one of the GNU projects with the most potential and relevance, but unfortunately it seems association with the FSF is a contributing factor to limited adoption."
• Not enough FSF: comments that the Guix project was not sufficiently supportive of FSF and/or Richard Stallman.
• "collaborate more with other GNU projects"
• Commit messages: concerns that the commit message format is repetitious or unneccessary.
• "Encourage or enforce the usage of commit messages that detail why a change is done (and not what is done - which is already visible from the git diff)."
• Importers and language ecosystem: comments about possible improvements to deal with dynamic language ecosystems (e.g. Javascript and Rust).
• "Improved build systems and importers. Generally improving management of high-noise ecosystems (Maven, Rust, NPM, …)"
• "Packaging Golang or Rust apps can be difficult and time-consuming because Guix requires all (recursive) dependencies to be packaged in Guix. I often gave up and just re-packaged a precompiled binary from upstream or another distro. It would be much easier if Guix relied on existing language-specific dependency management (e.g., use Cargo.lock files to fix all dependencies) - not perfect from Guix pov, but pragmatic and much more usable."
• "More flexible package definitions but also more strict filtering of available packages. For example, allow some packages to use the internet in the build path (so you may easily install pip packages like TensorFlow, Flax), but by default do not allow installation of NonFree licenses and network enabled packages. We allow package transformations (--with-commit) which need network access anyway and doesn't verify hashes, I think this can be allowed. The end goal of a package should be to be reproducible from source, but the current goal can be usability, widespread adoption, reliability. This way we can start to use Guix in more scientific experiments and super computers, then the new users can help contribute further."
• Project communications methods: requests for communications within the project to use modern methods (e.g. Matrix, Discourse, Github).
• "Having a Discourse instance, so that people can ask questions and others and chime in and the best answers get upvotes. IRC and mailing lists are suboptimal. My success rate of getting ANY reply to my question have been consistently less than 50% regardless of the time of the day, because in IRC it scrolls down and questions go out of focus. Also in IRC the threads of discussion is getting mixed. Keep the IRC, but provide a Discourse instance. I personally even pay for paart of the cost."
• Repo organisation: ideas to widen the set of contributors by having a community repo (e.g. Arch Linux like).
• "I would like more packages under Guix, but I am not convinced that adding them all to the Guix channel is the way. I believe a large number of Guix packages should be moved to guix-free or similar channel. The packages in Guix itself should be the minimal ones that come installed in Guix system. The guix-free channel should be part of default-channels."
• "I feel like channels are a cumbersome alternative to community packages. I previously tried to package a lesser known programming language compiler for Guix but never got replies to my patches to contribute the package. Perhaps there could be a core and community channel with stronger/weaker standards."
• Project culture: concerns about the project being inward looking, not inclusive and with too much gatekeeping. Most comments in this area were very passionate, and in some cases a bit angry.
• "TODO lists and direction is very helpful. Lists of "good first task" or "very important — need help with" etc, things to motivate others to contribute in. Also helpful if people ACTUALLY become part of the distro and it's not all gate-kept by idiots with attitude. I don't want to invest 1000 man hours to prove myself worthy of maintanership of a package!"

Organisational and social improvements

It's common in FOSS projects to focus on the technical issues, but Free Software is a social endeavour where organisational and social aspects are just as important. Q28 focused on the social and organisational parts of contribution by asking, What organisational and social areas would you prioritise to improve Guix?

This was a ranked question where participants had to prioritise their top 3. The rationale for asking it in this way was to achieve prioritisation.

It's useful to look at the results in two ways, first the table where participants set their highest priority (Rank 1):

Out of the 355 participants in this section, 338 answered this question and marked their highest priority.

Figure 20 shows it as a pie chart:

This second table shows how each category was prioritied across all positions:

Figure 21 shows this as a stacked bar chart. Each of the categories is the position for a rank (priority), so the smallest overall priority is the most important:

Looking at these together:

• It's clear that the highest priority (table 28) is to Improve the speed and capacity of the contribution process, as 63% of participants selected it and nothing else was close to it.
• I found it quite confusing that it didn't also score highly in the second and third rank questions, which negatively impacts the overall score. This seems to be caused by the question having a significant drop-off in answers: 338 participants set their 'Rank 1', but only 264 set a 'Rank 2' and then 180 set a 'Rank 3'. The conclusion I draw is that for many contributors the sole important organisational improvement is to improve the speed and capacity of the contribution process.
• Nonetheless, overall Project decision making and co-ordination was the most important social improvement across all ranks, and it was the second most important one for 'Rank 1' — so that's pretty consistent. Other than improving the contribution process this was the next most important item on contributors minds.
• Promotion and advocacy also seems to be important, though there are very few comments about it in the survey overall. The next most important across all ranks was Fund raising, which does get some comments.

Technical improvements

The partner question was Q29 which asked, What technical areas would you prioritise to improve Guix overall?

This was also a ranked question where participants had to prioritise their top 3.

There were 345 answers for the highest priority, 327 for the second rank and 285 for the third rank — so not as significant a drop-off as for the social question. Figure 22 shows this as a bar chart:

As before I've converted them to priorities in each rank. The smallest overall score is the highest priority:

Figure 23 shows this as a stacked bar chart.

Some things that are interesting from this question:

• For the technical improvements there isn't a single over-riding 'Rank 1' priority (table 30). The first choice, Debugging and error reporting, does come up consistently in comments as a problem for packagers, and across all three ranks it's the third priority.
• Across all ranks Debugging and error reporting along with Runtime performance (speed and memory) are high priorities. These are probably quite connected as there's lots of comments in the survey about error reporting and slow evaluations making development time-consuming and difficult.
• It's possible to think of the second and third priorities for 'Rank 1' (table 30) as being connected, since the velocity needed for Making the latest version of packages available would be helped by Automate patch testing and acceptance. We can see from the second table that through all priorities this is the area that contributors care about the most.
• We asked the same question of all Users (Q21) earlier in the survey. This time the question was for Contributors only and there were a few specific contribution-focused options. It's interesting to see the contrast between contributors and users priorities:
• For both the contributor (P2) and users (P1) improving the runtime performance was a high priority, so it's pretty consistent.
• For users making Guix easier to learn was the second highest priority, there wasn't really an equivalent option in the contributor question.
• Users identified Making the latest versions of packages available (package freshness) as very important and it's also a high priority in the first rank for contributors. However, overall it was middle of the pack for them — with both Project infrastructure (e.g. continuous integration) and Contribution workflow (e.g. Pull Requests) coming higher.

Key insights recap

That completes our review of the contributor section! Here are the key insights I draw:

1. The size of the active contributor community (~450) is really exciting. Many developers send a few patches (~60%), while at the other end of the scale there are some who have sent hundreds.
2. Retaining and developing contributors is important for the project's sustainability. About 66% of active developers are likely to contribute again. That's great, how can we encourage that to happen?
3. The key reasons contributors stopped (aside from life changes) was a slow response to contributions and the contribution process (e.g email and patch flow).
4. Improving the capacity and speed of reviews was also the over-riding concern for active contributors by a significant margin. High priority suggestions were automating patch testing and acceptance, along with improving the projects infrastructure (e.g. continuous integration).
5. Technical improvements to the developer experience were improving debugging and error reporting, runtime performance and also providing a more commonly used contribution process (e.g. Pull Requests).
6. Finally, the project is 95% a volunteer one, so we should bear in mind that everyone's contributing to Guix on their personal time! While it's great to see all this fantastic feedback and it's very useful, Guix is a collective of volunteers with the constraints that brings.

Getting the Data

We've really squeezed the juice from the lemon over these three posts — but maybe you'd like to dig into the data and do your own analysis? If so head over to the Guix Survey repository where you'll find all the data available to create your own plots!

This SRFI defines the procedure generate-symbol. Each time it is invoked, the procedure returns a new symbol whose name cannot be guessed. The returned symbol is a standard symbol for all purposes; it obeys write/read invariance and it is equal to another symbol if and only if their names are spelt the same.

Tagged procedures are procedures with boxes attached, which can be used to create applicable records and other abstractions. This SRFI proposes a variant with the notion of a tagging protocol, analogous to a record type definition, for ensuring encapsulation and security for tagged procedures.

Scheme's exception system is extended so that exception handlers gain access to the delimited continuation representing the rest of the computation of the call of the thunk guarded by the handler. Algebraic effect handlers can be directly expressed in this extended exception system. The system directly implements the shift0/reset0 delimited control operators. It is well known that other delimited control operators like prompt0/control0 or reset/shift are expressible in shift0/reset0 (and vice versa).

We are thrilled to announce a long-awaited goal: Goblins in the browser!!

Hoot can now be used to compile Goblins and Goblins-using applications to WebAssembly! In fact, we even have support for our distributed programming protocol, OCapN working in the browser with Goblins-on-Hoot! Goblins now compiles to Webassembly in Hoot from the same codebase used to run Goblins in Guile's own virtual machine. This is a major step forward toward getting this software in the hands of everyday users. We hope it unlocks a new wave of innovation about what secure collaboration can look like.

As part of this release, we are introducing the websocket netlayer which will allow browser-based applications to easily connect with one another!

Also, a number of performance improvements makes this release the fastest Goblins ever!

Let's get into it!

Seeing is believing: Goblins in the browser IN ACTION!

Long-time readers may remember the goblin-chat demo we've shown off several times before:

Above you can see two Guile goblin-chat programs talking with a Racket based goblin-chat program, demonstrating two completely different language runtimes communicating over OCapN via Goblins. The impressive thing about goblin-chat is that it's only 150 lines of Goblins code to implement both the user code and chatroom code for a peer-to-peer chat program which authenticates messages as they come in!

Cool enough, but didn't we say Goblins works in the browser now? Wouldn't it be cool if you could try two goblin-chat programs communicating in your browser over OCapN... right here, on this page?!

Well, behold!

Peer A

Peer B

Try sending messages between Alice and Bob!

If you don't see anything, note that this demo requires a recent browser supporting all the WebAssembly extensions used by Hoot, including Wasm GC and tail call support. Firefox ought to just work. Chrome needs the enable-experimental-web-platform-features flag enabled in chrome://flags. Safari is not expected to work properly at this time.

This is the VERY SAME 150 line goblin-chat program shown in the previous gif, but compiled to Hoot and running in the browser! (Source code for the running Webassembly code executing above; only the ^chatroom and spawn-user-controller-pair code are responsible for the chat protocol, the rest of the code is to provide a user interface.)

These messages really are being delivered through OCapN too. We have a simplified abstract netlayer which simulates the network which we're using here. However, all the ordinary OCapN protocol operations are occuring with each message transmitted from one user to the other. This isn't only real Goblins in the browser, this is real OCapN in the browser too!

More about Goblins on Hoot

If you've been paying close attention, you may have noticed that this release of Goblins was directly preceded by the Hoot 0.6.0 release. (It's also no coincidence that the Hoot 0.6.0 release art showed the Goblins mascot and the Hoot mascot talking about going on an adventure and this release's release art shows them flying together in the sky!) Hoot 0.6.0 had a large amount of work put into it which is useful far beyond Goblins, but Hoot 0.6.0 and Goblins 0.15.0 were actively developed together. This has been many months of hard work from our team, and we are proud to see it pay off. Goblins in the browser is possible at last, opening the door for a future where Spritely's technology is in the hands of everyone!

Moreover, the foreign function interface feature of Hoot allows developers to access any part of the enormous javascript ecosystem within a Goblins app. That includes reactive frameworks, data processing, and visualization libraries that we think will benefit user experiences.

WebSocket Netlayer

We are also releasing a new netlayer specifically designed for browsers and everyday use: WebSockets!

The WebSocket NetLayer is the glue between Goblins applications written for Guile and Hoot. It is currently the first NetLayer available for both and will allow communication between them!

Having two different users across two different browsers talk to each other does require an intermediary. Thankfully our prelay netlayer works well together with the websockets netlayer, allowing users across browser pages to talk to each other.

However, our prelay netlayer is called "prelay" for a reason: it's the "pre-relay" netlayer. The actual "relay" netlayer we would like to provide for Goblins' OCapN code should be properly end-to-end encrypted. The specification for how to do this still needs to be written and agreed upon by the our team and others in the OCapN group so it can be used widely across OCapN implementations.

Because the prelay is not end-to-end encrypted, prelay providers can surveil and modify communication on the wire. This is a known concern, and we are going to use this current implementation as a stepping stone to derive the correct and fully end-to-end encrypted relay netlayer we still have planned.

Speedup!

This release of Goblins has a major speedup: 1.2-2x performance improvements for all Goblins code! Even more performance improvements are planned for upcoming releases; this is just the beginning!

Your support is appreciated!

Excited about Goblins on Hoot, or any of our other projects? Consider showing your appreciation with a donation! We recently hit our initial fundraising goal of $80,000 USD and announced a stretch goal. For the stretch goal, we will use Hoot to build a learning environment for Goblins and advance Hoot’s live hacking abilities in the process.

Monthly supporters at the silver, gold, and diamond tiers will have their names featured in the credits of Cirkoban, a small web game built with Hoot, as a display of our gratitude.

Thank you to everyone who has supported us so far!

Getting the release

This release also includes a number of other bugfixes and minor features. See the NEWS file for more information!

As usual, if you're using Guix, you can upgrade to 0.15.0 by using:

guix pull
guix install guile-goblins

Otherwise, you can find the tarball on our release page.

As a little bonus, if you like the release artwork, you can get a 4k resolution version to use as a wallpaper if you like! The artwork is made in Blender and its Grease Pencil tool; you can also download the .blend file! (Observant readers of our blog may notice that this release art is a sequel to the Hoot 0.6.0 release art... in the previous artwork, the characters discussed going on an adventure together, and here they are!)

If you're making something with Goblins or want to contribute to Goblins itself, be sure to join our community at community.spritely.institute! Thanks for following along and hope to see you there!

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.

An uninterned symbol is not the same as any other symbol, even one with the same name. These symbols are useful in macro programming and in other situations where guaranteed-unique names are needed. A survey of uninterned and uniquely-named symbols in Scheme is also provided.

We are excited to announce the release of Hoot 0.6.0! Hoot is a Scheme to WebAssembly compiler backend for Guile, as well as a general purpose WebAssembly toolchain. In other words, Scheme in the browser!

But first, a humble ask

If you like what Spritely is doing with Hoot or any of our other projects, please consider showing your appreciation with a donation! We recently hit our initial fundraising goal of $80,000 USD and announced a stretch goal. For the stretch goal, we will use Hoot to build a learning environment for Goblins and advance Hoot’s live hacking abilities in the process.

Monthly supporters at the silver, gold, and diamond tiers will have their names featured in the credits of Cirkoban, a small web game built with Hoot, as a display of our gratitude.

Okay, back to the show!

Highlights

• Much improved weak hashtable support in (hoot hashtables). Weak key hashtables have been reimplemented in Scheme rather than using JavaScript’s WeakMap and are now iterable, as they are in Guile. Weak key hashtables now have company: Weak value and doubly weak hashtables have been added. The Guile legacy hashtable API has likewise been updated to support all forms of weak hashtables. As a bonus, we also have weak vectors thanks to a contribution from Vivianne Langdon.

• Hoot now implements enough of Guile (or provides sufficient alternatives for APIs that are not web compatible) to compile nearly all of the Goblins source code. Stay tuned for another blog post about this progress!

• As of December 9th, 2024, WebKit now ships with Wasm GC and tail calls enabled by default. These were the remaining blocker issues for running Hoot programs on Safari and other WebKit-derived browsers. Previously, Hoot couldn’t run on iOS because Safari is the only browser available on that platform. That said, we think there might be an issue with WebKit’s Wasm implementation. We’d like to gather more data so please let us know how things work for you on WebKit!

Try Hoot

Can I interest you in some eval?

Read on for the full release notes.

New features

• Added (hoot expander) module with a port of Guile’s psyntax. This was a major undertaking by Andy Wingo but we didn’t have time to hook it up to eval for this release. Stay tuned!

• Added (hoot finalization) module.

• Added (hoot primitive-eval) module for evaluating macro-expanded, lowered Tree-IL.

• Added (hoot environments) module.

• Added (hoot modules) module.

• Added (hoot weak-refs) module.

• Added (ice-9 weak-vector) module. Thanks to Vivianne Langdon.

• Reimplemented weak key and added weak value and doubly weak hashtables to (hoot hashtables).

• Added weak hashtable support to legacy Guile hashtable API.

• Added initial implementation of applicable records, undocumented for the moment while we figure out what the public API should be.

• File ports now track their line/column.

• syntax->datum and datum->syntax now work on the Wasm target.

• Added read-syntax.

• Added --user-imports flag to guild compile-wasm for user code that defines Wasm function imports.

• Added support for syntax transformers on the Wasm target.

• Added vector-binary-search to (hoot vectors).

• Added partial, temporary SRFI-14 implementation (character sets).

• Added partial implementation of inet-pton to (guile).

• Switched eval to use modules as representation of environments.

• Added partial implementation of while to (guile).

• Replaced define-inlinable stub with real implementation.

• Added string-rindex, string-trim, string-trim-both, string-trim-right, and string-reverse to (guile).

• capture-stack, stack-height, and print-backtrace are now exported from (hoot error-handling).

• Added any, every1, every, filter-map, and find to temporary SRFI-1 module (eventually you will just import the one from Guile).

• Added &external-error exception type.

• Added const to (guile).

• Added issue-deprecation-warning to (guile).

• Added ceiling-quotient, ceiling-remainder, ceiling/, euclidean-quotient, euclidean-remainder, euclidean/ procedures to (guile).

• Added iota to (guile).

• Added read-string implementation to (ice-9 rdelim).

• Trimmed default set of imports to compiler to just (scheme base) to reduce compilation time.

• Added target-side procedure-property scaffolding.

• Added procedure-name procedure.

• Partially implement R7RS exit procedure (it exits but doesn’t deal with dynamic-winds in effect.)

• map and for-each now support more than two lists, at last.

• Added simple terminal REPL demo to the Git repository.

Bug fixes

• Fixed auxilary modules not being added to *all-instances* table when running Wasm in Hoot’s VM.

• Guile no longer terminates when a Hoot module calls its internal quit function.

• (hoot ports) API is now usable at expansion time.

• Fixed f32.copysign and f64.copysign instructions in (wasm vm).

• Fixed Fix define-exception-type when deriving exception types with fields.

• Fixed cond-expand in define-library forms.

• Fixed parsing of br_on_cast and br_on_cast_fail instructions in (wasm parse).

• string-copy is now usable at expansion time.

• Improved hashtable size lower bound calculation to avoid some bad resizing behavior.

• Fixed legacy Guile hashtable API to return the unspecified value for hash-set!, hash-remove!, and hash-clear!.

• Fixed Wasm generated for s64->f64 primitive.

• Fixed unbounded exception raising loop when exception handler prompt is not on the current dynamic stack. This could occur when an exception handler is established before spawning a fiber, for example.

• Fix compilation of %inline-wasm that returns 0 or 2+ values.

• String comparison procedures are now usable at expansion time.

• Fixed memory leak in library group expansion.

• Fixed stream I/O implementation on Hoot VM.

Browser compatibility

• Compatible with Firefox 121 or later.

• Compatible with Google Chrome 119 or later.

• Compatible with Safari/WebKit 18.2 or later. Finally!

Get Hoot 0.6.0!

Hoot is already available in GNU Guix:

$ guix pull
$ guix install guile-next guile-hoot

(Hoot currently requires a bleeding-edge version of Guile, hence guile-next above.)

Otherwise, Hoot can be built from source via our release tarball. See the Hoot homepage for a download link and GPG signature.

Documentation for Hoot 0.6.0, including build instructions, can be found here.

Hoot at FOSDEM

I (Dave) will be presenting “Minimalist web application deployment with Scheme� on Sunday, February 2nd in the Declarative and Minimalistic Computing devroom. Hoot will be a major focus of the presentation. This talk, like all FOSDEM talks, will be livestreamed and a recording will be available sometime after the conference.

For all the details about Spritely’s presence at FOSDEM, see our recent blog post.

Get in touch!

For bug reports, pull requests, or just to follow along with development, check out the Hoot project on GitLab.

If you build something cool with Hoot, let us know on our community forum!

Thanks to Christine Lemmer-Webber for the lovely Hoot pixel art, and a special thanks to the MetaMask folks for funding this work!

Until next time, happy hooting! 🦉

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 no shortage of topics!

This time we’ve definitely reached the maximum capacity of our venue so please do not just show up if you did not register. Next year we’ll have to find a larger venue!

As for FOSDEM itself, here’s your agenda if you want to hear about Guix and related projects, be it on-line or on-site.

On Saturday, February 1st, in the Open Research track:

• Guix + Software Heritage: Source Code Archiving to the Rescue of Reproducible Deployment, at noon, where Simon Tournier will talk about the latest developments connecting Guix and the Software Heritage archive.

On Sunday, February 2nd, do not miss the amazing Declarative & Minimalistic Computing track! It will feature many Guile- and Guix-adjacent talks, in particular:

• RDE: Tools for managing reproducible development environments, where Nicolas Grave will present how RDE extends Guix and what nifty features it brings;
• The Shepherd: Minimalism in PID 1, where I (Ludovic Courtès) will talk about the recently-released Shepherd 1.0 and why I think its design makes it the coolest init system to hack on;
• Shepherd with Spritely Goblins for Secure System Layer Collaboration, where Juliana Sims of Spritely will present on-going work to port the Shepherd to Goblins in support of distributed and capability-based secure computing.

But really, there’s a lot more to see in this track, starting with talks by our Spritely friends on web development with Guile and Hoot by David Thompson, a presentation of the Goblins distributed computing framework by Jessica Tallon, and one on Spritely’s vision by Christine Lemmer-Webber herself (Spritely will be present in other tracks too, check it out!), as well as a talk by Andy Wingo on what may become Guile’s new garbage collector.

Also on Sunday, February 2nd, jgart (Jorge Gomez) will be presenting a survey of Immutable Linux distributions at the Distributions track which will include RDE.

Good times ahead!

Guix Days graphics are copyright © 2024 Luis Felipe López Acevedo, under CC-BY-SA 4.0, available from Luis’ Guix graphics repository.

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.