As this post might attract Guix users, what's the current state for using hardware?<p>When I tried it a few years ago I ran into a stance on firmware which amounted to it refusing to run unless you used some other Linux branch which was strongly discouraged on somewhat unclear grounds. I think the idea was that closed-source-firmware shalt not be used, and if you absolutely must, there's something over there that you aren't allowed to talk about.<p>Is that approach still the dominant one today? I'd like a scheme userspace but I'm not dealing with having to use unofficial linux forks to have a wifi card work.<p>I see <a href="https://gitlab.com/nonguix/nonguix" rel="nofollow">https://gitlab.com/nonguix/nonguix</a> offers:<p><pre><code> Guix channel for packages that can't be included upstream.
Please do NOT promote or refer to this repository on any
official Guix communication channels.
</code></pre>
but it's hard to determine from the outside whether this is a pragmatic obstacle or not.
I've been using Guix for about the last year and a half at this point (and is coincidentally most of what I post about on this site) and Guix certainly has its ups and downs. Most notably, for me, Guix is leagues slower than Nix it seems, since I use both on my system with Guix as the main distro. Also, just generally less packages and the ones that are present are out of date. However, the architecture of Guix means it can be extremely easy to bump versions of packages as long as dependencies or build options haven't changed too drastically. You will inevitably need to run your own channel on top of your system to actually house these version bumps (before you upstream them!) and packages that you package yourself (again, try to upstream if applicable!). I'd say that about 30-40% of my packages have been modified by me in some way or another, whether it be a complete rewrite of the definition, build option modifications, or just a simple version bump while we wait for it to appear in the upstream repo (more "core" packages, like bluez and those type, get updated less often since that triggers a rebuild of all packages that may depend on it). It definitely isn't for the faint of heart, but I find it rewarding.<p>Some exciting changes are upcoming too, like the addition of being able to boot from UKIs rather than being stuck with GRUB, which probably won't happen for a bit still, however I think this ties into the broader "issue" with Guix.<p>The community is small, which is definitely a result of it (just like Nix) being more complex than the average distro that people do not want to deal with, compounded by the fact that it uses even <i>less</i> standard utilities to build the system (like not using systemd as a service manager in lieu of shepherd). I feel a lot of the pain points that Guix has can be addressed just by having more eyes and hands on the project. If anyone has more specific questions on using Guix I'd be more than happy to give my view.
I love Guix and am migrating from NixOS and Ubuntu+Guix at the moment. I only wish I could run it on Android too.<p>Nix actually has a great purpose-built language and the ecosystem is huge, but something about guix feels nicer and more consistent. Also I like having childhurds and dreaming of the day the GNU OS is finally dominant.
Guix is a great rock steady system (especially if you include the non-guix repo to fetch the proprietary blobs).<p>What sucks are the packages, specifically the package reviews. Submitting an up to date package is blazingly simple.<p>Getting it merged and keeping your source tree and upstream stable requires some effort.
Well... Personally I've explorer Guix System a bit on test hw, coming from NixOS and looking for a more friendly system language, but...<p>- I miss zfs (actually zfs root, with encryption, OOB on NixOS)<p>- I miss few packages (i.e. RustDesk)<p>Observing that while Scheme is far more digestible the Guix System config it's not designed in so digestible ways. My take it's that they are too HPC/academic centered to be a generic desktop distro, which is unfortunate because as Microsoft tell the world back then conquering desktop means conquering people, also people who manage server, HPC clusters etc. No one since decades can survive without being on desktop...
I was curious if Guix was less militant about putting its store in "/" than its Nix friend and while surfing around the Guix wiki I found a link to an external wiki which discussed GuixSD (System Distribution) on WSL <a href="https://github.com/SystemCrafters/wiki-site/blob/64fc7f0aaecd08a5f4c6b3bc747c51ff0a87b407/content/guix/wsl.org">https://github.com/SystemCrafters/wiki-site/blob/64fc7f0aaec...</a> mentioning a lot of /var/guix so I have high hopes<p>However, a thread from a few years ago seems to imply that I have the wrong mental model of GuixSD and it's not "homebrew but in Guile" rather it's "GNU software all the way down" and since glibc doesn't build on macOS (according to that thread), Nix allegedly sidesteps this by making some of its packages impure and linking to libSystem <a href="https://guix-devel.gnu.narkive.com/BnGNBXUh/guix-on-macos#post18" rel="nofollow">https://guix-devel.gnu.narkive.com/BnGNBXUh/guix-on-macos#po...</a><p>I was happy to see that folks in that thread got GuixSD working for docker images, so that can still be a win, but my current heartburn is not building docker images so I am not the target audience for that
I tried to install it recently but the latest release of the disk image was from over 2 years ago, which has a problem that if the network craps out while you’re installing, the whole installation fails. They added retry logic but the released disk image doesn’t contain it.<p>Then I tried to build it from source, but there were a few dozen issues with po4a, the translations system. Every GNU project is cursed, I swear.