You execute nixos-rebuild switch which is part of NixOS. That it uses Nix in the background is an implementation detail which i think is not important to end-users.
You probably state that “NixOS is build upon Nix”, so that should be enough.
Again, when stated somewhere that EVERYTHING is because of Nix, then that should be clear that it is also in this case.
IIUC the composability of a Nix derivation mostly means the ability to edit a derivation with chains of functions, each taking an input derivation and morphing it into an edited derivation.
Please correct me if this is wrong.
IIRC, a dervation is a function which takes an attribute set (dictionary) and produces a “derivation” when “instantiated”. When that derivation is “realised”, that’s when it’s made into a store path (think package, but could be anything). This two step process allows us to modify existing derivations to achieve certain effects (like python support, etc). NOTE: This is probably more specific than people really care for, and it’s largely not how I conceptualize packages when I’m writing expressions.
The composibility really comes from the fact that all the packages exists on an extremely flat hierarchy (very easy to say I need “cmake, openssl, and zlib”), and the ability to override arguments to other derivations allows us to extend usage cases much farther than what is normally possible. (E.g but, I need openssl_1_0_2 instead of openssl_1_1_2) One good example is the vulkan ecosystem requires very specific versions of vulkan-headers, vulkan-validators, spirv-headers, and spirv for each of the tools. We can override which versions get pulled down per-package, which allows us to have all the packages able to work without worrying about which version of each is installed globally (generally the “known-good” and “latest stable” are mutually exclusive).
First mention of a derivation in Nix manual
So we have to build a package. Building something from other stuff is called a derivation in Nix (as opposed to sources, which are built by humans instead of computers). We perform a derivation by calling
stdenv.mkDerivation.mkDerivationis a function provided bystdenvthat builds a package from a set of attributes .
The result of the function in this case is a derivation. This is Nix-speak for a component build action, which derives the component from its inputs.
With these definitions I now wonder if there is any difference between a derivation instance (or output) and a “component” of the thesis.
EDIT :
The concept of (software) “component” seems a big topic in the thesis… I will study that when I will have some time.
@jojo As a fellow French, I am willing to proof-read your article if you want. I am not a NixOS expert but I have been using it for half a year now for what that’s worth.
The article is overall finished. Thanks to the help @juliendehos and @samueldr it has greatly improved through comments and reviews and I’m currently planning to send it to the editor next week.
I am still not 100% sure of a part about the upgrading process of NixOS. Here is my current hypothesis (written in the article) :
During a system upgrade:
- The new system is stored at:
/nix/store/qzaqjh…-nixos-system-<hostname>-19.03.- The corresponding generation is created:
/nix/var/nix/profiles/system-141-link.- The profile is updated :
/nix/var/nix/profiles/systempoints afterwards to generation 141.- At last, the generation link is copied to
/run/current-system. This last link thus points towards/nix/store/qzaqjh…-nixos-system-<hostname>-19.03.
When exactly does nixos-rebuild switch updates the /run/current-system link ? Is it actually the 4th step ? Or does it occur before ?
I searched in the NixOS paper of 2010 and even looked at the source code of switch-to-configuration.pl without finding this information.
Next sentence of the article currently explains that the atomicity of the system upgrade is due to the atomicity of step 4. Could someone confirm this too ?
Found out that switch-to-configuration.pl calls an activation script generated during system build : /nix/store/jwwfv...-nixos-system-jlucas-laptop-20.03pre193781.d484f2b7fc0/activate. Relevant lines of this script:
systemConfig=/nix/store/jwwfv...-nixos-system-jlucas-laptop-20.03pre193781.d484f2b7fc0
...
# Make this configuration the current configuration.
# The readlink is there to ensure that when $systemConfig = /system
# (which is a symlink to the store), /run/current-system is still
# used as a garbage collection root.
ln -sfn "$(readlink -f "$systemConfig")" /run/current-system
# Prevent the current configuration from being garbage-collected.
ln -sfn /run/current-system /nix/var/nix/gcroots/current-system
A stackoverflow discussion tends IMO to show that ln -sfn is not atomic. strace does show that ln -sfn calls first unlink, then symlink…
Another question: Why not having /run/current-system pointing to /nix/var/nix/profiles/system ?
EDIT:
In the Nix manual:
the
defaultsymlink is made to point at the new generation. This last step is atomic on Unix, which explains how we can do atomic upgrades
AFAIK, during this process, Nix calls replaceSymlink to:
default profileWhy not using this process during nixos-rebuild switch ? while switching /run/current-system to the new system ?
I have just received a positive feedback of the editor about the article 
In addition to current technical images describing NixOS, editor asks if it would be possible to add two screenshots, representative of the distribution : “thus readers will have an idea of what it looks like”.
The editor may expect something like a screenshot of the Desktop Environment (DE), e.g. Unity of Ubuntu. But NixOS is a bit like Arch Linux on this point and has not a default DE. KDE is the default DE in the virtual machine but, it is not customized for NixOS. Gnome displays a NixOS wallpaper but its software manager icon is not meant for NixOS…
So first I thought that I would explain to the editor that showing a random DE was meaningless.
But afterwards I thought that it could also be interesting, from a kind of commercial point of view, to show how a DE of NixOS can look like. Do you have a DE or a Display Manager with a NixOS graphic theme (e.g. GitHub - NixOS/nixos-artwork: Nix related artwork) that would be interesting to showcase ? Otherwise I will dismiss this request from the editor.
But afterwards I thought that it could also be interesting, from a kind of commercial point of view, to show how a DE of NixOS can look like. Do you have a DE or a Display Manager with a NixOS graphic theme (e.g. GitHub - NixOS/nixos-artwork: Nix related artwork) that would be interesting to showcase ? Otherwise I will dismiss this request from the editor.
There is also an option to offer a screenshot with minimal decoration, NixOS logo wallpaper, and an editor window with syntax-highlighted configuration.nix (or something in this direction).
I think that is a legitimate request. But we can only show what it CAN look like if you choose to.
You could show 2 screenshots, one with KDE and one with i3 and have the description “KDE is one of 11 available desktop environments. It is used in the graphical installation CD.”
Already sent a screenshot of my deskop: a minimalist and dark-themed Xfce+i3. The screenshot shows three tiled windows : Firefox with NixOS main page, a console with neofetch (including a NixOS ASCII logo) and a third window with Vim and configuration.nix using syntax highlighting.
It would have been interesting to add that “it is one of 11 available desktop environments” with a list of these environments but the answer to the first review is already sent… I will try to add this if I have a new opportunity.
Article is being formatted now.
I woke up recently with a doubt concerning the meaning of “purely functional”, that seems rather important since it is used in the NixOS paper title and pervasively in the NixOS about page.
From these sources and digging here and there on the web (e.g. wikipedia page) I wrote something during last round of review, in french, similar to
NixOS manages the system configuration in a purely functional manner, any new version is built directly from the configuration file and storing this new version in memory does not overwrite the preceding version – similar to purely functional languages, computed values of which are immutable.
Is it correct enough ? If no I may have some time to send an edition request…
TLDR; Is there a precise definition of “purely functional” in the NixOS world ?
I think that your definitions lacks the fact that in a “purely functional” paradigm, building a package (or configuration, which is a package) should not have any other side-effect than the act of generating the package itself. This means, for example, that a package build script cannot download dependencies from the Internet, read anything outside of the Nix store, or write anything outside of the output directory.
See the description of the Nix package manager:
Nix is a purely functional package manager . This means that it treats packages like values in purely functional programming languages such as Haskell — they are built by functions that don’t have side-effects, and they never change after they have been built.
maybe be more specific and say “purely functional programming languages”? Or are the audience only programmers that expect that?
Oh sorry @davidak, I realize that I missed to answer to your last post. Your suggestion has been included in the final version of the article, thanks 
Great. Is there a chance to get the article for our community?
What do you mean ? A free version for all the members ?
Just the one article to post here without explicit right to redistribute it.
I suppose I’m too late for your article, but on the topic of building well-specified, reproducible, (extremely) minimalist Docker containers with Nix, @grahamc gave an excellent talk a couple weeks ago at NYLUG that’s worth checking out!
Specifically, he addressed your question about how it compares to multi-stage builds.
