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

71–80 of 109 posts

Re: Nix and NixOS, my pain points

#71

Post by tsuujin »

40yearoldman wrote: post #3
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 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…

My complaint is chiefly about practical implementation. “I want to use nix as a package manager across systems” is far too difficult for a new user.

One document tells you to flakes, another tells you that it’s experimental and should be avoided.

One document tells you that you should use Darwin modules and home manager, and then completely omits the fact that the linked home manager scripts don’t work with Darwin by design leading to “why the fuck isn’t this file they tell me should be auto generated not being created”.

Because the official docs don’t seem to cover real world use cases, you end up relying on a labyrinth of out of date and conflicting user contributed tutorials and it is very frustrating.

Once you know what to do nix is simple enough, but learning what to do is outright painful; if you don’t believe me look to the other replies to my comment.

Re: Nix and NixOS, my pain points

#72

Post by tetris11 »

Reventlov wrote: post #4
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 agree with the Guix bit. At some point, I tried using Guix System on my laptop (with wireless support), and of course I was greeted with « use a wifi card that respect your freedom » or something of the sort. At some point, I might try again, using NonGuix ( https://gitlab.com/nonguix/nonguix ), but right now I'm not using Guix SD. Instead, I try to use Guix on small projects (like building websites using pelican),…

A caveat with nonguix: there aren't any binary repos, so you have to compile Firefox from the scratch.

Re: Nix and NixOS, my pain points

#73

Post by sunsunsunsun »

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 reflect the changed with a quick nixos-rebuild. Also being able to roll back is invaluable.

I reformatted one of my systems the other day and it only took about an hour to have my whole system in the exact same state it was before with all my tooling and files.

Re: Nix and NixOS, my pain points

#74

Post by masklinn »

soraminazuki wrote: post #70
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…

> Is that useful? I'm sure to somebody who already knows what they want out of nix it is, but the first thing I'm told is that shell environments exist and are useful to "use the tool without having to install the software.". Ok, but what if I want to install the software? Why would you go to https://nixos.org/learn.html , click on an introductory example titled "Ad-hoc developer environments" and complain that it do…

> Why would you go to https://nixos.org/learn.html, click on an introductory example titled "Ad-hoc developer environments" and complain that it doesn't explain how to permanently install software?

Because it's also the one labelled "First Steps with Nix". As in, the big orange button which immediately follows "Install Nix", and the second thing the Nix community apparently wants me to do to learn nix.

I literally did three things: I opened the nix website, I clicked "learn" (it's also what you get when you click "getting started" from the front page by the way), assumed I'd installed nix (I did check if there was seemingly critical information there, there isn't) then I clicked the following step.

I'm not quite sure what you'd want me to do.

> Again, you're pointing to a page containing TLDR examples. That's not the right place for an in-depth explanation.

I'm not asking for an in-depth explanation, I'm asking for pointers to the surface basics. The page tells me that "we’ll cover that in later tutorials" but I've no idea where those are, and none of the 5 links listed in the "next steps" seems helpful in any way. The least unpromising one ("Nix language basics") certainly didn't tell me anything about python.withPackages.

And again it's not "a page containing TLDR examples", it's what the website told me to start with.

> No surprise because you missed the entire manual.

The manuals which are at the bottom of the page (so one would assume the things to check after the one at the top of the page)?

And which are if anything even worse? The first one ("Nix Manual") goes directly from "you can upgrade packages" and "nix lets you rollback profiles" to "the nix language" to "advanced topics: remote builds".

I still have no answer to any of my question, but now I know that I can configure how many cores Nix will use when it builds derivations.

I still don't know what a nix project is or why I would want one, why I would want a derivation, though the manual does tell me they're important (why?)

Re: Nix and NixOS, my pain points

#75

Post by pshirshov »

viraptor wrote: post #65
pshirshov wrote: post #50

Earlier quoted context omitted.

> This ... seems entirely reasonable, though? Yeah. It's better to spend more time repeating "read the guidelines" instead of fixing the commit message. And of course it's better to keep critically vulnerable packages (netatalk, potential remote code execution) for months and piss off the maintainer (not me) instead of turning on the autosquash.

This may be annoying, but it makes sense at scale. If you learn the rules, you'll do it right the next time. If I fix commits, I'll handle a fraction of the PRs I could otherwise - and submitters will learn that anything goes (And I am still fixing the most trivial issues) For security issues, mentioning cve gives the pr a security tag which helps speed thing up.

I'm not a full-time nixpkgs developer being paid for that. I'm willing to make occasional contributions but won't if it costs me too much. If it's cheaper to maintain a private fork I would do exactly that.

Re: Nix and NixOS, my pain points

#76

Post by pshirshov »

gtaylor wrote: post #58
pshirshov wrote: post #48

Earlier quoted context omitted.

> can't be any further Probably you are lucky. > always free to submit I did. The problem is that in this particular case there is one guy with merge rights who doesn't want to update a package because it breaks something for him so the package is outdated by years. He provided me an excerpt from his logs and said that the update doesn't work for him. Period. They don't even think that the outdated package doesn't wo…

Which package was it?

Not so popular one. Doesn't really matter because the annoyances happen on regular basis.

Re: Nix and NixOS, my pain points

#77

Post by hamandcheese »

viraptor wrote: post #66
toastal wrote: post #46

Earlier quoted context omitted.

I can say I've had merge requests denied because I used the title "xxx: init @ 1.0.0" instead of "xxx: init at 1.0.0", but when upgrading packages you must use a symbol, either "->" or "→", but initialization doesn't allow a symbol. Nitpicky but fine, I update the commit title and I wait 2 months for approval+merge. There's also a long disconnect between approved vs. merged in general; I currently have 2 or 3 merge r…

The pr naming is strict, because a lot of the ci and automatic processing depends on correctly named commits. And you do want them to run well.

Seems like the naming should be its own CI check (or a comment bot or something) rather than result in rejection by a human.

Re: Nix and NixOS, my pain points

#78

Post by viraptor »

pshirshov wrote: post #75
viraptor wrote: post #65

Earlier quoted context omitted.

This may be annoying, but it makes sense at scale. If you learn the rules, you'll do it right the next time. If I fix commits, I'll handle a fraction of the PRs I could otherwise - and submitters will learn that anything goes (And I am still fixing the most trivial issues) For security issues, mentioning cve gives the pr a security tag which helps speed thing up.

I'm not a full-time nixpkgs developer being paid for that. I'm willing to make occasional contributions but won't if it costs me too much. If it's cheaper to maintain a private fork I would do exactly that.

That's the thing though - almost nobody is. Neither are the people merging the PRs, and while there's significantly fewer committers than contributors, the current setup just makes sense at scale. I'm not saying it's a good end result, just the most efficient at the time.

Re: Nix and NixOS, my pain points

#79

Post by masklinn »

anon291 wrote: post #55
xrd wrote: post #51

I agree with all the points in this post. And, I love NixOS. It's really special and very different than the other Linux I've used for 20 years. I have been curious to try Guix at some point. Does anyone know if there is a good comparison write-up? Also, can anyone speculate why the community has had such a hard time documenting this incredible technology? There are great posts like this from Xe: https://xeiaso.net/…

Realistically, the nix community is made up of a lot of functional programmers. I realize the nix language seems confusing to many, but to fp programmers, it's intuitive and there's not a whole lot to say about it.

The main problem of nix is not even the nix language, though I've heard little good around its error handling and debugging. My admittedly shallow understanding is also that it doesn't matter that much because most of your time will be spent in the sprawling mess of nixpkgs.

> it's intuitive

The naming is very odd (e.g. why "sets" for dicts / records), and then it manages to make the language incompatible with itself by having attribute sets for values and a completely different syntax for attribute set parameters, no doubt because the language was ambiguous due to the lack of function prefix (also makes curried functions awkward).

Like, there's nothing hard to it, but the entire language feels awkward for no reason. Like "?" meaning "default value" in parameters but "has attribute" for navigation (where "or" is "default value").

> I realize the nix language seems confusing to many, but to fp programmers, it's intuitive and there's not a whole lot to say about it.

XSLT is also a functional language. That doesn't make it not-awful.

Re: Nix and NixOS, my pain points

#80

Post by anon291 »

masklinn wrote: post #79
anon291 wrote: post #55

Earlier quoted context omitted.

Realistically, the nix community is made up of a lot of functional programmers. I realize the nix language seems confusing to many, but to fp programmers, it's intuitive and there's not a whole lot to say about it.

The main problem of nix is not even the nix language, though I've heard little good around its error handling and debugging. My admittedly shallow understanding is also that it doesn't matter that much because most of your time will be spent in the sprawling mess of nixpkgs. > it's intuitive The naming is very odd (e.g. why "sets" for dicts / records), and then it manages to make the language incompatible with itself…

> The naming is very odd (e.g. why "sets" for dicts / records), and then it manages to make the language incompatible with itself by having attribute sets for values and a completely different syntax for attribute set parameters, no doubt because the language was ambiguous due to the lack of function prefix (also makes curried functions awkward).

It's not sets... It's attrsets, and the naming of the construct doesn't matter. I'm not sure I called them anything until I looked it up just now.

As for syntax... I'm not sure what you're referring to. Pattern syntax and construction syntax are different in every functional language I know.

> XSLT is also a functional language. That doesn't make it not-awful.

You're thinking of XQuery I think

Nix broadly borrows exactly everything from the lambda calculus, with no change in terminology. It introduces records, which is kind of necessary for any serious programming. It adopts standard conventions for records (curly braces and an equal sign). The only 'surprising' bit of syntax is the lambda construct, but this is such a minor thing it's almost silly to complain about it. I honestly don't understand what is surprising about the nix language.

Nixpkgs... sure I can see that, and I actually agree that types would be nice. Or at least interfaces. But the nix language as a whole is pretty straightforward.

Post reply on HN