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.

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)
another shop
diff --git a/hardware/audio.mdwn b/hardware/audio.mdwn
index 7f97a197..6edebaa2 100644
--- a/hardware/audio.mdwn
+++ b/hardware/audio.mdwn
@@ -282,8 +282,9 @@ sell the gear:
  * [Long & McQuade](https://www.long-mcquade.com/locations/Quebec/): 10715, boulevard Pie-IX Phone: 514-388-9259,
    10h-~17h, ~65$ for mixer/amp/mikes rental
  * [Music Red One](https://musicredone.com/): 2069 Avenue Chartier, Dorval, +1-514-225-2226
- * [Nantel](https://www.nantelmusique.ca/default.aspx?pageId=5&lang=fr): same
+ * [Nantel](https://www.nantelmusique.ca/default.aspx?pageId=5&lang=fr): instruments rental, not much gear
  * [Twigg](https://www.twiggmusique.com/fr/service/location-montreal/): same
+ * [Studio Economik](http://economik.com/): nice gear, good prices, studio rental
  * [Solotech](https://www.solotech.com/contact-us/):  8-17h,  ~140$ for mixer/amp/mikes rental
  * [Steve's](https://stevesmusic.com/en/contacts/): 150 st-antoine, 97$ for mixer/amp/mikes rental, 15$
    par mike, 10-17h, 1-877-978-3837

it's actually in debian, thanks twb
diff --git a/blog/2020-03-10-font-changes.mdwn b/blog/2020-03-10-font-changes.mdwn
index ea0c6df6..bff6a116 100644
--- a/blog/2020-03-10-font-changes.mdwn
+++ b/blog/2020-03-10-font-changes.mdwn
@@ -32,8 +32,9 @@ alternatives. I found the following packages in debian:
  * [fonts-monoid](https://tracker.debian.org/fonts-monoid): ligatures, feels much "thinner" than jetbrains
  * [fonts-mononoki](https://tracker.debian.org/fonts-mononoki): no ligatures, looks good, suggested by the
    fonts team as part of [fonts-recommended](https://tracker.debian.org/fonts-recommended)
- * [fonts-agave](https://tracker.debian.org/pkg/fonts-agave):
-   recommended by tarzeau
+ * [fonts-agave](https://tracker.debian.org/pkg/fonts-agave): recommended by tarzeau
+ * [fonts-cascadia-code](https://tracker.debian.org/pkg/fonts-cascadia-code): ligatures, multilingual, new default for
+   [Windows Terminal](https://en.wikipedia.org/wiki/Windows_Terminal)
 
 Those are also "programmer fonts" that caught my interest but somehow
 didn't land in Debian yet:
@@ -42,8 +43,6 @@ didn't land in Debian yet:
  * [Iosevka](https://typeof.net/Iosevka/): ligatures, multilingual
  * [Adobe's source code pro](http://adobe-fonts.github.io/source-code-pro/): [RFP](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736681)
  * [spleen](https://github.com/fcambus/spleen): [RFS](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985447)
- * [cascadia code](https://github.com/microsoft/cascadia-code): ligatures, multilingual, new default for
-   [Windows Terminal](https://en.wikipedia.org/wiki/Windows_Terminal)
 
 Because Fira code had ligatures, i ended up giving it a shot. I really
 like the originality of the font. See, for example, how the `@` sign

another font
diff --git a/blog/2020-03-10-font-changes.mdwn b/blog/2020-03-10-font-changes.mdwn
index 6b903c38..ea0c6df6 100644
--- a/blog/2020-03-10-font-changes.mdwn
+++ b/blog/2020-03-10-font-changes.mdwn
@@ -42,6 +42,8 @@ didn't land in Debian yet:
  * [Iosevka](https://typeof.net/Iosevka/): ligatures, multilingual
  * [Adobe's source code pro](http://adobe-fonts.github.io/source-code-pro/): [RFP](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736681)
  * [spleen](https://github.com/fcambus/spleen): [RFS](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985447)
+ * [cascadia code](https://github.com/microsoft/cascadia-code): ligatures, multilingual, new default for
+   [Windows Terminal](https://en.wikipedia.org/wiki/Windows_Terminal)
 
 Because Fira code had ligatures, i ended up giving it a shot. I really
 like the originality of the font. See, for example, how the `@` sign

expand on the password hash change stuff
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index c98209ed..47bcc30c 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -143,7 +143,9 @@ noticed.
    savings when playing video, see [this note](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#new-vaapi-default-driver)
  * [password hashes have changed](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#pam-default-password) to [yescrypt](https://www.openwall.com/yescrypt/) (recognizable
    from its `$y$` prefix), a major change from the previous default,
-   SHA-512 (recognizable from its `$6$` prefix, see [crypt(5)](https://manpages.debian.org/crypt.5))
+   SHA-512 (recognizable from its `$6$` prefix), see also
+   [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
 
 ## New packages
 

another leguin quote
diff --git a/fortunes.txt b/fortunes.txt
index 63a35904..2a51aae2 100644
--- a/fortunes.txt
+++ b/fortunes.txt
@@ -1166,3 +1166,8 @@ happier if it is called "the People's Stick."
 No theory, no ready-made system, no book that has ever been written
 will save the world. I cleave to no system. I am a true seeker.
                         - Mikhail Bakunin
+%
+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

more places where my key lives, sigh
diff --git a/.well-known/openpgpkey/Makefile b/.well-known/openpgpkey/Makefile
index 2a525ec8..4d5eaa5b 100644
--- a/.well-known/openpgpkey/Makefile
+++ b/.well-known/openpgpkey/Makefile
@@ -19,6 +19,10 @@ upload:
 	gpg --keyserver keyring.debian.org --send-keys $(FINGERPRINT)
 	gpg --keyserver keys.openpgp.org --send-keys $(FINGERPRINT)
 	gpg --keyserver pool.sks-keyservers.net --send-keys $(FINGERPRINT)
+	@echo "Not covered: GitLab and GitHub accounts:"
+	@echo "https://gitlab.torproject.org/-/profile/gpg_keys"
+	@echo "https://gitlab.com/-/profile/gpg_keys"
+	@echo "https://github.com/settings/keys"
 
 renew:
 	gpg --quick-set-expire $(FINGERPRINT) $(NEXT_EXPIRE)

fix ordering: the default showed the warning at the end
diff --git a/.well-known/openpgpkey/Makefile b/.well-known/openpgpkey/Makefile
index ea4efcd6..2a525ec8 100644
--- a/.well-known/openpgpkey/Makefile
+++ b/.well-known/openpgpkey/Makefile
@@ -1,12 +1,14 @@
-.PHONY: all hu upload renew upload-tpo
+.PHONY: all warn hu upload renew upload-tpo
 
 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/
 
-all: hu upload
-	@echo "run $(MAKE) renew all upload-tpo to make a full renewal"
+all: warn hu upload
+
+warn:
+	@echo "run '$(MAKE) renew hu upload upload-tpo' to make a full renewal"
 	@echo "this is not default because 'renew' and 'upload-tpo' are not idempotent"
 
 hu:

renew my OpenPGP key for another year
I may switch to ed25519, SSH ecdsa-sk, change keycards, or give up on
the entire thing eventually, but for now this will fix the immediate
problem I have set for myself every year.
diff --git a/.well-known/openpgpkey/hu/myctwj4an6ne7htuzyoo8osctuji68xe b/.well-known/openpgpkey/hu/myctwj4an6ne7htuzyoo8osctuji68xe
index 87688745..224f3439 100644
Binary files a/.well-known/openpgpkey/hu/myctwj4an6ne7htuzyoo8osctuji68xe and b/.well-known/openpgpkey/hu/myctwj4an6ne7htuzyoo8osctuji68xe differ

fix typo
diff --git a/.well-known/openpgpkey/Makefile b/.well-known/openpgpkey/Makefile
index 7556a141..ea4efcd6 100644
--- a/.well-known/openpgpkey/Makefile
+++ b/.well-known/openpgpkey/Makefile
@@ -7,7 +7,7 @@ TPO_KEYRING=~/src/tor/account-keyring/
 
 all: hu upload
 	@echo "run $(MAKE) renew all upload-tpo to make a full renewal"
-	@echo "this is not default because 'renew' and 'upload-tpo' are no idempotent"
+	@echo "this is not default because 'renew' and 'upload-tpo' are not idempotent"
 
 hu:
 	@echo "Consider switching to weasel's version in https://kushaldas.in/posts/setting-up-wkd.html"

also push to alberti
diff --git a/.well-known/openpgpkey/Makefile b/.well-known/openpgpkey/Makefile
index 62f74384..7556a141 100644
--- a/.well-known/openpgpkey/Makefile
+++ b/.well-known/openpgpkey/Makefile
@@ -26,3 +26,4 @@ upload-tpo:
 	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

fix date format in expiry specification
Previous one would be (1) localized, and (2) with spaces, both of
which made GnuPG unhappy enough to just totally fail.
diff --git a/.well-known/openpgpkey/Makefile b/.well-known/openpgpkey/Makefile
index 6636f2e8..62f74384 100644
--- a/.well-known/openpgpkey/Makefile
+++ b/.well-known/openpgpkey/Makefile
@@ -2,7 +2,7 @@
 
 ADDRESS=anarcat@debian.org
 FINGERPRINT=8DC901CE64146C048AD50FBB792152527B75921E
-NEXT_EXPIRE=$(shell date -d '+1 year +1 month')
+NEXT_EXPIRE=$(shell LANG=C date -d '+1 year +1 month' '+%Y-%m-%d')
 TPO_KEYRING=~/src/tor/account-keyring/
 
 all: hu upload

simpler alternative to recordmydesktop
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 91de6973..c98209ed 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -203,7 +203,9 @@ list.
    an option here)
  * [gocode was removed](https://bugs.debian.org/976642) along with elpa-company-go, need to switch
    to gopls
- * [gtk-recordmydesktop](https://tracker.debian.org/pkg/gtk-recordmydesktop) - Python 2, dead upstream, see [bug 943983](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943983)
+ * [gtk-recordmydesktop](https://tracker.debian.org/pkg/gtk-recordmydesktop) - Python 2, dead upstream, see [bug
+   943983](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943983), [peek](https://github.com/phw/peek) ([in Debian](https://tracker.debian.org/pkg/peek)) is a great, no-frills
+   replacement
  * Python 2 support is removed! hopefully most of my stuff is already
    Python 3, but I did lose monkeysign and gameclock, as mentioned above
  * Mailman 2 is consequently removed
@@ -243,11 +245,11 @@ 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`                   | 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 |
+| `usbguard-applet-qt`  | `usbguard allow-device` | GUI just gone, but commandline might work                                          |
 
 ### Cool things I want to try
 

approve comment
diff --git a/blog/2020-03-10-font-changes/comment_1_dc3edf8f30167de3f6b290f5ccd69994._comment b/blog/2020-03-10-font-changes/comment_1_dc3edf8f30167de3f6b290f5ccd69994._comment
new file mode 100644
index 00000000..88c46908
--- /dev/null
+++ b/blog/2020-03-10-font-changes/comment_1_dc3edf8f30167de3f6b290f5ccd69994._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ ip="73.4.124.145"
+ claimedauthor="Robert Mohns"
+ url="https://www.imarc.com/about/robert-mohns"
+ subject="comment 5"
+ date="2021-05-07T16:05:11Z"
+ content="""
+Hi! I noticed the link here to my \"What’s the best font size for the web?\" post. I'm glad you found it useful!
+
+I recently discovered that my article was completely munged up by a site migration. I restored the busted calculator and cleaned up some repeated copy and some layout issues. Embarrassing, but … it's better now, and I think you'll find it more useful as well. :)
+
+I loved your post here. I really like seeing people get hands on with making their typography & readability better.
+"""]]

snapshots: check
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 3e9238a6..19756dcb 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -382,7 +382,7 @@ TODO:
         zfs snapshot bpool/BOOT/debian@install
         zfs snapshot rpool/ROOT/debian@install
 
- * [automatic snapshots](https://wiki.archlinux.org/title/ZFS#Automatic_snapshots)?
+ * [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))
  * setup services:
    * radio (DONE)
    * sonic

name tubman
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 38c28b7c..3e9238a6 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -1,3 +1,18 @@
+Tubman is named after [Harriet Tubman](https://en.wikipedia.org/wiki/Harriet_Tubman), an "*American abolitionist
+and political activist. Born into slavery, Tubman escaped and
+subsequently made some 13 missions to rescue approximately 70 enslaved
+people, including family and friends, using the network of antislavery
+activists and safe houses known as the [Underground
+Railroad](https://en.wikipedia.org/wiki/Underground_Railroad). During the [American Civil War](https://en.wikipedia.org/wiki/American_Civil_War), she served as an
+armed scout and spy for the Union Army. The first woman to lead an
+armed expedition in the war, she guided the raid at Combahee Ferry,
+which liberated more than 700 enslaved people. In her later years,
+Tubman was an activist in the movement for women's suffrage.*"
+
+> I was the conductor of the Underground Railroad for eight years, and
+> I can say what most conductors can't say — I never ran my train off
+> the track and I never lost a passenger.
+
 # Specification
 
 (copied from [[hardware/server/marcos/v1]])
diff --git a/services/dns.mdwn b/services/dns.mdwn
index ac76dfda..18e612d2 100644
--- a/services/dns.mdwn
+++ b/services/dns.mdwn
@@ -82,6 +82,7 @@ femmes. Exemples utilisés:
  * [[hardware/ursula]] ([K. Le Guin](https://en.wikipedia.org/wiki/Ursula_K._Le_Guin))
  * [[hardware/server/mafalda]] ([yes, the character](https://en.wikipedia.org/wiki/Mafalda))
  * [[hardware/server/plastik]] (a "piece of plastic")
+ * ([Harriet](https://en.wikipedia.org/wiki/Harriet_Tubman)) [[hardware/tubman]]
 
 Anciens
 -------
@@ -117,9 +118,6 @@ Les noms suivants pourraient être utilisés pour de futures machines:
    arborer le drapeau noir
  * [Séverine](https://fr.wikipedia.org/wiki/S%C3%A9verine) - journaliste, féministe, première femme à diriger un
    grand quotidien en France
- * [Harriet Tubman](https://en.wikipedia.org/wiki/Harriet_Tubman) - kick-ass self-freed slave, black women that
-   ran the underground railroad for 8 years and first women to lead an
-   army squadron in the US (in the Civil War, to free more slaves)
  * [Sojourner Truth](https://en.wikipedia.org/wiki/Sojourner_Truth) - abolotionist, first black women to win a
    court case against a black man
  * [Claudette Colvin](https://en.wikipedia.org/wiki/Claudette_Colvin) - before rosa parks, there was this rebel!

tag tubman
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 3be368fa..38c28b7c 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -463,3 +463,5 @@ Destroy:
    for the above procedure
  * [WIP PR for Bullseye root on ZFS instructions](https://github.com/openzfs/openzfs-docs/pull/126)
  * [another ZFS on linux documentation](https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/)
+
+[[!tag node]]

extra zfs docs, ssd caching
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 59938af2..3be368fa 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -310,24 +310,69 @@ says). I want to do systemd-networkd anyways.
 We performed steps 1 through 6, remaining steps are optional and
 troubleshooting.
 
+## SSD caching
+
+The machine has been installed on two HDD: spinning rust! Those are
+typically slow, but they are redundant which should ensure high
+availability. To boost performance, we're setting up a SSD cache.
+
+ZFS has two types of caches:
+
+ * write intent log (external ZIL or SLOG)
+ * layer 2 adaptive replacement cache (L2ARC)
+
+The L2ARC is purely a performance cache, and if it dies, no data is
+lost. The former, however, can cause data loss (typically a few
+seconds, but still) in case the drive dies. So we're going with L2ARC,
+based on this [source for the redundancy claim](https://www.reddit.com/r/zfs/comments/4lkv5v/can_loss_of_slog_or_l2arc_failure_on_modern/).
+
+To configure the L2ARC cache, we simply did this:
+
+    zpool add rpool cache /dev/sda3
+
+(Actually, `-f` was necessary because there already was a
+`crypto_LUKS` partition on there, which we didn't care about.)
+
+The `sda3` device is the third partition on the SSD drive. It's 465GB
+so it should provide a lot of space for the cache.
+
+The status of the cache can be found with the `zpool iostat` command:
+
+    root@tubman:~# zpool iostat -v
+                  capacity     operations     bandwidth 
+    pool        alloc   free   read  write   read  write
+    ----------  -----  -----  -----  -----  -----  -----
+    bpool       47.8M   912M      0      0      3     14
+      mirror    47.8M   912M      0      0      3     14
+        sdb3        -      -      0      0      1      7
+        sdc3        -      -      0      0      1      7
+    ----------  -----  -----  -----  -----  -----  -----
+    rpool       1.29G  3.62T      0     60    437   432K
+      mirror    1.29G  3.62T      0     60    437   432K
+        sdb4        -      -      0     30    199   216K
+        sdc4        -      -      0     30    238   216K
+    cache           -      -      -      -      -      -
+      sda3       326M   465G      0    183  4.96K  11.9M
+    ----------  -----  -----  -----  -----  -----  -----
+
 ## Next steps
 
 TODO:
 
- * SSD caching
- * configure swap? (step 7)
+ * SSD caching (DONE)
+ * configure swap? (step 7, issues with memory pressure)
  * disable log compression? (step 8.3)
  * delete install snapshots?
         
         zfs snapshot bpool/BOOT/debian@install
         zfs snapshot rpool/ROOT/debian@install
 
- * configure regular snaphots?
+ * [automatic snapshots](https://wiki.archlinux.org/title/ZFS#Automatic_snapshots)?
  * setup services:
    * radio (DONE)
    * sonic
    * paste
-   * photos
+   * photos (Nextcloud?)
    * torrent
  * static IP (DONE)
  * port forward SSH so that it doesn't land on curie (DONE)
@@ -369,6 +414,40 @@ TODO:
  * [initrd documentation](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20GNU%20Linux%20initrd%20documentation.html): booting from a snapshot, rollbacks, etc
  * [install troubleshooting](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html#troubleshooting)
 
+## ZFS primer
+
+### Information
+
+Listing partitions and snapshots:
+
+    zfs list
+
+IO statistics, every second:
+
+    zpool iostat 1
+
+### Snapshots
+
+Creating:
+
+    zfs snapshot pool/volume@LABEL
+
+Listing:
+
+    zfs list -t snapshot
+
+Listing with creation date:
+
+    zfs list -t snapshot -o name,creation
+
+Rollback:
+
+    zfs rollback pool/volume@LABEL
+
+Destroy:
+
+    zfs destroy pool/volume@LABEL
+
 ## Other documentation
 
 ### ZFS documentation
@@ -383,5 +462,4 @@ TODO:
  * [OpenZFS: Debian buster root on ZFS](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.htm): excellent documentation, basis
    for the above procedure
  * [WIP PR for Bullseye root on ZFS instructions](https://github.com/openzfs/openzfs-docs/pull/126)
- * [source for redundancy claim](https://www.reddit.com/r/zfs/comments/4lkv5v/can_loss_of_slog_or_l2arc_failure_on_modern/)
  * [another ZFS on linux documentation](https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/)

sort through some links
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 69b8e8bb..59938af2 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -324,7 +324,7 @@ TODO:
 
  * configure regular snaphots?
  * setup services:
-   * radio
+   * radio (DONE)
    * sonic
    * paste
    * photos
@@ -332,16 +332,6 @@ TODO:
  * static IP (DONE)
  * port forward SSH so that it doesn't land on curie (DONE)
  * [report back on the procedure](https://github.com/openzfs/openzfs-docs/pull/126#pullrequestreview-647650769) (DONE)
- * sort through those links:
-   * <https://wiki.debian.org/ZF>
-   * <https://www.reddit.com/r/zfs/comments/b2j66o/zfs_on_root_are_you_doing_it>
-   * <https://www.funtoo.org/ZFS_as_Root_Filesyste>
-   * <https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.htm>
-   * <https://github.com/openzfs/openzfs-docs/pull/12>
-   * <https://www.reddit.com/r/zfs/comments/4lkv5v/can_loss_of_slog_or_l2arc_failure_on_modern>
-   * <https://duckduckgo.com/?t=ffab&q=zfs+ssd+caching&ia=we>
-   * <https://startpage.com/do/metasearch.pl?query=zfs%20ssd%20cachin>
-   * <https://duckduckgo.com/?t=ffab&q=zfs+filesystem+caching>
 
 ## Decisions taken during the procedure
 
@@ -378,3 +368,20 @@ TODO:
 
  * [initrd documentation](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20GNU%20Linux%20initrd%20documentation.html): booting from a snapshot, rollbacks, etc
  * [install troubleshooting](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html#troubleshooting)
+
+## Other documentation
+
+### ZFS documentation
+
+ * [Debian wiki page](https://wiki.debian.org/ZFS): good introduction, basic commands, some
+   advanced stuff
+ * [Arch wiki page](https://wiki.archlinux.org/title/ZFS): much more stuff
+ * [Gentoo wiki page](https://wiki.gentoo.org/wiki/ZFS): less more stuff, similar to ARch
+ * [FreeBSD handbook](https://docs.freebsd.org/en/books/handbook/zfs/): FreeBSD-specific of course, but
+   excellent as always
+ * [ZFS on Linux FAQ](https://github.com/zfsonlinux/zfs/wiki/faq)
+ * [OpenZFS: Debian buster root on ZFS](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.htm): excellent documentation, basis
+   for the above procedure
+ * [WIP PR for Bullseye root on ZFS instructions](https://github.com/openzfs/openzfs-docs/pull/126)
+ * [source for redundancy claim](https://www.reddit.com/r/zfs/comments/4lkv5v/can_loss_of_slog_or_l2arc_failure_on_modern/)
+ * [another ZFS on linux documentation](https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/)

spacing
diff --git a/blog/2021-04-28-tpo-status-page.mdwn b/blog/2021-04-28-tpo-status-page.mdwn
index 43844272..8935599b 100644
--- a/blog/2021-04-28-tpo-status-page.mdwn
+++ b/blog/2021-04-28-tpo-status-page.mdwn
@@ -3,7 +3,7 @@
 The Tor Project now has a [status page](https://status.torproject.org/) which shows the state of
 our major services.
 
-**You can check[status.torprojet.org](https://status.torproject.org) for news about major outages
+**You can check [status.torprojet.org](https://status.torproject.org) for news about major outages
 in Tor services**, including v3 and v2 onion services, directory
 authorities, our website ([torproject.org](https://torproject.org)), and the
 [check.torproject.org](https://check.torproject.org/) tool. The status page also displays outages

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

publish tor blog post
It was put online on blog.torproject.org
diff --git a/blog/2021-04-28-tpo-status-page.mdwn b/blog/2021-04-28-tpo-status-page.mdwn
index 0ec9a1cf..43844272 100644
--- a/blog/2021-04-28-tpo-status-page.mdwn
+++ b/blog/2021-04-28-tpo-status-page.mdwn
@@ -87,4 +87,8 @@ when we need to. It doesn't seem like a priority at the moment.
 
 Comments and feedback are welcome!
 
-[[!tag draft]]
+----
+
+> This article was first published on the [Tor Project Blog](https://blog.torproject.org/check-status-of-tor-services).
+
+[[!tag debian-planet web sysadmin python-planet hugo markdown tor]]

more edits from torproject.org
diff --git a/blog/2021-04-28-tpo-status-page.mdwn b/blog/2021-04-28-tpo-status-page.mdwn
index 1d0e17f7..0ec9a1cf 100644
--- a/blog/2021-04-28-tpo-status-page.mdwn
+++ b/blog/2021-04-28-tpo-status-page.mdwn
@@ -1,65 +1,62 @@
 [[!meta title="Building a status page service with Hugo"]]
 
-The Tor Project now has a [status page](https://status.torproject.org/) which
-shows the state of our major services. It will be used to announce major
-outages in external (e.g. hidden services or consensus) or internal (e.g.
-GitLab) services not working. This post documents how the service was built
-and how it works.
+The Tor Project now has a [status page](https://status.torproject.org/) which shows the state of
+our major services.
+
+**You can check[status.torprojet.org](https://status.torproject.org) for news about major outages
+in Tor services**, including v3 and v2 onion services, directory
+authorities, our website ([torproject.org](https://torproject.org)), and the
+[check.torproject.org](https://check.torproject.org/) tool. The status page also displays outages
+related to Tor internal services, like our GitLab instance.
+
+This post documents why we launched
+[status.torproject.org](https://status.torproject.org), how the service was
+built, and how it works.
 
 # Why a status page
 
-The first step in setting up a service page was to realize we needed one in
-the first place. I did a [service
-survey](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021#survey-
-results) for internal users at the end of 2020 to see what could be improved,
-and one of the suggestions that came up was to "document downtimes of one hour
-or longer" and generally improve communications around monitoring. The latter
-is still on the [sysadmin
-roadmap](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021), but
-a status page seemed like a good solution for the former.
-
-Note that we already have to monitoring tools in the sysadmin team:
-[Icinga](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/nagios) (a
-fork of Nagios) and
-[Prometheus](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/prometheus/),
-with
-[Grafana](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/grafana)
-dashboards. But those are hard to understand for users. Worse, they also tend
-to generate false positives, and don't clearly show users which issues are
-critical. In the end, a manually curated dashboard provides important
-usability benefits over an automated system, and [all major organisations have
-one](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status#example-
-sites).
+The first step in setting up a service page was to realize we needed
+one in the first place. I [surveyed internal users](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021#survey- results) at the end of
+2020 to see what could be improved, and one of the suggestions that
+came up was to "document downtimes of one hour or longer" and
+generally improve communications around monitoring. The latter is
+still on the [sysadmin roadmap](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021), but a status page seemed like a
+good solution for the former.
+
+We already have two monitoring tools in the sysadmin team: [Icinga](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/nagios)
+(a fork of Nagios) and [Prometheus](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/prometheus/), with [Grafana](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/grafana)
+dashboards. But those are hard to understand for users. Worse, they
+also tend to generate false positives, and don't clearly show users
+which issues are critical.
+
+In the end, a manually curated dashboard provides important usability
+benefits over an automated system, and [all major organisations have
+one](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status#example- sites).
 
 # Picking the right tool
 
-It wasn't my first foray in status page design. In another life, I had setup a
-status page using a tool called [Cachet](https://cachethq.io/). That was
-already a great improvement over the previous solutions, which were to use
+It wasn't my first foray in status page design. In another life, I had
+setup a status page using a tool called [Cachet](https://cachethq.io/). That was already
+a great improvement over the previous solutions, which were to use
 first a wiki and then a blog to post updates. But Cachet is a complex
-[Laravel](https://laravel.com/) app, which also requires a web browser to
-update. It generally requires more maintenance than what we'd like, needing
-silly things like a SQL database and PHP web server.
+[Laravel](https://laravel.com/) app, which also requires a web browser to update. It
+generally requires more maintenance than what we'd like, needing silly
+things like a SQL database and PHP web server.
 
-So when I found [cstate](https://github.com/cstate/cstate), I was pretty
-excited. It's basically a theme for the [Hugo](https://gohugo.io/) static site
-generator, which means that it's a set of HTML, CSS, and a sprinkle of
-Javascript. And being based on Hugo means that the site is generated from a
-set of [Markdown](https://en.wikipedia.org/wiki/Markdown) files and the result
-is just plain HTML that can be hosted on any web server on the planet.
+So when I found [cstate](https://github.com/cstate/cstate), I was pretty excited. It's basically a
+theme for the [Hugo](https://gohugo.io/) static site generator, which means that it's a
+set of HTML, CSS, and a sprinkle of Javascript. And being based on
+Hugo means that the site is generated from a set of [Markdown](https://en.wikipedia.org/wiki/Markdown)
+files and the result is just plain HTML that can be hosted on any web
+server on the planet.
 
 # Deployment
 
-At first, I wanted to deploy the site through [GitLab
-CI](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/ci), but at
-that time we didn't have GitLab pages setup. Even though we do [have GitLab
-pages setup
-now](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab#publishing-
-gitlab-pages), it's not (yet) integrated with our mirroring infrastructure.
-So, for now, the source is hosted and built in our legacy
-[git](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/git) and
-[Jenkins](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/jenkins)
-services.
+At first, I wanted to deploy the site through [GitLab CI](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/ci), but at
+that time we didn't have GitLab pages set up. Even though we do [have
+GitLab pages set up now](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab#publishing- gitlab-pages), it's not (yet) integrated with our
+mirroring infrastructure.  So, for now, the source is hosted and built
+in our legacy [git](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/git) and [Jenkins](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/jenkins) services.
 
 It is nice to have the content hosted in a git repository: sysadmins can just
 edit Markdown in the git repository and push to deploy changes, no web browser
@@ -69,24 +66,24 @@ required. And it's trivial to setup a local environment to preview changes:
     firefox https://localhost:1313/
 
 Only the sysadmin team and gitolite administrators have access to the
-repository, at this stage, but that could be improved if necessary. Merge
-requests can also be issued on the [GitLab
-repository](https://gitlab.torproject.org/tpo/tpa/status-site/) and then
-pushed by authorized personnel later on, naturally.
+repository, at this stage, but that could be improved if
+necessary. Merge requests can also be issued on the [GitLab
+repository](https://gitlab.torproject.org/tpo/tpa/status-site/) and then pushed by authorized personnel later on,
+naturally.
 
 # Availability
 
-One of the concern I have is that the site is hosted inside our normal mirror
+One of the concerns I have is that the site is hosted inside our normal mirror
 infrastructure. Naturally, if an outage occurs there, the site goes down. But
 I figured it's a bridge we'll cross when we get there. Because it's so easy to
 build the site from scratch, it's actually trivial to host a copy of the site
 on _any_ GitLab server, thanks to the `.gitlab-ci.yml` file shipped (but not
-currently used) in the repository So if push comes to shove, we can just
-publish the site elsewhere and point DNS there.
+currently used) in the repository. If push comes to shove, we can just publish
+the site elsewhere and point DNS there.
 
 And, of course, if DNS fails us, then we're in trouble, but that's the
-situation anyways: we can always register a new domain name for the status
-page when we need to. It doesn't seem like a priority at the moment.
+situation anyway: we can always register a new domain name for the status page
+when we need to. It doesn't seem like a priority at the moment.
 
 Comments and feedback are welcome!
 

redraft
diff --git a/blog/2021-04-28-tpo-status-page.mdwn b/blog/2021-04-28-tpo-status-page.mdwn
index 939a911b..1d0e17f7 100644
--- a/blog/2021-04-28-tpo-status-page.mdwn
+++ b/blog/2021-04-28-tpo-status-page.mdwn
@@ -90,3 +90,4 @@ page when we need to. It doesn't seem like a priority at the moment.
 
 Comments and feedback are welcome!
 
+[[!tag draft]]

did some edits on the website, reimported with html2markdown
diff --git a/blog/2021-04-28-tpo-status-page.mdwn b/blog/2021-04-28-tpo-status-page.mdwn
index 66a8d98a..939a911b 100644
--- a/blog/2021-04-28-tpo-status-page.mdwn
+++ b/blog/2021-04-28-tpo-status-page.mdwn
@@ -1,87 +1,92 @@
 [[!meta title="Building a status page service with Hugo"]]
 
-The Tor Project now has a [status page](https://status.torproject.org/) which shows the state of
-our major services. We'll use this going forward to announce major
-outages in external (e.g. hidden services or consensus ) or internal
-(e.g. GitLab) services not working. This post documents how the
-service was built and how it works.
+The Tor Project now has a [status page](https://status.torproject.org/) which
+shows the state of our major services. It will be used to announce major
+outages in external (e.g. hidden services or consensus) or internal (e.g.
+GitLab) services not working. This post documents how the service was built
+and how it works.
 
 # Why a status page
 
-The first step in setting up a service page was to realize we needed
-one in the first place. I have made a [service survey](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021#survey-results) for internal
-users at the end of 2020 to see what could be improved, and one of the
-suggestions that came up was to "document downtimes of one hour or
-longer" and generally improve communications and monitoring. The
-latter is still on the [sysadmin roadmap](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021), but for the former, it
-seemed ideal to create a status page.
+The first step in setting up a service page was to realize we needed one in
+the first place. I did a [service
+survey](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021#survey-
+results) for internal users at the end of 2020 to see what could be improved,
+and one of the suggestions that came up was to "document downtimes of one hour
+or longer" and generally improve communications around monitoring. The latter
+is still on the [sysadmin
+roadmap](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021), but
+a status page seemed like a good solution for the former.
 
 Note that we already have to monitoring tools in the sysadmin team:
-[Icinga](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/nagios) (a fork of Nagios) and [Prometheus](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/prometheus/), with [Grafana](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/grafana)
-dashboards. But those are hard to understand for users and worse, tend
-to generate false positive, and don't clearly show users which issues
-are critical. In the end, a manually curated dashboard provides huge
-usability benefits over automated system, and [all major organisations
-have one](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status#example-sites).
+[Icinga](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/nagios) (a
+fork of Nagios) and
+[Prometheus](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/prometheus/),
+with
+[Grafana](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/grafana)
+dashboards. But those are hard to understand for users. Worse, they also tend
+to generate false positives, and don't clearly show users which issues are
+critical. In the end, a manually curated dashboard provides important
+usability benefits over an automated system, and [all major organisations have
+one](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status#example-
+sites).
 
 # Picking the right tool
 
-It wasn't my first foray in status page design. In a previous job, I
-had setup a status page using a tool called [Cachet](https://cachethq.io/), which was a
-great improvement over the previous solutions, which were to use first
-a wiki and then a blog to post updates. But Cachet is a complex
-PHP/Laravel app, and requires some work to setup and deploy. It also
-requires a web browser to update, and generally requires more
-maintenance than what we'd like.
+It wasn't my first foray in status page design. In another life, I had setup a
+status page using a tool called [Cachet](https://cachethq.io/). That was
+already a great improvement over the previous solutions, which were to use
+first a wiki and then a blog to post updates. But Cachet is a complex
+[Laravel](https://laravel.com/) app, which also requires a web browser to
+update. It generally requires more maintenance than what we'd like, needing
+silly things like a SQL database and PHP web server.
 
-So when I found about [cstate](https://github.com/cstate/cstate), I was so excited that I just set it
-up right away. It's basically a theme for the [Hugo](https://gohugo.io/) static site
+So when I found [cstate](https://github.com/cstate/cstate), I was pretty
+excited. It's basically a theme for the [Hugo](https://gohugo.io/) static site
 generator, which means that it's a set of HTML, CSS, and a sprinkle of
-Javascript. And being based on Hugo means that the site is generated
-from a set of [Markdown](https://en.wikipedia.org/wiki/Markdown) files and the result is just plain HTML
-that can be hosted on any web server on the planet.
+Javascript. And being based on Hugo means that the site is generated from a
+set of [Markdown](https://en.wikipedia.org/wiki/Markdown) files and the result
+is just plain HTML that can be hosted on any web server on the planet.
 
 # Deployment
 
-At first, I wanted to deploy the site through GitLab CI, but at that
-time we didn't have GitLab pages setup. Even though we [do have GitLab
-pages setup](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab#publishing-gitlab-pages), it's not integrated with our mirroring
-infrastructure. So, for now, the source is hosted and build in our
-[legacy git](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/git) and [Jenkins](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/jenkins) services.
-
-It is nice to have the content hosted in a git repository: sysadmins
-can just edit markdown in the git repository and push to deploy
-changes, no web browser required. And because `hugo` is fast, it's
-trivial to setup a local environment to preview changes:
+At first, I wanted to deploy the site through [GitLab
+CI](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/ci), but at
+that time we didn't have GitLab pages setup. Even though we do [have GitLab
+pages setup
+now](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab#publishing-
+gitlab-pages), it's not (yet) integrated with our mirroring infrastructure.
+So, for now, the source is hosted and built in our legacy
+[git](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/git) and
+[Jenkins](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/jenkins)
+services.
+
+It is nice to have the content hosted in a git repository: sysadmins can just
+edit Markdown in the git repository and push to deploy changes, no web browser
+required. And it's trivial to setup a local environment to preview changes:
 
     hugo serve --baseUrl=http://localhost/
     firefox https://localhost:1313/
 
 Only the sysadmin team and gitolite administrators have access to the
-repository, at this stage, but that can be changed. Merge requests can
-also be issued on the [GitLab repository](https://gitlab.torproject.org/tpo/tpa/status-site/) and then pushed by
-authorized personnel later on, naturally.
+repository, at this stage, but that could be improved if necessary. Merge
+requests can also be issued on the [GitLab
+repository](https://gitlab.torproject.org/tpo/tpa/status-site/) and then
+pushed by authorized personnel later on, naturally.
 
 # Availability
 
-One of the concern I have is that the site is hosted inside our normal
-mirror infrastructure. Naturally, if an outage occurs there, the site
-goes down. But I figured it's a bridge we'll cross when we get
-there.
-
-Because it's so easy to build the site from scratch, it's actually
-trivial to host a copy of the site on *any* GitLab server, thanks to
-the `.gitlab-ci.yml` file shipped (but not currently used) in the
-repository.
-
-If push comes to shove, we can just publish the site elsewhere and
-point DNS there.
+One of the concern I have is that the site is hosted inside our normal mirror
+infrastructure. Naturally, if an outage occurs there, the site goes down. But
+I figured it's a bridge we'll cross when we get there. Because it's so easy to
+build the site from scratch, it's actually trivial to host a copy of the site
+on _any_ GitLab server, thanks to the `.gitlab-ci.yml` file shipped (but not
+currently used) in the repository So if push comes to shove, we can just
+publish the site elsewhere and point DNS there.
 
 And, of course, if DNS fails us, then we're in trouble, but that's the
-situation anyways: we can always register a new domain name for the
-status page when we need to. It doesn't seem like a priority at the
-moment.
+situation anyways: we can always register a new domain name for the status
+page when we need to. It doesn't seem like a priority at the moment.
 
 Comments and feedback are welcome!
 
-[[!tag draft]]

keychron review
diff --git a/hardware/keyboard.mdwn b/hardware/keyboard.mdwn
index be67b14e..a9d42bf9 100644
--- a/hardware/keyboard.mdwn
+++ b/hardware/keyboard.mdwn
@@ -263,4 +263,11 @@ Keychron
 
 [Keychron](https://www.keychron.com/) - nice wireless keyboards, maybe?
 
+[Review from a DD](https://venthur.de/2021-04-30-keychron-c1-on-linux.html) says:
+
+> Although the fix [making F-keys work] was not very hard to find and
+> apply, this experience still leaves a foul taste. I naively assumed
+> the problem of having a properly functioning keyboard that simply
+> works when you plug it in, has been thoroughly solved by 2021.
+
 [[!tag research]]

fixed formatting
diff --git a/hardware/tubman.md b/hardware/tubman.md
index c7e4e73c..69b8e8bb 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -314,7 +314,6 @@ troubleshooting.
 
 TODO:
 
- * fix markdown/ikiwiki formatting above
  * SSD caching
  * configure swap? (step 7)
  * disable log compression? (step 8.3)

agin
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 5b436988..c7e4e73c 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -291,7 +291,7 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
 
  18. exit chroot:
  
-        exit
+         exit
 
  18. unmount filesystems:
  

agin
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 95176744..5b436988 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -216,26 +216,26 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
  12. enable tmpfs (TODO: isn't there a better way?)
 
          ln -s /usr/share/systemd/tmp.mount /etc/systemd/system/
-         root@grml:/# systemctl enable tmp.mount
+        root@grml:/# systemctl enable tmp.mount
 
  13. grub setup:
 
          root@grml:/# grub-probe /boot
-         zfs
-         root@grml:/# update-initramfs -c -k all
-         update-initramfs: Generating /boot/initrd.img-5.10.0-6-amd64
-         root@grml:/# sed -i 's,GRUB_CMDLINE_LINUX.*,GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/debian",' /etc/default/grub
-         root@grml:/# update-grub
-         Generating grub configuration file ...
-         Found linux image: /boot/vmlinuz-5.10.0-6-amd64
-         Found initrd image: /boot/initrd.img-5.10.0-6-amd64
-         done
-         root@grml:/# grub-install /dev/sdb 
-         Installing for i386-pc platform.
-         Installation finished. No error reported.
-         root@grml:/# grub-install /dev/sdc 
-         Installing for i386-pc platform.
-         Installation finished. No error reported.
+        zfs
+        root@grml:/# update-initramfs -c -k all
+        update-initramfs: Generating /boot/initrd.img-5.10.0-6-amd64
+        root@grml:/# sed -i 's,GRUB_CMDLINE_LINUX.*,GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/debian",' /etc/default/grub
+        root@grml:/# update-grub
+        Generating grub configuration file ...
+        Found linux image: /boot/vmlinuz-5.10.0-6-amd64
+        Found initrd image: /boot/initrd.img-5.10.0-6-amd64
+        done
+        root@grml:/# grub-install /dev/sdb 
+        Installing for i386-pc platform.
+        Installation finished. No error reported.
+        root@grml:/# grub-install /dev/sdc 
+        Installing for i386-pc platform.
+        Installation finished. No error reported.
 
     make sure you check both disks in there:
     
@@ -244,9 +244,9 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
  14. filesystem mount ordering (TODO: is this necessary?):
 
          mkdir /etc/zfs/zfs-list.cache
-         touch /etc/zfs/zfs-list.cache/bpool
-         touch /etc/zfs/zfs-list.cache/rpool
-         zed -F &
+        touch /etc/zfs/zfs-list.cache/bpool
+        touch /etc/zfs/zfs-list.cache/rpool
+        zed -F &
 
     then verify the files have data:
     
@@ -274,11 +274,11 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
 
  15. fix the paths to eliminate `/mnt`:
 
-        sed -Ei "s|/mnt/?|/|" /etc/zfs/zfs-list.cache/*
+         sed -Ei "s|/mnt/?|/|" /etc/zfs/zfs-list.cache/*
 
  16. extra config, setup SSH with auth key:
 
-        apt install --yes openssh-server
+         apt install --yes openssh-server
         mkdir /root/.ssh/
         cat > /root/.ssh/authorized_keys <<EOF
         ...
@@ -286,7 +286,7 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
 
  17. snapshot initial install:
  
-        zfs snapshot bpool/BOOT/debian@install
+         zfs snapshot bpool/BOOT/debian@install
         zfs snapshot rpool/ROOT/debian@install
 
  18. exit chroot:
@@ -295,13 +295,13 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
 
  18. unmount filesystems:
  
-        mount | grep -v zfs | tac | awk '/\/mnt/ {print $3}' | \
+         mount | grep -v zfs | tac | awk '/\/mnt/ {print $3}' | \
             xargs -i{} umount -lf {}
         zpool export -a
 
  18. reboot:
  
-        reboot
+         reboot
 
 That procedure actually worked! The only problem was the interfaces(5)
 configuration, which was missing (regardless of what the above

try to fix md formatting
dang you ikiwiki
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 58ec2034..95176744 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -190,11 +190,11 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
 
  10. pick a root password
  
-        passwd
+         passwd
 
  11. bpool import hack (TODO: whyy)
 
-        cat > /etc/systemd/system/zfs-import-bpool.service <<EOF
+         cat > /etc/systemd/system/zfs-import-bpool.service <<EOF
         [Unit]
         DefaultDependencies=no
         Before=zfs-import-scan.service
@@ -215,38 +215,38 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
 
  12. enable tmpfs (TODO: isn't there a better way?)
 
-        ln -s /usr/share/systemd/tmp.mount /etc/systemd/system/
-        root@grml:/# systemctl enable tmp.mount
+         ln -s /usr/share/systemd/tmp.mount /etc/systemd/system/
+         root@grml:/# systemctl enable tmp.mount
 
  13. grub setup:
 
-        root@grml:/# grub-probe /boot
-        zfs
-        root@grml:/# update-initramfs -c -k all
-        update-initramfs: Generating /boot/initrd.img-5.10.0-6-amd64
-        root@grml:/# sed -i 's,GRUB_CMDLINE_LINUX.*,GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/debian",' /etc/default/grub
-        root@grml:/# update-grub
-        Generating grub configuration file ...
-        Found linux image: /boot/vmlinuz-5.10.0-6-amd64
-        Found initrd image: /boot/initrd.img-5.10.0-6-amd64
-        done
-        root@grml:/# grub-install /dev/sdb 
-        Installing for i386-pc platform.
-        Installation finished. No error reported.
-        root@grml:/# grub-install /dev/sdc 
-        Installing for i386-pc platform.
-        Installation finished. No error reported.
+         root@grml:/# grub-probe /boot
+         zfs
+         root@grml:/# update-initramfs -c -k all
+         update-initramfs: Generating /boot/initrd.img-5.10.0-6-amd64
+         root@grml:/# sed -i 's,GRUB_CMDLINE_LINUX.*,GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/debian",' /etc/default/grub
+         root@grml:/# update-grub
+         Generating grub configuration file ...
+         Found linux image: /boot/vmlinuz-5.10.0-6-amd64
+         Found initrd image: /boot/initrd.img-5.10.0-6-amd64
+         done
+         root@grml:/# grub-install /dev/sdb 
+         Installing for i386-pc platform.
+         Installation finished. No error reported.
+         root@grml:/# grub-install /dev/sdc 
+         Installing for i386-pc platform.
+         Installation finished. No error reported.
 
     make sure you check both disks in there:
     
-        dpkg-reconfigure grub-pc
+         dpkg-reconfigure grub-pc
 
  14. filesystem mount ordering (TODO: is this necessary?):
 
-        mkdir /etc/zfs/zfs-list.cache
-        touch /etc/zfs/zfs-list.cache/bpool
-        touch /etc/zfs/zfs-list.cache/rpool
-        zed -F &
+         mkdir /etc/zfs/zfs-list.cache
+         touch /etc/zfs/zfs-list.cache/bpool
+         touch /etc/zfs/zfs-list.cache/rpool
+         zed -F &
 
     then verify the files have data:
     

pre blocks misformatted, sigh
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 8b75db6f..58ec2034 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -314,6 +314,7 @@ troubleshooting.
 
 TODO:
 
+ * fix markdown/ikiwiki formatting above
  * SSD caching
  * configure swap? (step 7)
  * disable log compression? (step 8.3)

link dump
diff --git a/hardware/tubman.md b/hardware/tubman.md
index ffa2bfb6..8b75db6f 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -332,6 +332,16 @@ TODO:
  * static IP (DONE)
  * port forward SSH so that it doesn't land on curie (DONE)
  * [report back on the procedure](https://github.com/openzfs/openzfs-docs/pull/126#pullrequestreview-647650769) (DONE)
+ * sort through those links:
+   * <https://wiki.debian.org/ZF>
+   * <https://www.reddit.com/r/zfs/comments/b2j66o/zfs_on_root_are_you_doing_it>
+   * <https://www.funtoo.org/ZFS_as_Root_Filesyste>
+   * <https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.htm>
+   * <https://github.com/openzfs/openzfs-docs/pull/12>
+   * <https://www.reddit.com/r/zfs/comments/4lkv5v/can_loss_of_slog_or_l2arc_failure_on_modern>
+   * <https://duckduckgo.com/?t=ffab&q=zfs+ssd+caching&ia=we>
+   * <https://startpage.com/do/metasearch.pl?query=zfs%20ssd%20cachin>
+   * <https://duckduckgo.com/?t=ffab&q=zfs+filesystem+caching>
 
 ## Decisions taken during the procedure
 

install successful!
diff --git a/hardware/tubman.md b/hardware/tubman.md
index cbe598c8..ffa2bfb6 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -299,7 +299,13 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
             xargs -i{} umount -lf {}
         zpool export -a
 
- 18. TODO: reboot
+ 18. reboot:
+ 
+        reboot
+
+That procedure actually worked! The only problem was the interfaces(5)
+configuration, which was missing (regardless of what the above
+says). I want to do systemd-networkd anyways.
 
 We performed steps 1 through 6, remaining steps are optional and
 troubleshooting.
@@ -323,9 +329,9 @@ TODO:
    * paste
    * photos
    * torrent
- * static IP
- * port forward SSH so that it doesn't land on curie
- * [report back on the procedure](https://github.com/openzfs/openzfs-docs/pull/126#pullrequestreview-647650769)
+ * static IP (DONE)
+ * port forward SSH so that it doesn't land on curie (DONE)
+ * [report back on the procedure](https://github.com/openzfs/openzfs-docs/pull/126#pullrequestreview-647650769) (DONE)
 
 ## Decisions taken during the procedure
 

ssd caching was the whole point
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 3e9921f4..cbe598c8 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -308,6 +308,7 @@ troubleshooting.
 
 TODO:
 
+ * SSD caching
  * configure swap? (step 7)
  * disable log compression? (step 8.3)
  * delete install snapshots?

yolo
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 40d8d288..3e9921f4 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -155,7 +155,7 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
 
  5. install the base system and copy the ZFS config:
  
-        debootstrap bullseye /mnt
+        debootstrap --components=main,contrib bullseye /mnt
         mkdir /mnt/etc/zfs
         cp /etc/zfs/zpool.cache /mnt/etc/zfs/
 
@@ -164,7 +164,6 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
         echo HOSTNAME > /mnt/etc/hostname
         vi /mnt/etc/hosts
         apt install ca-certificates
-        echo 'deb https://deb.debian.org/debian bullseye main contrib' > /etc/apt/sources.list
         echo 'deb https://deb.debian.org/debian-security bullseye-security main contrib' > /etc/apt/sources.list.d/security.list
 
  7. bind mounts and chroot for more complex config:
@@ -325,6 +324,7 @@ TODO:
    * torrent
  * static IP
  * port forward SSH so that it doesn't land on curie
+ * [report back on the procedure](https://github.com/openzfs/openzfs-docs/pull/126#pullrequestreview-647650769)
 
 ## Decisions taken during the procedure
 
@@ -356,3 +356,8 @@ TODO:
 
  * the `/var/log` and `/var/spool` datasets are creating needless
    complexity in the boot process, we could do without them
+
+## Troubleshooting
+
+ * [initrd documentation](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20GNU%20Linux%20initrd%20documentation.html): booting from a snapshot, rollbacks, etc
+ * [install troubleshooting](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html#troubleshooting)

install finished, need to reboot
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 5071daa8..40d8d288 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -163,7 +163,9 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
 
         echo HOSTNAME > /mnt/etc/hostname
         vi /mnt/etc/hosts
-        echo 'deb https://deb.debian.org/debian-security bullseye-security main' > /etc/apt/sources.list.d/security.list
+        apt install ca-certificates
+        echo 'deb https://deb.debian.org/debian bullseye main contrib' > /etc/apt/sources.list
+        echo 'deb https://deb.debian.org/debian-security bullseye-security main contrib' > /etc/apt/sources.list.d/security.list
 
  7. bind mounts and chroot for more complex config:
  
@@ -182,16 +184,147 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
  9. ZFS boot configuration
  
         apt install --yes dpkg-dev linux-headers-amd64 linux-image-amd64
-        apt install --yes zfs-initramfs # TODO
-        echo REMAKE_INITRD=yes > /etc/dkms/zfs.conf # TODO
-        apt install --yes grub-pc # TODO
-        apt remove --purge os-prober # TODO
+        apt install --yes zfs-initramfs
+        echo REMAKE_INITRD=yes > /etc/dkms/zfs.conf
+        apt install --yes grub-pc
+        apt remove --purge os-prober
 
  10. pick a root password
  
         passwd
 
- 11. TODO: now at step 4.11, the systemd config
+ 11. bpool import hack (TODO: whyy)
+
+        cat > /etc/systemd/system/zfs-import-bpool.service <<EOF
+        [Unit]
+        DefaultDependencies=no
+        Before=zfs-import-scan.service
+        Before=zfs-import-cache.service
+
+        [Service]
+        Type=oneshot
+        RemainAfterExit=yes
+        ExecStart=/sbin/zpool import -N -o cachefile=none bpool
+        # Work-around to preserve zpool cache:
+        ExecStartPre=-/bin/mv /etc/zfs/zpool.cache /etc/zfs/preboot_zpool.cache
+        ExecStartPost=-/bin/mv /etc/zfs/preboot_zpool.cache /etc/zfs/zpool.cache
+
+        [Install]
+        WantedBy=zfs-import.target
+        EOF
+        systemctl enable zfs-import-bpool.service
+
+ 12. enable tmpfs (TODO: isn't there a better way?)
+
+        ln -s /usr/share/systemd/tmp.mount /etc/systemd/system/
+        root@grml:/# systemctl enable tmp.mount
+
+ 13. grub setup:
+
+        root@grml:/# grub-probe /boot
+        zfs
+        root@grml:/# update-initramfs -c -k all
+        update-initramfs: Generating /boot/initrd.img-5.10.0-6-amd64
+        root@grml:/# sed -i 's,GRUB_CMDLINE_LINUX.*,GRUB_CMDLINE_LINUX="root=ZFS=rpool/ROOT/debian",' /etc/default/grub
+        root@grml:/# update-grub
+        Generating grub configuration file ...
+        Found linux image: /boot/vmlinuz-5.10.0-6-amd64
+        Found initrd image: /boot/initrd.img-5.10.0-6-amd64
+        done
+        root@grml:/# grub-install /dev/sdb 
+        Installing for i386-pc platform.
+        Installation finished. No error reported.
+        root@grml:/# grub-install /dev/sdc 
+        Installing for i386-pc platform.
+        Installation finished. No error reported.
+
+    make sure you check both disks in there:
+    
+        dpkg-reconfigure grub-pc
+
+ 14. filesystem mount ordering (TODO: is this necessary?):
+
+        mkdir /etc/zfs/zfs-list.cache
+        touch /etc/zfs/zfs-list.cache/bpool
+        touch /etc/zfs/zfs-list.cache/rpool
+        zed -F &
+
+    then verify the files have data:
+    
+        root@grml:/# cat /etc/zfs/zfs-list.cache/bpool                                                                                                                         
+        bpool   /mnt/boot       off     on      on      off     on      off     on      off     -       none    -       -       -       -       -       -       -       -
+        bpool/BOOT      none    off     on      on      off     on      off     on      off     -       none    -       -       -       -       -       -       -       -
+        bpool/BOOT/debian       /mnt/boot       on      on      on      off     on      off     on      off     -       none    -       -       -       -       -       -     -
+                -
+        root@grml:/# cat /etc/zfs/zfs-list.cache/rpool                                                                                                                         |
+        rpool   /mnt    off     on      on      on      on      off     on      off     rpool   prompt  -       -       -       -       -       -       -       -
+        rpool/ROOT      none    off     on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -       -
+        rpool/ROOT/debian       /mnt    noauto  on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        rpool/home      /mnt/home       on      on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        rpool/home/root /mnt/root       on      on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        rpool/srv       /mnt/srv        on      on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        rpool/var       /mnt/var        off     on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        rpool/var/cache /mnt/var/cache  on      on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        rpool/var/lib   /mnt/var/lib    off     on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        rpool/var/log   /mnt/var/log    on      on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        rpool/var/spool /mnt/var/spool  on      on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        rpool/var/tmp   /mnt/var/tmp    on      on      on      on      on      off     on      off     rpool   none    -       -       -       -       -       -       -     -
+        root@grml:/# fg
+        zed -F
+        ^CExiting
+
+ 15. fix the paths to eliminate `/mnt`:
+
+        sed -Ei "s|/mnt/?|/|" /etc/zfs/zfs-list.cache/*
+
+ 16. extra config, setup SSH with auth key:
+
+        apt install --yes openssh-server
+        mkdir /root/.ssh/
+        cat > /root/.ssh/authorized_keys <<EOF
+        ...
+        EOF
+
+ 17. snapshot initial install:
+ 
+        zfs snapshot bpool/BOOT/debian@install
+        zfs snapshot rpool/ROOT/debian@install
+
+ 18. exit chroot:
+ 
+        exit
+
+ 18. unmount filesystems:
+ 
+        mount | grep -v zfs | tac | awk '/\/mnt/ {print $3}' | \
+            xargs -i{} umount -lf {}
+        zpool export -a
+
+ 18. TODO: reboot
+
+We performed steps 1 through 6, remaining steps are optional and
+troubleshooting.
+
+## Next steps
+
+TODO:
+
+ * configure swap? (step 7)
+ * disable log compression? (step 8.3)
+ * delete install snapshots?
+        
+        zfs snapshot bpool/BOOT/debian@install
+        zfs snapshot rpool/ROOT/debian@install
+
+ * configure regular snaphots?
+ * setup services:
+   * radio
+   * sonic
+   * paste
+   * photos
+   * torrent
+ * static IP
+ * port forward SSH so that it doesn't land on curie
 
 ## Decisions taken during the procedure
 
@@ -208,6 +341,9 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
    eth0` etc)
  * we skip `keyboard-configuration` and `console-setup` config,
    defaults are fine
+ * this was skipped, as the target file already exists in bullseye:
+ 
+        ln -s /usr/lib/zfs-linux/zed.d/history_event-zfs-list-cacher.sh /etc/zfs/zed.d
 
 ## Abandoned ideas
 
@@ -215,3 +351,8 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing
    though it only has related mountpoints (actually, [that's
    supported](https://bugs.debian.org/987735) with `--skip=check/empty`, but that wasn't in the
    buster manpage and I failed to look at the bullseye one)
+
+## To be improved
+
+ * the `/var/log` and `/var/spool` datasets are creating needless
+   complexity in the boot process, we could do without them

draft post about the TPO status page
diff --git a/blog/2021-04-28-tpo-status-page.mdwn b/blog/2021-04-28-tpo-status-page.mdwn
new file mode 100644
index 00000000..66a8d98a
--- /dev/null
+++ b/blog/2021-04-28-tpo-status-page.mdwn
@@ -0,0 +1,87 @@
+[[!meta title="Building a status page service with Hugo"]]
+
+The Tor Project now has a [status page](https://status.torproject.org/) which shows the state of
+our major services. We'll use this going forward to announce major
+outages in external (e.g. hidden services or consensus ) or internal
+(e.g. GitLab) services not working. This post documents how the
+service was built and how it works.
+
+# Why a status page
+
+The first step in setting up a service page was to realize we needed
+one in the first place. I have made a [service survey](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021#survey-results) for internal
+users at the end of 2020 to see what could be improved, and one of the
+suggestions that came up was to "document downtimes of one hour or
+longer" and generally improve communications and monitoring. The
+latter is still on the [sysadmin roadmap](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/roadmap/2021), but for the former, it
+seemed ideal to create a status page.
+
+Note that we already have to monitoring tools in the sysadmin team:
+[Icinga](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/nagios) (a fork of Nagios) and [Prometheus](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/prometheus/), with [Grafana](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/grafana)
+dashboards. But those are hard to understand for users and worse, tend
+to generate false positive, and don't clearly show users which issues
+are critical. In the end, a manually curated dashboard provides huge
+usability benefits over automated system, and [all major organisations
+have one](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/status#example-sites).
+
+# Picking the right tool
+
+It wasn't my first foray in status page design. In a previous job, I
+had setup a status page using a tool called [Cachet](https://cachethq.io/), which was a
+great improvement over the previous solutions, which were to use first
+a wiki and then a blog to post updates. But Cachet is a complex
+PHP/Laravel app, and requires some work to setup and deploy. It also
+requires a web browser to update, and generally requires more
+maintenance than what we'd like.
+
+So when I found about [cstate](https://github.com/cstate/cstate), I was so excited that I just set it
+up right away. It's basically a theme for the [Hugo](https://gohugo.io/) static site
+generator, which means that it's a set of HTML, CSS, and a sprinkle of
+Javascript. And being based on Hugo means that the site is generated
+from a set of [Markdown](https://en.wikipedia.org/wiki/Markdown) files and the result is just plain HTML
+that can be hosted on any web server on the planet.
+
+# Deployment
+
+At first, I wanted to deploy the site through GitLab CI, but at that
+time we didn't have GitLab pages setup. Even though we [do have GitLab
+pages setup](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/gitlab#publishing-gitlab-pages), it's not integrated with our mirroring
+infrastructure. So, for now, the source is hosted and build in our
+[legacy git](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/git) and [Jenkins](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/jenkins) services.
+
+It is nice to have the content hosted in a git repository: sysadmins
+can just edit markdown in the git repository and push to deploy
+changes, no web browser required. And because `hugo` is fast, it's
+trivial to setup a local environment to preview changes:
+
+    hugo serve --baseUrl=http://localhost/
+    firefox https://localhost:1313/
+
+Only the sysadmin team and gitolite administrators have access to the
+repository, at this stage, but that can be changed. Merge requests can
+also be issued on the [GitLab repository](https://gitlab.torproject.org/tpo/tpa/status-site/) and then pushed by
+authorized personnel later on, naturally.
+
+# Availability
+
+One of the concern I have is that the site is hosted inside our normal
+mirror infrastructure. Naturally, if an outage occurs there, the site
+goes down. But I figured it's a bridge we'll cross when we get
+there.
+
+Because it's so easy to build the site from scratch, it's actually
+trivial to host a copy of the site on *any* GitLab server, thanks to
+the `.gitlab-ci.yml` file shipped (but not currently used) in the
+repository.
+
+If push comes to shove, we can just publish the site elsewhere and
+point DNS there.
+
+And, of course, if DNS fails us, then we're in trouble, but that's the
+situation anyways: we can always register a new domain name for the
+status page when we need to. It doesn't seem like a priority at the
+moment.
+
+Comments and feedback are welcome!
+
+[[!tag draft]]

keep going in the zfs install procedure
diff --git a/hardware/tubman.md b/hardware/tubman.md
index e857d3fc..5071daa8 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -20,29 +20,35 @@
  * USB Bluetooth receiver
  * cost: 350$CAD on 2011-02-26, not counting storage, BT and memory
 
-# ZFS root install
+# Installation procedure
 
-Would have used FAI's setup-storage but it doesn't support ZFS.
+I would have used [FAI](https://fai-project.org/)'s [setup-storage](https://manpages.debian.org/setup-storage.8) but it doesn't support
+ZFS, unfortunately. It is part of the [long term roadmap](https://fai-project.org/roadmap/), that
+said, and there's a [howto for stretch](https://wiki.fai-project.org/index.php/ZFS_root_with_Debian_Stretch_and_FAI), but that doesn't use
+setup-storage. I was hoping I would reuse the [installer](https://gitweb.torproject.org/admin/tsa-misc.git/tree/install) I've been
+working on at work...
 
-Following [this howto](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html), we have the following configuration:
+We have the following disk configuration:
 
  * `/dev/sda`: SSD drive, 512MB used for caching
  * `/dev/sdb`: HDD drive, 4TB, to be used in a ZFS pool with native encryption
  * `/dev/sdc`: HDD drive, 4TB, same
 
-We boot from a [grml](https://grml.org/) live image based on Debian testing (bullseye).
+We boot from a [grml](https://grml.org/) live image based on Debian testing
+(bullseye), and will follow [this howto](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html):
 
  1. install requirements:
 
         apt update
         apt install --yes debootstrap gdisk dkms dpkg-dev linux-headers-$(uname -r) zfs-dkms
-        modprobe zfs # TODO
-        apt install --yes zfsutils-linux # TODO
+        modprobe zfs
+        apt install --yes zfsutils-linux
 
-    Note that those instructions differ from the source howto because
-    we start from a `bullseye` live image.
+    Note that those instructions differ from the documentation (we
+    don't use `buster-backports`) because we start from a `bullseye`
+    live image.
 
- 1. clear the partitions on the two HDDs, and setup a BIOS, UEFI, boot
+ 1. clear the partitions on the two HDD, and setup a BIOS, UEFI, boot
     pool and native encrypted partition:
 
         for DISK in /dev/sdb /dev/sdc ; do
@@ -72,7 +78,8 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing (bul
            3         1050624         3147775   1024.0 MiB  BF01  
            4         3147776      7814037134   3.6 TiB     BF00
 
- 2. create a boot pool called `bpool` (TODO):
+ 2. create the boot pool called `bpool` and the root pool called
+    `rpool`, the latter will prompt for a disk encryption key:
 
         zpool create \
             -o cachefile=/etc/zfs/zpool.cache \
@@ -93,9 +100,6 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing (bul
             -O devices=off -O normalization=formD -O relatime=on -O xattr=sa \
             -O mountpoint=/boot -R /mnt \
             bpool mirror /dev/sdb3 /dev/sdc3
-
- 3. create the root pool called `rpool` (TODO):
-
         zpool create \
             -o ashift=12 \
             -O encryption=aes-256-gcm \
@@ -105,4 +109,109 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing (bul
             -O xattr=sa -O mountpoint=/ -R /mnt \
             rpool mirror /dev/sdb4 /dev/sdc4
 
-At step 3, "system installation". TODO.
+ 4. create filesytems and "datasets":
+
+    * this creates two containers, for `ROOT` and `BOOT`
+
+        zfs create -o canmount=off -o mountpoint=none rpool/ROOT
+        zfs create -o canmount=off -o mountpoint=none bpool/BOOT
+
+   * this actually creates the boot and root filesystems:
+
+        zfs create -o canmount=noauto -o mountpoint=/ rpool/ROOT/debian
+        zfs mount rpool/ROOT/debian
+        zfs create -o mountpoint=/boot bpool/BOOT/debian
+
+   * then they use even more data sets, although I'm not sure they are
+     all necessary:
+
+        zfs create                                 rpool/home
+        zfs create -o mountpoint=/root             rpool/home/root
+        chmod 700 /mnt/root
+        zfs create -o canmount=off                 rpool/var
+        zfs create -o canmount=off                 rpool/var/lib
+        zfs create                                 rpool/var/log
+        zfs create                                 rpool/var/spool
+
+   * to exclude temporary files from snapshots, for example:
+
+        zfs create -o com.sun:auto-snapshot=false  rpool/var/cache
+        zfs create -o com.sun:auto-snapshot=false  rpool/var/tmp
+        chmod 1777 /mnt/var/tmp
+
+   * and a `/srv`:
+
+        zfs create                                 rpool/srv
+
+   * or for Docker (TODO):
+
+        zfs create -o com.sun:auto-snapshot=false rpool/var/lib/docker
+
+   * make a `tmpfs` for `/run`:
+
+        mkdir /mnt/run
+        mount -t tmpfs tmpfs /mnt/run
+        mkdir /mnt/run/lock
+
+ 5. install the base system and copy the ZFS config:
+ 
+        debootstrap bullseye /mnt
+        mkdir /mnt/etc/zfs
+        cp /etc/zfs/zpool.cache /mnt/etc/zfs/
+
+ 6. base system configuration:
+
+        echo HOSTNAME > /mnt/etc/hostname
+        vi /mnt/etc/hosts
+        echo 'deb https://deb.debian.org/debian-security bullseye-security main' > /etc/apt/sources.list.d/security.list
+
+ 7. bind mounts and chroot for more complex config:
+ 
+        mount --rbind /dev  /mnt/dev
+        mount --rbind /proc /mnt/proc
+        mount --rbind /sys  /mnt/sys
+        chroot /mnt /bin/bash
+
+ 8. more base system config:
+
+        ln -s /proc/self/mounts /etc/mtab
+        apt update
+        apt install --yes console-setup locales
+        dpkg-reconfigure locales tzdata
+
+ 9. ZFS boot configuration
+ 
+        apt install --yes dpkg-dev linux-headers-amd64 linux-image-amd64
+        apt install --yes zfs-initramfs # TODO
+        echo REMAKE_INITRD=yes > /etc/dkms/zfs.conf # TODO
+        apt install --yes grub-pc # TODO
+        apt remove --purge os-prober # TODO
+
+ 10. pick a root password
+ 
+        passwd
+
+ 11. TODO: now at step 4.11, the systemd config
+
+## Decisions taken during the procedure
+
+ * use a `tmpfs` for `/run`
+ * use native ZFS encryption
+ * setup both BIOS and UEFI partitions, in case we switch to the
+   latter later
+
+## Changes from the original procedure
+
+ * we install a bullseye system from a bullseye live image (instead of
+   buster from buster)
+ * `interfaces(5)` file untouched, default is fine (`allow-hotplug
+   eth0` etc)
+ * we skip `keyboard-configuration` and `console-setup` config,
+   defaults are fine
+
+## Abandoned ideas
+
+ * using `mmdebstrap`: it complains that `/mnt` is "not empty" even
+   though it only has related mountpoints (actually, [that's
+   supported](https://bugs.debian.org/987735) with `--skip=check/empty`, but that wasn't in the
+   buster manpage and I failed to look at the bullseye one)

more todo
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 21e9cb56..e857d3fc 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -104,3 +104,5 @@ We boot from a [grml](https://grml.org/) live image based on Debian testing (bul
             -O dnodesize=auto -O normalization=formD -O relatime=on \
             -O xattr=sa -O mountpoint=/ -R /mnt \
             rpool mirror /dev/sdb4 /dev/sdc4
+
+At step 3, "system installation". TODO.

tubman setup notes
diff --git a/hardware/tubman.md b/hardware/tubman.md
new file mode 100644
index 00000000..21e9cb56
--- /dev/null
+++ b/hardware/tubman.md
@@ -0,0 +1,106 @@
+# Specification
+
+(copied from [[hardware/server/marcos/v1]])
+
+ * motherboard: [ASUS P5G41-M LE/CSM LGA 775 Intel G41 Micro ATX Intel
+   Motherboard](http://www.newegg.com/Product/Product.aspx?Item=N82E16813131399) 65$ newegg ([processeurs supportés](https://www.asus.com/Motherboards/P5G41M/specifications/))
+ * case: [Antec Black Aluminum / Steel Fusion Remote Black Micro ATX
+   Media Center / HTPC Case](http://www.newegg.com/Product/Product.aspx?Item=N82E16811129054) 150$ newegg, includes "GD01 MX LCD
+   Display/IR Receiver"
+ * CPU: [Intel Pentium Dual-Core E6500 Wolfdale 2.93GHz 2MB L2 Cache
+   LGA 775 65W Dual-Core Processor](http://www.newegg.com/Product/Product.aspx?Item=N82E16819116093) 80$ newegg ([Bonne explication des différents modèles de cores intel](http://en.wikipedia.org/wiki/Intel_Core))
+ * Memory: 8GB ram (2x4GB DDR2 667MHz, 1.5ns)
+ * Network: AR8114 Gigabit ethernet
+ * Storage, internal:
+   * 500GB Samsung SSD 850
+   * 4TB Seagate HDD ST4000DM000-1F21 5900RPM 3.5"
+   * DVD reader/writer (A  DH16A1P, broken)
+ * Storage, external:
+   * 3TB Western Digital "My Book" 1230 USB-3
+ * USB Bluetooth receiver
+ * cost: 350$CAD on 2011-02-26, not counting storage, BT and memory
+
+# ZFS root install
+
+Would have used FAI's setup-storage but it doesn't support ZFS.
+
+Following [this howto](https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html), we have the following configuration:
+
+ * `/dev/sda`: SSD drive, 512MB used for caching
+ * `/dev/sdb`: HDD drive, 4TB, to be used in a ZFS pool with native encryption
+ * `/dev/sdc`: HDD drive, 4TB, same
+
+We boot from a [grml](https://grml.org/) live image based on Debian testing (bullseye).
+
+ 1. install requirements:
+
+        apt update
+        apt install --yes debootstrap gdisk dkms dpkg-dev linux-headers-$(uname -r) zfs-dkms
+        modprobe zfs # TODO
+        apt install --yes zfsutils-linux # TODO
+
+    Note that those instructions differ from the source howto because
+    we start from a `bullseye` live image.
+
+ 1. clear the partitions on the two HDDs, and setup a BIOS, UEFI, boot
+    pool and native encrypted partition:
+
+        for DISK in /dev/sdb /dev/sdc ; do
+            sgdisk --zap-all $DISK
+            sgdisk -a1 -n1:24K:+1000K -t1:EF02 $DISK
+            sgdisk     -n2:1M:+512M   -t2:EF00 $DISK
+            sgdisk     -n3:0:+1G      -t3:BF01 $DISK
+            sgdisk     -n4:0:0        -t4:BF00 $DISK
+        done
+
+    resulting partition table:
+
+        root@grml ~ # sgdisk -p /dev/sdb
+        Disk /dev/sdb: 7814037168 sectors, 3.6 TiB
+        Model: ST4000DM004-2CV1
+        Sector size (logical/physical): 512/4096 bytes
+        Disk identifier (GUID): 63B2F372-B4E9-45FF-8151-9706F9F158C9
+        Partition table holds up to 128 entries
+        Main partition table begins at sector 2 and ends at sector 33
+        First usable sector is 34, last usable sector is 7814037134
+        Partitions will be aligned on 16-sector boundaries
+        Total free space is 14 sectors (7.0 KiB)
+
+        Number  Start (sector)    End (sector)  Size       Code  Name
+           1              48            2047   1000.0 KiB  EF02  
+           2            2048         1050623   512.0 MiB   EF00  
+           3         1050624         3147775   1024.0 MiB  BF01  
+           4         3147776      7814037134   3.6 TiB     BF00
+
+ 2. create a boot pool called `bpool` (TODO):
+
+        zpool create \
+            -o cachefile=/etc/zfs/zpool.cache \
+            -o ashift=12 -d \
+            -o feature@async_destroy=enabled \
+            -o feature@bookmarks=enabled \
+            -o feature@embedded_data=enabled \
+            -o feature@empty_bpobj=enabled \
+            -o feature@enabled_txg=enabled \
+            -o feature@extensible_dataset=enabled \
+            -o feature@filesystem_limits=enabled \
+            -o feature@hole_birth=enabled \
+            -o feature@large_blocks=enabled \
+            -o feature@lz4_compress=enabled \
+            -o feature@spacemap_histogram=enabled \
+            -o feature@zpool_checkpoint=enabled \
+            -O acltype=posixacl -O canmount=off -O compression=lz4 \
+            -O devices=off -O normalization=formD -O relatime=on -O xattr=sa \
+            -O mountpoint=/boot -R /mnt \
+            bpool mirror /dev/sdb3 /dev/sdc3
+
+ 3. create the root pool called `rpool` (TODO):
+
+        zpool create \
+            -o ashift=12 \
+            -O encryption=aes-256-gcm \
+            -O keylocation=prompt -O keyformat=passphrase \
+            -O acltype=posixacl -O canmount=off -O compression=lz4 \
+            -O dnodesize=auto -O normalization=formD -O relatime=on \
+            -O xattr=sa -O mountpoint=/ -R /mnt \
+            rpool mirror /dev/sdb4 /dev/sdc4

approve comment
diff --git a/blog/2021-04-24-ideas/comment_1_2edf87d9a181c95cd9d95af82ed90103._comment b/blog/2021-04-24-ideas/comment_1_2edf87d9a181c95cd9d95af82ed90103._comment
new file mode 100644
index 00000000..b8302737
--- /dev/null
+++ b/blog/2021-04-24-ideas/comment_1_2edf87d9a181c95cd9d95af82ed90103._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="86.150.30.45"
+ claimedauthor="Jonathan"
+ url="jmtd.net"
+ subject="comment 1"
+ date="2021-04-28T15:21:59Z"
+ content="""
+I remember seeing your byline on LWN and being pleased; I enjoy your writing and get the impression that we think alike in a lot of respects. From the list of stubs you have there, \"ideas/on-dying\" jumps out at me as a topic that's important but rarely discussed (and by coincidence, something I've been thinking about more and more recently, although I haven't written anything publically about my thoughts.)
+"""]]

approve comment
diff --git a/blog/2021-04-24-dead-game-clock/comment_1_3e963b06d01a90688617ef5ef2e347b6._comment b/blog/2021-04-24-dead-game-clock/comment_1_3e963b06d01a90688617ef5ef2e347b6._comment
new file mode 100644
index 00000000..b2b9b7e0
--- /dev/null
+++ b/blog/2021-04-24-dead-game-clock/comment_1_3e963b06d01a90688617ef5ef2e347b6._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ ip="77.189.146.201"
+ subject="comment 4"
+ date="2021-04-26T19:16:34Z"
+ content="""
+AFAIK pypy build-depends on Python 2 (even the Python 3 version of pypy). So it can't be removed without removing pypy as well.
+"""]]

mention lwn in coms
diff --git a/communication.mdwn b/communication.mdwn
index b13a6ff4..e83f3e20 100644
--- a/communication.mdwn
+++ b/communication.mdwn
@@ -5,6 +5,8 @@
 
 J'essaie d'écrire. Pour l'instant, il s'agit surtout de mon [[blog]] mais j'essaie également d'écrire de la fiction et je participe parfois à la revue [À Babord!](http://www.ababord.org/). J'ai également publié une bonne dizaine d'articles sur le défunt [Insomniaque](http://insomniaque.org/).
 
+Ah, et j'ai [[écrit pendant 2 ans pour LWN|tag/lwn]] (2018-2020).
+
 Voici certain des articles les plus importants que j'ai publié:
 
 [[!bibtex2html publications.bib]]

plug LWN better, and explain the lack of editing
diff --git a/blog/2021-04-24-ideas.mdwn b/blog/2021-04-24-ideas.mdwn
index af28c188..39b83e72 100644
--- a/blog/2021-04-24-ideas.mdwn
+++ b/blog/2021-04-24-ideas.mdwn
@@ -193,4 +193,13 @@ So that's all I got. As people might have noticed here, I have much
 less time to write these days, but if there's any subject in there I
 should pick, what is the one that you would find most interesting?
 
+Oh! and I should mention that *you* can write to LWN! If you think
+people should know more about some Linux thing, you can get paid to
+write for it! [Pitch it to the editors](https://lwn.net/op/AuthorGuide.lwn), they won't bite. The worst
+that can happen is that they say "yes" and there goes two years of
+your life learning to write. Because no, you don't know how to write,
+no one does. You need an editor to write.
+
+That's why this article looks like crap and has a smiley. :)
+
 [[!tag debian debian-planet meta lwn]]

minimal self-editing
diff --git a/blog/2021-04-24-ideas.mdwn b/blog/2021-04-24-ideas.mdwn
index 19a93664..af28c188 100644
--- a/blog/2021-04-24-ideas.mdwn
+++ b/blog/2021-04-24-ideas.mdwn
@@ -1,10 +1,10 @@
 [[!meta title="Lost article ideas"]]
 
-I [[wrote|tag/lwn]] for [LWN](https://lwn.net/) for about two
-years. During that time, I wrote (what seems to me an impressive) [[34
+I [[wrote|tag/lwn]] for [LWN](https://lwn.net/) for about two years. During that
+time, I wrote (what seems to me an impressive) [[34
 articles|tag/lwn]], but I always had a pile of ideas in the back of my
-mind. Those are things I had ideas of, notes and scribbles, or just
-completely abandoned because they didn't seem fit for LWN in the end.
+mind. Those are ideas, notes, and scribbles lying around. Some were
+just completely abandoned because they didn't seem a good fit for LWN.
 
 Concretely, I stored those in branches in a git repository, and used
 the branch name (and, naively, the last commit log) as indicators of
@@ -54,13 +54,16 @@ because it didn't seem worth it, or my editors rejected it, or I just
 moved on:
 
  * `novena`: the project is *ooold* now, didn't seem to fit a LWN
-   article
+   article. it was basically "how can i build my novena now" and "you
+   guys rock!" it seems like the [MNT Reform](https://www.crowdsupply.com/mnt/reform/) is the brain child of
+   the Novena now, and I dare say it's even cooler!
  * `secureboot`: my LWN editors were critical of my approach, and
    probably rightly so - it's a really complex subject and I was
    probably out of my depth... it's also out of date now, we did
    manage secureboot in Debian
- * `wireguard`: LWN ended up writing their own coverage, and I was
-   biased against Donenfeld because of conflicts in a previous project
+ * `wireguard`: LWN ended up [writing](https://lwn.net/Articles/748582/) [extensive coverage](https://lwn.net/Security/Index/#Linux_kernel-Virtual_private_network_VPN), and
+   I was biased against Donenfeld because of conflicts in a previous
+   project
 
 # Backlog
 
@@ -68,7 +71,8 @@ Those were articles I was planning to write about next.
 
  * `dat`: I already had written [[Sharing and archiving data sets with
    Dat|blog/2018-09-10-sharing-and-archiving-data-sets-with-dat]], but
-   it seems I had more to say... to be investigated, I guess?
+   it seems I had more to say... mostly performance issues, beaker, no
+   streaming, limited adoption... to be investigated, I guess?
  * `packet`: a primer on data communications over ham radio, and the
    cool new tech that has emerged in the free software world. those
    are mainly notes about [Pat](https://getpat.io/), [Direwolf](https://packet-radio.net/direwolf/), [APRS](http://www.aprs.org/) and so

article ideas
diff --git a/blog/2021-04-24-ideas.mdwn b/blog/2021-04-24-ideas.mdwn
new file mode 100644
index 00000000..19a93664
--- /dev/null
+++ b/blog/2021-04-24-ideas.mdwn
@@ -0,0 +1,192 @@
+[[!meta title="Lost article ideas"]]
+
+I [[wrote|tag/lwn]] for [LWN](https://lwn.net/) for about two
+years. During that time, I wrote (what seems to me an impressive) [[34
+articles|tag/lwn]], but I always had a pile of ideas in the back of my
+mind. Those are things I had ideas of, notes and scribbles, or just
+completely abandoned because they didn't seem fit for LWN in the end.
+
+Concretely, I stored those in branches in a git repository, and used
+the branch name (and, naively, the last commit log) as indicators of
+the topic.
+
+This was the state of affairs when I left:
+
+    remotes/private/attic/novena                    822ca2bb add letter i sent to novena, never published
+    remotes/private/attic/secureboot                de09d82b quick review, add note and graph
+    remotes/private/attic/wireguard                 5c5340d1 wireguard review, tutorial and comparison with alternatives
+    remotes/private/backlog/dat                     914c5edf Merge branch 'master' into backlog/dat
+    remotes/private/backlog/packet                  9b2c6d1a ham radio packet innovations and primer
+    remotes/private/backlog/performance-tweaks      dcf02676 config notes for http2
+    remotes/private/backlog/serverless              9fce6484 postponed until kubecon europe
+    remotes/private/fin/cost-of-hosting             00d8e499 cost-of-hosting article online
+    remotes/private/fin/kubecon                     f4fd7df2 remove published or spun off articles
+    remotes/private/fin/kubecon-overview            21fae984 publish kubecon overview article
+    remotes/private/fin/kubecon2018                 1edc5ec8 add series
+    remotes/private/fin/netconf                     3f4b7ece publish the netconf articles
+    remotes/private/fin/netdev                      6ee66559 publish articles from netdev 2.2
+    remotes/private/fin/pgp-offline                 f841deed pgp offline branch ready for publication
+    remotes/private/fin/primes                      c7e5b912 publish the ROCA paper
+    remotes/private/fin/runtimes                    4bee1d70 prepare publication of runtimes articles
+    remotes/private/fin/token-benchmarks            5a363992 regenerate timestamp automatically
+    remotes/private/ideas/astropy                   95d53152 astropy or python in astronomy
+    remotes/private/ideas/avaneya                   20a6d149 crowdfunded blade-runner-themed GPLv3 simcity-like simulator
+    remotes/private/ideas/backups-benchmarks        fe2f1f13 review of backup software through performance and features
+    remotes/private/ideas/cumin                     7bed3945 review of the cumin automation tool from WM foundation
+    remotes/private/ideas/future-of-distros         d086ca0d modern packaging problems and complex apps
+    remotes/private/ideas/on-dying                  a92ad23f another dying thing
+    remotes/private/ideas/openpgp-discovery         8f2782f0 openpgp discovery mechanisms (WKD, etc), thanks to jonas meurer
+    remotes/private/ideas/password-bench            451602c0 bruteforce estimates for various password patterns compared with RSA key sizes
+    remotes/private/ideas/prometheus-openmetrics    2568dbd6 openmetrics standardizing prom metrics enpoints
+    remotes/private/ideas/telling-time              f3c24a53 another way of telling time
+    remotes/private/ideas/wallabako                 4f44c5da talk about wallabako, read-it-later + kobo hacking
+    remotes/private/stalled/bench-bench-bench       8cef0504 benchmarking http benchmarking tools
+    remotes/private/stalled/debian-survey-democracy 909bdc98 free software surveys and debian democracy, volunteer vs paid work
+
+Wow, what a mess! Let's see if I can make sense of this:
+
+[[!toc]]
+
+# Attic
+
+Those are articles that I thought about, then finally rejected, either
+because it didn't seem worth it, or my editors rejected it, or I just
+moved on:
+
+ * `novena`: the project is *ooold* now, didn't seem to fit a LWN
+   article
+ * `secureboot`: my LWN editors were critical of my approach, and
+   probably rightly so - it's a really complex subject and I was
+   probably out of my depth... it's also out of date now, we did
+   manage secureboot in Debian
+ * `wireguard`: LWN ended up writing their own coverage, and I was
+   biased against Donenfeld because of conflicts in a previous project
+
+# Backlog
+
+Those were articles I was planning to write about next.
+
+ * `dat`: I already had written [[Sharing and archiving data sets with
+   Dat|blog/2018-09-10-sharing-and-archiving-data-sets-with-dat]], but
+   it seems I had more to say... to be investigated, I guess?
+ * `packet`: a primer on data communications over ham radio, and the
+   cool new tech that has emerged in the free software world. those
+   are mainly notes about [Pat](https://getpat.io/), [Direwolf](https://packet-radio.net/direwolf/), [APRS](http://www.aprs.org/) and so
+   on... just never got around to making sense of it or really using
+   the tech...
+ * `performance-tweaks`: "optimizing websites at the age of http2",
+   the unwritten story of the optimization of this website with HTTP/2
+   and friends
+ * `serverless`: god. one of the leftover topics at Kubecon, my notes
+   on this were thin, and the [actual subject](https://en.wikipedia.org/wiki/Serverless_computing), possibly even
+   thinner... the only lie worse than the cloud is that there's no
+   server at all! concretely, that's a pile of notes about
+   [[Kubecon|2018-05-26-kubecon-rant]] which I wanted to sort
+   through. Probably belongs in the attic now.
+
+# Fin
+
+Those are finished articles, they were published on my website and
+LWN, but the branches were kept because previous drafts had private
+notes that should not be published.
+
+# Ideas
+
+ * `astropy`: "[Python in astronomy](https://www.astropy.org/)" - had a chat with [saimn](http://sconseil.fr/)
+   while [[writing about|blog/2018-03-19-sigal]] [sigal](http://sigal.saimon.org/en/latest/), and it
+   turns out he actually works on free software in astronomy, in
+   Python... I actually expect LWN to [cover this sooner than
+   later](https://lwn.net/Articles/843195/), after Lee Phillips's [introduction to SciPy](https://lwn.net/Articles/842964/)
+ * `avaneya`: [crowdfunded blade-runner-themed GPLv3 simcity-like
+   simulator](https://www.patreon.com/avaneya), i just have that link so far
+ * `backups-benchmarks`: review of backup software through performance
+   and features, possibly based on [those benchmarks](https://github.com/gilbertchen/benchmarking), maybe based
+   on [this list from restic](https://github.com/restic/others) although they [refused
+   casync](https://github.com/restic/others/pull/17). benchmark articles are *hard* though, especially when
+   you want to "cover them all"... I did write a [silly Attic vs
+   Bup](https://anarc.at/blog/2014-11-18-bup-vs-attic-silly-benchmark/) back when those programs existed (2014), in a related
+   note...
+ * `ideas/cumin`: review of the [Cumin automation tool](https://wikitech.wikimedia.org/wiki/Cumin) from
+   WikiMedia Foundation... I ended up using the tool at work and
+   writing [service documentation](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/cumin) for it
+ * `ideas/future-of-distros`: modern packaging problems and complex
+   apps, starting from [this discussion](https://lists.debian.org/debian-devel/2018/02/msg00295.html) about the [removal of](https://bugs.debian.org/890598)
+   [Dolibarr](https://tracker.debian.org/pkg/dolibarr) from Debian, a [summary of the thread from liw](https://blog.liw.fi/posts/2018/02/17/what_is_debian_all_about_really_or_friction_packaging_complex_applications/),
+   and [ideas from joeyh](https://joeyh.name/blog/entry/futures_of_distributions/) (now from the outside of Debian), then
+   [debates](https://lists.debian.org/debian-devel/2018/03/msg00006.html) over the [power of FTP masters](https://lists.debian.org/debian-devel/2018/03/msg00064.html) - ugh, glad I
+   didn't step in that rat's nest
+ * `ideas/on-dying`: "what happens when a hacker dies?" rather grim
+   subject, but a more and more important one... [joeyh has ideas
+   again](https://joeyh.name/hacker_tombstone/), [phk as well](https://news.ycombinator.com/item?id=26831932), then there's [a protocol for dying](http://hintjens.com/blog:115)
+   (really grim)... then there are site policies like GitHub,
+   Facebook, etc... more in the branch, but that one I can't help but
+   think about now that family has taken a bigger place in my life...
+ * `ideas/openpgp-discovery`: OpenPGP discovery mechanisms (WKD, etc),
+   suggested by Jonas Meurer (somewhere?), only links to
+   [Mailveloppe](https://keys.mailvelope.com/), [LEAP](https://leap.se/en/docs/design/transitional-key-validation), [WKD](https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-04) (or is it WKS?), [another
+   standard](https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept), probably would need to talk about [OpenPGP CA](https://openpgp-ca.org/) now
+   and how Debian and Tor manage their keyrings... pain in the back.
+ * `ideas/password-bench`: bruteforce estimates for various password
+   patterns compared with RSA key sizes, spinoff of my [[smartcard
+   article|blog/2017-10-26-comparison-cryptographic-keycards/]], in
+   the [crypto-bench](https://gitlab.com/anarcat/crypto-bench), look at [this shiny graph](https://gitlab.com/anarcat/crypto-bench/-/raw/master/benchpasswords.png), surely that
+   must mean an article, right?
+ * `ideas/prometheus-openmetrics`: "Evolving the [Prometheus](https://prometheus.io/) exposition
+   format into a [standard](https://openmetrics.io/)", seems like this happened
+ * `ideas/telling-time`: telling time to users is hard. xclock vs
+   ttyclock, etc. maybe gameclock and undertime as well? syncing time
+   is hard, but it turns out *showing* it is non trivial as
+   well... basically turning [this bug report](https://github.com/xorg62/tty-clock/issues/40) into an article. for
+   some reason I linked to [this meme](https://i.imgur.com/jctrppz.jpg), derived from [this
+   meme](https://knowyourmeme.com/photos/320036-ps3-has-no-games), presumably a premonition of my stupid idea of writing
+   [undertime](https://gitlab.com/anarcat/undertime/) TIMEZONES!
+ * `ideas/wallabako`: "talk about wallabako, read-it-later + kobo
+   hacking", that's it, not even [a link to the project](https://gitlab.com/anarcat/wallabako)!
+
+A lot of those branches were actually just an empty commit, with the
+commitlog being the "pitch", more or less. I'd send that list to my
+editors, sometimes with a few more links (basically the above), and
+they would nudge me one way or the other.
+
+Sometimes they would actively discourage me to write about something,
+and I would do it anyways, send them a draft, and they would patiently
+make me rewrite it until it was a decent article. This was especially
+hard with the [[terminal emulator|2018-04-12-terminal-emulators-1]]
+[[series|2018-05-04-terminal-emulators-2]], which took forever to
+write and even got my editors upset when they realized I had never
+installed Fedora (I ended up installing it, and I was proven wrong!)
+
+# Stalled
+
+Oh, and then there's those: those are either "ideas" or "backlog" that
+got so far behind that I just moved them out of the way because I was
+tired of seeing them in my list.
+
+ * `stalled/bench-bench-bench` benchmarking http benchmarking tools, a
+   horrible mess of links, copy-paste from terminals, and ideas about
+   benchmarking... some of this trickled out into [this benchmarking
+   guide at Tor](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/benchmark), but not much more than the list of tools
+ * `stalled/debian-survey-democracy`: "free software surveys and
+   Debian democracy, volunteer vs paid work"... A long standing
+   concern of mine is that all Debian work is supposed to be
+   volunteer, and paying explicitly for work inside Debian has
+   traditionally been frowned upon, even leading to serious drama and
+   dissent (remember [Dunc-Tank](https://lwn.net/Articles/201488/))? back when I was writing for LWN,
+   I was also doing *paid* work for [Debian LTS](https://wiki.debian.org/LTS). I also learned
+   that a lot (most?)  Debian Developers were actually being paid by
+   their job to work on Debian. So I was confused by this apparent
+   contradiction, especially given how the LTS project has been mostly
+   accepted, while Dunc-Tank was not... See also [this talk at Debconf
+   16](https://debconf16.debconf.org/talks/41/). I had hopes that [this study](http://peerproduction.net/issues/issue-10-peer-production-and-work/preliminary-report-debian-survey/) would show the "hunch"
+   people have offered (that most DDs are paid to work on Debian) but
+   it seems to show the reverse (only 36% of DDs, and 18% of all
+   respondents paid). So I am still confused and worried about the
+   sustainability of Debian.
+
+# What do you think?
+
+So that's all I got. As people might have noticed here, I have much
+less time to write these days, but if there's any subject in there I
+should pick, what is the one that you would find most interesting?
+
+[[!tag debian debian-planet meta lwn]]

response
diff --git a/blog/2021-04-24-dead-game-clock/comment_3_338bbb28f16db211931ca2fb9d0ac6c8._comment b/blog/2021-04-24-dead-game-clock/comment_3_338bbb28f16db211931ca2fb9d0ac6c8._comment
new file mode 100644
index 00000000..4dc9f9d2
--- /dev/null
+++ b/blog/2021-04-24-dead-game-clock/comment_3_338bbb28f16db211931ca2fb9d0ac6c8._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""python 2 is still there"""
+ date="2021-04-24T23:28:53Z"
+ content="""
+To be honest, I didn't realize GTK2 and Python 2 actually shipped with Bullseye, I had assumed they would be completely gone.
+
+Those are the technical reasons why those packages were removed:
+
+ * Monkeysign: [Depends on removed python-zbar](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935335)
+ * Gameclock: [depends on unmaintained pygtk](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885282)
+ * Mailman: [depends on cruft package python-dnspython](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953376)
+
+So while none of those were removed because Python 2 was removed itself, those removals are *direct* consequences of the deprecation of Python 2. The Gameclock removal bug even explicitly says:
+
+> Note that pygtk is Python 2 only, and Python 2 is expected to be
+> removed from unstable after the release of buster.
+
+The python-dnspython package was also explicitly [removed as part of
+the Python 2 removal work](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936427):
+
+> Python2 becomes end-of-live upstream, and Debian aims to remove
+> Python2 from the distribution, as discussed in
+> https://lists.debian.org/debian-python/2019/07/msg00080.html
+
+So, sure, bullseye ships with Python 2 and GTK2, but there's no pygtk, and many *Debian* packages dropped their Python 2 versions, sometimes deliberately, so it's kind of splitting hairs to say that Python 2 still exists in bullseye... It's not because we actually *failed* to remove the Python 2 package that it is still really there.
+
+(To be honest, I'm actually puzzled by the presence of Python 2 in bullseye: given all the effort we've given to remove all that cruft, it seems to me it should just be removed already. As far as I can tell, nothing really depends on it anymore, does it?)
+"""]]

approve comment
diff --git a/blog/2021-04-24-dead-game-clock/comment_1_cc8a2206381ea775584070323f8d4a44._comment b/blog/2021-04-24-dead-game-clock/comment_1_cc8a2206381ea775584070323f8d4a44._comment
new file mode 100644
index 00000000..2ee4d356
--- /dev/null
+++ b/blog/2021-04-24-dead-game-clock/comment_1_cc8a2206381ea775584070323f8d4a44._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ ip="77.180.137.153"
+ subject="comment 1"
+ date="2021-04-24T20:35:08Z"
+ content="""
+Just FYI: Neither [Python 2](https://packages.debian.org/bullseye/python2) nor [GTK 2](https://packages.debian.org/bullseye/libgtk2.0-0) were removed from Debian. But the Python 2-GTK 2-bindings were removed.
+"""]]
diff --git a/blog/2021-04-24-dead-game-clock/comment_1_cef75bf07e5146d5fe6fb74c807c44a7._comment b/blog/2021-04-24-dead-game-clock/comment_1_cef75bf07e5146d5fe6fb74c807c44a7._comment
new file mode 100644
index 00000000..9353271a
--- /dev/null
+++ b/blog/2021-04-24-dead-game-clock/comment_1_cef75bf07e5146d5fe6fb74c807c44a7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="216.189.159.184"
+ claimedauthor="superkuh"
+ url="http://superkuh.com/"
+ subject="You're not wrong, but it's more complex."
+ date="2021-04-24T21:18:26Z"
+ content="""
+Debian 11 (bullseye) does have python 2.7 in the normal repos by default. It just isn't installed by default. The same is true for libgtk2.0 but unfortunately pygtk2 is *not* available. So you're not wrong. Thanks for the software while it lasted.
+"""]]

clarify the distinction between monkeysign and sphere
diff --git a/blog/2021-04-24-dead-game-clock.mdwn b/blog/2021-04-24-dead-game-clock.mdwn
index a8856ae5..3370db30 100644
--- a/blog/2021-04-24-dead-game-clock.mdwn
+++ b/blog/2021-04-24-dead-game-clock.mdwn
@@ -34,6 +34,7 @@ include:
 
 PS: [Monkeysign](http://web.monkeysphere.info/monkeysign) also suffered the same fate, for what that's
 worth. Alternatives include [caff](https://tracker.debian.org/pkg/signing-party), [GNOME Keysign](https://wiki.gnome.org/Apps/Keysign), and
-[pius](https://www.phildev.net/pius/).
+[pius](https://www.phildev.net/pius/). Note that this does not affect the larger [Monkeysphere](https://monkeysphere.info)
+project, which will ship with Debian bullseye.
 
 [[!tag debian debian-planet gameclock software python]]

fix link
diff --git a/blog/2008-08-12-cool-chess-clock.mdwn b/blog/2008-08-12-cool-chess-clock.mdwn
index 70762642..0159c32b 100644
--- a/blog/2008-08-12-cool-chess-clock.mdwn
+++ b/blog/2008-08-12-cool-chess-clock.mdwn
@@ -21,6 +21,6 @@ The chessclock can be downloaded [through the Koumbit Redmine site](https://redm
 
 The is also a package in Debian and Ubuntu.
 
-Update: Gameclock died, see the [[obituary|2021-04-dead-game-clock]].
+Update: Gameclock died, see the [[obituary|blog/2021-04-24-dead-game-clock]].
 
 [[!tag "software" "nouvelles" "geek" "debian-planet" gameclock]]

does software get eulogies?
diff --git a/blog/2008-08-12-cool-chess-clock.mdwn b/blog/2008-08-12-cool-chess-clock.mdwn
index 804663b2..70762642 100644
--- a/blog/2008-08-12-cool-chess-clock.mdwn
+++ b/blog/2008-08-12-cool-chess-clock.mdwn
@@ -21,4 +21,6 @@ The chessclock can be downloaded [through the Koumbit Redmine site](https://redm
 
 The is also a package in Debian and Ubuntu.
 
-[[!tag "software" "nouvelles" "geek" "debian-planet"]]
\ No newline at end of file
+Update: Gameclock died, see the [[obituary|2021-04-dead-game-clock]].
+
+[[!tag "software" "nouvelles" "geek" "debian-planet" gameclock]]
diff --git a/blog/2021-04-24-dead-game-clock.mdwn b/blog/2021-04-24-dead-game-clock.mdwn
new file mode 100644
index 00000000..a8856ae5
--- /dev/null
+++ b/blog/2021-04-24-dead-game-clock.mdwn
@@ -0,0 +1,39 @@
+[[!meta title="A dead game clock"]]
+
+Time flies. Back in 2008, I [[wrote a game
+clock|2008-08-12-cool-chess-clock]]. Since then, what was first called
+"chess clock" was renamed to pychessclock and then [Gameclock](https://gitlab.com/anarcat/gameclock)
+(2008). It shipped with Debian 6 squeeze (2011), 7 wheezy (4.0, 2013,
+with a new UI), 8 jessie (5.0, 2015, with a code cleanup, translation,
+go timers), 9 stretch (2017), and 10 buster (2019), phew! Eight years
+in Debian over 4 releases, not bad!
+
+But alas, Debian 11 bullseye (2021) won't ship with Gameclock because
+*both* Python 2 and GTK 2 were removed from Debian. I lack the time,
+interest, and energy to port this program. Even if I could find the
+time, everyone is on their phone nowadays. 
+
+So finding the right toolkit would require some serious thinking about
+how to make a portable program that can run on Linux *and* Android. I
+care less about Mac, iOS, and Windows, but, interestingly, it feels it
+wouldn't be much harder to cover those as well if I hit both Linux and
+Android (which is already hard enough, paradoxically).
+
+(And before you ask, no, Java is not an option for me thanks. If I
+switch to anything else than Python, it would be Golang or Rust. And I
+did [look at some toolkit options a few years ago](https://gitlab.com/anarcat/gameclock/-/issues/1), was excited by
+none.)
+
+So there you have it: that is how software dies, I guess. Alternatives
+include:
+
+ * [Chessclock](https://gnomecoder.wordpress.com/chessclock/) - really old Ruby which made Gameclock rename
+ * [Ghronos](http://ghronos.sourceforge.net/) - also really old Java app
+ * [Lichess](https://lichess.org/) - has a chess clock built into the app
+ * [Otter](https://salsa.debian.org/iwj/otter) - if you squint a little
+
+PS: [Monkeysign](http://web.monkeysphere.info/monkeysign) also suffered the same fate, for what that's
+worth. Alternatives include [caff](https://tracker.debian.org/pkg/signing-party), [GNOME Keysign](https://wiki.gnome.org/Apps/Keysign), and
+[pius](https://www.phildev.net/pius/).
+
+[[!tag debian debian-planet gameclock software python]]

add refs
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 7acb0d3f..91de6973 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -12,7 +12,9 @@ new version, issues I have stumbled upon (and possibly fixed), and
 troubleshooting instructions.
 
 It does not hope to replace the official documentation: it is a
-personal, living document that I have started keeping from [[jessie]].
+personal, living document that I have started keeping back when I
+upgraded to [[jessie]]. The other documents can be found in the parent
+[[upgrades]] page.
 
 # Procedure
 

some alternatives to removed packages
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 198d07e7..7acb0d3f 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -209,7 +209,9 @@ list.
    testing, seems like it is in bad shape
  * [qalculate-gtk](https://tracker.debian.org/pkg/qalculate-gtk), my dearest calculator, was dropped from testing
    too! a team picked up the package, but too late it seems :/
- * usbguard-applet-qt - [removed 0.7.5](https://tracker.debian.org/news/1069337/accepted-usbguard-075ds-1-source-into-unstable/) from [usbguard](https://tracker.debian.org/pkg/usbguard)
+ * usbguard-applet-qt - [removed 0.7.5](https://tracker.debian.org/news/1069337/accepted-usbguard-075ds-1-source-into-unstable/) from [usbguard](https://tracker.debian.org/pkg/usbguard),
+   workaround: find the device ID in `lsbusb` and run `usbguard
+   allow-device id $ID`
    [upstream](https://usbguard.github.io/), with the idea that it was a proof of concept and
    would be maintained outside of the main tree, but no clear
    candidate has emerged just yet, see [this upstream issue](https://github.com/USBGuard/usbguard/issues/334), [this
@@ -236,11 +238,14 @@ following, even if they don't make it to bullseye:
 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
 
-I need to find alternatives to:
+Some other removed packages I have just accepted the removal, with the
+following alternatives:
 
- * gocode
- * gtk-recordmydesktop
- * usbguard applet
+| Package               | Alternative             | Rationale                                      |
+|-----------------------|-------------------------|------------------------------------------------|
+| `gocode`              | `gopls`                 | LSP is the (ad-hoc) standard                   |
+| `gtk-recordmydesktop` | `obs`                   | OBS Studio can also be used for live streaming |
+| `usbguard-applet-qt`  | `usbguard allow-device` | GUI just gone, but commandline might work      |
 
 ### Cool things I want to try
 

yolo
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index eaed2a82..c32cf248 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -24,16 +24,16 @@ I somehow managed to collect a ridiculous pile of old monitors. Here's
 what works and doesn't, in descending order of (totally subjective)
 "quality":
 
-| Model                          | Resolution       | Size  | Contrast | Lat  | Connectors              | Notes                                  | Status         |
-|--------------------------------|------------------|-------|----------|------|-------------------------|----------------------------------------|----------------|
-| [Samsung B2330H][]             | 1920x1080@60Hz   | 23"   | 70000:1  | 5ms  | VGA HDMI DVI            | molten hole in the back                | lent to alexis |
-| [LG Flatron Wide L204WTX-SF][] | 1680x1050@60Hz   | 20"   | 2000:1   | 5ms  | VGA DVI                 | looks great, one dead pixel            | curie          |
-| [Acer X193w][]                 | 1440x900@75Hz    | 19"   | 2000:1   | 5ms  | VGA DVI                 | clean and simple, top partially melted | curie          |
-| [Acer P186HV][]                | 1366x768@60Hz    | 18.5" | 5000:1   | 5ms  | VGA                     | display looks dusty                    |                |
-| [HP L2245wg][]                 | 1680x1050 @ 60Hz | 22"   | 1000:1   | 5ms  | VGA DVI 2xUSB           | LCD TN Film, rotating, 45-65W          | ex-curie       |
-| [Dell 1704FPvt][]              | 1280x1024@60Hz   | 17"   | 1000:1   | 25ms | VGA DVI 4xUSB           | looks square, rotating                 | marcos         |
-| [LG Flatron L1718S][]          | 1280x1024@75Hz   | 17"   | 700:1    | ?    | VGA                     | square, 35W                            |                |
-| [Toshiba 19AV500U][]           | 1440x900@?Hz     | 19"   | ?        | ?    | VGA HDMI component coax | it's a TV! not working in Linux?       |                |
+| Model                          | Resolution       | Size  | Contrast | Lat  | Connectors              | Notes                                  | Status   |
+|--------------------------------|------------------|-------|----------|------|-------------------------|----------------------------------------|----------|
+| [Samsung B2330H][]             | 1920x1080@60Hz   | 23"   | 70000:1  | 5ms  | VGA HDMI DVI            | molten hole in the back                | alexis   |
+| [LG Flatron Wide L204WTX-SF][] | 1680x1050@60Hz   | 20"   | 2000:1   | 5ms  | VGA DVI                 | looks great, one dead pixel            | curie    |
+| [Acer X193w][]                 | 1440x900@75Hz    | 19"   | 2000:1   | 5ms  | VGA DVI                 | clean and simple, top partially melted | curie    |
+| [Acer P186HV][]                | 1366x768@60Hz    | 18.5" | 5000:1   | 5ms  | VGA                     | display looks dusty                    |          |
+| [HP L2245wg][]                 | 1680x1050 @ 60Hz | 22"   | 1000:1   | 5ms  | VGA DVI 2xUSB           | LCD TN Film, rotating, 45-65W          | ex-curie |
+| [Dell 1704FPvt][]              | 1280x1024@60Hz   | 17"   | 1000:1   | 25ms | VGA DVI 4xUSB           | looks square, rotating                 | marcos   |
+| [LG Flatron L1718S][]          | 1280x1024@75Hz   | 17"   | 700:1    | ?    | VGA                     | square, 35W                            |          |
+| [Toshiba 19AV500U][]           | 1440x900@?Hz     | 19"   | ?        | ?    | VGA HDMI component coax | it's a TV! not working in Linux?       |          |
 
 [HP L2245wg]: https://www.cnet.com/products/hp-l2245wg/
 [Toshiba 19AV500U]: https://productz.com/en/toshiba-19av500u/p/eWMGr#full-specs

meh
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index 0e1ef3e4..eaed2a82 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -26,7 +26,7 @@ what works and doesn't, in descending order of (totally subjective)
 
 | Model                          | Resolution       | Size  | Contrast | Lat  | Connectors              | Notes                                  | Status         |
 |--------------------------------|------------------|-------|----------|------|-------------------------|----------------------------------------|----------------|
-| [Samsung B2330H][]             | 1920x1080@60Hz   | 23"   | 70,000:1 | 5ms  | VGA HDMI DVI            | molten hole in the back                | lent to alexis |
+| [Samsung B2330H][]             | 1920x1080@60Hz   | 23"   | 70000:1  | 5ms  | VGA HDMI DVI            | molten hole in the back                | lent to alexis |
 | [LG Flatron Wide L204WTX-SF][] | 1680x1050@60Hz   | 20"   | 2000:1   | 5ms  | VGA DVI                 | looks great, one dead pixel            | curie          |
 | [Acer X193w][]                 | 1440x900@75Hz    | 19"   | 2000:1   | 5ms  | VGA DVI                 | clean and simple, top partially melted | curie          |
 | [Acer P186HV][]                | 1366x768@60Hz    | 18.5" | 5000:1   | 5ms  | VGA                     | display looks dusty                    |                |

merge hp monitor in
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index dad94e03..0e1ef3e4 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -17,50 +17,38 @@ can't quite be 4k yet, according to [this comment](https://forums.puri.sm/t/suit
 be capped at "1440p at 60Hz", which I assume is 2560×1440 or
 [QuadHD](https://en.wikipedia.org/wiki/Graphics_display_resolution#2560_%C3%97_1440_(QHD,_WQHD)), which is already pretty good.
 
-Current monitor
-===============
-
-HP L2245wg
-----------
-
- * 1680x1050 @ 60Hz (16:10)
- * 22" TN Film
- * 90° swivel, -5 to 35° tilt
- * 45-65W
- * VGA, DVI
- * contrast: 1000:1
- * 5ms
- * 2 USB
- * LCD
-
-Update: replaced with the LG Flatron Wid L204WTX-SF, on an "arm",
-because the HP was getting finicky: it would "short" and blank out,
-get all "fuzzy" and weird. The new monitor looks *much* better.
-
-[Upstream](https://support.hp.com/us-en/product/hp-l2245wg-22-inch-widescreen-lcd-monitor/3758498/manuals), [manual](http://h10032.www1.hp.com/ctg/Manual/c01555675), [specs](https://www.cnet.com/products/hp-l2245wg/).
-
-Old monitors
-------------
+Monitor inventory
+=================
 
 I somehow managed to collect a ridiculous pile of old monitors. Here's
 what works and doesn't, in descending order of (totally subjective)
 "quality":
 
-| Model                          | Resolution     | Size  | Contrast | Lat  | Connectors              | Notes                                  | Status         |
-|--------------------------------|----------------|-------|----------|------|-------------------------|----------------------------------------|----------------|
-| [Samsung B2330H][]             | 1920x1080@60Hz | 23"   | 70,000:1 | 5ms  | VGA HDMI DVI            | molten hole in the back                | lent to alexis |
-| [LG Flatron Wide L204WTX-SF][] | 1680x1050@60Hz | 20"   | 2000:1   | 5ms  | VGA DVI                 | looks great, one dead pixel            |                |
-| [Acer X193w][]                 | 1440x900@75Hz  | ?"    | 2000:1   | 5ms  | VGA DVI                 | clean and simple, top partially melted |                |
-| [Acer P186HV][]                | 1366x768@60Hz  | 18.5" | 5000:1   | 5ms  | VGA                     | display looks dusty                    |                |
-| [Dell 1704FPvt][]              | 1280x1024@60Hz | 17"   | 1000:1   | 25ms | VGA DVI 4xUSB           | looks square, rotating                 | marcos         |
-| [Toshiba 19AV500U][]           | 1440x900@?Hz   | 19"   | ?        | ?    | VGA HDMI component coax | it's a TV! not working in Linux?       |                |
-
+| Model                          | Resolution       | Size  | Contrast | Lat  | Connectors              | Notes                                  | Status         |
+|--------------------------------|------------------|-------|----------|------|-------------------------|----------------------------------------|----------------|
+| [Samsung B2330H][]             | 1920x1080@60Hz   | 23"   | 70,000:1 | 5ms  | VGA HDMI DVI            | molten hole in the back                | lent to alexis |
+| [LG Flatron Wide L204WTX-SF][] | 1680x1050@60Hz   | 20"   | 2000:1   | 5ms  | VGA DVI                 | looks great, one dead pixel            | curie          |
+| [Acer X193w][]                 | 1440x900@75Hz    | 19"   | 2000:1   | 5ms  | VGA DVI                 | clean and simple, top partially melted | curie          |
+| [Acer P186HV][]                | 1366x768@60Hz    | 18.5" | 5000:1   | 5ms  | VGA                     | display looks dusty                    |                |
+| [HP L2245wg][]                 | 1680x1050 @ 60Hz | 22"   | 1000:1   | 5ms  | VGA DVI 2xUSB           | LCD TN Film, rotating, 45-65W          | ex-curie       |
+| [Dell 1704FPvt][]              | 1280x1024@60Hz   | 17"   | 1000:1   | 25ms | VGA DVI 4xUSB           | looks square, rotating                 | marcos         |
+| [LG Flatron L1718S][]          | 1280x1024@75Hz   | 17"   | 700:1    | ?    | VGA                     | square, 35W                            |                |
+| [Toshiba 19AV500U][]           | 1440x900@?Hz     | 19"   | ?        | ?    | VGA HDMI component coax | it's a TV! not working in Linux?       |                |
+
+[HP L2245wg]: https://www.cnet.com/products/hp-l2245wg/
 [Toshiba 19AV500U]: https://productz.com/en/toshiba-19av500u/p/eWMGr#full-specs
 [Dell 1704FPvt]: https://www.dell.com/downloads/global/products/monitors/en/spec_1704fp_en.pdf
 [Acer P186HV]: https://productz.com/en/acer-p186hv/p/JJ3rY
 [Acer X193w]: https://www.cnet.com/products/acer-x193w-lcd-monitor/
 [LG Flatron Wide L204WTX-SF]: https://www.lg.com/ca_en/support/product/lg-L204WTX-SF
 [Samsung B2330H]: https://www.samsung.com/us/business/support/owners/product/b2330-series-b2330hd/
+[LG Flatron L1718S]: https://www.lg.com/us/support/product/lg-L1718S-BN.AUS
+
+Update: I replaced with the LG Flatron Wid L204WTX-SF, on an "arm",
+because the HP was getting finicky: it would "short" and blank out,
+get all "fuzzy" and weird. The new monitor looks *much* better.
+
+Extra specs for the HP: [upstream](https://support.hp.com/us-en/product/hp-l2245wg-22-inch-widescreen-lcd-monitor/3758498/manuals), [manual](http://h10032.www1.hp.com/ctg/Manual/c01555675).
 
 Those monitors do not power up at all:
 

turn monitor list into a table
Easier to compare
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index 4f762a04..dad94e03 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -46,19 +46,21 @@ I somehow managed to collect a ridiculous pile of old monitors. Here's
 what works and doesn't, in descending order of (totally subjective)
 "quality":
 
- * [Samsung B2330H](https://www.samsung.com/us/business/support/owners/product/b2330-series-b2330hd/) 1920x1080@60Hz, 23", 70,000:1, 5ms, VGA, HDMI,
-   DVI, gigantic, molten hole in the back, but works (lent to a
-   coworker)
- * [LG Flatron Wide L204WTX-SF](https://www.lg.com/ca_en/support/product/lg-L204WTX-SF) 1680x1050@60Hz, 20", 2000:1, 5ms,
-   VGA, DVI, looks great, one dead pixel
- * [Acer X193w](https://www.cnet.com/products/acer-x193w-lcd-monitor/) 1440x900@75Hz, 2000:1, 5ms VGA, DVI, clean and
-   simple, top partially melted
- * [Acer P186HV](https://productz.com/en/acer-p186hv/p/JJ3rY) 1366x768@60Hz, 18.5", 5000:1, 5ms, VGA, display
-   looks dusty (physically and in the image)
- * [Dell 1704FPvt](https://www.dell.com/downloads/global/products/monitors/en/spec_1704fp_en.pdf) 1280x1024@60Hz, 17", 1000:1, 25ms, VGA, DVI, USB
-   4-port hub, looks square, rotating (used as a console for a server)
- * [Toshiba 19AV500U](https://productz.com/en/toshiba-19av500u/p/eWMGr#full-specs) 1440x900, 19", VGA, HDMI, "component",
-   antenna coax (it's a TV!), can't make it work in Linux
+| Model                          | Resolution     | Size  | Contrast | Lat  | Connectors              | Notes                                  | Status         |
+|--------------------------------|----------------|-------|----------|------|-------------------------|----------------------------------------|----------------|
+| [Samsung B2330H][]             | 1920x1080@60Hz | 23"   | 70,000:1 | 5ms  | VGA HDMI DVI            | molten hole in the back                | lent to alexis |
+| [LG Flatron Wide L204WTX-SF][] | 1680x1050@60Hz | 20"   | 2000:1   | 5ms  | VGA DVI                 | looks great, one dead pixel            |                |
+| [Acer X193w][]                 | 1440x900@75Hz  | ?"    | 2000:1   | 5ms  | VGA DVI                 | clean and simple, top partially melted |                |
+| [Acer P186HV][]                | 1366x768@60Hz  | 18.5" | 5000:1   | 5ms  | VGA                     | display looks dusty                    |                |
+| [Dell 1704FPvt][]              | 1280x1024@60Hz | 17"   | 1000:1   | 25ms | VGA DVI 4xUSB           | looks square, rotating                 | marcos         |
+| [Toshiba 19AV500U][]           | 1440x900@?Hz   | 19"   | ?        | ?    | VGA HDMI component coax | it's a TV! not working in Linux?       |                |
+
+[Toshiba 19AV500U]: https://productz.com/en/toshiba-19av500u/p/eWMGr#full-specs
+[Dell 1704FPvt]: https://www.dell.com/downloads/global/products/monitors/en/spec_1704fp_en.pdf
+[Acer P186HV]: https://productz.com/en/acer-p186hv/p/JJ3rY
+[Acer X193w]: https://www.cnet.com/products/acer-x193w-lcd-monitor/
+[LG Flatron Wide L204WTX-SF]: https://www.lg.com/ca_en/support/product/lg-L204WTX-SF
+[Samsung B2330H]: https://www.samsung.com/us/business/support/owners/product/b2330-series-b2330hd/
 
 Those monitors do not power up at all:
 

one more fixed issue
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 771d8491..198d07e7 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -247,14 +247,6 @@ I need to find alternatives to:
  * sway
  * figure out what else is new in bullseye?
 
-### Packages mistakenly removed
-
- * inkscape
- * gnuradio
- * libu2f-host0 - need to test if u2f works without it in firefox/chrome
-
-Workaround: `apt install $PACKAGE`
-
 ### Puppet breaks in bullseye/sid
 
 testing has this ... peculiar notion of itself. instead of announcing
@@ -438,6 +430,21 @@ significant!
 
 Maybe there's a way to figure out which package ate all that much?
 
+### Packages mistakenly removed
+
+Those packages were removed during the upgrade, yet I still want to
+use them:
+
+ * inkscape
+ * gnuradio
+
+Workaround: `apt install $PACKAGE`
+
+The package `libu2f-host0` was also removed and, typically, I needed it
+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.
+
 # Troubleshooting
 
 ## Upgrade failures

more bullseye issues, mostly fixed
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 6be6d8d1..771d8491 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -331,6 +331,10 @@ 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
@@ -357,6 +361,27 @@ Once the upgrade is completed, just reinstall:
 
     apt install webext-browserpass
 
+The extension is quite finicky: i had to disable and re-enable it to
+get the button to show up on the browser interface.
+
+### Double redshift
+
+I had two Redshift items in the notification area (and presumably
+processes too) running after a reboot and re-login. Not sure what's
+going on, it made the monitor "flicker slowly" as it flipped between
+the two configurations somehow.
+
+It seems like the Debian package now ships a systemd unit file in
+`/usr/lib/systemd/user/redshift-gtk.service`, which takes care of the
+startup, so I disabled the hack in my `.xsession` file, nice.
+
+### Emacs took 2 minutes to start
+
+That was because I still had `company-go` in my `.emacs`
+configuration, which meant it was trying to fetch it from MELPA, which
+took forever. I removed it and, anyways, it wouldn't have done it a
+second time so that's fixed.
+
 ### i3-focus and rsendmail delivery failed
 
 I have this custom [i3-focus](https://gitlab.com/anarcat/scripts/blob/master/i3-focus) script to improve on the "alt-tab"

more comemnts ideas
diff --git a/services/wiki/ikiwiki-hugo-conversion.mdwn b/services/wiki/ikiwiki-hugo-conversion.mdwn
index 618c555b..0797d461 100644
--- a/services/wiki/ikiwiki-hugo-conversion.mdwn
+++ b/services/wiki/ikiwiki-hugo-conversion.mdwn
@@ -339,6 +339,11 @@ Discarded alternatives:
 Other ideas:
 
  * [bridgy](https://brid.gy/) "connects websites to social media", including Mastodon
+ * [email gateway](https://rak.ac/blog/2021-03-12-static-comments-in-hugo/) - hugo plugin based on
+   [jekyll-static-comments](https://github.com/mpalmer/jekyll-static-comments) which takes comments by email and adds
+   them inside the page, kind of like how ikiwiki comments work
+   (except with email instead of CGI)
+ * [cactus comments](https://cactus.chat/) "federated comment system for the web, based on the Matrix protocol"
 
 Other converters
 ================

another todo
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index a8e3efbd..6be6d8d1 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -242,6 +242,11 @@ I need to find alternatives to:
  * gtk-recordmydesktop
  * usbguard applet
 
+### Cool things I want to try
+
+ * sway
+ * figure out what else is new in bullseye?
+
 ### Packages mistakenly removed
 
  * inkscape

explicitly note missing packages
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 15e86f97..a8e3efbd 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -224,6 +224,24 @@ See also the official list of [known issues](https://www.debian.org/releases/bul
 
 ## Pending
 
+### Critical packages missing
+
+In the "removed packages" list above, i have decided to keep the
+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
+
+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
+
+I need to find alternatives to:
+
+ * gocode
+ * gtk-recordmydesktop
+ * usbguard applet
+
 ### Packages mistakenly removed
 
  * inkscape

disk space (mostly) resolved
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index c97043fa..15e86f97 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -224,39 +224,6 @@ See also the official list of [known issues](https://www.debian.org/releases/bul
 
 ## Pending
 
-### Too much stuff
-
-I have too much stuff on my computers. I was already a bit short on my
-`/` partition before the upgrade:
-
-    Filesystem                  Size  Used Avail Use% Mounted on
-    /dev/mapper/curie--vg-root   28G   25G  2.8G  90% /
-
-The upgrade downloaded ~7GB of Debian packages, and required an extra
-4.5GB of disk space! Clearly that wouldn't do here, so I had to expand
-the root partition, which ended up like this after the upgrade:
-
-    Filesystem                  Size  Used Avail Use% Mounted on
-    /dev/mapper/curie--vg-root   38G   25G   13G  67% /
-
-I'm surprised that Debian bullseye now would use an extra 4GB of disk
-space! The [disk](https://www.debian.org/releases/testing/amd64/ch03s04.en.html) [requirements](https://www.debian.org/releases/testing/amd64/apds02.en.html) don't seem to have changed in
-decades, yet I keep having to pile up more disk space only to store
-software... We'll see what the end result will be.
-
-Packages I could remove:
-
- * `php*` - maybe some leftover of a dev environment?
-
-After the complete upgrade procedure (but before removing the extra
-kernel):
-
-    Filesystem                  Size  Used Avail Use% Mounted on
-    /dev/mapper/curie--vg-root   38G   28G  9.1G  76% /
-
-So the upgrade *did* use about 3-4GB of disk space, which is quite
-significant!
-
 ### Packages mistakenly removed
 
  * inkscape
@@ -388,6 +355,41 @@ around packaging (which would fix this issue). It also meant it
 totally lost the mails, because postfix panicked and drop the mails
 when it couldn't generate a bounce either.
 
+### Not enough disk space
+
+I have too much stuff on my computers. I was already a bit short on my
+`/` partition before the upgrade:
+
+    Filesystem                  Size  Used Avail Use% Mounted on
+    /dev/mapper/curie--vg-root   28G   25G  2.8G  90% /
+
+The upgrade downloaded ~7GB of Debian packages, and required an extra
+4.5GB of disk space! Clearly that wouldn't do here, so I had to expand
+the root partition, which ended up like this after the upgrade:
+
+    Filesystem                  Size  Used Avail Use% Mounted on
+    /dev/mapper/curie--vg-root   38G   25G   13G  67% /
+
+I'm surprised that Debian bullseye now would use an extra 4GB of disk
+space! The [disk](https://www.debian.org/releases/testing/amd64/ch03s04.en.html) [requirements](https://www.debian.org/releases/testing/amd64/apds02.en.html) don't seem to have changed in
+decades, yet I keep having to pile up more disk space only to store
+software... We'll see what the end result will be.
+
+Packages I have removed:
+
+ * `php*` - maybe some leftover of a dev environment?
+
+After the complete upgrade procedure (but before removing the extra
+kernel):
+
+    Filesystem                  Size  Used Avail Use% Mounted on
+    /dev/mapper/curie--vg-root   38G   28G  9.1G  76% /
+
+So the upgrade *did* use about 3-4GB of disk space, which is quite
+significant!
+
+Maybe there's a way to figure out which package ate all that much?
+
 # Troubleshooting
 
 ## Upgrade failures

fix path to clean_conflicts (which was ran)
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index ffd9fe3f..c97043fa 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -96,7 +96,7 @@ after a reboot. And yes, that's even more dangerous.
         export DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none APT_LISTBUGS_FRONTEND=none &&
         apt full-upgrade -y -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold' &&
         printf "\a" &&
-        /home/anarcat/src/koumbit-scripts/bin/clean_conflicts &&
+        /home/anarcat/src/koumbit-scripts/vps/clean_conflicts &&
         printf "End of Step 5\a\n"
 
  6. Post-upgrade procedures:

outline one problem with apt-list
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 251beb41..ffd9fe3f 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -483,7 +483,9 @@ this, since APT adopted the aptitude patterns:
 
     apt list '?obsolete'
 
-It's unclear how it differs from the above.
+It works well, and the output is digestible, but it will not catch
+versions on the local machine *newer* than in the archive, which might
+be a problem in some cases.
 
 # References
 

lack of time: mostly done, just need to reboot curie
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 4e7722dc..251beb41 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -265,11 +265,6 @@ significant!
 
 Workaround: `apt install $PACKAGE`
 
-### Lack of time
-
-Lacked the time to complete the upgrade on curie, at step 6. Still
-need to fix puppet at the very least, and the remaining stuff.
-
 ### Puppet breaks in bullseye/sid
 
 testing has this ... peculiar notion of itself. instead of announcing

more removed packages, kind of worrisome that smd thing
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 7fd600fd..4e7722dc 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -192,18 +192,29 @@ list.
 
 ## Removed packages
 
+ * [apt-venv](https://tracker.debian.org/pkg/apt-venv) was removed because of an [invalid email address](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979347),
+   seems silly but I guess it makes sense
+ * [debirf](https://tracker.debian.org/pkg/debirf) also had critical bugs, although there's still hope for
+   that guy
+ * [elpy](https://tracker.debian.org/pkg/elpy) is also [failing its test suite](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975535) but hopefully should
+   make it back when that's fixed (although switching to LSP is also
+   an option here)
  * [gocode was removed](https://bugs.debian.org/976642) along with elpa-company-go, need to switch
    to gopls
+ * [gtk-recordmydesktop](https://tracker.debian.org/pkg/gtk-recordmydesktop) - Python 2, dead upstream, see [bug 943983](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943983)
  * Python 2 support is removed! hopefully most of my stuff is already
    Python 3, but I did lose monkeysign and gameclock, as mentioned above
  * Mailman 2 is consequently removed
+ * [syncmaildir](https://tracker.debian.org/pkg/syncmaildir) has a [FTBFS](https://bugs.debian.org/975227) and has been removed from
+   testing, seems like it is in bad shape
+ * [qalculate-gtk](https://tracker.debian.org/pkg/qalculate-gtk), my dearest calculator, was dropped from testing
+   too! a team picked up the package, but too late it seems :/
  * usbguard-applet-qt - [removed 0.7.5](https://tracker.debian.org/news/1069337/accepted-usbguard-075ds-1-source-into-unstable/) from [usbguard](https://tracker.debian.org/pkg/usbguard)
    [upstream](https://usbguard.github.io/), with the idea that it was a proof of concept and
    would be maintained outside of the main tree, but no clear
    candidate has emerged just yet, see [this upstream issue](https://github.com/USBGuard/usbguard/issues/334), [this
    fork](https://github.com/pinotree/usbguard-applet-qt), [usbguard-gnome](https://github.com/6E006B/usbguard-gnome), [usbguard-notifier](https://github.com/Cropi/usbguard-notifier) and also
    [usbauth-all](https://github.com/kochstefan/usbauth-all), none packaged in Debian
- * [gtk-recordmydesktop](https://tracker.debian.org/pkg/gtk-recordmydesktop) - Python 2, dead upstream, see [bug 943983](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943983)
 
 See also the [noteworthy obsolete packages](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#noteworthy-obsolete-packages) list.
 

disk space update
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index f674905d..7fd600fd 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -218,12 +218,14 @@ See also the official list of [known issues](https://www.debian.org/releases/bul
 I have too much stuff on my computers. I was already a bit short on my
 `/` partition before the upgrade:
 
+    Filesystem                  Size  Used Avail Use% Mounted on
     /dev/mapper/curie--vg-root   28G   25G  2.8G  90% /
 
 The upgrade downloaded ~7GB of Debian packages, and required an extra
 4.5GB of disk space! Clearly that wouldn't do here, so I had to expand
 the root partition, which ended up like this after the upgrade:
 
+    Filesystem                  Size  Used Avail Use% Mounted on
     /dev/mapper/curie--vg-root   38G   25G   13G  67% /
 
 I'm surprised that Debian bullseye now would use an extra 4GB of disk
@@ -235,7 +237,16 @@ Packages I could remove:
 
  * `php*` - maybe some leftover of a dev environment?
 
-### Packages mistakenly removed:
+After the complete upgrade procedure (but before removing the extra
+kernel):
+
+    Filesystem                  Size  Used Avail Use% Mounted on
+    /dev/mapper/curie--vg-root   38G   28G  9.1G  76% /
+
+So the upgrade *did* use about 3-4GB of disk space, which is quite
+significant!
+
+### Packages mistakenly removed
 
  * inkscape
  * gnuradio

browserpass mostly resolved
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 99a3b6b3..f674905d 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -235,30 +235,6 @@ Packages I could remove:
 
  * `php*` - maybe some leftover of a dev environment?
 
-### Browserpass fails to upgrade
-
-Upgrade crashed on this:
-
-```
-dpkg: error processing archive /var/cache/apt/archives/webext-browserpass_3.7.2-1+b1_amd64.deb (--unpack):
- unable to open '/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserpass@maximbaz.com/icon.png.dpkg-new': No such file or directory
-Reinstalling /etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json that was moved away
-Errors were encountered while processing:
- /var/cache/apt/archives/webext-browserpass_3.7.2-1+b1_amd64.deb
-```
-
-This is [bug #982758](https://bugs.debian.org/982758). Workaround:
-
-    apt purge webext-browserpass
-
-If the upgrade crashed, purge the package with the same Dpkg options:
-
-    apt -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold' purge webext-browserpass
-
-Once the upgrade is completed, just reinstall:
-
-    apt install webext-browserpass
-
 ### Packages mistakenly removed:
 
  * inkscape
@@ -350,6 +326,30 @@ the first place?
 
 ## Resolved
 
+### Browserpass fails to upgrade
+
+Upgrade crashed on this:
+
+```
+dpkg: error processing archive /var/cache/apt/archives/webext-browserpass_3.7.2-1+b1_amd64.deb (--unpack):
+ unable to open '/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserpass@maximbaz.com/icon.png.dpkg-new': No such file or directory
+Reinstalling /etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json that was moved away
+Errors were encountered while processing:
+ /var/cache/apt/archives/webext-browserpass_3.7.2-1+b1_amd64.deb
+```
+
+This is [bug #982758](https://bugs.debian.org/982758). Workaround:
+
+    apt purge webext-browserpass
+
+If the upgrade crashed, purge the package with the same Dpkg options:
+
+    apt -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold' purge webext-browserpass
+
+Once the upgrade is completed, just reinstall:
+
+    apt install webext-browserpass
+
 ### i3-focus and rsendmail delivery failed
 
 I have this custom [i3-focus](https://gitlab.com/anarcat/scripts/blob/master/i3-focus) script to improve on the "alt-tab"

sort
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index c4f2c20b..99a3b6b3 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -127,90 +127,6 @@ after a reboot. And yes, that's even more dangerous.
         apt-forktracer | sort
         printf "All procedures completed\a\n" &&
 
-## Finding orphaned and weird packages
-
-The [apt-forktracer](https://owsiany.pl/apt-forktracer-page) call used to have many other different
-incantations, and it's not yet clear that it does everything we
-need. What we want to find are basically packages that are not
-"canonical Debian packages", which are shipped by the stable Debian
-distribution. Those are typically called "obsolete" packages in
-Debian, but that term is somewhat to narrow, as I also want to
-consider packages that were *never* part of Debian at all.
-
-Weirdly, the release notes suggest *three* different methods to do
-this, in different part of the documentation. (Filed this as a bug in
-[987017](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987017).)
-
-This section tries to figure out the right way forward. See also [step
-4.2.2](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages), [4.8](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#obsolete) and [this forum](https://askubuntu.com/questions/98223/how-do-i-get-a-list-of-obsolete-packages).
-
-### aptitude search 1
-
-This is the first way I found:
-
-    aptitude search '?narrow(?not(?archive("^[^n][^o][^w].*$")),?version(CURRENT))'
-
-This incantation comes from the
-[[cross-upgrade|services/upgrades/cross-architecture/]]
-documentation. It selects packages that are currently installed
-(`?narrow(...,?version(CURRENT))`) from an archive other than "now"
-(`?not(?archive("^[^n][^o][^w].*$")`). This was cargo-culted from
-[Ewan's cross-upgrading documentation](http://www.nanonanonano.net/linux/debian/crossgrading).
-
-Nowadays, the release notes actually suggest a similar pattern:
-
-    aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
-
-### apt-show-versions
-
-I also found this somewhat works to find weird packages:
-
-    apt-show-versions | grep -v /bullseye
-
-This uses the more flexible [[!debpkg apt-show-version]] to list
-everything that is not in the `bullseye` repository. But the regex
-could hide third-party repositories that happen to reuse that
-codename. It can also yield strange results like:
-
-    linux-libc-dev:i386 not installed
-
-Those are presumably harmless, so this might be a better call:
-
-    apt-show-versions | grep -v /bullseye | grep -v 'not installed$'
-
-... to filter out those packages.
-
-### aptitude 2: ~obsolete
-
-Then the release notes also suggest this:
-
-    aptitude search '?obsolete'
-    
-This command has been recommended to [find obsolete packages](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#obsolete)
-[since buster](https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html#obsolete).
-
-### apt-forktracer
-
-This one is fairly new to the game, at least as far as I am concerned:
-
-    apt-forktracer | sort
-
-This will not find packages that are from a *newer* version (for
-example from "testing" in "stable").
-
-It's *also* recommended by the release notes. I've settled on it
-because its output is so much simpler, but I still need to compare the
-various results.
-
-### apt list
-
-Starting from bullseye, ironically, we have *another* way of doing
-this, since APT adopted the aptitude patterns:
-
-    apt list '?obsolete'
-
-It's unclear how it differs from the above.
-
 # Notable changes
 
 Here are some packages with notable version changes that I
@@ -468,6 +384,90 @@ If there's any trouble during reboots, you should use some recovery
 system. The [release notes actually have good documentation on
 that](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#recovery), on top of "use a live filesystem".
 
+## Finding orphaned and weird packages
+
+The [apt-forktracer](https://owsiany.pl/apt-forktracer-page) call above used to have many other different
+incantations, and it's not yet clear that it does everything we
+need. What we want to find are basically packages that are not
+"canonical Debian packages", which are shipped by the stable Debian
+distribution. Those are typically called "obsolete" packages in
+Debian, but that term is somewhat to narrow, as I also want to
+consider packages that were *never* part of Debian at all.
+
+Weirdly, the release notes suggest *three* different methods to do
+this, in different part of the documentation. (Filed this as a bug in
+[987017](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987017).)
+
+This section tries to figure out the right way forward. See also [step
+4.2.2](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages), [4.8](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#obsolete) and [this forum](https://askubuntu.com/questions/98223/how-do-i-get-a-list-of-obsolete-packages).
+
+### aptitude search 1
+
+This is the first way I found:
+
+    aptitude search '?narrow(?not(?archive("^[^n][^o][^w].*$")),?version(CURRENT))'
+
+This incantation comes from the
+[[cross-upgrade|services/upgrades/cross-architecture/]]
+documentation. It selects packages that are currently installed
+(`?narrow(...,?version(CURRENT))`) from an archive other than "now"
+(`?not(?archive("^[^n][^o][^w].*$")`). This was cargo-culted from
+[Ewan's cross-upgrading documentation](http://www.nanonanonano.net/linux/debian/crossgrading).
+
+Nowadays, the release notes actually suggest a similar pattern:
+
+    aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
+
+### apt-show-versions
+
+I also found this somewhat works to find weird packages:
+
+    apt-show-versions | grep -v /bullseye
+
+This uses the more flexible [[!debpkg apt-show-version]] to list
+everything that is not in the `bullseye` repository. But the regex
+could hide third-party repositories that happen to reuse that
+codename. It can also yield strange results like:
+
+    linux-libc-dev:i386 not installed
+
+Those are presumably harmless, so this might be a better call:
+
+    apt-show-versions | grep -v /bullseye | grep -v 'not installed$'
+
+... to filter out those packages.
+
+### aptitude 2: ~obsolete
+
+Then the release notes also suggest this:
+
+    aptitude search '?obsolete'
+    
+This command has been recommended to [find obsolete packages](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#obsolete)
+[since buster](https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html#obsolete).
+
+### apt-forktracer
+
+This one is fairly new to the game, at least as far as I am concerned:
+
+    apt-forktracer | sort
+
+This will not find packages that are from a *newer* version (for
+example from "testing" in "stable").
+
+It's *also* recommended by the release notes. I've settled on it
+because its output is so much simpler, but I still need to compare the
+various results.
+
+### apt list
+
+Starting from bullseye, ironically, we have *another* way of doing
+this, since APT adopted the aptitude patterns:
+
+    apt list '?obsolete'
+
+It's unclear how it differs from the above.
+
 # References
 
  * [Official guide](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html) (WIP)

u2f oddity
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index ed8b5468..c4f2c20b 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -347,6 +347,7 @@ Once the upgrade is completed, just reinstall:
 
  * inkscape
  * gnuradio
+ * libu2f-host0 - need to test if u2f works without it in firefox/chrome
 
 Workaround: `apt install $PACKAGE`
 

browserpass workaround
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index eb7cbb63..ed8b5468 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -333,9 +333,15 @@ Errors were encountered while processing:
 
 This is [bug #982758](https://bugs.debian.org/982758). Workaround:
 
+    apt purge webext-browserpass
+
+If the upgrade crashed, purge the package with the same Dpkg options:
+
     apt -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold' purge webext-browserpass
 
-Presumably it can be reinstalled after?
+Once the upgrade is completed, just reinstall:
+
+    apt install webext-browserpass
 
 ### Packages mistakenly removed:
 

more python libs fail
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 2d582343..eb7cbb63 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -105,6 +105,10 @@ after a reboot. And yes, that's even more dangerous.
         puppet agent --enable &&
         puppet agent -t --noop &&
         (puppet agent -t || true) &&
+        : reinstall Python packages to follow Python upgrade &&
+        for package in rsendmail pubpaste ; do
+            cd ~/src/$package && pip3 install .
+        done &&
         systemctl start apt-daily.timer &&
         printf "End of Step 6\a\n" &&
         shutdown -r +1 "rebooting to get rid of old kernel image..."
@@ -423,7 +427,7 @@ the first place?
 
 ## Resolved
 
-### i3-focus failed
+### i3-focus and rsendmail delivery failed
 
 I have this custom [i3-focus](https://gitlab.com/anarcat/scripts/blob/master/i3-focus) script to improve on the "alt-tab"
 behavior, which depends on a python library not in Debian. I have this
@@ -436,6 +440,14 @@ upgrade. Doing this fixed it:
     .virtualenvs/i3_py/bin/pip3 install i3_py
     rm -rf .virtualenvs/i3_py.orig
 
+This is presumably because Python libraries get installed in a
+version-specific directory...
+
+Note that this also crashed [rsendmail](https://gitlab.com/anarcat/rsendmail) which I really need to get
+around packaging (which would fix this issue). It also meant it
+totally lost the mails, because postfix panicked and drop the mails
+when it couldn't generate a bounce either.
+
 # Troubleshooting
 
 ## Upgrade failures

puppet snafu
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index c3218e04..2d582343 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -345,6 +345,82 @@ Workaround: `apt install $PACKAGE`
 Lacked the time to complete the upgrade on curie, at step 6. Still
 need to fix puppet at the very least, and the remaining stuff.
 
+### Puppet breaks in bullseye/sid
+
+testing has this ... peculiar notion of itself. instead of announcing
+itself like a normal Debian stable release, for example:
+
+    anarcat@angela:~(main)$ lsb_release -a
+    No LSB modules are available.
+    Distributor ID:	Debian
+    Description:	Debian GNU/Linux 10 (buster)
+    Release:	10
+    Codename:	buster
+
+It is kind of unsure about its identity:
+
+    vagrant@testing:~$ lsb_release -a
+    No LSB modules are available.
+    Distributor ID:	Debian
+    Description:	Debian GNU/Linux bullseye/sid
+    Release:	testing/unstable
+    Codename:	n/a
+
+When you know how Debian works (that `testing` is really just an old,
+partial copy of `unstable`), that makes sense. But when you create
+Puppet manifests, you expect stuff like:
+
+    if $facts['os']['release']['major'] < 11 {
+        # stuff before bullseye
+    } else {
+        # stuff after bullseye
+    }
+
+To just work. But they don't. In bullseye/sid/testing/unstable,
+however you want to call it, `os.release.major` is actually
+"bullseye/sid". Not "bullseye", not "sid", and, of course, not
+"11". "bullseye/sid". So obviously that just totally breaks when
+comparing to "11".
+
+I tried patching `/etc/os-release`:
+
+    cat >> /etc/os-release <<EOF
+    VERSION_ID="11"
+    VERSION="11 (bullseye)"
+    VERSION_CODENAME=bullseye
+    EOF
+
+But that doesn't seem to work: it looks like `facter -p`, at least,
+takes the major/minor information from... `/etc/debian_version`! So
+you actually need to do this to fix your manifests:
+
+    echo 11.0 > /etc/debian_version
+
+But that's really... quite a hack. To workaround this from the Puppet
+side, I ended up doing this ugly kludge:
+
+    # remove packages gone from bullseye
+    #
+    # XXX: we should really use < 11 here, but os.release.major is
+    # actually "bullseye/sid" now? ouch?
+    #
+    # remove this when we stop supporting buster
+    $bullseye_removed = $facts['os']['distro']['codename'] ? {
+      'bullseye/sid' => absent,
+      'bullseye' => absent,
+      default => present,
+    }
+    package { 'gtk-recordmydesktop':
+      ensure => $bullseye_removed,
+    }
+
+It's unclear to me here where the fault lies. On the one hand, it
+seems that Puppet shouldn't change the type of one of its core facts,
+but on the other, `/etc/debian_version` *is* `bullseye/sid`, a string
+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?
+
 ## Resolved
 
 ### i3-focus failed

more removed stuff
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 8d370bc1..c3218e04 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -277,9 +277,13 @@ list.
  * Python 2 support is removed! hopefully most of my stuff is already
    Python 3, but I did lose monkeysign and gameclock, as mentioned above
  * Mailman 2 is consequently removed
- * usbguard-applet-qt
- * qemu-kvm
- * gtk-recordmydesktop
+ * usbguard-applet-qt - [removed 0.7.5](https://tracker.debian.org/news/1069337/accepted-usbguard-075ds-1-source-into-unstable/) from [usbguard](https://tracker.debian.org/pkg/usbguard)
+   [upstream](https://usbguard.github.io/), with the idea that it was a proof of concept and
+   would be maintained outside of the main tree, but no clear
+   candidate has emerged just yet, see [this upstream issue](https://github.com/USBGuard/usbguard/issues/334), [this
+   fork](https://github.com/pinotree/usbguard-applet-qt), [usbguard-gnome](https://github.com/6E006B/usbguard-gnome), [usbguard-notifier](https://github.com/Cropi/usbguard-notifier) and also
+   [usbauth-all](https://github.com/kochstefan/usbauth-all), none packaged in Debian
+ * [gtk-recordmydesktop](https://tracker.debian.org/pkg/gtk-recordmydesktop) - Python 2, dead upstream, see [bug 943983](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943983)
 
 See also the [noteworthy obsolete packages](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#noteworthy-obsolete-packages) list.
 

link to journald.conf(5) for details on storage
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 5f6540ef..8d370bc1 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -214,7 +214,7 @@ noticed.
 
  * [driverless scanning and printing](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-whats-new.en.html#driverless-operation)
  * persistent systemd journal, which might have some privacy issues
-   (`rm -rf /var/log/journal` to disable)
+   (`rm -rf /var/log/journal` to disable, see [journald.conf(5)](https://manpages.debian.org/bullseye/systemd/journald.conf.5.en.html))
  * last release to support non-merged /usr
  * security archive changed to `deb https://deb.debian.org/debian-security bullseye-security main contrib` (covered by script above)
  * the Intel VA-API driver might give performance boosts and battery

puppet should be a noop, abort otherwise
at least that way we can see what's up
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 09bbd853..5f6540ef 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -103,7 +103,7 @@ after a reboot. And yes, that's even more dangerous.
 
         apt-get update --allow-releaseinfo-change &&
         puppet agent --enable &&
-        (puppet agent -t || true) &&
+        puppet agent -t --noop &&
         (puppet agent -t || true) &&
         systemctl start apt-daily.timer &&
         printf "End of Step 6\a\n" &&

upgrade not finished
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 7970b0a0..09bbd853 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -277,6 +277,9 @@ list.
  * Python 2 support is removed! hopefully most of my stuff is already
    Python 3, but I did lose monkeysign and gameclock, as mentioned above
  * Mailman 2 is consequently removed
+ * usbguard-applet-qt
+ * qemu-kvm
+ * gtk-recordmydesktop
 
 See also the [noteworthy obsolete packages](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#noteworthy-obsolete-packages) list.
 
@@ -326,8 +329,33 @@ This is [bug #982758](https://bugs.debian.org/982758). Workaround:
 
 Presumably it can be reinstalled after?
 
+### Packages mistakenly removed:
+
+ * inkscape
+ * gnuradio
+
+Workaround: `apt install $PACKAGE`
+
+### Lack of time
+
+Lacked the time to complete the upgrade on curie, at step 6. Still
+need to fix puppet at the very least, and the remaining stuff.
+
 ## Resolved
 
+### i3-focus failed
+
+I have this custom [i3-focus](https://gitlab.com/anarcat/scripts/blob/master/i3-focus) script to improve on the "alt-tab"
+behavior, which depends on a python library not in Debian. I have this
+virtualenv to deploy it, but somehow it failed after the
+upgrade. Doing this fixed it:
+
+    mv .virtualenvs/i3_py/ .virtualenvs/i3_py.orig
+    python3 -m venv --system-site-packages ~/.virtualenvs/i3_py
+    cp .virtualenvs/i3_py.orig/bin/activate_this.py .virtualenvs/i3_py/bin/
+    .virtualenvs/i3_py/bin/pip3 install i3_py
+    rm -rf .virtualenvs/i3_py.orig
+
 # Troubleshooting
 
 ## Upgrade failures

toc
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index c3b496ea..7970b0a0 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -1,6 +1,6 @@
 [[!meta title="Bullseye upgrade"]]
 
-[[!toc]]
+[[!toc levels=3]]
 
 It's Debian major upgrade time again! My personal policy is generally
 to upgrade slightly before or during the freeze. This time I feel

start tracking new interesting packages
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 91625db6..c3b496ea 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -223,6 +223,10 @@ noticed.
    from its `$y$` prefix), a major change from the previous default,
    SHA-512 (recognizable from its `$6$` prefix, see [crypt(5)](https://manpages.debian.org/crypt.5))
 
+## New packages
+
+ * the Wayland rewrite of [i3](https://i3wm.org/), [sway](http://swaywm.org/)
+
 ## My packages
 
 In packages I maintain, those are the important changes:

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 .