diff --git a/Notes.txt b/Notes.txt
index 7bc9f3c649cc27b561b57ec4985f5387d585638f..8ff8754a796d73ef5fc1b2413c0466e0b9f08bb2 100644
--- a/Notes.txt
+++ b/Notes.txt
@@ -10,7 +10,7 @@
* Timing / Overview
* (1) Lecture: Why care about Nix at all? (5 min)
* (2) Lecture: What are Nix (language), Nix (tool), Nixpkgs, NixOS (5 min)
- * (3) Activity: Install some packages with nix-shell, nix-env
+ * (3) Activity: Install some packages with nix-shell, nix-env (15 min)
* (4) Lecture: How does it work inside? (5 min)
* (5) Activity: Make and build your own derivation (15 min)
* Q&A
diff --git a/demo/mkderivation-1.nix b/demo/mkderivation-1.nix
new file mode 100644
index 0000000000000000000000000000000000000000..1f074004b16c14c6748f97bf3f67c793d691c833
--- /dev/null
+++ b/demo/mkderivation-1.nix
@@ -0,0 +1,5 @@
+builtins.derivation {
+ name = "example-derivation";
+ builder = builtins.toFile "builder.sh" "echo 'Hello, world'";
+ system = "x86_64-linux";
+}
diff --git a/demo/shell-1.nix b/demo/shell-1.nix
new file mode 100644
index 0000000000000000000000000000000000000000..9de8f804303e0639f79a754959aa18aa7fe71292
--- /dev/null
+++ b/demo/shell-1.nix
@@ -0,0 +1,7 @@
+let pkgs = import <nixpkgs> {};
+in pkgs.stdenv.mkDerivation {
+ name = "shell-demo";
+ shellHook = ''
+ echo "Hello world"
+ '';
+}
diff --git a/src/attribution b/src/attribution
index adac0a77aac9ab8054e38ba147b5869ba61b7ad8..be528e806e98684b723cbb96482c71c2b2c559e4 100644
--- a/src/attribution
+++ b/src/attribution
@@ -41,4 +41,7 @@ Source: https://www.iconfinder.com/icons/118945/image_missing_icon
---
filename: Broken-Chair.jpg
Source: http://miratico.com/wp-content/uploads/2015/02/Broken-Chair.jpg
----
\ No newline at end of file
+---
+filename: qmarks.webp
+Source: https://ak0.picdn.net/shutterstock/videos/29396560/thumb/1.jpg
+---
diff --git a/src/nixos-part1-slides.md b/src/nixos-part1-slides.md
index c20940b0f96bc1911f5795dc0c5bfdac0f9fc8e1..4af9be505cee96987916c6c66177382170a2900b 100644
--- a/src/nixos-part1-slides.md
+++ b/src/nixos-part1-slides.md
@@ -18,11 +18,12 @@ date: 2022-03-03
:::
+#
## Why Nix?
-## What is Nix?
-## Install some stuff with Nix
-## How does Nix work?
-## Make your own
+## What tools are provided?
+## Install some stuff!
+## How does it work?
+## Make your own!
::: notes
@@ -37,20 +38,14 @@ Here's an overview of what we'll cover today.
::: notes
* So, why?
-* First and really the biggest reason for Nix is reproducible builds.
-* Nix helps you run the same piece of software more than once.
-* What does that have to do with reproducible builds?
-* If you combine software and hardware you get a machine.
-* The machine does some piece of work.
-* Sometimes it is useful work.
-* If it does'nt do what it's supposed to do then it's less useful.
-* If it does a different thing each time then it probably doesn't always do what it's supposed to do.
+* The reason I'll focus on today is reproducible builds.
:::
#
+###
-### Reproducible Builds
+Reproducible *Builds*
```python
def b2a(os):
@@ -67,66 +62,59 @@ def b2a(os):
::: notes
-* Part of the problem is that most of the software programmers write is not combined directly with hardware.
-* Instead, it is transformed somehow into something that can be combined with the hardware --
- something the hardware can run.
* Here's something a programmer might write.
+* This is not a piece of software.
* No hardware in the world can run this.
-* This is a *plan* for a piece of software.
+* It is a *plan* for a piece of software.
+* We have "builds" to turn plans including pieces like this into something hardware can execute.
:::
#
+###
-### Reproducible Builds
-
-You have plans.
-
-
-
-::: notes
-
-* Or more accurately it is one small piece of a larger plan for some software --
- some machine.
-* Other disciplines work similarly, in some ways.
-* They make plans and then execute them to get some desired outcome.
-
-:::
+Nix helps you *build software*.
#
-### Reproducible Builds
+###
-
+*Reproducible* Builds
::: notes
-* Perhaps the plans are executed many times.
-* Execute them precisely each time and get the same output each time.
-* The trouble is most software is extraordinarily complex.
+* Once you have something hardware can execute,
+ you might have some hardware execute it.
+* If your plan was good *and the build was correct* then the results might be useful.
+* If your plan was good the build was *incorrect* then the results be less useful.
+* If the build is different each time then it's hard to know if the results will be useful or not.
+* What's the big deal?
+* Aren't computers good at doing the same thing over and over?
:::
#
-### Reproducible Builds
+###
+
+Simple plans...
::: notes
-* It's less like this ...
+* The challenge is that software and build plans are not like this.
:::
#
-### Reproducible Builds
+###
-You have _complex_ plans.
+Complex plans...
::: notes
-* And more like this ...
+* More often they're like this.
* Actually, that's still ridiculously simple compared to most software.
:::
@@ -138,7 +126,7 @@ You have _complex_ plans.
::: notes
-* It's hard to capture the complexity in a little picture.
+* It's hard to capture the complexity in a picture.
* How about this
* The space shuttle is often used as an example of one of the most complex machines ever built by humans.
* It comprised over 2.5 million components
@@ -147,9 +135,9 @@ You have _complex_ plans.
:::
#
-### Reproducible Builds
+###
-You have _really_ complex plans.
+_Really_ complex plans...
```sh
$ wormhole send complex-cats.png
@@ -175,54 +163,52 @@ wormhole receive 3-eskimo-topmost
:::
#
-### Reproducible Builds
-
-Incorrect Execution
+###
-
+
::: notes
-* You don't want what comes from incorrect execution.
+* Since the plan is so complex, we leave parts of it out.
+* We often leave out details about ...
+* versions of build-time tools (eg the C compiler)
+* versions of runtime dependencies (eg libc)
+* exact configurations for all those dependencies
+
+* These pieces get satisfied by whatever happens to be in the build environment
+* The consequence is each build has the opportunity to follow a completely unique plan -
+ and produce a completely unique piece of software.
:::
#
-### Reproducible Builds
+###
-Correct Execution
+Unique Outcomes
-
+
::: notes
-* You always want this
-* Many -- maybe most --
- software build systems don't even try very hard to achieve it.
-* If computers are so good at reliably executing a set of instructions over and over,
- why is this?
-* Almost always because we failed to give the computer the same set of instructions.
-* different build tools
-* different library dependencies
-* different configuration files
-* starting environment was already divergent
-* starting environments originally converged then diverged
-* Maybe had one environment and then installed security updates
- now we have a different environment
-* Most software build systems take parts of the plan from the environment.
+* Most of the time you are not interested in the unique outcomes.
:::
#
-### Reproducible builds
+###
-::: notes
+Nix builds are *the same every time*.
-* Nix is a tool for giving the computer the same set of instructions more than once.
+::: notes
:::
-# What is Nix?
+# What tools does Nix provide?
+
+* NixOS
+* Nixpkgs
+* nix command line interface
+* the Nix language
#
### NixOS the Linux distro
@@ -236,8 +222,7 @@ Correct Execution
* What if your entire OS install were a reproducible build?
* That's NixOS
-* Adds a configuration layer on top of packages from Nixpkgs.
-* Of course, the configuration layer employs reproducible builds.
+* NixOS adds a reproducible configuration layer on top of packages from Nixpkgs.
:::
@@ -252,8 +237,9 @@ Correct Execution
* What if you had a large, versioned repository of packages supporting reproducible builds?
* That's nixpkgs.
-* You can find any older version of any software that was ever packaged in a previous version of Nixpkgs.
-* Since the builds are reproducible, *it will even build*.
+* Any package in nixpkgs will build the same way for you as for anyone else.
+* Since it's versioned, you can find any older version of any software that was ever packaged in a previous version of Nixpkgs.
+* And since the builds are reproducible, *it will even build*.
:::
@@ -263,6 +249,7 @@ Correct Execution
* `nix-build`
* `nix-shell`
* `nix repl`
+* (and others)
::: notes
@@ -338,45 +325,94 @@ nix-repl>
:::
-# Hands-On
-## nix-shell
-
# Hands-On
## nix-env
```sh
nix search xaos
nix-env --install --attr nixos.xaos
-```
-```sh
nix-env --query
-```
-```sh
nix-env --uninstall xaos
-```
-```sh
+nix-env --list-generations
nix-env --rollback
-xaos
```
::: notes
-* nix-env imperatively manages a "profile"
+* I assume you already have the Nix tools installed.
+* `nix search` searches the package tree
+* `nix-env` imperatively manages a "profile"
+* you can install software into the profile
+* uninstall
+* query (ie, list what it contains)
+* generations of a profile are automatically kept around
+* list them, delete them, switch between them
:::
+# Hands-On
+## nix-shell
+
```sh
-nix-shell -p xaos almonds
+nix-shell -p xaos
```
+
::: notes
-* I assume you already have the Nix tools installed.
-* If not, maybe I can help
-* `nix search` searches the package tree
* `nix-shell` starts a new shell that has the requested packages installed
* exit the shell, the packages are gone
:::
+
+# Hands-On
+## nix-shell
+
+`shell.nix`
+```nix
+let pkgs = import <nixpkgs> {};
+in pkgs.stdenv.mkDerivation {
+ name = "shell-demo";
+ shellHook = ''
+ echo "Hello world"
+ '';
+}
+```
+
+::: notes
+
+*
+
+:::
+
+# How does Nix work?
+### Derivations
+
+```nix
+builtins.derivation {
+ name = "example-derivation";
+ builder = builtins.toFile "builder.sh" "echo 'Hello, world'"
+ system = "x86_64-linux";
+}
+```
+
+::: notes
+:::
+
+# How does Nix work?
+
+```include
+{ stdenv }:
+stdenv.mkDerivation {
+ name = "demo-derivation";
+ src = ./demo;
+ phases = [ "installPhase" ];
+
+ installPhase = ''
+ mkdir $out
+ echo "Hello, world" > $out/greeting.txt
+ '';
+}
+```
diff --git a/src/qmarks.webp b/src/qmarks.webp
new file mode 100644
index 0000000000000000000000000000000000000000..39dbd1cca929ba6b986ed3b80c8b099e8227349d
Binary files /dev/null and b/src/qmarks.webp differ