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

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

mention the popcorn computer
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index 8deac924..f02e742e 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -56,6 +56,28 @@ https://www.indiegogo.com/projects/gemini-pda-android-linux-keyboard-mobile-devi
 > lugging a full laptop around with you, the keyboard is better than
 > using the on screen keyboard on the phone.
 
+Popcorn
+-------
+
+https://pocket.popcorncomputer.com/
+
+Cheaper than the Gemini (~200$), Lora instead of GSM.
+
+ * 1080p 4.95"
+ * shipped with Debian
+ * 4xUSB-C (1 power, 2 host, 1 serial)
+ * no headphone jack
+ * Wifi, Bluetooth
+ * LoRa
+ * GNSS (GPS)
+ * 3200mAh battery
+ * external microSD
+ * ARM 1.2GHz Cortex-A53
+ * 2GB ram
+ * 32GB eMMC
+ * Physical keyboard
+
+In pre-order, expected in 2020.
 
 Mnt reform
 ----------

JAA filed bugs
diff --git a/services/archive/web.mdwn b/services/archive/web.mdwn
index f7eefdb0..222b6ffa 100644
--- a/services/archive/web.mdwn
+++ b/services/archive/web.mdwn
@@ -269,8 +269,8 @@ mentioned above, some not.
 
  * [Autistici crawl][crawl]: a simple and fast WARC crawler
  * [crau](https://github.com/turicas/crau): scrapy-based crawler, writes but also list, extracts and
-   replays WARC files, might be missing [redirects](https://github.com/turicas/crau/issues/1) and transfer
-   encoding
+   replays WARC files, might be missing [redirects](https://github.com/turicas/crau/issues/1) and fails to
+   preserve [transfer encoding](https://github.com/turicas/crau/issues/15) and [headers](https://github.com/turicas/crau/issues/16)
  * [Heritrix](https://en.wikipedia.org/wiki/Heritrix) is the Internet Archive crawler (!)
  * [httrack][]: old but basic tool that works. no WARC support.
  * [wget][]: a classic HTTP multipurpose tool.

jvoisin made a blog
diff --git a/blog/2019-10-16-bus-factor/comment_4_9ee8aadb7abef9aabbc7075cffee2be6._comment b/blog/2019-10-16-bus-factor/comment_4_9ee8aadb7abef9aabbc7075cffee2be6._comment
new file mode 100644
index 00000000..f5b4afca
--- /dev/null
+++ b/blog/2019-10-16-bus-factor/comment_4_9ee8aadb7abef9aabbc7075cffee2be6._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""jvoisin's blog post"""
+ date="2019-11-13T18:35:29Z"
+ content="""
+jvoisin made an [interesting argument](https://dustri.org/b/on-reducing-the-bus-factor-school-rant-edition.html) in response to this post that education might be a key solution to this:
+
+ 1. Encourage people to students to existing projects instead of reinventing old algorithms that have been written a billion times already.
+ 2. Teach students how to collaborate on software projects, with version control systems, issue trackers, handle reviews, be nice on mailing lists.
+ 3. Encourage students to apply to GSOC and similar programs to code during the summer
+
+I'm not convinced *at all* by the last part: students should get high and travel during their holidays, not work on computers. But for everything else, good ideas!
+"""]]

link
diff --git a/services/archive/web.mdwn b/services/archive/web.mdwn
index 486276dc..f7eefdb0 100644
--- a/services/archive/web.mdwn
+++ b/services/archive/web.mdwn
@@ -269,7 +269,8 @@ mentioned above, some not.
 
  * [Autistici crawl][crawl]: a simple and fast WARC crawler
  * [crau](https://github.com/turicas/crau): scrapy-based crawler, writes but also list, extracts and
-   replays WARC files, missing redirects, transfer encoding
+   replays WARC files, might be missing [redirects](https://github.com/turicas/crau/issues/1) and transfer
+   encoding
  * [Heritrix](https://en.wikipedia.org/wiki/Heritrix) is the Internet Archive crawler (!)
  * [httrack][]: old but basic tool that works. no WARC support.
  * [wget][]: a classic HTTP multipurpose tool.

mention crau
diff --git a/services/archive/web.mdwn b/services/archive/web.mdwn
index a9ff7956..486276dc 100644
--- a/services/archive/web.mdwn
+++ b/services/archive/web.mdwn
@@ -268,6 +268,8 @@ Here are the various programs that can archive websites. Some were
 mentioned above, some not.
 
  * [Autistici crawl][crawl]: a simple and fast WARC crawler
+ * [crau](https://github.com/turicas/crau): scrapy-based crawler, writes but also list, extracts and
+   replays WARC files, missing redirects, transfer encoding
  * [Heritrix](https://en.wikipedia.org/wiki/Heritrix) is the Internet Archive crawler (!)
  * [httrack][]: old but basic tool that works. no WARC support.
  * [wget][]: a classic HTTP multipurpose tool.

link to impass
diff --git a/blog/2017-02-18-passwords-entropy.mdwn b/blog/2017-02-18-passwords-entropy.mdwn
index 8ef516ca..1a7b0ac6 100644
--- a/blog/2017-02-18-passwords-entropy.mdwn
+++ b/blog/2017-02-18-passwords-entropy.mdwn
@@ -287,7 +287,7 @@ printable/transferable string*". The priority, in this case, is to have a
 token that is as compact as possible with the given entropy, while at
 the same time using a character set that should cause as little trouble
 as possible on sites that restrict the characters you can use. Gillmor
-is a co-maintainer of the [Assword](https://finestructure.net/assword/)
+is a co-maintainer of the [Assword](https://finestructure.net/assword/) (now known as [impass](https://salsa.debian.org/debian/impass))
 password manager, which chose base64 because it is widely available and
 understood and only takes up 33% more space than the original 8-bit
 binary encoding. After a lengthy discussion, the pass maintainer, Jason

african proverb, from
https://urvikagola.wordpress.com/2019/11/03/grace-hopper-celebration19-orlando/
diff --git a/fortunes.txt b/fortunes.txt
index 3327bd9e..d9f6c890 100644
--- a/fortunes.txt
+++ b/fortunes.txt
@@ -1113,3 +1113,6 @@ Anarchy is not perfection, it is not the absolute ideal which like the
 horizon recedes as fast as we approach it; but it is the way open to
 all progress and all improvements for the benefit of everybody.
                         - Errico Malatesta
+%
+If you want to go fast, go alone. If you want to go far, go together.
+                        - African proverb

cross-ref the blog post and archive wiki page better
diff --git a/blog/2018-10-04-archiving-web-sites.mdwn b/blog/2018-10-04-archiving-web-sites.mdwn
index d9b4e40c..75b26a5d 100644
--- a/blog/2018-10-04-archiving-web-sites.mdwn
+++ b/blog/2018-10-04-archiving-web-sites.mdwn
@@ -275,7 +275,8 @@ itself][].
 >
 > Finally, this article was originally written as a set of notes and
 > documentation in the [[services/archive]] page which may also be of
-> interest to my readers.
+> interest to my readers. This blog post will not be updated in the
+> future while the latter wiki page might.
 
   [this archive of two Bloomberg articles]: https://archive.org/details/anarcat-bloomberg
   [webrecorder.io]: https://webrecorder.io/
diff --git a/services/archive/web.mdwn b/services/archive/web.mdwn
index cd0aefa2..a9ff7956 100644
--- a/services/archive/web.mdwn
+++ b/services/archive/web.mdwn
@@ -1,5 +1,10 @@
 [[!meta title="Website mirroring and archival"]]
 
+Update: I published a [article](/blog/2018-10-04-archiving-web-sites/) [on LWN](https://lwn.net/Articles/766374/) based on this
+documentation, which is a more "narrative" form. The article, however,
+will not be updated any further while those notes are a living
+document that might be updated again eventually.
+
 For various reasons, I've played with website mirroring and
 archival. Particularly at [Koumbit](https://koumbit.org), when a project is over or
 abandoned, we have tried to keep a static copy of active websites. The

notes about wasd latency
diff --git a/hardware/keyboard.mdwn b/hardware/keyboard.mdwn
index 1d2e0dc9..6b091e73 100644
--- a/hardware/keyboard.mdwn
+++ b/hardware/keyboard.mdwn
@@ -90,6 +90,10 @@ everything.
  * custom switches
  * no windows logo (customizable)
  * 145$, 185$ with o-rings and MX-clear
+ * latency around 14ms according to manufacturer:
+   > Debounce delay: after key press delay *12ms*
+   > Algorithm: Time base=1ms, Fixed time =4ms, continuous 3 times with same
+   > result, KEY state can be determined.
 
 Update:
 

new nice to have features
diff --git a/hardware/keyboard.mdwn b/hardware/keyboard.mdwn
index 850e90e8..1d2e0dc9 100644
--- a/hardware/keyboard.mdwn
+++ b/hardware/keyboard.mdwn
@@ -39,6 +39,33 @@ Tactile feel
 
 I liked the clikety feeling of the Model M, but not the sound. Ideally, it would have the same feeling, but less loud. The [MX brown](http://deskthority.net/wiki/Cherry_MX_Brown) seems to have that characteristic, but I am worried it will loose the clikety feeling. The [Cherry MX clear](http://deskthority.net/wiki/Cherry_MX_Clear) may be a good compromise.
 
+Nice to have
+============
+
+Low latency
+-----------
+
+As discussed in [[monitor]] and my [[terminal emulators
+review|blog/2018-05-04-terminal-emulators-2/#latency]], we have very
+little wiggle room for latency in the various I/O component of the
+computer. In theory, we can get sub 30ms latency in the entire chain,
+and keyboards take up almost half of that (14ms). So it would be nice
+to have keyboards with lower latency than this.
+
+Open firmware
+-------------
+
+We now live in a world where every device has its own little computer,
+a controller that parses the electric output of switches and turn that
+into a meaningful data stream, usually over USB, to the main
+computer. Most keyboards, in that sense, are proprietary, but there
+are nice efforts like the [TMK](https://github.com/tmk/tmk_keyboard) and [QMK](https://qmk.fm/) firmware projects that
+attempt to reverse-engineer and replace the existing firmwares.
+
+Having support for an open firmware would be a plus, and would
+possibly allow us to *reduce* the keyboard latency by changing or
+removing the debouncing algorithm.
+
 Keyboard models
 ===============
 

wtf
diff --git a/blog/2019-10-25-stay-away-from-fizz.mdwn b/blog/2019-10-25-stay-away-from-fizz.mdwn
index 97572036..68330824 100644
--- a/blog/2019-10-25-stay-away-from-fizz.mdwn
+++ b/blog/2019-10-25-stay-away-from-fizz.mdwn
@@ -61,4 +61,13 @@ Infos Fizz:
 
 https://www.opc.gouv.qc.ca/se-renseigner/liste-des-resultats-de-recherche/details/commercant/690616/
 
+> Update:
+
+> Le problème que vous rencontrez n’est pas de la responsabilité de
+> l’Office de la protection du consommateur. Nous vous suggérons de
+> visiter le [Portail des programmes et services de Services
+> Québec](http://www.gouv.qc.ca/portail/quebec/pgs/citoyens/?lang=fr), qui est le centre de renseignements du gouvernement du
+> Québec. Il diffuse de l’information sur les organismes et les
+> ministères du gouvernement provincial.
+
 [[!tag draft]]

keep getting crap from fizz
diff --git a/blog/2019-10-25-stay-away-from-fizz.mdwn b/blog/2019-10-25-stay-away-from-fizz.mdwn
new file mode 100644
index 00000000..97572036
--- /dev/null
+++ b/blog/2019-10-25-stay-away-from-fizz.mdwn
@@ -0,0 +1,64 @@
+Still need to put this into shape, but I sent this complaint to
+[Office de Protection du Consommateur](https://www.opc.gouv.qc.ca/consommateur/probleme-commercant/etapes/).
+
+J'ai fait affaire avec Fizz pendant quelques mois au début de
+l'année. Quand j'ai tenté de transférer mon numéro de téléphone actuel
+vers Fizz.ca, la procédure a échoué sur leur site web. J'ai tenté de
+rejoindre le support technique, mais ils n'offrent pas de support par
+téléphone et semble cacher délibérément leur adresse postale. Ils
+prétendent avoir un support de "chat" sur leur site web mais il n'a
+jamais fonctionné.
+
+https://twitter.com/theanarcat/status/1115329821163311110
+
+(looking at plans.. https://twitter.com/theanarcat/status/1116406902085255168)
+
+J'ai fini par les rejoindre par Twitter (!), après 2 semaines de
+silence:
+
+https://twitter.com/theanarcat/status/1117549912982532096
+
+Leur support technique était pratiquement incompétent et prétendaient
+qu'il était impossible de "porter" le numéro de téléphone, ce qui
+était faux. Deux semaines plus tard, Fido.ca m'offrait le service et
+je changeait de fournisseur:
+
+https://twitter.com/theanarcat/status/1121120509297606656
+
+... et je fermais mon compte Fizz.
+
+Première plainte: mauvais support technique. Mais l'histoire ne
+s'arrête pas ici! Fizz n'a jamais effacé mes données personnelles de
+son serveur et continue allégrement à m'envoyer du spam, exemple en
+Août:
+
+https://twitter.com/theanarcat/status/1158384226942771200
+
+Après quelques conversations privées sur Twitter (par "DM"), ils ont
+reconnu qu'il y avait un problème de leur côté et m'ont promis de le
+régler. Mais deux semaines plus tard, je recevait un autre courriel de
+leur part.
+
+Et aujourd'hui, je reçois un courriel qui m'avise qu'ils refusent
+simplement de me retirer de leur liste d'envoi:
+
+https://twitter.com/theanarcat/status/1187801950852734976
+
+Je considère que ceci est un bris de confiance du lien client /
+fournisseur. Je ne suis plus client de cette entreprise et considère
+qu'elle devrait détruire toute donnée personnelle qu'elle détient à
+mon égard.
+
+À tout le moins, il me semble y avoir des lois au Canada interdisant
+l'envoi de courriels non-sollicités:
+
+https://www2.deloitte.com/ca/en/pages/risk/articles/canada-anti-spam-law-casl-faq.html
+
+Donc, plaine #2: Fizz m'envoie du "spam" même si je ne suis plus
+client.
+
+Infos Fizz:
+
+https://www.opc.gouv.qc.ca/se-renseigner/liste-des-resultats-de-recherche/details/commercant/690616/
+
+[[!tag draft]]

yaay dark mode!
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index c026869e..fdd45063 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -278,6 +278,8 @@ I have set the following configuration options:
    readable and trigger the vertical dropdown earlier
  * `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)
  * `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)

more bugs
diff --git a/services/upgrades/buster.mdwn b/services/upgrades/buster.mdwn
index be8d9706..74c9e48a 100644
--- a/services/upgrades/buster.mdwn
+++ b/services/upgrades/buster.mdwn
@@ -393,6 +393,79 @@ kernel bug][], still open.
 [this commit]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e839ffab028981ac77f650faf8c84f16e1719738
 [two-finger scrolling bug in Ubuntu]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1722478
 
+### Antidote 9 failures
+
+[Antidote][] is a powerful spell-and-grammar-checking that's popular
+in the french-speaking community because it's incredibly powerful,
+probably unrivaled in free software.
+
+The upgrade from stretch to buster broke it completely: it wouldn't
+start at all and the buttons wouldn't work in Libreoffice. Upgrading
+from the 9v5.1 to the 9v5.3 Antidote release fixed its startup: now
+the standalone version runs, but not the Libreoffice plugin, even
+after reinstalling that.
+
+Of course, that's proprietary software which I don't support out of
+the box, but I gotta help our users... We've opened a ticket upstream,
+and they said that Debian is unsupported and they suggest upgrading to
+Antidote 10 (which costs money). They also explicitely say they don't
+provide refunds if the upgrade doesn't fail.
+
+They also provide steps to debug the problem and a way to give them
+more information. So we'll see how that flies. The way that works is
+they make you download a file called [DruideInfos.bash.tar.gz][] and,
+yes, that's a bash script in a tar archive. They tell you to
+"uncompress it on the desktop and run it", presumably a user-friendly
+version of `curl | bash`, although my friend had no idea how to
+actually do that. Not sure I like the idea of telling people to run a
+50KB bash script, but at a cursory glance, the script looked more or
+less okay. Even though it does send a lot of private information to
+Druide, they warn about that profusely and it's in the context of the
+user asking for help, so it kind of makes sense. Still, there are a
+few things wrong with the way they're doing this:
+
+ 1. the link is HTTP, in plain text
+
+ 2. it's a huge bash script, for crying out loud, can't antidote ship
+    a self-diagnostic tool in itself instead of telling people to
+    download random stuff over the internet?
+
+ 3. minor: you don't need tar to compress a single file, `gzip`
+    suffices
+
+ 4. probably minor: the username of the staff that created the script
+    leaks in the gzip archive
+
+ 5. the insides of the scripts are of course absolutely
+    horrendous. just to give an example, they write a JSON parser in
+    an inline Python script, written with variables in french, for
+    good measure (spotted by sdk)
+
+Now we're waiting for a response from their tech support.
+
+[DruideInfos.bash.tar.gz]: http://telechargement.druide.com/telecharger/Linux/DruideInfos.bash.tar.gz
+
+### No sleep
+
+The user noticed the laptop doesn't go to sleep when the lid is
+closed. Technically, the bug report is "big power draw even if lid is
+closed", which I concluded was related to suspend not working in some
+situation. I suspect the problem might simply be that suspend doesn't
+trigger if the lid is closed *before* the power cable is
+unplugged.
+
+This might or might not be a regression, unclear.
+
+### Disk problems (unrelated to upgrade)
+
+Unrelated to the upgrade, but I have to write this down *somewhere*:
+that laptop is also showing alarming disk errors when booting, since
+the HDD was replaced with a Samsung 860 SSD. 
+
+When chatting with Samsung support, they suggested checking if the
+disk is well-seated, which we still have to try.
+
+[Antidote]: https://www.antidote.info/
 Resolved
 --------
 

Added a comment: yeah, but...
diff --git a/blog/2019-10-16-bus-factor/comment_3_32a612751faf3d24226fde7f44cd65ac._comment b/blog/2019-10-16-bus-factor/comment_3_32a612751faf3d24226fde7f44cd65ac._comment
new file mode 100644
index 00000000..3c98b824
--- /dev/null
+++ b/blog/2019-10-16-bus-factor/comment_3_32a612751faf3d24226fde7f44cd65ac._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ ip="62.216.209.225"
+ claimedauthor="simeon"
+ subject="yeah, but..."
+ date="2019-10-22T20:22:43Z"
+ content="""
+> Lobby governments and research institutions to sponsor only free software projects. Otherwise this civilization will collapse in a crash of spaghetti code before it even has time to get flooded over.
+
+This is the best conclusion I've ever read. I fully second that.
+
+Many projects rely on 1 person. Some get even to a state that could be considered as complete, maybe even with the support of contributors.
+
+Open-End-Projects for critical infrastructure with few or no alternatives, such as libinput, openssl won't stop even when the bus hit. Redhat, MS, Alphabet or newly created (non-)profits will take care (see libreoffice). If not, after a time with painful gap, something new will be born when the need is there. Worst, the \"terminal care Apache Foundation\" will bury it half-alive.
+
+I don't want to down-play busfactor 1. The stress must be enormous. More helpers and co-maintainers would really be helpful. However some projects would not have such massive improvements without a single person having a goal and vision.
+"""]]

mention the new password generator i use
diff --git a/blog/2017-02-18-passwords-entropy.mdwn b/blog/2017-02-18-passwords-entropy.mdwn
index 62d59118..8ef516ca 100644
--- a/blog/2017-02-18-passwords-entropy.mdwn
+++ b/blog/2017-02-18-passwords-entropy.mdwn
@@ -317,6 +317,29 @@ routines to generate tokens, but the procedure is the same: read from
 the kernel's entropy source (and user-generated sources in case of
 KeePass) and transform that data into a transferable string.
 
+Update: I have changed my above function slightly to pick a number of
+characters instead of the password entropy. You rarely need the
+former: most of the time, you want a specific password length and the
+underlying entropy is implicit. This is the new function I use:
+
+    pwg() {
+        CHARS=${1:-28} # in characters
+        #
+        # extract random alphanumeric characters. not '[:alnum:]' because
+        # that doesn't work with busybox.
+        #
+        # this uses urandom because it discards a significant ratio of the
+        # incoming entropy (keeps only 56/256 = 7/32 bytes on average) and
+        # would otherwise quickly deplete the entropy pool. this is safe
+        # because of:
+        #
+        # https://www.2uo.de/myths-about-urandom
+        #
+        # WARNING: do not use this early in the boot process with an
+        # uninitialized PRNG.
+        tr -dc 'A-Za-z0-9' < /dev/urandom | head -c $CHARS
+    }
+
 ## Conclusion
 
 While there are many aspects to password management, we have focused on

make possible alternatives section
diff --git a/services/bookmarks.mdwn b/services/bookmarks.mdwn
index 45e569bb..76fd2641 100644
--- a/services/bookmarks.mdwn
+++ b/services/bookmarks.mdwn
@@ -41,7 +41,12 @@ The [Zotero dataserver][] was also too difficult to setup, and without a Debian
 
 Finally, Zotero is in an uncertain state because of the
 [[software/desktop/firefox]] XULocalypse, so I'm looking for
-replacements. Possible options include:
+replacements.
+
+Possible alternatives
+=====================
+
+Possible alternatives to zotero and/or wallabag include:
 
  * [xapers](https://finestructure.net/xapers/)
  * [pubs](https://github.com/pubs/pubs)
@@ -51,7 +56,7 @@ This also overlaps with bookmarking software like:
 
  * [Turtl](https://turtlapp.com/)
  * [reminiscense](https://github.com/kanishka-linux/reminiscence)
- * [bookmark-archiver](https://pirate.github.io/bookmark-archiver/)
+ * [archivebox](https://archivebox.io/) (previously called [bookmark-archiver](https://pirate.github.io/bookmark-archiver/))
  * [Wallabag](https://wallabag.org/)
  * [Buku](https://github.com/jarun/Buku)
  * [Shiori](https://github.com/RadhiFadlillah/shiori)

yet another bookmarking service
diff --git a/services/bookmarks.mdwn b/services/bookmarks.mdwn
index 486c86dd..45e569bb 100644
--- a/services/bookmarks.mdwn
+++ b/services/bookmarks.mdwn
@@ -55,6 +55,7 @@ This also overlaps with bookmarking software like:
  * [Wallabag](https://wallabag.org/)
  * [Buku](https://github.com/jarun/Buku)
  * [Shiori](https://github.com/RadhiFadlillah/shiori)
+ * [memex](https://worldbrain.io/)
 
 ... and archival software in the [[WARC ecosystem|services/archive]].
 

bad macchiatobin review
diff --git a/hardware/server/marcos.mdwn b/hardware/server/marcos.mdwn
index fe6fc247..d32a0a8b 100644
--- a/hardware/server/marcos.mdwn
+++ b/hardware/server/marcos.mdwn
@@ -220,7 +220,9 @@ requirements (8+GB):
 The [Macchiatobin](https://macchiatobin.net/product/macchiatobin-single-shot/) is interesting because it has a DDR4 socket so
 it supports up to 16GB of ram, but has features I don't need for a
 home server, like three SFP 10Gig-E ports... Could still be
-interesting for a SAN if I ever upgrade the network to 10G. 269$-369$.
+interesting for a SAN if I ever upgrade the network to
+10G. 269$-369$. That said, someone on IRC had a very bad experience
+with it: the capacitors were broken and they refused to take it back.
 
 The [Beelink](http://www.bee-link.com/Beelink-MiniPC-TV-BOX-65-1.html) is also interesting: Intel N3450 4GB DDR, 64GB SSD.
 

fix markdown links
for some reason, references don't mix well with `code` blocks,
although inline works. go figure.
diff --git a/services/mail.mdwn b/services/mail.mdwn
index eb68f3d7..c9b8e4e4 100644
--- a/services/mail.mdwn
+++ b/services/mail.mdwn
@@ -291,14 +291,11 @@ fallback, in `main.cf`:
     smtpd_tls_security_level = may
     smtp_tls_security_level = may
 
-See the [`TLS_README`][] and [`smtp_tls_security_level`][] for more
+See the [`TLS_README`](http://www.postfix.org/TLS_README.html) and [`smtp_tls_security_level`](http://www.postfix.org/postconf.5.html#smtp_tls_security_level) for more
 information.
 
-[`smtp_tls_security_level`]: http://www.postfix.org/postconf.5.html#smtp_tls_security_level
-[`TLS_README`]: http://www.postfix.org/TLS_README.html
-
-This patch is required to disable TLS when a [`content_filter`][] is
-configured (see [`FILTER_README`][] and below).
+This patch is required to disable TLS when a [`content_filter`](http://www.postfix.org/postconf.5.html#content_filter) is
+configured (see [`FILTER_README`](http://www.postfix.org/FILTER_README.html) and below).
 
     diff --git a/postfix/master.cf b/postfix/master.cf
     index b0ed875..6329c70 100644
@@ -315,8 +312,6 @@ configured (see [`FILTER_README`][] and below).
              -o myhostname=delivery.anarc.at
      submission inet n       -       -       -       -       smtpd
 
-[`FILTER_README`]: http://www.postfix.org/FILTER_README.html
-[`content_filter`]: http://www.postfix.org/postconf.5.html#content_filter
 Without this patch, local delivery would hang during my tests.
 
 MTA-STS
@@ -453,11 +448,8 @@ address.
                                     reject_rbl_client zen.spamhaus.org
 
 
-In other words, make sure that [`permit_sasl_authenticated`][] is
-added to [`smtpd_recipient_restrictions`][].
-
-[`smtpd_recipient_restrictions`]: http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions
-[`permit_sasl_authenticated`]: http://www.postfix.org/postconf.5.html#permit_sasl_authenticated
+In other words, make sure that [`permit_sasl_authenticated`](http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions) is
+added to [`smtpd_recipient_restrictions`](http://www.postfix.org/postconf.5.html#permit_sasl_authenticated).
 
 Then you need to hook Dovecot SASL authentication into Postfix and
 make sure it is not offered in cleartext:
@@ -616,7 +608,7 @@ References
 ----------
 
  * Koumbit [PostfixConfiguration](https://wiki.koumbit.net/PostfixConfiguration#Postfix_client_SASL_configuration)
- * [`TLS_README`][]
+ * [`TLS_README`](http://www.postfix.org/TLS_README.html)
  * [`SASL_README`](http://www.postfix.org/SASL_README.html)
 
 Delievery and retrieval over SSH

more background on Onyx
diff --git a/hardware/tablet.mdwn b/hardware/tablet.mdwn
index 0acf454c..baf75e58 100644
--- a/hardware/tablet.mdwn
+++ b/hardware/tablet.mdwn
@@ -88,6 +88,16 @@ Otherwise similar to the Glo HD. Retail price around 180$CAD.
 Onyx
 ----
 
+[Onyx][] make all sorts of (e-ink) tablets, from big to small, mostly running
+Android. They [publish some of their source on GitHub][], mostly as a
+"GPL-compliant dump mode", but it's still better than nothing. The
+also have a neat [community forum][]. They are based in China so
+products will ship from there.
+
+[Onyx]: https://en.wikipedia.org/wiki/Onyx_Boox
+[community forum]: http://bbs.onyx-international.com/
+[publish some of their source on GitHub]: https://github.com/onyx-intl/
+
 ### Onyx Boox Max 2
 
 The [Onyx Boox Max 2](https://onyxboox.com/boox_max2) is an awesome creature:

thanks, and response
diff --git a/blog/2019-10-16-bus-factor/comment_2_2391621f66a0297cde17d07316684693._comment b/blog/2019-10-16-bus-factor/comment_2_2391621f66a0297cde17d07316684693._comment
new file mode 100644
index 00000000..57362d77
--- /dev/null
+++ b/blog/2019-10-16-bus-factor/comment_2_2391621f66a0297cde17d07316684693._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""comment 2"""
+ date="2019-10-17T23:22:00Z"
+ content="""
+Excellent comment and insight, thank you so much for this.
+
+I would only one thing, and it's a thing that someone else mentioned on IRC: they said the problem also exists in their corporate job. And indeed, I feel that, in my corporate experience, there's also strong specialization and the bus factor must be near one.
+
+The difference there is that there are resources (ie. money) to hire and train people when trouble comes...
+"""]]

Added a comment: Audition culture, exploitation, and the failure of "the market"
diff --git a/blog/2019-10-16-bus-factor/comment_1_8e2bfe6b686106ab3ac95eebec23011a._comment b/blog/2019-10-16-bus-factor/comment_1_8e2bfe6b686106ab3ac95eebec23011a._comment
new file mode 100644
index 00000000..2113b268
--- /dev/null
+++ b/blog/2019-10-16-bus-factor/comment_1_8e2bfe6b686106ab3ac95eebec23011a._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ ip="37.191.180.161"
+ claimedauthor="Paul Boddie"
+ subject="Audition culture, exploitation, and the failure of &quot;the market&quot;"
+ date="2019-10-17T21:31:11Z"
+ content="""
+There's an [interesting comment](https://lwn.net/Articles/801951/) on that LWN article that sums up a lot of the problem here: it is easier for \"open source companies\" to string people along, question people's commitment or expertise, and to have them constantly auditioning for work that they will never be hired to do. And yet, such practices are almost celebrated in certain \"open source\" communities.
+
+What does that have to do with single-developer projects, you might ask? Well, sometimes these projects come about by people following their own intellectual curiosity and sharing the results with others; sometimes these people buy into the folklore about \"scratching itches\"; but often such things are also done so that people can demonstrate competence and to indicate a strong interest in a particular technological domain.
+
+Having code to show can be a very useful thing when trying to further your career, get hired, and so on, provided that the entity doing the hiring can be bothered to take a look at it. But the world being what it is, it can also help to have connections: people who can profess familiarity with you, your work, your collaborative skills, and so on. Unfortunately, unless those people recognise the value of your project, you'll ultimately have to go and work on their projects instead.
+
+(It can happen that people stumble across independent projects and wish to contribute or improve them, and this has even happened with some of mine. It can also happen that people working for large companies are only interested if you change the licence to something permissive so that they can freeload.)
+
+Since another popular \"open source culture\" pastime involves playing the zero-sum game and trying to get other people to abandon their projects and to contribute to yours (recalling a conference where someone practically went round talks telling speakers to contribute to different projects in that person's own portfolio), it is likely that you will end up either sticking it out in the hope that your own projects remain viable or just going with the flow.
+
+Going with the flow means working on something potentially less rewarding than your own projects in the hope that the outcome will generally be more positive. But it risks being like work without actually getting paid for it. People may prefer to just accept that their own projects are regarded as hobbies by everyone else, but at least they might still enjoy them.
+
+Which leads us back to that commenter. It certainly seems that companies promote contribution to their projects as a way of getting hired: if you do enough interning or auditioning, eventually they might reward you with a position. In communications I have had, such things have been implied, suggested or even actually stated: keep up with your efforts and maybe there is an opportunity to be had.
+
+You don't have to be a prize-winning economist to realise that with enough people wanting to get ahead, there is little incentive for that reward to be granted. The eager brushing off of volunteer effort is also a familiar story in the Free Software realm amongst organisations and projects alike.
+
+All in all, you end up with under-resourced independent projects and potentially over-resourced corporate projects with a handful of under-resourced projects somehow managing to get funded by companies who probably wonder when they can get away with de-funding them. This is presumably \"the market\" doing its thing, to hell with the impact it has on the people involved.
+"""]]

s/python/gtk
diff --git a/blog/2019-10-16-bus-factor.mdwn b/blog/2019-10-16-bus-factor.mdwn
index 0558f896..409de6d2 100644
--- a/blog/2019-10-16-bus-factor.mdwn
+++ b/blog/2019-10-16-bus-factor.mdwn
@@ -11,7 +11,7 @@ any of those projects.
 Now that I have a full time job, I feel the pain. Projects like
 [Gameclock][], [Monkeysign][], [Stressant][], and (to a lesser extent)
 [Wallabako][] all need urgent work: the first three need to be ported
-to Python 3, the first two to Python 2, and the latter will probably
+to Python 3, the first two to GTK 3, and the latter will probably
 die because I am getting a new e-reader. (For the record, more recent
 projects like [undertime][] and [feed2exec][] are doing okay, mostly
 because they were written in Python 3 from the start, and the latter

link to more reflections
diff --git a/blog/2019-10-16-bus-factor.mdwn b/blog/2019-10-16-bus-factor.mdwn
index 059926f6..0558f896 100644
--- a/blog/2019-10-16-bus-factor.mdwn
+++ b/blog/2019-10-16-bus-factor.mdwn
@@ -53,7 +53,13 @@ But unless economics of technology production change significantly in
 the coming decades, this problem will remain, and probably worsen, as
 we keep on scaffolding an entire civilization on shoulders of
 hobbyists that are barely aware their work is being used to power
-phones, cars, airplanes and hospitals.
+phones, cars, airplanes and hospitals. A [lot][] [has][] [been][]
+[written][] on this, but nothing seems to be moving.
+
+[written]: https://medium.com/sustainable-free-and-open-source-communities/we-need-sustainable-free-and-open-source-communities-edf92723d619
+[been]: https://www.vice.com/en_us/article/43zak3/the-internet-was-built-on-the-free-labor-of-open-source-developers-is-that-sustainable
+[has]: https://staltz.com/software-below-the-poverty-line.html
+[lot]: https://onezero.medium.com/the-internet-relies-on-people-working-for-free-a79104a68bcc
 
 And if that doesn't scare you, it damn well should. As a user, one
 thing you can do is, instead of wondering if you should buy a bit of

try to fix link and typo
diff --git a/software.mdwn b/software.mdwn
index 41ce91d8..8a77e96a 100644
--- a/software.mdwn
+++ b/software.mdwn
@@ -21,12 +21,10 @@ Je suis impliqué dans le projet [Monkeysphere](http://monkeysphere.info/) qui v
 Feed2exec
 ---------
 
-J'ai écris un lecteur de fils RSS nommé [feed2exec][] afin de
+J'ai écrit un lecteur de fils RSS nommé [feed2exec](https://gitlab.com/anarcat/feed2exec) afin de
 connecter des fils RSS avec n'importe quoi: courriels, Twitter,
 Mastodon, téléchargements, etc.
 
-[feed2exec]: https://gitlab.com/anarcat/feed2exec
-
 Wallabako
 ---------
 

our bus factor is one
diff --git a/blog/2019-10-16-bus-factor.mdwn b/blog/2019-10-16-bus-factor.mdwn
new file mode 100644
index 00000000..059926f6
--- /dev/null
+++ b/blog/2019-10-16-bus-factor.mdwn
@@ -0,0 +1,82 @@
+[[!meta title="Theory: average bus factor = 1"]]
+
+[Two][] [articles][] recently made me realize that *all* my free
+software projects basically have a [bus factor][] of one. I am the
+sole maintainer of every piece of software I have ever written that I
+still maintain. There *are* projects that I have been the maintainer
+of which have other maintainers now (most notably [AlternC][],
+[Aegir][] and [Linkchecker][]), but I am not the original author of
+any of those projects.
+
+Now that I have a full time job, I feel the pain. Projects like
+[Gameclock][], [Monkeysign][], [Stressant][], and (to a lesser extent)
+[Wallabako][] all need urgent work: the first three need to be ported
+to Python 3, the first two to Python 2, and the latter will probably
+die because I am getting a new e-reader. (For the record, more recent
+projects like [undertime][] and [feed2exec][] are doing okay, mostly
+because they were written in Python 3 from the start, and the latter
+has extensive unit tests. But they do suffer from the occasional
+bitrot (the latter in particular) and need constant upkeep.)
+
+Now that I barely have time to keep up with just the upkeep, I can't
+help but think all of my projects will just die if I stop working on
+them. I have the same feeling about the [packages I maintain in
+Debian][].
+
+What does that mean? Does that mean those packages are useless? That
+no one cares enough to get involved? That I'm not doing a good job at
+including contributors?
+
+I don't think so. I think I'm a friendly person online, and I try my
+best at doing good documentation and followup on my projects. What I
+have come to understand is even more depressing and scary that this
+being a personal failure: that is the situation with everyone,
+everywhere. The LWN article is not talking about silly things like a
+chess clock or a feed reader: we're talking about the Linux input
+drivers. A very deep, core component of the vast majority of computers
+running on the planet, that depend on that single maintainer. And I'm
+not talking about whether those people are paid or not, that's
+related, but not directly the question here. The same realization
+occured with OpenSSL and NTP, GnuPG is in a similar situation, the
+list just goes on and on.
+
+A single guy maintains those projects! Is that a fluke? A statistical
+anomaly? Everything I feel, and read, and know in my decades of
+experience with free software show me a reality that I've been trying
+to deny for all that time: it's the average.
+
+My theory is this: our average bus factor is one. I don't have any
+hard evidence to back this up, no hard research to rely on. I'd love
+to be proven wrong. I'd love for this to change.
+
+But unless economics of technology production change significantly in
+the coming decades, this problem will remain, and probably worsen, as
+we keep on scaffolding an entire civilization on shoulders of
+hobbyists that are barely aware their work is being used to power
+phones, cars, airplanes and hospitals.
+
+And if that doesn't scare you, it damn well should. As a user, one
+thing you can do is, instead of wondering if you should buy a bit of
+proprietary software, consider using free software and donating that
+money to free software projects instead. Lobby governments and
+research institutions to [sponsor only free software
+projects][]. Otherwise this civilization will collapse in a crash of
+spaghetti code before it even has time to [get flooded over][].
+
+[get flooded over]: https://en.wikipedia.org/wiki/The_Year_of_the_Flood
+[sponsor only free software projects]: https://publiccode.eu/
+[bus factor]: https://en.wikipedia.org/wiki/Bus_factor
+[articles]: https://who-t.blogspot.com/2019/10/libinputs-bus-factor-is-1.html
+[Two]: https://lwn.net/Articles/801767/
+[feed2exec]: https://gitlab.com/anarcat/feed2exec/
+[undertime]: https://gitlab.com/anarcat/undertime
+[packages I maintain in Debian]: https://qa.debian.org/developer.php?email=anarcat@debian.org
+[Monkeysign]: https://monkeysign.readthedocs.io/
+[Stressant]: https://stressant.readthedocs.io/
+[Gameclock]: https://gitlab.com/anarcat/gameclock/
+[Wallabako]: https://gitlab.com/anarcat/wallabako/
+[Linkchecker]: https://github.com/linkchecker/linkchecker/
+[Aegir]: https://www.aegirproject.org/
+[AlternC]: https://alternc.org/
+
+[[!tag debian-planet python-planet python software debian]]

managed to get bookworm to work, but it's not so nice
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 109c2d3f..b31d0dea 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -115,8 +115,13 @@ Calibre is...
       doesn't seem to), but fails to load certain ebooks (book #1459
       for example)
     * [Bookworm][] looks very promising, not in Debian ([[!debbug
-      883867]]), but [Flathub][flathub-bookworm].  same problems as
-      GNOME books finding my books (ie. it can't).
+      883867]]), but [Flathub][flathub-bookworm]. scans books on exit,
+      and can take a loong time to scan an entire library (took 24+
+      hours here, and had to kill `pdftohtml` a few times) without a
+      progress bar. but has a nice library browser, although it looks
+      like covers are sorted randomly. search works okay,
+      however. unclear what happens when you add a book, it doesn't
+      end up in the chosen on-disk library.
     * [Buka][] is another "ebook" manager written in Javascript, but
       only supports PDFs for now.
     * [coolreader][] is another alternative, [not yet in Debian

add more of the soundcraft line
diff --git a/hardware/audio.mdwn b/hardware/audio.mdwn
index a48b5926..472de8ee 100644
--- a/hardware/audio.mdwn
+++ b/hardware/audio.mdwn
@@ -96,10 +96,18 @@ XLR and 4 stereo in (for 12 mono in). Only the first two lines have
 inserts. Builtin sd-card recorder with, apparently, 14/4 (14 in, 4
 out) USB support.
 
-The [Soundcraft EPM8][] is very interesting: 430$, with two stero
-output buses and inserts on all 8 XLR/TRS lines. No USB, for that you
-need to bump up to the [Signature 12MTK](https://www.long-mcquade.com/54582/Pro-Audio---Recording/Mixers/Soundcraft/Signature-12MTK-12-Channel-Mixer-with-14-in-12-out-USB-Interface.htm) at 730$ that has 14/12
-USB.
+The [Soundcraft EPM8][] is very interesting: [430$ at L&M][], [360$ at
+steve's][], with two
+stero output buses and inserts on all 8 XLR/TRS lines. No USB, for
+that you need to bump up to the [Signature 12MTK](https://www.long-mcquade.com/54582/Pro-Audio---Recording/Mixers/Soundcraft/Signature-12MTK-12-Channel-Mixer-with-14-in-12-out-USB-Interface.htm) at 730$ that has
+14/12 USB. They also have the equivalent [EFX8][] with a built-in
+effects module, [640$ at L&M][], [540$ at steve's][].
+
+[540$ at steve's]: https://stevesmusic.com/en/soundcraft-efx-8.html
+[360$ at steve's]: https://stevesmusic.com/en/soundcraft-epm-8.html
+[640$ at L&M]: https://www.soundcraft.com/en-US/products/efx8
+[EFX8]: https://www.soundcraft.com/en-US/products/efx8
+[430$ at L&M]: https://www.long-mcquade.com/5620/Pro_Audio_Recording/Mixers/Soundcraft/EPM8_-_8X2_Channel_Mixer.htm
 
 Behringer had a bad reputation over a decade ago, and it seems that
 reputation is still around. They do provide a cheap alternative
@@ -122,7 +130,7 @@ ALSA, but it might be better to just use an analog mixer and feed the
 signal from each unmixed track into an USB audio interface like
 [this](https://www.long-mcquade.com/87374/Pro-Audio---Recording/Audio-Interfaces/Presonus/Studio-68-6-In-8-Out-USB-Audio-Interface.htm), instead of trying to shove everything into a single device.
 
-[Soundcraft EPM8]: https://www.long-mcquade.com/5620/Pro_Audio_Recording/Mixers/Soundcraft/EPM8_-_8X2_Channel_Mixer.htm
+[Soundcraft EPM8]: https://www.soundcraft.com/en-US/products/epm8
 
 There was a lenghty conversation on the [Ardour forums](https://discourse.ardour.org/) about this
 topic, see:

more notes about the note
diff --git a/hardware/tablet.mdwn b/hardware/tablet.mdwn
index e0d9a011..0acf454c 100644
--- a/hardware/tablet.mdwn
+++ b/hardware/tablet.mdwn
@@ -146,6 +146,24 @@ slightly more reasonable:
    TIFF, BMP, WAV, MP3
  * 600$USD
 
+Downsides:
+
+ * [Android 6](http://bbs.onyx-international.com/t/android-upgrade/1827) (!)
+ * Kind of janky Android version: had to hack around to get f-droid
+   installed and the "settings" display is non-standard. but i could
+   get into "developer mode" at least...
+ * [Some compatibility problems with the annotation system](http://bbs.onyx-international.com/t/annotations-with-pen-with-pressure-not-displayed-in-pdf-viewer/1441)
+ * Difficulties syncing with linux at times, [MTP compatibility
+   problems](http://bbs.onyx-international.com/t/onyx-note-pro-not-visible-as-mtp-on-debian-10/1811)?
+ * [Shitty reseller in Canada](http://bbs.onyx-international.com/t/unexpected-delays-and-customs-fees-when-ordering-from-good-ereader/1423) but buying from boox.com seems fine
+   so far
+ * No external sd card
+
+I ended up buying *two* of those (one for a teacher and one for me!
+;), so I guess that means I'm happy with it. My biggest gripe about it
+is the old Android release and weird OS, but the reader is in
+generally excellent.
+
 reMarkable
 ----------
 

some experiences with readers (mupdf and atril failures, mostly)
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index cd4c85ad..109c2d3f 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -112,7 +112,8 @@ Calibre is...
    here:
 
     * [Atril][], MATE's version of [Evince][], supports ePUBs (Evince
-      doesn't seem to)
+      doesn't seem to), but fails to load certain ebooks (book #1459
+      for example)
     * [Bookworm][] looks very promising, not in Debian ([[!debbug
       883867]]), but [Flathub][flathub-bookworm].  same problems as
       GNOME books finding my books (ie. it can't).
@@ -136,7 +137,10 @@ Calibre is...
       provides a .deb). It depends on older Firefox releases (or
       "[Pale moon][]", a Firefox fork), see also the [[firefox]]
       XULocalypse for details
-    * [MuPDF][] also reads ePUBs without problems and is really fast
+    * [MuPDF][] also reads ePUBs and is really fast, but the user
+      interface is extremely minimal, and copy-paste doesn't work so
+      well (think "Xpdf"). it also failed to load certain books (e.g.
+      1359) and warns about 3.0 ePUBs (e.g. book 1162)
     * [Okular][] supports ePUBs when `okular-extra-backends` is
       installed
     * [plato][] is another alternative reader for Kobo readers, not in

make a new section on metadata
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 5192ebac..cd4c85ad 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -11,12 +11,19 @@ TL;DR: I'm considering replacing those various [Calibre][] compnents with...
    [Atril][] or [MuPDF][] on the desktop?
  * ebook-editor: [Sigil][].
  * collection browser: [Liber][]? see also [[services/bookmarks]]
+ * metadata editor: no good alternative.
  * device synchronisation: [git-annex][]?
  * RSS reader: [feed2exec][], [wallabako][]
  * ebook web server: [Liber][]?
 
 [git-annex]: https://git-annex.branchable.com/
 
+My biggest blocker that don't really have good alternatives are:
+
+ * collection browser
+ * metadata editor
+ * device sync
+
 See below why and a deeper discussion on all the features.
 
 Problems with Calibre
@@ -211,6 +218,26 @@ Calibre is...
    online articles. See also [[firefox]] (Zotero section) and
    [[bookmarks]] for a longer discussion of that problem.
 
+ * a **metadata editor**: the "collection browser" is based on a lot
+   of metadata that Calibre indexes from the books. It can magically
+   find a lot of stuff in the multitude of file formats it supports,
+   something that is pretty awesome and impressive. For example, I
+   just added a PDF file, and it found the book cover, author,
+   publication date, publisher, language and the original mobi book id
+   (!). It also added the book in the right directory and dumped that
+   metadata and the cover in a file next to the book. And if that's
+   not good enough, it can poll that data from various online sources
+   like Amazon, and Google books.
+   
+   Maybe the [work Peter Keel did][] could be useful in creating some
+   tool which would do this automatically? Or maybe [Sigil][] could
+   help? [Liber][] can also fetch metadata from Google books, but not
+   interactively.
+   
+   I still use Calibre mostly for this.
+
+[work Peter Keel did]: https://seegras.discordia.ch/Blog/life-with-calibre/
+
  * a **device synchronization tool** : I mostly use Calibre to
    synchronize books with an ebook-reader. It can also automatically
    update the database on the ebook with relevant metadata

problème réseau
diff --git "a/services/r\303\251seau.mdwn" "b/services/r\303\251seau.mdwn"
index 879888ac..24388a46 100644
--- "a/services/r\303\251seau.mdwn"
+++ "b/services/r\303\251seau.mdwn"
@@ -5,7 +5,12 @@ Update: ipv6 and dns work better with new router. see good test page: <http://en
 Problèmes connus
 ================
 
- * <del>le réseau [[IPv6]] est intermittent</del> semble être résolu avec teksavvy
+ * le réseau [[IPv6]] est intermittent, <del>semble être résolu avec
+   teksavvy</del> nope, IPv6 tombe environ une fois par mois (à
+   vérifier), cliquer sur "reconnect" de l'interface `WAN6` dans le
+   GUI règle le problème. selon [ce bout de code](https://github.com/openwrt/luci/blob/e712a8a4ac896189c333400134e00977912a918a/modules/luci-mod-network/luasrc/controller/admin/network.lua#L169-L176), il suffirait de
+   faire un `env -i /sbin/ifup %s >/dev/null 2>/dev/null` où `%s` est
+   l'interface réseau. à tester.
  * <del>la qualité de la bande passante varie avec les conditions météo</del> semble être résolu avec le VDSL
  * certaines requêtes DNS échouent, voir [[DNS]] pour les détails
  * le reverse DNS IPv6 ne fonctionne pas, voir mon [review the TSI](https://www.dslreports.com/forum/r30473265-Review)

add toc
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index cc492edf..4b29ad00 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -1,3 +1,5 @@
+[[!toc levels=2]]
+
 [Monitors](https://en.wikipedia.org/wiki/Computer_monitor) are devices that display information visually. They can
 include speakers and other connectors like USB. They were connected
 through [VGA][] connectors for the long time, but that has generally

Added a comment: Or an epub to HTML converter plus lynx…
diff --git a/software/desktop/calibre/comment_14_2c5c0cfd7d55143e984d8b6efd81db3f._comment b/software/desktop/calibre/comment_14_2c5c0cfd7d55143e984d8b6efd81db3f._comment
new file mode 100644
index 00000000..fd51f261
--- /dev/null
+++ b/software/desktop/calibre/comment_14_2c5c0cfd7d55143e984d8b6efd81db3f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ ip="89.1.20.66"
+ claimedauthor="mirabilos"
+ url="http://www.mirbsd.org/music/free/"
+ subject="Or an epub to HTML converter plus lynx…"
+ date="2019-10-10T16:40:32Z"
+ content="""
+I wrote this small shellscript for myself…
+
+http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/unepub?rev=HEAD
+
+… which unzips an EPUB file and converts the toc.nxc into an index.htm which I can then use with lynx (the standard text mode webbrowser).
+"""]]

Added a comment: Finally, someone says it!
diff --git a/blog/2019-10-06-native-apps-matter/comment_3_d8c3805fa8d311666364a2bb75597cd8._comment b/blog/2019-10-06-native-apps-matter/comment_3_d8c3805fa8d311666364a2bb75597cd8._comment
new file mode 100644
index 00000000..4b30fba4
--- /dev/null
+++ b/blog/2019-10-06-native-apps-matter/comment_3_d8c3805fa8d311666364a2bb75597cd8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="89.1.20.66"
+ claimedauthor="mirabilos"
+ url="http://www.mirbsd.org/music/free/"
+ subject="Finally, someone says it!"
+ date="2019-10-10T16:36:54Z"
+ content="""
+Thanks, much appreciated. I’ve been trying to get this point across for ages…
+"""]]

more latency notes
diff --git a/blog/2018-05-04-terminal-emulators-2/comment_2_f550f0e759d53438e60f6df5e3b28b59._comment b/blog/2018-05-04-terminal-emulators-2/comment_2_f550f0e759d53438e60f6df5e3b28b59._comment
new file mode 100644
index 00000000..219c91e0
--- /dev/null
+++ b/blog/2018-05-04-terminal-emulators-2/comment_2_f550f0e759d53438e60f6df5e3b28b59._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""Dan Luu's Terminal Latency"""
+ date="2019-10-10T13:30:14Z"
+ content="""
+I don't know how I managed to write this article without quoting *this* specific article from Dan Luu. I somehow managed to see Luu's [terminal latency](https://danluu.com/term-latency/) post, but I just missed the [input latency](https://danluu.com/input-lag/) one. It's just such an eye-opener: we keep on thinking computers get faster and faster while, in reality, they are getting *slower*. The Apple 2e, one of the first personal computers ever built in 1983, had a 30ms input latency. A Thinkpad Carbon X1 laptop running Linux had, in comparison, 170ms input latency. That's just crazy.
+"""]]
diff --git a/hardware/monitor.mdwn b/hardware/monitor.mdwn
index d2aff83c..cc492edf 100644
--- a/hardware/monitor.mdwn
+++ b/hardware/monitor.mdwn
@@ -50,7 +50,7 @@ Full gamut
 Normal
 ------
 
- * [Viewsonic VP2768](https://www.viewsonic.com/us/monitors/shop/professional-monitors/vp2768.html#specs)
+ * [Viewsonic VP2768 27" WQHD 14ms GTG](https://www.viewsonic.com/us/monitors/shop/professional-monitors/vp2768.html#specs)
  * [Dell 27" WQHD 144Hz 1ms GTG TN LED G-SYNC Gaming Monitor
    (S2716DG) - Black](https://www.bestbuy.ca/en-ca/product/dell-dell-27-wqhd-144hz-3ms-gtg-tn-led-g-sync-gaming-monitor-s2716dg-black-s2716dg/10409157) (bestbuy: 450$)
  * [DELL 27" 2ms 144Hz AMD FreeSync Gaming Monitor DisplayPort, HDMI,
@@ -58,6 +58,51 @@ 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)
+ * [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$)
+
+Note on latency
+---------------
+
+Latency might seem like a trivial concern for a non-gamer, but it
+actually matters. In their [Typing with pleasure](https://pavelfatin.com/typing-with-pleasure/#output-latency) article, Pavel
+Fatin explains that even 1ms delays matter. In my [[terminal emulators
+review|blog/2018-05-04-terminal-emulators-2/#latency]], I argue that
+we should follow the GNOME HIG that sets the bar at 10ms. Considering
+that my main work tool (Emacs) has a mean *input* latency of around
+5ms, adding 5ms latency to the *output*, just through the monitor, is
+unacceptable.
+
+So I'll set the bar, arbitrarily, at 2ms, but ideal this would be 1ms
+or below. 
+
+Keep in mind that the best total input latency for a computer is
+currently at 30, with the Apple IIe, [according to Dan Luu](https://danluu.com/input-lag/). But
+that takes into account the entire processing cycle, which includes
+input, processing and output, if we adhere to Fatin's vocabulary. The
+benchmarks I performed in my blog post concern only the *processing*
+side of things, as we don't physically bash on the keyboard to
+generate those keypresses. In other words, assuming a 2ms latency in
+the monitor and 5ms in Emacs, what we actually have is:
+
+| Source | Latency | Notes |
+| ------ | ------- | ----- |
+| Input  | 14 ms   | Fatin, section 2.1, avergge |
+| Emacs  | 5 ms    | Anarcat, section 1, rounded mean |
+| Screen refresh | 8 ms | Fatin, section 2.3, average with 60Hz monitor |
+| Pixel response | 2 ms | Assumption, above |
+| Total  | 29 ms |
+
+So *in theory*, with a 2ms monitor and best conditions in Emacs, we
+should rival the Apple IIe input latency. In practice, considering
+Luu's results, it's very likely that I'm missing some numbers here and
+latency is actually much higher.
+
+In any case, that's way beyond the 10ms objective, so it makes sense
+to reduce the monitor latency if possible. In fact, when looking at
+this, one has to wonder if the [[keyboard]] would be a better place to
+look for latency improvements. After all 7 ms spent in debouncing
+seems pretty horrible...
 
 Resources
 =========

more notes abouve vimium and tridactyl
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index d2e90c68..c026869e 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -83,10 +83,17 @@ I am testing those and they might make it to the top list once I'm happy:
    good enough for my purposes.
  * [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)
- * [tridactyl](https://github.com/tridactyl/tridactyl) - to use the web browser without the mouse. was
-   [pulled out of AMO][] for a policy violation, might return but in
-   the meantime, i'm trying out [vimium][]. also see the [builtin Firefox shortcuts][]
-
+ * [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
+
+[tridactyl]: https://github.com/tridactyl/tridactyl
 [builtin Firefox shortcuts]: https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly
 [vimium]: https://github.com/philc/vimium
 [Multi-account containers]: https://github.com/mozilla/multi-account-containers/
@@ -190,7 +197,7 @@ And here are the replacements I have found:
  * [web developer](https://addons.mozilla.org/en-US/firefox/addon/web-developer/): ported
  * [vimperator][]: a few [vimperator alternatives][] have popped
    up. [tridactyl][] was the most prominent one, but was also [pulled
-   from AMO][] for a policy violation. [vimium fx][] and [vim-vixen][]
+   from AMO][] for a policy violation. [vimium-ff][] and [vim-vixen][]
    seem like the only working alternatives right now, although the
    vimperator folks say they lack some features, I couldn't figure out
    which. [pentadactyl][] is the father to all of those, but seems to
@@ -202,7 +209,7 @@ And here are the replacements I have found:
 [vim-vixen]: https://github.com/ueokande/vim-vixen
 [vimfx]: https://github.com/akhodakivskiy/VimFx
 [pentadactyl]: http://web.archive.org/web/20171019152504/http://5digits.org/pentadactyl/
-[vimium fx]: https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/?src=search
+[vimium-ff]: https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/
 [salsa key]: https://addons.mozilla.org/en-US/firefox/addon/saka-key/
 [pulled from AMO]: https://github.com/tridactyl/tridactyl/issues/1800
 [vimperator alternatives]: https://github.com/vimperator/vimperator-labs#end-of-life-and-alternatives

another local provider
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index 30986b1b..8deac924 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -487,5 +487,6 @@ Fournisseurs
 * [Encan Dépôt](http://www.encandepot.com/) - same, across the street
 * [mike's computer shop](https://www.mikescomputershop.com/) - cheap canada seller
 * [canada computers](http://www.canadacomputers.com) - famous toronto computer shop?
+* [CIPC](https://cipc.com/) - another local shop!
 
 [[!tag research]]

fix markup
diff --git a/software/desktop/calibre/comment_12_7fb6eea9ecee3af73a888dd95069e318._comment b/software/desktop/calibre/comment_12_7fb6eea9ecee3af73a888dd95069e318._comment
index 72b9992d..16387790 100644
--- a/software/desktop/calibre/comment_12_7fb6eea9ecee3af73a888dd95069e318._comment
+++ b/software/desktop/calibre/comment_12_7fb6eea9ecee3af73a888dd95069e318._comment
@@ -4,15 +4,17 @@
  date="2019-10-09T17:03:35Z"
  content="""
 Yeah, I noticed some problems with Calibre as well, in 2013.
-https://seegras.discordia.ch/Blog/life-with-calibre/
+
+<https://seegras.discordia.ch/Blog/life-with-calibre/>
 
 I've written some software then, mainly to speed up extraction
 of epub-metatags by a factor of 100(!), but it's grown into 
-a veritable zoo of scripts. You can find them on my 
-https://github.com/Seegras/ site. Mainly:
-- https://github.com/Seegras/epub-meta
-- https://github.com/Seegras/metatags
-might be helpful. 
+a veritable zoo of scripts. You can find them on [my site](https://github.com/Seegras). Mainly:
+
+* https://github.com/Seegras/epub-meta
+* https://github.com/Seegras/metatags
+
+... might be helpful. 
 
 In any case, your posting helped me too, if for not other reason
 than I know now that atril can read epubs; but hopefully this 

move comments to right post
diff --git a/blog/2019-10-08-libreoffice-pdf-batch/comment_3_7fb6eea9ecee3af73a888dd95069e318._comment b/software/desktop/calibre/comment_12_7fb6eea9ecee3af73a888dd95069e318._comment
similarity index 100%
rename from blog/2019-10-08-libreoffice-pdf-batch/comment_3_7fb6eea9ecee3af73a888dd95069e318._comment
rename to software/desktop/calibre/comment_12_7fb6eea9ecee3af73a888dd95069e318._comment
diff --git a/blog/2019-10-08-libreoffice-pdf-batch/comment_4_b7456d39f03e9e2ad870e946778c0afd._comment b/software/desktop/calibre/comment_13_b7456d39f03e9e2ad870e946778c0afd._comment
similarity index 100%
rename from blog/2019-10-08-libreoffice-pdf-batch/comment_4_b7456d39f03e9e2ad870e946778c0afd._comment
rename to software/desktop/calibre/comment_13_b7456d39f03e9e2ad870e946778c0afd._comment

response
diff --git a/blog/2019-10-08-libreoffice-pdf-batch/comment_4_b7456d39f03e9e2ad870e946778c0afd._comment b/blog/2019-10-08-libreoffice-pdf-batch/comment_4_b7456d39f03e9e2ad870e946778c0afd._comment
new file mode 100644
index 00000000..79c1e347
--- /dev/null
+++ b/blog/2019-10-08-libreoffice-pdf-batch/comment_4_b7456d39f03e9e2ad870e946778c0afd._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""git-annex"""
+ date="2019-10-09T17:04:35Z"
+ content="""
+Re. git-annex, nothing special. I had some hacks to make it ignore the .db file, because Calibre would be really upset if it can't open (ie. write) to the database. But now with "unlocked mode", it's not really a problem anymore.
+"""]]

add comment i got by email, after approval
diff --git a/blog/2019-10-08-libreoffice-pdf-batch/comment_3_7fb6eea9ecee3af73a888dd95069e318._comment b/blog/2019-10-08-libreoffice-pdf-batch/comment_3_7fb6eea9ecee3af73a888dd95069e318._comment
new file mode 100644
index 00000000..72b9992d
--- /dev/null
+++ b/blog/2019-10-08-libreoffice-pdf-batch/comment_3_7fb6eea9ecee3af73a888dd95069e318._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="Peter Keel"
+ subject="""Calibre replacements"""
+ date="2019-10-09T17:03:35Z"
+ content="""
+Yeah, I noticed some problems with Calibre as well, in 2013.
+https://seegras.discordia.ch/Blog/life-with-calibre/
+
+I've written some software then, mainly to speed up extraction
+of epub-metatags by a factor of 100(!), but it's grown into 
+a veritable zoo of scripts. You can find them on my 
+https://github.com/Seegras/ site. Mainly:
+- https://github.com/Seegras/epub-meta
+- https://github.com/Seegras/metatags
+might be helpful. 
+
+In any case, your posting helped me too, if for not other reason
+than I know now that atril can read epubs; but hopefully this 
+calibre issue leads to more epub-related software packaged for
+debian.
+
+lucidor, btw., was nice, but it's ancient. Not worth porting
+anymore.
+
+BTW: you're managing your books in git-annex? How does that work
+exactly? I'm interested to read another blog-posting about that ;).
+"""]]

response
diff --git a/blog/2019-10-08-libreoffice-pdf-batch/comment_2_1bd2e99a6b1199068b709dc6612dfcfe._comment b/blog/2019-10-08-libreoffice-pdf-batch/comment_2_1bd2e99a6b1199068b709dc6612dfcfe._comment
new file mode 100644
index 00000000..5ba04f8c
--- /dev/null
+++ b/blog/2019-10-08-libreoffice-pdf-batch/comment_2_1bd2e99a6b1199068b709dc6612dfcfe._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""alternatives"""
+ date="2019-10-09T14:50:46Z"
+ content="""
+> Is that not precisely the idea of unoconv? plus it converts to many other formats and handles the headless server very nicely...
+
+[unoconv][], sure, why not. [Someone][] also suggested
+[lloconv][]. There's also [Pandoc][] that could probably do this as
+well.
+
+The thing is none of those have file manager integration. Plus, it's
+extra software to install. I want the simplest possible instructions,
+targeting novice Linux users, which means as little (commandline, in
+particular) work as possible. Installing new packages is therefore
+superfluous.
+
+By the way, I suspect the above instructions I made *do* reuse
+existing Libreoffice instances if they are already running. I might be
+wrong, but it seems faster with than without... 
+
+Without LibreOffice running:
+
+    ===> multitime results
+    1: libreoffice --headless --convert-to pdf impots.ods
+                Mean        Std.Dev.    Min         Median      Max
+    real        1.726       0.061       1.671       1.695       1.876       
+    user        1.258       0.050       1.208       1.244       1.362       
+    sys         0.226       0.023       0.180       0.231       0.257
+
+
+With LibreOffice running:
+
+    ===> multitime results
+    1: libreoffice --headless --convert-to pdf impots.ods
+                Mean        Std.Dev.    Min         Median      Max
+    real        0.411       0.033       0.367       0.398       0.468       
+    user        0.014       0.006       0.005       0.013       0.022       
+    sys         0.012       0.007       0.001       0.012       0.023
+
+So thanks everyone for the recommendations, those are very useful
+tools! But I think LibreOffice's builtin commandline is fine for this
+purpose for now.
+
+[Pandoc]: https://pandoc.org/
+[unoconv]: http://dag.wiee.rs/home-made/unoconv/
+[lloconv]: https://gitlab.com/ojwb/lloconv
+[Someone]: https://framapiaf.org/@boutil/102928777691782064
+"""]]

fix tag typo
diff --git a/blog/2019-10-08-libreoffice-pdf-batch.mdwn b/blog/2019-10-08-libreoffice-pdf-batch.mdwn
index f72146e3..0bb3b4f0 100644
--- a/blog/2019-10-08-libreoffice-pdf-batch.mdwn
+++ b/blog/2019-10-08-libreoffice-pdf-batch.mdwn
@@ -37,4 +37,4 @@ file (or anything supported by LibreOffice, really) into PDF.
 Now I wonder if this would be a useful addition to the Debian package,
 anyone?
 
-[[!tag debian-planet hack pdf planet-python debian]]
+[[!tag debian-planet hack pdf python-planet debian]]
diff --git a/tag/planet-python.mdwn b/tag/planet-python.mdwn
deleted file mode 100644
index aaab89f8..00000000
--- a/tag/planet-python.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-[[!meta title="pages tagged planet-python"]]
-
-[[!inline pages="tagged(planet-python)" actions="no" archive="yes"
-feedshow=10]]

Added a comment: Why not unoconv?
diff --git a/blog/2019-10-08-libreoffice-pdf-batch/comment_1_8cef74cc8613d5ab8f65b9f568256b12._comment b/blog/2019-10-08-libreoffice-pdf-batch/comment_1_8cef74cc8613d5ab8f65b9f568256b12._comment
new file mode 100644
index 00000000..4342faee
--- /dev/null
+++ b/blog/2019-10-08-libreoffice-pdf-batch/comment_1_8cef74cc8613d5ab8f65b9f568256b12._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ ip="88.144.55.174"
+ claimedauthor="Anonymous coward"
+ subject="Why not unoconv?"
+ date="2019-10-08T21:02:54Z"
+ content="""
+Is that not precisely the idea of unoconv? plus it converts to many other formats and handles the headless server very nicely...
+"""]]

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

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

libreoffice batch hack
diff --git a/blog/2019-10-08-libreoffice-pdf-batch.mdwn b/blog/2019-10-08-libreoffice-pdf-batch.mdwn
new file mode 100644
index 00000000..f72146e3
--- /dev/null
+++ b/blog/2019-10-08-libreoffice-pdf-batch.mdwn
@@ -0,0 +1,40 @@
+[[!meta title="Tip of the day: batch PDF conversion with LibreOffice"]]
+
+Someone asked me today why they couldn't write on the [DOCX][]
+document they received from a student using the pen in their [Onyx
+Note Pro][] reader. The answer, of course, is that while the Onyx can
+read those files, it can't annotate them: that only works with PDFs.
+
+[Onyx Note Pro]: https://onyxboox.com/boox_notepro
+[DOCX]: https://en.wikipedia.org/wiki/Office_Open_XML
+
+Next question then, is of course: do I really need to open each file
+separately and save them as PDF? That's going to take forever, I have
+30 students per class!
+
+> *Fear not, shell scripting and headless mode flies in to the rescue!*
+
+As it turns out, one of the [Libreoffice parameters][] allow you to
+run batch operations on files. By calling:
+
+    libreoffice --headless --convert-to pdf *.docx
+
+[Libreoffice parameters]: https://help.libreoffice.org/Common/Starting_the_Software_With_Parameters
+
+LibreOffice will happily convert all the `*.docx` files in the current
+directory to PDF. But because navigating the commandline can be hard,
+I figured I could push this a tiny little bit further and wrote the
+following script:
+
+    #!/bin/sh
+    
+    exec libreoffice --headless --convert-to pdf "$@"
+
+Drop this in `~/.local/share/nautilus/scripts/libreoffice-pdf`, mark
+it executable, and voilà! You can batch-convert basically any text
+file (or anything supported by LibreOffice, really) into PDF.
+
+Now I wonder if this would be a useful addition to the Debian package,
+anyone?
+
+[[!tag debian-planet hack pdf planet-python debian]]

link to other shortcuts
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 27773f4a..d2e90c68 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -85,8 +85,9 @@ I am testing those and they might make it to the top list once I'm happy:
    [source](https://github.com/shgysk8zer0/awesome-rss)) - replace the [Live bookmarks removal](https://support.mozilla.org/en-US/kb/live-bookmarks-migration)
  * [tridactyl](https://github.com/tridactyl/tridactyl) - to use the web browser without the mouse. was
    [pulled out of AMO][] for a policy violation, might return but in
-   the meantime, i'm trying out [vimium][].
+   the meantime, i'm trying out [vimium][]. also see the [builtin Firefox shortcuts][]
 
+[builtin Firefox shortcuts]: https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly
 [vimium]: https://github.com/philc/vimium
 [Multi-account containers]: https://github.com/mozilla/multi-account-containers/
 

promote browserpass, display-anchors and url-to-qrcode
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 3eb62c3b..27773f4a 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -24,14 +24,25 @@ or have used in the past.
 
 I have those extensions installed and use them very frequently:
 
+ * [browserpass-ce](https://addons.mozilla.org/en-US/firefox/addon/browserpass-ce/) ([[!debpkg webext-browserpass desc="debian
+   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
  * [uBlock Origin][] ([[!debpkg webext-ublock-origin desc="debian
    package"]], [source](https://github.com/gorhill/uBlock)) - making the web sane again
- * [uMatrix][] (no debian package, [#891859](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891859), [source](https://github.com/gorhill/uMatrix)) - making the web
-   somewhat safe again
+ * [uMatrix][] ([[!debpkg webext-umatrix desc="debian package"]],
+   [source](https://github.com/gorhill/uMatrix)) - making the web somewhat safe again
  * [Wallabager][] (no debian package, [source](https://github.com/wallabag/wallabagger)) - to YOLO a bunch
    of links in a pile outside my web browser that I can read offline
    thanks to [Wallabako](https://gitlab.com/anarcat/wallabako/)
+ * [URL to QR Code](https://addons.mozilla.org/en-US/firefox/addon/url-to-qrcode/?src=search) - (no debian package, [source](https://github.com/smoqadam/url-to-qrcode-firefox-addon)) after
+   kicking out that proprietary spyware (!! see below), I found about
+   6 different alternatives (this one and [1](https://addons.mozilla.org/en-US/firefox/addon/qr-code-util/), [2](https://addons.mozilla.org/en-US/firefox/addon/fxqrl/), [3](https://addons.mozilla.org/en-US/firefox/addon/ffqrcoder/),
+   [4](https://addons.mozilla.org/en-US/firefox/addon/qrify/), [5](https://addons.mozilla.org/en-US/firefox/addon/qr-coder/) - what is wrong with you people??) This is the most
+   popular, reviews are mostly positive, seems to be working offline,
+   has a free license, and source is available. Super simple too.
 
 [Wallabager]: https://addons.mozilla.org/en-US/firefox/addon/wallabagger/
 [uMatrix]: https://addons.mozilla.org/firefox/addon/umatrix/
@@ -48,11 +59,6 @@ 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:
 
- * [browserpass-ce](https://addons.mozilla.org/en-US/firefox/addon/browserpass-ce/) ([[!debpkg webext-browserpass desc="debian
-   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))
  * [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
@@ -60,12 +66,6 @@ I am testing those and they might make it to the top list once I'm happy:
    on the "+" tab button to choose container.
  * [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
- * [URL to QR Code](https://addons.mozilla.org/en-US/firefox/addon/url-to-qrcode/?src=search) - (no debian package, [source](https://github.com/smoqadam/url-to-qrcode-firefox-addon)) after
-   kicking out that proprietary spyware (!! see below), I found about
-   6 different alternatives (this one and [1](https://addons.mozilla.org/en-US/firefox/addon/qr-code-util/), [2](https://addons.mozilla.org/en-US/firefox/addon/fxqrl/), [3](https://addons.mozilla.org/en-US/firefox/addon/ffqrcoder/),
-   [4](https://addons.mozilla.org/en-US/firefox/addon/qrify/), [5](https://addons.mozilla.org/en-US/firefox/addon/qr-coder/) - what is wrong with you people??) This is the most
-   popular, reviews are mostly positive, seems to be working offline,
-   has a free license, and source is available. Super simple too.
  * [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
    everywhere](https://www.eff.org/https-everywhere) but i find that one works too and doesn't require
    sites to be added to a list. nowadays, https URLs match http URLs

sort software list and add details
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 1cfc7db5..5192ebac 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -104,33 +104,38 @@ Calibre is...
    ebook-readers, on different platforms, that can replace Calibre
    here:
 
-    * [Atril][], MATE's version of Evince, supports ePUBs (Evince
-      doesn't)
-    * [MuPDF][] also reads ePUBs without problems and is really fast
-    * [fbreader][] also supports ePUBs, but is much slower than all
-      those others
-    * Emacs (of course) supports ebooks through [nov.el][]
-    * [Okular][] apparently supports ePUBs, but I must be missing a
-      library because it doesn't actually work here
+    * [Atril][], MATE's version of [Evince][], supports ePUBs (Evince
+      doesn't seem to)
+    * [Bookworm][] looks very promising, not in Debian ([[!debbug
+      883867]]), but [Flathub][flathub-bookworm].  same problems as
+      GNOME books finding my books (ie. it can't).
+    * [Buka][] is another "ebook" manager written in Javascript, but
+      only supports PDFs for now.
     * [coolreader][] is another alternative, [not yet in Debian
       (#715470)][]
-    * [lucidor][] also looks interesting, but is not packaged in
-      Debian either (although upstream provides a .deb) and depends on
-      older Firefox releases (or "[Pale moon][]", a Firefox fork)
-    * [koreader][] and [plato][] are good alternatives for the Kobo
-      reader (although koreader also now has builds for Debian)
+    * Emacs (of course) supports ebooks through [nov.el][]
+    * [fbreader][] also supports ePUBs, but is much slower than all
+      those others, and turned proprietary so is unmaintained
+    * [Foliate][] looks gorgeous and is built on top of the ePUB.js
+      library, not in Debian, but [Flathub][flathub-foliate].
     * [GNOME Books][] is interesting, but relies on the GNOME search
       engine and doesn't find my books (and instead lots of other
       garbage). it's been described as "basic" and "the least mature"
       in [this OMG Ubuntu review][]
-    * [Bookworm][] looks very promising, not in Debian ([[!debbug
-      883867]]), but [Flathub][flathub-bookworm]
-    * [Foliate][] looks gorgeous and is built on top of the ePUB.js
-      library, not in Debian, but [Flathub][flathub-foliate]. same
-      problems as GNOME books finding my books (ie. it can't).
-    * [Buka][] is another "ebook" manager written in Javascript, but
-      only supports PDFs for now
+    * [koreader][] is a good alternative reader for the Kobo devices
+      and now also has builds for Debian, but no Debian package
+    * [lucidor][] is a Firefox extension that can read an organize
+      books, but is not packaged in Debian either (although upstream
+      provides a .deb). It depends on older Firefox releases (or
+      "[Pale moon][]", a Firefox fork), see also the [[firefox]]
+      XULocalypse for details
+    * [MuPDF][] also reads ePUBs without problems and is really fast
+    * [Okular][] supports ePUBs when `okular-extra-backends` is
+      installed
+    * [plato][] is another alternative reader for Kobo readers, not in
+      Debian
 
+[Evince]: https://wiki.gnome.org/Apps/Evince
 [flathub-bookworm]: https://www.flathub.org/apps/details/com.github.babluboy.bookworm
 [Buka]: https://github.com/oguzhaninan/Buka
 [flathub-foliate]: https://www.flathub.org/apps/details/com.github.johnfactotum.Foliate

more notes about bookworm
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index baf15123..1cfc7db5 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -123,12 +123,15 @@ Calibre is...
       engine and doesn't find my books (and instead lots of other
       garbage). it's been described as "basic" and "the least mature"
       in [this OMG Ubuntu review][]
-    * [Bookworm][] looks very promising
+    * [Bookworm][] looks very promising, not in Debian ([[!debbug
+      883867]]), but [Flathub][flathub-bookworm]
     * [Foliate][] looks gorgeous and is built on top of the ePUB.js
-      library, not in Debian, but [Flathub][flathub-foliate]
+      library, not in Debian, but [Flathub][flathub-foliate]. same
+      problems as GNOME books finding my books (ie. it can't).
     * [Buka][] is another "ebook" manager written in Javascript, but
       only supports PDFs for now
 
+[flathub-bookworm]: https://www.flathub.org/apps/details/com.github.babluboy.bookworm
 [Buka]: https://github.com/oguzhaninan/Buka
 [flathub-foliate]: https://www.flathub.org/apps/details/com.github.johnfactotum.Foliate
 [Foliate]: https://johnfactotum.github.io/foliate/

fix link and link to mail
diff --git a/blog/2016-05-12-email-setup.mdwn b/blog/2016-05-12-email-setup.mdwn
index 8eccc342..fb23f2e5 100644
--- a/blog/2016-05-12-email-setup.mdwn
+++ b/blog/2016-05-12-email-setup.mdwn
@@ -1,5 +1,7 @@
 [[!meta title="Notmuch, offlineimap and Sieve setup"]]
 
+Update: some of this configuration changed. See [[services/mail]].
+
 I've been using Notmuch since about 2011, switching away from Mutt to
 deal with the monstrous amount of emails I was, and still am dealing
 with on the computer. I have contributed a few patches and configs on
@@ -636,7 +638,7 @@ Critical parts are:
 
 The other settings should be self-explanatory.
 
- [Offlineimap]: http://www.offlineimap.org/
+ [OfflineIMAP]: http://www.offlineimap.org/
  [isync]: http://isync.sourceforge.net/
 
 RSS feeds

another answer
diff --git a/software/desktop/calibre/comment_11_fa465e23e6c4369a0aa81de3ae6dc875._comment b/software/desktop/calibre/comment_11_fa465e23e6c4369a0aa81de3ae6dc875._comment
new file mode 100644
index 00000000..05dbe2e9
--- /dev/null
+++ b/software/desktop/calibre/comment_11_fa465e23e6c4369a0aa81de3ae6dc875._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""comment 11"""
+ date="2019-10-07T13:34:10Z"
+ content="""
+> This appears to be an awful lot of effort to migrate from an open-source project. Perhaps that effort could be applied to helping out with the migration to Python3?  They have a working Beta now: https://github.com/kovidgoyal/calibre/pull/870
+>
+> You don't have to be a Python developer.  It would be helpful just having some willing beta-testers provide some feedback.  
+
+I actually *am* a Python developer. If Python 3 was the only problem with Calibre, I would totally and enthousiastically go that route. But as I explained in the blog post, there are other problems here.
+
+Also, there's only so much time in the day. I am already involved in another major Python 3 conversion in a program we salvaged from being abandoned by its maintainer ([linkchecker][]) and it's basically taking all of my free time at that level right now. I have my own programs I need to port to Python 3. So, sorry, but I don't have (free or paid, actually) time to offer to the Calibre community right now. But you should know that I did contribute quite a few times in the community (bug reports, security backports and patches). My experience then wasn't as great as I would have liked and I prefer not to get involved anymore.
+
+ [linkchecker]: https://github.com/linkchecker/linkchecker/
+
+> Either way, thanks for providing a roadmap of comparable software.  I personally don't want to switch from Calibre, but seeing the alternatives is always helpful for finding ways to improve.
+
+Thanks! That's the spirit with which I'm writing this. I might end up continuing to use Calibre myself too!
+"""]]

remove duplicate comment
diff --git a/software/desktop/calibre/comment_10_6a5852087614c10cc4e8934212fe74c3._comment b/software/desktop/calibre/comment_10_6a5852087614c10cc4e8934212fe74c3._comment
deleted file mode 100644
index aa4d498e..00000000
--- a/software/desktop/calibre/comment_10_6a5852087614c10cc4e8934212fe74c3._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- ip="71.136.138.224"
- claimedauthor="Jim Sorenson"
- subject="Replace vs Fix"
- date="2019-10-07T06:13:38Z"
- content="""
-This appears to be an awful lot of effort to migrate from an open-source project. Perhaps that effort could be applied to helping out with the migration to Python3?  They have a working Beta now: https://github.com/kovidgoyal/calibre/pull/870
-
-You don't have to be a Python developer.  It would be helpful just having some willing beta-testers provide some feedback.  
-
-Either way, thanks for providing a roadmap of comparable software.  I personally don't want to switch from Calibre, but seeing the alternatives is always helpful for finding ways to improve.
-
-- Jim
-"""]]

Added a comment
diff --git a/software/desktop/calibre/comment_11_4775bdfd0e135631f8076c52af31ac45._comment b/software/desktop/calibre/comment_11_4775bdfd0e135631f8076c52af31ac45._comment
new file mode 100644
index 00000000..3aeea379
--- /dev/null
+++ b/software/desktop/calibre/comment_11_4775bdfd0e135631f8076c52af31ac45._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ ip="132.206.154.8"
+ claimedauthor="mvc"
+ subject="comment 11"
+ date="2019-10-07T12:58:41Z"
+ content="""
+I have only used the latest stable fbreader Android app, which is proprietary but still actively maintained, and for me \"just works\". When the project went closed source in 2015 a free software fork targeting Android was created, but I've never tried it: https://gitlab.com/axet/android-book-reader
+
+The free app's bookshelf view was a little annoying, but as I said I was happy to give the developer a small sum of money for the \"premium\" version with a better collection viewer.
+
+I'm not surprised that PDF reflowing would be impossible in the general case for a multicolumn document, but I'm hoping they'll come up with something workable for some of the lengthy books I want to read that were only available in PDF format from the local library. At least I can borrow the physical books if needed!
+"""]]

Added a comment: Higher quality YouTube is DASH-only
diff --git a/blog/2019-10-06-native-apps-matter/comment_2_c34776c405292a5222db913af4560d18._comment b/blog/2019-10-06-native-apps-matter/comment_2_c34776c405292a5222db913af4560d18._comment
new file mode 100644
index 00000000..0da5bbd6
--- /dev/null
+++ b/blog/2019-10-06-native-apps-matter/comment_2_c34776c405292a5222db913af4560d18._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ ip="213.219.166.29"
+ claimedauthor="Frans"
+ url="https://fransdejonge.com"
+ subject="Higher quality YouTube is DASH-only"
+ date="2019-10-07T08:09:01Z"
+ content="""
+Unless something changed recently, VLC is limited to 720p. That won't truly affect any conclusions, but for a completely fair comparison you'd have to take down YT to 720p, specifically in mp4 so any potential hardware acceleration can do its job on the browser too. On Chromia you might have to flip a flag to enable that at all.
+
+Alternatively and for a better video viewing experience, you can download or pipe better quality video/audio with youtube-dl.
+
+```
+$ youtube-dl -F \"https://www.youtube.com/watch?v=tyOHcXKlyU8\"  
+[youtube] tyOHcXKlyU8: Downloading webpage
+[youtube] tyOHcXKlyU8: Downloading video info webpage
+WARNING: Unable to extract video title
+[info] Available formats for tyOHcXKlyU8:
+format code  extension  resolution note
+249          webm       audio only DASH audio   60k , opus @ 50k, 6.30MiB
+250          webm       audio only DASH audio   86k , opus @ 70k, 8.18MiB
+140          m4a        audio only DASH audio  131k , m4a_dash container, mp4a.40.2@128k, 15.53MiB
+251          webm       audio only DASH audio  164k , opus @160k, 15.87MiB
+160          mp4        256x144    144p  109k , avc1.4d400c, 24fps, video only, 6.70MiB
+278          webm       256x144    144p  118k , webm container, vp9, 24fps, video only, 11.36MiB
+242          webm       426x240    240p  229k , vp9, 24fps, video only, 13.57MiB
+133          mp4        426x240    240p  294k , avc1.4d4015, 24fps, video only, 12.39MiB
+243          webm       640x360    360p  401k , vp9, 24fps, video only, 22.38MiB
+134          mp4        640x360    360p  579k , avc1.4d401e, 24fps, video only, 22.12MiB
+244          webm       854x480    480p  703k , vp9, 24fps, video only, 32.00MiB
+135          mp4        854x480    480p  809k , avc1.4d401e, 24fps, video only, 31.22MiB
+136          mp4        1280x720   720p 1125k , avc1.4d401f, 24fps, video only, 46.40MiB
+247          webm       1280x720   720p 1242k , vp9, 24fps, video only, 53.06MiB
+248          webm       1920x1080  1080p 2642k , vp9, 24fps, video only, 152.24MiB
+137          mp4        1920x1080  1080p 3770k , avc1.640028, 24fps, video only, 161.78MiB
+43           webm       640x360    medium , vp8.0, vorbis@128k, 83.67MiB
+18           mp4        640x360    medium  460k , avc1.42001E, mp4a.40.2@ 96k (44100Hz), 55.23MiB
+22           mp4        1280x720   hd720 1428k , avc1.64001F, mp4a.40.2@192k (44100Hz) (best)
+```
+
+If I right click on a YouTube video and click \"stats for nerds,\"  I find that it typically prefers to send VP9 with Opus. The Opus stream (251) provides the best audio.
+
+In my case, to match what YouTube sends to my browser I have to use something like this:
+
+```
+$ youtube-dl -f 248+251 \"https://www.youtube.com/watch?v=tyOHcXKlyU8\"
+```
+
+Play that back in VLC or mpv and you'll find it uses a lot more CPU. By contrast, force YouTube to use 720p with H.264 for hardware acceleration and it'll use less. The difference should still be pronounced, mind you, but not quite by an order of magnitude.
+"""]]

Added a comment: Replace vs Fix
diff --git a/software/desktop/calibre/comment_10_6a5852087614c10cc4e8934212fe74c3._comment b/software/desktop/calibre/comment_10_6a5852087614c10cc4e8934212fe74c3._comment
new file mode 100644
index 00000000..aa4d498e
--- /dev/null
+++ b/software/desktop/calibre/comment_10_6a5852087614c10cc4e8934212fe74c3._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ ip="71.136.138.224"
+ claimedauthor="Jim Sorenson"
+ subject="Replace vs Fix"
+ date="2019-10-07T06:13:38Z"
+ content="""
+This appears to be an awful lot of effort to migrate from an open-source project. Perhaps that effort could be applied to helping out with the migration to Python3?  They have a working Beta now: https://github.com/kovidgoyal/calibre/pull/870
+
+You don't have to be a Python developer.  It would be helpful just having some willing beta-testers provide some feedback.  
+
+Either way, thanks for providing a roadmap of comparable software.  I personally don't want to switch from Calibre, but seeing the alternatives is always helpful for finding ways to improve.
+
+- Jim
+"""]]

Added a comment: Replace vs Fix
diff --git a/software/desktop/calibre/comment_9_21f2ff88eed237f7b995d831cc4024ce._comment b/software/desktop/calibre/comment_9_21f2ff88eed237f7b995d831cc4024ce._comment
new file mode 100644
index 00000000..6a4ac3a3
--- /dev/null
+++ b/software/desktop/calibre/comment_9_21f2ff88eed237f7b995d831cc4024ce._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ ip="71.136.138.224"
+ claimedauthor="Jim Sorenson"
+ subject="Replace vs Fix"
+ date="2019-10-07T06:10:44Z"
+ content="""
+This appears to be an awful lot of effort to migrate from an open-source project. Perhaps that effort could be applied to helping out with the migration to Python3?  They have a working Beta now: https://github.com/kovidgoyal/calibre/pull/870
+
+You don't have to be a Python developer.  It would be helpful just having some willing beta-testers provide some feedback.  
+
+Either way, thanks for providing a roadmap of comparable software.  I personally don't want to switch from Calibre, but seeing the alternatives is always helpful for finding ways to improve.
+
+- Jim
+"""]]

Added a comment: video acceleration
diff --git a/blog/2019-10-06-native-apps-matter/comment_1_e58b9d616608b35a80c260d7d531c6ed._comment b/blog/2019-10-06-native-apps-matter/comment_1_e58b9d616608b35a80c260d7d531c6ed._comment
new file mode 100644
index 00000000..1ae6d2a0
--- /dev/null
+++ b/blog/2019-10-06-native-apps-matter/comment_1_e58b9d616608b35a80c260d7d531c6ed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ ip="72.239.24.37"
+ claimedauthor="deccelerator"
+ subject="video acceleration"
+ date="2019-10-07T05:47:00Z"
+ content="""
+Isn't this because VLC can take advantage of VA-API for hardware accelerated decoding? Where as Firefox has no support and Chromium requires an out-of-tree patch.
+"""]]

so much software out there
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 7ba83d15..baf15123 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -119,7 +119,22 @@ Calibre is...
       older Firefox releases (or "[Pale moon][]", a Firefox fork)
     * [koreader][] and [plato][] are good alternatives for the Kobo
       reader (although koreader also now has builds for Debian)
-
+    * [GNOME Books][] is interesting, but relies on the GNOME search
+      engine and doesn't find my books (and instead lots of other
+      garbage). it's been described as "basic" and "the least mature"
+      in [this OMG Ubuntu review][]
+    * [Bookworm][] looks very promising
+    * [Foliate][] looks gorgeous and is built on top of the ePUB.js
+      library, not in Debian, but [Flathub][flathub-foliate]
+    * [Buka][] is another "ebook" manager written in Javascript, but
+      only supports PDFs for now
+
+[Buka]: https://github.com/oguzhaninan/Buka
+[flathub-foliate]: https://www.flathub.org/apps/details/com.github.johnfactotum.Foliate
+[Foliate]: https://johnfactotum.github.io/foliate/
+[this OMG Ubuntu review]: https://www.omgubuntu.co.uk/2017/07/best-ebook-reader-app-ubuntu
+[GNOME Books]: https://wiki.gnome.org/Apps/Books
+[Bookworm]: https://babluboy.github.io/bookworm/
 [Pale moon]: https://www.palemoon.org/
 [plato]: https://github.com/baskerville/plato/
 [koreader]: https://github.com/koreader/koreader/

clarify what lucidor actually is (a firefox extension)
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 7190138e..7ba83d15 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -115,10 +115,12 @@ Calibre is...
     * [coolreader][] is another alternative, [not yet in Debian
       (#715470)][]
     * [lucidor][] also looks interesting, but is not packaged in
-      Debian either (although upstream provides a .deb)
+      Debian either (although upstream provides a .deb) and depends on
+      older Firefox releases (or "[Pale moon][]", a Firefox fork)
     * [koreader][] and [plato][] are good alternatives for the Kobo
       reader (although koreader also now has builds for Debian)
 
+[Pale moon]: https://www.palemoon.org/
 [plato]: https://github.com/baskerville/plato/
 [koreader]: https://github.com/koreader/koreader/
 [Okular]: https://okular.kde.org/

many comments, many answers
diff --git a/software/desktop/calibre/comment_8_42a4785ddbcc3729cc5499aa9f75299e._comment b/software/desktop/calibre/comment_8_42a4785ddbcc3729cc5499aa9f75299e._comment
new file mode 100644
index 00000000..0a350f74
--- /dev/null
+++ b/software/desktop/calibre/comment_8_42a4785ddbcc3729cc5499aa9f75299e._comment
@@ -0,0 +1,83 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""many comments"""
+ date="2019-10-07T03:18:43Z"
+ content="""
+Hi everyone! Thanks for the many comments! I'll respond to the last few all together...
+
+***toton re okular***: thanks! that's what i was looking for, and I
+confirm it works. I updated the article accordingly
+
+***monkey re git-annex***: git-annex might provide the faceted search
+functionality that Calibre provides but, to be honest, my luck with
+git-annex metadata has been hit and miss. It kind of works, but for
+large collections, it's slow as it needs to rebuild the worktree every
+time you "search" something. And the user experience is really not
+that great: I often get confused between git branching commands and
+git-annex metadata commands, so much so that I quickly have no idea
+what's going on anymore...
+
+***john re Kindles***: honestly, I don't consider Kindles as part of
+my workflow. I completely boycott Amazon as a company for various
+reasons aside from the ebook problems, but specifically their attitude
+regarding contents on their devices has been problematic, to say the
+least. I understand it was to respond to a copyright litigation, but
+they did delete Orwell's 1984 and Animal Farm from every Kindle device
+out there. They are also very aggressive in creating hurdles for us to
+work with their devices, as you aptly described.
+
+So while they are shiny and enticing, hardware-wise, I don't consider
+them as part of my use-case model. So yes, I'm digging in my heels and
+I focus on standard contents: the hardware providers that do *not*
+follow that model shouldn't be encouraged with our wallets. I know
+it's not very helpful to the large number of Amazon users, but then
+again, I don't feel like going out of my way to help you people
+either. ;)
+
+(And, generally, **people shouldn't feel the need to defend Calibre or
+apologize for defending it**. Again, I have used Calibre for almost a
+decade (probably around 7 years now, according to the first bug
+report), and I feel *grateful* for the services it has given (and
+still is!) giving me. So I didn't mean to write this as an attack on
+Calibre, but mostly as an exploration of how parts (or all) of it
+could be replace, if that's needed for people. It's maybe unfortunate
+that I started with a rather critical section, but I felt it was
+important to explain why I was considering this in the first place,
+And, I have to be honest, I kind of had a chip on my shoulder with
+Calibre for a while, having dealt with it through the Debian LTS
+security work and numerous bug reports.)
+
+**mvc re fbreader**: so I've tried fbreader again and again, and I can
+never get used to it. It's installed on my phone, as a PDF reader, and
+I also have it on this laptop. Neither works very well. The phone
+version has this weird "bookshelf" browser that looks like a an wooden
+bookshelf, which is not very useful but does looks pretty. Similarly,
+the user interface on the desktop is ... really confusing to me. There
+a bunch of small buttons on top without any labels... Kind of hard to
+use.
+
+The desktop version of fbreader here taks over 30 seconds to
+start. When I finally managed to find how to tell it where my book
+collection is, it crashed after a few seconds of walking the tree,
+with an epic segfault ([[!debbug 941886]]):
+
+    oct 06 23:17:13 angela kernel: FBReader[16757] segfault at 8 ip 00007fb8e62800a2 sp 00007ffd84099070 error 4 in libzlcore.so.0.12.10[7fb8e626f000+54000] 
+    oct 06 23:17:13 angela kernel: Code: 8b 7c 24 30 48 8d 43 30 48 39 c7 74 05 e8 e6 06 ff ff 48 8b 7c 24 10 48 83 c3 10 48 39 df 74 05 e8 d3 06 ff ff 48 8b 44 24 08 <48> 8b 78 08 e8 05 f0 fe ff 48 89 ee 48 89 c7 e8 aa 01 ff ff 48 8b 
+
+I was able to workaround the problem and I *do* have a library browser
+now, so that's pretty cool. I also like that there's an easy way to
+add books in there...
+
+It also looks like fbreader is severely out of date in Debian
+([[!debbug 765039]]): it has been shipping version 0.12 forever now,
+while upstream is at 0.99. Which version are you using? Even then,
+that version is over 3 years old now, and it seems fbreader turned
+proprietary in 2015...
+
+As for PDF reflows, I have found this generally never works. I have
+*never* found PDFs to be *reflowable*, that's just basically an
+impossible problem to solve, especially with LaTeX-like, scientific,
+two-column articles. The best, for this, is to just read the PDF on a
+bigger screen, and for that those bigger e-readers are just great,
+albeit expensive.
+"""]]

Added a comment: fbreader has a collection browser & device sync'ing
diff --git a/software/desktop/calibre/comment_7_06dae7ff884d9d42484d6080b0e089cd._comment b/software/desktop/calibre/comment_7_06dae7ff884d9d42484d6080b0e089cd._comment
new file mode 100644
index 00000000..e65f80ae
--- /dev/null
+++ b/software/desktop/calibre/comment_7_06dae7ff884d9d42484d6080b0e089cd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ ip="107.190.36.196"
+ claimedauthor="mvc"
+ subject="fbreader has a collection browser & device sync'ing"
+ date="2019-10-07T02:50:13Z"
+ content="""
+Thanks for the info on Calibre; it seemed overengineered to me and you've just confirmed that. That said, I haven't used it since discovering fbreader.
+
+fbreader has a fine collection browser, although on mobile you have to pay a small amount to get the version of the app which shows cover images (I did this only to support the developer). If you're willing to use Google Drive it also does device synchronization; you upload at https://books.fbreader.org and then can download to any device. It also reads several formats (epub, mobi, fb2, CBR, PDF...), so no need for conversion. My main complaint is that it doesn't reflow text in PDFs, which is annoying when reading on the small screen on my phone, but that feature's on the short-term roadmap.
+
+I know this app is less useful to people who want to use an actual ereader and/or don't want to store their books with Google, but for others it's worth considering.
+"""]]

Added a comment: Another perspective
diff --git a/software/desktop/calibre/comment_6_755401e4d6296d02f014fa0368ecaf65._comment b/software/desktop/calibre/comment_6_755401e4d6296d02f014fa0368ecaf65._comment
new file mode 100644
index 00000000..8012ad3a
--- /dev/null
+++ b/software/desktop/calibre/comment_6_755401e4d6296d02f014fa0368ecaf65._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ ip="96.44.142.194"
+ claimedauthor="John Goerzen"
+ url="https://changelog.complete.org"
+ subject="Another perspective"
+ date="2019-10-07T01:53:45Z"
+ content="""
+Hi,
+
+Thanks for writing this.  So I have a Kindle, which doesn't support ePub at all.  I have used Calibre at times over the years; the organization it imposes over a collection is very good, but the formatting changes in makes and the things it does during \"synchronization\" are not.  I have mostly stopped using it because it is too cumbersome, though I do invoke ebook-viewer manually from time to time.  Critically, though, Calibre does provide mobi-to-epub conversion and better support for the newer formats Amazon keeps burdening us with than most other tools.  So if I were to switch to another tool, I'd have to start with Calibre and the other tool would be useful only for reading things on a PC screen (a thing I only do occasionally with ePub-type books) and not at all useful for reading things on my Kindle (a thing I do often).
+
+This is not a defense of Calibre; I know of its quality problems first-hand, but just to say that anything that is ePub-centric is totally unhelpful to a large segment of people.
+"""]]

Added a comment: git-annex metadata
diff --git a/software/desktop/calibre/comment_5_8a0d7b8c032e0b890b571386104e5b90._comment b/software/desktop/calibre/comment_5_8a0d7b8c032e0b890b571386104e5b90._comment
new file mode 100644
index 00000000..07a84ae2
--- /dev/null
+++ b/software/desktop/calibre/comment_5_8a0d7b8c032e0b890b571386104e5b90._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ ip="73.223.196.139"
+ claimedauthor="Pig Monkey"
+ url="https://pig-monkey.com"
+ subject="git-annex metadata"
+ date="2019-10-07T01:15:52Z"
+ content="""
+I've often thought that one of these days I should write a script that would parse through Calibre's `metadata.opf` file for each book and add it to the git-annex metadata of the ebook file. This would allow you to do all sorts of browsing, filtering and searching with git-annex's own powerful tooling, which is probably better than anything we could do today with Calibre itself (assuming you don't need a GUI).
+
+But the problem is getting the metadata in the first place which, as you pointed out, is one of the things that Calibre does pretty well. For my video collection, I wrote [metamovie](https://github.com/pigmonkey/metamovie/) to pull down metadata of movies and television shows from IMDB and store it as git-annex metadata. I suspect that it wouldn't be too difficult to hack together a similar script, using something like Google Books or Goodreads as the source. The difficult part is probably the search. With movies there is a single canonical entry, but with books you may have dozen of editions. Choosing the right one (or the one with the richest data, even if it doesn't exactly match your edition) could be a bit tricky.
+"""]]

Added a comment
diff --git a/software/desktop/calibre/comment_4_332d247445d56fdc66711a3de031fcf0._comment b/software/desktop/calibre/comment_4_332d247445d56fdc66711a3de031fcf0._comment
new file mode 100644
index 00000000..410f053b
--- /dev/null
+++ b/software/desktop/calibre/comment_4_332d247445d56fdc66711a3de031fcf0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="109.190.84.43"
+ claimedauthor="tonton"
+ subject="comment 4"
+ date="2019-10-07T00:36:13Z"
+ content="""
+For okular on Debian, the epub plugin is in the okular-extra-backends package.
+Can't tell you if it works fine (I don't use ebooks) but I can open epubs.
+"""]]

backtrack a little on python 3 support
Calibre 4 does support py3, it is plugins that are missing.
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index eeb52fe4..7190138e 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -54,11 +54,27 @@ However, it has had many problems over the years:
    mounting partitions][] which upstream refused to fix properly even
    after a [LWN article][] came out about it.
 
- * **No support for Python 3**. because of this, Calibre was [removed from
-   Debian in 2019][] ([[!debbug 936270]]). Now a there is [port in
-   progress][], but the author infamously claimed it wasn't necessary
-   to port to Python3 because he could [maintain Python 2 himself][]
-
+ * **Incomplete Python 3 support**. because of this, Calibre 4.0 was
+   [removed from Debian in 2019][] ([[!debbug 936270]]). Now a there
+   is [port in progress][] which is going well: only the plugins and
+   the ebook-viewer are blocking progress right now. In the past, the
+   author infamously claimed it wasn't necessary to port to Python3
+   because he could [maintain Python 2 himself][], but it seems he
+   backtracked on that position since then.
+
+Update: a previous version of that post claimed that all of Calibre
+had been removed from Debian. This was inaccurate, as the [Debian
+Calibre maintainer pointed out][]. What happened was [Calibre 4.0 was
+uploaded to Debian unstable][], then [broke][] because of missing
+Python 2 dependencies, and an [older version (3.48) was uploaded in
+its place][]. So Calibre *will* stay around in Debian for the
+foreseeable future, hopefully, but the current latest version (4.0)
+cannot get in because it depends on older Python 2 libraries.
+
+[broke]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941802
+[older version (3.48) was uploaded in its place]: https://tracker.debian.org/news/1069605/accepted-calibre-400really348dfsg-1-source-into-unstable/
+[Calibre 4.0 was uploaded to Debian unstable]: https://tracker.debian.org/news/1069411/accepted-calibre-400dfsg-1-source-into-unstable/
+[Debian Calibre maintainer pointed out]: https://mastodon.social/@norbu/102918222761204651
 [LWN article]: https://lwn.net/Articles/465311/
 [legendary security bug about how Calibre handled mounting partitions]: https://bugs.launchpad.net/calibre/+bug/885027
 [in my experience]: https://lists.debian.org/87muy0usv1.fsf@curie.anarc.at
@@ -66,7 +82,7 @@ However, it has had many problems over the years:
 [port in progress]: https://github.com/kovidgoyal/calibre/blob/63f1996/README.python3
 [removed from Debian in 2019]: https://www.preining.info/blog/2019/10/rip-for-now-calibre-in-debian/
 
-The latest issue (lack of Python 3) is the last straw, for me. While
+The latest issue (Python 3) is the last straw, for me. While
 Calibe is an awesome piece of software, I can't help but think it's
 doing too much, and the wrong way. It's one of those tools that looks
 amazing on the surface, but when you look underneath, it's a monster

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

silly benchmark
diff --git a/blog/2019-10-06-native-apps-matter.mdwn b/blog/2019-10-06-native-apps-matter.mdwn
new file mode 100644
index 00000000..73cd3c2f
--- /dev/null
+++ b/blog/2019-10-06-native-apps-matter.mdwn
@@ -0,0 +1,47 @@
+[[!meta title="This is why native apps matter"]]
+
+I was just looking a web stream on Youtube today and was wondering why
+my CPU was so busy. So I fired up top and saw my web browser (Firefox)
+took up around 70% of a CPU to play the stream.
+
+I thought, "this must be some high resolution crazy stream!  how
+modern! such wow!" Then I thought, wait, this is the web, there must
+be something insane going on.
+
+So I did a little experiment: I started `chromium --temp-profile` on
+the stream, alongside `vlc` (which can also play Youtube
+streams!). Then I took a snapshot of the [top(1)][] command after 5
+minutes. Here are the results:
+
+[top(1)]: https://manpages.debian.org/top
+
+      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
+    16332 anarcat   20   0 1805160 269684 102660 S  60,2   1,7   3:34.96 chromium
+    16288 anarcat   20   0  974872 119752  87532 S  33,2   0,7   1:47.51 chromium
+    16410 anarcat   20   0 2321152 176668  80808 S  22,0   1,1   1:15.83 vlc
+     6641 anarcat   20   0   21,1g 520060 137580 S  13,8   3,2  55:36.70 x-www-browser
+    16292 anarcat   20   0  940340  83980  67080 S  13,2   0,5   0:41.28 chromium
+     1656 anarcat   20   0 1970912  18736  14576 S  10,9   0,1   4:47.08 pulseaudio
+     2256 anarcat   20   0  435696  93468  78120 S   7,6   0,6  16:03.57 Xorg
+    16262 anarcat   20   0 3240272 165664 127328 S   6,2   1,0   0:31.06 chromium
+      920 message+  20   0   11052   5104   2948 S   1,3   0,0   2:43.37 dbus-daemon
+    17915 anarcat   20   0   16664   4164   3276 R   1,3   0,0   0:02.07 top
+
+To deconstruct this, you can see my Firefox process (masquerading as
+`x-www-browser`) which has been started for a long time. It's taken 55
+hours of CPU time, but let's ignore that for now as it's not in the
+benchmark. What I find fascinating is there are at least 4 chromium
+processes running here, and they collectively take up over 7 minutes
+of CPU time.
+
+Compare this a little over *one* (1!!!11!!!) minute of CPU time for
+VLC, and you realize why people are so ranty about everything being
+packaged as web apps these days. It's basically using up an order of
+magnitudes more processing power (and therefore electric power and
+slave labor) to watch those silly movies in your web browsers than in
+a proper video player.
+
+Keep that in mind next time you let Youtube go on a "autoplay Donald
+Drumpf" playlist...
+
+[[!tag web performance silly debian-planet benchmark]]

link to mastodon
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index aedc6572..eeb52fe4 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -224,3 +224,6 @@ easier to run Calibre headless, in a virtual machine or remote server
 for extra isoluation, for example.
 
 [[!tag blog debian-planet python ebook python-planet python archive wallabako git-annex wallabag]]
+
+Update: this post generated some activity on Mastodon, [follow the
+conversation here or on your favorite Mastodon instance](https://social.weho.st/@anarcat/102917682883043910).

another thing
diff --git a/software/desktop/calibre/comment_3_dfbfbefc7fb07f0079e9f2d140d0fc2a._comment b/software/desktop/calibre/comment_3_dfbfbefc7fb07f0079e9f2d140d0fc2a._comment
new file mode 100644
index 00000000..07331174
--- /dev/null
+++ b/software/desktop/calibre/comment_3_dfbfbefc7fb07f0079e9f2d140d0fc2a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""already used tools"""
+ date="2019-10-06T23:50:44Z"
+ content="""
+Another thing to understand about this list of tools is that I already use a lot of those. I already:
+
+ * use Sphinx and Sigil to work with eBooks
+ * manage and synchronize my library across multiple devices with git-annex
+ * read PDFs with Evince (which Atril is derived from)
+ * read RSS feeds with another feed reader
+
+It's not like I'm hell-bent on causing the Calibre people pain here. :) It's just that I found too many problems with the software, and now it's possibly going away so I'm looking at alternatives. I thought I could share this with the community, if you don't like the answers, you're free to talk a walk elsewhere and keep on happily using Calibre, blissfully unaware of any problems I might be ranting about here. :p
+"""]]

update: played with liber a bit
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index ae42db07..aedc6572 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -153,7 +153,17 @@ Calibre is...
    solving that problem. The [Liber][] web server, however, does
    provide similar search and metadata functionality. It also supports
    migrating from an existing Calibre database as it can read the
-   Calibre metadata stores.
+   Calibre metadata stores. When no metadata is found, it fetches some
+   from online sources (currently Google Books).
+
+   One major limitation of Liber in this context is that it's solely
+   search-driven: it will not allow you to see (for example) the
+   "latest books added" or "browse by author". It also doesn't support
+   "uploading" books although it will incrementally pick up new books
+   added by hand in the library. It somewhat assumes Calibre already
+   exists, in a way, to properly curate the library and is more
+   designed to be a search engine and book sharing system between
+   liber instances.
 
    This also connects with the more general "book inventory" problem I
    have which involves an inventory physical books and directory of

Added a comment: maybe
diff --git a/software/desktop/calibre/comment_2_9740d0d91d893fcdb7ec4f05a967877a._comment b/software/desktop/calibre/comment_2_9740d0d91d893fcdb7ec4f05a967877a._comment
new file mode 100644
index 00000000..b3f6c613
--- /dev/null
+++ b/software/desktop/calibre/comment_2_9740d0d91d893fcdb7ec4f05a967877a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="https://seccdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="maybe"
+ date="2019-10-06T23:25:58Z"
+ content="""
+maybe you're right. maybe the result will be too complex and buggy and will not be useful. but the reality of the problem now is that Calibre 4.0 is not going to make it to Debian until it's ported to Python 3. And even if it does, I have enough serious concerns about the security of Calibre to never want to use it again. It would need to go through a full audit, with a significant overhaul of its design and architecture, for me to ever trust it again.
+
+I strongly doubt that the tools I have enumerated in my review will be as buggy and insecure as Calibre. Maybe I'll be proven wrong, but so far, many of those tools have proven to be well maintained and perform extremely well.
+
+I feel it's definitely worth a try.
+
+(I am also unsure as to which package you're refering to when you say \"now that well maintained\"...)
+"""]]

Added a comment
diff --git a/software/desktop/calibre/comment_1_2f5d6d59af2c27902fbe63b240dd5410._comment b/software/desktop/calibre/comment_1_2f5d6d59af2c27902fbe63b240dd5410._comment
new file mode 100644
index 00000000..bfc46a41
--- /dev/null
+++ b/software/desktop/calibre/comment_1_2f5d6d59af2c27902fbe63b240dd5410._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ ip="190.244.169.52"
+ claimedauthor="Carlos"
+ subject="comment 1"
+ date="2019-10-06T23:02:24Z"
+ content="""
+> Calibre is a complex piece of machinery, and it's therefore buggy.
+
+So you're going to replace it with 6 or 7 pieces of machinery, some of them complex, some of them buggy, some of them now that well maintained.
+"""]]

fix broken link
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 2f87b971..ae42db07 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -115,7 +115,7 @@ Calibre is...
 [Atril]: https://tracker.debian.org/pkg/atril
 [ebook-viewer]: https://manpages.debian.org/ebook-viewer
 
- * an **ebook editor**: Calibre also ships with an [ebook-editor][]
+ * an **ebook editor**: Calibre also ships with an [ebook-edit][]
    command, which allows you to do all sorts of nasty things to your
    ebooks. I have rarely used this tool, having found it hard to use
    and not giving me the results I needed, in my use case (which was
@@ -127,7 +127,7 @@ Calibre is...
 
 [Sphinx documentation system]: http://www.sphinx-doc.org/
 [Sigil]: https://sigil-ebook.com/
-[ebook-editor]: https://manpages.debian.org/ebook-editor
+[ebook-edit]: https://manpages.debian.org/ebook-edit
 
  * a **file converter**: Calibre can convert between many ebook
    formats, to accomodate the various readers. In my experience, this

mupdf is awesome
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index ce4f940c..2f87b971 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -8,7 +8,7 @@ Summary
 TL;DR: I'm considering replacing those various [Calibre][] compnents with...
 
  * ebook-viewer: using a Kobo or other ebook reader, possibly
-   [Atril][] on the desktop?
+   [Atril][] or [MuPDF][] on the desktop?
  * ebook-editor: [Sigil][].
  * collection browser: [Liber][]? see also [[services/bookmarks]]
  * device synchronisation: [git-annex][]?
@@ -90,7 +90,7 @@ Calibre is...
 
     * [Atril][], MATE's version of Evince, supports ePUBs (Evince
       doesn't)
-    * [MuPDF][] also reads ePUBs without problems
+    * [MuPDF][] also reads ePUBs without problems and is really fast
     * [fbreader][] also supports ePUBs, but is much slower than all
       those others
     * Emacs (of course) supports ebooks through [nov.el][]

add toc
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index f22153d4..ce4f940c 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -1,5 +1,7 @@
 [[!meta title="Calibre replacement considerations"]]
 
+[[!toc levels=2]]
+
 Summary
 =======
 

s/archiving/archive
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 9a753f8d..f22153d4 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -211,4 +211,4 @@ limited exposure to other security issues. It would also make it
 easier to run Calibre headless, in a virtual machine or remote server
 for extra isoluation, for example.
 
-[[!tag blog debian-planet python ebook archiving python-planet python ebook archive wallabako git-annex wallabag]]
+[[!tag blog debian-planet python ebook python-planet python archive wallabako git-annex wallabag]]
diff --git a/tag/archiving.mdwn b/tag/archiving.mdwn
deleted file mode 100644
index 3359884e..00000000
--- a/tag/archiving.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-[[!meta title="pages tagged archiving"]]
-
-[[!inline pages="tagged(archiving)" actions="no" archive="yes"
-feedshow=10]]

add ebook
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index d36c7227..9a753f8d 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -211,4 +211,4 @@ limited exposure to other security issues. It would also make it
 easier to run Calibre headless, in a virtual machine or remote server
 for extra isoluation, for example.
 
-[[!tag blog debian-planet python ebook archiving python-planet python archive wallabako git-annex wallabag]]
+[[!tag blog debian-planet python ebook archiving python-planet python ebook archive wallabako git-annex wallabag]]

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

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

turn this into a blog
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 677c97b3..d36c7227 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -1,49 +1,58 @@
-[Calibre][] is amazing software: it works on Windows and Linux, and allows
-one to manage ebooks on your desktop and a multitude of ebook
-readers.
-
-[Calibre]: https://calibre-ebook.com/
+[[!meta title="Calibre replacement considerations"]]
 
 Summary
 =======
 
-TL;DR: I'm considering replacing those various Calibre compnents with...
+TL;DR: I'm considering replacing those various [Calibre][] compnents with...
 
  * ebook-viewer: using a Kobo or other ebook reader, possibly
    [Atril][] on the desktop?
  * ebook-editor: [Sigil][].
  * collection browser: [Liber][]? see also [[services/bookmarks]]
- * device synchronisation: git-annex?
+ * device synchronisation: [git-annex][]?
  * RSS reader: [feed2exec][], [wallabako][]
  * ebook web server: [Liber][]?
 
+[git-annex]: https://git-annex.branchable.com/
+
 See below why and a deeper discussion on all the features.
 
 Problems with Calibre
 =====================
 
-It has, however, had many problems over the years:
+[Calibre][] is an amazing software: it allows users to manage ebooks
+on your desktop and a multitude of ebook readers. It's used by Linux
+geeks as well as Windows power-users and vastly surpasses any native
+app shipped by ebook manufacturers. I know almost exactly zero people
+that have an ebook reader that do *not* use Calibre.
+
+[Calibre]: https://calibre-ebook.com/
+
+However, it has had many problems over the years:
 
- * Calibre's inclusion inside Debian has been bumpy in itself, it
-   ships embedded libraries ([[!debbug 872595]], [[!debbug 704977]],
-   [[!debbug 684229]], [[!debbug 555352]], [[!debbug 555368]],
-   [[!debbug 700838]], most fixed in Debian), sometimes with security issues
-   ([[!debbug 873660]], [[!debbug 787085]])
+ * Calibre is a **complex** piece of machinery, and it's therefore
+   **buggy**. It manages to simultaneously ship with **embedded
+   libraries** ([[!debbug 872595]], [[!debbug 704977]], [[!debbug
+   684229]], [[!debbug 555352]], [[!debbug 555368]], [[!debbug
+   700838]], most fixed in Debian) and also suffer from the **NIH
+   syndrome*. For example, it implement its own web framework instead
+   of reusing stuff like requests or flask.
 
- * There are numerous security issues in Calibre. For example, it can
+ * There are **numerous security issues in Calibre**. For example, it can
    execute arbitrary code while fetching news ([[!debbug 873795]]) or
    plugin updates ([[!debbug 640026]]), it would phone home ([[!debbug
    584334]], fixed in Debian), allowed arbitrary file access via
    crafted files ([[!debbug 853004]], [[!debbug 608822]]), arbitrary
    code execution in bookmark data ([[!debbug 892242]]), and XSS vuln
-   ([[!debbug 608822]]). Some of those issues have been fixed upstream
-   but, [in my experience][], it's clear that upstream does not take
-   security seriously at all. The best example is probably the
-   [legendary security bug about how Calibre handled mounting
-   partitions][] which upstream refused to fix properly even after a
-   [LWN article][] came out about it.
-
- * No support for Python 3. because of this, Calibre was [removed from
+   ([[!debbug 608822]]), or even insecure embedded libraries
+   ([[!debbug 873660]], [[!debbug 787085]]). Some of those issues have
+   been fixed upstream but, [in my experience][], it's clear that
+   **upstream does not take security seriously**. The best example is
+   probably the [legendary security bug about how Calibre handled
+   mounting partitions][] which upstream refused to fix properly even
+   after a [LWN article][] came out about it.
+
+ * **No support for Python 3**. because of this, Calibre was [removed from
    Debian in 2019][] ([[!debbug 936270]]). Now a there is [port in
    progress][], but the author infamously claimed it wasn't necessary
    to port to Python3 because he could [maintain Python 2 himself][]
@@ -57,10 +66,10 @@ It has, however, had many problems over the years:
 
 The latest issue (lack of Python 3) is the last straw, for me. While
 Calibe is an awesome piece of software, I can't help but think it's
-too much, and the wrong way. It's one of those tools that looks
+doing too much, and the wrong way. It's one of those tools that looks
 amazing on the surface, but when you look underneath, it's a monster
 that is impossible to maintain, a liability that is just bound to
-cause problems in the future.
+cause more problems in the future.
 
 What does Calibre do anyways
 ============================
@@ -89,7 +98,11 @@ Calibre is...
       (#715470)][]
     * [lucidor][] also looks interesting, but is not packaged in
       Debian either (although upstream provides a .deb)
+    * [koreader][] and [plato][] are good alternatives for the Kobo
+      reader (although koreader also now has builds for Debian)
 
+[plato]: https://github.com/baskerville/plato/
+[koreader]: https://github.com/koreader/koreader/
 [Okular]: https://okular.kde.org/
 [lucidor]: http://lucidor.org/lucidor/
 [coolreader]: http://list.xmodulo.com/cool-reader.html
@@ -140,17 +153,17 @@ Calibre is...
    migrating from an existing Calibre database as it can read the
    Calibre metadata stores.
 
-   This bridges with the more general "book inventory" problem which
-   also includes physical books and online articles. See also
-   [[firefox]] (Zotero section) and [[bookmarks]] for a longer
-   discussion of that problem.
+   This also connects with the more general "book inventory" problem I
+   have which involves an inventory physical books and directory of
+   online articles. See also [[firefox]] (Zotero section) and
+   [[bookmarks]] for a longer discussion of that problem.
 
  * a **device synchronization tool** : I mostly use Calibre to
    synchronize books with an ebook-reader. It can also automatically
    update the database on the ebook with relevant metadata
    (e.g. collection or "shelves"), although I do not really use that
    feature. I do like to use Calibre to quickly search and prune books
-   from by ebook reader, however. I might be able to use `git-annex`
+   from by ebook reader, however. I might be able to use [git-annex][]
    for this, however, given that I already use it to synchronize and
    backup my ebook collection in the first place...
 
@@ -159,9 +172,9 @@ Calibre is...
    continously generating new ebooks based on those feeds and I would
    never read them, because I would never find the time to transfer
    them to my ebook viewer in the first place. Instead, I use a
-   regular RSS feed reader (I ended up writing my own, [feed2exec][])
-   and when I find an article I like, I added it to [Wallabag][] which
-   gets sync'd to my reader using [wallabako][] (another tool I wrote)
+   regular RSS feed reader. I ended up writing my own, [feed2exec][])
+   and when I find an article I like, I add it to [Wallabag][] which
+   gets sync'd to my reader using [wallabako][], another tool I wrote.
 
 [Wallabag]: https://wallabag.org/en
 [wallabako]: https://gitlab.com/anarcat/wallabako
@@ -172,7 +185,7 @@ Calibre is...
    supports acting as an OPDS directory, which is kind of neat. There
    are, as far as I know, no alternative for such a system although
    there *are* servers to share and store ebooks, like [Trantor][] or
-   [Liber][]
+   [Liber][].
 
 [Liber]: https://git.autistici.org/ale/liber
 [Trantor]: https://gitlab.com/trantor/trantor
@@ -186,5 +199,16 @@ different computers, but I never used that feature.
 So there you go. It's a colossal task! And while it's great that
 Calibre does all those things, I can't help but think that it would be
 better if Calibre was split up in multiple components, each maintained
-separately. I would love to use *only* the document browser for
-example.
+separately. I would love to use *only* the document converter, for
+example. It's possible to do that on the commandline, but it still
+means I have the entire Calibre package installed.
+
+Maybe a simple solution, from Debian's point of view, would be to
+split the package into multiple components, with the GUI and web
+servers packaged separately from the commandline converter. This way I
+would be able to install only the parts of Calibre I need and have
+limited exposure to other security issues. It would also make it
+easier to run Calibre headless, in a virtual machine or remote server
+for extra isoluation, for example.
+
+[[!tag blog debian-planet python ebook archiving python-planet python archive wallabako git-annex wallabag]]

push tl;dr: on top
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 6218ec05..677c97b3 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -4,6 +4,21 @@ readers.
 
 [Calibre]: https://calibre-ebook.com/
 
+Summary
+=======
+
+TL;DR: I'm considering replacing those various Calibre compnents with...
+
+ * ebook-viewer: using a Kobo or other ebook reader, possibly
+   [Atril][] on the desktop?
+ * ebook-editor: [Sigil][].
+ * collection browser: [Liber][]? see also [[services/bookmarks]]
+ * device synchronisation: git-annex?
+ * RSS reader: [feed2exec][], [wallabako][]
+ * ebook web server: [Liber][]?
+
+See below why and a deeper discussion on all the features.
+
 Problems with Calibre
 =====================
 
@@ -173,14 +188,3 @@ Calibre does all those things, I can't help but think that it would be
 better if Calibre was split up in multiple components, each maintained
 separately. I would love to use *only* the document browser for
 example.
-
-Summary
-=======
-
- * ebook-viewer: using a Kobo or other ebook reader, possibly
-   [Atril][] on the desktop?
- * ebook-editor: [Sigil][].
- * collection browser: [Liber][]? see also [[services/bookmarks]]
- * device synchronisation: git-annex?
- * RSS reader: [feed2exec][], [wallabako][]
- * ebook web server: [Liber][]?

summarize way forward
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index f20018e7..6218ec05 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -173,3 +173,14 @@ Calibre does all those things, I can't help but think that it would be
 better if Calibre was split up in multiple components, each maintained
 separately. I would love to use *only* the document browser for
 example.
+
+Summary
+=======
+
+ * ebook-viewer: using a Kobo or other ebook reader, possibly
+   [Atril][] on the desktop?
+ * ebook-editor: [Sigil][].
+ * collection browser: [Liber][]? see also [[services/bookmarks]]
+ * device synchronisation: git-annex?
+ * RSS reader: [feed2exec][], [wallabako][]
+ * ebook web server: [Liber][]?

git-annex as file sync alternative
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index 7cc3db33..f20018e7 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -134,7 +134,10 @@ Calibre is...
    synchronize books with an ebook-reader. It can also automatically
    update the database on the ebook with relevant metadata
    (e.g. collection or "shelves"), although I do not really use that
-   feature.
+   feature. I do like to use Calibre to quickly search and prune books
+   from by ebook reader, however. I might be able to use `git-annex`
+   for this, however, given that I already use it to synchronize and
+   backup my ebook collection in the first place...
 
  * an **RSS reader**: I used this for a while to read RSS feeds on my
    ebook-reader, but it was pretty clunky. Calibre would be

zotero/wallabag/bookie status updates
diff --git a/services/bookmarks.mdwn b/services/bookmarks.mdwn
index 1d5050b1..486c86dd 100644
--- a/services/bookmarks.mdwn
+++ b/services/bookmarks.mdwn
@@ -7,22 +7,12 @@ Current alternatives
 
 Those are either just dead recently, or are still considered.
 
-Bookie
-------
+I'm currently using Wallabag to index my bookmarks and sync some
+articles to my ebook reader with [Wallabako][]. I am using Zotero for
+an inventory of my physical book collection and
+[[software/desktop/calibre]] for my ebook collection.
 
-Then I discovered Bookie, installed by a friend on <https://lib3.net/bookie>. It is pretty impressive: it keeps snapshots of pages and imported my whole bookmark collection *really* fast. Bookie is written in Python.
-
-The downsides?
-
- * not packaged in Debian (WNPP: [[!debbug 744306]])
- * [list of bugs i filed](https://github.com/bookieio/Bookie/issues/created_by/anarcat)
-  * [broken link in RSS search and weirdness in some links](https://github.com/bookieio/Bookie/issues/455)
-  * [read/unread status missing](https://github.com/bookieio/Bookie/issues/454)
- * [fetches favicons from Google](https://github.com/bookieio/Bookie/issues/453)
- * [doesn't integrate with regular bookmarks](https://github.com/bookieio/bookie-chrome/issues/3)
- * [weird duplicate tags issue](https://github.com/bookieio/bookie-chrome/issues/4)
- * [no private bookmarks](https://github.com/bookieio/Bookie/issues/187)
- * [no federation support](https://github.com/bookieio/Bookie/issues/10)
+[Wallabako]: https://gitlab.com/anarcat/wallabako
 
 Wallabag
 --------
@@ -34,9 +24,13 @@ Wallabag supports read/unread status and favorites, and also remember your readi
 Downsides:
 
  * not packaged in Debian (WNPP: [[!debbug 734753]])
- * not installed yet (!)
- * site is currently down (may 15th 2014, [archive.org mirror](http://web.archive.org/web/20140301211138/https://www.wallabag.org/))
  * written in PHP
+ * no tag intersection in searches
+
+See also all the [issues i commented on][] ([and in the app][]).
+
+[and in the app]: https://github.com/wallabag/wallabagger/issues?utf8=%E2%9C%93&q=involves%3Aanarcat
+[issues i commented on]: https://github.com/wallabag/wallabag/issues?utf8=%E2%9C%93&q=involves%3Aanarcat
 
 Zotero
 ------
@@ -125,3 +119,23 @@ Status.net
 ----------
 
 While using SemanticScuttle, I did a brief and feeble attempt at using the [Status.net](http://status.net/) bookmark support, which completely failed basically because I [couldn't import](http://status.net/open-source/issues/3596) my already huge bookmark collection.
+
+Bookie
+------
+
+Then I discovered Bookie, installed by a friend on <https://lib3.net/bookie>. It is pretty impressive: it keeps snapshots of pages and imported my whole bookmark collection *really* fast. Bookie is written in Python.
+
+The downsides?
+
+ * not packaged in Debian (WNPP: [[!debbug 744306]])
+ * [list of bugs i filed](https://github.com/bookieio/Bookie/issues/created_by/anarcat)
+  * [broken link in RSS search and weirdness in some links](https://github.com/bookieio/Bookie/issues/455)
+  * [read/unread status missing](https://github.com/bookieio/Bookie/issues/454)
+ * [fetches favicons from Google](https://github.com/bookieio/Bookie/issues/453)
+ * [doesn't integrate with regular bookmarks](https://github.com/bookieio/bookie-chrome/issues/3)
+ * [weird duplicate tags issue](https://github.com/bookieio/bookie-chrome/issues/4)
+ * [no private bookmarks](https://github.com/bookieio/Bookie/issues/187)
+ * [no federation support](https://github.com/bookieio/Bookie/issues/10)
+
+Update: bookie kind of died. The upstream project is dead and the main
+hosting service shutdown. My friend converted his instance to Wallabag.

move zotero details to the bookmarks page
diff --git a/services/bookmarks.mdwn b/services/bookmarks.mdwn
index 94fce803..1d5050b1 100644
--- a/services/bookmarks.mdwn
+++ b/services/bookmarks.mdwn
@@ -45,6 +45,25 @@ I'm using Zotero for my book collection, so I figured i could use it for my book
 
 The [Zotero dataserver][] was also too difficult to setup, and without a Debian package ([[!debbug 709925]]).
 
+Finally, Zotero is in an uncertain state because of the
+[[software/desktop/firefox]] XULocalypse, so I'm looking for
+replacements. Possible options include:
+
+ * [xapers](https://finestructure.net/xapers/)
+ * [pubs](https://github.com/pubs/pubs)
+ * [papis](https://github.com/papis/papis)
+
+This also overlaps with bookmarking software like:
+
+ * [Turtl](https://turtlapp.com/)
+ * [reminiscense](https://github.com/kanishka-linux/reminiscence)
+ * [bookmark-archiver](https://pirate.github.io/bookmark-archiver/)
+ * [Wallabag](https://wallabag.org/)
+ * [Buku](https://github.com/jarun/Buku)
+ * [Shiori](https://github.com/RadhiFadlillah/shiori)
+
+... and archival software in the [[WARC ecosystem|services/archive]].
+
  [Zotero dataserver]: https://www.zotero.org/support/dev/dataserver_setup
  [bug #15]: https://github.com/zotero/zotero-connectors/issues/15
 
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index e12f352d..3eb62c3b 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -149,23 +149,13 @@ hard to use or simply irrelevant.
    down, but it often fails to notice when a site is down or think
    it's down when it isn't. Replaced with [View Page Archive &
    Cache][].
- * [zotero](https://www.zotero.org/) is in a bad shape in Debian. The "XUL" extension is
-   gone from Zotero 5.0, and the 4.0 extension will stop working
-   because upstream will drop support in 2018. Debian is scrambling to
-   package the newer version that is only standalone
-   ([#871502](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871502)). Right now I'm using the standalone binary from
-   upstream but I'm looking at alternatives like:
-    * [xapers](https://finestructure.net/xapers/)
-    * [pubs](https://github.com/pubs/pubs)
-    * [papis](https://github.com/papis/papis)
-   This also overlaps with bookmarking software like:
-    * [Turtl](https://turtlapp.com/)
-    * [reminiscense](https://github.com/kanishka-linux/reminiscence)
-    * [bookmark-archiver](https://pirate.github.io/bookmark-archiver/)
-    * [Wallabag](https://wallabag.org/)
-    * [Buku](https://github.com/jarun/Buku)
-    * [Shiori](https://github.com/RadhiFadlillah/shiori)
-   ... and archival software in the [[WARC ecosystem|services/archive]].
+ * [zotero](https://www.zotero.org/) is in a bad shape in Debian. The
+   "XUL" extension is gone from Zotero 5.0, and the 4.0 extension will
+   stop working because upstream will drop support in 2018. Debian is
+   scrambling to package the newer version that is only standalone
+   ([#871502](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871502)). Right now I'm using the <del>standalone binary from
+   upstream</del> flatpak but I'm looking at alternatives, see
+   [[services/bookmarks]] for that more general problem.
 
 [it's all text!]: https://addons.mozilla.org/en-US/firefox/addon/its-all-text/
 

split device sync in a separate bullet point
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index de94ca9d..7cc3db33 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -118,22 +118,24 @@ Calibre is...
    * allows downloading and editing metadata (like covers) easily
    * track read/unread status (although that's a custom field *I* had
      to add)
-   * synchronize books with an ebook-reader, automatically upddating
-     the database on the ebook with relevant metadata (e.g. collection
-     or "shelves", although I do not really use that feature)
 
    Calibre is, as far as I know, the only tool that goes so deep in
    solving that problem. The [Liber][] web server, however, does
    provide similar search and metadata functionality. It also supports
    migrating from an existing Calibre database as it can read the
-   Calibre metadata stores. It does not, as far as I can tell, support
-   synchronizing your books to an ebook reader.
+   Calibre metadata stores.
 
    This bridges with the more general "book inventory" problem which
    also includes physical books and online articles. See also
    [[firefox]] (Zotero section) and [[bookmarks]] for a longer
    discussion of that problem.
 
+ * a **device synchronization tool** : I mostly use Calibre to
+   synchronize books with an ebook-reader. It can also automatically
+   update the database on the ebook with relevant metadata
+   (e.g. collection or "shelves"), although I do not really use that
+   feature.
+
  * an **RSS reader**: I used this for a while to read RSS feeds on my
    ebook-reader, but it was pretty clunky. Calibre would be
    continously generating new ebooks based on those feeds and I would

fix broken links
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
index f8d0cf24..de94ca9d 100644
--- a/software/desktop/calibre.mdwn
+++ b/software/desktop/calibre.mdwn
@@ -12,7 +12,7 @@ It has, however, had many problems over the years:
  * Calibre's inclusion inside Debian has been bumpy in itself, it
    ships embedded libraries ([[!debbug 872595]], [[!debbug 704977]],
    [[!debbug 684229]], [[!debbug 555352]], [[!debbug 555368]],
-   [[!700838]], most fixed in Debian), sometimes with security issues
+   [[!debbug 700838]], most fixed in Debian), sometimes with security issues
    ([[!debbug 873660]], [[!debbug 787085]])
 
  * There are numerous security issues in Calibre. For example, it can
@@ -75,6 +75,7 @@ Calibre is...
     * [lucidor][] also looks interesting, but is not packaged in
       Debian either (although upstream provides a .deb)
 
+[Okular]: https://okular.kde.org/
 [lucidor]: http://lucidor.org/lucidor/
 [coolreader]: http://list.xmodulo.com/cool-reader.html
 [not yet in Debian (#715470)]: https://bugs.debian.org/715470
@@ -156,6 +157,12 @@ Calibre is...
 [Liber]: https://git.autistici.org/ale/liber
 [Trantor]: https://gitlab.com/trantor/trantor
 
+Note that I might have forgotten functionality in Calibre in the above
+list: I'm only listing the things I have used or am using on a regular
+basis. For example, you can have a USB stick with Calibre on it to
+carry the actual software, along with the book library, around on
+different computers, but I never used that feature.
+
 So there you go. It's a colossal task! And while it's great that
 Calibre does all those things, I can't help but think that it would be
 better if Calibre was split up in multiple components, each maintained

getting tired of calibre
diff --git a/software/desktop/calibre.mdwn b/software/desktop/calibre.mdwn
new file mode 100644
index 00000000..f8d0cf24
--- /dev/null
+++ b/software/desktop/calibre.mdwn
@@ -0,0 +1,163 @@
+[Calibre][] is amazing software: it works on Windows and Linux, and allows
+one to manage ebooks on your desktop and a multitude of ebook
+readers.
+
+[Calibre]: https://calibre-ebook.com/
+
+Problems with Calibre
+=====================
+
+It has, however, had many problems over the years:
+
+ * Calibre's inclusion inside Debian has been bumpy in itself, it
+   ships embedded libraries ([[!debbug 872595]], [[!debbug 704977]],
+   [[!debbug 684229]], [[!debbug 555352]], [[!debbug 555368]],
+   [[!700838]], most fixed in Debian), sometimes with security issues
+   ([[!debbug 873660]], [[!debbug 787085]])
+
+ * There are numerous security issues in Calibre. For example, it can
+   execute arbitrary code while fetching news ([[!debbug 873795]]) or
+   plugin updates ([[!debbug 640026]]), it would phone home ([[!debbug
+   584334]], fixed in Debian), allowed arbitrary file access via
+   crafted files ([[!debbug 853004]], [[!debbug 608822]]), arbitrary
+   code execution in bookmark data ([[!debbug 892242]]), and XSS vuln
+   ([[!debbug 608822]]). Some of those issues have been fixed upstream
+   but, [in my experience][], it's clear that upstream does not take
+   security seriously at all. The best example is probably the
+   [legendary security bug about how Calibre handled mounting
+   partitions][] which upstream refused to fix properly even after a
+   [LWN article][] came out about it.
+
+ * No support for Python 3. because of this, Calibre was [removed from
+   Debian in 2019][] ([[!debbug 936270]]). Now a there is [port in
+   progress][], but the author infamously claimed it wasn't necessary
+   to port to Python3 because he could [maintain Python 2 himself][]
+
+[LWN article]: https://lwn.net/Articles/465311/
+[legendary security bug about how Calibre handled mounting partitions]: https://bugs.launchpad.net/calibre/+bug/885027
+[in my experience]: https://lists.debian.org/87muy0usv1.fsf@curie.anarc.at
+[maintain Python 2 himself]: https://www.mobileread.com/forums/showthread.php?t=293242
+[port in progress]: https://github.com/kovidgoyal/calibre/blob/63f1996/README.python3
+[removed from Debian in 2019]: https://www.preining.info/blog/2019/10/rip-for-now-calibre-in-debian/
+
+The latest issue (lack of Python 3) is the last straw, for me. While
+Calibe is an awesome piece of software, I can't help but think it's
+too much, and the wrong way. It's one of those tools that looks
+amazing on the surface, but when you look underneath, it's a monster
+that is impossible to maintain, a liability that is just bound to
+cause problems in the future.
+
+What does Calibre do anyways
+============================
+
+So let's say I wanted to get rid of Calibre, what would that mean
+exactly? What do I actually use Calibre for anyways?
+
+Calibre is...
+
+ * an **ebook viewer**: Calibre ships with the [ebook-viewer][]
+   command, which allows one to browse a vast variety of ebook
+   formats. I *rarely use* this feature, since I read my ebooks on a
+   e-reader, on purpose. There is, besides, a good variety of
+   ebook-readers, on different platforms, that can replace Calibre
+   here:
+
+    * [Atril][], MATE's version of Evince, supports ePUBs (Evince
+      doesn't)
+    * [MuPDF][] also reads ePUBs without problems
+    * [fbreader][] also supports ePUBs, but is much slower than all
+      those others
+    * Emacs (of course) supports ebooks through [nov.el][]
+    * [Okular][] apparently supports ePUBs, but I must be missing a
+      library because it doesn't actually work here
+    * [coolreader][] is another alternative, [not yet in Debian
+      (#715470)][]
+    * [lucidor][] also looks interesting, but is not packaged in
+      Debian either (although upstream provides a .deb)
+
+[lucidor]: http://lucidor.org/lucidor/
+[coolreader]: http://list.xmodulo.com/cool-reader.html
+[not yet in Debian (#715470)]: https://bugs.debian.org/715470
+[nov.el]: https://github.com/wasamasa/nov.el
+[fbreader]: https://fbreader.org/
+[MuPDF]: https://mupdf.com/
+[Atril]: https://tracker.debian.org/pkg/atril
+[ebook-viewer]: https://manpages.debian.org/ebook-viewer
+
+ * an **ebook editor**: Calibre also ships with an [ebook-editor][]
+   command, which allows you to do all sorts of nasty things to your
+   ebooks. I have rarely used this tool, having found it hard to use
+   and not giving me the results I needed, in my use case (which was
+   to reformat ePUBs before publication). For this purpose, [Sigil][]
+   is a much better option, now packaged in Debian. There are also
+   various tools that render to ePUB: I often use the [Sphinx
+   documentation system][] for that purpose, and have been able to
+   produce ePUBs from LaTeX for some projects.
+
+[Sphinx documentation system]: http://www.sphinx-doc.org/
+[Sigil]: https://sigil-ebook.com/
+[ebook-editor]: https://manpages.debian.org/ebook-editor
+
+ * a **file converter**: Calibre can convert between many ebook
+   formats, to accomodate the various readers. In my experience, this
+   doesn't work very well: the layout is often broken and I have found
+   it's much better to find pristine copies of ePUB books than fight
+   with the converter. There are, however, very few alternatives to
+   this functionality, unfortunately.
+ 
+ * a **collection browser**: this is the main functionality I would
+   miss from Calibre. I am constantly adding books to my library, and
+   Calibre does have this incredibly nice functionality of just
+   hitting "add book" and Just Do The Right Thing™ after
+   that. Specifically, what I like is that it:
+   
+   * sort, view, and search books in folders, per author, date,
+     editor, etc
+   * quick search is especially powerful
+   * allows downloading and editing metadata (like covers) easily
+   * track read/unread status (although that's a custom field *I* had
+     to add)
+   * synchronize books with an ebook-reader, automatically upddating
+     the database on the ebook with relevant metadata (e.g. collection
+     or "shelves", although I do not really use that feature)
+
+   Calibre is, as far as I know, the only tool that goes so deep in
+   solving that problem. The [Liber][] web server, however, does
+   provide similar search and metadata functionality. It also supports
+   migrating from an existing Calibre database as it can read the
+   Calibre metadata stores. It does not, as far as I can tell, support
+   synchronizing your books to an ebook reader.
+
+   This bridges with the more general "book inventory" problem which
+   also includes physical books and online articles. See also
+   [[firefox]] (Zotero section) and [[bookmarks]] for a longer
+   discussion of that problem.
+
+ * an **RSS reader**: I used this for a while to read RSS feeds on my
+   ebook-reader, but it was pretty clunky. Calibre would be
+   continously generating new ebooks based on those feeds and I would
+   never read them, because I would never find the time to transfer
+   them to my ebook viewer in the first place. Instead, I use a
+   regular RSS feed reader (I ended up writing my own, [feed2exec][])
+   and when I find an article I like, I added it to [Wallabag][] which
+   gets sync'd to my reader using [wallabako][] (another tool I wrote)
+
+[Wallabag]: https://wallabag.org/en
+[wallabako]: https://gitlab.com/anarcat/wallabako
+[feed2exec]: https://feed2exec.rtfd.io/
+
+ * an **ebook web server** : Calibre can also act as a web server,
+   presenting your entire ebook collection as a website. It also
+   supports acting as an OPDS directory, which is kind of neat. There
+   are, as far as I know, no alternative for such a system although
+   there *are* servers to share and store ebooks, like [Trantor][] or
+   [Liber][]
+
+[Liber]: https://git.autistici.org/ale/liber
+[Trantor]: https://gitlab.com/trantor/trantor
+
+So there you go. It's a colossal task! And while it's great that
+Calibre does all those things, I can't help but think that it would be
+better if Calibre was split up in multiple components, each maintained
+separately. I would love to use *only* the document browser for
+example.

more notes on the remarkable, generally negative
diff --git a/hardware/tablet.mdwn b/hardware/tablet.mdwn
index c3bc1b5f..e0d9a011 100644
--- a/hardware/tablet.mdwn
+++ b/hardware/tablet.mdwn
@@ -167,14 +167,32 @@ The [reMarkable][] seems promising:
  * 500$USD
 
 [FCC teardown]: https://fccid.io/2AMK2-RM100/Internal-Photos/Internal-Photos-1-3549283
+
 Downsides:
 
- * based on a deprecated version of Android or "Codex, a custom
-   Linux-based OS optimized for low-latency e-paper"
- * software has very negative reviews
- * requires a custom pointer to draw
+ * based on yet another custom Linux distribution called "Codex, a
+   custom Linux-based OS optimized for low-latency e-paper" - which
+   means it will be (needlessly) difficult to write extensions to it
+ * software has very negative reviews - highlights don't follow
+   reflows, generally doesn't seem ready
+ * requires a custom pointer to draw, although it seems there are
+   [compatible pointers][], this FAQ seems to say they might [damage
+   the screen][] - how fast do those wear out anyways?
  * only ePUB and PDF support
  * no backlight?
+ * can it still be used without the "remarkable cloud" stuff?
+ * [battery life may be shorter than expected][]
+ * [disastrous review][]: no metadata display, bad transfer
+   experience, no in-book search, no table of contents, poor ePUB
+   support (everything is plain text, no footnotes), fragile pen, no
+   landscape mode
+ * there's a [desktop app][] but support for Linux was dropped in 2018
+
+[desktop app]: https://remarkablewiki.com/tips/client
+[disastrous review]: https://medium.com/@dmytro_poremskyi/nothing-remarkable-about-the-remarkable-paper-tablet-a-disastrous-reading-experience-200153c43a64
+[battery life may be shorter than expected]: https://remarkablewiki.com/faq/battery_life
+[damage the screen]: https://remarkablewiki.com/faq/nibs
+[compatible pointers]: https://remarkablewiki.com/tech/stylus
 
 There's a [library to write applications for it](https://github.com/canselcik/libremarkable) (here's also an
 [development tutorial](https://dragly.org/2017/12/01/developing-for-the-remarkable/)) which is a good sign, but then why write

price updates
diff --git a/hardware/tablet.mdwn b/hardware/tablet.mdwn
index e6186529..c3bc1b5f 100644
--- a/hardware/tablet.mdwn
+++ b/hardware/tablet.mdwn
@@ -106,7 +106,7 @@ The [Onyx Boox Max 2](https://onyxboox.com/boox_max2) is an awesome creature:
  * Wifi 2.4GHz, Bluetooth
  * 4100mAh battery
  * includes cover case, stylus
- * 
+ * 750$USD, now 700USD
 
 Downsides:
 
@@ -119,7 +119,10 @@ Downsides:
 
 Update: the [Onyx Boox Max 2 Pro](https://onyxboox.com/boox_maxpro)
 just came out with an update on the e-ink technology (Mobius) and a
-more powerful processor.
+more powerful processor. 850$USD
+
+Another update: there's also the [Max
+3](https://onyxboox.com/boox_max3) now at 860$USD.
 
 ### Onyx Boox Note Pro
 
@@ -148,6 +151,8 @@ reMarkable
 
 The [reMarkable][] seems promising:
 
+ [reMarkable]: https://remarkable.com/
+
  * "paper feel"
  * launched by a member of the KDE community
  * 10" display (177 x 256 x 6.7mm / 6.9 x 10.1 x .26 inches)
@@ -158,7 +163,10 @@ The [reMarkable][] seems promising:
  * wifi
  * includes stylus
  * 3000mAh battery
+ * [FCC teardown][]
+ * 500$USD
 
+[FCC teardown]: https://fccid.io/2AMK2-RM100/Internal-Photos/Internal-Photos-1-3549283
 Downsides:
 
  * based on a deprecated version of Android or "Codex, a custom

driverless printing link
diff --git a/services/print.mdwn b/services/print.mdwn
index 507fbdcf..a1def7fd 100644
--- a/services/print.mdwn
+++ b/services/print.mdwn
@@ -55,10 +55,12 @@ Améliorations possibles
 =======================
 
 Les Mac ont particulièrement de la difficulté à parler au serveur
-d'imprimante, qui ne marche pas du tout. Normalement, le "driverless
-printing" devrait rendre cette configuration plus facile: il devrait
-être possible, grâce à ce mécanisme, d'offrir les imprimantes aux
-clients sans qu'ils aient besoin de configurer de "driver".
+d'imprimante, qui ne marche pas du tout. Normalement, le "[driverless
+printing][]" devrait rendre cette configuration plus facile: il
+devrait être possible, grâce à ce mécanisme, d'offrir les imprimantes
+aux clients sans qu'ils aient besoin de configurer de "driver".
+
+[driverless printing]: https://wiki.debian.org/CUPSDriverlessPrinting
 
 Le message d'erreur, dans Mac OS, est "l'imprimante ne répond pas". Il
 semblerait que la solution se trouve soit dans l'[émulation

plus de notes sur le driverless
diff --git a/services/print.mdwn b/services/print.mdwn
index a2dc7acb..507fbdcf 100644
--- a/services/print.mdwn
+++ b/services/print.mdwn
@@ -59,3 +59,9 @@ d'imprimante, qui ne marche pas du tout. Normalement, le "driverless
 printing" devrait rendre cette configuration plus facile: il devrait
 être possible, grâce à ce mécanisme, d'offrir les imprimantes aux
 clients sans qu'ils aient besoin de configurer de "driver".
+
+Le message d'erreur, dans Mac OS, est "l'imprimante ne répond pas". Il
+semblerait que la solution se trouve soit dans l'[émulation
+Airprint](https://wiki.debian.org/CUPSAirPrint) ou [IPP Everywhere](https://wiki.debian.org/CUPSIPPEverywhere), pas clair. Dans les deux cas, ça
+semble mal supporté par CUPS, ce qui est étrange vu que CUPS est un
+projet de Mac OS au départ...

mise à jour: imprimante maintenant sur marcos
diff --git a/services/print.mdwn b/services/print.mdwn
index 03878183..a2dc7acb 100644
--- a/services/print.mdwn
+++ b/services/print.mdwn
@@ -2,6 +2,9 @@ J'ai une imprimante ou deux. Auparavant, [[hardware/server/mafalda]]
 était un serveur d'impression CUPS mais il a été remplacé par
 [[hardware/server/plastik]] car il a un port USB.
 
+Configuration du service 910n
+=============================
+
 Le nouveau serveur utilise le [service p910n de OpenWRT][p910n] car le
 serveur CUPS n'est pas disponible sous la version OpenWRT que j'ai
 installé, présumément parce que j'ai une version "LEDE" du
@@ -19,13 +22,40 @@ ce qui semble, pour l'instant, fonctionner.
 
 [p910n]: https://openwrt.org/docs/guide-user/services/print_server/p910ndprinterserver
 
-Configurer l'imprimante sur une nouvelle machine devrait être
-automatique: elle devrait auto-détecter l'imprimante partagée sur
-`curie`.
+Configuration du serveur CUPS
+=============================
 
-Pour configurer `curie`, il faut ajouter une nouvelle imprimante de
-type "AppSocket/HP JetDirect" avec l'URL
+Mais après, chaque machine doit configurer "CUPS" parler à
+plastik. Pour configurer `curie`, il faut ajouter une nouvelle
+imprimante de type "AppSocket/HP JetDirect" avec l'URL
 `socket://plastik.anarc.at:9100`. On entre ensuite le nom de
 l'imprimante (`HP-LaserJet-1012`) et on la partage, puis on choisit le
 driver `HP LaserJet 1012 hpijs`, qui est disponible dans le [package
 printer-driver-hpijs](https://tracker.debian.org/printer-driver-hpijs).
+
+Maintenant que `curie` n'est plus à la maison, j'ai configuré `marcos`
+de la même façon, et j'ai marqué l'imprimante comme partagée
+également.
+
+Configurer de clients CUPS
+==========================
+
+Configurer l'imprimante sur une nouvelle machine devrait être
+automatique: elle devrait auto-détecter l'imprimante partagée sur
+`marcos`.
+
+Curieusement, sur `angela`, bien que l'imprtimante soit détectée, elle
+me demande de choisir un pilote. `HP LaserJet 1012 Printer - IPP
+Everywhere™`. 
+
+Mais a priori, il n'est pas nécessaire d'installer l'imprimante, elle
+devrait apparaître magiquement dans les dialogues CUPS.
+
+Améliorations possibles
+=======================
+
+Les Mac ont particulièrement de la difficulté à parler au serveur
+d'imprimante, qui ne marche pas du tout. Normalement, le "driverless
+printing" devrait rendre cette configuration plus facile: il devrait
+être possible, grâce à ce mécanisme, d'offrir les imprimantes aux
+clients sans qu'ils aient besoin de configurer de "driver".

removed
diff --git a/blog/2018-04-12-terminal-emulators-1/comment_5_d88343198a02f9c27c21173fe0be64e1._comment b/blog/2018-04-12-terminal-emulators-1/comment_5_d88343198a02f9c27c21173fe0be64e1._comment
deleted file mode 100644
index 8b73628d..00000000
--- a/blog/2018-04-12-terminal-emulators-1/comment_5_d88343198a02f9c27c21173fe0be64e1._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- ip="117.26.229.20"
- claimedauthor="zincesas"
- url="http://www.zincesas.com/"
- subject="zincesas"
- date="2019-10-05T04:26:22Z"
- content="""
-<a href=\"http://www.lurioaddl.com/nhl-jerseys-detroit-red-wings-13-pavel-datsyuk-charcoal-cross-check-fashion-jerseys-nfla_uk\">nhl jerseys detroit red wings 13 pavel datsyuk charcoal cross check fashion jerseys</a> <a href=\"http://www.secureorb.com/adidas-yeezy-boost-350-buy-online-free-nikeh_dk\">adidas yeezy boost 350 buy online free</a> <a href=\"http://www.susanlew.com/nike-air-jordan-5-low-unit-afoot_en\">nike air jordan 5 low unit</a> <a href=\"http://www.babilisim.com/nike-air-pegasus-83-grey-suede-cfoot_en\">nike air pegasus 83 grey suede</a> <a href=\"http://www.ftlsubsea.com/nike-kobe-9-elite-release-date-excel-kdf_en\">nike kobe 9 elite release date excel</a> <a href=\"http://www.lewislist.com/white-blue-black-under-armour-curry-2.5-uk-shoes-niken_dk\">white blue black under armour curry 2.5 uk shoes</a>
-"""]]

Added a comment: zincesas
diff --git a/blog/2018-04-12-terminal-emulators-1/comment_5_d88343198a02f9c27c21173fe0be64e1._comment b/blog/2018-04-12-terminal-emulators-1/comment_5_d88343198a02f9c27c21173fe0be64e1._comment
new file mode 100644
index 00000000..8b73628d
--- /dev/null
+++ b/blog/2018-04-12-terminal-emulators-1/comment_5_d88343198a02f9c27c21173fe0be64e1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="117.26.229.20"
+ claimedauthor="zincesas"
+ url="http://www.zincesas.com/"
+ subject="zincesas"
+ date="2019-10-05T04:26:22Z"
+ content="""
+<a href=\"http://www.lurioaddl.com/nhl-jerseys-detroit-red-wings-13-pavel-datsyuk-charcoal-cross-check-fashion-jerseys-nfla_uk\">nhl jerseys detroit red wings 13 pavel datsyuk charcoal cross check fashion jerseys</a> <a href=\"http://www.secureorb.com/adidas-yeezy-boost-350-buy-online-free-nikeh_dk\">adidas yeezy boost 350 buy online free</a> <a href=\"http://www.susanlew.com/nike-air-jordan-5-low-unit-afoot_en\">nike air jordan 5 low unit</a> <a href=\"http://www.babilisim.com/nike-air-pegasus-83-grey-suede-cfoot_en\">nike air pegasus 83 grey suede</a> <a href=\"http://www.ftlsubsea.com/nike-kobe-9-elite-release-date-excel-kdf_en\">nike kobe 9 elite release date excel</a> <a href=\"http://www.lewislist.com/white-blue-black-under-armour-curry-2.5-uk-shoes-niken_dk\">white blue black under armour curry 2.5 uk shoes</a>
+"""]]

trying vimium
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 983fd698..e12f352d 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -83,7 +83,11 @@ I am testing those and they might make it to the top list once I'm happy:
    good enough for my purposes.
  * [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)
+ * [tridactyl](https://github.com/tridactyl/tridactyl) - to use the web browser without the mouse. was
+   [pulled out of AMO][] for a policy violation, might return but in
+   the meantime, i'm trying out [vimium][].
 
+[vimium]: https://github.com/philc/vimium
 [Multi-account containers]: https://github.com/mozilla/multi-account-containers/
 
 Those should probably not be packaged in Debian until they make it to
@@ -193,6 +197,24 @@ And here are the replacements I have found:
  * [uMatrix][]: ported
  * [Wallabager][]: ported
  * [web developer](https://addons.mozilla.org/en-US/firefox/addon/web-developer/): ported
+ * [vimperator][]: a few [vimperator alternatives][] have popped
+   up. [tridactyl][] was the most prominent one, but was also [pulled
+   from AMO][] for a policy violation. [vimium fx][] and [vim-vixen][]
+   seem like the only working alternatives right now, although the
+   vimperator folks say they lack some features, I couldn't figure out
+   which. [pentadactyl][] is the father to all of those, but seems to
+   have disappeared off the internet. [salsa key][] is one without
+   vi-like keybindings. [vimfx][] also did not survive the
+   XULocalypse.
+
+[vimperator]: https://github.com/vimperator/vimperator-labs
+[vim-vixen]: https://github.com/ueokande/vim-vixen
+[vimfx]: https://github.com/akhodakivskiy/VimFx
+[pentadactyl]: http://web.archive.org/web/20171019152504/http://5digits.org/pentadactyl/
+[vimium fx]: https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/?src=search
+[salsa key]: https://addons.mozilla.org/en-US/firefox/addon/saka-key/
+[pulled from AMO]: https://github.com/tridactyl/tridactyl/issues/1800
+[vimperator alternatives]: https://github.com/vimperator/vimperator-labs#end-of-life-and-alternatives
 
 Those are the extensions I was using for which no replacement exists:
 

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 .