I wonder if the Nix approach would be more popular if a schism (between Nix and Guix) hadn't developed so early. When you talk about Nix and Guix, a novice's natural first question is, "Which one do I use?"
I wouldn't call it a schism; this sounds much too negative. They are different implementations of the same idea. Nix uses an external DSL, Guix an embedded DSL (using Guile Scheme for everything). The projects are not competing against one another. Problems that are solved to make software packageable in Nix benefit Guix and vice versa.
As a Schemer and GNU person it was easy for me to pick Guix. I've been contributing to Guix for a few years now. I find the tooling of Guix to be more accessible and more hackable.
In my experience when packaging Java for Guix it seems to me that Guix is a little more principled, where Nix would more readily accept binaries for bootstrapping (e.g. prebuilt jars).
Considering how different functional package management is compared to the alternatives I think that novices could pick one or the other; once they are used to functional package management they can better make a decision to switch to another implementation.
For bioinformatics software, though, Guix is far ahead. It's used at our bioinfo institute and in big projects like GeneNetwork.
The thing is, they are competing for package maintainers and users. A Nix package can't be natively used by Guix, and vice-versa, so a package have to be written for both.
Heh, my thinking basically. As Guix is a GNU project, it adheres to FSF definitions of freedom. That means there will be no proprietary drivers or similar in the official repositories.
This is true. We offer deblobbed Linux (linux-libre) by default.
However, it is very simple to customise packages, including the kernel package, e.g. to apply patches, use different sources, or to exercise your right to disagree with the Linux libre upstream on what blobs should be deleted from the kernel.
That said, I consider freedom by default a feature and it works very well on most of the hardware I use (an exception is an on-board Radeon graphics chip in a desktop machine I don't use much).
Creating package variants is almost trivial; it's certainly no harder than, say, customising Emacs. Guix blurs the lines between user and maintainer, so using custom package definitions is a supported use-case. At work even our scientist users create custom packages in case they are not available in Guix upstream yet.
Sounds very similar to my experience with Gobolinux. If the source is packaged sanely (proper support for --prefix or equivalent) a user can roll up a recipe ready for Compile with a single command and a url to the source needed.
Some software is promoted on its merits and some software exists just "because it's GNU" (e.g. Hurd, Guile, Guix, gNewSense, GnuTLS, Shishi, GNUstep, Gnash, etc.). It's pretty safe to ignore the latter kind.
GnuTLS is actually a good thing. OpenSSL has become a monoculture and there's a lot of good reasons to not use it (in addition, the license isn't GPL-compatible so it's a pain to link against in projects too).
Gnash, really? What other open alternative to Adobe's player would you recommend? For example, Gnash is the only way to get Flash support on the Raspberry Pi - is that not valuable?
As someone who works on Guile and Guix in good part because of their technical aspects and friendly community, this comes off as pretty insulting and ignorant.
