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.

Added a comment: I don't trust Signal - Drew DeVault
diff --git a/blog/2018-07-27-signal-metadata/comment_1_70edfadf673cced00eec0546421dacac._comment b/blog/2018-07-27-signal-metadata/comment_1_70edfadf673cced00eec0546421dacac._comment
new file mode 100644
index 00000000..778a1740
--- /dev/null
+++ b/blog/2018-07-27-signal-metadata/comment_1_70edfadf673cced00eec0546421dacac._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="robin@2dd2089cf9dcc835ea1c51e5bf3d44f339f0485b"
+ nickname="robin"
+ avatar="https://seccdn.libravatar.org/avatar/4ba3e4c5c0e1ac65d5ff8fd6df326060"
+ subject="I don't trust Signal - Drew DeVault "
+ date="2018-08-09T17:33:13Z"
+ content="""
+Popular on hackernews today: https://drewdevault.com/2018/08/08/Signal.html
+"""]]

Added a comment: Hammer on the ISP and the device maker for source code
diff --git a/blog/2015-10-20-smartrg-sr630n-proprietary-router-running-linux/comment_13_6b06c5671b0955588441316a4d655312._comment b/blog/2015-10-20-smartrg-sr630n-proprietary-router-running-linux/comment_13_6b06c5671b0955588441316a4d655312._comment
new file mode 100644
index 00000000..6a5b5583
--- /dev/null
+++ b/blog/2015-10-20-smartrg-sr630n-proprietary-router-running-linux/comment_13_6b06c5671b0955588441316a4d655312._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ ip="84.176.155.75"
+ claimedauthor="Adam"
+ subject="Hammer on the ISP and the device maker for source code"
+ date="2018-08-06T13:25:59Z"
+ content="""
+Well, I had some luck pushing Technicolor to publish some sources: https://www.phoronix.com/scan.php?page=news_item&px=Technicolor-Opens-TC72
+"""]]

fix ordering
diff --git a/blog/2018-07-27-signal-metadata.mdwn b/blog/2018-07-27-signal-metadata.mdwn
index b3bac1bd..fbd2bd6f 100644
--- a/blog/2018-07-27-signal-metadata.mdwn
+++ b/blog/2018-07-27-signal-metadata.mdwn
@@ -18,11 +18,11 @@ peers when you send messages. Using those messages, I could establish
 when my friend opened his laptop and the [Signal
 Desktop](https://signal.org/blog/signal-desktop/) app got back online.
 
-[[!img signal-screenshot.png]]
-
 How this works
 --------------
 
+[[!img signal-screenshot.png]]
+
 This is possible because the receipt notifications in Signal are
 per-device. This means that the "double-checkmark" you see when a
 message is delivered to the device is actually only when the *first*

link for read receipts
diff --git a/blog/2018-07-27-signal-metadata.mdwn b/blog/2018-07-27-signal-metadata.mdwn
index f1475d54..b3bac1bd 100644
--- a/blog/2018-07-27-signal-metadata.mdwn
+++ b/blog/2018-07-27-signal-metadata.mdwn
@@ -38,7 +38,7 @@ confirming reception for a message, as seen from `signal-cli`:
 
 That's Bob's phone telling me it received the message. On my side, the
 Signal app shows a second checkmark to tell me the message was
-transmitted. (There are also "blue checkmarks" now that tell the user
+transmitted. (There are also "[blue checkmarks](https://www.signal.org/blog/read-receipts/)" now that tell the user
 the other person has *seen* the message, but I haven't looked into
 those in detail.) Then another notification comes in:
 

tags
diff --git a/blog/2018-07-27-signal-metadata.mdwn b/blog/2018-07-27-signal-metadata.mdwn
index 82051440..f1475d54 100644
--- a/blog/2018-07-27-signal-metadata.mdwn
+++ b/blog/2018-07-27-signal-metadata.mdwn
@@ -176,3 +176,5 @@ it can have surprising properties even for skilled engineers who
 thought they knew about the security properties of the system, so I am
 worried about my fellow non-technical friends and their expectations
 of privacy...
+
+[[!tag debian-planet signal security review]]

reword titles and small changes
diff --git a/blog/2018-07-27-signal-metadata.mdwn b/blog/2018-07-27-signal-metadata.mdwn
index 3429c3b2..82051440 100644
--- a/blog/2018-07-27-signal-metadata.mdwn
+++ b/blog/2018-07-27-signal-metadata.mdwn
@@ -1,4 +1,4 @@
-[[!meta title="An worrisome example of Signal metadata"]]
+[[!meta title="Concerns with Signal receipt notifications"]]
 
 During some experiments with a custom [Signal](https://signal.org)
 client with a friend, let's call him Bob, he was very surprised when
@@ -147,13 +147,15 @@ notifications if they were given the choice.
 Other metadata issues
 ---------------------
 
-There are other metadata issues in Signal, of course. The most notable
-one is probably how Signal shares your contact list. The user-visible
-effect is the "Bob is on Signal!" message that pops up when the server
-figures that out. The Signal people have done [extensive research](https://www.signal.org/blog/private-contact-discovery/)
-to make this work securely while at the same time leveraging the
-contacts on your phone, but it's still a surprising phenomenon to new
-users who don't know about the specifics of how this is implemented.
+There are other metadata issues in Signal, of course. Like receipt
+notifications, they are tradeoffs between usability and privacy. The
+most notable one is probably how Signal shares your contact list. The
+user-visible effect is the "Bob is on Signal!" message that pops up
+when the server figures that out. The Signal people have done
+[extensive research](https://www.signal.org/blog/private-contact-discovery/) to make this work securely while at the same
+time leveraging the contacts on your phone, but it's still a
+surprising phenomenon to new users who don't know about the specifics
+of how this is implemented.
 
 Another one is how groups are opt-out only: anyone can add you to a
 group without your consent, which shares your phone number to the
@@ -170,6 +172,7 @@ seem to other users.
 The bottomline is that crypto and security are hard to implement but
 also hard to make visible to users. Signal does a great job at making
 a solid communication application that provides decent security, but
-even there it can have surprising properties even for knowledgeable
-engineers who thought they know about the security properties of the
-system.
+it can have surprising properties even for skilled engineers who
+thought they knew about the security properties of the system, so I am
+worried about my fellow non-technical friends and their expectations
+of privacy...

rename files properly
diff --git a/blog/signal-metadata.mdwn b/blog/2018-07-27-signal-metadata.mdwn
similarity index 100%
rename from blog/signal-metadata.mdwn
rename to blog/2018-07-27-signal-metadata.mdwn
diff --git a/blog/signal-metadata/signal-screenshot.png b/blog/2018-07-27-signal-metadata/signal-screenshot.png
similarity index 100%
rename from blog/signal-metadata/signal-screenshot.png
rename to blog/2018-07-27-signal-metadata/signal-screenshot.png

rewrite article after Signal Security review
diff --git a/blog/signal-metadata.mdwn b/blog/signal-metadata.mdwn
index ac0f6498..3429c3b2 100644
--- a/blog/signal-metadata.mdwn
+++ b/blog/signal-metadata.mdwn
@@ -1,8 +1,8 @@
 [[!meta title="An worrisome example of Signal metadata"]]
 
-[Signal](https://signal.org) leaks all sorts of metadata. A particular leakage was
-especially surprising to a friend, let's call him Bob, when we had a
-conversation that went a little like this:
+During some experiments with a custom [Signal](https://signal.org)
+client with a friend, let's call him Bob, he was very surprised when
+we had a conversation that went a little like this:
 
     A> hey Bob! welcome home!
     B> what?
@@ -10,15 +10,19 @@ conversation that went a little like this:
     B> what the heck man? did you hack my machine? OMGWTFSTHUBERTBBQ?!
 
 I'm paraphrasing as I lost copy of the original chat, but it was
-striking how he had absolutely no clue how it happened and was quite
-worried I hacked into his system to spy on his webcam or some other
-elite hack. As it turns out, I just made simple assertions based on
-data Signal provides to other peers when you send messages to
-establish when my friend opened my laptop and his [Signal Desktop](https://signal.org/blog/signal-desktop/)
-app got back online.
+striking how he had absolutely no clue how I figured out he had just
+came home in front of his laptop. He was quite worried I hacked into
+his system to spy on his webcam or some other "hack". As it turns out,
+I just made simple assertions based on data Signal provides to other
+peers when you send messages. Using those messages, I could establish
+when my friend opened his laptop and the [Signal
+Desktop](https://signal.org/blog/signal-desktop/) app got back online.
 
 [[!img signal-screenshot.png]]
 
+How this works
+--------------
+
 This is possible because the receipt notifications in Signal are
 per-device. This means that the "double-checkmark" you see when a
 message is delivered to the device is actually only when the *first*
@@ -55,20 +59,6 @@ Signal Desktop client. This can be used to assert physical presence on
 different machines: the desktop at home, laptop in the office, etc. It
 might not seem like much, but it sure felt creepy to Bob.
 
-This attack can be carried out by anyone who knows Bob's phone
-number. Because Signal is an open network, you are free to send
-messages to anyone without their consent. An attacker only has to send
-spam messages to a victim to figure out when they're online, how many
-devices they own and when they are online. There's no way for Bob to
-protect himself from this attack, other than trying to keep his phone
-number private.
-
-The unique identifiers to not seem to provide any user-visible
-functionality and so should be removed from the protocol. The tradeoff
-involved in allowing peers to know that Bob received the message at
-all might be worth it: those double check marks are somewhat useful,
-but that does not require device-specific metadata.
-
 While writing this article, I figured I would reproduce those results,
 I wrote Bob again to ask for help. Here's how the (redacted and
 reformatted) conversation went:
@@ -87,25 +77,99 @@ reformatted) conversation went:
     A-1> i'll know, don't worry :p
     * B-1 message received
 
-~90 minutes pass and Bob opens his laptop:
+After an hour or two, Bob gets home opens his laptop, and you can see
+the key message that reveals it:
 
     * B-2 mesage received
     A-1> welcome home, sucker! ;)
     B-2> dang dog.
 
-There are other metadata leaks in Signal, of course. The most notable
-one is probably how groups are opt-out only and leak everyone's phone
-numbers to everyone else which, combined with this one, makes for
-interesting attacks. But this specific leak is more pernicious: apart
-from signal-cli users, the leak is not visible at all... While people
+This attack can be carried out by anyone who knows Bob's phone
+number. Because Signal is an open network, you are free to send
+messages to anyone without their consent. An attacker only has to send
+spam messages to a victim to figure out when they're online, how many
+devices they own and when they are online. There's no way for Bob to
+protect himself from this attack, other than trying to keep his phone
+number private.
+
+Why Signal works that way
+-------------------------
+
+When I shared an earlier draft of this article to the Signal Security
+team, they stated this was a necessary trade-off, as each device
+carries a unique cryptographic key anyways and that:
+
+> Signal encrypts messages individually to each recipient device.
+> Thus as long as there is a "delivery receipt" feature, it will be
+> possible to learn which recipient devices are online, for example by
+> sending an encrypted message to a subset of the recipient devices,
+> and seeing whether a delivery receipt is received or not.
+
+The alternative seems to be to either disable receipt notifications or
+sharing the same private key among different devices, which induces
+other problems:
+
+> Having all recipient devices share the same encryption keys would
+> render the Diffie-Hellman ratcheting which is part of the Signal
+> protocol ineffective, since all devices (including offline ones) would
+> have to use synchronized DH ratchet key pairs, preventing these values
+> from adding fresh randomness.  In addition, it would add massive
+> protocol complexity and fragility to try to keep recipient devices
+> synchronized, while trying to achieve the (probably-infeasible) goal
+> of eliminating all ways to distinguish recipient devices.
+
+I am not certain those tradeoffs are that clear-cut, however. I am not
+a cryptographer, and specifically not very familiar with the
+"ratcheting" algorithm behind the "Signal protocol" (or is it called
+[Noise](https://noiseprotocol.org/) now?), but it seems to me there *should* be a way to
+provide multi-device, multi-key encryption, without revealing
+per-device identifiers to other clients. In particular, I do not
+understand what purpose those integers serve: maybe they are
+automatically generated by signal-cli and are just a side-effect of a
+fundamental property of the protocol, in which case I would understand
+why they would be unavoidable. To be fair, other cryptographic systems
+also share similar problems: an encrypted OpenPGP email usually embeds
+metadata about source and destination addresses, as email headers are
+not encrypted. Even a normal OpenPGP encrypted blob includes OpenPGP
+key data by default, although there are ways to turn that off and make
+sure an encrypted blob is just an undecipherable blob. The problem
+with this, of course, is that many critics of OpenPGP present it as an
+old technology that should be replaced by more modern alternatives
+like Signal, so it's a bit disappointing to see it suffers from
+similar metadata exposure problems as older protocols.
+
+But apart from cryptographic properties, there are certain user
+expectations regarding Signal, and my experience with this specific
+issue is that this property certainly breaks some privacy expectations
+for users. I'm not sure people would choose to have delivery
+notifications if they were given the choice.
+
+Other metadata issues
+---------------------
+
+There are other metadata issues in Signal, of course. The most notable
+one is probably how Signal shares your contact list. The user-visible
+effect is the "Bob is on Signal!" message that pops up when the server
+figures that out. The Signal people have done [extensive research](https://www.signal.org/blog/private-contact-discovery/)
+to make this work securely while at the same time leveraging the
+contacts on your phone, but it's still a surprising phenomenon to new
+users who don't know about the specifics of how this is implemented.
+
+Another one is how groups are opt-out only: anyone can add you to a
+group without your consent, which shares your phone number to the
+other members of the group, a bit like how carbon-copies in emails
+reveals a social network.
+
+Compared with groups and new users notifications, the receipt
+notification issue is a little more pernicions: the leak is not
+visible at all to users except if they run signal-cli... While people
 clearly see each other's presence in a group, they definitely will not
 know that those little checkmark disclose more information than they
 seem to other users.
 
-This should be clearly be fixed and I hope the Signal people
-eventually do the right thing on this one.
-
-Note that I haven't gone through a formal disclosure process
-considering the relative mild severity of this security issue. I also
-considered the threat model followed by Signal, which typically
-reveals metadata such as phone numbers somewhat liberally elsewhere...
+The bottomline is that crypto and security are hard to implement but
+also hard to make visible to users. Signal does a great job at making
+a solid communication application that provides decent security, but
+even there it can have surprising properties even for knowledgeable
+engineers who thought they know about the security properties of the
+system.

finalize report
diff --git a/blog/2018-07-27-report.mdwn b/blog/2018-07-27-report.mdwn
index 440a96ee..7ec8026d 100644
--- a/blog/2018-07-27-report.mdwn
+++ b/blog/2018-07-27-report.mdwn
@@ -35,4 +35,31 @@ I have also uploaded fixes for cups ([DLA-1412-1](https://lists.debian.org/20180
 CVE-2017-18190]] and [[!debcve CVE-2017-18248]]) and dokuwiki
 ([DLA-1413-1](https://lists.debian.org/20180705163617.kxs26pt6tacfxk7i@angela.anarc.at), fixing [[!debcve CVE-2017-18123]]).
 
-[[!tag draft]]
+Other activities
+================
+
+This month was fairly quiet otherwise, as I was on vacation.
+
+I still managed to push a few projects forward. The [pull request to
+add nopaste to ELPA](https://github.com/melpa/melpa/pull/5601) was met with skepticism considering there is
+already [another paste tool in ELPA](https://melpa.org/#/webpaste) called [webpaste.el](https://github.com/etu/webpaste.el) which
+takes the different (and unfortunate) approach of reimplementing all
+pastebins natively, instead of reusing the existing paste programs. I
+have, incidentally, discovered similar functionality in my terminal
+emulator, in the form of [urxvt-selection-pastebin](https://manpages.debian.org/unstable/rxvt-unicode/urxvt-selection-pastebin.1.en.html) although I have
+yet to try (and probably patch) that approach.
+
+We have also been dealing with a vast [attack on IRC servers](https://freenode.net/news/spambot-attack)
+primarily aimed at hurting the reputation of [Freenode](https://freenode.net/) operators,
+but that affected all IRC networks. On top of implementing custom
+measures to deal with the problem on our networks, I have contributed
+some [documentation to help users](https://github.com/charybdis-ircd/charybdis/pull/263) and [improvements to a IRC
+service](https://github.com/atheme/atheme-contrib-modules/pull/37) to help with the attack.
+
+I've also had a [great conversation](https://github.com/schollz/croc/issues/71) with the author of [croc](https://github.com/schollz/croc/),
+a derivative of [magic-wormhole](https://magic-wormhole.readthedocs.io) because of flaws I felt were
+present in the croc implementation. It seems I was able to convince
+the author to do the right thing and future versions of the program
+might be fully compatible with wormhole, which is great news.
+
+[[!tag debian-lts debian debian-planet irc emacs monthly-report]]

add missing tags
diff --git a/blog/2018-03-01-free-software-activities-february-2018.mdwn b/blog/2018-03-01-free-software-activities-february-2018.mdwn
index 1d6b6d8c..dccdb806 100644
--- a/blog/2018-03-01-free-software-activities-february-2018.mdwn
+++ b/blog/2018-03-01-free-software-activities-february-2018.mdwn
@@ -96,4 +96,4 @@ time. I'm also trying to turn those reports into articles to help
 ramping up that rhythm, which means you'll need to [subscribe](https://lwn.net/subscribe/Info) to
 LWN to get the latest goods before the 2 weeks exclusivity period.
 
-[[!tag debian-planet debian debian-lts python-planet software geek free]]
+[[!tag debian-planet debian debian-lts python-planet monthly-report]]
diff --git a/blog/2018-06-27-report.mdwn b/blog/2018-06-27-report.mdwn
index cec260de..22de6519 100644
--- a/blog/2018-06-27-report.mdwn
+++ b/blog/2018-06-27-report.mdwn
@@ -256,4 +256,4 @@ Random stuff
  * contributed to about 20 different repositories on GitHub, too
    numerous to list here
 
-[[!tag debian-planet debian debian-lts python-planet software geek free monkeysign ikiwiki emacs rsendmail linkchecker]]
+[[!tag debian-planet debian debian-lts python-planet software geek free monkeysign ikiwiki emacs rsendmail linkchecker monthly-report]]

published DLA, fix URL
diff --git a/blog/2018-07-27-report.mdwn b/blog/2018-07-27-report.mdwn
index 7d7ac750..440a96ee 100644
--- a/blog/2018-07-27-report.mdwn
+++ b/blog/2018-07-27-report.mdwn
@@ -21,7 +21,7 @@ vulnerability ([[!debcve CVE-2017-17458]]). In other issues, upstream
 at least attempted to try identifiers through the [OVE](http://www.openwall.com/ove/) system
 which is not as well integrated in our security tracker but does allow
 *some* cross-distro collaboration at least. The regression advisory
-was published as DLA-1414-2.
+was published as [DLA-1414-2](https://lists.debian.org/20180727185214.zj6tawfiekayqz55@curie.anarc.at).
 
 Overall, the updates of the Mercurial package were quite difficult as
 the test suite would fail because order of one test would vary between

draft lts report
diff --git a/blog/2018-07-27-report.mdwn b/blog/2018-07-27-report.mdwn
new file mode 100644
index 00000000..7d7ac750
--- /dev/null
+++ b/blog/2018-07-27-report.mdwn
@@ -0,0 +1,38 @@
+[[!meta title="My free software activities, July 2018"]]
+
+[[!toc levels=2]]
+
+Debian Long Term Support (LTS)
+==============================
+
+This is my monthly [Debian LTS][] report. 
+
+[Debian LTS]: https://www.freexian.com/services/debian-lts.html
+
+Most of my hours this month were spent updating jessie to catchup with
+all the work we've done in Wheezy that were never forward-ported
+([DLA-1414-1](https://lists.debian.org/20180705210052.vu4wqkmw7mbbmfsh@angela.anarc.at), fixing [[!debcve CVE-2017-9462]], [[!debcve
+CVE-2017-17458]], [[!debcve CVE-2018-1000132]], OVE-20180430-0001,
+OVE-20180430-0002, and OVE-20180430-0004). Unfortunately, work was
+impeded by how upstream now refuses to get CVE identifiers for new
+issues they discover in the process, which meant that I actually
+missed three more patches which were required to fix the subrepo
+vulnerability ([[!debcve CVE-2017-17458]]). In other issues, upstream
+at least attempted to try identifiers through the [OVE](http://www.openwall.com/ove/) system
+which is not as well integrated in our security tracker but does allow
+*some* cross-distro collaboration at least. The regression advisory
+was published as DLA-1414-2.
+
+Overall, the updates of the Mercurial package were quite difficult as
+the test suite would fail because order of one test would vary between
+*builds* (and not runs!) which was quite confusing. I originally tried
+fixing this by piping the output of the test suite through `sort` to
+get consistent output, but, after vetting the idea one of the upstream
+maintainers (`durin42`), I ended up sorting the dictionnary in the
+code directly.
+
+I have also uploaded fixes for cups ([DLA-1412-1](https://lists.debian.org/20180703190003.egurgb4h4ronyf4c@angela.anarc.at), fixing [[!debcve
+CVE-2017-18190]] and [[!debcve CVE-2017-18248]]) and dokuwiki
+([DLA-1413-1](https://lists.debian.org/20180705163617.kxs26pt6tacfxk7i@angela.anarc.at), fixing [[!debcve CVE-2017-18123]]).
+
+[[!tag draft]]

shared with signal security
diff --git a/blog/signal-metadata.mdwn b/blog/signal-metadata.mdwn
index 31ec3985..ac0f6498 100644
--- a/blog/signal-metadata.mdwn
+++ b/blog/signal-metadata.mdwn
@@ -1,67 +1,77 @@
-Signal leaks all sorts of metadata. A particular leakage was
-especially surprising to a friend, let's call hime Bob, when we had a
-conversation that went a little like this:
-
-    A> hey friend! welcome home!
-    B> what? how did you know I got home? what the fuck man? did
-    you hack my machine? OMGWTFST-HUBERTBBQ?!
+[[!meta title="An worrisome example of Signal metadata"]]
 
-Or something to that effect. I wish I had kept a copy now, because it
-was quite striking how easy it was for me to figure out when Bob got
-back home and how he had absolutely no clue how it happened.
+[Signal](https://signal.org) leaks all sorts of metadata. A particular leakage was
+especially surprising to a friend, let's call him Bob, when we had a
+conversation that went a little like this:
 
-As it turns out, the receipt notifications in Signal are
-per-device. This means that the double-checkmark you see when a
-message is delivered to the device is actually only when a *first*
-device receives the message, regardless of the device. Behind the
-scenes, Signal actually sends notifications for *each* device, with a
-unique identifier for each device. This is easy to see with
-[signal-cli][]. For example, this is a normal notification:
+    A> hey Bob! welcome home!
+    B> what?
+    B> wait, how did you know I got home?
+    B> what the heck man? did you hack my machine? OMGWTFSTHUBERTBBQ?!
+
+I'm paraphrasing as I lost copy of the original chat, but it was
+striking how he had absolutely no clue how it happened and was quite
+worried I hacked into his system to spy on his webcam or some other
+elite hack. As it turns out, I just made simple assertions based on
+data Signal provides to other peers when you send messages to
+establish when my friend opened my laptop and his [Signal Desktop](https://signal.org/blog/signal-desktop/)
+app got back online.
+
+[[!img signal-screenshot.png]]
+
+This is possible because the receipt notifications in Signal are
+per-device. This means that the "double-checkmark" you see when a
+message is delivered to the device is actually only when the *first*
+device receives the message. Behind the scenes, Signal actually sends
+a notification for *each* device, with a unique, per-device
+identifier. Those identifiers are visible with [signal-cli](https://github.com/AsamK/signal-cli). For
+example, this is a normal notification the Signal app will send when
+confirming reception for a message, as seen from `signal-cli`:
 
     Envelope from: “Bob” +15555555555 (device: 1)
     Timestamp: 1532279834422 (2018-07-22T17:17:14.422Z)
     Got receipt.
 
-That's Bob's phone telling me it received the message: great! The
-graphical Signal client adds the second checkmark and I'm happy to see
-that he got it. But then another notification comes in later:
+That's Bob's phone telling me it received the message. On my side, the
+Signal app shows a second checkmark to tell me the message was
+transmitted. (There are also "blue checkmarks" now that tell the user
+the other person has *seen* the message, but I haven't looked into
+those in detail.) Then another notification comes in:
 
     Envelope from: “Bob” +15555555555 (device: 2)
     Timestamp: 1532279901951 (2018-07-22T17:18:21.951Z)
     Got receipt.
 
 Notice the device number there? It changed from `1` to `2`. This tells
-me this is a *different* device than the first one. In all but exotic
-configurations, device 1 will be a phone and 2 [Signal Desktop][]. In
-my case, I have experimented with *many* different configurations, so
-I have device numbers up to 8, but my phone is *still* device 1. 
-
-This means it is completely possible for an attacker to figure out
-when my phone goes online, reliably. It is also possible to make
-reasonable assertions about the identity of most devices: any device
-number above one is most likely a Signal Desktop client, which will
-indicate when each device goes online. This can be used to assert
-physical presence on different machines: the desktop at home, laptop
-in the office, or phone anywhere. It might not seem like much, but it
-sure felt creepy to Bob.
-
-This attack can also be carried that anyone who knows Bob's phone
+me this is a *different* device than the first one. Device 1 will most
+likely be the phone app and device 2 will most likely be Signal
+Desktop. (In my case, I tried so *many* different configurations thatI
+have device numbers up to 8, but my phone is still device 1.)
+
+An attacker can use those notifications to tell when my phone goes
+online. It is also possible to make reasonable assertions about the
+identity of each device: any device number above one is most likely a
+Signal Desktop client. This can be used to assert physical presence on
+different machines: the desktop at home, laptop in the office, etc. It
+might not seem like much, but it sure felt creepy to Bob.
+
+This attack can be carried out by anyone who knows Bob's phone
 number. Because Signal is an open network, you are free to send
 messages to anyone without their consent. An attacker only has to send
 spam messages to a victim to figure out when they're online, how many
-devices they own and when they are online.
+devices they own and when they are online. There's no way for Bob to
+protect himself from this attack, other than trying to keep his phone
+number private.
 
-Considering the unique identifiers do not show up in the GUI, they do
-not provide any user-visible functionality that I can think of. So I
-do not think they should be part of the protocol, and should be
-removed. The tradeoff involved in allowing peers to know that Bob
-received the message at all might be worth it: those double check
-marks are great. But I do not think they require having
-device-identifying metadata attached to them.
+The unique identifiers to not seem to provide any user-visible
+functionality and so should be removed from the protocol. The tradeoff
+involved in allowing peers to know that Bob received the message at
+all might be worth it: those double check marks are somewhat useful,
+but that does not require device-specific metadata.
 
-While writing this article, I figure I would make sure I could
-reproduce those results, I wrote Bob again to ask for help. Here's how
-the (redacted and reformatted) conversation went:
+While writing this article, I figured I would reproduce those results,
+I wrote Bob again to ask for help. Here's how the (redacted and
+reformatted) conversation went:
 
     A-1> hey you there?
     * B-1 message received
@@ -74,15 +84,28 @@ the (redacted and reformatted) conversation went:
     A-1> all he needs to do is open his laptop and start signal-desktop :p
     * B-1 message received
     B-1> we'll be home in 1h30
-    * B-1 message received
     A-1> i'll know, don't worry :p
+    * B-1 message received
 
-~90 minutes pass:
+~90 minutes pass and Bob opens his laptop:
 
     * B-2 mesage received
     A-1> welcome home, sucker! ;)
-    B-2> damn dog.
-
-
-
-+ seen notifications?
+    B-2> dang dog.
+
+There are other metadata leaks in Signal, of course. The most notable
+one is probably how groups are opt-out only and leak everyone's phone
+numbers to everyone else which, combined with this one, makes for
+interesting attacks. But this specific leak is more pernicious: apart
+from signal-cli users, the leak is not visible at all... While people
+clearly see each other's presence in a group, they definitely will not
+know that those little checkmark disclose more information than they
+seem to other users.
+
+This should be clearly be fixed and I hope the Signal people
+eventually do the right thing on this one.
+
+Note that I haven't gone through a formal disclosure process
+considering the relative mild severity of this security issue. I also
+considered the threat model followed by Signal, which typically
+reveals metadata such as phone numbers somewhat liberally elsewhere...
diff --git a/blog/signal-metadata/signal-screenshot.png b/blog/signal-metadata/signal-screenshot.png
new file mode 100644
index 00000000..7cfe80a4
Binary files /dev/null and b/blog/signal-metadata/signal-screenshot.png differ

clarify how much water we need
diff --git a/pleinair/liste.mdwn b/pleinair/liste.mdwn
index 62904845..cda52fd6 100644
--- a/pleinair/liste.mdwn
+++ b/pleinair/liste.mdwn
@@ -317,10 +317,16 @@ Médicaments:
 
 ### Consommation d'eau
 
-On peut compter, en moyenne, au moins un litre d'eau par jour par
-personne, sans compter l'eau nécessaire pour la vaisselle, le lavage
-et l'hygiène personnelle. L'hiver, la neige peut *parfois* être
-utilisée mais demande évidemment du carburant pour fondre. 
+L'hiver, on doit compter, en moyenne, au moins un litre d'eau par jour
+par personne, sans compter l'eau nécessaire pour la vaisselle, le
+lavage et l'hygiène personnelle. La neige peut *parfois* être utilisée
+mais demande évidemment du carburant pour fondre.
+
+L'été, les demandes d'eau sont plus grandes. Selon la température, on
+compte au moins 1.5L voire deux litres d'eau à boire par personne par
+jour.
+
+Pour purifier l'eau:
 
  * Les pompes à eau fonctionnent bien et sont très fiables, mais
    doivent être nettoyées périodiquement, ce qui peut être

yolo
diff --git a/blog/signal-metadata.mdwn b/blog/signal-metadata.mdwn
index 906f42e9..31ec3985 100644
--- a/blog/signal-metadata.mdwn
+++ b/blog/signal-metadata.mdwn
@@ -83,3 +83,6 @@ the (redacted and reformatted) conversation went:
     A-1> welcome home, sucker! ;)
     B-2> damn dog.
 
+
+
++ seen notifications?

first draft
diff --git a/blog/signal-metadata.mdwn b/blog/signal-metadata.mdwn
new file mode 100644
index 00000000..906f42e9
--- /dev/null
+++ b/blog/signal-metadata.mdwn
@@ -0,0 +1,85 @@
+Signal leaks all sorts of metadata. A particular leakage was
+especially surprising to a friend, let's call hime Bob, when we had a
+conversation that went a little like this:
+
+    A> hey friend! welcome home!
+    B> what? how did you know I got home? what the fuck man? did
+    you hack my machine? OMGWTFST-HUBERTBBQ?!
+
+Or something to that effect. I wish I had kept a copy now, because it
+was quite striking how easy it was for me to figure out when Bob got
+back home and how he had absolutely no clue how it happened.
+
+As it turns out, the receipt notifications in Signal are
+per-device. This means that the double-checkmark you see when a
+message is delivered to the device is actually only when a *first*
+device receives the message, regardless of the device. Behind the
+scenes, Signal actually sends notifications for *each* device, with a
+unique identifier for each device. This is easy to see with
+[signal-cli][]. For example, this is a normal notification:
+
+    Envelope from: “Bob” +15555555555 (device: 1)
+    Timestamp: 1532279834422 (2018-07-22T17:17:14.422Z)
+    Got receipt.
+
+That's Bob's phone telling me it received the message: great! The
+graphical Signal client adds the second checkmark and I'm happy to see
+that he got it. But then another notification comes in later:
+
+    Envelope from: “Bob” +15555555555 (device: 2)
+    Timestamp: 1532279901951 (2018-07-22T17:18:21.951Z)
+    Got receipt.
+
+Notice the device number there? It changed from `1` to `2`. This tells
+me this is a *different* device than the first one. In all but exotic
+configurations, device 1 will be a phone and 2 [Signal Desktop][]. In
+my case, I have experimented with *many* different configurations, so
+I have device numbers up to 8, but my phone is *still* device 1. 
+
+This means it is completely possible for an attacker to figure out
+when my phone goes online, reliably. It is also possible to make
+reasonable assertions about the identity of most devices: any device
+number above one is most likely a Signal Desktop client, which will
+indicate when each device goes online. This can be used to assert
+physical presence on different machines: the desktop at home, laptop
+in the office, or phone anywhere. It might not seem like much, but it
+sure felt creepy to Bob.
+
+This attack can also be carried that anyone who knows Bob's phone
+number. Because Signal is an open network, you are free to send
+messages to anyone without their consent. An attacker only has to send
+spam messages to a victim to figure out when they're online, how many
+devices they own and when they are online.
+
+Considering the unique identifiers do not show up in the GUI, they do
+not provide any user-visible functionality that I can think of. So I
+do not think they should be part of the protocol, and should be
+removed. The tradeoff involved in allowing peers to know that Bob
+received the message at all might be worth it: those double check
+marks are great. But I do not think they require having
+device-identifying metadata attached to them.
+
+While writing this article, I figure I would make sure I could
+reproduce those results, I wrote Bob again to ask for help. Here's how
+the (redacted and reformatted) conversation went:
+
+    A-1> hey you there?
+    * B-1 message received
+    A-1> i want to see if i can freak you out with signal again
+    * B-1 message received
+    A-1> i'm going to write about the issue, and i want to reproduce the results
+    * B-1 message received
+    B-1> he's driving
+    B-1> sure, I'll be your guinea pig he says
+    A-1> all he needs to do is open his laptop and start signal-desktop :p
+    * B-1 message received
+    B-1> we'll be home in 1h30
+    * B-1 message received
+    A-1> i'll know, don't worry :p
+
+~90 minutes pass:
+
+    * B-2 mesage received
+    A-1> welcome home, sucker! ;)
+    B-2> damn dog.
+

Revert "also show errors on stderr"
This mysteriously fails, blame bash.
This reverts commit 9e60c160be387c4f8f1c562e8bf2c5029961fe7d.
diff --git a/services/backup.mdwn b/services/backup.mdwn
index 9daebf59..f19f392a 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -393,7 +393,7 @@ feature allows you to write custom wrappers that get called by git
 when an unknown command is sent. I wrote this wrapper in
 `~/git-shell-commands/rsync`:
 
-    #!/bin/bash
+    #!/bin/sh
 
     for i; do
     	case $i in
@@ -404,7 +404,7 @@ when an unknown command is sent. I wrote this wrapper in
     		true
     		;;
     	*)
-    		tee >(logger) <<EOF
+    		logger <<EOF
     disallowed rsync argument: '$i'
     EOF
     		exit 1
@@ -412,7 +412,7 @@ when an unknown command is sent. I wrote this wrapper in
     	esac
     done
 
-    tee >(logger) <<EOF
+    logger <<EOF
     passthrough rsync command: '$@'
     EOF
 

also show errors on stderr
unfortunately requires bash
diff --git a/services/backup.mdwn b/services/backup.mdwn
index f19f392a..9daebf59 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -393,7 +393,7 @@ feature allows you to write custom wrappers that get called by git
 when an unknown command is sent. I wrote this wrapper in
 `~/git-shell-commands/rsync`:
 
-    #!/bin/sh
+    #!/bin/bash
 
     for i; do
     	case $i in
@@ -404,7 +404,7 @@ when an unknown command is sent. I wrote this wrapper in
     		true
     		;;
     	*)
-    		logger <<EOF
+    		tee >(logger) <<EOF
     disallowed rsync argument: '$i'
     EOF
     		exit 1
@@ -412,7 +412,7 @@ when an unknown command is sent. I wrote this wrapper in
     	esac
     done
 
-    logger <<EOF
+    tee >(logger) <<EOF
     passthrough rsync command: '$@'
     EOF
 

whitelist more seemingly harmless rsync options
diff --git a/services/backup.mdwn b/services/backup.mdwn
index 1fcde75a..f19f392a 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -397,10 +397,10 @@ when an unknown command is sent. I wrote this wrapper in
 
     for i; do
     	case $i in
-    	--server|--sender|-WIe.LsfxC|.)
+    	--server|--sender|-WIe.LsfxC|-de.LsfxC|-re.iLsfxC|--log-format=X|--partial-dir)
     		true
     		;;
-    	/home/anarcat/offsite/*.git/*)
+    	.rsync-partial|.|/home/anarcat/offsite/*.git/*|/home/anarcat/offsite/*.annex/*)
     		true
     		;;
     	*)

note how to workaround another limitation
diff --git a/services/backup.mdwn b/services/backup.mdwn
index e46bc54e..1fcde75a 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -356,6 +356,19 @@ Then, in each repo, configure the key:
 
     git config core.sshCommand "ssh -i /home/anarcat/.ssh/id_rsa.git-annex -o IdentitiesOnly=yes"
 
+Unfortunately, because git-annex does not respect the
+`core.sshCommand` configuration in git, we need to use a special
+remote configured in `~/.ssh/config` as such:
+
+    Host backup-annex
+        # special key for git-annex
+        IdentitiesOnly yes
+        IdentityFile ~/.ssh/id_rsa.git-annex
+
+And then change the remote:
+
+    git remote set-url offsite backup-annex:/srv/offsite/foo/
+
 Then a cronjob (or the assistant, but i chose the former) can be ran
 to sync changes automatically:
 

add safer rsync mode
diff --git a/services/backup.mdwn b/services/backup.mdwn
index 95ada0c2..e46bc54e 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -372,6 +372,46 @@ The problem here is that `--quiet` is not completely quiet:
 
 git-annex should pass `--quiet` down to `git commit`...
 
+Another problem is that this only works for regular git remotes. This
+will fail on encrypted remotes, which rely on rsync. A workaround I
+found was to rely on a feature of the `git-shell` command, which
+`git-annex-shell` calls unless `GIT_ANNEX_SHELL_LIMITED` is set. That
+feature allows you to write custom wrappers that get called by git
+when an unknown command is sent. I wrote this wrapper in
+`~/git-shell-commands/rsync`:
+
+    #!/bin/sh
+
+    for i; do
+    	case $i in
+    	--server|--sender|-WIe.LsfxC|.)
+    		true
+    		;;
+    	/home/anarcat/offsite/*.git/*)
+    		true
+    		;;
+    	*)
+    		logger <<EOF
+    disallowed rsync argument: '$i'
+    EOF
+    		exit 1
+    		;;
+    	esac
+    done
+
+    logger <<EOF
+    passthrough rsync command: '$@'
+    EOF
+
+    exec rsync "$@"
+
+This allows only certain `rsync` commands to go through, namely the
+normal rsync arguments passed by git-annex, but also only paths along
+a restricted pattern. Yes, this means an attacker can overwrite any
+git repository it choses, but it needs to be a bare git repository
+(`/*.git/*`), as there is no way to use gcrypt with append-only
+repositories, unfortunately.
+
 ### Encrypted remotes
 
 To setup the encrypted for pictures remotes, first the git-annex

restricted, append-only shell done for borg, update plan
diff --git a/services/backup.mdwn b/services/backup.mdwn
index f5863c54..95ada0c2 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -272,26 +272,21 @@ documentation.
  3. automate crypto:
  
     a. change passphrase
-    b. include it in script here
-    c. include a GnuPG symmetric encrypted copy of the pass on the offsite disk
+    a. include it in script here
+    a. include a GnuPG symmetric encrypted copy of the pass on the offsite disk
 
     Note: this approach should work, but needs a full shell when the
     key is changed, so it is fundamentally [incompatible with
     restricted shell provider](https://github.com/borgbackup/borg/issues/3585#issuecomment-362110929)
 
- 4. set append-only mode on server:
+ 4. set [append-only mode](https://borgbackup.readthedocs.io/en/stable/usage/notes.html#append-only-mode) and restricted shell by allowing only
+    the right borg command to be called, in `authorized_keys`:
 
-        borg config PATH append_only 1
-
- 5. somehow make sure server is called with:
-
-        borg serve --append-only
+        command="borg serve --append-only",restrict ssh-rsa AAAAB...
 
  5. test full run again
 
- 6. switch to restricted shell, remove on-disk SSH keys from `authorized_keys`
-
- 7. document this in the borg documentation itself?
+ 6. document this in the borg documentation itself or at least here
 
 ### Remaining work on git-annex
 

update progress with backups
part of automation complete, still sticky bits with gpg, of course
diff --git a/services/backup.mdwn b/services/backup.mdwn
index 6b878b45..f5863c54 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -300,7 +300,7 @@ documentation.
 
  2. enable in script sync in script (done)
 
- 3. resync everything again (in progress)
+ 3. resync everything again (done)
 
  4. add Photos repo with [git-annex encryption](http://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/) (blocker: [error
     while setting up gcrypt remote](https://git-annex.branchable.com/bugs/gcrypt_repository_not_found/), fixed by removing the
@@ -313,10 +313,19 @@ documentation.
     `GIT_ANNEX_SHELL_DIRECTORY` would be useful, but we have multiple
     repositories we want to allow, and that, if I read
     `CmdLine.GitAnnexShell.Checks.checkDirectory` correctly, is not
-    pattern-based but an exact match (using `equalFilePath`).
+    pattern-based but an exact match (using `equalFilePath`). (done,
+    see below)
 
- 4. make repositories made [append-only](https://git-annex.branchable.com/todo/append-only_mode/?updated), not currently supported
-    by git-annex
+ 6. make repositories made [append-only](https://git-annex.branchable.com/todo/append-only_mode/?updated), not currently supported
+    by git-annex (done, see below)
+
+ 7. change encryption key for encrypted repositories so they work
+    unattended. the sticky question here is which key to use. a
+    different subkey? or a whole other keypair? if that, then how to
+    deal with expiry, propagation, etc?
+
+ 8. setup cronjobs for all repositories (partly done: non-encrypted
+    repositories are part of the manual backup script)
 
 ### Random git-annex docs
 
@@ -331,6 +340,43 @@ This is how the git-annex repositories were setup at first:
         git -C /srv/$r annex sync --content
     done
 
+### Append-only git repositories
+
+On the server, for each repo, disable destructive pushes:
+
+    git config receive.denyDeletes true
+    git config receive.denyNonFastForwards true
+
+And force git-annex to be used for that key, in `~/.ssh/authorized_keys`:
+
+    command="GIT_ANNEX_SHELL_APPENDONLY=true git-annex-shell -c \"$SSH_ORIGINAL_COMMAND\"",restrict ssh-rsa AAAAB3NzaC1y[...] user@example.com
+
+This only works with git-annex 6.20180529 or later.
+
+Then, on the client, generate a key for this purpose:
+
+    ssh-keygen -f ~/.ssh/id_rsa.git-annex
+
+Then, in each repo, configure the key:
+
+    git config core.sshCommand "ssh -i /home/anarcat/.ssh/id_rsa.git-annex -o IdentitiesOnly=yes"
+
+Then a cronjob (or the assistant, but i chose the former) can be ran
+to sync changes automatically:
+
+    for r in audiobooks books espresso roms mp3 incoming video; do
+        echo "syncing $r"
+        git -C /srv/$r annex sync --content -J2 
+    done
+
+The problem here is that `--quiet` is not completely quiet:
+
+    $ LANG=C.UTF-8 git annex sync --content --quiet 
+    On branch master
+    nothing to commit, working tree clean
+
+git-annex should pass `--quiet` down to `git commit`...
+
 ### Encrypted remotes
 
 To setup the encrypted for pictures remotes, first the git-annex

add spare cover kit
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index f13ae1e1..0dd68dc7 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -209,11 +209,13 @@ Gogosses:
  1. lens cap holder: [regular sensei](https://www.bhphotovideo.com/c/product/834774-REG/Sensei_CK_L_Cap_Keeper_for_Lens.html?sts=pi) seems fine, 2USD
  2. UV filter for zoom ø62mm, [9-50$ on B&H](https://www.bhphotovideo.com/c/search?setNs=p_OVER_ALL_RATE%7c1&Ns=p_OVER_ALL_RATE%7c1&ci=112&fct=fct_circular-sizes_27%7c62mm%2bfct_filter-type_39%7cuv&srtclk=sort&N=4026728358&), e.g. [B+W 62mm UV
     Haze SC 010 Filter](https://www.bhphotovideo.com/c/product/11969-REG/B_W_65070127_62mm_Ultraviolet_UV_Filter.html) at 20$
- 3. un doubleur:
+ 3. [Spare cover kit](https://www.bhphotovideo.com/c/product/1263618-REG/fujifilm_16519522_x_t2_cover_kit.html) (yes, I already lost the flash sync terminal
+    cover), 9$USD, B/O
+ 4. un doubleur:
     * [Vivitar 62mm 2.2x](https://www.bhphotovideo.com/c/product/1150442-REG/vivitar_viv_62t_62mm_2_2x_telephoto_attachment.html) - cheapo?, 38$USD
     * [Bower VLB3558 3.5x](https://www.bhphotovideo.com/c/product/700003-REG/Bower_VLB3558_VLB3558_3_5x_Telephoto_Lens.html) - chromatic aberration? 28$USD
- 4. un holder a lentilles "lens flipper" [75$USD @ B&H](https://www.bhphotovideo.com/c/product/1203066-REG/gowing_8809416750118_lens_flipper_for_mount.html)
- 5. un tube macro [MCEX-11 ou MCEX-16](http://www.fujifilm.com/products/digital_cameras/accessories/lens/#mountadapter), [this table](http://www.fujifilm.com/products/digital_cameras/accessories/pdf/mcex_01.pdf) shows the
+ 5. un holder a lentilles "lens flipper" [75$USD @ B&H](https://www.bhphotovideo.com/c/product/1203066-REG/gowing_8809416750118_lens_flipper_for_mount.html)
+ 6. un tube macro [MCEX-11 ou MCEX-16](http://www.fujifilm.com/products/digital_cameras/accessories/lens/#mountadapter), [this table](http://www.fujifilm.com/products/digital_cameras/accessories/pdf/mcex_01.pdf) shows the
     magnification/distance for various lens. MCEX-16, for example,
     does not improve the 60mm macro much (0.5x → 0.76x, 185mm → 143mm)
     but it does wonder with the 18-55mm (0.08x → 0.97x, 211mm → 4mm,

cleaning gear not required
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index 111b141a..f13ae1e1 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -207,11 +207,7 @@ Reference
 Gogosses:
 
  1. lens cap holder: [regular sensei](https://www.bhphotovideo.com/c/product/834774-REG/Sensei_CK_L_Cap_Keeper_for_Lens.html?sts=pi) seems fine, 2USD
- 2. cleaning gear:
-    * [cleaning pen](https://www.bhphotovideo.com/c/product/1051483-REG/lenspen_nlp1_c_nlp1c_lens_pen.html): ~10USD. haven't looked at alternative brushes.
-    * air brush - apparently, that's best to clear sensors,
-      e.g. [blower on B&H](https://www.bhphotovideo.com/c/buy/Blowers-Compressed-Air/ci/18806/N/4077634545?origSearch=blower), 5-15$ [red](https://www.bhphotovideo.com/c/product/838821-REG/sensei_bl_014_bulb_air_blower_cleaning_system.html) is easier to find (8$USD)
- 3. UV filter for zoom ø62mm, [9-50$ on B&H](https://www.bhphotovideo.com/c/search?setNs=p_OVER_ALL_RATE%7c1&Ns=p_OVER_ALL_RATE%7c1&ci=112&fct=fct_circular-sizes_27%7c62mm%2bfct_filter-type_39%7cuv&srtclk=sort&N=4026728358&), e.g. [B+W 62mm UV
+ 2. UV filter for zoom ø62mm, [9-50$ on B&H](https://www.bhphotovideo.com/c/search?setNs=p_OVER_ALL_RATE%7c1&Ns=p_OVER_ALL_RATE%7c1&ci=112&fct=fct_circular-sizes_27%7c62mm%2bfct_filter-type_39%7cuv&srtclk=sort&N=4026728358&), e.g. [B+W 62mm UV
     Haze SC 010 Filter](https://www.bhphotovideo.com/c/product/11969-REG/B_W_65070127_62mm_Ultraviolet_UV_Filter.html) at 20$
  3. un doubleur:
     * [Vivitar 62mm 2.2x](https://www.bhphotovideo.com/c/product/1150442-REG/vivitar_viv_62t_62mm_2_2x_telephoto_attachment.html) - cheapo?, 38$USD
@@ -226,6 +222,12 @@ Gogosses:
     for lighting!), [94$USD](https://www.bhphotovideo.com/c/product/1102440-REG/fujifilm_mcex_11_macro_extension_tubes.html#!)/[87$USD at B&H](https://www.bhphotovideo.com/c/product/1102439-REG/fujifilm_mcex_16_macro_extension_tubes.html), [120$CAD at
     Henry's](https://www.henrys.com/88489-FUJIFILM-X-MOUNT-16MM-EXTENSION-TUBE.aspx), [110$CAD a lozeau](https://lozeau.com/produits/fr/fujifilm/tube-d-extension-macro-fujifilm-mcex-16-p25463/), [good comparison between the
     two lenses](https://www.fujivsfuji.com/mcex-11-vs-mcex-16/). might not be worth getting the MCE-16
+ 2. cleaning gear, not necessary as I found my old gear already:
+    * [cleaning pen](https://www.bhphotovideo.com/c/product/1051483-REG/lenspen_nlp1_c_nlp1c_lens_pen.html): ~10USD. haven't looked at alternative brushes
+      and the blower i have has a brush. still looks interesting.
+    * blower are apparently the best solution to clear sensors,
+      e.g. [blower on B&H](https://www.bhphotovideo.com/c/buy/Blowers-Compressed-Air/ci/18806/N/4077634545?origSearch=blower), 5-15$. a [red one](https://www.bhphotovideo.com/c/product/838821-REG/sensei_bl_014_bulb_air_blower_cleaning_system.html) is easier to find
+      in a bag (8$USD). i already have a blower, so not necessary.
 
 Lentilles:
 

more filter info
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index cca689f1..111b141a 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -147,7 +147,8 @@ Lentilles
   lens"), [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/), bonne lentille de portrait, mais pas
   aussi lumineux que la 56mm f/1.2 ou la 50mm f/2. "demi-macro", a
   besoin d'un tube approcher du 1x, voir plus bas vue à 420-700$ sur kijiji, payée
-  425$, 790$ lozeau.
+  425$, 790$ lozeau. Couvert par un filtre UV B+W ø39mm ("B+W 39 010 UV Haze
+  1x E")
 
 ### Vieux kit
 
@@ -157,10 +158,12 @@ j'utilise actuellement à moins d'utiliser un adaptateur.
 * Image 70-210mm f3.8, [Minolta SR], ???
 * Minolta 135mm f3.5, [Minolta SR], 30$ ebay
 * Minolta 50mm f2, [Minolta SR], 50$ kijiji
-* Minolta 28mm f2.8, [Minolta SR], 50$ kijiji
+* Minolta 28mm f2.8, [Minolta SR], 50$ kijiji, with Vivitar ø55mm
+  Skylight 1A filter and hood
 * Vivitar 2x converter, [Minolta SR], 10$ kijiji
 * SMC Pentax-M 50mm f1.4, [Pentax K], 115$ amazon, 140$ kijiji
-* Canon 50mm f1.8 S.C., [Canon FD][], 60$ kijiji, 40$ ebay
+* Canon 50mm f1.8 S.C., [Canon FD][], 60$ kijiji, 40$ ebay, with Hoya
+  ø55mm UV filter
 * Soligor 75-260mm f4.5, [Canon FD], 150$ kijiji, 30-80$ ebay,
   beautiful leather case
 * Canon 28-80mm f3.5-5.6, [Canon EF], 70$ kijiji, 45$ ebay, 70$ amazon

clarify statements
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index 2b534c2a..cca689f1 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -135,12 +135,14 @@ Lentilles
 ---------
 
 * Fujifilm [18-55mm f/2.8-4 R LM OIS ø58](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf18_55mmf28_4_r_lm_ois/), vient avec le kit X-T2,
-  avec un [filtre 58mm XS-Pro Clear MRC-Nano 007 Filter](https://www.bhphotovideo.com/c/product/756813-REG/B_W_66_1066106_58mm_XS_Pro_NANO_Clear.html) payé 30$USD
-* Fujifilm [55-200mm f/3.5-4.8 R LM OIS ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf55_200mmf35_48_r_lm_ois/), payée 650$ sur kijiji
+  protégé par un [filtre 58mm XS-Pro Clear MRC-Nano 007 Filter](https://www.bhphotovideo.com/c/product/756813-REG/B_W_66_1066106_58mm_XS_Pro_NANO_Clear.html)
+  payé 30$USD, dès les débuts. Excellent lentille de base.
+* Fujifilm [55-200mm f/3.5-4.8 R LM OIS ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf55_200mmf35_48_r_lm_ois/), payée 650$ sur
+  kijiji. Excellent téléobjectif.
 * Fujifilm [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm) ("extraordinary lens"),
-  vraiment une jolie petite lentille, très pratique pour le voyage et
-  rend l'appareil discret, vue pour 300-350$ sur kijiji mais payée
-  375$ au final par impatience, 540$ chez Lozeau
+  jolie petite lentille, pratique pour le voyage et rend l'appareil
+  discret, vue pour 300-350$ sur kijiji mais payée 375$ au final par
+  impatience, 540$ chez Lozeau
 * Fujifilm [60mm f/2.4 R Macro ø39](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm) ("extraordinary
   lens"), [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/), bonne lentille de portrait, mais pas
   aussi lumineux que la 56mm f/1.2 ou la 50mm f/2. "demi-macro", a

remove dupe and try to avoid it in the future
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index aa97ec2e..2b534c2a 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -109,8 +109,8 @@ probably be improved.
 Inventaire
 ==========
 
-Appareils numériques
---------------------
+Appareils
+---------
 
 * [Canon Powershot G12] - firmware 1.00G
 * [Nokia N900]
@@ -123,14 +123,12 @@ Appareils numériques
  [Canon Powershot G12]: https://en.wikipedia.org/wiki/Canon_PowerShot_G12
  [Canon Powershot A430]: https://en.wikipedia.org/wiki/Canon_PowerShot_A430 
 
-Appareils analogues
--------------------
+### Appareils analogues
 
 * [Minolta SRT-200](http://www.rokkorfiles.com/SRT%20Series.htm#b200)
 * [Pentax ME](https://en.wikipedia.org/wiki/Pentax_ME)
 * [Canon FTb](https://en.wikipedia.org/wiki/Canon_FTb)
 * [Canon EOS Rebel 2000](https://en.wikipedia.org/wiki/Canon_EOS_Rebel_2000)
-* [Canon Powershot A430](https://en.wikipedia.org/wiki/Canon_PowerShot_A)
 * Ricoh one take AF 39mm 3.9 - ma première caméra!
 
 Lentilles

more details on current lens set
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index ea32690b..aa97ec2e 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -137,17 +137,17 @@ Lentilles
 ---------
 
 * Fujifilm [18-55mm f/2.8-4 R LM OIS ø58](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf18_55mmf28_4_r_lm_ois/), vient avec le kit X-T2,
-  avec un [filtre 58mm XS-Pro Clear MRC-Nano 007 Filter](https://www.bhphotovideo.com/c/product/756813-REG/B_W_66_1066106_58mm_XS_Pro_NANO_Clear.html), 30$USD
-* Fujifilm [55-200mm f/3.5-4.8 R LM OIS ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf55_200mmf35_48_r_lm_ois/), 650$ sur kijiji
-* Fujifilm [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), 375$ sud kijiji, [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm)
-  ("extraordinary lens"), vraiment une jolie petite lentille, très
-  pratique pour le voyage et rend l'appareil discret, 300-350$ sur
-  kijiji, 540$ lozeau
+  avec un [filtre 58mm XS-Pro Clear MRC-Nano 007 Filter](https://www.bhphotovideo.com/c/product/756813-REG/B_W_66_1066106_58mm_XS_Pro_NANO_Clear.html) payé 30$USD
+* Fujifilm [55-200mm f/3.5-4.8 R LM OIS ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf55_200mmf35_48_r_lm_ois/), payée 650$ sur kijiji
+* Fujifilm [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm) ("extraordinary lens"),
+  vraiment une jolie petite lentille, très pratique pour le voyage et
+  rend l'appareil discret, vue pour 300-350$ sur kijiji mais payée
+  375$ au final par impatience, 540$ chez Lozeau
 * Fujifilm [60mm f/2.4 R Macro ø39](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm) ("extraordinary
-  lens"), [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/), une bonne lentille de macro, bon
-  compromis pour le portrait, mais pas aussi lumineux que la 56mm
-  f/1.2 ou la 50mm f/2. 420-700$ sur kijiji, 790$ lozeau (26.7cm range
-  min)
+  lens"), [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/), bonne lentille de portrait, mais pas
+  aussi lumineux que la 56mm f/1.2 ou la 50mm f/2. "demi-macro", a
+  besoin d'un tube approcher du 1x, voir plus bas vue à 420-700$ sur kijiji, payée
+  425$, 790$ lozeau.
 
 ### Vieux kit
 

flash testing
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index 6cd16c92..ea32690b 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -176,8 +176,9 @@ Note: of all those lens, only the [Canon EF] and [Pentax K] are still in use.
 Flash
 -----
 
-* Vivitar 2000, horse-shoe avec câble de synchro (pentax?)
-* Suntax 16A
+* Vivitar 2000, horse-shoe avec câble de synchro (pentax?), does not
+  charge, tested on X-T2 2018-07-02
+* Suntax 16A, works, tested on X-T2 2018-07-02
 
 Reference
 ---------

split out old kit and evaluate price
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index ab83fc07..6cd16c92 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -148,16 +148,23 @@ Lentilles
   compromis pour le portrait, mais pas aussi lumineux que la 56mm
   f/1.2 ou la 50mm f/2. 420-700$ sur kijiji, 790$ lozeau (26.7cm range
   min)
-* Image 70-210mm 3.8, [Minolta SR] (monté sur le Minolta SRT-200)
-* Minolta 135mm 3.5, [Minolta SR]
-* Minolta 50mm 2, [Minolta SR]
-* Vivitar 2x converter, [Minolta SR]
-* SMC Pentax-M 50mm 1.4, [Pentax K] (monté sur le Pentax ME, mais malheureusement égratignée)
-* Canon 50mm 1.8, [Canon FD][] (monté sur le Canon FTb)
-* Soligor 75-260mm 4.5, [Canon FD]
-* Canon 28-80mm 3.5-5.6, [Canon EF]
-* Canon 75-300mm 4-5.6, [Canon EF]
+
+### Vieux kit
+
+Ces lentilles ne sont pas compatibles avec l'équipement numérique que
+j'utilise actuellement à moins d'utiliser un adaptateur.
+
+* Image 70-210mm f3.8, [Minolta SR], ???
 * Minolta 135mm f3.5, [Minolta SR], 30$ ebay
+* Minolta 50mm f2, [Minolta SR], 50$ kijiji
+* Minolta 28mm f2.8, [Minolta SR], 50$ kijiji
+* Vivitar 2x converter, [Minolta SR], 10$ kijiji
+* SMC Pentax-M 50mm f1.4, [Pentax K], 115$ amazon, 140$ kijiji
+* Canon 50mm f1.8 S.C., [Canon FD][], 60$ kijiji, 40$ ebay
+* Soligor 75-260mm f4.5, [Canon FD], 150$ kijiji, 30-80$ ebay,
+  beautiful leather case
+* Canon 28-80mm f3.5-5.6, [Canon EF], 70$ kijiji, 45$ ebay, 70$ amazon
+* Canon 75-300mm f4-5.6 III, [Canon EF], [200$ Amazon](https://www.amazon.com/Canon-75-300mm-4-5-6-Telephoto-Cameras/dp/B00004THD0), 100-150$ kijiji
 
  [Minolta SR]: https://en.wikipedia.org/wiki/Minolta_SR-mount
  [Pentax K]: https://en.wikipedia.org/wiki/Pentax_K-mount

add two missing pieces i found in inventory
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index 49810f45..ab83fc07 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -130,6 +130,7 @@ Appareils analogues
 * [Pentax ME](https://en.wikipedia.org/wiki/Pentax_ME)
 * [Canon FTb](https://en.wikipedia.org/wiki/Canon_FTb)
 * [Canon EOS Rebel 2000](https://en.wikipedia.org/wiki/Canon_EOS_Rebel_2000)
+* [Canon Powershot A430](https://en.wikipedia.org/wiki/Canon_PowerShot_A)
 * Ricoh one take AF 39mm 3.9 - ma première caméra!
 
 Lentilles
@@ -156,6 +157,7 @@ Lentilles
 * Soligor 75-260mm 4.5, [Canon FD]
 * Canon 28-80mm 3.5-5.6, [Canon EF]
 * Canon 75-300mm 4-5.6, [Canon EF]
+* Minolta 135mm f3.5, [Minolta SR], 30$ ebay
 
  [Minolta SR]: https://en.wikipedia.org/wiki/Minolta_SR-mount
  [Pentax K]: https://en.wikipedia.org/wiki/Pentax_K-mount

choose holder and blower
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index afbc3614..49810f45 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -193,11 +193,11 @@ Reference
 
 Gogosses:
 
- 1. lens cap holder: [1](https://www.bhphotovideo.com/c/product/834774-REG/Sensei_CK_L_Cap_Keeper_for_Lens.html?sts=pi) or [2](https://www.bhphotovideo.com/c/product/850525-REG/Sensei_ck_lp_Cap_Keeper_Plus_Lens.html), haven't found others
+ 1. lens cap holder: [regular sensei](https://www.bhphotovideo.com/c/product/834774-REG/Sensei_CK_L_Cap_Keeper_for_Lens.html?sts=pi) seems fine, 2USD
  2. cleaning gear:
     * [cleaning pen](https://www.bhphotovideo.com/c/product/1051483-REG/lenspen_nlp1_c_nlp1c_lens_pen.html): ~10USD. haven't looked at alternative brushes.
     * air brush - apparently, that's best to clear sensors,
-      e.g. [blower on B&H](https://www.bhphotovideo.com/c/buy/Blowers-Compressed-Air/ci/18806/N/4077634545?origSearch=blower), 5-15$
+      e.g. [blower on B&H](https://www.bhphotovideo.com/c/buy/Blowers-Compressed-Air/ci/18806/N/4077634545?origSearch=blower), 5-15$ [red](https://www.bhphotovideo.com/c/product/838821-REG/sensei_bl_014_bulb_air_blower_cleaning_system.html) is easier to find (8$USD)
  3. UV filter for zoom ø62mm, [9-50$ on B&H](https://www.bhphotovideo.com/c/search?setNs=p_OVER_ALL_RATE%7c1&Ns=p_OVER_ALL_RATE%7c1&ci=112&fct=fct_circular-sizes_27%7c62mm%2bfct_filter-type_39%7cuv&srtclk=sort&N=4026728358&), e.g. [B+W 62mm UV
     Haze SC 010 Filter](https://www.bhphotovideo.com/c/product/11969-REG/B_W_65070127_62mm_Ultraviolet_UV_Filter.html) at 20$
  3. un doubleur:

Added a comment: Collabora
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_11_68c872ca5bccdc425239e9c6c6d43a04._comment b/blog/2018-06-26-collaborative-editors-history/comment_11_68c872ca5bccdc425239e9c6c6d43a04._comment
new file mode 100644
index 00000000..ed128765
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_11_68c872ca5bccdc425239e9c6c6d43a04._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ ip="91.64.229.53"
+ claimedauthor="Jos Poortvliet"
+ url="jos@nextcloud.com"
+ subject="Collabora"
+ date="2018-07-02T16:53:19Z"
+ content="""
+I do believe it was Collabora who developed the 'online' part and released it first, and then contributed it back to LibreOffice which now also has it - credit-where-it-is-due would be to call it Collabora Online, I think.
+
+Sadly the collaborative editing never made it into Kate proper...
+
+Note that Abiword doesn't have a web view like Collabora/LibreOffice has, and LibreOffice still doesn't have collaborative editing on the desktop like Abiword has (but I believe work is happening to enable it).
+
+There once upon a time was also the quite interesting Documents app for ownCloud/Nextcloud based on WebODF. It was a full javascript ODF editor that used the DOM tree, css etc to directly display and edit documents. So it had no import/export, it just directly loaded them and showed the documents in the browser! Quite clever, I don't think as of today any web editor can do that still). The biggest advantage was that the editor was non-destructive, even if it didn't understand or know how to display parts, they wouldn't get deleted/damaged on saving. There is a back-end for it that uses LibreOffice on the server to convert MS Word docs into ODF and back after editing, but, as that IS a destructive import/export, this has its limitations. https://github.com/nextcloud/documents
+
+Sadly, while we kept it working with Nc 12 and will probably make it work with 13 someday, the actual engine is unmaintained so it won't be useful for much longer as browsers move on and break compatibility...
+"""]]

documenter le tube macro
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index 7d735307..afbc3614 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -204,6 +204,15 @@ Gogosses:
     * [Vivitar 62mm 2.2x](https://www.bhphotovideo.com/c/product/1150442-REG/vivitar_viv_62t_62mm_2_2x_telephoto_attachment.html) - cheapo?, 38$USD
     * [Bower VLB3558 3.5x](https://www.bhphotovideo.com/c/product/700003-REG/Bower_VLB3558_VLB3558_3_5x_Telephoto_Lens.html) - chromatic aberration? 28$USD
  4. un holder a lentilles "lens flipper" [75$USD @ B&H](https://www.bhphotovideo.com/c/product/1203066-REG/gowing_8809416750118_lens_flipper_for_mount.html)
+ 5. un tube macro [MCEX-11 ou MCEX-16](http://www.fujifilm.com/products/digital_cameras/accessories/lens/#mountadapter), [this table](http://www.fujifilm.com/products/digital_cameras/accessories/pdf/mcex_01.pdf) shows the
+    magnification/distance for various lens. MCEX-16, for example,
+    does not improve the 60mm macro much (0.5x → 0.76x, 185mm → 143mm)
+    but it does wonder with the 18-55mm (0.08x → 0.97x, 211mm → 4mm,
+    that is not a typo and means the lens is almost touching the
+    subject, which might be impractical for some subjects, especially
+    for lighting!), [94$USD](https://www.bhphotovideo.com/c/product/1102440-REG/fujifilm_mcex_11_macro_extension_tubes.html#!)/[87$USD at B&H](https://www.bhphotovideo.com/c/product/1102439-REG/fujifilm_mcex_16_macro_extension_tubes.html), [120$CAD at
+    Henry's](https://www.henrys.com/88489-FUJIFILM-X-MOUNT-16MM-EXTENSION-TUBE.aspx), [110$CAD a lozeau](https://lozeau.com/produits/fr/fujifilm/tube-d-extension-macro-fujifilm-mcex-16-p25463/), [good comparison between the
+    two lenses](https://www.fujivsfuji.com/mcex-11-vs-mcex-16/). might not be worth getting the MCE-16
 
 Lentilles:
 

two more lenses, add x-e3
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index 93d7a6fd..7d735307 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -138,6 +138,15 @@ Lentilles
 * Fujifilm [18-55mm f/2.8-4 R LM OIS ø58](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf18_55mmf28_4_r_lm_ois/), vient avec le kit X-T2,
   avec un [filtre 58mm XS-Pro Clear MRC-Nano 007 Filter](https://www.bhphotovideo.com/c/product/756813-REG/B_W_66_1066106_58mm_XS_Pro_NANO_Clear.html), 30$USD
 * Fujifilm [55-200mm f/3.5-4.8 R LM OIS ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf55_200mmf35_48_r_lm_ois/), 650$ sur kijiji
+* Fujifilm [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), 375$ sud kijiji, [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm)
+  ("extraordinary lens"), vraiment une jolie petite lentille, très
+  pratique pour le voyage et rend l'appareil discret, 300-350$ sur
+  kijiji, 540$ lozeau
+* Fujifilm [60mm f/2.4 R Macro ø39](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm) ("extraordinary
+  lens"), [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/), une bonne lentille de macro, bon
+  compromis pour le portrait, mais pas aussi lumineux que la 56mm
+  f/1.2 ou la 50mm f/2. 420-700$ sur kijiji, 790$ lozeau (26.7cm range
+  min)
 * Image 70-210mm 3.8, [Minolta SR] (monté sur le Minolta SRT-200)
 * Minolta 135mm 3.5, [Minolta SR]
 * Minolta 50mm 2, [Minolta SR]
@@ -182,7 +191,7 @@ Reference
 
 Évidemment, je magasine encore...
 
-Gogogsses:
+Gogosses:
 
  1. lens cap holder: [1](https://www.bhphotovideo.com/c/product/834774-REG/Sensei_CK_L_Cap_Keeper_for_Lens.html?sts=pi) or [2](https://www.bhphotovideo.com/c/product/850525-REG/Sensei_ck_lp_Cap_Keeper_Plus_Lens.html), haven't found others
  2. cleaning gear:
@@ -196,22 +205,10 @@ Gogogsses:
     * [Bower VLB3558 3.5x](https://www.bhphotovideo.com/c/product/700003-REG/Bower_VLB3558_VLB3558_3_5x_Telephoto_Lens.html) - chromatic aberration? 28$USD
  4. un holder a lentilles "lens flipper" [75$USD @ B&H](https://www.bhphotovideo.com/c/product/1203066-REG/gowing_8809416750118_lens_flipper_for_mount.html)
 
-Lentilles primes:
+Lentilles:
 
- 4. [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm) ("extraordinary lens"),
-    vraiment une jolie petite lentille, très pratique pour le voyage
-    et rend l'appareil discret, 300-350$ sur kijiji, 540$ lozeau
- 5. [35mm f/2 R WR ø43](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf2_r_wr/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f2.htm), [fstoppers](https://fstoppers.com/gear/fstoppers-reviews-fujifilm-35mm-f2-wr-158227), bonne
+ 1. [35mm f/2 R WR ø43](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf2_r_wr/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f2.htm), [fstoppers](https://fstoppers.com/gear/fstoppers-reviews-fujifilm-35mm-f2-wr-158227), bonne
     taille, scellée, 350-400$ sur kijiji , 500$ lozeau
- 6. [60mm f/2.4 R Macro ø39](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm) ("extraordinary lens"),
-    [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/), une bonne lentille de macro, bon compromis
-    pour le portrait, mais pas aussi lumineux que la 56mm f/1.2 ou la
-    50mm f/2. 420-700$ sur kijiji, 790$ lozeau (26.7cm range min)
-
-Range: 1070$-1450$ sur kijiji, 1830$ lozeau
-
-Autres possibilités, mais un peu hors de prix...
-
  1. [23mm f/1.4 R ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf23mmf14_r/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/23mm-f14.htm) ("extraordinary lens"),
     [fstoppers](https://fstoppers.com/gear/worlds-quickest-lens-review-fuji-xf-23mm-14r-8342) (glowing review), 700-900$ on kijiji
  2. [16-55mm f/2.8 R LM WR ø77](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf16_55mmf28_r_lm_wr/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/16-55mm-f28.htm), [Phoblographer](https://www.thephoblographer.com/2015/03/12/review-fujifilm-16-55mm-f2-8-lm-wr-fujifilm-x-mount/), huge
@@ -222,7 +219,13 @@ Autres possibilités, mais un peu hors de prix...
     again), [Photography life](https://photographylife.com/reviews/fuji-xf-56mm-f-1-2-r) ("one of the best prime portrait
     lenses on the market") 900$ sur kijiji, 1175$ lozeau, not so great
     for macro (70cm min)
- 5. [X100f ø49](http://www.fujifilm.com/products/digital_cameras/x/fujifilm_x100f/) 1200-1600$ on kijiji
+
+Second appareil:
+
+ 4. [X-E3](http://www.fujifilm.com/products/digital_cameras/x/fujifilm_x_e3/), [dpreview](https://www.dpreview.com/reviews/fujifilm-x-e3-review/), 800CAD on kijiji with a 35mm f/1.4!,
+    [1450$ lozeau](https://lozeau.com/produits/fr/photo/appareils-sans-miroir-hybrides/fujifilm/fujifilm/ensemble-fujifilm-x-e3-noir-avec-23mm-f-2-r-wr-p31164c74c77c101/?limit=100), similar size than the x100f but interchangeable
+    lenses and cheaper. especially relevant with the 27mm pancake
+ 5. [X100f ø49](http://www.fujifilm.com/products/digital_cameras/x/fujifilm_x100f/) 1200-1600$ on kijiji, [1650$ lozeau](https://lozeau.com/produits/fr/fujifilm/fujifilm-x100f-argent-p30174/), nostalgia!
 
 Écarté:
 

another typo
diff --git a/blog/2018-06-27-report.mdwn b/blog/2018-06-27-report.mdwn
index 5a3749b4..cec260de 100644
--- a/blog/2018-06-27-report.mdwn
+++ b/blog/2018-06-27-report.mdwn
@@ -143,7 +143,7 @@ decent editor to work on Python notebooks and I have used this to work
 on the [[terminal emulators series|2018-04-12-terminal-emulators-1]]
 and the [related source code](https://github.com/anarcat/terms-benchmarks)
 
-I have also tried to complete my conversation to [Magit](https://magit.vc/), a pretty
+I have also tried to complete my conversion to [Magit](https://magit.vc/), a pretty
 nice wrapper around git for Emacs. Some of my usual git shortcuts have
 good replacements, but not all. For example, those are equivalent:
 

removed
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_11_18adab27e69c808f53ce28710d9d6221._comment b/blog/2018-06-26-collaborative-editors-history/comment_11_18adab27e69c808f53ce28710d9d6221._comment
deleted file mode 100644
index 0f2efe47..00000000
--- a/blog/2018-06-26-collaborative-editors-history/comment_11_18adab27e69c808f53ce28710d9d6221._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- ip="104.163.166.8"
- claimedauthor="Robin"
- url="http://robin.millette.info/"
- subject="One more thing"
- date="2018-06-28T21:35:33Z"
- content="""
-Another tool built on automerge and dat (hypercore):
-
-<https://inkandswitch.github.io/pushpin/>
-
-> A collaborative digital workspace designed to work offline and in real-time
-
-offline **and** in real-time - beat that ;-)
-
-"""]]

Added a comment: One more thing
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_11_18adab27e69c808f53ce28710d9d6221._comment b/blog/2018-06-26-collaborative-editors-history/comment_11_18adab27e69c808f53ce28710d9d6221._comment
new file mode 100644
index 00000000..0f2efe47
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_11_18adab27e69c808f53ce28710d9d6221._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ ip="104.163.166.8"
+ claimedauthor="Robin"
+ url="http://robin.millette.info/"
+ subject="One more thing"
+ date="2018-06-28T21:35:33Z"
+ content="""
+Another tool built on automerge and dat (hypercore):
+
+<https://inkandswitch.github.io/pushpin/>
+
+> A collaborative digital workspace designed to work offline and in real-time
+
+offline **and** in real-time - beat that ;-)
+
+"""]]

fix date
diff --git a/blog/2018-06-27-report.mdwn b/blog/2018-06-27-report.mdwn
index 8cdd1626..5a3749b4 100644
--- a/blog/2018-06-27-report.mdwn
+++ b/blog/2018-06-27-report.mdwn
@@ -1,4 +1,4 @@
-[[!meta title="My free software activities, June 2017"]]
+[[!meta title="My free software activities, June 2018"]]
 
 [[!toc levels=2]]
 

a few corrections, add WAVE
diff --git a/blog/2018-06-26-collaborative-editors-history.mdwn b/blog/2018-06-26-collaborative-editors-history.mdwn
index 46a2d668..76969203 100644
--- a/blog/2018-06-26-collaborative-editors-history.mdwn
+++ b/blog/2018-06-26-collaborative-editors-history.mdwn
@@ -21,15 +21,16 @@ notable feature or implementation detail.
 
 | Project          | Date       | Platform | Notes |
 | ---------------- | ---------- | -------- | ----- |
-| [SubEthaEdit](https://www.codingmonkeys.de/subethaedit/) | 2003-2015? | Mac-only | first collaborative, real-time, multi-cursor editor I could find. [reverse-engineering attempt in Emacs](https://www.emacswiki.org/emacs/SubEthaEmacs) |
-| [DocSynch](http://docsynch.sourceforge.net/) |  2004-2007 | ? | built on top of IRC (!) |
-| [Gobby](https://gobby.github.io/) | 2005-now | C, multi-platform | first open, solid and reliable implementation. still around! protocol ("[libinfinoted](http://infinote.0x539.de/libinfinity/API/libinfinity/)") notoriously hard to port to other editors (e.g. [Rudel](https://www.emacswiki.org/emacs/Rudel) failed to implement this in Emacs. 0.7 release in jan 2017 adds possible python bindings that might improve this. Interesting plugins: autosave to disk. |
+| [SubEthaEdit](https://www.codingmonkeys.de/subethaedit/) | 2003-2015? | Mac-only | first collaborative, real-time, multi-cursor editor I could find. An [reverse-engineering attempt in Emacs](https://www.emacswiki.org/emacs/SubEthaEmacs) failed to produce anything. |
+| [DocSynch](http://docsynch.sourceforge.net/) |  2004-2007 | ? | built on top of IRC! |
+| [Gobby](https://gobby.github.io/) | 2005-now | C, multi-platform | first open, solid and reliable implementation and still around! The protocol ("[libinfinoted](http://infinote.0x539.de/libinfinity/API/libinfinity/)") is notoriously hard to port to other editors (e.g. [Rudel](https://www.emacswiki.org/emacs/Rudel) failed to implement this in Emacs). 0.7 release in jan 2017 adds possible python bindings that might improve this. Interesting plugins: autosave to disk. |
 | [Ethercalc](https://ethercalc.net/) | 2005-now | Web, Javascript | First spreadsheet, along with [Google docs](https://en.wikipedia.org/wiki/Google_docs) |
-| [moonedit](https://web.archive.org/web/20060423192346/http://www.moonedit.com:80/) | 2005-2008? | ? | Original website died. Other user's cursors visible and emulated keystrokes noises. Calculator and music sequencer. |
+| [moonedit](https://web.archive.org/web/20060423192346/http://www.moonedit.com:80/) | 2005-2008? | ? | Original website died. Other user's cursors visible and emulated keystrokes noises. Included a calculator and music sequencer! |
 | [synchroedit](http://www.synchroedit.com/) | 2006-2007 | ? | First web app. |
-| [Inkscape](http://wiki.inkscape.org/wiki/index.php/WhiteBoard) | 2007-2011 | C++ | First graphics editor, used Jabber, now defunct |
+| [Inkscape](http://wiki.inkscape.org/wiki/index.php/WhiteBoard) | 2007-2011 | C++ | First graphics editor with collaborative features backed by the "whiteboard" plugin built on top of Jabber, now defunct. |
 | [Abiword](https://en.wikipedia.org/wiki/AbiWord) | 2008-now | C++ | First word processor |
-| [Etherpad](http://etherpad.org/) | 2008-now | Web | First solid webapp. Originally developped as a heavy Java app in 2008, acquired and opensourced by google in 2009, then rewritten in Node.js in 2011. Widely used. |
+| [Etherpad](http://etherpad.org/) | 2008-now | Web | First solid web app. Originally developped as a heavy Java app in 2008, acquired and opensourced by Google in 2009, then rewritten in Node.js in 2011. Widely used. |
+| [Wave](https://en.wikipedia.org/wiki/Apache_Wave) | 2009-2010 | Web, Java | Failed attempt at a grand protocol unification |
 | [CRDT](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) | 2011 | Specification | Standard for replicating a document's datastructure among different computers reliably.|
 | [Operational transform](http://operational-transformation.github.io/) | 2013 | Specification | Similar to CRDT, yet, well, different. |
 | [Floobits](https://floobits.com/) | 2013-now | ? | Commercial, but opensource plugins for different editors |
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_10_22b3309b9f1abbbe3022bf7f3a2f1d51._comment b/blog/2018-06-26-collaborative-editors-history/comment_10_22b3309b9f1abbbe3022bf7f3a2f1d51._comment
index b415d141..f7285d67 100644
--- a/blog/2018-06-26-collaborative-editors-history/comment_10_22b3309b9f1abbbe3022bf7f3a2f1d51._comment
+++ b/blog/2018-06-26-collaborative-editors-history/comment_10_22b3309b9f1abbbe3022bf7f3a2f1d51._comment
@@ -7,5 +7,7 @@ Thanks for all the feedback! I've updated the table to add Ethercalc, Inkscape (
 
 I've also fixed the "NextCloud" entry to be "LibreOffice Online" as, it's true, it's just one frontend. Plus it promotes it earlier in the history. Funny to notice that Abiword beat LibreOffice on that.. ;)
 
+I've also added Google Wave, even though it was fairly short lived, in retrospect.
+
 Thanks to the other suggestions, but the goal here is not to make an exhaustive inventory of all possible collaborative editors: there are *way* more than what's listed here. It seems that everyone thinks they can do better than whoever came before, so I tried to keep the list to project which brought something really new to the pool and/or that succeeded in a significant way. I also try to keep the list limited to free software project and open platforms, except when there is a really notable change.
 """]]

add ethercalc, inkscape, abiword and fix nextcloud/libreoffice
diff --git a/blog/2018-06-26-collaborative-editors-history.mdwn b/blog/2018-06-26-collaborative-editors-history.mdwn
index a6a08c88..46a2d668 100644
--- a/blog/2018-06-26-collaborative-editors-history.mdwn
+++ b/blog/2018-06-26-collaborative-editors-history.mdwn
@@ -24,17 +24,20 @@ notable feature or implementation detail.
 | [SubEthaEdit](https://www.codingmonkeys.de/subethaedit/) | 2003-2015? | Mac-only | first collaborative, real-time, multi-cursor editor I could find. [reverse-engineering attempt in Emacs](https://www.emacswiki.org/emacs/SubEthaEmacs) |
 | [DocSynch](http://docsynch.sourceforge.net/) |  2004-2007 | ? | built on top of IRC (!) |
 | [Gobby](https://gobby.github.io/) | 2005-now | C, multi-platform | first open, solid and reliable implementation. still around! protocol ("[libinfinoted](http://infinote.0x539.de/libinfinity/API/libinfinity/)") notoriously hard to port to other editors (e.g. [Rudel](https://www.emacswiki.org/emacs/Rudel) failed to implement this in Emacs. 0.7 release in jan 2017 adds possible python bindings that might improve this. Interesting plugins: autosave to disk. |
+| [Ethercalc](https://ethercalc.net/) | 2005-now | Web, Javascript | First spreadsheet, along with [Google docs](https://en.wikipedia.org/wiki/Google_docs) |
 | [moonedit](https://web.archive.org/web/20060423192346/http://www.moonedit.com:80/) | 2005-2008? | ? | Original website died. Other user's cursors visible and emulated keystrokes noises. Calculator and music sequencer. |
 | [synchroedit](http://www.synchroedit.com/) | 2006-2007 | ? | First web app. |
+| [Inkscape](http://wiki.inkscape.org/wiki/index.php/WhiteBoard) | 2007-2011 | C++ | First graphics editor, used Jabber, now defunct |
+| [Abiword](https://en.wikipedia.org/wiki/AbiWord) | 2008-now | C++ | First word processor |
 | [Etherpad](http://etherpad.org/) | 2008-now | Web | First solid webapp. Originally developped as a heavy Java app in 2008, acquired and opensourced by google in 2009, then rewritten in Node.js in 2011. Widely used. |
 | [CRDT](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) | 2011 | Specification | Standard for replicating a document's datastructure among different computers reliably.|
 | [Operational transform](http://operational-transformation.github.io/) | 2013 | Specification | Similar to CRDT, yet, well, different. |
 | [Floobits](https://floobits.com/) | 2013-now | ? | Commercial, but opensource plugins for different editors |
+| [LibreOffice Online](https://wiki.documentfoundation.org/Development/LibreOffice_Online) | 2015-now | Web | free Google docs equivalent, now integrated in [Nextcloud](https://nextcloud.com/collaboraonline/) |
 | [HackMD](https://hackmd.io/) | 2015-now | ? | Commercial but [opensource](https://github.com/hackmdio/hackmd). Inspired by hackpad, which was bought up by Dropbox. |
 | [Cryptpad](https://cryptpad.fr/) | 2016-now | web? | spin-off of xwiki. encrypted, "zero-knowledge" on server |
 | [Prosemirror](https://prosemirror.net/) | 2016-now | Web, Node.JS | "Tries to bridge the gap between Markdown text editing and classical WYSIWYG editors." Not really an editor, but something that can be used to build one. |
 | [Qill](https://quilljs.com/) | 2013-now | Web, Node.JS | Rich text editor, also javascript. Not sure it is really collaborative. |
-| [Nextcloud](https://nextcloud.com/collaboraonline/) | 2017-now | Web | Some sort of Google docs equivalent |
 | [Teletype](https://teletype.atom.io/) | 2017-now | WebRTC, Node.JS | For the GitHub's [Atom editor](https://atom.io), introduces "portal" idea that makes guests follow what the host is doing across multiple docs. p2p with webRTC after visit to introduction server, CRDT based. |
 | [Tandem](http://typeintandem.com/) | 2018-now | Node.JS? | Plugins for atom, vim, neovim, sublime... uses a relay to setup p2p connexions CRDT based. [Dubious license issues](https://github.com/typeintandem/tandem/issues/131) were resolved thanks to the involvement of Debian developers, which makes it a promising standard to follow in the future. |
 
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_10_22b3309b9f1abbbe3022bf7f3a2f1d51._comment b/blog/2018-06-26-collaborative-editors-history/comment_10_22b3309b9f1abbbe3022bf7f3a2f1d51._comment
new file mode 100644
index 00000000..b415d141
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_10_22b3309b9f1abbbe3022bf7f3a2f1d51._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""keep em coming"""
+ date="2018-06-28T20:45:08Z"
+ content="""
+Thanks for all the feedback! I've updated the table to add Ethercalc, Inkscape (how could I forget our poor Jabber friend!) and Abiword (that one still works??). 
+
+I've also fixed the "NextCloud" entry to be "LibreOffice Online" as, it's true, it's just one frontend. Plus it promotes it earlier in the history. Funny to notice that Abiword beat LibreOffice on that.. ;)
+
+Thanks to the other suggestions, but the goal here is not to make an exhaustive inventory of all possible collaborative editors: there are *way* more than what's listed here. It seems that everyone thinks they can do better than whoever came before, so I tried to keep the list to project which brought something really new to the pool and/or that succeeded in a significant way. I also try to keep the list limited to free software project and open platforms, except when there is a really notable change.
+"""]]

Added a comment: Inkscape Whiteboard
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_9_a5b03572f60f1cf194be6e71bc6d7317._comment b/blog/2018-06-26-collaborative-editors-history/comment_9_a5b03572f60f1cf194be6e71bc6d7317._comment
new file mode 100644
index 00000000..9afba8e2
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_9_a5b03572f60f1cf194be6e71bc6d7317._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="38.109.115.130"
+ claimedauthor="Daniel Kahn Gillmor"
+ url="https://dkg.fifthhorseman.net/blog/"
+ subject="Inkscape Whiteboard"
+ date="2018-06-28T20:29:49Z"
+ content="""
+This list is missing the late, lamented [Inkscape Whiteboard feature](http://wiki.inkscape.org/wiki/index.php/WhiteBoard) which was super cool (when it worked).  you could collaboratively edit an SVG document, not just plaintext.
+"""]]

Added a comment: automerge, dat
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_8_58af712463e8c564a6d61abb778880a2._comment b/blog/2018-06-26-collaborative-editors-history/comment_8_58af712463e8c564a6d61abb778880a2._comment
new file mode 100644
index 00000000..c3613098
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_8_58af712463e8c564a6d61abb778880a2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ ip="104.163.166.8"
+ claimedauthor="Robin"
+ url="http://robin.millette.info/"
+ subject="automerge, dat"
+ date="2018-06-28T18:58:25Z"
+ content="""
+Saw a demo a couple of months ago:
+
+* <https://github.com/automerge/pixelpusher>
+* <https://medium.com/@pvh/pixelpusher-real-time-peer-to-peer-collaboration-with-react-7c7bc8ecbf74>
+
+It's based on automerge, which is a JSON CDRT and dat, a modern updatable bittorrent.
+"""]]

fix style issue, thanks robin
diff --git a/blog/2018-06-27-report.mdwn b/blog/2018-06-27-report.mdwn
index de50220c..8cdd1626 100644
--- a/blog/2018-06-27-report.mdwn
+++ b/blog/2018-06-27-report.mdwn
@@ -76,7 +76,7 @@ LWN
 
 I wrote eigth articles in the last three months, for an average of
 three monthly articles. I was aiming at an average of one or two a
-week, so I didn't get to my objective. My [[last article about
+week, so I didn't get reach my goal. My [[last article about
 Kubecon|2018-05-26-kubecon-rant]] generated a lot of feedback,
 probably the best I have ever received. It seems I struck a chord for
 a lot of people, so that certainly feels nice.

fix url
diff --git a/blog/2018-06-27-report.mdwn b/blog/2018-06-27-report.mdwn
index 90548350..de50220c 100644
--- a/blog/2018-06-27-report.mdwn
+++ b/blog/2018-06-27-report.mdwn
@@ -114,7 +114,7 @@ the `sendmail` command: its behavior can vary a lot between platforms
 reduce the attack surface. It works with another program I wrote
 called `sshsendmail` which connects to it over a pipe. It integrates
 well into "dumb" MTAs like [nullmailer](https://packages.debian.org/sid/nullmailer) but I also use it with the
-popular [Postfix](https://postfix.org/) as well, without problems.
+popular [Postfix](http://www.postfix.org/) as well, without problems.
 
 The second is to switch from [OfflineIMAP](https://www.offlineimap.org/) to [Syncmaildir](https://github.com/gares/syncmaildir)
 (SMD). The latter allows synchronization over SSH only. The

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

finalize report
diff --git a/blog/2018-06-27-report.mdwn b/blog/2018-06-27-report.mdwn
index bbc94a46..90548350 100644
--- a/blog/2018-06-27-report.mdwn
+++ b/blog/2018-06-27-report.mdwn
@@ -36,13 +36,12 @@ ended up being postponed to LTS.
 Most of my work this month was spent actually working on porting the
 Mercurial fixes from wheezy to jessie. Technically, the patches were
 ported from upstream 4.3 and led to some pretty interesting results in
-the test suite, as usual, but I ended up prevailing over that package
-and published a DLA for 3 issues ([[!debcve CVE-2018-1000132]],
-[[!debcve CVE-2017-9462]], [[!debcve CVE-2017-17458]]). Three more
-issues have been disclosed since I started working on the package but
-they do not have a CVE assigned yet and I felt it was better to bundle
-this already large change into one upload already since I have ran out
-of hours for the month.
+the test suite, which fails to build from source
+non-reproducibly. Because I couldn't figure out how to fix this in the
+alloted time, I [uploaded the package](https://lists.debian.org/878t6yhk4x.fsf@curie.anarc.at) to my usual test location in
+the hope someone else picks it up. The test package fixes 6 issues
+([[!debcve CVE-2018-1000132]], [[!debcve CVE-2017-9462]], [[!debcve
+CVE-2017-17458]] and [three issues without a CVE](https://bugs.debian.org/901050)).
 
 I also worked on cups in a similar way, sending a test package to the
 security team for 2 issues ([[!debcve CVE-2017-18190]], [[!debcve
@@ -144,46 +143,117 @@ decent editor to work on Python notebooks and I have used this to work
 on the [[terminal emulators series|2018-04-12-terminal-emulators-1]]
 and the [related source code](https://github.com/anarcat/terms-benchmarks)
 
-I have also tried to finish my conversation to [Magit](https://magit.vc/)
-
-etc
-
-https://github.com/jwiegley/git-annex-el/blob/master/git-annex.el
+I have also tried to complete my conversation to [Magit](https://magit.vc/), a pretty
+nice wrapper around git for Emacs. Some of my usual git shortcuts have
+good replacements, but not all. For example, those are equivalent:
+
+ * `vc-annotate` (<kbd>C-x C-v g</kbd>): `magit-blame`
+ * `vc-diff` (<kbd>C-x C-v =</kbd>): `magit-diff-buffer-file`
+
+Those do not have a direct equivalent:
+
+ * `vc-next-action` (<kbd>C-x C-q</kbd>, or <kbd>F6</kbd>): `anarcat/magic-commit-buffer`, see below
+ * `vc-git-grep` (<kbd>F8</kbd>): no replacement
+
+I wrote my own replacement for "diff and commit this file" as the
+following function:
+
+    (defun anarcat/magit-commit-buffer ()
+      "commit the changes in the current buffer on the fly
+
+    This is different than `magit-commit' because it calls `git
+    commit' without going through the staging area AKA index
+    first. This is a replacement for `vc-next-action'.
+
+    Tip: setting the git configuration parameter `commit.verbose' to
+    2 will show the diff in the changelog buffer for review. See
+    `git-config(1)' for more information.
+
+    An alternative implementation was attempted with `magit-commit':
+
+      (let ((magit-commit-ask-to-stage nil))
+        (magit-commit (list \"commit\" \"--\"
+                            (file-relative-name buffer-file-name)))))
+
+    But it seems `magit-commit' asserts that we want to stage content
+    and will fail with: `(user-error \"Nothing staged\")'. This is
+    why this function calls `magit-run-git-with-editor' directly
+    instead."
+      (interactive)
+      (magit-run-git-with-editor (list "commit" "--" (file-relative-name buffer-file-name))))
+
+It's not very pretty, but it works... Mostly. Sometimes the
+`magit-diff` buffer becomes out of sync, but the `--verbose` output in
+the commitlog buffer still works.
+
+I've also looked at git-annex integration. The [magit-annex](https://github.com/magit/magit-annex)
+package did not work well for me: the file listing is [really too
+slow](https://github.com/magit/magit-annex/issues/20). So I found the [git-annex.el](https://github.com/jwiegley/git-annex-el/blob/master/git-annex.el) package, but did not try it
+out yet.
+
+While working on all of this, I fell in a different rabbit hole: I
+found it inconvenient to "pastebin" stuff from Emacs, as it would
+involve selection a region, piping to `pastebinit` and copy-pasting
+the URL found in the `*Messages*` buffer. So I wrote this first
+prototype:
+
+    (defun pastebinit (begin end)
+      "pass the region to pastebinit and add output to killring
+
+    TODO: prompt for possible pastebins (pastebinit -l) with prefix arg
+
+    Note that there's a `nopaste.el' project which already does this,
+    which we should use instead.
+    "
+      (interactive "r")
+      (message "use nopaste.el instead")
+      (let ((proc (make-process :filter #'pastebinit--handle
+                                :command '("pastebinit")
+                                :connection-type 'pipe
+                                :buffer nil
+                                :name "pastebinit")))
+        (process-send-region proc begin end)
+        (process-send-eof proc)))
+
+    (defun pastebinit--handle (proc string)
+      "handle output from pastebinit asynchronously"
+      (let ((url (car (split-string string))))
+        (kill-new url)
+        (message "paste uploaded and URL added to kill ring: %s" url)))
+
+It was my first foray into aynchronous process operations in Emacs:
+difficult and confusing, but it mostly worked. Those who know me know
+what's coming next, however: I found not only one, but *two* libraries
+for pastebins in Emacs: [nopaste](https://github.com/avar/nopaste) and (after patching nopaste to
+add [asynchronous support](https://github.com/avar/nopaste/pull/1) and [customize support](https://github.com/avar/nopaste/pull/2) of course)
+[debpaste.el](https://github.com/alezost/debpaste.el). I'm not sure where that will go: there is a proposal
+to [add nopaste in Debian](https://bugs.debian.org/580259) that was discussed a while back and I
+made a detailed report there.
 
 Monkeysign
 ----------
 
-Archives
---------
-
-rec, etc...
-
-Backups
--------
-
-git-annex appendonly, etc
+I made a [minor release](https://lists.riseup.net/www/arc/monkeysphere/2018-06/msg00003.html) of Monkeysign to cover for [[!debcve CVE-2018-12020]]
+and its [GPG sigspoof](https://neopg.io/blog/gpg-signature-spoof/) vulnerability. I am not sure where to take
+this project anymore, and I [opened a discussion](https://lists.riseup.net/www/arc/monkeysphere/2018-06/msg00004.html) to possibly
+retire the project completely. Feedback welcome.
 
 ikiwiki
 -------
 
-bootstrap plugin, etc?
+I wrote a new ikiwiki plugin called [bootstrap](https://ikiwiki.info/plugins/contrib/bootstrap/) to fix table markup
+to match what the Bootstrap theme expects. This was particularly
+important for the [[previous blog
+post|2018-06-26-collaborative-editors-history]] which uses tables a
+lot. This was surprisingly easy and might be useful to tweak other
+stuff in the theme.
 
 Random stuff
 ------------
 
+ * I wrote up a review of security of APT packages when compared with
+   the TUF project, in [TufDerivedImprovements](https://wiki.debian.org/SecureApt/TufDerivedImprovements)
  * contributed to about 20 different repositories on GitHub, too
    numerous to list here
- * undertime?
- * vgo, go vet -shadow
- * review emails?
-brightness wtf.
-
-https://github.com/ddccontrol/ddccontrol/issues/24
-https://github.com/ddccontrol/ddccontrol-db/issues/43
-https://github.com/ddccontrol/ddccontrol-db/issues/57
-
-
-#820842 - gitpkg reproducible
-
 
-[[!tag debian-planet debian debian-lts python-planet software geek free]]
+[[!tag debian-planet debian debian-lts python-planet software geek free monkeysign ikiwiki emacs rsendmail linkchecker]]

Added a comment
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_7_5baf93f4825a8037c6d6668a742f54ec._comment b/blog/2018-06-26-collaborative-editors-history/comment_7_5baf93f4825a8037c6d6668a742f54ec._comment
new file mode 100644
index 00000000..0110a92d
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_7_5baf93f4825a8037c6d6668a742f54ec._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ ip="90.146.184.46"
+ subject="comment 7"
+ date="2018-06-28T07:04:50Z"
+ content="""
+AbiWord has supported collaborative editing since version 2.6 released in 2008.
+"""]]

preliminary report
diff --git a/blog/2018-06-27-report.mdwn b/blog/2018-06-27-report.mdwn
new file mode 100644
index 00000000..bbc94a46
--- /dev/null
+++ b/blog/2018-06-27-report.mdwn
@@ -0,0 +1,189 @@
+[[!meta title="My free software activities, June 2017"]]
+
+[[!toc levels=2]]
+
+It's been a while since I haven't done a report here! Since I need to
+do one for LTS, I figured I would also catchup you up with the work
+I've done in the last three months. Maybe I'll make that my new
+process: quarterly reports would reduce the overhead on my side with
+little loss on you, my precious (few? many?) readers.
+
+Debian Long Term Support (LTS)
+==============================
+
+This is my monthly [Debian LTS][] report. 
+
+[Debian LTS]: https://www.freexian.com/services/debian-lts.html
+
+I omitted doing a report in May because I didn't spend a significant
+number of hours, so this also covers a handful of hours of work in May.
+
+May and June were strange months to work on LTS, as we made the
+transition between wheezy and jessie. I worked on all three LTS
+releases now, and I must have been absent from the last transition
+because I felt this one was a little confusing to go through. Maybe
+it's because I was on frontdesk duty during that time...
+
+For a week or two it was unclear if we should have worked on wheezy,
+jessie, or both, or even how to work on either. I [documented which
+packages needed an update from wheezy to jessie](https://lists.debian.org/874lig7y6f.fsf@angela.anarc.at) and proposed a
+process for the transition period. This generated a good discussion,
+but I am not sure we resolved the problems we had this time around in
+the long term. I also sent patches to the security team in the hope
+they would land in jessie before it turns into LTS, but most of those
+ended up being postponed to LTS.
+
+Most of my work this month was spent actually working on porting the
+Mercurial fixes from wheezy to jessie. Technically, the patches were
+ported from upstream 4.3 and led to some pretty interesting results in
+the test suite, as usual, but I ended up prevailing over that package
+and published a DLA for 3 issues ([[!debcve CVE-2018-1000132]],
+[[!debcve CVE-2017-9462]], [[!debcve CVE-2017-17458]]). Three more
+issues have been disclosed since I started working on the package but
+they do not have a CVE assigned yet and I felt it was better to bundle
+this already large change into one upload already since I have ran out
+of hours for the month.
+
+I also worked on cups in a similar way, sending a test package to the
+security team for 2 issues ([[!debcve CVE-2017-18190]], [[!debcve
+CVE-2017-18248]]). Same for Dokuwiki, where I [sent a patch](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889281#16) single
+issue ([[!debcve CVE-2017-18123]]). Those have yet to be published,
+however, and I will hopefully wrap that up in July.
+
+Because I was looking for work, I ended up doing meta-work as well. I
+made a [prototype](https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/4) that would use the `embedded-code-copies` file
+to populate `data/CVE/list` with related packages as a way to address
+a problem we have in LTS triage, where package that were renamed
+between suites do not get correctly added to the tracker. It ended up
+being rejected because the changes were too invasive, but led to
+Brian May suggesting [another approach](https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/8), we'll see where that goes.
+
+I've also looked at splitting up that dreaded `data/CVE/list` but my
+[results](https://salsa.debian.org/security-tracker-team/security-tracker/issues/2) were negative: it looks like git is very efficient at
+splitting things up. While a split up list might be easier on editors,
+it would be a massive change and was eventually refused by the
+security team.
+
+Other free software work
+========================
+
+With my [[last
+report|2018-03-01-free-software-activities-february-2018]] dating back
+to February, this will naturally be a little imprecise, as three
+months have passed. But let's see...
+
+LWN
+---
+
+I wrote eigth articles in the last three months, for an average of
+three monthly articles. I was aiming at an average of one or two a
+week, so I didn't get to my objective. My [[last article about
+Kubecon|2018-05-26-kubecon-rant]] generated a lot of feedback,
+probably the best I have ever received. It seems I struck a chord for
+a lot of people, so that certainly feels nice.
+
+Linkchecker
+-----------
+
+Usual maintenance work, but we at last finally got access to the
+Linkchecker organization on GitHub, which meant a bit of
+reorganizing. The only bit missing now it the PyPI namespace, but that
+should also come soon. The code of conduct and contribution guides
+were finally merged after we clarified project membership. This gives
+us issue templates which should help us deal with the constant flow of
+issues that come in every day.
+
+The biggest concern I have with the project now is the C parser and
+the outdated Windows executable. The latter has been removed from the
+website so hopefully Windows users won't report old bugs (although
+that means we won't gain new Windows users at all) and the former
+might be fixed by a port to BeautifulSoup.
+
+Email over SSH
+--------------
+
+I did a lot of work to switch away from SMTP and IMAP to synchronise
+my workstation and laptops with my mailserver. Having the privilege of
+running my own server has its perks: I have SSH access to my mail
+spool, which brings the opportunity for interesting optimizations.
+
+The first I have done is called [rsendmail](https://gitlab.com/anarcat/rsendmail). Inspired by work from
+Don Armstrong and David Bremner, rsendmail is a Python program I wrote
+from scratch to deliver email over a pipe, securely. I do not trust
+the `sendmail` command: its behavior can vary a lot between platforms
+(e.g. allow flushing the mailqueue or printing it) and I wanted to
+reduce the attack surface. It works with another program I wrote
+called `sshsendmail` which connects to it over a pipe. It integrates
+well into "dumb" MTAs like [nullmailer](https://packages.debian.org/sid/nullmailer) but I also use it with the
+popular [Postfix](https://postfix.org/) as well, without problems.
+
+The second is to switch from [OfflineIMAP](https://www.offlineimap.org/) to [Syncmaildir](https://github.com/gares/syncmaildir)
+(SMD). The latter allows synchronization over SSH only. The
+[[migration|services/mail/syncmaildir]] was a little difficult but I
+very much like the results: SMD is faster than OfflineIMAP and works
+transparently in the background.
+
+I really like to use SSH for email. I used to have my email password
+stored all over the place: in my Postfix config, in my email clients'
+memory, it was a mess. With the new configuration, things just work
+unattended and email feels like a solved problem, at least the
+synchronization aspects of it.
+
+Emacs
+-----
+
+As often happens, I've done some work on my Emacs configuration. I
+switched to a new Solarized theme, the [bbatsov version](https://github.com/bbatsov/solarized-emacs/) which has
+support for a light and dark mode and generally better colors. I had
+[problems with the cursor](https://github.com/bbatsov/solarized-emacs/issues/290) which are unfortunately unfixed.
+
+I learned about and used the [Emacs iPython Notebook](https://github.com/tkf/emacs-ipython-notebook/) project (EIN)
+and filed a [feature request](https://github.com/tkf/emacs-ipython-notebook/issues/199) to replicate the "restart and run"
+behavior of the web interface. Otherwise it's real nice to have a
+decent editor to work on Python notebooks and I have used this to work
+on the [[terminal emulators series|2018-04-12-terminal-emulators-1]]
+and the [related source code](https://github.com/anarcat/terms-benchmarks)
+
+I have also tried to finish my conversation to [Magit](https://magit.vc/)
+
+etc
+
+https://github.com/jwiegley/git-annex-el/blob/master/git-annex.el
+
+Monkeysign
+----------
+
+Archives
+--------
+
+rec, etc...
+
+Backups
+-------
+
+git-annex appendonly, etc
+
+ikiwiki
+-------
+
+bootstrap plugin, etc?
+
+Random stuff
+------------
+
+ * contributed to about 20 different repositories on GitHub, too
+   numerous to list here
+ * undertime?
+ * vgo, go vet -shadow
+ * review emails?
+brightness wtf.
+
+https://github.com/ddccontrol/ddccontrol/issues/24
+https://github.com/ddccontrol/ddccontrol-db/issues/43
+https://github.com/ddccontrol/ddccontrol-db/issues/57
+
+
+#820842 - gitpkg reproducible
+
+
+[[!tag debian-planet debian debian-lts python-planet software geek free]]

Added a comment
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_6_1ea899e7a36a0a95018bfae89f2e8705._comment b/blog/2018-06-26-collaborative-editors-history/comment_6_1ea899e7a36a0a95018bfae89f2e8705._comment
new file mode 100644
index 00000000..e47b222a
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_6_1ea899e7a36a0a95018bfae89f2e8705._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="195.168.117.202"
+ claimedauthor="Andrej Shadura"
+ url="https://shadura.me"
+ subject="comment 6"
+ date="2018-06-27T16:34:15Z"
+ content="""
+Oh, I didn’t notice the link actually is to Collabora Online, which is a ‘branded’ version of LibreOffice Online. I think the entry should say LibreOffice Online or Collabora Online, not NextCloud, since it’s not something NextCloud itself provides, but an external piece of software.
+"""]]

Added a comment
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_5_e6f750e259d70b98421df8eecaca4895._comment b/blog/2018-06-26-collaborative-editors-history/comment_5_e6f750e259d70b98421df8eecaca4895._comment
new file mode 100644
index 00000000..adc6cbf1
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_5_e6f750e259d70b98421df8eecaca4895._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="195.168.117.202"
+ claimedauthor="Andrej Shadura"
+ url="https://shadura.me/"
+ subject="comment 5"
+ date="2018-06-27T16:29:37Z"
+ content="""
+I’m not sure what editor is there in NextCloud, but LibreOffice Online is a multi-user editor and Google Docs alternative, so you may want to add or correct that entry.
+"""]]

Added a comment: Not Google Docs
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_4_c3e23d5c97a63f575cb1a05a29bbcc43._comment b/blog/2018-06-26-collaborative-editors-history/comment_4_c3e23d5c97a63f575cb1a05a29bbcc43._comment
new file mode 100644
index 00000000..e8367575
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_4_c3e23d5c97a63f575cb1a05a29bbcc43._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="https://seccdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="Not Google Docs"
+ date="2018-06-27T10:56:36Z"
+ content="""
+Yeah no, I am not. I refer to it in the NextCloud section, but I generally tried to avoid proprietary software in there. If anything, I missed [EtherCalc](https://ethercalc.net/), created in 2005 basically at the time a similar product was acquired (not created!) by Google. So no cookie for them.
+"""]]

Added a comment: Google Docs
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_3_d83c8c8dadfbb9c66e1db30faa053556._comment b/blog/2018-06-26-collaborative-editors-history/comment_3_d83c8c8dadfbb9c66e1db30faa053556._comment
new file mode 100644
index 00000000..f5288fc8
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_3_d83c8c8dadfbb9c66e1db30faa053556._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="81.128.178.178"
+ claimedauthor="Jonathan"
+ url="jmtd.net"
+ subject="Google Docs"
+ date="2018-06-27T10:23:43Z"
+ content="""
+You're missing Google Docs, at least the word processor and spreadsheet programs support multi-edit.
+"""]]

Added a comment: Couple more milestones
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_2_80ea6206009449c4fae1c2e981b61b43._comment b/blog/2018-06-26-collaborative-editors-history/comment_2_80ea6206009449c4fae1c2e981b61b43._comment
new file mode 100644
index 00000000..2aaccd26
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_2_80ea6206009449c4fae1c2e981b61b43._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ ip="104.163.166.8"
+ claimedauthor="Robin"
+ url="http://robin.millette.info/"
+ subject="Couple more milestones"
+ date="2018-06-26T23:38:42Z"
+ content="""
+The TogetherJS library by Mozilla was promising... 5 years ago: <https://github.com/mozilla/togetherjs>
+
+Also worth a mention, good old Google Wave from 2009. It had it all (too much?)
+
+I don't get why Collaborative Editing isn't a standard wiki feature by now.
+
+"""]]

a new ikiwiki plugin
diff --git a/services/wiki.mdwn b/services/wiki.mdwn
index eadf7ff3..f499e8c9 100644
--- a/services/wiki.mdwn
+++ b/services/wiki.mdwn
@@ -134,6 +134,7 @@ There are two patches left:
  * [[!iki bugs/footnotes-look-weird]]
  * [[!iki todo/git-annex_support]]
  * [[!iki todo/admonitions]]
+ * [[!iki plugins/contrib/bootstrap]]
 
 I dropped the [[!iki bugs/notifyemail fails with some openid providers]] patch because of the impeding doom of OpenID.
 
@@ -150,6 +151,9 @@ To apply this patch:
     git rebase $release i18n-headinganchors
     git diff $release..i18n-headinganchors | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run )
     git diff $release..i18n-headinganchors | ( cd /usr/share/perl5 ; sudo patch -p1  )
+    git rebase $release bootstrap
+    git diff $release..bootstrap | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run )
+    git diff $release..bootstrap | ( cd /usr/share/perl5 ; sudo patch -p1  )
     # not sure about that rebase
     git rebase $release admonitions
     git diff $release..admonitions IkiWiki/Plugin/admonition.pm | ( cd /usr/share/perl5 ; sudo patch -p1 --dry-run )

Added a comment: few other links
diff --git a/blog/2018-06-26-collaborative-editors-history/comment_1_2e47379dc2f80a4d6bc97c80f95631f4._comment b/blog/2018-06-26-collaborative-editors-history/comment_1_2e47379dc2f80a4d6bc97c80f95631f4._comment
new file mode 100644
index 00000000..e3cda3aa
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history/comment_1_2e47379dc2f80a4d6bc97c80f95631f4._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ ip="88.162.73.247"
+ claimedauthor="Vincent"
+ subject="few other links"
+ date="2018-06-26T21:21:07Z"
+ content="""
+Hello,
+
+Thanks for your interesting post!
+
+I recently did a similar search, I retained the following:
+
+  - as a KDE guy I could ignore [this](http://blog.svenbrauch.de/2013/08/17/gsoc-collaborative-text-editing-in-kate/)
+  - a [WebRTC candidate](https://hackernoon.com/building-conclave-a-decentralized-real-time-collaborative-text-editor-a6ab438fe79f)
+  - another [links page](https://we.riseup.net/cgdev/collaborative-editor)
+
+Cheers!
+"""]]

revert back to markdown
i enabled a plugin to add the proper bootstrap class to the rendered tables
diff --git a/blog/2018-06-26-collaborative-editors-history.mdwn b/blog/2018-06-26-collaborative-editors-history.mdwn
index d4e6977b..a6a08c88 100644
--- a/blog/2018-06-26-collaborative-editors-history.mdwn
+++ b/blog/2018-06-26-collaborative-editors-history.mdwn
@@ -19,114 +19,24 @@ So without further ado, here is the list of notable collaborative
 editors that I could find. By "notable" i mean that they introduce a
 notable feature or implementation detail.
 
-<table class="table">
-<thead>
-<tr>
-	<th>Project</th>
-	<th>Date</th>
-	<th>Platform</th>
-	<th>Notes</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-	<td><a href="https://www.codingmonkeys.de/subethaedit/">SubEthaEdit</a></td>
-	<td>2003-2015?</td>
-	<td>Mac-only</td>
-	<td>first collaborative, real-time, multi-cursor editor I could find. <a href="https://www.emacswiki.org/emacs/SubEthaEmacs">reverse-engineering attempt in Emacs</a></td>
-</tr>
-<tr>
-	<td><a href="http://docsynch.sourceforge.net/">DocSynch</a></td>
-	<td>2004-2007</td>
-	<td>?</td>
-	<td>built on top of IRC <img src="../../smileys/idea.png" alt="(!)"></td>
-</tr>
-<tr>
-	<td><a href="https://gobby.github.io/">Gobby</a></td>
-	<td>2005-now</td>
-	<td>C, multi-platform</td>
-	<td>first open, solid and reliable implementation. still around! protocol ("<a href="http://infinote.0x539.de/libinfinity/API/libinfinity/">libinfinoted</a>") notoriously hard to port to other editors (e.g. <a href="https://www.emacswiki.org/emacs/Rudel">Rudel</a> failed to implement this in Emacs. 0.7 release in jan 2017 adds possible python bindings that might improve this. Interesting plugins: autosave to disk.</td>
-</tr>
-<tr>
-	<td><a href="https://web.archive.org/web/20060423192346/http://www.moonedit.com:80/">moonedit</a></td>
-	<td>2005-2008?</td>
-	<td>?</td>
-	<td>Original website died. Other user's cursors visible and emulated keystrokes noises. Calculator and music sequencer.</td>
-</tr>
-<tr>
-	<td><a href="http://www.synchroedit.com/">synchroedit</a></td>
-	<td>2006-2007</td>
-	<td>?</td>
-	<td>First web app.</td>
-</tr>
-<tr>
-	<td><a href="http://etherpad.org/">Etherpad</a></td>
-	<td>2008-now</td>
-	<td>Web</td>
-	<td>First solid webapp. Originally developped as a heavy Java app in 2008, acquired and opensourced by google in 2009, then rewritten in Node.js in 2011. Widely used.</td>
-</tr>
-<tr>
-	<td><a href="https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type">CRDT</a></td>
-	<td>2011</td>
-	<td>Specification</td>
-	<td>Standard for replicating a document's datastructure among different computers reliably.</td>
-</tr>
-<tr>
-	<td><a href="http://operational-transformation.github.io/">Operational transform</a></td>
-	<td>2013</td>
-	<td>Specification</td>
-	<td>Similar to CRDT, yet, well, different.</td>
-</tr>
-<tr>
-	<td><a href="https://floobits.com/">Floobits</a></td>
-	<td>2013-now</td>
-	<td>?</td>
-	<td>Commercial, but opensource plugins for different editors</td>
-</tr>
-<tr>
-	<td><a href="https://hackmd.io/">HackMD</a></td>
-	<td>2015-now</td>
-	<td>?</td>
-	<td>Commercial but <a href="https://github.com/hackmdio/hackmd">opensource</a>. Inspired by hackpad, which was bought up by Dropbox.</td>
-</tr>
-<tr>
-	<td><a href="https://cryptpad.fr/">Cryptpad</a></td>
-	<td>2016-now</td>
-	<td>web?</td>
-	<td>spin-off of xwiki. encrypted, "zero-knowledge" on server</td>
-</tr>
-<tr>
-	<td><a href="https://prosemirror.net/">Prosemirror</a></td>
-	<td>2016-now</td>
-	<td>Web, Node.JS</td>
-	<td>"Tries to bridge the gap between Markdown text editing and classical WYSIWYG editors." Not really an editor, but something that can be used to build one.</td>
-</tr>
-<tr>
-	<td><a href="https://quilljs.com/">Qill</a></td>
-	<td>2013-now</td>
-	<td>Web, Node.JS</td>
-	<td>Rich text editor, also javascript. Not sure it is really collaborative.</td>
-</tr>
-<tr>
-	<td><a href="https://nextcloud.com/collaboraonline/">Nextcloud</a></td>
-	<td>2017-now</td>
-	<td>Web</td>
-	<td>Some sort of Google docs equivalent</td>
-</tr>
-<tr>
-	<td><a href="https://teletype.atom.io/">Teletype</a></td>
-	<td>2017-now</td>
-	<td>WebRTC, Node.JS</td>
-	<td>For the GitHub's <a href="https://atom.io">Atom editor</a>, introduces "portal" idea that makes guests follow what the host is doing across multiple docs. p2p with webRTC after visit to introduction server, CRDT based.</td>
-</tr>
-<tr>
-	<td><a href="http://typeintandem.com/">Tandem</a></td>
-	<td>2018-now</td>
-	<td>Node.JS?</td>
-	<td>Plugins for atom, vim, neovim, sublime... uses a relay to setup p2p connexions CRDT based. <a href="https://github.com/typeintandem/tandem/issues/131">Dubious license issues</a> were resolved thanks to the involvement of Debian developers, which makes it a promising standard to follow in the future.</td>
-</tr>
-</tbody>
-</table>
+| Project          | Date       | Platform | Notes |
+| ---------------- | ---------- | -------- | ----- |
+| [SubEthaEdit](https://www.codingmonkeys.de/subethaedit/) | 2003-2015? | Mac-only | first collaborative, real-time, multi-cursor editor I could find. [reverse-engineering attempt in Emacs](https://www.emacswiki.org/emacs/SubEthaEmacs) |
+| [DocSynch](http://docsynch.sourceforge.net/) |  2004-2007 | ? | built on top of IRC (!) |
+| [Gobby](https://gobby.github.io/) | 2005-now | C, multi-platform | first open, solid and reliable implementation. still around! protocol ("[libinfinoted](http://infinote.0x539.de/libinfinity/API/libinfinity/)") notoriously hard to port to other editors (e.g. [Rudel](https://www.emacswiki.org/emacs/Rudel) failed to implement this in Emacs. 0.7 release in jan 2017 adds possible python bindings that might improve this. Interesting plugins: autosave to disk. |
+| [moonedit](https://web.archive.org/web/20060423192346/http://www.moonedit.com:80/) | 2005-2008? | ? | Original website died. Other user's cursors visible and emulated keystrokes noises. Calculator and music sequencer. |
+| [synchroedit](http://www.synchroedit.com/) | 2006-2007 | ? | First web app. |
+| [Etherpad](http://etherpad.org/) | 2008-now | Web | First solid webapp. Originally developped as a heavy Java app in 2008, acquired and opensourced by google in 2009, then rewritten in Node.js in 2011. Widely used. |
+| [CRDT](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) | 2011 | Specification | Standard for replicating a document's datastructure among different computers reliably.|
+| [Operational transform](http://operational-transformation.github.io/) | 2013 | Specification | Similar to CRDT, yet, well, different. |
+| [Floobits](https://floobits.com/) | 2013-now | ? | Commercial, but opensource plugins for different editors |
+| [HackMD](https://hackmd.io/) | 2015-now | ? | Commercial but [opensource](https://github.com/hackmdio/hackmd). Inspired by hackpad, which was bought up by Dropbox. |
+| [Cryptpad](https://cryptpad.fr/) | 2016-now | web? | spin-off of xwiki. encrypted, "zero-knowledge" on server |
+| [Prosemirror](https://prosemirror.net/) | 2016-now | Web, Node.JS | "Tries to bridge the gap between Markdown text editing and classical WYSIWYG editors." Not really an editor, but something that can be used to build one. |
+| [Qill](https://quilljs.com/) | 2013-now | Web, Node.JS | Rich text editor, also javascript. Not sure it is really collaborative. |
+| [Nextcloud](https://nextcloud.com/collaboraonline/) | 2017-now | Web | Some sort of Google docs equivalent |
+| [Teletype](https://teletype.atom.io/) | 2017-now | WebRTC, Node.JS | For the GitHub's [Atom editor](https://atom.io), introduces "portal" idea that makes guests follow what the host is doing across multiple docs. p2p with webRTC after visit to introduction server, CRDT based. |
+| [Tandem](http://typeintandem.com/) | 2018-now | Node.JS? | Plugins for atom, vim, neovim, sublime... uses a relay to setup p2p connexions CRDT based. [Dubious license issues](https://github.com/typeintandem/tandem/issues/131) were resolved thanks to the involvement of Debian developers, which makes it a promising standard to follow in the future. |
 
 Other lists
 ===========

remove code sandbox, not really notable
diff --git a/blog/2018-06-26-collaborative-editors-history.mdwn b/blog/2018-06-26-collaborative-editors-history.mdwn
index 4ac23e92..d4e6977b 100644
--- a/blog/2018-06-26-collaborative-editors-history.mdwn
+++ b/blog/2018-06-26-collaborative-editors-history.mdwn
@@ -125,12 +125,6 @@ notable feature or implementation detail.
 	<td>Node.JS?</td>
 	<td>Plugins for atom, vim, neovim, sublime... uses a relay to setup p2p connexions CRDT based. <a href="https://github.com/typeintandem/tandem/issues/131">Dubious license issues</a> were resolved thanks to the involvement of Debian developers, which makes it a promising standard to follow in the future.</td>
 </tr>
-<tr>
-	<td><a href="https://codesandbox.io/">Code sandbox</a></td>
-	<td>2018-now</td>
-	<td>Node.JS?</td>
-	<td>Originally just a web-based text editor, <a href="https://hackernoon.com/introducing-codesandbox-live-real-time-code-collaboration-in-the-browser-6d508cfc70c9?gi=b1f154f8e8f8">introduced collaborative editing in 2018</a></td>
-</tr>
 </tbody>
 </table>
 

remove useless toc and colgroup
diff --git a/blog/2018-06-26-collaborative-editors-history.mdwn b/blog/2018-06-26-collaborative-editors-history.mdwn
index 9db7aca4..4ac23e92 100644
--- a/blog/2018-06-26-collaborative-editors-history.mdwn
+++ b/blog/2018-06-26-collaborative-editors-history.mdwn
@@ -3,8 +3,6 @@
 A quick inventory of major collaborative editor efforts, in
 chronological order.
 
-[[!toc]]
-
 As with any such list, it must start with an honorable mention to [the
 mother of all demos](https://en.wikipedia.org/wiki/The_Mother_of_All_Demos) during which [Doug Engelbart](https://en.wikipedia.org/wiki/Douglas_Engelbart) presented
 what is basically an exhaustive list of all possible software written
@@ -22,11 +20,7 @@ editors that I could find. By "notable" i mean that they introduce a
 notable feature or implementation detail.
 
 <table class="table">
-<colgroup><col>
-<col>
-<col>
-<col>
-</colgroup><thead>
+<thead>
 <tr>
 	<th>Project</th>
 	<th>Date</th>

fix style issues by adding the table class
This was done by rendering the table and then just adding a
`class="table"` to the table, something that Ikiwiki does not do on
its own but that bootstrap expects.
diff --git a/blog/2018-06-26-collaborative-editors-history.mdwn b/blog/2018-06-26-collaborative-editors-history.mdwn
index d9e54eb5..9db7aca4 100644
--- a/blog/2018-06-26-collaborative-editors-history.mdwn
+++ b/blog/2018-06-26-collaborative-editors-history.mdwn
@@ -21,25 +21,124 @@ So without further ado, here is the list of notable collaborative
 editors that I could find. By "notable" i mean that they introduce a
 notable feature or implementation detail.
 
-| Project          | Date       | Platform | Notes |
-| ---------------- | ---------- | -------- | ----- |
-| [SubEthaEdit](https://www.codingmonkeys.de/subethaedit/) | 2003-2015? | Mac-only | first collaborative, real-time, multi-cursor editor I could find. [reverse-engineering attempt in Emacs](https://www.emacswiki.org/emacs/SubEthaEmacs) |
-| [DocSynch](http://docsynch.sourceforge.net/) |  2004-2007 | ? | built on top of IRC (!) |
-| [Gobby](https://gobby.github.io/) | 2005-now | C, multi-platform | first open, solid and reliable implementation. still around! protocol ("[libinfinoted](http://infinote.0x539.de/libinfinity/API/libinfinity/)") notoriously hard to port to other editors (e.g. [Rudel](https://www.emacswiki.org/emacs/Rudel) failed to implement this in Emacs. 0.7 release in jan 2017 adds possible python bindings that might improve this. Interesting plugins: autosave to disk. |
-| [moonedit](https://web.archive.org/web/20060423192346/http://www.moonedit.com:80/) | 2005-2008? | ? | Original website died. Other user's cursors visible and emulated keystrokes noises. Calculator and music sequencer. |
-| [synchroedit](http://www.synchroedit.com/) | 2006-2007 | ? | First web app. |
-| [Etherpad](http://etherpad.org/) | 2008-now | Web | First solid webapp. Originally developped as a heavy Java app in 2008, acquired and opensourced by google in 2009, then rewritten in Node.js in 2011. Widely used. |
-| [CRDT](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) | 2011 | Specification | Standard for replicating a document's datastructure among different computers reliably.|
-| [Operational transform](http://operational-transformation.github.io/) | 2013 | Specification | Similar to CRDT, yet, well, different. |
-| [Floobits](https://floobits.com/) | 2013-now | ? | Commercial, but opensource plugins for different editors |
-| [HackMD](https://hackmd.io/) | 2015-now | ? | Commercial but [opensource](https://github.com/hackmdio/hackmd). Inspired by hackpad, which was bought up by Dropbox. |
-| [Cryptpad](https://cryptpad.fr/) | 2016-now | web? | spin-off of xwiki. encrypted, "zero-knowledge" on server |
-| [Prosemirror](https://prosemirror.net/) | 2016-now | Web, Node.JS | "Tries to bridge the gap between Markdown text editing and classical WYSIWYG editors." Not really an editor, but something that can be used to build one. |
-| [Qill](https://quilljs.com/) | 2013-now | Web, Node.JS | Rich text editor, also javascript. Not sure it is really collaborative. |
-| [Nextcloud](https://nextcloud.com/collaboraonline/) | 2017-now | Web | Some sort of Google docs equivalent |
-| [Teletype](https://teletype.atom.io/) | 2017-now | WebRTC, Node.JS | For the GitHub's [Atom editor](https://atom.io), introduces "portal" idea that makes guests follow what the host is doing across multiple docs. p2p with webRTC after visit to introduction server, CRDT based. |
-| [Tandem](http://typeintandem.com/) | 2018-now | Node.JS? | Plugins for atom, vim, neovim, sublime... uses a relay to setup p2p connexions CRDT based. [Dubious license issues](https://github.com/typeintandem/tandem/issues/131) were resolved thanks to the involvement of Debian developers, which makes it a promising standard to follow in the future. |
-| [Code sandbox](https://codesandbox.io/) | 2018-now | Node.JS? | Originally just a web-based text editor, [introduced collaborative editing in 2018](https://hackernoon.com/introducing-codesandbox-live-real-time-code-collaboration-in-the-browser-6d508cfc70c9?gi=b1f154f8e8f8) |
+<table class="table">
+<colgroup><col>
+<col>
+<col>
+<col>
+</colgroup><thead>
+<tr>
+	<th>Project</th>
+	<th>Date</th>
+	<th>Platform</th>
+	<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+	<td><a href="https://www.codingmonkeys.de/subethaedit/">SubEthaEdit</a></td>
+	<td>2003-2015?</td>
+	<td>Mac-only</td>
+	<td>first collaborative, real-time, multi-cursor editor I could find. <a href="https://www.emacswiki.org/emacs/SubEthaEmacs">reverse-engineering attempt in Emacs</a></td>
+</tr>
+<tr>
+	<td><a href="http://docsynch.sourceforge.net/">DocSynch</a></td>
+	<td>2004-2007</td>
+	<td>?</td>
+	<td>built on top of IRC <img src="../../smileys/idea.png" alt="(!)"></td>
+</tr>
+<tr>
+	<td><a href="https://gobby.github.io/">Gobby</a></td>
+	<td>2005-now</td>
+	<td>C, multi-platform</td>
+	<td>first open, solid and reliable implementation. still around! protocol ("<a href="http://infinote.0x539.de/libinfinity/API/libinfinity/">libinfinoted</a>") notoriously hard to port to other editors (e.g. <a href="https://www.emacswiki.org/emacs/Rudel">Rudel</a> failed to implement this in Emacs. 0.7 release in jan 2017 adds possible python bindings that might improve this. Interesting plugins: autosave to disk.</td>
+</tr>
+<tr>
+	<td><a href="https://web.archive.org/web/20060423192346/http://www.moonedit.com:80/">moonedit</a></td>
+	<td>2005-2008?</td>
+	<td>?</td>
+	<td>Original website died. Other user's cursors visible and emulated keystrokes noises. Calculator and music sequencer.</td>
+</tr>
+<tr>
+	<td><a href="http://www.synchroedit.com/">synchroedit</a></td>
+	<td>2006-2007</td>
+	<td>?</td>
+	<td>First web app.</td>
+</tr>
+<tr>
+	<td><a href="http://etherpad.org/">Etherpad</a></td>
+	<td>2008-now</td>
+	<td>Web</td>
+	<td>First solid webapp. Originally developped as a heavy Java app in 2008, acquired and opensourced by google in 2009, then rewritten in Node.js in 2011. Widely used.</td>
+</tr>
+<tr>
+	<td><a href="https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type">CRDT</a></td>
+	<td>2011</td>
+	<td>Specification</td>
+	<td>Standard for replicating a document's datastructure among different computers reliably.</td>
+</tr>
+<tr>
+	<td><a href="http://operational-transformation.github.io/">Operational transform</a></td>
+	<td>2013</td>
+	<td>Specification</td>
+	<td>Similar to CRDT, yet, well, different.</td>
+</tr>
+<tr>
+	<td><a href="https://floobits.com/">Floobits</a></td>
+	<td>2013-now</td>
+	<td>?</td>
+	<td>Commercial, but opensource plugins for different editors</td>
+</tr>
+<tr>
+	<td><a href="https://hackmd.io/">HackMD</a></td>
+	<td>2015-now</td>
+	<td>?</td>
+	<td>Commercial but <a href="https://github.com/hackmdio/hackmd">opensource</a>. Inspired by hackpad, which was bought up by Dropbox.</td>
+</tr>
+<tr>
+	<td><a href="https://cryptpad.fr/">Cryptpad</a></td>
+	<td>2016-now</td>
+	<td>web?</td>
+	<td>spin-off of xwiki. encrypted, "zero-knowledge" on server</td>
+</tr>
+<tr>
+	<td><a href="https://prosemirror.net/">Prosemirror</a></td>
+	<td>2016-now</td>
+	<td>Web, Node.JS</td>
+	<td>"Tries to bridge the gap between Markdown text editing and classical WYSIWYG editors." Not really an editor, but something that can be used to build one.</td>
+</tr>
+<tr>
+	<td><a href="https://quilljs.com/">Qill</a></td>
+	<td>2013-now</td>
+	<td>Web, Node.JS</td>
+	<td>Rich text editor, also javascript. Not sure it is really collaborative.</td>
+</tr>
+<tr>
+	<td><a href="https://nextcloud.com/collaboraonline/">Nextcloud</a></td>
+	<td>2017-now</td>
+	<td>Web</td>
+	<td>Some sort of Google docs equivalent</td>
+</tr>
+<tr>
+	<td><a href="https://teletype.atom.io/">Teletype</a></td>
+	<td>2017-now</td>
+	<td>WebRTC, Node.JS</td>
+	<td>For the GitHub's <a href="https://atom.io">Atom editor</a>, introduces "portal" idea that makes guests follow what the host is doing across multiple docs. p2p with webRTC after visit to introduction server, CRDT based.</td>
+</tr>
+<tr>
+	<td><a href="http://typeintandem.com/">Tandem</a></td>
+	<td>2018-now</td>
+	<td>Node.JS?</td>
+	<td>Plugins for atom, vim, neovim, sublime... uses a relay to setup p2p connexions CRDT based. <a href="https://github.com/typeintandem/tandem/issues/131">Dubious license issues</a> were resolved thanks to the involvement of Debian developers, which makes it a promising standard to follow in the future.</td>
+</tr>
+<tr>
+	<td><a href="https://codesandbox.io/">Code sandbox</a></td>
+	<td>2018-now</td>
+	<td>Node.JS?</td>
+	<td>Originally just a web-based text editor, <a href="https://hackernoon.com/introducing-codesandbox-live-real-time-code-collaboration-in-the-browser-6d508cfc70c9?gi=b1f154f8e8f8">introduced collaborative editing in 2018</a></td>
+</tr>
+</tbody>
+</table>
 
 Other lists
 ===========

rewrite everything as a table, more succint
diff --git a/blog/2018-06-26-collaborative-editors-history.mdwn b/blog/2018-06-26-collaborative-editors-history.mdwn
index 6d60dea5..d9e54eb5 100644
--- a/blog/2018-06-26-collaborative-editors-history.mdwn
+++ b/blog/2018-06-26-collaborative-editors-history.mdwn
@@ -5,196 +5,41 @@ chronological order.
 
 [[!toc]]
 
-The mother of all demos
-=======================
+As with any such list, it must start with an honorable mention to [the
+mother of all demos](https://en.wikipedia.org/wiki/The_Mother_of_All_Demos) during which [Doug Engelbart](https://en.wikipedia.org/wiki/Douglas_Engelbart) presented
+what is basically an exhaustive list of all possible software written
+since 1968. This includes not only a collaborative editor, but
+graphics, programming and math editor.
 
-1968
-
-As with any such list, it must start with [the mother of all demos](https://en.wikipedia.org/wiki/The_Mother_of_All_Demos)
-during which [Doug Engelbart](https://en.wikipedia.org/wiki/Douglas_Engelbart) presented what is basically an
-exhaustive list of all possible software written since 1968.
-
-Everything else is just a slower implementation to compensate for the
-acceleration of hardware.
+Everything else after that demo is just a slower implementation to
+compensate for the acceleration of hardware.
 
 > Software gets slower faster than hardware gets faster.
 >                         - Wirth's law
 
-subethaedit
-===========
-
-2003-2015?, mac-only
-
-<https://www.codingmonkeys.de/subethaedit/>
-
-first collaborative, real-time, multi-cursor editor I could find.
-
-[reverse-engineering attempt in Emacs](https://www.emacswiki.org/emacs/SubEthaEmacs)
-
-DocSynch
-========
-
-2004-2007
-
-<http://docsynch.sourceforge.net/>
-
-built on top of IRC (!)
-
-Gobby
-=====
-
-2005-now
-
-<https://gobby.github.io/>
-
-still around! protocol in libinfinoted, but notoriously hard to port
-to other editors (e.g. [Rudel](https://www.emacswiki.org/emacs/Rudel) failed to implement this in
-Emacs. 0.7 release in jan 2017 with possible python bindings might
-improve this.
-
-Interesting plugins: autosave to disk.
-
-[API docs](http://infinote.0x539.de/libinfinity/API/libinfinity/)
-
-moonedit
-========
-
-2005-2008?
-
-Original website died, [web archive](https://web.archive.org/web/20060423192346/http://www.moonedit.com:80/)
-
-synchroedit
-===========
-
-<http://www.synchroedit.com/>
-
-2006-2007
-
-Etherpad
-========
-
-<http://etherpad.org/>
-
-2008-now
-
-First webapp.
-
-Originally developped as a heavy Java app in 2008, acquired and
-opensourced by google in 2009, then rewritten in Node.js
-in 2011. Widely used.
-
-CRDT
-====
-
-<https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type>
-
-2011
-
-Standard for replicating a document's datastructure among different
-computers reliably.
-
-Operational transform
-=====================
-
-<http://operational-transformation.github.io/>
-
-2013
-
-Similar to CRDT, yet, well, different.
-
-HackMD
-======
-
-2015-now
-
-<https://hackmd.io/>
-
-Commercial but [opensource](https://github.com/hackmdio/hackmd). Inspired by hackpad, which was bought
-up by Dropbox.
-
-Cryptpad
-========
-
-<https://cryptpad.fr/>
-
-spin-off of xwiki. encrypted, "zero-knowledge" on server?
-
-Floobits
-========
-
-2013-now
-
-<https://floobits.com/>
-
-Commercial, but opensource plugins for different editors
-
-Prosemirror
-===========
-
-2016-now
-
-<https://prosemirror.net/>
-
-"Tries to bridge the gap between Markdown text editing and classical
-WYSIWYG editors."
-
-Not really an editor, but something that can be used to build one,
-node.js.
-
-Qill
-=====
-
-2013-now
-
-<https://quilljs.com/>
-
-Rich text editor, also javascript. Not sure it is really
-collaborative.
-
-Nextcloud + Office
-==================
-
-2017-now?
-
-<https://nextcloud.com/collaboraonline/>
-
-Some sort of Google docs equivalent
-
-Teletype
-========
-
-2017-now
-
-<https://teletype.atom.io/>
-
-For the GitHub's [Atom editor](https://atom.io), introduces "portal" idea that makes
-guests follow what the host is doing across multiple docs.
-
-p2p with webRTC after visit to introduction server, CRDT based.
-
-Tandem
-======
-
-2018-now
-
-<http://typeintandem.com/>
-
-Plugins for atom, vim, neovim, sublime... uses a relay to setup p2p connexions
-CRDT based.
-
-[Dubious license issues](https://github.com/typeintandem/tandem/issues/131) were resolved thanks to the involvement of
-Debian developers, which makes it a promising standard to follow in
-the future.
-
-Code sandbox
-============
-
-2018-now

(fichier de différences tronqué)
document all "extraordinary" statements from rockwell correctly
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index 3b2e3a08..93d7a6fd 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -198,9 +198,9 @@ Gogogsses:
 
 Lentilles primes:
 
- 4. [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm), vraiment une jolie petite
-    lentille, très pratique pour le voyage et rend l'appareil discret,
-    300-350$ sur kijiji, 540$ lozeau
+ 4. [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm) ("extraordinary lens"),
+    vraiment une jolie petite lentille, très pratique pour le voyage
+    et rend l'appareil discret, 300-350$ sur kijiji, 540$ lozeau
  5. [35mm f/2 R WR ø43](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf2_r_wr/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f2.htm), [fstoppers](https://fstoppers.com/gear/fstoppers-reviews-fujifilm-35mm-f2-wr-158227), bonne
     taille, scellée, 350-400$ sur kijiji , 500$ lozeau
  6. [60mm f/2.4 R Macro ø39](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm) ("extraordinary lens"),
@@ -212,8 +212,8 @@ Range: 1070$-1450$ sur kijiji, 1830$ lozeau
 
 Autres possibilités, mais un peu hors de prix...
 
- 1. [23mm f/1.4 R ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf23mmf14_r/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/23mm-f14.htm), [fstoppers](https://fstoppers.com/gear/worlds-quickest-lens-review-fuji-xf-23mm-14r-8342) (glowing review),
-    700-900$ on kijiji
+ 1. [23mm f/1.4 R ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf23mmf14_r/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/23mm-f14.htm) ("extraordinary lens"),
+    [fstoppers](https://fstoppers.com/gear/worlds-quickest-lens-review-fuji-xf-23mm-14r-8342) (glowing review), 700-900$ on kijiji
  2. [16-55mm f/2.8 R LM WR ø77](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf16_55mmf28_r_lm_wr/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/16-55mm-f28.htm), [Phoblographer](https://www.thephoblographer.com/2015/03/12/review-fujifilm-16-55mm-f2-8-lm-wr-fujifilm-x-mount/), huge
     but real nice, 900-1400$
  3. [35mm f/1.4 R ø52](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf14_r/), [Rockwell](https://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f14.htm) ("extraordinary lens"),
@@ -230,8 +230,11 @@ Autres possibilités, mais un peu hors de prix...
     Lozeau, cheaper slower version of the 56mm, [not good for
     macro](https://www.imaging-resource.com/lenses/fujinon/xf-50mm-f2-r-wr/review/) as small magnification and not much closeup (39cm min)
 
-PS: It looks like Rockwell considers all Fujifilm lenses to be
-"extraordinary" in some shape or form, so be warned.
+PS: It looks like Rockwell considers almost all Fujifilm lenses to be
+"extraordinary" in some way, so be warned of the potential
+bias. (Direct quote: "the Fuji X-Mount Lenses are all extraordinary.")
+He is linked above because he's one of the few reviewers that has good
+coverage of almost the whole Fujinon X series.
 
 2013-2017 shopping
 ==================

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

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

braindump of quick research on collaborative editors
diff --git a/blog/2018-06-26-collaborative-editors-history.mdwn b/blog/2018-06-26-collaborative-editors-history.mdwn
new file mode 100644
index 00000000..6d60dea5
--- /dev/null
+++ b/blog/2018-06-26-collaborative-editors-history.mdwn
@@ -0,0 +1,205 @@
+[[!meta title="Historical inventory of collaborative editors"]]
+
+A quick inventory of major collaborative editor efforts, in
+chronological order.
+
+[[!toc]]
+
+The mother of all demos
+=======================
+
+1968
+
+As with any such list, it must start with [the mother of all demos](https://en.wikipedia.org/wiki/The_Mother_of_All_Demos)
+during which [Doug Engelbart](https://en.wikipedia.org/wiki/Douglas_Engelbart) presented what is basically an
+exhaustive list of all possible software written since 1968.
+
+Everything else is just a slower implementation to compensate for the
+acceleration of hardware.
+
+> Software gets slower faster than hardware gets faster.
+>                         - Wirth's law
+
+subethaedit
+===========
+
+2003-2015?, mac-only
+
+<https://www.codingmonkeys.de/subethaedit/>
+
+first collaborative, real-time, multi-cursor editor I could find.
+
+[reverse-engineering attempt in Emacs](https://www.emacswiki.org/emacs/SubEthaEmacs)
+
+DocSynch
+========
+
+2004-2007
+
+<http://docsynch.sourceforge.net/>
+
+built on top of IRC (!)
+
+Gobby
+=====
+
+2005-now
+
+<https://gobby.github.io/>
+
+still around! protocol in libinfinoted, but notoriously hard to port
+to other editors (e.g. [Rudel](https://www.emacswiki.org/emacs/Rudel) failed to implement this in
+Emacs. 0.7 release in jan 2017 with possible python bindings might
+improve this.
+
+Interesting plugins: autosave to disk.
+
+[API docs](http://infinote.0x539.de/libinfinity/API/libinfinity/)
+
+moonedit
+========
+
+2005-2008?
+
+Original website died, [web archive](https://web.archive.org/web/20060423192346/http://www.moonedit.com:80/)
+
+synchroedit
+===========
+
+<http://www.synchroedit.com/>
+
+2006-2007
+
+Etherpad
+========
+
+<http://etherpad.org/>
+
+2008-now
+
+First webapp.
+
+Originally developped as a heavy Java app in 2008, acquired and
+opensourced by google in 2009, then rewritten in Node.js
+in 2011. Widely used.
+
+CRDT
+====
+
+<https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type>
+
+2011
+
+Standard for replicating a document's datastructure among different
+computers reliably.
+
+Operational transform
+=====================
+
+<http://operational-transformation.github.io/>
+
+2013
+
+Similar to CRDT, yet, well, different.
+
+HackMD
+======
+
+2015-now
+
+<https://hackmd.io/>
+
+Commercial but [opensource](https://github.com/hackmdio/hackmd). Inspired by hackpad, which was bought
+up by Dropbox.
+
+Cryptpad
+========
+
+<https://cryptpad.fr/>
+
+spin-off of xwiki. encrypted, "zero-knowledge" on server?
+
+Floobits
+========
+
+2013-now
+
+<https://floobits.com/>
+
+Commercial, but opensource plugins for different editors
+
+Prosemirror
+===========
+
+2016-now
+
+<https://prosemirror.net/>
+
+"Tries to bridge the gap between Markdown text editing and classical
+WYSIWYG editors."
+
+Not really an editor, but something that can be used to build one,
+node.js.
+
+Qill
+=====
+
+2013-now
+
+<https://quilljs.com/>
+
+Rich text editor, also javascript. Not sure it is really
+collaborative.
+
+Nextcloud + Office
+==================
+
+2017-now?
+
+<https://nextcloud.com/collaboraonline/>
+
+Some sort of Google docs equivalent
+
+Teletype
+========
+
+2017-now
+
+<https://teletype.atom.io/>
+
+For the GitHub's [Atom editor](https://atom.io), introduces "portal" idea that makes
+guests follow what the host is doing across multiple docs.
+
+p2p with webRTC after visit to introduction server, CRDT based.
+
+Tandem
+======
+
+2018-now
+
+<http://typeintandem.com/>
+
+Plugins for atom, vim, neovim, sublime... uses a relay to setup p2p connexions
+CRDT based.
+
+[Dubious license issues](https://github.com/typeintandem/tandem/issues/131) were resolved thanks to the involvement of
+Debian developers, which makes it a promising standard to follow in
+the future.
+
+Code sandbox
+============
+
+2018-now
+
+<https://codesandbox.io/>

(fichier de différences tronqué)
une autre gogosse
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index bccbf3fa..3b2e3a08 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -194,6 +194,7 @@ Gogogsses:
  3. un doubleur:
     * [Vivitar 62mm 2.2x](https://www.bhphotovideo.com/c/product/1150442-REG/vivitar_viv_62t_62mm_2_2x_telephoto_attachment.html) - cheapo?, 38$USD
     * [Bower VLB3558 3.5x](https://www.bhphotovideo.com/c/product/700003-REG/Bower_VLB3558_VLB3558_3_5x_Telephoto_Lens.html) - chromatic aberration? 28$USD
+ 4. un holder a lentilles "lens flipper" [75$USD @ B&H](https://www.bhphotovideo.com/c/product/1203066-REG/gowing_8809416750118_lens_flipper_for_mount.html)
 
 Lentilles primes:
 

trier, total des prix, ecarter la 50mm
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index 2c5aa999..bccbf3fa 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -180,7 +180,9 @@ Reference
 2018 shopping
 =============
 
-Évidemment, je magasine encore, cette fois pour des lentilles.
+Évidemment, je magasine encore...
+
+Gogogsses:
 
  1. lens cap holder: [1](https://www.bhphotovideo.com/c/product/834774-REG/Sensei_CK_L_Cap_Keeper_for_Lens.html?sts=pi) or [2](https://www.bhphotovideo.com/c/product/850525-REG/Sensei_ck_lp_Cap_Keeper_Plus_Lens.html), haven't found others
  2. cleaning gear:
@@ -192,17 +194,20 @@ Reference
  3. un doubleur:
     * [Vivitar 62mm 2.2x](https://www.bhphotovideo.com/c/product/1150442-REG/vivitar_viv_62t_62mm_2_2x_telephoto_attachment.html) - cheapo?, 38$USD
     * [Bower VLB3558 3.5x](https://www.bhphotovideo.com/c/product/700003-REG/Bower_VLB3558_VLB3558_3_5x_Telephoto_Lens.html) - chromatic aberration? 28$USD
+
+Lentilles primes:
+
  4. [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm), vraiment une jolie petite
     lentille, très pratique pour le voyage et rend l'appareil discret,
-    300-350$ sur kijiji
+    300-350$ sur kijiji, 540$ lozeau
  5. [35mm f/2 R WR ø43](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf2_r_wr/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f2.htm), [fstoppers](https://fstoppers.com/gear/fstoppers-reviews-fujifilm-35mm-f2-wr-158227), bonne
-    taille, scellée, 350-400$ sur kijiji 
- 6. [50mm f/2 R WR ø46](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf50mmf2_r_wr/), not many reviews! 480$ kijiji, 600$
-    Lozeau, cheaper slower version of the 56mm
- 8. [60mm f/2.4 R Macro ø39](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm) ("extraordinary lens"),
+    taille, scellée, 350-400$ sur kijiji , 500$ lozeau
+ 6. [60mm f/2.4 R Macro ø39](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm) ("extraordinary lens"),
     [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/), une bonne lentille de macro, bon compromis
     pour le portrait, mais pas aussi lumineux que la 56mm f/1.2 ou la
-    50mm f/2. 420-700$ sur kijiji, 790$ lozeau
+    50mm f/2. 420-700$ sur kijiji, 790$ lozeau (26.7cm range min)
+
+Range: 1070$-1450$ sur kijiji, 1830$ lozeau
 
 Autres possibilités, mais un peu hors de prix...
 
@@ -214,9 +219,16 @@ Autres possibilités, mais un peu hors de prix...
     700$ new [B&H](https://www.bhphotovideo.com/c/product/839139-REG/Fujifilm_16240755_35mm_f_1_4_XF_R.html), 400-460$ on kijiji
  4. [56mm f/1.2 R ø62mm](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf56mmf12_r/), [Rockwell](https://www.kenrockwell.com/fuji/x-mount-lenses/56mm-f12.htm) ("extraordinary lens",
     again), [Photography life](https://photographylife.com/reviews/fuji-xf-56mm-f-1-2-r) ("one of the best prime portrait
-    lenses on the market") 900$ sur kijiji, 1175$ lozeau
+    lenses on the market") 900$ sur kijiji, 1175$ lozeau, not so great
+    for macro (70cm min)
  5. [X100f ø49](http://www.fujifilm.com/products/digital_cameras/x/fujifilm_x100f/) 1200-1600$ on kijiji
 
+Écarté:
+
+ 6. [50mm f/2 R WR ø46](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf50mmf2_r_wr/), not many reviews. 480$ kijiji, 600$
+    Lozeau, cheaper slower version of the 56mm, [not good for
+    macro](https://www.imaging-resource.com/lenses/fujinon/xf-50mm-f2-r-wr/review/) as small magnification and not much closeup (39cm min)
+
 PS: It looks like Rockwell considers all Fujifilm lenses to be
 "extraordinary" in some shape or form, so be warned.
 

more options
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index 973d8f20..2c5aa999 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -189,19 +189,36 @@ Reference
       e.g. [blower on B&H](https://www.bhphotovideo.com/c/buy/Blowers-Compressed-Air/ci/18806/N/4077634545?origSearch=blower), 5-15$
  3. UV filter for zoom ø62mm, [9-50$ on B&H](https://www.bhphotovideo.com/c/search?setNs=p_OVER_ALL_RATE%7c1&Ns=p_OVER_ALL_RATE%7c1&ci=112&fct=fct_circular-sizes_27%7c62mm%2bfct_filter-type_39%7cuv&srtclk=sort&N=4026728358&), e.g. [B+W 62mm UV
     Haze SC 010 Filter](https://www.bhphotovideo.com/c/product/11969-REG/B_W_65070127_62mm_Ultraviolet_UV_Filter.html) at 20$
- 4. [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm), really nice little pancake
-    lens, 300-350$ on kijiji
- 5. [35mm f/2 R WR ø43](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf2_r_wr/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f2.htm), [fstoppers](https://fstoppers.com/gear/fstoppers-reviews-fujifilm-35mm-f2-wr-158227), nice size,
-    sealed, 350-400$ on kijiji 
- 6. [23mm f/1.4 R ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf23mmf14_r/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/23mm-f14.htm), [fstoppers](https://fstoppers.com/gear/worlds-quickest-lens-review-fuji-xf-23mm-14r-8342) (glowing review),
+ 3. un doubleur:
+    * [Vivitar 62mm 2.2x](https://www.bhphotovideo.com/c/product/1150442-REG/vivitar_viv_62t_62mm_2_2x_telephoto_attachment.html) - cheapo?, 38$USD
+    * [Bower VLB3558 3.5x](https://www.bhphotovideo.com/c/product/700003-REG/Bower_VLB3558_VLB3558_3_5x_Telephoto_Lens.html) - chromatic aberration? 28$USD
+ 4. [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm), vraiment une jolie petite
+    lentille, très pratique pour le voyage et rend l'appareil discret,
+    300-350$ sur kijiji
+ 5. [35mm f/2 R WR ø43](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf2_r_wr/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f2.htm), [fstoppers](https://fstoppers.com/gear/fstoppers-reviews-fujifilm-35mm-f2-wr-158227), bonne
+    taille, scellée, 350-400$ sur kijiji 
+ 6. [50mm f/2 R WR ø46](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf50mmf2_r_wr/), not many reviews! 480$ kijiji, 600$
+    Lozeau, cheaper slower version of the 56mm
+ 8. [60mm f/2.4 R Macro ø39](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm) ("extraordinary lens"),
+    [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/), une bonne lentille de macro, bon compromis
+    pour le portrait, mais pas aussi lumineux que la 56mm f/1.2 ou la
+    50mm f/2. 420-700$ sur kijiji, 790$ lozeau
+
+Autres possibilités, mais un peu hors de prix...
+
+ 1. [23mm f/1.4 R ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf23mmf14_r/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/23mm-f14.htm), [fstoppers](https://fstoppers.com/gear/worlds-quickest-lens-review-fuji-xf-23mm-14r-8342) (glowing review),
     700-900$ on kijiji
- 7. [35mm f/1.4 R ø52](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf14_r/), [Rockwell](https://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f14.htm) ("an extraordinary lens"),
-    700$ new [B&H](https://www.bhphotovideo.com/c/product/839139-REG/Fujifilm_16240755_35mm_f_1_4_XF_R.html), 400-460$ on kijiji
- 8. [60mm f/2.4 R Macro ø39mm](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm), [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/),
-    420-700$ on kijiji
- 9. [16-55mm f/2.8 R LM WR ø77](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf16_55mmf28_r_lm_wr/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/16-55mm-f28.htm), [Phoblographer](https://www.thephoblographer.com/2015/03/12/review-fujifilm-16-55mm-f2-8-lm-wr-fujifilm-x-mount/), huge
+ 2. [16-55mm f/2.8 R LM WR ø77](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf16_55mmf28_r_lm_wr/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/16-55mm-f28.htm), [Phoblographer](https://www.thephoblographer.com/2015/03/12/review-fujifilm-16-55mm-f2-8-lm-wr-fujifilm-x-mount/), huge
     but real nice, 900-1400$
- 10. [X100f ø49](http://www.fujifilm.com/products/digital_cameras/x/fujifilm_x100f/) 1200-1600$ on kijiji
+ 3. [35mm f/1.4 R ø52](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf14_r/), [Rockwell](https://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f14.htm) ("extraordinary lens"),
+    700$ new [B&H](https://www.bhphotovideo.com/c/product/839139-REG/Fujifilm_16240755_35mm_f_1_4_XF_R.html), 400-460$ on kijiji
+ 4. [56mm f/1.2 R ø62mm](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf56mmf12_r/), [Rockwell](https://www.kenrockwell.com/fuji/x-mount-lenses/56mm-f12.htm) ("extraordinary lens",
+    again), [Photography life](https://photographylife.com/reviews/fuji-xf-56mm-f-1-2-r) ("one of the best prime portrait
+    lenses on the market") 900$ sur kijiji, 1175$ lozeau
+ 5. [X100f ø49](http://www.fujifilm.com/products/digital_cameras/x/fujifilm_x100f/) 1200-1600$ on kijiji
+
+PS: It looks like Rockwell considers all Fujifilm lenses to be
+"extraordinary" in some shape or form, so be warned.
 
 2013-2017 shopping
 ==================

fix two links
diff --git a/services/mail.mdwn b/services/mail.mdwn
index a8b6e652..d0e4fca6 100644
--- a/services/mail.mdwn
+++ b/services/mail.mdwn
@@ -310,10 +310,12 @@ directly and ignore local emails.
 
 ### Ideas
 
- 1. ✓ test [syncmaildir](https://github.com/gares/syncmaildir) to replace offlineimap: would allow for an
+ 1. ✓ test [syncmaildir][] to replace offlineimap: would allow for an
     automated configuration based on SSH keys instead of
     passwords. DONE! this setup is documented in [[services/mail/syncmaildir]].
 
+[syncmaildir]: https://github.com/gares/syncmaildir
+
  2. ✓ similarly, consider using [nullmailer](https://untroubled.org/nullmailer/). bremner has [this setup
     that using SSH](https://salsa.debian.org/bremner/nullmailer-ssh). nullmailer has the advantage over [msmtp](http://msmtp.sourceforge.net/)
     that it can queue emails. update: done, with a custom rsendmail,
@@ -323,7 +325,9 @@ directly and ignore local emails.
     sendmail` could do the job as well. it would need to be some
     restricted sendmail command, maybe like `rsendmail` above. but
     then emails can only be sent online. Update: this was implemented,
-    with a nullmailer remote, as [rsendmail](https://gitlab.com/anarcat/rsendmail).
+    with a nullmailer remote, as [rsendmail][].
+
+[rsendmail]: https://gitlab.com/anarcat/rsendmail
 
  4. ultimately, maybe the IMAP server can send the email, through a
     "Outbox" folder that would slurp emails written there and send

update status of SSH delivery/retrieval and cross ref with smd docs
diff --git a/services/mail.mdwn b/services/mail.mdwn
index 476d576f..a8b6e652 100644
--- a/services/mail.mdwn
+++ b/services/mail.mdwn
@@ -310,8 +310,9 @@ directly and ignore local emails.
 
 ### Ideas
 
- 1. test [syncmaildir](https://github.com/gares/syncmaildir) to replace offlineimap: would allow for an
-    automated configuration based on SSH keys instead of passwords
+ 1. ✓ test [syncmaildir](https://github.com/gares/syncmaildir) to replace offlineimap: would allow for an
+    automated configuration based on SSH keys instead of
+    passwords. DONE! this setup is documented in [[services/mail/syncmaildir]].
 
  2. ✓ similarly, consider using [nullmailer](https://untroubled.org/nullmailer/). bremner has [this setup
     that using SSH](https://salsa.debian.org/bremner/nullmailer-ssh). nullmailer has the advantage over [msmtp](http://msmtp.sourceforge.net/)
@@ -336,6 +337,20 @@ References
  * [`TLS_README`][]
  * [`SASL_README`](http://www.postfix.org/SASL_README.html)
 
+Delievery and retrieval over SSH
+================================
+
+I have switched from using IMAP and SMTP to receive and deliver email
+to SSH as a transport mechanism. This is possible thanks to two
+different bits of software, [syncmaildir][] to replace IMAP and I
+wrote [rsendmail][] to replace SMTP. The former is documented in
+[[services/mail/syncmaildir]] and the latter is documented in the
+upstream rsendmail documentation.
+
+This makes it so I do not need to use clear-text passwords to deliver
+or retrieve email which means everything can be fully automated
+without writing any password on disk.
+
 Spam filtering
 ==============
 

order wishlist, add filter
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index bad31ae0..973d8f20 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -135,7 +135,8 @@ Appareils analogues
 Lentilles
 ---------
 
-* Fujifilm [18-55mm f/2.8-4 R LM OIS ø58](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf18_55mmf28_4_r_lm_ois/), vient avec le kit X-T2
+* Fujifilm [18-55mm f/2.8-4 R LM OIS ø58](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf18_55mmf28_4_r_lm_ois/), vient avec le kit X-T2,
+  avec un [filtre 58mm XS-Pro Clear MRC-Nano 007 Filter](https://www.bhphotovideo.com/c/product/756813-REG/B_W_66_1066106_58mm_XS_Pro_NANO_Clear.html), 30$USD
 * Fujifilm [55-200mm f/3.5-4.8 R LM OIS ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf55_200mmf35_48_r_lm_ois/), 650$ sur kijiji
 * Image 70-210mm 3.8, [Minolta SR] (monté sur le Minolta SRT-200)
 * Minolta 135mm 3.5, [Minolta SR]
@@ -181,22 +182,26 @@ Reference
 
 Évidemment, je magasine encore, cette fois pour des lentilles.
 
- * [16-55mm f/2.8 R LM WR ø77](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf16_55mmf28_r_lm_wr/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/16-55mm-f28.htm), [Phoblographer](https://www.thephoblographer.com/2015/03/12/review-fujifilm-16-55mm-f2-8-lm-wr-fujifilm-x-mount/), huge
-   but real nice, 900-1400$
- * [23mm f/1.4 R ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf23mmf14_r/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/23mm-f14.htm), [fstoppers](https://fstoppers.com/gear/worlds-quickest-lens-review-fuji-xf-23mm-14r-8342) (glowing review),
-   700-900$ on kijiji
- * [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm), nice little pancake lens, 300-350$
-   on kijiji
- * [35mm f/2 R WR ø43](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf2_r_wr/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f2.htm), [fstoppers](https://fstoppers.com/gear/fstoppers-reviews-fujifilm-35mm-f2-wr-158227), nice size,
-   sealed, 350-400$ on kijiji 
- * [35mm f/1.4 R ø52](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf14_r/), [Rockwell](https://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f14.htm) ("an extraordinary lens"),
-   700$ new [B&H](https://www.bhphotovideo.com/c/product/839139-REG/Fujifilm_16240755_35mm_f_1_4_XF_R.html), 400-460$ on kijiji
- * [60mm f/2.4 R Macro ø39mm](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm), [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/),
-   420-700$ on kijiji
- * [X100f ø49](http://www.fujifilm.com/products/digital_cameras/x/fujifilm_x100f/) 1200-1600$ on kijiji
- * lens cap holder: [1](https://www.bhphotovideo.com/c/product/834774-REG/Sensei_CK_L_Cap_Keeper_for_Lens.html?sts=pi), [2](https://www.bhphotovideo.com/c/product/850525-REG/Sensei_ck_lp_Cap_Keeper_Plus_Lens.html), haven't found others
- * [cleaning pen](https://www.bhphotovideo.com/c/product/1051483-REG/lenspen_nlp1_c_nlp1c_lens_pen.html): ~10USD. haven't looked at alternative brushes.
- * sensor cleaner?
+ 1. lens cap holder: [1](https://www.bhphotovideo.com/c/product/834774-REG/Sensei_CK_L_Cap_Keeper_for_Lens.html?sts=pi) or [2](https://www.bhphotovideo.com/c/product/850525-REG/Sensei_ck_lp_Cap_Keeper_Plus_Lens.html), haven't found others
+ 2. cleaning gear:
+    * [cleaning pen](https://www.bhphotovideo.com/c/product/1051483-REG/lenspen_nlp1_c_nlp1c_lens_pen.html): ~10USD. haven't looked at alternative brushes.
+    * air brush - apparently, that's best to clear sensors,
+      e.g. [blower on B&H](https://www.bhphotovideo.com/c/buy/Blowers-Compressed-Air/ci/18806/N/4077634545?origSearch=blower), 5-15$
+ 3. UV filter for zoom ø62mm, [9-50$ on B&H](https://www.bhphotovideo.com/c/search?setNs=p_OVER_ALL_RATE%7c1&Ns=p_OVER_ALL_RATE%7c1&ci=112&fct=fct_circular-sizes_27%7c62mm%2bfct_filter-type_39%7cuv&srtclk=sort&N=4026728358&), e.g. [B+W 62mm UV
+    Haze SC 010 Filter](https://www.bhphotovideo.com/c/product/11969-REG/B_W_65070127_62mm_Ultraviolet_UV_Filter.html) at 20$
+ 4. [27mm f/2.8 ø39](http://www.fujifilm.com/products/digital_cameras/x/fujinon_lens_xf27mmf28/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/27mm-f28.htm), really nice little pancake
+    lens, 300-350$ on kijiji
+ 5. [35mm f/2 R WR ø43](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf2_r_wr/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f2.htm), [fstoppers](https://fstoppers.com/gear/fstoppers-reviews-fujifilm-35mm-f2-wr-158227), nice size,
+    sealed, 350-400$ on kijiji 
+ 6. [23mm f/1.4 R ø62](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf23mmf14_r/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/23mm-f14.htm), [fstoppers](https://fstoppers.com/gear/worlds-quickest-lens-review-fuji-xf-23mm-14r-8342) (glowing review),
+    700-900$ on kijiji
+ 7. [35mm f/1.4 R ø52](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf14_r/), [Rockwell](https://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f14.htm) ("an extraordinary lens"),
+    700$ new [B&H](https://www.bhphotovideo.com/c/product/839139-REG/Fujifilm_16240755_35mm_f_1_4_XF_R.html), 400-460$ on kijiji
+ 8. [60mm f/2.4 R Macro ø39mm](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm), [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/),
+    420-700$ on kijiji
+ 9. [16-55mm f/2.8 R LM WR ø77](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf16_55mmf28_r_lm_wr/): [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/16-55mm-f28.htm), [Phoblographer](https://www.thephoblographer.com/2015/03/12/review-fujifilm-16-55mm-f2-8-lm-wr-fujifilm-x-mount/), huge
+    but real nice, 900-1400$
+ 10. [X100f ø49](http://www.fujifilm.com/products/digital_cameras/x/fujifilm_x100f/) 1200-1600$ on kijiji
 
 2013-2017 shopping
 ==================

include in series
diff --git a/blog/2018-05-26-kubecon-rant.mdwn b/blog/2018-05-26-kubecon-rant.mdwn
index 86f1f849..5cc616b0 100644
--- a/blog/2018-05-26-kubecon-rant.mdwn
+++ b/blog/2018-05-26-kubecon-rant.mdwn
@@ -6,7 +6,7 @@
 > * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]]
 > * [[Updates in container isolation|2018-05-31-secure-pods]]
 > * [[Securing the container image supply chain|2018-05-31-securing-container-supply]]
-> * [[Easier container security with entitlements|entitlements]] (to be published)
+> * [[Easier container security with entitlements|2018-06-13-easier-container-security-entitlements]]
 
 This is a rant I wrote while attending [KubeCon Europe 2018](https://kccnceu18.sched.com/). I do
 not know how else to frame this deep discomfort I have with the way
diff --git a/blog/2018-05-29-autoscaling-kubernetes.mdwn b/blog/2018-05-29-autoscaling-kubernetes.mdwn
index a8069d4a..3edbac2e 100644
--- a/blog/2018-05-29-autoscaling-kubernetes.mdwn
+++ b/blog/2018-05-29-autoscaling-kubernetes.mdwn
@@ -9,7 +9,7 @@
 > * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]] (this article)
 > * [[Updates in container isolation|2018-05-31-secure-pods]]
 > * [[Securing the container image supply chain|2018-05-31-securing-container-supply]]
-> * [[Easier container security with entitlements|entitlements]] (to be published)
+> * [[Easier container security with entitlements|2018-06-13-easier-container-security-entitlements]]
 
 [[!toc levels=2]]
 
diff --git a/blog/2018-05-31-secure-pods.mdwn b/blog/2018-05-31-secure-pods.mdwn
index 8a148670..d89d8bde 100644
--- a/blog/2018-05-31-secure-pods.mdwn
+++ b/blog/2018-05-31-secure-pods.mdwn
@@ -8,7 +8,7 @@
 > * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]]
 > * [[Updates in container isolation|2018-05-31-secure-pods]] (this article)
 > * [[Securing the container image supply chain|2018-05-31-securing-container-supply]]
-> * [[Easier container security with entitlements|entitlements]] (to be published)
+> * [[Easier container security with entitlements|2018-06-13-easier-container-security-entitlements]]
 
 [KubeCon EU](https://lwn.net/Archives/ConferenceByYear/#2018-KubeCon_EU)
 At [KubeCon + CloudNativeCon
diff --git a/blog/2018-05-31-securing-container-supply.mdwn b/blog/2018-05-31-securing-container-supply.mdwn
index b045b4d4..4c42f622 100644
--- a/blog/2018-05-31-securing-container-supply.mdwn
+++ b/blog/2018-05-31-securing-container-supply.mdwn
@@ -8,7 +8,7 @@
 > * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]]
 > * [[Updates in container isolation|2018-05-31-secure-pods]]
 > * [[Securing the container image supply chain|2018-05-31-securing-container-supply]] (this article)
-> * [[Easier container security with entitlements|entitlements]] (to be published)
+> * [[Easier container security with entitlements|2018-06-13-easier-container-security-entitlements]]
 
 [KubeCon EU](https://lwn.net/Archives/ConferenceByYear/#2018-KubeCon_EU)
 "Security is hard" is a tautology, especially in the fast-moving world
diff --git a/blog/2018-06-13-easier-container-security-entitlements.mdwn b/blog/2018-06-13-easier-container-security-entitlements.mdwn
index 94ac0116..861c160d 100644
--- a/blog/2018-06-13-easier-container-security-entitlements.mdwn
+++ b/blog/2018-06-13-easier-container-security-entitlements.mdwn
@@ -1,10 +1,16 @@
 [[!meta title="Easier container security with entitlements"]]
-\[LWN subscriber-only content\]
--------------------------------
 
 [[!meta date="2018-05-22T00:00:00+0000"]]
 [[!meta updated="2018-05-23T09:32:11-0400"]]
 
+> This article is part of a series on KubeCon Europe 2018.
+>
+> * [[Diversity, education, privilege and ethics in technology|2018-05-26-kubecon-rant]]
+> * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]]
+> * [[Updates in container isolation|2018-05-31-secure-pods]]
+> * [[Securing the container image supply chain|2018-05-31-securing-container-supply]]
+> * [[Easier container security with entitlements|2018-06-13-easier-container-security-entitlements]] (this article)
+
 [[!toc levels=2]]
 
 During [KubeCon + CloudNativeCon Europe

add tags, rename
diff --git a/blog/entitlements.mdwn b/blog/2018-06-13-easier-container-security-entitlements.mdwn
similarity index 99%
rename from blog/entitlements.mdwn
rename to blog/2018-06-13-easier-container-security-entitlements.mdwn
index da54f883..94ac0116 100644
--- a/blog/entitlements.mdwn
+++ b/blog/2018-06-13-easier-container-security-entitlements.mdwn
@@ -223,9 +223,6 @@ A YouTube [video](https://www.youtube.com/watch?v=Jbqxsli2tRw) and
 \[PDF\]](https://schd.ws/hosted_files/kccnceu18/d1/Kubecon%20Entitlements.pdf)
 of the talk are available.
 
-\[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting
-my travel to the event.\]
-
 ------------------------------------------------------------------------
 
 
@@ -235,4 +232,4 @@ my travel to the event.\]
 [first appeared]: https://lwn.net/Articles/755238/
 [Linux Weekly News]: http://lwn.net/
 
-[[!tag debian-planet lwn]]
+[[!tag debian-planet lwn kubernetes containers security]]

Added a comment
diff --git a/blog/2018-05-26-kubecon-rant/comment_6_a00fd375402b5c6145907d349905e5be._comment b/blog/2018-05-26-kubecon-rant/comment_6_a00fd375402b5c6145907d349905e5be._comment
new file mode 100644
index 00000000..c687ea88
--- /dev/null
+++ b/blog/2018-05-26-kubecon-rant/comment_6_a00fd375402b5c6145907d349905e5be._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ ip="130.125.11.171"
+ claimedauthor="Hugues le cousin"
+ subject="comment 6"
+ date="2018-06-11T13:54:26Z"
+ content="""
+Excellent article!
+"""]]

notes on the gemini
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index da879b23..d7ce530c 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -40,6 +40,18 @@ Tiny - closer to a phone:
 
 https://www.indiegogo.com/projects/gemini-pda-android-linux-keyboard-mobile-device-phone#/
 
+[First impressions](https://www.sommitrealweird.co.uk/blog/2018/06/07/psion-gemini/), from fellow Debian maintainer Brett Parker:
+
+> I look forward to seeing where it goes, I'm happy to have been an
+> early backer, as I don't think I'd pay the current retail price for
+> one. [...] not bad once you're on a call, but not great until you're
+> on a call, and I certainly wouldn't use it to replace the Samsung
+> Galaxy S7 Edge that I currently use as my full time phone. [...]
+> really rather useful as a sysadmin tool when you don't want to be
+> lugging a full laptop around with you, the keyboard is better than
+> using the on screen keyboard on the phone.
+
+
 Mnt reform
 ----------
 

add custom suffix for tar chroot otherwise it fails
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index e96fd484..1fe93d50 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -463,7 +463,7 @@ This assumes that:
     you need that feature (e.g. the mercurial test suite relies on
     this). to create a tarball image, use this:
     
-        sudo sbuild-createchroot --make-sbuild-tarball=/srv/chroot/unstable-amd64-sbuild.tar.gz unstable `mktemp -d` http://deb.debian.org/debian
+        sudo sbuild-createchroot --make-sbuild-tarball=/srv/chroot/unstable-amd64-sbuild.tar.gz unstable --chroot-prefix unstable-tar `mktemp -d` http://deb.debian.org/debian
 """]]
 
 The above will create chroots for all the main suites and two

rewrite the offloading section with sbuild
The procedure was written for cowpoke. That relies on cowbuilder which
we is a secondary option. With sbuild, there's no
sbuild-specific *thing* to do remote builds, but after looking at how
cowpoke works, it is simple enough to reproduce what it does with
simple commands (yay dcmd).
I found about dcmd after looking at the cowpoke source code.
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index 4e8f2dc7..e96fd484 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -562,24 +562,28 @@ really is...
 [AskUbuntu.com has a good comparative between pbuilder and sbuild]: http://askubuntu.com/questions/53014/why-use-sbuild-over-pbuilder
 """]]
 
-Offloading: cowpoke and debomatic
----------------------------------
+<a name="offloading-cowpoke-and-debomatic" />
+
+Build servers
+-------------
 
 Sometimes, your machine is too slow to build this stuff yourself. If
-you have a more powerful machine lying around, you can use [cowpoke][]
-to send builds to that machine. `cowpoke` operates on a source package
-(the `.dsc` file created with `dpkg-source -b`) and works well with
-`gitpkg`. By default, `cowpoke` logs into a remote server and uses
-`sudo` to call `cowbuilder` to build a chroot. For example, this will
-build calibre on the remote host `buildd.example.com`, in a
-`jessie/amd64` chroot:
+you have a more powerful machine lying around, you can send a source
+package to the machine and build the package there.
 
-    cowpoke --buildd buildd.example.com --dist sid --arch amd64 calibre_2.55.0+dfsg-1~bpo8+1.dsc
+You first need to create a source package (the `.dsc` file created
+with `dpkg-buildpackage -S`) and transfer the files over. An easy way to do
+the latter is with the [dcmd](https://manpages.debian.org/dcmd) command. For example, this will
+create a source package, transfer it to the remote host
+`example.net` and build it:
 
-This assume the chroot already exists of course. You can create it by
-using the `--create` argument. It also only works for `.dsc` files, so
-it doesn't cooperate well with git-buildpackage, which expects a
-`debuild`-like interface.
+    foo-1.0$ dpkg-buildpackage -S
+    foo-1.0$ dcmd scp ../foo_1.0.dsc example.net:dist/
+    foo-1.0$ ssh example.net sbuild dist/foo_1.0.dsc
+
+The above might cause trouble if you are working within a git
+repository, as `dpkg-source` might bundle `.git` files that should be
+ignored.
 
 To build from git, you first use `gitpkg` to generate a `.dsc` file
 from the git tree, where `rev` is the current commit of the debian
@@ -589,7 +593,23 @@ tarball if not already present:
 
     gitpkg rev upstream
 
-Then call `cowpoke` on the resulting `.dsc` file.
+Then you can use the resulting `.dsc` file as normal.
+
+[[!note """
+If you use cowbuilder, you can also use [cowpoke][] instead of the
+above. Since I started using `sbuild`, I do not have a `cowbuilder`
+setup anymore. 
+
+By default, `cowpoke` logs into a remote server and uses `sudo` to
+call `cowbuilder` to build a chroot. For example, this will build
+calibre on the remote host `buildd.example.com`, in a `jessie/amd64`
+chroot:
+
+    cowpoke --buildd buildd.example.com --dist sid --arch amd64 calibre_2.55.0+dfsg-1~bpo8+1.dsc
+
+This assume the chroot already exists of course. You can create it by
+using the `--create` argument.
+"""]]
 
 If you do not have your own host to build packages, you can upload
 source packages to another buildd using `dput`, for example through

use dpkg-buildpackage -S instead of dpkg-source -b .
This means one less command to learn, because you *need*
dpkg-buildpackage -S to perform source-only uploads, while dpkg-source
-b only builds a source package. The latter is useful to build stuff,
but that's it, so we drop that.
diff --git a/software/debian-development.mdwn b/software/debian-development.mdwn
index 00d11751..4e8f2dc7 100644
--- a/software/debian-development.mdwn
+++ b/software/debian-development.mdwn
@@ -436,9 +436,8 @@ configurations that can contaminate the build.
 
 `sbuild` takes your source package (the `.dsc` file), and builds it in
 a clean, temporary `chroot`. To create that `.dsc` file, you can use
-`dpkg-source -b` or simply call `sbuild` in the source directory. Some
-places, like Debomatic, require a full `.changes` file, which is
-generated with `dpkg-buildpackage -S`.
+`dpkg-buildpackage -S` simply call `sbuild` in the source directory
+which will create it for you.
 
 To use sbuild, you first need to configure an image:
 
@@ -478,7 +477,7 @@ packages) and each chroot is between 500MB and 700MB.
 Then I build packages in one of three ways.
 
  1. If I have a `.dsc` already (again, that can be generated with
-    `dpkg-source -b` in the source tree):
+    `dpkg-buildpackage -S` in the source tree):
  
         sbuild calibre_2.55.0+dfsg-1~bpo8+1.dsc
 

new attack against the STM / FST-01
diff --git a/blog/2017-10-26-comparison-cryptographic-keycards/comment_1_bf4338f21b87f54ff6cacf9add07f1c8._comment b/blog/2017-10-26-comparison-cryptographic-keycards/comment_1_bf4338f21b87f54ff6cacf9add07f1c8._comment
new file mode 100644
index 00000000..9f118536
--- /dev/null
+++ b/blog/2017-10-26-comparison-cryptographic-keycards/comment_1_bf4338f21b87f54ff6cacf9add07f1c8._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""STM32F103 secrets extraction"""
+ date="2018-06-06T00:05:50Z"
+ content="""
+FST-01's author (gniibe) recently found out about a key extraction service online, see this post: [STM32F103 flash ROM read-out service](https://lists.gnupg.org/pipermail/gnupg-users/2018-June/060601.html).
+
+This does not profoundly change the conclusions from this article: attacks were already known against the previous STMF design. That such an attack can be mounted against the FST-01 firmware is not surprising, although it is a little disconcerting to find out about it as a *service* (as opposed to a publication or research.
+
+gniibe suggested using the gnuk's new [KDF-DO algorithm](https://dev.gnupg.org/T3152), which seems to be a custom-built key derivation function built with SHA-2. I can't tell from a quick inspection of the source but it probably suffers from the same issues as [PBKDF](https://en.wikipedia.org/wiki/PBKDF2) in that it's vulnerable to custom-built ASICs, or, to put it simply: SHA-2 is too fast and shouldn't be used in a KDF. Unfortunately, the limited hardware capabilities of the FST-01 might limit the gnuk to that algorithm for now. It might also be possible to do the KDF on the host which might leverage more powerful processing. The new KDF support was released in [Gnuk 1.2.8](https://www.fsij.org/gnuk/version1_2_8.html) in January 2018.
+
+All this requires physical access to the key, and having the key lost long enough to allow for such extraction should probably trigger key revocation which was also explained in the article.
+
+Just something to keep in mind still...
+"""]]

new bottom
diff --git a/hardware/camera.mdwn b/hardware/camera.mdwn
index f5806719..bad31ae0 100644
--- a/hardware/camera.mdwn
+++ b/hardware/camera.mdwn
@@ -190,7 +190,7 @@ Reference
  * [35mm f/2 R WR ø43](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf2_r_wr/), [Rockwell](http://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f2.htm), [fstoppers](https://fstoppers.com/gear/fstoppers-reviews-fujifilm-35mm-f2-wr-158227), nice size,
    sealed, 350-400$ on kijiji 
  * [35mm f/1.4 R ø52](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf35mmf14_r/), [Rockwell](https://www.kenrockwell.com/fuji/x-mount-lenses/35mm-f14.htm) ("an extraordinary lens"),
-   700$ new [B&H](https://www.bhphotovideo.com/c/product/839139-REG/Fujifilm_16240755_35mm_f_1_4_XF_R.html), 460$ on kijiji
+   700$ new [B&H](https://www.bhphotovideo.com/c/product/839139-REG/Fujifilm_16240755_35mm_f_1_4_XF_R.html), 400-460$ on kijiji
  * [60mm f/2.4 R Macro ø39mm](http://www.fujifilm.ca/products/digital_cameras/x/fujinon_lens_xf60mmf24_r_macro/), [Rockwell](https://kenrockwell.com/fuji/x-mount-lenses/60mm-f24.htm), [Photograph blog](http://www.photographyblog.com/reviews/fujifilm_xf_60mm_f2_4_r_review/),
    420-700$ on kijiji
  * [X100f ø49](http://www.fujifilm.com/products/digital_cameras/x/fujifilm_x100f/) 1200-1600$ on kijiji

limit image width so it scales properly
diff --git a/blog/2018-05-31-secure-pods.mdwn b/blog/2018-05-31-secure-pods.mdwn
index 5d9437db..8a148670 100644
--- a/blog/2018-05-31-secure-pods.mdwn
+++ b/blog/2018-05-31-secure-pods.mdwn
@@ -118,7 +118,7 @@ and audit. It provides a cleaner and simpler interface: no hardware
 drivers, interrupts, or I/O port support to implement, as the host
 operating system takes care of all that mess.
 
-[[!img gvisor-architecture.png alt="gVisor architecture"]]
+[[!img gvisor-architecture.png size="600x" alt="gVisor architecture"]]
 
 As we can see in the diagram above (taken from the talk slides),
 gVisor has a component called "sentry" that implements the core of the

two new articles online
diff --git a/blog/2018-05-26-kubecon-rant.mdwn b/blog/2018-05-26-kubecon-rant.mdwn
index 0cd2e395..86f1f849 100644
--- a/blog/2018-05-26-kubecon-rant.mdwn
+++ b/blog/2018-05-26-kubecon-rant.mdwn
@@ -4,8 +4,8 @@
 >
 > * [[Diversity, education, privilege and ethics in technology|2018-05-26-kubecon-rant]] (this article)
 > * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]]
-> * [[Updates in container isolation|2018-05-29-secure-pods]] (to be published)
-> * [[Securing the container image supply chain|image-security]] (to be published)
+> * [[Updates in container isolation|2018-05-31-secure-pods]]
+> * [[Securing the container image supply chain|2018-05-31-securing-container-supply]]
 > * [[Easier container security with entitlements|entitlements]] (to be published)
 
 This is a rant I wrote while attending [KubeCon Europe 2018](https://kccnceu18.sched.com/). I do
diff --git a/blog/2018-05-29-autoscaling-kubernetes.mdwn b/blog/2018-05-29-autoscaling-kubernetes.mdwn
index 6d34e8c7..a8069d4a 100644
--- a/blog/2018-05-29-autoscaling-kubernetes.mdwn
+++ b/blog/2018-05-29-autoscaling-kubernetes.mdwn
@@ -7,8 +7,8 @@
 >
 > * [[Diversity, education, privilege and ethics in technology|2018-05-26-kubecon-rant]]
 > * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]] (this article)
-> * [[Updates in container isolation|2018-05-29-secure-pods]] (to be published)
-> * [[Securing the container image supply chain|image-security]] (to be published)
+> * [[Updates in container isolation|2018-05-31-secure-pods]]
+> * [[Securing the container image supply chain|2018-05-31-securing-container-supply]]
 > * [[Easier container security with entitlements|entitlements]] (to be published)
 
 [[!toc levels=2]]
diff --git a/blog/2018-05-31-secure-pods.mdwn b/blog/2018-05-31-secure-pods.mdwn
new file mode 100644
index 00000000..5d9437db
--- /dev/null
+++ b/blog/2018-05-31-secure-pods.mdwn
@@ -0,0 +1,245 @@
+[[!meta title="Updates in container isolation"]]
+[[!meta date="2018-05-16T12:00:00-0500"]]
+[[!meta updated="2018-05-31T13:22:07-04:00"]]
+
+> This article is part of a series on KubeCon Europe 2018.
+>
+> * [[Diversity, education, privilege and ethics in technology|2018-05-26-kubecon-rant]]
+> * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]]
+> * [[Updates in container isolation|2018-05-31-secure-pods]] (this article)
+> * [[Securing the container image supply chain|2018-05-31-securing-container-supply]]
+> * [[Easier container security with entitlements|entitlements]] (to be published)
+
+[KubeCon EU](https://lwn.net/Archives/ConferenceByYear/#2018-KubeCon_EU)
+At [KubeCon + CloudNativeCon
+Europe](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/)
+2018, several talks explored the topic of container isolation and
+security. The last year saw the release of [Kata
+Containers](https://katacontainers.io/) which, combined with the
+[CRI-O](http://cri-o.io/) project, provided strong isolation guarantees
+for containers using a hypervisor. During the conference, Google
+released its own hypervisor called
+[gVisor](https://github.com/google/gvisor), adding yet another possible
+solution for this problem. Those new developments prompted the community
+to work on integrating the concept of "secure containers" (or "sandboxed
+containers") deeper into Kubernetes. This work is now coming to
+fruition; it prompts us to look again at how Kubernetes tries to keep
+the bad guys from wreaking havoc once they break into a container.
+
+Attacking and defending the container boundaries
+------------------------------------------------
+
+[![Tim Allclair](https://photos.anarc.at/events/kubecon-eu-2018/DSCF3523.JPG)](https://photos.anarc.at/events/kubecon-eu-2018/#/43)
+
+Tim Allclair's
+[talk](https://kccnceu18.sched.com/event/Dqvf/secure-pods-tim-allclair-google-advanced-skill-level)
+([slides
+\[PDF\]](https://schd.ws/hosted_files/kccnceu18/96/Secure%20Pods%20-%20KubeCon%20EU%202018.pdf),
+[video](https://www.youtube.com/watch?v=GLwmJh-j3rs)) was all about
+explaining the possible attacks on secure containers. To simplify,
+Allclair said that "secure is isolation, even if that's a little
+imprecise" and explained that isolation is directional across
+boundaries: for example, a host might be isolated from a guest
+container, but the container might be fully visible from the host. So
+there are two distinct problems here: threats from the outside
+(attackers trying to get *into* a container) and threats from the
+inside (attackers trying to get *out* of a compromised
+container). Allclair's talk focused on the latter. In this context,
+sandboxed containers are concerned with threats from the *inside*;
+once the attacker is inside the sandbox, they should not be able to
+compromise the system any further.
+
+Attacks can take multiple forms: untrusted code provided by users in
+multi-tenant clusters, un-audited code fetched from random sites by
+trusted users, or trusted code compromised through an unknown
+vulnerability. According to Allclair, defending a system from a
+compromised container is harder than defending a container from external
+threats, because there is a larger attack surface. While outside
+attackers only have access to a single port, attackers on the inside
+often have access to the kernel's extensive system-call interface, a
+multitude of storage backends, the internal network, daemons providing
+services to the cluster, hardware interfaces, and so on.
+
+Taking those vectors one by one, Allclair first looked at the kernel and
+said that there were [169 code execution
+vulnerabilities](https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2017/opec-1/Linux-Linux-Kernel.html)
+in the Linux kernel in 2017. He admitted this was a bit of fear
+mongering; it indeed was a rather [unusual
+year](https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33)
+and "most of those were in mobile device drivers". These vulnerabilities
+are not really a problem for Kubernetes unless you run it on your phone.
+Allclair said that at least one attendee at the conference was probably
+doing exactly that; as it turns out, some people have managed to [run
+Kubernetes on a vacuum
+cleaner](https://kccnceu18.sched.com/event/DqwI/why-running-kubelet-on-your-vacuum-robot-is-not-a-good-idea-christian-simon-jetstack-any-skill-level).
+Container runtimes implement all sorts of mechanisms to reduce the
+kernel's attack surface: Docker has seccomp profiles, but Kubernetes
+turns those off by default. Runtimes will use AppArmor or SELinux rule
+sets. There are also ways to run containers as non-root, which was the
+topic of a pun-filled [separate
+talk](https://kccnceu18.sched.com/event/DquO/the-route-to-rootless-containers-ed-king-pivotal-julz-friedman-ibm-any-skill-level)
+as well. Unfortunately, those mechanisms do not fundamentally solve the
+problem of kernel vulnerabilities. Allclair cited the [Dirty
+COW](https://dirtycow.ninja/) vulnerability as a classic example of a
+container escape through race conditions on system calls that *are*
+allowed by security profiles.
+
+The proposed solution to this problem is to add a second security
+boundary. This is apparently an overarching principle at Google,
+according to Allclair: "At Google, we have this principle security
+principle that between any untrusted code and user data there have to be
+at least two distinct security boundaries so that means two independent
+security mechanisms need to fail in order to for that untrusted code to
+get out that user data."
+
+Adding another boundary makes attacks harder to accomplish. One such
+solution is to use a hypervisor like Kata Containers or gVisor. Those
+new runtimes depend on a `sandboxed` setting that is still in the
+proposal stage in the Kubernetes API.
+
+gVisor as an extra boundary
+---------------------------
+
+[![Dawn Chen](https://photos.anarc.at/events/kubecon-eu-2018/original/DSCF3361.JPG)](https://photos.anarc.at/events/kubecon-eu-2018/#/31)
+
+Let's look at gVisor as an example hypervisor. Google spent five years
+developing the project in the dark before sharing it with the
+world. At KubeCon, it was introduced in a keynote and a more in-depth
+[talk](https://kccnceu18.sched.com/event/Dqv1/best-practice-for-container-security-at-scale-dawn-chen-zhengyu-he-google-intermediate-skill-level)
+([slides
+\[PDF\]](https://schd.ws/hosted_files/kccnceu18/47/Container%20Isolation%20at%20Scale.pdf),
+[video](https://www.youtube.com/watch?v=pWyJahTWa4I)) by Dawn Chen and
+Zhengyu He. gVisor is a user-space kernel that implements a subset of
+the Linux kernel API, but which was written from scratch in Go. The
+idea is to have an independent kernel that reduces the attack surface;
+while the Linux kernel has 20 million lines of code, at the time of
+writing gVisor only has 185,000, which should make it easier to review
+and audit. It provides a cleaner and simpler interface: no hardware
+drivers, interrupts, or I/O port support to implement, as the host
+operating system takes care of all that mess.
+
+[[!img gvisor-architecture.png alt="gVisor architecture"]]
+
+As we can see in the diagram above (taken from the talk slides),
+gVisor has a component called "sentry" that implements the core of the
+system-call logic. It uses `ptrace()` out of the box for portability
+reasons, but can also work with KVM for better security and performance,
+as `ptrace()` is slow and racy. Sentry can use KVM to map processes to
+CPUs and provide lower-level support like privilege separation and
+memory-management. He suggested thinking of gVisor as a "layered
+solution" to provide isolation, as it also uses seccomp filters and
+namespaces. He explained how it differed from user-mode Linux (UML):
+while UML is a port of Linux to user space, gVisor actually reimplements
+the Linux system calls (211 of the 319 x86-64 system calls) using only
+64 system calls in the host system. Another key difference from other
+systems, like [unikernels](http://unikernel.org/) or Google's Native
+Client ([NaCL](https://developer.chrome.com/native-client)), is that it
+can run unmodified binaries. To fix classes of attacks relying on the
+`open()` system call, gVisor also forbids any direct filesystem access;
+all filesystem operations go through a second process called the
+`gopher` that enforces access permissions, in another example of a
+double security boundary.
+
+[![Zhengyu He](https://photos.anarc.at/events/kubecon-eu-2018/DSCF3367.JPG)](https://photos.anarc.at/events/kubecon-eu-2018/#/33)
+
+According to He, gVisor has a 150ms startup time and 15MB overhead,
+close to Kata Containers startup times, but smaller in terms of
+memory.  He said the approach is good for small containers in
+high-density workloads. It is not so useful for trusted images
+(because it's not required), workloads that make heavy use of system
+calls (because of the performance overhead), or workloads that require
+hardware access (because that's not available at all). Even though
+gVisor implements a large number of system calls, some functionality is
+missing. There is no System V shared memory, for example, which means
+[PostgreSQL](https://github.com/google/gvisor/issues/3) does not work
+under gVisor. A simple `ping` might not work either, as gVisor [lacks
+`SOCK_RAW` support](https://github.com/google/gvisor/issues/6). Linux
+has been in use for decades now and is more than just a set of system
+calls: interfaces like `/proc` and sysfs also make Linux what it is.
+~~gVisor implements none of those~~ Of those, gVisor only implements a
+subset of `/proc` currently, with the result that some containers will
+not work with gVisor without modification, for now.
+
+As an aside, the new hypervisor does allow for experimentation and
+development of new system calls directly in user space. The speakers

(fichier de différences tronqué)
slides available
diff --git a/blog/2018-05-26-kubecon-rant/comment_5_6edd9e76d5b80cd6f163ed9b6ddcd5ad._comment b/blog/2018-05-26-kubecon-rant/comment_5_6edd9e76d5b80cd6f163ed9b6ddcd5ad._comment
new file mode 100644
index 00000000..bb0c5fe7
--- /dev/null
+++ b/blog/2018-05-26-kubecon-rant/comment_5_6edd9e76d5b80cd6f163ed9b6ddcd5ad._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""presentation"""
+ date="2018-05-31T15:26:03Z"
+ content="""
+Out of sheer coincidence, a friend asked me this week to do my (now
+usual) presentation in their class. The course is called
+"*Informatique et société*" and is given at [UQAM](http://uqam.ca) to computer
+science students, as an general philosophy / ethics class.
+
+I often go there to talk about free software, my experience working at
+[Koumbit](https://koumbit.org) and so on, but this time around I had
+some other material to give, so I gave an ardent talk based on this
+article which was met with a round of applause and heated debate about
+whether those problems were bound to human nature (I don't think so),
+what we can actually do about it (just do the right thing, damnit) and
+what kind of ethical decisions or projects people get involved in
+(some students help community groups with their website, others get
+involved in free software).
+
+We talked about self-driving cars and the trolley problem (why are
+people on the track in the first place? why don't we just get rid of
+cars instead?), about social networking (people were just as isolated
+in the bus when they were reading their newspapers a century ago, but
+social media is engineered to create addiction, craving, and filter
+bubbles) and many more stuff than I can related here.
+
+It was fun.
+
+Slides are available in [this repository](https://gitlab.com/anarcat/presentation-ethics).
+"""]]

link to systemd experiments
diff --git a/services/mail/syncmaildir.mdwn b/services/mail/syncmaildir.mdwn
index 31fbcb3b..fac52809 100644
--- a/services/mail/syncmaildir.mdwn
+++ b/services/mail/syncmaildir.mdwn
@@ -292,7 +292,8 @@ one-time cost only without data loss.
         chmod +x ~/.smd/hooks/post-pull.d/notmuch
 
  16. start `smd-loop` from *somewhere*. for now just running in place
-     of OfflineIMAP in a different workspace
+     of OfflineIMAP in a different workspace. I'm also experimenting
+     with [starting SMD from systemd](https://github.com/gares/syncmaildir/issues/10)
 
  17. create restricted shell. this means creating a new key with
      `ssh-keygen`, without password, and adding it on the server in

fix typo
diff --git a/blog/2018-05-26-kubecon-rant.mdwn b/blog/2018-05-26-kubecon-rant.mdwn
index 9cfd161d..0cd2e395 100644
--- a/blog/2018-05-26-kubecon-rant.mdwn
+++ b/blog/2018-05-26-kubecon-rant.mdwn
@@ -2,7 +2,7 @@
 
 > This article is part of a series on KubeCon Europe 2018.
 >
-> * [[Diversity, education, privilege and ethics in technology|2018-05-25-kubecon-rant]] (this article)
+> * [[Diversity, education, privilege and ethics in technology|2018-05-26-kubecon-rant]] (this article)
 > * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]]
 > * [[Updates in container isolation|2018-05-29-secure-pods]] (to be published)
 > * [[Securing the container image supply chain|image-security]] (to be published)
diff --git a/blog/2018-05-29-autoscaling-kubernetes.mdwn b/blog/2018-05-29-autoscaling-kubernetes.mdwn
index b380e51e..6d34e8c7 100644
--- a/blog/2018-05-29-autoscaling-kubernetes.mdwn
+++ b/blog/2018-05-29-autoscaling-kubernetes.mdwn
@@ -5,7 +5,7 @@
 
 > This article is part of a series on KubeCon Europe 2018.
 >
-> * [[Diversity, education, privilege and ethics in technology|2018-05-25-kubecon-rant]]
+> * [[Diversity, education, privilege and ethics in technology|2018-05-26-kubecon-rant]]
 > * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]] (this article)
 > * [[Updates in container isolation|2018-05-29-secure-pods]] (to be published)
 > * [[Securing the container image supply chain|image-security]] (to be published)

publish first LWN article in the series
diff --git a/blog/2018-05-26-kubecon-rant.mdwn b/blog/2018-05-26-kubecon-rant.mdwn
index ea6dce56..9cfd161d 100644
--- a/blog/2018-05-26-kubecon-rant.mdwn
+++ b/blog/2018-05-26-kubecon-rant.mdwn
@@ -1,5 +1,13 @@
 [[!meta title="Diversity, education, privilege and ethics in technology"]]
 
+> This article is part of a series on KubeCon Europe 2018.
+>
+> * [[Diversity, education, privilege and ethics in technology|2018-05-25-kubecon-rant]] (this article)
+> * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]]
+> * [[Updates in container isolation|2018-05-29-secure-pods]] (to be published)
+> * [[Securing the container image supply chain|image-security]] (to be published)
+> * [[Easier container security with entitlements|entitlements]] (to be published)
+
 This is a rant I wrote while attending [KubeCon Europe 2018](https://kccnceu18.sched.com/). I do
 not know how else to frame this deep discomfort I have with the way
 one of the most cutting edge projects in my community is moving. I see
diff --git a/blog/2018-05-29-autoscaling-kubernetes.mdwn b/blog/2018-05-29-autoscaling-kubernetes.mdwn
index 3d600230..b380e51e 100644
--- a/blog/2018-05-29-autoscaling-kubernetes.mdwn
+++ b/blog/2018-05-29-autoscaling-kubernetes.mdwn
@@ -3,6 +3,14 @@
 [[!meta date="2018-05-14T00:00:00+0000"]]
 [[!meta updated="2018-05-29T09:42:21-0400"]]
 
+> This article is part of a series on KubeCon Europe 2018.
+>
+> * [[Diversity, education, privilege and ethics in technology|2018-05-25-kubecon-rant]]
+> * [[Autoscaling for Kubernetes workloads|2018-05-29-autoscaling-kubernetes]] (this article)
+> * [[Updates in container isolation|2018-05-29-secure-pods]] (to be published)
+> * [[Securing the container image supply chain|image-security]] (to be published)
+> * [[Easier container security with entitlements|entitlements]] (to be published)
+
 [[!toc levels=2]]
 
 Technologies like containers, clusters, and Kubernetes offer the
@@ -254,9 +262,6 @@ dive](https://kccnceu18.sched.com/event/DroC/sig-autoscaling-deep-dive-marcin-wi
 be interesting to our readers who want all the gory details about
 Kubernetes autoscaling.
 
-\[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting
-my travel to the event.\]
-
 ------------------------------------------------------------------------
 
 
@@ -266,4 +271,4 @@ my travel to the event.\]
 [first appeared]: https://lwn.net/Articles/754153/
 [Linux Weekly News]: http://lwn.net/
 
-[[!tag debian-planet lwn]]
+[[!tag debian-planet lwn kubernetes containers prometheus]]

proper name
diff --git a/blog/autoscaling.mdwn b/blog/2018-05-29-autoscaling-kubernetes.mdwn
similarity index 100%
rename from blog/autoscaling.mdwn
rename to blog/2018-05-29-autoscaling-kubernetes.mdwn

article public
diff --git a/blog/autoscaling.mdwn b/blog/autoscaling.mdwn
index 68e53dd1..3d600230 100644
--- a/blog/autoscaling.mdwn
+++ b/blog/autoscaling.mdwn
@@ -1,9 +1,7 @@
 [[!meta title="Autoscaling for Kubernetes workloads"]]
-\[LWN subscriber-only content\]
--------------------------------
 
-[[!meta date="2018-05-10T00:00:00+0000"]]
-[[!meta updated="2018-05-10T13:17:48-0400"]]
+[[!meta date="2018-05-14T00:00:00+0000"]]
+[[!meta updated="2018-05-29T09:42:21-0400"]]
 
 [[!toc levels=2]]
 

Added a comment: Je partage !
diff --git a/blog/2018-05-26-kubecon-rant/comment_4_57d25a96bec21e5e061eff311aaea941._comment b/blog/2018-05-26-kubecon-rant/comment_4_57d25a96bec21e5e061eff311aaea941._comment
new file mode 100644
index 00000000..e39dc785
--- /dev/null
+++ b/blog/2018-05-26-kubecon-rant/comment_4_57d25a96bec21e5e061eff311aaea941._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ ip="132.208.1.8"
+ claimedauthor="Thomas"
+ subject="Je partage !"
+ date="2018-05-28T14:20:36Z"
+ content="""
+Très bon article que je vais partager dans mon réseau de ce pas. Je trouve aussi que l'équilibre entre certaines valeurs (qui me touchent), l’innovation, le code ouvert, notre passion technologique, l'argent des géant américain etc est dur à trouver. Merci.
+"""]]

Added a comment: learning sysadm and moving fast
diff --git a/blog/2018-05-26-kubecon-rant/comment_3_667104772a99366e59ec1423512205d4._comment b/blog/2018-05-26-kubecon-rant/comment_3_667104772a99366e59ec1423512205d4._comment
new file mode 100644
index 00000000..7e2fe7df
--- /dev/null
+++ b/blog/2018-05-26-kubecon-rant/comment_3_667104772a99366e59ec1423512205d4._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ ip="65.103.205.222"
+ claimedauthor="der.hans"
+ subject="learning sysadm and moving fast"
+ date="2018-05-28T02:41:35Z"
+ content="""
+> There is basically no sysadmin education curriculum right now. Sure you can follow a Cisco CCNA or MSCE private trainings. But anyone who's been seriously involved in running any computing infrastructure knows those are a scam: that will tie you down in a proprietary universe (Cisco and Microsoft, respectively) and probably just to \"remote hands monkey\" positions and rarely to executive positions.
+
+Community colleges in Arizona and California do teach system administration. Arizona has had an associates degree in Linux system administration for over a decade. While the program I taught in is an offshoot to Cisco Networking Academy classes, Cisco did not provide any educational resources for the GNU/Linux classes. ( Full disclosure: I did not realize when I started teaching part-time that the GNU/Linux classes were part of a Cisco Networking Academy and my day job was as a database developer for the non-profit behind the academies )
+
+ I was an instructor for many years and many of my degree students are doing well in system administration.
+
+In regards to \"move fast and break things\", Friday Cory Doctorow recommended we should instead \"Be thoughtful and consider human circumstances\" during a panel at Phoenix Comic Fest
+"""]]

align the borg to the right
diff --git a/blog/2018-05-26-kubecon-rant.mdwn b/blog/2018-05-26-kubecon-rant.mdwn
index bb2a351e..ea6dce56 100644
--- a/blog/2018-05-26-kubecon-rant.mdwn
+++ b/blog/2018-05-26-kubecon-rant.mdwn
@@ -214,7 +214,7 @@ resistance truly is futile, the ultimate neo-colonial scheme.
  [this one]: https://en.wikipedia.org/wiki/SKYNET_(surveillance_program)
  [that one]: https://en.wikipedia.org/wiki/Skynet_(satellite)
 
-<figure>
+<figure class="align-right">
 <a href="https://en.wikipedia.org/wiki/File:Picard_as_Locutus.jpg">
 <img
 src="https://upload.wikimedia.org/wikipedia/en/a/a1/Picard_as_Locutus.jpg"

Added a comment: feedback, related articles
diff --git a/blog/2018-05-26-kubecon-rant/comment_2_1613cbb720aaeb165b2d4b6e0f57d477._comment b/blog/2018-05-26-kubecon-rant/comment_2_1613cbb720aaeb165b2d4b6e0f57d477._comment
new file mode 100644
index 00000000..6fa945b8
--- /dev/null
+++ b/blog/2018-05-26-kubecon-rant/comment_2_1613cbb720aaeb165b2d4b6e0f57d477._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="https://seccdn.libravatar.org/avatar/741655483dd8a0b4df28fb3dedfa7e4c"
+ subject="feedback, related articles"
+ date="2018-05-27T11:38:30Z"
+ content="""
+A friend referred to an article from The Atlantic, [The 9.9 Percent Is the New American Aristocracy](https://www.theatlantic.com/amp/article/559130/) that goes much deeper in some of the causes of my discomfort:
+
+>  We are not innocent bystanders to the growing concentration of wealth in our time. We are the principal accomplices in a process that is slowly strangling the economy, destabilizing American politics, and eroding democracy. Our delusions of merit now prevent us from recognizing the nature of the problem that our emergence as a class represents. We tend to think that the victims of our success are just the people excluded from the club. But history shows quite clearly that, in the kind of game we’re playing, everybody loses badly in the end.
+
+Also, I want to thank everyone for the excellent feedback that was provided and, incidentally, mention that the space here is *not* a free-for-all, totally free speech zone. This is my blog and I decide which comments get published. I fully reserve the right to remove trollish comments and I have very little tolerance for those these days. You have the [right to free speech in your own spaces](https://xkcd.com/1357/), but here should be a safe space for everyone, and that does mean I may err on the side of censorship. Sorry to bring this up, but I already had to remove one such comment and wish to avoid any sort of escalation.
+"""]]

removed
diff --git a/blog/2018-05-26-kubecon-rant/comment_1_43bd3be6bdab38fa8784ecbcdf83fb6f._comment b/blog/2018-05-26-kubecon-rant/comment_1_43bd3be6bdab38fa8784ecbcdf83fb6f._comment
deleted file mode 100644
index 335b456f..00000000
--- a/blog/2018-05-26-kubecon-rant/comment_1_43bd3be6bdab38fa8784ecbcdf83fb6f._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- ip="82.8.134.118"
- subject="Yes!"
- date="2018-05-27T08:10:07Z"
- content="""
-
-We should be forcing girls to do technology and STEM subjects at school. 
-
-Also, ban all forms of \"girly\" TV cartoons and all any makeup or fashion advice.  Make them watch Star Trek and play D&D.
-
-We can fix women to be what we want them to be!
-"""]]

Added a comment
diff --git a/blog/2018-05-26-kubecon-rant/comment_2_ae0ae1a3f81688416173d8b0261edbe5._comment b/blog/2018-05-26-kubecon-rant/comment_2_ae0ae1a3f81688416173d8b0261edbe5._comment
new file mode 100644
index 00000000..7c817b51
--- /dev/null
+++ b/blog/2018-05-26-kubecon-rant/comment_2_ae0ae1a3f81688416173d8b0261edbe5._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="80.110.92.125"
+ claimedauthor="Manu"
+ subject="comment 2"
+ date="2018-05-27T08:46:33Z"
+ content="""
+Thank you for putting this conference in a higher perspective.
+Yes the social context of what software production does matter.
+"""]]

Added a comment: Yes!
diff --git a/blog/2018-05-26-kubecon-rant/comment_1_43bd3be6bdab38fa8784ecbcdf83fb6f._comment b/blog/2018-05-26-kubecon-rant/comment_1_43bd3be6bdab38fa8784ecbcdf83fb6f._comment
new file mode 100644
index 00000000..335b456f
--- /dev/null
+++ b/blog/2018-05-26-kubecon-rant/comment_1_43bd3be6bdab38fa8784ecbcdf83fb6f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ ip="82.8.134.118"
+ subject="Yes!"
+ date="2018-05-27T08:10:07Z"
+ content="""
+
+We should be forcing girls to do technology and STEM subjects at school. 
+
+Also, ban all forms of \"girly\" TV cartoons and all any makeup or fashion advice.  Make them watch Star Trek and play D&D.
+
+We can fix women to be what we want them to be!
+"""]]

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 .