What would you like me to explain? I'll do my best to present NixOS stack in 25 minutes talk. Anything particular you would like to know from the stack?<p>- Nix is a purely functional package manager. This means that it can ensure that an upgrade to one package cannot break others, that you can always roll back to previous version, that multiple versions of a package can coexist on the same system, and much more.<p>- Nixpkgs is a large collection of packages that can be installed with the Nix package manager.<p>- NixOS is a Nix-based Linux distribution. Thanks to Nix, it supports atomic upgrades, rollbacks and multi-user package management, and it has a declarative approach to system configuration management that makes it easy to reproduce a configuration on another machine.<p>- NixOps, the NixOS-based cloud deployment tool<p>- Hydra is a Nix-based continuous build system.<p>Cross-post from reddit.com: http://www.reddit.com/r/linux/comments/1st3vz/im_giving_a_talk_nixos_declarative_configuration/
Anecdotal experience deploying in the lab with NixOS and/or Nix:<p>1. At the time, I was maintaining several heterogenous RPM-based systems, so that was the comparison. I can say with some limited authority that it's easier to make NixOS packages than RPMs, but harder than (say) tweaking /usr/ports in a BSD or Gentoo.<p>2. Being able to send closures between machines -- i.e. a reproducible recipe for the user's current environment, including all installed and user-acccessible packages, libs and binaries -- is eerie, like alien technology. Think of 'nvm' or 'virtualenv', but granular, and for everything. Once you get used to it, you will never be happy with any other package manager.<p>3. Nix' independence from NixOS is both a blessing and curse . On every OS except NixOS, Nix is necessarily a third-party add-on, and it necessarily uses slightly different versions of everything. Thanks to some insanely clever environment management, this never causes things to go plink, but it <i>does</i> mean that I often had a choice between a fresh Fedora RPM -- <i>on a Fedora machine</i> -- and a slightly stale Nix package. Guess which worked better. Guess which I chose most of the time. (But if you guessed that I was a bit OCD about package freshness, you'd be right.)<p>4. Final drawback, and the reason NixOS hasn't yet made it into production at our company: NixOS itself obviously has to use the same slightly stale packages that Nix does.
That said, how upset can you really get? These guys don't have the dev-hours that Canonical or Red Hat do -- or even Debian, for that matter. What they have achieved with the resources at hand is mindblowing. What this project needs to really be useful to me is about two dozen new FOSS contributors and like maybe half a million dollars of investment. Any more than that, though, and I'd worry they'd lose their game ;D -- so much of it is based on doing immense amounts with almost nothing, using cleverness as the amplifier. Isn't that what it's all about?<p>5. Oh, and also, the devs are responsive. Hi guys! ;D
I'd love to hear more about the potential of Nix for language agnostic isolated development environments: <a href="https://nixos.org/wiki/Howto_develop_software_on_nixos" rel="nofollow">https://nixos.org/wiki/Howto_develop_software_on_nixos</a><p>Could it be a unified alternative to Python virtualenv, rvm, rbenv, cabal sandbox, etc? This would be specially important for projects needing heterogeneous builds.<p>It'd also be interesting to see a typical Nix development workflow taking advantages of Nix goodies like continuous integration with Hydra or staging and production deployment with NixOps.