Typo fixes and grammar improvements, h/t Claude

content/articles/2025-08-10-ctlog-2.md

@@ -29,7 +29,7 @@ audit the certificate logs themselves.  The intent is that eventually clients wo
 certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to
 the logs.
 
-In a [[previous article]({{< ref 2025-07-26-ctlog-1 >}})], I took a deep dive into an upcoming
+In a [[previous article]({{< ref 2025-07-26-ctlog-1 >}})], I took a deep dive into a new
 open source implementation of Static CT Logs made by Google. There is however a very competent
 alternative called [[Sunlight](https://sunlight.dev/)], which deserves some attention to get to know
 its look and feel, as well as its performance characteristics.
@@ -230,7 +230,7 @@ pim@ctlog-test:~$ curl -k https://ctlog-test.lab.ipng.ch:1443/log.v3.json
 
 I'm starting to think that using a non-standard listen port won't work, or more precisely, adding
 a port in the `monitoringprefix` won't work. I notice that the logname is called
-`ctlog-test.lab.ipng.ch:1443` which I don't think is supposed to have a portname in it. So instead,
+`ctlog-test.lab.ipng.ch:1443` which I don't think is supposed to have a port number in it. So instead,
 I make Sunlight `listen` on port 443 and omit the port in the `submissionprefix`, and give it and
 its companion Skylight the needed privileges to bind the privileged port like so:
 
@@ -293,7 +293,7 @@ pim@ctlog-test:/etc/sunlight$ T=0; O=0; while :; do \
 ```
 
 On the first commandline I'll start the loadtest at 100 writes/sec with the standard duplication
-probability of 10%, which allows me to test Sunlights ability to avoid writing duplicates. This
+probability of 10%, which allows me to test Sunlight's ability to avoid writing duplicates. This
 means I should see on average a growth of the tree at about 90/s. Check. I raise the write-load to
 500/s:
 
@@ -387,7 +387,7 @@ A few interesting observations:
     likely explained because the sqlite3 database lives on ZFS here, while TesseraCT uses MariaDB
     running on a different filesystem.
 *   The MinIO usage is a lot lighter. As I reduce the load to 1'000/s, as was the case in the TesseraCT
-    test, I can see the ratio of Get:Put was 93:4 in TesseraCT, while it's 70:30 here. TesseraCT as
+    test, I can see the ratio of Get:Put was 93:4 in TesseraCT, while it's 70:30 here. TesseraCT was
     also consuming more IOPS, running at about 10.5k requests/minute, while Sunlight is
     significantly calmer at 2.8k requests/minute (almost 4x less!)
 *   The burst capacity of Sunlight is a fair bit higher than TesseraCT, likely due to its more
@@ -510,7 +510,7 @@ pim@ctlog-test:/etc/sunlight$ while :; do curl -ksS https://ctlog-test.lab.ipng.
 ```
 
 This rate boils down to `(6576712-6008831)/120` or 4'700/s of written certs, which at a duplication
-ratio of 10% means approximately 5'200/s of total accepted certs. This rate, Sunlight is consuming
+ratio of 10% means approximately 5'200/s of total accepted certs. At this rate, Sunlight is consuming
 about 10.3 CPUs/s, while Skylight is at 0.1 CPUs/s and the CT Hammer is at 11.1 CPUs/s; Given the 40
 threads on this machine, I am not saturating the CPU, but I'm curious as this rate is significantly
 lower than TesseraCT. I briefly turn off the hammer on `ctlog-test` to allow Sunlight to monopolize
@@ -616,16 +616,16 @@ this setup.
 
 ## Wrapup - Observations
 
-From an operators point of view, TesseraCT and Sunlight handle quite differently. Both are easily up
+From an operator's point of view, TesseraCT and Sunlight handle quite differently. Both are easily up
 to the task of serving the current write-load (which is about 250/s).
 
 *    ***S3***: When using the S3 backend, TesseraCT became quite unhappy above 800/s while Sunlight
-     went all the way up to 4'200/s and sent significantly less requests to MinIO (about 4x less),
+     went all the way up to 4'200/s and sent significantly fewer requests to MinIO (about 4x less),
      while showing good telemetry on the use of S3 backends. In this mode, TesseraCT uses MySQL (in
      my case, MariaDB) which was not on the ZFS pool, but on the boot-disk.
 
-*    ***POSIX***: When using normal filesystem, Sunlight seems to peak at 4'800/s while TesseraCT
-     went all the way to 12'000/s. When doing so, Disk IO was quite similar between the two
+*    ***POSIX***: When using a normal filesystem, Sunlight seems to peak at 4'800/s while TesseraCT
+     went all the way to 12'000/s. When doing so, disk I/O was quite similar between the two
      solutions, taking into account that TesseraCT runs BadgerDB, while Sunlight uses sqlite3,
      both are using their respective ZFS pool.
 
@@ -647,7 +647,7 @@ to the task of serving the current write-load (which is about 250/s).
      instance. It uses flags to construct the environment, and is much more forgiving for creative
      `origin` (log name), and submission- and monitoring URLs. It's happy to use regular 'http://'
      for both, which comes in handy in those architectures where the system is serving behind a
-     reversed proxy.
+     reverse proxy.
 
 *    The TesseraCT Hammer tool then again does not like using self-signed certificates, and needs
      to be told to skip certificate validation in the case of Sunlight loadtests while it is