Fiducia Gocciolabile - Own composition - Piano

Unknown — Sat, 02 Aug 2025 18:23:55 +0200

Fiducia Consolabile</h1>
This is my own composition. Licensed under the Creative Commons Attribution ShareAlike license (CC-BY-SA).
</iframe> </div>
A pure audio-only version is available here</a>.

Text processing on the Command Line - sharing my tools

Unknown — Sun, 07 Jul 2024 13:48:28 +0200

Introduction</h2>
I'm quite fond of the command-line and spend a larger chunk of my life in a terminal emulator than I dare admit. I try to embrace the unix philosophy of using tools that "do one thing only, and do it well" and "interconnect largely via plain text formats". Following this philosophy, the output of one program can typically be the input to the next, for instance through the pipe operator (`|</code>) in a command-line shell.`
`Chaining multiple heterogeneous tools in this way gives a great amount of power and flexibility, something that's much harder to achieve through complex monolithic GUIs. It allows to quickly automate things in shell scripts and do batch processing, even if the underlying tools are written in different languages.`
`For text processing and data science, the unix shell and environment kind of form the lingua franca of data science; a common foundation upon which we can build our data processing pipelines. This environment is usually a unix-like system such as Linux or macOS that offers a (POSIX-compliant) shell like bash and a set of core utilities such as provided by``GNU coreutils</a> and friends, by FreeBSD/OpenBSD/NetBSD/macOS itself or by busybox</a>. All of these are different implementations of the same core utilities, but following some standard specification (POSIX</a>). Even Windows users have access to such a command-line environment via the WSL</a>, or alternatively via Cygwin</a>.`
`I'll first mention some of these standard unix tools, then some additional tools, and finally I'll move on to what is the main subject of this writing: my tools</a>; the text processing tools for the command-line which I myself developed (or co-developed) and want to share with you.`

Basic standard tools</h2> Out of the box, a unix environment usually gives you text processing tools like: awk</code> - pattern scanning and processing language</li> cat</code> - print or concatenate text (or tac</code> to do it in reverse)</li> cut</code> - extract/remove columns from lines</li> column</code> - format input into multiple columns</li> colrm</code> - remove columns from a file</li> comm</code> - compare two sorted files line by line</li> dos2unix</code> - convert DOS/Windows line endings to UNIX (\r\n</code> -> \n</code>)</li> diff</code> - compare files line by line and show where they differ</li> echo</code>/printf</code> - print text</li> expand</code> - convert tabs to spaces</li> fold</code> - wrap each input line to fit in a specified width</li> head</code>/tail</code> - extract the first/last lines of a text</li> grep</code> - print lines that match patterns (regular expressions)</li> nl</code> - assign numbers to lines in a file</li> paste</code> - merge lines from multiple files into one</li> rev</code> - reverse lines character-wise</li> tr</code> - translate or delete characters (here translation is just a mapping between character, not between natural languages)</li> sed</code> - stream editor for filtering and transforming text</li> shuf</code> - shuffle lines in a random order</li> split</code> - split a file into several equally-sized pieces</li> sort</code> - sort lines</li> uniq</code> - remove duplicate lines</li> wc</code> - word count, line count, byte count</li> </ul> They shine when used together. Take the example of having a plain text file, and wanting to extract a top 1000 frequency list of the words in it, all lower-cased. All this can be captured in the following one-liner: $ sed -E 's/\W+/\n/g' text.txt | tr '[:upper:]' '[:lower:]' | tr -s '\n' | sort | uniq -c | sort -rn | head -n 1000</code></pre> An analysis of the many possibilities of these common unix tools for text processing and data analysis is well out of scope for this writing. I do not intend to write a tutorial here. If you are interested in such a thing, I can warmly recommend the O'Reilly book Data Science at the Command Line</a> by Jeroen Janssens, freely accessible on-line. It also covers some of the tools I mention in the next section, and more. Common additional tools</h2> In addition to these standard unix tools that are often part of the core system, there are more specialised tools I can recommend for text & data processing. The following few work with structured data like JSON, CSV or XML and overlap partially in functionality: jq</code></a> - like sed</code> but specifically for extracting and manipulating JSON data, written in C.</li> Miller</a> - mlr</code> - like awk, sed, cut, join, and sort for name-indexed data such as CSV and tabular JSON. Written in Go.</li> xsv</a> - CSV command line toolkit, written in Rust.</li> dasel</code></a> - to query and modify JSON/CSV/YAML/XML , written in Go.</li> csvkit</a> - suite of utilities for working with CSV (csvlook</code>, csvcut</code>, csvgrep</code>,csvjson</code>, csvsql</code>, csvstat</code>), written in Python.</li> xmllint</code> in libxml2</a> - to validate and query XML files (xpath), written in C.</li> </ul> For visualisation purposes, I first have to give an honourable mention to less</code> and more</code>, both of which do more or less the same (pun intended). They serve as the so-called pager. For a richer experience, I can recommend the following: bat</code></a> - a cat</code> clone and/or less</code> alternative with fancy features like syntax highlighting; great for viewer all kinds of files, written in Rust.</li> glow</code></a> - a Markdown viewer, written in Go.</li> csvlook</code> from csvkit</a> - viewer for CSV files, written in Python.</li> </ul> When it comes to conversion of texts, I recommend the following: pandoc</code></a> - A universal document converter. Converts between many document formats such as LaTeX/Markdown/ReStructuredText/plain text/Asciidoc/Word/Epub/Roff/etc... Written in Haskell.</li> iconv</code> - convert plain text from one character encoding to another. Written in C.</li> uconv</code> from icu</a> - convert plain text from one character encoding to another. Written in C.</li> </ul> To combine these and all kinds of other data processing tools into larger automated pipelines, the most basic solution is to write a shell script. Alternatively, you can write a Makefile</code> that builds targets using make</code></a>. The latter also offers a certain degree of parallelisation using the -j</code> parameter. Another useful tool to consider for parallelisation is parallel</code></a> and/or xargs</code> with the -P</code> parameter. The latter, xargs</code>, is also a basic standard tool useful when building sequential pipelines. Remembering how to invoke all these command line tools may be rather daunting, and nobody expects you to remember everything anyway. Of course, a manual page should be available by simply running man</code> followed by the command you need help on. You should also be able to get usage information from the tool itself by passing -h</code> and/or --help</code>. If you're lazy like me and prefer to quickly get some very short concise usage examples for a number of common use cases for a tool, then I can recommend tldr</code></a> (internet slang for "too long; didn't read"). Intermezzo: What about Python/Julia/R etc...?</h2> Bear with me before I finally get to show you my own tools. At this point some readers may wonder: All this command-line stuff is fine, but why not just use Python, or R, or Julia or whatever other open-source language implementation you prefer? (this excludes proprietary ecosystems like Matlab and Wolfram which I explicitly condemn). Languages like Python/Julia/R come with a solid standard library and on top of that a wide range of third party libraries to accommodate all kinds of text processing needs or whatever else a data scientist might desire. Furthermore, they too come with an interactive shell or can be used in the web-browser in the form of Notebooks (Jupyter</a>/Pluto</a>/RStudio</a>), Some may find the latter more appealing than a terminal, especially for data stories and teaching. Indeed, I say in response, these are all perfectly fine solutions and great projects. Such language ecosystems tend to give you tighter coupling between components and cleaner abstraction than the unix shell can. The shell often has more archaic syntax and interoperability is not always optimal because each tool can be very different. The shell, however, does provide a kind of lowest-common denominator that no other can. It offers a great deal of flexibility with regards to the tools you use. It's been around for decades and likely will last a while longer. Whether your command-line interface is written in C, C++, Rust, Go, Zig, Hare, R, Python, Perl, Haskell, Lisp, Scheme, or God forbid, even Java, it can all be readily mixed. Just by virtue of having a command line interface and reading either from file or standard input, and outputting to file or standard output. Committing yourself to a higher-level language, on the other hand, adds an extra layer, often in the form of a high-level language interpreter which has its own overhead and limits certain choices. This has both benefits and drawbacks. The trade-off is often between diversity and uniformity. This is not a question of one method being inherently superior to the other, it all depends on your use case, the complexity thereof, the technologies you and those working with you are familiar and comfortable with, and your intended audience; the users. You then choose the form of interface that fits these conditions best; whether it is invoking tools via command-line interfaces, calling functions in software libraries via an API, or WebAPI, or even clicking buttons in GUIs. My tools</h2> In this writing, I would like to introduce some of the tools I wrote over the years for text processing, often in line of my work. As mentioned in the introduction, these tools are largely specialised in doing one thing, and doing it well, as per the unix philosophy. As the years go by, I'm more and more drawn to simpler solutions, where simple entails: keeping the scope of a tool limited, constraining the amount of features</li> keeping a codebase maintainable by not letting it grow too large</li> limiting the number of dependencies (and in doing so limiting security vulnerabilities as well)</li> getting the job done with optimal performance, reducing the amount of unnecessary overhead.</li> </ul> Rust</a> is my language of choice nowadays, as it compiles to highly performant native code on a variety of platforms and processor architectures. It offers important safety guarantees that prevents a whole range of common memory bugs that are prevalent in other system's programming languages as C and C++. You will therefore find a lot of my tools are written in Rust, often with a Python binding on top for accessibility for researchers and developers from Python. All software I write is free open source software available, almost always under the GNU General Public License v3. I will be listing the tools in approximate order from simpler to more complex tools: charfreq</code></a> - Tiny tool that just counts unicode character frequencies from text it receives on standard input.</li> hyphertool</code></a> - Hyphenation tool, performs wordwrap at morphologically sensible places for a number of languages.</li> ssam</code></a> - Split sampler to draw train/development/test samples from plain text data using random sampling.</li> lingua-cli</code></a> - Language Detection</li> sesdiff</code></a> - Computes a Shortest Edit Script that shows the difference between two strings on a character-level</li> lexmatch</code></a> - Matching texts against one or more lexicons</li> </ul> The above tools were all fairly small, now we're moving on to bigger software projects, mostly developed in the scope of my work at the KNAW Humanities Cluster and Radboud University Nijmegen, often under the umbrella of the CLARIN-NL and CLARIAH projects. stam</code></a> - Toolkit for stand-off annotation on text</li> ucto</code></a> - Unicode tokeniser</li> frog</code></a> - NLP suite for Dutch</li> analiticcl</code></a> - Fuzzy string-matching system used e.g. for spelling correction, text normalisation or post-OCR correction.</li> colibri-core</code></a> - Efficient pattern extraction (n-grams/skipgrams/flexgrams) and modelling from text.</li> folia-tools</code></a> - Toolkit for working with the FoLiA XML format</a>.</li> </ul> Last, a small tool that is a bit of an odd-one-out in this list, but which I wanted to include anyway: vocage</code></a> - Vocabulary training with flashcards (spaced-repetition system aka Leitner)</li> </ul> I'll briefly discuss each of the mentioned programs. Click the above links to quickly jump to the relevant section. charfreq</h3> charfreq</code> is a very simple tiny CLI tool that just computes (unicode) character frequencies from text received via standard input. Written in Rust. You can find charfreq</code> on Sourcehut</a> or Github</a>. hyphertool</h3> hyphertool</code> does hyphenation and builds upon the third party hypher</a> library, which in turn uses rules from the TeX hyphenation library. It is written in Rust. $ hyphertool --language nl --width 15 test.txt Dit is een test- bestand. Kan je dit bestand mooi voor mij verwer- ken? Ik hoop op een positief re- sultaat.</code></pre> It can also also output all syllables using hyphenation rules: $ hyphertool --language nl test.txt Dit is een test-be-stand. Kan je dit be-stand mooi voor mij ver-wer-ken? Ik hoop op een po-si-tief re-sul-taat.</code></pre> Or with character offsets: $ hyphertool --language nl --standoff test.txt Text BeginOffset EndOffset ... Ik 68 70 hoop 71 75 op 76 78 een 79 82 po 83 85 si 85 87 tief 87 91 re 92 94 sul 94 97 taat 97 101</code></pre> For more information, see hyphertool</code> on Codeberg</a>, Sourcehut</a>, Github</a> or Crates.io</a>. ssam</h3> I wrote ssam</a>, short for Split sampler, as a simple program that splits one or more text-based input files into multiple sets using random sampling. This is useful for splitting data into a training, test and development sets, or whatever sets you desire. This software was written in Rust. It works nicely with multiple files when entries one the same lines correspond (such as sentence-aligned parallel corpora). Suppose you a sentences.txt</code> and a sätze.txt</code> with the same sentences in German (i.e. the same line numbers correspond and contain translations). You can then make a dependent split as follows: $ ssam --shuffle --sizes "0.1,0.1,*" --names "test,dev,train" sentences.txt sätze.txt</code></pre> For more information, see ssam</code> on Codeberg</a>, Sourcehut</a>, Github</a> or Crates.io</a>. sesdiff</h3> sesdiff</code> is a small and fast command-line tool and Rust library that reads a two-column tab separated input from standard input and computes the shortest edit script (Myers' diff algorithm) to go from the string in column A to the string in column B. In other words, it computes how strings difer. It also computes the edit distance (aka levenshtein distance). It builds upon the dissimilar</a> library by David Tolnay for the bulk of the computations. $ sesdiff < input.tsv hablaron hablar =[hablar]-[on] 2 contaron contar =[contar]-[on] 2 pidieron pedir =[p]-[i]+[e]=[di]-[eron]+[r] 6 говорим говорить =[говори]-[м]+[ть] 3</code></pre> The output is in a four-column tab separated format (reformatted for legibility here, the first two columns correspond to the input). It can also do the reverse, given a word and a edit recipe, compute the other string. It was initially designed to compute training data for a lemmatiser. For more information, see sesdiff</code> on Codeberg</a>, Sourcehut</a>, Github</a> or Crates.io</a>. lingua-cli</h3> lingua-cli</code> is a command-line tool for language detection. Given a text, it will predict what language a text is in. It supports many languages. It can also predict per line of the input, as the underlying algorithm is particularly suited to deal with shorter text, or it can actively search the text for languages and return offsets. This program is a mostly a wrapper around the lingua-rs</a> library by Peter M. Stahl. It is written in Rust. The 3rd party library is also available for python</a>, go</a>, and Javascript via WASM</a>. $ echo -e "bonjour à tous\nhola a todos\nhallo allemaal" | lingua-cli --per-line --languages "fr,de,es,nl,en" fr 0.9069164472389637 bonjour à tous es 0.918273871035807 hola a todos nl 0.988293648761749 hallo allemaal</code></pre> Output is TSV and consists of an iso-639-1 language code, confidence score, and in line-by-line mode, a copy of the line. In --multi</code> mode, it will detect languages in running text and return UTF-8 byte offsets: $ lingua-cli --multi --languages fr,de,en < /tmp/test.txt 0 23 fr Parlez-vous français? 23 73 de Ich spreche ein bisschen spreche Französisch ja. 73 110 en A little bit is better than nothing.</code></pre> For more information, see lingua-cli</code> on Codeberg</a>, Sourcehut</a>, Github</a> or Crates.io</a>. lexmatch</h3> lexmatch</code> is a simple lexicon matching tool that, given a lexicon of words or phrases, identifies all matches in a given target text, returning their exact positions. It can be used compute a frequency list for a lexicon, on a target corpus. The implementation uses either suffix arrays or hash tables. The lexicon is in the form of one word or phrase per line. Multiple lexicons are supported. It is written in Rust. $ lexmatch --lexicon lexicon.lst corpus.txt</code></pre> Rather than take a lexicon, you can also directly supply lexical entries (words/phrases) on the command line using --query</code>: $ lexmatch --query good --query bad /nettmp/republic.short.txt Reading text from /tmp/republic.short.txt... Building suffix array (this may take a while)... Searching... good 4 193 3307 3480 278 bad 3 201 3315 3488</code></pre> By default, you get a TSV file with a column for the text, the occurrence count, and one with the begin position (UTF-8 byte position) for each match (dynamic columns). In --verbose</code> both you get cleaner TSV with separate UTF-8 byte offsets for each match: $ lexmatch --verbose --query good --query bad /nettmp/republic.short.txt Text BeginUtf8Offset EndUtf8Offset Reading text from /tmp/republic.short.txt... Building suffix array (this may take a while)... Searching... good 193 197 good 3307 3311 good 3480 3484 good 278 282 bad 201 204 bad 3315 3318 bad 3488 3491</code></pre> For more information, see lexmatch</code> on Codeberg</a>, Sourcehut</a>, Github</a> or Crates.io</a>. stam</h3> STAM Tools</a> is a collection of command-line programs for working with stand-off annotations on plain text. These all make use of the STAM</a> data model and accompanying library</a> for representing annotations, which can also be exported as simple CSV or TSV. They are written in Rust. Each can be accessed through the executable stam</code> and a subcommand. I mention just a few for brevity: stam align</code> - Align two similar texts, mapping their coordinate spaces. This looks for similar strings in each text using the Needleman-Wunsch or Smith-Waterman algorithm.</li> stam fromxml</code> - Turn text and annotations from XML-based formats (like xHTML, TEI) into plain text with separate stand-off annotations following the STAM model. This effectively 'untangles' text and annotations.</li> stam query</code> or stam export</code> - Query an annotation store and export the output in tabular form to a simple TSV (Tab Separated Values) format. This is not lossless but provides a decent view on the data. It provides a lot of flexibility by allowing you to configure the output columns as you see fit.</li> stam validate</code> - Validate a STAM model, tests if all annotation offsets still point to the intended text selections.</li> stam tag</code> - Regular-expression based tagger on plain text, it also serves as a good tokeniser.</li> stam transpose</code> - Given an alignment between text (as computed by stam align</code>), converts annotations in one coordinate space to another.</li> stam view</code> - View annotations as queried by outputting to HTML (or ANSI coloured text).</li> </ul> A demo video is available that demonstrates all these and more: </a> See STAM</a> for more information about the data model and the general project, and stam-tools</a> for information specifically about these command-line tools. A python binding</a> is also available (pip install stam</code>). ucto</h3> Ucto</a> is a regular-expression based tokeniser. It comes with tokenisation rules for about a dozen languages. It is written in C++, initially by me but then in much larger part by my colleague Ko van der Sloot. </a> See the Ucto website</a> for more information. A Python binding is also available (pip install ucto</code>). frog</h3> Frog</a> is a tool that integrates various NLP modules for Dutch. Such as a tokeniser (ucto), part of speech tagger, lemmatiser, dependency parser, named-entity recogniser, dependency parser and more. It is written in C++ by Ko van der Sloot as lead developer, and by myself, Antal van den Bosch and in its initial stages Bertjan Busser. It has a long history containing various components that are also made possible by Walter Daelemans, Jakub Zavrel, Sabine Buchholz, Sander Canisius, Gert Durieux and Peter Berck. Though parts of the Frog have been superseded by more recent advancements in NLP, it is still a useful tool in many use-cases: </a> I also wrote a python binding</a> so you can use Frog directly from Python (pip install frog</code>). See the Frog website</a> for more information. analiticcl</h3> Analiticcl</a> is an approximate string matching system. It can be used for spelling correction or text normalisation and post-OCR correction. It does comparisons against one or more lexicons. This may sound similar to lexmatch</a> which I introduced earlier. However, analiticcl goes a lot further than lexmatch. It does not require exact matches with the lexicon but is designed to detect spelling variants, and to do so efficiently. It is written in Rust and builds upon earlier research by Martin Reynaert. $ analiticcl query --lexicon examples/eng.aspell.lexicon --alphabet examples/simple.alphabet.tsv --output-lexmatch --json < input.tsv > output.json</code></pre>[ { "input": "seperate", "variants": [ { "text": "separate", "score": 0.734375, "dist_score": 0.734375, "freq_score": 1, "lexicons": [ "examples/eng.aspell.lexicon" ] }, { "text": "desperate", "score": 0.6875, "dist_score": 0.6875, "freq_score": 1, "lexicons": [ "examples/eng.aspell.lexicon" ] }, { "text": "operate", "score": 0.6875, "dist_score": 0.6875, "freq_score": 1, "lexicons": [ "examples/eng.aspell.lexicon" ] }, { "text": "temperate", "score": 0.6875, "dist_score": 0.6875, "freq_score": 1, "lexicons": [ "examples/eng.aspell.lexicon" ] }, { "text": "serrate", "score": 0.65625, "dist_score": 0.65625, "freq_score": 1, "lexicons": [ "examples/eng.aspell.lexicon" ] }, { "text": "separated", "score": 0.609375, "dist_score": 0.609375, "freq_score": 1, "lexicons": [ "examples/eng.aspell.lexicon" ] }, { "text": "separates", "score": 0.609375, "dist_score": 0.609375, "freq_score": 1, "lexicons": [ "examples/eng.aspell.lexicon" ] } ] } ]</code></pre> </a> See the analiticcl source repository</a> for more information. A python binding is also available (pip install analiticcl</code>). colibri-core</h3> Colibri Core</a> is software to quickly and efficiently count and extract patterns from large corpus data, to extract various statistics on the extracted patterns, and to compute relations between the extracted patterns. The employed notion of pattern or construction encompasses ngrams, skipgrams and flexgrams (an abstract pattern with one or more gaps of variable-size). N-gram extraction may seem fairly trivial at first, with a few lines in your favourite scripting language, you can move a simple sliding window of size n over your corpus and store the results in some kind of hashmap. This trivial approach however makes an unnecessarily high demand on memory resources, this often becomes prohibitive if unleashed on large corpora. Colibri Core tries to minimise these space requirements. Colibri Core is written in C++, a python binding is also available. A demo video is available: </a> See the Colibri Core website</a> for more information. A journal article "Efficient n-gram, Skipgram and Flexgram modelling with colibri-core</a>" was published in the Journal of Open Research Software (2016), and was also included in my PhD dissertation. folia-tools</h3> FoLiA tools</a> is a set of numerous command-line tools I wrote for working with the FoLiA format. FoLiA</a> is an XML-based Format for Linguistic Annotation. It is written in Python (pip install folia-tools</code>). My colleague Ko van der Sloot wrote complementary C++ tooling to work with the same format, these are called foliautils</a>. Both contain a wide variety of programs such as validators, converters from and to other document and annotation formats (TEI, PageXML, Abby, plain text, ReStructuredText, CONLL, STAM) etc. vocage</h3> Vocage</a> may be a bit of an odd-one out in this list as it is not really a text processing tool as-such, but rather a TUI (Terminal User Interface) for studying language vocabulary (which still counts as text so is excuse enough for inclusion here). I wrote it in Rust. Vocage works by presenting flashcards using a spaced-repetition algorithm, which means it shows cards (e.g. words) you know well less frequently than cards you do not know yet. The difference with more common software like Anki</a> is that vocage is fully terminal-based, has vim keybindings, and it stores its data in a simple TSV format (both the wordlists as well as the learning progress go in the same TSV file). It was featured in a video by Brodie Robertson</a> in 2021. For more information, see vocage</code> on Codeberg</a>, Sourcehut</a>, Github</a> or Crates.io</a>. Conclusion</h3> I hope I have been able to convey some of my enthusiasm for the unix command-line for text processing and natural language processing. Moreover, I hope you find some of my software useful for some of your own projects. You can publicly comment on this post on the fediverse</a> (e.g. using mastodon).

Do not Restrict Me! How copy protection (DRM) on e-books harms our freedom and what to do about it

Unknown — Fri, 05 Jan 2024 20:39:34 +0100

Do not Restrict Me! How copy protection (DRM) on e-books harms our freedom and what to do about it</h1>

Part I: DRM Hell</h2>
Like many people, I like reading books. My favourite genre is science fiction, but I also like the occasional gay romance and I love to diversify by reading books in different languages. My home isn't too spacious, and with two completely filled-up bookcases there's little room left for more physical books, so I've hopped on the e-book bandwagon over a decade ago, I generally prefer things to be digital anyway. However, my love for all things digital is significantly dampened by the nastiness that is DRM (Digital Rights Management), the copy protection that encumbers the majority of e-books nowadays.

I've been using a Kobo Aura e-reader for a long time, Over the years, I have bought my fair share of books. Getting them from the Kobo store or the Dutch bol.com (which has some kind of partnership with Kobo) onto the reader was a breeze. Most consumers would be happy with such an experience, but for me there was always this nagging feeling that I was being locked into an ecosystem and never really own the books I bought.
What if my e-reader breaks? What if Kobo or Adobe goes bankrupt? Would I still have access to all the books I bought? All my physical books will still be there even in 50 years or so unless they befall to fire, burglary, rising sea levels, or paper-devouring bookworms. With my normal digital data, I take care to ensure similar longevity by making frequent backups and storing them in simple interoperable formats that pass the test of time (like plain text, HTML, etc). DRM encumbered data, however, is not normal digital data, it is encrypted data. You can't read it without having the proper key. Now data encryption as such is fine and something I'm a big proponent and heavy user of, but it stands or falls on who has ownership of the key! Spoiler alert, with DRM it's not you!

When it comes to e-books with DRM, books are typically encrypted with a key personalized for you, but you don't own the personalized key to decrypt your own books. Worse, the whole technology relies on obfuscation of this decryption key. The use of obfuscation in data security is flawed in principle, there will always be clever people capable of breaking it (this is also the case for DRM). DRM is a flawed technological solution for what is in fact a legal or socio-economic problem.
The legal issue is that of copyright, the author or publisher of a book has the exclusive right to sell copies of his/her own work, others are not permitted to do so. This sounds fair enough to me. The creator who created the work should be the one receiving the monetary gains from it, if he/she so desires. The challenge is, whereas a physical book needs to be printed and shipped to the customer, a digital resource copies effortlessly and can be sent all over the world in no time. This means there is no longer any significant scarcity involved in the distribution process from which value can be derived.
Those who enforce DRM upon us attempt to keep an old business model alive where distribution was coupled to creation and tightly controlled, but this no longer works. The only way to do so in a digital age is to place ever-further restrictions on the user. When you watch a movie in a movie theatre, as opposed to from your own home, you are in a fairly tightly controlled environment. You play by the rules of the theatre and you pay essentially for a (single) viewing experience. DRM software does something similar, it builds a tightly controlled virtual theatre for you within the constraints of which you are allowed to do your viewing. It never really works though, everything that you see on your screen or hear from your speakers can in principle be copied. As cumbersome as it might be, it's theoretically possible to make photographs of pages of your DRM-protected book on your e-reader and then have the text extracted via OCR (optical character recognition), or to record an audio/video stream with a microphone and camera. In a real movie theatre there are rules against this: you're under some form of surveillance, you'll probably be be kicked out if you start recording the movie from your smartphone. In the software theatres that DRM forces you into, you're under an ever-encroaching kind of surveillance too and you are shipped a crippled product that is defective by design</a>. The core tenet is: the user/consumer can not be trusted and the rights of the producer outweigh the rights of the consumer.
The use of DRM means that only software that implements proprietary DRM technology like Adobe DRM, can decrypt the book on your behalf and show it. This is also how e-readers do it. Such software is, probably by contract with the supplier of the DRM technology, bound to all kinds of restrictions designed to keep the actual data as far away from the user as possible. Such software is by definition fundamentally incompatible with the free and open source software that I cherish and choose to use. DRM relies on obfuscation, openness and freedom is its anti-thesis, DRM requires proprietary software libraries that usually come with a licensing fee to be paid by whoever builds the viewer software to the DRM technology supplier. DRM in itself is an industry, and whereas supporting the authors that write the books I love is something I whole- heartedly support, a major share of the profit ends up not with the author but with publishers and platforms whose practises I do oppose.
More and more, our devices impact our privacy and monitor how we use them. Knowing exactly what books we read (or what music we listen, videos we watch) is a treasure trove for parties like Amazon, Google, Apple, Kobo, etc.. because it allows them to 1) recommend and sell more similar books to us and 2) build up a profile of our interests which has value (= can be sold) to anyone who wants to target us with advertisements.
In democratic societies we tend to value freedom of opinion, without it our democratic societies could not exist. The books we read, the information we consume, are pivotal in a free society and says a lot about us. It may also divulge a lot about us to potential adversaries (political or otherwise). It is not a coincidence that dictatorships often start with book bannings and burnings. I therefore think it is fundamentally important that information on our reading habits and media consumption in general is not collected by any one or few major players, be it companies or governments. The potential for abuse is just too great.

Technologies like DRM, aside from being technically flawed in principle, also provide the wrong incentives, they hinder interoperability and lead to the emergence of one or a few centralised solutions. Those who control these solutions then sit on a treasure trove of potential data that is just waiting to be exploited. They also hinder any alternative legitimate use I might have on the books I buy, say I want to do scientific research by doing some kind of statistical analysis on the text, or some kind of annotation on the text. I am a research software developer developing precisely such (open) software. But all of this is not possible on DRM encumbered e-books as the actual text is being deliberately kept as far away from me as possible!
Likewise, I can't just build an open e-reader software myself, say based on postmarketOS</a> and SXMO</a>, both of which have been successfully tried on a Kobo Clara HD</a>, because it would not be able to open anything touched by DRM, making it pretty useless for the average consumer. I'd be very interested in trying if I can get something like this working on my Kobo Aura and read my books using our own Sxmo system! Or what if I wanted to build a search index to search in the text of all the books I own? If it were not for DRM, I could easily build this, but DRM makes me reliant on third-party proprietary software. Normal competition is stifled as the DRM provider acts as a gatekeeper that demands the user can only access a crippled defective version of the actual product.

Part II: Do not Restrict me!</h2>

I'm writing all of this because my Kobo reader has been having some difficulties lately so I decided to look for a replacement. This opened the gates to the DRM hell I depicted above.
Being aware of the ecosystem I was being locked into, I decided this was a good moment to break with it and opt for more freedom and sustainability. I chose a Pocketbook e-reader (the PocketBook Inkpad Color 3 to be precise) as this brand seems to be one of the few e-readers that isn't as tied to a store as for example Amazon Kindles (they are the worst) or, to lesser extend, Kobo devices are. It's a device that can still be fully used without requiring you to log in with some kind of cloud account. The exception being of course DRM, the device supports Adobe's DRM technology and you need an Adobe ID if you want to be able to read books tainted by it. I reluctantly registered such an account.
So how do I transfer the DRM books I have on my old Kobo to my new Pocketbook? I can't grab the EPUB files from the Kobo because they'd be encrypted specifically for that device using Kobo's own DRM scheme. Stores like Kobo and bol.com have a download option. This suggests you can download the e-books but in fact, in case of Adobe DRM encumbered e-books you don't even get the encrypted EPUB files, but you get so-called ACSM files (Adobe Content Server Message) instead. These are not the actual book but is merely a receipt that a client can in turn send to Adobe's server to obtain the (encrypted) book. The message contains information such as your personal UUID and Adobe account details.
My PocketBook e-reader is supposed to support these ACSM files and obtain the encrypted DRM-encumbered books for me. This would be the obvious route for the normal user. However, it didn't work for some unknown reason: I got a cryptic `E_ADEPT_NO_FULFILLMENT_RESULT</code> error when trying to open the ACSM files directly on my new reader. This shows that the technology is fragile and that if things break, there's not much you can do. For any normal non-technical user things would have already gotten too difficult by now.`
`Fortunately I'm not a non-technical user and I don't give up easily, my next try was to go via a program called "Adobe Digital Editions", this is proprietary software that can read these ACSM files and obtains the encrypted EPUB file for you. Both in this program as well as on the device, I register the same Adobe ID, and then the encrypted EPUB files this program downlods can be transferred and decrypted/displayed by the e-reader.`
`A major caveat is that Adobe Digital Editions is proprietary software that is available (free of charge), but only for Windows or macOS, or for Android or iOS nowadays as well. But I have none of those systems nor intend to buy any of them just so I can access my books! As a FOSS enthusiast I run on Linux systems exclusively.`
`There's a solution though, I (again, reluctantly) installed` `Adobe Digital Editions 4.5</a> via Wine</a> on my Arch Linux system. I'll guide you to the steps in case anybody finds themselves in a similar conundrum:`
On Arch Linux, first enable multilib</a> so you can install 32-bit software like Wine on a 64-bit system.</li> Then install wine and various dependencies you might need: pacman -Syu wine winetricks wine-mono lib32-gnutls samba</code></li> Set a new WINEPREFIX</code> and WINEARCH</code>: export WINEPREFIX=~/.adewine/ WINEARCH=win32</code></li> Create the WINEPREFIX</code>: winecfg</code></li> Install Adobe Digital Editions 4.5 via winetricks: winetricks -q adobe_dige4</code></li> Start Adobe Digital Editions: WINEPREFIX=~/.adewine WINEARCH=win32 wine $WINEPREFIX/drive_c/Program\ Files/Adobe/Adobe\ Digital\ Editions\ 4.5/DigitalEditions.exe</code></li> Register your Adobe ID in the program.</li> </ol> If that is all done, you can now import ACSM files in Adobe Digital Editions. It will use the query the Adobe server to obtain the actual encrypted book and puts encrypted EPUB or PDF files in a directory My Digital Editions</code> in C:\users\$USERNAME\Documents\</code>. If you are lucky this is already mapped to your ~/Documents</code>. These you can transfer to your e-reader. You can also let Adobe Digital Editions transfer things to your e-reader but I didn't try that as I prefer to let it do as little as possible and didn't want to go into the hassle of getting a USB device accessible via wine. At this point I finally managed to get my encrypted books onto the e-reader and the e-reader actually manages to open them. But... the books are still tainted by DRM which is not what I want. As DRM is a flawed technology to begin with, it should not be surprising that it has been reverse engineered and broken. For Adobe ADEPT DRM this was initially published back in 2009 by a user under the pseudonym i♥cabbages</a>. This software has been integrated into DeDRM-tools</a>, which is a plugin for the open source e-book management software Calibre</a>. On Arch Linux, install calibre with pacman -Syu calibre</code> and install the plugin from the Arch User Repository with yay -S calibre-plugin-dedrm</code> (or whatever other AUR helper you use). I recommend you launch calibre</code> from a terminal so you can see its standard error output. If Adobe Digital Editions is installed and you now import a DRM-protected EPUB, i.e. the ones you got from Adobe Digital Editions, the DeDRM plugin will automatically extract the encryption key from the Adobe Digital Editions installation and subsequently decrypt the book. The resulting EPUB will finally be a normal one which you can read anywhere. The caveat again is that this a bit tricky to get working since we run Adobe Digital Editions in Wine. In the Calibre plugin settings for DeDRM tools, you need to explicitly set the wine prefix to ~/.adewine</code>. Moreover, the DeDRM scripts are written in Python and some of them will have to run inside Wine, so we need a Python installation in our WINEPREFIX, I installed one as follows: Grab a 32-bit Windows installer version of Python 3: wget https://www.python.org/ftp/python/3.7.8/python-3.7.8.exe</code></li> Run the installer WINEPREFIX=~/.adewine WINEARCH=win32 wine python-3.7.8.exe</code>.</li> Install the required cryptography module for Python: WINEPREFIX=~/.adewine WINEARCH=win32 wine ~/.adewine/drive_c/users/$USER/AppData/Local/Programs/Python/Python37-32/python.exe -m pip install pycryptodome</code></li> Launch calibre</code>, (make sure to set the wine prefix in the plugin configuration screen for DeDRM-tools), then import your DRM EPUBs.</li> The resulting EPUBs in your Calibre Library directory will now be fully decrypted, i.e. not tainted by DRM. You can transfer them to your e-reader or open them with any normal EPUB viewer anywhere!</li> Make sure to export your extracted key from Calibre's plugin configuration screen for DeDRM-tools. This will be produce a der</code> file. It ensures that even if Adobe at some point changes their obfuscation algorithm so key extraction no longer works, you still have the decrypted key and can import it back.</li> </ol> When removing DRM you must of course take care not to redistribute/share the resulting files, that would be a clear violation of copyright law anywhere. I explicitly do NOT advocate for NOR encourage you to violate such laws, I merely advocate for software freedom, proper interoperability, long term sustainability, consumer privacy and freedom from surveillance. I argue against DRM technology because it is is detrimental to all those things and technologically faulty by design because it relies on obfuscation. As to the legality of removing DRM from your own e-books without redistributing them, I am by no means a lawyer, but you can read this article that provides a fairly thorough perspective: Is removing DRM illegal? Demystifying the Legality of Removing Digital Rights Management</a>. Last, but not least, I would like to urge the reader to seek out those publishers and authors that sell DRM-free books and buy books from them whenever possible. A notably one in the Science Fiction genre is Tor Books</a> (not to be confused with the Tor Network which is completely unrelated). Notable DRM-free stores are Smashwords</a> and Lulu</a>, see Guide to DRM-Free Living: Literature</a> for more. Credits and references</h2> Free Software Foundation</a> for their Defective by Design</a> campaign and the DRM-free imagery. Guide to DRM-Free Living: Literature</a></li> </ul> </li> DeDRM-tools</a> by Apprentice Harper, Apprentice Alf, NoDRM, i♥cabbages and many others.</li> Book burning comic by Bill Bramhall, Bramhall's World as published in the New York Daily News (2018): https://www.nydailynews.com/2018/02/01/bramhall-cartoons-for-january-2018/</a></li> Martijn Braam</a> for his work on showing postmarketOS</a> and sxmo</a> on the Kobo Clara HD: video</a></li> Willie Howard. TechYouLike. Is removing DRM illegal? Demystifying the Legality of Removing Digital Rights Management</a></li> Calibre</a> - e-book management software</li> Tor Books</a> - DRM-free publisher</li> Smashwords</a> - DRM-free store</li> Openclipart.org</a>: https://openclipart.org/detail/320872/woman-reading-in-sunset</a> from https://www.publicdomainpictures.net/en/view-image.php?image=264941&picture=reading-read-peacefulwoman-dusk</a></li> https://openclipart.org/detail/38869/stack-of-paperbacks</a></li> https://openclipart.org/detail/170514/keys</a></li> https://openclipart.org/detail/68545/padlock-icon-rounded</a></li> https://openclipart.org/detail/323509/security-camera</a></li> </ul> </li> </ul> Discredits</h2> Adobe, Amazon, Google and all those many others enforcing DRM technology on end-users. Comments</h2> You can comment on this post on the fediverse/mastodon</a>.

My Default Apps

Unknown — Tue, 07 Nov 2023 23:36:00 +0100

There seems to be a bit of a hype going currently amongst bloggers where people post what their so-called "default apps" or mostly used applications are, apparently prompted by this podcast</a> and Robb Knight's list </a>.

I see most of the participants posting a variety of often Apple-based proprietary software. I thought I'd join in on the fun from a purely FOSS (Free Open Source Software) perspective. I have a strong preference for minimalistic local-first software following the UNIX philosophy (do one thing only, do it well, and interconnect), and often prefer terminal-based interfaces. I want to show that you can perfectly use FOSS tools for all your everyday needs!

📮 Mail Client: aerc</a></li>
🌐 Web Browser: Firefox</a></li>
🧮 Code/Text Editor: neovim</a></li>
📜 Word Processing: LaTeX</a> (but more often via Markdown + pandoc</a>)</li>
📊 Presentations: LaTeX</a> with beamer (more often via Markdown + pandoc)</li>
📜 PDF viewer: zathura</a></li>
🎥 Media Player: mpv</a></li>
🎵 Music: ncmpcpp</a> (client) + mpd</a> + snapcast</a></li>
📝 Notes: neovim</a> and markdown files in a git repo</li>
✅ To-Do: todo.txt</a> with my own todo.txt-more</a> extension.</li>
📆 Calendar: todo.txt-more</a></li>
🗞️ RSS Client: newsboat</a></li>
🎤 Podcasts: podboat (comes with newsboat)</li>
⌨️ Launcher: bemenu</a></li>
🌅 Photo viewer: imv</a></li>
🌅 Photo editing: gimp</a></li>
🌅 Image editing (vector): inkscape</a></li>
📹 Video editing: kdenlive</a></li>
💬 Chat: senpai</a> + soju</a> (IRC), bitlbee</a> (XMPP), gomuks</a> (Matrix), Telegram</a> (or tg</a>)</li>
🔖 Bookmarks: buku</a> + bemenu script</li>
🔐 Password Management: pass</a></li>
🤦 Social Media: Mastodon</a> (sometimes via tut</a>)</li> </ul>
Geek Bonus:

🐧 OS: I use Arch Linux</a> btw (on my desktop and laptop)

I use postmarketOS</a> on my phone (based on Alpine linux</a>), with SXMO</a></li>
On my server I use Ubuntu Linux</a> as host system, with Alpine Linux</a> containers via podman</a> for various self-hosted services, I posted about it on lemmy</a>.</li> </ul> </li>
Terminal: foot</a></li>
Terminal multiplexer: tmux</a></li>
🐚 Shell: zsh</li>
Compositor/Window Manager: Hyprland</a> on desktop/laptop, sway</a> as part of SXMO</a> on phone</li>
Dotfiles</a></li> </ul>

Rant against centralising e-mail in big-tech silos, and breaking the internet in the process

Unknown — Mon, 13 Feb 2023 00:17:28 +0100

Rant against centralising e-mail in big-tech silos, and breaking the internet in the process</h1>
Universities and research institutes used to be at the forefront when it comes to development of the fundamental technologies that power the internet. As early as 1965, researchers at MIT developed a kind of precursor to e-mail. In 1978, researchers at Berkeley leveraged the already existing unix tool 'mail' (1971) to communicate over a larger network. Universities and research institutes were among the first to embrace this new way to communicate with peers across ever greater distances and eventually, with the advent of the internet, all over the globe.
I'm a rather dismayed to see those universities and institutes nowadays no longer as pioneers and innovators in this area, but instead as mere consumers of ready-made corporate solutions, following corporate interests and centralising solutions. I have two employers, both academic, and both have resorted to big-tech corporations that offer solutions like e-mail as a service. E-mail "in the cloud", as they say. In these particular instances it's Microsoft's Office 365 solution that is being adopted, but I'd be just as vocal in my opposition it were Apple, Google or Facebook.
By adopting such solutions, you, as the user, very conveniently get great interoperability within a limited set of proprietary software tools (the ones of the vendor of course). That may be great if you are indeed a user of those tools and happy with it as you are. But as soon as you leave that vendor's ecosystem, the experience becomes less than stellar and often even a burden. Using one of their tools nudges you to also use the others, because it's the most convenient. Worse, it may nudge your peers and they instead apply peer pressure on you to use also those tools.
The average user may not care, but for those of us on the deep-end of the geek spectrum, these trends have worrying implications for software freedom, open standards, overall interoperability and net neutrality. Our concern is highly political.
I don't know what the motivations of the institutes were to adopt this e-mail service, nor who made the decisions, but I'm sure parties like Microsoft know how to ply their wares enticingly. Their promise is, I would guess, most often one of convenience and security. For an institute, outsourcing your e-mail needs to a 3rd party who has the expertise is of course not a bad idea if you lack the expertise yourself. It may be more convenient as you don't have to appoint system administrators yourself and secure your own mail infrastructure. That in itself, however, is not the issue.
My issue is everyone converging on the same extremely select group of service providers. This has already been ongoing for a long time for personal e-mail, with end-users adopting mail services like hotmail and gmail, but it is a different thing when we as academic institutions now follow suit and abandon any pretence of contributing to a mature and properly decentralised infrastructure. In this way, we are willingly contributing to centralisation, which if conducted on such a scale, may fundamentally alter the nature and power-balance of a decentralised network like the internet is in essence meant to be.
This centralisation has security implications too, because not just institutes and users converge on the select group of service providers, but so do attackers. When (I dare say when rather than if) a vulnerability is discovered and exploited by a malicious actor at one point, tremendous amount of e-mails might be compromised.
Let's take the political argument further, what is fundamentally at stake here is who owns the world's computing resources, the world's communication infrastructure, who has access to those, and to whose benefit are they employed. It is all about fair ownership and fair distribution, and in the end, a fairer world. In a digitised society, computing power as well as raw data will become ever more important resources. The question who owns (or has access to) both matters and should not be trivialised. E-mail in particular is quite a treasure trove of data, if accumulated by any centralised party.
Whenever you centralize something, especially on such a scale, you grant power to some entity (a private company in this case) and you have to ask whether this trust is justified and whose interests are really served. How will it play out over the long term? What if some eccentric right-wing billionaire takes over the big-tech company and enforces his own agenda? We've seen it happen already in the social media world, we've put all our microblogging needs in the hands of Twitter and are now tasting the bitter results when such a platform goes downhill rapidly. With centralised e-mail, we'd expose ourselves once more to such risks. Or what if some state-actor takes a hold like in China and uses the data for censorship and other repression? It'd be naive to think we're immune to all this in Western democracies. Technology choices made today shape the internet, the digital society, of the future. Putting all eggs in any single basket is a bad idea in principle. We need to nurture the decentralised nature of the internet.
A few years ago, I already wrote in my post Break free! Don't be a prisoner of your software platform!</a> that the internet is not in the best of states. It has become a hyper-commercialised place in which users flock to free social media platforms, usually advertisement companies at heart, to post their photos, blogs and videos. This trend has developed for over almost two decades, in which fundamental technologies that used to be fairly open were sealed off and turned into walled-in gardens. Users were lured in en masse by the convenience of a service free of charge, but they pay with their privacy by being tracked, profiled and fed to an algorithm aimed to maximize their stay on their service.
It's taken a while but in recent years societal awareness has finally increased that this may not be all for the better. Is the technology still serving us or are we now serving the technology, or the companies providing it to us?
I always maintain that technology choices and usage have real-life implications; it's probably fair to say that social media, as an example, brought an unparalleled upsurge in disinformation, hate-speech, and a whole array of psychological disorders such as attention problems. Things that eventually affect the real world.
If you are, like I am, conscientiously choosing not to use centralised communication platforms that lock you in, then you quickly hit a wall if you don't play along. I'm already excluded (self-imposed) from various instant messaging groups because they use WhatsApp (= Facebook aka Meta), which I've always refused to use. Now at work the push towards M365 effectively locks me out of my institutional mail; this used to be easily remedied with a simple automatic mail forward, a basic mail function that's been around for ages and which everyone should have, but that option has been disabled. I get the concern you may not want everybody wildly forwarding everything and prevent sensitive information from landing on insecure servers, but a complete block is unnecessarily inflexible. Now I have no say in where mail directed at me goes anymore and am forced into Microsoft's solution.
As a result, I have resorted to just telling people not to use my institutional mail at all anymore, via a silly auto-reply. This is an option I'd rather not have taken as that burdens the sender with something that should have been, and can normally be, easily automated.
Aside from the political objections I also wanted to provide some further technical arguments against M365, as they make several technical choices that go against my idea of software freedom and how e-mail should work:

M365 blocks various IP ranges which affects self-hosted SMTP servers. The sender will have to explicitly register mail address and IP with M365 to be let through. I get the need to combat spam, which is the major cancer of e-mail. But this strictness breaks the decentralised spirit.</li>
M365 rewrites URLs in mails, it modifies the incoming mail (which in my view is a already big no-go by definition and breaks cryptographic signatures). It makes all links go through their system (safelinks.protection.outlook.com</code>). Again, I understand this is to protect against phishing, which is the 2nd most common problem with e-mail, but it misses the mark entirely, works counter productive, and introduces a huge privacy problem whilst doing so. Every link I click would go through their system and can potentially be tracked! Moreover, I only use text mails (no HTML, so far less prone to phishing) and their URL rewriting obfuscates the URLs, making it harder for me to spot whether a link is legitimate or not. I can make that decision on my own, I don't need nor want MS to do it on my behalf.</li>
`The IMAP login procedure with two-factor authentication breaks more traditional mail clients without OAuth2 support. Okay, then they should implement OAuth2, fine, I don't have an issue with 2FA in general. But the way it is implemented in OAuth2 by big mail providers like M365, according to``the fetchmail developer</a>, obliges mail clients to register with the mail provider. This gives more control to the companies and less to the user. The service provider shouldn't care what client I use, the only thing that matters is that I as user have the right credentials to access my mail.</li>`
I'm using a rather specific mail workflow which I've optimised over the years to work for me. Using my own mailserver, notmuch, neomutt and more. It's certainly not for everybody but it works for me (and it took me years to find something I'm actually comfortable with, most mail solutions suck pretty bad, or I suck at mail, probably a combination of both). Pulling in IMAP from M365 into my mail workflow would require me to spend a few nights setting up complex solutions</a> which I don't really need or want in the first place.</li> </ul> I may be a bit (okay, more than a bit) of an opinionated left-leaning idealist, but the principles that formed the backbone of the internet are grounded in interconnectivity of decentralised entities. Agreements like RFCs establish protocols that specify how communication should proceed and what is expected of implementations. Anyone is free to implement them. Communication especially should be open, secure and interoperable, or we end up communicating only with people in different walled-off corporate (or governmental) silos. Which is sub-optimal. I strongly believe in federation, but that's been under siege for well over two decades because it's 1) technically much more difficult to get right 2) socially harder because it requires communication and coordination and 3) harder to exploit commercially, as trapping users in your own platform is way more profitable. In conclusion, I want to appeal to institutes and individuals alike to think about this and contribute to a better decentralised yet interconnected digital future, rather than be complacent in its demise: keep fundamental technologies accessible to everybody, not just big commercial (or governmental) players, and improve upon them where necessary. If you haven't had enough after my rant on this subject, I strongly recommend you to also read Carlos Fenollosa's blogpost "After self hosting my email for twenty-three years, I have thrown in the towel. The oligopoly has won."</a> who makes compelling arguments in the same direction and explains the technical difficulties more in depth than I did here. I know I'm not alone in this struggle.

STAM: Stand-off Text Annotation Model

Unknown — Sun, 01 Jan 2023 00:04:34 +0100

STAM: Stand-off Text Annotation Model</h1>
STAM is a data model for stand-off text annotation. The underlying premise is that any information on a text is represented as an annotation. We define an annotation as any kind of remark, classification/tagging on any particular portion(s) of a text, or on the resource or annotation set as a whole, in which case we can interpret annotations as metadata. Additionally, rather than reference the text directly, annotations may point to other annotations (higher-order annotation). Examples of annotation may be linguistic annotation, structure/layout annotation, editorial annotation, technical annotation, or whatever comes to mind. Our model does not define any vocabularies whatsoever.
The underlying resource is taken in its most bare form without further information; e.g. plain text (an ordered sequence of unicode points). Any additional information would be considered an annotation in our model. Interpreting and supporting particular formats/encodings is up to the implementations and opaque to the data model.
STAM does not depend on other more complex data models such as RDF, W3C Web Annotations, TEI, FoLiA or whatever, but instead addresses the problem from a more functional and pragmatic perspective. We separate pragmatics from semantics and define a kind of lowest common denominator upon which further solutions can be built. The user is free, and in fact encouraged, to use vocabularies that are formalised elsewhere.
STAM is primarily intended as a model for data representation, and less so as a format for data interchange. It is designed in such as way that an efficient implementation (both speed & memory) is feasible. The form of such an implementation either in a relational database, triple store, directly modelled in memory, is left open to the implementation. Our model should also be reducible to a more generalised acyclic directed graph model without much difficulty.
Goals/characteristics of STAM are:

Simplicity - the data model must be easy to understand for a user/developer to use and only contain what is needed, not more. We provide a minimal foundation upon which other projects can build more complex solutions. These are deliberately kept out of STAM itself. The notion that everything is an annotation is at the core of STAM and one of the things that keeps it simple. </li>

Separation from semantics - The data model does not commit to any vocabulary or annotation paradigm. It must be flexible enough to express whatever annotation paradigm a researcher wants to use, yet provide the facilities to be specific enough for practical purposes. The model basically allows for any kind of directed or undirected graph. </li>

Standalone - No dependency on other data models (e.g. RDF) aside from Unicode and JSON for serialisation, no dependency on any software services. </li>

Practical - Rather than provide a theoretical framework, we primarily aim to provide a practical specification and actual low-level tooling you can get to work with right away. </li>

Performant - The data model is set up in such a way that it allows for efficient/performant implementations, with regard to processing requirements but especially memory consumption. The model should be suitable for big data (millions of annotations). We sit at a point where we deem to have an optimal trade-off between simplicity, flexibility and performance. </li>

Import & Export - Reads/writes a simple JSON format. But also designed with export to more complex formats in mind (such as W3C Web Annotations / RDF) and imports from common formats such as CONLL. Note that although STAM puts no constraints on annotation paradigms and vocabularies, higher data models may. </li> </ul>
The name STAM, an acronym for "Stand-off Text Annotation Model", is Dutch, Swedish, Afrikaans and Frisian for "trunk" (as in the trunk of a tree), the name itself depicts a solid foundation upon which more elaborate solutions can be built.
STAM is introduced on the STAM website</a>.
Implementations</h2>
The following implementations are available:

stam-rust</a> - A STAM library written in Rust, aims to be a full STAM implementation with high performance and memory-based storage model.</li>
stam-python</a> - A STAM Library for Python. This is not an independent implementation but it is a Python binding to the above Rust library.</li>
stam-tools</a> - A set of CLI tools for STAM.</li> </ul>

Todo.txt-more: Efficiently managing your todo list and your time

Unknown — Sat, 31 Dec 2022 17:07:28 +0100

Todo.txt More: Efficiently managing your todo list and your time</h1>

Introduction</h2>
I tend to get fairly enthusiastic when it comes to lists, even more so when there's a chance to optimise my productivity. The end of the year is a time for looking backward and forward, so what better time to revise my time management solution than this?
Over the years, I've tried various ways of keeping todo lists. Some methods were more successful than others. Too often I found myself abandoning the lists I had because it introduced too much overhead (or I simply lacked the discipline to maintain them), or the lists themselves got too cluttered and I lost overview, or they were too detached from the places where I actually needed them.
Two things that did work well for me in recent years are the use of Github issues for software related tasks, and keeping track of todo tasks related to mails by tagging the mails (using notmuch</a>. However, that is already two different systems, and they don't cover all possible todo tasks. Aside from Github I also use Sourcehut and Gitlab for software development, and at work they use Jira, so that would introduce even more systems to check. Such context switches, the need to check different systems, have an especially large negative impact on productivity. My aim is to minimize these.
What I want is one unified way to see and organise my todo tasks, regardless of where they come from. I also want to add tasks like simple household chores or hobby projects, with the main aim so I don't forget them. I want to be able to efficiently search through them so I can easily get all tasks pertaining to a specific project, a specific employer, a specific priority, etc..
I'm now coming back to todo.txt</a> to do all this. This is a simple minimalistic solution, developed by Gina Trapani, that's already been around since 2006. It keeps todo tasks in a simple plain text file and introduces some basic syntax for tagging. A command line shell script called todo.txt-cli</a> is provided for various basic operations. It requires no complicated database solutions, no complex software implementations, and it can just be used from your favourite text editor (vim in my case) even without any bells and whistles.
Todo.txt has a simple tag syntax, tags starting with `+</code> are projects, tags starting with @</code> indicate contexts, and I add #</code> for other kinds of tags (hashtags). Then there is a simple tag for priorities. With todo.txt I'm making use of priorities A, B and C only (and D as a special category). I use them as follows that could also map to a kind of kanban-style:`
`(A) for tasks to do today</li> (B) for tasks to do later this week</li> (C) for tasks after this week (limited)</li> (D) for tasks that are temporarily blocked/waiting on hold</li>`
Then there's a whole backlog of tasks without a priority, these also act as a trove storing ideas I might or might not get to.</li> </ul>
Priorities are adjusted as needed, corresponding to moving tasks between columns on a kanban board. I'm using three main contexts `@work</code> and @hobby</code> and @chore</code> to attempt to create a bit of a distinction between my work and private life.`
`There is already a wide variety of community software that handles todo.txt</code>, but I was still missing some features, or they weren't implemented in other extensions in the way I prefer. So I took towards improving the todo.txt</code> experience. I will describe what I added and how it can be used in the remainder of this post.`
`Todo.txt More</h2>`The todo.txt</code> CLI implementation offers a nice way to extend it. I have done so and implemented various extensions which I felt were missing. I call this Todo.txt More</a>. Go to its Sourcehut page</a> to find the source code repository and installation instructions. Todotxt More contains the following extensions to todo.txt-cli: more</code> - Main entry point, shortcut invoking various underlying plugins. By default displays a list with better sorting (relsort</code>) and colour highlighting (format</code>)</li> edit</code> - Invokes editor to edit todo.txt.</li> show</code> - Show a single task based on item number</li> priup</code> - Priority up</li> pridown</code> - Priority down (down to C, deprioritised after)</li> rofi</code> - Control todo.txt interactively via rofi (a menu program)</li> fzf</code> - Control todo.txt interactively via fzf (a terminal based fuzzy finder)</li> issue</code> - View and sync issues (sync with Github)</li> timetrack</code> - Track time on projects and contexts, and produce summary reports</li> notmuch</code> - Sync with notmuch mail based on tags like 'todo' and/or 'reply'</li> cal</code> - Import iCalendar/vCalendar (ics) files</li> autoprio</code> - Automatically assign priorities (mostly based on due dates)</li> </ul> The following are usually not called directly: format</code> - Better coloured output, supports ANSI colours, pango, and html</li> relsort</code> - Better sorting with relative dates</li> actionmenu</code> - The menu used in the fzf and rofi interfaces.</li> </ul> One of the primary additions is a simple interactive interface powered by either fzf</code> (terminal) or rofi</code> (GUI). Both are fuzzy finders and allow to quickly navigate the todo tasks. To display your tasks non-interactively, we recommend you use todo.sh more</code> (short for todo.sh more list</code>) rather than the traditional todo.sh list</code>; todo.sh more</code> redefines several built-in commands. A quick recommended way to use this from your shell is to set an alias t="todo.sh more"</code>, you can then do t list</code> (or just t</code> as a shortcut),t add</code>,t done</code> etc... All the regular commands as well as the extensions should be available. Todo.txt-more will invoke the format</code> and relsort</code> extensions to do better colour highlighting and better relative sorting. You can pass any actions you also pass to todo.sh</code>. Here is an example: You can note the following in this example: todo.txt-more adds hashtags (starting with #) and will colour them differently (todo.sh format</code>), context (@</code>) and projects (+</code>) will also get a distinctive colour.</li> tasks with priority will always be shown before any items without priority (todo.sh relsort</code>)</li> tasks with a creation date will be shown using their relative date in days (e.g. 6d) , and sorted accordingly. though not shown in this example, tasks with a due date (due:</code> attribute) will be shown using their relative date in days (e.g. 6d+), and sorted accordingly, this takes precedence over creation date.</li> </ul> </li> you see tasks synced from GitHub (issue</code>) and from my mail (notmuch</code>), more about this later...</li> </ul> Between the more</code> and lists</code> actions, you can inject the format you want for the output and the colouring. ansi</code> - ANSI escape sequences, good for terminals, this is the default</li> pango</code> - Pango markup, good when used with GUI applications like rofi, dmenu with pango patch, wayout</a></li> html</code> - HTML, good for exporting to the web</li> markdown</code> - Markdown syntax</li> slack</code> - Slack's butchered version of markdown syntax, good for pasting into Slack.</li> </ul> You might, however, prefer a more interactive view that allows you to do fuzzy search and makes the tasks directly actionable. If you run todo.sh fzf list @work</code>, you'd the see same view as the static one, but interactively using fzf: Or run todo.sh rofi list @work</code>, for the same thing in rofi, which opens a graphical menu. This is great to tie to a keybinding in your (tiling?) window manager: Note that your rofi may look different depending on the theme you are using. The rofi method even binds some shortcuts keys for quick actions like prioritisation and editing. Moreover, you can directly add new entries with rofi by just typing the full task entry in the search field and pressing enter. For existing items, once you select an item in either rofi or fzf, you're presented with an action menu (todo.sh actionmenu</code>) Notifications</h2> You can enable feedback via your notification daemon (via notify-send</code>) by setting environment variable TODOTXT_NOTIFY=1</code>. If set, you will get feedback notifications on various actions. Issue syncing</h3> If you use Github extensively, like I do, its issue tracker is likely an important source of information for your todo tasks. However, it's cumbersome to have issues separate from your todo.txt and effectively have two systems you need to check. The issue</code> extension should solve this problem. Its job is to sync issues (including pull requests) from github with your todo.txt. It will sync all issues assigned to you. The sync works as follows: All tasks that are issues are marked with issue:</code> and the full path to the issue.</li> A sync is done by calling todo.sh issue sync</code>, in order for this to work you need to have the environment variable $GITHUB_TOKEN</code> set to a Github API token.</li> Any github issue that is assigned to you and not yet in todo.txt</code> or done.txt</code> will be added (without prioritisation)</li> The Github repository name is translated to a project name (e.g proycon/codemeta-harvester</code> becomes +codemetaharvester</code>, punctuation etc is stripped and all is lowercased) and will be shown at the beginning of the task line.</li> The todo.txt</code> contains just the issue title, its labels, project, not the body or comments. The rofi and fzf extensions offer an easy way to inspect an issue in the browser.</li> If you close a task that is also a github issue via the action menu in rofi/fzf or via task.sh issue done</code>, an API call will go out to GitHub to close the issue.</li> Projects may also translate to further projects or contexts, you can customize this in a JSON file and pass the JSON filename in environment variable $TODO_ISSUE_INFERMAP</code>. Example:</li> </ul> { "codemetapy": ["@work","@huc","@clariah","+wp2tooldiscovery"], "codemetaharvester": ["@work","@huc","@clariah","+wp2tooldiscovery"], "codemetaserver": ["@work","@huc","@clariah","+wp2tooldiscovery"], }</code></pre> These will all be appended to the end. Github labels will be added as hashtags immediately after the project name. You can optionally translate these through another map defined in a JSON file and filename in $TODO_ISSUE_LABELMAP</code>. Example:</li> </ul> { "feature": "feat", "enhancement": "feat" }</code></pre> Tasks will have a creation date corresponding to the creation data of the issue.</li> An extra updated:</code> attribute is added with the last updated time. This is updated on sync.</li> </ul> There are a few limitations to be aware of: The task description/issue subject is synced from github to task.txt only once, editing it in either has no effect on the other.</li> When Github labels change, they will be synced back to todo.txt (but will appear at the end when they're new). You can't sync hashtags to github labels the other way round.</li> When an issue is closed and reopened, it won't be detected in the sync</li> </ul> Though currently limited to Github, I hope to add Gitlab and Sourcehut support as well at a later stage. Mail syncing</h3> Another common source of todo tasks is email. I often receive mails that require some kind of follow-up action, or that I simply have to reply to. I am using notmuch</a> as a means to add tags to my mail and make it quickly searchable. I use a reply tag for mail I still have to reply to, and todo for mail that requires another follow-up actions. Of course, I want both in my todo.txt</code> so I have everything in one place again. The todo.txt notmuch</code> extension syncs with your notmuch database. It runs a query (defined in environment variable $TODOTXT_NOTMUCH_SEARCH</code>, which defaults to tag:todo or tag:reply</code> fitting my own use-case) and adds all threads it finds to todo.txt</code>. It is a one-way sync. Synced mails receive the context @mail</code> and the notmuch tag translates to a hashtag. Any further mappings between notmuch tags and todo.txt can be configured in a JSON file, filename stored in $TODOTXT_NOTMUCH_MAP</code>. Example: { "work": ["@work"], "personal": ["@hobby"], "sxmo": ["+sxmo", "@hobby"], "folia": ["+folia","@huc","@work"] }</code></pre>Time tracking</h3> Employers often require you to track your working hours, especially if you are working on a variety of distinct projects. Keeping track of this manually is a waste of time. If you have your todo.txt</code> workflow in place, we can simply take advantage of this for tracking time as well. This is done using todo.txt timetrack</code> and it can be invoked interactively via the action menu as presented by fzf or rofi. When you say start task a simply eentry of the full task line, prepended with the current date and time, is registered to a file timetrack.txt</code> that lives alongside your todo.txt</code> and done.txt</code>. Only one task can be tracked at any given time (people suck at multitasking anyway, so better not pretend you can do it). When you start a new task the previous one ends. There is also todo.sh timetrack stop</code> to stop tracking, which will simply register an idle entry in timetrack.txt</code>. I recommend to automatically trigger this action when your screensaver/screenlock kicks in so you don't have to worry about it. The tracking will also be stopped automatically if you mark the currently tracked task as done via todo.sh more done</code> or fzf/rofi. To see the task you are currently working on, run todo.sh timetrack current</code>. This may be worth adding to whatever bar (waybar/polybar/dwm's bar/etc) you use so you can see it at all times. $ todo.sh timetrack current -d 1h13m +todotxtmore implement timetrack summary options @hobby</code></pre> The timetrack.txt</code> log can be visualised with todo.sh timetrack log</code>, it optionally takes a start date and an end date (non-inclusive) as parameters (YYYY-MM-DD). Add the -d</code> option if you want to have relative time (durations), use -s</code> instead if you want it in raw seconds, these are also available for timetrack current</code> as shown above. Using todo.sh timetrack daysummary</code> you can get a summary of total time spent, per day, on specific contexts or projects. It aggregates for each day all projects (+</code>) and contexts (@</code>) mentioned in the log. Example output: $ todo.sh timetrack daysummary 2022-12-29 2022-12-29 Thu 8h52m @hobby 2022-12-29 Thu 4h8m +todotxtmore 2022-12-29 Thu 14m @generic 2022-12-29 Thu 14m @entertainment</code></pre> Be aware that the contexts and projects used in aggregation are not mutually exclusive. You can use any combination you want. Similarly, there is a weeksummary</code> and monthsummary</code> that aggregates per week/month. You may add the -all</code> parameter to see individual tasks again (rather than just contexts and projects). Calendar</h3> There is a fair degree of overlap between todo lists and calendars, even though they are distinct perspectives on your time planning. Todo.txt traditionally caters towards todo lists and not calendars, due dates are not in the initial design but can be easily using a due</code> attribute, as many other implementations also do. Todo.txt-more follows this convention and takes due</code> dates into account when sorting (relsort</code>) and highlighting. This opens up the road to expressing calendar items in todo.txt</code>. The cal</code> extension allows importing iCalendar (ics) format via todo.sh cal import</code>. Similarly, you can export todo items to iCalendar format using todo.sh cal export</code>. The cal</code> extension also has some specific visualisations via todo.sh cal list</code>: Add the --headers</code> parameter for a more verbose view grouped per day. The latter is also what you get if you just run todo.sh cal</code> without further arguments. Contribute</h2> If you want to contribute, git clone the source code repository</a> and send patches to my public inbox</a>. Read about the git e-mail workflow</a> if you are not yet familiar with it. The code is currently in a fairly early stage of development and needs further testing and cleanup.

Analiticcl

Unknown — Sat, 25 Sep 2021 00:04:34 +0200

Analiticcl</h1>
Analiticcl is an approximate string matching or fuzzy-matching system that can be used for spelling correction or text normalisation (such as post-OCR correction or post-HTR correction). Texts can be checked against a validated or corpus-derived lexicon (with or without frequency information) and spelling variants will be returned.
The distinguishing feature of the system is the usage of anagram hashing to drastically reduce the search space and make quick lookups possible even over larger edit distances. The underlying idea is largely derived from prior work TICCL (Reynaert 2010; Reynaert 2004), which was implemented in ticcltools</a>. This analiticcl implementation attempts to re-implement the core of these ideas from scratch, but also introduces some novelties, such as the introduction of prime factors for improved anagram hashing. We aim at a high-performant implementation written in Rust.
Aside from reading the documentation</a>, you can also view an in-depth presentation video</a> that was presented at the KNAW Humanities Cluster in January 2022.

Demo</h2>

SXMO: Simple X mobile - presented at AlpineConf 2021

Unknown — Sat, 15 May 2021 16:30:00 +0200

Sxmo: Simple X mobile - A minimalist environment for Linux smartphones</h1>
We presented Sxmo at AlpineConf 2021:
</video> </div>
Details shown in this video:

Hardware: Pinephone 1.2</li>
Environment: Sxmo</a></li>
Distribution: PostmarketOS</a>, on top of Alpine Linux</a></li>
Window Manager: dwm</a></li>
Terminal: st</a></li>
Virtual Keyboard: svkbd</a></li>
Note: our IRC channel moved to oftc.net rather than Freenode (as shown in the video) due to the hostile takeover of the latter network.</li> </ul>

clickclack

Unknown — Mon, 15 Mar 2021 16:04:34 +0100

Clickclack</h1>
Clickclack is a simple haptic feedback and audio feedback tool. It does nothing more than emulate the clickclack sound and vibration when pressing keys.
This tools reads from standard input and emits a vibration and/or a sound whenever it receives a character. It is intented to be used in combination with a virtual keyboard like svkbd</a> (X11) or wvkbd</a> (wayland).

Een antwoord op corona-skepsis

Unknown — Thu, 18 Feb 2021 09:25:28 +0100

Een antwoord op corona-skepsis</h1>

Inleiding</h2>
We zitten midden in een pandemie met ongekende maatregelen die de meeste van ons in het westen nog nooit gezien hebben. Het coronavirus en alle maatregelen zorgen begrijpelijkerwijs wereldwijd voor opschudding. In dit opiniestuk reageer ik op het verschijnsel van de coronaskepticus, of in extreme de complotdenker, en probeer ik mijn visie hierop voor mezelf en anderen wat te duiden.
Toen de eerste signalen van het coronavirus uit China kwamen trok dit al snel mijn aandacht. In eerste instantie kwam het voornamelijk vanuit burgerjournalistiek naar boven. Ik volgde o.a. Fang Bin en Chen Qiushi. De eerste reactie van de overheid daar was om die geluiden hard te onderdrukken. Zo ook werden de allereerste corona-bevindingen van de arts Li Wenliang onderdrukt. Hij zou later aan het virus overlijden. Je kan je afvragen of een sneller ingrijpen in plaats van een typische repressie reactie de pandemie had kunnen voorkomen. Beide genoemde burgerjournalisten zijn overigens nog steeds 'vermist' in bepaalde vorm. Mijn zorgen gingen niet alleen naar de gezondheidsrisico's van het virus uit, maar ook naar de omgang met informatie en maatregelen van de Chinese overheid. Een duidelijk beeld vormen over de situatie daar was lastig als er van zo'n sterke censuur sprake is, maar dat er een uit de hand gelopen gezondheidssituatie ontstond leek al snel niet meer te ontkennen. Later kondigde de overheid er strikte quarantaines af, ze waren erg drastisch maar bleken wel effectief.
Ik kwam al vroeg op het spoor van Dr. John Campbell [^campbell], een gepensioneerde Britse verpleegkundige en academicus die een beetje een youtube hit is geworden en al vanaf het begin nauwgezet allerlei ontwikkelingen rond het virus volgt. Hij presenteert deze met zijn eigen duiding duidelijk en onvermoeibaar aan het algemene publiek; op karakteristieke wijze met geprinte velletjes papier en een markeerpen.
Dat het virus mogelijk pandemische vormen aan zou kunnen nemen, hield ik al snel voor een realistische mogelijkheid. Met het eerste SARS virus zijn we hier de dans ontsprongen gelukkig, maar vele wetenschappers voorspelden al langer dat het een kwestie van tijd zou zijn eer een virus mondiaal om zich heen grijpt. Gegeven de globalisatie, grote bevolkingsdichtheid, en omgang met dieren die vaak veel te wensen overlaat, was dit potentieel al geruime tijd aanwezig en een reële dreiging volgens mij.
In die tijd nam ik ook maar het zekere voor het onzekere en kocht ik alvast een klein doosje FFP2 mondkapjes. Toen kon het nog prima want het was voor de meeste mensen nog een ver-van-mijn-bed-show. Nu geef ik toe dat ik van karakter nogal snel op m'n hoede ben als het om het oplopen van ziektes gaat, dus ik nam het risico snel serieus gegeven de tot dan toe beschikbare informatie. Toen het in Italië opdook begon ik zelf al met wat beperkende voorzorgsmaatregelen. Ik werkte sowieso altijd al vanuit huis en ben van nature vrij introvert, dus het is voor mij lang niet zo moeilijk als het voor vele anderen is.

Flatten the curve</h2>
Dat er uiteindelijk maatregelen vanuit de overheid kwamen om de verspreiding van het virus in te dammen vond ik dus ook zeer terecht en noodzakelijk. Ik zie het op zich ook als een erg positief teken van medemenselijkheid dat de maatschappij in staat is zichzelf tijdelijk een halt toe te roepen om elkaar in bescherming te nemen. Dat een centrum-rechts kabinet kabinet toch in staat is de economie niet voor alles te laten gaan vond ik persoonlijk wel een hoopvol teken. Een andere hoopvol teken in deze lastige tijden vind ik dat er hiermee wellicht een hernieuwde waardering is gekomen voor de publieke sector, de 'verzorgingstaat' en de zogenaamde essentiële beroepen. Een derde hoopvolle ontwikkeling is de enorme snelheid waarmee wetenschappers er in geslaagd zijn om succesvolle vaccins tegen dit virus te ontwikkelen, waaronder een hele nieuwe generatie aan mRNA vaccins. De cijfers die we van vaccinatie-koploper Israël krijgen zijn veelbelovend. Het is toch met deze oplossing dat we uit eindelijk het virus eronder zullen moeten krijgen, als het zich niet tot een onschadelijkere variant muteert in de tussentijd.
Het argument dat er juist op het gebied van essentiële beroepen als de zorg veel afbreuk is gedaan deel ik wel. Is er niet te veel bezuinigd op de zorg? Hadden we niet veel meer IC-capaciteit moeten hebben, zoals bijvoorbeeld Duitsland? Werkt de verregaande privatisering van de zorg en de marktwerking erin niet averechts? Op zich wil ik, zonder dat ik dit in alle diepte uitgezocht heb, hier best ver in meegaan. Ik snap op zich dat zorgkosten stijgen met toenemende vergrijzing en dat er een zekere kosten-efficiëntie moet zijn, maar dat we hierin in doorgeslagen zijn vind ik zeer aannemelijk. [^vpro]
Dat gezegd hebbende is de gangbare visie dat geen elk zorgsysteem echt opgewassen is tegen een virus wat zich razendsnel verspreid en een niet gering deel van de populatie hard raakt [^rtlnieuws]. Je hoort weleens de quote "The greatest shortcoming of the human race is our inability to understand the exponential function.". Ik ben ervan overtuigd dat als er geen maatregelen genomen worden en men op oude voet doorgegaan zou zijn, je binnen niet afzienbare tijd tegen de grenzen van welk systeem dan ook zou aanlopen.
Hier in Nederland hebben we tijdens de eerste golf al gezien dat mensen over ziekenhuizen verdeeld werden, en dat zie je op tal van plekken gebeuren, in de EU ook geregeld over landsgrenzen heen. Die solidariteit vind ik ook wel weer een lichtpuntje in deze tijd. Nu ik dit schrijf is de situatie in Portugal erg kritisch met overvolle ziekenhuizen, en zie je Duitsland een militair vliegtuig sturen met extra personeel en materieel en eerder ook al patiënten overnemen [^expresso] [^cmjornal].
Je zorgsysteem laten overstromen zal tot een verdere toename van het aantal ernstig zieken en doden leiden, je kunt ze dan immers niet meer allemaal behandelen en moet gaan kiezen. Dit zie je dan ook al gebeuren op plekken waar het virus hard om zich heen grijpt en het gezondheidssysteem minder sterk staat dan hier in Europa, kijk bijvoorbeeld naar Manaus in Brazilië [^redebrasil], waar patiënten stierven omdat de zuurstof op was, sommigen liever vanuit het ziekenhuis naar huis vluchten om daar te sterven [^folhapatoense], en de thuissterfte sowieso al toenam omdat mensen het ziekenhuis niet eens meer bereikten [^amazoniareal]. Het wrange hier is ook dat Manaus in de eerste golf ook al hard getroffen was en zowel zorg als uitvaartwezen overweldigde [^guardian]. Er was bij de tweede golf enige hoop op groepsimmuniteit was, maar dat viel vies tegen, mogelijk mede door de mutatie aldaar [^sabino2021]. In de allereerste toespraak van Rutte hoorde je de term groepsimmuniteit nog vallen, maar de strategie van het bereiken van gecontroleerde groepsimmuniteit is al snel onrealistisch gebleken, ook in landen als het VK en Zweden waar ze er sterker op hadden ingezet.
De reden dat we onszelf beperkingen opleggen is om dat soort drama's te voorkomen. Dat zijn ook geen gevolgen die een respectabel politicus voor zijn/haar rekening wil nemen. De volksgezondheid waarborgen is bij uitstek een taak die de overheid is toebedeeld. Als we niks zouden doen zouden er veel meer mensen, voornamelijk ouderen en andere kwetsbare groepen sterven [^flaxman2020]; ook dikke mannen van boven de 50 tellen mee als volwaardige mensen. De sterfgevallen zijn uiteraard het topje van de ijsberg, de meeste mensen zijn in meer of minder mate ziek en herstellen uiteindelijk weer. Een bijkomende zorg hier is nog wel het niet geringe aantal mensen wat lange tijd last blijft houden van de gevolgen van de infectie (de zogenaamde long covid) [^volkskrant3], zoals ook een naaste collega van mij overkwam. Een overspoelde gezondheidszorg heeft natuurlijk ook negatieve implicaties voor niet-covid patiënten. Als noodzakelijke zorg niet meer geleverd kan worden omdat covid-19 alle zorg opeist, heb je ook daar een groot probleem, meer lijden en meer sterfte ook onder mensen die niet met covid besmet zijn.
De oversterfte afgelopen jaar wordt ook duidelijk aangetoond [^cbs], al hoor je vanuit corona-skeptische kringen zoals het Forum voor Democratie soms gekunstelde pogingen om het tegendeel te beweren [^sargasso]. Dat we toch nog hoge oversterfte hebben juist in een context van harde maatregelen om virusverspreiding tegen te gaan, toont ook wel aan dat we ons in een uitzonderlijke situatie bevinden. Die context kan je ook niet buiten beschouwing laten. De aanname dat het zonder maatregelen om verspreiding tegen te gaan veel erger zou zijn met de oversterfte is een realistische, want er is een direct causaal verband tussen corona besmetting, de covid-19 ziekte en sterfte. Beperking van besmetting leidt logischerwijs tot beperking van sterfte. Hier kom ik later ook nog wel op terug.
De doelstelling van alle maatregelen is wat mij betreft, en ik heb het gevoel dat dit breed gedeeld wordt, om alle gezondheidsschade die dit virus aanbrengt binnen de perken en controleerbaar te houden. Het in stand houden van het gezondheidswezen is hierin een cruciale factor. Als de cijfers laag en beheersbaar zijn, kunnen we met veel testen en bron & contactonderzoek gerichter opereren, en zijn we niet meer genoodzaakt om met een kanon op een mug te schieten.
De wetenschap</h2>
Wat betreft het virus zelf. Nee, dit is (gegeven infectie) zeker niet zo'n killer als ebola, of als HIV lange tijd was, en op plekken in Afrika waar de dure medicatie niet voorhanden is, nog steeds is. Het treft ook niet de jongeren op de manier die we wel zagen bij de H1N1 influenza pandemie van 1918 die tientallen miljoenen doden tot gevolg had. De IFR (Infection Fatality Rate) van corona valt gelukkig lager uit dan initieel gedacht, maar wordt altijd toch nog een behoorlijke factor hoger geschat dan influenza, zeer afhankelijk uiteraard van de populatie en de mate van vergrijzing daarin [^blackburn2021] [^levin2020].
Het belang van de IFR in deze is eigenlijk ook onderschikt aan het belang van het gemak/ongemak waarmee een virus zich verspreid; de besmettelijkheid. Als we een virus A hebben dat veel minder dodelijk (lage IFR) is maar zich veel sneller verspreid (hoge R) dan een ander veel dodelijker virus B (hoge IFR, lage R), dan zal virus A uiteindelijk onder de streep verreweg de meeste doden op zijn geweten hebben. Met dit coronavirus hebben we vooral te maken met het probleem van snelle verspreiding (wat alleen maar toegenomen is door varianten als de Britse B1.1.7). In deze zin is het virus wél vele male ernstiger dan bv. ebola. De snelle verspreiding komt nu ook mede doordat het een nieuw virus was waar niemand nog antistoffen tegen heeft.
Voor ik verder ga over de wetenschap moeten me eerst even twee dingen van het hart. Ik wil een positief en een negatief punt noemen wat betreft onze houding tegenover de wetenschap in deze kwestie. Ten eerste het positieve punt dat er momenteel intensief naar de wetenschap gekeken wordt en dat ook overheidsbeleid van vele landen op de adviezen van wetenschappelijke organen stoelt. Hier in Nederland middels het welbekende OMT. Dit vind ik een positief punt en staat in contrast met landen waar dat veelal niet gebeurd of waar de autoriteit vaak in strijd is met we wetenschappelijk consensus. We kennen in deze vooral Trump die er nog al een handje van had om voor zijn beurt uit te spreken met wilde ideeën ('it will go away soon') en in een persconferentie vrijuit speculeerde of bleekmiddelen geen rol zouden kunnen spelen binnen het lichaam in het tegengaan van het virus; Fauci moest ingrijpen om ergere misverstanden te voorkomen. Maar goed, ik maak hier dus juist een positief punt dat het goed is dat men zich op de wetenschap beroept, en ook dat het goed is dat men zich in de wetenschap verdiept en dat de wetenschap er in slaagt binnen zo snelle tijd effectieve vaccins te produceren die ons weer uit de pandemie zullen helpen.
Het tweede punt is een negatieve: er wordt weleens gekscherend gezegd dat we naast een virus-pandemie ook een virologen-pandemie hebben. Iedereen hoort nu het één en ander over virologie en epidemiologie en sommigen lijken iets te snel geneigd te denken expert te zijn. Dus laat ik bij mezelf beginnen en duidelijk stellen dat ik geen viroloog, epidemioloog of arts ben. Ik zal proberen daarom in dit stuk niet te veel harde wetenschappelijke beweringen te doen maar vooral te beschrijven hoe ik de handelingen van overheid en wetenschap duidt.
Wetenschapper mag ik mezelf officieel wel noemen, maar ik denk dat terughoudendheid op zijn plaats is zodra ik buiten mijn vakgebied treed. Ik doe wel vaker peer reviews binnen mijn vakgebied uiteraard, en dat is al vaak lastig genoeg. Bij papers op het gebied van epidemiologie en virologie ontbreekt het me al heel snel aan diepte én breedte van kennis/literatuur die nodig is om tot een volledig beeld te komen en het naar waarde te kunnen beoordelen. Deze terughoudenheid is ook iets wat je van andere academici mag verwachten, al is dat niet altijd het geval. De tendens is meestal; hoe meer je over iets weet, hoe beter je ook weet wat je allemaal juist nog niet weet. Wetenschap leidt in de regel meestal tot meer nieuwe vragen dan het tot antwoorden leidt. Mijn punt hiermee is dat ik en wij allemaal ons dus vooral moeten baseren op wat de experts op dit gebied onderzocht hebben en concluderen. Dit is ook een vertrouwensrelatie, een vertrouwen in het wetenschappelijke proces. Ik begrijp dat dat soms beschadigd kan worden. Het wetenschappelijk proces is een inherent sociaal en menselijk proces, want zelfs de briljantste persoon kan niet in zijn eentje de breedte en diepte van allerlei verschillende kennisvelden zich eigen maken. De beste manier om dit virus te begrijpen en te verhelpen is via de wetenschap, tenzij je wellicht van mening bent dat we ons en masse in de kerken moeten terugtrekken en de goden moeten bidden om verlossing. Het is belangrijk dat er publiek vertrouwen is in de wetenschappelijke consensus die uit een een stapeling van onderzoek voortkomt, en in de ondermijning hiervan vanuit sommige hoeken zie ik als een risico. Een opiniestuk van filosoof Maarten Boudry [^boudry] in de context van het corona-skepticisme roept hier ook toe op en hij verwoordt het een stuk beter dan ik hier kan. In een openingscollege voor een leerstoel aan de Universiteit Gent gaat hij hier ook verder op in [^boudry2].
Uiteraard kan in de wetenschap alles ter discussie worden gesteld, een kritische vragende houding is noodzakelijk voor goede wetenschap. Dat moet ook zo. Dat verschillende opvattingen flink kunnen schuren zit ook in haar aard. Ik zal verder ook de laatste zijn die zal ontkennen dat er niet veel fouten gemaakt worden, geklungeld wordt, en soms andere belangen meespelen die objectiviteit in de weg zitten. Dat wetenschap op punten te diep met commercie of politiek vervlochten is, is een zeer terecht punt van aandacht. Je ziet het OMT ook af en toe worstelen met druk vanuit de politiek [^volkskrant2]. Zoals ik al zei, het is een onvolmaakt proces want het is uiteindelijk mensenwerk van een grote diverse groep wetenschappers, en niets menselijks is hen vreemd. Een zekere marge van twijfel, onzekerheid en nuance is ook inherent aan wetenschappelijke output.
Kritiek</h2>
Vanuit corona-kritische hoek mis ik soms dit besef; men lijkt geneigd zich op een aantal specifieke bomen blind te staren en het bos te missen, of in extreme gevallen het bestaan van het gehele bos te ontkennen. Er zullen ook altijd wetenschappers zijn die wat verder van de heersende consensus af staan, als die er is, en dat is op zich ook prima juist. Hun argumenten moeten nog steeds op hun eigen wetenschappelijke waarde beoordeeld worden, maar de buitenstaande leek moet dan wel oppassen niet te snel met die argumenten aan de haal te gaan en de nuance te missen. Hier gaat het vaak fout naar mijn idee. Als leek zijn we denk ik extra gevoelig voor 'confirmation bias', het aanhangen van bepaalde theorieën omdat ze met ons resoneren en in ons straatje liggen, ook al zijn ze wellicht onjuist. Dit geldt denk ik extra sterk als er heftige emoties (bv. woede of angst) mee verbonden zijn.
Ik vind het retraction paper van Borger et al. zo'n voorbeeld waar veel te veel mee aan de haal wordt gegaan door corona-critici, zoals bijvoorbeeld op het Youtube kanaal BLCKBX van Flavio Pasquino die hier de kwalificatie PCR-gate aan geeft, alsof er een groot schandaal achter schuilt. Borger et al. [^borger2019] claimen serieuze fouten te hebben gevonden in het paper van Corman et al. [^corman2019] wat op haar beurt een belangrijk grondwerk is voor de PCR test ter detectie van het coronabesmetting. Ze vinden de fouten zo serieus om terugtrekking van dat paper eisen, een zwaar middel. Het paper van zowel Borger et al. als Corman et al. is voor de leek, ook voor mij dus, eigenlijk niet goed te beoordelen. Sommige kritiek klinkt al snel best redelijk, maar is hij dat daadwerkelijk? Het antwoord van de editors van het journal [^eurosurveillance] verwerpt stellig beschuldigingen die gedaan zijn met betrekking tot belangenverstrengeling en het (zeer snelle) beoordelingsproces. Er zijn externe experts ingeschakeld die de inhoudelijke kritiek hebben beoordeeld en ook daar geconcludeerd hebben dat het Corman paper adequaat was voor haar doel en in de tijdsperiode van beperkte data waarin het onderzoek plaatsvond. De review van de geraadpleegde experts in deze is helaas niet openbaar. Dat vind ik wel jammer en deels ook een gemiste kans waar ik vrees dat sommige coronaskeptici onterecht kwade wil inzien. Op zich is het vanuit de normale gang van zaken best te begrijpen, want reviews zijn vrijwel nooit openbaar en ook de auteurs zelfs zien niet wie hun reviewer is. Omgekeerd weten zelfs de reviewers idealiter ook niet wie de auteur is (double blind), en dat was hier ook het geval. Ik geef toe dat ik niet weet in hoeverre een retraction procedure hier verschilt van een normale review. Wat ook nog wil toevoegen is dat het uiteraard ook niet de bedoeling dat wetenschappelijke geschillen via retraction requests beslist worden, éénieder kan immers altijd het onderzoek van de ander herhalen, verbeteren en bekritiseren in een nieuwe publicatie. Retractions zijn voor grove fouten, belangenverstrengeling, plagiaat, e.d...
Terug naar de inhoud: gelukkig zijn er verschillende andere wetenschappers die wel in dit vakgebied bekwaam zijn en hun kritiek op Borger et al. al wel kenbaar gemaakt hebben [^mckay] [^koopmans] [^publikum] [^visser] [^beyer] [^kloptdatwel] [^wilson]. Ook Follow The Money raadpleegde experts en wijdde er onlangs een uitgebreid artikel aan om het voor het grotere publiek op een rij te zetten en behandelt elk punt van kritiek [^ftm].
Een veelgehoord argument uit onder ander dat retraction paper is dat de PCR-test te veel vals-positieve uitslagen zou opleveren [^mckay] en dat veel besmette mensen niet besmettelijk zouden zijn. Het is inderdaad een bekend gegeven dat de test geen actieve besmettelijkheid aantoont maar slechts aangeeft of de persoon het virus bij zich draagt (wat een noodzakelijke voorwaarde voor besmettelijkheid is). In het aantonen van (fragmenten van) het virus heeft de test juist een zeer hoge sensitiviteit [^sciencefeedback]. Om maar één punt uit te weerlegging als voorbeeld te nemen: Als er een significante aantal vals-positieve uitslagen zou zijn zou je dat ook verwachten in landen als Australië, Nieuw Zeeland en Ijsland, die een erg lage true positive rate hebben terwijl er nog steeds veel getest wordt [^ourworldindata] [^wilson2]. Ook in Nederland zien we met name na de piek van eerste golf en de naderende zomer ook duidelijke perioden van stijgende testafname met een dalend aandeel positieve uitslagen.
In de context van een snotterende persoon die voor een test aanklopt of iemand die nog asymptomatisch is maar recentelijk (incubatietijd) wel in contact met een besmette persoon geweest is, heb je sterke grond om besmettelijkheid te veronderstellen als de test een positieve uitslag geeft. In zo'n situatie neem je het zekere voor het onzekere, want in het kader van het terugdringen van verspreiding van een virus is een vals positieve uitslag minder ernstig dan een vals negatieve. Terugdringen van verspreiding is de primaire grond voor het testen en ook door het WHO aanbevolen [^reuters]. Uiteraard wil je dat de test zo nauwkeurig mogelijk is en zo goed mogelijk gehanteerd wordt [^mckay2], de vraag of het beter kan is nooit onterecht. De instrumenten die je hebt uit handen gooien omdat ze wellicht niet perfect zijn, is wel onterecht. De besmettingscijfers die we dagelijks langs zien komen geven een goede indicatie van waar en hoe ver het virus zich onder de populatie verspreid heeft en geeft ons de mogelijkheid geïnformeerde schattingen te doen over het aantal ziekenhuisopnamen, IC-opnamen en sterfgevallen later in de tijd. Er is ook een duidelijk correlatie tussen deze curves. De waarde zit dan ook met name in dit aspect en het feit of de trend stijgend of dalend is, dan in de absolute getallen an sich.
Een ander veel gehoord kritiekpunt zit hem in het feit dat men uitgaat van zulke modellen om maatregelenbeleid op te baseren, en de claim dat de modellen er vaak naast zitten. Ik begin met het eerste punt. Als je enige voorspellingen wil doen over de toekomst ontkom je er nooit aan met modellen te werken, harde cijfers over de toekomst heb je nog niet want het is nog niet gebeurd. Je extrapoleert op basis van beschikbare data uit het verleden wat de toekomst kan brengen. Uiteraard geldt ook hier dat je wil dat je model zo nauwkeurig mogelijk is, en ben je je ervan bewust dat er altijd een zekere onzekerheidsmarge mee gemoeid is. Bij nieuwe data stel je je model bij. Het is in deze aan de epidemiologen, virologen, artsen e.d. om modellen te formuleren naar het beste van hun kunnen. Mijn repliek hier is dus; aan modelleren ontkom je niet, zeker niet in beleidsvoering, want beleid gaat per definitie over het sturen van toekomstige ontwikkelingen. Als je niet extrapoleert maar wacht met maatregelen tot de werkelijkheid je heeft ingehaald en wacht tot bv. de IC's vol liggen, dan ben je te laat met je maatregelen. Je gaat niet pas nieuwe dijken bouwen als de oude doorbreekt.
Nu zouden modellen vaak niet kloppen zeggen de skeptici. Zeker in het begin van de pandemie zal dit ongetwijfeld veel het geval geweest zijn, want er was nog weinig data en heel veel onzekerheid. Nog steeds is er heel veel onbekend, zeker met de opkomst van mutaties als B.1.1.7 die zich anders gedragen; de onzekerheidsmarges zijn groot. Kijk bijvoorbeeld naar een aantal mogelijke prognoses van het Duitse Robert Koch Instituut [^sueddeutsche]. We zien veelal zulke modellen met schrikbarende exponentiële curves die uiteindelijk ver boven de zorgcapaciteit uitstijgen, uiteraard weer met een zekere onzekerheidsmarge. Op basis van die modellen wordt strikter maatregelenbeleid gemaakt die juist de voorspelling van het model probeert te voorkomen. Als je na het nemen van die maatregelen dan concludeert dat het model er faliekant naast zat en het dus allemaal wel meevalt omdat het doemscenario niet waarheid is geworden, dan heb je de verkeerde conclusie getrokken. Het model op haar juiste waarde schatten is een stuk complexer dan dat. Maarten Boudry schetst dit wederom mooi in het artikel was ik al eerder aanhaalde [^boudry].
In het nemen van maatregelen in een pandemie waarvan sprake is van veel onzekerheid in de modellen, geldt ook een zekere mate van "better safe than sorry". We proberen een punt in de tijd te vinden waar maatregelen effectief zijn tegen de voorspellingen, en vooral de ergste voorspellingen daarmee te voorkomen. Tegelijkertijd moet dat punt in de tijd zo liggen dat de maatregelen proportioneel zijn en nevenschade minimaal is. Dit maakt het juiste tijdstip voor de juiste maatregel vinden een ingewikkelde opgave. Het is sowieso een kwestie van kiezen tussen twee kwaden, want linksom of rechtsom zal er schade zijn; "damned if you do, damned if you don't", om er nog maar eens een Engelse expressie tegenaan te gooien.
Als je liever naar het verleden terug wil kijken dan de toekomst wil modelleren, zijn er genoeg voorbeelden van exponentiële groei en overstroming van de zorg te vinden. In Nederland zien we zelf al dat we massaal IC's moesten opschalen tijdens de eerste golf en het tij maar net op tijd hebben kunnen keren. De plotselinge opkomst van de besmettelijkere B.1.1.7 variant in o.a. Engeland, Ierland en met stip Portugal, heeft daar tot grote verzadiging van de zorg geleid, inclusief rijen wachtende ambulances. In Portugal en Ierland ging dat ook gepaard met ongelukkige versoepelingen van de maatregelen rondom kerst, waarbij het daardoor onduidelijk is wat nu daar aan toe te schrijven is aan hogere besmettelijkheid van de mutaties, en wat aan de versoepelingen. In het VK moest Boris Johnson zijn volk teleurstellen en de reeds beloofde versoepelingen niet door laten gaan.
Een grote kwestie in de virusverspreiding is de factor asymptomatisch danwel presymptomatische verspreiding. Het beeld hierom is voor mij nog niet helemaal duidelijk, er lijken hier soms ook conflicterende data over naar buiten te komen [^cnn]. Aanvankelijk werd het aandeel sowieso groter ingeschat dan gedacht. Een video van Dr. John Campbell [^campbell2] geeft een hele aardige bespreking van een aantal studies op dat gebied, maar dateert wel van Augustus 2020. Hij legt daarin uit dat studies aantonen dat besmettelijkheid (of preciezer gezegd viral load, wat niet hetzelfde is maar een stuk meetbaarder) het hoogst is vlak voor en vlak na het begin van symptomen. Die symptomen kunnen in eerste instantie ook nog licht zijn. Een latere studie van Cao et al. [^cao2020] in Wuhan identificeert juist geen enkele besmetting rondom asymptomatische dragers, wat op het eerste oog een opmerkelijk resultaat lijkt. Hier moet wel meegenomen worden dat dit in een context onderzocht is waar de pandemie na een lange zeer strikte lockdown onder controle is gebracht. De auteurs zeggen zelf ook dat hun bevindingen niet zomaar generaliseerbaar zijn en dat de studie niet aantoont dat het virus niet door asymptomatische dragers verpreid kan worden [^bmi]. Presymptomatische verspreiding is immers ook bij andere luchtweginfecties als influenza gebruikelijk [^gu2011]. Afin, dit is niet mijn vakgebied en hier is het beeld voor mij dus ook nog niet helemaal duidelijk. Wel is asymptomatische en presymptomatische verspreiding een zeer belangrijke overweging in het coronabeleid, en ook een mikpunt voor coronacritici, en zou het goed verklaren waarom juist dit virus zo'n pandemische vorm heeft aangenomen.
Een opiniestuk over coronaskepsis in Nederland zou onvolledig zijn zonder Maurice de Hond even kort te noemen. Hij is bekend van zijn opiniepeilingen maar heeft ook omtrent corona een zeer duidelijk mening die geregeld ingaat tegen overheid en OMT, en die hij niet schroomt te delen op zijn daarvoor ingerichte blog [^maurice] en in de media. Zo bepleit hij dat verspreiding vooral via aerosolen gaat, daar waar de gangbare consensus grotere druppelvorming als de voornaamste verspreidingsroute ziet [^who], en is hij daarom voorstander van goede ventilatie. Voor goede ventilatie is ook wel degelijk het één en ander te zeggen uiteraard. Hij opereert mijns inziens in een wat grijs gebied tussen terechte criticus, opiniemaker, maar ook zakenman en soms zelfs complotdenker. Viroloog of epidemioloog is hij zeer zeker niet, maar het zou te makkelijk hem daarom weg te zetten waartoe dit NRC artikel [^nrc2] of de TV rapportage van Propaganda [^kroncrv] wel neigen. Hij haalt wel degelijk serieuze kritiek aan op bepaalde punten, maar het probleem is hier vaak om dat te kunnen scheiden van de punten waar hij de plank misslaat en de echte experts een andere mening toegedaan zijn. De grote stelligheid en overtuiging waarmee hij zijn beweringen over het algemeen doet maakt het niet makkelijk dit onderscheid te maken.
Ik denk dat het belangrijk is om desinformatie en het daaruit voortvloeiende wantrouwen tegen te gaan. Er is in deze tijd een ruime voedingsbodem voor desinformatie door de grote impact van maatregelen. De pandemie legt ook nog eens als katalysator pijnpunten in ons systeem bloot die eerder verborgen bleven. Men is moe en lijdt begrijpelijkerwijs onder alle gevolgen. Hier zie ik een risico dat onvrede over de maatregelen iemand ontvankelijker kan maken voor desinformatie omtrent het virus an sich. Als er immers geen virus is, of het virus is lang niet zo erg als gedacht en de fundamenten onder het testbeleid deugen niet, dan kunnen die maatregelen ook wel weg. Mijn inschatting zou zijn dat sommige corona-critici op deze manier achterstevoren redeneren en hiermee het virus voor zichzelf en anderen bagatteliseren. Het resultaat is dan denk ik wel een erg wantrouwende houding richting wetenschap, media en overheid die constant een beeld propageren dat niet strookt met het eigen beeld.
Een extra gevaar hierbij is dat dit wantrouwen zich naast het virus en de maatregelen ook op de belangrijkste oplossing richt: de vaccins. Een hoge bereidheid om te vaccineren is juist nodig om uiteindelijk van alles maatregelen af te komen. De antivaxxer bestond ook al lang voor corona, met bv. de hardnekkige mythe dat het autisme zou veroorzaken, maar ook in corona skeptische kringen als bij de groep Viruswaarheid wordt zo'n antivax houding aanwakkerd.
Ik denk dat we een duidelijk onderscheid moeten maken tussen kritiek op specifieke maatregelen, of kritiek tegen maatregelen in het algemeen en tegen de wetenschappelijk consensus in het bijzonder. Het is één ding om het virus wetenschappelijk te duiden en het effect van potentiële maatregelen in te schatten, zoals het OMT doet. Het is weer een hele andere tak van sport om daadwerkelijk beleid te voeren. In het voeren van beleid komen terecht meer vraagstukken op tafel dan alleen de medisch-epidemiologische, terwijl het OMT zich juist tot de medisch-epidemiologische dient te beperken, want alleen daar ligt haar expertise. Voor kritiek tegen maatregelen en overheids in het algemeen is ook plaats zonder de wetenschappelijk consensus rondom het virus te ontkennen. Er is ook ruim plek voor onzekerheid en twijfel, maar wellicht is dit juist het pijnpunt voor sommige mensen en kiezen ze liever voor de schijnzekerheid dat het wel meevalt en men het en masse fout heeft.
Complot</h2>
Bij sommige mensen is sprake van een soort van radicaliseringsproces dat leidt tot heus complotdenken. Mensen als Willem Engel en zijn Viruswaarheid lijken redelijk van het pad af als ze vergelijkingen met Jodenvervolging en genocide maken en daarbij ook nog een davidster opspelden tijden demonstraties. Voor de hard-core complotdenker is corona is niet langer iets dat ons zomaar is overkomen, maar iets waarachter kwade intenties zitten. Het is bijvoorbeeld gefabriceerd en uit een lab ontsnapt, zoals Willem Engel terloops maar stellig beweert in de talkshow Op1 [^op1], of het is helemaal geen virus maar de ziekte komt door de 5G masten, of het is slechts een list zodat Bill Gates ons allemaal een microchip kan injecteren! Dit zijn extremen maar zo'n radicaliseringsproces is vaak wel een glijdende schaal die leidt tot dieper geloof in het eigen gelijk en steeds wantrouwende houding jegens de ander. Dit is een ontwikkeling waar ik mij ernstige zorgen over maak want mensen drijven zo steeds verder af van een genuanceerd en op wetenschap gestoeld wereldbeeld richting steeds extremere visies waarin de kwade intenties van de gevestigde orde vaak de hoofdrol spelen. Dit heeft consequenties in de reële wereld. Ik denk dat de Capitoolbestorming in de VS een goed voorbeeld is dat laat zien dat complotdenken wel degelijk massa's aanhangers in beweging kan zetten en gevestigde instituties in gevaar kan brengen. Het compleet afbreken van allerlei gevestigde instituties is juist vaak expliciet het doel van de complotdenker [^nrc], om ze daarna naar eigen utopisch wereldbeeld op te bouwen. Het is een kwalijke ontwikkeling als politici, wetenschappers, en journalisten in de reeële wereld bedreigingen ontvangen, vanuit welke extremistische hoek dan ook. We zien dat de NOS besloot logo's van hun busjes te moeten halen. We zien mensen (inclusief presidenten) die alles wat ze niet bevalt als fakenews bestempelen en zo elk debat uit de weg gaan. We zien leden van het OMT die bedreigingen ontvangen en bescherming moeten krijgen omdat een marginale groep ze ziet als een sinister complot.
Een probleem dat ik heb met de complotdenker in het algemeen is dat hij naar mijn mening veel te geneigd is overal (kwaad) agentschap in te zien; de dingen zijn zoals ze zijn omdat iemand dat zo gewild en georchestreerd heeft. Het gaat uit van een onterecht grote mate van maakbaarheid van de samenleving waarin de rol van toeval en het toelaten van twijfel en nuance wordt gemarginaliseerd. Natuurlijk leven we in een wereld van mensen met allerlei botsende intenties, en veel van die intenties zullen best op eigen gewin gericht zijn en niet erg altruïstisch van aard zijn; de geschiedenis staat immers ook bol van oorlog en corruptie. Desalniettemin gaat het vaak te ver om daar één overkoepelende regie in toe te kennen, de mate van regie wordt door de complotdenker sterk overschat denk ik. De gehele samenleving met al haar instituties, ook al zijn ze door mensen zelf bedacht en opgericht, zijn toch ook aan een zekere evolutie onderhevig en kan je in zekere zin bezien als een chaotisch systeem waarin echte regie ontbreekt.
Een complot impliceert vaak ook een hoge mate van geheimhouding tussen de samenzweerders, zo'n deceptie op wereldniveau volhouden zou een bijna onmenselijke opgave zijn. De meeste misstanden in de wereld hebben geen sinistere 'deep state' nodig maar vinden vrij open en bloot plaats. Daar waar er sterke een autoritaire staat is en 'geheime' veiligheidsdiensten een grote vinger in de pap hebben, neem China en Rusland als voorbeeld, is dit vaak overduidelijk. Ook als er wel een complot van de zijde van de machthebbers komt dit vaak snel aan het licht, neem bijvoorbeeld het gebrekkige bewijs tegen massavernietigingswapens waarmee de VS ons in 2003 de Irak oorlog in gerommeld heeft, of de vergiftiging van Aleksej Navalnij en het daarop volgende show-proces onlangs.
Ik zie in de complotdenker ook een zeker arrogantie; het idee dat hij, met een kleine groep trouwe volgers, de waarheid in petto heeft daar waar de 'mainstream' het geheel bij het verkeerde eind heeft, terwijl de experts juist, per definitie zou ik zelfs zeggen, in de mainstream zitten. Iets meer zelf-skepsis zou op zijn plaats zijn. In de coronakwestie roept de complotdenker vaak op tegen een angstcultuur die gezaaid zou worden door de overheid, maar met hyperbolen als vergelijkingen met de tweede wereldoorlog en dictaturen draagt de complotdenker mijns inziens net zo goed bij aan een angstcultuur. Het realiteitsbeeld dat de complotdenker schets waarin we door duistere machten gemanipuleerd worden vind ik eerlijk gezegd beangstigender overkomen dan die van een pandemie.
Het helpt natuurlijk ook niet als er wel degelijk signalen van het bevorderen van een angstcultuur naar boven komen zoals in het Duitse Panikpapier schandaal wat door Die Welt aan het licht is gebracht [^welt]. Wetenschappers waren gevraagd om voor het Duitse ministerie van binnenlandse zaken in een intern document worst-case scenario's uit te werken die strikte corona-maatregelen rechtvaardigen. Een ietwat overijverige ambtenarij? Dit klinkt als 'wetenschap op bestelling' en is natuurlijk kolen op het vuur als je al een kwade overheid en corrupte wetenschap verondersteld. Hoewel ik zeker ook van mening ben dat de Duitse ambtenaren en de wetenschappers die hieraan mee deden hier wel degelijk een misstap hebben begaan, denk ik ook dat er meer nuance in deze zaak zit dan in eerste instantie lijkt [^gunnarkaiser]. Een complotdenker is waarschijnlijk geneigd hier snel een gegeneraliserende conclusie aan te verbinden, onder het motto "waar rook is, is vuur". Maar mijn stelling is eerder omgekeerd: het rookt overal wel een beetje, en het is ook zeer terecht dat aan de kaak te stellen, maar dat betekent nog niet dat alles ook in lichterlaaie staat. Ik vermoed dat er veel voorbeelden te vinden zijn waar complottheorieën wel degelijk deels op aantal terechte feitelijke kritiekpunten stoelen, maar de complottheorie zelf veel te ver gaat. De kunst is juist vaak om de desinformatie van de echte feitelijkheden te onderscheiden, en dat is zeker niet altijd zo simpel als het lijkt.
Na dit alles gezegd te hebben wil ik tot slot nog meegeven dat we zeker ook moeten oppassen niet gelijk iedereen met kritiek als 'complotdenker' of 'wappie' te bestempelen en diskwalificeren, dit betoogde ik al in mijn vorige artikel</a> en dat is zeker ook niet mijn intentie met dit stuk. We moeten juist eventueel onjuiste argumenten feitelijk ontkrachten, scheiden van terechte zorgen die er wellicht aan ten grondslag liggen, en vooral niet de hele groep als zodanig proberen te negeren en denken dat het wel over gaat.
Maatregelen</h2>
Hoewel ik zelf in de gelukkige positie ben dat de maatregelen geen al te grote impact hebben, besef ik goed dat dit voor veel andere mensen niet zo is. Er zijn reële zorgen op allerlei vlakken die niet onderschat mogen worden. Van de economische schade van alle bedrijven die gedwongen gesloten zijn tot aan mentale schade in de vorm van bijvoorbeeld eenzaamheid, angst en depressie. Ik onderken deze ernst ook zeker. Hoe langer de situatie ook voortduurt, hoe zwaarder het wordt het vol te houden. Feit dat de maatregelen ondanks nevenschade doorgaan wil ook niet zeggen dan deze mensen niet gehoord worden, het blijft een constante afweging tussen de volksgezondheid en de andere belangen. Mijn impressie is dat deze aspecten ook steeds meer en meer in de media aan bod komen. De bewering van de corona-criticus is vaak dat het medicijn erger is dan de kwaal, maar dat is juist niet evident en ook iets wat per situatie (land/tijdsduur/maatregelenpakket) zal verschillen en aan constante heroverweging onderhevig is.
Er is ook genoeg te bekritiseren op het optreden van de overheid, er gaan geregeld dingen fout. Van de langzame vaccinatie tot het datalek bij de GGD en de blamage rondom de juridische grondslag voor de avondklok. Ook zal de ene groep vinden dat er harder opgetreden had moeten worden, terwijl de andere groep bijvoorbeeld vanuit een principiëelere grondslag tegen inperkingen van vrijheid is. Die verschillen mogen er ook zijn. Hoewel we natuurlijk fouten moeten proberen te voorkomen en uit gemaakte fouten moeten leren, moet een zekere foutmarge zelfs de overheid gegund zijn.
Ik denk dat de meest succesvolle landen in het onder controle houden van de pandemie vaak de landen zijn die vrij snel en met vrij forse maatregelen reageren zodra het virus opduikt. Ik denk aan landen als Taiwan, Zuid-Korea, Nieuw Zeeland. Feit dat het effectief eilanden zijn, en twee ervan lessen hebben geleerd tijdens de eerste SARS epidemie, speelt wellicht ook mee in dit succes. Zij zijn in staat het virus zo goed als uit te bannen waarna ze slechts constant de vinger aan de pols hoeven te houden en eventuele oplevingen de kop indrukken. Ik denk dat als je die strikte maatregelen maar zeer lokaal of voor korte duur hoeft toe te passen, de nadelige gevolgen beperkter zijn dan wanneer het maanden doorsukkelt en je met grof geschut werkt om de cijfers weer controleerbaar te krijgen.
Dat maatregelen als lockdowns überhaupt niet zouden werken wordt soms ook opgevoerd. Dat zou wat mij betreft alleen het geval kunnen zijn als ze er niet in slagen het aantal contactmomenten tussen potentieel besmettelijke mensen significant te verlagen, dus als mensen zich er en masse niet aan houden. De effectiviteit van lockdowns is uiteraard gelijk al een onderwerp van onderzoek geweest [26]. Dat het niet altijd even makkelijk te evalueren is in een context van meerdere maatregelen, is evident. Of een lockdown een proportioneel of geëigend middel is laat ik hier nog even buiten beschouwing, daar kan je kritiek heb hebben. Als je een hypothetische lockdown in extrema zou doen en iedereen in een eigen cel opsluit zodat niemand meer met niemand in contact komt gedurende een periode die de incubatietijd goed overschrijdt, dan heb je het virus in relatief korte tijd uitgebannen. Praktisch en ethisch compleet onuitvoerbaar uiteraard, maar het idee van contacten tussen mensen beperken lijkt me per definitie ook de verspreiding van mens-op-mens overdraagbare virussen tegengaan. In deze corona-periode lijkt influenza overigens ook compleet uitgebannen [^volkskrant]. Een Nieuw Zeelandse studie toont ook aan dat de maatregelen daar prima tegen influenza werken [^huang2021], wat niemand denk ik zal verbazen.
In Europa viel Zweden in eerste instantie een buiten de boot doordat ze minder strenge maatregelen afkondigden en meer dan anderen appelleerde op het eigen verantwoordelijkheidsgevoel van de bevolking, wat ik op zich ook wel mooi vind en zeker voorstander van ben, als het werkt. In Nederland hebben we soortgelijke appellen gedaan maar zijn we uiteindelijk toch richting dwingendere maatregelen moeten gaan, in Zweden uiteindelijk ook. In vergelijking met de andere Scandinavische buren komt Zweden ook beduidend slechter uit de bus. Het relatieve dodental ligt daar beduidend hoger als in alle omringende Scandinavische landen, die wel striktere lockdowns hebben afgekondigd. Vaak is het lastig maatregelenpakketten in verschillende landen te vergelijken, maar deze landen liggen socio-economisch juist erg dicht bij elkaar waardoor je hier wat beter conclusies kan trekken over de effectiviteit van aan aantal maatregelen waaronder de lockdown. Het is uitzonderlijk dat zelfs de Zweedse koning oppert op televisie dat ze gefaald hebben in hun coronabeleid [^svt].
In Duitsland zie je dat men zeer vergelijkbare maatregelen hanteert als hier, ook al hebben ze een beduidend hogere IC capaciteit en zijn ze nooit bij kritieke bezetting geweest. Men beseft simpelweg dat als het virus eenmaal te veel verspreidt, dat het dan heel snel uit de hand loopt en ook hun systeem uit haar voegen zal barsten. Zicht en controle behouden is essentieel.
Idealiter heb je een verstandige bevolking die die netjes thuisblijft als men ziek is, om de ander niet te besmetten. Ik vrees dat we hier wat minder optimistisch moeten zijn als we signalen horen van onderzoeken waarin mensen met klachten toch naar buiten of zelfs naar het werk gaan [^rtl2]. Ik vind het persoonlijk ook erg betuttelend als de overheid ons berispt dat we ons niet goed genoeg aan de te regels houden, maar het is blijkbaar nodig. Naast de groep van mensen die het niet zo nauw nemen hebben we, zoals ik eerder al behandelde, ook de mensen die zich er simpelweg (nog) niet bewust van zijn dat ze besmet danwel besmettelijk zijn. Juist vanwege deze ongrijpbaarheid zijn er grootschalige preventieve maatregelen als afstand houden, groepsbeperking en mondkapjes ingevoerd.
Met name de situatie waar we nu in zitten voelt voor veel mensen erg tegenintuïtief, alle cijfers lijken te dalen, en toch zijn we zelfs een avondklok ingegaan. Het is logisch dat dat vraagtekens oproept. Bij de critici die het handelen van de overheid hierin toch al niet vertrouwen, roept het al snel grote verontwaardiging en zelfs woede op. De maatregel is immers ook extreem grof en heftig.
Wij zijn geen China, en beperkingen op onze vrijheid raken ons vrij fundamenteel. Ik geloof ook niet dat de overheid zulke maatregelen graag oplegt, zoals sommige complotdenkers beweren, maar het als een noodzakelijk kwaad zien. Dat de maatregelen ook grote schade aanrichten lijkt me evident, maar verdedigbaar om nog grotere schade te voorkomen. Dit is geen makkelijke afweging en is er een die we ook keer op keer opnieuw moeten blijven maken. Ik heb alle begrip voor kritiek op maatregelen en voor zelfs principiële rode lijnen waar niet overheen gegaan kan worden ongeacht de consequenties. Voor sommige ligt die bij de avondklok, een maatregel waar ik principieel ook erg veel moeite mee heb. Voor anderen is die al lang gepasseerd of ligt die pas later bij bv. het actief monitoren en ingrijpen "achter de voordeur" bij mensen thuis. Dat zou voor mij zo'n principiële lijn zijn. Voor de maatregelen die we wel nemen moeten we altijd zeer waakzaam blijven dat ze tijdelijk en doelgericht zijn, en geen precedent scheppen waar later misbruik van gemaakt kan worden.
Conclusie</h2>
De wijdverbreide consensus, waar ik me bij aansluit, is dat het virus en de daaruit voortkomende pandemie een zeer reëel probleem vormen waar niet te lichtzinnig mee omgegaan moet worden. Dat het middel erger zou zijn dan de kwaal bestrijd ik. Ik vind ook dat critici vooral geneigd zijn de kwaal weg te relativeren in plaats van betere oplossingen te suggereren. Overheden hebben een terechte opgave om in deze kwestie pro-actief de volksgezondheid te beschermen.
Skeptisch de wetenschap volgen is uiteraard goed, maar vertrouwen hebben in de consensus die daaruit voorkomt is een essentiële component hierin. Maarten Boudry formuleert het mooi als “Wetenschap is de juiste balans tussen twijfel en vertrouwen” [^boudry2]. Ik onderstreep alle menselijke gebreken die ook wetenschappers eigen zijn maar vertrouw erop dat deze in het grote geheel eerder gladgestreken dan uitvergroot worden. Ik verklaar de wetenschap en de wetenschapper zeker niet heilig, maar zij zijn de beste manier om de wereld te duiden. Ik onderken ook het feit dat de media de wetenschappelijke output zeker niet altijd met de juiste nuance vertolkt en dat er zowel in media als politiek uiteraard conflicterende belangen kunnen spelen. De rolverdeling moet altijd zijn dat de politiek regeert, de wetenschap adviseert, en de journalistiek rapporteert en controleert. Men moet hier niet op elkaars stoel gaan zitten.
Het gevaar van 'confirmation-bias' of 'cherry-picking' liggen al snel op de loer, ook voor de wetenschapper, maar helemaal voor de leek. Het is lastig om wetenschappelijke geluiden die tegen de consensus ingaan op hun juiste waarde te schatten als je de breedte van het veld niet goed in beeld hebt. Het is juist die breedte die de consensus vormt. We zijn allemaal snel geneigd tot zelfoverschatting en tot het in een positieve-feedback loop geraken waar het om onze overtuigingen gaat. Als we ruim gedragen consensus overboord zetten terwijl we zelf geen experts in de materie zijn, dan draagt dit een extra risico dat we het bij het verkeerde eind hebben.
Referenties</h2>

[^campbell] John Campbell, Youtube kanaal https://www.youtube.com/c/Campbellteaching</a></li>
[^vpro] VPRO Tegenlicht wijdde hier onlangs een interessante aflevering aan: https://www.vpro.nl/programmas/tegenlicht/kijk/afleveringen/2020-2021/zorgen-voor-morgen.html#</a></li>
[^rtlnieuws] RTL Nieuws - Kuipers: geen enkel zorgsysteem kan snelle verspreiding Britse coronavariant aan https://www.rtlnieuws.nl/nieuws/nederland/artikel/5208327/kuipers-geen-enkel-zorgsysteem-kan-zeer-snelle-verspreiding-aan</a></li>
[^expresso] Expresso - “É para isso que servem os amigos”: a equipa médica alemã já está em Portugal https://expresso.pt/coronavirus/2021-02-03-E-para-isso-que-servem-os-amigos-a-equipa-medica-alema-ja-esta-em-Portugal</a></li>
[^cmjornal] CM - Avião-hospital pronto a levar doentes portugueses com Covid-19 para a Alemanha https://www.cmjornal.pt/sociedade/detalhe/aviao-hospital-pronto-a-levar-doentes-portugueses-com-covid-19-para-a-alemanha</a></li>
[^redebrasil] Rede Brasil Atual - Hospitais de Manaus ficam sem oxigênio, dois dias depois de Pazuello pressionar por cloroquina https://www.redebrasilatual.com.br/saude-e-ciencia/2021/01/manaus-fica-sem-oxigenio-dois-dias-depois-de-ministro-oferecer-cloroquina/</a></li>
[^folhapatoense] Folha Patoense - Pacientes fogem dos hospitais de Manaus para ‘morrer em casa’ http://www.folhapatoense.com/2021/01/20/pacientes-fogem-dos-hospitais-de-manaus-para-morrer-em-casa/</a></li>
[^amazoniareal] Amazônia Real - Pandemia no Amazonas: Manaus volta a registrar mortes em casa https://amazoniareal.com.br/manaus-volta-a-registrar-mortes-em-casa/</a></li>
[^guardian] The Guardian - 'Utter disaster': Manaus fills mass graves as Covid-19 hits the Amazon' https://www.theguardian.com/world/2020/apr/30/brazil-manaus-coronavirus-mass-graves</a></li>
[^sabino2021] Ester C Sabino, Lewis F Buss, Maria P S Carvalho, Carlos A Prete Jr, Myuki A E Crispim, Nelson A Fraiji et al. (2021). Resurgence of COVID-19 in Manaus, Brazil, despite high seroprevalence. The Lancet. DOI:https://doi.org/10.1016/S0140-6736(21)00183-5</a></li>
[^flaxman2020] Flaxman, S., Mishra, S., Gandy, A. et al. (2020). Estimating the effects of non-pharmaceutical interventions on COVID-19 in Europe. Nature 584, 257–261. https://doi.org/10.1038/s41586-020-2405-7</a></li>
[^volkskrant3] Volkskrant - Ook maanden na corona nog extreem moe: ‘Dit is een nieuwe ziekte. En een buitensporige’ https://www.volkskrant.nl/wetenschap/ook-maanden-na-corona-nog-extreem-moe-dit-is-een-nieuwe-ziekte-en-een-buitensporige~bd35c456/</a></li>
[^cbs] CBS Jaaroverzicht 2020 https://www.cbs.nl/nl-nl/achtergrond/2020/53/jaaroverzicht-2020</a> . Voor een aantal Europese landen: https://www.euromomo.eu/graphs-and-maps#excess-mortality</a> . Het CBS heeft ook een mooi filmpje met uitleg over de berekening gemaakt: https://www.youtube.com/watch?v=6E5e2PbvmwA</a></li>
[^sargasso] https://sargasso.nl/hoe-fvd-met-visuele-trucs-sterfte-door-corona-wegpoetst-oversterfte/</a></li>
[^blackburn2021] Blackburn et al (2021) - Infection Fatality Ratios for COVID-19 Among Noninstitutionalized Persons 12 and Older: Results of a Random-Sample Prevalence Study - https://www.acpjournals.org/doi/full/10.7326/M20-5352</a></li>
[^levin2020] Levin, A.T., Hanage, W.P., Owusu-Boaitey, N. et al. Assessing the age specificity of infection fatality rates for COVID-19: systematic review, meta-analysis, and public policy implications. Eur J Epidemiol 35, 1123–1138 (2020). https://doi.org/10.1007/s10654-020-00698-1</a></li>
[^boudry] Maarten Boudry - Academici denken beter twee keer na voor ze hun gewicht verlenen aan corona-scepticisme - https://maartenboudry.be/2020/09/academici-denken-beter-twee-keer-na-voor-ze-hun-gewicht-verlenen-aan-corona-scepticisme.html</a></li>
[^boudry2] Maarten Boudry - “Wetenschap is de juiste balans tussen twijfel en vertrouwen” https://www.durfdenken.be/nl/ugenters/wetenschap-de-juiste-balans-tussen-twijfel-en-vertrouwen</a></li>
[^volkskrant2] Volkskrant - OMT-leden hadden zoveel moeite met de politieke druk dat ze overwogen op te stappen https://www.volkskrant.nl/nieuws-achtergrond/omt-leden-hadden-zoveel-moeite-met-de-politieke-druk-dat-ze-overwogen-op-te-stappen~bbff108c/</a></li>
[^borger2019] Borger et al (2019) - External Review and request to retract the paper of Corman et al, published in Eurosurveillance January 23, 2020. https://cormandrostenreview.com/retraction-request-letter-to-eurosurveillance-editorial-board/</a></li>
[^corman2019] Corman, V. M., Landt, O., Kaiser, M., Molenkamp, R., Meijer, A., Chu, D. K., Bleicker, T., Brünink, S., Schneider, J., Schmidt, M. L., Mulders, D. G., Haagmans, B. L., van der Veer, B., van den Brink, S., Wijsman, L., Goderski, G., Romette, J. L., Ellis, J., Zambon, M., Peiris, M., … Drosten, C. (2020). Detection of 2019 novel coronavirus (2019-nCoV) by real-time RT-PCR. Euro surveillance : bulletin Europeen sur les maladies transmissibles = European communicable disease bulletin, 25(3), 2000045. https://doi.org/10.2807/1560-7917.ES.2020.25.3.2000045</a></li>
[^eurosurveillance] https://www.eurosurveillance.org/content/10.2807/1560-7917.ES.2021.26.5.2102041</a></li>
[^mckay] Ian M. Mckay - The “false-positive PCR” problem is not a problem: https://virologydownunder.com/the-false-positive-pcr-problem-is-not-a-problem/</a></li>
[^koopmans] Dr. Marion Koopmans (co-auteur van het Corman paper) reageert zelf ook in een twitter draadje: https://twitter.com/MarionKoopmans/status/1333002771738611712</a></li>
[^publikum] Publikum - Wie man die „Drosten-PCR“ zu SARS-CoV-2 ganz einfach nicht widerlegt https://publikum.net/wie-man-die-drosten-pcr-zu-sars-cov-2-ganz-einfach-nicht-widerlegt/</a></li>
[^visser] Deze bijdrage is van na het antwoord van Eurosurveillance: Frank Visser - The Corona Conspiracy Part 24: PCR-Gate 2: When Lockdown Skeptics Pose as Expert Scientists http://www.integralworld.net/visser198.html</a></li>
[^beyer] Prof. Andreas Beyer heeft de kritiek van Borger et al punt-voor-punt inline becomentarieerd: https://www.researchgate.net/publication/348732878_Pseudowissenschaftliche_Kritik_an_einem_von_der_Berliner_Charite_veroffentlichten_Coronavirus_SARS-CoV-2-Test_publiziert_von_Peter_Borger_und_Koautoren_Pseudoscientific_criticism_on_a_Coronavirus_SARS</a></li>
[^kloptdatwel] Klopt dat wel? - Bedenkingen bij het ‘retraction paper’ voor de Corman-Drosten PCR-test https://kloptdatwel.nl/2020/12/02/retraction-paper-pcr/</a></li>
[^wilson] Video van moleculair bioloog Dr Wilson waarin hij de kritiek op de PCR-test behandelt: Were COVID PCR tests proven to be useless? No. - https://www.youtube.com/watch?v=kLODxwQj-ns</a></li>
[^ftm] Follow The Money - Vivisectie op een twijfelzaaier in dertien bedrijven https://www.ftm.nl/artikelen/peter-borger-pcr-test-corona</a></li>
[^sciencefeedback] https://sciencefeedback.co/claimreview/claim-that-high-pcr-test-sensitivity-inflates-covid-19-cases-wrongly-conflates-the-issue-of-contagiousness-with-the-presence-of-infection/</a></li>
[^ourworldindata] https://ourworldindata.org/coronavirus-testing</a></li>
[^wilson2] Dit punt komt ook duidelijk naar voren in een video van moleculair bioloog Dr Wilson waarin hij desinformatie van Dr. Mike Yeadon (een oud-medewerker van Pfizer populair in coronaskeptische kringen) weerlegt: https://www.youtube.com/watch?v=8u-H5ihH8is</a></li>
[^reuters] https://www.reuters.com/article/us-healthcare-coronavirus-who-idUSKBN2132S4</a></li>
[^mckay2] In corona-skeptische kringen gaat de claim rond dat zelfs het WHO waarschuwt voor PCR tests, een repliek daarop komt van Dr. Ian M. Mckay die stelt dat de skeptici meer in de WHO uitspraak lezen dan er is: https://virologydownunder.com/who-to-new-pcr-users-read-the-damned-manual/</a></li>
[^sueddeutsche] Die Unsichtbare Welle - https://www.sueddeutsche.de/wissen/coronavirus-mutante-b117-daten-1.5197700</a></li>
[^cnn] CNN - Iceland lab's testing suggests 50% of coronavirus cases have no symptoms https://edition.cnn.com/2020/04/01/europe/iceland-testing-coronavirus-intl/index.html</a></li>
[^campbell2] https://www.youtube.com/watch?v=bUfuF3Il4ik</a></li>
[^cao2020] Cao et al (2020) - Post-lockdown SARS-CoV-2 nucleic acid screening in nearly ten million residents of Wuhan, China - https://pubmed.ncbi.nlm.nih.gov/33219229/</a></li>
[^bmi] https://www.bmj.com/content/371/bmj.m4695</a></li>
[^gu2011] Gu, Y., Komiya, N., Kamiya, H., Yasui, Y., Taniguchi, K., & Okabe, N. (2011). Pandemic (H1N1) 2009 Transmission during Presymptomatic Phase, Japan. Emerging Infectious Diseases, 17(9), 1737-1739. https://dx.doi.org/10.3201/eid1709.101411</a></li>
[^maurice] Maurice de Hond - https://maurice.nl/</a></li>
[^who] WHO - Transmission of SARS-CoV-2: implications for infection prevention precautions - https://www.who.int/news-room/commentaries/detail/transmission-of-sars-cov-2-implications-for-infection-prevention-precautions</a></li>
[^nrc2] NRC - Maurice de Hond laveert tussen serieuze kritiek, onbewezen claims en viruswaanzin - https://www.nrc.nl/nieuws/2021/01/28/van-serieuze-kritiek-onbewezen-claims-en-viruswaanzin-a4029682</a></li>
[^kroncrv] KRO/NRCV - Propaganda https://www.npo3.nl/propaganda/28-01-2021/KN_1725469</a></li>
[^op1] Uitzending van Op1 van 16 februari 2021</li>
[^nrc] Ik haal hier wederom Wilem Engel als voorbeeld van de complotdenker aan: https://www.nrc.nl/nieuws/2021/02/16/de-familie-engel-gaat-altijd-voorop-in-de-strijd-tegen-de-overheid-a4032045</a></li>
[^welt] Die Welt - Wenn der Staatssekretär Wissenschaftler zu „maximaler Kollaboration“ aufruft - https://www.welt.de/politik/deutschland/plus225868061/Corona-Politik-Wie-das-Innenministerium-Wissenschaftler-einspannte.html</a></li>
[^gunnarkaiser] Gunnar Kaiser - Bestellte Wissenschaft - Einige Fragen - Anmerkungen und Fragen an die Journalisten der WELT zum Panikpapier des BMI https://gunnarkaiser.substack.com/p/bestellte-wissenschaft-einige-fragen</a></li>
[^volkskrant] https://www.volkskrant.nl/columns-opinie/de-griep-is-spoorloos-verdwenen-uit-de-statistieken-van-de-belangrijkste-gezondheidsorganisatie~bb2c9610/</a></li>
[^huang2021] Huang, Q.S., Wood, T., Jelley, L. et al. Impact of the COVID-19 nonpharmaceutical interventions on influenza and other respiratory viral infections in New Zealand. Nat Commun 12, 1001 (2021). https://doi.org/10.1038/s41467-021-21157-9</a></li>
[^svt] SVT - Kungen om pandemin: ”Jag anser att vi har misslyckats” https://www.svt.se/nyheter/inrikes/kungen-jag-anser-att-vi-har-misslyckats</a></li>
[^rtl2] RTL Nieuws - RIVM: 20 procent positief geteste mensen gaat toch naar buiten https://www.rtlnieuws.nl/nieuws/nederland/artikel/5190014/rivm-20-procent-positief-geteste-mensen-gaat-naar-buiten</a></li> </ul>

Homepage update: from Hugo to Zola

Unknown — Tue, 29 Dec 2020 18:56:34 +0100

Homepage update: from Hugo to Zola</h1>
At the start of 2019, I launched a new incarnation of my homepage (yes, I still call it "homepage", it has a nice nostalgic touch to it of a time where people still bothered to create their own little corner on the internet instead of joining corporate social networks en masse) . I had chucked away my old site that still relied on server-side processing (I believe it was Django-based at the time), which stopped being the hip thing to do many years ago. Instead, my 2019 site was statically generated with Hugo</a> and powered by the Academic theme</a>, which I heavily modified to suit my needs.
Things looked pretty slick and I was happy with the end result, but as always, happiness is fleeting. As time progressed, both Hugo and the theme I was using saw various updates, mostly consisting of features and additions I didn't need or want anyways, and I found that my site would no longer generate with either the latest Hugo or the latest Academic theme.
My aim had been to build a website that was more manageable over time, but that failed. Getting rid of server-side processing was a good thing, but my website was still too complex. Moreover, it contained some javascript and external resources that I really wanted to get rid of as this became more and more of an affront to my ethical sensibilities.
One thing I never liked about Hugo was its templating syntax, but I do see the value of having a good and powerful templating system. There are countless static site generators out there, as evidenced by for example Jamstack</a>, so I set out to investigate a bit. I wanted to have a solution where I could do most of the actual content writing in Markdown, but still have some decent control over how things end up.
Drawn by minimalism, I even contemplated solutions such as ssg by Roman Zolotarev</a> or mkws</a>, but the former foregoes on templating altogether and just sticks on a header and footer, and the latter uses shell scripting as templating, which is not a syntactic improvement.
Although generating a site isn't very performance-critical for me, I did want something efficient and compiled in a single binary, in the hope that this would be closer to achieving simplicity and minimalism. Therefore, static site generators in interpreted languages, like Ruby, Python or Javascript, were out of scope for me. That ruled out things like Jekyll</a>, which I have some experience with for some other websites.
To make a long story short, I opted for Zola</a> in the end. A fairly simply static site generator written in Rust. This is one that looked simple enough and up to do the job, without doing much more than that. It features a nice templating engine with a decent Jinja2-like syntax and shortcodes</a>. The fact that it's in Rust was a compelling argument for me too, as I know and like Rust, so I'll be able to contribute to the generator if needed.
I also decided I shouldn't rely on an external template as a basis, but make something from scratch and for my specific purpose, that way it can't diverge and it won't contain things I won't need or need to strip out.
I'll summarise my experience with Zola in a pro and cons list:

Pro</h3>

Simple</li>
No unnecessary bloat, things you may want (like galleries) are not predefined but you can accomplish easily through templates)</li>
Good intuitive template syntax</li>
Written in Rust, single binary</li>
Responsive developer</li> </ul>
Con</h3>

The distinction between sections and pages was a bit limiting in some regards, can't I have a section be a page at the same time? Building a navigation menu over both was a bit convoluted for me, but I may have misunderstood something perhaps.</li>
Error feedback could be better in general, it would also be nice if we could set verbosity a bit higher whilst zola is running.</li>
I had one actual crash/panic (but I submitted an issue and this is already being fixed by the developer)</li> </ul>
I think most of these issues come down to lacking some maturity still, but I'm confident of the direction the development is proceeding in. I hope backward compatibility will be better guaranteed than my experience with Hugo.
References</h2>
I'm not the only one two has made the jump from Hugo to Zola, I found two other blog posts on the topic and found their stories insightful:

by xypnox</a></li>
by Karan Sharma</a></li> </ul>

Hanzigrid & Learning chinese characters based on visual similarity

Unknown — Sat, 04 Jan 2020 19:38:28 +0100

Hanzigrid & Learning chinese characters based on visual similarity</h1>
大家好！
I've been trying to learn Mandarin Chinese for quite a while, following the vocabulary compiled for the HSK (汉语水平考试) tests. As every Chinese learner will surely know, memorising all the characters is a rather daunting task. I often find myself mixing up similarly looking characters (like 牛 and 午 or 手 and 毛).
In order to learn these properly, I need to see them next to eachother, following a more horizontal vocabulary learning strategy nicely described by Hacking Chinese</a>.
To facilitate my learning, I've compiled a list of hanzi I wish to study (based on HSK mostly) and ordered them based on similarity, or my own subjective notion of it. Then I wrote a little software tool</a> to generate what I call hanzi grids. A hanzi grid is a study grid or matrix of chinese characters along with (optionally) pinyin and/or words, often coloured according to tone. The tool I wrote enables anyone to generate hanzi grids in all kinds of sizes, also nice for printing on A1/A0 paper and hanging on your wall as a poster and constant study reminder!
The resulting hanzi grid using my confusible ordering looks as shown below. It contains all of HSK 1 to 3 and some characters from higher levels:

The above is a just an example, you'll want to use the scalable (SVG) version</a> for printing. The character colours corresponds to the tones (red = first, yellow = second/rising, green = third, blue = fourth/falling, black = neutral or ambiguous), the background colours give an indication of the HSK level, so you can skip the higher levels if you're not up to it yet.
I also made an Interactive clickable variant (desktop version)</a>, on mobile devices you will want to try the Mobile clickable variant</a> instead. In these versions you can click characters and get a list of all HSK words that use the character: 
If you're more interested in a conventional ordering by level or pinyin then that's possible too:

Example HSK 1 to 4 in pinyin order</a></li>
Example HSK 1 to 4 in level/frequency order</a></li> </ul>
The tool I wrote allows you to include the pinyin in the grid itself, but I deliberately did not make that the default, as the pinyin is something I need to learn. Traditional characters instead of simplified is also possible.
For the software itself (free & open source!), more readily available grids, and a more detailed explanation, see hanzigrid on github</a>.
我希望这个《汉字格》对你有用！ Happy learning! :)

GPS tracker integreren in home automation

Unknown — Sun, 09 Dec 2018 12:38:28 +0100

GPS tracker integreren in home automation</h1>
Ik heb de GPS tracker die o.a. verkocht wordt als Reptrek Minitrek</a> aangeschaft om onze hond te kunnen tracken.
In plaats van de standaard beschreven SeTracker2 software (Chinese closed-source app voor Android en iOS) te gebruiken wilde ik als home-automation hobbyist deze gps tracker in mijn home automation systeem integreren en wilde ik pertinent niet dat de tracker via een server van derden (namelijk die van de SeTracker2 app) communiceert waarbij ik totaal niet weet wat er met mijn data gebeurt. Dit wil ik dus in eigen beheer hebben ook ivm privacy en veiligheid. (Let wel, de tracker communiceert sowieso over GPRS zonder enige encryptie!)
Dit documentje biedt wat instructies en technische details om deze tracker met je eigen GPS tracking platform op te zetten. Het geheel werkt goed, enige minpunt is dat de GPS module toch af en toe wat moeite heeft goed signaal te krijgen.

Benodigdheden</h2>

De GPS tracker</li>
Een SIM kaart met mogelijkheid tot bellen, SMS en data (GPRS), (KPN prepaid voldeed prima bij mij). Let op dat 2G netwerk ondersteund is/blijft (is niet bij alle providers zo)

Zet de pincode vergrendeling uit (via bv. een andere mobiele telefoon) voor het gebruik in de tracker</li> </ul> </li>
Een eigen server (bv. een raspberry pi voldoet al)

Installeer Traccar</a> - Open-source GPS tracking platform met web interface en eventueel app voor Android en iOS.</li>
Open TCP poort 5093 voor de GPS tracker, en 8082 voor de webinterface</li> </ul> </li> </ul>
Technische Details</h2>

De tracker is de q36 (of een afgeleide daarvan) van chinese makelij, oorspronkelijk in de vorm van een gps horloge.</li>
De chipset is MTK2503 van MediaTek.</li>
Het GPRS communicatieprotocol is hier</a> beschreven, binnen de Traccar software wordt dit protocol als watch aangeduid.
De verschillende instructies kunnen als ook SMS naar de tracker gestuurd worden, het standaardwachtwoord is `123456</code>. De syntax bestaat dan uit komma-gescheiden instructries/parameters en een hekje als afsluiting.</li>`
`SMS Voorbeeldinstructries:`

`pw,123456,ts#</code> - rapporteert (per SMS) de status en huidige instellingen, gebruik dit om te verifiëren of de SIM werkt, en in later stadium of er GPRS en GPS verbinding is.</li>`
`pw,123456,pw,987654#</code> - wijzig het wachtwoord (in 987654, gebruik dus iets anders)</li>`
`pw,123456,lz,0,1#</code> - stelt taal en tijdszone in</li>`
`pw,123456,apn,portalmmm.nl,,,20408#</code> - Activeert GPRS verkeer door het access point (APN) in te stellen, dit voorbeeld is voor KPN. Zoek de APN gegevens van je SIM provider op.</li>`
`pw,123456,sos,+31612345678#</code> - stel één of meerder SOS telefoonnummers in</li>`
`pw,123456,whitelist1,+31612345678#</code> - stel één of meerdere telefoonnummers in die mogen bellen naar de tracker</li>`
`pw,123456,upload,120#</code> - zet de upload interval in seconden (120 hier)</li>`
`pw,123456,ip,127.0.0.1,5093#</code> - Stel hier je eigen server in waar de GPS gegevens naartoe gestuurd worden (vervang het lokale IP hier door het IP van je eigen Traccar server, we hanteren hier standaardpoort 5093)</li>`
`pw,123456,url#</code> - De tracker SMSt een google maps link terug met de huidige lokatie gemarkeerd (handig als je puur via SMS wil werken en geen enkele app of server wil gebruiken).</li>`
`pw,123456,reset#</code> - Reboot de tracker</li>`
`pw,123456,poweroff#</code> - Zet de tracker uit (daar is immers geen knopje voor)</li> </ul> </li> </ul> </li> </ul>Home Automation</h2> Traccar integreert mooi met de open-source software Home Assistant</a>, middels het traccar component</a>.`

Labirinto

Unknown — Sun, 22 Apr 2018 00:04:34 +0100

Labirinto</h1>
Labirinto is a virtual laboratory portal, it makes a collection of software browseable and searchable for the end-user. Labirinto presents the software's metadata following the CodeMeta</a> specification in an intuitive way and allows the user to filter and perform a limited search. The portal gives access to software if it offers web-based interfaces.
This system is specifically geared towards research software, and for instance allows linking to relevant scientific publications for each tool.

Architecture</h2>
Labirinto is a front-end only, it runs fully client-side and is written in Javascript using the Vue.js</a> framework.
Labirinto relies on software metadata specifications according to the CodeMeta</a> standard (linked open data / JSON-LD). Metadata of the desired software collection should be combined into a single registry (JSON-LD), which can be hosted and obtained from wherever you want. CodeMetaPy</a> can be used to build such a registry from individual `codemeta.json</code> files.`
Note that Labirinto does not and will never offer an editable database or metadata editor for the software metadata; this is a front-end that does not even require a database backend or any server-side component for that matter. Our philosophy is that software metadata should be in a simple format and either live right alongside the source code in a version controlled repository (e.g. on github, bitbucket, etc), or be obtained from a software repository such as as the Python Package Index, CRAN, CPAN, Maven Central and automatically converted to a unified format.
`Labirinto is used by and included in the` `LaMachine</a> software distribution, providing an overview and access to all software installed in LaMachine. The metadata for tools participating in LaMachine is, when not explicitly provided yet, automatically converted to the CodeMeta standard (by CodeMetaPy</a> or CodeMetar</a>), and subsequently combined into a single registry for use with Labirinto.`

Screenshots Linux Desktop August 2017

Unknown — Mon, 21 Aug 2017 13:30:37 +0100

I recently switched to the gruvbox colours and polybar.

Distribution: Arch Linux</li>

WM: bspwm</li>

Bar: polybar</li>

Launcher: rofi</li>

Multiplexer: tmux</li>

Editor: neovim + gruvbox theme</li>

Browser: Firefox</li>

Terminal: urxvt + gruvbox theme</li>

Music player: mpd + ncmpcpp</li>

Chat: weechat</li>

Mail: notmuch + alot</li>

Browser: firefox</li>

Spaceship: Stratios</li>

dotfiles</a></li>
Wallpaper</a></li> </ul>

</a>
ss201708_vim_python.png</div> ss201708_vim_python.png</label> </div>
</a>
ss201708_vim_irc2.png</div> ss201708_vim_irc2.png</label> </div>
</a>
ss201708_vim_cpp.png</div> ss201708_vim_cpp.png</label> </div>
</a>
ss201708_tmux1.png</div> ss201708_tmux1.png</label> </div>
</a>
ss201708_rofi_neofetch.png</div> ss201708_rofi_neofetch.png</label> </div>
</a>
ss201708_neofetch.png</div> ss201708_neofetch.png</label> </div>
</a>
ss201708_ncmpcpp_htop.png</div> ss201708_ncmpcpp_htop.png</label> </div>
</a>
ss201708_mail.png</div> ss201708_mail.png</label> </div>
</a>
ss201708_irc.png</div> ss201708_irc.png</label> </div>
</a>
ss201708_firefox_unixporn.png</div> ss201708_firefox_unixporn.png</label> </div>
</a>
ss201708_firefox_homeassistant.png</div> ss201708_firefox_homeassistant.png</label> </div>
</a>
ss201708_eve3.png</div> ss201708_eve3.png</label> </div>
</a>
ss201708_eve2.png</div> ss201708_eve2.png</label> </div>
</a>
ss201708_eve1.png</div> ss201708_eve1.png</label> </div>
</a>
ss201708_empty.png</div> ss201708_empty.png</label> </div> </div>

Light of the Seven

Unknown — Tue, 30 Aug 2016 11:48:55 +0100

Light of the Seven</h1>
Seven blessings to you! Here I play the epic piece by Ramin Djawadi for the season 6 finale of Game of Thrones. This is my version based on the score of Halcon</a> with some personal interpretation and some errors.
</iframe> </div>

Fireplace with Raspberry Pi and Neopixels

Unknown — Wed, 04 Nov 2015 11:48:55 +0100

Fireplace with Raspberry Pi and Neopixels</h1>
Electronic fireplace, powered by a Raspberry Pi and Neopixel LED-strip. Fully integrated into our homeautomation system. The colour representation in the video is a bit off, it's looks less red in reality. See here</a>
</iframe> </div>

My Home Automation

Unknown — Sat, 11 Jan 2014 00:04:34 +0100

Home Automation</h1>
This repository contains my elaborate home automation configuration, using Home Assistant</a>.

Introduction</h2>
Prior to Home Assistant, I ran my own custom-built home automation software. This got too time consuming to maintain and expand so in the summer of 2017 I migrated everything to Home Assistant.
I have a main server and various Raspberry Pis distributed through the house (for wiring reasons). One of the challenges was getting them to communicate properly with Home Assistant. I decided on simply running a Home Assistant instance on each (EventStream solutions did not work properly for me), have the master instance control as much as possible, and the slaves as bare as possible, with communication proceeding over MQTT.
Goals</h2>

Automate and integrate as much as possible:

Lights</li>
TV</li>
Audio</li>
Cameras</li>
Lots of environment sensors for automations</li> </ul> </li>
Open-source and no third-party cloud solutions, I like to own and safeguard my data!</li>
Security/Alarm system</li> </ul> Devices</h2>
I have the following devices:

Master: Main server (Ubuntu Linux)

Quad core</li>
16GB RAM</li>
Aeotec Z-Stick</li>
Webserver: Apache</li>
MQTT Broker: Mosquitto</li>
Audio streaming: Mopidy</a> (MPD) + Modidy-spotify + Iris + Icecast</li>
Messaging: XMPP (Prosody)</li> </ul> </li>
Slave: Raspberry Pi 1 (Raspbian) (GPIO wiring schematic</a>)

GPIO: 433.92Mhz Transmitter for lights (see also https://github.com/proycon/433mhzforrpi/)</li>
GPIO: Door/doorbell sensors (wired, reed contacts)</li>
GPIO: IR LED for remote control of TV/audio</li> </ul> </li>
Slave: Raspberry Pi 2 (Raspbian) (GPIO wiring schematic</a>)

GPIO: 433.92Mhz Transmitter for lights</li>
GPIO: Door/window sensors (wired, reed contacts)</li>
GPIO: Neopixels LED for ambilight in living room</li>
GPIO: IR LED for remote control of TV/audio</li>
GPIO: IR Receiver</li> </ul> </li>
Slave: Raspberry Pi 3 (Raspbian)
GPIO: DH-22 temperature/humidity sensor</a></li>
GPIO: Neopixels LED fireplace (video</a>, sources</a>)</li>
GPIO: PIR sensor</a></li> </ul> </li>
IP Cams
Living room (D-Link 5222-L)</li>
Street (Foscam)</li>
Garden (Foscam)</li> </ul> </li>
Webcams
Front door</li>
Hallway</li> </ul> </li>
433 Mhz
Many Klik-aan-klik-Uit Adapters or older ELRO adapters for all lights</li>
1x RFLink Transceiver</a>, based on Arduino Mega, connected to Pi2

1x ALECTO WS-4500 Weather Station (mounted outside for wind, rain, temperature)</li> </ul> </li> </ul> </li>
Z-Wave
Aeotec Z-Stick</li>
3x Fibaro Motion/light/temperature sensor</a></li>
1x Neo Coolcam Door/window sensor</li>
2x Nodon Softremote buttons for scene selection/quick remote functionality</li>
1x Philiotech Temperature/Humidity Sensor for bathroom</li>
1x Remotec ZRC-90 remote</li> </ul> </li>
Other
Slimme Meter for power consumption, connected to main server</li>
Speakers throughout the house for text-to-speech notifications</li>
Wake up timer through bedroom TV</li> </ul> </li> </ul> Interface</h2>
Some screenshots of the interface, featuring home assistant tiles</a>:

Dotfiles

Unknown — Sun, 26 May 2013 00:04:34 +0100

Current setup:

Maisha

Unknown — Fri, 09 Jul 2010 11:48:55 +0100

Maisha</h1>
This is my interpretation on piano of the wonderful song Maisha, of the Idan Raichel project. One of the many fantastic songs he made. The original is with Swahili vocals, but my version is instrumental only (I'm a very bad singer unfortunately :) ). The original version can be found here</a>, with English and Polish subtitles: . As always, my interpretation may vary from the original, and no, I don't have any score.
</iframe> </div>

Proycon's website

Fiducia Gocciolabile - Own composition - Piano

Fiducia Consolabile</h1> This is my own composition. Licensed under the Creative Commons Attribution ShareAlike license (CC-BY-SA).</p> </iframe> </div> A pure audio-only version is available here</a>.</p>

Text processing on the Command Line - sharing my tools

Text processing on the command line - sharing my tools</h1>

charfreq</h3> charfreq</code> is a very simple tiny CLI tool that just computes (unicode) character frequencies from text received via standard input. Written in Rust.</p>

Do not Restrict Me! How copy protection (DRM) on e-books harms our freedom and what to do about it

Do not Restrict Me! How copy protection (DRM) on e-books harms our freedom and what to do about it</h1>

Discredits</h2> Adobe, Amazon, Google and all those many others enforcing DRM technology on end-users.</p>

Canto Ostinato - Simeon Ten Holt - Piano solo

Canto Ostinato - Simeon Ten Holt</h1> This is my own interpretation of (small part of) Simeon Ten Holt's wonderful composition "Canto Ostinato", famous for its repetitive nature.</p> </iframe> </div>

My Default Apps

Rant against centralising e-mail in big-tech silos, and breaking the internet in the process

STAM: Stand-off Text Annotation Model

Todo.txt-more: Efficiently managing your todo list and your time

Todo.txt More: Efficiently managing your todo list and your time</h1>

Todo.txt More

codemeta-harvester

Analiticcl

wvkbd: On-screen keyboard for wlroots

SXMO: Simple X mobile - presented at AlpineConf 2021

Sxmo: Simple X mobile - A minimalist environment for Linux smartphones</h1> We presented Sxmo at AlpineConf 2021:</p>

clickclack

Clickclack</h1> Clickclack is a simple haptic feedback and audio feedback tool. It does nothing more than emulate the clickclack sound and vibration when pressing keys.</p>

Een antwoord op corona-skepsis

Een antwoord op corona-skepsis</h1>

The Disinformation age

Homepage update: from Hugo to Zola

Pro</h3> Simple</li> No unnecessary bloat, things you may want (like galleries) are not predefined but you can accomplish easily through templates)</li> Good intuitive template syntax</li> Written in Rust, single binary</li>

References</h2> I'm not the only one two has made the jump from Hugo to Zola, I found two other blog posts on the topic and found their stories insightful:</p>

SVKBD: Simple Virtual Keyboard

SVKBD: Simple Virtual Keyboard</h1> This is a simple virtual keyboard, intended to be used in environments where no physical keyboard is available.</p>

Sxmo: Simple X Mobile

SXMO: Simple X mobile - demo video on a pinephone

SXMO: Simple X mobile - demo video on a pinephone</h1> </video> </div> Details shown in this video:</p>

Vocage

Sesdiff

Break Free! Don't be a prisoner of your sofware platform!

Context as Linguistic Bridges [PhD thesis]

Hanzigrid & Learning chinese characters based on visual similarity

GPS tracker integreren in home automation

Benodigdheden</h2> De GPS tracker</li>

Technische Details</h2> De tracker is de q36 (of een afgeleide daarvan) van chinese makelij, oorspronkelijk in de vorm van een gps horloge.</li> De chipset is MTK2503 van MediaTek.</li>

Labirinto

CodeMetaPy

Screenshots Linux Desktop August 2017

The Shape of Things to Come

The Shape of Things to Come</h1> From Battlestar Galactica, Composed by Bear McCreary. My performance is a bit sloppy here and there but I didn't want to do it over again ;)</p> </iframe> </div>

Light of the Seven

Star Wars Composition

Star Wars Composition</h1> This is my Star Wars Composition, consisting of my interpretation of various medleys that appear throughout the eight Star Wars movies.</p> </iframe> </div>

Madredeus - O Pastor

Prelude to War

Prelude to war</h1> My version of epic piece Prelude to War from Battlestar Galactica, composed by Bear McCreary. My version may differ a bit from the original, and it has some mistakes.</p> </iframe> </div>

Busy Bees - Five years of work in version control

Fireplace with Raspberry Pi and Neopixels

Bang Bang - Dalida

LaMachine

foliadocserve

Gecco

The Rains of Castamere

The Rains of Castamere</h1> Here I play "The rains of Castamere" from Game of Thrones. My interpretation may differ from the original and the sound quality is not that great. Disclaimer: Nobody died during the making of this video.</p> </iframe> </div>

My Home Automation

Goals</h2> Automate and integrate as much as possible: Lights</li> TV</li> Audio</li> Cameras</li> Lots of environment sensors for automations</li> </ul> </li> Open-source</strong> and no</strong> third-party cloud solutions, I like to own and safeguard my data!</li>

Devices</h2> I have the following devices:</p>

Home Automation

FLAT

Mhysa

Mhysa</h1> Here I play the epic music "Mhysa" (mother) from the season 3 finale of Game of Thrones.</p> </iframe> </div>

Colibri Core

Fiducia Consolabile</h1>
This is my own composition. Licensed under the Creative Commons Attribution ShareAlike license (CC-BY-SA).</p>
</iframe> </div>
A pure audio-only version is available here</a>.</p>

charfreq</h3>
`charfreq</code> is a very simple tiny CLI tool that just computes (unicode) character frequencies from text received via standard input. Written in Rust.</p>`
`You can find charfreq</code> on` `Sourcehut</a> or Github</a>.</p>`

Discredits</h2>
Adobe, Amazon, Google and all those many others enforcing DRM technology on end-users.</p>

Canto Ostinato - Simeon Ten Holt</h1>
This is my own interpretation of (small part of) Simeon Ten Holt's wonderful composition "Canto Ostinato", famous for its repetitive nature.</p>
</iframe> </div>

References</h2>
I'm not the only one two has made the jump from Hugo to Zola, I found two other blog posts on the topic and found their stories insightful:</p>

by xypnox</a></li>
by Karan Sharma</a></li> </ul>

The Shape of Things to Come</h1>
From Battlestar Galactica, Composed by Bear McCreary. My performance is a bit sloppy here and there but I didn't want to do it over again ;)</p>
</iframe> </div>

Star Wars Composition</h1>
This is my Star Wars Composition, consisting of my interpretation of various medleys that appear throughout the eight Star Wars movies.</p>
</iframe> </div>

Prelude to war</h1>
My version of epic piece Prelude to War from Battlestar Galactica, composed by Bear McCreary. My version may differ a bit from the original, and it has some mistakes.</p>
</iframe> </div>

The Rains of Castamere</h1>
Here I play "The rains of Castamere" from Game of Thrones. My interpretation may differ from the original and the sound quality is not that great. Disclaimer: Nobody died during the making of this video.</p>
</iframe> </div>

Mhysa</h1>
Here I play the epic music "Mhysa" (mother) from the season 3 finale of Game of Thrones.</p>
</iframe> </div>