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.

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.
+"""]]

typos
diff --git a/blog/2021-05-24-leaving-freenode/comment_4_6993dd530e4740bbb25d84c807f72693._comment b/blog/2021-05-24-leaving-freenode/comment_4_6993dd530e4740bbb25d84c807f72693._comment
index 6b22d997..d739dd1a 100644
--- a/blog/2021-05-24-leaving-freenode/comment_4_6993dd530e4740bbb25d84c807f72693._comment
+++ b/blog/2021-05-24-leaving-freenode/comment_4_6993dd530e4740bbb25d84c807f72693._comment
@@ -9,11 +9,11 @@ While I'm trying my best to be objective, in general, this here is my personal b
 
 >  But matrix isn't \"the best and the newest\".
 
-I didn't actually use those words, so those quotes are also misplaced. What I actually used is pretty close: it's "latest and greatest", which is a common expression; I didn't really mean "greatest" in the litteral sense here.
+I didn't actually use those words, so those quotes are also misplaced. What I actually used is pretty close: it's "latest and greatest", which is a common expression; I didn't really mean "greatest" in the literal sense here...
 
 > It may be the most recent, but the software ecosystem around XMPP is very active, if not more than Matrix one. I won't dissert about how XMPP is best than Matrix. That would be too subjective.
 
-Well you're certainly hinting at that. I personnally find are actually quite similar at the technical level, and what I'm arguing is that there's a lot more inertia around Matrix than XMPP.
+Well you're certainly hinting at that. I personally find both are actually quite similar at the technical level, and what I'm arguing is that there's a lot more inertia around Matrix than XMPP.
 
 I was a big XMPP fan, in my days. I almost managed to switch away from IRC, with the bridges that were mentioned here before. I was talking with people on Google mail through it, it was great. But then Google (and Facebook) basically destroyed XMPP (from my perspective) by pulling the plug on interoperability. A classic case of "embrace and extinguish". And now I use bitlbee (over irc!) when I need such interoperability.
 

*another* XMPP response, sigh.
diff --git a/blog/2021-05-24-leaving-freenode/comment_4_6993dd530e4740bbb25d84c807f72693._comment b/blog/2021-05-24-leaving-freenode/comment_4_6993dd530e4740bbb25d84c807f72693._comment
new file mode 100644
index 00000000..6b22d997
--- /dev/null
+++ b/blog/2021-05-24-leaving-freenode/comment_4_6993dd530e4740bbb25d84c807f72693._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""re: xmpp/matrix"""
+ date="2021-05-26T13:34:02Z"
+ content="""
+> objectivism
+
+While I'm trying my best to be objective, in general, this here is my personal blog, and I don't have a strong requirement for objectivity as I would have when (say) I wrote for LWN.net. So while I welcome the feedback, I think it's misplaced.
+
+>  But matrix isn't \"the best and the newest\".
+
+I didn't actually use those words, so those quotes are also misplaced. What I actually used is pretty close: it's "latest and greatest", which is a common expression; I didn't really mean "greatest" in the litteral sense here.
+
+> It may be the most recent, but the software ecosystem around XMPP is very active, if not more than Matrix one. I won't dissert about how XMPP is best than Matrix. That would be too subjective.
+
+Well you're certainly hinting at that. I personnally find are actually quite similar at the technical level, and what I'm arguing is that there's a lot more inertia around Matrix than XMPP.
+
+I was a big XMPP fan, in my days. I almost managed to switch away from IRC, with the bridges that were mentioned here before. I was talking with people on Google mail through it, it was great. But then Google (and Facebook) basically destroyed XMPP (from my perspective) by pulling the plug on interoperability. A classic case of "embrace and extinguish". And now I use bitlbee (over irc!) when I need such interoperability.
+
+The main reason why I haven't switched to Matrix just yet is mostly because it's not a full bitlbee replacement (and nor is XMPP, last I checked).
+
+> Also instead of choosing libera blindly without thinking, just use the network you're the most comfortable on, and if possible one which you know personally the staff. Going nuts about migrating on libera is stupid and makes no sense 
+
+Well thanks for calling me, FOSDEM, Wikipedia, CentOS, Gentoo, and hundreds of free software project "stupid". I'm sure that's going to help you make a point here.
+
+It's also strange to make this comment considering I explicitly made a decision tree that basically matches your algorithm. But text, you know, who reads that nowadays...
+
+Finally, I should note that this is probably the last comment about XMPP that I approve here. It's kind of sad that the only comments I get here are from disgruntled XMPP users, upset that I don't recommend it higher in my list. Sorry folks, but we lost, and there's new stuff now. We'll be better off moving on now.
+"""]]

approve comment
diff --git a/blog/2021-05-24-leaving-freenode/comment_1_29983be80acbf4dbe5ebafeff167e3f3._comment b/blog/2021-05-24-leaving-freenode/comment_1_29983be80acbf4dbe5ebafeff167e3f3._comment
new file mode 100644
index 00000000..848756e3
--- /dev/null
+++ b/blog/2021-05-24-leaving-freenode/comment_1_29983be80acbf4dbe5ebafeff167e3f3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ ip="92.184.100.189"
+ claimedauthor="raspbeguy"
+ url="hashtagueule.fr"
+ subject="xmpp/matrix"
+ date="2021-05-25T17:40:49Z"
+ content="""
+I am a XMPP user who agreed not to tell publicly bad stuff about matrix anymore. I think we need some objectivism. The comparison you made between Matrix and XMPP is not objective.
+You're not into XMPP and are happy about Matrix, that's fine. But matrix isn't \"the best and the newest\". It may be the most recent, but the software ecosystem around XMPP is very active, if not more than Matrix one. I won't dissert about how XMPP is best than Matrix. That would be too subjective.
+
+Also instead of choosing libera blindly without thinking, just use the network you're the most comfortable on, and if possible one which you know personally the staff. Going nuts about migrating on libera is stupid and makes no sense 
+"""]]

some updates on the freenode hijack
diff --git a/blog/2021-05-24-leaving-freenode.mdwn b/blog/2021-05-24-leaving-freenode.mdwn
index 7dcd15f3..bdfe2072 100644
--- a/blog/2021-05-24-leaving-freenode.mdwn
+++ b/blog/2021-05-24-leaving-freenode.mdwn
@@ -1,6 +1,11 @@
 [[!meta title="Leaving Freenode"]]
 
-The [freenode IRC network][freenode] has been [hijacked](https://lwn.net/Articles/856543/).
+The [freenode IRC network][freenode] has been [hijacked](https://lwn.net/Articles/856543/). 
+
+TL;DR: move to [libera.chat][irc.libera.chat] or [OFTC.net][OFTC], as did countless
+free software projects including Gentoo, CentOS, KDE, Wikipedia,
+FOSDEM, and more. Debian and the Tor project were already on OFTC and
+are not affected by this.
 
 [freenode]: https://en.wikipedia.org/wiki/Freenode
 
@@ -71,19 +76,54 @@ It's a long story, but basically:
     [reverted](https://github.com/freenode/web-7.0/commit/53a47a094283bfef9adda5d8ea5fb8b369d7caa1), but not by Lee)
 
 [Andrew Lee]: https://en.wikipedia.org/wiki/Andrew_Lee_(entrepreneur)
-    
+
+Update: even though the policy change was reverted, the actual
+conversations allowed on freenode have already [degenerated into toxic
+garbage](https://twitter.com/mjg59/status/1397297559777906691). There are also massive channel takeovers (presumably
+[over 700](https://mastodon.sdf.org/@kline/106299403921451814)), mostly on channels that were redirecting to libera,
+but also [channels that were still live](https://twitter.com/laurenceb/status/1397409061348331521). Channels that were taken
+over include [#fosdem](https://twitter.com/fosdem/status/1397454352835653632), [#wikipedia](https://twitter.com/mjg59/status/1397391160906158082), [#haskell](https://octodon.social/@joeyh/106299715021240447)... 
+
+Instead of working on the network, the new "so-called freenode" staff
+is spending effort writing bots and patches to basically [automate
+taking over channels](https://lwn.net/Articles/857252/). I run an IRC network and this bot is
+obviously not standard "services" stuff... This is just grotesque.
+
+At this point I agree with [this HN comment](https://news.ycombinator.com/item?id=27287038):
+
+> We should stop implicitly legitimizing Andrew Lee's power grab by
+> referring to his dominion as "Freenode". Freenode is a
+> quarter-century-old community that has changed its name to
+> libera.chat; the thing being referred to here as "Freenode" is
+> something else that has illegitimately acquired control of
+> Freenode's old servers and user database, causing enormous
+> inconvenience to the real Freenode.
+
+I don't agree with the suggested name there, let's instead call it "so
+called freenode" as suggested later in the thread.
+
 # What now?
 
 I recommend people and organisations move away from freenode as soon
 as possible. This is a major change: documentation needs to be fixed,
 and the migration needs to be coordinated. But I do not believe we can
 trust the new freenode "owners" to operate the network reliably and in
-good faith. It's also important to use the current momentum to build a
-critical mass elsewhere so that people don't end up on freenode again
-by default and find an even more toxic community than your typical
+good faith. 
+
+It's also important to use the current momentum to build a critical
+mass elsewhere so that people don't end up on freenode again by
+default and find an even more toxic community than your typical
 run-of-the-mill free software project (which is already not a high bar
 to meet).
 
+Update: people are moving to libera in droves. It's now reaching
+18,000 users, which is bigger than OFTC and getting close to the
+largest, traditionnal, IRC networks (EFnet, Undernet, IRCnet are in
+the 10-20k users range). so-called freenode is still larger, currently
+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).
+
 # Where do I move to?
 
 The first thing you should do is to figure out which tool to use for

response
diff --git a/blog/2021-05-24-leaving-freenode/comment_2_ec9cdaf3776fe317dccbda709117a7e2._comment b/blog/2021-05-24-leaving-freenode/comment_2_ec9cdaf3776fe317dccbda709117a7e2._comment
new file mode 100644
index 00000000..35072bbe
--- /dev/null
+++ b/blog/2021-05-24-leaving-freenode/comment_2_ec9cdaf3776fe317dccbda709117a7e2._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""XMPP chat"""
+ date="2021-05-25T13:12:33Z"
+ content="""
+> [...] can't really follow why you consider the \"chat room story\" is not good there
+
+Well, it's been a while since I have used chat rooms in XMPP, but I seem to recall the capabilities there were limited. As often is the case with XMPP, client support was not uniform and you had to use that special clients to do more advanced things like moderation and so on.
+
+This is a problem on the Matrix side as well, of course: the ecosystem is maturing at variable speed and you have to use their Electron-based "Element" client to get all the shiny new features, but at least there's an "official" client which does it all.
+
+> Also, as you mentioned the Matrix IRC bridges: Whenever I have to use an IRC chat room I do so by using an XMPP gateway (biboumi) which works great. ;-)
+
+Yeah well, let's just say my experience with *that* was definitely "not great". :) But it's been a while, maybe things have improved significantly in XMPP land since I last looked.
+
+> I am using XMPP daily (1-1 with friends and family, small private groupchats with friends and family, large public groupchats)
+
+As I said in the article, it really depends: I basically *never* use XMPP, and my upstream provider is likely to discontinue its service some time this year. When that last happened, I migrated to a new one, but this time I'm thinking of just leaving since I have no use for it.
+
+If you use it daily, then it might be good to move your stuff there, but keep in mind that people who don't use XMPP might have trouble connecting with you (which is less a problem with Matrix because of the web gateways).
+
+"""]]

approve comment
diff --git a/blog/2021-05-24-leaving-freenode/comment_1_d1ff658eb95ec641519fadc4049f9835._comment b/blog/2021-05-24-leaving-freenode/comment_1_d1ff658eb95ec641519fadc4049f9835._comment
new file mode 100644
index 00000000..8b39c714
--- /dev/null
+++ b/blog/2021-05-24-leaving-freenode/comment_1_d1ff658eb95ec641519fadc4049f9835._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ ip="93.198.215.127"
+ claimedauthor="Martin"
+ url="mdosch.de"
+ subject="XMPP"
+ date="2021-05-25T10:22:24Z"
+ content="""
+> XMPP/Jabber also still exists, if you're into that kind of stuff, but I don't think the \"chat room\" story is great there, at least not as good as Matrix
+
+I am using XMPP daily (1-1 with friends and family, small private groupchats with friends and family, large public groupchats) and can't really follow why you consider the \"chat room story\" is not good there?
+
+Also, as you mentioned the Matrix IRC bridges: Whenever I have to use an IRC chat room I do so by using an XMPP gateway (biboumi) which works great. ;-)
+"""]]

nazi change reverted
diff --git a/blog/2021-05-24-leaving-freenode.mdwn b/blog/2021-05-24-leaving-freenode.mdwn
index 1c7109eb..7dcd15f3 100644
--- a/blog/2021-05-24-leaving-freenode.mdwn
+++ b/blog/2021-05-24-leaving-freenode.mdwn
@@ -67,7 +67,8 @@ It's a long story, but basically:
     accused of [taking over a channel](https://www.devever.net/~hl/freenode_abuse), in a grotesque abuse of
     power; then [changing freenode policy](https://github.com/freenode/web-7.0/pull/513/files) to not only justify the
     abuse, but also remove rules against hateful speech, effectively
-    allowing nazis on the network
+    allowing nazis on the network (update: the change was
+    [reverted](https://github.com/freenode/web-7.0/commit/53a47a094283bfef9adda5d8ea5fb8b369d7caa1), but not by Lee)
 
 [Andrew Lee]: https://en.wikipedia.org/wiki/Andrew_Lee_(entrepreneur)
     
@@ -189,7 +190,7 @@ change it everywhere.
 
 This is a sad time for IRC in general, and freenode in
 particular. It's a real shame that the previous freenode staff have
-been kicked out, and it's especially horrible that the new policies of
+been kicked out, and it's especially horrible <del>that</del> if the new policies of
 the network are basically making the network open to nazis. I wish
 things would have gone out differently: now we have yet another fork
 in the IRC history. While it's not the first time freenode changes

expand on my outrage machine, publish
diff --git a/blog/2021-05-24-leaving-freenode.mdwn b/blog/2021-05-24-leaving-freenode.mdwn
index 1ff00cb9..1c7109eb 100644
--- a/blog/2021-05-24-leaving-freenode.mdwn
+++ b/blog/2021-05-24-leaving-freenode.mdwn
@@ -30,12 +30,13 @@ and worker power, and this might taint this analysis.
 It's a long story, but basically:
 
  1. back in 2017, the former head of staff sold the freenode.net
-    domain to [Andrew Lee][], "American entrepreneur, software
-    developer and writer", and, rather weirdly, supposedly "crown
-    prince of Korea" although that part is kind of complex (see [House
-    of Yi](https://en.wikipedia.org/wiki/House_of_Yi), [Yi Won](https://en.wikipedia.org/wiki/Yi_Won), and [Yi Seok](https://en.wikipedia.org/wiki/Yi_Seok)). It should be noted the
-    [Korean Empire](https://en.wikipedia.org/wiki/Korean_Empire) hasn't existed for over a century at this point
-    (even though [its flag](https://en.wikipedia.org/wiki/Flag_of_South_Korea), also weirdly, remains)
+    domain (and its related company) to [Andrew Lee][], "American
+    entrepreneur, software developer and writer", and, rather weirdly,
+    supposedly "crown prince of Korea" although that part is kind of
+    complex (see [House of Yi](https://en.wikipedia.org/wiki/House_of_Yi), [Yi Won](https://en.wikipedia.org/wiki/Yi_Won), and [Yi Seok](https://en.wikipedia.org/wiki/Yi_Seok)). It
+    should be noted the [Korean Empire](https://en.wikipedia.org/wiki/Korean_Empire) hasn't existed for over a
+    century at this point (even though [its flag](https://en.wikipedia.org/wiki/Flag_of_South_Korea), also weirdly,
+    remains)
 
  2. back then, this was only known to the public as this strange [PIA
     and freenode joining forces](https://freenode.net/news/pia-fn) gimmick. it was suspicious at
@@ -184,6 +185,8 @@ 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.
 
+# Last words
+
 This is a sad time for IRC in general, and freenode in
 particular. It's a real shame that the previous freenode staff have
 been kicked out, and it's especially horrible that the new policies of
@@ -194,8 +197,16 @@ name (it was called OPN before), now the old freenode is still around
 and this will bring much confusion to the world, especially since the
 new freenode staff is still claiming to support FOSS.
 
-I guess it's time for this old thing to die already, but that's still
-a sad day in internet history. Then again, maybe [IRC will never
+I understand there are many sides to this story, and some people were
+[deeply hurt](https://gist.github.com/prawnsalad/4ca20da6c2295ddb06c1646791c61953) by all this. But for me, it's completely unacceptable
+to keep pushing your staff so hard that they basically *all* (except
+one?) resign in protest. For me, that's leadership failure at the
+utmost, and a complete disgrace. And of course, I can't in good
+conscience support or join a network that allows hate speech.
+
+Regardless of the fate of whatever we'll call what's left of freenode,
+maybe it's time for this old IRC thing to die already. It's still a
+sad day in internet history, but then again, maybe [IRC will never
 die](https://xkcd.com/1782/)...
 
-[[!tag draft]]
+[[!tag irc debian-planet python-planet news history]]

leaving freenode
diff --git a/blog/2021-05-24-leaving-freenode.mdwn b/blog/2021-05-24-leaving-freenode.mdwn
new file mode 100644
index 00000000..1ff00cb9
--- /dev/null
+++ b/blog/2021-05-24-leaving-freenode.mdwn
@@ -0,0 +1,201 @@
+[[!meta title="Leaving Freenode"]]
+
+The [freenode IRC network][freenode] has been [hijacked](https://lwn.net/Articles/856543/).
+
+[freenode]: https://en.wikipedia.org/wiki/Freenode
+
+# What is freenode and why should I care?
+
+[freenode][] is the largest remaining [IRC][] network. Before this
+incident, it had close to 80,000 users, which is small in terms of
+modern internet history -- even small social networks are larger by
+multiple orders of magnitude -- but is large in IRC history. The IRC
+network is also extensively used by the free software community, being
+the default IRC network on many programs, and used by hundreds if not
+thousands of free software projects.
+
+I have been using freenode since at least 2006.
+
+This matters if you care about IRC, the internet, open protocols,
+decentralisation, and, to a certain extent, federation as well. It
+also touches on who has the right on network resources: the people who
+"own" it (through money) or the people who make it work (through their
+labor). I am biased towards open protocols, the internet, federation,
+and worker power, and this might taint this analysis.
+
+[IRC]: https://en.wikipedia.org/wiki/IRC
+
+# What happened?
+
+It's a long story, but basically:
+
+ 1. back in 2017, the former head of staff sold the freenode.net
+    domain to [Andrew Lee][], "American entrepreneur, software
+    developer and writer", and, rather weirdly, supposedly "crown
+    prince of Korea" although that part is kind of complex (see [House
+    of Yi](https://en.wikipedia.org/wiki/House_of_Yi), [Yi Won](https://en.wikipedia.org/wiki/Yi_Won), and [Yi Seok](https://en.wikipedia.org/wiki/Yi_Seok)). It should be noted the
+    [Korean Empire](https://en.wikipedia.org/wiki/Korean_Empire) hasn't existed for over a century at this point
+    (even though [its flag](https://en.wikipedia.org/wiki/Flag_of_South_Korea), also weirdly, remains)
+
+ 2. back then, this was only known to the public as this strange [PIA
+    and freenode joining forces](https://freenode.net/news/pia-fn) gimmick. it was suspicious at
+    first, but since the network kept running, no one paid much
+    attention to it. opers of the network were similarly reassured
+    that Lee would have no say in the management of the network
+
+ 3. this all changed recently when Lee asserted ownership of the
+    freenode.net domain and started meddling in the operations of the
+    network, [according to this summary](https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409). this part is disputed,
+    but it is corroborated by almost a *dozen* former staff which
+    collectively resigned from the network in protest, after legal
+    threats, when it was obvious freenode was lost.
+
+ 4. the departing freenode staff founded a new network,
+    [irc.libera.chat][], based on the new ircd they were working on
+    with [OFTC][], [solanum](https://solanum.chat/)
+
+[OFTC]: https://oftc.net/
+[irc.libera.chat]: https://libera.chat/
+
+ 5. meanwhile, bot armies started attacking all IRC networks: both
+    libera and freenode, but also OFTC and unrelated networks like a
+    small one I help operate. those attacks have mostly stopped as of
+    this writing (2021-05-24 17:30UTC)
+
+ 6. on freenode, however, things are going for the worse: Lee has been
+    accused of [taking over a channel](https://www.devever.net/~hl/freenode_abuse), in a grotesque abuse of
+    power; then [changing freenode policy](https://github.com/freenode/web-7.0/pull/513/files) to not only justify the
+    abuse, but also remove rules against hateful speech, effectively
+    allowing nazis on the network
+
+[Andrew Lee]: https://en.wikipedia.org/wiki/Andrew_Lee_(entrepreneur)
+    
+# What now?
+
+I recommend people and organisations move away from freenode as soon
+as possible. This is a major change: documentation needs to be fixed,
+and the migration needs to be coordinated. But I do not believe we can
+trust the new freenode "owners" to operate the network reliably and in
+good faith. It's also important to use the current momentum to build a
+critical mass elsewhere so that people don't end up on freenode again
+by default and find an even more toxic community than your typical
+run-of-the-mill free software project (which is already not a high bar
+to meet).
+
+# Where do I move to?
+
+The first thing you should do is to figure out which tool to use for
+interactive user support. There are multiple alternatives, of course
+-- this is the internet after all -- but here is a short list of
+suggestions, in preferred priority order:
+
+ 1. [irc.libera.chat][]
+ 2. [irc.OFTC.net][OFTC]
+ 3. [Matrix.org][], which bridges with OFTC and (hopefully soon) [with
+    libera](https://github.com/matrix-org/matrix-appservice-irc/issues/1324) as well, modern IRC alternative
+ 4. [XMPP/Jabber][XMPP] also still exists, if you're into that kind of
+    stuff, but I don't think the "chat room" story is great there, at
+    least not as good as Matrix
+
+[XMPP]: https://xmpp.org/
+[Matrix.org]: https://matrix.org/
+
+Basically, the decision tree is this:
+
+ * if you want to stay on IRC:
+   * if you are already on many OFTC channels and few freenode
+     channels: **move to OFTC**
+   * if you are more inclined to support the previous freenode staff:
+     **move to libera**
+   * if you care about matrix users (in the short term): **move to
+     OFTC**
+ * if you are ready to leave IRC:
+   * if you want the latest and greatest: **move to Matrix**
+   * if you like XML and already use XMPP: **move to XMPP**
+
+Frankly, at this point, everyone should seriously consider moving to
+Matrix. The user story is great, the web is a first class user, it
+supports E2EE (although XMPP as well), and has a lot of momentum
+behind it. It even bridges with IRC well (which is not the case for
+XMPP) so if you're worried about problems like this happening again.
+
+(Indeed, I wouldn't be surprised if similar drama happens on OFTC or
+libera in the future. The history of IRC is *full* of such epic
+controversies, takeovers, sabotage, attacks, technical flamewars, and
+other silly things. I am not sure, but I suspect a federated model
+like Matrix might be more resilient to conflicts like this one.)
+
+Changing protocols might mean losing a bunch of users however: not
+everyone is ready to move to Matrix, for example. Graybeards like me
+have been using irssi for years, if not decades, and would take quite
+a bit of convincing to move elsewhere.
+
+I have mostly kept my channels on IRC, and moved either to OFTC or
+libera. In retrospect, I think I might have moved everything to OFTC
+if I would have thought about it more, because almost all of my
+channels are there. But I kind of expect a lot of the freenode
+community to move to libera, so I am keeping a socket open there
+anyways.
+
+# How do I move?
+
+The first thing you should do is to update documentation, websites,
+and source code to stop pointing at freenode altogether. [This is what
+I did for feed2exec](https://gitlab.com/anarcat/feed2exec/-/commit/bbb1a3995dc6bb9c392a0295c2fe85ea5915aca9), for example. You need to let people know in
+the current channel as well, and possibly shutdown the channel on
+freenode.
+
+Since my channels are either small or empty, I took the radical
+approach of:
+
+ * redirecting the channel to `##unavailable` which is historically
+   the way we show channels have moved to another network
+ * make the channel invite-only (which effectively enforces the
+   redirection)
+ * kicking everyone out of the channel
+ * kickban people who rejoin
+ * set the topic to announce the change
+
+In IRC speak, the following commands should do all this:
+
+    /msg ChanServ set #anarcat mlock +if ##unavailable
+    /msg ChanServ clear #anarcat users moving to irc.libera.chat
+    /msg ChanServ set #anarcat restricted on
+    /topic #anarcat this channel has moved to irc.libera.chat
+
+If the channel is not registered, the following might work
+
+    /mode #anarcat +if ##unavailable
+
+Then you can leave freenode altogether:
+
+    /disconnect Freenode unacceptable hijack, policy changes and takeovers. so long and thanks for all the fish.
+
+Keep in mind that some people have been unable to setup such
+redirections, because the new freenode staff have taken over their
+channel, in which case you're out of luck...
+
+Some people have expressed concern about their private data hosted at
+freenode as well. If you care about this, you can always talk to
+`NickServ` and `DROP` your nick. Be warned, however, that this assumes
+good faith of the network operators, which, at this point, is kind of
+futile. I would assume any data you have registered on there
+(typically: your NickServ password and email address) to be
+compromised and leaked. If your password is used elsewhere (tsk, tsk),
+change it everywhere.
+
+This is a sad time for IRC in general, and freenode in
+particular. It's a real shame that the previous freenode staff have
+been kicked out, and it's especially horrible that the new policies of
+the network are basically making the network open to nazis. I wish
+things would have gone out differently: now we have yet another fork
+in the IRC history. While it's not the first time freenode changes
+name (it was called OPN before), now the old freenode is still around
+and this will bring much confusion to the world, especially since the

(Diff truncated)

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 .