Comment by adamgordonbell | Hacker News Reader

Comment by adamgordonbell | Hacker News Reader

I was a nixos user for a year or so maybe 4 years ago. I recently learned how containers work at the kernel level, which deepened my understanding of Nix.

I’m still not sure this is right, but this is how I’ve been thinking about nix:

    Packaging things is hard on Linux because you have dynamic dependencies. Everything written in C probably loads in libc. And it gets worse from there. You have all kinds of dependencies that are loaded dynamically at runtime, some crypto library, P threads, et cetera. If everything was linked into a static fat binary, it would be easy to package a deploy things onto Linux machines, but that’s not the case.

    So one way to view Docker is as a hack around this issue. You can ship an application easily – You can package it up easily – If you put it inside of a box and inside that box, you put an entire Linux file system and all its dependencies.

    A second solution is the one that Nix has, which is to rethink all this. When you build things just be very explicit about what the dependencies are. And when you link them, link them by hash that’s made of all the inputs, and then you don’t have collision problems. And you’ve solved the packaging problem for Linux. But it requires changing how you build programs.

I’m sure nix experts on here have a deeper understanding of things. But it’s been a useful mental model for me.

---

Copied over my comment from https://lobste.rs/s/pnnoba/nix_turns_20_what_hell_is_it

Did you use nixos for builds or as your daily driver (or both)? Using nixos as a daily driver doesn't make sense to me, but I'm probably missing something.

I had a windows machine that had outlook on and such and then a VM that was nixOS and i did all my dev work in it.

It was super nice to have everything configured in a single file that specified every detail of the OS. But some things were super hard (writing my own packages) and I slowly moved on.

I use it everywhere. Daily driver, VMs, and servers. I think it more than makes sense to use it this way. When I want to try to use some software I can checkout a new branch and try it out. If there are issues I can just revert back and everything is normal.

> Using nixos as a daily driver doesn't make sense to me

Many Nix enthusiasts use NixOS as a daily driver, and are very pleased with it.

I'd say some of the advantages are: the same 'elegance' from being able to declare how a package gets built carries over to being able to configure a system. -- e.g. for niche things like "setup Yubikey with PAM", I don't have to worry about what config settings to manually change, I can just update my config with that. (And my config is in a git repo; whereas "what changes I made" is not).

There are certainly significant drawbacks, sure; but I think the main decider between whether it makes sense is how appealing "take the time to write a config with changes" is vs "just run the command / edit the system file" is.

I used NixOS for a while, but switched back to Debian. My pain point was that unless you also use Docker etc, deploying applications and deploying the system is inseparable. I don’t want to rebuild my system to update an app. This is especially painful on e.g. Raspberry Pi, because full deployments are expensive and you end up needing to set up VMs for building etc. The killer feature for me would be separable roots, so I could use multiple instances of NixOS on 1 system.

The other aspect is that declarative is nice, but often you care about preserving data as well. So you need backups etc. If you have full system backups, then separating config from data is more complex (and less useful). I’d rather spend my time on a rock solid and frequent backup strategy than worry about NixOS + a solid backup strategy.

I only have 1 server though. If I had more, then being declarative might be more useful. I currently use Nix for project dependencies, which is really nice.

> don’t want to rebuild my system to update an app.

You don't have to do that - there's lots of other options. (Although the system shouldn't rebuild if you don't update your channels, so the premise is interesting/suspicious.)

You can build your app independently against a pinned nixpkgs version. You can build the app and export/import that closure on another system. You can build the app itself using nix-build without engaging the nixos switch.

Building the app is not the problem, Nix adds minimal overhead for that. Deploying the app is annoying because changing a systemd service requires a nixos-rebuild, which is pretty slow on a Raspberry Pi.

There’s no good way to have an auto-updating non-NixOS systemd service on NixOS, because it’s not designed to co-exist with other things.

Also, NixOS is pretty much a DSL around systemd for this kind of thing. Systemd is already fairly declarative, so the indirection seems a bit unnecessary.

Reply on news.ycombinator.com