
A Gentle Introduction to the Nix Family (2019) - gurjeet
https://ebzzry.io/en/nix/
======
burke
If this is of interest, I’ve been publicly releasing a series of educational
Nix videos I originally recorded for developers at Shopify that you may also
enjoy:
[https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4...](https://www.youtube.com/playlist?list=PLRGI9KQ3_HP_OFRG6R-p4iFgMSK1t5BHs)

~~~
JamesSwift
I had to log in just so I could upvote and thank you for doing these! My
biggest issue with nix on MacOS (besides not grokking the DSL even after a
couple years) is that there are a decent handful of packages that dont support
Darwin. How do you handle those?

~~~
burke
Some of them actually do support darwin and we have a function in our company
overlay:

    
    
        withDarwinEnabled = drv:
        drv.overrideAttrs (oldAttrs: {
          meta = with super.stdenv.lib.platforms; {
            platforms = darwin ++ oldAttrs.meta.platforms;
          };
        });
    

but really, we've only run into a couple of things we've cared about that are
Linux-only, and just PR'd fixes upstream and duplicated them to our overlay
temporarily.

------
rq1
I use NixOS as my main OS on my Blade 15.

It was a bit confusing to set up all the bumblebee stuff to use the RTX2080 on
demand for my ML tasks (nixGL is the solution).

All my projects include a `default.nix` to start a shell with all the
necessary dependencies.

I’m very happy with it now. I’ll never look back.

------
koolba
This is a fun read. Curious how this works for large systems:

> This shell instance is special because it only contains sufficient
> information just to make GNU Hello, available. We can even inspect the value
> of $PATH, here:

> (list of 20 or so paths to binaries)

Do binary path lookups slow to a crawl when you’ve got 100s or 1000s of
separate directory paths to look through? IIUC, there’s a separate directory
added to PATH for each binary right? Which presumably would be a disk I/O to
read the file list for PATH matching for each command.

~~~
xyzzy_plugh
Good question, you can of course test this yourself with `time`.

In the case of Bash, non-built-in commands are stored in a lookup table,
exposed via the hash built-in (`help hash`). So, there should only be a one-
time performance hit per shell instance.

Generally speaking, stat'ing hundreds of directories is surprisingly quick,
most binaries do it all the time, when loading libraries for example. You can
`strace` to see the numerous file tree crawls.

------
gurjeet
I have struggled with understanding Nix package manager for a long time. I use
it on my macOS as a daily driver, but never understood the various pieces
involved for me to comfortable make changes to my configuration. `nix-env -i`
and `nix-env -e` were all I was comfortable with.

This blog post does a good job of breaking down the Nix package manager's
knowledge into decent sized chunks that one can easily understand and reason
about.

------
xena
The Esperanto translation is fantastic

~~~
senorsmile
I did not notice that at first! It appears to be complete too.

------
k__
Everyone read this!

This Nix/Guix level of package management is what every distribution should
aim for.

~~~
j88439h84
NixOS is available, not sure what other distros offer that it doesn't.

~~~
solarkraft
An easy, relatively worry free installation/out of the box experience? The
option to install uncommon software in a way that may be crappy but would work
(make install?)?

That's what's holding me back, although I'm fascinated by the concept.

~~~
chpatrick
I would say the installation experience might be a bit more involved, but once
it's installed it's much more worry-free for me. On every other distribution
I've used (including Ubuntu and co), it's very easy to break the system
completely. On Nix, it's almost impossible because you can always boot
directly into the state before your update. Once you've set up your
configuration, you can install it instantly on other machines by copying one
file. On other distributions, you would have to re-install and configure
everything by hand. Many of the tweaks for which you usually have to read Arch
Wiki are also built into Nix, so you just have to write
services.myService.myOption = foo; and you're done.

For the second point, if you've got a package that just builds with the usual
./configure, make, make install, here is all you need to get a nix package for
it:

    
    
      { stdenv }:
      stdenv.mkDerivation {
        name = "my-package";
        src = ./.;
        buildInputs = [ ... whatever dependencies you need ...];
      }
    

And the standard build commands will be run automatically. The only thing
that's kind of annoying is installing binary distributions of packages since
they need to be patched to work on Nix, but it's not the end of the world.
Also, nixpkgs is so universal that I very rarely find myself having to add a
package that's not in it.

~~~
solarkraft
Thanks!

> The only thing that's kind of annoying is installing binary distributions of
> packages since they need to be patched

This worries me, as every once in a while I do feel like using some
proprietary app. What does it even mean more precisely? What about Steam games
and such? Would it make sense to run them in a container or something like
that?

I suppose I like to use unpopular software in general. How would I use (make a
package or otherwise install) the odd go, python, js, nim, rust ... project
that is made with its own weird build system? If I made a package for it I
could very comfortably make changes to the code and directly
recompile/reinstall, right?

~~~
manveru
For Steam, NixOS actually builds a full FHS with all the packages from SteamOS
and then runs Steam within that using a simple chroot. It works surprisingly
well and can also be used for stubborn software that cannot work without FHS
and without messing up the rest of your system.

------
ShamelessC
Would love to see NixOS available as an image for Windows Subsystem for Linux.
Looks like it's been an open issue for awhile.

[https://github.com/NixOS/nixpkgs/issues/30391](https://github.com/NixOS/nixpkgs/issues/30391)

Seems someone may have figured it out -

[https://github.com/Trundle/NixOS-WSL](https://github.com/Trundle/NixOS-WSL)

------
avindroth
I love the mood in this writing

------
enriquto
> We can even inspect the value of $PATH, here:

> (...)

> Your output is going to be different from mine because of the hashes in the
> store paths.

Does this mean that a nix install is not reproducible? If the same
installation is performed twice, the file names and contents will be different
due to some randomness?

~~~
pingiun
The hashes will only be different if you install different versions of the
derivation (package). All the inputs of a derivation, so even selected plugins
and compile options influence the hash.

That said, if me and you agreed on a specific git commit of the nixpkgs repo
and build some packages from that, our hashes would be the same. This
knowledge is also used to download packages from the binary cache. You can see
the automatic building of the packages on hydra.nixos.org, from there they
will be made avaiable on the binary cache.

