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.

Just some notes you might be interested in:

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.