Recent changes to this wiki. Not to be confused with my history.

Complete source to the wiki is available on gitweb or by cloning this site.

mention microled
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index c32cf248..f23cadfc 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -63,6 +63,13 @@ See also this discussion:
 
 See the selector: https://www.tftcentral.co.uk/selector.htm
 
+Update, 2021-10-18: One thing to keep in mind while reviewing this is
+that the technology is changing rapidly in this space. The new MacBook
+M1 Pro ships with [MiniLED](https://en.wikipedia.org/wiki/MicroLED) which is like OLED (so real blacks,
+faster refresh rate, HDR, low energy consumption) but no burn-in,
+which is really amazing. Not yet available for real monitors, but
+might be waiting for.
+
 Full gamut
 ----------
 

update status
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 98899819..6192fd1e 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -7,10 +7,10 @@ to upgrade slightly before or during the freeze. This time I feel
 almost late because it seems we'll be releasing in almost a month now
 (May 2021, it's April 2021 now).
 
-Update: and that procedure was done only on one workstation
+Update: this procedure was tested first on my workstation
 ([[hardware/curie]]). I have done another (the laptop,
 [[hardware/angela]]) in July 2021, and the server
-([[hardware/server/marcos]]) is still pending.
+([[hardware/server/marcos]]) in October 2021.
 
 This document contains my upgrade procedure, notable changes in the
 new version, issues I have stumbled upon (and possibly fixed), and

marcos upgraded, rainloop missing
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index b50d0098..98899819 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -269,6 +269,8 @@ list.
    testing, seems like it is in bad shape
  * [qalculate-gtk](https://tracker.debian.org/pkg/qalculate-gtk), my dearest calculator, was dropped from testing
    too! a team picked up the package, but too late it seems :/
+ * [rainloop](https://tracker.debian.org/pkg/rainloop), my webmail, [was removed](https://bugs.debian.org/972570) because of a dependency
+   problem, likely to get fixed in backports
  * usbguard-applet-qt - [removed 0.7.5](https://tracker.debian.org/news/1069337/accepted-usbguard-075ds-1-source-into-unstable/) from [usbguard](https://tracker.debian.org/pkg/usbguard),
    workaround: find the device ID in `lsbusb` and run `usbguard
    allow-device id $ID`

ikiwiki upgrade
diff --git a/services/wiki.mdwn b/services/wiki.mdwn
index 087211e2..9266fa38 100644
--- a/services/wiki.mdwn
+++ b/services/wiki.mdwn
@@ -131,7 +131,6 @@ On any given upgrade, the following patches need to be applied:
 
 I still carry those patches on top of ikiwiki:
 
- * [todo/git-annex_support](https://ikiwiki.info/todo/git-annex_support)
  * [todo/allow_toc_to_skip_entries](https://ikiwiki.info/todo/allow_toc_to_skip_entries)
  * [todo/include_page_variable_in_base_templates](https://ikiwiki.info/todo/include_page_variable_in_base_templates)
  * [bugs/javascript_resources_placed_after_html_tag](https://ikiwiki.info/bugs/javascript_resources_placed_after_html_tag/)
@@ -151,32 +150,29 @@ to follow the `$release` tag those patches are based on, to facilitate
 web-based reviews there.</div>
 
     cd src/ikiwiki &&
-    release=debian/3.20190228-1 &&
-    git rebase $release dev/git-annex-support &&
-    git diff $release..dev/git-annex-support | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
-    git diff $release..dev/git-annex-support | ( cd /usr/share/perl5 ;    sudo patch -p1 ) &&
-    git rebase $release toc-skip &&
+    release=3.20200202.3 &&
+    git rebase --onto $release anarcat/master toc-skip &&
     git diff $release..toc-skip | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
     git diff $release..toc-skip | ( cd /usr/share/perl5 ;    sudo patch -p1 ) &&
-    git rebase $release page-template-variable &&
+    git rebase --onto $release anarcat/master $release page-template-variable &&
     git diff $release..page-template-variable | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
     git diff $release..page-template-variable | ( cd /usr/share/perl5 ;    sudo patch -p1 ) &&
-    git rebase $release js-newline &&
+    git rebase --onto $release anarcat/master $release js-newline &&
     git diff $release..js-newline | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
     git diff $release..js-newline | ( cd /usr/share/perl5 ;    sudo patch -p1 ) &&
-    git rebase $release i18n-headinganchors &&
+    git rebase --onto $release anarcat/master $release i18n-headinganchors &&
     mv /usr/share/perl5/IkiWiki/Plugin/i18nheadinganchors.pm{,.orig} &&
     git diff $release..i18n-headinganchors | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
     git diff $release..i18n-headinganchors | ( cd /usr/share/perl5 ; sudo patch -p1  ) &&
     diff -u /usr/share/perl5/IkiWiki/Plugin/i18nheadinganchors.pm{,.orig} &&
     rm /usr/share/perl5/IkiWiki/Plugin/i18nheadinganchors.pm.orig &&
+    git rebase --onto $release anarcat/master $release bootstrap-plugin &&
     mv /usr/share/perl5/IkiWiki/Plugin/bootstrap.pm{,.orig} &&
-    git rebase $release bootstrap-plugin &&
-    git diff $release..bootstrap-plugin | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run )
-    git diff $release..bootstrap-plugin | ( cd /usr/share/perl5 ; sudo patch -p1  )
+    git diff $release..bootstrap-plugin | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
+    git diff $release..bootstrap-plugin | ( cd /usr/share/perl5 ; sudo patch -p1  ) &&
     diff -u /usr/share/perl5/IkiWiki/Plugin/bootstrap.pm{,.orig} &&
     rm /usr/share/perl5/IkiWiki/Plugin/bootstrap.pm.orig &&
-    git rebase $release admonitions &&
+    git rebase --onto $release anarcat/master $release admonitions &&
     mv /usr/share/perl5/IkiWiki/Plugin/admonition.pm{,.orig} &&
     git diff $release..admonitions IkiWiki/Plugin/admonition.pm | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
     git diff $release..admonitions IkiWiki/Plugin/admonition.pm | ( cd /usr/share/perl5 ; sudo patch -p1 ) &&
@@ -185,6 +181,26 @@ web-based reviews there.</div>
     git diff $release..admonitions doc/style.css | ( cd /usr/share/ikiwiki/basewiki ; sudo patch -p2 --dry-run ) &&
     git diff $release..admonitions doc/style.css | ( cd /usr/share/ikiwiki/basewiki ; sudo patch -p2 )
 
+Then rebase and push all the branches:
+
+    for b in toc-skip page-template-variable'js-newline i18n-headinganchors bootstrap-plugin; do git co  $b && git reset --hard marcos/$b &&  git push --force-with-lease anarcat $b; done
+    git co deploy
+    git reset --hard $release
+    git merge toc-skip page-template-variable js-newline i18n-headinganchors bootstrap-plugin
+    git push --force-with-lease
+    git co master
+    git reset --hard $release
+    git push --force-with-lease anarcat
+
+## 2021-10-05: major upgrade (to bullseye)
+
+Upgraded the entire server to bullseye.
+
+The following patches were dropped:
+
+ * [todo/git-annex_support](https://ikiwiki.info/todo/git-annex_support)
+   (was not really working anyways)
+
 ## 2019-10-02: major upgrade
 
 Upgraded the entire server to buster. The following patches were

document the change required in unattended-upgrades
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index b5793e07..b50d0098 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -304,6 +304,10 @@ Also note that the *codename* of the security changed, this time, from
 APT configuration which involves pinning the `APT::Default-Release`
 manually.
 
+At least that's what the release notes say. In reality, in my case, I
+had the codename set in the unattended-upgrades configuration file,
+which required a change ([in Puppet](https://gitlab.com/anarcat/puppet/-/commit/f6bb076bab43e045b84e5c43a0a315025c8c21ee)).
+
 I can't find any other recent changes in my notes, but I could have
 sworn it's not the first time a change like this happens. If someone
 remember what it was *before* that, I would be grateful if I could

more info about printers
diff --git a/hardware/printer.md b/hardware/printer.md
index 445a7150..114bc381 100644
--- a/hardware/printer.md
+++ b/hardware/printer.md
@@ -16,3 +16,36 @@
 ## Must not have
 
  * ink-jet printing
+
+# Advice received
+
+ * avoid HP (twice), although one concern was with their "printing as
+   a service" approach with inkjet printer, which may not apply to me
+ * good words about Canon, which I have a personal chip on the
+   shoulder with
+ * don't expect scanning to work from Linux, instead scan to a SMB
+   share from the device (so look from SMB support)
+
+# Options
+
+Picking some common ratings websites (rtings.com and Wirecutters), I
+come to the following conclusion:
+
+ * HP has a more expensive model, but long-term per page cost is lower
+ * according to rtings.com, it's the opposite, the "Canon imageCLASS
+   MF743Cdw" has a better per-page cost
+ * according to rtings.com, it prints B&W faster, has a better
+   scanner, but worse photo printer, again than the MF743Cdw
+ * that said, the "Canon imageCLASS MF743Cdw" is not available at Best
+   Buy or Staples, the closest alternative at Staples is the MF741Cdw,
+   which doesn't have duplex scanning, but is cheaper (see [bh
+   comparison](https://www.bhphotovideo.com/c/compare/Canon_MF743Cdw_vs_Canon_MF644Cdw_vs_Canon_MF741Cdw/BHitems/1489652-REG_1489654-REG_1489653-REG)). it's out of stock at Staples and Bestbuy as well
+
+## HP Color LaserJet Pro MFP M479FDW
+
+<https://www.hp.com/us-en/shop/pdp/hp-color-laserjet-pro-mfp-m479fdw>
+
+recommended by Wirecutters and rtings.com
+
+ * [Staples](https://www.staples.ca/products/2946505-en-hp-color-laserjet-pro-mfp-m479dw-printer-w1a77abgj): CAD$699.99, [replacement B&W](https://www.staples.ca/products/24398984-en-hp-414a-w2020a-black-original-laserjet-toner-cartridge): 110$, 0.046$/page
+

start looking into printers
diff --git a/hardware/printer.md b/hardware/printer.md
new file mode 100644
index 00000000..445a7150
--- /dev/null
+++ b/hardware/printer.md
@@ -0,0 +1,18 @@
+# Requirements
+
+## Must have
+
+ * network port
+ * "driverless printing"
+ * laser
+ * stellar Linux support
+
+## Nice to have
+
+ * colors
+ * scanner/photocopier
+ * double-sided printing, AKA "[duplex printing](https://en.wikipedia.org/wiki/Duplex_printing)"
+
+## Must not have
+
+ * ink-jet printing

another good mbsync ref
diff --git a/blog/2021-06-29-another-mail-crash.md b/blog/2021-06-29-another-mail-crash.md
index 7a7edac6..1bb1b5a9 100644
--- a/blog/2021-06-29-another-mail-crash.md
+++ b/blog/2021-06-29-another-mail-crash.md
@@ -169,7 +169,7 @@ are other programs that sync mail. I'm looking at:
    switching from offlineimap to this, has support for TLS client
    certs, running over SSH (e.g. [presumably](https://www.angio.net/misc/mail.html) with `Tunnel "ssh -C
    -q imap.example.com /usr/lib/dovecot/imap"`), and generally has
-   good words from multiple Debian and notmuch people
+   good words from multiple Debian and notmuch people ([Arch tutorial](https://wiki.archlinux.org/title/Isync))
  * [getmail](http://pyropus.ca/software/getmail/): just downloads email, might not be enough
  * [nncp](http://www.nncpgo.org/): treat the local spool as another mail server, might not
    be compatible with my "multiple clients" setup

more evaluations of smd alternatives
diff --git a/blog/2021-06-29-another-mail-crash.md b/blog/2021-06-29-another-mail-crash.md
index b029895c..7a7edac6 100644
--- a/blog/2021-06-29-another-mail-crash.md
+++ b/blog/2021-06-29-another-mail-crash.md
@@ -167,8 +167,9 @@ are other programs that sync mail. I'm looking at:
    over SSH, see comment below
  * [isync/mbsync](http://isync.sf.net/): might be faster, I remember having trouble
    switching from offlineimap to this, has support for TLS client
-   certs, running over SSH, and generally has good words from multiple
-   Debian and notmuch people
+   certs, running over SSH (e.g. [presumably](https://www.angio.net/misc/mail.html) with `Tunnel "ssh -C
+   -q imap.example.com /usr/lib/dovecot/imap"`), and generally has
+   good words from multiple Debian and notmuch people
  * [getmail](http://pyropus.ca/software/getmail/): just downloads email, might not be enough
  * [nncp](http://www.nncpgo.org/): treat the local spool as another mail server, might not
    be compatible with my "multiple clients" setup
@@ -176,7 +177,8 @@ are other programs that sync mail. I'm looking at:
    using SSH to sync, <del>will try this next</del>, may have
    performance problems, see comment below
  * [interimap](https://guilhem.org/interimap/): syncs two IMAP servers, apparently faster than
-   `doveadm` and `offlineimap`
+   `doveadm` and `offlineimap`, but requires running an IMAP server
+   locally
  * [mail-sync](https://blog.hades.lkamp.de/mail-sync/): notify support, happens over any piped transport
    (e.g. ssh), diff/patch system, requires binary on both ends,
    mentions UUCP in the manpage, seems awfully complicated to setup,

also update TPO password manager, untested
diff --git a/.well-known/openpgpkey/Makefile b/.well-known/openpgpkey/Makefile
index 4d5eaa5b..a08a1d55 100644
--- a/.well-known/openpgpkey/Makefile
+++ b/.well-known/openpgpkey/Makefile
@@ -4,6 +4,7 @@ ADDRESS=anarcat@debian.org
 FINGERPRINT=8DC901CE64146C048AD50FBB792152527B75921E
 NEXT_EXPIRE=$(shell LANG=C date -d '+1 year +1 month' '+%Y-%m-%d')
 TPO_KEYRING=~/src/tor/account-keyring/
+TPO_PWMANAGER=~/src/tor/tor-passwords/
 
 all: warn hu upload
 
@@ -28,8 +29,15 @@ renew:
 	gpg --quick-set-expire $(FINGERPRINT) $(NEXT_EXPIRE)
 
 upload-tpo:
+	@echo "updating TPO keyring"
 	git -C $(TPO_KEYRING) pull
 	gpg --export --export-options export-minimal $(FINGERPRINT) > $(TPO_KEYRING)/torproject-keyring/anarcat-$(FINGERPRINT).gpg
 	git -C $(TPO_KEYRING) commit torproject-keyring/anarcat-$(FINGERPRINT).gpg
 	git -C $(TPO_KEYRING) push
 	git -C $(TPO_KEYRING) push alberti
+
+	@echo "updating TPO password manager keyring"
+	git -C $(TPO_PWMANAGER) pull
+	gpg --export --export-options export-minimal $(FINGERPRINT) | gpg --no-default-keyring --keyring=$(TPO_PWMANAGER)/.keyring --import
+	git -C $(TPO_PWMANAGER) commit .keyring
+	git -C $(TPO_PWMANAGER) push

response
diff --git a/blog/2021-09-05-bullseye-upgrade-notes/comment_2_f522f178bcc58f5dea201363c5ffa277._comment b/blog/2021-09-05-bullseye-upgrade-notes/comment_2_f522f178bcc58f5dea201363c5ffa277._comment
new file mode 100644
index 00000000..03dc681f
--- /dev/null
+++ b/blog/2021-09-05-bullseye-upgrade-notes/comment_2_f522f178bcc58f5dea201363c5ffa277._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""cssh and others"""
+ date="2021-09-21T14:57:58Z"
+ content="""
+Thanks Fabian, that's a great point! clusterssh (AKA `cssh`) is how I did a *lot* of Debian upgrades at Koumbit back in the days. I don't know why exactly I haven't used it yet here, but there's something to be said about heterogeneous systems here.
+
+If you have a lot of identical machines, then, yes, just batch-entering all those commands on all those machines at once works like a charm. I would actually use clustershell for this nowadays, since you can feed it a bunch of scripts more easily and you don't have to deal with tens of windows or Perl or TCL/TK like cssh (maybe I remember wrong).
+
+But still: that doesn't deal with the situation where you have that special snowflake server (e.g. PostgreSQL) that needs to be upgraded just so. Sure, you can do the upgrade at once there as well: you enter the magic commands on all the servers for that as well. But then if you mess it up, you destroy all your (e.g. PostgreSQL!) servers all at once.
+
+The idea of scripting this into something that can be batched by something like cumin or others is that you can start the upgrade on a part of the cluster and then *stop* if something goes wrong. With `cssh` and friends, it's kind of all-or-nothing.
+
+Of course, you can absolutely select part of the cluster by hand, but that is still kind of slow and manual.
+
+I want a silver bullet, and one that we can collaborate on too. If you or I can do cssh to deal with those things, that's great, but that doesn't help Roger over there who's just getting started with Debian sysadmin and has to now figure out how to upgrade PostgreSQL interactively...
+"""]]

approve comment
diff --git a/blog/2021-09-05-bullseye-upgrade-notes/comment_1_5c4a20ce8649253bcc96fac6d7296ae2._comment b/blog/2021-09-05-bullseye-upgrade-notes/comment_1_5c4a20ce8649253bcc96fac6d7296ae2._comment
new file mode 100644
index 00000000..2a27f40b
--- /dev/null
+++ b/blog/2021-09-05-bullseye-upgrade-notes/comment_1_5c4a20ce8649253bcc96fac6d7296ae2._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ ip="24.37.118.114"
+ claimedauthor="Fabian Rodriguez"
+ url="https://legoudulibre.com"
+ subject="clusterssh"
+ date="2021-09-21T02:22:24Z"
+ content="""
+I group together virtual machines, servers and containers that are similar.
+
+They tend to have configurations close enough to send the upgrade commands/ scripts in parallel, simultaneously.
+
+So for example I have a cluster of 3 Proxmox servers, I will access them with:
+
+    clusterssh pve01 pve02 pve03
+
+... and issue the commands there.
+
+Then for all the IS/IT servers (VMs):
+
+    clusterssh support syspass guacamole ssh-bastion
+
+And for web servers:
+
+    clusterssh web1 web2 web3 web4
+
+etc.
+
+It remains a semi-manual process but much faster than going into each and every system simultaneously. 
+
+I don't manage anything bigger than 15-20 servers at a time so it's not the same problem and probably wouldn't scale but it works for me.
+"""]]

details on the purism i won't buy
diff --git a/hardware/curie.mdwn b/hardware/curie.mdwn
index 0496c653..7a647816 100644
--- a/hardware/curie.mdwn
+++ b/hardware/curie.mdwn
@@ -184,7 +184,15 @@ To investigate: see the [Brix](https://www.gigabyte.com/us/Mini-PcBarebone) and
 ### Purism
 
 Purism [announced their own mini-PC as well](https://puri.sm/posts/announcing-the-purism-librem-mini/), although I kind of
-don't want to buy from them ever again.
+[[don't want to buy from them ever
+again|blog/2020-07-13-not-recommending-purism]]. Their specs include
+"1 HDMI 2.0 4K@60Hz 1 DisplayPort 1.2 4K@60Hz", but (a) it's unclear
+if that's a "and" (2x4k) or a "or" (1x4k). And given what I know about
+DP and HDMI, that's probably barely 4k in the first place...
+
+It's also expensive: 800$, which is a couple hundreds above an
+equivalent Asus or Intel equivalent. It's even 200$ above a better
+System76 (the meerkat, below).
 
 ### System76 & Intel
 

toc
diff --git a/hardware/curie.mdwn b/hardware/curie.mdwn
index f6206132..0496c653 100644
--- a/hardware/curie.mdwn
+++ b/hardware/curie.mdwn
@@ -18,7 +18,7 @@ which remain major centres of medical research today.*"
 
 I bought it after a failed search for a [[laptop|hardware/laptop]].
 
-[[!toc levels=2]]
+[[!toc levels=3]]
 
 # Specification
 
@@ -177,16 +177,16 @@ twist: has AMD Ryzen processors, see e.g. the [PN50](https://www.asus.com/us/dis
 The [Quiet PC](https://www.quietpc.com/) folks make a [fanless version](https://www.quietpc.com/sys-ultra-pn50-pro-4-fanless), although it's
 much larger.
 
-## Brix and Qotom
+### Brix and Qotom
 
 To investigate: see the [Brix](https://www.gigabyte.com/us/Mini-PcBarebone) and [Qotom](https://www.qotom.net/) mini-PCs.
 
-## Purism
+### Purism
 
 Purism [announced their own mini-PC as well](https://puri.sm/posts/announcing-the-purism-librem-mini/), although I kind of
 don't want to buy from them ever again.
 
-## System76 & Intel
+### System76 & Intel
 
 System76 still sell their [Meerkat](https://system76.com/desktops/meerkat) which is a whiteboxing of the
 famous [Intel NUC platform](https://en.wikipedia.org/wiki/Next_Unit_of_Computing). It's unclear what we gain by buying

small note about the latest NUC
diff --git a/hardware/curie.mdwn b/hardware/curie.mdwn
index a787578d..f6206132 100644
--- a/hardware/curie.mdwn
+++ b/hardware/curie.mdwn
@@ -192,4 +192,8 @@ System76 still sell their [Meerkat](https://system76.com/desktops/meerkat) which
 famous [Intel NUC platform](https://en.wikipedia.org/wiki/Next_Unit_of_Computing). It's unclear what we gain by buying
 from them, other than encouraging a Linux company of course.
 
+The 11th gen Intel stuff does support 2xDP 1.4a *and* 2x thunderbolt
+(3 and 4, respectively) connectors, which can basically power *four*
+4k monitors, if I count correctly.
+
 [[!tag node]]

add system76
diff --git a/hardware/curie.mdwn b/hardware/curie.mdwn
index b0b2b6ae..a787578d 100644
--- a/hardware/curie.mdwn
+++ b/hardware/curie.mdwn
@@ -186,4 +186,10 @@ To investigate: see the [Brix](https://www.gigabyte.com/us/Mini-PcBarebone) and
 Purism [announced their own mini-PC as well](https://puri.sm/posts/announcing-the-purism-librem-mini/), although I kind of
 don't want to buy from them ever again.
 
+## System76 & Intel
+
+System76 still sell their [Meerkat](https://system76.com/desktops/meerkat) which is a whiteboxing of the
+famous [Intel NUC platform](https://en.wikipedia.org/wiki/Next_Unit_of_Computing). It's unclear what we gain by buying
+from them, other than encouraging a Linux company of course.
+
 [[!tag node]]

add toc
diff --git a/hardware/curie.mdwn b/hardware/curie.mdwn
index 6bc377b0..b0b2b6ae 100644
--- a/hardware/curie.mdwn
+++ b/hardware/curie.mdwn
@@ -18,6 +18,8 @@ which remain major centres of medical research today.*"
 
 I bought it after a failed search for a [[laptop|hardware/laptop]].
 
+[[!toc levels=2]]
+
 # Specification
 
 * SoC: [Intel NUC BOXNUC6I3SYH][] I3-6100U 2xDDR4-2133 SODIMM Slots

curie replacement options
diff --git a/hardware/curie.mdwn b/hardware/curie.mdwn
index a9f251bb..6bc377b0 100644
--- a/hardware/curie.mdwn
+++ b/hardware/curie.mdwn
@@ -127,4 +127,61 @@ the upgrade eventually go through, but it finally did.
 The [release notes](https://downloadmirror.intel.com/29102/eng/SY_0072_ReleaseNotes.pdf) detail the updates since the previous one (v61)
 which includes a bunch of security updates, for example.
 
+## Replacement options
+
+The CMOS battery died some time in 2021, and I'm having a hard time
+replacing it (surprisingly). I'm also seeing weird CPU hangs, e.g.:
+
+    sep 13 15:23:46 curie kernel: watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [Web Content:25294]
+
+So I'm wondering if things are exploding here, and looking at
+replacement options.
+
+Must have:
+
+ * 2 x monitor support, ideally forward-compatible with 2x4k
+ * 32GB or more
+ * similar processing power as the current NUC or the librem 13v4 or
+   better
+ * silent or mostly so, even under load
+ * support for current storage (M.2 or NVMe + 2.5" HDD or more)
+ * gigabit ethernet
+ * full Linux support without proprietary blobs
+
+Nice to have:
+
+ * USB-C powered
+ * SD card reader
+ * similar form factor as the NUC
+ * not Intel
+ * hotswap bays
+
+### Asus MiniPC PN50
+
+Asus has a [PN/PB series](https://www.asus.com/us/Displays-Desktops/Mini-PCs/PN-PB-series/filter?Series=PN-PB-series) that's basically a clone of the NUC. Nice
+twist: has AMD Ryzen processors, see e.g. the [PN50](https://www.asus.com/us/displays-desktops/mini-pcs/pn-pb-series/mini-pc-pn50/):
+
+ * AMD Ryzen 4000
+ * 4x4k
+ * <=64GB ram
+ * M.2 SSD
+ * dual USB-C 3.2 gen 2
+ * dual USB-A
+ * microSD
+ * HDMI
+ * gbit ethernet
+ * modular extra port: Display Port, serial, LAN, VGA
+
+The [Quiet PC](https://www.quietpc.com/) folks make a [fanless version](https://www.quietpc.com/sys-ultra-pn50-pro-4-fanless), although it's
+much larger.
+
+## Brix and Qotom
+
+To investigate: see the [Brix](https://www.gigabyte.com/us/Mini-PcBarebone) and [Qotom](https://www.qotom.net/) mini-PCs.
+
+## Purism
+
+Purism [announced their own mini-PC as well](https://puri.sm/posts/announcing-the-purism-librem-mini/), although I kind of
+don't want to buy from them ever again.
+
 [[!tag node]]
diff --git a/hardware/server/marcos.mdwn b/hardware/server/marcos.mdwn
index cf5cc437..d5731bf1 100644
--- a/hardware/server/marcos.mdwn
+++ b/hardware/server/marcos.mdwn
@@ -165,23 +165,7 @@ looking for replacements.
 
 ## NUC
 
-An easy first target is to buy another NUC like the [[curie
-workstation|hardware/curie]] since it's cheap and works well. The
-downside is that it requires laptop (2.5") hard disks which are more
-expensive. A replacement drive for Marcos could cost around 200$CAD ([2.5"
-4TB Seagate at newegg.ca](https://www.newegg.ca/Product/Product.aspx?Item=N82E16822179105)). The 500GB M.2 drives are still around
-190$CAD. So a replacement would be at least 800$CAD, probably around
-1000$ with memory.
-
-Possible issues:
-
- * limited disk space
- * embeded SoC from Intel, with *hardcore* proprietary onboard
-   software (Intel ME and crazy BIOS)
-
-See also the [Brix](https://www.gigabyte.com/us/Mini-PcBarebone) and [Qotom](https://www.qotom.net/) mini-PCs.
-
-Update: Purism [announced their own mini-PC as well](https://puri.sm/posts/announcing-the-purism-librem-mini/).
+See [[the curie page for ideas on that space|hardware/curie]].
 
 ## Vero
 
@@ -388,9 +372,9 @@ little [NAS case](https://wiki.pine64.org/wiki/NASCase). Make sure you also get
 
 https://www.crowdsupply.com/traverse-technologies/ten64/updates/building-a-nas-with-ten64-and-rockstor-and-new-turnkey-nas-bundle
 
-## Qotom
+## Brix and Qotom
 
-Embedded devices: http://qotom.net/
+To investigate: see the [Brix](https://www.gigabyte.com/us/Mini-PcBarebone) and [Qotom](https://www.qotom.net/) mini-PCs.
 
 ## Other SoC boards
 

some keyboard from outer space
diff --git a/hardware/keyboard.mdwn b/hardware/keyboard.mdwn
index 1da71933..f74a54f2 100644
--- a/hardware/keyboard.mdwn
+++ b/hardware/keyboard.mdwn
@@ -210,6 +210,22 @@ Another split keyboard, but this one you get to build yourself: http://ergodox.o
 
 Good luck with the soldering. If you fail, you get to start over with a new kit too, yaaay.
 
+## Moonlander
+
+<https://www.zsa.io/moonlander/>
+
+ * split keyboard
+ * programmable, open firmware
+ * mechanical, hot-swappable switches
+ * backlit
+ * beeps
+ * foldable, slim
+ * USB-C
+ * both ends connected with a standard 1/8" jack
+ * 380$
+ * no windows logo (obviously), tons of custom keys
+ * customizable keys (e.g. "hold to send X")
+
 ## Keyboard for life
 
 15$. Spill-proof. Lifetime warranty. Next keyboard?

fix headings
diff --git a/hardware/keyboard.mdwn b/hardware/keyboard.mdwn
index 608834cb..1da71933 100644
--- a/hardware/keyboard.mdwn
+++ b/hardware/keyboard.mdwn
@@ -7,19 +7,16 @@ MX blue keys. That turned out to be too noisy, even with my roommates
 being *in the next room*, so I do not use the keyboard except as a
 spare now (!).
 
-Requirements
-============
+# Requirements
 
-Layout
-------
+## Layout
 
 I like the [ANSI layout](https://en.wikipedia.org/wiki/Keyboard_layout#Mechanical.2C_visual_and_functional_layouts), [[!wikipedia QWERTY]] of course. Ideally,
 I would like to have an ANSI keyboard with the `«»` key added, but
 this doesn't seem to actually exist, and I don't like the oversized
 ISO enter key, as I used backslash a lot.
 
-No numpad
----------
+## No numpad
 
 I would like to have an external numeric keypad. This means less
 traveling between the keyboard and the mouse, which I still use more
@@ -34,16 +31,13 @@ keyboard. Those articles help me figure out the different layouts:
  * [WASD keyboard products](http://www.wasdkeyboards.com/index.php/products/mechanical-keyboard.html?dir=asc&order=name), for example comparing [88-key](http://www.wasdkeyboards.com/index.php/products/mechanical-keyboard/wasd-v2-88-key-iso-custom-mechanical-keyboard.html),
    [87-key](http://www.wasdkeyboards.com/index.php/products/mechanical-keyboard/wasd-v2-87-key-custom-mechanical-keyboard.html) and [104-key](http://www.wasdkeyboards.com/index.php/products/mechanical-keyboard/wasd-v3-104-key-custom-mechanical-keyboard.html) layouts
 
-Tactile feel
-------------
+## Tactile feel
 
 I liked the clikety feeling of the Model M, but not the sound. Ideally, it would have the same feeling, but less loud. The [MX brown](http://deskthority.net/wiki/Cherry_MX_Brown) seems to have that characteristic, but I am worried it will loose the clikety feeling. The [Cherry MX clear](http://deskthority.net/wiki/Cherry_MX_Clear) may be a good compromise.
 
-Nice to have
-============
+# Nice to have
 
-Low latency
------------
+## Low latency
 
 As discussed in [[monitor]] and my [[terminal emulators
 review|blog/2018-05-04-terminal-emulators-2/#latency]], we have very
@@ -56,8 +50,7 @@ Update: apparently, this is moot if the keyboard connects with a
 high-speed USB protocol. See [this video](https://www.youtube.com/watch?v=wdgULBpRoXk) from [Ben
 Eater](https://eater.net/), which shows a high-speed keyboard with 1ms latency.
 
-Open firmware
--------------
+## Open firmware
 
 We now live in a world where every device has its own little computer,
 a controller that parses the electric output of switches and turn that
@@ -70,13 +63,11 @@ Having support for an open firmware would be a plus, and would
 possibly allow us to *reduce* the keyboard latency by changing or
 removing the debouncing algorithm.
 
-Keyboard models
-===============
+# Keyboard models
 
 So here is inventory of the (surprisingly) expensive alternatives...
 
-WASD
-----
+## WASD
 
 The [WASD](http://www.wasdkeyboards.com/) family has interesting
 model. The [WASD V2 87-Key Custom Mechanical Keyboard](http://www.wasdkeyboards.com/index.php/products/mechanical-keyboard/wasd-v2-87-key-custom-mechanical-keyboard.html) has the
@@ -112,8 +103,7 @@ Update:
    Mechanical Keyboard](https://www.wasdkeyboards.com/index.php/products/mechanical-keyboard/wasd-87-key-doubleshot-pbt-black-slate-mechanical-keyboard.html) next time, because they keys wear out much
    less, and it's still really pretty
 
-CODE
-----
+## CODE
 
 The [CODE keyboard](http://codekeyboards.com/) is also made by WASD but has special specs.
 
@@ -131,8 +121,7 @@ The [CODE keyboard](http://codekeyboards.com/) is also made by WASD but has spec
  * no windows logo!
  * 147$USD
 
-Happy Hacker Keyboard
----------------------
+## Happy Hacker Keyboard
 
 The [HHKB](https://hhkeyboard.us/) is interesting because it goes back to the old "[Sun
 type 3](http://blog.daveastels.com.s3-website-us-west-2.amazonaws.com/2014/12/27/type-3-keyboard.html)" keyboard layout, where the control key is next to the `A`
@@ -146,8 +135,7 @@ Their keyboards have weird features like variable actuation points and
 
 260$USD.
 
-Das Keyboard
-------------
+## Das Keyboard
 
 I had the privilege of using that keyboard for a week. I like the sound, layout and general design of the keyboard. I found it a bit annoying to not have any labels on the keys: even if I am a good touch typist, sometimes for typing passwords, especially with digits in them, it can be difficilt to find the keys... But they have an alternative with labels on the key, at no extra cost.
 
@@ -168,8 +156,7 @@ I think I would get [a Model S professsionnal](http://www.daskeyboard.com/produc
 
 See also [[!wikipedia Das_Keyboard]].
 
-Filco
------
+## Filco
 
 This company also produces cherry switches keyboards. The [majestouch](http://ncix.com/products/?sku=70718&vpn=FKBN104MC%2FEB2&manufacture=Filco&promoid=1306) is interesting:
 
@@ -181,8 +168,7 @@ This company also produces cherry switches keyboards. The [majestouch](http://nc
 
 The [ninja](http://ncix.com/products/?sku=70726&vpn=FKBN104MC%2FEFB2&manufacture=Filco) version has key labels in front.
 
-Cherry
-------
+## Cherry
 
 The company that makes those famous switches also actually make keyboards. Ncix sell [this one](http://products.ncix.com/detail/cherry-g80-3800-blue-switch-mx-board-2-0-104-key-mechanical-keyboard-black-a2-75697.htm) for 70$. It seems it's a cheaper design than the other ones.
 
@@ -201,8 +187,7 @@ The [G80-3000](http://deskthority.net/wiki/Cherry_G80-3000), manufactured since
  * 1.75m cable
  * 2lbs
 
-Rosewill
---------
+## Rosewill
 
 The Rosewill is Newegg's branded Filco keyboard. It's the equivalent of the Majestouch.
 
@@ -213,30 +198,26 @@ The Rosewill is Newegg's branded Filco keyboard. It's the equivalent of the Maje
 
 [This one](http://www.newegg.ca/Product/Product.aspx?Item=N82E16823201054) is illuminated and 120$ for cherry blue keys...
 
-Truly ergonomic
----------------
+## Truly ergonomic
 
 This keyboard is different from all the other and I'll take it as the flagship of "ergonomic" keyboards (aka "split" keyboards):
 
 <https://www.trulyergonomic.com/store/index.php>
 
-Ergodox
--------
+## Ergodox
 
 Another split keyboard, but this one you get to build yourself: http://ergodox.org/
 
 Good luck with the soldering. If you fail, you get to start over with a new kit too, yaaay.
 
-Keyboard for life
------------------
+## Keyboard for life
 
 15$. Spill-proof. Lifetime warranty. Next keyboard?
 
 <http://www.kensington.com/us/us/4489/k64370a/keyboard-for-life#.VsjA1j9Xbec>
 
 
-Ultimate hacking keyboard
------------------------------
+## Ultimate hacking keyboard
 
 "Built to last", "split keyboard" and all sorts of buzzwords...
 
@@ -250,8 +231,7 @@ Downsides:
  * no function keys without modifier
  * expensive
 
-Keyboard.io
------------
+## Keyboard.io
 
 [Keyboard.io](https://shop.keyboard.io/) is an open hardware keyboard that comes with "source
 code and a screwdriver". It comes fully assembled, that said. It has a
@@ -262,8 +242,7 @@ control, alt and shift). There are also "palm" keys that act as Fn
 keys. All this is probably totally alien and too weird for my poor old
 fingers to adapt to, but it does look gorgeous.
 
-Keychron
---------
+## Keychron
 
 [Keychron](https://www.keychron.com/) - nice wireless keyboards, maybe?
 

note the new latency info i got
diff --git a/hardware/keyboard.mdwn b/hardware/keyboard.mdwn
index a9d42bf9..608834cb 100644
--- a/hardware/keyboard.mdwn
+++ b/hardware/keyboard.mdwn
@@ -52,6 +52,10 @@ computer. In theory, we can get sub 30ms latency in the entire chain,
 and keyboards take up almost half of that (14ms). So it would be nice
 to have keyboards with lower latency than this.
 
+Update: apparently, this is moot if the keyboard connects with a
+high-speed USB protocol. See [this video](https://www.youtube.com/watch?v=wdgULBpRoXk) from [Ben
+Eater](https://eater.net/), which shows a high-speed keyboard with 1ms latency.
+
 Open firmware
 -------------
 

fix typo
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index 32b1f8ae..1c312fe7 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -51,7 +51,7 @@ when you have tens or hundreds of machines to upgrade.
 Debian upgrades are notorious for being extremely reliable, but we
 have a *lot* of packages, and there are *always* corner cases where
 the upgrade will just fail because of a bug specific to your
-environment. Those will only fixed after some back and forth in the
+environment. Those will only be fixed after some back and forth in the
 community (and that's assuming users report those bugs, which is not
 always the case). There's no obvious way to deploy "hot fixes" in this
 context, at least not without fixing the package *and* publishing it

another caveat with frame.work
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index ffdb490e..4b2d26d4 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -61,7 +61,10 @@ Frame work
  * [excellent documentation of the (proprietary) BIOS](https://community.frame.work/t/bios-guide/4178/1)
  * 3.5mm combo headphone jack
  * 60W USB-C
- * 55 Wh battery, between 2h and 10h battery
+ * 55 Wh battery, between 2h and 10h battery, described as "mediocre"
+   by Ars Technica, certainly not up to the Dell XPS 13 standard, but
+   may be better or equivalent than my current (2021-09-27) laptop
+   (Purism 13v4, currently says 7h)
  * 1080p 60fps camera
  * backlit keyboard, annoying LED around power button
  * 1.3kg, 15.85mm x 296.63mm x 228.98mm

update mnt reform reviews
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index 96aaa3de..ffdb490e 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -122,16 +122,68 @@ In pre-order, expected in 2020.
 Mnt reform
 ----------
 
-The [reform](http://mntmn.com/reform/) is a DIY laptop at the
-prototype stage:
-
- * ARM NXP i.MX6 / i.MX8
- * PCIe, USB3/C?
- * Wifi?
+The [reform](http://mntmn.com/reform/) is a DIY laptop that is pretty grassroots, somewhat
+"vintage" computing, reminescent of the Apple II or Comodore 64, but
+with a quad-core ARM CPU.
+
+ * upstream spec:
+   * CPU: NXP/Freescale i.MX8MQ with 4x ARM Cortex-A53 cores (1.5
+     GHz), 1x Cortex-M4F core. CPU and RAM are on exchangeable SO-DIMM
+     sized module.
+   * RAM: 4 GB LPDDR4 memory
+   * GPU: Vivante GC7000Lite GPU with mainline Linux drivers and
+     OpenGL 2.1, ES 2.0
+   * Display: Full HD (1920x1080 pixels) 12.5" IPS eDP display driven
+     via MIPI-DSI. Optionally-enabled HDMI port. 128 x 32 pixel system
+     control OLED
+   * USB: 3x USB 3.0 ports external (Type-A), 2x USB 2.0 internal (for
+     input devices)
+   * Networking: Gigabit Ethernet port. miniPCIe Wi-Fi card included
+     in Reform Max pledge level.
+   * Storage: Internal M.2 M-key socket for NVMe SSD. Full size SD
+     card slot.
+   * PCIe: 1x miniPCIe socket (PCIe 2.0 1x), 1x M.2/NGFF socket M-key
+     (PCIe 2.0 1x)
+   * Keyboard: Reform mechanical USB keyboard with Kailh Choc Brown
+     Switches, dimmable backlight, open firmware
+   * Trackball (Option): Reform optical USB trackball with 5
+     mechanical switches (Kailh Choc Brown), open firmware
+   * Trackpad (Option): Reform capacitive USB trackpad, open firmware
+   * Enclosure: Modular case from CNC-milled, bead-blasted,
+     black-anodized 6061 aluminum. Bottom cover milled from
+     semi-transparent acrylic.
+   * Sound: Wolfson WM8960 ADC/DAC, stereo speakers, 3.5"
+     headset/microphone jack (no internal microphone)
+   * Camera: No camera. Internal MIPI-CSI connector
+   * Battery: LiFePO4 battery technology - which is more fire-safe and
+     has more charge-cycles than LiPo battieries. 8x owner-serviceable
+     18650 cells totalling 12 Ah/3.2 V. 5 h approximate battery life
+   * System Controller: NXP LPC11U24 ARM Cortex-M0 chip with open
+     firmware and hackable expansion port
+   * Manual: Operator Manual incl. system schematics and full parts
+     list
+   * Sources: KiCAD sources for motherboard, keyboard, trackball,
+     trackpad, STEP/STL/FreeCAD files for case parts, C sources for
+     all firmware (input devices and system controller), build scripts
+     for boot & system image
+   * OS: Preloaded with Debian GNU/Linux 11, Linux 5.x mainline kernel
+   * Dimensions: 29 x 20.5 x 4 cm
+   * Weight: ~1.9 kg
+ * ships with a trackball!?
+ * no mic, no webcam!
+ * kind of really bulky, deliberately
+ * awesome batteries
+ * 24 V 2 A international power supply (110/230 V)
+ * aluminium and acrylic case
  * MiniSD boot, SSD
- * 500-700EUR
-
-Interesting especially for the possibility of a e-ink screen...
+ * 1000$ kit, 1500$ built
+ * [input mag review](https://www.inputmag.com/reviews/mnt-reform-review-your-diy-laptop-fantasy-is-here-at-last), which mentions some build issues and
+   definitely sets expectations about performance
+ * [another review](https://technomancy.us/195)
+ * could be used as a low-end audio recording/mixing station?
+
+There was a possibility for an e-ink screen and hot-swappable
+keyboard, but that was scraped during production.
 
 Wootbook
 --------

more details on frame.work laptop
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index 83aea3f1..96aaa3de 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -43,7 +43,10 @@ Frame work
 
  * easily repairable (qrcodes pointing to repair guides!), [10/10
    score from ifixit.com](https://www.ifixit.com/News/51614/framework-laptop-teardown-10-10-but-is-it-perfect), which they call "exceedingly rare"
- * modular ports, replacable mainboard
+ * four modular USB-C ports which can fit HDMI, USB-C (pass-through,
+   can provide power on both sides), USB-A, DisplayPort, MicroSD,
+   external storage (250GB, 1TB), [active modding community](https://community.frame.work/c/expansion-cards/developer-program/90)
+ * replaceable mainboard
  * first two batches shipped, third batch sold out, fourth batch ships
    in October 2021
  * 1300$USD for i5 with 8GB RAM, 256GB storage, Windows 10
@@ -51,6 +54,22 @@ Frame work
    for 1TB)
  * good reviews: [Ars Technica](https://arstechnica.com/gadgets/2021/07/frameworks-new-lightweight-modular-laptop-delivers-on-its-promises/), [Fedora developer](https://www.scrye.com/wordpress/nirik/2021/08/29/frame-work-laptop-the-hyperdetailed-fedora-review/), [iFixit
    teardown](https://www.ifixit.com/News/51614/framework-laptop-teardown-10-10-but-is-it-perfect), more critical review: [OpenBSD developer](https://jcs.org/2021/08/06/framework)
+ * [test account on fwupd.org](https://fwupd.org/lvfs/vendors/#framework), "expressed interest to port to
+   coreboot" (according to the Fedora developer) and [are testing
+   firmware updates over fwupd](https://community.frame.work/t/framework-firmware-on-the-lvfs/4466), supposedly "plans to release
+   firmware updates there" (according to the Fedora dev)
+ * [excellent documentation of the (proprietary) BIOS](https://community.frame.work/t/bios-guide/4178/1)
+ * 3.5mm combo headphone jack
+ * 60W USB-C
+ * 55 Wh battery, between 2h and 10h battery
+ * 1080p 60fps camera
+ * backlit keyboard, annoying LED around power button
+ * 1.3kg, 15.85mm x 296.63mm x 228.98mm
+ * 1 year warranty
+ * 13.5” 3:2, 2256x1504, 100% sRGB color gamut, and >400 nit
+ * Intel® Wi-Fi 6E AX210
+ * fan quiet when idle, but can be noisy when running
+ * fingerprint reader
 
 GPD pocket
 ----------

more on the framework laptop
This feels more and more like my next laptop.
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index f7c5ca35..83aea3f1 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -41,9 +41,16 @@ Frame work
 
 <https://frame.work/>
 
- * easily repairable (qrcodes pointing to repair guides!)
+ * easily repairable (qrcodes pointing to repair guides!), [10/10
+   score from ifixit.com](https://www.ifixit.com/News/51614/framework-laptop-teardown-10-10-but-is-it-perfect), which they call "exceedingly rare"
  * modular ports, replacable mainboard
- * no price announced yet (feb 2021)
+ * first two batches shipped, third batch sold out, fourth batch ships
+   in October 2021
+ * 1300$USD for i5 with 8GB RAM, 256GB storage, Windows 10
+ * DIY kit: 1250$USD for i5 with 16GB RAM, 500GB NVMe, no OS (+100$
+   for 1TB)
+ * good reviews: [Ars Technica](https://arstechnica.com/gadgets/2021/07/frameworks-new-lightweight-modular-laptop-delivers-on-its-promises/), [Fedora developer](https://www.scrye.com/wordpress/nirik/2021/08/29/frame-work-laptop-the-hyperdetailed-fedora-review/), [iFixit
+   teardown](https://www.ifixit.com/News/51614/framework-laptop-teardown-10-10-but-is-it-perfect), more critical review: [OpenBSD developer](https://jcs.org/2021/08/06/framework)
 
 GPD pocket
 ----------

another great upgrade report
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index 318c9451..32b1f8ae 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -161,10 +161,10 @@ There must be a better way. What is yours?
 
 So far, I have upgraded 2 out of my 3 home machines running buster --
 others have been installed directly in bullseye -- with only my main,
-old, messy server left. Upgrades have been pretty painless so far,
-much better than the [[previous buster
-upgrade|services/upgrades/buster]]. Obviously, for me personal use,
-automating this is pointless.
+old, messy server left. Upgrades have been pretty painless so far (see
+[another report](https://q-funk.blogspot.com/2021/09/sudo-apt-get-update-sudo-apt-get-dist.html), for example), much better than the [[previous
+buster upgrade|services/upgrades/buster]]. Obviously, for me personal
+use, automating this is pointless.
 
 Work-side, however, is [another story](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/bullseye): we have over 80 boxes to
 upgrade there and that will take a while. The last [stretch to buster

remove duplicate tag
diff --git a/blog/2016-12-22-debian-considering-automated-upgrades.mdwn b/blog/2016-12-22-debian-considering-automated-upgrades.mdwn
index 0eab5b4d..d0e8e7d6 100644
--- a/blog/2016-12-22-debian-considering-automated-upgrades.mdwn
+++ b/blog/2016-12-22-debian-considering-automated-upgrades.mdwn
@@ -246,4 +246,4 @@ or the [Debian wiki](https://wiki.debian.org/UnattendedUpgrades).
 [first appeared]: https://lwn.net/Articles/709201/
 [Linux Weekly News]: http://lwn.net/
 
-[[!tag debian-planet debian lwn geek security upgrades]]
+[[!tag debian-planet debian lwn geek security upgrade]]
diff --git a/tag/upgrades.mdwn b/tag/upgrades.mdwn
deleted file mode 100644
index 45e3f238..00000000
--- a/tag/upgrades.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-[[!meta title="pages tagged upgrades"]]
-
-[[!inline pages="tagged(upgrades)" actions="no" archive="yes"
-feedshow=10]]

publish draft
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index d8df6f47..318c9451 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -176,6 +176,6 @@ too late...
 At least I fixed the installers so that new the machines we create all
 ship with bullseye, so we stopped accumulating new buster hosts...
 
-> Thanks to [lelutin](https://lelutin.ca/) for reviewing a draft of this post.
+> Thanks to [lelutin](https://lelutin.ca/) and [pabs](https://bonedaddy.net/pabs3/) for reviewing a draft of this post.
 
-[[!tag draft]]
+[[!tag debian-planet python-planet debian upgrade sysadmin tor]]

reword title
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index 4e801666..d8df6f47 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -1,4 +1,4 @@
-[[!meta title="Automating Debian major upgrades"]]
+[[!meta title="Automating major Debian upgrades"]]
 
 It's major upgrade time again! The [Debian project](https://www.debian.org/) just published
 the [Debian 11 "bullseye"](https://www.debian.org/News/2021/20210814) release, and it's pretty awesome! This

more tools
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index 28962482..4e801666 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -28,7 +28,8 @@ on my wiki, starting with the [[jessie
 release|services/upgrades/jessie]], but I have actually written such
 guides for [Koumbit.org](https://koumbit.org) as far back as [Debian squeeze](https://wiki.koumbit.net/SqueezeUpgrade) in 2011
 (another worker wrote the older [Debian lenny](https://wiki.koumbit.net/LennyUpgrade) upgrade guide in
-2009).
+2009). Koumbit, since then, has kept maintaining those guides all the
+way to the latest [bullseye upgrade](https://wiki.koumbit.net/BullseyeUpgrade), through 7 major releases!
 
 Over the years, those guides evolved from a quick "cheat-sheet" format
 copied from the [release notes](https://www.debian.org/releases/) into a more or less "scripted" form
@@ -36,7 +37,8 @@ that I currently use.
 
 Each guide has a procedure made of a few steps that can be basically
 copy-pasted to batch-upgrade a host (or multiple hosts in parallel) as
-quickly as possible. 
+quickly as possible. There is also the [predict-os](https://gitlab.com/anarcat/predict-os) script which
+allows you to keep track of progress of the upgrades in a Puppet cluster.
 
 # Limitations of the official procedure
 

rephrase
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index cc709f7f..28962482 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -12,9 +12,9 @@ which includes major version changes (e.g. [Inkscape 1.0](https://librearts.org/
 packages (e.g. [podman](https://podman.io/)!) and important behavior changes
 (e.g. [driverless scanning and printing](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html#driverless-operation)!).
 
-I'm particularly interested to hear if I missed any significant
-change. If you know of a cool new package that shipped with bullseye
-and that I forgot, do let me know!
+I'm particularly interested to hear about any significant change I
+might have missed. If you know of a cool new package that shipped with
+bullseye and that I forgot, do let me know!
 
 But that's for the cool new stuff. We need to talk about the problems
 with Debian major upgrades.

clarify
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index b261ce44..cc709f7f 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -6,7 +6,7 @@ makes me realized that I have never written here about my [[peculiar
 upgrade process|services/upgrades/bullseye]], and figured it was worth
 bringing that up to a wider audience.
 
-The [[upgrade document|services/upgrades/bullseye]] also has a
+My [[upgrade process|services/upgrades/bullseye]] also has a
 [[notable changes|services/upgrades/bullseye#notable-changes]] section
 which includes major version changes (e.g. [Inkscape 1.0](https://librearts.org/2020/05/above-and-beyond-inkscape-1-0/)!), new
 packages (e.g. [podman](https://podman.io/)!) and important behavior changes

shuffle titles and sections around
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index ae22b97c..b261ce44 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -66,7 +66,7 @@ Which means every Debian install needs to be manually upgraded and
 inspected when a new release comes out. That's slow and error prone
 and we can do better.
 
-# A way to automate major upgrades?
+# How to automate major upgrades
 
 I have a [proposal to automate this](https://wiki.debian.org/AutomatedUpgrade). It's been mostly dormant in
 the Debian wiki, for 5 years now. Fundamentally, this is a hard
@@ -104,7 +104,7 @@ grouping using [Cumin](https://doc.wikimedia.org/cumin/master/introduction.html)
 experimenting with [Puppet Bolt](https://puppet.com/docs/bolt/latest/bolt.html) in the bullseye upgrade process,
 but that feels too site-specific to be useful more broadly.
 
-# Is it worth it? Would it work for you?
+# Trade-offs
 
 I am not sure where this stands in the [XKCD time trade-off](https://xkcd.com/1205/)
 evaluation, because the table doesn't actually cover the time
@@ -120,16 +120,6 @@ would shave off between 3 and 18 days of work, which implies I might
 allow myself to spend a minimum of 5 days working on such a
 project.
 
-I'm curious to hear what people think of the idea. It strikes me as
-really odd that no one has really tackled that problem yet,
-considering how many clusters of Debian machines are out there. Surely
-people are upgrading those, and not following that slow step by step
-guide, right?
-
-I suspect everyone is doing the same thing: we all have our little
-copy-paste script we batch onto multiple machines, sometimes in
-parallel. That is what the [Debian.org sysadmins are doing](https://dsa.debian.org/howto/upgrade-to-bullseye/) as well.
-
 # The other option: never upgrade
 
 Before people mention those: I am aware of containers, Kubernetes, and
@@ -151,9 +141,21 @@ about as long as upgrading it, and that's after a [significant amount
 of work](https://gitlab.torproject.org/tpo/tpa/team/-/issues/31239) automating that process, partly writing my own Debian
 installer with Fabric (!).
 
+# What is your process?
+
+I'm curious to hear what people think of those ideas. It strikes me as
+really odd that no one has really tackled that problem yet,
+considering how many clusters of Debian machines are out there. Surely
+people are upgrading those, and not following that slow step by step
+guide, right?
+
+I suspect everyone is doing the same thing: we all have our little
+copy-paste script we batch onto multiple machines, sometimes in
+parallel. That is what the [Debian.org sysadmins are doing](https://dsa.debian.org/howto/upgrade-to-bullseye/) as well.
+
 There must be a better way. What is yours?
 
-# Upgrade progress
+# My upgrades so far
 
 So far, I have upgraded 2 out of my 3 home machines running buster --
 others have been installed directly in bullseye -- with only my main,

tone it down
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index b752406e..ae22b97c 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -38,7 +38,7 @@ Each guide has a procedure made of a few steps that can be basically
 copy-pasted to batch-upgrade a host (or multiple hosts in parallel) as
 quickly as possible. 
 
-# How the official procedure fails us
+# Limitations of the official procedure
 
 In comparison with my procedure, the [official upgrade guide](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html) is
 mostly designed to upgrade a single machine, typically a workstation,

whitespace
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index ba7e47a6..b5793e07 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -658,10 +658,8 @@ be a problem in some cases.
 
  * [Official guide](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html)
  * [Release notes](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html)
- * [Koumbit guide](https://wiki.koumbit.net/BullseyeUpgrade) (WIP,
-   reviewed 2021-08-26)
- * [DSA guide](https://dsa.debian.org/howto/upgrade-to-bullseye/)
-   (WIP, reviewed 2021-08-26)
+ * [Koumbit guide](https://wiki.koumbit.net/BullseyeUpgrade) (WIP, reviewed 2021-08-26)
+ * [DSA guide](https://dsa.debian.org/howto/upgrade-to-bullseye/) (WIP, reviewed 2021-08-26)
  * [TPA guide][] (WIP, last sync 2021-08-26)
  * [Solution proposal to automate this](https://wiki.debian.org/AutomatedUpgrade)
 

some tweaks based on feedback from lelutin
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index cd856e53..b752406e 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -108,7 +108,7 @@ but that feels too site-specific to be useful more broadly.
 
 I am not sure where this stands in the [XKCD time trade-off](https://xkcd.com/1205/)
 evaluation, because the table doesn't actually cover the time
-frequency of Debian release (which is basically "biennal") and the
+frequency of Debian release (which is basically "biennial") and the
 amount of time the upgrade would take across a cluster (which varies a
 lot, but that I estimate to be between one to 6 hours per machine).
 
@@ -130,21 +130,35 @@ I suspect everyone is doing the same thing: we all have our little
 copy-paste script we batch onto multiple machines, sometimes in
 parallel. That is what the [Debian.org sysadmins are doing](https://dsa.debian.org/howto/upgrade-to-bullseye/) as well.
 
-There must be a better way. What is yours?
+# The other option: never upgrade
+
+Before people mention those: I am aware of containers, Kubernetes, and
+other deployment mechanisms. Indeed, those may be a long-term
+solution, we currently can't afford to migrate everything over to
+containers right now: that is a *huge* migration and a total paradigm
+shift. At that point, whatever is left might not even be Debian in the
+first place. And besides, if you run Kubernetes, you still need to run
+*some* OS underneath and upgrade *that*, so that problem never
+completely disappears.
+
+Still, maybe that's the final answer: never upgrade.
 
-(And before people mention those: I am aware of containers,
-Kubernetes, and other deployment mechanisms. Those are, indeed,
-somewhat of a long-term solution, but there are still systems
-underneath those and I currently can't afford to migrate everything
-over to those new systems just yet. Maybe that's the final answer:
-never upgrade. But I still feel there needs to be an intermediate
-solution.)
+For some stateless machines like DNS replicas or load balancers, that
+might make a lot of sense as there's no or little data to carry to the
+new host. But this implies a seamless and fast provisioning process,
+and we don't have that either: at my work, installing a machine takes
+about as long as upgrading it, and that's after a [significant amount
+of work](https://gitlab.torproject.org/tpo/tpa/team/-/issues/31239) automating that process, partly writing my own Debian
+installer with Fabric (!).
+
+There must be a better way. What is yours?
 
 # Upgrade progress
 
-I'm 2/3 machines upgraded so far, only my server is left, and that's
-just because I haven't found the time. Upgrades have been pretty
-painless so far, much better than the [[previous buster
+So far, I have upgraded 2 out of my 3 home machines running buster --
+others have been installed directly in bullseye -- with only my main,
+old, messy server left. Upgrades have been pretty painless so far,
+much better than the [[previous buster
 upgrade|services/upgrades/buster]]. Obviously, for me personal use,
 automating this is pointless.
 
@@ -158,4 +172,6 @@ too late...
 At least I fixed the installers so that new the machines we create all
 ship with bullseye, so we stopped accumulating new buster hosts...
 
+> Thanks to [lelutin](https://lelutin.ca/) for reviewing a draft of this post.
+
 [[!tag draft]]

tweak title
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index 2d79f10e..cd856e53 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -1,4 +1,4 @@
-[[!meta title="A streamlined Debian upgrade process"]]
+[[!meta title="Automating Debian major upgrades"]]
 
 It's major upgrade time again! The [Debian project](https://www.debian.org/) just published
 the [Debian 11 "bullseye"](https://www.debian.org/News/2021/20210814) release, and it's pretty awesome! This

add toc
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index 1c708a7c..2d79f10e 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -19,6 +19,8 @@ and that I forgot, do let me know!
 But that's for the cool new stuff. We need to talk about the problems
 with Debian major upgrades.
 
+[[!toc]]
+
 # Background
 
 I have been maintaining [[detailed upgrade guides|services/upgrades]],

turn this into a broader "how do we upgrade debian" discussion
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index 5747b6cc..1c708a7c 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -1,35 +1,159 @@
-[[!meta title="Debian 11 bullseye upgrade notes"]]
+[[!meta title="A streamlined Debian upgrade process"]]
 
 It's major upgrade time again! The [Debian project](https://www.debian.org/) just published
-the [Debian 11 "bullseye"](https://www.debian.org/News/2021/20210814) release, and it's pretty awesome!
+the [Debian 11 "bullseye"](https://www.debian.org/News/2021/20210814) release, and it's pretty awesome! This
+makes me realized that I have never written here about my [[peculiar
+upgrade process|services/upgrades/bullseye]], and figured it was worth
+bringing that up to a wider audience.
 
-As usual, I have made a [[detailed upgrade
-guide|services/upgrades/bullseye]] which I am not copying here because
-it is still a changing document and, if you follow this blog at all,
-you have probably seen that procedure before.
+The [[upgrade document|services/upgrades/bullseye]] also has a
+[[notable changes|services/upgrades/bullseye#notable-changes]] section
+which includes major version changes (e.g. [Inkscape 1.0](https://librearts.org/2020/05/above-and-beyond-inkscape-1-0/)!), new
+packages (e.g. [podman](https://podman.io/)!) and important behavior changes
+(e.g. [driverless scanning and printing](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html#driverless-operation)!).
 
-I will say that I have a [proposal to automate this](https://wiki.debian.org/AutomatedUpgrade) that I've been
-threatening myself with implementing for a long time now, and if we
-keep releasing at such a cadence, I will probably actually implement.
+I'm particularly interested to hear if I missed any significant
+change. If you know of a cool new package that shipped with bullseye
+and that I forgot, do let me know!
 
-I would also like to especially bring your attention to the [[notable
-changes|services/upgrades/bullseye#notable-changes]] section. I'm
-particularly interested to hear if I miss any significant change. If
-you know of a cool new package that shipped with bullseye, do let me
-know!
+But that's for the cool new stuff. We need to talk about the problems
+with Debian major upgrades.
+
+# Background
+
+I have been maintaining [[detailed upgrade guides|services/upgrades]],
+on my wiki, starting with the [[jessie
+release|services/upgrades/jessie]], but I have actually written such
+guides for [Koumbit.org](https://koumbit.org) as far back as [Debian squeeze](https://wiki.koumbit.net/SqueezeUpgrade) in 2011
+(another worker wrote the older [Debian lenny](https://wiki.koumbit.net/LennyUpgrade) upgrade guide in
+2009).
+
+Over the years, those guides evolved from a quick "cheat-sheet" format
+copied from the [release notes](https://www.debian.org/releases/) into a more or less "scripted" form
+that I currently use.
+
+Each guide has a procedure made of a few steps that can be basically
+copy-pasted to batch-upgrade a host (or multiple hosts in parallel) as
+quickly as possible. 
+
+# How the official procedure fails us
+
+In comparison with my procedure, the [official upgrade guide](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html) is
+mostly designed to upgrade a single machine, typically a workstation,
+with a rather slow and exhaustive process. The [PDF version of the
+upgrade guide](https://www.debian.org/releases/bullseye/amd64/release-notes.en.pdf) is *14 pages long*! This, obviously, does not work
+when you have tens or hundreds of machines to upgrade.
+
+Debian upgrades are notorious for being extremely reliable, but we
+have a *lot* of packages, and there are *always* corner cases where
+the upgrade will just fail because of a bug specific to your
+environment. Those will only fixed after some back and forth in the
+community (and that's assuming users report those bugs, which is not
+always the case). There's no obvious way to deploy "hot fixes" in this
+context, at least not without fixing the package *and* publishing it
+on an unofficial Debian archive while the official ones catch up. This
+is slow and difficult.
+
+Or some packages require manual labor. Examples of this are the
+PostgreSQL or Ganeti packages which require you to upgrade your
+clusters by hand, while the old and new packages live side by
+side. Debian packages bring you far in the upgrade process, but
+sometimes not all the way.
+
+Which means every Debian install needs to be manually upgraded and
+inspected when a new release comes out. That's slow and error prone
+and we can do better.
+
+# A way to automate major upgrades?
+
+I have a [proposal to automate this](https://wiki.debian.org/AutomatedUpgrade). It's been mostly dormant in
+the Debian wiki, for 5 years now. Fundamentally, this is a hard
+problem: Debian gets installed in so many different environments, from
+workstations to physical servers to virtual machines, embedded systems
+and so on, that it's extremely hard to come up with a "one size fits
+all" system.
+
+The (manual) procedure I'm using is mostly targeting servers, but I'm
+also using it on workstations. And I'll note that it's specific to my
+home setup: I have a [different procedure at work](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/bullseye), although it has
+a lot of common code.
+
+To automate this, I would factor out that common code with hooks where
+you could easily inject special code like "you need to upgrade `ferm`
+first", "you need an extra reboot here", or "this is how you finish
+the PostgreSQL upgrade".
+
+With Debian getting closer to a 2 year release cycle, with the
+previous release being supported basically only *one* year after the
+new stable comes out, I feel more and more strongly that this needs
+better automation.
+
+So I'm thinking that I should write a prototype for this. Ubuntu has
+[do-release-upgrade](https://wiki.debian.org/AutomatedUpgrade#Ubuntu.27s_release_upgrades) that is too Ubuntu-specific to be reused. An
+[attempt at collaborating on this](https://answers.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+question/402913) has been mostly met with silence
+from Ubuntu's side as well.
+
+I'm thinking that using something like [Fabric](https://www.fabfile.org/), [Mitogen](https://github.com/mitogen-hq/mitogen/), or
+[Transilience](https://github.com/spanezz/transilience/): anything that will allow me to write simple,
+portable Python code that can run transparently on a local machine
+(for single systems upgrades, possibly with a GUI frontend) to remote
+servers (for large clusters of servers, maybe with canaries and
+grouping using [Cumin](https://doc.wikimedia.org/cumin/master/introduction.html)). I'll note that Koumbit started
+experimenting with [Puppet Bolt](https://puppet.com/docs/bolt/latest/bolt.html) in the bullseye upgrade process,
+but that feels too site-specific to be useful more broadly.
+
+# Is it worth it? Would it work for you?
+
+I am not sure where this stands in the [XKCD time trade-off](https://xkcd.com/1205/)
+evaluation, because the table doesn't actually cover the time
+frequency of Debian release (which is basically "biennal") and the
+amount of time the upgrade would take across a cluster (which varies a
+lot, but that I estimate to be between one to 6 hours per machine).
+
+Assuming I have 80 machines to upgrade, that is 80 to 480 hours
+(between ~3 to 20 days) of work! It's unclear how much work such an
+automated system would shave off, however. Assuming things are an
+order of magnitude faster (say I upgrade 10 machines at a time), I
+would shave off between 3 and 18 days of work, which implies I might
+allow myself to spend a minimum of 5 days working on such a
+project.
+
+I'm curious to hear what people think of the idea. It strikes me as
+really odd that no one has really tackled that problem yet,
+considering how many clusters of Debian machines are out there. Surely
+people are upgrading those, and not following that slow step by step
+guide, right?
+
+I suspect everyone is doing the same thing: we all have our little
+copy-paste script we batch onto multiple machines, sometimes in
+parallel. That is what the [Debian.org sysadmins are doing](https://dsa.debian.org/howto/upgrade-to-bullseye/) as well.
+
+There must be a better way. What is yours?
+
+(And before people mention those: I am aware of containers,
+Kubernetes, and other deployment mechanisms. Those are, indeed,
+somewhat of a long-term solution, but there are still systems
+underneath those and I currently can't afford to migrate everything
+over to those new systems just yet. Maybe that's the final answer:
+never upgrade. But I still feel there needs to be an intermediate
+solution.)
+
+# Upgrade progress
 
 I'm 2/3 machines upgraded so far, only my server is left, and that's
 just because I haven't found the time. Upgrades have been pretty
 painless so far, much better than the [[previous buster
-upgrade|services/upgrades/buster]].
+upgrade|services/upgrades/buster]]. Obviously, for me personal use,
+automating this is pointless.
 
-Work-side, however, is another story: we have over 80 boxes to upgrade
-there and that will take a while. The last stretch to buster cycle
-took about two years to complete, so we might be done by the time the
-next release (12, "bookworm") is released. At least I fixed the
-installers so that new the machines we create all ship with
-bullseye...
+Work-side, however, is [another story](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/bullseye): we have over 80 boxes to
+upgrade there and that will take a while. The last [stretch to buster
+cycle](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/buster#per-host-progress) took about two years to complete, so we might be done by the
+time the next release (12, "bookworm") is released, but that's
+actually a full *year* after "buster" becomes EOL, so it's actually
+too late...
 
-Enjoy the new Debian release!
+At least I fixed the installers so that new the machines we create all
+ship with bullseye, so we stopped accumulating new buster hosts...
 
 [[!tag draft]]

expand on the upgrade process
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
index 02dac341..5747b6cc 100644
--- a/blog/2021-09-05-bullseye-upgrade-notes.mdwn
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -23,6 +23,13 @@ just because I haven't found the time. Upgrades have been pretty
 painless so far, much better than the [[previous buster
 upgrade|services/upgrades/buster]].
 
+Work-side, however, is another story: we have over 80 boxes to upgrade
+there and that will take a while. The last stretch to buster cycle
+took about two years to complete, so we might be done by the time the
+next release (12, "bookworm") is released. At least I fixed the
+installers so that new the machines we create all ship with
+bullseye...
+
 Enjoy the new Debian release!
 
 [[!tag draft]]

make a draft blog post about the release
diff --git a/blog/2021-09-05-bullseye-upgrade-notes.mdwn b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
new file mode 100644
index 00000000..02dac341
--- /dev/null
+++ b/blog/2021-09-05-bullseye-upgrade-notes.mdwn
@@ -0,0 +1,28 @@
+[[!meta title="Debian 11 bullseye upgrade notes"]]
+
+It's major upgrade time again! The [Debian project](https://www.debian.org/) just published
+the [Debian 11 "bullseye"](https://www.debian.org/News/2021/20210814) release, and it's pretty awesome!
+
+As usual, I have made a [[detailed upgrade
+guide|services/upgrades/bullseye]] which I am not copying here because
+it is still a changing document and, if you follow this blog at all,
+you have probably seen that procedure before.
+
+I will say that I have a [proposal to automate this](https://wiki.debian.org/AutomatedUpgrade) that I've been
+threatening myself with implementing for a long time now, and if we
+keep releasing at such a cadence, I will probably actually implement.
+
+I would also like to especially bring your attention to the [[notable
+changes|services/upgrades/bullseye#notable-changes]] section. I'm
+particularly interested to hear if I miss any significant change. If
+you know of a cool new package that shipped with bullseye, do let me
+know!
+
+I'm 2/3 machines upgraded so far, only my server is left, and that's
+just because I haven't found the time. Upgrades have been pretty
+painless so far, much better than the [[previous buster
+upgrade|services/upgrades/buster]].
+
+Enjoy the new Debian release!
+
+[[!tag draft]]

release was done, those are not WIP
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 9cff7e3f..ba7e47a6 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -656,8 +656,8 @@ be a problem in some cases.
 
 # References
 
- * [Official guide](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html) (WIP)
- * [Release notes](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html) (WIP)
+ * [Official guide](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html)
+ * [Release notes](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html)
  * [Koumbit guide](https://wiki.koumbit.net/BullseyeUpgrade) (WIP,
    reviewed 2021-08-26)
  * [DSA guide](https://dsa.debian.org/howto/upgrade-to-bullseye/)

link to the debian wiki
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index fbd386ba..9cff7e3f 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -166,6 +166,8 @@ mikas](https://michael-prokop.at/blog/2021/05/27/what-to-expect-from-debian-bull
  * Ganeti has a major upgrade! there were concerns about the upgrade
    path, not sure how that turned out
 
+See also the [wiki page about bullseye](https://wiki.debian.org/NewInBullseye) for another list.
+
 ## New packages
 
 This is a curated list of packages that were introduced in

clarify the security changes
It's not the *label* that changed, apparently: that was and still is
`Debian-security`. The *codename* is different in the security archive now.
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index fb8530e0..fbd386ba 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -297,8 +297,10 @@ In `buster`, it was:
 
     deb https://deb.debian.org/debian-security buster/updates main contrib
 
-Also note that the *label* of the updates changed, this time, from
-`buster-updates` to `bullseye-security`.
+Also note that the *codename* of the security changed, this time, from
+`buster` to `bullseye-security`. This affects you only if you have an
+APT configuration which involves pinning the `APT::Default-Release`
+manually.
 
 I can't find any other recent changes in my notes, but I could have
 sworn it's not the first time a change like this happens. If someone

fix typo, thanks tianon
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 6d68a598..fb8530e0 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -229,7 +229,7 @@ This table summarizes package version changes I find interesting.
 | Firefox     | 68     | 78       | 78 was already in buster-updates                                                                                        |
 | Ganeti      | 2.16.0 | 3.0.1    | breaking upgrade?                                                                                                       |
 | GNOME       | 3.30   | 3.38     | Missed the "GNOME 40" release                                                                                           |
-| Inkscap     | 0.92   | 1.0      | Finally, 1.0!                                                                                                           |
+| Inkscape    | 0.92   | 1.0      | Finally, 1.0!                                                                                                           |
 | Libreoffice | 6.2    | 7.0      |                                                                                                                         |
 | OpenSSH     | 7.9    | 8.4      | [FIDO/U2F, Include][8.2], [signatures][8.1], [quantum-resistant key exchange, key fingerprint as confirmation][8.0]     |
 | Postgresql  | 11     | 13       |                                                                                                                         |

explain the section
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index fe696b57..6d68a598 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -168,6 +168,11 @@ mikas](https://michael-prokop.at/blog/2021/05/27/what-to-expect-from-debian-bull
 
 ## New packages
 
+This is a curated list of packages that were introduced in
+bullseye. There are actually *thousands* of new packages in the new
+Debian release, but this is a small selection of projects I found
+particularly interesting:
+
  * [age](https://github.com/FiloSottile/age), alternative encryption tool
  * [bpfmon](https://tracker.debian.org/pkg/bpfmon), BPF-based packet visualizer
  * [bpytop](https://github.com/aristocratos/bpytop), awesome looking system monitor, python rewrite of bashtop

more details
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 342e414d..fe696b57 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -171,13 +171,13 @@ mikas](https://michael-prokop.at/blog/2021/05/27/what-to-expect-from-debian-bull
  * [age](https://github.com/FiloSottile/age), alternative encryption tool
  * [bpfmon](https://tracker.debian.org/pkg/bpfmon), BPF-based packet visualizer
  * [bpytop](https://github.com/aristocratos/bpytop), awesome looking system monitor, python rewrite of bashtop
- * [crowdsec](https://github.com/crowdsecurity/crowdsec), lightweight and collaborative security engine, think
-   of a collaborative denyhosts
+ * [crowdsec](https://github.com/crowdsecurity/crowdsec), "lightweight and collaborative security engine", think
+   of a collaborative [fail2ban](https://www.fail2ban.org/)
  * [dnf](https://tracker.debian.org/pkg/dnf), the RedHat package manager
  * [doas](https://tracker.debian.org/pkg/doas), OpenBSD's sudo replacement
  * [foot](https://codeberg.org/dnkl/foot), fast, lightweight and minimalistic Wayland terminal emulator
- * [gammastep](https://gitlab.com/chinstrap/gammastep), redshift replacement for Wayland
- * [gdu](https://tracker.debian.org/pkg/gdu), disk usage analyzer, golang rewrite of ncdu, presumably faster
+ * [gammastep](https://gitlab.com/chinstrap/gammastep), [redshift](http://jonls.dk/redshift/) replacement for Wayland
+ * [gdu](https://tracker.debian.org/pkg/gdu), disk usage analyzer, golang rewrite of [ncdu](https://dev.yorhel.nl/ncdu), presumably faster
  * [guix](https://tracker.debian.org/pkg/guix), declarative package manager
  * [jamulus](https://github.com/martinrotter/rssguard), "real-time collaborative music session client and server"
  * [laminar](https://laminar.ohwg.net), simple CI
@@ -186,7 +186,7 @@ mikas](https://michael-prokop.at/blog/2021/05/27/what-to-expect-from-debian-bull
    already in buster, but actually usable now
  * [plocate](https://plocate.sesse.net/), mlocate rewrite, much faster, will be default in bookworm
  * [podman](https://tracker.debian.org/pkg/libpod), a Docker replacement
- * [rssguard](https://github.com/martinrotter/rssguard), nice looking feedreader
+ * [rssguard](https://github.com/martinrotter/rssguard), nice looking feed reader
  * [sayonara](https://sayonara-player.com/), nice looking music player
  * [sbuild-qemu](https://tracker.debian.org/sbuild-qemu), a qemu-backed sbuild Debian package builder
  * [sequoia](https://sequoia-pgp.org/), Rust OpenPGP implementation, ships with `sq` and

consistency
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 80b5b2f9..342e414d 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -177,7 +177,7 @@ mikas](https://michael-prokop.at/blog/2021/05/27/what-to-expect-from-debian-bull
  * [doas](https://tracker.debian.org/pkg/doas), OpenBSD's sudo replacement
  * [foot](https://codeberg.org/dnkl/foot), fast, lightweight and minimalistic Wayland terminal emulator
  * [gammastep](https://gitlab.com/chinstrap/gammastep), redshift replacement for Wayland
- * [gdu](https://tracker.debian.org/pkg/gdu), golang rewrite of ncdu, presumably faster
+ * [gdu](https://tracker.debian.org/pkg/gdu), disk usage analyzer, golang rewrite of ncdu, presumably faster
  * [guix](https://tracker.debian.org/pkg/guix), declarative package manager
  * [jamulus](https://github.com/martinrotter/rssguard), "real-time collaborative music session client and server"
  * [laminar](https://laminar.ohwg.net), simple CI
@@ -186,7 +186,7 @@ mikas](https://michael-prokop.at/blog/2021/05/27/what-to-expect-from-debian-bull
    already in buster, but actually usable now
  * [plocate](https://plocate.sesse.net/), mlocate rewrite, much faster, will be default in bookworm
  * [podman](https://tracker.debian.org/pkg/libpod), a Docker replacement
- * [rssguard](https://github.com/martinrotter/rssguard), nice-looking feedreader
+ * [rssguard](https://github.com/martinrotter/rssguard), nice looking feedreader
  * [sayonara](https://sayonara-player.com/), nice looking music player
  * [sbuild-qemu](https://tracker.debian.org/sbuild-qemu), a qemu-backed sbuild Debian package builder
  * [sequoia](https://sequoia-pgp.org/), Rust OpenPGP implementation, ships with `sq` and

more bullseye new packages
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index e2891b68..80b5b2f9 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -168,8 +168,31 @@ mikas](https://michael-prokop.at/blog/2021/05/27/what-to-expect-from-debian-bull
 
 ## New packages
 
- * the Wayland rewrite of [i3](https://i3wm.org/), [sway](http://swaywm.org/)
+ * [age](https://github.com/FiloSottile/age), alternative encryption tool
+ * [bpfmon](https://tracker.debian.org/pkg/bpfmon), BPF-based packet visualizer
+ * [bpytop](https://github.com/aristocratos/bpytop), awesome looking system monitor, python rewrite of bashtop
+ * [crowdsec](https://github.com/crowdsecurity/crowdsec), lightweight and collaborative security engine, think
+   of a collaborative denyhosts
+ * [dnf](https://tracker.debian.org/pkg/dnf), the RedHat package manager
+ * [doas](https://tracker.debian.org/pkg/doas), OpenBSD's sudo replacement
+ * [foot](https://codeberg.org/dnkl/foot), fast, lightweight and minimalistic Wayland terminal emulator
+ * [gammastep](https://gitlab.com/chinstrap/gammastep), redshift replacement for Wayland
+ * [gdu](https://tracker.debian.org/pkg/gdu), golang rewrite of ncdu, presumably faster
+ * [guix](https://tracker.debian.org/pkg/guix), declarative package manager
+ * [jamulus](https://github.com/martinrotter/rssguard), "real-time collaborative music session client and server"
+ * [laminar](https://laminar.ohwg.net), simple CI
+ * [lowdown](https://kristaps.bsd.lv/lowdown/), Markdown translator (to HTML, man, LaTeX, etc)
+ * [pipewire](https://pipewire.org/), Pulseaudio and Jack replacement, video multiplexer,
+   already in buster, but actually usable now
+ * [plocate](https://plocate.sesse.net/), mlocate rewrite, much faster, will be default in bookworm
  * [podman](https://tracker.debian.org/pkg/libpod), a Docker replacement
+ * [rssguard](https://github.com/martinrotter/rssguard), nice-looking feedreader
+ * [sayonara](https://sayonara-player.com/), nice looking music player
+ * [sbuild-qemu](https://tracker.debian.org/sbuild-qemu), a qemu-backed sbuild Debian package builder
+ * [sequoia](https://sequoia-pgp.org/), Rust OpenPGP implementation, ships with `sq` and
+   `sq-keyring-linter` in bullseye!
+ * [sway](http://swaywm.org/), Wayland rewrite of the [i3](https://i3wm.org/) window manager
+ * [vorta](https://vorta.borgbase.com), GUI frontend to the Borg backup tool
 
 ## My packages
 

two quotes from harvest
diff --git a/fortunes.txt b/fortunes.txt
index 2a51aae2..a71b1a81 100644
--- a/fortunes.txt
+++ b/fortunes.txt
@@ -1171,3 +1171,13 @@ Imaginative fiction trains people to be aware that there *are* other
 ways to do things and other ways to be, that there is not just one
 civilization and it is good and it is the way we have to be.
                         - Ursula K. Le Guin
+%
+Science knows still practically nothing about the real nature of
+matter, energy, dimension, or time; and even less about those
+remarkable things called life and thought. But whatever the meaning
+and purpose of this universe, you are a legitimate part of it.
+                        - Gene Roddenberry
+%
+Time is a created thing. To say, "I don't have time" is like saying,
+"I don't want to."
+                        - Lao Tzu

mark sync dates for other guides
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 14b38f81..e2891b68 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -626,9 +626,11 @@ be a problem in some cases.
 
  * [Official guide](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html) (WIP)
  * [Release notes](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html) (WIP)
- * [Koumbit guide](https://wiki.koumbit.net/BullseyeUpgrade) (N/A yet)
- * [DSA guide](https://dsa.debian.org/howto/upgrade-to-bullseye/) (WIP, reviewed)
- * [TPA guide][] (N/A yet)
+ * [Koumbit guide](https://wiki.koumbit.net/BullseyeUpgrade) (WIP,
+   reviewed 2021-08-26)
+ * [DSA guide](https://dsa.debian.org/howto/upgrade-to-bullseye/)
+   (WIP, reviewed 2021-08-26)
+ * [TPA guide][] (WIP, last sync 2021-08-26)
  * [Solution proposal to automate this](https://wiki.debian.org/AutomatedUpgrade)
 
 [TPA guide]: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/upgrades/bullseye

sync with TPA procedure
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index fd9cfccb..14b38f81 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -60,7 +60,7 @@ connection.
         apt-mark showhold &&
         dpkg --audit &&
         : look for dkms packages and make sure they are relevant, if not, purge. &&
-        dpkg -l '*dkms' || true &&
+        ( dpkg -l '*dkms' || true ) &&
         : look for leftover config files &&
         find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error' &&
         : run backups &&

notice sources.list security change
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 1f07dab8..fd9cfccb 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -250,6 +250,33 @@ list.
 
 See also the [noteworthy obsolete packages](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#noteworthy-obsolete-packages) list.
 
+## Security updates URL changes
+
+So you might have noticed this little line in the upgrade procedure:
+
+    sed -i 's#buster/updates#bullseye-security#' /etc/apt/sources.list $(ls /etc/apt/sources.list.d/*) &&
+
+This is a [known issue](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive) in this release, it's because the security
+`sources.list` is now:
+
+    deb https://deb.debian.org/debian-security bullseye-security main contrib
+
+In `buster`, it was:
+
+    deb http://security.debian.org/ buster/updates main contrib non-free
+
+... although this presumably worked already as well:
+
+    deb https://deb.debian.org/debian-security buster/updates main contrib
+
+Also note that the *label* of the updates changed, this time, from
+`buster-updates` to `bullseye-security`.
+
+I can't find any other recent changes in my notes, but I could have
+sworn it's not the first time a change like this happens. If someone
+remember what it was *before* that, I would be grateful if I could
+update that list!
+
 # Issues
 
 See also the official list of [known issues](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html).

sort
diff --git a/software.mdwn b/software.mdwn
index fa3846a3..aa19824a 100644
--- a/software.mdwn
+++ b/software.mdwn
@@ -21,16 +21,6 @@ J'ai écrit un lecteur de fils RSS nommé [feed2exec](https://gitlab.com/anarcat
 connecter des fils RSS avec n'importe quoi: courriels, Twitter,
 Mastodon, téléchargements, etc.
 
-Wallabako
----------
-
-J'utilise [Wallabag](http://wallabag.org/) pour répertorier des
-articles à lire plus tard. Pour éviter d'avoir à les lire sur un
-ordinateur, j'ai écrit un programme embarqué nommé [Wallabako][] pour
-les transférer sur ma liseuse électronique.
-
-[Wallabako]: https://gitlab.com/anarcat/wallabako
-
 pubpaste
 --------
 
@@ -44,7 +34,7 @@ rsendmail and sshsendmail
 [rsendmail](https://gitlab.com/anarcat/rsendmail) permet de gérer l'envoi de courriels par SSH, sans mot
 de passe, à partir d'ordinateurs distants (par exemple un laptop).
 
-Stressant
+stressant
 ---------
 
 J'ai écrit un logiciel pour faire le [Burn-in][] de nouvelles
@@ -62,6 +52,16 @@ undertime
 time across multiple timezones for conference calls or other
 coordinated events".
 
+wallabako
+---------
+
+J'utilise [Wallabag](http://wallabag.org/) pour répertorier des
+articles à lire plus tard. Pour éviter d'avoir à les lire sur un
+ordinateur, j'ai écrit un programme embarqué nommé [Wallabako][] pour
+les transférer sur ma liseuse électronique.
+
+[Wallabako]: https://gitlab.com/anarcat/wallabako
+
 Autres contributions
 ================
 

spelloing
diff --git a/software.mdwn b/software.mdwn
index 7dbcf73f..fa3846a3 100644
--- a/software.mdwn
+++ b/software.mdwn
@@ -14,7 +14,7 @@ J'ai écrit un manuel
 [[d'entretien de packages debian|debian-development]] (en anglais)
 parce qu'il semblait qu'il n'y avait rien de complet à ce niveau...
 
-Feed2exec
+feed2exec
 ---------
 
 J'ai écrit un lecteur de fils RSS nommé [feed2exec](https://gitlab.com/anarcat/feed2exec) afin de
@@ -24,7 +24,7 @@ Mastodon, téléchargements, etc.
 Wallabako
 ---------
 
-J'utilises [Wallabag](http://wallabag.org/) pour répertorier des
+J'utilise [Wallabag](http://wallabag.org/) pour répertorier des
 articles à lire plus tard. Pour éviter d'avoir à les lire sur un
 ordinateur, j'ai écrit un programme embarqué nommé [Wallabako][] pour
 les transférer sur ma liseuse électronique.

add two more programs, deprecate monkeysphere, freedombox
diff --git a/software.mdwn b/software.mdwn
index b289dd7b..7dbcf73f 100644
--- a/software.mdwn
+++ b/software.mdwn
@@ -14,11 +14,6 @@ J'ai écrit un manuel
 [[d'entretien de packages debian|debian-development]] (en anglais)
 parce qu'il semblait qu'il n'y avait rien de complet à ce niveau...
 
-Monkeysphere
-------------
-
-Je suis impliqué dans le projet [Monkeysphere](http://monkeysphere.info/) qui vise à rendre la cryptographie OpenPGP plus accessible au commun des mortels. En particulier, j'ai écrit un logiciel nommé [Monkeysign](http://monkeysphere.info/monkeysign) qui permet de facilement signer des clefs PGP. J'ai écrit aussi un [guide simple pour l'utilisation de Monkeysphere](http://web.monkeysphere.info/getting-started-ssh/).
-
 Feed2exec
 ---------
 
@@ -36,6 +31,19 @@ les transférer sur ma liseuse électronique.
 
 [Wallabako]: https://gitlab.com/anarcat/wallabako
 
+pubpaste
+--------
+
+[pubpaste](https://gitlab.com/anarcat/pubpaste) permet de facilement publier des captures d'écran, du
+texte, des images, des galeries de photos, avec un simple serveur web
+et un accès SSH.
+
+rsendmail and sshsendmail
+-------------------------
+
+[rsendmail](https://gitlab.com/anarcat/rsendmail) permet de gérer l'envoi de courriels par SSH, sans mot
+de passe, à partir d'ordinateurs distants (par exemple un laptop).
+
 Stressant
 ---------
 
@@ -47,12 +55,12 @@ dérivé de [Debian][].
 [stressant]: https://gitlab.com/anarcat/stressant
 [Burn-in]: https://en.wikipedia.org/wiki/Burn-in
 
-Freedom Box
------------
-
-Je travaille, par l'entremise de Debian, à l'avancement du projet [Freedom Box](http://freedomboxfoundation.org/). J'ai depuis longtemps un serveur "freedombox" chez moi, il s'agit maintenant de partager comment on fabriquer un avec tout le monde, et faire que c'est facile à gérer et utiliser. Voir aussi [[services]].
+undertime
+---------
 
-> _We're building software for smart devices whose engineered purpose is to work together to facilitate free communication among people, safely and securely, beyond the ambition of the strongest power to penetrate. They can make freedom of thought and information a permanent, ineradicable feature of the net that holds our souls._ - [Eben Moglen](http://moglen.law.columbia.edu/)
+[undertime](https://gitlab.com/anarcat/undertime) permet de (pardonnez l'anglais) "quickly pick a meeting
+time across multiple timezones for conference calls or other
+coordinated events".
 
 Autres contributions
 ================
@@ -84,3 +92,26 @@ Mon histoire
 ============
 
 La maintenance de mon [[desktop]] est quelquechose qui a toujours pris un certain temps, et qui témoigne mon enthousiasme pour les logiciels libres. J'ai pris un peu de temps pour documenter dans ma page [[software/history]] les différentes configurations que j'utilise, les tests que j'ai fait et les languages que j'ai appris.
+
+Projets désuets
+===============
+
+Monkeysphere
+------------
+
+Le projet [Monkeysphere](http://monkeysphere.info/) visait à rendre la cryptographie OpenPGP plus accessible au commun des mortels. En particulier, j'ai écrit un logiciel nommé [Monkeysign](http://monkeysphere.info/monkeysign) qui permet de facilement signer des clefs PGP. J'ai écrit aussi un [guide simple pour l'utilisation de Monkeysphere](http://web.monkeysphere.info/getting-started-ssh/).
+
+Le projet Monkeysign est [abandonné](https://0xacab.org/monkeysphere/monkeysign/-/issues/64) depuis 2018, en faveur
+d'alternatives telles que [GNOME Keysign](https://wiki.gnome.org/Apps/Keysign), [pius](https://www.phildev.net/pius/) ou [caff](https://tracker.debian.org/pkg/signing-party).
+
+Freedom Box
+-----------
+
+J'ai travaillé, par l'entremise de Debian, à l'avancement du projet
+[Freedom Box](http://freedomboxfoundation.org/). J'ai depuis longtemps un serveur "freedombox" chez
+moi, il s'agit maintenant de partager comment on fabriquer un avec
+tout le monde, et faire que c'est facile à gérer et utiliser. Voir
+aussi [[services]].
+
+> _We're building software for smart devices whose engineered purpose is to work together to facilitate free communication among people, safely and securely, beyond the ambition of the strongest power to penetrate. They can make freedom of thought and information a permanent, ineradicable feature of the net that holds our souls._ - [Eben Moglen](http://moglen.law.columbia.edu/)
+
diff --git a/software/contributions.mdwn b/software/contributions.mdwn
index 0b05e63c..7ed9e94c 100644
--- a/software/contributions.mdwn
+++ b/software/contributions.mdwn
@@ -17,15 +17,11 @@ Auteur principal
 
 Actifs:
 
- * [bup-cron](https://github.com/anarcat/bup-cron), a wrapper
-   around [bup](https://bup.github.io/)
  * [[a set of packages to install on debian|packages.yml]], usable as
    an ansible playbook
  * [feed2exec](https://gitlab.com/anarcat/feed2exec)
- * [Gameclock](http://redmine.koumbit.net/projects/gameclock)
- * [irklab](https://gitlab.com/anarcat/irklab/), an IRC gateway for [gitlab.com](http://gitlab.com)
- * [Monkeysign](http://monkeysphere.info/monkeysign), a human-friendly PGP key signing package, along with a
-   GPG library (originally by Jerome Charaoui but mostly rewrote)
+ * [pubpaste](https://gitlab.com/anarcat/pubpaste)
+ * [rsendmail](https://gitlab.com/anarcat/rsendmail)
  * [Stressant](https://gitlab.com/anarcat/stressant) and
    [Torride](https://redmine.koumbit.net/projects/torride/)
  * [Undertime](https://gitlab.com/anarcat/undertime)
@@ -34,9 +30,15 @@ Actifs:
 
 Inactifs:
 
+ * [bup-cron](https://github.com/anarcat/bup-cron), a wrapper
+   around [bup](https://bup.github.io/)
  * [debmans](https://gitlab.com/anarcat/debmans)
  * [PHPTimetracker](http://phptimetracker.sf.net/), which included an ORM for PHP as far back as 2004
  * [decisions](http://drupal.org/project/decisions) (with others)
+ * [Gameclock](http://redmine.koumbit.net/projects/gameclock)
+ * [irklab](https://gitlab.com/anarcat/irklab/), an IRC gateway for [gitlab.com](http://gitlab.com)
+ * [Monkeysign](http://monkeysphere.info/monkeysign), a human-friendly PGP key signing package, along with a
+   GPG library (originally by Jerome Charaoui but mostly rewrote)
  * [worldtools](http://www.freshports.org/sysutils/worldtools)
  * [numerous house-made shell scripts](https://gitlab.com/anarcat/scripts)
  * [bksh](https://gitlab.com/anarcat/bksh): un "backup shell" [rs]sh

more info about keyboard latency
diff --git a/blog/2018-05-04-terminal-emulators-2.mdwn b/blog/2018-05-04-terminal-emulators-2.mdwn
index 2f5a8c63..b140e53a 100644
--- a/blog/2018-05-04-terminal-emulators-2.mdwn
+++ b/blog/2018-05-04-terminal-emulators-2.mdwn
@@ -293,6 +293,32 @@ future.
 [Linux Weekly News]: http://lwn.net/
 
 Update: I have had many comments elsewhere about how latency shouldn't
-matter so much, particularly from keyboard hardware providers. 
+matter so much, particularly from keyboard hardware providers. I
+wasn't actually convinced until I saw [this video](https://www.youtube.com/watch?v=wdgULBpRoXk) from [Ben
+Eater](https://eater.net/) (who has some serious oscilloscope skills). His experiment
+shows that high-speed, high quality USB keyboards shouldn't have to
+worry about this, because they have a 1ms latency -- which is still
+high, but not much higher than the PS/2 latency (0.7ms). Basically,
+the 16ms figure comes from the low-speed USB poll interval; as long as
+your keyboard is high speed, it should be okay.
+
+I checked, and my keyboard is actually high speed:
+
+    aoû 23 16:32:52 angela kernel: usb 1-6.1: new full-speed USB device number 24 using xhci_hcd 
+    aoû 23 16:32:52 angela kernel: usb 1-6.1: New USB device found, idVendor=0c45, idProduct=7692, bcdDevice= 3.0e 
+    aoû 23 16:32:52 angela kernel: usb 1-6.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 
+    aoû 23 16:32:52 angela kernel: usb 1-6.1: Product: USB Keyboard 
+    aoû 23 16:32:52 angela kernel: usb 1-6.1: Manufacturer: SONiX
+
+Interestingly, my *mouse* doesn't run at high speed, so that might
+mean more latency there:
+
+    aoû 23 16:32:53 angela kernel: usb 1-6.2: new low-speed USB device number 25 using xhci_hcd 
+    aoû 23 16:32:53 angela kernel: usb 1-6.2: New USB device found, idVendor=047d, idProduct=1020, bcdDevice= 1.06 
+    aoû 23 16:32:53 angela kernel: usb 1-6.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0 
+    aoû 23 16:32:53 angela kernel: usb 1-6.2: Product: Kensington Expert Mouse
+
+But it seems I would need an oscilloscope (and know how to use it!) to
+debug this. ;)
 
 [[!tag debian-planet lwn geek review terminals performance]]

jamie migrated!
diff --git a/services/wiki/ikiwiki-hugo-conversion.mdwn b/services/wiki/ikiwiki-hugo-conversion.mdwn
index 9bbb2dd4..ca603a66 100644
--- a/services/wiki/ikiwiki-hugo-conversion.mdwn
+++ b/services/wiki/ikiwiki-hugo-conversion.mdwn
@@ -343,6 +343,8 @@ Other ideas:
  * [Simpler conversion](https://blog.jak-linux.org/2018/10/25/migrated-website-from-ikiwiki-to-hugo/)
  * [Previous tests](https://gitlab.com/anarcat/wallabako/issues/13)
  * [Upstream list of converters](https://gohugo.io/tools/migrations/)
+ * [Jamie McClelland migration](https://current.workingdirectory.net/posts/2021/hugo/)
+
 # Other alternatives
 
 Consider alternative SSGs:

fix headings
diff --git a/services/wiki/ikiwiki-hugo-conversion.mdwn b/services/wiki/ikiwiki-hugo-conversion.mdwn
index 0797d461..9bbb2dd4 100644
--- a/services/wiki/ikiwiki-hugo-conversion.mdwn
+++ b/services/wiki/ikiwiki-hugo-conversion.mdwn
@@ -2,8 +2,7 @@
 
 [[!toc levels=3]]
 
-Why
-===
+# Why
 
  * too slow: ikiwiki takes 30 seconds to refresh even when changing a
    single page
@@ -39,8 +38,7 @@ $ git grep -h '\[\[!' | sed 's/\[\[!/\n[[!/g' | grep '\[\[!' | sed 's/ .*//' | s
 
    I had to use the `format` directive to workaround those problems.
 
-First conversion attempt
-========================
+# First conversion attempt
 
 I had to rename all files, and move stuff into `content/`, then things
 started generally working "working" (as in "breaking").
@@ -68,8 +66,7 @@ I also tried:
 Another failure is when it finds an HTML file with an unquoted `href`
 argument (e.g. `hardware/phone/htc-one-s/apps.html`).
 
-Hugo ultra short primer
-=======================
+# Hugo ultra short primer
 
  * `apt install hugo` - available in Debian, also there's a newer
    version in unstable
@@ -79,8 +76,7 @@ Hugo ultra short primer
 
 Maybe the [Emacs mode](https://github.com/masasam/emacs-easy-hugo) could be useful.
 
-Results
-=======
+# Results
 
 Result of running hugo build after the renames:
 
@@ -103,8 +99,7 @@ Things generally look like crap:
  * blog posts are not sorted properly and generally look like crap as
    well
 
-Inventory
-=========
+# Inventory
 
 List of directives used in my wiki:
 
@@ -182,8 +177,7 @@ mostly used in frontpage and blog, need to figure out
 ^ IMPORTANT, need to figure it out
 """]]
 
-Magic links
-------------
+## Magic links
 
 There are also a ton of "magic ikiwiki links", called
 [[ikiwiki/wikilink]], which have their own unique logic:
@@ -230,8 +224,7 @@ The peculiarities of wikilinks in ikiwiki:
      spaces and other funky escape mechanisms - NOT IMPLEMENTED,
      look at IkiWiki::titlepage for those
 
-Tasks
-=====
+# Tasks
 
 the gist of it is we need to implement:
 
@@ -278,8 +271,7 @@ will be converted by hand:
 
 Work is ongoing in this [conversion script](https://gitlab.com/anarcat/scripts/blob/master/ikiwiki2hugo.py).
 
-Comments
---------
+## Comments
 
 Comments are a particular beast that desserves its own section. Here
 are the solutions I found online:
@@ -345,8 +337,7 @@ Other ideas:
    (except with email instead of CGI)
  * [cactus comments](https://cactus.chat/) "federated comment system for the web, based on the Matrix protocol"
 
-Other converters
-================
+# Other converters
 
  * [Drupal 7](https://www.researchut.com/post/drupal-7_to_hugo/)
  * [Simpler conversion](https://blog.jak-linux.org/2018/10/25/migrated-website-from-ikiwiki-to-hugo/)

document sanoid better
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 19756dcb..4b0fc1d6 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -382,7 +382,10 @@ TODO:
         zfs snapshot bpool/BOOT/debian@install
         zfs snapshot rpool/ROOT/debian@install
 
- * [automatic snapshots](https://wiki.archlinux.org/title/ZFS#Automatic_snapshots) (DONE, with sanoid, [puppet](https://gitlab.com/anarcat/puppet/-/blob/main/site-modules/profile/manifests/sanoid.pp), [config](https://gitlab.com/anarcat/puppet/-/blob/main/site-modules/profile/files/sanoid.conf))
+ * [automatic snapshots](https://wiki.archlinux.org/title/ZFS#Automatic_snapshots) (DONE, with [sanoid](https://github.com/jimsalterjrs/sanoid), see the [Puppet
+   code](https://gitlab.com/anarcat/puppet/-/blob/main/site-modules/profile/manifests/sanoid.pp) and [configuration file](https://gitlab.com/anarcat/puppet/-/blob/main/site-modules/profile/files/sanoid.conf) - also considered
+   [zfs-auto-snapshot](https://github.com/zfsonlinux/zfs-auto-snapshot/), which is also packaged in Debian, not sure
+   why I picked sanoid, but it works well)
  * setup services:
    * radio (DONE)
    * sonic

approve comment
diff --git a/hardware/tablet/kobo-clara-hd/comment_1_55c0204d1afac43c6dad402a19419fe7._comment b/hardware/tablet/kobo-clara-hd/comment_1_55c0204d1afac43c6dad402a19419fe7._comment
new file mode 100644
index 00000000..96daedb5
--- /dev/null
+++ b/hardware/tablet/kobo-clara-hd/comment_1_55c0204d1afac43c6dad402a19419fe7._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ ip="45.162.228.187"
+ claimedauthor="joseph channel"
+ subject="Nickel menu working"
+ date="2021-08-15T00:08:30Z"
+ content="""
+Hello there. I arrived here from the mobileread forum thread.
+
+I've managed to get the nickelmenu options working with a script similar to what was posted in [the thread](https://www.mobileread.com/forums/showpost.php?p=3243942&postcount=20)
+
+Here is what I have:
+
+1. Syncthing binary is at `/mnt/onboard/.adds/syncthing/`
+
+2. Start script: `/mnt/onboard/.adds/start_syncthing.sh`
+
+        #!/bin/sh
+        rm /mnt/onboard/syncthing.log
+        ifconfig lo | grep -q addr:127.0.0.1 || ifconfig lo 127.0.0.1
+        /mnt/onboard/.adds/syncthing -no-browser -home=/root/.syncthing -logfile=/mnt/onboard/syncthing.log &>/dev/null &
+
+3. Stop script: `/mnt/onboard/.adds/stop_syncthing.sh`
+
+        #!/bin/sh
+        killall -15 syncthing
+
+4. Nickel menu config: `/mnt/onboard/.adds/nm/syncthing`
+
+        menu_item:main:start syncthing:cmd_spawn:quiet:exec /mnt/onboard/.adds/start_syncthing.sh
+        menu_item:main:stop syncthing:cmd_spawn:quiet:exec /mnt/onboard/.adds/stop_syncthing.sh
+
+I just copied the same script used for koreader and changed the shell scripts at the end. By the way, you need to add `-gui-address` to the startup command if you want to access the web interface on you PC.
+
+Since I just use koreader all the time, the Nickel menu item isn't useful to me, but it may help someone here.
+"""]]

notes about upgrades over SSH
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index bb836740..1f07dab8 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -37,6 +37,11 @@ upgrade process (without it, configuration file changes stop the
 upgrade at more or less random times). Then those changes get applied
 after a reboot. And yes, that's even more dangerous.
 
+IMPORTANT: if you are doing this procedure over SSH (I had the
+privilege of having a console), you may want to [upgrade SSH first](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#ssh-not-available)
+as it has a longer downtime period, especially if you are on a flaky
+connection.
+
  1. Preparation:
 
         : reset to the default locale

approve comment
diff --git a/blog/2021-05-24-leaving-freenode/comment_1_790a1502ad46d06067484f84af21ee1d._comment b/blog/2021-05-24-leaving-freenode/comment_1_790a1502ad46d06067484f84af21ee1d._comment
new file mode 100644
index 00000000..45c56d31
--- /dev/null
+++ b/blog/2021-05-24-leaving-freenode/comment_1_790a1502ad46d06067484f84af21ee1d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ ip="77.140.115.9"
+ subject="comment 8"
+ date="2021-08-06T13:10:10Z"
+ content="""
+> if you like XML
+
+one of the most irrelevant things to mention lol
+Being on IRC, Matrix, XMPP and other libre/open source messaging tools it's depressing that part of the discussions about the strength and weakness of them are still like this.
+
+Anyway, thanks a lot for this post. Well documented resources are important to build a reliable opinion about what is going on. I was a lot worried to have everything wrong due to a party being good at misinformation. Thanks to the current so-called freenode staff to takeover channels. It would be hard to make that up from various project victims of this.
+"""]]

advice from taggart
diff --git a/hardware/tablet/kobo-clara-hd.md b/hardware/tablet/kobo-clara-hd.md
index 13ede6d9..48029940 100644
--- a/hardware/tablet/kobo-clara-hd.md
+++ b/hardware/tablet/kobo-clara-hd.md
@@ -91,6 +91,10 @@ SSH:
  3. unmount USB
  4. enable SSH in koreader (Gear -> Network -> SSH -> start SSH)
 
+Note that ed25519 keys do *not* work: try an RSA key. This might be
+because koreader ships with dropbear (or an older version), but I
+haven't verified this.
+
 ## Install syncthing
 
 I use [Syncthing](https://syncthing.net/) to copy all my books into the device now. I was
@@ -112,23 +116,25 @@ Here is how I installed and started Syncthing at first:
  1. [Download the latest version for ARM](https://syncthing.net/downloads/)
  2. extract the archive
  3. copy the `syncthing` binary into `.../KOBOeReader/.adds/`
- 4. login over SSH (see above, sorry)
+ 4. login over SSH (see above on how to enable) with `-p 2222 -l root`
  5. create the following directory: `~/.config/syncthing/`
- 6. create the following configuration file:
+ 6. create the following configuration file, named `config.xml`:
 
         <configuration version="18">
             <gui enabled="true" tls="false" debugging="false">
                 <address>0.0.0.0:8384</address>
             </gui>
         </configuration>
- 7. copy a valid `ca-certificates.crt` file into `/etc/ssl/certs/` on
-    the Kobo (otherwise syncthing cannot bootstrap discovery servers)
+ 7. copy a valid `ca-certificates.crt` file (say from your Linux
+    desktop) into `/etc/ssl/certs/` on the Kobo (otherwise syncthing
+    cannot bootstrap discovery servers)
  8. launch syncthing over SSH: `/mnt/onboard/.adds/syncthing`
 
 You should now be able to connect to the syncthing GUI through your
 web browser.
 
-Immediately change the admin password.
+Immediately change the GUI admin user and password on the
+`Settings: GUI` tab.
 
 Then, figure out how to start it. Here are your options:
 
diff --git a/hardware/tablet/kobo-clara-hd/comment_2_93ae3ec84e03327733b79e1b687420a9._comment b/hardware/tablet/kobo-clara-hd/comment_2_93ae3ec84e03327733b79e1b687420a9._comment
new file mode 100644
index 00000000..d018ffbe
--- /dev/null
+++ b/hardware/tablet/kobo-clara-hd/comment_2_93ae3ec84e03327733b79e1b687420a9._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""answers"""
+ date="2021-07-27T19:41:00Z"
+ content="""
+Thanks for the corrections! I tried to add them to the post.
+
+You're right that the syncthing shares setup itself could use some help. I share all of `/mnt/onboard` and use the following `.stignore`:
+
+    .git
+    .adds
+    .adobe-digital-editions
+    .kobo-images
+    .kobo
+
+I also have that in a `stignore` file instead of `.stignore` and put `#include stignore` in the `.stignore` itself, as syncthing ignores the `.stignore` file, which I find annoying.
+"""]]

approve comment
diff --git a/hardware/tablet/kobo-clara-hd/comment_1_cf7661c6f9339362a35c43467b67eafd._comment b/hardware/tablet/kobo-clara-hd/comment_1_cf7661c6f9339362a35c43467b67eafd._comment
new file mode 100644
index 00000000..f91d6fc8
--- /dev/null
+++ b/hardware/tablet/kobo-clara-hd/comment_1_cf7661c6f9339362a35c43467b67eafd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ ip="97.113.90.155"
+ claimedauthor="taggart"
+ subject="thanks for howto! and suggestions"
+ date="2021-07-27T19:18:39Z"
+ content="""
+Thanks a lot for this writeup! I was able to get this all working. Here are some comments of things you might adjust:
+
+- for SSH using an ed25519 key didn't work, but rsa did. I guess a dropbear restriction?
+- on syncthing step 5/6 the file should be named config.xml in that dir
+- step 7 maybe suggest grabbing the ca-certificates.crt from their linux desktop system and scp'ing it over
+- on step 4 maybe include the ssh command with the \"-p 2222 -l root\" to be more clear
+- for syncthing GUI change \"change the admin password\" to \"change the GUI admin user and password on the Settings->GUI tab\"
+- maybe some hints on how to setup syncthing(or a link) would be helpful. Also do you recommend having syncthing sync /mnt/onboard directly or another dir?
+
+"""]]

sarcasm is my sig
diff --git a/hardware/tablet/kobo-clara-hd.md b/hardware/tablet/kobo-clara-hd.md
index 65727e36..13ede6d9 100644
--- a/hardware/tablet/kobo-clara-hd.md
+++ b/hardware/tablet/kobo-clara-hd.md
@@ -192,4 +192,6 @@ decided *not* to do here because my time is precious:
    that, and yes, it was pretty bad and almost useless)
  * [SSH support][]: builtin to koreader
 
+Now maybe I'll have time to actually read a book...
+
 [[!tag blog hardware python-planet debian-planet kobo syncthing]]

typo
diff --git a/hardware/tablet/kobo-clara-hd.md b/hardware/tablet/kobo-clara-hd.md
index 2a0db8a6..65727e36 100644
--- a/hardware/tablet/kobo-clara-hd.md
+++ b/hardware/tablet/kobo-clara-hd.md
@@ -179,7 +179,7 @@ action. In either case, syncthing doesn't actually start.
 ## Avoided tasks
 
 This list wouldn't be complete without listing more explicitly the
-stuff I have done before on the Kobo and which I have deliberately
+stuff I have done before on the Kobo Glo HD and which I have deliberately
 decided *not* to do here because my time is precious:
 
  * [plato](https://www.mobileread.com/forums/showthread.php?t=292914) install: beautiful project, but koreader is good enough

fix toc
diff --git a/hardware/tablet/kobo-clara-hd.md b/hardware/tablet/kobo-clara-hd.md
index 185586a0..2a0db8a6 100644
--- a/hardware/tablet/kobo-clara-hd.md
+++ b/hardware/tablet/kobo-clara-hd.md
@@ -4,7 +4,7 @@ I just got a new [Kobo](https://www.kobo.com/) ebook reader, a [Kobo Clara HD](h
 pretty similar to the Glo HD I had but which has unfortunately [died
 after 5 years](https://www.mobileread.com/forums/showthread.php?t=340012_), even after [trying to replace the battery](https://www.ifixit.com/Guide/Kobo+Glo+HD+eReader+Battery+Replacement/143903).
 
-[[!toc]]
+[[!toc levels=2]]
 
 # Quick hardware review
 

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

mostly done with the kobo setup
diff --git a/hardware/tablet/kobo-clara-hd.md b/hardware/tablet/kobo-clara-hd.md
index df9f48d8..185586a0 100644
--- a/hardware/tablet/kobo-clara-hd.md
+++ b/hardware/tablet/kobo-clara-hd.md
@@ -1,15 +1,65 @@
-[[!meta title="My Kobo hacks"]]
+[[!meta title="Hacking my Kobo Clara HD"]]
 
-I just got a new kobo reader, a Kobo Clara HD. It's pretty similar to
-the Glo HD I had but which has unfortunately [died after 5 years](https://www.mobileread.com/forums/showthread.php?t=340012_),
-even after [trying to replace the battery](https://www.ifixit.com/Guide/Kobo+Glo+HD+eReader+Battery+Replacement/143903).
+I just got a new [Kobo](https://www.kobo.com/) ebook reader, a [Kobo Clara HD](https://ca.kobobooks.com/products/kobo-clara-hd?utm_source=Kobo&utm_medium=TopNav&utm_campaign=Clara). It's
+pretty similar to the Glo HD I had but which has unfortunately [died
+after 5 years](https://www.mobileread.com/forums/showthread.php?t=340012_), even after [trying to replace the battery](https://www.ifixit.com/Guide/Kobo+Glo+HD+eReader+Battery+Replacement/143903).
 
-Here are the config hacks I put on top of the device.
+[[!toc]]
 
-# Registration bypass hack
+# Quick hardware review
 
-[This guide](https://yingtongli.me/blog/2018/07/30/kobo-rego.html) has this awesome trick to bypass the annoying
-registration step. Basically:
+This is a neat little device. It's *very* similar to the Glo HD, which
+is a bit disappointing: you'd think they would have improved on the
+design in the 5+ years since the Glo HD has come out.. It does have an
+"amber" night light which is nice, but the bezel is still not level
+with the display, and the device is still kind of on the thick side. A
+USB-C (instead of micro-USB) port would have been nice too.
+
+But otherwise, it's pretty slick, and just works. And because the
+hardware design didn't change, I can still hack at it like a madman,
+which is really why I bought this thing in the first place.
+
+Hopefully it will last longer than 5 years. Ebook readers should
+really last for decades, not years, but I guess that's too much to
+expect from our consumerist, suicidal, [extinctionist society](https://rebellion.global/).
+
+# Configuration hacks
+
+Here are the hacks I done on the device. I had done many more hacks on
+the Kobo Glo HD, but I decided to take a more streamlined, minimalist
+and, hopefully, easier for new users than the pile of hacks I was
+doing before (which I expand on at the end of the article).
+
+[SSH support]: https://gitlab.com/anarcat/kobo-ssh
+[wallabako]: https://gitlab.com/anarcat/wallabako
+
+## SD card replacement
+
+I [replaced the SD card](https://yingtongli.me/blog/2018/07/29/kobo-sd.html). The original card shipped with the Clara
+HD was 8GB which meant all my books actually fitted on the original,
+but just barely. The new card is 16GB.
+
+Unfortunately, I did this procedure almost at the end of this guide
+(right before writing the syncthing scripts, below). Next time, that
+should be the first thing done so the original SD card acts as a
+pristine copy of the upstream firmware. So even though this seems like
+an invasive and difficult procedure, I actually do recommend you do it
+first.
+
+The process is basically to:
+
+ 1. crack open the Kobo case (don't worry, it sounds awful but I've
+    done it often)
+ 2. take the SD card out
+ 3. copy it over to a new, larger card (say on your computer)
+ 4. put the larger card in
+
+This [guide](https://yingtongli.me/blog/2018/07/29/kobo-sd.html) has all the details.
+
+## Registration bypass hack
+
+[This guide](https://yingtongli.me/blog/2018/07/30/kobo-rego.html) (from the same author!) has this awesome trick to
+bypass the annoying registration step. Basically:
 
  1. pretend you do not have wifi
  2. mount the device
@@ -17,12 +67,20 @@ registration step. Basically:
  4. `INSERT INTO user(UserID,UserKey) VALUES('1','');`
  5. unmount the device
 
-More details in the above guide.
+More details in the above guide, again.
+
+## Install koreader
 
-# Install koreader
+My e-reader of choise is Koreader. It's just that great. I still don't
+find the general user interface (ie. the "file browswer") as intuitive
+as the builtin one, but the book reading just feels better. And
+anyways it's the easier way to get a shell on the device.
 
 Follow [those instructions](https://github.com/koreader/koreader/wiki/Installation-on-Kobo-devices), particularly the [NickelMenu](https://github.com/koreader/koreader/wiki/Installation-on-Kobo-devices#alternative-manual-installation-method-based-on-nickelmenu)
-instructions (see [the NickelMenu home page](https://pgaskin.net/NickelMenu/)).
+instructions (see also [the NickelMenu home page](https://pgaskin.net/NickelMenu/)). Yes, you need
+to install some other thing to start koreader, which doesn't start on
+its own. NickelMenu is the simplest and better integrated I have
+found.
 
 You might also want to [install some dictionnaries](https://github.com/koreader/koreader/wiki/Dictionary-support) and configure
 SSH:
@@ -33,7 +91,23 @@ SSH:
  3. unmount USB
  4. enable SSH in koreader (Gear -> Network -> SSH -> start SSH)
 
-# Install syncthing
+## Install syncthing
+
+I use [Syncthing](https://syncthing.net/) to copy all my books into the device now. I was
+previously using Koreader's OPDS support with Calibre's web interface,
+but that was clunky and annoying, and I'd constantly have to copy
+books around. Now the entire collection is synchronized.
+
+As a bonus, I can actually synchronise (and backup!) the koreader
+metadata, since it's stored next to the files. So in theory, this
+means I could use koreader from multiple devices and have my reading
+progress sync'd, but I haven't tested that feature just yet.
+
+I chose [Syncthing](https://syncthing.net/) because it's simple, lightweight, supported on
+Linux and Android, and statically compiles by default which means it's
+easy to deploy on the Kobo.
+
+Here is how I installed and started Syncthing at first:
 
  1. [Download the latest version for ARM](https://syncthing.net/downloads/)
  2. extract the archive
@@ -47,22 +121,75 @@ SSH:
                 <address>0.0.0.0:8384</address>
             </gui>
         </configuration>
- 7. copy a valid `ca-certificates.crt` file over
+ 7. copy a valid `ca-certificates.crt` file into `/etc/ssl/certs/` on
+    the Kobo (otherwise syncthing cannot bootstrap discovery servers)
  8. launch syncthing over SSH: `/mnt/onboard/.adds/syncthing`
 
 You should now be able to connect to the syncthing GUI through your
-web browser. Immediately change the admin password.
+web browser.
 
-TODO: figure out how to start it. Options:
+Immediately change the admin password.
 
- 1. on boot (inittab or whatever). downside: power usage.
- 2. on wifi (udev hacks). downside: unreliable (see wallabako).
- 3. on demande (e.g. nickel menu, koreader terminal
-    shortcuts). downside: did not work in my tests.
+Then, figure out how to start it. Here are your options:
+
+ 1. on boot (`inittab` or whatever). downside: power usage.
+ 2. on wifi (`udev` hacks). downside: unreliable (see [wallabako][]).
+ 3. on demand (e.g. nickel menu, koreader terminal
+    shortcuts). downside: kind of clunky in koreader, did not work in
+    nickel menu.
  4. manually, through shell. downside: requires a shell, but then
     again we already have one through koreader?
 
-# Remaining
+What I have done is to write trivial shell scripts (in
+`.../KOBOeReader/scripts`) to start syncthing. The first is
+`syncthing-start.sh`:
+
+    #!/bin/sh
+
+    /mnt/onboard/.adds/syncthing serve &
+
+Then `syncthing-stop.sh`:
+
+    #!/bin/sh
+
+    /usr/bin/pkill syncthing
+
+This makes those scripts usable from the koreader file browser. Then
+the folder can be added to the folder shortcuts and a long-hold on the
+script will allow you to execute it.
+
+Still have to figure out why the Nickel Menu script is not working,
+but it could simply reuse the above to simplify debugging. This is the
+script I ended up with, in `.../KOBOeReader/.adds/nm/syncthing`:
+
+    menu_item :main    :Syncthing (toggle)    :cmd_spawn         :exec /mnt/onboard/scripts/syncthing-stop.sh
+      chain_success:skip:4
+        chain_success                      :cmd_spawn          :exec /mnt/onboard/scripts/syncthing-start.sh
+        chain_success                      :dbg_toast          :Started Syncthing server
+        chain_failure                      :dbg_toast          :Error starting Syncthing server
+        chain_always:skip:-1
+      chain_success                        :dbg_toast          :Stopped Syncthing server
+    menu_item :main    :Syncthing (start)    :cmd_output         :exec /mnt/onboard/scripts/syncthing-start.sh
+    menu_item :main    :Syncthing (stop)    :cmd_output         :exec /mnt/onboard/scripts/syncthing-stop.sh
+
+It's unclear why this doesn't work: I only get "Error starting
+Syncthing server" for the toggle, and no output for the `(start)`
+action. In either case, syncthing doesn't actually start.
+
+## Avoided tasks
+
+This list wouldn't be complete without listing more explicitly the
+stuff I have done before on the Kobo and which I have deliberately
+decided *not* to do here because my time is precious:
+

(Diff truncated)
link to guide, fix headings
diff --git a/hardware/tablet.mdwn b/hardware/tablet.mdwn
index 07b0e922..308483d6 100644
--- a/hardware/tablet.mdwn
+++ b/hardware/tablet.mdwn
@@ -87,6 +87,11 @@ but more expensive:
 
 Otherwise similar to the Glo HD. Retail price around 180$CAD.
 
+### Clara HD
+
+See [[the guide I wrote for hacking on this device|kobo-clara-hd]],
+similar to the above two devices.
+
 Onyx
 ----
 
diff --git a/hardware/tablet/kobo-clara-hd.md b/hardware/tablet/kobo-clara-hd.md
index 0f3c2d08..df9f48d8 100644
--- a/hardware/tablet/kobo-clara-hd.md
+++ b/hardware/tablet/kobo-clara-hd.md
@@ -6,7 +6,7 @@ even after [trying to replace the battery](https://www.ifixit.com/Guide/Kobo+Glo
 
 Here are the config hacks I put on top of the device.
 
-## Registration bypass hack
+# Registration bypass hack
 
 [This guide](https://yingtongli.me/blog/2018/07/30/kobo-rego.html) has this awesome trick to bypass the annoying
 registration step. Basically:
@@ -19,7 +19,7 @@ registration step. Basically:
 
 More details in the above guide.
 
-## Install koreader
+# Install koreader
 
 Follow [those instructions](https://github.com/koreader/koreader/wiki/Installation-on-Kobo-devices), particularly the [NickelMenu](https://github.com/koreader/koreader/wiki/Installation-on-Kobo-devices#alternative-manual-installation-method-based-on-nickelmenu)
 instructions (see [the NickelMenu home page](https://pgaskin.net/NickelMenu/)).
@@ -33,7 +33,7 @@ SSH:
  3. unmount USB
  4. enable SSH in koreader (Gear -> Network -> SSH -> start SSH)
 
-## Install syncthing
+# Install syncthing
 
  1. [Download the latest version for ARM](https://syncthing.net/downloads/)
  2. extract the archive
@@ -62,7 +62,7 @@ TODO: figure out how to start it. Options:
  4. manually, through shell. downside: requires a shell, but then
     again we already have one through koreader?
 
-## Remaining
+# Remaining
 
  * [plato](https://www.mobileread.com/forums/showthread.php?t=292914) install?
  * [SD card replacement](https://yingtongli.me/blog/2018/07/29/kobo-sd.html)

publish kobo notes
diff --git a/hardware/tablet/kobo-clara-hd.md b/hardware/tablet/kobo-clara-hd.md
new file mode 100644
index 00000000..0f3c2d08
--- /dev/null
+++ b/hardware/tablet/kobo-clara-hd.md
@@ -0,0 +1,68 @@
+[[!meta title="My Kobo hacks"]]
+
+I just got a new kobo reader, a Kobo Clara HD. It's pretty similar to
+the Glo HD I had but which has unfortunately [died after 5 years](https://www.mobileread.com/forums/showthread.php?t=340012_),
+even after [trying to replace the battery](https://www.ifixit.com/Guide/Kobo+Glo+HD+eReader+Battery+Replacement/143903).
+
+Here are the config hacks I put on top of the device.
+
+## Registration bypass hack
+
+[This guide](https://yingtongli.me/blog/2018/07/30/kobo-rego.html) has this awesome trick to bypass the annoying
+registration step. Basically:
+
+ 1. pretend you do not have wifi
+ 2. mount the device
+ 3. `sqlite3 /media/.../KOBOeReader/.kobo/KoboReader.sqlite`
+ 4. `INSERT INTO user(UserID,UserKey) VALUES('1','');`
+ 5. unmount the device
+
+More details in the above guide.
+
+## Install koreader
+
+Follow [those instructions](https://github.com/koreader/koreader/wiki/Installation-on-Kobo-devices), particularly the [NickelMenu](https://github.com/koreader/koreader/wiki/Installation-on-Kobo-devices#alternative-manual-installation-method-based-on-nickelmenu)
+instructions (see [the NickelMenu home page](https://pgaskin.net/NickelMenu/)).
+
+You might also want to [install some dictionnaries](https://github.com/koreader/koreader/wiki/Dictionary-support) and configure
+SSH:
+
+ 1. mount USB
+ 2. drop your SSH public key in
+    `.../KOBOeReader/.adds/koreader/settings/SSH/authorized_keys`
+ 3. unmount USB
+ 4. enable SSH in koreader (Gear -> Network -> SSH -> start SSH)
+
+## Install syncthing
+
+ 1. [Download the latest version for ARM](https://syncthing.net/downloads/)
+ 2. extract the archive
+ 3. copy the `syncthing` binary into `.../KOBOeReader/.adds/`
+ 4. login over SSH (see above, sorry)
+ 5. create the following directory: `~/.config/syncthing/`
+ 6. create the following configuration file:
+
+        <configuration version="18">
+            <gui enabled="true" tls="false" debugging="false">
+                <address>0.0.0.0:8384</address>
+            </gui>
+        </configuration>
+ 7. copy a valid `ca-certificates.crt` file over
+ 8. launch syncthing over SSH: `/mnt/onboard/.adds/syncthing`
+
+You should now be able to connect to the syncthing GUI through your
+web browser. Immediately change the admin password.
+
+TODO: figure out how to start it. Options:
+
+ 1. on boot (inittab or whatever). downside: power usage.
+ 2. on wifi (udev hacks). downside: unreliable (see wallabako).
+ 3. on demande (e.g. nickel menu, koreader terminal
+    shortcuts). downside: did not work in my tests.
+ 4. manually, through shell. downside: requires a shell, but then
+    again we already have one through koreader?
+
+## Remaining
+
+ * [plato](https://www.mobileread.com/forums/showthread.php?t=292914) install?
+ * [SD card replacement](https://yingtongli.me/blog/2018/07/29/kobo-sd.html)

more resolved stuff (cool new things)
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 2deb6a46..bb836740 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -279,11 +279,6 @@ For syncmaildir, the plan is to drop it. See [this blog post](https://anarc.at/b
 elpy, I'm likely to use LSP as well, since it seems it won't make it
 after all. For qalculate, I'm betting on backports.
 
-### Cool things I want to try
-
- * sway
- * figure out what else is new in bullseye?
-
 ### Puppet breaks in bullseye/sid
 
 testing has this ... peculiar notion of itself. instead of announcing
@@ -362,6 +357,19 @@ the first place?
 
 ## Resolved
 
+### Cool things I want to try
+
+ * sway
+ * figure out what else is new in bullseye?
+
+Update: I postponed those. I feel sway (and Wayland in general) is not
+ready for prime time just yet. For example it requires pipewire for
+screensharing, Emacs is not yet ported yet, etc. Kind of a mess.
+
+[Debian Planet](https://planet.debian.org/) has the `#newinbullseye` stuff ([mikas blog](https://michael-prokop.at/blog/index.php?s=newinbullseye)
+mostly), I added what I found here already. There's also [this wiki
+page](https://wiki.debian.org/NewInBullseye) and, of course, the [release notes](https://www.debian.org/releases/bullseye/amd64/release-notes).
+
 ### Browserpass fails to upgrade
 
 Upgrade crashed on this:

updates on removed packages (add nomacs)
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 91122778..2deb6a46 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -259,6 +259,8 @@ following, even if they don't make it to bullseye:
  * elpy - keeping until i switch to LSP? hopefully it will make it too
  * syncmaildir - my email sync! maybe i can try another
  * qalculate-gtk - it will get back on its feet, i'm sure
+ * nomacs - a great image viewer, has [some packaging issues](https://tracker.debian.org/pkg/nomacs), most
+   notably it's [out of date with upstream](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974617) and [vendors libexiv2](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974616)
 
 I also particularly need to pay attention to usbguard, as it's quite
 possible I won't be able to do anything after reboot. :p
@@ -266,11 +268,16 @@ possible I won't be able to do anything after reboot. :p
 Some other removed packages I have just accepted the removal, with the
 following alternatives:
 
-| Package               | Alternative             | Rationale                                                                          |
-|-----------------------|-------------------------|------------------------------------------------------------------------------------|
-| `gocode`              | `gopls`                 | LSP is the (ad-hoc) standard                                                       |
-| `gtk-recordmydesktop` | `obs`, `peek`           | peek is a nice, simple alternative, OBS Studio can also be used for live streaming |
-| `usbguard-applet-qt`  | `usbguard allow-device` | GUI just gone, but commandline might work                                          |
+| Package               | Alternative             | Rationale                                                                                                           |
+|-----------------------|-------------------------|---------------------------------------------------------------------------------------------------------------------|
+| `gocode`              | `gopls`                 | LSP is the (ad-hoc) standard                                                                                        |
+| `gtk-recordmydesktop` | `obs`, `peek`           | peek is a nice, simple alternative, OBS Studio can also be used for live streaming                                  |
+| `nomacs`              | `geeqie`, many others   | i mostly use geeqie all the time, and only recently found nomacs, might be interesting if it gets packaged properly |
+| `usbguard-applet-qt`  | `usbguard allow-device` | GUI just gone, but commandline might work                                                                           |
+
+For syncmaildir, the plan is to drop it. See [this blog post](https://anarc.at/blog/2021-06-29-another-mail-crash/). For
+elpy, I'm likely to use LSP as well, since it seems it won't make it
+after all. For qalculate, I'm betting on backports.
 
 ### Cool things I want to try
 

progress
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index ca9fc2f5..91122778 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -7,6 +7,11 @@ to upgrade slightly before or during the freeze. This time I feel
 almost late because it seems we'll be releasing in almost a month now
 (May 2021, it's April 2021 now).
 
+Update: and that procedure was done only on one workstation
+([[hardware/curie]]). I have done another (the laptop,
+[[hardware/angela]]) in July 2021, and the server
+([[hardware/server/marcos]]) is still pending.
+
 This document contains my upgrade procedure, notable changes in the
 new version, issues I have stumbled upon (and possibly fixed), and
 troubleshooting instructions.

one resolved upgrade issue
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 7fe9ec61..ca9fc2f5 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -348,10 +348,6 @@ and not a version, in testing/unstable in Debian... Garbage-in,
 garbage-out? Why don't we set a real version number there in Debian in
 the first place?
 
-### LUKS password prompt in plain text instead of GUI
-
-It seems like Plymouth just disappeared?
-
 ## Resolved
 
 ### Browserpass fails to upgrade
@@ -470,6 +466,11 @@ to make U2F authentication work (2FA) in Firefox and Chrome, but it
 seems it's not necessary in bullseye anymore at least, so I've just
 removed it altogether.
 
+### LUKS password prompt in plain text instead of GUI
+
+It seems like Plymouth just disappeared? At least on curie. Could not
+reproduce on angela, suspecting this was never correctly setup on curie.
+
 # Troubleshooting
 
 ## Upgrade failures

fix typo, thanks ukleinek
diff --git a/blog/2019-07-07-rsync-oneliner.mdwn b/blog/2019-07-07-rsync-oneliner.mdwn
index 354ad22d..6a481a54 100644
--- a/blog/2019-07-07-rsync-oneliner.mdwn
+++ b/blog/2019-07-07-rsync-oneliner.mdwn
@@ -17,7 +17,7 @@ The common answer is "just use `-av`":
  * it shows every file transfered, which can overwhelm the terminal
    for large transfers
  * it won't transfer hardlinks, ACLs and other extended attributes
- * it might break if `/etc/password` is not synchronized across hosts
+ * it might break if `/etc/passwd` is not synchronized across hosts
 
 The full one liner
 ==================

more alternatives and a short response
diff --git a/blog/2021-06-29-another-mail-crash.md b/blog/2021-06-29-another-mail-crash.md
index 7624565f..b029895c 100644
--- a/blog/2021-06-29-another-mail-crash.md
+++ b/blog/2021-06-29-another-mail-crash.md
@@ -163,7 +163,8 @@ before|blog/2021-03-22-email-crash/#workarounds-and-solutions]], there
 are other programs that sync mail. I'm looking at:
 
  * [offlineimap3](https://github.com/OfflineIMAP/offlineimap3): requires IMAP, used the py2 version in the past,
-   might just still work, first sync painful
+   might just still work, first sync painful (IIRC), ways to tunnel
+   over SSH, see comment below
  * [isync/mbsync](http://isync.sf.net/): might be faster, I remember having trouble
    switching from offlineimap to this, has support for TLS client
    certs, running over SSH, and generally has good words from multiple
@@ -172,6 +173,13 @@ are other programs that sync mail. I'm looking at:
  * [nncp](http://www.nncpgo.org/): treat the local spool as another mail server, might not
    be compatible with my "multiple clients" setup
  * [doveadm-sync](https://wiki2.dovecot.org/Tools/Doveadm/Sync): requires dovecot on both ends, but supports
-   using SSH to sync, will try this next
+   using SSH to sync, <del>will try this next</del>, may have
+   performance problems, see comment below
+ * [interimap](https://guilhem.org/interimap/): syncs two IMAP servers, apparently faster than
+   `doveadm` and `offlineimap`
+ * [mail-sync](https://blog.hades.lkamp.de/mail-sync/): notify support, happens over any piped transport
+   (e.g. ssh), diff/patch system, requires binary on both ends,
+   mentions UUCP in the manpage, seems awfully complicated to setup,
+   mentions `rsmtp` which is a nice name for `rsendmail`
 
 [[!tag syncmaildir rsendmail email fail sysadmin debian-planet python-planet]]
diff --git a/blog/2021-06-29-another-mail-crash/comment_4_13ddf1c7a48bafb0154762671e7dac69._comment b/blog/2021-06-29-another-mail-crash/comment_4_13ddf1c7a48bafb0154762671e7dac69._comment
new file mode 100644
index 00000000..7627094d
--- /dev/null
+++ b/blog/2021-06-29-another-mail-crash/comment_4_13ddf1c7a48bafb0154762671e7dac69._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""on tools"""
+ date="2021-07-09T00:25:21Z"
+ content="""
+Answering a bunch of comments at once:
+
+ * Marius: nice trick, noted, thanks!
+ * guilhem: excellent story, great background, tool looks awesome, may
+   try it out next, thanks!
+ * Landry: i am not sure Syncthing would scale, and i wouldn't trust
+   it with my mail spool. i'm almost 100% certain that Unison would
+   *not* scale. syncing mail spools is hard: most backup software have
+   a lot of trouble walking those large directory trees, for example,
+   let alone "in real time"...
+
+I've also added `mail-sync` to the list, recommended by helmut on IRC. Thanks!
+"""]]

approve comment
diff --git a/blog/2021-06-29-another-mail-crash/comment_1_25aa1e7dba8d17e3e7eba2bd2e84073b._comment b/blog/2021-06-29-another-mail-crash/comment_1_25aa1e7dba8d17e3e7eba2bd2e84073b._comment
new file mode 100644
index 00000000..ee29c4f2
--- /dev/null
+++ b/blog/2021-06-29-another-mail-crash/comment_1_25aa1e7dba8d17e3e7eba2bd2e84073b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="82.65.226.14"
+ claimedauthor="Landry"
+ subject="commenting on 2021-06-29-another-mail-crash"
+ date="2021-07-08T12:28:05Z"
+ content="""
+These are maildirs after all: directories and files, why not using a generic file synchronisation tool? I think at Syncthing which will synchronize those in almost real time, a little footprint and the ability to do backups by itself…
+Unison should be able to do the job, or more \"fun\", something like glusterfs…
+"""]]
diff --git a/blog/2021-06-29-another-mail-crash/comment_1_37dd8d92f1c6da87f0d4b391be452fb7._comment b/blog/2021-06-29-another-mail-crash/comment_1_37dd8d92f1c6da87f0d4b391be452fb7._comment
new file mode 100644
index 00000000..3b8da667
--- /dev/null
+++ b/blog/2021-06-29-another-mail-crash/comment_1_37dd8d92f1c6da87f0d4b391be452fb7._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ ip="185.220.101.204"
+ claimedauthor="guilhem"
+ subject="other alternative: interimap"
+ date="2021-07-07T16:39:50Z"
+ content="""
+> * doveadm-sync: requires dovecot on both ends, but supports using SSH to sync, will try this next
+
+Went down that route as well some years ago, and IIRC that solution is more suitable for bidirectional synchronization of multiple IMAPd in a “ring” topology not a “star” topology.  Also at the time I [was not](https://dovecot.org/pipermail/dovecot/2014-February/094935.html) able to get incremental synchronization to work, thereby wasting much more bandwidth and CPU cycles than necessary (like OfflineIMAP).
+
+For these reasons I ending up writing my own synchronization software shortly afterwards, which — shameless plug :-) — you might want to try too¹: [interimap](https://guilhem.org/interimap/).  Like `doveadm sync` it requires an IMAPd on each end, and can use SSH for transport.  It takes advantage of the QRESYNC IMAP extension for incremental synchronization, yielding [much better performance](https://guilhem.org/interimap/benchmark.html) than OfflineIMAP.
+
+¹ If you'd like to give a try be sure to check the [known bugs and limitations section of the manual](https://guilhem.org/interimap/interimap.1.html#known-bugs-and-limitations).  It has served me well for almost 6 years now but it's neither as flexible (the use-case is much narrower, although if you've decided to install Dovecot on each end you should be covered) nor as mature as OfflineIMAP.
+"""]]

list of diagrams
diff --git a/blog/2020-09-30-presentation-tools.mdwn b/blog/2020-09-30-presentation-tools.mdwn
index 223ec47f..a59ab6d1 100644
--- a/blog/2020-09-30-presentation-tools.mdwn
+++ b/blog/2020-09-30-presentation-tools.mdwn
@@ -174,6 +174,8 @@ series of images one by one. In that case, any of those image viewers
  * [fim](https://www.nongnu.org/fbi-improved/)
  * [sxiv](https://github.com/muennich/sxiv)
 
+And to make diagrams, see this [maybe exhaustive list](https://xosh.org/text-to-diagram/).
+
 Update: it turns out I already wrote a somewhat similar thing when I
 did a recent presentation. If you're into rants, you might enjoy [the
 README file accompanying the Kubecon rant presentation][]. TL;DR:

moar tools
diff --git a/blog/2020-09-30-presentation-tools.mdwn b/blog/2020-09-30-presentation-tools.mdwn
index 66e3d222..223ec47f 100644
--- a/blog/2020-09-30-presentation-tools.mdwn
+++ b/blog/2020-09-30-presentation-tools.mdwn
@@ -23,6 +23,7 @@ Further advice:
  * [10 tips by Neil Patel](http://www.quicksprout.com/2007/09/01/10-tips-for-a-killer-presentation/)
  * [The Art of Presenting by Matt Westgate](https://www.lullabot.com/blog/art-presenting) (video)
  * [Presenting You by Emma Jane Hogbin](http://dc2009.drupalcon.org/session/presenting-you.html) (video)
+ * [Create better conference slides and presentations by Stéphanie Walter](https://stephaniewalter.design/blog/create-better-conference-presentations-slides/)
 
 I'm currently using Pandoc with PDF input (with a trip through LaTeX)
 for most slides, because PDFs are more reliable and portable than web
@@ -92,6 +93,11 @@ keep up to date.
  * [Home page](https://github.com/visit1985/mdp)
  * [lookatme](https://github.com/d0c-s4vage/lookatme) is similar
 
+## Pampi
+
+ * Markdown, pandoc, impress
+ * [Home page](https://gitlab.com/edleh/pampi)
+
 ## Pandoc
 
  * Allows converting from basically whatever into slides, including
@@ -107,6 +113,11 @@ keep up to date.
  * basically "Keynote for Linux"
  * [Home page](https://pdfpc.github.io/), pdf-presenter-console in Debian
 
+Another viewer that might be relevant here is [pympress](https://github.com/Cimbali/pympress/) which
+supports annotations (in a separate screen), caching, timing, and
+embedded videos. [dspdfviewer](https://dspdfviewer.danny-edel.de/) is another such viewer.
+
+Others just [use their IDE directly](https://staltz.com/your-ide-as-a-presentation-tool.html).
 ## Pinpoint
 
  * Native GNOME app
@@ -115,6 +126,11 @@ keep up to date.
  * [Home page](https://wiki.gnome.org/Attic/Pinpoint)
  * Abandoned since at least 2019
 
+## Remark
+
+ * In-browser, HTML/Markdown/Javascript based
+ * [Home page](https://github.com/gnab/remark)
+
 ## Reveal.js
 
  * HTML, Javascript

approve comment
diff --git a/blog/2021-06-29-another-mail-crash/comment_1_191413161e8163b7fb740d5a28070aa5._comment b/blog/2021-06-29-another-mail-crash/comment_1_191413161e8163b7fb740d5a28070aa5._comment
new file mode 100644
index 00000000..419f752b
--- /dev/null
+++ b/blog/2021-06-29-another-mail-crash/comment_1_191413161e8163b7fb740d5a28070aa5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ ip="78.56.236.68"
+ claimedauthor="Marius Gedminas"
+ url="https://gedmin.as/"
+ subject="offlineimap over ssh"
+ date="2021-06-30T22:35:56Z"
+ content="""
+I'm using offlineimap over ssh, with
+
+    preauthtunnel = ssh -q mymailserver /usr/lib/dovecot/imap
+
+Thus my offlineimap doesn't need to know my IMAP password (which happens to match the Unix account login password, since I'm using dovecot with the default configuration).
+"""]]

expand on mbsync
diff --git a/blog/2021-06-29-another-mail-crash.md b/blog/2021-06-29-another-mail-crash.md
index 9a59622b..7624565f 100644
--- a/blog/2021-06-29-another-mail-crash.md
+++ b/blog/2021-06-29-another-mail-crash.md
@@ -165,7 +165,9 @@ are other programs that sync mail. I'm looking at:
  * [offlineimap3](https://github.com/OfflineIMAP/offlineimap3): requires IMAP, used the py2 version in the past,
    might just still work, first sync painful
  * [isync/mbsync](http://isync.sf.net/): might be faster, I remember having trouble
-   switching from offlineimap to this
+   switching from offlineimap to this, has support for TLS client
+   certs, running over SSH, and generally has good words from multiple
+   Debian and notmuch people
  * [getmail](http://pyropus.ca/software/getmail/): just downloads email, might not be enough
  * [nncp](http://www.nncpgo.org/): treat the local spool as another mail server, might not
    be compatible with my "multiple clients" setup

fix typo, tx pollo
diff --git a/blog/2021-06-29-another-mail-crash.md b/blog/2021-06-29-another-mail-crash.md
index 0ca6ca1d..9a59622b 100644
--- a/blog/2021-06-29-another-mail-crash.md
+++ b/blog/2021-06-29-another-mail-crash.md
@@ -11,7 +11,7 @@ to backups and sheer luck (again).
 It is not really worth going over the crash in details, it's fairly
 similar to the last one: something bad happened and `smd` started
 destroying everything. The hint is that it takes a long time to do
-what usually takes seconds. It helps that I know have a second monitor
+what usually takes seconds. It helps that I now have a second monitor
 showing logs. 
 
 I still lost much more mail than the last time. I used to have "301

short notes on alternatives
diff --git a/blog/2021-06-29-another-mail-crash.md b/blog/2021-06-29-another-mail-crash.md
index 34af3bfb..0ca6ca1d 100644
--- a/blog/2021-06-29-another-mail-crash.md
+++ b/blog/2021-06-29-another-mail-crash.md
@@ -162,10 +162,14 @@ As [[mentioned
 before|blog/2021-03-22-email-crash/#workarounds-and-solutions]], there
 are other programs that sync mail. I'm looking at:
 
- * [offlineimap3](https://github.com/OfflineIMAP/offlineimap3)
- * [isync/mbsync](http://isync.sf.net/)
- * [getmail](http://pyropus.ca/software/getmail/)
- * [nncp](http://www.nncpgo.org/)
- * [doveadm-sync](https://wiki2.dovecot.org/Tools/Doveadm/Sync)
+ * [offlineimap3](https://github.com/OfflineIMAP/offlineimap3): requires IMAP, used the py2 version in the past,
+   might just still work, first sync painful
+ * [isync/mbsync](http://isync.sf.net/): might be faster, I remember having trouble
+   switching from offlineimap to this
+ * [getmail](http://pyropus.ca/software/getmail/): just downloads email, might not be enough
+ * [nncp](http://www.nncpgo.org/): treat the local spool as another mail server, might not
+   be compatible with my "multiple clients" setup
+ * [doveadm-sync](https://wiki2.dovecot.org/Tools/Doveadm/Sync): requires dovecot on both ends, but supports
+   using SSH to sync, will try this next
 
 [[!tag syncmaildir rsendmail email fail sysadmin debian-planet python-planet]]

publish crash post
diff --git a/blog/2021-03-22-email-crash.md b/blog/2021-03-22-email-crash.md
index 1a5209d8..446af3fd 100644
--- a/blog/2021-03-22-email-crash.md
+++ b/blog/2021-03-22-email-crash.md
@@ -536,4 +536,6 @@ they will win, eventually.
 
 In any case, I'm just happy I got mail again, strangely.
 
+Update: this happened again, believe it or not! See [[this next post|2021-06-29-another-mail-crash]].
+
 [[!tag syncmaildir rsendmail email fail sysadmin debian-planet python-planet]]
diff --git a/blog/2021-06-29-another-mail-crash.md b/blog/2021-06-29-another-mail-crash.md
index 77576330..34af3bfb 100644
--- a/blog/2021-06-29-another-mail-crash.md
+++ b/blog/2021-06-29-another-mail-crash.md
@@ -1,6 +1,6 @@
 [[!meta title="Another syncmaildir crash"]]
 
-So I had [[another major email crash|blog/2021-03-22-email-crash]]
+So I had another [[major email crash|blog/2021-03-22-email-crash]]
 with my [syncmaildir](https://github.com/gares/syncmaildir)
 [[setup|https://github.com/gares/syncmaildir]]. This time I was at
 least able to confirm the issue, and I still haven't lost mail thanks
@@ -15,7 +15,7 @@ what usually takes seconds. It helps that I know have a second monitor
 showing logs. 
 
 I still lost much more mail than the last time. I used to have "301
-723 messages", according to `notmuch`. But then when I ran `smd-pull`
+723 messages", according to [notmuch](https://notmuchmail.org/). But then when I ran `smd-pull`
 by hand, it was telling me:
 
     95K emails scanned
@@ -143,6 +143,29 @@ Phew!
 
 # Workaround
 
+I have filed this as a bug in [upstream issue 18](https://github.com/gares/syncmaildir/issues/18). Considering I
+filed 11 issues and only 3 of those were closed, I'm not holding my
+breath. I nevertheless filed [PR 19](https://github.com/gares/syncmaildir/pull/19) in the hope that this will fix
+my particular issue, but I'm not even sure this is the right
+fix...
 
+# Fix
 
-[[!tag draft]]
+At this point, I'm really ready to give up on SMD. It's really, really
+nice to be able to sync mail over SSH because I don't need to store my
+IMAP password on disk. But surely there are more reliable syncing
+mechanisms. I do not remember ever losing that much mail before. At
+worst, offlineimap would duplicate emails like mad, but never destroy
+my entire mail spool that way.
+
+As [[mentioned
+before|blog/2021-03-22-email-crash/#workarounds-and-solutions]], there
+are other programs that sync mail. I'm looking at:
+
+ * [offlineimap3](https://github.com/OfflineIMAP/offlineimap3)
+ * [isync/mbsync](http://isync.sf.net/)
+ * [getmail](http://pyropus.ca/software/getmail/)
+ * [nncp](http://www.nncpgo.org/)
+ * [doveadm-sync](https://wiki2.dovecot.org/Tools/Doveadm/Sync)
+
+[[!tag syncmaildir rsendmail email fail sysadmin debian-planet python-planet]]

another smd mail crash, gah
diff --git a/blog/2021-06-29-another-mail-crash.md b/blog/2021-06-29-another-mail-crash.md
new file mode 100644
index 00000000..77576330
--- /dev/null
+++ b/blog/2021-06-29-another-mail-crash.md
@@ -0,0 +1,148 @@
+[[!meta title="Another syncmaildir crash"]]
+
+So I had [[another major email crash|blog/2021-03-22-email-crash]]
+with my [syncmaildir](https://github.com/gares/syncmaildir)
+[[setup|https://github.com/gares/syncmaildir]]. This time I was at
+least able to confirm the issue, and I still haven't lost mail thanks
+to backups and sheer luck (again).
+
+# The crash
+
+It is not really worth going over the crash in details, it's fairly
+similar to the last one: something bad happened and `smd` started
+destroying everything. The hint is that it takes a long time to do
+what usually takes seconds. It helps that I know have a second monitor
+showing logs. 
+
+I still lost much more mail than the last time. I used to have "301
+723 messages", according to `notmuch`. But then when I ran `smd-pull`
+by hand, it was telling me:
+
+    95K emails scanned
+
+Oops. You can see `notmuch` happily noticing the destroyed files on
+the server:
+
+    jun 28 16:33:40 marcos notmuch[28532]: No new mail. Removed 65498 messages. Detected 1699 file renames.
+    jun 28 16:36:05 marcos notmuch[29746]: No new mail. Removed 68883 messages. Detected 2488 file renames.
+    jun 28 16:41:40 marcos notmuch[31972]: No new mail. Removed 118295 messages. Detected 3657 file renames.
+
+The final count ended up being 81 042 messages, according to
+notmuch. A whopping 220 000 mails deleted.
+
+The interesting bit, this time around, is that I caught smd in the act
+of running two processes in parallel:
+
+    jun 28 16:30:09 curie systemd[2845]: Finished pull emails with syncmaildir. 
+    jun 28 16:30:09 curie systemd[2845]: Starting push emails with syncmaildir... 
+    jun 28 16:30:09 curie systemd[2845]: Starting pull emails with syncmaildir... 
+
+So clearly that is the source of the bug.
+
+# Recovery
+
+Emergency stop on curie:
+
+    notmuch dump > notmuch.dump
+    systemctl --user --now disable smd-pull.service smd-pull.timer smd-push.service smd-push.timer notmuch-new.service notmuch-new.timer
+
+On marcos (the server), guessed the number of messages delivered since
+the last backup to be 71, just looking at timestamps in the mail
+log. Made a list:
+
+    grep postfix/local /var/log/mail.log | tail -71 > lost-mail
+
+Found postfix queue IDs:
+
+    sed 's/.*\]://;s/:.*//' lost-mail > qids
+
+Turn those into message IDs, find those that are missing from the disk
+(had previously ran `notmuch new` just to be sure it's up to date):
+
+    while read qid ; do 
+        grep "$qid: message-id" /var/log/mail.log
+    done < qids  | sed 's/.*message-id=<//;s/>//' | while read msgid; do
+        sudo -u anarcat notmuch count --exclude=false id:$msgid | grep -q 0 && echo $msgid
+    done
+
+Copy this back on curie as `missing-msgids` and:
+
+    $ wc -l missing-msgids 
+    48 missing-msgids
+    $ while read msgid ; do notmuch count --exclude=false id:$msgid | grep -q 0 && echo $msgid ; done < missing-msgids
+    mailman.189.1624881611.23397.nodes-reseaulibre.ca@reseaulibre.ca
+    AnwMy7rdSpK-N-vt4AiOag@ismtpd0148p1mdw1.sendgrid.net
+
+only two mails missing! whoohoo!
+
+Copy those back onto marcos as `really-missing-msgids`, and look at
+the full mail logs to see what they are:
+
+    ~anarcat/src/koumbit-scripts/mail/postfix-trace --from-file really-missing-msgids2
+
+I actually remembered deleting those, so no mail lost!
+
+Rebuild the list of msgids that were lost, on marcos:
+
+    while read qid ; do grep "$qid: message-id" /var/log/mail.log; done < qids  | sed 's/.*message-id=<//;s/>//'
+
+Copy that on curie as `lost-mail-msgids`, then copy the files over in
+a test dir:
+
+    while read msgid ; do
+        notmuch search --output=files --exclude=false "id:$msgid"
+    done < lost-mail-msgids | sed 's#/home/anarcat/Maildir/##' | rsync -v  --files-from=- /home/anarcat/Maildir/ shell.anarc.at:restore/Maildir-angela/
+
+If that looks about right, on marcos:
+
+    find restore/Maildir-angela/ -type f | wc -l
+
+... should match the number of missing mails, roughly.
+
+Copy if in the real spool:
+
+    while read msgid ; do
+        notmuch search --output=files --exclude=false "id:$msgid"
+    done < lost-mail-msgids | sed 's#/home/anarcat/Maildir/##' | rsync -v  --files-from=- /home/anarcat/Maildir/ shell.anarc.at:Maildir/
+
+Then on the server, `notmuch new` should find the new emails, and we
+shouldn't have any lost mail anymore:
+
+    while read qid ; do grep "$qid: message-id" /var/log/mail.log; done < qids  | sed 's/.*message-id=<//;s/>//' | while read msgid; do sudo -u anarcat notmuch count --exclude=false id:$msgid | grep -q 0 && echo $msgid ; done
+
+Then, crucial moment, try to pull the new mails from the backups on curie:
+
+    anarcat@curie:~(main)$ smd-pull  -n  --show-tags -v
+    Found lockfile of a dead instance. Ignored.
+    Phase 0: handshake
+    Phase 1: changes detection
+        5K emails scanned
+       10K emails scanned
+       15K emails scanned
+       20K emails scanned
+       25K emails scanned
+       30K emails scanned
+       35K emails scanned
+       40K emails scanned
+       45K emails scanned
+       50K emails scanned
+    Phase 2: synchronization
+    Phase 3: agreement
+    default: smd-client@localhost: TAGS: stats::new-mails(49687), del-mails(0), bytes-received(215752279), xdelta-received(3703852)
+    "smd-pull  -n  --show-tags -v" took 3 mins 39 secs
+
+This brought me back to the state after the backup plus the mails
+delivered during the day, which means I had to catchup with all my
+holiday's read emails (1440 mails!) but thankfully I made a dump of
+the notmuch database on curie at the start of the procedure, so this
+actually restored a sane state:
+
+    pv notmuch.dump | notmuch restore
+
+Phew!
+
+# Workaround
+
+
+
+[[!tag draft]]

plug goerzen
diff --git a/services/backup.mdwn b/services/backup.mdwn
index af72c8d6..3b5806a5 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -286,6 +286,8 @@ Backups:
 
 * [Backblaze](https://www.backblaze.com/): 5USD/mth/machine; "cloud storage" at ~5$/TB/mth
 
+See also [Goerzen's list](https://changelog.complete.org/archives/10265-roundup-of-unique-data-storage-hosting-options).
+
 Offsite procedures
 ==================
 

respond
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus/comment_8_2028ca198e188d5ca02584da1798a75c._comment b/blog/2020-06-04-replacing-smokeping-prometheus/comment_8_2028ca198e188d5ca02584da1798a75c._comment
new file mode 100644
index 00000000..8dd9b810
--- /dev/null
+++ b/blog/2020-06-04-replacing-smokeping-prometheus/comment_8_2028ca198e188d5ca02584da1798a75c._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""comment 8"""
+ date="2021-06-13T19:00:56Z"
+ content="""
+> Hi Anarcat,
+
+Hi Ravac!
+
+> I wonder what solution you settled with at the end ?
+
+Hum... I'm a bit confused by the question, because i thought [this section](#how-do-draw-smokeping-graphs-in-grafana) was pretty clear. :)
+
+> Do you prefer using the smokeping exporter over the blackbox one ?
+
+I use the blackbox exporter, not the smokeping prober, as I found out about it later.
+
+> Which dashboard do you use finally ? Thx!
+
+The one I uploaded to grafana.com and mentioned above.
+
+"""]]

approve comment
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus/comment_1_39dd8d147afec594057447ff9096c27d._comment b/blog/2020-06-04-replacing-smokeping-prometheus/comment_1_39dd8d147afec594057447ff9096c27d._comment
new file mode 100644
index 00000000..0d1bf8f9
--- /dev/null
+++ b/blog/2020-06-04-replacing-smokeping-prometheus/comment_1_39dd8d147afec594057447ff9096c27d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="185.161.129.151"
+ claimedauthor="Ravac"
+ subject="comment 7"
+ date="2021-06-13T14:45:53Z"
+ content="""
+Hi Anarcat,
+I wonder what solution you settled with at the end ? Do you prefer using the smokeping exporter over the blackbox one ? Which dashboard do you use finally ? Thx!
+"""]]

update on the ups stuff
diff --git a/hardware/power.org b/hardware/power.org
index 36922aca..ab79cb22 100644
--- a/hardware/power.org
+++ b/hardware/power.org
@@ -12,6 +12,12 @@
 | Total    |      |      | 78.16 |      |       | 321. | 320?     |
 #+TBLFM: $4=$2*$3::$7=$5*$6::@1$4=DC W::@1$7=VA::@7$4=vsum(@2$4..@6$4)::@7$7=vsum(@2$7..@6$7)
 
+Setup on the APC BR1000MS (1000VA), which estimates ~3h standby time,
+with about 18W in actual use.
+
+This survived for about 2h30 minutes during a 3h power outage on
+2021-06-09, with indoor temperature of about 27C.
+
 ** Downstairs
 
 server should take less than 500W AC, according to the specs. But
@@ -26,6 +32,10 @@ according to what's actually inside, it should be much less:
 | Total       | -      |     - | 160 W        |
 #+TBLFM: $4=$2*$3::@7$4=vsum(@2$4..@6$4)::<r2>
 
+Actual power usage, according to the UPS downstairs (APC BX1500M
+1500VA), fluctuates between 60 and 80 watts, with about 50 minutes of
+standby time.
+
 * Possible hardware
 
  * APC Back-UPS BR1500MS, 270$ 1500VA 4-15min load, USB 10 ports
@@ -40,3 +50,10 @@ according to what's actually inside, it should be much less:
  * spare batteries: https://www.upsbatterycenter.ca/
 
  * how to pick a UPS (TL;DR: VA = 1.6*W): https://www.howtogeek.com/161479/how-to-select-a-battery-backup-for-your-computer/
+
+* Actual hardware
+
+I ended up ordering this from Amazon (yes, I know):
+
+ * APC BR1000MS: 1000VA, 196$
+ * APC BX1500M: 1500VA, 212$

you would have thought
diff --git a/blog/2020-07-12-contact-tracing.mdwn b/blog/2020-07-12-contact-tracing.mdwn
index a957f39d..42e94c93 100644
--- a/blog/2020-07-12-contact-tracing.mdwn
+++ b/blog/2020-07-12-contact-tracing.mdwn
@@ -30,6 +30,10 @@ Please don't do this.
 > of doing it with "apps" so far, but I do not deny the utility and
 > importance of "contact tracing" itself. Apologies for the confusion.
 
+> Update 2, 2021-06-14: unsurprisingly, Google's tracing
+> implementation [leaks private information](https://themarkup.org/privacy/2021/04/27/google-promised-its-contact-tracing-app-was-completely-private-but-it-wasnt) even though they
+> promised the opposite.
+
 ----
 
 > Pour une raison que je m'explique mal, le sondage m'été envoyé en

add yaeus ht
diff --git a/hardware/radio.mdwn b/hardware/radio.mdwn
index 567db591..e66679e9 100644
--- a/hardware/radio.mdwn
+++ b/hardware/radio.mdwn
@@ -14,6 +14,7 @@ Hardware
   * Baofeng UV-3R MKII radio (<50$)
   * [Baofeng UV-5R](https://baofengtech.com/uv-5r)
   * Wouxun KG-UVD1P
+  * [Yaesu FT-60R](https://www.yaesu.com/indexVS.cfm?cmd=DisplayProducts&encProdID=6EC43B29CEF0EC2B4E19BB7371688B7F)
 * Transceiver: Yaesu FT-100D, bought around 600$ on ebay in 2010
 * Antenna/tuner kit:
  * MFJ-941E - antenna tuner and switch [155$ at radioworld](http://radioworld.ca/product_info.php?products_id=2885)

more data on freenode exile
diff --git a/blog/2021-05-24-leaving-freenode.mdwn b/blog/2021-05-24-leaving-freenode.mdwn
index bdfe2072..38ee5389 100644
--- a/blog/2021-05-24-leaving-freenode.mdwn
+++ b/blog/2021-05-24-leaving-freenode.mdwn
@@ -124,6 +124,14 @@ clocking 68,000 users, but that's a huge drop from the previous count
 which was 78,000 before the exodus began. We're even starting to see
 the effects of the migration on [netsplit.de](https://netsplit.de/networks/top10.php).
 
+Update 2: the [isfreenodedeadyet.com](https://isfreenodedeadyet.com/) site is updated more
+frequently than netsplit and shows tons more information. It shows 25k
+online users for libera and 61k for so-called freenode (down from
+~78k), and the trend doesn't seem to be stopping for so-called
+freenode. There's also a [list of 400+ channels that have moved
+out](https://github.com/siraben/freenode-exodus). Keep in mind that such migrations take effect over long
+periods of time.
+
 # Where do I move to?
 
 The first thing you should do is to figure out which tool to use for
@@ -226,6 +234,11 @@ futile. I would assume any data you have registered on there
 compromised and leaked. If your password is used elsewhere (tsk, tsk),
 change it everywhere.
 
+Update: there's also [another procedure](https://gist.github.com/nurupo/91b0ebc7f85059b57ea7108a25ae6c69), similar to the above, but
+with a different approach. Keep in mind that so-called freenode staff
+are actively hijacking channels for the mere act of mentioning libera
+in the channel topic, so thread carefully there.
+
 # Last words
 
 This is a sad time for IRC in general, and freenode in

approve comment
diff --git a/blog/2021-05-24-leaving-freenode/comment_1_082029cba37c050b1e35d581d069d437._comment b/blog/2021-05-24-leaving-freenode/comment_1_082029cba37c050b1e35d581d069d437._comment
new file mode 100644
index 00000000..5737beb7
--- /dev/null
+++ b/blog/2021-05-24-leaving-freenode/comment_1_082029cba37c050b1e35d581d069d437._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="180.253.83.241"
+ claimedauthor="Ade Malsasa Akbar"
+ url="https://floss.social/@ademalsasa"
+ subject="Thank You"
+ date="2021-05-30T16:57:00Z"
+ content="""
+Thank you very much for writing about this Freenode case. I am a Freenode member since many years I cannot remember anymore and I did not know about the noise until I read this. I am only a user who loved IRC. I am glad now the former Freenode existed as Libera.Chat. 
+"""]]

more notable changes, mostly from mikas
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 47bcc30c..7fe9ec61 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -147,9 +147,19 @@ noticed.
    [crypt(5)](https://manpages.debian.org/crypt.5) (in bullseye), [crypt(3)](https://manpages.debian.org/crypt.3) (in buster), and
    `mkpasswd -m help` for a list of supported hashes on whatever
 
+There is a more [exhaustive review of server-level changes from
+mikas](https://michael-prokop.at/blog/2021/05/27/what-to-expect-from-debian-bullseye-newinbullseye/) as well. Notable:
+
+ * `kernel.unprivileged_userns_clone` enabled by default ([bug
+   898446](https://bugs.debian.org/898446))
+ * Prometheus [hardering](https://salsa.debian.org/go-team/packages/prometheus/-/commit/62017e7de3f9e5ae02bc842cabd3b2da69fb354f), initiated by yours truly
+ * Ganeti has a major upgrade! there were concerns about the upgrade
+   path, not sure how that turned out
+
 ## New packages
 
  * the Wayland rewrite of [i3](https://i3wm.org/), [sway](http://swaywm.org/)
+ * [podman](https://tracker.debian.org/pkg/libpod), a Docker replacement
 
 ## My packages
 
@@ -172,20 +182,24 @@ In packages I maintain, those are the important changes:
 
 This table summarizes package version changes I find interesting.
 
-| Package     | Buster | Bullseye | Notes                                                                                                         |
-|-------------|--------|----------|---------------------------------------------------------------------------------------------------------------|
-| Browserpass | 2.0    | 3.7      | Major usability improvements                                                                                  |
-| Docker      | 18     | 20       | Docker made it for a second release                                                                           |
-| Emacs       | 26     | 27       | JSON parsing for LSP? ~/.config/emacs/? harfbuzz?? oh my! [details](https://emacsredux.com/blog/2020/08/13/emacs-27-1/)                                        |
-| Firefox     | 68     | 78       | 78 was already in buster-updates                                                                              |
-| GNOME       | 3.30   | 3.38     | Missed the "GNOME 40" release                                                                                 |
-| Inkscap     | 0.92   | 1.0      | Finally, 1.0!                                                                                                 |
-| Libreoffice | 6.2    | 7.0      |                                                                                                               |
-| OpenSSH     | 7.9    | 8.4      | [FIDO/U2F, Include][8.2], [signatures][8.1], [quantum-resistant key exchange, key fingerprint as confirmation][8.0] |
-| Postgresql  | 11     | 13       |                                                                                                               |
-| Python      | 3.7    | 3.9      | walrus operator, importlib.metadata, dict unions, zoneinfo                                                    |
-| Puppet      | 5.5    | 5.5      | Missed the Puppet 6 (and 7!) releases                                                                         |
-
+| Package     | Buster | Bullseye | Notes                                                                                                                   |
+|-------------|--------|----------|-------------------------------------------------------------------------------------------------------------------------|
+| APT         | 1.8    | 2.2      | [2.0][apt-2.0], [2.2][apt-2.2]                                                                                          |
+| Browserpass | 2.0    | 3.7      | Major usability improvements                                                                                            |
+| Docker      | 18     | 20       | Docker made it for a second release                                                                                     |
+| Emacs       | 26     | 27       | JSON parsing for LSP? ~/.config/emacs/? harfbuzz?? oh my! [details](https://emacsredux.com/blog/2020/08/13/emacs-27-1/) |
+| Firefox     | 68     | 78       | 78 was already in buster-updates                                                                                        |
+| Ganeti      | 2.16.0 | 3.0.1    | breaking upgrade?                                                                                                       |
+| GNOME       | 3.30   | 3.38     | Missed the "GNOME 40" release                                                                                           |
+| Inkscap     | 0.92   | 1.0      | Finally, 1.0!                                                                                                           |
+| Libreoffice | 6.2    | 7.0      |                                                                                                                         |
+| OpenSSH     | 7.9    | 8.4      | [FIDO/U2F, Include][8.2], [signatures][8.1], [quantum-resistant key exchange, key fingerprint as confirmation][8.0]     |
+| Postgresql  | 11     | 13       |                                                                                                                         |
+| Python      | 3.7    | 3.9      | walrus operator, importlib.metadata, dict unions, zoneinfo                                                              |
+| Puppet      | 5.5    | 5.5      | Missed the Puppet 6 (and 7!) releases                                                                                   |
+
+[apt-2.2]: https://blog.jak-linux.org/2021/02/18/apt-2.2/
+[apt-2.0]: https://blog.jak-linux.org/2020/03/07/apt-2.0/
 [8.0]: http://www.openssh.com/txt/release-8.0
 [8.1]: http://www.openssh.com/txt/release-8.1
 [8.2]: http://www.openssh.com/txt/release-8.2

approve comment
diff --git a/blog/2021-05-24-leaving-freenode/comment_1_b2b051b91b3c95fbcdb0b8d4fd3dcd11._comment b/blog/2021-05-24-leaving-freenode/comment_1_b2b051b91b3c95fbcdb0b8d4fd3dcd11._comment
new file mode 100644
index 00000000..ba01fe8b
--- /dev/null
+++ b/blog/2021-05-24-leaving-freenode/comment_1_b2b051b91b3c95fbcdb0b8d4fd3dcd11._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ ip="24.200.158.126"
+ claimedauthor="sdk"
+ subject="Bridging multiple IRC channels"
+ date="2021-05-27T14:54:14Z"
+ content="""
+It's possible to bridge multiple IRC channels on different networks with Matrix bridges as long as the IRC network permits it. If a network doesn't permit it, you can always use a bot like [Matterbridge](https://github.com/42wim/matterbridge) to relay messages between channels. The integration isn't as transparent as with a Matrix bridge because messages with be viewed as being sent by the bot but it's definitely better than nothing if you really need that functionality.
+"""]]

fixup structure
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index f1cfc4c5..f7c5ca35 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -2,8 +2,11 @@
 
 Update: I didn't buy a new, powerful, laptop for my work, but a
 NUC. See [[hardware/curie]] for details. When my travel laptop finally
-died, I bought a X220 as a replacement, see [[hardware/angela]]
-for details.
+died, I bought a X220, then a Purism Librem 13v4 as a replacement, see
+[[hardware/angela]] for details.
+
+Reviewed models
+===============
 
 [[!map pages="page(hardware/laptop/*)" show=title]]
 

approve comment
diff --git a/blog/2021-05-24-leaving-freenode/comment_1_7b4b524b75d10b9f4f0c3c9210c1afd4._comment b/blog/2021-05-24-leaving-freenode/comment_1_7b4b524b75d10b9f4f0c3c9210c1afd4._comment
new file mode 100644
index 00000000..2709d3f4
--- /dev/null
+++ b/blog/2021-05-24-leaving-freenode/comment_1_7b4b524b75d10b9f4f0c3c9210c1afd4._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ ip="85.212.172.65"
+ claimedauthor="Martin"
+ subject="XMPP chat"
+ date="2021-05-26T13:53:42Z"
+ content="""
+> As often is the case with XMPP, client support was not uniform...
+
+IMHO, Matrix shares this feature with Jabber. As a Debian user, I have the choice between nheko, spectral, and quaternion, which have pretty different feature sets. Element does not exist [in Debian] :-)
+
+Federated, open protocols (IRC, Email, Jabber/XMPP, Matrix) always will have multiple clients with different feature sets. That's strength, not weakness, despite its downsides.
+
+Btw. I'm using IRC (both libera.chat and oftc) via Jabber and Biboumi, too!
+
+> if you like XML
+
+Note, that XML is an implementation detail invisible to Jabber users, as use of JSON is invisible to users of Matrix.
+"""]]

Archival link:

The above link creates a machine-readable RSS feed that can be used to easily archive new changes to the site. It is used by internal scripts to do sanity checks on new entries in the wiki.

Created . Edited .