Nix never uses host dependencies, it always builds with exactly precise dependencies every time, and will always refer to them from then on.
Nix lets you roll back changes atomically.
nix-shell lets you make build environments that are totally reproducible across machines, and don’t interfere with each other. You can freely mix any number of libraries of versions or software on the same machine and they don’t conflict.
With Ubuntu, every time you want to fix something with your car, you roll it into the garage, pop open the hood and get to work. It's intensive labour, results will vary, and undoing a change can be difficult.
With NixOS, it's like 3D printing a new car every time. You'll design a model, press a button, and the car gets built from scratch. If you don't like it, tweak the design a bit, and print a new car. If the new car breaks, just go back to the previous known-good one, which is already in your garage. You can even take the design documents to your friend and generate an exactly identical model.
sudo command sets the wrong
$HOME, have to use
sudo -i for nix commands that need sudo.
Nix is Turing complete language used for configuration and building packages.
Can use nox, nix search, nix-repl, nixOS packages to search for packages.
Think of Nix (the language) as an expression-based programming language where every program evaluates to a single (possibly complex) value; that resulting value is what is used as eg. the configuration of your system or a package, but it means that you can generate that value based on arbitrary logic and abstractions like you would with a regular programming language.
As for domain-specific package managers, It Depends; it's possible with varying degrees of hackiness (and I definitely use eg. npm for development), but for a 'real' deployment - whether as a service on a server or as a local application - you'd want to convert your project's metadata to a Nix expression and let Nix handle the dependency management.
Overlay adds/overrides something in the global package set.
In general, you should only install things with nix, and not use any other package managers.
The main idea of the Nix approach is to store software components in isolation from each other in a central component store, under path names that contain cryptographic hashes of all inputs involved in building the component, such as
Don't install libraries with Nix.
Nix, the purely functional build system - Great intro article.
hnix - Haskell re-implementation of the Nix expression language.
example-nix - A way to develop software with Nix.
Hercules - Hosted CI for building Nix projects on your infrastructure.
Dysnomia - Tool and plug-in system that can be used to automatically deploy mutable components.
Disnix - Nix-based distributed service deployment tool.
NUR - Nix User Repository: User contributed nix packages.
Eris - Binary cache for Nix.
pypi2nix - Generate Nix expressions for Python packages.
hnix-store - Haskell implementation of the nix store API.
nix-linter - Linter for the Nix expression language.
Install Nix docs by Mozilla - Pretty good.
niv - Painless dependencies for Nix projects.
Cachix - Build Nix packages once and share them for good.
Alternative Haskell Infrastructure for Nixpkgs - Works by automatically translating your Cabal or Stack project and its dependencies into Nix code.
nix-bundle - Bundle Nix derivations to run anywhere.
lorri - nix-shell replacement for project development.
nixfmt - Formatter for Nix code.
Nix for devs - Collection of recipes focused on nix-shell to make setting up project environments easy.
nixpkgs-fmt - Nix code formatter for nixpkgs.
Nixery - Provides the ability to pull ad-hoc container images from a Docker-compatible registry server.
hnix-lsp - Language Server Protocol for Nix.
Nixery - Container registry which transparently builds images using the Nix package manager.
Nix - A One Pager - A (more or less) one page introduction to Nix, the language.