The Nix project – Atomic upgrades, rollbacks and multi-user package management
nixos.org
nixos.org
One issue is that at present, the system is very much rolling release with snapshots every 6 months called "releases". Unfortunately, there's not currently a good release management process; 14.04 was essentially managed by asking everyone not to merge anything major in the month before, then a week(?) of testing on a separate branch. If there's anyone with release management experience, I'm sure they'd appreciate some help.
The IRC channel on Freenode is extremely friendly, for anyone who has difficulty setting it up.
Someone else on here mentioned Guix; Guix is essentially Nix with a different language for defining packages. Nix's language is purely functional and lazy, but actually really simple; the nixpkgs library defines enough helpers that the vast majority of use of the language looks like a slightly more complex version of JSON.
Not having KVM access is hell when you're trying to figure out why your system won't boot, btw.
Not to bash Nix(OS) developers, because I think they're doing a great job.
"GNU Guix is a purely functional package manager for the GNU system, and a distribution thereof."
There's a gotcha though. The default configuration will use the "channel" as the package repository (which is really just a nixpkgs snapshot that was automatically built by the build farm and automatically tested to some extent). Updating the channel is stateful - it's non-trivial to go back to a previous version of a channel, in case you want to extend and rebuild a working configuration (not just boot it). Personally I avoid the channels and instead just manage a nixpkgs git checkout, where you can make a tag whenever you're happy with the results of nixos-rebuild, possibly with an equally named tag in your configuration (/etc/nixos) repo.
Another problem is the insecurity of the channels and the cache. By default Nix will try to fetch builds from cache.nixos.org, even if you don't use channels, and anyone capable of MITM could give you whatever he wants. So for the moment, I've disabled the cache on my systems and I build everything locally (and the nixpkgs is fetched over HTTPS). I think that signing is being worked on though.
On a positive note, it's very easy to get help, and it's not hard at all to get fixes and package additions merged. All my added packages were merged in a few days, most within a few hours. In Gentoo I usually had an overlay with 15 or so packages, now I have just 2 local commits in nixpkgs. On the other hand, if you're using channels, making local changes is a bit harder than Gentoo's overlays.
#!/bin/sh exec nixos-rebuild -I nixpkgs=/etc/nixos/nixpkgs "$@"
This itself works, but then you're probably still using channels for nix-env (user profiles). These need to be configured separately. Or maybe with NIX_PATH, I don't know since I don't use the user profiles feature.
After that, you just work with it like any git repo (presumably you, like git pull --rebase, git rebase -i...).
You can have multiple different versions of packages installed and other packages can depend on the different versions. The management of the 'shared library hell' is done behind the scenes using symbolic links in a GNU Stow like manner.
You can create 'environments' that are collections of installed packages and switch between them so tools needed for one task don't pollute the namespace for other tasks. For example, I create an environment for working on Firefox. It uses specific GCC versions and libraries. Only that environment sees them. I then switch to another environment when working on another project which uses clang - that environment can't see the library versions from the firefox environment, etc.
You can build package from source or download from a binary cache. You can modify configure flags and other build settings and the correct packages will rebuild - or download from cache if they are built with the same flags.
It installs easily on top of other Linux distros.
I think that portage has all of these features plus USE flags and source code compilation (and it also supports binaries).
If 'installation time' is touted as improved, then zero compilation is implied. That means lost portability and binary packages, which is unacceptable to many.
As for repeatability, anything that touches the network is by definition unreliable. Portage offers package caching.
To make portage operations repeatable it is necessary to snapshot the system, kernel and portage tree, run emerge --fetchonly <package-spec> then provide the resulting /usr/portage/distfiles/ as part of the environment seeking to repeat the process. It's achievable, but non-trivial. Gentoo-family distribution developers do not optimize for this use case but it does work well.
Personally I have created an alternative to the other options in this space (thoughts at http://stani.sh/walter/pfcts) and am attempting full cross-platform support (any OS, any build system or deployment process).
But it has nothing to do with Nix except that it's 'package management'.
nix allows you to roll back to a previous state. That doesn't mean emerge-ing older versions again or grabbing that package you have in your distfiles folder and installing that. Every operation is creating a new 'generation' and you can go back with a rollback. Think a revision control system - you just added a new revision, which points to new packages, but you can set the 'current' pointer back to "What I had yesterday".
Having the ability to install multiple versions of a package doesn't mean portage slots (Hey, I can have multiple gcc versions), it means that you can install every package in multiple versions.
You can install stuff without root, i.e. joeuser installs mysql.
(While I had an idea about Nix and worked a good deal with portage/the BSD port collections, most of the stuff above is written after checking with the site again/looking at the user's guide. I assume people vote you down for not checking what Nix is)
That's still not the same thing though. It's a wrapper around portage for all I can tell and uses portage to get back to some previous (destroyed!) state. Nix doesn't mutate (well, ignoring garbage collects) and provides this out of the box. demerge is a utility that I have to install on top of portage (provided I know about it) and portage itself doesn't know a thing about it. Oh, and it was last touched in 2008.
Back to the first line: Good argument though, it _does_ provide rollbacks for portage and - if it still works as advertised and is reliable enough - can simulate a somewhat similar feature, I give you that.
Please correct me if I'm wrong, but the way I read it, it actually rolls back to previous software versions, rather than previous state. Which is a small part of a state rollback - that would have to also include repeatable data migration both ways.
When you install new software, the old ones are not automatically overwritten - packages are immutable and cannot be "replaced" - you can only introduce a new package for the same software, which also requires that all of the dependants of that software be updated to use the new one.
As to the question of what is rolled back - that depends entirely on what you put into your Nixpkg. Every package derivation is built inside a chroot environment, and only the explicit dependency graph described in the package is made available to the environment, which ensures that packages are built in ways that cannot depend on arbitrary data which is not specified up-front.
The package format is used for configurations, and can be used for data too - if you just treat your data itself as a package, or part of another. This won't work for frequently changing data, such as databases - and as such, irreversible state changes cannot be rolled back - you generally need a full backup solution and a bespoke migration strategy for that kind of change anyway.
EDIT: Thinking about it, it should be theoretically possible to write a schema migration layer on top of Nix. In the system activation script, copy all schema migration scripts to some directory (/var/schema or similar), then run the schema migration tool. When you try to rollback, all the schema migration scripts will still be in that directory, so the schema migration tool can rollback as well.
It's great & usable without considering the new feature of "append-only" package management. nix is kind of database with a support for multiple versions of data, where data is programs, libraries, the system itself.
I'm wondering whether it has a "freeze" command which allows to generate a stripped OS image without debug, without nix itself or support for nix features except a recipe to rebuild the frozen image with nix.
Any one knows how hard is to add a package?
http://releases.nixos.org/nix/nix-1.7/manual/#chap-writing-n...
http://nixos.org/nixpkgs/manual/
Looks alien to me (of course, it's new!), but not too scary. Might give it a spin in a VM at least.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...
Is that not AwesomeWM btw? There are some rough edges around package discovery (or holes in my knowledge).
If you install nix locally (just the package manager, not NixOS), I usually query like this:
nix-env -qaP | grep awesome
I'll say that I'm finding nix (just using the package manager, not NixOS) to be a very nice way to manage some custom-compiled packages. I was able to upgrade nginx, for example, from 1.5 to 1.6 with all my plugins and compile flags in place with just a few small changes. This is surely possible through other means, but my previous method of manually downloading/compiling/saving configure flags in my $HOME/src was sloppy.