I really like the concepts brought by Nix. Guix is also a nice derivative, which uses Scheme as a DSL to describe packages and its own Scheme-implemented init system.
Explicit package definitions bring 2 great advantages. First, one can easily modify them programatically (to e.g. enable or disable options) and build the resulting custom package from source. Like Gentoo on steroids. Second, one can build packages from source and compare them bitwise with binaries offered by mirrors. This is incredibly important to avoid malicious attacks. See guix challenge command.
I dislike a bit that some Nix packages are very non-minimal, built with every possible optional dependency baked in. I consider this a security threat. Not so long ago, Firefox came with Flash by default. Getting seemingly innocent CLI packages like Mutt ended up pulling a lot of stuff like Python I don't need via GPG. I would love to have something more minimal, like what Arch gives.
We agree that package configuration isn't very discoverable — for users or our tools. Once we fix that it could be possible to add a blanket config to default to a minimal cfg instead.
I'd guess the default configurations tend to err on the side of completeness to get the most bang for buck from the cached builds.
Yep. My litmus test here would be, can I set up a whole minimal desktop (xmonad, emacs, firefox, mutt, git, rsync, openssh, gnupg...) without pulling any extraneous dependencies? This is possible on most major Linux distributions, but not in NixOS.
Otherwise a fantastic piece of work. I wish it plenty of success. It's full of simple and great ideas.
I've been using nixpkgs for almost a year on an age-old linux distro controlled by my company. It replaced gentoo-prefix, which was error prone and hated RH based distros.
Nixpkgs works really well and the separated environment makes maintenance easier to control. It occasionally breaks upgrade of some packages, but it never affects the working environment.
It seems with 16.03 they are bold enough to go gcc 5.3. It would be interesting to test out my toolchains against the gcc 5 series, but I still don't see gcc 5 being the default on the Nixpkgs. I guess I'll wait a bit longer to waste my time on gcc 5.
Does NixOS have a good security update story yet? Last time I looked, security updates in widely-used libraries like glibc could get bogged down in huge rebuilds because of the way dependencies are specified/resolved. There was some kind of hack to bypass this, but I think it required manual config changes for each update. The wiki seems to have evaporated, so I'm not sure what's current.
Disclaimer: I'm a NixOS user who is interested in switching to Guix but have not actually tried it yet.
Both package managers (Nix and Guix) and the distributions (NixOS and GuixSD) are very young, so expect some missing packages and some rough edges. That said, Guix & co are newer than Nix & co, so expect more missing packages and roughness with Guix. Also, GuixSD being a GNU project, you'll have a harder time finding proprietary stuff packaged up.
Guix is entirely scripted in Guile Scheme, which is a strong point in my mind. And from what I understand, you can drive your whole operating system from emacs, which appeals to me as someone who lives in and loves emacs. It also has a strong emphasis on user Freedom.
But you can use both! This is part of what's so cool about functional systems. I personally started with Nix on Ubuntu, graduated NixOS, and am now starting to look into Guix. And eventually, GuixSD.
Guix uses Guile instead of the nix expression language for defining packages.
Honestly, I don't understand that choice. The main issue with nix is that is a lazy functional language and the learning curve for that is a barrier to adoption. But... scheme is not a solution to that problem. It looks to me like GuixSD the successor to the Hurd as the favoured GNU OS. It's the official GNU distribution of Linux and it's choices are more political/ideological than practical.
So you're excited to use an OS that's FSF-endorsed from top to bottom, choose Guix. If you're more interested in realizing the benefits of functional package management, choose Nix.
So, if you're more interested in functional package management
> Guix uses Guile instead of the nix expression language for defining packages.
> Honestly, I don't understand that choice. [...]
Then maybe you should not have written a whole paragraph speculating about political reasons.
Pretty much everything in Guix is written in Guile. The only exception is the daemon. The build derivations themselves are in Guile again. Having almost everything in Guile is great as it allows us to use different stages for code by quoting S-expressions. It gives programmatic access to package definitions and turns Guix into a library. This has proven invaluable as it made it quite simple to build a package manager web interface, recursive importers that take into account what packages have already been defined, package expression updaters, an Emacs interface using Geiser, a graphing tool, etc.
The values we hold also have an impact on how we approach functional package management. I'm working on reproducible Java, for example, building everything from source rather than accepting pre-packaged jars. This is a very slow process, but we are able to draw the complete dependency graph without having to accept binary blobs (e.g. for maven dependencies).
GuixSD is not the official GNU distribution if Linux, it's just part of the GNU project (Like Emacs isn't the official GNU text editor). And Scheme as the language for defining packages and even the system services is very powerfull, because you are able to do almost everything you want to.
From what I understand they will make a DSL when the time comes and they have realised what they need. Scheme is a really nice language, and the barrier should be almost non-existant if you know how to balance parens.
A DSL already exists. It's just embedded in Scheme, not an external DSL. Here's a package definition. You can see that it mixes regular Scheme (`string-append`) with new package-specific syntax (`version`, `source`, etc).
(define-public babl
(package
(name "babl")
(version "0.1.10")
(source (origin
(method url-fetch)
(uri (list (string-append "http://ftp.gtk.org/pub/babl/0.1/babl-"
version ".tar.bz2")
(string-append "ftp://ftp.gtk.org/pub/babl/0.1/babl-"
version ".tar.bz2")))
(sha256
(base32
"1x2mb7zfbvk9d0a7h5cpdff9hhjsadxvqml2jay2bpf7x9nc6gwl"))))
(build-system gnu-build-system)
(home-page "http://gegl.org/babl/")
(synopsis "Image pixel format conversion library")
(description
"Babl is a dynamic, any to any, pixel format translation library.
It allows converting between different methods of storing pixels known as
pixel formats that have with different bitdepths and other data
representations, color models and component permutations.
A vocabulary to formulate new pixel formats from existing primitives is
provided as well as the framework to add new color models and data types.")
(license license:lgpl3+)))
Susan Potter - "From Zero To Production" : https://www.youtube.com/watch?v=5vVZzu6HMaQ
Eric Merritt -"Managing And Releasing Erlang Systems In The Cloud With A Fully Declarative Package Manager" : https://www.youtube.com/watch?v=xRSFJH3Lw6I