Attempting to Use GNU Guix (2019) | Hacker News Reader

Attempting to Use GNU Guix (2019)

amodernist.com

61 pointsluu25 comments

As this post might attract Guix users, what's the current state for using hardware?

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.

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.

I see https://gitlab.com/nonguix/nonguix offers:

  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.

but it's hard to determine from the outside whether this is a pragmatic obstacle or not.

I'm not sure what you mean by "pragmatic obstacle" but it ensures Guix will be super duper niche forever, which I don't think the developers mind. For regular users it "doesn't matter" in the sense that it's trivial to bypass, but it limits adoption which definitely affects quality.

> definitely affects quality.

not always in a negative way.

I'm running Guix on my personal desktop, my personal server, and my work laptop. I'm using the nonguix channel on all three of them, it has been perfectly fine for me.

My servers NICs actually are not even supported by the Linux-libre kernel. I got around that by building a custom installer iso with the mainline Linux kernel. That probably sounds awful, but I have never built a bootable iso for any other distro before, and it was a breeze for me.

https://www.pantherx.org/ might be what you want.

It adds non-free softwares, GUI package installer, and GUI config to gnu guix.

pantherx also allows you to pay for support for however many people you want.

Thanks for sharing... but why? I don't think I expressed wanting something other than GNU Guix.

I think what you're describing is still the case, but the way you described it isn't quite accuratie. The default kernel used is linux-libre. If you need more hardware support and binary blobs, you use regular linux, the same one basically all the other distros use. You're not using an unofficial fork of anything (or some might argue the default is more of an unofficial fork). You do have to go out of your way somewhat to get the standard linux instead of linux-libre, and I don't believe you can just load your required firmware into linux-libre instead. It's one of the FSF-approved distros so there are indeed strict guidelines (FSDG) on proprietary software, often to the point that it puts people off, and the official IRC and probably the mailing list as well don't talk about the non-free bits, yes. However if you join the #nonguix IRC channel or use the guix channel (like a repo or PPA) of the same name you'll find many of the same faces from the core community there. It's just a bit hush-hush due to the guidelines. Remember Guix System is a step more extreme than Debian, so even something like Debian's official non-free repo is not allowed.

Personally I have run Guix System on a ThinkPad X220T and ThinkPad T440p which are old enough to not really need any blobs aside from the ones for WiFi, and you can remove or replace the card in them. I believe any machine newer than this is going to need blobs for the integrated graphics or other things. I have been debating whether I'd run Guix System on my next (newer) machine and as I've never gotten too deep into the weeds understanding Guix stuff despite using it for years, I may opt for a different distro, but I would say if you really want to try it, it's probably not too bad to get up and running with a regular non-libre Linux on Guix System.

That is useful information, thank you.

If running upstream Linux with guix userspace is a somewhat well established path that solves the firmware problem. I'm a little unclear on what the various distribution patches to the kernel usually achieve but I'm hopeful that moving from Debian's kernel package to upstream would work fine in practice.

I should give it a try. Thanks

Look into PantherX linux. https://www.pantherx.org/

It is based on gnu guix. It comes with non-free softwares by default.

It also has GUI package installer and some form of GUI config.

If you want support, you can pay for that, too.

I think pantherx can be easier than ubuntu or fedora due to GUI-centric approach and reproducibility.

I am on a team that provides commercial support for our Linux based user endpoints. We do not deploy endpoints with WiFi cards that require closed-source firmware.

  https://www.thinkpenguin.com/gnu-linux/wireless-n-m2-ngff-card-v2-tpe-m2ncrd2

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.

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.

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

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

What sucks are the packages, specifically the package reviews. Submitting an up to date package is blazingly simple.

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

- I miss zfs (actually zfs root, with encryption, OOB on NixOS)

- I miss few packages (i.e. RustDesk)

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

You can have btrfs root with encryption OotB, however.

Unfortunately it can't be compared to zfs...

Zfs is the sole spread and battle tested moderately modern storage we have in the world, the other but constrained by the OS it support is Hammer. btrfs, lvm, mdraid, luks, stratis are monsters designed by people who do not really understand operation.

Actually they are one of the reasons why GNU/Linux is in a so dire state respect of decade old unices.

LUKS is okay in compariton to GELI. btrfs doesn't have RAID10. btrfs RAID10 is actually RAID1 with some performance optimizations. zfs makes lvm obsolete. mdraid is inferior to zfs.

I wouldn't say they are monsters. But, they are just not good enough.

Because zfs native encryption is still immature for send/receive, there's still some value in LUKS, and zfs native encryption doesn't yet support multiple key slots because it is essentially unmaintained.

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 https://github.com/SystemCrafters/wiki-site/blob/64fc7f0aaec... mentioning a lot of /var/guix so I have high hopes

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 https://guix-devel.gnu.narkive.com/BnGNBXUh/guix-on-macos#po...

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

So the store itself is still located in '/', it's in '/gnu/store'. However, the location can be changed when building guix (you would need to compile it yourself) with the ./configure options --with-store-dir={PATH}. (The /var/guix path you referred to is the state path, where guix stores accounting databases and stuff for it to actually track the store)

EDIT: I forgot to mention, do not do this. If you want the store in a different location, set up a bind mount. Guix makes assumptions that would make it so you no longer could use substitutes (binary downloads of packages), so keep that in mind.[1]

[1]: https://lists.gnu.org/archive/html/help-guix/2022-02/msg0016...

This article (2019) begins with a link to a more recent one (2021). Any reason to post the earlier one specifically?

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.

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.

There's an in-between option, the "latest" image.

https://guix.gnu.org/en/download/latest/

Last update to this site appears to be circa 2019 :/

It says: "Update (01Nov21)"[1] on top, and I presume it is 2021-11-01. Still old though.

[1] https://amodernist.com/texts/guix-again.html

It does, you are right. Apparently I am going blind :(

Reply on news.ycombinator.com