NixOS 16.03 Released
nixos.org
nixos.org
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
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.
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.
Otherwise a fantastic piece of work. I wish it plenty of success. It's full of simple and great ideas.
You may also be interested in https://github.com/NixOS/nixpkgs/pull/7701 which cuts down in unintentional dependencies.
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.
What makes them different / how can I choose between them? (or should I consider using them both? where is each better?)
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.
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
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).
(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+)))- gcc5 definition: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
- Old cc wrapper with a custom libc option https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/...
- libc in the GCC package itself: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
The whole system is very modular and customizable. But yeah, very hackish and undocumented.