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.

ideas
diff --git a/blog/cdpath-replacement.mdwn b/blog/cdpath-replacement.mdwn
new file mode 100644
index 00000000..2007a5a6
--- /dev/null
+++ b/blog/cdpath-replacement.mdwn
@@ -0,0 +1,88 @@
+after reading [this post](https://www.kvr.at/posts/my-new-favorite-utility-autojump/) I figured I might as well bite the bullet
+and improve on my CDPATH-related setup, especially because it does not
+work with Emacs. so i looked around for autojump-related alternatives
+that do.
+
+Shell jumpers
+=============
+
+Those are commandline tools that can be used from a shell, generally
+with built-in shell integration so that a shell alias will find the
+right directory magically, usually by keeping track of the directories
+visited with `cd`.
+
+Some of those may or may not have integration in Emacs.
+
+autojump
+--------
+
+https://github.com/wting/autojump 
+
+not in emacs, just in eshell
+https://github.com/coldnew/eshell-autojump
+
+https://stackoverflow.com/questions/25277748/use-z-jump-around-in-emacs-to-find-directories
+
+fasd
+----
+
+https://github.com/clvv/fasd
+
+upstream packaged in debian, but those emacs extensions:
+
+ * helm integration: https://github.com/ajsalminen/helm-fasd (not in melpa?)
+ * more direct: https://framagit.org/steckerhalter/emacs-fasd
+
+z
+-
+
+ungooglable.
+
+https://github.com/rupa/z
+
+not in debian at all.
+
+helm integration: https://melpa.org/#/helm-z
+eshell integration: https://github.com/xuchunyang/eshell-z
+
+fzf
+---
+
+https://github.com/junegunn/fzf
+
+the original "fuzzer". uses `find` by default, so no notion of
+frequency.
+
+emacs integration: https://github.com/bling/fzf.el
+
+similar projects: https://github.com/junegunn/fzf/wiki/Related-projects
+
+Emacs plugins not integrated with the shell
+===========================================
+
+Those projects can be used to track files inside a project or find
+files around directories, but do not offer the equivalent
+functionality in the shell.
+
+projectile
+----------
+
+https://github.com/bbatsov/projectile
+
+supports ido, ivy, or helm.
+
+elpy?
+-----
+
+bookmarks.el
+------------
+
+recentf
+-------
+
+references
+==========
+
+https://www.emacswiki.org/emacs/LocateFilesAnywhere
+
+[[!tag draft]]

yolo
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index 9b2d33f5..7475ba2c 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -91,6 +91,8 @@ Normal
  * [Philips Moniteur 276E8VJSB 27 po, IPS 4K UHD 3840 x 2160, 60Hz,
    5ms](https://www.bureauengros.ca/products/2939812-fr-philips-moniteur-276e8vjsb-27-po-ips-4k-uhd-3840-x-2160-60hz-5ms) (BEG: 380$)
 
+Another idea: a [USB C monitor](https://etbe.coker.com.au/2020/07/02/desklab-portable-usb-c-monitor/)
+
 Note on latency
 ---------------
 

new hardware and people
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index 49cb7e22..9b2d33f5 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -84,6 +84,10 @@ Normal
    computers: 270$)
  * [Dell U2419H 24" Ultrasharp LED Monitor 1920 x 1080 - IPS](https://www.canadacomputers.com/product_info.php?cPath=22_1195_700_1103&item_id=133314):
    (Canada computers: $320, special order)
+ * same at amazon, 27", https://www.amazon.com/dp/B07KGR784M/, as
+   suggested by [this
+   article](https://arstechnica.com/features/2020/08/work-from-home-01-ergo/),
+   see also https://www.amazon.com/dp/B082X46ZGD/
  * [Philips Moniteur 276E8VJSB 27 po, IPS 4K UHD 3840 x 2160, 60Hz,
    5ms](https://www.bureauengros.ca/products/2939812-fr-philips-moniteur-276e8vjsb-27-po-ips-4k-uhd-3840-x-2160-60hz-5ms) (BEG: 380$)
 
diff --git a/services/dns.mdwn b/services/dns.mdwn
index f2b4bfe8..a7809cbc 100644
--- a/services/dns.mdwn
+++ b/services/dns.mdwn
@@ -92,6 +92,7 @@ Les noms suivants pourraient être utilisés pour de futures machines:
    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!
 
 [Margaret Hamilton]: https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer)
 

two more awesome people
diff --git a/services/dns.mdwn b/services/dns.mdwn
index 27cab389..f2b4bfe8 100644
--- a/services/dns.mdwn
+++ b/services/dns.mdwn
@@ -87,6 +87,11 @@ 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
 
 [Margaret Hamilton]: https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer)
 

ship date
diff --git a/hardware/laptop/purism-librem13v4.mdwn b/hardware/laptop/purism-librem13v4.mdwn
index fab16286..d4efb3c6 100644
--- a/hardware/laptop/purism-librem13v4.mdwn
+++ b/hardware/laptop/purism-librem13v4.mdwn
@@ -535,3 +535,4 @@ The timeline of that laptop's hardware problems looks like this:
  * 2020-07-26: response: repair failed, new device will be sent, "ETA
    next week by the end of next week"
  * 2020-08-04: replacement ready, prompted for address again
+ * 2020-08-06: laptop shipped

another nice book
diff --git a/wishlist.mdwn b/wishlist.mdwn
index 2c6b5bf3..7595ca2c 100644
--- a/wishlist.mdwn
+++ b/wishlist.mdwn
@@ -52,6 +52,7 @@ Voici des choses que vous pouvez m'acheter si vous êtes le Père Nowel (yeah ri
      * [La théorie du drone](http://www.worldcat.org/oclc/847564093)
      * [The ARRL Operating Manual](http://www.arrl.org/shop/The-ARRL-Operating-Manual/)
      * [Les idées noires](https://en.wikipedia.org/wiki/Id%C3%A9es_noires) de Franquin, [l'intégrale](http://www.worldcat.org/oclc/493932411)
+     * [99% invisible city](https://99percentinvisible.org/book/)
  * <del>une liseuse 13" comme le [Sony DPT-S1](https://www.sony.com/electronics/digital-paper-notepads/dpts1#product_details_default) ou le [Onyx BOOX Max](https://onyxboox.com/boox_max),
    ou encore une tablette rootable qui roule le plus de logiciel libre
    possible</del> - j'en ai un maintenant, voir aussi [[hardware/tablet]]

update: maybe shipped soon?
diff --git a/hardware/laptop/purism-librem13v4.mdwn b/hardware/laptop/purism-librem13v4.mdwn
index d85a3b2b..fab16286 100644
--- a/hardware/laptop/purism-librem13v4.mdwn
+++ b/hardware/laptop/purism-librem13v4.mdwn
@@ -534,3 +534,4 @@ The timeline of that laptop's hardware problems looks like this:
  * 2020-07-25: ping sent
  * 2020-07-26: response: repair failed, new device will be sent, "ETA
    next week by the end of next week"
+ * 2020-08-04: replacement ready, prompted for address again

problem with dark mode and privacy
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index d79c1e53..29a5ad0e 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -294,7 +294,9 @@ that I version-control into git:
  * `network.cookie.cookieBehavior` ([ref](http://kb.mozillazine.org/Network.cookie.cookieBehavior#3_2)):
    1 (no third-party cookies)
  * `browser.in-content.dark-mode`: true (prefer dark CSS, see [this
-   discussion](https://css-tricks.com/dark-modes-with-css/), new in FF ~68)
+   discussion](https://css-tricks.com/dark-modes-with-css/), [new in FF 67](https://blog.logrocket.com/whats-new-in-firefox-67-prefers-color-scheme-and-more-195be81df03f/)), does not work with
+   `privacy.resistFingerprinting`, use `ui.systemUsesDarkTheme` set to
+   `1` instead. see [this doc](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme)
  * `middlemouse.contentLoadURL` ([ref](http://kb.mozillazine.org/Middlemouse.contentLoadURL)):
    false (got used to chromium not doing that, and it seems too risky:
    passwords can leak in DNS too easily if you miss the field)

fix formatting problem
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index fae57ec3..d79c1e53 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -120,7 +120,7 @@ hard to use or simply irrelevant.
  * [Cookie autodelete](https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/) - even though uMatrix stops most cookies
    from being sent, it actually stores them locally. it would be great
    if this could sync with umatrix block lists... maybe with [issue
-   #43](https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/issues/43)? turns out this is too inconvenient: need to specify the
+   43](https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/issues/43)? turns out this is too inconvenient: need to specify the
    cookies to keep per container, then per site, it's a huge mess and
    there's no way to run a "simulation" mode... either the cookies get
    deleted and you get kicked out everywhere (at once!) or it does

approve comment
diff --git a/blog/2020-06-10-gnutls-audit/comment_1_8c16cd71ac43a3c4449ef84cb0864038._comment b/blog/2020-06-10-gnutls-audit/comment_1_8c16cd71ac43a3c4449ef84cb0864038._comment
new file mode 100644
index 00000000..67c58fea
--- /dev/null
+++ b/blog/2020-06-10-gnutls-audit/comment_1_8c16cd71ac43a3c4449ef84cb0864038._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ ip="90.208.192.45"
+ claimedauthor="Peter Green"
+ subject="Client verses server."
+ date="2020-07-27T15:25:48Z"
+ content="""
+You seem to be assuming that this vulnerability affects gnutls clients, but my reading of the advisory is that it is an issue with gnutls servers.
+
+Can anyone with deeper knowledge of the vulnerability clarify?
+"""]]
diff --git a/blog/2020-06-10-gnutls-audit/comment_1_9511d5d7a8d44aaabd7fbf63f17bb99c._comment b/blog/2020-06-10-gnutls-audit/comment_1_9511d5d7a8d44aaabd7fbf63f17bb99c._comment
new file mode 100644
index 00000000..d42f9279
--- /dev/null
+++ b/blog/2020-06-10-gnutls-audit/comment_1_9511d5d7a8d44aaabd7fbf63f17bb99c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ ip="50.39.163.217"
+ claimedauthor="Josh"
+ subject="OpenSSL licensing is not fixed yet"
+ date="2020-07-27T08:16:24Z"
+ content="""
+> There are at least a few programs that link against GnuTLS because of the OpenSSL licensing oddities but that has been first announced in 2015, then definitely and clearly resolved in 2017 -- or maybe that was in 2018? Anyways it's fixed
+
+Unfortunately, the OpenSSL license is only fixed on the branches leading up to OpenSSL 3.0, which hasn't been released yet; it's still in alpha.
+"""]]

approve comment
diff --git a/blog/2020-06-10-gnutls-audit/comment_1_183d6ddbea4e146041ec7e0780416529._comment b/blog/2020-06-10-gnutls-audit/comment_1_183d6ddbea4e146041ec7e0780416529._comment
new file mode 100644
index 00000000..9a24be91
--- /dev/null
+++ b/blog/2020-06-10-gnutls-audit/comment_1_183d6ddbea4e146041ec7e0780416529._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ ip="193.16.224.12"
+ claimedauthor="anonym guy"
+ subject="comment 2"
+ date="2020-07-27T12:40:21Z"
+ content="""
+And what about: 
+
+https://www.libressl.org/
+"""]]

purism status update
diff --git a/hardware/laptop/purism-librem13v4.mdwn b/hardware/laptop/purism-librem13v4.mdwn
index 68439f49..d85a3b2b 100644
--- a/hardware/laptop/purism-librem13v4.mdwn
+++ b/hardware/laptop/purism-librem13v4.mdwn
@@ -531,3 +531,6 @@ The timeline of that laptop's hardware problems looks like this:
  * 2020-07-13: ping sent to Purism
  * 2020-07-13: [update to this review published](/blog/2020-07-13-not-recommending-purism)
  * 2020-07-14: response: motherboard confirmed dead
+ * 2020-07-25: ping sent
+ * 2020-07-26: response: repair failed, new device will be sent, "ETA
+   next week by the end of next week"

Added a comment: comment removed
diff --git a/blog/2020-07-13-not-recommending-purism/comment_6_24f29cfc00da5c43ca95a0a1d51975f9._comment b/blog/2020-07-13-not-recommending-purism/comment_6_24f29cfc00da5c43ca95a0a1d51975f9._comment
new file mode 100644
index 00000000..1ad37174
--- /dev/null
+++ b/blog/2020-07-13-not-recommending-purism/comment_6_24f29cfc00da5c43ca95a0a1d51975f9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="https://seccdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="comment removed"
+ date="2020-07-19T13:05:04Z"
+ content="""
+A comment questioning the fact that Purism allows racism was removed. (The word *racism* was \"quoted\" in the original comment, which makes me believe the author was also questioning the existence of racism itself, which I find to be just despicable.)
+
+People interested in criticizing my stance on Purism's \"tolerance\" of neonazis and related ideologies are welcome to read [[my previous post on the topic|2019-05-13-free-speech]] and generally, just shove off somewhere else.
+
+Yes, you have found a Social Justice Warrior. Don't wet your pants too much, there's plenty of us out there.
+"""]]

-port isn't necessary as we have a proxy
diff --git a/services/analytics.mdwn b/services/analytics.mdwn
index 3af0b8ab..2dec9d28 100644
--- a/services/analytics.mdwn
+++ b/services/analytics.mdwn
@@ -31,7 +31,7 @@ Server configuration
 
  3. start the server:
 
-        exec docker run --restart=unless-stopped --volume="goatcounter:/home/user/db/" --publish 127.0.0.1:8081:8080 --detach zgoat/goatcounter serve -listen :8080 -port 8080 -tls none
+        exec docker run --restart=unless-stopped --volume="goatcounter:/home/user/db/" --publish 127.0.0.1:8081:8080 --detach zgoat/goatcounter serve -listen :8080 -tls none
 
  4. apache configuration:
 

more todos
diff --git a/services/analytics.mdwn b/services/analytics.mdwn
index 0939c712..3af0b8ab 100644
--- a/services/analytics.mdwn
+++ b/services/analytics.mdwn
@@ -73,8 +73,8 @@ Server configuration
 Remaining issues
 ================
 
- * the :8080 port leaks in some places, namely in the "Site config"
-   documentation
+ * Docker image should be `FROM scratch`, this is statically built
+   golang stuff after all...
  * move to Docker Compose or podman instead of just starting the thing
    by hand
  * this is all super janky and should be put in config management
@@ -82,8 +82,8 @@ Remaining issues
  * remove "anarc.at" test site (the site is the analytics site, not
    the tracked site), seems like [this is not possible yet](https://github.com/zgoat/goatcounter/issues/344)
  * do log parsing instead of Javascript or 1x1 images?
- * compare with goaccess logs, probably in september
- * `goatcounter monitor` [doesn't with sqlite](https://github.com/zgoat/goatcounter/issues/343)
+ * compare with goaccess logs, probably at the end of july, to have
+   two full weeks to compare
 
 Fixed issues
 ============
@@ -95,5 +95,9 @@ Fixed issues
  * <del>add pixel tracking for `noscript` users</del> done, but
    required a [patch to ikiwi](https://ikiwiki.info/ikiwiki.cgi?do=goto&page=todo%2Finclude_page_variable_in_base_templates) (and I noticed [another bug while
    doing it](https://ikiwiki.info/ikiwiki.cgi?do=goto&page=bugs%2Fjavascript_resources_placed_after_html_tag))
+ * `goatcounter monitor` [doesn't with sqlite](https://github.com/zgoat/goatcounter/issues/343) (fixed upstream!)
+ * <del>the :8080 port leaks in some places, namely in the "Site config"
+   documentation</del> that is because i was using `-port 8080` which
+   was not necessary.
 
 [[!tag blog debian-planet python-planet privacy meta ikiwiki stats]]

Added a comment: Re: Praising Pine64
diff --git a/blog/2020-07-13-not-recommending-purism/comment_5_8cfee72fe20550614c1907b35fa7a3d9._comment b/blog/2020-07-13-not-recommending-purism/comment_5_8cfee72fe20550614c1907b35fa7a3d9._comment
new file mode 100644
index 00000000..890a6d3a
--- /dev/null
+++ b/blog/2020-07-13-not-recommending-purism/comment_5_8cfee72fe20550614c1907b35fa7a3d9._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="https://seccdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="Re: Praising Pine64"
+ date="2020-07-16T18:35:05Z"
+ content="""
+> How many of the people running PostmarketOS (or any other distribution) are using Phosh and other apps that were developed for it?
+
+Frankly, I don't know... I had to lookup \"Phosh\", just to give you an idea. I sense this is a rhetorical question and that the answer should be obvious, yet it is not at all, to me.
+
+> You are consistently leaving important details out of the picture. That makes your statements unfair and reflects badly on you.
+
+I am probably leaving out a lot of details out of Pine64, system76, and Fairphone out of this picture. But that's the point, isn't it: this is not a review of Pine64, it's a review of Purism and its hardware. Believe me, when I end up with Pine64 or system76 hardware, I will do a similarly merciless review and hordes of *their* fans will come accusing me of being unfair to *them* then. Maybe that will be a consolation? :p
+
+> As I said I’m all for criticising and you make good points against Purism, but you must apply equal treatment to all.
+
+As you have correctly asserted, I lack information about Pine64. I just felt they are more honest about their work, and I do not believe I have explicitly compared their free **software** work against Purism. What I said in the original post is:
+
+> I wish that people wishing to support the free software **movement** would spend their energy towards organisations that actually do honest work in that direction, like System76 and Pine64. And if you're going to go crazy with an experimental free hardware design, why not go retro with the MNT Reform.
+
+Emphasis added. Maybe you misinterpreted my comment as saying that System76 and Pine64 were contributing more to the **software** part of the ecosystem. That is not what I am saying. I am saying that by contributing cheap and somewhat open hardware that works well on Linux, and being honest about what their promises are, they are being more useful than Purism.
+
+I will be happy to apply the same, hopefully fair, treatment to other manufacturers when I end up with their products falling apart in my hands, when they do.
+
+I will also point out that you seem to get stuck on a tiny part of the lengthy review I (re)announced here. There are way more problems with Purism than their free software contributions. I did not even mention them in the original review, a year ago...
+"""]]

approve comment
diff --git a/blog/2020-07-13-not-recommending-purism/comment_1_1b7a40f08b245add3d6d2100b160b1f3._comment b/blog/2020-07-13-not-recommending-purism/comment_1_1b7a40f08b245add3d6d2100b160b1f3._comment
new file mode 100644
index 00000000..9b1a827c
--- /dev/null
+++ b/blog/2020-07-13-not-recommending-purism/comment_1_1b7a40f08b245add3d6d2100b160b1f3._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ ip="82.242.148.38"
+ claimedauthor="Alexandre Franke"
+ url="https://alexandrefranke.com"
+ subject="Re: Re: Praising Pine64"
+ date="2020-07-16T09:35:37Z"
+ content="""
+>> How much of the PinePhone is working thanks to the work of Purism?
+
+> Really? Probably not much, actually. Most people do not use PureOS on their PinePhone, as far as I know. The reviews I have seen use either PostmarketOS or their own distro on top of it, see for example Drew Devault's review.
+
+How many of the people running PostmarketOS (or any other distribution) are using Phosh and other apps that were developed for it? 
+
+You are consistently leaving important details out of the picture. That makes your statements unfair and reflects badly on *you*. As I said I’m all for criticising and you make good points against Purism, but you must apply equal treatment to all.
+"""]]

clarify trigger warning
diff --git a/blog/2020-07-13-not-recommending-purism.mdwn b/blog/2020-07-13-not-recommending-purism.mdwn
index 8ca40fe4..029565ae 100644
--- a/blog/2020-07-13-not-recommending-purism.mdwn
+++ b/blog/2020-07-13-not-recommending-purism.mdwn
@@ -52,6 +52,9 @@ post. There were more discussions on the subject here:
  * [Reddit /r/linux](http://www.reddit.com/r/linux/comments/hr8hvi/not_recommending_purism), [/r/linuxhardware](https://www.reddit.com/r/linuxhardware/comments/hqs48i/debian_developer_not_recommending_purism/), [r/purism](https://www.reddit.com/r/Purism/comments/hqs0vz/debian_developer_not_recommending_purism/)
  * [Hacker news](https://news.ycombinator.com/item?id=23842347)
 
-Trigger warning: 
+Trigger warning: some of those threads include personal insults and
+explicitly venture into the [[free speech
+discussion|2019-05-13-free-speech]], with predictable (sad)
+consequences...
 
 [[!tag debian-planet python-planet hardware review phone laptop]]

update external discussion links
diff --git a/blog/2020-07-13-not-recommending-purism.mdwn b/blog/2020-07-13-not-recommending-purism.mdwn
index 772ab082..8ca40fe4 100644
--- a/blog/2020-07-13-not-recommending-purism.mdwn
+++ b/blog/2020-07-13-not-recommending-purism.mdwn
@@ -49,10 +49,9 @@ while I usually get about 1k visitors after a week on any regular blog
 post. There were more discussions on the subject here:
 
  * [Lobsters](https://lobste.rs/s/ecyjq2/not_recommending_purism)
- * [Reddit /r/linux 1](http://www.reddit.com/r/linux/comments/hr8hvi/not_recommending_purism), [2](https://www.reddit.com/r/linuxhardware/comments/hqs48i/debian_developer_not_recommending_purism/)
+ * [Reddit /r/linux](http://www.reddit.com/r/linux/comments/hr8hvi/not_recommending_purism), [/r/linuxhardware](https://www.reddit.com/r/linuxhardware/comments/hqs48i/debian_developer_not_recommending_purism/), [r/purism](https://www.reddit.com/r/Purism/comments/hqs0vz/debian_developer_not_recommending_purism/)
  * [Hacker news](https://news.ycombinator.com/item?id=23842347)
 
-It also apparently showed up on /r/ubuntu and /r/purism but
-disapparead, at least from the latter.
+Trigger warning: 
 
 [[!tag debian-planet python-planet hardware review phone laptop]]

typo
diff --git a/blog/2020-07-13-not-recommending-purism.mdwn b/blog/2020-07-13-not-recommending-purism.mdwn
index ff54ef1a..772ab082 100644
--- a/blog/2020-07-13-not-recommending-purism.mdwn
+++ b/blog/2020-07-13-not-recommending-purism.mdwn
@@ -49,7 +49,7 @@ while I usually get about 1k visitors after a week on any regular blog
 post. There were more discussions on the subject here:
 
  * [Lobsters](https://lobste.rs/s/ecyjq2/not_recommending_purism)
- * [Reddit /r/linux 1](http://www.reddit.com/r/linux/comments/hr8hvi/not_recommending_purism) [2](https://www.reddit.com/r/linuxhardware/comments/hqs48i/debian_developer_not_recommending_purism/), 
+ * [Reddit /r/linux 1](http://www.reddit.com/r/linux/comments/hr8hvi/not_recommending_purism), [2](https://www.reddit.com/r/linuxhardware/comments/hqs48i/debian_developer_not_recommending_purism/)
  * [Hacker news](https://news.ycombinator.com/item?id=23842347)
 
 It also apparently showed up on /r/ubuntu and /r/purism but

link to other discussions
diff --git a/blog/2020-07-13-not-recommending-purism.mdwn b/blog/2020-07-13-not-recommending-purism.mdwn
index 6c1b6d31..ff54ef1a 100644
--- a/blog/2020-07-13-not-recommending-purism.mdwn
+++ b/blog/2020-07-13-not-recommending-purism.mdwn
@@ -44,4 +44,15 @@ the [Fairphone](https://www.fairphone.com/) a fair chance. It really is a "fair"
 the best, but okay) phone that you can moderately liberate, and it
 actually frigging works. See also my [hardware review of the FP2](/hardware/phone/fairphone2).
 
+Update: this kind of blew up, for my standards: 10k visitors in ~24h
+while I usually get about 1k visitors after a week on any regular blog
+post. There were more discussions on the subject here:
+
+ * [Lobsters](https://lobste.rs/s/ecyjq2/not_recommending_purism)
+ * [Reddit /r/linux 1](http://www.reddit.com/r/linux/comments/hr8hvi/not_recommending_purism) [2](https://www.reddit.com/r/linuxhardware/comments/hqs48i/debian_developer_not_recommending_purism/), 
+ * [Hacker news](https://news.ycombinator.com/item?id=23842347)
+
+It also apparently showed up on /r/ubuntu and /r/purism but
+disapparead, at least from the latter.
+
 [[!tag debian-planet python-planet hardware review phone laptop]]

fix tag name
diff --git a/services/analytics.mdwn b/services/analytics.mdwn
index a2a144b6..0939c712 100644
--- a/services/analytics.mdwn
+++ b/services/analytics.mdwn
@@ -96,4 +96,4 @@ Fixed issues
    required a [patch to ikiwi](https://ikiwiki.info/ikiwiki.cgi?do=goto&page=todo%2Finclude_page_variable_in_base_templates) (and I noticed [another bug while
    doing it](https://ikiwiki.info/ikiwiki.cgi?do=goto&page=bugs%2Fjavascript_resources_placed_after_html_tag))
 
-[[!tag blog debian-planet python-planet privacy meta ikiwiki stat]]
+[[!tag blog debian-planet python-planet privacy meta ikiwiki stats]]
diff --git a/tag/stat.mdwn b/tag/stat.mdwn
deleted file mode 100644
index e061f111..00000000
--- a/tag/stat.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-[[!meta title="pages tagged stat"]]
-
-[[!inline pages="tagged(stat)" actions="no" archive="yes"
-feedshow=10]]

try to fix ikiwiki freaking out about gt
diff --git a/services/analytics.mdwn b/services/analytics.mdwn
index a7a79c56..a2a144b6 100644
--- a/services/analytics.mdwn
+++ b/services/analytics.mdwn
@@ -41,15 +41,15 @@ Server configuration
                     DocumentRoot /var/www/html/
             </VirtualHost>
 
-            <VirtualHost *:443>
-                    ServerName analytics.anarc.at
-                    Use common-letsencrypt-ssl analytics.anarc.at
-                    DocumentRoot /var/www/html/
-                    ProxyPass /.well-known/ !
-                    ProxyPass / http://localhost:8081/
-                    ProxyPassReverse / http://localhost:8081/
-                    ProxyPreserveHost on
-            </VirtualHost>
+        <VirtualHost *:443>
+                ServerName analytics.anarc.at
+                Use common-letsencrypt-ssl analytics.anarc.at
+                DocumentRoot /var/www/html/
+                ProxyPass /.well-known/ !
+                ProxyPass / http://localhost:8081/
+                ProxyPassReverse / http://localhost:8081/
+                ProxyPreserveHost on
+        </VirtualHost>
 
  5. add `analytics.anarc.at` to DNS
 

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

make this an article on my blog
diff --git a/services/analytics.mdwn b/services/analytics.mdwn
index 23a43d8b..a7a79c56 100644
--- a/services/analytics.mdwn
+++ b/services/analytics.mdwn
@@ -1,63 +1,99 @@
-goatcounter docker image:
+[[!meta title="Goatcounter analytics in ikiwiki"]]
 
-https://github.com/anarcat/goatcounter
+I have started using [Goatcounter](https://www.goatcounter.com/) for analytics after reading
+[this LWN article](https://lwn.net/Articles/822568/) called "Lightweight alternatives to Google
+Analytics". Goatcounter has an interesting approach to privacy in that
+it:
 
-build:
+> tracks sessions using a hash of the browser's user agent and IP
+> address to identify the client without storing any personal
+> information. The salt used to generate these hashes is rotated every
+> 4 hours with a sliding window.
 
-    docker build -t zgoat/goatcounter .
+There was no Debian package for the project, so I filed a [request for
+package](https://bugs.debian.org/964905) and instead made a [fork of the project to add a Docker
+image](https://github.com/anarcat/goatcounter).
 
-create volume for db:
+This page documents how Goatcounter was setup from there...
 
-    docker volume create goatcounter
+[[!toc]]
 
-startup:
+Server configuration
+====================
 
-    exec docker run --restart=unless-stopped --volume="goatcounter:/home/user/db/" --publish 127.0.0.1:8081:8080 --detach zgoat/goatcounter serve -listen :8080 -port 8080 -tls none
+ 1. build the image from [this fork](https://github.com/anarcat/goatcounter)
 
-need to be committed...
+        docker build -t zgoat/goatcounter .
 
-apache:
+ 2. create volume for db:
 
-    <VirtualHost *:80>
-            ServerName analytics.anarc.at
-            Redirect / https://analytics.anarc.at/
-            DocumentRoot /var/www/html/
-    </VirtualHost>
+        docker volume create goatcounter
 
-    <VirtualHost *:443>
-            ServerName analytics.anarc.at
-            Use common-letsencrypt-ssl analytics.anarc.at
-            DocumentRoot /var/www/html/
-            ProxyPass /.well-known/ !
-            ProxyPass / http://localhost:8081/
-            ProxyPassReverse / http://localhost:8081/
-            ProxyPreserveHost on
-    </VirtualHost>
+ 3. start the server:
 
-+ bind
+        exec docker run --restart=unless-stopped --volume="goatcounter:/home/user/db/" --publish 127.0.0.1:8081:8080 --detach zgoat/goatcounter serve -listen :8080 -port 8080 -tls none
 
-let's encrypt:
+ 4. apache configuration:
 
-    certbot certonly --webroot  -d analytics.anarc.at --webroot-path /var/www/html/
+        <VirtualHost *:80>
+                    ServerName analytics.anarc.at
+                    Redirect / https://analytics.anarc.at/
+                    DocumentRoot /var/www/html/
+            </VirtualHost>
 
-create site:
+            <VirtualHost *:443>
+                    ServerName analytics.anarc.at
+                    Use common-letsencrypt-ssl analytics.anarc.at
+                    DocumentRoot /var/www/html/
+                    ProxyPass /.well-known/ !
+                    ProxyPass / http://localhost:8081/
+                    ProxyPassReverse / http://localhost:8081/
+                    ProxyPreserveHost on
+            </VirtualHost>
 
-    docker run -it --rm --volume="goatcounter:/home/user/db/" zgoat/goatcounter create -domain analytics.anarc.at -email anarcat+rapports@anarc.at
+ 5. add `analytics.anarc.at` to DNS
 
-and add to ikiwiki template (must be committed). then:
+ 6. create a TLS cert with LE:
 
-    ikiwiki --setup ikiwiki.setup --rebuild --verbose
+        certbot certonly --webroot  -d analytics.anarc.at --webroot-path /var/www/html/
 
-remaining issues:
+    note that goatcounter has code to do this on its own, but we avoid
+    it to follow our existing policies and simplify things
 
- * cache headers are wrong (120ms!)
- * some redirects...
- * move docker to compose or podman
- * this is all super janky and should be put in CM somehow
+ 7. create site:
+
+        docker run -it --rm --volume="goatcounter:/home/user/db/" zgoat/goatcounter create -domain analytics.anarc.at -email anarcat+rapports@anarc.at
+
+ 8. [add to ikiwiki template](https://gitlab.com/anarcat/ikiwiki-bootstrap-anarcat/-/commit/bde10038f12218a0cd0cea0a4900d9fd3f23e185)
+
+ 9. rebuild wiki:
+
+        ikiwiki --setup ikiwiki.setup --rebuild --verbose
+
+Remaining issues
+================
+
+ * the :8080 port leaks in some places, namely in the "Site config"
+   documentation
+ * move to Docker Compose or podman instead of just starting the thing
+   by hand
+ * this is all super janky and should be put in config management
+   somehow
+ * remove "anarc.at" test site (the site is the analytics site, not
+   the tracked site), seems like [this is not possible yet](https://github.com/zgoat/goatcounter/issues/344)
+ * do log parsing instead of Javascript or 1x1 images?
+ * compare with goaccess logs, probably in september
+ * `goatcounter monitor` [doesn't with sqlite](https://github.com/zgoat/goatcounter/issues/343)
+
+Fixed issues
+============
+
+ * <del>cache headers are wrong (120ms!)</del> deployed workaround in
+   apache, [reported as a bug upstream](https://github.com/zgoat/goatcounter/issues/342)
  * <del>remove self-referer</del> done, just a matter of configuring
    the URL in the settings. could this be automated too?
- * remove "anarc.at" test site (the site is the analytics site,
-   not the tracked site)
- * add pixel tracking for `noscript` users
- * log parsing?
- * compare with goaccess logs, probably in september
+ * <del>add pixel tracking for `noscript` users</del> done, but
+   required a [patch to ikiwi](https://ikiwiki.info/ikiwiki.cgi?do=goto&page=todo%2Finclude_page_variable_in_base_templates) (and I noticed [another bug while
+   doing it](https://ikiwiki.info/ikiwiki.cgi?do=goto&page=bugs%2Fjavascript_resources_placed_after_html_tag))
+
+[[!tag blog debian-planet python-planet privacy meta ikiwiki stat]]

and yet another patch
diff --git a/services/wiki.mdwn b/services/wiki.mdwn
index 565cdd09..dbae7a85 100644
--- a/services/wiki.mdwn
+++ b/services/wiki.mdwn
@@ -134,6 +134,7 @@ I still carry those patches on top of ikiwiki:
  * [todo/git-annex_support](https://ikiwiki.info/todo/git-annex_support)
  * [todo/allow_toc_to_skip_entries](https://ikiwiki.info/todo/allow_toc_to_skip_entries)
  * [todo/include_page_variable_in_base_templates](https://ikiwiki.info/todo/include_page_variable_in_base_templates)
+ * [bugs/javascript_resources_placed_after_html_tag](https://ikiwiki.info/bugs/javascript_resources_placed_after_html_tag/)
  * [plugins/contrib/i18nheadinganchors](https://ikiwiki.info/plugins/contrib/i18nheadinganchors)
  * [plugins/contrib/bootstrap](https://ikiwiki.info/plugins/contrib/bootstrap)
  * [todo/admonitions](https://ikiwiki.info/todo/admonitions)
@@ -153,6 +154,9 @@ To apply this patch set:
     git rebase $release page-template-variable &&
     git diff $release..page-template-variable | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
     git diff $release..page-template-variable | ( cd /usr/share/perl5 ;    sudo patch -p1 ) &&
+    git rebase $release js-newline &&
+    git diff $release..js-newline | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
+    git diff $release..js-newline | ( cd /usr/share/perl5 ;    sudo patch -p1 ) &&
     git rebase $release i18n-headinganchors &&
     mv /usr/share/perl5/IkiWiki/Plugin/i18nheadinganchors.pm{,.orig} &&
     git diff $release..i18n-headinganchors | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&

replace macros by real links here so they are clickable in emacs
diff --git a/services/wiki.mdwn b/services/wiki.mdwn
index 87443048..565cdd09 100644
--- a/services/wiki.mdwn
+++ b/services/wiki.mdwn
@@ -131,14 +131,14 @@ On any given upgrade, the following patches need to be applied:
 
 I still carry those patches on top of ikiwiki:
 
- * [[!iki todo/git-annex_support]]
- * [[!iki todo/allow_toc_to_skip_entries]]
- * [[!iki plugins/contrib/i18nheadinganchors]]
- * [[!iki plugins/contrib/bootstrap]]
- * [[!iki todo/admonitions]]
- * [[!iki bugs/footnotes-look-weird]] (not a patch on core per se, but
+ * [todo/git-annex_support](https://ikiwiki.info/todo/git-annex_support)
+ * [todo/allow_toc_to_skip_entries](https://ikiwiki.info/todo/allow_toc_to_skip_entries)
+ * [todo/include_page_variable_in_base_templates](https://ikiwiki.info/todo/include_page_variable_in_base_templates)
+ * [plugins/contrib/i18nheadinganchors](https://ikiwiki.info/plugins/contrib/i18nheadinganchors)
+ * [plugins/contrib/bootstrap](https://ikiwiki.info/plugins/contrib/bootstrap)
+ * [todo/admonitions](https://ikiwiki.info/todo/admonitions)
+ * [bugs/footnotes-look-weird](https://ikiwiki.info/bugs/footnotes-look-weird) (not a patch on core per se, but
    a modification to the stylesheet, as [many others](https://anarc.at/bootstrap.local.css))
- * [[!iki todo/include_page_variable_in_base_templates]]
 
 To apply this patch set:
 

new patch against ikiwiki
diff --git a/services/wiki.mdwn b/services/wiki.mdwn
index a98dfea6..87443048 100644
--- a/services/wiki.mdwn
+++ b/services/wiki.mdwn
@@ -138,6 +138,7 @@ I still carry those patches on top of ikiwiki:
  * [[!iki todo/admonitions]]
  * [[!iki bugs/footnotes-look-weird]] (not a patch on core per se, but
    a modification to the stylesheet, as [many others](https://anarc.at/bootstrap.local.css))
+ * [[!iki todo/include_page_variable_in_base_templates]]
 
 To apply this patch set:
 
@@ -149,6 +150,9 @@ To apply this patch set:
     git rebase $release toc-skip &&
     git diff $release..toc-skip | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
     git diff $release..toc-skip | ( cd /usr/share/perl5 ;    sudo patch -p1 ) &&
+    git rebase $release page-template-variable &&
+    git diff $release..page-template-variable | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&
+    git diff $release..page-template-variable | ( cd /usr/share/perl5 ;    sudo patch -p1 ) &&
     git rebase $release i18n-headinganchors &&
     mv /usr/share/perl5/IkiWiki/Plugin/i18nheadinganchors.pm{,.orig} &&
     git diff $release..i18n-headinganchors | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run ) &&

another linux laptop platform
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index 4d85c7a3..18e451bc 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -532,6 +532,12 @@ the i3 is good enough anyways: it has 4 cores instead of 2, takes up
 much less power (15W vs 65W) and has an integrated GPU, even though it
 has a lower actual clock speed (2.3GHz vs 2.93GHz).
 
+Zareason
+========
+
+Didn't know about [Zareason](https://zareason.com/) until [this comment](https://social.weho.st/web/statuses/104516711452286035) in response to
+[this Purism rant](/blog/2020-07-13-not-recommending-purism/)...
+
 Fournisseurs
 ============
 

more todos
diff --git a/services/analytics.mdwn b/services/analytics.mdwn
index 042902d9..23a43d8b 100644
--- a/services/analytics.mdwn
+++ b/services/analytics.mdwn
@@ -54,6 +54,10 @@ remaining issues:
  * some redirects...
  * move docker to compose or podman
  * this is all super janky and should be put in CM somehow
- * remove self-referer
- * remove "anarc.at" test site (the site is the analytics site, not
-   the tracked site)
+ * <del>remove self-referer</del> done, just a matter of configuring
+   the URL in the settings. could this be automated too?
+ * remove "anarc.at" test site (the site is the analytics site,
+   not the tracked site)
+ * add pixel tracking for `noscript` users
+ * log parsing?
+ * compare with goaccess logs, probably in september

Added a comment: Re: Praising Pine64
diff --git a/blog/2020-07-13-not-recommending-purism/comment_3_cfe79ad93cdf23baad79a43f481b0ad4._comment b/blog/2020-07-13-not-recommending-purism/comment_3_cfe79ad93cdf23baad79a43f481b0ad4._comment
new file mode 100644
index 00000000..dbfabe8c
--- /dev/null
+++ b/blog/2020-07-13-not-recommending-purism/comment_3_cfe79ad93cdf23baad79a43f481b0ad4._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="https://seccdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="Re: Praising Pine64"
+ date="2020-07-15T13:15:06Z"
+ content="""
+> I don’t see how Pine64 deserves your praises when they fail to hire software developers to work on things that Purism actually pays people for.
+
+Pine64 deserves our praise exactly for that: they are a hardware company, and they make good hardware, with open schematics, that we can write software for. They don't pretend that they will build a hardware platform, and operating system, and liberate the universe all at once, because that's unrealistic, and they know it.
+
+And Purism knows it too.
+
+> Your criticism of Purism may be well founded, but you can’t then claim that Pine64 is doing better.
+
+Why not?
+
+> How much of the PinePhone is working thanks to the work of Purism?
+
+Really? Probably not much, actually. Most people do not use PureOS on their PinePhone, as far as I know. The reviews I have seen use either PostmarketOS or their own distro on top of it, see for example [Drew Devault's review](https://drewdevault.com/2019/12/18/PinePhone-review.html).
+
+> How much did Pine64 contribute to the software stack?
+
+Arguably, not much. But that's not their job and they don't pretend it is: they're building a phone, a piece of hardware. They try to make it as open as possible so that people can write software for it.
+
+> If Pine64 was actually a bit more Purism-like, they would both be in better shape (and the community would also benefit).
+
+The entire point of my article here is exactly the opposite of that. I believe we are in a better situation with Pine64 *not* faking it and creating real, working, everyday hardware that people can use instead of promising the moon and then failing to deliver.
+
+Besides, I'm not sure that \"Praising Pine64\" is an honest characterization of my article. I just said they did \"honest work\". If that's praise, our standards are very low indeed...
+"""]]

approve comment
diff --git a/blog/2020-07-13-not-recommending-purism/comment_1_46595ff9be3cc390a959c5d217394f02._comment b/blog/2020-07-13-not-recommending-purism/comment_1_46595ff9be3cc390a959c5d217394f02._comment
new file mode 100644
index 00000000..e479f429
--- /dev/null
+++ b/blog/2020-07-13-not-recommending-purism/comment_1_46595ff9be3cc390a959c5d217394f02._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="90.255.34.237"
+ claimedauthor="Fazal Majid"
+ url="https://majid.info/"
+ subject="This is consistent with their former CTO"
+ date="2020-07-15T12:23:48Z"
+ content="""
+https://www.phoronix.com/scan.php?page=news_item&px=Zlatan-Todoric-Interview
+"""]]
diff --git a/blog/2020-07-13-not-recommending-purism/comment_1_c3736d7c60e0275528cab2dbb3ffef14._comment b/blog/2020-07-13-not-recommending-purism/comment_1_c3736d7c60e0275528cab2dbb3ffef14._comment
new file mode 100644
index 00000000..cf46ec80
--- /dev/null
+++ b/blog/2020-07-13-not-recommending-purism/comment_1_c3736d7c60e0275528cab2dbb3ffef14._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="82.242.148.38"
+ claimedauthor="Alexandre Franke"
+ url="https://alexandrefranke.com"
+ subject="Praising Pine64"
+ date="2020-07-15T08:53:52Z"
+ content="""
+I don’t see how Pine64 deserves your praises when they fail to hire software developers to work on things that Purism actually pays people for. Your criticism of Purism may be well founded, but you can’t then claim that Pine64 is doing better. How much of the PinePhone is working thanks to the work of Purism? How much did Pine64 contribute to the software stack? If Pine64 was actually a bit more Purism-like, they would both be in better shape (and the community would also benefit).
+"""]]

another task
diff --git a/services/analytics.mdwn b/services/analytics.mdwn
index adaff1d1..042902d9 100644
--- a/services/analytics.mdwn
+++ b/services/analytics.mdwn
@@ -55,3 +55,5 @@ remaining issues:
  * move docker to compose or podman
  * this is all super janky and should be put in CM somehow
  * remove self-referer
+ * remove "anarc.at" test site (the site is the analytics site, not
+   the tracked site)

notes on the new analytics service
diff --git a/services/analytics.mdwn b/services/analytics.mdwn
new file mode 100644
index 00000000..adaff1d1
--- /dev/null
+++ b/services/analytics.mdwn
@@ -0,0 +1,57 @@
+goatcounter docker image:
+
+https://github.com/anarcat/goatcounter
+
+build:
+
+    docker build -t zgoat/goatcounter .
+
+create volume for db:
+
+    docker volume create goatcounter
+
+startup:
+
+    exec docker run --restart=unless-stopped --volume="goatcounter:/home/user/db/" --publish 127.0.0.1:8081:8080 --detach zgoat/goatcounter serve -listen :8080 -port 8080 -tls none
+
+need to be committed...
+
+apache:
+
+    <VirtualHost *:80>
+            ServerName analytics.anarc.at
+            Redirect / https://analytics.anarc.at/
+            DocumentRoot /var/www/html/
+    </VirtualHost>
+
+    <VirtualHost *:443>
+            ServerName analytics.anarc.at
+            Use common-letsencrypt-ssl analytics.anarc.at
+            DocumentRoot /var/www/html/
+            ProxyPass /.well-known/ !
+            ProxyPass / http://localhost:8081/
+            ProxyPassReverse / http://localhost:8081/
+            ProxyPreserveHost on
+    </VirtualHost>
+
++ bind
+
+let's encrypt:
+
+    certbot certonly --webroot  -d analytics.anarc.at --webroot-path /var/www/html/
+
+create site:
+
+    docker run -it --rm --volume="goatcounter:/home/user/db/" zgoat/goatcounter create -domain analytics.anarc.at -email anarcat+rapports@anarc.at
+
+and add to ikiwiki template (must be committed). then:
+
+    ikiwiki --setup ikiwiki.setup --rebuild --verbose
+
+remaining issues:
+
+ * cache headers are wrong (120ms!)
+ * some redirects...
+ * move docker to compose or podman
+ * this is all super janky and should be put in CM somehow
+ * remove self-referer

found two more damn monitors!
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index 5661c87a..49cb7e22 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -52,10 +52,12 @@ what works and doesn't, in descending order of (totally subjective)
    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
- 
-It seems all monitors actually work, although some of those have such
-a poor resolution (long time since I saw 1024x768!) that they are not
-much use...
+ * [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
+
+Those monitors do not power up at all:
+
+ * Philips 170B
 
 Possible monitors
 =================

add links
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index ae483d68..5661c87a 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -42,15 +42,15 @@ 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 TV 1920x1080@60Hz,  23", 70,000:1, 5ms, VGA,
-   HDMI, DVI, gigantic, top burnt off
- * LG Flatron Wide L204WTX-SF 1680x1050@60Hz, 20", 2000:1, 5ms, VGA,
-   DVI, looks great
- * Acer X193w 1440x900@75Hz, 2000:1, 5ms VGA, DVI, clean and simple,
-   top partially melted
- * Acer P186HV 133x768@60Hz, 18.5", 5000:1, 5ms, VGA, display looks
-   dusty (physically and in the image)
- * Dell 1704FPvt 1280x1024@60Hz, 17", 1000:1, 25ms, VGA, DVI, USB
+ * [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
+ * [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
+ * [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) 133x768@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
  
 It seems all monitors actually work, although some of those have such

inventory of a pile of monitors
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index 36e8da5a..ae483d68 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -35,6 +35,28 @@ HP L2245wg
 
 [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
+------------
+
+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 TV 1920x1080@60Hz,  23", 70,000:1, 5ms, VGA,
+   HDMI, DVI, gigantic, top burnt off
+ * LG Flatron Wide L204WTX-SF 1680x1050@60Hz, 20", 2000:1, 5ms, VGA,
+   DVI, looks great
+ * Acer X193w 1440x900@75Hz, 2000:1, 5ms VGA, DVI, clean and simple,
+   top partially melted
+ * Acer P186HV 133x768@60Hz, 18.5", 5000:1, 5ms, VGA, display looks
+   dusty (physically and in the image)
+ * Dell 1704FPvt 1280x1024@60Hz, 17", 1000:1, 25ms, VGA, DVI, USB
+   4-port hub, looks square, rotating
+ 
+It seems all monitors actually work, although some of those have such
+a poor resolution (long time since I saw 1024x768!) that they are not
+much use...
+
 Possible monitors
 =================
 

the x220 has a vga port
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index 8b77c403..4d85c7a3 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -224,7 +224,7 @@ X220
  * SD card
  * 3xUSB, incl. 1 USB3 on i7
  * 720p camera
- * displayport
+ * DisplayPort and VGA port
  * combined audio jack
  * fprint reader
  * 65W AC

move junk to a more generic location
diff --git a/hardware/server/junk.mdwn b/hardware/junk.mdwn
similarity index 100%
rename from hardware/server/junk.mdwn
rename to hardware/junk.mdwn
diff --git a/hardware/server/marcos/v1.mdwn b/hardware/server/marcos/v1.mdwn
index 199f49c1..9b8fc25f 100644
--- a/hardware/server/marcos/v1.mdwn
+++ b/hardware/server/marcos/v1.mdwn
@@ -230,7 +230,7 @@ Chez newegg.ca - 1-2 jours packaging, 2-7 jours shipping, fait aujourdhui. -- Th
 
 ### Inventaire
 
-Inventory of old parts moved to [[junk]].
+Inventory of old parts moved to [[hardware/junk]].
 
 #### Other
 

link to my x220 reference
diff --git a/hardware/emma.mdwn b/hardware/emma.mdwn
index f955d845..81694a1f 100644
--- a/hardware/emma.mdwn
+++ b/hardware/emma.mdwn
@@ -14,8 +14,8 @@ Europe in the first half of the 20th century".
 >
 > -- Emma Goldman, 1910
 
-Emma is also an old battered X220 laptop running Debian I use for
-music recording.
+Emma is also an old battered [X220 laptop](/hardware/laptop/#x220) running Debian I use for
+music recording and as a spare laptop.
 
 Emma's name was also briefly attributed to [[rosa]] by mistake, before
 I remembered of its existence.

note that mumble echo cancelation is actually not that great
One of the most horrible audio conferencing experience i had was with
Mumble failing to do echo cancelation and generating nasty feedback
loops with someone using their speakers and onboard mic on a laptop.
Heck, I've even heard feedback from my *own* mic bleed through someone
else's channel even if I was using a headset. Weird stuff.
diff --git a/blog/2020-04-09-mumble-dreams.mdwn b/blog/2020-04-09-mumble-dreams.mdwn
index b3fb110a..6a1ce1bd 100644
--- a/blog/2020-04-09-mumble-dreams.mdwn
+++ b/blog/2020-04-09-mumble-dreams.mdwn
@@ -31,7 +31,7 @@ implementations, the official one called [Murmur](https://wiki.mumble.info/wiki/
 [umurmur](https://umurmur.net/) and [Grumble](https://github.com/mumble-voip/grumble), a Go rewrite.
 
 It has *great* quality: echo canceling, when correctly configured, is
-solid and latency is minimal. It has "overlays" so you can use it
+<del>solid</del> okay and latency is minimal. It has "overlays" so you can use it
 while gaming or demo'ing in full screen while still having an idea of
 who's talking. It also supports positional audio for gaming that
 integrates with popular games like Counterstrike or Half-Life. It even

mention that mayfirst use mumble for translation
diff --git a/blog/2020-03-15-remote-tools.mdwn b/blog/2020-03-15-remote-tools.mdwn
index 40a90f0f..938272e3 100644
--- a/blog/2020-03-15-remote-tools.mdwn
+++ b/blog/2020-03-15-remote-tools.mdwn
@@ -80,7 +80,10 @@ Teamspeak, but made with free software. It requires users to [install
 an app](https://www.mumble.info/downloads/) but there are clients for every platform out there
 ([F-Droid](https://f-droid.org/repository/browse/?fdid=com.morlunk.mumbleclient), [Google Play](https://play.google.com/store/apps/details?id=com.morlunk.mumbleclient.free), [Apple Store](https://apps.apple.com/us/app/mumble/id443472808)). Mumble is harder
 to setup, but is much more efficient in terms of bandwidth and
-latency. In other words, it will just scale and sound better.
+latency. In other words, it will just scale and sound better. It also
+has interesting moderation and room management features which allow
+creative use of the software. For example, [Mayfirst use it for
+interpretation](https://support.mayfirst.org/wiki/mumble-interpreter-setup) (AKA "simultaneous translation").
 
 Mumble ships with a list of known servers, but you can also connect to
 those trusted ones:
diff --git a/blog/2020-04-09-mumble-dreams.mdwn b/blog/2020-04-09-mumble-dreams.mdwn
index a5f1ee58..b3fb110a 100644
--- a/blog/2020-04-09-mumble-dreams.mdwn
+++ b/blog/2020-04-09-mumble-dreams.mdwn
@@ -34,7 +34,10 @@ It has *great* quality: echo canceling, when correctly configured, is
 solid and latency is minimal. It has "overlays" so you can use it
 while gaming or demo'ing in full screen while still having an idea of
 who's talking. It also supports positional audio for gaming that
-integrates with popular games like Counterstrike or Half-Life.
+integrates with popular games like Counterstrike or Half-Life. It even
+has support for cross-linking different "rooms" which allow all sorts
+of features. For example, [Mayfirst use it for interpretation](https://support.mayfirst.org/wiki/mumble-interpreter-setup) (AKA
+"simultaneous translation").
 
 It's moderately secure: it doesn't support end-to-end encryption, but
 client/server communication is [encrypted and authenticated](https://wiki.mumble.info/wiki/FAQ#Is_Mumble_encrypted.3F) with

update: MB dead, insert articles in timeline
diff --git a/hardware/laptop/purism-librem13v4.mdwn b/hardware/laptop/purism-librem13v4.mdwn
index fbf5a7d4..68439f49 100644
--- a/hardware/laptop/purism-librem13v4.mdwn
+++ b/hardware/laptop/purism-librem13v4.mdwn
@@ -501,9 +501,15 @@ The timeline of that laptop's hardware problems looks like this:
  * 2019-05-09: first laptop received, DOA, TMA issued
  * 2019-05-13: shipping label issued, first laptop returned, second
    laptop shipped
+ * 2019-05-13: [article about Purism and free speech published](/blog/2019-05-13-free-speech)
  * 2019-05-15: first laptop received by Purism
  * 2019-05-17: second laptop received, working, extra 190$ Fedex fee
- * somewhere in April 2020: right-side USB-A port breaks
+ * 2019-05-29: this review published and updated for a few days
+ * (11 months pass): laptop in semi-regular use: travel to two
+   conferences, some holidays, some work from home, but not heavy use
+   until the pandemic hits early march 2020, when it gets used more
+   daily
+ * (somewhere in April 2020): right-side USB-A port breaks
  * 2020-04-27: hardware bug reported to Purism, response from Purism:
    "check dmesg", which I had reported in the bug report as empty,
    replied that
@@ -523,3 +529,5 @@ The timeline of that laptop's hardware problems looks like this:
  * 2020-07-03: Purism confirms reception, announces the hardware issue
    needs to be "diagnosed" which will "take a few days"
  * 2020-07-13: ping sent to Purism
+ * 2020-07-13: [update to this review published](/blog/2020-07-13-not-recommending-purism)
+ * 2020-07-14: response: motherboard confirmed dead

add details of mumble encryption mechanisms
diff --git a/blog/2020-04-09-mumble-dreams.mdwn b/blog/2020-04-09-mumble-dreams.mdwn
index b31f97f7..a5f1ee58 100644
--- a/blog/2020-04-09-mumble-dreams.mdwn
+++ b/blog/2020-04-09-mumble-dreams.mdwn
@@ -37,8 +37,9 @@ who's talking. It also supports positional audio for gaming that
 integrates with popular games like Counterstrike or Half-Life.
 
 It's moderately secure: it doesn't support end-to-end encryption, but
-client/server communication is encrypted with TLS. It supports a
-server password and some moderation mechanisms.
+client/server communication is [encrypted and authenticated](https://wiki.mumble.info/wiki/FAQ#Is_Mumble_encrypted.3F) with
+(mutual) TLS (for the control channel) and OCB-AES-128 over UDP (for
+media). It supports a server password and some moderation mechanisms.
 
 UI improvements
 ===============

spell-check purism docs
Thanks to ukleinek for the heads up.
diff --git a/hardware/laptop/purism-librem13v4.mdwn b/hardware/laptop/purism-librem13v4.mdwn
index cf40e629..fbf5a7d4 100644
--- a/hardware/laptop/purism-librem13v4.mdwn
+++ b/hardware/laptop/purism-librem13v4.mdwn
@@ -46,7 +46,7 @@ Semi-standard power connector
 The power connector is [somewhat standard](https://learn.sparkfun.com/tutorials/connector-basics/power-connectors): 19V DC on a 5.5mm
 sleeve with 2.5 positive pin, with a [C5/C6 cable](https://en.wikipedia.org/wiki/IEC_60320#C5/C6_coupler) for the AC side
 (as opposed to the more standard C13/C14 coupler, mind you). I was
-able to find a "universal 19V adpater" for ~60$ at a local store that
+able to find a "universal 19V adapter" for ~60$ at a local store that
 also supported other barrel connectors.
 
 It would be better if the laptop would charge through USB-C,
@@ -204,7 +204,7 @@ paid it now.
 Bright LEDs, not accessible when lid closed
 -------------------------------------------
 
-There are three leds on the top right of the keyboad: one for wifi,
+There are three leds on the top right of the keyboard: one for wifi,
 battery and power. They are very bright and even though they can
 technically be dimmed, the firmware is not open so there's [no way to
 dim the LEDs](https://forums.puri.sm/t/is-there-a-way-to-dim-the-leds-on-the-13-v2/1172). 
@@ -227,7 +227,7 @@ be questionable. While, yes, they try to provide a [liberated boot](#liberated-b
 and coreboot-based BIOS, that BIOS is not free software. At best they
 "neuter" the Intel Management Engine, but you still require non-free
 firmware to operate a Librem Computer, from the CPU down to the
-Bluetooth and Wifi hardwre. Even if that is a very common pattern on
+Bluetooth and Wifi hardware. Even if that is a very common pattern on
 laptops and phone, it is a huge disconnect with the "purity" and
 "freedom" narrative on their website.
 
@@ -269,7 +269,7 @@ Bullshit anti-interdiction
 --------------------------
 
 This is part of a larger pattern of "bullshit", if you'll pardon my
-french. The market the new Librem 14 as being shippable with
+french. The market the new Librem 14 as being shipped with
 [Anti-interdiction services](https://puri.sm/posts/anti-interdiction-services/) which supposedly consist of:
 
  1. Customized tamper-evident tape on the sealed plastic bag
@@ -330,11 +330,11 @@ that involves know what I mean) and I am deeply aware of how difficult
 OpenPGP and online security can be.
 
 I have actually *asked* Purism to get anti-interdiction services
-before I got the laptop. I knew about their suposed care for those
+before I got the laptop. I knew about their supposed care for those
 services and wanted to have the laptop hand-delivered, say at a
 conference we would commonly attend in the near future: I can wait!
 and I can pay for the extra trouble too. But that fairly
-straightforwared security measure was not possible. And none of the
+straightforward security measure was not possible. And none of the
 above measures seemed to apply to my order.
 
 So I call bullshit on that. 
@@ -400,7 +400,7 @@ enthusiasts in general". Yet in the developer updates, we learn that
 the [latest Dogwood update](https://puri.sm/posts/librem-5-dogwood-update-3/) now features *amazing* new features
 like "multiple hours" battery, "more reliable charging", and "app
 thumbnails". The previous batch, [chestnut](https://puri.sm/posts/librem-5-chestnut-hardware-changes/) had *exciting* stuff
-like a charging LED, a writable microSD card, and working phone
+like a charging LED, a writable MicroSD card, and working phone
 calls...
 
 So I call bullshit on that too: the Librem 5 is not a phone. It's a
@@ -501,8 +501,8 @@ The timeline of that laptop's hardware problems looks like this:
  * 2019-05-09: first laptop received, DOA, TMA issued
  * 2019-05-13: shipping label issued, first laptop returned, second
    laptop shipped
- * 2019-05-15: first laptoped received by Purism
- * 2019-05-17: second laptop received, working, exta 190$ Fedex fee
+ * 2019-05-15: first laptop received by Purism
+ * 2019-05-17: second laptop received, working, extra 190$ Fedex fee
  * somewhere in April 2020: right-side USB-A port breaks
  * 2020-04-27: hardware bug reported to Purism, response from Purism:
    "check dmesg", which I had reported in the bug report as empty,

clarify that coreboot itself might be free software...
... but not the product shipped by purism
diff --git a/hardware/laptop/purism-librem13v4.mdwn b/hardware/laptop/purism-librem13v4.mdwn
index 79fdf5ba..cf40e629 100644
--- a/hardware/laptop/purism-librem13v4.mdwn
+++ b/hardware/laptop/purism-librem13v4.mdwn
@@ -240,11 +240,11 @@ claims to be:
 > line-by-line, to respect your rights to privacy, security, and
 > freedom.
 
-Yet it still ships with Intel processors, known for a large variety
-of fundamental security issues that are part of the hardware design,
+Yet it still ships with Intel processors, known for a large variety of
+fundamental security issues that are part of the hardware design,
 which Intel refuses to fix. That it ships [coreboot](https://puri.sm/coreboot/) on top of that
-is besides the point: coreboot is not free software, and definitely
-ships proprietary blobs.
+is besides the point: coreboot, as shipped by Purism, is not open
+source, or at least ships proprietary blobs.
 
 Compare this with the work System76 has been doing in recent
 times. While they brand themselves as just a company shipping Linux

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

announce the hardware review changes and rant
diff --git a/blog/2020-07-13-not-recommending-purism.mdwn b/blog/2020-07-13-not-recommending-purism.mdwn
new file mode 100644
index 00000000..6c1b6d31
--- /dev/null
+++ b/blog/2020-07-13-not-recommending-purism.mdwn
@@ -0,0 +1,47 @@
+[[!meta title="Not recommending Purism"]]
+
+This is just a quick note to mention that I have updated my [hardware
+documentation on the Librem 13v4 laptop](/hardware/laptop/purism-librem13v4). It has unfortunately
+turned into a rather lengthy (and ranty) piece about Purism. Let's
+just say that waiting weeks for your replacement laptop (yes, it died
+again) does wonders for creativity. To quote the full review:
+
+> TL;DR: I recommend people avoid the Purism brand and products. I
+> find they have questionable politics, operate in a "libre-washing"
+> fashion, and produce unreliable hardware. Will not buy again.
+
+People who have read the article might want to jump directly to the
+new sections:
+
+ * [Libre washing](/hardware/laptop/purism-librem13v4/#libre-washing)
+ * [Bullshit anti-interdiction](/hardware/laptop/purism-librem13v4/#bullshit-anti-interdiction)
+ * [Bullshit crowdfunding](/hardware/laptop/purism-librem13v4/#bullshit-crowdfunding)
+ * [Hardware reliability](/hardware/laptop/purism-librem13v4/#hardware-reliability) (or lack thereof)
+
+I have also added the minor section of the [missing mic jack](/hardware/laptop/purism-librem13v4/#no-mic-jack).
+
+I realize that some folks (particularly at Debian) might still work at
+Purism, and that this article might be demoralizing for their work. If
+that is the case, I am sorry this article triggered you in any way and
+I hope this can act as a disclaimer. But I feel it is my duty to
+document the issues I am going through, as a user, and to call
+bullshit when I see it (let's face it, the anti-interdiction stuff and
+the Purism 5 crowd-funding campaign were total bullshit).
+
+I also understand that the pandemic makes life hard for everyone, and
+probably makes a bad situation at Purism worse. But those problems
+existed before the pandemic happened. They were issues I had
+identified in 2019 and that I simply never got around to document.
+
+I wish that people wishing to support the free software movement would
+spend their energy towards organisations that actually do honest work
+in that direction, like [System76](https://system76.com/) and [Pine64](https://www.pine64.org/). And if you're
+going to go crazy with an experimental free hardware design, why not
+go retro with the [MNT Reform](https://www.crowdsupply.com/mnt/reform).
+
+In the meantime, if you're looking for a phone, I recommend you give
+the [Fairphone](https://www.fairphone.com/) a fair chance. It really is a "fair" (as in, not
+the best, but okay) phone that you can moderately liberate, and it
+actually frigging works. See also my [hardware review of the FP2](/hardware/phone/fairphone2).
+
+[[!tag debian-planet python-planet hardware review phone laptop]]

more purism bullshit
diff --git a/hardware/laptop/purism-librem13v4.mdwn b/hardware/laptop/purism-librem13v4.mdwn
index 3206b8a3..79fdf5ba 100644
--- a/hardware/laptop/purism-librem13v4.mdwn
+++ b/hardware/laptop/purism-librem13v4.mdwn
@@ -4,6 +4,10 @@ understand. I have the `v4` means it's the fourth hardware version of
 the device. This is the latest incarnation of the [[hardware/angela]]
 node.
 
+TL;DR: I recommend people avoid the Purism brand and products. I find
+they have questionable politics, operate in a "libre-washing" fashion,
+and produce unreliable hardware. Will not buy again.
+
 [[!toc levels=3]]
 
 Specifications
@@ -215,6 +219,196 @@ useful. Plus, I can afford to have a USB dongle there with a gigabit
 ethernet port, indeed, I already have one of those USB hubs. So not
 that big of a deal.
 
+Libre-washing
+-------------
+
+I have found Purism's commitment to free hardware and free software to
+be questionable. While, yes, they try to provide a [liberated boot](#liberated-boot)
+and coreboot-based BIOS, that BIOS is not free software. At best they
+"neuter" the Intel Management Engine, but you still require non-free
+firmware to operate a Librem Computer, from the CPU down to the
+Bluetooth and Wifi hardwre. Even if that is a very common pattern on
+laptops and phone, it is a huge disconnect with the "purity" and
+"freedom" narrative on their website.
+
+For example, the replacement for the Librem 13, called Librem 14,
+claims to be:
+
+> **The first 14″ laptop designed to protect your digital life**
+>
+> Ultra-portable workstation laptop that was designed chip-by-chip,
+> line-by-line, to respect your rights to privacy, security, and
+> freedom.
+
+Yet it still ships with Intel processors, known for a large variety
+of fundamental security issues that are part of the hardware design,
+which Intel refuses to fix. That it ships [coreboot](https://puri.sm/coreboot/) on top of that
+is besides the point: coreboot is not free software, and definitely
+ships proprietary blobs.
+
+Compare this with the work System76 has been doing in recent
+times. While they brand themselves as just a company shipping Linux
+laptops, they [work with the de-facto standard LVFS](https://blog.system76.com/post/187072707563/the-new-firmware-manager-updating-firmware-across) (even though
+that is a [bumpy ride](https://blog.system76.com/post/173801677358/system76-and-lvfs-what-really-happened)), actually [design and prototype their own
+hardware](https://blog.system76.com/post/612315972866637824/a-look-back-at-manufacturing), and [liberated their keyboard microcontroller](https://opensource.com/article/20/1/system76-open-source-firmware). They
+have even started [working on an open Thunderbolt
+microcontroller](https://blog.system76.com/post/186655523269/open-firmware-and-more-news-from-july). And while those might sound like small things
+compared to liberating the CPU firmware, I will point out that they
+actually *succeed* in completely liberating those components, while
+Purism, in the *years* they have supposedly been working on those
+projects, have only managed to reuse (and, to be fair, improve on) the
+work *others* have done to neutralize the IME.
+
+What has Purism done, in the meantime? Neutralized IME. That's
+it. They have not published *anything* on LVFS. Even closed-source
+companies like [Logitech](https://fwupd.org/lvfs/vendors/#logitech), [Synaptics](https://fwupd.org/lvfs/vendors/#synaptics), [HP](https://fwupd.org/lvfs/vendors/#hp-ws) and [Dell](https://fwupd.org/lvfs/vendors/#dell)
+ship their updates on LVFS. Purism [has a test account](https://fwupd.org/lvfs/vendors/#purism) and work
+has been [stalled for years now](https://forums.puri.sm/t/submit-firmware-to-linux-vendor-firmware-service-lvfs-for-easy-updating/4731).
+
+Bullshit anti-interdiction
+--------------------------
+
+This is part of a larger pattern of "bullshit", if you'll pardon my
+french. The market the new Librem 14 as being shippable with
+[Anti-interdiction services](https://puri.sm/posts/anti-interdiction-services/) which supposedly consist of:
+
+ 1. Customized tamper-evident tape on the sealed plastic bag
+    surrounding the laptop itself
+
+ 2. Customized tamper-evident tape on the internal, branded box
+
+ 3. Glitter nail polish covering the center (or all) screws on the
+    bottom of the laptop
+
+ 4. Pictures of all of the above plus pictures of the inside of the
+    laptop before sealing the bottom case
+
+ 5. All pictures sent to the customer out-of-band, signed by Purism
+    and encrypted against the customer’s GPG key
+
+ 6. All coordination occurring over GPG-protected email
+
+Now, that post is from October 2019, so maybe things changed after I
+ordered my laptop. But my experience was very different:
+
+ 1. yes, there was a "tamper-evident" bag "sealing" the laptop, but
+    seriously, I don't buy that. the CIA has been learning how to
+    reseal packages for a long time now and if your adversary is
+    serious at all, you would *never* notice the difference between a
+    CIA- and a Purism-sealed bag.
+
+ 2. same comment
+
+ 3. considering that the screws just fall off the Librem 13 on their
+    own, I doubt such a measure helps in any way. the CIA knows about
+    nail polish as well right?
+
+ 4. I never got such a picture. I am curious to see if I get one on
+    this round of RMA. I strongly doubt so.
+
+ 5. Again, no such picture. I'm curious to hear how I am supposed to
+    verify Purism's OpenPGP keys, that said, or how they would verify
+    mine.
+
+ 6. While some emails with Purism support were signed by their
+    individual's OpenPGP keys, they have never encrypted emails sent
+    to me, nor have they requested my OpenPGP key. I was not aware
+    there was a way to provide one. There is no way to provide such a
+    certificate in [my account](https://shop.puri.sm/my-account/edit-address/) on their website.
+
+(Note that glittery nail polish might sound silly, but it's actually a
+fairly good security measure, *provided you have a way to send a
+trusted image of the pattern out of band*. I would also assume the CIA
+has workarounds for those. I can imagine, for example, a magnetic
+"screwdriver" that can remove screws without contact...)
+
+I don't take those claims of OpenPGP operations lightly. I have worked
+for years with the Debian LTS security team. I'm a Debian developer
+and Tor sysadmin, where we use OpenPGP extensively. I have written at
+least one major program interoperating with GnuPG (those who know what
+that involves know what I mean) and I am deeply aware of how difficult
+OpenPGP and online security can be.
+
+I have actually *asked* Purism to get anti-interdiction services
+before I got the laptop. I knew about their suposed care for those
+services and wanted to have the laptop hand-delivered, say at a
+conference we would commonly attend in the near future: I can wait!
+and I can pay for the extra trouble too. But that fairly
+straightforwared security measure was not possible. And none of the
+above measures seemed to apply to my order.
+
+So I call bullshit on that. 
+
+(And that's without getting into upstream supply chain issues: it
+seems that Purism [don't have direct contact with their
+manufacturers](https://www.phoronix.com/scan.php?page=news_item&px=Zlatan-Todoric-Interview) and instead deal with a "man in the middle for
+China", "Todd's partner in San Francisco" to get their stuff
+manufactured. If I were to interdict something in the Purism supply
+chain, I would certainly know where to apply the pressure...)
+
+Bullshit crowdfunding
+---------------------
+
+A similar amount of what I can now only describe as lies has spun out
+of the Librem 5 crowdfunding campaign. I am too tired to go into the
+details of this, but let's just say that the promises of the Purism
+venture into the phone market were wildly overstated. There were [huge
+delays in shipping](https://jaylittle.com/post/view/2019/10/the-sad-saga-of-purism-and-the-librem-5-part-2https://arstechnica.com/gadgets/2019/11/the-librem-5-has-been-shipping-for-a-month-but-not-to-backers/) after the crowdfunding. Some people even
+[doubted there was a working phone at all](https://jaylittle.com/post/view/2019/10/the-sad-saga-of-purism-and-the-librem-5-part-3) which ended up being not
+too far off the mark, with the first models [not able to even make a
+phone call](https://arstechnica.com/gadgets/2019/12/librem-5-backers-receiving-their-linux-phones/). 
+
+In an [interview with a former employee](https://www.phoronix.com/scan.php?page=news_item&px=Zlatan-Todoric-Interview), it became clear that
+Purism, as a company, doesn't really have any direct contact with
+actual hardware manufacturers, let alone manufacture its own
+hardware. To quote the interview:
+
+> We worked day and night but Todd's partner (the company in South San
+> Francisco that assembles Librems and also is man in the middle for
+> China were all parts get produced and then shipped to California)
+> were being mostly silent to us.
+>
+> [...]
+>
+> The Librems are heavily overpriced but that is because Purism
+> seemingly never tried to get better deal and the South San Francisco
+> partner abused this so that is why Purism Librems are double the
+> price they should be.
+
+The interview is worth reading in full. It makes Purism sound like a
+con artist's success more than an honest failure at producing good
+open hardware.
+
+Even if assuming good faith, I think Purism made a critical mistake
+when moving to mobile: they assumed they could both build a phone's
+hardware and software at once. There is a reason why Android was so
+successful: building a mobile OS is fundamentally, radically different
+than building a desktop OS. You can't both do that and build a new
+hardware platform with a tiny 1M$ crowdfunding. It just doesn't work
+like that. Canonical at least had the honesty to [set the bar at at
+32M$ and fail](https://en.wikipedia.org/wiki/Ubuntu_Edge). Or take Pine64: they built the [Pinephone](https://en.wikipedia.org/wiki/PinePhone)
+without any promises. It is explicitly and deliberately a hacker
+phone, and people are happy to "boot linux" on it. They don't really
+expect anything else. Maybe make phone calls. Maybe run apps, but it's
+a toy platform, and people know it.
+
+The Librem 5 is being [marketed](https://puri.sm/products/librem-5/) as a real thing, a "Security and
+Privacy Focused Phone", "made for you in mind", where "you" is
+basically everyone: "parents", "developers", "enterprises, businesses
+and organizations of all sizes", "CTOs/CIOs/IT and technology
+enthusiasts in general". Yet in the developer updates, we learn that
+the [latest Dogwood update](https://puri.sm/posts/librem-5-dogwood-update-3/) now features *amazing* new features
+like "multiple hours" battery, "more reliable charging", and "app
+thumbnails". The previous batch, [chestnut](https://puri.sm/posts/librem-5-chestnut-hardware-changes/) had *exciting* stuff

(fichier de différences tronqué)
document alternative power supply
diff --git a/hardware/laptop/purism-librem13v4.mdwn b/hardware/laptop/purism-librem13v4.mdwn
index 0febb92b..3206b8a3 100644
--- a/hardware/laptop/purism-librem13v4.mdwn
+++ b/hardware/laptop/purism-librem13v4.mdwn
@@ -276,8 +276,8 @@ normally, but had to carry the laptop downstairs to do disk changes on
 a server. So I piled two HDDs and a SSD on the laptop and merrily
 walked downstairs. When I opened the lid again, display was blank, and
 no led would turn on. The LEDs wouldn't turn on even when the power
-was plugged in. When an alternative power supply was plugged in, it
-blinked on and off instead of giving a steady blue light, which was
+was plugged in. When an [alternative power supply](https://forums.puri.sm/t/spare-power-supply-for-librem-13/597/4) was plugged in,
+it blinked on and off instead of giving a steady blue light, which was
 also unusual.
 
 So the laptop is dead, and I've now been waiting almost a month for a

purism: more hardware problems
diff --git a/hardware/laptop/purism-librem13v4.mdwn b/hardware/laptop/purism-librem13v4.mdwn
index 44025098..0febb92b 100644
--- a/hardware/laptop/purism-librem13v4.mdwn
+++ b/hardware/laptop/purism-librem13v4.mdwn
@@ -181,11 +181,13 @@ Shipping delays, DOA
 I waited almost four weeks to have my laptop delivered. Presumably
 this was due to a [warehouse move](https://forums.puri.sm/t/where-was-purism-moving/5799/) but I found that communication
 about the issue could have been better. Worse: the laptop was [dead on
-arrival](https://forums.puri.sm/t/librem-13v3-bricked/5714/19?u=anarcat) (DOA) so I had to return it, adding another week delay for
+arrival][] (DOA) so I had to return it, adding another week delay for
 getting an actual working laptop. FedEx even charged me for the return
 even though Purism actually issued a shipping label, something I still
 haven't quite resolved.
 
+[dead on arrival]: https://forums.puri.sm/t/librem-13v3-bricked/5714/19?u=anarcat
+
 Update: I ended up paying over 260$ in shipping fees to Fedex, in the
 end. I first paid around 70$ for the first laptop sent, then Fedex
 sent me *another* 200$ bill for the *second* laptop. Purism were
@@ -232,3 +234,83 @@ got into the business of hosting social networks, emails and so on, so
 this is a big problem. I have written about the rationale in details
 in [[blog/2019-05-13-free-speech]], but I cannot in good faith
 recommend doing business with Purism anymore, unfortunately.
+
+No mic jack
+-----------
+
+The "headphones" jack is not [TRRS][]: it doesn't have a "mic"
+wire. So you can't plug in a headset with a mic. You need to use the
+onboard mic which pics up a lot of noise from the computer (e.g. the
+fan, see below) or use an external USB mic bundle.
+
+[TRRS]: https://en.wikipedia.org/wiki/Phone_connector_(audio)#TRRS_standards
+
+Hardware reliability
+--------------------
+
+As I mentioned above, the first Librem 13 I ordered was [DOA][dead on arrival] and
+incurred significant extra costs and delays in getting the machine up
+to speed.
+
+But it seems the platform has some fundamental hardware reliability
+issues. Case screws would [fall off](https://forums.puri.sm/t/where-can-i-get-screws-for-the-librem-13v4/7044). A USB port broke. The CPU fan
+goes crazy. And now, after a year, the laptop just completely
+died. Below are the details...
+
+I have found that any significant hardware processing would quickly
+throttle the CPU because it would overheat. Any videoconferencing work
+(Jitsi, Zoom, whatever) would quickly kick the fan in high speed, hard
+enough that it would be audible the voice-activation software and
+therefore by participants of the conference. Because there is no mic
+jack (above), workaround that problem requires yet another USB dongle.
+
+After a little less than a year, one of the USB-A connectors
+failed. It would deliver power, but had no actual data signal: it
+wouldn't get detected in `dmesg` or listed in `lsusb`. I got *another*
+RMA issued for this, but procrastinated on shipping the device back
+for about a month because, seriously, I didn't want to see how long
+the RMA cycle would take this time around, *again*.
+
+But the machine eventually completely died. I was working at home
+normally, but had to carry the laptop downstairs to do disk changes on
+a server. So I piled two HDDs and a SSD on the laptop and merrily
+walked downstairs. When I opened the lid again, display was blank, and
+no led would turn on. The LEDs wouldn't turn on even when the power
+was plugged in. When an alternative power supply was plugged in, it
+blinked on and off instead of giving a steady blue light, which was
+also unusual.
+
+So the laptop is dead, and I've now been waiting almost a month for a
+replacement. All in all, in the 15 months since I've been, in theory,
+the owner of a Purism device, I have spent 2 of those months waiting
+for shipping or a replacement device...
+
+The timeline of that laptop's hardware problems looks like this:
+
+ * 2019-04-16: first laptop ordered
+ * 2019-05-01: first laptop shipped
+ * 2019-05-09: first laptop received, DOA, TMA issued
+ * 2019-05-13: shipping label issued, first laptop returned, second
+   laptop shipped
+ * 2019-05-15: first laptoped received by Purism
+ * 2019-05-17: second laptop received, working, exta 190$ Fedex fee
+ * somewhere in April 2020: right-side USB-A port breaks
+ * 2020-04-27: hardware bug reported to Purism, response from Purism:
+   "check dmesg", which I had reported in the bug report as empty,
+   replied that
+ * 2020-05-14: pinged Purism
+ * 2020-05-15: asked by Purism to run `lsusb`
+ * 2020-05-16: confirmed that `lsusb` does not mention connected
+   devices
+ * 2020-05-18: RMA issued for second laptop, plan is to replace the
+   motherboard
+ * 2020-05-19: asking for a shipping label and cross-shipping,
+   followed by a lengthy back and forth and numerous pings
+ * 2020-06-07: Purism confirms they will not provide a shipping label
+   or cross-shipping anymore
+ * 2020-06-21: second laptop short-circuits and completely dies
+ * 2020-06-23: second laptop shipped back to Purism
+ * 2020-06-29: second laptop delivered to Purism
+ * 2020-07-03: Purism confirms reception, announces the hardware issue
+   needs to be "diagnosed" which will "take a few days"
+ * 2020-07-13: ping sent to Purism

FP3: update /e/ ships phones, clove not B/O, update prices
diff --git a/hardware/phone.mdwn b/hardware/phone.mdwn
index 7326c167..090745bc 100644
--- a/hardware/phone.mdwn
+++ b/hardware/phone.mdwn
@@ -219,6 +219,8 @@ There are some problems, however, that I have found with the specs:
    (missing LTE, GPS, Updater and selinux) or [/e/](https://forum.fairphone.com/t/e-for-fp3-google-free-os/59328) ([missing
    sensors, camera, gps and fingerprint sensor](https://community.e.foundation/t/fairphone-3-fp3-support-on-e/6438/111)), TWRP has been
    [ported](https://forum.fairphone.com/t/twrp-for-fairphone-3/56995/26) but the port is [still unofficial](https://twrp.me/Devices/Fairphone/)
+   Update: [LineageOS also has an unofficial port](https://forum.fairphone.com/t/rom-unofficial-lineageos-16-0-for-fp3/59849) and [/e/ even
+   *sells* FP3 phones now](https://esolutions.shop/shop/e-os-fairphone-3/)
  * the phone is 10% larger than the FP2 (FP3: 158 x 71.8 x 9.89 mm,
    FP2: 143 x 73 x 11 mm) but 2mm thinner and 1mm narrower
 
@@ -256,8 +258,11 @@ On the upside:
 
 Places that might ship in Canada:
 
- * [Clove](https://www.clove.co.uk/collections/smartphones-fairphone) - backorder
- * [Vireo](https://www.vireo.de/fairphone/fairphone/8725/fairphone-3) - ships to Kanada (note the K instead of C!)
+ * [Clove](https://www.clove.co.uk/collections/smartphones-fairphone) - 350GBP (~600CAD) + ~34CAD shipping + customs
+ * [Vireo](https://www.vireo.de/fairphone/fairphone/8725/fairphone-3) - 450EUR (690CAD) + shipping + customs, ships to Kanada (note the
+   K instead of C!)
+ * [/e/](https://esolutions.shop/shop/e-os-fairphone-3/) - 480EUR (740CAD) + ship + customs, more expensive, but
+   preinstalled with a liberated android! (backorder)
 
 [Ecosto](https://www.ecosto.net/en/search/?q=fairphone+3), where I bought the [[fairphone2]], do not <del>yet</del> ship the
 Fairphone 3 -- and has stopped shopping the FP2 as well, so they're

Added a comment: Re: no benefit to public health?
diff --git a/blog/2020-07-12-contact-tracing/comment_2_5ee46bf7cbe575c20a11f0db72ba6a9b._comment b/blog/2020-07-12-contact-tracing/comment_2_5ee46bf7cbe575c20a11f0db72ba6a9b._comment
new file mode 100644
index 00000000..9fdee61a
--- /dev/null
+++ b/blog/2020-07-12-contact-tracing/comment_2_5ee46bf7cbe575c20a11f0db72ba6a9b._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="https://seccdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="Re: no benefit to public health?"
+ date="2020-07-13T19:26:45Z"
+ content="""
+> I doubt the \"no benefit to public health\" part. A contact tracing app speeds up contact tracing at least in some cases and so has some benefit.
+
+I didn't make that up. I based that comment on [this article from the MIT Technology Preview](https://www.technologyreview.com/2020/05/11/1001541/iceland-rakning-c19-covid-contact-tracing/) which is titled: **Nearly 40% of Icelanders are using a covid app—and it hasn’t helped much**. That 40% was, at the time of writing, \"the largest penetration rate of all contact trackers in the world\".
+
+I feel those comments are particularly alarming:
+
+> one senior figure in the country’s covid-19 response says the real impact of Rakning C-19 has been small, compared with manual tracing techniques like phone calls
+
+and:
+
+> “The technology is more or less … I wouldn’t say useless,” says Gestur Pálmason, a detective inspector with the Icelandic Police Service who is overseeing contact tracing efforts. “But it’s the integration of the two that gives you results. I would say it [Rakning] has proven useful in a few cases, but it wasn’t a game changer for us.”
+
+My fundamental concern with contact tracing app is that they try to solve a social problem (namely: reverse engineering human contacts, a fundamentally social activity) through technology (namely: by using radio transmissions as a trace of said contacts). This is bound to fail in all sorts of mysterious ways and triggers the very real risk of *replacing* proper contact tracing with a cheaper technological solution.
+
+In other words, if we cheapen our contact tracing mechanisms by relying on technology too much, we can create a false sense of security and trigger new outbreaks, which will lead to more deaths.
+
+And even if I was wrong and that you could make a contact tracing app that would be more useful than manual tracing techniques, I still doubt the privacy tradeoffs would be worth it. *Maybe* with a technique like the one proposed by bunnie. Maybe. But that is not what the government is proposing, in Québec, and that is that blind, I would even say ignorant, posturing that I object to.
+
+TL:DR; maybe they are benefits to public health in contact tracing apps. I argue they are marginal enough to be non-existent, and definitely not worth the privacy trade-offs.
+"""]]

approve comment
diff --git a/blog/2020-07-12-contact-tracing/comment_1_187d3c43f8765c7aa53f0221b8209e8d._comment b/blog/2020-07-12-contact-tracing/comment_1_187d3c43f8765c7aa53f0221b8209e8d._comment
new file mode 100644
index 00000000..be8bcf57
--- /dev/null
+++ b/blog/2020-07-12-contact-tracing/comment_1_187d3c43f8765c7aa53f0221b8209e8d._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ ip="37.49.27.20"
+ claimedauthor="Uwe Kleine-König"
+ subject="no benefit to public health?"
+ date="2020-07-13T18:49:58Z"
+ content="""
+I doubt the \"no benefit to public health\" part. A contact tracing app speeds up contact tracing at least in some cases and so has some benefit.
+
+It doesn't make the number of new infections go down to zero, I also agree every implementation is imperfect and so probably generates both false positives and false negatives which quite reduces the value of such an app for an individual. Also you're fee to judge the downsides prevail. But claiming there was no benefit seems unfair to me.
+
+Best regards
+"""]]

clarify that i do not object to contact tracing itself
diff --git a/blog/2020-07-12-contact-tracing.mdwn b/blog/2020-07-12-contact-tracing.mdwn
index c4385a16..a957f39d 100644
--- a/blog/2020-07-12-contact-tracing.mdwn
+++ b/blog/2020-07-12-contact-tracing.mdwn
@@ -1,4 +1,4 @@
-[[!meta title="On contact tracing"]]
+[[!meta title="On contact tracing apps"]]
 
 I have strong doubts about the efficiency of any tracing app of the
 sort, and even less in the context where it is [unlikely that a
@@ -22,6 +22,14 @@ Please don't do this.
 > I wrote the above in a response to the Québec government's [survey
 > about a possible tracing app](https://consultation.quebec.ca/processes/covidapp/).
 
+> Update: a previous version of this article was titled plainly "on
+> contact tracing". In case that was not obvious, I definitely do not
+> object to contact tracing per se. I believe it's a fundamental,
+> critical, and important part of fighting the epidemic and I think we
+> should do it. I do not believe any engineer has found a proper way
+> of doing it with "apps" so far, but I do not deny the utility and
+> importance of "contact tracing" itself. Apologies for the confusion.
+
 ----
 
 > Pour une raison que je m'explique mal, le sondage m'été envoyé en

outline french bit
diff --git a/blog/2020-07-12-contact-tracing.mdwn b/blog/2020-07-12-contact-tracing.mdwn
index 96e36c24..c4385a16 100644
--- a/blog/2020-07-12-contact-tracing.mdwn
+++ b/blog/2020-07-12-contact-tracing.mdwn
@@ -22,6 +22,8 @@ Please don't do this.
 > I wrote the above in a response to the Québec government's [survey
 > about a possible tracing app](https://consultation.quebec.ca/processes/covidapp/).
 
+----
+
 > Pour une raison que je m'explique mal, le sondage m'été envoyé en
 > anglais, et j'ai donc écrit ma réponse dans la langue de Shakespeare
 > au lieu de celle de molière... Je serai heureux de fournir une

fix tag macro
diff --git a/blog/2020-07-12-contact-tracing.mdwn b/blog/2020-07-12-contact-tracing.mdwn
index 2fc063af..96e36c24 100644
--- a/blog/2020-07-12-contact-tracing.mdwn
+++ b/blog/2020-07-12-contact-tracing.mdwn
@@ -27,4 +27,4 @@ Please don't do this.
 > au lieu de celle de molière... Je serai heureux de fournir une
 > traduction française à ceux ou celles qui en ont besoin...
 
-[[!tags debian-planet python-planet covid-19 privacy]]
+[[!tag debian-planet python-planet covid-19 privacy]]

quick blurb on contact tracing apps
diff --git a/blog/2020-07-12-contact-tracing.mdwn b/blog/2020-07-12-contact-tracing.mdwn
new file mode 100644
index 00000000..2fc063af
--- /dev/null
+++ b/blog/2020-07-12-contact-tracing.mdwn
@@ -0,0 +1,30 @@
+[[!meta title="On contact tracing"]]
+
+I have strong doubts about the efficiency of any tracing app of the
+sort, and even less in the context where it is [unlikely that a
+majority of the population will use it](https://www.technologyreview.com/2020/05/11/1001541/iceland-rakning-c19-covid-contact-tracing/).
+
+There's also the problem that this app would need to work on Apple
+phones, or be incompatible with them, and cause significant "fracture"
+between those who have access to technology, and those who
+haven't. See [this text for more details](https://www.ledevoir.com/opinion/idees/579637/sortie-de-crise-technologies-numeriques-le-tracage-de-contacts-et-la-fracture-numerique).
+
+Such an app would be a security and privacy liability at no benefit to
+public health. There are better options, see for this [research on
+hardware tokens](https://www.bunniestudios.com/blog/?p=5820). But I doubt any contact tracing app or hardware
+will [actually work](https://www.schneier.com/blog/archives/2020/05/me_on_covad-19_.html) anyways.
+
+I am a computer engineer with more than 20 years of experience in the
+domain, and I have been following this question closely.
+
+Please don't do this.
+
+> I wrote the above in a response to the Québec government's [survey
+> about a possible tracing app](https://consultation.quebec.ca/processes/covidapp/).
+
+> Pour une raison que je m'explique mal, le sondage m'été envoyé en
+> anglais, et j'ai donc écrit ma réponse dans la langue de Shakespeare
+> au lieu de celle de molière... Je serai heureux de fournir une
+> traduction française à ceux ou celles qui en ont besoin...
+
+[[!tags debian-planet python-planet covid-19 privacy]]

got a new cool antenna
diff --git a/hardware/radio.mdwn b/hardware/radio.mdwn
index 0b079bda..567db591 100644
--- a/hardware/radio.mdwn
+++ b/hardware/radio.mdwn
@@ -21,6 +21,9 @@ Hardware
  * 100' of RG8 coax cabling [65$ at radioworld](http://radioworld.ca/product_info.php?cPath=73_394&products_id=6831)
  * 3 PL259 connectors [4$ at radioworld](http://radioworld.ca/product_info.php?cPath=73_394&products_id=3244)
  * Total, incl. shipping: 452.35$
+ * [S&K Open Stub J-Pole Antenna](https://signalstuff.com/product/signal-staff-osj/) (OSJ) from [Signalstuff.com](https://signalstuff.com/),
+   can be mounted on a mast *or* a camera tripod *or* even hanged from
+   a tree! (60$USD)
 * VHF/UHF meter: [workman 50$](http://www.ebay.com/itm/SWR-Power-500-Watt-METER-120-500-MHz-UHF-VHF-Ham-Radio-w-RG8X-Jumper-/380424888249)  ([17 reviews: 3.5/5](http://www.eham.net/reviews/detail/3905))
 * Ferrites: ~40$ + 24$ customs fees (PN: 2643167851 from [IBS electronics](http://www.ibselectronics.com/search_r.asp?mfgpn=2643167851))
 * some PL259 connectors, usually around 2$ each

update i do not use borg anymore
diff --git a/services/backup.mdwn b/services/backup.mdwn
index 6c7ca3ab..bf4531c2 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -11,9 +11,12 @@ hand, monthly.
 Workstation and laptop backups are more irregular, on a separate
 drive.
 
-Most backups are performed with [borg](http://borgbackup.rtfd.org/) but some offsite backups are
-still done with [bup](https://bup.github.io/) for historical reasons but may be migrated to
-another storage system, see below for progress.
+Backups are performed with [borg](http://borgbackup.rtfd.org/) and [git-annex](https://git-annex.branchable.com/).
+
+Some offsite backups were done with [bup](https://bup.github.io/), but that was replaced by
+borg because the latter supports client-side encryption out of the
+box, supports purging old snapshots (which bup didn't at the time),
+and has a better commandline interface.
 
 Backup storage
 ==============

some settings in a user.js now, document other issues
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index ec9b3b31..fae57ec3 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -279,7 +279,8 @@ the long term.
 Configuration
 ==============
 
-I have set the following configuration options:
+I have set the following configuration options, in a `user.js` file
+that I version-control into git:
 
  * `browser.tabs.loadDivertedInBackground` ([ref](http://kb.mozillazine.org/About:config_entries)):
    true (fixes an issue where focus would change to the firefox window
@@ -329,6 +330,27 @@ I add some search engines that are misconfigured from [Mycroft](http://mycroftpr
 import my set of [Debian bookmarks](https://salsa.debian.org/debian/debian-bookmarks-shortcuts) for quick access to Debian
 resources.
 
+Remaining work
+==============
+
+My Firefox configuration is not fully automated yet. The `user.js`
+hacks above only go so far. For example, the search engine override
+[doesn't seem to work anymore](https://superuser.com/questions/1372679/how-to-set-duckduckgo-as-default-search-engine-using-user-js). Similarly, it is not possible to
+populate the following:
+
+ * search engines
+ * bookmarks
+ * extensions
+
+Bookmarks and search engines seems to be hackable through a
+[distribution file](https://wiki.mozilla.org/Distribution_INI_File) (and a [different one on mobile](https://wiki.mozilla.org/Mobile/Distribution_Files)??), but I
+haven't figured out how that works just yet. It also seems extensions
+are going to become harder since [Mozilla decided to stop
+sideloading](https://blog.mozilla.org/addons/2020/03/10/support-for-extension-sideloading-has-ended/) for some obscure reason...
+
+I miss the times where bookmarks where just that HTML file sitting in
+the profile directory...
+
 History
 =======
 

promote livemarks and minimal, demote display anchors, containers, tridactyl
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 9bb17c9f..ec9b3b31 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -28,8 +28,11 @@ I have those extensions installed and use them very frequently:
    package"]], [source](https://github.com/browserpass/browserpass)) - super fast access to my passwords. use
    some magic mumble-jumble message passing thing which feels a bit
    creepy.
- * [display anchors](https://addons.mozilla.org/en-US/firefox/addon/display-_anchors/) (no deb, [source](https://github.com/Rob--W/display-anchors))
  * [GhostText][] (no debian package, [#910289](https://bugs.debian.org/910289), [source](https://github.com/GhostText/GhostText))- "It's all text" replacement
+ * [Livemarks](https://addons.mozilla.org/en-US/firefox/addon/livemarks/) (no deb, [source](https://github.com/nt1m/livemarks)) or [Awesome RSS](https://addons.mozilla.org/en-US/firefox/addon/awesome-rss/) (no deb,
+   [source](https://github.com/shgysk8zer0/awesome-rss)) - replace the [Live bookmarks removal](https://support.mozilla.org/en-US/kb/live-bookmarks-migration)
+ * [Minimal](https://addons.mozilla.org/en-US/firefox/addon/minimal-internet-experience/) ([homepage](https://minimal.community/)) - removes autoplay, search suggestions
+   and all sorts of junks from many websites
  * [uBlock Origin][] ([[!debpkg webext-ublock-origin desc="debian
    package"]], [source](https://github.com/gorhill/uBlock)) - making the web sane again
  * [uMatrix][] ([[!debpkg webext-umatrix desc="debian package"]],
@@ -60,15 +63,7 @@ Ideally, all of those should be packaged for Debian.
 
 I am testing those and they might make it to the top list once I'm happy:
 
- * Firefox [Multi-account containers][] (no deb, [source](https://github.com/mozilla/multi-account-containers/)) - kind of
-   useful, but also a bit strange: impossible to assign an existing
-   tab to a container, UI is very clikety (can't open a
-   container-specific tab from the keyboard), etc. need to click-hold
-   on the "+" tab button to choose container.
- * [Livemarks](https://addons.mozilla.org/en-US/firefox/addon/livemarks/) (no deb, [source](https://github.com/nt1m/livemarks)) or [Awesome RSS](https://addons.mozilla.org/en-US/firefox/addon/awesome-rss/) (no deb,
-   [source](https://github.com/shgysk8zer0/awesome-rss)) - replace the [Live bookmarks removal](https://support.mozilla.org/en-US/kb/live-bookmarks-migration)
- * [Minimal](https://addons.mozilla.org/en-US/firefox/addon/minimal-internet-experience/) ([homepage](https://minimal.community/)) - removes autoplay, search suggestions
-   and all sorts of junks from many websites
+ * [display anchors](https://addons.mozilla.org/en-US/firefox/addon/display-_anchors/) (no deb, [source](https://github.com/Rob--W/display-anchors))
  * [Open in Browser](https://addons.mozilla.org/en-US/firefox/addon/open-in-browser/) (no deb, [source](https://github.com/Rob--W/open-in-browser)) - reopen the file in the
    browser instead of downloading
  * [Smart HTTPS](https://addons.mozilla.org/en-US/firefox/addon/smart-https-revived/) (no deb, [source](https://github.com/ilGur1132/Smart-HTTPS)) - some use [HTTPS
@@ -78,19 +73,6 @@ I am testing those and they might make it to the top list once I'm happy:
    "secure" URL...  HE does have a "Block all unencrypted requests"
    setting, but it does exactly that: it breaks plaintext sites
    completely. See [issue #7936](https://github.com/EFForg/https-everywhere/issues/7936) and [issue #16488](https://github.com/EFForg/https-everywhere/issues/16488) for details.
- * [Switch container](https://addons.mozilla.org/en-US/firefox/addon/switch-container/) (no deb, [source](https://gitlab.com/mjanetmars/switch-container)) - fixes *one* of the
-   issues with multi-account containers (ie. moving tab to another
-   container)
- * [tridactyl][] - to use the web browser without the mouse. was
-   [pulled from AMO][] for a policy violation, might return but in the
-   meantime, i'm trying out [vimium][], which has the major problem of
-   not entering the "edit mode" (where keybindings are not effective)
-   in text areas, or at least in etherpad. tridactyl has its own
-   annoyances though, like <kbd>C-f</kbd> being bound to "page
-   down". this can be disabled with `:unbind <C-f>`. also see the
-   [builtin Firefox shortcuts][] and the `pentadactyl` entry in the
-   XULocalypse section below. [Krabby](https://krabby.netlify.com/), another of those
-   implementations, has an [interesting list of alternatives](https://github.com/alexherbo2/krabby/blob/master/doc/alternatives.md).
  * [View Page Archive & Cache](https://addons.mozilla.org/en-US/firefox/addon/view-page-archive/) (no deb, [source](https://github.com/dessant/view-page-archive/)) - load page in
    one or many page archives. No "save" button unfortunately, but is
    good enough for my purposes. [The Archiver](https://addons.mozilla.org/en-US/firefox/addon/the-archiver/) (no deb,
@@ -105,6 +87,30 @@ I am testing those and they might make it to the top list once I'm happy:
 Those should probably not be packaged in Debian until they make it to
 the top list.
 
+## Might use again
+
+Those were in testing for a while, then installed, but then I got
+tired of them...
+
+ * Firefox [Multi-account containers][] (no deb, [source](https://github.com/mozilla/multi-account-containers/)) - kind of
+   useful, but also a bit strange: impossible to assign an existing
+   tab to a container, UI is very clikety (can't open a
+   container-specific tab from the keyboard), etc. need to click-hold
+   on the "+" tab button to choose container.
+ * [Switch container](https://addons.mozilla.org/en-US/firefox/addon/switch-container/) (no deb, [source](https://gitlab.com/mjanetmars/switch-container)) - fixes *one* of the
+   issues with multi-account containers (ie. moving tab to another
+   container)
+ * [tridactyl][] - to use the web browser without the mouse. was
+   [pulled from AMO][] for a policy violation, might return but in the
+   meantime, i'm trying out [vimium][], which has the major problem of
+   not entering the "edit mode" (where keybindings are not effective)
+   in text areas, or at least in etherpad. tridactyl has its own
+   annoyances though, like <kbd>C-f</kbd> being bound to "page
+   down". this can be disabled with `:unbind <C-f>`. also see the
+   [builtin Firefox shortcuts][] and the `pentadactyl` entry in the
+   XULocalypse section below. [Krabby](https://krabby.netlify.com/), another of those
+   implementations, has an [interesting list of alternatives](https://github.com/alexherbo2/krabby/blob/master/doc/alternatives.md).
+
 ## Previously used
 
 I once used those but eventually removed them for various

update marcos status
diff --git a/hardware/server/marcos.mdwn b/hardware/server/marcos.mdwn
index 9d99d7f9..538c7d76 100644
--- a/hardware/server/marcos.mdwn
+++ b/hardware/server/marcos.mdwn
@@ -58,6 +58,7 @@ fail. Here's the inventory of drives.
 Currently in marcos:
 
  * `Samsung SSD 850 EVO 500GB`: 465GiB
+ * `Seagate HDD IronWolf 8TB ST8000VN004-2M21`: 7.3TiB
  * `Seagate HDD IronWolf 8TB ST8000VN0022-2EL112`: 7.3TiB
  * `Western Digital Green 3TB WDC_WD30EZRX-00D8PB0`: 2.7TiB (external
    "WD My Drive" backup drive)
@@ -95,6 +96,15 @@ Possible newegg order:
  * <https://www.newegg.ca/p/N82E16882203142?Item=9SIAH2M8651681>
  * https://www.staples.ca/products/805523-en-dymo-labelwriter-450-label-printer-1756692
 
+Update: seems like Intel is more popular there, maybe try one in the
+mix. We support NVMe anyways, so might as well get one of those:
+
+ * https://www.newegg.ca/intel-660p-series-1tb/p/N82E16820167462
+ * https://www.newegg.ca/western-digital-blue-sn550-nvme-1tb/p/N82E16820250135?Item=N82E16820250135
+ * review and pick one of those https://nairatips.com/best-nvme-ssd-enclosure/
+
+The [samsung is 70$+ more](https://www.newegg.ca/samsung-860-evo-series-1tb/p/N82E16820147678?Item=N82E16820147678) so maybe not worth it?
+
 ## BIOS config
 
 New machine BIOS configuration:
@@ -117,16 +127,13 @@ New machine BIOS configuration:
 
 ## Remaining transplant TODO
 
- 1. missing a SATA cable for the port #3, because provided cables have
-    an "elbow" that prevents them to be connected (and the bord
-    connectors are on the side instead of on top (!!).
-
  2. The external backup drive (sdc2) could be swapped into one of the
     hotswap bay.
 
- 3. need to setup RAID-1.
+ 3. need to setup RAID-1 on the SSDs
 
- 4. SSD drive floating in bay because of missing tray adapter.
+ 4. SSD drive floating in bay because of missing tray adapter. (to be
+    replaced by 2xNVMe drives)
 
  5. Missig serial port, required to switch to headless server (and
     remove the nvidia video card), although...
@@ -136,7 +143,18 @@ New machine BIOS configuration:
     output).
 
  6. HDD LEDs seem to light up (but not the SSD!) in the BIOS, but are
-    not lit when Linux is booted.
+    not lit when Linux is booted. tested [ledmon](https://github.com/intel/ledmon) but it seems to
+    have [issues with AMD devices](https://github.com/intel/ledmon/issues/65) and, surprise-suprise, i have a
+    AMD board! but i'm not sure that is related because the leds are
+    controlled by the Supermicro enclosure...
+
+## DONE
+
+ 1. missing a SATA cable for the port #3, because provided cables have
+    an "elbow" that prevents them to be connected (and the bord
+    connectors are on the side instead of on top (!!).
+
+ 2. RAID-1 on the HDDs
 
 # Possible phase out
 

completely moved to puppet
diff --git a/software/packages.yml b/software/packages.yml
index cb62a1c6..78a2a069 100644
--- a/software/packages.yml
+++ b/software/packages.yml
@@ -11,336 +11,4 @@
 #
 # ansible-playbook packages.yml --tags graphics
 #
-# to install only graphics-related packages
-#
-# the following tags are available right now:
-#
-# author
-# comms
-# desktop
-# developer
-# games
-# gis
-# graphics
-# ham
-# multimedia
-# sysadmin
-
----
-- name: install common packages
-  hosts: all
-
-  tasks:
-  - name: install authorship tools (incl. TeX)
-    # This is mostly TeX-related packages
-    tags: author
-    # replaced by profile::author
-
-  - name: install communication tools
-    tags: comms
-    # replaced by profile::comms
-
-  - name: install desktop packages
-    # Shitload of stuff that doesn't fit anywhere else.
-    tags: desktop
-    # profile::desktop
-
-  - name: install developer tools
-    tags: developer
-    #  Mostly VCS tools, emacs, emulation tools and emulators.
-    apt: name={{item}} state=installed
-    with_items:
-      - adb
-      - adequate
-      - apt-file
-      - apt-listbugs
-      - apt-show-versions
-      - apt-venv
-      - aptitude
-      - austin
-      - bats
-      - binwalk
-      - bzr
-      - build-essential
-      - cdbs
-      - cloc
-      - curl
-      - colordiff
-      - cvs
-      - dateutils
-      - debian-el
-      - debian-installer-9-netboot-amd64
-      - dgit
-      - dh-make
-      - dh-make-elpa
-      - syslinux-efi
-      - pxelinux
-      - devscripts
-      - dia
-      - docker.io
-      - dpkg-dev-el
-      - dstat
-      - dictionary-el
-      - elpa-anzu
-      - elpa-atomic-chrome
-      - elpa-company
-      - elpa-company-go
-      - elpa-elpy
-      - elpa-flycheck
-      - elpa-hl-todo
-      - elpa-ledger
-      - elpa-magit
-      - elpa-mailscripts
-      - elpa-markdown-mode
-      - elpa-py-autopep8
-      - elpa-rainbow-mode
-      - elpa-solarized-theme
-      - elpa-use-package
-      - elpa-web-mode
-      - elpa-which-key
-      - elpa-writegood-mode
-      - elpa-yaml-mode
-      - elpa-yasnippet
-      - exuberant-ctags
-      - emacs
-      - emacs-goodies-el
-      - emacs25
-      - emacs25-common-non-dfsg
-      - fabric
-      - fastboot
-      - flake8
-      - gdb
-      - gettext-el
-      - git
-      - git-annex
-      - git-buildpackage
-      - git-email
-      - git-extras
-      - git-mediawiki
-      - git-review
-      - git-svn
-      - github-backup
-      - gitlint
-      - glade
-      - gocode
-      - go-dep
-      - golang
-      - golang-mode
-      - golint
-      - graphviz
-      - haskell-mode
-      - help2man
-      - hub
-      - stylish-haskell
-      - icdiff
-      - ikiwiki
-      - ikiwiki-hosting-common
-      - info
-      - inotify-tools
-      - ipython
-      - ipython3
-      - jq
-      - kicad
-      - ldap-utils
-      - librarian-puppet
-      - libterm-readkey-perl
-      - libtext-bibtex-perl
-      - libsearch-xapian-perl
-      # for flamegraph
-      - libdevel-nytprof-perl
-      - linkchecker
-      - make-doc
-      - mercurial
-      - multitime
-      - myrepos
-      - ncdu
-      - npm
-      - num-utils
-      - org-mode
-      - org-mode-doc
-      - pastebinit
-      - perl-doc
-      - po4a
-      - puppet
-      - puppet-lint
-      - puppet-strings
-      - pv
-      - pypi2deb
-      - python
-      - python3
-      - python3-betamax
-      - python3-doc
-      - python-jedi
-      - python3-jedi
-      - python3-html2text
-      - python-pip
-      - python3-pip
-      - python-pytest
-      - python3-pytest
-      - python-seaborn
-      - python3-seaborn
-      - python-setuptools
-      - python3-setuptools-scm
-      - python-setuptools
-      - python3-setuptools-scm
-      - python-sphinx
-      - python3-sphinx
-      - python-sphinx-rtd-theme
-      - python3-sphinx-rtd-theme
-      - python-ttystatus
-      - python3-unidecode
-      - python-wheel
-      - python3-vcr
-      - qemu
-      - qemu-kvm
-      - quilt
-      - rename
-      - reprotest
-      - g10k
-      - ruby-rspec
-      - sbuild
-      - shellcheck
-      - sloccount
-      - sqlitebrowser
-      - subversion

(fichier de différences tronqué)
start converting this to a puppet recipe
diff --git a/software/packages.yml b/software/packages.yml
index a62f7728..cb62a1c6 100644
--- a/software/packages.yml
+++ b/software/packages.yml
@@ -34,175 +34,16 @@
   - name: install authorship tools (incl. TeX)
     # This is mostly TeX-related packages
     tags: author
-    apt: name={{item}} state=installed
-    with_items:
-      - auctex
-      - dict
-      - dict-bouvier
-      - dict-devil
-      - dict-elements
-      - dict-foldoc
-      - dict-freedict-eng-fra
-      - dict-freedict-eng-spa
-      - dict-freedict-fra-eng
-      - dict-freedict-spa-eng
-      - dict-gazetteer2k
-      - dict-gcide
-      - dict-jargon
-      - dict-moby-thesaurus
-      - dict-vera
-      - dict-wn
-      - dictd
-      - dictionary-el
-      - epubcheck
-      - elpa-writegood-mode
-      - gv
-      - libtext-multimarkdown-perl
-      - multitime
-      - pandoc
-      - sigil
-      - texlive-latex-base
-      - texlive-latex-recommended
-      - texlive-latex-extra
-      - texlive-luatex
+    # replaced by profile::author
 
   - name: install communication tools
     tags: comms
-    #  Mostly consists of mail and IRC stuff (irssi, mutt, thunderbird, offlineimap).
-    apt: name={{item}} state=installed
-    with_items:
-      - bsd-mailx
-      - irssi-plugin-otr
-      - irssi-plugin-xmpp
-      - irssi-scripts
-      - mutt
-      - neomutt
-      - nullmailer
-      - syncmaildir
+    # replaced by profile::comms
 
   - name: install desktop packages
     # Shitload of stuff that doesn't fit anywhere else.
     tags: desktop
-    apt: name={{item}} state=installed
-    with_items:
-      - afuse
-      - anki
-      - apksigner
-      - arandr
-      - aspell-fr
-      - calibre
-      - chromium
-      - diceware
-      - electrum
-      - emacs
-      - exiftool
-      - feed2exec
-      - feh
-      - fim
-      - finger
-      - firefox-esr
-      - fonts-roboto
-      - fonts-firacode
-      - fortunes
-      - gajim
-      - gameclock
-      - git-annex
-      - git-annex-remote-rclone
-      - git-lfs
-      - git-mediawiki
-      - gobby
-      - gnutls-bin
-      - gucharmap
-      - hledger
-      - i3
-      - jmtpfs
-      - khal
-      - khard
-      - kstars
-      - ledger
-      - ledger-el
-      - less
-      - libnotify-bin
-      - libu2f-host0
-      - localepurge
-      - locales
-      - mlocate
-      - maim
-      - monkeysign
-      - monkeysphere
-      - mpd
-      - mumble
-      - mutt
-      - muttprint
-      - ncdu
-      - needrestart
-      - needrestart-session
-      - network-manager-iodine-gnome
-      - network-manager-openvpn-gnome
-      - notmuch
-      - notmuch-emacs
-      - oathtool
-      - offlineimap
-      - onionshare
-      - openjdk-8-jdk-headless
-      - openntpd
-      - parcimonie
-      - pavucontrol
-      - pass
-      - pass-extension-otp
-      - pcscd
-      - picard
-      - pidgin
-      - pinpoint
-      - pmount
-      - pinentry-qt
-      - python-certifi
-      - python3-notmuch
-      - qalculate
-      - qalculate-gtk
-      - ranger
-      - redshift-gtk
-      - rofi
-      - rxvt-unicode
-      - scdaemon
-      - slop
-      - sm
-      - surfraw
-      - sxiv
-      - taffybar
-      - thunar
-      - torbrowser-launcher
-      - transmission-qt
-      - trayer
-      - tty-clock
-      - unattended-upgrades
-      - unicode
-      - vdirsyncer
-      - verbiste
-      - verbiste-gnome
-      - workrave
-      - wotsap
-      - xkbset
-      - xprintidle
-      - xkcdpass
-      - xmobar
-      - xsel
-      - libghc-xmonad-dev
-      - libghc-xmonad-contrib-dev
-      - libghc-xmonad-extras-dev
-      - libghc-taffybar-dev
-      - xmonad
-      - xplanet
-      - xscreensaver
-      - xscreensaver-screensaver-bsod
-      - xterm
-      - webext-browserpass
-      - webext-ublock-origin
-      - webext-umatrix
-      - xournal
-      - yubikey-personalization
-      - yubikey-manager
-      - zotero-standalone
+    # profile::desktop
 
   - name: install developer tools
     tags: developer
@@ -390,21 +231,8 @@
 
   - name: install graphics packages
     # My graphic design tools. Not much, since I don't do much of that.
-    apt: name={{item}} state=installed
     tags: graphics
-    with_items:
-      - colorhug-client
-      - darktable
-      - dia
-      - dispcalgui
-      - feh
-      - geeqie
-      - gimp
-      - inkscape
-      - rapid-photo-downloader
-      - sane

(fichier de différences tronqué)
another nice debian font
diff --git a/blog/2020-03-10-font-changes.mdwn b/blog/2020-03-10-font-changes.mdwn
index 7cdc4afc..386ac46c 100644
--- a/blog/2020-03-10-font-changes.mdwn
+++ b/blog/2020-03-10-font-changes.mdwn
@@ -30,6 +30,8 @@ alternatives. I found the following packages in debian:
  * [fonts-hack](https://tracker.debian.org/fonts-hack): no ligatures
  * [fonts-hermit](https://tracker.debian.org/fonts-hermit): no ligatures, smaller
  * [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)
 
 Those are also "programmer fonts" that caught my interest but somehow
 didn't land in Debian yet:

noter un oubli et une mise à jour sur le blockchain
diff --git a/blog/2019-12-12-blockchain-biometrie.mdwn b/blog/2019-12-12-blockchain-biometrie.mdwn
index e946612a..84b301f8 100644
--- a/blog/2019-12-12-blockchain-biometrie.mdwn
+++ b/blog/2019-12-12-blockchain-biometrie.mdwn
@@ -102,8 +102,11 @@ vie privée.
 > > 
 > > Merci.
 
-Mise à jour: il semblerait que la journaliste ait en effet reçu mon
-message et répondu, mais n'a pas effectué de correction. Voir [cette
-discussion sur Twitter](https://twitter.com/MyleneCrete/status/1205531144135020544).
+Mise à jour, 2020-06-17: il semblerait que la journaliste ait en effet
+reçu mon message et répondu, mais n'a pas effectué de correction. Voir
+[cette discussion sur Twitter](https://twitter.com/MyleneCrete/status/1205531144135020544). J'avais oublié de noter ce fait
+ici. Noter aussi que je n'ai pas eu de suivi du conseil de la presse
+mais que cette idée parfaitement ridicule [est de retour](https://www.journaldemontreal.com/2020/06/17/des-milliards-de-dollars-pour-un-projet-unique) avec des
+budgets de milliards de dollars, en plein pandémie.
 
 [[!tag politique québec légal réflexion blockchain biométrie vie_privée]]

noter la discussion twitter
diff --git a/blog/2019-12-12-blockchain-biometrie.mdwn b/blog/2019-12-12-blockchain-biometrie.mdwn
index 350e3c6b..e946612a 100644
--- a/blog/2019-12-12-blockchain-biometrie.mdwn
+++ b/blog/2019-12-12-blockchain-biometrie.mdwn
@@ -102,4 +102,8 @@ vie privée.
 > > 
 > > Merci.
 
+Mise à jour: il semblerait que la journaliste ait en effet reçu mon
+message et répondu, mais n'a pas effectué de correction. Voir [cette
+discussion sur Twitter](https://twitter.com/MyleneCrete/status/1205531144135020544).
+
 [[!tag politique québec légal réflexion blockchain biométrie vie_privée]]

update wikilink and toc status: implemented
diff --git a/services/wiki/ikiwiki-hugo-conversion.mdwn b/services/wiki/ikiwiki-hugo-conversion.mdwn
index 943ae219..80f983a8 100644
--- a/services/wiki/ikiwiki-hugo-conversion.mdwn
+++ b/services/wiki/ikiwiki-hugo-conversion.mdwn
@@ -201,23 +201,34 @@ done to see how other engines handle this and how it compares to the
 
 The peculiarities of wikilinks in ikiwiki:
 
- * case-insensitiven (e.g. `\[[OtherPage]]` and `\[[otherpage]]` both
-   work)
- * subpage lookups (e.g. `\[[otherpage]]` in `foo/subpage` will
-   look for `foo/subpage/otherpage`, `foo/otherpage`,
-   `otherpage`, in order; `\[[foo/subpage]]` will find
-   `/foo/subpage` from `bar`, instead of the expected
-   `bar/foo/subpage` in HTML)
- * absolute lookups (prefixed with `/`, e.g. `\[[/about]]` links to
-   `https://example.com/foo/about` if the wiki is in
-   `example.com/foo`, and *not* `https://example.com/about` as HTML
-   normally would - probably relevant only for wikis in subdirectories)
- * userdir lookups (`\[[anarcat]]` links to `\[[users/anarcat]]` if
-   userdir is set to `users`)
- * backslash escapes (`\\[[WikiLink]]` is not a link)
- * anchor lookups (`\[[WikiLink#foo]]`)
- * there might be other rules like underscore (`_`) mapping to spaces
-   and other funky escape mechanisms
+  1. case-insensitiven (e.g. `\[[OtherPage]]` and `\[[otherpage]]` both
+     work) - implemented
+
+  2. subpage lookups (e.g. `\[[otherpage]]` in `foo/subpage` will
+     look for `foo/subpage/otherpage`, `foo/otherpage`,
+     `otherpage`, in order; `\[[foo/subpage]]` will find
+     `/foo/subpage` from `bar`, instead of the expected
+     `bar/foo/subpage` in HTML) - implemented
+
+  3. absolute lookups (prefixed with `/`, e.g. `\[[/about]]` links
+     to `https://example.com/foo/about` if the wiki is in
+     `example.com/foo`, and *not* `https://example.com/about` as
+     HTML normally would - probably relevant only for wikis in
+     subdirectories) - NOT IMPLEMENTED
+
+  4. userdir lookups (`\[[anarcat]]` links to `\[[users/anarcat]]` if
+     userdir is set to `users`) in some contexts (namely comments,
+     recentchanges, but not normal content) - NOT IMPLEMENTED
+
+  5. backslash escapes (`\\[[WikiLink]]` is not a link) -
+     implemented by the caller (in LINK_RE)
+
+  6. anchor lookups (`\[[WikiLink#foo]]`) - implemented by the
+     caller (in LINK_RE)
+
+  7. there might be other rules like underscore (`_`) mapping to
+     spaces and other funky escape mechanisms - NOT IMPLEMENTED,
+     look at IkiWiki::titlepage for those
 
 Tasks
 =====
@@ -229,10 +240,13 @@ the gist of it is we need to implement:
    bundles](https://gohugo.io/content-management/page-bundles/) and [content organization](https://gohugo.io/content-management/organization/))
  * `\[[link]]` and `\[[link|parser]]`, hard because we need to figure
    out pagespec? maybe [links and crossferences](https://gohugo.io/content-management/cross-references/) could save us, or
-   maybe just [relative URLs](https://gohugo.io/content-management/urls/#relative-urls)
+   maybe just [relative URLs](https://gohugo.io/content-management/urls/#relative-urls) - implemented some of that logic in
+   the parser
  * incidentally, backslashed stuff like the above link stuff for example
  * table of contents could be a problem: Hugo only has [support
-   through templates](https://gohugo.io/content-management/toc/#usage), not markup (or maybe shortcode would work?)
+   through templates](https://gohugo.io/content-management/toc/#usage), not markup (or maybe shortcode would
+   work?) - implemented a directive parser that converts to GitLab's
+   `\[[__TOC__]]` which might be reused)
  * img directives (maybe [this works](https://gohugo.io/content-management/image-processing/)
  * format (shortcodes? or [syntax hilighting](https://gohugo.io/content-management/syntax-highlighting/))
  * shortcodes ([dokuwiki converter](https://github.com/wgroeneveld/dokuwiki-to-hugo) also suggests using shortcodes for interwiki)

new package entered unstable!
diff --git a/software/packages.yml b/software/packages.yml
index c8beb4f4..a62f7728 100644
--- a/software/packages.yml
+++ b/software/packages.yml
@@ -241,6 +241,7 @@
       - dstat
       - dictionary-el
       - elpa-anzu
+      - elpa-atomic-chrome
       - elpa-company
       - elpa-company-go
       - elpa-elpy

a quote from hendrix
This one is tricky. Technically, it's a derivation of an existing
quote, possibly from Ghandi:
> The day the power of love overrules the love of power, the world
> will know peace.
https://www.goodreads.com/quotes/248476-the-day-the-power-of-love-overrules-the-love-of
But wikipedia attributes to Sri Chinmoy a similar quote:
> The heart's Power Of Love must replace the mind's Love Of Power. If
> I have the Power Of Love, then I shall claim the whole World as my
> own … World Peace can be achieved when the Power Of Love replaces
> the Love Of Power.
https://en.wikiquote.org/wiki/Sri_Chinmoy
.. but that's from 1993, years after Hendrix. The original quote from
his 1970 book is actually:
> When the power of love replaces the love of power, man will have a
> new name: God.
... which is a *very* different thing.
But maybe the first source is Gladstone:
> We look forward to the time when the Power of Love will replace the
> Love of Power. Then will our world know the blessings of peace.
... which wikipedia marks as disputed:
https://en.wikiquote.org/wiki/William_Ewart_Gladstone#Disputed
It *is*, however, predating Jimi Hendrix (almost his birth, even) by
quite a few years.
I do prefer Hendrix's wording so I'm using that. And black lives
matter so fuck that white guy, whoever that is.
diff --git a/fortunes.txt b/fortunes.txt
index c169a3c2..6a8e6592 100644
--- a/fortunes.txt
+++ b/fortunes.txt
@@ -1120,3 +1120,6 @@ If you want to go fast, go alone. If you want to go far, go together.
 Programming is a social activity in which communication is a vital
 skill. The code you leave behind speaks.
                         - Kate Gregory
+%
+When the power of love overcomes love of power the world will know peace.
+                        - Jimi Hendrix

Added a comment: Mandos
diff --git a/blog/2020-06-10-gnutls-audit/comment_1_e5b0a919ab63d55b0479e4b5ceabb6bc._comment b/blog/2020-06-10-gnutls-audit/comment_1_e5b0a919ab63d55b0479e4b5ceabb6bc._comment
new file mode 100644
index 00000000..bbc41394
--- /dev/null
+++ b/blog/2020-06-10-gnutls-audit/comment_1_e5b0a919ab63d55b0479e4b5ceabb6bc._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="teddy@322dd771f447963677b44de7dd32d0ed5690ce0e"
+ nickname="teddy"
+ avatar="https://seccdn.libravatar.org/avatar/989f6e31dc9c4027c83bfc89b4ac379b"
+ subject="Mandos"
+ date="2020-06-11T18:51:25Z"
+ content="""
+Mandos co-author here.  You are correct about Mandos; only OpenPGP encrypted data is sent over the TLS connection.  Also, Mandos *does* use TLS1.3, so only active connections could ever have been intercepted and decrypted.
+
+If one would suspect that this *actually* has been done, what one should do on each Mandos client is change the OpenPGP key, generate a new encrypted blob for the Mandos server configuration, using the same password for the encrypted disk; the password can not have been compromised unless the OpenPGP secret key from the client also was compromised.  (Of course, changing the encrypted disk password is also an option, but that would also mean generating a new encrypted blob for the Mandos server configuration, which would mean more work than the other option.)
+
+Regarding your comment about Heartbleed; I agree; in using GnuTLS, we have been able to avoid being affected by most of the TLS vulnerabilities in recent years.  Also, we do not know of any other TLS library which provides either OpenPGP keys as session keys (RFC 6091), or raw public keys (RFC 7250).  We prefer to avoid X.509 certificates, so we need either one; GnuTLS recently switched from the former to the latter.
+"""]]

fix wording
diff --git a/blog/2020-06-10-gnutls-audit.mdwn b/blog/2020-06-10-gnutls-audit.mdwn
index 5a2a5b57..80d97e89 100644
--- a/blog/2020-06-10-gnutls-audit.mdwn
+++ b/blog/2020-06-10-gnutls-audit.mdwn
@@ -161,7 +161,8 @@ the above with a grain of salt.
 
 The [full patch is available here](https://gitlab.com/gnutls/gnutls/-/merge_requests/1275.patch). See also the [upstream issue
 1011](https://gitlab.com/gnutls/gnutls/-/issues/1011), the [upstream advisory](https://gnutls.org/security-new.html#GNUTLS-SA-2020-06-03), the [Debian security
-tracker](https://security-tracker.debian.org/tracker/CVE-2020-13777), and the [Redhat's Bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=1843723).
+tracker](https://security-tracker.debian.org/tracker/CVE-2020-13777),
+and the [Redhat Bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=1843723).
 
 # Moving forward
 

fix broken link
diff --git a/blog/2020-06-10-gnutls-audit.mdwn b/blog/2020-06-10-gnutls-audit.mdwn
index 224d8f31..5a2a5b57 100644
--- a/blog/2020-06-10-gnutls-audit.mdwn
+++ b/blog/2020-06-10-gnutls-audit.mdwn
@@ -177,13 +177,15 @@ Looking ahead, however, one has to wonder whether we should follow
 [@FiloSottile][]'s advice and stop using GnuTLS altogether. There are
 at least a few programs that link against GnuTLS because of the
 [OpenSSL licensing oddities][] but that has been first announced in
-2015, then [definitely and clearly resolved in 2017][] -- or [maybe
+2015, then [definitely and clearly resolved in 2017][openssl-license-update] -- or [maybe
 that was in 2018](https://opensource.com/article/19/2/top-foss-legal-developments)? Anyways it's fixed, pinky-promise-I-swear,
 except if you're one of those weirdos still using GPL-2, of
 course. Even though OpenSSL isn't the simplest and secure TLS
 implementation out there, it could preferable to GnuTLS and maybe we
 should consider changing Debian packages to use it in the future.
 
+[openssl-license-update]: https://www.openssl.org/blog/blog/2017/03/22/license/
+
 But then again, the last time something like this happened, it was
 [Heartbleed][] and GnuTLS wasn't affected, so who knows... It is
 likely that people don't have OpenSSL in mind when they suggest moving
@@ -194,7 +196,6 @@ away from GnuTLS and instead think of other TLS libraries like
 "This is fine", as they say...
 
 [Heartbleed]: https://en.wikipedia.org/wiki/Heartbleed
-[mostly resolved in 2017]: https://www.openssl.org/blog/blog/2017/03/22/license/
 [OpenSSL licensing oddities]: https://en.wikipedia.org/wiki/OpenSSL#Licensing
 
 [[!tag debian-planet security crypto sysadmin]]

clarify: openssl licensing situation is far from solved
diff --git a/blog/2020-06-10-gnutls-audit.mdwn b/blog/2020-06-10-gnutls-audit.mdwn
index 4622c123..224d8f31 100644
--- a/blog/2020-06-10-gnutls-audit.mdwn
+++ b/blog/2020-06-10-gnutls-audit.mdwn
@@ -176,8 +176,11 @@ It promises to be a fun week for some people at least.
 Looking ahead, however, one has to wonder whether we should follow
 [@FiloSottile][]'s advice and stop using GnuTLS altogether. There are
 at least a few programs that link against GnuTLS because of the
-[OpenSSL licensing oddities][] but that has been [mostly resolved in
-2017][]. Even though OpenSSL isn't the simplest and secure TLS
+[OpenSSL licensing oddities][] but that has been first announced in
+2015, then [definitely and clearly resolved in 2017][] -- or [maybe
+that was in 2018](https://opensource.com/article/19/2/top-foss-legal-developments)? Anyways it's fixed, pinky-promise-I-swear,
+except if you're one of those weirdos still using GPL-2, of
+course. Even though OpenSSL isn't the simplest and secure TLS
 implementation out there, it could preferable to GnuTLS and maybe we
 should consider changing Debian packages to use it in the future.
 

do not use "safe", it is ambiguous
mutt is not necessarily entirely "safe" just because it doesn't suffer
from this bug...
diff --git a/blog/2020-06-10-gnutls-audit.mdwn b/blog/2020-06-10-gnutls-audit.mdwn
index b61021e0..4622c123 100644
--- a/blog/2020-06-10-gnutls-audit.mdwn
+++ b/blog/2020-06-10-gnutls-audit.mdwn
@@ -96,7 +96,7 @@ against GnuTLS and could be vulnerable:
 
 # Not affected
 
-Those programs are known to be safe against the vulnerability:
+Those programs are not affected by this vulnerability:
 
  * `apache2`
  * `gnupg`
@@ -125,7 +125,7 @@ TLS.
 Keep in mind that it's not because a package links against GnuTLS that
 it *uses* it. For example, I have been told that, on Arch Linux, if
 both GnuTLS and OpenSSL are available, the `mutt` package will use the
-latter, so it's safe. I haven't confirmed that myself nor have I
+latter, so it's not affected. I haven't confirmed that myself nor have I
 checked on Debian.
 
 Also, because it relies on session tickets, there's a time window

move toc
diff --git a/blog/2020-06-10-gnutls-audit.mdwn b/blog/2020-06-10-gnutls-audit.mdwn
index 6e60b90e..b61021e0 100644
--- a/blog/2020-06-10-gnutls-audit.mdwn
+++ b/blog/2020-06-10-gnutls-audit.mdwn
@@ -1,7 +1,5 @@
 [[!meta title="CVE-2020-13777 GnuTLS audit: be scared"]]
 
-[[!toc]]
-
 So [CVE-2020-13777][] came out while I wasn't looking last week. The
 GnuTLS advisory ([GNUTLS-SA-2020-06-03][]) is pretty opaque so I'll
 refer instead to [this tweet][] from [@FiloSottile][] (Go team
@@ -33,6 +31,8 @@ roof right now, so this article is not about that.
 This article is about figuring out what, exactly, was exposed in our
 infrastructure because of this.
 
+[[!toc]]
+
 # Affected packages
 
 Assuming you're running Debian, this will show a list of packages that

add toc
diff --git a/blog/2020-06-10-gnutls-audit.mdwn b/blog/2020-06-10-gnutls-audit.mdwn
index 7671d391..6e60b90e 100644
--- a/blog/2020-06-10-gnutls-audit.mdwn
+++ b/blog/2020-06-10-gnutls-audit.mdwn
@@ -1,5 +1,7 @@
 [[!meta title="CVE-2020-13777 GnuTLS audit: be scared"]]
 
+[[!toc]]
+
 So [CVE-2020-13777][] came out while I wasn't looking last week. The
 GnuTLS advisory ([GNUTLS-SA-2020-06-03][]) is pretty opaque so I'll
 refer instead to [this tweet][] from [@FiloSottile][] (Go team

new article about gnutls vuln
diff --git a/blog/2020-06-10-gnutls-audit.mdwn b/blog/2020-06-10-gnutls-audit.mdwn
new file mode 100644
index 00000000..7671d391
--- /dev/null
+++ b/blog/2020-06-10-gnutls-audit.mdwn
@@ -0,0 +1,195 @@
+[[!meta title="CVE-2020-13777 GnuTLS audit: be scared"]]
+
+So [CVE-2020-13777][] came out while I wasn't looking last week. The
+GnuTLS advisory ([GNUTLS-SA-2020-06-03][]) is pretty opaque so I'll
+refer instead to [this tweet][] from [@FiloSottile][] (Go team
+security lead):
+
+> PSA: don't rely on GnuTLS, please.
+>
+> [CVE-2020-13777] Whoops, for the past 10 releases most TLS 1.0–1.2
+> connection could be passively decrypted and most TLS 1.3 connections
+> intercepted. Trivially.
+>
+> Also, [TLS 1.2–1.0 session tickets are awful][].
+
+[TLS 1.2–1.0 session tickets are awful]: https://blog.filippo.io/we-need-to-talk-about-session-tickets/
+[@FiloSottile]: https://twitter.com/FiloSottile
+[this tweet]: https://twitter.com/FiloSottile/status/1270061316368224256
+[GNUTLS-SA-2020-06-03]: https://gnutls.org/security-new.html#GNUTLS-SA-2020-06-03
+[CVE-2020-13777]: https://nvd.nist.gov/vuln/detail/CVE-2020-13777
+
+You are reading this correctly: supposedly encrypted TLS connections
+made with affected GnuTLS releases are vulnerable to *passive*
+cleartext recovery attack (and active for 1.3, but who uses that
+anyways). That is extremely bad. It's pretty close to just switching
+everyone to HTTP instead of HTTPS, more or less. I would have a lot
+more to say about the security of GnuTLS in particular -- and security
+in general -- but I am mostly concerned about patching holes in the
+roof right now, so this article is not about that.
+
+This article is about figuring out what, exactly, was exposed in our
+infrastructure because of this.
+
+# Affected packages
+
+Assuming you're running Debian, this will show a list of packages that
+`Depends` on GnuTLS:
+
+    apt-cache --installed rdepends libgnutls30 | grep '^ ' | sort -u
+
+This assumes you run this only on hosts running Buster or
+above. Otherwise you'll need to figure out a way to pick machines
+running GnuTLS 3.6.4 or later.
+
+Note that this list only *first level* dependencies! It is perfectly
+possible that another package uses GnuTLS without being listed
+here. For example, in the above list I have `libcurl3-gnutls`, so the
+be really thorough, I would actually need to recurse down the
+dependency tree.
+
+On my desktop, this shows an "interesting" list of targets:
+
+ * `apt`
+ * `cadaver` - AKA WebDAV
+ * `curl` & `wget`
+ * `fwupd` - another attack on top of [this one][]
+ * `git` (through the `libcurl3-gnutls` dependency)
+ * `mutt` - all your emails
+ * `weechat` - your precious private chats
+
+Arguably, fetchers like `apt`, `curl`, `fwupd`, and `wget` rely on HTTPS for
+"authentication" more than secrecy, although `apt` has its own
+OpenPGP-based authentication so that wouldn't matter anyways. Still,
+this is truly distressing. And I haven't mentioned here things like
+`gobby`, `network-manager`, `systemd`, and others - the scope of this is
+broad. Hell, even good old `lynx` links against GnuTLS.
+
+[this one]: https://github.com/justinsteven/advisories/blob/master/2020_fwupd_dangling_s3_bucket_and_CVE-2020-10759_signature_verification_bypass.md
+
+In our infrastructure, the magic command looks something like this:
+
+    cumin -o txt -p 0  'F:lsbdistcodename=buster' "apt-cache --installed rdepends libgnutls30 | grep '^ ' | sort -u" | tee gnutls-rdepds-per-host | awk '{print $NF}' | sort | uniq -c | sort -n
+
+There, the result is even more worrisome, as those important packages seem to rely on GnuTLS for their transport security:
+
+ * `mariadb` - all MySQL traffic and passwords
+ * `mandos` - full disk encryption
+ * `slapd` - LDAP passwords
+
+`mandos` is especially distressing although it's probably not
+vulnerable because it seems it doesn't store the cleartext -- it's
+encrypted with the client's OpenPGP public key -- so the TLS tunnel
+never sees the cleartext either.
+
+[Other reports][] have also mentioned the following servers link
+against GnuTLS and could be vulnerable:
+
+[Other reports]: https://twitter.com/jedisct1/status/1270078914996682753
+
+ * `exim`
+ * `rsyslog`
+ * `samba`
+ * various `VNC` implementations
+
+# Not affected
+
+Those programs are known to be safe against the vulnerability:
+
+ * `apache2`
+ * `gnupg`
+ * `python`
+ * `nginx`
+ * `openssh`
+
+This list is not exhaustive, naturally, but serves as an example of
+common software you don't need to worry about.
+
+The vulnerability only exists in GnuTLS, as far as we know, so
+programs linking against other libraries are not vulnerable.
+
+Because the vulnerability affects session tickets -- and those are set
+on the server side of the TLS connection -- only users of GnuTLS as a
+server are vulnerable. This means, for example, that while `weechat`
+uses GnuTLS, it will only suffer from the problem when acting as a
+server (which it does, in relay mode) or, of course, if the remote IRC
+server also uses GnuTLS. Same with apt, curl, wget, or git: it is
+unlikely to be a problem because it is only used as a client; the
+remote server is usually a webserver -- not git itself -- when using
+TLS.
+
+# Caveats
+
+Keep in mind that it's not because a package links against GnuTLS that
+it *uses* it. For example, I have been told that, on Arch Linux, if
+both GnuTLS and OpenSSL are available, the `mutt` package will use the
+latter, so it's safe. I haven't confirmed that myself nor have I
+checked on Debian.
+
+Also, because it relies on session tickets, there's a time window
+after which the ticket gets cycled and properly initialized. But that
+is [apparently 6 hours by default](https://twitter.com/__agwa/status/1270054740559384576) so it is going to protect only
+really long-lasting TLS sessions, which are uncommon, I would argue.
+
+My audit is limited. For example, it might have been better to walk
+the shared library dependencies directly, instead of relying on Debian
+package dependencies.
+
+# Other technical details
+
+It seems the vulnerability might have been introduced in [this merge
+request](https://gitlab.com/gnutls/gnutls/-/merge_requests/695), itself following a (entirely reasonable) [feature request
+to make it easier to rotate session tickets](https://gitlab.com/gnutls/gnutls/-/issues/184). The merge request was
+open for a few months and was thoroughly reviewed by a peer before
+being merged. Interestingly, the vulnerable function
+(`_gnutls_initialize_session_ticket_key_rotation`), explicitly says:
+
+     * This function will not enable session ticket keys on the server side. That is done
+     * with the gnutls_session_ticket_enable_server() function. This function just initializes
+     * the internal state to support periodical rotation of the session ticket encryption key.
+
+In other words, it thinks it is not responsible for session ticket
+initialization, yet it is. Indeed, the [merge request fixing the
+problem](https://gitlab.com/gnutls/gnutls/-/merge_requests/1275/) unconditionally does this:
+
+    memcpy(session->key.initial_stek, key->data, key->size);
+
+I haven't reviewed the code and the vulnerability in detail, so take
+the above with a grain of salt.
+
+The [full patch is available here](https://gitlab.com/gnutls/gnutls/-/merge_requests/1275.patch). See also the [upstream issue
+1011](https://gitlab.com/gnutls/gnutls/-/issues/1011), the [upstream advisory](https://gnutls.org/security-new.html#GNUTLS-SA-2020-06-03), the [Debian security
+tracker](https://security-tracker.debian.org/tracker/CVE-2020-13777), and the [Redhat's Bugzilla](https://bugzilla.redhat.com/show_bug.cgi?id=1843723).
+
+# Moving forward
+
+The impact of this vulnerability depends on the affected packages and
+how they are used. It can range from "meh, someone knows I downloaded
+that Debian package yesterday" to "holy crap my full disk encryption
+passwords are compromised, I need to re-encrypt all my drives",
+including "I need to change all LDAP and MySQL passwords".
+
+It promises to be a fun week for some people at least.
+
+Looking ahead, however, one has to wonder whether we should follow
+[@FiloSottile][]'s advice and stop using GnuTLS altogether. There are
+at least a few programs that link against GnuTLS because of the
+[OpenSSL licensing oddities][] but that has been [mostly resolved in
+2017][]. Even though OpenSSL isn't the simplest and secure TLS
+implementation out there, it could preferable to GnuTLS and maybe we
+should consider changing Debian packages to use it in the future.
+
+But then again, the last time something like this happened, it was
+[Heartbleed][] and GnuTLS wasn't affected, so who knows... It is
+likely that people don't have OpenSSL in mind when they suggest moving
+away from GnuTLS and instead think of other TLS libraries like
+[mbedtls](https://tls.mbed.org/) (previously known as PolarSSL), [NSS](https://en.wikipedia.org/wiki/Network_Security_Services), [BoringSSL](https://boringssl.googlesource.com/boringssl/),
+[LibreSSL](https://www.libressl.org/) and so on. Not that those are totally sinless either...
+
+"This is fine", as they say...
+
+[Heartbleed]: https://en.wikipedia.org/wiki/Heartbleed
+[mostly resolved in 2017]: https://www.openssl.org/blog/blog/2017/03/22/license/
+[OpenSSL licensing oddities]: https://en.wikipedia.org/wiki/OpenSSL#Licensing
+

(fichier de différences tronqué)
make it more obvious you don't need to recreate the dashboard
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
index 21c58fc1..93c46f57 100644
--- a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -98,8 +98,8 @@ missing something. Here's what I did.
     samples. `nexthop.anarc.at` was added into DNS to avoid hardcoding
     my upstream ISP's IP in my configuration.
 
- 4. create a Grafana panel to graph the results. first, add this
-    query:
+ 4. use this [Grafana panel](https://grafana.com/grafana/dashboards/12412) to graph the results. It was created
+    with this query:
     
         sum(probe_icmp_duration_seconds{phase="rtt"}) by (instance)
     
@@ -109,7 +109,7 @@ missing something. Here's what I did.
     * Show the `Legend` `As table`, with `Min`, `Avg`, `Max` and
       `Current` enabled
 
-    Then add this query, for packet loss:
+    Then this query, for packet loss:
     
         1-avg_over_time(probe_success[$__interval])!=0 or null
 
@@ -131,10 +131,8 @@ The result looks something like this:
 <figcaption>Not bad, but not Smokeping</figcaption>
 </figure>
 
-This actually looks pretty good!
-
-I've uploaded the resulting dashboard in the [Grafana dashboard
-repository](https://grafana.com/grafana/dashboards/12412).
+This actually looks pretty good! The resulting dashboard is available
+in the [Grafana dashboard repository](https://grafana.com/grafana/dashboards/12412).
 
 What is missing?
 ================

another typo
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
index 7becc3ef..21c58fc1 100644
--- a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -115,7 +115,7 @@ missing something. Here's what I did.
 
     * Set the `Legend` field to `{{instance}} packet loss`
     * Set a `Add series override` to `Lines: false`, `Null point mode:
-      null`, `Points: true`, `Points Radios: 1`, `Color: deep red`,
+      null`, `Points: true`, `Points Radius: 1`, `Color: deep red`,
       and, most importantly, `Y-axis: 2`
     * Set the `Right Y` axis `Unit` to `percent (0.0-1.0)` and set
       `Y-max` to 1

another archive tool
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index b4ff61ce..9bb17c9f 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -93,7 +93,9 @@ I am testing those and they might make it to the top list once I'm happy:
    implementations, has an [interesting list of alternatives](https://github.com/alexherbo2/krabby/blob/master/doc/alternatives.md).
  * [View Page Archive & Cache](https://addons.mozilla.org/en-US/firefox/addon/view-page-archive/) (no deb, [source](https://github.com/dessant/view-page-archive/)) - load page in
    one or many page archives. No "save" button unfortunately, but is
-   good enough for my purposes.
+   good enough for my purposes. [The Archiver](https://addons.mozilla.org/en-US/firefox/addon/the-archiver/) (no deb,
+   [source](https://www.cathalmcnally.com/tools/the-archiver/)) is another option that does the reverse: save only, no
+   view.
 
 [tridactyl]: https://github.com/tridactyl/tridactyl
 [builtin Firefox shortcuts]: https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly

fix headings in old articles
Some were starting directly from level 2. I thought I had fixed those,
but it seems I had only looked for '----' styled headers, not '##'.
diff --git a/blog/2007-05-30-la-resolution-et-les-laptops.mdwn b/blog/2007-05-30-la-resolution-et-les-laptops.mdwn
index facf133a..789a40f8 100644
--- a/blog/2007-05-30-la-resolution-et-les-laptops.mdwn
+++ b/blog/2007-05-30-la-resolution-et-les-laptops.mdwn
@@ -8,39 +8,39 @@ Argh... compliqué la vie avec [Xorg](http://www.x.org/). Après avoir vu [Mathi
 
  time seq -f "the quick brown fox jumps over the lazy dog %g"    10000
 
-= Voici les résultats =
+# Voici les résultats
 
-== 75dpi  ==
+## 75dpi
 
- real    0m0.908s
- user    0m0.024s
- sys     0m0.040s
+    real    0m0.908s
+    user    0m0.024s
+    sys     0m0.040s
 
-== 85dpi ==
+## 85dpi
 
- real    0m3.302s
- user    0m0.184s
- sys     0m0.104s
+    real    0m3.302s
+    user    0m0.184s
+    sys     0m0.104s
 
-== 96dpi ==
+## 96dpi
 
- real    0m6.195s
- user    0m0.212s
- sys     0m0.276s
+    real    0m6.195s
+    user    0m0.212s
+    sys     0m0.276s
 
-== 24bpp, 75dpi ==
+## 24bpp, 75dpi
 
- real    0m0.709s
- user    0m0.028s
- sys     0m0.036s
+    real    0m0.709s
+    user    0m0.028s
+    sys     0m0.036s
 
-== 24bpp, 96dpi ==
+## 24bpp, 96dpi
 
- real    0m8.125s
- user    0m0.204s
- sys     0m0.204s
+    real    0m8.125s
+    user    0m0.204s
+    sys     0m0.204s
 
-= Conclusion =
+# Conclusion
 
 On remarque donc que le 96dpi est beaucoup plus lent, d'un ordre de 8x. J'ai donc configuré GDM pour lancer X avec cette configuration:
 
@@ -54,7 +54,7 @@ On remarque donc que le 96dpi est beaucoup plus lent, d'un ordre de 8x. J'ai don
 
 Tout ceci est un bordel impossible. Je ne devrais pas avoir à m'occupper de ces choses là et X devrait fournir une interface transparente pour la résolution et les fontes. Peut-être que c'est déjà le cas et que ce sont les applications qui sont cassées, je n'en sait rien...
 
-= Update =
+# Update
 
 En fait, la "bonne façon" de régler la résolution, c'est avec le paramètre DisplaySize dans le xorg.conf:
 
@@ -72,4 +72,4 @@ Il me donne alors une résolution pas carrée:
 
 C'est évidemment n'importe quoi, mais ça marche
 
-[[!tag "logiciel libre" "geek"]]
\ No newline at end of file
+[[!tag "logiciel libre" "geek"]]
diff --git a/blog/2008-02-09-coupures-reseau-majeures-en-orient-un-complot.mdwn b/blog/2008-02-09-coupures-reseau-majeures-en-orient-un-complot.mdwn
index 5b86a85b..6a1e8823 100644
--- a/blog/2008-02-09-coupures-reseau-majeures-en-orient-un-complot.mdwn
+++ b/blog/2008-02-09-coupures-reseau-majeures-en-orient-un-complot.mdwn
@@ -22,7 +22,7 @@ Le 31 janvier, Telecom Egypt faisait [l'annonce](http://www.tmcnet.com/usubmit/2
 
 Parfois, il y a des coïncidences qui sont seulement des coïncidences...
 
-== Références ==
+# Références
 
 En plus de tous les liens inclus dans le texte, voir aussi ces excellentes ressources:
 
@@ -31,4 +31,4 @@ En plus de tous les liens inclus dans le texte, voir aussi ces excellentes resso
 * [Une autre excellente carte](http://www.telegeography.com/products/map_cable/index.php)
 * [Cette photo](http://www.wired.com/culture/art/multimedia/2008/01/gallery_simon?slide=10) sur wired.com donne une idée de la vulnérabilité de ce matériel en général
 
-[[!tag "politique" "nouvelles" "monde" "geek"]]
\ No newline at end of file
+[[!tag "politique" "nouvelles" "monde" "geek"]]
diff --git a/blog/2008-02-16-des-exemples-des-negociations-de-couloirs.mdwn b/blog/2008-02-16-des-exemples-des-negociations-de-couloirs.mdwn
index 6831b4ed..6c6cea82 100644
--- a/blog/2008-02-16-des-exemples-des-negociations-de-couloirs.mdwn
+++ b/blog/2008-02-16-des-exemples-des-negociations-de-couloirs.mdwn
@@ -6,7 +6,7 @@
 
 Dans mon article précédent, j'ai présenté comment les compagnies et le gouvernement marchent main dans la main pour nous exploiter et nous massacrer... Quelques exemples de l'actualité.
 <!--break-->
-== La forêt ==
+# La forêt
 
 [Le "livre vert"](http://www.radio-canada.ca/nouvelles/Politique/2008/02/14/001-livre-vert.shtml) des (néo-)libéraux québécois pour "réformer" la gestion de la forêt, propose, sous sa couverture "verte", d'ouvrir 25% de la forêt présentement attribuée à contrat (les fameux CAAF, qui seraient enfin abolis) au libre marché, pour créer un véritable "marché de la forêt". Encore une fois la foi au marché magique qui va tout gérer pour nous...
 
@@ -23,8 +23,8 @@ Bref, tous du monde pour le rasage de la forêt sur l'autel de la création d'em
 
 Greenpeace est cité dans l'article comme étant "beaucoup plus critique", critiquant le "manque de vision" et le mutisme sur la "conservation du patrimoine mondial que constituent les dernières forêts intactes du Québec". C'est que, deux jours plus tôt, Greenpeace publiait une [lettre ouverte au ministre](http://www.greenpeace.org/canada/fr/presse/communiques/lettre-greenpeace-claude-bechard), l'accusant d'avoir une politique de "liquidation des forêts anciennes". On ne parle pas de ce communiqué dans l'article de Radio-Canada, évidemment...
 
-== La guerre ==
+# La guerre
 
 2009? 20011? On a dit quoi déjà? Le PLC avait demandé 2009, le PC offre 2011 et on chante les louanges du concensus parlementaire. Dion nous dit maintenant que quand il a dit "2011", il voulait dire 2009, avec deux ans de "formations" des militaires "afghans". So what, tant que les sondages sont de son bord... Curieusement, ce n'est pas le cas, selon [Le Devoir](http://www.ledevoir.com/2008/02/14/176085.html), le PC obtenait 37% des intentions de vote, contre 32% pour le PLC... 
 
-[[!tag "politique" "nouvelles"]]
\ No newline at end of file
+[[!tag "politique" "nouvelles"]]
diff --git a/blog/2013-04-04-internet-101-anatomie-dun-site-web.mdwn b/blog/2013-04-04-internet-101-anatomie-dun-site-web.mdwn
index e283ac12..a4b8a214 100644
--- a/blog/2013-04-04-internet-101-anatomie-dun-site-web.mdwn
+++ b/blog/2013-04-04-internet-101-anatomie-dun-site-web.mdwn
@@ -48,7 +48,7 @@ Mais on voit rarement les adresses IP durant notre utilisation régulière du we
 
  [^2]: IP ("Internet Protocol") est un autre standard ouvert qui permet à tout le monde de se parler de façon égale sur internet.
 
-### Exercice 2.1: trouver l'adresse IP d'un site web
+## Exercice 2.1: trouver l'adresse IP d'un site web
 
 Pour trouver où est un site web, on doit commencer par trouver son adresse IP. Plusieurs outils existent sur le web pour cela, mais je vais assumer que vous avez une machine Linux qui peut faire des opérations de base dans un terminal. Si vous avez une machine handicappée (ie. Windows) vous devriez quand même être capable de trouver un terminal et rouler des commandes similaires.
 
diff --git a/blog/2016-10-14-bug-reporting.mdwn b/blog/2016-10-14-bug-reporting.mdwn
index 81ee9e79..4a49ecc6 100644
--- a/blog/2016-10-14-bug-reporting.mdwn
+++ b/blog/2016-10-14-bug-reporting.mdwn
@@ -7,7 +7,7 @@ developers to be made aware of issues with their software that they
 could not have foreseen or found themselves, for lack of resources,
 variety or imagination.
 
-[[!toc levels=2 startlevel=2]]
+[[!toc]]
 
 Prior art
 =========
diff --git a/blog/2016-12-22-debian-considering-automated-upgrades.mdwn b/blog/2016-12-22-debian-considering-automated-upgrades.mdwn
index 7065f737..0eab5b4d 100644
--- a/blog/2016-12-22-debian-considering-automated-upgrades.mdwn
+++ b/blog/2016-12-22-debian-considering-automated-upgrades.mdwn
@@ -35,7 +35,7 @@ discussion that followed was interesting as it brought up key issues one
 would have when deploying automated upgrade tools, outlining both the
 benefits and downsides to such systems.
 
-## Problems with automated upgrades
+# Problems with automated upgrades
 
 An issue raised in the following discussion is that automated upgrades
 may create unscheduled downtime for critical services. For example,
@@ -95,7 +95,7 @@ degrades the interactivity of the usually satisfying `apt-get install`
 process. Nevertheless, it seems like `needrestart` is a key component of
 a properly deployed automated upgrade system.
 
-## Benefits of automated upgrades
+# Benefits of automated upgrades
 
 One thing that was less discussed is the actual benefit of automating
 upgrades. It is merely described as "secure by default" by McIntyre in
@@ -132,7 +132,7 @@ adventurous users could follow rolling distributions like Debian testing
 or unstable with unattended upgrades as well, with all the risks and
 benefits that implies.
 
-## Possible non-issues
+# Possible non-issues
 
 That there was not a backlash against the proposal surprised me: I
 expected the privacy-sensitive Debian community to react negatively to
@@ -153,7 +153,7 @@ upgrades: such changes could mean degraded functionality or additional
 spyware. However, this is the free-software world and upgrades generally
 come with bug fixes and new features, not additional restrictions.
 
-## Automating major upgrades?
+# Automating major upgrades?
 
 While automating minor upgrades is one part of the solution to the
 problem of security maintenance, the other is how to deal with major
@@ -197,7 +197,7 @@ but it is Ubuntu-specific and would need [significant
 changes](https://answers.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+question/402913)
 in order to work in Debian.
 
-## Future work
+# Future work
 

(fichier de différences tronqué)
fix typo
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
index e3bab9d0..7becc3ef 100644
--- a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -154,7 +154,7 @@ same in PromQL. I tried:
     stddev_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[1m])
 
 The first two give zero for all samples. The latter works, but doesn't
-looks as good as Smokeping. So there might be something I'm missing.
+look as good as Smokeping. So there might be something I'm missing.
 
 [SuperQ](https://github.com/SuperQ) wrote a [special exporter for this called
 smokeping_prober](https://github.com/SuperQ/smokeping_prober/) that came out of [this discussion in the blackbox

Added a comment
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus/comment_2_48883e550b0b213f1a629fd6e178cddc._comment b/blog/2020-06-04-replacing-smokeping-prometheus/comment_2_48883e550b0b213f1a629fd6e178cddc._comment
new file mode 100644
index 00000000..da6d8bf1
--- /dev/null
+++ b/blog/2020-06-04-replacing-smokeping-prometheus/comment_2_48883e550b0b213f1a629fd6e178cddc._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="https://seccdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="comment 2"
+ date="2020-06-05T13:25:19Z"
+ content="""
+I don't actually know what those mean, to be honest. The blackbox exporter documentation isn't exactly exhaustive, so I can only venture a guess:
+
+    probe_icmp_duration_seconds{phase=\"resolve\"}
+
+DNS (domain name resolution). I ignore this in my graphing, because it's not what I am measuring.
+
+    probe_icmp_duration_seconds{phase=\"rtt\"}
+
+\"RTT\" stands for \"Round Trip Time\", this is the number \"ping\" gives you, the time it takes for a packet to reach its destination, for the destination to generate a new one, and for that packet to return back.
+
+    probe_icmp_duration_seconds{phase=\"setup\"}
+
+That, I frankly have no idea. I guess it's everything else the exporter might be doing to do what it needs to do? Looking [at the source code](https://github.com/prometheus/blackbox_exporter/blob/master/prober/icmp.go) it looks like it's the time it takes to setup the socket...
+"""]]

approve comment
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus/comment_1_ebbcf2e4e7ebeeba1180dd02ce0ebd06._comment b/blog/2020-06-04-replacing-smokeping-prometheus/comment_1_ebbcf2e4e7ebeeba1180dd02ce0ebd06._comment
new file mode 100644
index 00000000..35034f9c
--- /dev/null
+++ b/blog/2020-06-04-replacing-smokeping-prometheus/comment_1_ebbcf2e4e7ebeeba1180dd02ce0ebd06._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ ip="193.219.12.33"
+ claimedauthor="Hardsoda"
+ subject="Explain"
+ date="2020-06-05T07:55:16Z"
+ content="""
+Hi! This is greate article :) But I missing explainetion of this probes:
+
+probe_icmp_duration_seconds{phase=\"resolve\"}
+probe_icmp_duration_seconds{phase=\"rtt\"}
+probe_icmp_duration_seconds{phase=\"setup\"}
+"""]]

add more fuzzing to graphs
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
index a5f6b735..e3bab9d0 100644
--- a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -215,13 +215,22 @@ So yes, we're missing pretty "fuzz" lines around the main lines, but
 maybe that's alright. It *would* be possible to do the equivalent to
 the InfluxDB hack, with queries like:
 
-    min_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[1m])
-    avg_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[1m])
-    max_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[1m])
+    min_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[30s])
+    avg_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[5m])
+    max_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[30s])
 
-... and setup the "fill lines" but that's not really the way things
-work in Prometheus/Grafana land. I'm actually satisfied with the
-current result.
+The output looks something like this:
+
+<figure>
+<img src="snap-20200604T222103.png" alt="A plot of RTT and packet loss over time of three nodes, with minimax" />
+<figcaption>Looks more like Smokeping!</figcaption>
+</figure>
+
+But there's a problem there: see how the middle graph "dips" sometimes
+below 20ms? That's the `min_over_time` function (incorrectly, IMHO)
+returning zero. I haven't quite figured out how to fix that, and I'm
+not sure it is better. But it does look more like Smokeping than the
+previous graph.
 
 Update: I forgot to mention one big thing that this setup is
 missing. Smokeping has this nice feature that you can order and group
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus/snap-20200604T222103.png b/blog/2020-06-04-replacing-smokeping-prometheus/snap-20200604T222103.png
new file mode 100644
index 00000000..2e5627aa
Binary files /dev/null and b/blog/2020-06-04-replacing-smokeping-prometheus/snap-20200604T222103.png differ

another feature missing from my setup
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
index 467bd93b..a5f6b735 100644
--- a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -223,6 +223,14 @@ the InfluxDB hack, with queries like:
 work in Prometheus/Grafana land. I'm actually satisfied with the
 current result.
 
+Update: I forgot to mention one big thing that this setup is
+missing. Smokeping has this nice feature that you can order and group
+probe targets in a "folder"-like hierarchy. It is often used to group
+probes by location, which makes it easier to scan a lot of
+targets. This is harder to do in this setup. It might be possible to
+setup location-specific "jobs" and select based on that, but it's not
+exactly the same.
+
 Credits
 =======
 

update screenshot
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
index 88bf0827..467bd93b 100644
--- a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -127,8 +127,8 @@ missing something. Here's what I did.
 The result looks something like this:
 
 <figure> 
-<img src="snap-20200604T111507.png" alt="A plot of RTT and packet loss over time of three nodes" />
-<figcaption>Not bad, but definitely not Smokeping</figcaption>
+<img src="snap-20200604T121030.png" alt="A plot of RTT and packet loss over time of three nodes" />
+<figcaption>Not bad, but not Smokeping</figcaption>
 </figure>
 
 This actually looks pretty good!
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus/snap-20200604T111507.png b/blog/2020-06-04-replacing-smokeping-prometheus/snap-20200604T111507.png
deleted file mode 100644
index e63c71e0..00000000
Binary files a/blog/2020-06-04-replacing-smokeping-prometheus/snap-20200604T111507.png and /dev/null differ
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus/snap-20200604T121030.png b/blog/2020-06-04-replacing-smokeping-prometheus/snap-20200604T121030.png
new file mode 100644
index 00000000..0e58b3cb
Binary files /dev/null and b/blog/2020-06-04-replacing-smokeping-prometheus/snap-20200604T121030.png differ

clarify conclusion
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
index 97fc5a7f..88bf0827 100644
--- a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -219,8 +219,9 @@ the InfluxDB hack, with queries like:
     avg_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[1m])
     max_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[1m])
 
-... and setup the "fill bits" but that's not really the way things
-work in Prometheus/Grafana land.
+... and setup the "fill lines" but that's not really the way things
+work in Prometheus/Grafana land. I'm actually satisfied with the
+current result.
 
 Credits
 =======

add toc
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
index d6282bca..97fc5a7f 100644
--- a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -14,6 +14,8 @@ from Munin](https://help.torproject.org/tsa/howto/prometheus/#Migrating_from_Mun
 Nagios is much harder, and I still haven't quite [figured out if it's
 worth it](https://trac.torproject.org/projects/tor/ticket/29864).
 
+[[!toc]]
+
 How does Smokeping work
 =======================
 

tag for debian-planet
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
index 9010f363..d6282bca 100644
--- a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -225,3 +225,5 @@ Credits
 
 Credits to [Chris Siebenmann](https://utcc.utoronto.ca/~cks/) for his [article about Prometheus and
 pings](https://utcc.utoronto.ca/~cks/space/blog/sysadmin/PrometheusAmountCheckDown) which gave me the `avg_over_time` query idea.
+
+[[!tag debian-planet python-planet prometheus sysadmin]]

prometheus smokeping replacement
diff --git a/blog/2020-06-04-replacing-smokeping-prometheus.mdwn b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
new file mode 100644
index 00000000..9010f363
--- /dev/null
+++ b/blog/2020-06-04-replacing-smokeping-prometheus.mdwn
@@ -0,0 +1,227 @@
+[[!meta title="Replacing Smokeping with Prometheus"]]
+
+I've been struggling with replacing parts of my old sysadmin
+monitoring toolkit (previously built with Nagios, Munin and Smokeping)
+with more modern tools (specifically Prometheus, its "exporters" and
+Grafana) for a while now.
+
+Replacing Munin with Prometheus and Grafana is fairly straightforward:
+the network architecture ("server pulls metrics from all nodes") is
+similar and there are lots of exporters. They are a little harder to
+write than Munin modules, but that makes them more flexible and
+efficient, which was a huge problem in Munin. I wrote a [Migrating
+from Munin](https://help.torproject.org/tsa/howto/prometheus/#Migrating_from_Munin) guide that summarizes those differences. Replacing
+Nagios is much harder, and I still haven't quite [figured out if it's
+worth it](https://trac.torproject.org/projects/tor/ticket/29864).
+
+How does Smokeping work
+=======================
+
+Leaving those two aside for now, I'm left with Smokeping, which I used
+in my previous job to diagnose routing issues, using Smokeping as a
+decentralized looking glass, which was handy to debug long term
+issues. Smokeping is a strange animal: it's fundamentally similar to
+Munin, except it's harder to write plugins for it, so most people just
+use it for Ping, something for which it excels at.
+
+Its trick is this: instead of doing a single ping and returning this
+metrics, it does *multiple* ones and returns *multiple*
+metrics. Specifically, smokeping will send multiple ICMP packets (20
+by default), with a low interval (500ms by default) and a single
+retry. It also pings *multiple* hosts at once which means it can
+quickly scan multiple hosts simultaneously. You therefore see network
+conditions affecting one host reflected in further hosts down (or up)
+the chain. The *multiple* metrics also mean you can draw graphs with
+"error bars" which Smokeping shows as "smoke" (hence the name). You
+also get per-metric packet loss.
+
+Basically, smokeping runs this command and collects the output in a
+RRD database:
+
+    fping -c $count -q -b $backoff -r $retry -4 -b $packetsize -t $timeout -i $mininterval -p $hostinterval $host [ $host ...]
+
+... where those parameters are, by default:
+
+ * `$count` is 20 (packets)
+ * `$backoff` is 1 (avoid exponential backoff)
+ * `$timeout` is 1.5s
+ * `$mininterval` is 0.01s (minimum wait interval between any target)
+ * `$hostinterval` is 1.5s (minimum wait between probes on a single target)
+
+It can also override stuff like the source address and TOS
+fields. This probe will complete between 30 and 60 seconds, if my math
+is right (0% and 100% packet loss).
+
+How do draw Smokeping graphs in Grafana
+=======================================
+
+A naive implementation of Smokeping in Prometheus/Grafana would be to
+use the blackbox exporter and create a dashboard displaying those
+metrics. I've done this at home, and then I realized that I was
+missing something. Here's what I did.
+
+ 1. install the blackbox exporter:
+ 
+        apt install prometheus-blackbox-exporter
+
+ 2. make sure to allow capabilities so it can ping:
+ 
+        dpkg-reconfigure prometheus-blackbox-exporter
+
+ 3. hook monitoring targets into `prometheus.yml` (the default blackbox
+    exporter configuration is fine):
+
+        scrape_configs:
+          - job_name: blackbox
+              metrics_path: /probe
+              params:
+                module: [icmp]
+              scrape_interval: 5s
+              static_configs:
+                - targets:
+                  - octavia.anarc.at
+                  # hardcoded in DNS
+                  - nexthop.anarc.at
+                  - koumbit.net
+                  - dns.google
+              relabel_configs:
+                - source_labels: [__address__]
+                  target_label: __param_target
+                - source_labels: [__param_target]
+                  target_label: instance
+                - target_label: __address__
+                  replacement: 127.0.0.1:9115  # The blackbox exporter's real hostname:port.
+
+    Notice how we lower the `scrape_interval` to 5 seconds to get more
+    samples. `nexthop.anarc.at` was added into DNS to avoid hardcoding
+    my upstream ISP's IP in my configuration.
+
+ 4. create a Grafana panel to graph the results. first, add this
+    query:
+    
+        sum(probe_icmp_duration_seconds{phase="rtt"}) by (instance)
+    
+    * Set the `Legend` field to `{{instance}} RTT`
+    * Set `Draw modes` to `lines` and `Mode options` to `staircase`
+    * Set the `Left Y` axis `Unit` to `duration(s)`
+    * Show the `Legend` `As table`, with `Min`, `Avg`, `Max` and
+      `Current` enabled
+
+    Then add this query, for packet loss:
+    
+        1-avg_over_time(probe_success[$__interval])!=0 or null
+
+    * Set the `Legend` field to `{{instance}} packet loss`
+    * Set a `Add series override` to `Lines: false`, `Null point mode:
+      null`, `Points: true`, `Points Radios: 1`, `Color: deep red`,
+      and, most importantly, `Y-axis: 2`
+    * Set the `Right Y` axis `Unit` to `percent (0.0-1.0)` and set
+      `Y-max` to 1
+
+    Then set the entire thing to `Repeat`, on `target`,
+    `vertically`. And you need to add a `target` variable like
+    `label_values(probe_success, instance)`.
+
+The result looks something like this:
+
+<figure> 
+<img src="snap-20200604T111507.png" alt="A plot of RTT and packet loss over time of three nodes" />
+<figcaption>Not bad, but definitely not Smokeping</figcaption>
+</figure>
+
+This actually looks pretty good!
+
+I've uploaded the resulting dashboard in the [Grafana dashboard
+repository](https://grafana.com/grafana/dashboards/12412).
+
+What is missing?
+================
+
+Now, that doesn't exactly look like Smokeping, does it. It's pretty
+good, but it's not quite what we want. What is missing is *variance*,
+the "smoke" in Smokeping.
+
+There's a [good article about replacing Smokeping with
+Grafana](https://hveem.no/visualizing-latency-variance-with-grafana). They wrote a custom script to write samples into InfluxDB
+so unfortunately we can't use it in this case, since we don't have
+InfluxDB's query language. I couldn't quite figure out how to do the
+same in PromQL. I tried:
+
+    stddev(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"})
+    stddev_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[$__interval])
+    stddev_over_time(probe_icmp_duration_seconds{phase="rtt",instance=~"$instance"}[1m])
+
+The first two give zero for all samples. The latter works, but doesn't
+looks as good as Smokeping. So there might be something I'm missing.
+
+[SuperQ](https://github.com/SuperQ) wrote a [special exporter for this called
+smokeping_prober](https://github.com/SuperQ/smokeping_prober/) that came out of [this discussion in the blackbox
+exporter](https://github.com/prometheus/blackbox_exporter/issues/115). Instead of delegating scheduling and target definition
+to Prometheus, the targets are set in the exporter.
+
+They also take a different approach than Smokeping: instead of
+recording the individual variations, they delegate that to Prometheus,
+through the use of "buckets". Then they use a query like this:
+
+    histogram_quantile(0.9 rate(smokeping_response_duration_seconds_bucket[$__interval]))
+
+This is the rationale to SuperQ's implementation:
+
+> Yes, I know about smokeping's bursts of pings. IMO, smokeping's data
+> model is flawed that way. This is where I intentionally deviated
+> from the smokeping exact way of doing things. This prober sends a
+> smooth, regular series of packets in order to be measuring at
+> regular controlled intervals.
+> 
+> Instead of 20 packets, over 10 seconds, every minute. You send one
+> packet per second and scrape every 15. This has the same overall
+> effect, but the measurement is, IMO, more accurate, as it's a
+> continuous stream. There's no 50 second gap of no metrics about the
+> ICMP stream.
+> 
+> Also, you don't get back one metric for those 20 packets, you get
+> several. Min, Max, Avg, StdDev. With the histogram data, you can
+> calculate much more than just that using the raw data.
+> 
+> For example, IMO, avg and max are not all that useful for continuous
+> stream monitoring. What I really want to know is the 90th percentile
+> or 99th percentile.
+> 
+> This smokeping prober is not intended to be a one-to-one replacement
+> for exactly smokeping's real implementation. But simply provide
+> similar functionality, using the power of Prometheus and PromQL to
+> make it better.
+>

(fichier de différences tronqué)
Added a comment
diff --git a/blog/2020-05-28-isp-upgrade/comment_2_0268518e78b93314146e535ba4c0baa1._comment b/blog/2020-05-28-isp-upgrade/comment_2_0268518e78b93314146e535ba4c0baa1._comment
new file mode 100644
index 00000000..285f7720
--- /dev/null
+++ b/blog/2020-05-28-isp-upgrade/comment_2_0268518e78b93314146e535ba4c0baa1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="https://seccdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="comment 2"
+ date="2020-06-02T20:23:38Z"
+ content="""
+> Other than the speed being lower than what you want and the IPv6 being iffy, does TSI satisfy your other requirements?
+
+It does, mostly. I'm looking for something cheaper / faster.
+
+One problem I have with TSI is they are not local. I come out from somewhere in Ontario, both in geolocation but also (more critically) in terms of latency. So that's inconvenient for local voice conferencing, where you want latency to an absolute minimum. 
+
+DSL also adds quite a lot more latency than cable, so the latter is kind of becoming a must. And unfortunately, there, TSI has the same problems as Ebox, last I checked (that is, services are blocked).
+"""]]

a nice package in emacs to tell me which key is on which command
diff --git a/software/packages.yml b/software/packages.yml
index d5f17209..c8beb4f4 100644
--- a/software/packages.yml
+++ b/software/packages.yml
@@ -255,6 +255,7 @@
       - elpa-solarized-theme
       - elpa-use-package
       - elpa-web-mode
+      - elpa-which-key
       - elpa-writegood-mode
       - elpa-yaml-mode
       - elpa-yasnippet

approve comment
diff --git a/blog/2020-05-28-isp-upgrade/comment_1_f2a8b591f8b87403f04aeefbe5600c9e._comment b/blog/2020-05-28-isp-upgrade/comment_1_f2a8b591f8b87403f04aeefbe5600c9e._comment
new file mode 100644
index 00000000..77f95bba
--- /dev/null
+++ b/blog/2020-05-28-isp-upgrade/comment_1_f2a8b591f8b87403f04aeefbe5600c9e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ ip="96.23.12.217"
+ claimedauthor="mgregoire"
+ subject="comment 1"
+ date="2020-05-28T18:55:17Z"
+ content="""
+Other than the speed being lower than what you want and the IPv6 being iffy, does TSI satisfy your other requirements?
+
+I live on the South Shore, and haven't been very happy with either Vidéotron or Bell.  Teksavvy might be an improvement.
+"""]]

add delays
diff --git a/blog/2020-05-28-isp-upgrade.mdwn b/blog/2020-05-28-isp-upgrade.mdwn
index 5b1610f7..3f627977 100644
--- a/blog/2020-05-28-isp-upgrade.mdwn
+++ b/blog/2020-05-28-isp-upgrade.mdwn
@@ -94,6 +94,8 @@ residential services", even though they [seem to have that package on
 their website](https://www.teksavvy.com/services/internet/hardware/?itemID=4843&prov=QC). They confirmed that they "don't have a option more
 than 10 mbps upload."
 
+TSI were the first to respond, within 24h.
+
 Oricom
 ------
 
@@ -105,6 +107,10 @@ their IP address space.
 
 I can confirm that the IP is fairly static from the office.
 
+Oricom were the second to respond, within 24h, but required a phone
+call instead of an email exchange. Responded within 6 hours after
+leaving a voicemail.
+
 Ebox
 ----
 
@@ -122,6 +128,8 @@ service:
 No static IP addressing, shared dynamic space so no garantee on
 reputation. IPv6 only on DSL, so no high speed IPv6.
 
+Ebox took the longest to respond, about 48 hours.
+
 Beanfield / Openface
 ---------------------
 

ebox response
diff --git a/blog/2020-05-28-isp-upgrade.mdwn b/blog/2020-05-28-isp-upgrade.mdwn
index b51bf793..5b1610f7 100644
--- a/blog/2020-05-28-isp-upgrade.mdwn
+++ b/blog/2020-05-28-isp-upgrade.mdwn
@@ -108,7 +108,19 @@ I can confirm that the IP is fairly static from the office.
 Ebox
 ----
 
-No response yet.
+Ebox claims my neighborhood supports 400mbps down, but offered me a
+100/30 package with 350Go bandwidth per month for 54.95$/mth or
+unlimited for 65$/mth.
+
+Many ports are blocked, which makes it impossible for me to use their
+service:
+
+ * port 25 blocked incoming
+ * port 25 filtered outgoing (only allowed to their servers)
+ * port 53 blocked incoming (!)
+
+No static IP addressing, shared dynamic space so no garantee on
+reputation. IPv6 only on DSL, so no high speed IPv6.
 
 Beanfield / Openface
 ---------------------

clarifier les sections
diff --git a/services/dns.mdwn b/services/dns.mdwn
index 3853315f..27cab389 100644
--- a/services/dns.mdwn
+++ b/services/dns.mdwn
@@ -4,6 +4,8 @@ Le service de DNS n'est pas censuré d'aucune façon, mais donne des réponses d
 
 Il supporte [[IPv6]].
 
+[[!toc levels=2]]
+
 Problèmes connus
 ================
 
@@ -51,7 +53,13 @@ femmes. Exemples utilisés:
  * [[hardware/server/mafalda]] ([yes, the character](https://en.wikipedia.org/wiki/Mafalda))
  * [[hardware/server/plastik]] (a "piece of plastic")
 
-Utilisés par le passé:
+Anciens
+-------
+
+Ces noms ont été utilisés par le passé et ont été retiré de la
+circulation, généralement parce que les machines auxquelles ils ont
+été attitrés ont été retirés, mais aussi parce que les noms ne sont
+plus compatibles avec la nouvelle convention.
 
  * [[hardware/server/lenny]] - origin forgotten
  * marvin - origin forgotten
@@ -61,7 +69,10 @@ Utilisés par le passé:
  * roadkill
  * [[hardware/server/roadkiller]]
 
-Autres idées:
+Potentiels
+----------
+
+Les noms suivants pourraient être utilisés pour de futures machines:
 
  * [Hannah Arendt](https://en.wikipedia.org/wiki/Hannah_Arendt) - "one of the most important political
    philosophers of the twentieth century"

explain the picks
diff --git a/services/dns.mdwn b/services/dns.mdwn
index 2b1f5cb1..3853315f 100644
--- a/services/dns.mdwn
+++ b/services/dns.mdwn
@@ -63,14 +63,19 @@ Utilisés par le passé:
 
 Autres idées:
 
- * [Hannah Arendt](https://en.wikipedia.org/wiki/Hannah_Arendt) - although, how do you spell it?
- * [Viola Desmond](https://en.wikipedia.org/wiki/Viola_Desmond)
- * [Margaret Hamilton][]
- * [Ada Lovelace](https://en.wikipedia.org/wiki/Ada_Lovelace)
- * [Grace Hopper](https://en.wikipedia.org/wiki/Grace_Hopper)
- * [Fumiko Kaneko](https://en.wikipedia.org/wiki/Fumiko_Kaneko)
- * [Louise Michel](https://fr.wikipedia.org/wiki/Louise_Michel)
- * [Séverine](https://fr.wikipedia.org/wiki/S%C3%A9verine)
+ * [Hannah Arendt](https://en.wikipedia.org/wiki/Hannah_Arendt) - "one of the most important political
+   philosophers of the twentieth century"
+ * [Viola Desmond](https://en.wikipedia.org/wiki/Viola_Desmond) - challenged racial segregation in Canada
+ * [Margaret Hamilton][] - developed the on-board flight software for NASA's Apollo program
+ * [Ada Lovelace](https://en.wikipedia.org/wiki/Ada_Lovelace) - first programmer
+ * [Grace Hopper](https://en.wikipedia.org/wiki/Grace_Hopper) - inventor of the compiler and linker
+ * [Fumiko Kaneko](https://en.wikipedia.org/wiki/Fumiko_Kaneko) - Japanese feminist, anti-colonialist, anarchist
+   and nihilist, (possibly self-)convicted of plotting to assassinate
+   the Japanese emperor
+ * [Louise Michel](https://fr.wikipedia.org/wiki/Louise_Michel) - anarchiste de la commune de Paris, première à
+   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
 
 [Margaret Hamilton]: https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer)
 

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 .