I am not sure if these are the projects that are going to drive the innovation, if they are only showing the way for the 2nd-generation functional package managers, or if this will just remain a niche forever.
Nix does not use versions for packages, instead relying on channels and pinning, which can be confusing at best.
There is a manual, but not a good wiki. While you can learn to read the syntax, there isn't any good introduction to write it. Nix derivations are very unique, and difficult to approach without examples and guidance.
Both Nix & Guix are past proof-of-concept stage. In particular, I've found Guix very elegant, simple and useful.
It's an attempt to bring the functional system paradigm to Arch linux, giving you the "my system is a function of my configuration" approach combined with not having to relearn how to administer a linux system like GuixSD and NixOS require.
What is the benefit of directly using Scheme for the package declarations over using NixOS's DSL? Specifically, what technical features does Scheme make possible which are not possible in NixOS?
Integration of all stages. We use the same language on the build side as on the host side; the same language to execute builds as to define packages. In Guix there is no mix of languages, so we don't need to glue strings together produce build-side shell scripts. Instead we can use higher-level S-expressions and code staging.
For more on code staging see this paper:
https://hal.inria.fr/hal-01580582/en
This allows for code reuse, even across projects, e.g. the GNU Shepherd init system can take the container code from Guix and run services in isolated environments with very little effort. See this blog post for details: https://www.gnu.org/software/guix/blog/2017/running-system-services-in-containers/
FWIW, Guix implements a DSL that's embedded in Scheme (it's not just "raw" Scheme). The advantage of embedding is tooling: you can work with package definitions right there in the REPL / with Emacs+Geiser; you can use the Guile debugger features.Another result is that all these package definitions form a lazy graph of live Scheme values. In Nix you have a large hash table of identifiers to functions. Think code vs data. In Guix the primary data structure is an emergent lazy graph; it is not merely an inert description of such a graph. Each package definition is just another Scheme value.
Nix's Firefox: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...
Guix IceCat: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages...
The site should be more direct about whether or not it is Linux.
I don't have time to wade through reams of words to work out what something is. Just tell me.
It's not clear at all why this matters or is better than other operating systems. If this is a competitor to Linux then the first thing they need to address is "why should you care?", if it is Linux, then the first thing it should adress is "Why you should use this over other distros"
I'm guessing if the word "Hurd" doesn't appear anywhere on the page, it's still Linux.
"GuixSD is a distribution of the GNU operating system centered on the GNU Guix package manager. It uses the Linux-libre kernel, and support for the Hurd is being worked on."