[HN Gopher] Nix journey part 0: Learning and reference materials
       ___________________________________________________________________
        
       Nix journey part 0: Learning and reference materials
        
       Author : rrampage
       Score  : 56 points
       Date   : 2023-03-01 19:26 UTC (3 hours ago)
        
 (HTM) web link (tinkering.xyz)
 (TXT) w3m dump (tinkering.xyz)
        
       | Chatter9220 wrote:
       | So, I don't quite grok nix.
       | 
       | Am I supposed to use it instead of Ansible and Terraform? Where
       | does it fit exactly?
        
         | zach_mitchell wrote:
         | You can use as much or as little of it as you want, which I
         | know is not a satisfying answer.
         | 
         | I think the most common use case is as a build system, but in
         | this context you aren't limited to building packages, you can
         | also build "environments". By "environments" I mean a shell
         | with certain packages available in `$PATH`. You would use Nix
         | like other build systems in the sense that you specify the
         | build requirements (which other packages, libraries, etc you
         | need to build _your_ stuff), then you specify how exactly to
         | build your stuff. Here "stuff" could be as little as a shell
         | script or as much a huge monorepo.
         | 
         | There are ways to use Nix like you would use Ansible or
         | Terraform, but I wouldn't say that's the mainstream use case of
         | Nix.
        
         | tomberek wrote:
         | Nix is a package manager. But it can weave together multiple
         | package managers so it frees you from being locked in to any
         | one particular language, OS, architecture. The proof of this
         | that we also ended up making a full OS (NixOS). Then there are
         | follow-on things one can do, such as using it to manage the
         | configuration of things and people continue to build more tools
         | for this.
         | 
         | Fundamentally the core technology is for it to be a correct and
         | safe package manager. (eg: think about the engineering
         | tradeoffs for memory-safety vs anything-goes) Once you have
         | that basic primitive, lots of things can be "packages":
         | software, data, configuration, dotfiles,......
        
         | strogonoff wrote:
         | To me, Nix is about content addressing.
         | 
         | It is possible to "hash" a function so that the hash stays the
         | same for as long as the function does the same thing (in which
         | sense the language is similar to, e.g., Dhall), which is
         | guaranteed because 1) function is pure, 2) the hash derives
         | also from any other functions it may call and all the way down,
         | and 3) everything is a function.
         | 
         | In the world of package management that gives you a superpower
         | and/or curse of being able to say "I want dependency X" and
         | mean "I want a dependency built in this exact way". When
         | applied thoroughly, the only inconsistencies in behavior that
         | can arise in theory would be due to logic errors in external to
         | Nix software or to hardware issues[0].
         | 
         | From provisioning deployed software runtime environments (in
         | which sense Nix is more similar to, e.g., Docker) to automating
         | your development machine configuration--basically anywhere you
         | want consistency and hate surprises--in this sense Nix suffers
         | from solving very different problems for different people, and
         | as a result people being confused as to what is it for just by
         | looking at articles and discussion threads about it.
         | 
         | [0] In practice, you might occasionally have to fight poorly
         | behaved software that makes unwarranted assumptions about the
         | system (can't be installed into or look for dependencies under
         | hash-paths), modifies itself (auto updates), etc.
        
         | dlyons wrote:
         | I'm a consultant and jump around different stacks, or have to
         | grok some new thing pretty quickly. Nix helps me with my
         | personal dev environment. I also generally prefer functional
         | style of doing things, declarative, immutable, etc.
         | 
         | Nix is so easy to share across machines (including Mac) that it
         | ends up being pretty cool when you pair it with something like
         | syncthing. I can jump around, get up to speed with something
         | new, and have it everywhere without much setup now that my
         | machines share some Nix code and data.
         | 
         | Mac support is pretty great with nix-darwin; I'm able to update
         | my flake, run nix-build and my terminal/system level apps, Mac
         | app store apps, homebrew apps, and dock shortcuts all get
         | updated at once. My dock points to apps in the Nix store. Sure
         | I could do that with some scripts, but Nix ends up being way
         | more robust.
         | 
         | I also still use Emacs and the community emacs-overlay is
         | pretty awesome.
         | 
         | But after you're up and running, Nix makes all this stuff
         | _generally_ seamless is my point. There have been times I can
         | 't update due to some upstream thing, but 80% of the time it's
         | fixed for me in nixpkgs a few days later.
         | 
         | nixpkgs has like 80,000+ packages the last time I looked, and
         | is growing.
         | 
         | I haven't had a use case to stray outside of Docker + terraform
         | for my work related stuff, but it's amazing for sharing dev
         | environments on a team. Flox is a new thing to check out
         | 
         | My repo if it helps anyone get started:
         | https://github.com/dustinlyons/nixos-config
        
         | xyproto wrote:
         | Without having properly tried it either, my general impression
         | is that the pitch goes a bit like this:
         | 
         | If you love Haskell and wants to make everything that has to so
         | with packages on your system more like Haskell, Nix's got your
         | back.
        
           | aliasxneo wrote:
           | Because it's functional? I've been using Nix in production
           | for six months and I have no desire to learn Haskell.
        
         | JamesSwift wrote:
         | It is a powerful abstraction that ends up being a replacement
         | for several kinds of tools depending on your use case.
         | 
         | It can be a way to declaratively configure a system similar to
         | ansible.
         | 
         | It can be a way to isolate runtimes (e.g. ruby v2.8 and ruby
         | v3.0) in different projects similar to rbenv / virtualenv.
         | 
         | It can be a way to define an application in a self-contained
         | way so that the target platform needn't have needed software
         | installed beforehand similar to docker.
         | 
         | It can be a way to install packages/software to your system in
         | a well-defined way similar to many package managers.
        
         | clhodapp wrote:
         | I'll take a stab and say that I believe that nix's actual power
         | is to efficiently materialize an exact tree of files (raw or
         | generated) on any machine. By "exact", I mean in a fully
         | reproducible way.
         | 
         | That capability turns out to be really powerful because you can
         | materialize a program, a whole Unix tree, or even a script that
         | converges the current host to a desired state.
        
         | kenmacd wrote:
         | My use case:
         | 
         | I used to use Arch. I would always do a btrfs-snapshot before
         | doing a system upgrade, then create another one after booting
         | the new update (provided everything worked). In NixOS I don't
         | have to because it has generations. The upgrade is entirely
         | atomic and if it doesn't work I just use a previous generation.
         | 
         | Second I used to use pyenv and bunch of other tools to make
         | sure I had the right development dependencies. Instead I just
         | put the requirements in a shell.nix or flake.nix in the project
         | directory, have those called with direnv. Now I can easily have
         | python38 with clang_11 for one project and python311 with gcc48
         | for another.
         | 
         | Third the system of modules generally makes it easy to have my
         | system setup in one place, and with the services I want. If I
         | want zram, I just set `zramSwap.enable = true;` and that works.
         | If I need ssh access: `services.openssh.enable = true;`, oh,
         | but I have the firewall enabled (networking.firewall.enable =
         | true;), that's okay because services.openssh.openFirewall
         | defaults to true, so it handled automatically. And if I change
         | services.openssh.ports to a better port, the firewall will be
         | updated too.
        
       | julianeon wrote:
       | It feels like Nix is crossing some kind of developer awareness
       | threshhold. For me as someone perusing various tech threads, this
       | feels like the year that, among developers, Nix is going
       | mainstream.
        
       | coldblues wrote:
       | My current objective is to make an easy and reproducible
       | configuration + live image installer. I want to automate the
       | whole process. As soon as I plug in the USB stick, my preferred
       | defaults should do their work without user input.
       | 
       | Although, I really don't like Nix as a language. I really wish it
       | would have used something like GNU Guile. Searching deep for
       | nuggets of information isn't nearly as painful as the language
       | itself. I might adapt to it in time, but still.
        
         | tomberek wrote:
         | Can you clarify what parts you don't like. I think it's
         | important to distinguish so I know what portions to work on
         | (and figure out how to fix it). Is it: the language syntax
         | itself, the idioms used in Nixpkgs, the module system, the
         | common frameworks used to create package sets, or something
         | else?
        
         | mr337 wrote:
         | Not for sure if you are working on SD card based things but
         | this might get you half way there. We do this for loading RPIs
         | https://github.com/Robertof/nixos-docker-sd-image-builder
        
         | Ericson2314 wrote:
         | https://github.com/NixOS/rfcs/pull/136 soon, you shouldn't have
         | to care what language it uses!
        
         | schemescape wrote:
         | Did you mention Guile because of Guix? If not, you might be
         | interested in GNU Guix.
        
       | zach_mitchell wrote:
       | Author here if anyone has questions
        
         | clem wrote:
         | Any good resources on how to use flakes? I'm currently
         | experimenting with having home-manager work via a flake but I
         | haven't come across any good HOWTOs on common operations. For
         | example, I'd like to update the flake dependencies similar to
         | how I used to use "nix-channel --update" to freshen the
         | dependencies used by home-manager.
        
           | zach_mitchell wrote:
           | Here you go:
           | 
           | https://nixos.wiki/wiki/Flakes
           | 
           | https://tonyfinn.com/blog/nix-from-first-principles-flake-
           | ed...
           | 
           | The second link appears to be down at the moment so check
           | back later.
        
             | tonyfinn wrote:
             | [dead]
        
           | SkyMarshal wrote:
           | https://www.reddit.com/r/NixOS/comments/v2xpjm/big_list_of_f.
           | ..
        
           | Filligree wrote:
           | "nix flake update" should be able to do that.
        
           | JamesSwift wrote:
           | This is a script I run every monday when I come into work to
           | get the latest updates on my system [1]. It prints the flake
           | hash when it runs, so I can also rollback if there are
           | issues.
           | 
           | [1] - https://gist.github.com/J-Swift/a4dad59843f1a1f512a7230
           | 8031b...
        
       | pikanix wrote:
       | regarding function docs, https://noogle.dev/ is a new search tool
       | to that effect
        
       | peter_l_downs wrote:
       | The nix package search website is OK, but it doesn't let you
       | filter by the names of installed binaries. A lot of the time, you
       | have a question like "what nixpkgs attribute do i install in
       | order to get the `python3` command". I recently wrote a command
       | line tool that allows you to do this. It uses the same
       | elasticsearch index as the search website, but allows more
       | powerful filtering. If anyone is thinking of getting into nix,
       | please consider trying it out!
       | 
       | https://github.com/peterldowns/nix-search-cli
        
         | zach_mitchell wrote:
         | I've also noticed this. If you install `rustc` it says that you
         | get `rust-gdb`, but that's really just a wrapper script around
         | `gdb`, which it doesn't install.
        
       ___________________________________________________________________
       (page generated 2023-03-01 23:00 UTC)