Hacker News Reader

The "market" for Nix is honestly OCD people that care about the software production process --- "god willing" our fastidiousness will eventually pay off as everyone else slowly boils in "accidental complexity", and our decisions finally make sense to others. In the meantime, it's hard to convey the benefits.

For now, I argue there is surprisingly little business case to care about developer efficiency --- VCs want you to blow cash, and increased developer outsourcing with remote work is covering the stupid complexity costs the cloud imposed. Mainly, businesses are demand constrained. That there is tons of embarrassing supply chain issues rights now is to me in accordance with this. America has gotten really good at advertising and customer acquisition, but we've lost skills at actually doing the basics, as it is really easy to service whatever demand you can scrounge up.

So far now, you either really want a clean workbench, even at the cost of dealing with the complexity that cleanup exposes, or you don't. That says whether Nix is or isn't for you.

> it seems to me like it’s competing with docker and kubernetes and I have never seen a convincing argument about why it would be better.

This seems to indicate a huge mismatch between what you think Nix/OS is compared to what it actually is. NixOS is for creating/maintaining systems, Docker is for running applications and Kubernetes is for running applications but across multiple servers, neither of those tools are like the other really.

The market you compete in is the market your users imagine you offer similar solutions. Not the market of how you describe yourself.

Docker's features usually include "its easier to create and maintain a system".

That Nix does this different and better doesn't matter when a user is just looking to solve that one problem.

At that moment, for that user, Nix is just a fancy config manager with one click deploy features and competing with docker.

I would argue Docker and Kubernetes are a bunch of crap popularized by people lulled into blowing all their money to cloud providers and compelled out of envy to imitate big tech -style deployments, even though it means taking on extra problems you absolutely don't need to deal with.

Also, Docker and Kubernetes are...just more layers. There is no cleaning up what came before. The Nix ecosystem is about drilling all the way down and cleaning up the prior tech debt. It's a fundamentally different approach.

Again, misunderstandings seems to run rampant in this thread...

No, Docker doesn't maintain systems, it handles applications. No one runs systems inside of Docker. People run applications with Docker, and Docker itself runs on systems.

And no, Nix doesn't "do this differently and better", as what Docker does and Nix does is wildly different. Nix is for machines, not applications. Sure, a subset of features from Nix can be used like Docker, but that doesn't mean Nix and Docker is the same, no matter what you think of markets or whatever.

I think what the parent is alluding to is: What is the practical point of using Nix when similar outcomes can be reached with more mainstream solutions? In other words, suppose I want to deploy a web app that depends on Nginx, PHP, and PostgreSQL.

I could:

(a) Run all as docker-compose type solution

(b) Run all as scripted Nix solution

(c) Install packages manually on general purpose OS

Lets ignore "c" for the moment as the goal is to avoid that exact scenario. Given the prevalence and widespread support for "a" why should sysadmins choose "b"?

I don't understand how you can use docker-compose, docker, Kubernetes or anything else to achieve the same thing as NixOS. NixOS gives you a fully reproducible personal computing system, from boot config, window manager, partitioning to applications, home directories and everything in between.

What mainstream options are available for doing this? Guix could be one option, but it's not mainstream so I'm not sure what tools you are referring to.

You are talking past the comment that you replied to, and you haven't answered it.

Guess I'm missing the whole subject of this thread then. The submission is about NixOS, which is for full systems (like in personal computers), something you cannot build with either Docker nor Kubernetes, the technologies that WastingMyTime89 said seems to compete with NixOS.

Eh you can do the same thing (or close enough) with a bash install script on a "stock" linux system and then a docker set up with the applications that that you want. Or with ansible. it really depends on the end goal. Not everyone needs every single bit to be the same. Or you can just image a drive. It depends on the end goal and often multiple solutions will get you there.

These are the nasty solutions I have to deal with at work all the time and my entire job consists of handling things when the "quick" bash cloud init script that someone wrote and various people have made additions to over the years goes wrong.

Bash scripts fail at this task because they are generally not convergent. Ansible makes a basic effort at being convergent, but most of the scripts I've seen are extremely naive about the ways in which a configuration can diverge.

moreover, you can also use docker digest instead of tags, that is: instead of docker pull postgresql:11 you can do docker pull postgresql@sha:xxxx....

And why would someone want that? Sure it sounds theoretically nice, especially if I was still working in IT. But learning another system with a poor ui has a large cost for a theoretical benefit.

Nix is (a) and (c), depending on how you want to use it. What differentiates it from docker-compose or `dnf install` isn't just the fact that you can ship something in containers or install some packages but also the various properties those containers or packages inherit from the build system.

I guess the nix way would be more performant because it does not need layers of OSes

> Docker is for running applications

Yes but no. Docker is mainly used for its ability to build and reuse standardised containers. It’s very much a distribution mechanism (I mean that’s why it’s called docker). From other comments I get the feeling that NixOS could be used to build reproducible containers in a way that remind me of building tools like Bazel but it’s not entirely clear to me why you would chose to do that nor if it’s actually a goal of the product.

Docker and Kubernetes are almost strictly a subset of the power within the Nix ecosystem.

> NixOS could be used to build reproducible containers

You absolutely can build docker images using Nix via dockerTools.buildImage [0].

[0]: https://nix.dev/tutorials/building-and-running-docker-images

> I guess it could make sense for servers as an alternative to provisioning tools but then it seems to me like it’s competing with docker and kubernetes

It’s not competing, it’s complementing. Think of it as a fully deterministic “docker build”.

Yes but « docker build » already exists and can already be made deterministic so it’s indeed somewhat competing. Would anything be easier by using Nix?

Right now it seems to me like a large ordeal with little to no benefits and my interaction with the Nix community hasn’t been very convincing. A lot of Nix users seem to believe determinism and reproducibility of everything to be enough of a justification in itself. I don’t think it’s worth the pain.

The biggest limitation of using Docker for building images is that it does not allow for composition. You can't simply say you want to combine a Python and Rust image for example.

With dockerTools from nix (https://nix.dev/tutorials/building-and-running-docker-images), this kind of composition is easy. You also end up with significantly smaller image sizes - containing only exactly the dependencies needed for the image to work, which is also good from a security perspective - since it decreases the attack surface.

> « docker build » already exists and can already be made deterministic

Truly deterministic Dockerfiles are a rare thing to find among the ecosystem.

And we haven't even got into docker's poor support for unprivileged container building which leads to weird solutions using dind when you need to build an image from inside a container..

Two examples to get a taste of the tradeoffs and utility it provides would be postgrest and IHL.

I think it’s sexy. But like you I haven’t had the time to really dive into it and understand it. The promise is simplification, both operational and in terms of the runtime.