Remember the days when everyone and their pet iguana was raving about Arch Linux? You couldn't escape the ever-so-subtle "I use Arch BTW" remarks in every Linux forum. Well, move over, Arch, because NixOS is here to steal your thunder! Nowadays, it seems that you can't browse YouTube or read a blog without stumbling upon someone extolling the virtues of NixOS and how it is the epitome of computing perfection. But hey, who needs critical analysis when we can jump on the hype train and declare NixOS as the new Arch? Because that's exactly what's going on. NixOS has now become the self-proclaimed prodigy that's poised to dethrone Arch Linux as the holy grail of Linux distributions. The time is calling, my friends! It's time for you – the seasoned Linux enthusiast – to dust off your keyboard warrior capes and embark on a new crusade. So, grab your Tux plushie (or, your pitchforks if you belong to the world of devils) and let's embark on an adventure through the enigmatic world of NixOS (and let the memes commence)!
Here’s a (hopefully) simple breakdown on flakes:
While Nix is typically called a “package manager”, I recommend thinking of it more like a build system.
And flakes are like blueprints to feed into that build system.
A flake can contain a number “outputs” that can be build, this can be a package, a system configuration, a module for a system configuration, a development environment and much more.
But be aware that nix is very picky and will only accept flakes if it can (typically) guarantee that it will always build the same thing, on every platform, at any time.
That’s why you have to specify external “inputs” like system libraries, git repos or files, if you want to use these within your flake.
After running your flake for the first time, nix will generate a flake.lock file for you. This file contains all used “inputs”, pinned to the specific version/hash used, so that builds in the future will be executed on exactly the same inputs.
And while we’re at it, I should explain something: A flake is a directory, containing a “flake.nix” file, not the file itself. Since other aspects are also part of the “flake” you build, like the lockfile or version control system (if a VCS exists, the flake will only see files that are tracked by it).
This makes flakes very powerful, since they allow nix to be used in a very modular manner.
Here’s an example: If you’d want nix to build and run a little fetcher I’ve written, you could just type:
nix run sourcehut:~sntx/nx-fetch(c.f. https://git.sr.ht/~sntx/nx-fetch )This would make nix fetch the flake from sourcehut, build all “inputs” (these are typically prebuild and pulled from cache.nixos.org), compile the rust-code that is within the flake, add the output package to the local /nix/store and run it.
Edit 1: Fixed typo