Recent changes to this wiki:

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% — 2019-12-13
+* 11% — 19 December 2019
+* 9% — 13/12/2019
+* 0% — 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?

Fix: typo
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 233e085..926bdaf 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
@@ -58,7 +58,7 @@ else than /dev/null.... and some programs have different debug logging
 frameworks in different parts that have to be turned on in different
 ways. It's a pain.
 
-Sometimes there is actually a simple way bug it's not documented, and I
+Sometimes there is actually a simple way but it's not documented, and I
 have to read the code or google for it.
 
 Sometimes the way to get logs keeps changing between versions. (Looking

Fix: typo
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 68abc43..233e085 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
@@ -54,7 +54,7 @@ like me to provide to help you debug?
 **R**: Heh. An easy way to get the debug logs. 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 then /dev/null.... and some programs have different debug logging
+else than /dev/null.... and some programs have different debug logging
 frameworks in different parts that have to be turned on in different
 ways. It's a pain.
 

Drop: unnecessary explanation
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 06307fc..68abc43 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
@@ -17,8 +17,6 @@ a new system, named Ick, which will have a server component, and I
 want to make it easily debuggable. So of course I asked advice from
 the best debugger I know.
 
-(Below, L is me, R is my friend.)
-
 **L**: What would your top three hints be for someone who needs to learn
 to debug better?
 

Fix: typo
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 0d71342..06307fc 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
@@ -3,7 +3,7 @@
 [[!tag draft debugging]]
 
 
-Had a discussion recently with my friend Richard Braakmen about
+Had a discussion recently with my friend Richard Braakman about
 debugging. Here's a lightly edited version, in case it is of any use
 for others.
 

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 408b996..0d71342 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
@@ -7,8 +7,8 @@ Had a discussion recently with my friend Richard Braakmen about
 debugging. Here's a lightly edited version, in case it is of any use
 for others.
 
-R. is awesome at debugging, and I've often suggested he should employ
-himself as a consulting debugger, the say Sherlock Holmes was a
+Richard is awesome at debugging, and I've often suggested he should
+employ himself as a consulting debugger, the way Sherlock Holmes was a
 consulting detective: to be called in when the usual experts are
 stymied.
 

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

Publish log entry
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
new file mode 100644
index 0000000..408b996
--- /dev/null
+++ b/posts/2019/06/23/two_guys_walk_into_a_bar_to_talk_about_debugging.mdwn
@@ -0,0 +1,155 @@
+[[!meta title="Two guys walk into a bar... to talk about debugging"]]
+[[!meta date="2019-06-23 11:14"]]
+[[!tag draft debugging]]
+
+
+Had a discussion recently with my friend Richard Braakmen about
+debugging. Here's a lightly edited version, in case it is of any use
+for others.
+
+R. is awesome at debugging, and I've often suggested he should employ
+himself as a consulting debugger, the say Sherlock Holmes was a
+consulting detective: to be called in when the usual experts are
+stymied.
+
+The context of this discussion is that I'm working in my free time on
+a new system, named Ick, which will have a server component, and I
+want to make it easily debuggable. So of course I asked advice from
+the best debugger I know.
+
+(Below, L is me, R is my friend.)
+
+**L**: What would your top three hints be for someone who needs to learn
+to debug better?
+
+**R**: Hmmm... obviously it depends on where they are now :)
+
+**L**: I'm asking for myself primarily but also collection ideas in case
+I do a talk on this some day.
+
+**R**: One. Find a way to observe the problems. By which I mean, instead
+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
+tempting to leave it as a last resort. I've found that it pays to resort
+to this early.)
+
+Two. When you conclude that the behaviour you're seeing is completely
+impossible, don't give up. You're actually getting close. One of your
+assumptions is wrong. When you find which one, you'll have the bug.
+
+Three. Try to duplicate the buggy behaviour on another system. (This is
+easiest if you already have one - the "it works for me" case). Then
+systematically remove the differences between the working and
+non-working systems.
+
+If you ask on another day you might get a different top 3. :)
+
+Something I often say is "make sure the code you're reading is the same
+code you're running."
+
+**L**: Interesting. Thank you. This helps me. New question: if I were
+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
+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 then /dev/null.... and some programs have different debug logging
+frameworks in different parts that have to be turned on in different
+ways. It's a pain.
+
+Sometimes there is actually a simple way bug it's not documented, and I
+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
+for recent times but rest reduced the level of detail for older stuff?
+Or would that just be complicated?
+
+**R**: Do you mean for recently written code?
+
+**L**: Recent in terms of of execution, so much detail for the latest
+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
+transaction). If the transaction was error free, the debug log buffer
+was discarded.
+
+It works for server-like programs.
+
+I think time based log purging wouldn't be good in my current type of
+jobs, where I often see problems only the next day etc.
+
+**L**: Was that useful? Should I consider that for Ick?
+
+**R**: Yeah it was useful :) It meant we got detailed logs of problem
+cases, without overflowing the log files. We had a high transaction rate
+and the logs were several GB a day.
+
+**L**: I shall keep it in mind then :)
+
+**R**: I guess it's less useful if you have no capacity problem :)
+
+**L**: Speaking of logs, what's a good log like?
+
+**R**: One thing is, it helps if the log text is unique in the code.
+That way I know for sure which bit of code generated the log.
+
+Hmm, when I modify the logging, it's often to add the actual values the
+code is having problems with. Like instead of "too many entries", log
+how many there were and what the limit was.
+
+Same with stuff like "unknown command code".
+
+Including those values is often extra work and I don't actually know if
+it pays to do it in advance :) I just know it's the change I most
+commonly make.
+
+**L**: Would you say log message should make sense without having the
+code in front of you?
+
+**R**: I think that's a "sometimes".
+
+Like... if the log message is like trace logging, for example if it's
+logging the disposition of a packet, then the trace should be
+understandable without looking at the code. But if it's logging something
+internal, like the workings of an algorithm, then I'm probably looking at
+that code already.
+
+**L**: Nod, good point.
+
+What's a good way to control logging? As in where it goes and how
+detailed it is.
+
+**R**: That I don't know :) All the ways I've seen annoy me.
+
+I think my favourite is to generate a separate debug.log file next to
+the normal logs.
+
+It all depends on whether capacity is a problem.
+
+Hmm a separate point is about consistency in logging. Like, if there are
+five reasons to reject an input and only four of them have logs, then
+I'm likely to miss that fifth one and assume "no log means input was
+accepted".
+
+**L**: Nod.
+
+What's your preferred format for logs?
+
+**R**: I don't think I have a preference :)
+
+**L**: Do you like logs that are easily processed by programs?
+
+**R**: Nah, at most I use grep. But the people who make intrusion
+detection systems prefer that :)
+
+Same for system monitoring I guess.
+
+**L**: Check

Change: publish post on rust and go
diff --git a/posts/2019/03/24/on_learning_rust_and_go_migrating_away_from_python.mdwn b/posts/2019/03/24/on_learning_rust_and_go_migrating_away_from_python.mdwn
index 355c1c7..7fbcfbf 100644
--- a/posts/2019/03/24/on_learning_rust_and_go_migrating_away_from_python.mdwn
+++ b/posts/2019/03/24/on_learning_rust_and_go_migrating_away_from_python.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="On learning Rust and Go: migrating away from Python"]]
 [[!meta date="2019-03-24 10:15"]]
-[[!tag rust go python draft]]
+[[!tag rust go python]]
 
 I first started using Python in 1993. It's been my main programming
 language since about 2000. I've written a ton of code in Python, both

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

Publish log entry
diff --git a/posts/2019/03/24/on_learning_rust_and_go_migrating_away_from_python.mdwn b/posts/2019/03/24/on_learning_rust_and_go_migrating_away_from_python.mdwn
new file mode 100644
index 0000000..355c1c7
--- /dev/null
+++ b/posts/2019/03/24/on_learning_rust_and_go_migrating_away_from_python.mdwn
@@ -0,0 +1,65 @@
+[[!meta title="On learning Rust and Go: migrating away from Python"]]
+[[!meta date="2019-03-24 10:15"]]
+[[!tag rust go python draft]]
+
+I first started using Python in 1993. It's been my main programming
+language since about 2000. I've written a ton of code in Python, both
+for work and in my free time. For several years now, I've been growing
+dissatisfied with it. Partly it's because I'd like more help from my
+programming tools, such as static type checking, better handling of
+abstractions and code modules, and in general aiding me in writing
+larger, more complex software. Partly it's because I'm writing more
+challenging software, and trying to get more out of the hardware I
+have available. Partly it's because I'm not getting the feeling that
+the Python community is going in a direction I want to follow. Instead
+I get the feeling that the Python community is happy to cut corners
+and compromise on things that I'm not willing to. Which is fine, if it
+makes their lives better, but leaves me wanting something else.
+
+I wrote Obnam, my backup application, in Python, over a period of
+about fourteen years, until I retired it a year ago. During Obnam's
+life, Python 3 happened. Python 3 is actually a good thing, I think,
+but the transition was painful, and Obnam never made it. Obnam had
+other issues, which made it less fun to work on; Python 3 wasn't what
+killed it.
+
+Obnam and other large programs I've written in Python gave me the
+strong feeling that it's a nice language up to a certain size and
+complexity of program. Obnam is about 15000 lines of Python code. That
+turned out to be too much for me in Python: too often there were bugs
+that a static, strong type system would have caught. I could perhaps
+have been more diligent in how I used Python, and more careful in how
+I structured my code, but that's my point: a language like Python
+requires so much self-discipline that at some point it gets too much.
+
+So over the last few months I've been learning Rust and Go, on and
+off, in short gaps of free time between other duties. Both have static
+type systems that can be argued to be strong. Both seem to have decent
+module systems. Both seem to support concurrency well. Either should
+be a good replacement for Python for non-small software I write. But I
+expect to be using Rust for any non-work programming and Go only when
+work needs me to.
+
+Rust is developed by a community, and was started by Mozilla. Go
+development seems to be de facto controlled by Google, who originated
+the language. I'd rather bet my non-work future on a language that
+isn't controlled by a huge corporation, especially one of the main
+players in today's surveillance economy. I write code in my free time
+because it's fun, and I release it as free software because that's the
+ethical thing to do. I feel quite strongly that software freedom is
+one of the corner stones for the long-term happiness for humanity.
+
+Anyway.
+
+Ignoring ethical concerns, Rust seems like the better language of the
+two, so far. It has the better type system, the better compiler, the
+better tooling in general, and seems to me to have learnt better the
+lessons of programming languages and tools of the past third of a
+century. Rust exhibits better taste: things are designed the way they
+are for good reasons. It's not always as convenient or familiar as Go,
+but it doesn't seem to make compromises for short-term convenience the
+way Go does.
+
+Note that I've not written any significant code in either language, so
+I'm just writing based on what I've learnt by reading. My opinions may
+change in the future, as I get more into both languages.

Change: publish blog post
diff --git a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
index 58dc1af..db1b9f0 100644
--- a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
+++ b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="On deep, constructive online discussions about technical topics"]]
 [[!meta date="2019-03-17 10:41"]]
-[[!tag draft discussions]]
+[[!tag discussions]]
 
 [lamented on Mastodon]: https://social.nasqueron.org/@liw/101663177079133772
 
@@ -35,9 +35,9 @@ thoughts are:
   and won't be satisfied with the same solutions. That's OK. Let's see
   what we can do together.
 
-* Dr. Edward Morbius has many good points about online discussions.
-  The most fundamental point is to start producing the kind of content
-  one wants more of.
+* Dr. Edward Morbius (a pseudonym) has many good points about online
+  discussions. The most fundamental point is to start producing the
+  kind of content one wants more of.
 
 * Any discussion medium is going to require some shared values among
   its participants, and these will need to be enforced in some manner.

Fix: spelling
diff --git a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
index 1c1fb80..58dc1af 100644
--- a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
+++ b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
@@ -42,7 +42,7 @@ thoughts are:
 * Any discussion medium is going to require some shared values among
   its participants, and these will need to be enforced in some manner.
   When it's two friends chatting privately, this is not problematic.
-  When it's a whole bunch of random strangers, this gets tricker.
+  When it's a whole bunch of random strangers, this gets trickier.
 
 * An interesting point is whether discussions should be public, and
   open for anyone to participate. A public/open discussion forum that
@@ -81,7 +81,7 @@ For more concreteness, example of what I'd like to have:
   every discussion on any topic
 
 As far as technical solutions go, there are lots of existing options:
-IRC, Matrix, private email, mailing lists, Usenet/NNT%P, blogs, web
+IRC, Matrix, private email, mailing lists, Usenet/NNTP, blogs, web
 forums, the lobste.rs code base, the fediverse, secure scuttlebutt,
 etc. On the whole, I don't care about the solution, except I'd like it
 to not require real-time participation, and support an "inbox" style

Fix: spelling
diff --git a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
index 3424c83..1c1fb80 100644
--- a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
+++ b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
@@ -59,7 +59,7 @@ thoughts are:
 
 * It's entirely possible that what I want isn't realistic.
 
-For more concretness, example of what I'd like to have:
+For more concreteness, example of what I'd like to have:
 
 * practical and theoretical software architecture and implementation
   topics in general

Fix: wording
diff --git a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
index c241c2a..3424c83 100644
--- a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
+++ b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
@@ -42,7 +42,7 @@ thoughts are:
 * Any discussion medium is going to require some shared values among
   its participants, and these will need to be enforced in some manner.
   When it's two friends chatting privately, this is not problematic.
-  When it's a whole bunch of random strangers, this get tricker.
+  When it's a whole bunch of random strangers, this gets tricker.
 
 * An interesting point is whether discussions should be public, and
   open for anyone to participate. A public/open discussion forum that

Change: how I reference Dr Edward Morbius
diff --git a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
index e7d3449..c241c2a 100644
--- a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
+++ b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
@@ -35,9 +35,9 @@ thoughts are:
   and won't be satisfied with the same solutions. That's OK. Let's see
   what we can do together.
 
-* <@dredmorbius@mastodon.cloud> has many good points about online
-  discussions. The most fundamental point is to start producing the
-  kind of content one wants more of.
+* Dr. Edward Morbius has many good points about online discussions.
+  The most fundamental point is to start producing the kind of content
+  one wants more of.
 
 * Any discussion medium is going to require some shared values among
   its participants, and these will need to be enforced in some manner.

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

Publish log entry
diff --git a/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
new file mode 100644
index 0000000..e7d3449
--- /dev/null
+++ b/posts/2019/03/17/on_deep_constructive_online_discussions_about_technical_topics.mdwn
@@ -0,0 +1,88 @@
+[[!meta title="On deep, constructive online discussions about technical topics"]]
+[[!meta date="2019-03-17 10:41"]]
+[[!tag draft discussions]]
+
+[lamented on Mastodon]: https://social.nasqueron.org/@liw/101663177079133772
+
+A while I ago I [lamented on Mastodon][] about wanting a place to
+discuss technical topics online.
+
+> I'm missing an online place to have deep, constructive discussions
+> about technical topics. Parts of Usenet and parts of Debian used to
+> have that for me in the 1990s, and some blogs in the early 2000s,
+> but now everywhere seems to become filled with trolls or people who
+> seem to enjoy shooting down every new idea.
+
+It's possible that my recollections of online discussions from those
+times are coloured by time, and that they were never really as good as
+I now think they were. It's possible that if I stepped into my time
+machine and went back to, say, 1995, and participated in Debian
+development discussions, I'd be horrified at how bad they were.
+
+That doesn't matter. I still want to have interesting discussions now.
+Preferably with a sufficiently diverse set of people. I have some of
+that, with a few close friends, but I'm hoping to widen the experience
+to more participants. A more diverse pool of opinions and experience
+would teach me more.
+
+There were many responses to my toot. You can read most them in detail
+via the link above, although some were private, and if you can read
+those, I'm going to have to have a look at my laptop's security. My
+thoughts are:
+
+* I'm not alone in wanting this. This is not a surprise. It's likely
+  that everyone who wants this isn't interested in the same topics,
+  and won't be satisfied with the same solutions. That's OK. Let's see
+  what we can do together.
+
+* <@dredmorbius@mastodon.cloud> has many good points about online
+  discussions. The most fundamental point is to start producing the
+  kind of content one wants more of.
+
+* Any discussion medium is going to require some shared values among
+  its participants, and these will need to be enforced in some manner.
+  When it's two friends chatting privately, this is not problematic.
+  When it's a whole bunch of random strangers, this get tricker.
+
+* An interesting point is whether discussions should be public, and
+  open for anyone to participate. A public/open discussion forum that
+  is successful is likely to grow too big to be manageable and will
+  require much effort to moderate. A private/closed forum is easier,
+  but less likely to gather a diverse group of participants, and thus
+  can thus suffer from a lack new thoughts and ideas. Possibly some
+  other mix than those two is better? I don't know.
+
+* It seems clear to me that relying on advertising-supported platforms
+  to host discussions is unlikely to be a good long-term strategy. At
+  the same time, anything that requires significant financial or time
+  investment to host is unlikely to survive long-term.
+
+* It's entirely possible that what I want isn't realistic.
+
+For more concretness, example of what I'd like to have:
+
+* practical and theoretical software architecture and implementation
+  topics in general
+
+* design, architecture, and implementation of specific software
+  solutions to problems I'm interested in, currently CI/CD,
+  authentication, storage of large binary files, and small structured
+  data; obviously, others are likely to be interested in other
+  specific topics, and that's OK
+
+* a culture of moving the discussion forward, and being constructive,
+  rather than "winning" on points; confrontational and combative
+  attitudes tend to ruin things for me, although they do work for some
+
+* not having to re-debate things that are fundamental for me, such as
+  software freedom, human rights, and specific technical solutions; I
+  don't mind disagreements, but I don't want to have the same
+  discussion all over again every week or have it be inserted into
+  every discussion on any topic
+
+As far as technical solutions go, there are lots of existing options:
+IRC, Matrix, private email, mailing lists, Usenet/NNT%P, blogs, web
+forums, the lobste.rs code base, the fediverse, secure scuttlebutt,
+etc. On the whole, I don't care about the solution, except I'd like it
+to not require real-time participation, and support an "inbox" style
+instead of an infinite stream of messages. But that's me.

Fix: link markup
diff --git a/posts/2019/01/12/starting_new_project_yuck_an_identity_provider.mdwn b/posts/2019/01/12/starting_new_project_yuck_an_identity_provider.mdwn
index d17d6e3..71c4651 100644
--- a/posts/2019/01/12/starting_new_project_yuck_an_identity_provider.mdwn
+++ b/posts/2019/01/12/starting_new_project_yuck_an_identity_provider.mdwn
@@ -12,4 +12,4 @@ allow storing and managing data about end users, applications, and
 other entities related to authentication.
 
 A preliminary architecture document is at
-https://files.liw.fi/yuck-arch/ and feedback is welcome.
+<https://files.liw.fi/yuck-arch/> and feedback is welcome.

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

Publish log entry
diff --git a/posts/2019/01/12/starting_new_project_yuck_an_identity_provider.mdwn b/posts/2019/01/12/starting_new_project_yuck_an_identity_provider.mdwn
new file mode 100644
index 0000000..d17d6e3
--- /dev/null
+++ b/posts/2019/01/12/starting_new_project_yuck_an_identity_provider.mdwn
@@ -0,0 +1,15 @@
+[[!meta title="Starting new project: Yuck (an identity provider)"]]
+[[!meta date="2019-01-12 13:43"]]
+[[!tag yuck]]
+
+I'm starting a new side project: Yuck.
+
+Yuck is an identity provider that allows end users to securely
+authenticate themselves to web sites and applications. Yuck also
+allows users to authorize applications to act on their behalf. Yuck
+supports the OAuth2 and OpenID Connect protocols, and has an API to
+allow storing and managing data about end users, applications, and
+other entities related to authentication.
+
+A preliminary architecture document is at
+https://files.liw.fi/yuck-arch/ and feedback is welcome.

Amend 2015 blog post to update Sage Sharp's name to be current
diff --git a/posts/preining.mdwn b/posts/preining.mdwn
index 7df32ff..b420c1c 100644
--- a/posts/preining.mdwn
+++ b/posts/preining.mdwn
@@ -28,6 +28,6 @@ Planet Debian, where both Preining's and my blogs are published, that
 his opinions are not mainstream in the Debian project, and that
 despite what he says, Debian development continues to be fun.
 
-Amended in 2019 to not use Sharp's old name. They changed it in 2017.
+_Amended in 2019 to not use Sharp's old name. They changed it in 2017.
 Justification: if people refer to this blog post now, it'd be nice if
-the post didn't lead people to using the old name.
+the post didn't lead people to using the old name._

Amend 2015 blog post to update Sage Sharp's name to be current
diff --git a/posts/preining.mdwn b/posts/preining.mdwn
index 3b89411..7df32ff 100644
--- a/posts/preining.mdwn
+++ b/posts/preining.mdwn
@@ -1,14 +1,15 @@
-[[!meta title="On Norbert Preining, Sarah Sharp, and Debian"]]
+[[!meta title="On Norbert Preining, Sage Sharp, and Debian"]]
+[[!meta date="Thu Oct 8 19:58:27 2015 +0300"]]
 [[!tag debian rant]]
 
 I disagree with pretty much everything Norbert Preining says in his
-[blog post about Sarah Sharp][] in response to Sharp's blog post
+[blog post about Sage Sharp][] in response to Sharp's blog post
 [Closing a door][] about leaving Linux kernel development. I think
 Preining mis-characterises what happens on the Linux kernel mailing
 list, and in Debian, in free software development in general, and what
-Sarah Sharp has said and done.
+Sage Sharp has said and done.
 
-[blog post about Sarah Sharp]: http://www.preining.info/blog/2015/10/looking-at-the-facts-sarah-sharps-crusade/
+[blog post about Sage Sharp]: http://www.preining.info/blog/2015/10/looking-at-the-facts-sarah-sharps-crusade/
 [Closing a door]: http://sarah.thesharps.us/2015/10/05/closing-a-door/
 
 I do not wish to participate in yet another discussion on the
@@ -26,3 +27,7 @@ I do feel it is important to make it clear to the people reading
 Planet Debian, where both Preining's and my blogs are published, that
 his opinions are not mainstream in the Debian project, and that
 despite what he says, Debian development continues to be fun.
+
+Amended in 2019 to not use Sharp's old name. They changed it in 2017.
+Justification: if people refer to this blog post now, it'd be nice if
+the post didn't lead people to using the old name.

Add: link to toot for comments
diff --git a/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn b/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
index 806be85..5586ac4 100644
--- a/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
+++ b/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
@@ -36,3 +36,11 @@ A strongly, statically typed language with a good compiler, like Rust,
 or even C, gets much of the same benefit from the type system and the
 compiler, so there's much less need to aim for high unit test coverage
 to become confident about the code.
+
+(If you with to comment on this blog post, please do so on 
+[Mastodon][] as a response to my [toot][]. You can [join][] an
+instance to do so.)
+
+[Mastodon]: https://en.wikipedia.org/wiki/Mastodon_(software)
+[toot]: https://social.nasqueron.org/@liw/101340849291489052
+[join]: https://joinmastodon.org/

Change: publish blog post
diff --git a/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn b/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
index 6b983cf..806be85 100644
--- a/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
+++ b/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Unit test coverage and confidence"]]
 [[!meta date="2019-01-01 12:18"]]
-[[!tag python unit-testing coverage rust draft]]
+[[!tag python unit-testing coverage rust]]
 
 It seems Python is now deprecating the `imp` standard library module,
 in favour of `importlib`. Eventually `imp` will go away. My Python

Change: clearer wording
diff --git a/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn b/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
index 45bb927..6b983cf 100644
--- a/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
+++ b/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
@@ -4,13 +4,14 @@
 
 It seems Python is now deprecating the `imp` standard library module,
 in favour of `importlib`. Eventually `imp` will go away. My Python
-unit test runner uses `imp`, so I will have to change it. All my
-Python projects use my unit test runner. I suspect I won't be able to
-drop all my old Python projects in time (in favour of replacing them
-with other project, possibly written in Rust) to not have to convert
-things to `importlib`. Bummer. I dislike the extra work, but at least
-Python tends to do standard library transitions like this slowly, with
-clear deprecation warnings, and rarely, so I won't complain too much.
+unit test runner uses `imp`, so I will have to update it to use
+`importlib`. All my Python projects use my unit test runner. I suspect
+I won't be able to drop all my old Python projects in time (in favour
+of replacing them with other project, possibly written in Rust) to not
+have to convert things to `importlib`. Bummer. I dislike the extra
+work, but at least Python tends to do standard library transitions
+like this slowly, with clear deprecation warnings, and rarely, so I
+won't complain too much.
 
 [CoverageTestRunner]: https://liw.fi/coverage-test-runner/
 

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

Publish log entry
diff --git a/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn b/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
new file mode 100644
index 0000000..45bb927
--- /dev/null
+++ b/posts/2019/01/01/unit_test_coverage_and_confidence.mdwn
@@ -0,0 +1,37 @@
+[[!meta title="Unit test coverage and confidence"]]
+[[!meta date="2019-01-01 12:18"]]
+[[!tag python unit-testing coverage rust draft]]
+
+It seems Python is now deprecating the `imp` standard library module,
+in favour of `importlib`. Eventually `imp` will go away. My Python
+unit test runner uses `imp`, so I will have to change it. All my
+Python projects use my unit test runner. I suspect I won't be able to
+drop all my old Python projects in time (in favour of replacing them
+with other project, possibly written in Rust) to not have to convert
+things to `importlib`. Bummer. I dislike the extra work, but at least
+Python tends to do standard library transitions like this slowly, with
+clear deprecation warnings, and rarely, so I won't complain too much.
+
+[CoverageTestRunner]: https://liw.fi/coverage-test-runner/
+
+[CoverageTestRunner][] runs Python unittest test suites under
+`coverage.py`, and measures test coverage for a module while running
+that module's unit tests, but ignoring accidental and incidental
+coverage from that unit getting called from other units. It fails the
+suite unless all statements are covered by unit tests, or the
+statements are explicitly marked as being excluded from coverage. I
+wrote it and use it because it's an easy way to get my projects into a
+state where I have high confidence that the code will work if it
+passes unit tests.
+
+I don't really care about reaching "100% test coverage", but I do like
+being confident, and this approach means I don't accidentally leave
+something untested. Python's dynamic typing and general "scriptiness"
+mean that the rigour imposed by `CoverageTestRunner` has made me much
+more confident about changing my own code, and has saved me from
+numerous bugs.
+
+A strongly, statically typed language with a good compiler, like Rust,
+or even C, gets much of the same benefit from the type system and the
+compiler, so there's much less need to aim for high unit test coverage
+to become confident about the code.

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

Publish log entry
diff --git a/posts/2018/12/16/thanking_authors_of_the_free_software_you_use.mdwn b/posts/2018/12/16/thanking_authors_of_the_free_software_you_use.mdwn
new file mode 100644
index 0000000..8783e3c
--- /dev/null
+++ b/posts/2018/12/16/thanking_authors_of_the_free_software_you_use.mdwn
@@ -0,0 +1,24 @@
+[[!meta title="Thanking authors of the free software you use"]]
+[[!meta date="2018-12-16 15:04"]]
+[[!tag thanking]]
+
+For the holidays, you could say thank you to some of the people who
+write free software you use, especially software that isn't hugely
+popular.
+
+Those of us who write little-known software may go for months without
+hearing from a user, and it can be a little de-motivating.
+
+Hearing from someone who actually uses one's software gives an
+energising jolt that can carry one through several weeks of darkness
+and cold and wet.
+
+On Debian-based systems, you can check the
+/usr/share/doc/foo/copyright file for copyright information for
+package foo. This roughly corresponds with authorship, especially for
+smaller projects. The file also usually has a link to the home page of
+the project or person who produced the software, with contact
+information.
+
+(See also the [this same message on
+Mastodon](https://social.nasqueron.org/@liw/101246301729760284).)