fixing issues

lessons/02-crafting-containers-by-hand/C-namespaces.md

@@ -22,7 +22,7 @@ Your first line of defense is that you could log them into chroot'd environments
 
 Enter namespaces. Namespaces allow you to hide processes from other processes. If we give each chroot'd environment different sets of namespaces, now Alice, Bob, and Eve can't see each others' processes (they even get different process PIDs, or process IDs, so they can't guess what the others have) and you can't steal or hijack what you can't see!
 
-There's a lot more depth to namespaces beyond what I've outlined here. The above is describing _just_ the UTS (or UNIX Timesharing) namespace. There are more namespaces as well and this will help these containers stay isloated from each other.
+There's a lot more depth to namespaces beyond what I've outlined here. The above is describing _just_ the PID namespace. There are more namespaces as well and this will help these containers stay isloated from each other.
 
 ## The problem with chroot alone
 

lessons/02-crafting-containers-by-hand/D-cgroups.md

@@ -60,7 +60,7 @@ echo <PID> > /sys/fs/cgroup/sandbox/cgroup.procs
 cat /sys/fs/cgroup/sandbox/cgroup.procs
 
 # should see the process no longer in the root cgroup - processes belong to exactly 1 cgroup
-cat /sys/fs/cgroup/cgroups.proc
+cat /sys/fs/cgroup/cgroup.proc
 ```
 
 We now have moved our unshared bash process into a cgroup. We haven't placed any limits on it yet but it's there, ready to be managed. We have a minor problem at the moment though that we need to solve.
@@ -88,6 +88,9 @@ cat /sys/fs/cgroup/cgroups.proc
 # you have to do this one at a time for each process
 echo <PID> > /sys/fs/cgroup/other-procs/cgroup.procs
 
+# verify all the processes have been moved
+cat /sys/fs/cgroup/cgroups.proc
+
 # add the controllers
 echo "+cpuset +cpu +io +memory +hugetlb +pids +rdma" > /sys/fs/cgroup/cgroup.subtree_control
 

lessons/03-docker/D-tags.md

@@ -15,7 +15,7 @@ keywords:
   - minimalist containers
 ---
 
-So far we've just been running containers with random tags that I chose. If you run `docker run -it node` the tag implicitly is using the `latest` tag. When you say `docker run -it node`, it's the same as saying `docker run -it node:latest`. The `:latest` is the tag. This allows you to run different versions of the same container, just like you can install React version 17 or React version 18: some times you don't want the latest. Let's say you have a legacy application at your job and it depends on running on Node.js 12 (update your app, Node.js is already past end-of-life) then you can say
+So far we've just been running containers with random tags that I chose. If you run `docker run -it node` the tag implicitly is using the `latest` tag. When you say `docker run -it node`, it's the same as saying `docker run -it node:latest`. The `:latest` is the tag. This allows you to run different versions of the same container, just like you can install React version 17 or React version 18: some times you don't want the latest. Let's say you have a legacy application at your job and it depends on running on Node.js 20 (update your app, Node.js is already past end-of-life) then you can say
 
 ```bash
 docker run -it node:20 bash

lessons/03-docker/E-docker-cli.md

@@ -28,6 +28,8 @@ docker run -it jturpin/hollywood hollywood
 
 That will pull the hollywood container from the user jturpin's user account. The second line will execute this fun container which is just meant to look a hacker's screen in a movie (it doesn't really do anything than look cool.)
 
+> Note: The `jturpin/hollywood` image has been depricated. These steps should still work, but if you have issues, you can replace that image with `bcbcarl/hollywood`.
+
 `push` allows you to push containers to whatever registry you're connected to (probably normally Docker Hub or something like Azure Container Registry or GitHub Container Registry).
 
 ### inspect

lessons/05-making-tiny-containers/A-alpine-linux.md

@@ -42,9 +42,9 @@ CMD ["node", "index.js"]
 
 [⛓️ Link to the Dockerfile][dockerfile-file]
 
-Our image size (by comparing the `"Size"` field in in `docker inspect my-app`) from 1.1GB to 150MB just like that. We shed quite a bit of cruft that we didn't need in Ubuntu and we didn't even need to change anything in our Dockerfile. Honestly, that's unusual. When you strip _everything_ out typically you'll have to go back and add some of them back in. But in this case we're golden!
+Our image size (by comparing the `"Size"` field in in `docker inspect my-app`) from 1.1GB to 150MB just like that. We shed quite a bit of cruft that we didn't need in Debian and we didn't even need to change anything in our Dockerfile. Honestly, that's unusual. When you strip _everything_ out typically you'll have to go back and add some of them back in. But in this case we're golden!
 
-Alpine, if you remember, is a bare bones alternative to Ubuntu. It's built on Busybox Linux which is a 2MB distro of Linux (Alpine is 5MB.) `node:20-alpine` itself is about `133MB` and `node:latest` is about 1.0GB.
+Alpine, if you remember, is a bare bones alternative to Debian. It's built on Busybox Linux which is a 2MB distro of Linux (Alpine is 5MB.) `node:20-alpine` itself is about `133MB` and `node:latest` is about 1.0GB.
 
 When should you select Alpine? My general feeling (this is a Brian Holt opinion, not a community one so take it with a grain of salt) is that the "end destination" container is where Alpine is most useful. It cuts all cruft out which is super helpful for end-deployment sorts of scenarios due to security and size but it also can be annoying for development scenarios because it lacks just about everything necessary for those, making you have to hand install everything you need. In these "middle scenarios" where it's not really the destination and the container is just another tool in your development system (where that's a multi stage build or a development container) I'll reach for Ubuntu or Debian.