(1) What is a package manager?
A package manager keeps track of what software is installed on your computer, and allows you to easily install new software, upgrade software to newer versions, or remove software that you previously installed. As the name suggests, package managers deal with packages: collections of files that are bundled together and can be installed and removed as a group.
Thus, we can say that a package manager automates the installation/upgrading/removing of computer programs from a system in a consistent manner. Moreover, package managers often manage a database that includes the dependencies between the software artifacts and version information in order to avoid conflicts
Packages can depend on, recommend, suggest, break, conflict
Job of the package manager to present an interface which assists the user in managing the collection of packages installed on their system.
There can be different types of package managers, but the ones we are going to be focusing on are OS package managers for Linux.
(2) How does a normal package manager work
query for information about packages, fetch packages from repositories, install and uninstall packages using automatic dependency resolution, and update an entire system to the latest available packages.
When you execute a command to install a package, the package manager looks at configuration files on the local machine to determine the location of a repository that has a given package on the internet. Then the installation command downloads the package along with its dependencies from the internet. Finally, the package manager installs and configures the application on the local machine.
(3) So whats the issue?
If a package B conflicts with another package C, then the two packages cannot be installed at the same time. For instance, fb-music-hi conflicts with fb-music-low because they provide alternate sets of music for the game Frozen Bubble.
There are some attempts to minimize this issue with traditional package managers, such as Debian’s alternative systems, so theoretically possible but painful in practice.
That stacks as well, as software development keeps progressing and builds on top of itself it becomes more and more likely that a dependency will break with another dependency. This is especially true in Linux open source projects as they are heavily component-based. 
This creates dependency hell, where different versions of libraries are needed and it becomes the users problem to fix. 
Even more installing software from traditional package managers can create version issues. Say you develop an application on A version 1 but apt only has version 2 in its repositories, this means you either have to port your application to A version 2 (which depending on breaking changes could entirely stall a project or deployment) or have to add a repository (that may not even work)
As the software landscape increases it is readily apparent that traditional package managers are not equipped with the tools to optimally manage the packages of modern Linux systems
(4) The solution - Nix
(5) What is Nix?
Nix is a lot of things. First it's a functional language that is used in a functional package manager then was then used to create its own operating system (NixOS)
For this presentation we will mainly be focusing on the package manager
But we will also be talking about the programming language a little as its needed for context
(6) How does nix work?
In essence, the Nix package manager builds packages, called “derivations”, from build instructions made in the Nix language and stores them in a path inside the Nix store.
The Nix store is a storage system in your filesystem with its root at /nix/store by default. The Nix daemon stores several things in the Nix store but the most important for us is the the products of derivations: a folder containing build outputs such as /nix/store/<hash>-my-package/
This structure is actually very important, broken down the path describes:
The root path is /nix/store by default.
The input hash is derived from the inputs (sources, dependencies, compiler flags, etc.)  to the derivation used to build the package
The package name is provided by the package creator
This allows each package to have its own unique subdirectory, where any inputs changes creates a new package. Meaning that 2 packages with slightly different dependencies become entirely new packages.
(7) How does nix work cont.
But how do we keep track of what packages in what places? How do I run my applications?
The solution Nix uses is to create directory trees of symlinks to activated packages. These are called user environments and they are packages themselves.
Looking at this you can see that for example alice is using the default profile. Whats also really cool about Nix is the default-42 it has there. When you do operations that change the user environment a new user environment is actually generated and “default.nix” is a simple symlink to the new generation (seen by the switch.)
This makes sense as you can see in the store the user environments are themselves symlinking to other packages, so changing generations is just changeling symlinks.
Nix with this allows you to rollback a generation, as “default-42” is not automatically deleted you can add a package to your environment > for whatever reason decide you dont like it > and Nix allows you to just rollback if you want.
(8) Ok ok…so how does it work overall?
Looking at a high level, this is a flowchart of what happens when you attempt to add a package to your user profile.
First it looks to see if that package is in your channel. Channels are a mechanism that allows you to point at a repository of Nix code. The most popular (and default channel) is nixpkgs. This repository contains over 80,000 packages…technically the build instructions for those packages. So when you are making a package you import the channel, so whenever you attempt to get a package you're getting its build instructions from the channel. If not, cant install as you dont have the build instructions.
Then you check if that package (using the nix store path of the package) see if your package already exists. If so use it, if not…
Check if the inputs are in the local nix store. As we looked at the hash earlier, a Nix package defines all of its dependencies with the hash. So you can easily check if you have all of the inputs. If not then you would attempt to get the dependencies an inputs, which would do a recursive loop down attempting to get all of firefoxes dependencies.
Once you have all the dependencies. You check if the package is in the cache server. To speed up build times, Nix caches packages in a cache server for easy and fast downloading. If not found, then you must build the package from scratch
Finally, you get your package at the Nix store path.
(9) Nix in action