Practical questions: I’d love to try this out for my personal desktop/laptop, but I’ve been really pampered by the Arch repositories. What is the extent of completeness in supporting practically important daily use software? Are there parallel repositories supporting the non-libre packages that one might occasionally need? Is there an easy way to construct Guix recipes from another Linux system — say Debian, or Fedora or Arch?
The main guix "channel" (that's what it's called) contains more than 17.000 packages. Some software is hard to package, but I can't think of anything that's missing from the repository. You can have a look at the list of packages at https://guix.gnu.org/en/packages/ (note that firefox for instance is called icecat and based on the ESR version).
There are no other official channels, but a bunch of people have their own channels with additional packages. The most popular is probably nonguix (https://gitlab.com/nonguix/nonguix) which provides some popular nonfree packages.
Creating a recipe is generally easy (it's just a bunch of metadata) and even easier if it's supported by one of the importers (python, perl, emacs, ...). You can use guix on any other Linux system if you're not ready to install the complete system. The only difference is that your system is not managed by guix, and you can't run "guix system reconfigure", but the experience is otherwise the same. Make sure to follow the additional steps from the manual.
I use Guix as my daily driver and do occassionally come across software that hasn't been packaged. The big ones for my work that immediately come to mind are:
- slack
- kubectl
- terraform
- azure-cli
- cscope
There have been a several other missing tools for personal use that I just ended up packaging and sharing upstream. For the ones listed above, though, I just haven't gotten around to it, so I let Nix fill in the gap, hehe. FWIW, Guix already has Nix packaged and available as a service, so having parallel stores is really straightforward.
Icecat is a fork of Firefox to rid it of proprietary services and DRM. It's got a different name because Mozilla forbids (or used to forbid) redistribution with patches.
Debian also used to do this until Mozilla changed their tune on a few things. Debian's version and Icecat both used to be named IceWeasel, though, making fun of Mozilla.
Guix is pretty cool, and I'll probably switch to it one day.
But as of now, it lacks some basic stuff like KDE suit. The nonguix channel AFAIK doesn't have binary builds so you'll be building quite a few packages yourself. Using nonguix also means you can't expect support in official support channels. Just something to know before you start.
Using nonguix also means you can't expect support in official support channels. Just something to know before you start.
If this is true, it is a deal breaker for me. I try to buy open source hardware when I can, but even systems like the Pinebook Pro will have their functionality significantly limited by the absence of the linux-firmware package. It is a simple fact that most common WiFi chipset require non-free firmware.
That's not true. You get support for the part of the guix system that is free software from guix, and support for what comes from nonguix, from nonguix. So if you have issues with the proprietary driver, you talk about it on #nonguix, but if you have troubles with guix, you talk about it on official channels like #guix.
Thank you for this! Missing KDE is a dealbreaker for primary system, but I can start using nonguix for older systems now.
Edit: I'm not sure if I'm reading this right, but the job says 0 builds (eg. https://mirror.brielmaier.net/eval/97958?status=succeeded&pa...). I'm not familiar with how guix works, but where can I see list of actual built derivations for a particular job?
It depends on your priorities. If you care about package availability and the broader ecosystem, Nix would be a better choice[1]. Nix has a larger community size, lower barrier for participation, and is more forgiving regarding non-free software. Its package count likely exceeds the AUR too, if you exclude duplicates.
Guix, on the other hand, is better suited for the more adventurous folks. It's built on Scheme, which many find appealing.
Both Nix and Guix can be installed on other Linux distros. Both are now available in the official Debian repository. Additionally, Nix supports macOS quite well. It even supports FreeBSD and Cygwin too, although it's probably not as mature.
Guix combines the specification language, API, and base distribution into a single monorepo. This makes it a bit like the linux kernel in terms of scope and ability to adapt and update itself without external dependencies. My understanding was that this wasn't quite the same for Nix, and that's led to some trickiness in the way that the project evolves. What do you think?
As a user who occasionally makes my own packages for software deployment, I can learn very quickly how to write a package description by grepping through the guix main repo and looking at how other packages are written. That's probably similar for Nix, but it's something that I found refreshingly clean and flat in guix and I'm frankly hooked.
Guix and guile are in separate repositories just like nixpkgs and nix.. It wouldn't be nice to mix these. The difference is really about the amount of coevolving the language can make to the specific tasks.
Thanks; this sounds interesting. Could you please link to any documentation or HOWTO?
Considering I have all my daily use software already installed in Arch, if I attempted to re-install them with Guix in parallel, would that lead to namespace collisions? (i.e. would I have to uninstall currently installed software before I re-install them with Guix?)
> if I attempted to re-install software with Guix in parallel, would that lead to namespace collisions?
It shouldn't. That's one thing Guix (and Nix) excel at: packages only refer to specific versions of their inputs, so you can even install multiple versions of the same package at once if you want.
In terms of Guix shadowing packages installed by Arch, you can put $HOME/.guix-profile either at the front or the end of your $PATH depending on whether you want to prioritize Guix or Arch packages. When I was getting my feet wet with Guix, I ran Guix on top of Gentoo (doing basically what you suggested, gradually shadowing Gentoo packages with Guix ones) for a few months without any significant problems.
Could I ask you to compare guix and portage? I'm not an expert in either, but it looks like guix provides very similar source builds with easier binary caching/substitution.
I can compare. Ebuilds are nothing in comparison, and guix is much more flexible. What portage has over guix is the wealth of premade packages (for now)
Namespacing in this case is just adding the guix bin directory to your PATH; put it in front of your existing path to default to guix programs, or at the end to default to Arch. You can also just use an ad-hoc environment (https://guix.gnu.org/manual/en/html_node/Invoking-guix-envir...) to call guix packages at will without really installing them.
