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

91–100 of 109 posts

Re: Nix and NixOS, my pain points

#91

Post by cwp »

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, with a custom programming language that also has a different paradigm. (Though Haskell folks eat it right up... no surprise there.)

It's gonna take time and effort to learn it, and there's just no way around it.

Re: Nix and NixOS, my pain points

#92

Post by masklinn »

soraminazuki wrote: post #81
masklinn wrote: post #74

Earlier quoted context omitted.

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

I still don't get why "first steps with Nix" has to include installing packages permanently. Making persistent changes is exactly the kind of thing that is better avoided before users have had the chance to learn anything. > And again it's not "a page containing TLDR examples", it's what the website told me to start with. So the website recommended you to read a page containing introductory examples. Not sure why you…

> I still don't get why "first steps with Nix" has to include installing packages permanently.

Because if I don't know nix (which, you know, would be why I'd be reading introductory material) I'd be looking to use it, and my basis would be to do would be the way every other distro works.

And if I have to type `nix-shell -p python38` every time I want to run Python and `nix-shell -p vimMinimal` every time I want to edit a file, the experiment is not going to last long.

> So the website recommended you to read a page containing introductory examples. Not sure why you insist otherwise.

I'm not "insisting otherwise", I'm observing that it's confusing, utterly useless, and provides no real guidance towards improvement. And it's where the site told me to go as my second step into nix.

But apparently you're perfectly happy that this is what the "first steps with nix" should be (after having berated me for going there), so... proving the point I guess.

> What? The there are far more chapters in the Nix manual than just the three you mentioned.

Have you actually looked at them? ever?

1 is a quick overview of the entire thing, none of it actually helpful.

2 is a few basic commands expanded upon in (4)

3 is a lot of time spent on installation details

4 is where the meat starts, "You can upgrade package" is 4.1, "profiles are a thing" is 4.2, 4.3 is "nix will eat your disk space" (useless to a beginner), 4.4 is "channels" (even worse), 4.5 is "sharing packages between machines" which could not be less useful at this point./

5 is, as I said, "the nix language" covering the basics, with 5.4 mentioning derivations and going into plenty of details, none of them actually useful or telling a beginner why they should care

Following which we reach 6.1 "remote builds.

From a beginner's perspective, tits on a bull are at least funny, the nix manual doesn't even have that going for it.

Have a nice day, I'm done wasting time on you.

Re: Nix and NixOS, my pain points

#93

Post by rekado »

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 mac is to sign an EULA and use proprietary software (Xcode and the SDK).

It's easier to build software for Windows than for a Mac. If it was about "full hardcore FOSS" (what a weirdly judgmental term!) then we wouldn't support building for WSL or cross-compilation to mingw64, but we do.

Personally, I have no interest in working my ass off to get a subpar implementation of the package graph grafted on top of a huge binary blob (Xcode and the SDK) just to elevate a highly restrictive proprietary platform.

Until Apple commissions this kind of work it is still preferable to just use Guix in a virtualized GNU system.

Re: Nix and NixOS, my pain points

#94

Post by rekado »

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

> for example allowing to specify environment variables in manifest.scm files.

Just use setenv in the manifest:

(setenv "MAMA" "MIA") (specifications->manifest (list "hello"))

Then `guix shell -m this-file.scm` enters a shell session where "hello" exists and the env var MAMA is set to "MIA".

Re: Nix and NixOS, my pain points

#95

Post by rekado »

Reventlov wrote: post #10
sierkov wrote: post #9

Earlier quoted context omitted.

> for example allowing to specify environment variables in manifest.scm files. There is already .envrc or .dir-locals.el? And manifest is just - well - manifest. By definition it has to be 'plain'. I mean, there are already a million ways to load env vars so why'd you want guix to do that too and from manifest.scm of all places?

Because instead of distributing two files (channels.scm and manifest.scm, or flake.lock and flake.nix), you have to execute monstruosities like `guix shell --container -m ./manifest.scm -- bash -c 'GUIX_LOCPATH=$GUIX_ENVIRONMENT/lib/locale LC_ALL=fr_FR.utf-8 exec jekyll build'`, which is how I build some websites I have. To me, that's not ok from an user experience point of view.

Use `setenv` inside the manifest.

    (setenv "MAMA" "MIA")
    (specifications->manifest (list "hello"))

Re: Nix and NixOS, my pain points

#96

Post by uncletaco »

uncletaco wrote: post #83
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/…

I don't think Xe's posts are all that great. The stuff they complain about are a result of not knowing what Doom Emacs does for them (because Henrik Lissner uses NixOS personally and has added a lot of convenient functionality to the nix module).

It's too late to edit but I'm speaking specifically about their guix/gnu posts. Otherwise they're fantastic to read.

Re: Nix and NixOS, my pain points

#97

Post by soraminazuki »

masklinn wrote: post #92
soraminazuki wrote: post #81

Earlier quoted context omitted.

I still don't get why "first steps with Nix" has to include installing packages permanently. Making persistent changes is exactly the kind of thing that is better avoided before users have had the chance to learn anything. > And again it's not "a page containing TLDR examples", it's what the website told me to start with. So the website recommended you to read a page containing introductory examples. Not sure why you…

> I still don't get why "first steps with Nix" has to include installing packages permanently. Because if I don't know nix (which, you know, would be why I'd be reading introductory material) I'd be looking to use it, and my basis would be to do would be the way every other distro works. And if I have to type `nix-shell -p python38` every time I want to run Python and `nix-shell -p vimMinimal` every time I want to ed…

First of all ...

> after having berated me

Wow, I must be a terrible person, except I never recall berating you. I double checked, and it's just me expressing my disagreement. I'm not the one saying things like "It's like the nix community saw how git is taught and went 'we can do worse'" or "I'm done wasting time on you."

> Because if I don't know nix (which, you know, would be why I'd be reading introductory material) I'd be looking to use it, and my basis would be to do would be the way every other distro works.

Nix isn't a drop-in replacement of apt or yum. It's possible to use it like one, but that would be missing the whole point. Most of the benefits of Nix is obtained by writing configuration files tailored for each project you're working on. That's another reason why the examples don't start off with a replacement of "sudo apt install". Creating localized development environments is one of the primary use cases of Nix.

> Have you actually looked at them? ever?

Of course I did. I read the entire manual when I learned Nix. That's why I get the impression that your summary of the Nix manual makes it look more distorted than it actually is.

For example:

> 1 is a quick overview of the entire thing, none of it actually helpful.

The said overview includes instructions for installing packages permanently. You clearly stated that is what you were most interested in, so it actually should've been helpful for you.

Re: Nix and NixOS, my pain points

#98

Post by tadfisher »

steeleduncan wrote: post #88
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…

> sha256 = "0xabcd1234"; Am I right in assuming this is a ChatGPT misunderstanding, or is it a wildcard SHA256 in nix to allow any download?

Definitely not a wildcard, such things are not allowed. You can fetch at evaluation time with the built-in fetchers (builtins.fetchgit, builtins.fetchTarball, etc) and not provide a hash, which makes the expression "impure", which means the expression wouldn't be acceptable in nixpkgs and it has consequences for flakes.

Re: Nix and NixOS, my pain points

#99

Post by YoshiRulz »

guilhas wrote: post #17

> The documentation of Nix and NixOS is rather poor. To understand how a service or an option works, it is very often necessary to read the source code (`.nix’ files) ... I think this is also a plus point, for Guix and Nix, how easy you can check the parent file dependencies, which are the same language as the configuration you're creating, and are easy to understand

Except in Nixpkgs, where it's tedious to go from the package's expression (easy enough to find from NixOS Search) to where it's called in `all-packages.nix` or to the various helpers exposed in `lib`. But there are multiple efforts to make jumping to declarations easier in the new CLI and even to rearchitect Nixpkgs.

Re: Nix and NixOS, my pain points

#100

Post by YoshiRulz »

kkfx wrote: post #14

My very personal main pain point is documentation: Nix/NixOS do have some, but mostly or too little or deprecated. Where is a proper Flake documentation? Where is a proper $newNixFeatureInVogueNow? The second pain point is: Nix might sound nice to read and write as a language for Haskellers, but most people actually aren't haskellers... The third is essentially the fists, more specified: target. If the target is desk…

Counter-anecdata: I took to Nix very easily, including its more Functional aspects, despite my little prior experience with FP and 0 experience with Haskell specifically.
Post reply on HN