I currently use NixOS for a personal server (running on a Kimsufi Atom box at €10.20 a month). It's seriously awesome; I have my full operating system defined in a config file which can be versioned and backed up. I can write extra packages and custom services easily, as well, as part of my configuration. It even has its own declarative cloud management tool, NixOps.
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.
Would you mind sharing how you set it up on a Kimsufi/OVH machine? All infos I have found were quite outdated and I haven't had enough time to dig into it myself yet. I think it would be great if someone would document this.
I could write it up on the wiki, but I've forgotten the finer details at this point. Basically, I followed the Linode instructions, using the Kimsufi rescue disk as a base. The problems that I ran into were that I had problems with the latest Nix tarball, so I used the latest release of Nix at the time instead[0] (probably a good idea anyway), and also that I needed to set up separate / and /boot partitions, as Nix wouldn't install when everything was on / for some reason (I think the Gentoo forums claim there's some issue with GRUB2 and ext4).
Not having KVM access is hell when you're trying to figure out why your system won't boot, btw.
On one hand, I find Nix/NixOS fascinating, and I think package management should go in this direction. On the other hand, there is a weird dichotomy between nix-env and the main nix file, and I find that fairly common tasks such as "tell me the contents of package X" or "let's read the distro changelog and the upstream changelog for package X" to be either unintuitive or impossible.
Not to bash Nix(OS) developers, because I think they're doing a great job.
Yes, in general you can't say "what version of X am I using?". You have to ask: "what version of X, the derivation Y is using?".
You can see the contents of package X on your system, there's no index provided online for that. Also "contents of package X" is too general for nix, it's "contents of package X built with inputs Y", you may have the same package X built in different ways in your nix store.
It's not impossible, there's the need of a service that provides information on what packages provide a certain file.
I'm using NixOS for my HPTC and home PC. It took some to set it all up, including adding a few new packages (mostly related to 3D printing) and fixing some, but now it's running well and I'm really happy. I've always wanted distro where I can have all the configuration on the same place and which I can use to reproduce the whole thing.
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.
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.
Portage is a 'ports for Linux' (that's .. the reason for the name). It takes the BSD approach and adds a little here and there.
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)
> nix allows you to roll back to a previous state.
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.
Note that previous software versions also includes previous configuration files. I don't believe there's anyone who manages things like database schemas via Nix, you're right there.
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.
A rollback to a previous software version isn't "download the old version and replace the current one" as would happen with Portage, or most package managers.
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.
K, let me be honest: I haven't heard about demerge before, ever. Interesting and cool!
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.
Over portage? Installation time, outcome repeatability (how many binary packages do you have installed?) and ability to reliably roll back to previous state.
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).
One big difference is that _the entire system_ is built using Nix, including configuration files. Nothing in /etc is editable, everything goes through /etc/nixos/configuration.nix followed by a `nixos-rebuild switch` (does the entire build before atomically switching) and a `nixos-rebuild switch --rollback` (takes a few seconds) if you panic.
The configuration is just a Nix expression so you can do whatever you like with it, it's not like a JSON file but actually integrates with your packages, allowing you to override settings etc. There are options which are the same as USE flags, for example you can turn off X with `environment.noXlibs=true` and the entire system would be rebuilt without X.
It's at the same time much simpler than portage and much more expressive.
USE flags are just different inputs to the functions that build stuff in nix, which is most probably even more flexible in nix.
Nix is mixed binary and source compilation when there's no cache.
I'm happily using it for years already, and for me it's mainly a great step forward in freedom to experiment. You can do almost anything without touching virtualization, and even in bad failures you can simply choose your old stable config in GRUB whenever you need a working system :-)
Very interesting, and promising. It's a pity apt doesn't do that too. Though there is apt-btrfs-snapshot that conveniently fills the gap - though on btrfs only.
I tested both guix on top of ubuntu and nixos, the distro. It's really nice. With Nix I was able to use Steam and play windows-only games :)
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.
I found the nix expression language somewhat confusing at first, but I was able to create simple packages after a couple days. You can find many examples in nixpkgs, e.g.
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
Or I search through my local checkout of nixpkgs source.
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.
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.