Hacker News Reader

Comment by rank0 | Hacker News Reader

Can anyone explain to me the appeal of guix over nix? Is the learning curve any easier? I really badly wanted to like nix...but its just so strange and unconventional.

Whenever I need a disposable environment I reach for lxc/lxd.

View on HN

From what I can tell (I've only used NixOS/Nix), Guix has considerably more thought put into the UX: Nix is currently undergoing a transition to a newer CLI; Nix's nomenclature is confusing; Guix has much better documentation; Guix has its equivalent of Nix's home-manager built-in.

There is still some division in the Nix ecosystem between the pre-flake and the experimental post-flake way of doing things.

Guix uses an established programming language for configuration, which some might find attractive (I actually quite like Nixlang after getting used to it).

Guix makes installing non-free software a hassle (you have to include community sources). Nixpkgs doesn't impose this restriction, though you still have to explicitly allow the install of non-free packages when running Nix.

Overall, Guix seems like the more polished product, though NixOS/Nix is similar in functionality and has a larger collection of packages and more traction in general.

> Overall, Guix seems like the more polished product

Possibly when comparing the Guix vs. Nix package managers, but for Linux distributions GuixSD ("Guix System" now) is very far behind NixOS in this regard. I've tried to install GuixSD on different hardware several times over the past couple years, and failed every time, between a lack of drivers and unpolished or buggy installer. Last time the installer wiped out my partition table without prompting when I went in to manually partition (to set up dual boot).

NixOS on the other hand has always been flawless to install, and now there's even a modern GUI installer.

I like Guix better in theory, but Nix wins in practicality.

Well the thing with the "Guix System" is that is uses the LinuxLibre kernel. So if the hardware you have requires proprietary bits or driver, it just isn't included. That isn't to defend Guix in anyway, but the problem doesn't seem to be Guix when you read the fine print of the distro, the problem is your hardware.

So, do I agree necessarily agree with GNU's official distributions having this philosophy? Not really. Firmware and drivers is probably the one area I think the GNU people should finally throw in the towel. It keeps people out of running it, or doing so with relative ease. And the battle is for the most part lost on that end. But they do essentially tell you that it is likely it won't work across a lot of hardware out of the box.

But here is the download page [0] https://guix.gnu.org/en/download/ That mentions the Libre kernel with link to information about the Libre kernel [1] https://www.fsfla.org/ikiwiki/selibre/linux-libre/ With the following information:

"Linux, the kernel developed and distributed by Linus Torvalds et al, contains non-Free Software, i.e., software that does not respect your essential freedoms, and it induces you to install additional non-Free Software that it doesn't contain. Even after allegedly moving all firmware to a separate project as of release 4.14, Linux so-called "sources" published by Mr Torvalds still contain non-Free firmware disguised as source code. Stux, a cute penguin. Few realize he's not Free

GNU Linux-libre is a project to maintain and publish 100% Free distributions of Linux, suitable for use in Free System Distributions, removing software that is included without source code, with obfuscated or obscured source code, under non-Free Software licenses, that do not permit you to change the software so that it does what you wish, and that induces or requires you to install additional pieces of non-Free Software."

I think that allow unfree in nix is practically the same as adding nonguix repo to your channels. Both are essentially one line of config in some file.

(I am former nixos user but now on guix)

Guix is strange and unconventional in the same fundamental way as Nix, namely that each package is installed to its own, immutable, quasi-content-addressed prefix. This is because that design decision is what gives both package managers their superpowers.

If you are already a Scheme user, you may find Guix more accessible for you. If you are not a C++ programmer, you may find hacking on the package manager itself easier with Guix.

In terms of the CLI interface, Guix really shines here. Guix also has a more centralized approach to documentation, which you may find helpful.

Beyond the surface-level language differences, Guix has gone with different abstractions than Nix in some key areas, and has some features that Nix lacks. One big one is that GuixSD uses a different model for defining the options that can be used to configure the system. Guix's approach¹ is more explicit, and features some provenance tracking for configured options— it can draw a graph for you showing where each setting on your system came from.

Guix also takes a different approach to pinning package versions and defining repositories of source packages, and its conventions for doing those things are more settled than their equivalents and alternatives in the Nix world.

Guix also supports a feature called 'grafts'² that allows you to avoid rebuilding the world in case of things like mission-critical security updates to glibc. This is a really cool and useful feature!

I'm sure there are other things that more serious Guix users can better highlight than this dilettante. :)

The Guix blog is really excellent! I strongly recommend it for getting a sense of what problems Guix tries to solve and how it sometimes approaches them differently than Nix does.

1: https://guix.gnu.org/manual/en/html_node/Defining-Services.h...

2: https://guix.gnu.org/blog/2020/grafts-continued/

I tried and bounced off Nix on other systems, and I'm now running nixOS on my personal laptop (which is a secondary device).

I think there's absolutely room to solve the same set of problems better than Nix does:

1. The number 1 problem for me has been documentation of nixpkgs. Nix lang is a bit funky but even if I was writing python the problem is that you're writing code to assign magic objects to magic variables and the only way to find the right ones is to read the nixpkgs source (and given the size of all-packages.nix and the limit of github's web viewer, maintain a local checkout).

2. Second place goes to the flake/non-flake divide where the nix community generally implies flakes are better but apart from the nix cli detailed docs, most things refuse to acknowledge its existence in the official docs.

3. Portability between macOS and Linux, where flakes actually make the situation worse as the root config is now system specific.

4. Tools like flakes, niv, the suggested way to write a shell.nix all want you to handle full commit hashes directly which is kinda unergonomic.

None of these are inherent to the problem space. If I was to keep writing the list, maybe around 9 and 10 are the things around nixlang being a funky language or /nix directory that the "you just need to understand functional languages/content addressable stores" discussion seems to think are the top ones.

Agreed on points 1 and 2. I think 3 is basically solvable for Nix, and it's easy to paper over with a Nix library for now.

Re: 4, Flakes do let you define inputs in terms of Git tags and branches and then have the computer resolve those to commit hashes for you, which is good.

Overall, I agree that it's not fair to think of package managers that work in the same basic paradigm as Nix as mere also-rans or clones. There's a lot of room to meaningfully experiment in the space and Guix's developers have proven thoughtful about where they want to differ in technical and ergonomic matters.

One of my personal pet peeves are that Guix does not support Apple, while Nix does.

Haven't tried guix yet, and haven't used nix in years, but if what you struggled with is the language, guix might be less strange and more conventional since it uses Scheme as the language. It uses strict evaluation like most languages and there's probably more documentation about it.

In addition to the other answers here: the Guix repositories only accept Free Software, even excluding things like Firefox, and intentionally make it somewhat difficult to install non-Free-Software (as opposed to Nix, where installing things like Firefox is relatively easy[1]). This may appeal to some people.

[1] https://nixos.wiki/wiki/Firefox

Reminds me of the VHS vs Betamax war, where VHS won because Betamax (Sony) didn't allow adult videos (at least, so the legend goes).

Guix does not make non-free software "intentionally more difficult", it just excludes it from the main repository. There is a nonfree repo that you can add to your guix channels.

the non free repo explicitly asks you not to talk about it

https://gitlab.com/nonguix/nonguix

looks intentional to me

Well, all it says that you shouldn't promote it on the "official channels" (i.e. the mailing list and the #guix libera.chat channel). Guix, the package manager itself, does not make installing non-free packages any more difficult than free packages. I suppose it could be said that Guix (the project) makes finding non-free packages harder, although anecdotally I will say that nonguix is the first thing I've heard about guix, since it seems to be the most controversial part of it.

While it's technically correct to say that the software itself does not make it particularly difficult to install non-free packages, it also doesn't come with non-free repos when you set it up, and the documentation and official support channels intentionally lack information on non-free repos. As default settings and documentation are a critical part of a software project, it still has the end result of making it harder (much harder for non-technically-inclined users) to do so.

Non-free software is just off-topic in official channels, there is no need to interpret malicious intent into it. It is no more difficult to enable nonguix than it is to enable any other repository.

I don't think anyone was implying malice, just that there was intent. Nothing wrong with having principles.

I'm sorry, but if ask how to install Firefox and no one tells me in official channel or, worse, suggests alternative browser/fork of firefox. That's a pretty intentional way of making things hard.

I'm sure someone will tell you, perhaps privately. Everyone is quite nice there and no one is going around trying to shame people or kick them out.

I think the main difference is that Guix will only support open software officially, whereas Nix will also happily allow proprietary stuff, like nVidia drivers.

See e.g.:

https://gitlab.com/nonguix/nonguix

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

Far from the 'main difference' -- if there was a project that just forked Nix and made that change, you could say that about it, but not about Guix, which has tons of work-hours invested and pretty much none of those work hours have to do with that.

True but that's from mostly a technical perspective. It is also (more?) important to know how a community thinks.

I think the main difference is that Guix uses an actual language and writing things for it seems pretty reasonable, while Nix language is frustrating to work with and look at. There are probably hundreds of functions in nixpkgs that would make your life easy, but only 3.5 people know about them or how to use them.

guix is written in basically scheme. Nix is some weird stringly typed DSL thing.

What in particular did you find strange and unconventional?

For me it was the core premise that is both the blessing and the curse. That it is only possible to install software by first packaging it.

That's because the basic idea is immutability and that doesn't go well with OSes designed around mutability.

Nix/Guix are basically the "glue" that connects two worlds.

Reply on news.ycombinator.com