Live data from Hacker News

Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

zero-to-nix.com

111–120 of 227 posts

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#111
post #88

Earlier quoted context omitted.

# What's opinionated about Zero to Nix Zero to Nix is opinionated because it advocates learning and using flakes and treating channels as deprecated. Zero to Nix also deviates from official recommendations in that it recommends installing Nix using Nix Installer rather than the official Nix installation script. https://zero-to-nix.com/about#whats-opinionated-about-zero-t...

To me using the word opinionated is a deterrent. Any time I hear the word opinionated used it usually means the opinion(s) expressed are overly strong, stubborn, and/or negative. I was expecting the guide to call out issues with the official documentation in a way that could upset the people working on the official docs. But this is just an alternative method. Hardly opinionated.

The term has gained a specialized meaning in computing over the last decade or so.

> Opinionated software means that there is basically one right way to do things […] Non-opinionated software leaves lots of flexibility to the user https://stackoverflow.com/q/802050

Providing only a single answer for how to do things is helpful for beginners who haven’t yet formed a basis upon which to make informed decisions.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#112
post #24

Earlier quoted context omitted.

It's basically checking in your OS to git. It never gets crufty and almost never breaks. There's a lot more to it but those are the core ideas and I'm typing on my phone.

NO. He asked about Nix NOT NixOS... do not conflate them together. Nix an extremely generic tool for much much much more than what you have said.

Is Nix used for anything besides configuring a computer?

I said "a lot more to it" as well...

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#113
post #109

Earlier quoted context omitted.

Not bit-for-bit reproducible. Package builds can be nondeterministic, binaries can have embedded timestamps (e.g, build time), and so on. They should be semantically equivalent, but it's not fully guaranteed.

You're not wrong overall, but your example is. In the build environment, the current time is set to the epoch which removes that variability. An upcoming feature of nix is content addressed builds which use the output hashes to determine the store path. This should make it much more transparent which builds are reproducible and which are not.

> In the build environment, the current time is set to the epoch which removes that variability.

The amount of time per build can vary. Embedded timestamps will all be in January 1970, but even a single second difference means the binaries are no longer bit for bit identical -- and that assumes the embedded timestamp isn't microseconds.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#114

I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread. I feel like I must not be doing anything "serious" enough to need package reproducibility at that high level. I'm aware of things like git checkout/tags, package-lock.json, Cargo.lock, Docker image tags. What is a real worl…

> I would love to see a discussion from somebody who really likes Nix on why it isn't ready for prime time yet/just play devil's advocate aloud on why it isn't the greatest thing since sliced bread.

Top reasons in my mind:

1. Error messages. Even with my >1 year of experience using NixOS full-time, I've encountered errors that I simply _cannot_ fix. This is getting better (recent nix releases let you introspect problems more easily).

2. Documentation gaps. Much of the nix docs are actually pretty good now! But sometimes you run into "missing links" that make it really hard.

> What is a real world use case where Nix isn't overkill? I've read toolchains but... nvm (node version manager), rustup. I still Rust on a machine once and I never think about it again.

For me, nix is unbelievably powerful to construct system images for various virtual machine formats. I'm using the nixos-generators[1] project to construct 8 or 9 image formats from one NixOS configuration. Packer and similar tools are the non-nix analog, but nixos-generators requires essentially adding a singular line to support something like Proxmox as opposed to much more work in some other tool.

I'm also using nix to build all our team's software - which varies from Vue.js to Rust to Django - and fold _all_ those development dependencies into a singular nix `devShell`. This means you can clone our repository, use `nix develop .`, and all engineers use the identical verisons of all software, dependencies, and libraries across several toolchains. It's incredibly convenient. (Imagine that you're a .js developer who needs to make a quick edit to a Rust backend route but doesn't sling Rust all day - you don't need to know how to setup rust at all, the `devShell` provides it).

[1]: https://github.com/nix-community/nixos-generators

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#115

Earlier quoted context omitted.

What's the `nix3 interface`? I use NixOS with Flakes, but frankly it's quite obtuse lol. I don't even know how to specifically update my `nix`. I updated to the latest release the other week and my `nix` CLI is on `2.11`. Are you referencing a 3.0 version of the `nix` CLI? If is there a summary somewhere on what is different between 2.xx and 3.0? Though i still have no clue how to update to 3.0 if i wanted to. Search…

It refers to the new CLI, i.e. the "nix" command. The old CLI is the nix-* commands (nix-env, nix-store, etc.). The new CLI and flakes are still marked experimental, but the plan is to stabilize them and call that "3.0". So it won't be very different from the current 2.12 - you just won't need to enable some experimental features anymore to get the new CLI/flakes.

Do you have an idea when the stabilization might come?

I've been using flakes for well over a year and there doesn't seem to be much discernible progress.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#116

I wish guides like these contained screenshots. Do people use Nix for desktop OSes? As a VM they SSH into? A collection of config scripts that they don't directly issue commands to? I certainly can't tell from a quick glance of this guide

Screenshots of what exactly? Installing packages? Running nixos-rebuild switch? I guess screenshots of a bunch of text.

Yes! Assuming that is what "using Nix" looks like for an expected use case, that would be informative for someone who does not know what using Nix looks like.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#117
post #60

Just my two cents: Nix doesn’t guarantee “reproducible”, just “repeatable”. (I think it’s helpful to keep these technical concepts distinct, and to introduce the right terminology when teaching, since it makes elaboration easier in the future.)

Accurate, but there is only so much to be done on that front when the consumed packages do not strive for reproducibility. As Nix or similar tools bring the lack of bit-for-bit reproducibility to the forefront, I hope build systems start adopting processes that will correct this behavior.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#118
post #60

Just my two cents: Nix doesn’t guarantee “reproducible”, just “repeatable”. (I think it’s helpful to keep these technical concepts distinct, and to introduce the right terminology when teaching, since it makes elaboration easier in the future.)

Can you elaborate? From what I understand, Nix packages are mostly reproducible as they are running great lengths for that, to the point where every time in Nix land is the exact same.

"reproducible" means you get the same result, bit-for-bit, when running a build in different circumstances.

It's trivial to write non-reproducible Nix derivations by placing timestamps, randomly generated data, or similar into the build output, directly or indirectly. Nix is a powerful tool for working towards reproducibility, since it can specify the software side of a build environment more exhaustively than most other package managers out there, and has a language (derivations) that enables repeating builds easily as well as comparing them, but does not guarantee reproducibility on its own.

A lot of the reproducibility of nixpkgs is attributable to reproducible build efforts elsewhere, including conventions like SOURCE_DATE_EPOCH. Nix itself does not in fact "freeze the clock" for builds, but many tools that use timestamps as part of a build will respect SOURCE_DATE_EPOCH instead of using the system clock. Many of these valuable developments in this direction are coordinated in the cross-distro https://reproducible-builds.org group.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#119
post #60

Just my two cents: Nix doesn’t guarantee “reproducible”, just “repeatable”. (I think it’s helpful to keep these technical concepts distinct, and to introduce the right terminology when teaching, since it makes elaboration easier in the future.)

Can you elaborate? From what I understand, Nix packages are mostly reproducible as they are running great lengths for that, to the point where every time in Nix land is the exact same.

hash of build output is not used in hash of derivation and in derivation tree. hence it is not reproducible.

Re: Zero to Nix, an unofficial, opinionated, gentle introduction to Nix

#120

I've been dipping my toes into the Nix ecosystem recently, having a dev environment per project with direnv is neat but how does this work with IDEs like VSCode or IntelliJ IDEA? For example, if I define a specific JDK in my project with Nix, will IntelliJ be able to pick this up? Does anyone have any good resources on how to set this up? BTW, for others who just want to try it out without having to install anything…

I've just been starting my Emacs from the direnv to ensure it has the right dev tools. This works, but can be annoying. It'd be nice to have a better solution.
Post reply on HN