1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

diff --git a/articles/gomodsri.md b/articles/gomodsri.md
index 0db9c867ae5e27317291da7db2cc437bcb3328c7..2684f50c0b816c2e6401d2a770ee5b19f2be8cb0 100644
--- a/articles/gomodsri.md
+++ b/articles/gomodsri.md
@@ -9,13 +9,13 @@ ### The problem
 
 When building a Go module with `nix`, generally one uses `buildGoModule`. One thing this shares with other builders in the nix ecosystem is `vendorHash` (or similar name).
 
-Although there _have_ been various workarounds, there's usually no getting around some variation of building, noting the "expected" new hash, and replacing the hash with the correct one before building works for real.
+Although there _have_ been various workarounds, there's usually no getting around some variation of building, noting the "expected" new hash, and replacing the old hash with the correct one before building works for real.
 
 ### The solution
 
 Now, admittedly I am borrowing this idea from [tailscale](https://tailscale.com). I simply wrapped it in a (nu)shell command for easier usage more generically.
 
-The original idea combines the command [nardump](https://github.com/tailscale/tailscale/tree/ad33e47270509345469af795aed65177df88904e/cmd/nardump) with the [vendoring](https://pkg.go.dev/cmd/go#hdr-Make_vendored_copy_of_dependencies) ability of Go modules to predict the `vendorHash`. Put together, it can look something like the following:
+The original idea combines the [nardump](https://github.com/tailscale/tailscale/tree/ad33e47270509345469af795aed65177df88904e/cmd/nardump) command with the [vendoring](https://pkg.go.dev/cmd/go#hdr-Make_vendored_copy_of_dependencies) ability of Go modules to predict the `vendorHash`. Put together, it can look something like the following:
 
 - [update-flake.sh](https://github.com/tailscale/tailscale/blob/ad33e47270509345469af795aed65177df88904e/update-flake.sh#L9-L10)
 ```sh