Seems neat, better than Terraform, although limited to just nix and a few providers. Hopefully that will grow. I've been working on a provisioning tool myself. Provisioning is hard, and supporting multiple APIs can be really difficult.
When I last tried it about 6 months ago it seemed to be a complete mess. I failed to get any recent ruby gems installed. There were dozens of different articles describing how to work with package repositories, and all of them seemed to be outdated by varying degrees. I also got the feeling that nix had more of a focus on desktop systems, for whatever reason.
I use it as a system level configuration tool, and then use Docker for the application level. This is not how the NixOS sees itself ideally, but in my experience their ideology does not map well to the reality of application deployment.
So what I do is have all system level tools installed using NixOS: the OS, logging, systemd, Docker, sshd and so on. Then I have my applications built as Docker containers and provision them as systemd units also configured by NixOS files.
That sounds reasonable, but it kinda makes me question NixOS' value proposition. It seems that any one of the current distributions works well as a generic base for containers.
There are probably lots of systems running standard Linux packages with more complex configurations (i.e. Mailservers, maybe databases, proxies etc) where I could imagine it being useful? Or maybe their desktop work makes more sense than I thought–my desktop environment is much more customised than any server, and I've never tried if the setup scripts I try to maintain actually work.
I don't think any operating system at this moment does well as a base for containers. At least not from the box, and as soon as you have to customise the OS you need tooling like Puppet/Chef/Salt to make your customizations reproducible. And that's the exact value proposition of NixOS, it's not only reproducible, the OS will be a complete reflection of your Nix specifications from the ground up.
I feel NixOS definitely gets some stuff wrong, and I hope at some point it gets some good competition. Mainly because the Nix language looks a bit awkward to me, and also because I don't fully get their package management situation. But the idea of having the operating system be configured from a specification is just a level up from old fashioned linux distros.
I thought the same as well, but recently I've been having a decent go at it with RancherOS. Everything boots from two docker processes, either at the system or user level. Almost anything in the system can be pretty easily configured via cloud-init.yml file. If you want an Ubuntu console layer(or Alpine) just specify it in the yml.
It's great to see NixOS and similar tools gaining ground. But personally I find that docker's configurations simpler to grok than NixOS's syntax. Plus it's interesting the granular level of control over system security and system access gaiened via docker (really mostly Linux secomp controls and process namespaces). It's kind of like having capabilities built into the OS on top of specification driven system configuration.
NixOS is capable of creating a Docker image given a Nix specification, by turning the Nix store into an archive. These images are quite minimal since they contain exactly the dependencies needed for your app.
NixOS also has its own container system, so your server configuration can simply specify a subconfiguration that will be spawned as a container. The containers reuse the Nix store from the host system, which means you get a fine-grained caching system.
I haven't used those things much so I don't really know how production-ready they are.
I sometimes use Docker (with Dockerfiles or DockerHub images) on NixOS as a way to run systems that I don't want to package with Nix. I've made a little Nix module for declaring Docker services as systemd services.
That's part of why I don't feel like Nix is a limitation. I have actually used NixOps to deploy NixOS configurations that include Docker services, so my feeling of Nix is that it kind of supervenes on everything else...
Well, Nix is probably never going to be usable by non-developers and is very far from production quality for any kind of infrastructure. I mean theoretically you can use it in production if you avoid nixpkgs and make your own package repository with your own packages and your own tools. Playing with it on desktop is fine, although you can't get far without learning the language, reading sources and doing some functional programming.
Still, Nix should be at least an inspiration for next real world package managers.
Can I use it to deploy either client or server applications on windows? All configuration and deployment tools I've looked at seem like they assume the only deployment target is linux servers running web applications. I don't care about the web. I need a deployment tool that works for local research on my clients' analysts' desktops, not just devops on remote somewhere.
Nix itself does indeed work on the latest version of WSL. However, there are still issues with building most of the packages from nixpkgs. For instance, I'm still waiting for this issue to be solved: https://github.com/Microsoft/BashOnWindows/issues/1878
Other distros are also affected by these issues, so I think they'll be solved eventually.
I don't know how NetBSD handles this, but for any provider that doesn't allow you to use custom ISO's or ipxe, you can use [nixos-in-place](https://github.com/jeaye/nixos-in-place). I've used it before. It isn't ideal, but it gets the job done.
I cherry-picked this into my local NixOps repo and have been using it for several weeks to deploy to Vultr servers with no issues, except one -- the author has hard-wired an assumption that you're using Btrfs for your root filesystem. I didn't want that so I simply replaced that hard-wired assumption with ext4 in my personal branch. Now everything is working great.
I'm the author of that PR. I apologize for the forced usage of btrfs. This was one of my first delves into the nix language, and I literally copied the digital ocean backend and changed the API calls (and the d.o had a hardcoded filesystem and I wanted btrfs and didn't know how at the time to move that into the configuration level). After the 17.09 release of NixOS is completed, I'll put some focus back in that PR and hopefully get it merged upstream.
