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

61–70 of 109 posts

Re: Nix and NixOS, my pain points

#61

Post by nalllar »

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…

The dev shell inherits environment, but the builds don't. Having a dev shell inherit none of your environment is possible but an inconvenient default, you can do this with `--ignore-environment`.

`nix build .#somePackage` is pure by default, as is `nix flake check`

I believe `nix shell` also inherits environment by default for the same reason. People expect to be able to run the packages they installed system wide after entering a shell.

Re: Nix and NixOS, my pain points

#62

Post by trynewideas »

nrabulinski wrote: post #12
viraptor wrote: post #6

> When we use NixOS, and we want to use a package that is not available under NixOS / Nixpkgs (which happens quite often), we have only one choice: pack it into NixOS. That's not the only way. It's definitely the easiest option, but you can also create a temporary fhs environment https://github.com/ElvishJerricco/nixpkgs/commit/05742c15d5a...

What’s even easier is using steam-run which is technically intended to run games which expect FHS environment on NixOS, but it works excellent to run any binary which was built on another distro

Toward the docs point, nowhere in the Nix manual do they spell out the FHS acronym. It's just the Linux derivation of the standard Unix filesystem structure, something that I never knew had a formal name (Filesystem Hierarchy Standard) or centralized authority.

That kind of re-emphasizes to me that regardless of the value Nix might offer me, I'm not and probably won't ever be the audience for it, because if it assumes I know that well enough to recognize it by acronym then it's going to assume I know a lot more than that. I can look forward to a few months of Googling and tangents just to get a grip on its fundamentals.

Re: Nix and NixOS, my pain points

#63

Post by pca006132 »

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

Perhaps because there isn't really a starting point for this?

Different people use nix for different things, perhaps a bit differently (e.g. whether they use flakes, home-manager, what channels do they follow). Each language has their own way of building packages, and different 'framework' in nix to build for them (usually about how to pull the dependencies in a reproducible way). And there are things that readers are expected to know such as basic shell scripts, paths, etc.

Re: Nix and NixOS, my pain points

#64

Post by soraminazuki »

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…

Nix actually has far better than average documentation compared to other typical open source projects. I started using Nix years ago on Ubuntu to quickly install a package that wasn't present in Ubuntu's repository. Eventually, I began customizing packages using Nix expressions. Before I knew it, I migrated my existing systems over to NixOS. What I can say is it wasn't at all the uphill struggle that's associated with Nix in online discussions. Even though the documentation isn't perfect and going through active improvements, there's a considerable gap between Nix's reputation regarding documentation and my own actual experience.

What surprises me is that people tout RPM/Chef as easier replacements to Nix/NixOS. The assumption about those being "replacements" of each other is questionable because they address different needs. What's even more questionable is the part about RPM or Chef being easy. I have dealt with those two for years as part of my day job, and they're both far from easy. I still have troubles with them to this day. Documentation is far more lacking than Nix, and it's not because things are obvious. If you encounter any trouble, you almost always have to dive into the source code. Navigating the source code of RPM or Chef is a nightmare because the code is scattered across countless different repositories and it's impossible to guess where to look for to begin with. Choice of programming languages doen't help here too. Chef is written in Ruby, which has a tendency of making code ungreppable due to its metaprogramming features. RPM has its own macro syntax which works similar to the C preprocessor. It's very terse and full of gotchas. Navigating around Nix code is much, much easier in comparison. Everything you need is in a single repo, https://github.com/NixOS/nixpkgs, and written in a JSON-like language.

Many people also claim that Nix is hard because it requires a functional programming background. That too doesn't match my experience. Nix expressions are basically JSON with functions. Learning the syntax is a non-issue if you know JSON and some common programming language constructs like conditionals, functions, map, filter and reduce. The only functional programming exposure I had prior to Nix was LISP, in a university classroom. Yet I didn't experience problems learning the syntax. The hard part is learning how to actually utilize the language. The documentation and some grepping around of the Nixpkgs codebase helped a lot with this.

Re: Nix and NixOS, my pain points

#65

Post by viraptor »

pshirshov wrote: post #50
rgoulter wrote: post #29

Earlier quoted context omitted.

> Nope, your time isn't valuable because there are too many of you and just one nix. This ... seems entirely reasonable, though? As you point out, having to do extra work on behalf of others isn't desirable. -- If a pull request is made and the maintainer(s) don't like it, the options are "reject it", "maintainer puts in extra work to accept it", "pull request author puts in extra work to get it accepted". With as ma…

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

Re: Nix and NixOS, my pain points

#66

Post by viraptor »

toastal wrote: post #46
pshirshov wrote: post #21

Earlier quoted context omitted.

Normal flow in other distros I contributed to: "thanks for the patch, we'll do the rest". Nix flow: your patch is not done according to our guidelines, so fuck off. Still not. Still not. Read the guidelines. Still not, read the guidelines. You have to squash commits manually, we won't enable autosquashing because someone important doesn't like them. Nope, your time isn't valuable because there are too many of you and…

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.

Re: Nix and NixOS, my pain points

#67

Post by [deleted] »

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…

[deleted]

Re: Nix and NixOS, my pain points

#68

Post by tsuujin »

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),…

Nonguix is new to me. I may give it a look at some point but I’m already over the pain threshold on nix.

Any idea if nonguix will allow an install on macOS? I really want a system like this that I can use on my work MacBook and remote Linux servers.

Re: Nix and NixOS, my pain points

#69

Post by viraptor »

trynewideas wrote: post #62
nrabulinski wrote: post #12

Earlier quoted context omitted.

What’s even easier is using steam-run which is technically intended to run games which expect FHS environment on NixOS, but it works excellent to run any binary which was built on another distro

Toward the docs point, nowhere in the Nix manual do they spell out the FHS acronym. It's just the Linux derivation of the standard Unix filesystem structure, something that I never knew had a formal name (Filesystem Hierarchy Standard) or centralized authority. That kind of re-emphasizes to me that regardless of the value Nix might offer me, I'm not and probably won't ever be the audience for it, because if it assume…

You can't describe everything every time, at some point you need to use more concise naming for better communication. While it would be nice to improve things for beginners, this one seems pretty good already. Searching for "nix standard directory layout" brings up relevant blogs along with a Wikipedia page for FHS. Not bad.

Re: Nix and NixOS, my pain points

#70

Post by soraminazuki »

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…

> 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 doesn't explain how to permanently install software?

> but there's no real explanation to give me knowledge to expand upon

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

> There's not just a step missing here, there's an entire floor, possibly building. It's like the nix community saw how git is taught and went "we can do worse".

No surprise because you missed the entire manual.

Post reply on HN