Recent changes to this wiki:

Fix: email -> gmail
diff --git a/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
index 98b73eb..c842482 100644
--- a/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
+++ b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
@@ -73,7 +73,7 @@ going to be good enough against their implied threat model.
 
 For example, email clients and servers could refuse to send or accept
 email except over unencrypted or unverified channels, or emails that
-are unencrypted. This wouldn't help, say, email users, but we would
+are unencrypted. This wouldn't help, say, gmail users, but we would
 not expect people with the blog post's implied threat model to use
 gmail. Or email at all.
 

Fix: spellos
diff --git a/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
index c842482..98b73eb 100644
--- a/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
+++ b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
@@ -73,7 +73,7 @@ going to be good enough against their implied threat model.
 
 For example, email clients and servers could refuse to send or accept
 email except over unencrypted or unverified channels, or emails that
-are unencrypted. This wouldn't help, say, gmail users, but we would
+are unencrypted. This wouldn't help, say, email users, but we would
 not expect people with the blog post's implied threat model to use
 gmail. Or email at all.
 

Add: another example of when email encryption is OK
diff --git a/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
index 2960169..c842482 100644
--- a/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
+++ b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
@@ -41,6 +41,9 @@ well enough. For example, password reset emails that are encrypted to
 the PGP public key registered with the service. The value of the email
 disappears minutes after it's sent.
 
+Or emails preparing a surprise party for someone's spouse. If the
+messages leak, it's a bummer, but it's not a big problem.
+
 Thus we feel that rather than telling people to not use encrypted
 email at all, for anything, ever, a more sensible and useful approach
 is to discuss the risks and give people tools to decide for

Fix: typos
diff --git a/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
index bb52bfa..2960169 100644
--- a/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
+++ b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
@@ -18,9 +18,9 @@ points out problems:
 * email metadata (headers, routing) is public, even on encrypted
   messages
 * it's easy to reply to an encrypted email in cleartext
-* PGP is far from ideal 
+* PGP is far from ideal
 * PGP users tend to have long-lived encryption keys, and that if and
-  when they are broken or leak, many messages' security is at danger
+  when they are broken or leak, all messages' security is at danger
 * personal email archives can leak an encrypted message long after it
   was sent
 

creating tag page tag/encryption
diff --git a/tag/encryption.mdwn b/tag/encryption.mdwn
new file mode 100644
index 0000000..60898b2
--- /dev/null
+++ b/tag/encryption.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged encryption"]]
+
+[[!inline pages="tagged(encryption)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/book-club
diff --git a/tag/book-club.mdwn b/tag/book-club.mdwn
new file mode 100644
index 0000000..5ecd6b7
--- /dev/null
+++ b/tag/book-club.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged book-club"]]
+
+[[!inline pages="tagged(book-club)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
new file mode 100644
index 0000000..bb52bfa
--- /dev/null
+++ b/posts/2020/03/17/book_club_latacora_--_stop_using_encrypted_email.mdwn
@@ -0,0 +1,79 @@
+[[!meta title="Book club: Latacora -- Stop using encrypted email"]]
+[[!meta date="2020-03-17 08:26"]]
+[[!tag draft book-club email encryption]]
+
+Three friends sat down and discussed a book, er, blog post that they'd
+read: Daniel, Mark, and myself. We live in different countries, so we
+did this over video conferencing. This is a summary of the discussion.
+
+The article:
+<https://latacora.singles/2020/02/19/stop-using-encrypted.html>
+published in February this year. The title is "Stop Using Encrypted
+Email". It's not long.
+
+To start with, we all agree that using encryption with the current
+Internet email system is far from ideal. The blog post correctly
+points out problems:
+
+* email metadata (headers, routing) is public, even on encrypted
+  messages
+* it's easy to reply to an encrypted email in cleartext
+* PGP is far from ideal 
+* PGP users tend to have long-lived encryption keys, and that if and
+  when they are broken or leak, many messages' security is at danger
+* personal email archives can leak an encrypted message long after it
+  was sent
+
+However, we think that blog post argues too strongly that encrypted
+email is pointless.
+
+Most importantly, they claim that encrypted email should not be used
+by anyone, ever, for anything. We find this to be too strong, if
+understandable. They don't describe an actual threat model, though
+they give some examples, and seem to mostly concentrate on a threat
+where a very powerful adversary, with pervasive surveillance
+capabilities, is trying to catch individuals so they can punish them,
+and possibly kill them, possibly long after the communication happens.
+That is certainly a threat model where current encrypted email fails.
+
+However, we claim there are situations where the encrypted email works
+well enough. For example, password reset emails that are encrypted to
+the PGP public key registered with the service. The value of the email
+disappears minutes after it's sent.
+
+Thus we feel that rather than telling people to not use encrypted
+email at all, for anything, ever, a more sensible and useful approach
+is to discuss the risks and give people tools to decide for
+themselves. Accurate information is more valuable than overblown
+rhetoric, whether it's for or against email encryption.
+
+We agree that the secure messaging systems they promote are good, but
+we don't agree that they're as good as the article implies. Signal,
+for example, routes all traffic through its own servers. A very
+powerful adversary with pervasive surveillance capabilities can deduce
+much from traffic patterns. This has already been used against Tor
+users. (FIXME: link would be good)
+
+We're also not entirely happy with messaging systems that require the
+use of phone numbers. Signal is one of these. Signal is also
+problematic when changing phones or phone numbers, as all trust
+relationships within it have to be re-established.
+
+Messaging systems are also meant for use cases that aren't all the
+same as email's. For example, offline use, and long-form messages. We
+see messaging systems and email as complementary more than competing.
+
+We also do not agree that improving email security is as hopeless as
+the blog post claims. Much could be done just by improving email
+client software. That said, we repeat that we agree that it's not
+going to be good enough against their implied threat model.
+
+For example, email clients and servers could refuse to send or accept
+email except over unencrypted or unverified channels, or emails that
+are unencrypted. This wouldn't help, say, gmail users, but we would
+not expect people with the blog post's implied threat model to use
+gmail. Or email at all.
+
+In summary, we do think the email system could be improved. We just
+don't think it and its encryption are as useless as the blog post
+claims, and we don't think the blog post is making things better.

Fix: typos
diff --git a/posts/2020/03/09/godwin_on_empowering_people.mdwn b/posts/2020/03/09/godwin_on_empowering_people.mdwn
index 2ea57d4..8c1d106 100644
--- a/posts/2020/03/09/godwin_on_empowering_people.mdwn
+++ b/posts/2020/03/09/godwin_on_empowering_people.mdwn
@@ -2,7 +2,7 @@
 [[!meta date="2020-03-09 09:35"]]
 [[!tag godwin wikipedia empowering]]
 
-Mike Godwin in essay on
+Mike Godwin in an essay on
 [slate.com](https://slate.com/technology/2020/02/three-decades-internet-freedom-activism.html):
 
 > That’s the biggest thing I learned at the Wikimedia Foundation: When
@@ -16,4 +16,4 @@ Mike Godwin in essay on
 > we dutifully have to bear. Now, more than I ever did 30 years ago, I
 > argue that it’s the solution.
 
-I though that was well said.
+I thought that was well said.

creating tag page tag/empowering
diff --git a/tag/empowering.mdwn b/tag/empowering.mdwn
new file mode 100644
index 0000000..f1a6668
--- /dev/null
+++ b/tag/empowering.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged empowering"]]
+
+[[!inline pages="tagged(empowering)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/godwin
diff --git a/tag/godwin.mdwn b/tag/godwin.mdwn
new file mode 100644
index 0000000..0829f39
--- /dev/null
+++ b/tag/godwin.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged godwin"]]
+
+[[!inline pages="tagged(godwin)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/wikipedia
diff --git a/tag/wikipedia.mdwn b/tag/wikipedia.mdwn
new file mode 100644
index 0000000..a74cf29
--- /dev/null
+++ b/tag/wikipedia.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged wikipedia"]]
+
+[[!inline pages="tagged(wikipedia)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2020/03/09/godwin_on_empowering_people.mdwn b/posts/2020/03/09/godwin_on_empowering_people.mdwn
new file mode 100644
index 0000000..2ea57d4
--- /dev/null
+++ b/posts/2020/03/09/godwin_on_empowering_people.mdwn
@@ -0,0 +1,19 @@
+[[!meta title="Godwin on empowering people"]]
+[[!meta date="2020-03-09 09:35"]]
+[[!tag godwin wikipedia empowering]]
+
+Mike Godwin in essay on
+[slate.com](https://slate.com/technology/2020/02/three-decades-internet-freedom-activism.html):
+
+> That’s the biggest thing I learned at the Wikimedia Foundation: When
+> ordinary people are empowered to come together and work on a common,
+> humanity-benefiting project like Wikipedia, unexpectedly great and
+> positive things can happen. Wikipedia is not the anomaly my
+> journalist friend thinks it is. Instead, it’s a promise of the good
+> works that ordinary people freed by the internet can create. I no
+> longer argue primarily that the explosion of freedom of expression
+> and diverse voices, facilitated by the internet, is simply a burden
+> we dutifully have to bear. Now, more than I ever did 30 years ago, I
+> argue that it’s the solution.
+
+I though that was well said.

creating tag page tag/email
diff --git a/tag/email.mdwn b/tag/email.mdwn
new file mode 100644
index 0000000..c7295f6
--- /dev/null
+++ b/tag/email.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged email"]]
+
+[[!inline pages="tagged(email)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2020/03/08/what_people_like_or_hate_about_email.mdwn b/posts/2020/03/08/what_people_like_or_hate_about_email.mdwn
new file mode 100644
index 0000000..5f25a66
--- /dev/null
+++ b/posts/2020/03/08/what_people_like_or_hate_about_email.mdwn
@@ -0,0 +1,67 @@
+[[!meta title="What people like or hate about email"]]
+[[!meta date="2020-03-08 09:33"]]
+[[!tag email]]
+
+I [asked a couple of weeks
+ago](https://toot.liw.fi/@liw/103729502946243759) what people like or
+hate about email. Here's a summary of the responses. I admit the
+summary may be tainted by my current thinking about [re-inventing
+email](https://ideas.liw.fi/email2.html).
+
+# Like
+
+* It's not real time. Sender and recipient do not net need to be
+  participating in the communication at the same time. The sender can
+  take their time to craft their message, the recipient can take their
+  time to ponder on the message and how to respond.
+
+* It's established, ubiquitous.
+
+* It's de-centralized.
+
+* It's built on top of well-known data formats and protocols, and data
+  can be stored locally under user control, and is highly portable.
+  There are a variety of client software to choose from.
+
+* Separate discussions are kept separate.
+
+* Formatting, attachments, and lenght is flexible.
+
+* Mailing lists can be archived publically.
+
+* One can have many accounts, and people comprehend this.
+
+* Subject lines.
+
+* Email providers are neutral, commodity entities. Choosing one
+  doesn't imply membership in a community.
+
+# Not like
+
+* Unreliable for communication, often due to bad anti-spam.
+
+* People sending one-line replies that don't add actual value or that
+  miss the point entirely.
+
+* Encryption, security, privacy, rich media content, formatted
+  messages, etc, are all built on top of older protocols, often
+  resulting in unfortunate consequences.
+
+* Top quoting.
+
+* De-facto oligopoly.
+
+* Spam.
+
+* Abuse.
+
+* Configuring and administering email servers is complex.
+
+* Filters and organisation of email is often difficult. The tools
+  provided are not always well suited for the task.
+
+* Threading is unreliable.
+
+* Email addresses are too tightly tied to your identity.
+
+* Searching is often inadequate.

Publish log entry
diff --git a/posts/2020/03/07/demo_site_for_how_i_journal.mdwn b/posts/2020/03/07/demo_site_for_how_i_journal.mdwn
new file mode 100644
index 0000000..1601c24
--- /dev/null
+++ b/posts/2020/03/07/demo_site_for_how_i_journal.mdwn
@@ -0,0 +1,22 @@
+[[!meta title="Demo site for how I journal"]]
+[[!meta date="2020-03-07 11:32"]]
+[[!tag ]]
+
+A friend expressed interest in how I keep my journal, so I set up a
+demo site. In short:
+
+* markdown files (mostly) in git
+* [ikiwiki][] renders to HTML (locally or via CI to a website)
+  - ikiwiki's [inline][] directive helps collect journal entries
+  - tags and topic pages help collect
+  - I have a "topic" for each person
+* [jt][] helps make entries and maintain the journal (not necessary,
+  but relieves some tedium)
+
+[ikiwiki]: http://ikiwiki.info/
+[inline]: http://ikiwiki.info/ikiwiki/directive/inline/
+[jt]: http://git.liw.fi/jt
+
+* source: <http://git.liw.fi/demo-journal>
+* rendered: <http://demo-journal.liw.fi/>
+* instructions: <http://git.liw.fi/demo-journal/tree/README.md>

Fix: typo
diff --git a/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn b/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
index be015dc..2b1683a 100644
--- a/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
+++ b/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
@@ -2,7 +2,7 @@
 [[!meta title="Alternative Debian installer based on vmdb2: v-i"]]
 [[!tag vmdb2 v-i debian]]
 
-I wrote an alterantive Debian installer as a toy, called v-i. One of
+I wrote an alternative Debian installer as a toy, called v-i. One of
 the following two bullet points is correct:
 
 * v-i can install a very rudimentary Debian onto exactly one computer

Fix: missing word
diff --git a/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn b/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
index 109a921..be015dc 100644
--- a/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
+++ b/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
@@ -30,7 +30,7 @@ things I wanted to change:
   special udeb packages for any software that's to be part of the
   installer. v-i is happy with normal debs.
 
-* Debian in general preseeding for automating an installation.
+* Debian in general uses preseeding for automating an installation.
   Preseeding means providing answers, in a file, to questions the
   package may ask during its installation. This is fine, if a little
   cumbersome, but only helps when the packages ask the right

Change: publish
diff --git a/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn b/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
index 5dbc9c2..109a921 100644
--- a/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
+++ b/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
@@ -1,6 +1,6 @@
 [[!meta date="2020-02-29 20:12"]]
 [[!meta title="Alternative Debian installer based on vmdb2: v-i"]]
-[[!tag draft vmdb2 v-i debian]]
+[[!tag vmdb2 v-i debian]]
 
 I wrote an alterantive Debian installer as a toy, called v-i. One of
 the following two bullet points is correct:
@@ -68,4 +68,5 @@ PS. A 128 GB USB3 flash drive can be had for as little as 20 euros,
 and that has enough disk space for v-i and a Debian mirror.
 
 If you want to respond to this blog post, please email me (liw@liw.fi)
-or respond to [this fediverse post]().
+or respond to [this fediverse
+post](https://toot.liw.fi/@liw/103743493062316650).

creating tag page tag/v-i
diff --git a/tag/v-i.mdwn b/tag/v-i.mdwn
new file mode 100644
index 0000000..fa94165
--- /dev/null
+++ b/tag/v-i.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged v-i"]]
+
+[[!inline pages="tagged(v-i)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn b/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
new file mode 100644
index 0000000..5dbc9c2
--- /dev/null
+++ b/posts/2020/02/29/alternative_debian_installer_based_on_vmdb2_v-i.mdwn
@@ -0,0 +1,71 @@
+[[!meta date="2020-02-29 20:12"]]
+[[!meta title="Alternative Debian installer based on vmdb2: v-i"]]
+[[!tag draft vmdb2 v-i debian]]
+
+I wrote an alterantive Debian installer as a toy, called v-i. One of
+the following two bullet points is correct:
+
+* v-i can install a very rudimentary Debian onto exactly one computer
+  in the world: my very own spare Thinkpad x220 laptop. It might not
+  work on your x220. v-i almost certainly won't work on any other kind
+  of computer. If you try, it will probably delete all your data. Make
+  sure your backups work.
+
+* v-i is perfect in every way. There are not even any typos in the
+  manual. There are no bugs, and all features are fully implemented.
+  Every possible use case is supported. Not only is there no danger to
+  your data, v-i will prevent it from ever disappering. Even your
+  hardware will never break again. Your laptop will have infinite
+  battery life, and your screen resolution will require 64 bit
+  integers to express.
+
+[vmdb2]: https://vmdb2.liw.fi/
+
+The v-i installer is based on the [vmdb2][] tool, which I also wrote.
+It has nothing to do with debian-installer, which is the official
+Debian installer, also known as d-i. I use d-i, but have a couple of
+things I wanted to change:
+
+* I'd like something I can easily modify. d-i requires building
+  special udeb packages for any software that's to be part of the
+  installer. v-i is happy with normal debs.
+
+* Debian in general preseeding for automating an installation.
+  Preseeding means providing answers, in a file, to questions the
+  package may ask during its installation. This is fine, if a little
+  cumbersome, but only helps when the packages ask the right
+  questions. v-i lets you have the full power of Ansible during
+  initial installation, which is much more flexible.
+
+On the other hand, d-i is mature software and tested by a very large
+number of people, on a very large number of different hardware. v-i
+is not. v-i might, at best, be the beginning of something useful for a
+small number of people.
+
+I can now install Debian onto my x220 with v-i. It's a very basic
+install, without LVM2, full-disk encryption, or a graphical desktop,
+but it does have sshd and I can configure the laptop further with
+Ansible from another host. I've installed the GNOME desktop that way,
+after rebooting into a v-i installed system. (In theory, I could
+install GNOME directly from v-i. In practice, there are bugs in
+packages and/or how vmdb2 runs Ansible.)
+
+The installed system is also highly configured to my needs and
+preferences. It uses Finnish locales, and requires my SSH key to log
+in. The root account has no password. All of this could be made better
+with a bit of work.
+
+The code is at <https://gitlab.com/larswirzenius/v-i>. Check the
+README for more instructions if you're curious. If you do give it a
+try, I'd love to hear from you, unless you just lost all your data.
+Please don't lose all your data.
+
+If you'd like to help build a more viable installer from v-i, please
+talk to me. I dream of a future where I can install a bare metal
+machine as easily as I can create and configure a VM. 
+
+PS. A 128 GB USB3 flash drive can be had for as little as 20 euros,
+and that has enough disk space for v-i and a Debian mirror.
+
+If you want to respond to this blog post, please email me (liw@liw.fi)
+or respond to [this fediverse post]().

Change: publish
diff --git a/posts/2020/02/28/security_isolation_in_ci_engines.mdwn b/posts/2020/02/28/security_isolation_in_ci_engines.mdwn
index 65653c1..fa6beaf 100644
--- a/posts/2020/02/28/security_isolation_in_ci_engines.mdwn
+++ b/posts/2020/02/28/security_isolation_in_ci_engines.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Security isolation in CI engines"]]
 [[!meta date="2020-02-28 09:28"]]
-[[!tag draft ick continuous-integration security]]
+[[!tag ick continuous-integration security]]
 
 A continuous integration engine (CI) takes the source code for a
 software project and ensures it works. In less abstract terms, it
@@ -106,5 +106,5 @@ HTTPS proxy may need to be enough.
 What threat am I missing? Are my mitigations acceptable?
 
 If you want to comment on this blog post, please send me email
-(liw@liw.fi), or respond on the fediverse on [this thread](). Thank
-you!
+(liw@liw.fi), or respond on the fediverse on [this
+thread](https://toot.liw.fi/@liw/103735557747821512). Thank you!

Fix? typo
diff --git a/posts/2020/02/28/security_isolation_in_ci_engines.mdwn b/posts/2020/02/28/security_isolation_in_ci_engines.mdwn
index 7690cbb..65653c1 100644
--- a/posts/2020/02/28/security_isolation_in_ci_engines.mdwn
+++ b/posts/2020/02/28/security_isolation_in_ci_engines.mdwn
@@ -73,7 +73,7 @@ My current plan for mitigating all of the above looks as follows:
 * the inner VM can be any operating system, as long as it can run as a
   Qemu/KVM guest, and provides ssh access from the outer VM
 * the manager runs commands on the builder over ssh, or possibly via
-  serial consoler (ssh would be simpler, though)
+  serial console (ssh would be simpler, though)
 * both VMs have a restricted amount of CPUs, RAM, disk space
 * the manager monitors the builder's use of CPU time, bandwidth use
 * the manager proxies and firewalls all outgoing network access to

creating tag page tag/security
diff --git a/tag/security.mdwn b/tag/security.mdwn
new file mode 100644
index 0000000..d42e5e2
--- /dev/null
+++ b/tag/security.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged security"]]
+
+[[!inline pages="tagged(security)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2020/02/28/security_isolation_in_ci_engines.mdwn b/posts/2020/02/28/security_isolation_in_ci_engines.mdwn
new file mode 100644
index 0000000..7690cbb
--- /dev/null
+++ b/posts/2020/02/28/security_isolation_in_ci_engines.mdwn
@@ -0,0 +1,110 @@
+[[!meta title="Security isolation in CI engines"]]
+[[!meta date="2020-02-28 09:28"]]
+[[!tag draft ick continuous-integration security]]
+
+A continuous integration engine (CI) takes the source code for a
+software project and ensures it works. In less abstract terms, it
+builds it, and runs any automated tests it may have. The exact steps
+for that depend heavily on the CI engine and the project, but can be
+thought of as follows (with concrete examples of possible commands):
+
+* retrieve the desired revision of the source code (git clone, git
+  checkout)
+* install build dependencies (dpkg-checkbuilddeps, apt install)
+* build (./configure, make)
+* test (make check)
+
+This is dangerous stuff. In the specific case of an open, hosted CI
+service, it's especially dangerous: anyone can submit any build, and
+that build can do anything, including attack computers anywhere on the
+Internet. However, even in a CI engine that only builds projects for
+in-house developers, it's risky: most attacks on IT are done by
+insiders.
+
+Apart from actual attacks, building software is dangerous also due to
+accidents: a mistake in the way software is built, or automatically
+tested, can result in what looks and behaves like an attack. An
+infinite loop can use excessive amounts of CPU resources, or block
+other projects from getting built.
+
+I've been thinking about ways to deal with this, in the context of
+developing a CI engine, and here's a list of specific threats I've
+come up with:
+
+* excessive use build host resources
+  * e.g., CPU, GPU, RAM, disk, etc
+  * mitigation: use quotas or other hard limits that can't be exceeded
+    (e.g., dedicated file system for build, virtual machine with a
+    virtual memory limit)
+  * mitigation: monitor use, stop build if use goes over a limit, if a
+    quota is infeasible (e.g., CPU time)
+* excessive use of network bandwidth
+  * mitigation: monitor use, stop build if it goes over a limit
+* attack on a networked target via a denial of service attack
+  * e.g., build joins a DDoS swarm, or sends fabricated SYN packets to
+    prevent target from working
+  * mitigation: prevent direct network access for build, force all
+    outgoing connections to go via a proxy that validates requests and
+    stops build if anything looks suspicious
+* attack on build host, or other host, via network intrusion
+  * e.g., port scanning, probing for known vulnerabilities
+  * mitigation: prevent direct network access for build, force all
+    outgoing connections to go via a proxy that validates requests and
+    stops build if anything looks suspicious
+* attack build host directly without network
+  * e.g., by breaching security isolation using build host kernel or
+    hardware vulnerabilities, or CI engine vulnerabilities
+  * this includes eavesdropping on the host, and stealing secrets
+  * mitigation: keep build host up to date on security updates
+  * mitigation: run build inside a VM controlled by CI engine (on the
+    assumption that a VM provides better security isolation than a
+    Linux container)
+
+I'm sure this is not an exhaustive list. If you can think of
+additional risks, do tell me.
+
+My current plan for mitigating all of the above looks as follows:
+
+* there are two, nested virtual machines
+* the outer VM is the manager, the inner VM is the builder
+* the manager creates, controls, monitors, and destroys the builder
+* the outer VM is probably Debian Linux, since that what I know best,
+  using libvirt with Qemu and KVM to manage the inner VM
+* the inner VM can be any operating system, as long as it can run as a
+  Qemu/KVM guest, and provides ssh access from the outer VM
+* the manager runs commands on the builder over ssh, or possibly via
+  serial consoler (ssh would be simpler, though)
+* both VMs have a restricted amount of CPUs, RAM, disk space
+* the manager monitors the builder's use of CPU time, bandwidth use
+* the manager proxies and firewalls all outgoing network access to
+  prevent any access that isn't explicitly allowed
+
+To look at the build steps from the top of this article, they would
+work something like this:
+
+* retrieve the desired revision of the source code: the builder does
+  this, but proxied via the manager, which checks that
+  only from servers listed as allowed for this project are connected
+* install build dependencies: the builder downloads the build
+  dependencies, but proxied via the manager, which checks that
+  downloads come only from servers listed as allowed for this project
+* build: runs inside the builder
+* test: runs inside the builder
+
+It would be awesome if the manager could disable the builder from
+having network access after build dependencies are installed. This
+would be feasible if the build recipe is structured in a way that
+allows the manager to know what part is doing what. (If I'm designing
+the CI engine, then I can probably achieve that.)
+
+It would be even more awesome if the manager could do all the
+downloading, but given the guest may need to use tools specific for
+its operating system, which might not be available on the operating
+system of the manager, this might not be feasible. A filtering HTTP or
+HTTPS proxy may need to be enough.
+
+What threat am I missing? Are my mitigations acceptable?
+
+If you want to comment on this blog post, please send me email
+(liw@liw.fi), or respond on the fediverse on [this thread](). Thank
+you!

Publish
diff --git a/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
index c8c0696..57705f7 100644
--- a/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
+++ b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Subplot volunteers? (Acceptance testing tool)"]]
 [[!meta date="2020-02-15 18:48"]]
-[[!tag subplot announcement draft]]
+[[!tag subplot announcement]]
 
 [Subplot]: https://subplot.liw.fi/
 [yarn]: https://liw.fi/cmdtest/

Change: scenario typesetting
diff --git a/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
index 47bccc8..c8c0696 100644
--- a/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
+++ b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
@@ -14,9 +14,9 @@ Would you be willing to try Subplot for acceptance testing for one of
 your real projects, and give us feedback? We're looking for two
 volunteers.
 
-> given a project  
-> when it uses Subplot  
-> then it is successful
+> *given* a project  
+> *when* it uses Subplot  
+> *then* it is successful
 
 [Subplot][] is a tool for capturing and automatically verifying the
 acceptance criteria for a software project or a system, in a way

Change: style for kitten photo
diff --git a/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
index f8e9d2c..47bccc8 100644
--- a/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
+++ b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
@@ -8,7 +8,7 @@
 [Lars Wirzenius]: https://liw.fi/
 [Daniel Silverstone]: https://blog.digital-scurf.org/
 
-[[!img kitten.jpg]]
+[[!img kitten.jpg class=floatTR]]
 
 Would you be willing to try Subplot for acceptance testing for one of
 your real projects, and give us feedback? We're looking for two

Add: kitten photo
diff --git a/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool/kitten.jpg b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool/kitten.jpg
new file mode 100644
index 0000000..837a8cd
Binary files /dev/null and b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool/kitten.jpg differ

Publish log entry
diff --git a/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
new file mode 100644
index 0000000..f8e9d2c
--- /dev/null
+++ b/posts/2020/02/15/subplot_volunteers_acceptance_testing_tool.mdwn
@@ -0,0 +1,91 @@
+[[!meta title="Subplot volunteers? (Acceptance testing tool)"]]
+[[!meta date="2020-02-15 18:48"]]
+[[!tag subplot announcement draft]]
+
+[Subplot]: https://subplot.liw.fi/
+[yarn]: https://liw.fi/cmdtest/
+[gitlab.com]: https://gitlab.com/larswirzenius/subplot
+[Lars Wirzenius]: https://liw.fi/
+[Daniel Silverstone]: https://blog.digital-scurf.org/
+
+[[!img kitten.jpg]]
+
+Would you be willing to try Subplot for acceptance testing for one of
+your real projects, and give us feedback? We're looking for two
+volunteers.
+
+> given a project  
+> when it uses Subplot  
+> then it is successful
+
+[Subplot][] is a tool for capturing and automatically verifying the
+acceptance criteria for a software project or a system, in a way
+that's understood by all stakeholders.
+
+In a software project there are always more than one stakeholder. Even
+in a project one writes for oneself, there are two stakeholders:
+oneself, and that malicious cretin oneself-in-the-future. More
+importantly, though, there are typically stakeholders such as end
+users, sysadmins, clients, software architects, developers, and
+testers. They all need to understand what the software should do, and
+when it's in an acceptable state to be put into use: in other words,
+what the acceptance criteria are.
+
+Crucially, all stakeholders should understand the acceptance criteria
+the same way, and also how to verify they are met. In an ideal
+situation, all verification is automated, and happens very frequently.
+
+There are various tools for this, from generic documentation tooling
+(word processors, text editors, markup languages, etc) to test
+automation (Cucumber, Selenium, etc). On the one hand, documenting
+acceptance criteria in a way that all stakeholders understand is
+crucial: otherwise the end users are at risk of getting something
+that's not useful to help them, and the project is a waste of
+everyone's time and money. On the other hand, automating the
+verification of how acceptance criteria is met is also crucial:
+otherwise it's done manually, which is slow, costly, and error prone,
+which increases the risk of project failure.
+
+Subplot aims to solve this by an approach that combines documentation
+tooling with automated verification.
+
+* The stakeholders in a project jointly produce a document that
+  captures all relevant acceptance criteria and also describes how
+  they can be verified automatically, using scenarios. The document is
+  written using Markdown.
+
+* The developer stakeholders produce code to implement the steps in
+  the scenarios. The Subplot approach allows the step implementations
+  to be done in a highly cohesive, de-coupled manner, making such code
+  usually be quite simple. (Test code should be your best code.)
+
+* Subplot's "docgen" program produces a typeset version as PDF or
+  HTML. This is meant to be easily comprehensible by all stakeholders.
+
+* Subplot's "codegen" program produces a test program in the language
+  used by the developer stakeholders. This test program can be run to
+  verify that acceptance criteria are met.
+
+Subplot started in in late 2018, and was initially called Fable. It is
+based on the [yarn][] tool for the same purpose, from 2013. Yarn has
+been in active use all its life, if not popular outside a small
+circle. Subplot improves on yarn by improving document generation,
+markup, and decoupling of concerns. Subplot is not compatible with
+yarn.
+
+Subplot is developed by [Lars Wirzenius][] and [Daniel Silverstone][]
+as a hobby project. It is free software, implemented in Rust,
+developed on Debian, and uses Pandoc and LaTeX for typesetting. The
+code is hosted on [gitlab.com][]. Subplot verifies its own acceptance
+criteria. It is alpha level software.
+
+We're looking for one or two volunteers to try Subplot on real
+projects of their own, and give us feedback. We want to make Subplot
+good for its purpose, also for people other than us. If you'd be
+willing to give it a try, start with the [Subplot][] website, then
+tell us you're using Subplot. We're happy to respond to questions from
+the first two volunteers, and from others, time permitting. (The
+reality of life and time constraints is that we can't commit to
+supporting more people at this time.)
+
+We'd love your feedback, whether you use Subplot or not.

Publish log entry
diff --git a/posts/2019/12/21/why_debian_isn_t_fun_for_me.mdwn b/posts/2019/12/21/why_debian_isn_t_fun_for_me.mdwn
new file mode 100644
index 0000000..2ae3bd8
--- /dev/null
+++ b/posts/2019/12/21/why_debian_isn_t_fun_for_me.mdwn
@@ -0,0 +1,32 @@
+[[!meta title="Why Debian isn't fun for me"]]
+[[!meta date="2019-12-21 10:13"]]
+[[!tag debian]]
+
+I retired from Debian as a developer a year ago. I said then that it
+was because Debian wasn't fun anymore, but I didn't unpack that much.
+It's been long enough that I feel I can do that. I should've done it
+back then, but I wasn't strong enough.
+
+A big part of Debian not being fun is that there's so much hatred in
+the project. There's people attacking others for who they are, be it
+women or trans or non-binary. There's people standing up to defend the
+attackers. Debian is just now going through another bout of that. It's
+sad and it's disgusting. And it reaffirms that I made the right
+decision getting out.
+
+[bout]: https://lists.debian.org/debian-project/2019/12/msg00069.html
+
+People denying other people their humanity, their very right to exist,
+is something Debian should not tolerate. I think Debian should exclude
+people who do that from the project. Likewise, people defending the
+right to deny others their humanity should equally unacceptable.
+
+De-humanizing rhetoric isn't the only reason Debian stopped being fun.
+Everything else seems irrelevant, though. If people don't want others
+to even exist, there's no point in discussing minor points like
+improving a consensus building culture, paying off at least a
+noticeable part of the technical debt Debian carries from the past
+quarter century, or smoothing away some of the worst sources of
+friction in the development process of the project.
+
+Stop the hatred. The good will follow.

Change: publish draft
diff --git a/posts/2019/12/13/date_formats_in_international_contexts.mdwn b/posts/2019/12/13/date_formats_in_international_contexts.mdwn
index 647bd97..bbe08ea 100644
--- a/posts/2019/12/13/date_formats_in_international_contexts.mdwn
+++ b/posts/2019/12/13/date_formats_in_international_contexts.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Date formats in international contexts"]]
 [[!meta date="2019-12-13 10:38"]]
-[[!tag draft]]
+[[!tag ]]
 
 [poll]: https://toot.liw.fi/@liw/103295475472501319
 

Publish log entry
diff --git a/posts/2019/12/13/date_formats_in_international_contexts.mdwn b/posts/2019/12/13/date_formats_in_international_contexts.mdwn
new file mode 100644
index 0000000..647bd97
--- /dev/null
+++ b/posts/2019/12/13/date_formats_in_international_contexts.mdwn
@@ -0,0 +1,35 @@
+[[!meta title="Date formats in international contexts"]]
+[[!meta date="2019-12-13 10:38"]]
+[[!tag draft]]
+
+[poll]: https://toot.liw.fi/@liw/103295475472501319
+
+I made a [poll][] on the fediverse yesterday.
+
+> In an international context (e.g., company that works around the
+> globe, or a free software project with participants from several
+> continents), what's the right date format?
+
+The options and results:
+
+* 80% &mdash; 2019-12-13
+* 11% &mdash; 19 December 2019
+* 9% &mdash; 13/12/2019
+* 0% &mdash; 12/13/2019
+
+The one with the name of the month is a different date than the
+others. That was a typo; mea culpa. Nobody commented on that, though,
+and I doubt it affected the results.
+
+Here's my commentary. It was a bit of a trick question. Sorry. The
+first two options are both unambiguous as to which part is day, month,
+and year. The last two are entirely ambiguous, and require contextual
+information to interpret correctly. Thus, even though the third option
+is closest to what I'm used to from my own culture, I think it's
+utterly unsuitable in an international context.
+
+My own preference is to express the month as a word, or abbreviation,
+but in many cases being all numeric is easier.
+
+The most important bit is to be clear and unambiguous. Sometimes that
+means getting used to an unfamiliar notation.

Fix: title (missing word)
diff --git a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
index c8ade6b..4c45eeb 100644
--- a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
+++ b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
@@ -1,4 +1,4 @@
-[[!meta title="Free software development doesn't have to awful"]]
+[[!meta title="Free software development doesn't have to be awful"]]
 [[!meta date="2019-11-03 09:43"]]
 [[!tag debian gnu rms software-freedom tolerance governance]]
 

Fix: add missing word
diff --git a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
index cd0caf6..c8ade6b 100644
--- a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
+++ b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
@@ -33,7 +33,7 @@ A few of the other people in Debian I don't want to be
 associated with in any way, any more.
 
 Debian has some vocal people who treat other people in ways that I
-don't want accept. I don't want to go into specifics, or names,
+don't want to accept. I don't want to go into specifics, or names,
 because that's not going help me move forward.
 
 This is of course not a new thing. Debian has had problems with people

Fix: typo
diff --git a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
index acd2ad6..cd0caf6 100644
--- a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
+++ b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
@@ -58,7 +58,7 @@ GNU project. A lot of people are religously defending RMS and
 attacking his detractors. I find this to be problematic.
 
 [LWN][] has an excellent article on the topic. RMS has been behaving
-in problematic ways for a long time. He's not been publicaly
+in problematic ways for a long time. He's not been publicly
 confronted about it before, at the scale he has been now.
 
 [LWN]: https://lwn.net/Articles/802985/

Fix: typo
diff --git a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
index 879e3fa..acd2ad6 100644
--- a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
+++ b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
@@ -108,7 +108,7 @@ What should we in the software freedom movement do about all this?
 I've come to a few conclusions so far, though my process to think
 about this is ongoing.
 
-* Most importantly, we need to stop be tolerant of intolerance and bad
+* Most importantly, we need to stop being tolerant of intolerance and bad
   behaviour. It's time for all project, groups, and organisations in
   the movement to have and enforce at least a minimal level of civil
   behaviour. We are a movement consisting of many communities, and

Fix: word order
diff --git a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
index 49a0a22..879e3fa 100644
--- a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
+++ b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
@@ -84,7 +84,7 @@ harmful behavour, and tolerance of it.
 Harmful behaviour comes in many forms. Some people, for example, say
 outright that they don't want women involved in free software
 development. Others attack gay, lesbian, trans, queer, black, old,
-young, Christian, Muslim, atheist, other any other group of people
+young, Christian, Muslim, atheist, any other other group of people
 identified by whatever attribute the attacker happens to dislike. Yet
 others are more subtle, not attacking directly, but not giving people
 in the group they dislike the same chance to participate, learn, grow,

Fix: typo
diff --git a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
index 201c062..49a0a22 100644
--- a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
+++ b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
@@ -23,7 +23,7 @@ tools, file formats, and workflows Debian uses are getting a little
 archaic, and generally sub-optimal. Even mundane, everyday tasks
 involved much more friction than they should. Another is that making
 any large changes in Debian is too much of an effort, these days,
-partly because inertial, partly because it involves so many people.
+partly because of inertia, partly because it involves so many people.
 
 All of that could have been tolerable, if not for the people. Some of
 the nicest, most competent people I know work on Debian. It has been a

Change: publish
diff --git a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
index 35d1631..201c062 100644
--- a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
+++ b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Free software development doesn't have to awful"]]
 [[!meta date="2019-11-03 09:43"]]
-[[!tag draft debian gnu rms software-freedom tolerance governance]]
+[[!tag debian gnu rms software-freedom tolerance governance]]
 
 I want to develop free software with people who lift up each other,
 and aren't arseholes.
@@ -156,3 +156,7 @@ is tolerated. I'm hoping this will have at least some effect.
 
 What about you?
 
+(My blog does not have comments, but you can respond to this 
+[fediverse][] thread: <https://toot.liw.fi/@liw/103080486083100970>.)
+
+[fediverse]: https://en.wikipedia.org/wiki/Fediverse

creating tag page tag/rms
diff --git a/tag/rms.mdwn b/tag/rms.mdwn
new file mode 100644
index 0000000..7063056
--- /dev/null
+++ b/tag/rms.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged rms"]]
+
+[[!inline pages="tagged(rms)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/gnu
diff --git a/tag/gnu.mdwn b/tag/gnu.mdwn
new file mode 100644
index 0000000..f17bb76
--- /dev/null
+++ b/tag/gnu.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged gnu"]]
+
+[[!inline pages="tagged(gnu)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/governance
diff --git a/tag/governance.mdwn b/tag/governance.mdwn
new file mode 100644
index 0000000..6e11bd5
--- /dev/null
+++ b/tag/governance.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged governance"]]
+
+[[!inline pages="tagged(governance)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/tolerance
diff --git a/tag/tolerance.mdwn b/tag/tolerance.mdwn
new file mode 100644
index 0000000..05386b4
--- /dev/null
+++ b/tag/tolerance.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged tolerance"]]
+
+[[!inline pages="tagged(tolerance)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
new file mode 100644
index 0000000..35d1631
--- /dev/null
+++ b/posts/2019/11/03/free_software_development_doesn_t_have_to_awful.mdwn
@@ -0,0 +1,158 @@
+[[!meta title="Free software development doesn't have to awful"]]
+[[!meta date="2019-11-03 09:43"]]
+[[!tag draft debian gnu rms software-freedom tolerance governance]]
+
+I want to develop free software with people who lift up each other,
+and aren't arseholes.
+
+A year ago I left Debian. The process is called retiring in Debian,
+and it's not final: if you do it in an orderly manner, you can come
+back again, and be re-instated as a Debian developer with a faster,
+more lightweight process than is used for entirely new developers.
+This was the third time I retired. The reasons were different than
+previously.
+
+The first two times I retired because I was pursuing other passions,
+and did not feel I could give Debian even the minimal attention and
+effort required to keep a few minor, leaf packages maintained. This
+time, I retired because Debian was not fun; it was in fact becoming
+awful, and I didn't want to participate anymore.
+
+Debian had stopped being fun for me in several ways. One was that the
+tools, file formats, and workflows Debian uses are getting a little
+archaic, and generally sub-optimal. Even mundane, everyday tasks
+involved much more friction than they should. Another is that making
+any large changes in Debian is too much of an effort, these days,
+partly because inertial, partly because it involves so many people.
+
+All of that could have been tolerable, if not for the people. Some of
+the nicest, most competent people I know work on Debian. It has been a
+privilege and a joy to work with them. 
+
+A few of the other people in Debian I don't want to be
+associated with in any way, any more.
+
+Debian has some vocal people who treat other people in ways that I
+don't want accept. I don't want to go into specifics, or names,
+because that's not going help me move forward.
+
+This is of course not a new thing. Debian has had problems with people
+behaving badly for years. I may have contributed to that, passively if
+not actively. However, as I get older, the friction from dealing with
+abrasive people is sanding off what thick skin I may have had when
+younger.
+
+As I get older, I am also learning that some of the things I thought
+were OK when I was younger, are in fact harmful to other people. I
+don't want to harm other people, and I don't want to participate in a
+project where some of the people insist on what I think is harmful
+behaviour, because they feel it's their right.
+
+Long after I left Debian, RMS managed to collapse the reality
+distortion field that's been surrounding and protecting him for many
+years. The triggering event for this was comments he made in a context
+involving Jeffrey Epstein. The comments caused a public uproar, and as
+a result RMS resigned from role of president of the Free Software
+Foundation, which he founded. He is currently still the leader of the
+GNU project. A lot of people are religously defending RMS and
+attacking his detractors. I find this to be problematic.
+
+[LWN][] has an excellent article on the topic. RMS has been behaving
+in problematic ways for a long time. He's not been publicaly
+confronted about it before, at the scale he has been now.
+
+[LWN]: https://lwn.net/Articles/802985/
+
+RMS has done some awesome things that he should be honoured for. He
+started the GNU project and gave it, and the world, a vision of being
+able to use computers whose entire software stack is free, and
+inventing copyleft, a legal tool to protect software freedom, as well
+as writing large amounts of the initial code in the GNU project. He
+has worked hard and long to help drive the vision of freedom into
+reality. For this, he shall always be remembered and revered.
+
+That doesn't excuse bad behaviour, such as insisting on abortion
+jokes, making women feel unwelcome in the GNU project, or various
+other things. I'm not going to make a list of his shortcomings,
+because this isn't a critique of RMS specifically. The problem I want
+to discuss isn't RMS or his personal behaviour.
+
+The problem I do want to discuss is that almost everywhere in the
+free and open source development communities there's a lot of
+harmful behavour, and tolerance of it.
+
+Harmful behaviour comes in many forms. Some people, for example, say
+outright that they don't want women involved in free software
+development. Others attack gay, lesbian, trans, queer, black, old,
+young, Christian, Muslim, atheist, other any other group of people
+identified by whatever attribute the attacker happens to dislike. Yet
+others are more subtle, not attacking directly, but not giving people
+in the group they dislike the same chance to participate, learn, grow,
+and generally be the best person they can be in the context of free
+software development.
+
+This doesn't just harm the groups of people being targeted. It harms
+others, who see it happen, and think they might be targeted too,
+later, maybe for some other reason. It harms reaching the vision of
+software freedom, because it shoves large parts of humanity outside
+the software freedom movement, robbing the movement from many voices
+and much effort. This makes it harder to achieve the vision.
+
+Excluding people from the movement for irrelevant reasons also harms
+humanity in general. It propagates the hate, hurt, and harm that is
+emblematic of life and politics around the world. While the software
+freedom movement can't solve all of those problems, we can and should
+at least not make it worse.
+
+What should we in the software freedom movement do about all this?
+I've come to a few conclusions so far, though my process to think
+about this is ongoing.
+
+* Most importantly, we need to stop be tolerant of intolerance and bad
+  behaviour. It's time for all project, groups, and organisations in
+  the movement to have and enforce at least a minimal level of civil
+  behaviour. We are a movement consisting of many communities, and
+  each community may want or need their own norms, and that's OK. Some
+  norms may even be in conflict. That's also OK, if unfortunate. 
+
+  Some people react to this kind of suggestion with hyperbolic claims
+  and conspiracy theories. I don't want to debate them. It's possible
+  to discuss community norms in a civil and constructive way. I know
+  this, because I've seen it happen many times. However, it requires
+  all participants to at least agree that there's behaviour that's
+  unwelcome, and not reject the notion of community norms outright.
+
+* I am by nature averse to conflicts. I will try to confront bad
+  behaviour in the future, rather than slinking away and going
+  elsewhere. I will at least speak out and say I think something is
+  unacceptable, when I see it.
+
+* I think the era for dictatorial models of governance for large free
+  software projects is over. For small projects, it's unavoidable,
+  because there's only one person doing any development, but when a
+  project grows, it doesn't work to have one person, or a small
+  anointed group, making all decisions. It's time to have more
+  democratic governance.
+
+  There are technical decisions that probably can't be done well by
+  letting everyone vote on them. However, every substantial project
+  will have other decisions that the whole community around the
+  project should have a say in. Voting on how to fix a bug may not be
+  workable, but voting on the minimum criteria for determining if a
+  bug fix is acceptable is. Should the project require adding a
+  regression test for any bug found in production? Should any such
+  test and bug fix be subjected to code review? Should such bugs and
+  their fixes be documented, even announced, publicly or kept secret?
+  How should security problems be handled?
+
+  In Debian, one of the guiding principles is that those who do,
+  decide. It seems time to involve those who use in the decision
+  making process as well.
+
+I can't force all communities in the software freedom movement to
+agree with me. Obviously not. I won't even try. I will, however, in
+the future be wary of joining dictatorial projects where bad behaviour
+is tolerated. I'm hoping this will have at least some effect.
+
+What about you?
+

Fix:typo
Thanks: Edward
diff --git a/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn b/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
index 57c52d1..e127123 100644
--- a/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
+++ b/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
@@ -38,5 +38,5 @@ process, and ideally recorded as automated test cases.
 Code coverage is most useful when the main user of a piece of code is
 a developer, usually the developer who writes or maintains the code.
 In this case, coverage helps ensure all interesting parts of the code
-are unit tested. The unit tests capture the use cvases and acceptance
+are unit tested. The unit tests capture the use cases and acceptance
 criteria, in very fine-grained details.

Change: publish
diff --git a/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn b/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
index cbae2c4..57c52d1 100644
--- a/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
+++ b/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Code coverage is almost pointless for tests"]]
 [[!meta date="2019-10-12 16:20"]]
-[[!tag draft automated-testing coverage use-case acceptance-criteria]]
+[[!tag automated-testing coverage use-case acceptance-criteria]]
 
 Measuring test coverage by measuring which parts of the code
 are executed tests is not useless, but it usually misses the point.

Change: tighten and clarify wording
diff --git a/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn b/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
index 9ce4dcd..cbae2c4 100644
--- a/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
+++ b/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
@@ -2,10 +2,8 @@
 [[!meta date="2019-10-12 16:20"]]
 [[!tag draft automated-testing coverage use-case acceptance-criteria]]
 
-Measuring test coverage by using a tool to see what parts of the code
+Measuring test coverage by measuring which parts of the code
 are executed tests is not useless, but it usually misses the point.
-Expressing coverage as a percent of all lines of code is almost
-entirely pointless.
 
 [rant]: https://blog.liw.fi/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing/
 
@@ -13,24 +11,29 @@ Tests are not meant to show the absence of bugs, but to show what
 aspects of a program or system work. (See my previous [rant][].) If
 your automated tests execute 90% of your code lines, is that good
 enough? It doesn't really tell you what is tested and, crucially, what
-isn't. Users don't care about code lines. Users care about features
-and functionality. In other words, they care about use cases, or more
-specifically, they care about use cases that are acceptance criteria.
+isn't. Those using the software don't care about code lines. They care
+about being able to do the things they want to do. In other words,
+they care about use cases and acceptance criteria.
 
 The 10% of code not covered by your tests? If users never exercise
-them, they're dead code, and should probably be deleted. If those
+that code, it's dead code, and should probably be removed. If those
 lines keep crashing the program, producing wrong results, causing data
 loss, security problems, privacy leaks, or otherwise cause
-dissatisfaction for users, then that's a problem. How do you know?
+dissatisfaction, then that's a problem. How do you know?
 
-Test coverage should be measured of use cases and acceptance criteria.
+Test coverage should be measuring use cases and acceptance criteria.
 These are often not explicit, or written down, or even known. In most
-projects there are a lot of acceptance criteria and use cases, that
+projects there are a lot of acceptance criteria and use cases that
 are implicit, and only become explicit, when things don't work the way
 users want them to.
 
-A practical test coverage would be how many of the explicit, known,
-recorded use cases are tested?
+A realistic test coverage would be how many of the explicit, known,
+recorded use cases and acceptance criteria are tested by automated
+tests.
+
+Use cases are not always acceptance criteria. Acceptance criteria are
+not always use cases. Both need to be captured during the development
+process, and ideally recorded as automated test cases.
 
 Code coverage is most useful when the main user of a piece of code is
 a developer, usually the developer who writes or maintains the code.

creating tag page tag/use-case
diff --git a/tag/use-case.mdwn b/tag/use-case.mdwn
new file mode 100644
index 0000000..dc7e953
--- /dev/null
+++ b/tag/use-case.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged use-case"]]
+
+[[!inline pages="tagged(use-case)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/acceptance-criteria
diff --git a/tag/acceptance-criteria.mdwn b/tag/acceptance-criteria.mdwn
new file mode 100644
index 0000000..632978f
--- /dev/null
+++ b/tag/acceptance-criteria.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged acceptance-criteria"]]
+
+[[!inline pages="tagged(acceptance-criteria)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/automated-testing
diff --git a/tag/automated-testing.mdwn b/tag/automated-testing.mdwn
new file mode 100644
index 0000000..3eb05db
--- /dev/null
+++ b/tag/automated-testing.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged automated-testing"]]
+
+[[!inline pages="tagged(automated-testing)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn b/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
new file mode 100644
index 0000000..9ce4dcd
--- /dev/null
+++ b/posts/2019/10/12/code_coverage_is_almost_pointless_for_tests.mdwn
@@ -0,0 +1,39 @@
+[[!meta title="Code coverage is almost pointless for tests"]]
+[[!meta date="2019-10-12 16:20"]]
+[[!tag draft automated-testing coverage use-case acceptance-criteria]]
+
+Measuring test coverage by using a tool to see what parts of the code
+are executed tests is not useless, but it usually misses the point.
+Expressing coverage as a percent of all lines of code is almost
+entirely pointless.
+
+[rant]: https://blog.liw.fi/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing/
+
+Tests are not meant to show the absence of bugs, but to show what
+aspects of a program or system work. (See my previous [rant][].) If
+your automated tests execute 90% of your code lines, is that good
+enough? It doesn't really tell you what is tested and, crucially, what
+isn't. Users don't care about code lines. Users care about features
+and functionality. In other words, they care about use cases, or more
+specifically, they care about use cases that are acceptance criteria.
+
+The 10% of code not covered by your tests? If users never exercise
+them, they're dead code, and should probably be deleted. If those
+lines keep crashing the program, producing wrong results, causing data
+loss, security problems, privacy leaks, or otherwise cause
+dissatisfaction for users, then that's a problem. How do you know?
+
+Test coverage should be measured of use cases and acceptance criteria.
+These are often not explicit, or written down, or even known. In most
+projects there are a lot of acceptance criteria and use cases, that
+are implicit, and only become explicit, when things don't work the way
+users want them to.
+
+A practical test coverage would be how many of the explicit, known,
+recorded use cases are tested?
+
+Code coverage is most useful when the main user of a piece of code is
+a developer, usually the developer who writes or maintains the code.
+In this case, coverage helps ensure all interesting parts of the code
+are unit tested. The unit tests capture the use cvases and acceptance
+criteria, in very fine-grained details.

Fix: word form
diff --git a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
index eaabcb8..fc2eb9e 100644
--- a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
+++ b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
@@ -59,7 +59,7 @@ Good stuff:
   Arduino with a fancy peripheral.
 * Keyboard layout can be configured with the Chrysalis desktop software,
   without having to build and update a whole new firmware blob. I've
-  used to convert what is normall num lock to be scroll lock, so I can
+  used to convert what is normally num lock to be scroll lock, so I can
   use it as a compose key.
 
 I don't really have complaints, but of course one can always whinge:

Change: publish
diff --git a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
index 5b65f28..eaabcb8 100644
--- a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
+++ b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Review: Keyboardio Model 01 keyboard"]]
 [[!meta date="2019-10-05 21:43"]]
-[[!tag draft review keyboardio]]
+[[!tag review keyboardio]]
 
 Some irrelevant personal history follows, skip to the next heading if
 uninterested. I first learnt to touch type on a portable, mechanical

Fix: plural
diff --git a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
index fdaffd0..5b65f28 100644
--- a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
+++ b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
@@ -83,4 +83,4 @@ offered to gift me a keyboard, they made no condition or request or
 even hint that I should write a review. They only asked that if I
 didn't like it, I'd gift it forward to some young hacker who would put
 it into good use, but couldn't afford it themselves. Sorry, young
-hacker, I'm keeping it.
+hackers, I'm keeping it.

Fix: word form
diff --git a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
index 7606458..fdaffd0 100644
--- a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
+++ b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
@@ -80,7 +80,7 @@ If necessary, I'd write another book to get one.
 
 Disclaimer: this review was not commissioned by Keyboardio. When they
 offered to gift me a keyboard, they made no condition or request or
-even hinted that I should write a review. They only asked that if I
+even hint that I should write a review. They only asked that if I
 didn't like it, I'd gift it forward to some young hacker who would put
 it into good use, but couldn't afford it themselves. Sorry, young
 hacker, I'm keeping it.

Fix: add missing word
diff --git a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
index 41726d1..7606458 100644
--- a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
+++ b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
@@ -2,7 +2,7 @@
 [[!meta date="2019-10-05 21:43"]]
 [[!tag draft review keyboardio]]
 
-Some irrelevant personal history follows, skip to next heading if
+Some irrelevant personal history follows, skip to the next heading if
 uninterested. I first learnt to touch type on a portable, mechanical
 typewriter in my early teens. It was a somewhat painful process: when
 I hit a key a little wrong, my finger would plunge between the keys

creating tag page tag/keyboardio
diff --git a/tag/keyboardio.mdwn b/tag/keyboardio.mdwn
new file mode 100644
index 0000000..d770e03
--- /dev/null
+++ b/tag/keyboardio.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged keyboardio"]]
+
+[[!inline pages="tagged(keyboardio)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
new file mode 100644
index 0000000..41726d1
--- /dev/null
+++ b/posts/2019/10/05/review_keyboardio_model_01_keyboard.mdwn
@@ -0,0 +1,86 @@
+[[!meta title="Review: Keyboardio Model 01 keyboard"]]
+[[!meta date="2019-10-05 21:43"]]
+[[!tag draft review keyboardio]]
+
+Some irrelevant personal history follows, skip to next heading if
+uninterested. I first learnt to touch type on a portable, mechanical
+typewriter in my early teens. It was a somewhat painful process: when
+I hit a key a little wrong, my finger would plunge between the keys
+into the internals of the typewriter, which was full of sharpish metal
+edges. I lost some blood to gain typing skills.
+
+Typing on computers is a joy in comparison. However, there's big
+differences between different keyboards. Over the decades I've learnt to
+prefer some types over others. Overall, my preference is for keyboards
+with mechanical switches over more rubbery ones. I type better and
+faster and more accurately when my fingers can sense that a key has been
+pressed.
+
+For some time I'd been using gaming PC keyboards with Cherry MX red
+switches. These are a joy to type on, but are quite noisy. I've also
+been curious about split keyboards. Earlier this year I heard of the
+[Keyboardio Model01](https://shop.keyboard.io/) keyboard, which started
+as a crowdfunded project. I was curious.
+
+However, it's expensive, for me, and quite different from anything I'd
+ever used before, so I was hesitant to get one. Luckily, I was
+introduced online to one of the founders of Keyboardio, who said they'd
+enjoyed the book I wrote for the Linux Documentation Project in the 90s,
+and would like to donate a keyboard for me. Joy!
+
+# Review
+
+I've been using the keyboard for some weeks now. Initially, I only used
+it to learn to touch type all over again. Not only is the keyboard
+different from any I'd been using before, but it seemed better suited to
+the US qwerty layout than the Finnish one, so I've been learning both a
+new physical layout and a logical layout.
+
+Also, I've been curious of using a US layout for programming for some
+time, and this is the perfect excuse to learn. Much fun. Luckily, it's
+not been actually painful, and I've not lost any blood this time.
+
+Now that I'm getting a little closer to my previous typing speed of 60
+words per minute on the new keyboard, it is time to write this review.
+I've never been a fast typist, but this speed seems to be fast enough
+that my brain doesn't get bored or frustrated waiting for my fingers
+to do their thing.
+
+Good stuff:
+
+* It just works. Plug it in via USB, and start typing.
+* Typing feel is great. It's fairly quiet, thanks to using Matias Quiet
+  Click key switches, instead of Cherry ones. Yet there's no doubt
+  about having pressed a key.
+* Build quality is good. Feels solid. They call it heirloom-grade,
+  and I can imagine this one lasting me decades.
+* The firmware is free software, hackable, and changing it does not void
+  warranty. I've not managed to brick the device. It's basically an
+  Arduino with a fancy peripheral.
+* Keyboard layout can be configured with the Chrysalis desktop software,
+  without having to build and update a whole new firmware blob. I've
+  used to convert what is normall num lock to be scroll lock, so I can
+  use it as a compose key.
+
+I don't really have complaints, but of course one can always whinge:
+
+* The Keyboardio website is a little disorganised and could be improved.
+  There might be a need for a documentation project just for this
+  keyboard and its firmware and associated software.
+* Oh boy does it take time and effort to learn to type all over again.
+  Even if it's worth it, it's still frustrating to re-learn something
+  I first learnt almost forty years ago.
+* I wasn't overly impressed with the bundled cables (USB-C and
+  Ethernet), but they're easy enough to replace. I now have cables
+  that are just the right length, even if it seems silly to use CAT7
+  to connect two halves of a keyboard.
+
+Verdict: I like the keyboard. If I lost it, I'd want to buy a new one.
+If necessary, I'd write another book to get one.
+
+Disclaimer: this review was not commissioned by Keyboardio. When they
+offered to gift me a keyboard, they made no condition or request or
+even hinted that I should write a review. They only asked that if I
+didn't like it, I'd gift it forward to some young hacker who would put
+it into good use, but couldn't afford it themselves. Sorry, young
+hacker, I'm keeping it.

Change: publish
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index a8d894d..b21d311 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -1,5 +1,5 @@
 [[!meta title="The reMarkable tablet: a review"]]
-[[!tag draft review remarkable]]
+[[!tag review remarkable]]
 [[!meta date="2019-09-22 10:00"]]
 
 [reMarkable]: https://remarkable.com/

Add: more emphasis
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index 857161a..a8d894d 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -73,7 +73,7 @@ considering to buy one.
   support would result in more hardware sold.
 
 * The way it renders PDF tables of content is ugly, hard to read, a
-  little slow, and a little easy to misnavigate.
+  little slow, and a little too easy to misnavigate.
 
 * The tablet does not follow intra-document links in PDFs. In some
   books this is annoying.

Fix: q to a
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index 88ef0ca..857161a 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -79,7 +79,7 @@ considering to buy one.
   books this is annoying.
 
 * There's a bug in the firmware when exporting annotations you've made
-  to q PDF with different sized pages. It turns out a lot of the books
+  to a PDF with different sized pages. It turns out a lot of the books
   I've bought as PDF have a cover page that's of a different size to
   the interior pages, and the tablet exports annotations relative to
   the top left of the cover page, rather than the page where the

Change: clarify free
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index 5321521..88ef0ca 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -62,7 +62,9 @@ considering to buy one.
   sure why it doesn't cache more, since I have gigabytes of free
   space.
 
-* The software isn't free, and the APIs, file formats, and data
+[free]: https://www.debian.org/social_contract#guidelines
+
+* The software isn't [free][], and the APIs, file formats, and data
   structures are not documented. This makes it harder to, say, sync
   any new documents to the device automatically. I bet the company
   would get an enthusiastic developer community in no time, if they

Add: ToC is hard to read
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index 705c4a4..5321521 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -70,8 +70,8 @@ considering to buy one.
   given they make their money from hardware sales and better software
   support would result in more hardware sold.
 
-* The way it renders PDF tables of content is ugly, a little slow, and
-  a little easy to misnavigate.
+* The way it renders PDF tables of content is ugly, hard to read, a
+  little slow, and a little easy to misnavigate.
 
 * The tablet does not follow intra-document links in PDFs. In some
   books this is annoying.

Fix: add missing word
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index f786980..705c4a4 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -4,7 +4,7 @@
 
 [reMarkable]: https://remarkable.com/
 
-The [reMarkable][] tablet is a 10" e-paper tablet on which you can PDF
+The [reMarkable][] tablet is a 10" e-paper tablet on which you can read PDF
 and ePub files, and write on with the stylus that comes with the
 device. It has fundamentally changed how I read textbooks.
 

Add: why sw dev community would benefit
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index b553706..f786980 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -66,7 +66,9 @@ considering to buy one.
   structures are not documented. This makes it harder to, say, sync
   any new documents to the device automatically. I bet the company
   would get an enthusiastic developer community in no time, if they
-  opened up the software.
+  opened up the software. That seems like it would be a no-brainer,
+  given they make their money from hardware sales and better software
+  support would result in more hardware sold.
 
 * The way it renders PDF tables of content is ugly, a little slow, and
   a little easy to misnavigate.

Fix: they/it
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index 6f2a548..b553706 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -56,10 +56,10 @@ but I feel I should mention them in case someone reading this is
 considering to buy one.
 
 * While the tablet keeps up with writing just fine, it's a little slow
-  when jumping around a long document. It feels like they only cache a
-  few pages in full, and thumbnails of the rest, if that, and have to
-  re-render pages. This makes jumping around a little tedious. I'm not
-  sure why they don't cache more, since I have gigabytes of free
+  when jumping around a long document. It feels like it only caches a
+  few pages in full, and thumbnails of the rest, if that, and has to
+  re-render pages often. This makes jumping around a little tedious. I'm not
+  sure why it doesn't cache more, since I have gigabytes of free
   space.
 
 * The software isn't free, and the APIs, file formats, and data

Fix: missing word
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index b2513eb..6f2a548 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -42,10 +42,10 @@ Things I especially like:
 * Writing is natural and smooth, almost exactly like writing on paper.
   The tablet seems to not have any trouble keeping up with the pen.
 
-* Did you know it's fun to scribble notes on books? It wasn't when I
-  was in school, since books were shared and often borrowed from the
-  school. So much fun! Also, seems to make comprehension better for
-  me.
+* Did you know it's fun to  scribble notes on books? It wasn't allowed
+  when I  was in school,  since books  were shared and  often borrowed
+  from  the school.  So much  fun! Also,  seems to  make comprehension
+  better for me.
 
 * There are no distractions on the device, except all the other books
   you've put there.

Change: para on old lib
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index 6891c1e..b2513eb 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -8,6 +8,10 @@ The [reMarkable][] tablet is a 10" e-paper tablet on which you can PDF
 and ePub files, and write on with the stylus that comes with the
 device. It has fundamentally changed how I read textbooks.
 
+I used to collect books, and was proud of my library. I have a
+custom-made book case, with about 20 shelf meters of space. Not huge,
+but I curated my dead trees carefully.
+
 I have for years not liked having paper books. They're expensive to
 store (need a larger home, and thus higher rent), and become quite
 heavy to carry (I've moved home more than twenty times in my life).

Add: verdict
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
index 78dfcf0..6891c1e 100644
--- a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -76,3 +76,5 @@ considering to buy one.
   the interior pages, and the tablet exports annotations relative to
   the top left of the cover page, rather than the page where the
   annotations are.
+
+Verdict: I like the tablet, and would buy a new one if I lost mine.

creating tag page tag/review
diff --git a/tag/review.mdwn b/tag/review.mdwn
new file mode 100644
index 0000000..8e28525
--- /dev/null
+++ b/tag/review.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged review"]]
+
+[[!inline pages="tagged(review)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/remarkable
diff --git a/tag/remarkable.mdwn b/tag/remarkable.mdwn
new file mode 100644
index 0000000..6ff8c23
--- /dev/null
+++ b/tag/remarkable.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged remarkable"]]
+
+[[!inline pages="tagged(remarkable)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
new file mode 100644
index 0000000..78dfcf0
--- /dev/null
+++ b/posts/2019/09/22/the_remarkable_tablet_a_review.mdwn
@@ -0,0 +1,78 @@
+[[!meta title="The reMarkable tablet: a review"]]
+[[!tag draft review remarkable]]
+[[!meta date="2019-09-22 10:00"]]
+
+[reMarkable]: https://remarkable.com/
+
+The [reMarkable][] tablet is a 10" e-paper tablet on which you can PDF
+and ePub files, and write on with the stylus that comes with the
+device. It has fundamentally changed how I read textbooks.
+
+I have for years not liked having paper books. They're expensive to
+store (need a larger home, and thus higher rent), and become quite
+heavy to carry (I've moved home more than twenty times in my life).
+For a decade now I've preferred e-books. However, Kindle devices, or
+their competitors, tend to be small, paperback size. That's no good
+for texts that have graphs, diagrams, tables. Worse, most e-book
+formats are reflowable, which is great for novels and straight prose,
+but not so good for textbooks or other works that need layout.
+
+I have, over the years, bought a number of textbooks as PDFs. PDF is
+in many ways an excellent format for textbooks. However, I've lacked a
+convenient way to read them. Reading on a laptop screen is awkward,
+due to the small screen. Reading on an external monitor is
+uncomfortable, since it ties me to my desk. Also, it's very easy to be
+distracted when at my computer (IRC, the Fediverse, email, RSS, ...
+and if nothing else, there's a web browser and Wikipedia).
+
+I bought the reMarkable tablet almost a year ago, after starting a new
+job, and getting my first couple of salaries. It's a little expensive,
+but I felt like splurging, and was in a privileged position to do so.
+I've not regretted it.
+
+Things I especially like:
+
+* The screen is big enough for most books, and big enough for me to
+  read A4 (or letter) sized documents without problems.
+
+* Writing is natural and smooth, almost exactly like writing on paper.
+  The tablet seems to not have any trouble keeping up with the pen.
+
+* Did you know it's fun to scribble notes on books? It wasn't when I
+  was in school, since books were shared and often borrowed from the
+  school. So much fun! Also, seems to make comprehension better for
+  me.
+
+* There are no distractions on the device, except all the other books
+  you've put there.
+
+There are some things I don't much like, of course. They're not big
+enough to prevent me from using the device, and finding it a pleasure,
+but I feel I should mention them in case someone reading this is
+considering to buy one.
+
+* While the tablet keeps up with writing just fine, it's a little slow
+  when jumping around a long document. It feels like they only cache a
+  few pages in full, and thumbnails of the rest, if that, and have to
+  re-render pages. This makes jumping around a little tedious. I'm not
+  sure why they don't cache more, since I have gigabytes of free
+  space.
+
+* The software isn't free, and the APIs, file formats, and data
+  structures are not documented. This makes it harder to, say, sync
+  any new documents to the device automatically. I bet the company
+  would get an enthusiastic developer community in no time, if they
+  opened up the software.
+
+* The way it renders PDF tables of content is ugly, a little slow, and
+  a little easy to misnavigate.
+
+* The tablet does not follow intra-document links in PDFs. In some
+  books this is annoying.
+
+* There's a bug in the firmware when exporting annotations you've made
+  to q PDF with different sized pages. It turns out a lot of the books
+  I've bought as PDF have a cover page that's of a different size to
+  the interior pages, and the tablet exports annotations relative to
+  the top left of the cover page, rather than the page where the
+  annotations are.

Change: publish subplot post
diff --git a/posts/2019/09/17/subplot_-_new_name_for_acceptance_testing_tool.mdwn b/posts/2019/09/17/subplot_-_new_name_for_acceptance_testing_tool.mdwn
index 0c37e9e..e0f0035 100644
--- a/posts/2019/09/17/subplot_-_new_name_for_acceptance_testing_tool.mdwn
+++ b/posts/2019/09/17/subplot_-_new_name_for_acceptance_testing_tool.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Subplot - new name for acceptance testing tool"]]
 [[!meta date="2019-09-17 09:09"]]
-[[!tag draft fable subplot announcement ]]
+[[!tag fable subplot announcement ]]
 
 Recently I announced a tool for acceptance testing. It turned out that
 the name we'd chosen was already used by another testing tool, so we

creating tag page tag/subplot
diff --git a/tag/subplot.mdwn b/tag/subplot.mdwn
new file mode 100644
index 0000000..b2c8bb4
--- /dev/null
+++ b/tag/subplot.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged subplot"]]
+
+[[!inline pages="tagged(subplot)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2019/09/17/subplot_-_new_name_for_acceptance_testing_tool.mdwn b/posts/2019/09/17/subplot_-_new_name_for_acceptance_testing_tool.mdwn
new file mode 100644
index 0000000..0c37e9e
--- /dev/null
+++ b/posts/2019/09/17/subplot_-_new_name_for_acceptance_testing_tool.mdwn
@@ -0,0 +1,16 @@
+[[!meta title="Subplot - new name for acceptance testing tool"]]
+[[!meta date="2019-09-17 09:09"]]
+[[!tag draft fable subplot announcement ]]
+
+Recently I announced a tool for acceptance testing. It turned out that
+the name we'd chosen was already used by another testing tool, so we
+renamed ours. The new name is [Subplot][] (the old name was [Fable][]).
+
+[Subplot]: https://subplot.liw.fi/
+[Fable]: https://blog.liw.fi/posts/2019/08/24/fable_for_acceptance_testing/
+
+Work on the production implementation has started. If you are good at
+typography, help with automated typesetting of Subplot documents would
+be greatly appreciated. The goal: to use typography to make Subplot
+documents as easily understood and as effective at communicating
+acceptance criteria as possible.

Change: publish draft
diff --git a/posts/2019/08/24/fable_for_acceptance_testing.mdwn b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
index 327b22f..6a88db5 100644
--- a/posts/2019/08/24/fable_for_acceptance_testing.mdwn
+++ b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
@@ -1,5 +1,5 @@
 [[!meta date="2019-08-24 09:44"]]
-[[!tag fable announcement draft]]
+[[!tag fable announcement]]
 [[!meta title="Fable for acceptance testing"]]
 
 [Lars Wirzenius]: https://liw.fi/

Fix: spelling etc
diff --git a/posts/2019/08/24/fable_for_acceptance_testing.mdwn b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
index b6b2f0e..327b22f 100644
--- a/posts/2019/08/24/fable_for_acceptance_testing.mdwn
+++ b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
@@ -6,7 +6,7 @@
 [Daniel Silverstone]: https://blog.digital-scurf.org/
 [Fable home page]: https://fable.liw.fi/
 [tutorial]: https://fable-files.liw.fi/fable-poc/tutorial.html
-[pdf]: https://fable-files.liw.fi/fable-poc/tutorial.pdf
+[PDF]: https://fable-files.liw.fi/fable-poc/tutorial.pdf
 
 [Lars Wirzenius][] and [Daniel Silverstone][] announce the Fable project.
 
@@ -15,11 +15,11 @@
 > _then_ all stakeholders understand them  
 > _and_ they can be automatically tested
 
-Fable is a toolset for documenting acceptance criteria for a system,
+Fable is a tool set for documenting acceptance criteria for a system,
 in a way that's understandable by all stakeholders, and for
-implementing automated tests to verify the crietria are being met.
+implementing automated tests to verify the criteria are being met.
 
 See the [Fable home page][], including links to source code and Debian
-packages. There is a [tutorial][] ([pdf][]), examples, and
+packages. There is a [tutorial][] ([PDF][]), examples, and
 documentation. Fable is free software, but doesn't constrain the
 license of the generated documentation or test programs.

Fix: improvements from Daniel
diff --git a/posts/2019/08/24/fable_for_acceptance_testing.mdwn b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
index e433639..b6b2f0e 100644
--- a/posts/2019/08/24/fable_for_acceptance_testing.mdwn
+++ b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
@@ -12,13 +12,14 @@
 
 > _given_ all stakeholders need to understand acceptance criteria  
 > _when_ Fable is used to document them  
-> _then_ Fable can be used to automatically test them
+> _then_ all stakeholders understand them  
+> _and_ they can be automatically tested
 
-Fable is a toolset for documenting acceptance crietria for a system,
+Fable is a toolset for documenting acceptance criteria for a system,
 in a way that's understandable by all stakeholders, and for
 implementing automated tests to verify the crietria are being met.
 
-See the [Fable home page][], including links to source code an Debian
+See the [Fable home page][], including links to source code and Debian
 packages. There is a [tutorial][] ([pdf][]), examples, and
 documentation. Fable is free software, but doesn't constrain the
 license of the generated documentation or test programs.

Fix: link to Daniel
diff --git a/posts/2019/08/24/fable_for_acceptance_testing.mdwn b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
index fe633aa..e433639 100644
--- a/posts/2019/08/24/fable_for_acceptance_testing.mdwn
+++ b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
@@ -3,7 +3,7 @@
 [[!meta title="Fable for acceptance testing"]]
 
 [Lars Wirzenius]: https://liw.fi/
-[Daniel Silverstone]: http://www.digital-scurf.org/index.html
+[Daniel Silverstone]: https://blog.digital-scurf.org/
 [Fable home page]: https://fable.liw.fi/
 [tutorial]: https://fable-files.liw.fi/fable-poc/tutorial.html
 [pdf]: https://fable-files.liw.fi/fable-poc/tutorial.pdf

Fix: formatting
diff --git a/posts/2019/08/24/fable_for_acceptance_testing.mdwn b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
index 029b4bb..fe633aa 100644
--- a/posts/2019/08/24/fable_for_acceptance_testing.mdwn
+++ b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
@@ -10,8 +10,8 @@
 
 [Lars Wirzenius][] and [Daniel Silverstone][] announce the Fable project.
 
-> _given_ all stakeholders need to understand acceptance criteria
-> _when_ Fable is used to document them
+> _given_ all stakeholders need to understand acceptance criteria  
+> _when_ Fable is used to document them  
 > _then_ Fable can be used to automatically test them
 
 Fable is a toolset for documenting acceptance crietria for a system,

creating tag page tag/fable
diff --git a/tag/fable.mdwn b/tag/fable.mdwn
new file mode 100644
index 0000000..ba03706
--- /dev/null
+++ b/tag/fable.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged fable"]]
+
+[[!inline pages="tagged(fable)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2019/08/24/fable_for_acceptance_testing.mdwn b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
new file mode 100644
index 0000000..029b4bb
--- /dev/null
+++ b/posts/2019/08/24/fable_for_acceptance_testing.mdwn
@@ -0,0 +1,24 @@
+[[!meta date="2019-08-24 09:44"]]
+[[!tag fable announcement draft]]
+[[!meta title="Fable for acceptance testing"]]
+
+[Lars Wirzenius]: https://liw.fi/
+[Daniel Silverstone]: http://www.digital-scurf.org/index.html
+[Fable home page]: https://fable.liw.fi/
+[tutorial]: https://fable-files.liw.fi/fable-poc/tutorial.html
+[pdf]: https://fable-files.liw.fi/fable-poc/tutorial.pdf
+
+[Lars Wirzenius][] and [Daniel Silverstone][] announce the Fable project.
+
+> _given_ all stakeholders need to understand acceptance criteria
+> _when_ Fable is used to document them
+> _then_ Fable can be used to automatically test them
+
+Fable is a toolset for documenting acceptance crietria for a system,
+in a way that's understandable by all stakeholders, and for
+implementing automated tests to verify the crietria are being met.
+
+See the [Fable home page][], including links to source code an Debian
+packages. There is a [tutorial][] ([pdf][]), examples, and
+documentation. Fable is free software, but doesn't constrain the
+license of the generated documentation or test programs.

Add: Mastodon verification link
diff --git a/index.mdwn b/index.mdwn
index 5d109f4..a20cb44 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -6,6 +6,9 @@ introduction. See the [[archive|posts]] page for all posts. (There is an
 [Moderation policy](http://liw.fi/moderation/)
 [Main site](http://liw.fi/)
 
+Me on <a rel="me" href="https://toot.liw.fi/@liw">Mastodon</a>, for
+anything that is too small to warrant a blog post.
+
 All content outside of comments is copyrighted by Lars Wirzenius, and
 licensed under a <a rel="license"
 href="http://creativecommons.org/licenses/by-sa/3.0/">Creative Commons

Change: publish
diff --git a/posts/2019/07/02/debian_and_the_sks_signature_flooding_attack.mdwn b/posts/2019/07/02/debian_and_the_sks_signature_flooding_attack.mdwn
index 94e9624..54f999b 100644
--- a/posts/2019/07/02/debian_and_the_sks_signature_flooding_attack.mdwn
+++ b/posts/2019/07/02/debian_and_the_sks_signature_flooding_attack.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Debian and the SKS signature flooding attack"]]
 [[!meta date="2019-07-02 17:18"]]
-[[!tag draft debian keyserver pgp]]
+[[!tag debian keyserver pgp]]
 
 Debian uses PGP keys of its uploading members to authenticate package
 uploads. The keys are stored in a keyring maintained by the

creating tag page tag/keyserver
diff --git a/tag/keyserver.mdwn b/tag/keyserver.mdwn
new file mode 100644
index 0000000..c13ce07
--- /dev/null
+++ b/tag/keyserver.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged keyserver"]]
+
+[[!inline pages="tagged(keyserver)" actions="no" archive="yes"
+feedshow=10]]

creating tag page tag/pgp
diff --git a/tag/pgp.mdwn b/tag/pgp.mdwn
new file mode 100644
index 0000000..73313f1
--- /dev/null
+++ b/tag/pgp.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged pgp"]]
+
+[[!inline pages="tagged(pgp)" actions="no" archive="yes"
+feedshow=10]]

Publish log entry
diff --git a/posts/2019/07/02/debian_and_the_sks_signature_flooding_attack.mdwn b/posts/2019/07/02/debian_and_the_sks_signature_flooding_attack.mdwn
new file mode 100644
index 0000000..94e9624
--- /dev/null
+++ b/posts/2019/07/02/debian_and_the_sks_signature_flooding_attack.mdwn
@@ -0,0 +1,28 @@
+[[!meta title="Debian and the SKS signature flooding attack"]]
+[[!meta date="2019-07-02 17:18"]]
+[[!tag draft debian keyserver pgp]]
+
+Debian uses PGP keys of its uploading members to authenticate package
+uploads. The keys are stored in a keyring maintained by the
+keyring-maint team. The team also maintains a PGP keyserver, and new
+keys and signatures are uploaded there. The Debian keyserver gets new
+signatures from other keyservers, but only accepts signatures by keys
+already in the Debian keyring. New keys are accepted into the keyring
+manually, after a vetting process of the person. Updates from the
+Debian keyserver to the Debian keyring happen manually, roughly once a
+month. Only package uploads signed by keys in the Debian keyring get
+accepted by the Debian package archive.
+
+The Debian package archive is signed by another key, securely
+maintained by the Debian FTP team. A copy of the public key is
+installed on every Debian machine, and updates to the key, as well
+as new keys, are distributed via package updates. This happens
+routinely in Debian.
+
+Because of these reasons, Debian seems immune to the current attack on
+the SKS keyserver network, since Debian isn't getting those
+signatures, and the Debian package archive and updates to machines
+running Debian aren't getting the fraudulent signatures either.
+
+(I've checked the above text with the keyring-maint team and they are
+OK with it.)

Change: publish
diff --git a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
index b0e67ea..65abea0 100644
--- a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
+++ b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
@@ -1,5 +1,5 @@
 [[!meta date="2019-06-29 15:58"]]
-[[!tag draft testing software-development]]
+[[!tag testing software-development]]
 [[!meta title="Dijkstra was only partially correct about testing"]]
 
 [Edsger Dijkstra]: https://en.wikipedia.org/wiki/Edsger_W._Dijkstra

Fix: typo
diff --git a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
index d83a61f..b0e67ea 100644
--- a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
+++ b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
@@ -17,7 +17,7 @@ correctness in software development.)
 This is used from time to time to claim testing is pointless. I object
 to that sentiment. Dijkstra's quip is funny, but it's only partly
 correct, for general software development, that testing can't show the
-absence of bugs. More importantly, testing is mean to show the absence
+absence of bugs. More importantly, testing is meant to show the absence
 of bugs.
 
 Testing is about showing what works.

Fix: typos
diff --git a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
index f5b7ee4..d83a61f 100644
--- a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
+++ b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
@@ -22,7 +22,7 @@ of bugs.
 
 Testing is about showing what works.
 
-Consider the physical world, from the point of a phycisist. What
+Consider the physical world, from the point of a physicist. What
 happens if you drop an apple? It falls down. The physicist needs to
 answer the question: Does all fruit always fall down?
 
@@ -33,10 +33,10 @@ there's a lot of people watching? When there's betting about what
 happens?
 
 To answer the question, the physicist needs to drop a very large
-number of diffrent fruit, a very large number of times, in all sorts
+number of different fruit, a very large number of times, in all sorts
 of environment and contexts. And eventually, they form a hypothesis
 that yes, all fruit always falls down. After a long time, after many
-other phycisists have tried everything they can think of to prove the
+other physicists have tried everything they can think of to prove the
 hypothesis wrong, the community of physicists accepts the hypothesis
 as true: all fruit always falls down when dropped.
 
@@ -56,6 +56,6 @@ to cover the case you're interested in.
 If the suite of tests misses a use case, and the code happens not to
 work in that particular case, that does not mean testing is useless,
 or that there's no point in even trying. If you don't have a test for
-dropping an orange in outer space, you don't know if organges fall in
+dropping an orange in outer space, you don't know if oranges fall in
 outer space. It doesn't mean physics is pointless. If you care about
 dropping fruit in outer space, you go to outer space and try it.

Change: clarify trying to prove hypothesis wrong
diff --git a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
index 1e03604..f5b7ee4 100644
--- a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
+++ b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
@@ -34,11 +34,11 @@ happens?
 
 To answer the question, the physicist needs to drop a very large
 number of diffrent fruit, a very large number of times, in all sorts
-of environment and contexts. And eventually, they form a
-hypothesis that yes, all fruit always falls down. After a long time,
-after many other phycisists have tried hard to prove the hypothesis
-wrong, the community of physicists accepts the hypothesis as true: all
-fruit always falls down when dropped.
+of environment and contexts. And eventually, they form a hypothesis
+that yes, all fruit always falls down. After a long time, after many
+other phycisists have tried everything they can think of to prove the
+hypothesis wrong, the community of physicists accepts the hypothesis
+as true: all fruit always falls down when dropped.
 
 Until someone goes to outer space. And then no fruit falls. It just
 floats there looking smug.

Change: remove unnecessary fancy word
diff --git a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
index 4c028a6..1e03604 100644
--- a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
+++ b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
@@ -34,7 +34,7 @@ happens?
 
 To answer the question, the physicist needs to drop a very large
 number of diffrent fruit, a very large number of times, in all sorts
-of environment and contexts. And eventually, they form a falsiafiable
+of environment and contexts. And eventually, they form a
 hypothesis that yes, all fruit always falls down. After a long time,
 after many other phycisists have tried hard to prove the hypothesis
 wrong, the community of physicists accepts the hypothesis as true: all

Fix: typo
diff --git a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
index 0ec6536..4c028a6 100644
--- a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
+++ b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
@@ -35,7 +35,7 @@ happens?
 To answer the question, the physicist needs to drop a very large
 number of diffrent fruit, a very large number of times, in all sorts
 of environment and contexts. And eventually, they form a falsiafiable
-hypothesis that yes, all fruit always fall down. After a long time,
+hypothesis that yes, all fruit always falls down. After a long time,
 after many other phycisists have tried hard to prove the hypothesis
 wrong, the community of physicists accepts the hypothesis as true: all
 fruit always falls down when dropped.

creating tag page tag/software-development
diff --git a/tag/software-development.mdwn b/tag/software-development.mdwn
new file mode 100644
index 0000000..df568da
--- /dev/null
+++ b/tag/software-development.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged software-development"]]
+
+[[!inline pages="tagged(software-development)" actions="no" archive="yes"
+feedshow=10]]

Add: tags
diff --git a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
index 757cd1a..0ec6536 100644
--- a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
+++ b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
@@ -1,5 +1,5 @@
 [[!meta date="2019-06-29 15:58"]]
-[[!tag draft]]
+[[!tag draft testing software-development]]
 [[!meta title="Dijkstra was only partially correct about testing"]]
 
 [Edsger Dijkstra]: https://en.wikipedia.org/wiki/Edsger_W._Dijkstra

Change: clafify Dijkstra's description
diff --git a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
index 5f328b2..757cd1a 100644
--- a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
+++ b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
@@ -6,7 +6,8 @@
 [testing]: https://en.wikiquote.org/wiki/Edsger_W._Dijkstra#1960s
 
 [Edsger Dijkstra][] was one of the most influential computer
-scientists. One of the many quotes from is about [testing][]:
+scientists, in the early days of the field. One of the many quotes
+from him is about [testing][]:
 
 > Testing shows the presence, not the absence of bugs 
 

Publish log entry
diff --git a/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
new file mode 100644
index 0000000..5f328b2
--- /dev/null
+++ b/posts/2019/06/29/dijkstra_was_only_partially_correct_about_testing.mdwn
@@ -0,0 +1,60 @@
+[[!meta date="2019-06-29 15:58"]]
+[[!tag draft]]
+[[!meta title="Dijkstra was only partially correct about testing"]]
+
+[Edsger Dijkstra]: https://en.wikipedia.org/wiki/Edsger_W._Dijkstra
+[testing]: https://en.wikiquote.org/wiki/Edsger_W._Dijkstra#1960s
+
+[Edsger Dijkstra][] was one of the most influential computer
+scientists. One of the many quotes from is about [testing][]:
+
+> Testing shows the presence, not the absence of bugs 
+
+(See page 16 of the linked PDF. Note that the context is formal
+correctness in software development.)
+
+This is used from time to time to claim testing is pointless. I object
+to that sentiment. Dijkstra's quip is funny, but it's only partly
+correct, for general software development, that testing can't show the
+absence of bugs. More importantly, testing is mean to show the absence
+of bugs.
+
+Testing is about showing what works.
+
+Consider the physical world, from the point of a phycisist. What
+happens if you drop an apple? It falls down. The physicist needs to
+answer the question: Does all fruit always fall down?
+
+To answer that, it's not enough to drop one apple one time. Do pears
+also fall down? Do all apples fall down? Every apple, every time? Does
+it happen on sea level? At the top of a mountain? When it rains? When
+there's a lot of people watching? When there's betting about what
+happens?
+
+To answer the question, the physicist needs to drop a very large
+number of diffrent fruit, a very large number of times, in all sorts
+of environment and contexts. And eventually, they form a falsiafiable
+hypothesis that yes, all fruit always fall down. After a long time,
+after many other phycisists have tried hard to prove the hypothesis
+wrong, the community of physicists accepts the hypothesis as true: all
+fruit always falls down when dropped.
+
+Until someone goes to outer space. And then no fruit falls. It just
+floats there looking smug.
+
+The point of testing software is not to do one test, once, and assume
+the code always works. The point is to consider all the cases in which
+to code under test needs to work, and try it in all those ways, and
+make sure it does what is expected of it.
+
+Tests don't tell you that code works in cases that aren't tested.
+Tests tell you code works in the cases that are tested. If you want it
+to work in some other case, you add a test, or expand an existing test
+to cover the case you're interested in.
+
+If the suite of tests misses a use case, and the code happens not to
+work in that particular case, that does not mean testing is useless,
+or that there's no point in even trying. If you don't have a test for
+dropping an orange in outer space, you don't know if organges fall in
+outer space. It doesn't mean physics is pointless. If you care about
+dropping fruit in outer space, you go to outer space and try it.

Change: publish
diff --git a/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn b/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
index d457f1f..a0550ba 100644
--- a/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
+++ b/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Two guys walk into a bar... to talk about debugging"]]
 [[!meta date="2019-06-23 11:14"]]
-[[!tag draft debugging]]
+[[!tag debugging]]
 
 
 Had a discussion recently with my friend Richard Braakman about

Fix: typos
diff --git a/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn b/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
index e6e0bfc..d457f1f 100644
--- a/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
+++ b/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
@@ -29,7 +29,7 @@ I do a talk on this some day.
 of massaging the starting conditions to make hypotheses, actually follow
 it step by step through what goes wrong. See what it's actually doing.
 This might mean using a debugger, or strace, or tcpdump, or adding logs,
-whatever it takes. (When doing so involves extra works it's often
+whatever it takes. (When doing so involves extra work it's often
 tempting to leave it as a last resort. I've found that it pays to resort
 to this early.)
 
@@ -51,7 +51,7 @@ code you're running."
 building a program that you may need to debug later, what would you
 like me to provide to help you debug?
 
-**R**: Heh. An easy way to get the debug logs. I often find that logging
+**R**: Heh. An easy way to get the debug log. I often find that logging
 has been turned off in multiple ways. I have to figure out how to
 compile it in, then how to turn it on, then how to make it go somewhere
 else than /dev/null.... and some programs have different debug logging
@@ -64,7 +64,7 @@ have to read the code or google for it.
 Sometimes the way to get logs keeps changing between versions. (Looking
 at Qt.)
 
-**L**: Haha. Q: would it be useful to have highly detailed debug logs
+**L**: Haha. Q: would it be useful to have highly detailed debug log
 for recent times but the rest reduced the level of detail for older stuff?
 Or would that just be complicated?
 
@@ -75,7 +75,7 @@ hour, but less for older logs.
 
 **R**: Hmm. I had one program where I logged debugs logs to a memory
 buffer... as soon as there was an error or warning log, it dumped the
-whole debug log too (and wrote debug logs directly for the rest of the
+whole debug log too (and wrote the debug log directly for the rest of the
 transaction). If the transaction was error free, the debug log buffer
 was discarded.
 

Add: the
diff --git a/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn b/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
index 926bdaf..e6e0bfc 100644
--- a/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
+++ b/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
@@ -65,7 +65,7 @@ Sometimes the way to get logs keeps changing between versions. (Looking
 at Qt.)
 
 **L**: Haha. Q: would it be useful to have highly detailed debug logs
-for recent times but rest reduced the level of detail for older stuff?
+for recent times but the rest reduced the level of detail for older stuff?
 Or would that just be complicated?
 
 **R**: Do you mean for recently written code?