Nix and NixOS, my pain points • Hacker News Board

Re: Nix and NixOS, my pain points

#81

Post by soraminazuki » Sun, Dec 25, 2022, 8:58 PM UTC

masklinn wrote: post #74

soraminazuki wrote: post #70

Earlier quoted context omitted.

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

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

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

Re: Nix and NixOS, my pain points

#82

Post by uncletaco » Sun, Dec 25, 2022, 9:28 PM UTC

tetris11 wrote: post #72

Reventlov wrote: post #4

Earlier quoted context omitted.

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.

This hasn't been true for about a year. Nonguix has a substitution server that includes Firefox and the Linux kernel.

Re: Nix and NixOS, my pain points

#83

Post by uncletaco » Sun, Dec 25, 2022, 9:31 PM UTC

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

Re: Nix and NixOS, my pain points

#84

Post by user5678 » Sun, Dec 25, 2022, 9:37 PM UTC

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…

[dead]

Re: Nix and NixOS, my pain points

#85

Post by kkfx » Sun, Dec 25, 2022, 10:10 PM UTC

viraptor wrote: post #20

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…

> Where is a proper Flake documentation? That one actually exists in the right place. (Assuming you meant the flake file) https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3...

Let's say a new user start using NixOS: where he/she find a good starting point to quickly deploy hes/shes first flake-based NixOS test desktop? Than the user want a bit more, let's say "hey, since it's damn easy let's build a custom ISO with my testing desktop config for replication. Sure some blog posts do exists, but from official docs? A third point "oh, nice, now I have a reasonably good NixOS config, a way to deploy it from a custom ISO on a local machine. What about a LAN-wide deploy?" (here is the delirium, and ok, not only for NixOS but for most OS out there, NixOS in particular have stared NixOps, but now seems a bit abandoned, Disnix is not really documented and so on).

That's why my third point is separated from the first: what's the target? The above example is what I see as a classic GNU/Linux nerdy/a bit navigated user path to NixOS for a personal usage as a desktop and for a home-lab-alike infra. For such target there is no good docs at all.

For some niche, like HPC for Guix, again there is nothing "targeted". Similarly for all NixOS use cases I can imaging.

That's why I conclude that docs was produced as a separate stuff "we need to have, not nice to made, not really useful" instead of the base to create newcomers paths to NixOS and also drive future design decisions because writing targeted docs in natural language is the best way to spot very high level logical design issues very hard to get up front discussing between devs and quickly produced code.

Re: Nix and NixOS, my pain points

#86

Post by ajb » Sun, Dec 25, 2022, 10:15 PM UTC

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…

To be fair, FHS isn't an acronym introduced by the nix project. It's not that well known though, so I do agree that it would make sense it introduce it.

More generally, it seems that the nix documentation (including the reference docs) suffer from not having been developed systematically to introduce things in dependency order.

Re: Nix and NixOS, my pain points

#87

Post by ratorx » Sun, Dec 25, 2022, 10:16 PM UTC

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.

This should be fairly straightforward with overlays (https://nixos.wiki/wiki/Overlays) right? Just overlay libc package with the version you want to use.

The main disadvantage of doing this is that you lose the binary cache and will need to rebuild your system from scratch. This will eventually be solved (content-addressable packages), but that needs reproducibility guarantees that current compilers don’t provide.

Re: Nix and NixOS, my pain points

#88

Post by steeleduncan » Sun, Dec 25, 2022, 10:31 PM UTC

scoopertrooper wrote: post #22

laserlight wrote: post #16

Earlier quoted context omitted.

By documentation, I believe people mean tutorials. At least, lack of tutorials is my complaint. I've read all introductory material. I want to build a customized version of emacs on nix, yet I have no idea how to do it or where to start.

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?

Re: Nix and NixOS, my pain points

#89

Post by masklinn » Sun, Dec 25, 2022, 10:45 PM UTC

anon291 wrote: post #80

masklinn wrote: post #79

Earlier quoted context omitted.

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…

> It's not sets... It's attrsets

You may want to tell, er, the official website? https://nixos.org/manual/nix/stable/language/index.html

> { x = 1; y = 2; } A set with attributes named x and y

> and the naming of the construct doesn't matter.

It absolutely matters when you're trying to learn the language and the naming of concepts is nonsensical.

> Pattern syntax and construction syntax are different in every functional language I know.

So you don't know Haskell?

    -- construction
    example = Person { name = "John Doe", admin = True }
    -- pattern
    render Person { name = name, admin = admin } = name ++ suffix
      where
        suffix = if admin then " - Admin" else ""

or OCaml?

    (* construction *)
    let initial_state = { lcd=0; lka=Equals; loa=Equals; vpr=0 } ;; 
    (* pattern *)
    match s with
    | { lcd = a; vpr = d; _ } -> (* Expression *)

or Rust?

    // construction
    let p = Point { x: 0, y: 7 };
    // pattern
    let Point { x: a, y: b } = p;

All three have punning (as an extension for Haskell) so you can skip the explicit rebinding, but that's not what Nix does, as far as I can tell it doesn't have punning on the construction side, doesn't have full syntax on the pattern side, and the syntaxes are just similar enough to be annoying:

    # construction
    { x = 1; y = 2; }
    # pattern
    { x, y }: x + y

> You're thinking of XQuery I think

No, I am not.

> I honestly don't understand what is surprising about the nix language.

I can only assume that's Stockholm syndrome given I literally just went through https://nixos.org/manual/nix/stable/language/index.html and found the inconsistencies listed above, also that @ patterns can go on either side (why?), or the existence of "with" (though I guess in a functional and pure language it's not as bad as it is in good ol javascript with which it shares this great feature).

And it's not that it's "surprising", it's just that it's... sloppy. Sub-par.

And definitely not "intuitive". Even less so when a pair of single quotes is equivalent to a double quote (except not), rather than either an empty string (or at least something string-like), or an error. To say nothing of the escaping scheme inside those string literals.

Re: Nix and NixOS, my pain points

#90

Post by zaphar » Sun, Dec 25, 2022, 10:49 PM UTC

anon291 wrote: post #80

masklinn wrote: post #79

Earlier quoted context omitted.

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…

No,he is correct when he says XSLT. It's a pure functional language with a terrible syntax.

Nix as a language is fine. There isn't actually much to it. However the extreme approach to laziness while quite powerful also means you can't actually follow the flow of a package. It's manifests as come from programming since with stuff in packages with no reference in yours messing with your own packages internals. It is possible to tease it out and after a while you sort of know where stuff is probably coming from. But even for someone who is pretty comfortable with Haskell and other poster children for FP, nix is a challenge to reason about code locally.