I'm giving a talk at FOSDEM: NixOS, declarative configuration Linux distribution
15 comments
Anecdotal experience deploying in the lab with NixOS and/or Nix:
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.
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.
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 does mean that I often had a choice between a fresh Fedora RPM -- on a Fedora machine -- 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.)
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?
5. Oh, and also, the devs are responsive. Hi guys! ;D
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.
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.
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 does mean that I often had a choice between a fresh Fedora RPM -- on a Fedora machine -- 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.)
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?
5. Oh, and also, the devs are responsive. Hi guys! ;D
2 is intriguing. Would this sort of functionality make a reasonable replacement for vagrant?
Well, in some contexts, yes, although to be honest I don't use Vagrant myself, so it's hard for me to compare use-cases.
I see Nix as much-needed conceptual competition in the ongoing package-manager vs devops-deployment dogfight, to both package managers (rpm, yum, zypper, dpkg, apt-get...) and devops tools like Chef, Ansible, Salt, and Puppet. Nix is both, and does cool things like try to resolve a binary that will work on your architecture on the fly at runtime, and compiling one if it can't find one in the repo. It's just... better. Go try it.
I see Nix as much-needed conceptual competition in the ongoing package-manager vs devops-deployment dogfight, to both package managers (rpm, yum, zypper, dpkg, apt-get...) and devops tools like Chef, Ansible, Salt, and Puppet. Nix is both, and does cool things like try to resolve a binary that will work on your architecture on the fly at runtime, and compiling one if it can't find one in the repo. It's just... better. Go try it.
nixops is the Nix version of vagrant, it uses this closure-sending mechanism to create the machines.
4 is going to be solved when enough users contribute to the nixpkgs isn't it ?
Yes, precisely why I said it hadn't made it to production 'yet'. I haven't had time to contribute like I want to, but believe me, it's up there on the list.
My advice? Get involved with this project now. It's going places. The only problems it has will be solved by 'confidence-convergence' -- i.e., as the project continues to be awesome, more people will contribute, making the project more awesome. NixOS just needs more package maintainers. That's it, really.
My advice? Get involved with this project now. It's going places. The only problems it has will be solved by 'confidence-convergence' -- i.e., as the project continues to be awesome, more people will contribute, making the project more awesome. NixOS just needs more package maintainers. That's it, really.
I'd love to hear more about the potential of Nix for language agnostic isolated development environments: https://nixos.org/wiki/Howto_develop_software_on_nixos
Could it be a unified alternative to Python virtualenv, rvm, rbenv, cabal sandbox, etc? This would be specially important for projects needing heterogeneous builds.
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.
Could it be a unified alternative to Python virtualenv, rvm, rbenv, cabal sandbox, etc? This would be specially important for projects needing heterogeneous builds.
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.
Yes, Nix profiles are package manager (or system level) alternative to virtualenv, etc. They can be used to give different evironments, be it development or production.
Actually, your system is a "system" profile. You update profiles independently from each other.
Example of collection of such environments: https://github.com/chaoflow/skel/blob/master/.nixpkgs/config...
I'll mention examples with NixOps and how I've used it in practice. Good call about "development workflow", I'll think about how to explain that in minimal words.
Actually, your system is a "system" profile. You update profiles independently from each other.
Example of collection of such environments: https://github.com/chaoflow/skel/blob/master/.nixpkgs/config...
I'll mention examples with NixOps and how I've used it in practice. Good call about "development workflow", I'll think about how to explain that in minimal words.
I would love to see some good examples on how to create custom development environments. ie one for erlang, C, oz etc
We don't have good examples documented yet, sorry. There are some (rather poor) wiki articles how to achieve that at https://nixos.org/wiki/Howto_develop_software_on_nixos#Obtai...
How difficult is it to package for Nixpkgs, assuming some familiarity with deb and RPM packaging?
DISCLAIMER: I've written a lot of ebuilds (Gentoo), but only tried Deb a few times.
I'd argue it's way easier. Here is an example of packaged nginx https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/ht...
In a nutshell, you need to know the following:
- be familiar with basics of Nix language (shouldn't take more than an hour reading that chapter in Nix manual)
- be familiar with basics how mkDerivation function works and how are the phases of packaging bound to it (shouldn't take more than a hour reaind that chapter in Nixpkgs manual)
- take a simple package you want to try, copy some existing one and modify it to fit the needs
Also see https://nixos.org/wiki/Main_Page#Contributing_to_Nix_Project...
I'd argue it's way easier. Here is an example of packaged nginx https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/ht...
In a nutshell, you need to know the following:
- be familiar with basics of Nix language (shouldn't take more than an hour reading that chapter in Nix manual)
- be familiar with basics how mkDerivation function works and how are the phases of packaging bound to it (shouldn't take more than a hour reaind that chapter in Nixpkgs manual)
- take a simple package you want to try, copy some existing one and modify it to fit the needs
Also see https://nixos.org/wiki/Main_Page#Contributing_to_Nix_Project...
- 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.
- Nixpkgs is a large collection of packages that can be installed with the Nix package manager.
- 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.
- NixOps, the NixOS-based cloud deployment tool
- Hydra is a Nix-based continuous build system.
Cross-post from reddit.com: http://www.reddit.com/r/linux/comments/1st3vz/im_giving_a_talk_nixos_declarative_configuration/