Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix and NixOS, my pain points

remy.grunblatt.org

Post reply on HN
Print view View original

31–40 of 109 posts

Re: Nix and NixOS, my pain points

#31

Post by rgoulter »

Reventlov wrote: post #27
rgoulter wrote: post #26

Regarding the second point, ("it's not enough to have the same /etc/nixos/configuration.nix file, because of environment variables, other files, and commit revisions of repos used"), this is one thing which Nix Flakes solves. With nix flakes, all the Nix sources you use must be checked into source control, and impurities like environment variables can't be used (by default).

This is actually the opposite, by default, impurities like environment variables can still be used, as well as binaries, or other things ! A small example : ``` [remy@typhoon:~/Blog]$ cat flake.nix { inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-22.11"; }; outputs = { self, nixpkgs }: let pkgs = nixpkgs.legacyPackages.x86_64-linux; in { devShell.x86_64-linux = with pkgs; pkgs.mkShell { buildInputs = [ python3P…

> by default, impurities like environment variables can still be used

In a `nix develop` shell? Ah, sure. -- I don't think the new nix commands have the same functionality that `nix-shell --pure` had.

But, in nix expressions used, in order to use environment variables (or to fetch from URLs without using a known sha256), the `--impure` flag needs to be passed.

Re: Nix and NixOS, my pain points

#32

Post by prox »

tsuujin wrote: post #2

I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home. Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun. I like the outcome, and I’m glad I took the time now, but it was a slog that I don…

It’s typical of certain areas in tech (like here) to not document, to not care about up to date information, and only as a last resort. You need people who can manage that and create a culture of documenting.

Re: Nix and NixOS, my pain points

#33

Post by prox »

kstenerud wrote: post #11
40yearoldman wrote: post #3

Earlier quoted context omitted.

I keep reading, this, and keeping being told this. Yet I switched every system over to nix and have found no thing but the best examples documentation and help from nix to do so. Within the span of a afternoon and a bit a reading I went from zero, to a script that lets me setup an entire dev systems with just a few commands in a vm, and or even on hardware. If anything the Nix documentation is just as good as every o…

Then you are a superhuman. I too went through weeks of pain and suffering to get my nixos hypervisor running, and if I were to lose my script and have to start from scratch again, I'd just install Debian instead. I would never recommend nixos to anyone. The concept is awesome, but the execution is terrible.

What I often find is this “ought to know” treshold. Parent comment user is probably familiar with lingo you are not. Documentation often assumes a certain level and a writer does not imagine a less capable user.

Re: Nix and NixOS, my pain points

#34

Post by Reventlov »

Foxboron wrote: post #30

Slight misunderstanding in the blog post there. > Archlinux is 78% reproducible on amd64 packages > Debian is 95.7% reproducible on amd64 packages This references the "fuzzing" infrastructure hosted by the Reproducible Builds project, and doesn't show "true" reproduction of binaries. It's designed to help us figure out where impurites occur in builds. Proper package reproduction is much better in Arch because we don'…

Thanks for the details, i'll update the numbers for Arch !

Re: Nix and NixOS, my pain points

#35

Post by abathur »

Reventlov wrote: post #27
rgoulter wrote: post #26

Regarding the second point, ("it's not enough to have the same /etc/nixos/configuration.nix file, because of environment variables, other files, and commit revisions of repos used"), this is one thing which Nix Flakes solves. With nix flakes, all the Nix sources you use must be checked into source control, and impurities like environment variables can't be used (by default).

This is actually the opposite, by default, impurities like environment variables can still be used, as well as binaries, or other things ! A small example : ``` [remy@typhoon:~/Blog]$ cat flake.nix { inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-22.11"; }; outputs = { self, nixpkgs }: let pkgs = nixpkgs.legacyPackages.x86_64-linux; in { devShell.x86_64-linux = with pkgs; pkgs.mkShell { buildInputs = [ python3P…

A dev shell is designed to allow the outside environment to be accessible (so you've got access to tools you'd want to invoke while working that aren't strictly project dependencies).

Re: Nix and NixOS, my pain points

#36

Post by abathur »

rgoulter wrote: post #31
Reventlov wrote: post #27

Earlier quoted context omitted.

This is actually the opposite, by default, impurities like environment variables can still be used, as well as binaries, or other things ! A small example : ``` [remy@typhoon:~/Blog]$ cat flake.nix { inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-22.11"; }; outputs = { self, nixpkgs }: let pkgs = nixpkgs.legacyPackages.x86_64-linux; in { devShell.x86_64-linux = with pkgs; pkgs.mkShell { buildInputs = [ python3P…

> by default, impurities like environment variables can still be used In a `nix develop` shell? Ah, sure. -- I don't think the new nix commands have the same functionality that `nix-shell --pure` had. But, in nix expressions used, in order to use environment variables (or to fetch from URLs without using a known sha256), the `--impure` flag needs to be passed.

I haven't used it, but afaict the --ignore-environment flag is intended for roughly the same usecase. https://github.com/NixOS/nix/issues/4359#issuecomment-907768... notes some differences.

Re: Nix and NixOS, my pain points

#37

Post by abathur »

amelius wrote: post #18

My main problem is that Nix is based on one version of libc. If your system already has vendor-locked libraries based on a different version of libc, then it is quite difficult to get the rest of the system on that same version of libc.

What systems have you encountered this on? (just curious; not trying to minimize)

Re: Nix and NixOS, my pain points

#38

Post by abathur »

tsuujin wrote: post #2

I switched my personal dotfiles to nix recently, and the “poor documentation “ comment here really hits home. Trying to learn /how to use/ nix was awful. I found lots of guides, almost always incomplete, and oftentimes directly contradicting each other. It took me weeks to get a working build and much of that time was anything but fun. I like the outcome, and I’m glad I took the time now, but it was a slog that I don…

I have been starting to suspect that a big part of the gap may be a sort of field guide to real-world patterns with context on what's new/old, where they are used/useful, and so on.

Re: Nix and NixOS, my pain points

#39

Post by amelius »

abathur wrote: post #37
amelius wrote: post #18

My main problem is that Nix is based on one version of libc. If your system already has vendor-locked libraries based on a different version of libc, then it is quite difficult to get the rest of the system on that same version of libc.

What systems have you encountered this on? (just curious; not trying to minimize)

Nvidia Jetson

Re: Nix and NixOS, my pain points

#40

Post by nemoniac »

The article mentions Guix several times but never once mentions as a pain point that Nix lacks a well-founded programming language.

Now I may be a total outlier here but it seems to me that while getting the fundamental concepts right is a good thing, having powerful means of combining them becomes more important in the long run.

Does that not speak in Guix' favour?

Post reply on HN