Guix explicitly rejects non-free software.

Unfortunately, that isn't workable for most of us.

Note you can use any Nix package in Guix...

Ouch. Is this at a legal or community level?

Community.

There may even be community-based sources for non-free packages, but they are explicitly ignored by the Guix project.

Anybody can run guix publish however and self publish their own non-free substitutes if they wanted, plus there's all the existing non-free substitute servers around, and you can try your luck with guix import from nixpkgs. The community won't help anybody if they ask for help with non-free software though.

I haven't missed any non-free packages since switching to Guix surprisingly, I always seem to find a free alternative though my daily req are pretty basic.

> plus there's all the existing non-free substitute servers around

Where?

> The community won't help anybody if they ask for help with non-free software though.

This, specifically, is where Nix has the advantage.

Not the grandparent, but from what i can see, grandparent compares Nix with traditional package managers like dpkg or RPM, rather than Guix.

I cannot answer your question, but I think Nix has (for some reason) a lot more publicity than Guix at the moment.

Guix is derived from Nix, so that might be why.

If by "derived" you mean that it is another implementation of functional package management, then you are right.

But if "derived" implies that Guix is a fork, then you are mistaken.

Guix is not a fork of Nix.

Guix is built on top of the nix daemon, so while it's not strictly a fork, derived seems fair.

> some rando's

This is a GNU-approved fork

> weakly motivated

Has lots of strong motivation, like a stricter stance on non-free software, the usage of a "real", more expressive language (Guile) instead of a niche, poorly undocumented DSL (Nix), use of GNU Shepherd instead of SystemD for the init system, among other

> niche NIH rehash

It shares most of the codebase with Nix, so to say it's NIH is missing the point. Nix improvements are shared with Guix, and Guix improvements are shared with Nix

> unless you're already victim to lisp-induced stockholm syndrome

Different lisp offer different syntaxes, features, and use-cases. That you cannot see it makes me think you didn't try too much, and are probably just trolling.

Guix doesn't really share any of the codebase with Nix. Guix uses a modified version of the Nix daemon, but that is a tiny fraction of the total source code. Guix is an alternative implementation of the packaging model pioneered by Nix, plus additional features not found in Nix.

> It shares most of the codebase with Nix, so to say it's NIH is missing the point. Nix improvements are shared with Guix, and Guix improvements are shared with Nix.

In Guix, the only code from Nix is the Nix daemon. There is not really much code going back and forth, mostly just bug fixes.

I'm curious if you'd like to elaborate on what makes Guile more expressive than Nix for writing package definitions.

I’d just like to interject for a moment. What you’re refering to as Guix, is in fact, Nix/Guile, or as I’ve recently taken to calling it, Nix plus Guile.