diff --git a/content/posts/debuggers-really.md b/content/posts/debuggers-really.md
new file mode 100644
index 0000000..2b84191
--- /dev/null
+++ b/content/posts/debuggers-really.md
@@ -0,0 +1,40 @@
++++
+date = "2023-04-02"
+draft = true
+path = "/blog/debuggers-really"
+tags = ["debugging"]
+title = "Our debuggers are awful"
++++
+
+* Working on otel for rust
+* Have to vendor several things to get http request logs
+* Why are browsers the only things that you can dump http request logs from
+* Why can't I dump a http/2 protocol trace from h2 in rust?
+
+* This isn't a tracing problem
+ * Tracing is designed to not leak customer data
+ * Tracing is generally a metadata thing, *not* a data thing
+ * Tracing needs instrumentation and seeing the possibility of a problem
+ ahead of time
+* What is a futuristic debugger, anyway?
+ * Integrate with rr
+ * Attach to a running system
+ * Has no overhead while not in use
+ * Can get information out of a system which has not yet been instrumented
+* So thats just dtrace
+ * Yes kinda! But there's not enough instrumentation
+ * I can't dump the request logs into browser devtools (e.g. with a .har
+ file)
+ * Rust ecosystem does not really have deep dtrace integration
+* Debugging a system is too important to disturb it
+ * Debugging a system is too important to care about module privacy
+* Sidebar: "realness"
+ * When we build systems, we tend to treat the user . . . patronizingly, or
+ at least specially
+ * Database schemas with cursed tag-value schemas rather than dynamic
+ schemas
+ * Lowering things into a worse value representation that's different than
+ host-language objects
+ * Cannot introspect objects while ignoring module privacy, even though you
+ could exactly do this given ctf data
+ * RUSTC_BOOTSTRAP
diff --git a/content/posts/nix-evaluation-blocking/index.md b/content/posts/nix-evaluation-blocking/index.md
index fc813bc..07bf606 100644
--- a/content/posts/nix-evaluation-blocking/index.md
+++ b/content/posts/nix-evaluation-blocking/index.md
@@ -52,9 +52,12 @@ only take in things that are known statically; in Bazel it is thus common to
check in generated build instructions. This property in category theory is
illustrated in the type signatures of the operations of Monad and Applicative:
-* `apply :: Applicative f => f (a -> b) -> a -> f b`
- which means that something *outside* the `f` box can be put into a
- computation `a -> b` inside the box.
+* `apply :: Applicative f => f (a -> b) -> f a -> f b`
+ which means that a value inside a box can be passed into a pure
+ computation `a -> b` inside a box. This is less powerful than `bind`, since
+ unlike `bind`, the function you provide cannot use the "a" it got to create
+ new operations involving boxes: this means that the build graph of an
+ Applicative build system is static.
* `bind :: Monad m => m a -> (a -> m b) -> m b`
which means that if you have a value of type `a` in a `m` box, you can *get
the `a` out of the box* and create a further computation in a box depending