Live data from Hacker News

My First Impressions of Nix

mtlynch.io

181–190 of 354 posts

Re: My First Impressions of Nix

#181
post #165

Earlier quoted context omitted.

Nix vs not Nix seems like a parallel to Infrastructure As Code (terraform for example) vs Cowboying the AWS Console. Is that a fair comparison?

Yes that is a fair comparison. In the latter you have to write down or remember what you did to reproduce it, and even if you make a script it could screw up and leave your system in a bad state.

That script can also stop working or misbehave once the underlaying system state changes, e.g. as the repository packages get updated.

Re: My First Impressions of Nix

#182
post #85

Earlier quoted context omitted.

Disagree. The larger selling point is Nix reproducible builds. Getting a reproducible developer environment is a start, but everything inside that “shell” is then mutable. Hiding Nix behind YAML is obscuring a tool, Nix, to make the entire build stateless—and that YAML can often be a stopping point where folks aren’t going ‘deeper’ to unlock the reproducible build part. There are things it does that are very helpful,…

> reproducible builds fwiw, NixOS does not support reproducible builds as defined by the Reproducible Builds project. They support reproducible environments/configuration/deployments or how you want to describe it.

1307 out of 1331 (98.20%) reproducible https://reproducible.nixos.org/nixos-iso-gnome-runtime/

see also https://reproducible.nixos.org/

Re: My First Impressions of Nix

#183
nix: automating running scripts from random readme.md as root.

the amount of JavaScript devs just learning SE in this thread defending the maybe-good-enough-for-your-dev-box nix is so amusing.

it's like seeing second year CS students thinking they mastered system programming because they wrote one toy compilet that optimizes one loop they were looking at the time. not saying it's bad. it's a very essential first step and everyone will step on this starting their journey, but the amount of misplaced self confidence is too funny looking from a more experienced vantage point.

Re: My First Impressions of Nix

#184

Earlier quoted context omitted.

You can think of the function inputs as: 1. All the package definitions in nixpkgs 2. Any external sources When a package is updated in nixpkgs, input #1 changes.

I mean, I get that, but that means that the reproducibility of my build depends on the whims of the nixpkgs maintainers, it's not a property guaranteed by the package manager.

You can however define inputs that are not the whole of nixpkgs. You would use something like this and you would pin it to a very exact version and hash of a package:

https://nixos.org/guides/nix-pills/nixpkgs-overriding-packag...

Re: My First Impressions of Nix

#185

Earlier quoted context omitted.

Nix vs not Nix seems like a parallel to Infrastructure As Code (terraform for example) vs Cowboying the AWS Console. Is that a fair comparison?

Not really, unfortunately. In my opinion, Nix is more like using Haskell instead of whatever language your team is using to write software.

I got pretty far the first year without really writing much nix code at all.

Re: My First Impressions of Nix

#186

Earlier quoted context omitted.

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

You don't have to manage your system with NixOS to reap the benefits of Nix. It solves very real problems that very much exist, it might not exist if you're a one-man show deploying WordPress to GoDaddy though. Barrier to entry: 1. Run the nix installer 2. Enable flakes 3. cd project 4. nix run This ensures you run the package with every dependency except the kernel pinned to a hashed version. If dependency hell is n…

> Run the nix installer

Ok and this requires root access, sets up some global directories under root, and a new user. Me as the administrator: why the hell do I need a new user and what is the nix store and what are the conditions that mutate it? (I know the answers to this question, but it's a barrier for people who give a shit).

> Enable flakes

What the fuck is a flake? Reads a bit... what the fuck is a derivation? (again: I know the answers to these questions already, but the invention of jargon by nix devs is a massive barrier to entry that shouldn't be overlooked, it's extremely confusing)

> cd project

Ok now I'm comfortable doing things I know

> nix run

Fine, but what about auto envs and nix shell? I don't use these with make or cmake. I need to attach a debugger, where does it go? How do I set up my IDE that has no idea nix exists?

My point is, nix has a lot bigger of a barrier than these four lines, and it's really naive to think that's it.

Re: My First Impressions of Nix

#187

Earlier quoted context omitted.

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

> The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. That's simple: nix is a package manager and the language used by the package manager, NixOS is a Linux distro. > It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't…

As someone who seems to be going along a similar path (started as a dev, no one was around to do sysadmin so I did it, and now in trying to modernize a bunch of really old/unpatched servers running a legacy system I'm learning how to devops) I feel better knowing I'm not alone in this struggle.

Re: My First Impressions of Nix

#188

> Nix, on the other hand, does have a concept of state. If you make a one-line change to a 200-line Nix configuration, it doesn’t have to re-do all the work from the other 199 lines. It can evaluate the state of the system against the configuration file and recognize that it just has to apply the one-line change. And that change usually happens in a few seconds. The author seems to have some misguided ideas about Nix…

Author here. Thanks for the clarification! I'm still new to Nix, so I'm trying to share useful things I'm learning without overstepping my expertise and saying wrong things. My mental model of Nix was that if I'm in system state A, which is the result of performing task X + Y, and I want to get to system state B, which is the result of task X + Y + Z, then Nix would recognize that it's already in state A, so it only…

When it comes to building derivations, yes. Which describes almost everything you can do.

For live system rebuilds in NixOS, the final step involves examining the system to decide which systemd services need restarting and restarting only those; that’s part of the process called activation. But that’s the only exception, and doesn’t happen if you reboot instead.

Re: My First Impressions of Nix

#189

Earlier quoted context omitted.

It seems like Nixpkgs aims to minimize the number of package versions in use at one time. Not just nix, most package managers do, it seems (i.e. you wouldn't expect to find different minor versions of Nginx in Debian, would you?) So by that same logic, there is only one version of Django 4. It is definitely possible with Nix to use the precise versions of what's in your requirements.txt, but I'm not sure if the Nixpk…

Doesn't this auto-upgrade behavior punch straight through the reproducibility Nix is supposed to be giving you? It's not exactly a functional build system if the results you get depend on when you download the dependencies. (I mean, I guess you could say that time is an input to the function, but that seems to miss the point.)

What do you mean by auto-upgrade behavior?

If the Django package in nix were upgraded, all packages that use it would be tested.

And you wouldn't get the upgrade automatically, instead you would only get the upgrade when you change the version of Nixpkgs that you are using.

And if you don't like that, then you can use multiple versions of Nixpkgs at the same time. Your old package will stay exactly as it was. This of course cuts both ways, and means you get no security updates for it or any of its transitive dependencies.

Which part of this isn't reproducible or functional? If nixpkgs never changed, it wouldn't be a very good package repository.

Re: My First Impressions of Nix

#190

Earlier quoted context omitted.

> reproducible builds fwiw, NixOS does not support reproducible builds as defined by the Reproducible Builds project. They support reproducible environments/configuration/deployments or how you want to describe it.

1307 out of 1331 (98.20%) reproducible https://reproducible.nixos.org/nixos-iso-gnome-runtime/ see also https://reproducible.nixos.org/

Yes, they are testing this for a fraction of their packages.

It still amounts to less testing then what distros like Guix, Debian and Arch Linux is currently doing.

Post reply on HN