Almost every time I see nix get brought up, one of 3 replies come up.

1. I love it! It’s the best distro ever!!
2. I don’t know, Nix seems like a lot of hype & difficult to learn
3. Why would you use Nix? We already solved all these problems.

Preamble

I’ll be covering the 2nd and 3rd points in this article. One thing I want to say now before I start explaining the points, I do not think everyone should be using NixOS. Nixos is for people who enjoy tinkering and setting up their computer from the ground up. If you enjoy setting up Desktop Linux with hardly anything preinstalled, you could be a candidate for enjoying NixOS.

As a server, NixOS is a lot more palatable. It’s almost like a fancy docker compose file to set up an entire server environment. The configuration can be as minimal or complex as you want to make it. It has a lot of merit and could be considered as a serious distro to rely on for servers.

“Nix Seems Too Hard”

Syntax

The hardest part with getting started with nix in my opinion is learning the syntax. I will be covering this in detail in my next blogpost, but it’s not documented very well. For example, you will see configuration examples that seem to be freely mixing { };[ ];[{ }{ }]; which at first seems arbitrary and confusing. Especially if you don’t have experience in basic programming languages. And I don’t believe it’s detailed in documentation, you’re supposed to infer what to use based on the source code, or type of information you’re entering. Again, I won’t detail this now, but I do recognize that it’s a huge pain point. It took me a while to be able to freely type into config files without really thinking about it.

Where’s The Binaries?

The next glaring issue that makes Nix difficult is you can’t just download and run a binary. I say that despite the fact you can with minimal steps. However it’s an important thing to recognize with how nix works. In fact, if you check the /usr/bin dir, you’ll just see this:

[celer@akagi:~]$ ls /usr/bin
env

This ties into the whole binaries being unlaunchable by default. The actual programs to execute the program are stored in /nix/store/

celer@slaptop ~ $ ls /nix/store/ | less
-----
drwxrwxr-t 1 root  nixbld   898202 Mar 18 23:18 .
drwxr-xr-x 1 root  root         16 Feb 25 20:20 ..
-r--r--r-- 1 root  root       1542 Dec 31  1969 001gp43bjqzx60cg345n2slzg7131za8-nix-nss-open-files.patch
-r--r--r-- 1 root  root       5238 Dec 31  1969 00mz6idj54an2pkiih0qzk0gbns5lfcj-python3-3.11.8-env.drv
-r--r--r-- 1 root  root       1870 Dec 31  1969 00nmcp1az6b9rcbqpsgvwngw32dyg6ai-nlohmann_json-3.11.3.drv
dr-xr-xr-x 1 root  root          6 Dec 31  1969 00pl8dbji4k3dy9vsfxwmgvf79x0r8b1-libva-1.8.3
-r--r--r-- 1 root  root       3047 Dec 31  1969 00plkc2wzlggiva28c6ffjw8yvgnpfmq-31_allow_overriding_AGexe_for_crossbuild.diff.drv
-r--r--r-- 1 root  root        437 Dec 31  1969 00qr10y7z2fcvrp9b2m46710nkjvj55z-update-autotools-gnu-config-scripts.sh
-r--r--r-- 1 root  root       2447 Dec 31  1969 00rwip0a5hsdhhwnc5j0qaxa8pymq316-perl5.38.2-XML-SAX-1.02.drv
-r--r--r-- 1 root  root       2081 Dec 31  1969 011rvilfp07w22vyqf963c2hh1vfq84g-perl5.38.2-ExtUtils-Config-0.008.drv
lines 1-11

At first glance this seems absolutely ridiculous, and I don’t blame you for thinking that. It took me a long time to understand why you would store all the program’s compiled bins like this. For the sake of this Part 0 article, I won’t even explain further. The main point I wanted to get across is that nix is unique in the sense that typical libraries and bins are not stored in usual locations, and this can result in unexpected effects on just running and downloading software.

“We’ve Already Solved This”

The Solution Hasn’t Arrived

This mindset seems like a weird way to approach software and configurations. What’s the point of Ansible? You can just use shell scripts. Terraform? Set up your VPS with your hands. How many package managers exist with different philosophies? We’ve got a few of those already. Portage, which is not apt, which is not flatpak, which is not nix. Should we have given up on package management? We already figured it out, right?

The point I’m trying to make is, there’s always room to improve. The power of nix solves multiple issues, not just one issue.

Provisioning - Replace Anible

It replaces Ansible for “some” aspects, mainly in terms of provisioning new machines with the exactly right configs and settings. Instead of a series of roles in a playbook, you can just do all of the work in one config file instead.

Deploy VPS fleet a la Docker Compose

Let’s say you need to deploy a series of VMs to the cloud. Like a seperate reverse proxy, database, and service. Similar to docker compose. With the nix tool morph you can do just that! Define a series of nix configurations in one file and deploy to all of them any changes you made in the file.

nix - The Final Package Manager

One huge advantage to nix is not only that it’s an OS, but that it’s also a universal package manager. Which means you can install it on any distribution and install any of nix’s many packages, which is 80,000 as of the time of writing. If you can package something for nix, congratulations, you just packaged it for every linux distro.

Unified Configuration Syntax

To me one of the coolest parts of nix is how it unifies configuration to “the nix way”. Instead of having to deal with different config files in different locations, most config files are turned into nix options. Whatever isn’t a nixoption already, usually has an “extraConfig” option that just uses plaintext anyways.

Sure gnu-stow exists to hand home configurations, but that’s another tool that nix handles inherently. Placing configuration files, and the configuration itself, becomes unified under 1 roof.

In Closing

This is a short and sweet article, but I wanted to start out with simple explanations on what I like about nix. I tried to keep things simple, I just wanted to cover a couple key points where nix has personally helped me. Join me next time when I begin to explain how nix works - starting with the configuration file & syntax!