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

101–109 of 109 posts

Re: Nix and NixOS, my pain points

#101

Post by 40yearoldman »

masklinn wrote: post #52
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…

> It's a language, and thus the language has may expressions that result in the same outcome. First it's a distribution and a package manager, and the guidance regarding these is sub-par. Especially with what there is of documentation being split between the old and new UIs, then being told about flakes but that they're experimental so it's not clear whether you should or should not use them. I just went to the nix w…

> First it's a distribution and a package manager

Nope, it's a language, and thinking of it as those things, even more so firstly is probably part of the struggle.

It's a language that you use to get your computer to do specific things. In this case, it might be a "package manager" and in the other case it could be a "distribution".

When you write go or rust to print "hello world" to the terminal you don't go around and call these things "printers", or "hello worlders".

It's a language, just like rust, go, php, bash, ed, awk, and brainfuck. Your first example even shows you using the language why proclaiming ahah! shell thing, or package manger! -> `'python38.withPackages (packages: [ packages.django ])'` is using this language to instruct the computer to do something. If you don't want to take the time to learn the language and understand its outputs, and want to just think "this is a package manager" then you are going to get lost.

Re: Nix and NixOS, my pain points

#102

Post by masklinn »

40yearoldman wrote: post #101
masklinn wrote: post #52

Earlier quoted context omitted.

> It's a language, and thus the language has may expressions that result in the same outcome. First it's a distribution and a package manager, and the guidance regarding these is sub-par. Especially with what there is of documentation being split between the old and new UIs, then being told about flakes but that they're experimental so it's not clear whether you should or should not use them. I just went to the nix w…

> First it's a distribution and a package manager Nope, it's a language, and thinking of it as those things, even more so firstly is probably part of the struggle. It's a language that you use to get your computer to do specific things. In this case, it might be a "package manager" and in the other case it could be a "distribution". When you write go or rust to print "hello world" to the terminal you don't go around…

> When you write go or rust to print "hello world" to the terminal you don't go around and call these things "printers", or "hello worlders".

That is the exact reverse of the relationship between Nix and Nix.

When I write in Go or Rust, a printer is a tool I might use to achieve a specific sub-part of my over-arching goal.

My goal is not writing nix programs, I've got better programming languages available for that. Nor are the nix OS or package managers utilities of nix. The relationship is the opposite: the nix language is a tool provided to manage software or distribution in order to actually do things.

> Your first example even shows you using the language why proclaiming ahah! shell thing, or package manger!

Aha yes, that well known language of whatever apt is, checkmate!

> If you don't want to take the time to learn the language

I don't even mind that, I'm pointing out that the official nix documentation I got from the official nix site following its own recommendation gave me something utterly unhelpful which neither helps me in furtherance of my goals, nor provide any obvious steps towards that.

Having learned that `python38.withPackages` is a function called with an other function `packages: [packages.django]` as parameter does not help me either.

> want to just think "this is a package manager" then you are going to get lost.

I guess I should remove nix then, since it's not a package manager and that's what I'm looking for?

You should maybe think of fixing the branding by the way, because some folks slander nix by calling it an OS, and there's pages talking about "nix: the package manager".

In fact that's literally the tagline of the primary manual:

> Nix Manual: Nix is a package manager which comes in a form of many command line tools.

> Introduction: Nix is a purely functional package manager.

Re: Nix and NixOS, my pain points

#103

Post by masklinn »

cwp wrote: post #91
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…

There's an element of truth to the "poor documentation" complaint, because there are tutorials etc out there that are out of date, incomplete etc. But the official nix project has excellent documentation. I think the problem is that nix is just hard to learn. It's really different from most package managers, but people expect to look at a few examples and just pick it up intuitively. It's a whole different paradigm,…

> But the official nix project has excellent documentation.

If it does, it's really well hidden. Because the nix manual certainly is not that.

> I think the problem is that nix is just hard to learn.

No, the problem is that nix offers no guidance or real help along that path. You go to https://nixos.org/learn.html and you've got essentially nothing helpful beyond the installation (which is easy enough). And it gets really bad when you get there from https://nixos.org/explore.html with no prior knowledge.

> Though Haskell folks eat it right up... no surprise there.

They're used to having to power through absent documentation?

Re: Nix and NixOS, my pain points

#104

Post by masklinn »

sunsunsunsun wrote: post #73

Been using nixos for about a month. It took me about a week to really start to grok Nix a tiny bit, I had to spend a lot of time on the forums asking questions or searching for questions because the discoverability of the documentation is low when you don't know the lingo. I'm loving it now though, I have 3 computers running it and a flake that I push to github. I can push changes to my flake and have all my systems…

> It took me about a week to really start to grok Nix a tiny bit, I had to spend a lot of time on the forums asking questions or searching for questions because the discoverability of the documentation is low when you don't know the lingo.

Do you have resources you would recommend on that front?

Having to go to forums over and over and hope a kind stranger will take pity doesn't seem scalable.

Re: Nix and NixOS, my pain points

#105

Post by Rexogamer »

delroth wrote: post #25
scoopertrooper wrote: post #22

Earlier quoted context omitted.

Why use a tutorial when ChatGPT has you covered? > How do I create a nix package that clones eMacs from GitHub and builds it from source? { pkgs ? import {}, fetchFromGitHub }: let emacsSrc = fetchFromGitHub { owner = "emacs-mirror"; repo = "emacs"; rev = "master"; sha256 = "0xabcd1234"; }; in pkgs.stdenv.mkDerivation { name = "emacs"; version = "27.1"; src = emacsSrc; buildInputs = [ pkgs.autoconf pkgs.make ]; confi…

As usual for ChatGPT this is full of mistakes and bad code. The buildPhase and installPhase it writes are completely unnecessary and worse than the default, the configurePhase might work in some cases but most likely won't, and it's unnecessary when instead autoreconfHook should be used, stdenv/autoconf should be taken as an argument for the function returning the derivation, autoconf should be a nativeBuildInput, ma…

More fundamentally, even if the code produced by ChatGPT worked and was high-quality, why should a new user have to rely on a chatbot instead of useful/up-to-date tutorials and guides?

Re: Nix and NixOS, my pain points

#106

Post by oflor »

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'…

> 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.

I think the "fuzzing" approach is actually the correct one. The fact that build systems are static does not improve reproducibility on its own, as the idea is that the packages could be built on different systems and result in the same binaries. If I built some Arch PKGBUILDs from the official community repo, I should still get the same binary, despite the fact that my machine has a different setup from the Arch project's own infra.

Re: Nix and NixOS, my pain points

#107

Post by tsuujin »

rekado wrote: post #93
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 too bad guix went full hardcore FOSS and refuses to support macs, This is either a misunderstanding or misrepresentation of the issue. We don't refuse to support Macs. Consider this: - the value of Guix is in building up a package graph all the way from the very bottom (a tiny binary seed without parallel in other distros); this uses glibc. - glibc doesn't support Darwin - the only way to build software on a m…

> … just to elevate a highly restrictive proprietary platform.

This is the attitude I’m referring to when I say “hardcore FOSS”. You can choose to see it as a judgement if you want, but I view it as an implementation detail precluding my use of Guix.

“It’s hard and it’s not worth my time” is totally fine, I don’t expect projects to cater to my needs; but it’s worth calling out that it really seems like your chief complaint is that Apple is not FOSS (aka: proprietary).

Re: Nix and NixOS, my pain points

#108

Post by rekado »

tsuujin wrote: post #107
rekado wrote: post #93

Earlier quoted context omitted.

> It’s too bad guix went full hardcore FOSS and refuses to support macs, This is either a misunderstanding or misrepresentation of the issue. We don't refuse to support Macs. Consider this: - the value of Guix is in building up a package graph all the way from the very bottom (a tiny binary seed without parallel in other distros); this uses glibc. - glibc doesn't support Darwin - the only way to build software on a m…

> … just to elevate a highly restrictive proprietary platform. This is the attitude I’m referring to when I say “hardcore FOSS”. You can choose to see it as a judgement if you want, but I view it as an implementation detail precluding my use of Guix. “It’s hard and it’s not worth my time” is totally fine, I don’t expect projects to cater to my needs; but it’s worth calling out that it really seems like your chief com…

I can't build any software for macos without signing a contract and buying their hardware. The fact that it is proprietary is the obstacle here.

Re: Nix and NixOS, my pain points

#109

Post by 40yearoldman »

masklinn wrote: post #102
40yearoldman wrote: post #101

Earlier quoted context omitted.

> First it's a distribution and a package manager Nope, it's a language, and thinking of it as those things, even more so firstly is probably part of the struggle. It's a language that you use to get your computer to do specific things. In this case, it might be a "package manager" and in the other case it could be a "distribution". When you write go or rust to print "hello world" to the terminal you don't go around…

> When you write go or rust to print "hello world" to the terminal you don't go around and call these things "printers", or "hello worlders". That is the exact reverse of the relationship between Nix and Nix. When I write in Go or Rust, a printer is a tool I might use to achieve a specific sub-part of my over-arching goal. My goal is not writing nix programs, I've got better programming languages available for that.…

> My goal is not writing nix programs

That is your issue. This is a language to write "operating systems" and "packages" it is not really a "package manager".

You use different programs and libraries to work with different systems.

>I guess I should remove nix then, since it's not a package manager and that's what I'm looking for?

Yes, I think that is the flaw, it's a language, that lets you write code that produces an output.

Post reply on HN