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.
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.
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)
Over portage? Installation time, outcome repeatability (how many binary packages do you have installed?) and ability to reliably roll back to previous state.
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.
[+] [-] vertex-four|12 years ago|reply
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.
[+] [-] Seldaek|12 years ago|reply
[+] [-] Lethalman|12 years ago|reply
[+] [-] mercurial|12 years ago|reply
Not to bash Nix(OS) developers, because I think they're doing a great job.
[+] [-] Lethalman|12 years ago|reply
[+] [-] davexunit|12 years ago|reply
"GNU Guix is a purely functional package manager for the GNU system, and a distribution thereof."
[+] [-] ambrop7|12 years ago|reply
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.
[+] [-] yetfeo|12 years ago|reply
[+] [-] yetfeo|12 years ago|reply
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.
[+] [-] samsaga2|12 years ago|reply
I think that portage has all of these features plus USE flags and source code compilation (and it also supports binaries).
[+] [-] darklajid|12 years ago|reply
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)
[+] [-] dozzie|12 years ago|reply
[+] [-] davexunit|12 years ago|reply
[+] [-] wmertens|12 years ago|reply
[+] [-] Lethalman|12 years ago|reply
[+] [-] vcunat|12 years ago|reply
[+] [-] aruggirello|12 years ago|reply
[+] [-] iElectric2|12 years ago|reply
[+] [-] amirouche|12 years ago|reply
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.
[+] [-] lewaldman|12 years ago|reply
Any one knows how hard is to add a package?
[+] [-] pmahoney|12 years ago|reply
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:
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.
[+] [-] darklajid|12 years ago|reply
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.
[+] [-] iElectric2|12 years ago|reply