Hacker News Reader

I use nix in production, and I love it. It's just as good in practice as it is in theory.

I think the problem is that really using nix involves learning a new language. And it's a weird lazy functional language at that. So yeah, the Haskell folk adopt it readily enough, but everyone else has a high barrier to get over. The only people that do it are the ones that have really wrestled with the problem of dependencies and can see how well nix solves it.

We're using Nix in production. It has some polish issues but even in its unpolished state Nix is adding a lot of value for us.

I meet people that have all kinds of familiar issues with puppet, chef etc. We used to have those problems and we just don't have any more.

That's exactly what I think is so neat about it. puppet, chef, ansible, are all really cool, and they manage to bolt a declarative and atomic looking facade onto something that is decidedly not declarative or atomic (a regular old operating system). But, NixOS hits the problem in the gut. It seems like everything that is hard about the problem disappears when your entire OS is built from the ground up to be declarative and atomic.

It's pretty neat, and once I get my current projects squared away, I want to spend some time with NixOS, and maybe even get involved. It's just such a nice idea, and doesn't make me feel queasy the way so many of the bolted on solutions do.

A minor correction as a courtesy to other readers: puppet, chef, etc are not atomic. They can usually be considered thread safe across processes, if for some reason you run two simultaneously, but that is not a guarantee. Their changes are visible while they are executing on the system, so to other unrelated processes, they are not atomic.

Nix is atomic.

Not so much a correction...I think saying it is "a declarative and atomic looking facade" implies it is not actually that, even though it might look like it, doesn't it? But, perhaps it is a worthwhile clarification.

>>when your entire OS is built from the ground up to be declarative and atomic

entire OS?? I guess, the kernel is still imperative and not declarative.

That's true. And, Apache, the databases, etc. are all challenging. But, one step at a time. NixOS is several steps ahead of what the rest of us are doing (my products run predominantly on CentOS, Ubuntu, Debian, with a small number running on FreeBSD and a few other outliers).

I'm pretty excited about rust based operating system experiments, though it'll probably be 10+ years before we can start using them seriously in production (and operating system kernels have a lot of unpleasant stateful things to deal with, so likely will never be particularly pure no matter what language they're written in).

Anyway, Nix is cool stuff that I think is interesting and novel.

What has rust to do with Nix?

Nothing. It's just a more trustworthy language for building a kernel or other systems software. I was just rambling about cool shit happening in the OS development space.

I thought the intent of CoreOS was not to use a package manager, but simply be a host to run containers?

https://coreos.com/using-coreos/

Yes, I suppose that's one way to look at it. But, to quote from that: "Instead of installing packages via yum or apt, CoreOS uses Linux containers to manage your services at a higher level of abstraction. A single service's code and all dependencies are packaged within a container that can be run on one or many CoreOS machines."

So, you're now managing "containers" instead of "packages". What's the difference in terms of making them reproduce-able and reliable? Very little (though there are big differences in how you deploy them and how they behave when deployed). You still need tools to manage the complexity of reliably building these containers (a "higher level of abstraction" that contains many more moving parts than a single package, generally speaking). They've built configuration management (etcd), and they use existing tools or custom tools for the "packaging" part of the equation (Docker or rkt). Even though they're calling it a "container", you're still building and deploying software...now only with less mature tools than the old ones we've been using for 20 years.

Someone has to build those containers, and someone has to use tools to do so reliably and predictably.

I'm saying that NixOS seems to provide better tools (for both configuration management and for packaging) than the current popular solutions. It surprises me that more people haven't embraced it for doing this stuff. I'm just saying I think NixOS would be an ideal candidate for the same spaces where people are using CoreOS and Docker or CoreOS and rkt.

I think Docker, along with an orchestration system (such as Kubernetes) warrants a try, I was hesitant at first myself. It is just a different way of attacking deployments. It has some overlap with configuration management, but does not cover that entire domain.

As far as reliably building images, I believe you can use Nix to provision images. I don't see this as NixOS vs Docker, I believe they can be used in conjunction.

As far as the maturity, despite its age there is so much momentum behind docker right now. Also, NixOS is also not that old.

I totally understand the hesitation, but I think it's worth trying out.

I think maybe I've mis-communicated somewhere along the way. I'm not saying containers are a bad idea; they're a good deployment strategy for many use cases. What I'm saying is that there are a lot of slapped together tools out there trying to provide a declarative/atomic infrastructure that are doing it poorly...but, are quite popular. NixOS seems like an ideal tool for the task; as you note, one could readily build your containers with NixOS (and I think it'd be the ideal choice for that). And, in fact, that's primarily what I was thinking of.

We've been working on Docker support in our products lately, so it's on my mind, and the way that so many lessons that have been learned in the past couple decades of systems management are kinda thrown overboard in the Docker (and other containers) community. As above where there's a sort of belief that "containers" makes the problems package management solves irrelevant. Likewise, there's a lot of throwing security out the window; a tremendous level of trust is being given to container builders.

I could rant all day about stuff like this, and there's always the risk of turning into Grandpa Simpson. So, I'll stop ranting after a summary:

Containers are cool, but a lot of people are making a lot of mistakes in their use of containers. NixOS is cool, and might remedy some of the problems I see in the way people are using containers (while also solving a number of other problems of reliable deployments, not just with containers).