maybe finish LXD post?

content/posts/lxd-containers-for-human-beings.md

@@ -39,6 +39,11 @@ migrate as soon as there's an installable release.
 
 {{< /adm >}}
 
+Questions, comments, and corrections are welcome! Feel free to use the
+self-hosted comment system at the bottom, send me an email, an IM, reply to the
+fediverse post, etc. Edits and corrections, if there are any, will be noted just
+below this paragraph.
+
 ## The benefits of VMs and containers
 
 - **Isolation:** you don't want to allow an attacker to infiltrate your email
@@ -362,12 +367,37 @@ entered. You should see the home page with just the text `earl` on it. If you go
 to `/login`, you'll be able to enter whatever access token you set earlier and
 log in.
 
-### Executing a fork bomb
+### Further tips
+
+One of the things you mind want to do post-installation is mess around with
+profiles. There's a `default` profile in LXD that you can show with `lxc profile
+show default`.
+
+``` text
+$ lxc profile show default
+config: {}
+description: Default LXD profile
+devices:
+  eth0:
+    name: eth0
+    network: lxdbr0
+    type: nic
+  root:
+    path: /
+    pool: default
+    type: disk
+name: default
+used_by: []
+```
+
+Not all config options are listed here though; you'll need to read [the
+documentation] for a full enumeration.
+
+[the documentation]: https://documentation.ubuntu.com/lxd/en/latest/config-options/
 
 I've seen some people say that executing a fork bomb from inside a container is
 equivalent to executing it on the host. The fork bomb will blow up the whole
 system and render every application and container you're running inoperable.
-
 That's partially true because LXD _by default_ doesn't put a limit on how many
 processes a particular container can spawn. You can limit that number yourself
 by running
@@ -380,12 +410,9 @@ Any container you create under the `default` profile will have a total process
 limit of `<num-processes>`. I can't tell you what a good process limit is
 though; you'll need to do some testing and experimentation on your own.
 
-Note that this doesn't _save_ you from fork bombs, all it does is prevent an
-affected container from affecting _other_ containers. If someone executes a fork
-bomb in a container, it'll be the same as if they executed it in a virtual
-machine; assuming it's a one-off, you'll need to fix it by rebooting the
-container. If it was set to run at startup, you'll need to recreate the
-container, restore from a backup, revert to a snapshot, etc.
+As stated in [the containers section,](#containers) this doesn't _save_ you from
+fork bombs. It just helps prevent a fork bomb from affecting the host OS or
+other containers.
 
 [^1]:
     There's a [technical