aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--conf.py26
-rw-r--r--files/cert/dave@sleepmap.de.asc247
-rw-r--r--pages/about.rst5
-rw-r--r--posts/2015/201502-ssh-tunnel-and-postfix.rst2
-rw-r--r--posts/2015/201504-linux-audio-conference-2015.rst2
-rw-r--r--posts/2016/201609-letsencrypt.rst2
-rw-r--r--posts/2016/201610-uwsgi.rst2
-rw-r--r--posts/2022/arch-a-recap.rst294
-rw-r--r--posts/2022/managing-binary-package-repositories.rst193
-rw-r--r--posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst182
-rw-r--r--posts/2022/packaging-for-arch-linux.rst1152
-rw-r--r--posts/2023/grants-for-operating-systems.md158
-rw-r--r--posts/2023/operating-system-bias-in-next-generation-internet-and-nlnet.md293
-rw-r--r--state_data.json3
14 files changed, 2293 insertions, 268 deletions
diff --git a/conf.py b/conf.py
index ab50599..355dcc2 100644
--- a/conf.py
+++ b/conf.py
@@ -951,20 +951,22 @@ FEED_LINKS_APPEND_QUERY = False
# A HTML fragment describing the license, for the sidebar.
# (translatable)
-LICENSE = ""
-# I recommend using the Creative Commons' wizard:
-# https://creativecommons.org/choose/
-LICENSE = """
-<a rel="license" href="https://creativecommons.org/licenses/by-nc-sa/4.0/">CC BY-NC-SA 4.0</a>"""
+LICENSE = """<a rel="license" href="https://creativecommons.org/licenses/by-nc-sa/4.0/">CC BY-NC-SA 4.0</a>"""
# A small copyright notice for the page footer (in HTML).
# (translatable)
-CONTENT_FOOTER = '<p>Contents &copy; {date} <a href="mailto:{email}">{author}</a> {license} </p> \
-<p><a href="https://www.discogs.com/user/dvzrv" target="_blank" >Discogs</a> | \
-<a href="https://www.flattr.com/profile/davezerave" target="_blank" >Flattr</a> | \
-<a href="https://www.github.com/dvzrv" target="_blank" >GitHub</a> | \
-<a href="https://www.gitlab.com/dvzrv" target="_blank" >GitLab</a> | \
-<a href="https://www.twitter.com/dvzrv" target="_blank" >Twitter</a> </p>'
+CONTENT_FOOTER = (
+ '<p>Contents &copy; {date} <a href="mailto:{email}">{author}</a> {license} </p>'
+ "<p>"
+ '<a href="https://archlinux.org/people/developers/#dvzrv" target="_blank" >Arch Linux</a>'
+ ' | <a href="https://gitlab.archlinux.org/dvzrv" target="_blank" >Arch Linux GitLab</a>'
+ ' | <a rel="me" href="https://chaos.social/@dvzrv" target="_blank" >Chaos.social</a>'
+ ' | <a href="https://codeberg.org/dvzrv" target="_blank" >Codeberg</a>'
+ ' | <a href="https://discogs.com/user/dvzrv" target="_blank" >Discogs</a>'
+ ' | <a href="https://github.com/dvzrv" target="_blank" >GitHub</a>'
+ ' | <a href="https://gitlab.com/dvzrv" target="_blank" >GitLab</a>'
+ "</p>"
+)
# Things that will be passed to CONTENT_FOOTER.format(). This is done
@@ -1034,7 +1036,7 @@ STRIP_INDEXES = True
# from indexing and other robotic spidering. * is supported. Will only be effective
# if SITE_URL points to server root. The list is used to exclude resources from
# /robots.txt and /sitemap.xml, and to inform search engines about /sitemapindex.xml.
-ROBOTS_EXCLUSIONS = ["/archive.html", "/category/*.html", "/about/index.html", "/impressum/index.html"]
+ROBOTS_EXCLUSIONS = ["/about/index.html", "/impressum/index.html"]
# Instead of putting files in <slug>.html, put them in <slug>/index.html.
# No web server configuration is required. Also enables STRIP_INDEXES.
diff --git a/files/cert/dave@sleepmap.de.asc b/files/cert/dave@sleepmap.de.asc
deleted file mode 100644
index c62e963..0000000
--- a/files/cert/dave@sleepmap.de.asc
+++ /dev/null
@@ -1,247 +0,0 @@
------BEGIN PGP PUBLIC KEY BLOCK-----
-Version: GnuPG v2
-
-mQINBE+m1eEBEADcmX7HkkJp2a++OKf3gzlpd1/JVKp1o7i6UdROohdqyvl78oKT
-MCZC2ZGXZpDmch7G3bdPAdmLPcEI0L8tJFZCpge5UEbXpQqgekEBemaOpWQvqu7U
-2J+nm9+8VcAjffN/Sq2QKcrK6iN0mLsUA80KgPko0SWZi/2OFQh3ERr5MfDuwjnF
-rLA0PDQBIkDhnNqQs61coubC5G5JTZPMAk9H07W4qoUHerAWHpvEXuJGtVpZl5Og
-r3t8xGq/rjPy3O8w9K69wTWpwibOP/WRhtwEHHaO3QLe0mME1QWyPpo8XMORjus4
-XPiGPibCSwtcIp7iSASHcCS0QfLc3COhSz9SyyktMqE8qHhmcwNNrtWa+s9WyD2h
-CPF258G4K0+jxn2/FE8ok3BUA1qlpM1YyWeAIBgTH/PS7XLctGOaVzAWjDwBzgQk
-dmzXv8ep2pthNrxWV4LmgCiVuaZytAP1CamudDnrl15R1h8U7h/X03UjCs44dyCH
-F+uAAY9RNaOeW8hBW05viRGekIjSkbnsp3Pu2Lz+2/ijqDEb1ozF8tF1XycoWxY2
-heHYkQaRdr7/CkFUHB9ewsLoLglcD7HvV7nKmKotfl2XtdwBdGgliCz/C2vnfidA
-bBh95husdV2gPweLi9VoZ/tUai+AQMvRNfJcYnE5Wg3UIxC8KY5sh/Z1KQARAQAB
-tB5EYXZpZCBSdW5nZSA8ZGF2ZUBzbGVlcG1hcC5kZT6JAkAEEwEIACoCGyMFCQlm
-AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlSpCoUCGQEACgkQVMKPT/WhqUlJ
-8w/+L5zJObJ6y0jUNMaDKQo2CMIJIfU85woegrrc9vUYCoZfvICn9qNEqiN/IOK/
-e+Uy2k7l21SiBwWbbC7mOtKhomuIs8bQ9Qq/dv4lC58HYL7vr8jkH28eO5O6UM3J
-prNWOYK1HKsYpDmjzhX0xOoSaL83zrf34VXgww/aYKanTQrh2tvSVd3UVtJlpMoF
-4eHYYhEmVxIc4KDWUEIVqS88zSPj0Y9d/plu4NHNM6H7MGpaYVx6kSgd9TBM1mR8
-FWRPOIXQ5UmXciiAy7hlxkOO96CPi7joLo3GISTs7RFCwzfHEz0Ocj9bhgQJm8Wg
-tuThFxJD713o5Vz48s6tPTFu46hEgknLBehFJ4666aMCaf6HzQHMHSbfXGqDDb87
-G2JJz7a+ft8YSTJ1Wl2uECsywYGEh4LebBACAXagSUfpXgDCY99rJB3uh3eTvXmT
-wB2CPDcll/Oz2vjV8CEdysSfSnJfqbp4Pf1+Ucekw2fIUbGNbIAgFnvY0xVAN/xE
-bN7Udv2ycRmqLhnyiYt5xkIFlCXV9vVt3V6GLhjXxpvzhPQziEGC86tcHCwWU9JA
-4vhgQuwt7MdCKuNmc+WjoYg8nnY25YwBGhepm50DwUfjpUyFSnNE/R7hTqw6TpmB
-LeS/NMof73Ttns+u8ajOLtpJG8Xz03pWwVyh73aM/0iJy4C0JERhdmlkIFJ1bmdl
-IDxkYXZpZC5ydW5nZUBmcnFyZWMuY29tPokCHwQwAQgACQUCVNFAZAIdAAAKCRBU
-wo9P9aGpSe5ZEADCMTExqktu4w86bfCJi/Rqi4JkgCRvoUMKiOupuBGt6YTeYWsg
-qQAwuDTG5GOgWrcBf7sktTC46i7xyLkhbV9L0bzqlcCmuXpIg0ldRyERboweQl2v
-veXPlDYxOJKDMUlqpGS1cemEPbARJk+zzZdn0DiJh4ruWWJiqRsJzpK9uKMybiTv
-atxPz4bQj+2W25174UAjpzb+zWPCV9HUcsNhR0yGGzUEmIXsHSRqJ97R7Yafhdyp
-BMTiyIgA0x0I/jNxvwCH6v2meJO/jed6uBoz0r83NP/sC5ccf7ZSvqmcSAFJdPLo
-WKvJrRTN5FT/zDS/BDdv/7UIOWEtWxJ7v+cel2vGHM0iuLRmyxBjYm9VlGdvjdqj
-CHArz5Qd7FRLvMevdZ7N2gbPUSRNV9UWWF3iMMtZzWj/VyV81b4M6uVMGIxS3bWj
-MgcirHRjUS+R2JewYoaMYcSQfIknZgDVVA73HpzL8jhrqcnBWCFs6gEEy0lef7DZ
-PTyUby3vZ3U5iHXSoURGE03cgid4yvXlwRW8fjCiKiYS0feZvrv4ARrbnO78+bPN
-FvNMNITbRitXgtZ/d9tuEUXZHCmBkNkAS+hAPLv886ercxKPfCq8qRLedZzWtzl/
-9qar41POiFwtFfjdhHHe6W3C9kd3y8WwuEqIhua95BRomEghtsWds13YhokCPgQT
-AQIAKAIbIwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlSpCoUACgkQ
-VMKPT/WhqUk/HQ/9FiJwCT08a6UVUuCOkY2MZfDoRPqToZQVxOSx0LYxoVF+o+44
-tCnPIay7ypMnf1GKufKuOlL7Y8/1V5qIgSI3PPuQibcIJV7WYhdqasOSgwN2smqd
-Bj7uteq3sxuJ7YkT909h0oHKGpOXFG2Ooj8YtU+mCOePxImlIyQTmGwDPNXOcxNe
-sydhdBUd00H8lNT0kfc1z87j1JdNg0ESiNV9svtMKfehmYFyxdzNAW3BXKZDthla
-0nu4XpS816uDBcOh5I8uAHRPakAITReKEaSD9lqfqoEF7NPny9jyea0LhSSX5//h
-wMhzCdXQOdtk1lkIGwtGgPND+yGFncbWqkcNjrWisDpJQgVziefJEXj7AMRLZAci
-r/DVkvJqaEeYbYUdnxND9R4UtcNjY+fBQeuMGqMrF1LClFe26fgkq1jMhFPQhDeu
-J9ciG0MvmdHQZteGncJuQv1F5hHLQFGDq9c6ybudbLNTJKlRYc3o+/QC4CQYg5A5
-iQc2d0lHQWwF/Goy7EMe6DksYOv/e1qfEWz54bosDLsgZRc51QCcXfPnrS+W41qN
-WnMmIJTyZi5sxMIFgNZUkUG/k8PKWRXprphJRlp7uqIwjfMqjGp0iOmVBor58ATu
-MuIpHwH10FhYyTSYuQ309egHsr7St1e+HX/W4eC5wCLqOrn5PaZp7JaleH6JAhwE
-EwECAAYFAk+m3KsACgkQXKyqz021N/6K5hAArMuAR2G5hQxfycqBE/McPj0H9uSp
-jkmlw2c9IylcFSLoe64DnNEyxgdyVcMmXKn5wRd1zLxu9gGaQuqqa8WOYYXBoSnz
-Yia03enIDR4lPSIMnMH8wsd3IQIhwL3RVdEcvioHCvwPGtYtIBbp1AjQouskUrHz
-DiKZ4AhfUIYMUpSUBg5ArxI1Hknl0191qCOvdI83suFz0pNVYA4Ezdwq+lqAxDau
-Jih4YH4PJtnYpINVBD/W1fvdDboglXj1KspnIhKWO7KyBypKOl/8v10DcP/5vbCO
-QZsY1AXR7A7zb2i/6mXeiWPJXx4Zr9g9KyjwZpgT+A3FleBlBXy6zmkgeYx+hjfq
-xZDSeuwJpmLA+WnQTEgJJsDg11arBMQAroNyKkHe9CdFouZBnNSAmw/5Y6SorFAq
-7LU19J1H3z2pAijOi5863IPOjY6RHBdQREjIKHLwwnZ4Q8lrotw8vr1vjdKHgec0
-eNzxiom0kKmuT7DxaP5/MifAz89Ppr75wZ8cgFBxBg/CZze505bnGRGCcZm5K416
-njqA7/G1U0KeyVxgSnjyCPqQVwfXHDf3b4Igjt58hHJuX9QzmV7bEzltXSXmxvYC
-WauilFxAceRks0OYhxT2TANU42TYn22iwy8Hnf/Tcye9UiuisBj94XIxUv/3vRV3
-Y70TZEMcl6vm1wqJAj4EEwECACgFAk+m1eECGyMFCQlmAYAGCwkIBwMCBhUIAgkK
-CwQWAgMBAh4BAheAAAoJEFTCj0/1oalJL2UQAJ7RjvaeeY2pUVq9tPefvYdHv6Kh
-0mQStXxmSzSmS+nAKVIqx7Uy4xjcphWq4TvB5hK2082dCGpYboeKnarnofsMjUQ3
-vX20lZf5CHnSIhBOq8+ROke2ISV9Mn4EQC7G6SC7yPAYEhqbqGbeSr52Dellw4Q/
-qcjguIfZlmdhr4f9hbGA1UfwtF+MlDjiRIMuTOzNb43ajJT/tq5cG1pMDGxbQSyD
-36jqD2SN1rFPlWdOmKRp281E3um9nCLXfPBx65LzDh6yOFpryKiLym3qyMpC+t6V
-DtS6liFjGlE7K+YZixOtRrm88xMxIiJFi4NPjOavj54hYEzlVqe8AbVa0rgQmXVh
-qOwz8y/5W9CZdIb1li6kWidmAxhEvYS3rJ7ya9/bwyi1mkDvhJQhr5wxufgCE288
-O15rL4W0nzQ4HNrcAp31rGU2T5FqosywOX8LebMBJn7y/WY635XD+0OtkrldBa2f
-6Z+QJ98YPUkr/+xSilHV8fpnBZamnciO3cJdvrdh5e46copKsBEUHV51AmaaDtu1
-l/E14tU0vDwJwyhAgLZPcZ1aCsVaZsqUGfJ62ZL/rcJY1U9Q+P3isdU0dNaKEpS3
-ixgjmIHA8G++J5nzkFQ9O0sfdVpIldx1Yrpu1+ltCllNkCSnWyPb9+ogeOgRaxVK
-Z0a4qyp5UowURazliQJBBBMBAgArAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgID
-AQIeAQIXgAUCVC6w3AIZAQAKCRBUwo9P9aGpSTKMEAC8akQPsX5eVy2fFIWgu+nX
-kIRxqR3HoqGSguzWtpmoXxqBjlzMbs1jX8UZz24BkGm0aia2Fb9W77mPxRBgu4Ei
-9FFZ+gFlo18FJZOQOQe30FvTlRlaW4lGMiQALVvomvSbzWgoQ3usCHmuZUnX9Knx
-mEfr5fT5CTLnbaaDzTljqkjZ1V7hYrJpv3S3BlNq/R2P4vt2+ueO1EcEWhZq2xOO
-23w70QVZYBltrcXTr1jZBAjdbzF8XeYlWAoY9mwFp/+zAVhO9u+iN5nuoIcMyG/x
-/yGtwwR56ksIPEv/MaLyJSeRlDj0Rsp6iAGaXe9QFui0LxhU/W/9Nd56hdTcLakV
-z841AySXY3Xsr872lsgITCmNb0+U1RTxHHvzMZRHULcDAth2WA7aj3WYyLOtP7NG
-IdtMwhRsJMWIhaXtuZrwRvtPaG/ZWLpM4PG70mI1IbP3n8LUtOMbMF05udIzxguV
-bcKw4vlY7kwzrMGqA3Ix+cloUTIyItLKHiWcoLUsZR5vy7pHB837eLeERn7dYzd7
-HkIlA0IEo+iZftBypMA63VMl0fxAVg08Znsc5LXpn1Y+wa1P+UIYOju6jpIaTNHU
-OD06faFzYmuhrWvB0JEzsX3eGyUn49crfhXeO+gZbfWf3c4zcnbtmMPJD7p2fuPX
-ZIJgSavuO4b9eaD3n7/6BbQsRHJhZnRlZCBUbyBIYXVudCA8ZHJhZnRlZHRvaGF1
-bnRAZnJxcmVjLmNvbT6JAh8EMAEIAAkFAlTRQHACHQAACgkQVMKPT/WhqUkk/w//
-a4Dp7Z196wC34og5ZpsoMBQ5RMrxErpGiy7ERs16zB1mC1NkngFBWVb1nNlGAzNJ
-vXtFun9nW93Ce/vagmdEel8bDD2vCtFyNQwPqvcfSS/N3U7a/C7v2H2zuCPmz+QG
-0h//GECuOJh2vUKcsTLkjR+5mSxJDhhm5+DEl5sQFrgVBqHlOlZR58wsmKz7blXr
-W+revoa3IDL0XJx3ifdbfAX8AIptxlRElrJdnt3vV7yzTFn6+RpRbGvMrKATDiiD
-4IX0m64YKpQLndkdrDMlAOMOQn/Z0wdvBRpaO1fNrJTKMvREYJVNNYeNFWm1LXw/
-fnmqX6GAuaomZlBPKGwV6S30wCo+DfAnYgPih/Di+ktOwR/tK2Il2Kz0EsD+xxug
-5KAXnoTtAkkXj9zyIkolqHQ5qCbZc1S7zkWg6636aBIp2eGcxtWIC1HVRaPCRHoJ
-MECFddPLgzeFnLpiZsXdB4tEWgOdbW5i7qLPK4OPa2emllBSBP9rw2zCtdL1l0+L
-v0W8RD7a09NiuhT07va3iCBKerSnpm5EKJaR13ntqy7vBeVE+koQT6u6sK1F1jm6
-8jPWcBAyoam8gPBBtSnFh/CQKKQhB3LHVzw334Ap9hwlVA4+sovpy1YsWSQ97yzC
-yEsrTmlANspHt6V02VCxGbbKoVM2TQ1fPJOk6Tup+uWJAj8EEwECACkFAlQusMAC
-GyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBUwo9P9aGpScg8
-EACR0AcclxJWnLOX+i0njY3mUFrvoFe/fx0bshsUZ5CCdly0habsSzwt3VKh52Mi
-pnl6xgxTMbJL5obBCaUjudi5d85Uy2+madKl8/6Euos0j5DT0E6zSjNTKSdiG45i
-dlPCYjwhTdXLeJeEBOJknE+bREw5kxrFFV91MmNVY+Bb9bkQhyB/dBAXVT9B/WT3
-Rx5tuUF4SCFOyNILHGW5+bTcbuj0jQHAS3ARhmqMrSZQjhoMO2Pan7byM/rOlsf+
-t99uvtIh+otSHOwluj/PqCc7hDXCjVDgx56/c43uwhpVTjKhiuWMM9PSgwWp6V49
-gN38KQ8o0HvO7msiTQxvPlgfi9UGuUinlvY4sc7Nehojpgqu/BGws/cdwLlcvUYS
-F4eEEbw6segoOKxQYomAHJB9nrLByj+2GYgGkWV1SEOnoAeruqmQVUSydAQ+HStc
-MadNsqPYvRcdxVxm9APkeIb6YLrlEXn+rNkFuF0c9vLhCyAViMfYx8+baGj0DxMn
-k+qoimQKRN3XVRRDlyBvQPlQMr0scnXbdp0SygmyVd04canUe3LzYs9Mplhsuvep
-0nBWR7GjtVRnfvUZqdm/uplLCu5o9Nqb4ZmopXuKyjknuXF5C1I/3vZhOjNnZt0O
-k03az7kc5hbH6qiGi1jnpqdEBijP7Wi6fq2sQUZ+0303dLQcRGV2aXNlciA8ZGV2
-aXNlckBmcnFyZWMuY29tPokCHwQwAQgACQUCVNFAdwIdAAAKCRBUwo9P9aGpSdRW
-D/9diYkM3RJoD/gnc5YoPmjde8mICagI/V2+rvw+7zJjQsWuZMgcRqvjPzNKqMU7
-ue/QGagsjN3otLaqC+FZWyTZC4D1hYIBHm8q54/Jpqy0iF8cCjGZ6YDeQ99GR/R2
-Zys+uD1t///Q1KY1vOxQzfBM5ouZ+nQmoSssiIKgQEY+nObRBtAp7LMGseNN+Wik
-1/VC8S/8zp8hSNyAQK/SDlBap1y08PvG6QLWn0RYycyJKXExEq8XoJE28nOzwmoT
-OECUy3jzPtavYrdlLJMSpTN4FWuXzQy4reJ5W9jWqaGbsrsaujuDj2DucEzFfCfL
-181krfYouG7EWJzdDNmdsONchJkz0OMGnox7/A0JK3izYNR2SbxJ+w8FvEK7yZq4
-HX2ZsxtdOryxd0EBhwtEdNxIb3TDMB6yHEEEgua3H3IvwPFejM5HdKmi9N2SqXFE
-mpx7jHnhpdM1PyCvsvL8czTea1VZ4TG79hrgzN5TOeKwhZbQ23lFK/pWdkXNRyag
-xGKvzG/z9o+1VmnOBdRHsu1H+LtNQleBJ3n80Pz9sUJANLuPn3mm5PlGQOX35/ZA
-GIA1nGHw01+J67CsXhR36OkQ+EJCiAlzvW7r+IMtMDGpt1pdzujdl16q2nTr1zoa
-KbdV/msRuMbB2x3TcaVzmIPeBk/esN7pwNUTsZ89BMe7WYkCPwQTAQIAKQUCVC6w
-pQIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEFTCj0/1oalJ
-fgUP/0UgyHxt6B04AqJt19RE0XOgWsMYYLfkVmxzTKR06Rp+Rzl53fV9X20mailt
-eKmw3hFVkqlH65YhNMVvlDEAkNi4rnFgfUAVwZofKqYdzuj6skkq5tnh9W+7d/lN
-uiqmClxE72O/pqcnYqXbd5/YbZdGhLqvmOmjH24XKsRhOoLigrJuzBPMKrQpIxsc
-xwywtTllDX2i5cQHT8dPEXjJwCo80S+4X/wMdwj8k8tKdeMs74Qa5MEdD2+XPZlp
-g/NMwkyOYt35+ATWqtJvj1ps2VQf+h7NgE0JhRv2D2e9B4dDpImaOgHgl9kr9POe
-umTlQIjnLTvjAnKZ3kiv8kFI3/L2iahd8PT2BQh1bCFiCbh/DM49JXmZa4FYwX7w
-JJMtXlSeWOUJ7SpbLMnCOV/ehA549iS/5Hm4/jINqosW/+UhOGUYUJDvJIS82D3q
-wAlypiyP3Edb0w21RFxUmEKz2Bbt7isCIOPqnY6FuiAuHqmnpP4H/mEV9rIaxdZ/
-Rhps29L3ofCD3D0TWlHIAMUWSZdMjuVYWhdFLzq2j4lq5HvZ1tRySd/RsdK7zn6n
-/NOZuBaX+E7Og1fJ34xVDsGsJXFaQHrbs/8N/22m680TfdfAKdOEZgXWiczl9QUi
-RH9BOm25/b60WdwDFi5+7jCqvSeoYVZrJoAkCuErm0oEXC90tCJXYXNzZXJ0dXJt
-IDx3YXNzZXJ0dXJtQGZycXJlYy5jb20+iQIfBDABCAAJBQJU0UB+Ah0AAAoJEFTC
-j0/1oalJySEQAM62TaRt7PWc23XgLYnbpfAiMcMoh4CMlTAEJC7L3b5tS2ZQqglc
-LLY52EfRXwGGLrKHI8BkFml3vhq9uvjbAA6od0+N0x0dvh0NJfDZrmEz9M6d2D8T
-ygRDYnUcfzuZDLi+NudNYHzOo3lcFqPeqeCTmhN1wwoPrm4jmdDHO3a4oqVwFi9b
-X1u2BuTetAizC1N1zkHlljQLPJim2WK5mXq0pMTHwdjds/i8OzJzaXkh0zdFkPnl
-bGfOo2RMXnHlY7TrPVcBUuNPNDmHyqhf77vGatB2sFUU6wJwvN/2+Fl062ZCqpoU
-DzsqBGXyX60gxAUqhoGLDOFm3p7QaUVzR1/iU72vizi8mByO17fJ0mYIjpNLnQJ6
-0CfMrjMW+/jyXOBCiFjqVG0GuFK8vVMlpe6GLAKxR8G9W6idNhNITUqJzI9MZvwM
-dyT7VQQeVUPLrJdGldw73yIgUQ1sXdvNiCSwVujWpM1rIzLCHL6oeAUPFy25L3Nn
-BxAPFwiZkAp+6i9dTRhhFC+XbJqxssNJcv5tQ4fN/qiykgPUQpDmND/SHVjcZVEh
-KUYHrmDQeJKxvQKmUC9pFhJltx/qvwNi6yQOQJmgM+Y3hat8+pcyuYNtbyTgjPpH
-ycxaSr8xL3QFxDHGpP+b5pf6sr4UY26aepKD72866tNtumT1AjN+h9aJiQI/BBMB
-AgApBQJULrBiAhsjBQkJZgGABwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ
-VMKPT/WhqUk4tg//VGii92yAPBfGsgwqTDMwQPSBY9YzAGNng4dATr70YxvS/w0z
-784CDKck3+5OZa2drNQSu3HoDUqovTL1Oq/aeBfpNaEY/rCb589CtjsGoacRFTE6
-fPTHqN5fWeF1Yuwpxjp40i/eIt5DWjnJ+shTF/e2U+SGbC2A3X+2ttkkuaYhPCLw
-Jg4jTfs1H1rKHHMjTapgKI8JIgBbq9IdT+krYJFu8sIB9azxrG08o0xCuNeTplO+
-Yiy8SKtzdERTm2yEECgmpPNqv0k0RTRa3saQbCE+lIEwPZMGFPYc287/eexE1eIo
-olowsaiZkIoeQLLZ6dtRYvi8MkHO5pkLwEOF0gxth/c90KjKJHWGkgrux4HdjS/7
-EtcAV9zH98+hipcTD4rSLAVgFRtEBYwDq7VWCpTPyp3swHg2WZwfsZcYPfYhoCC1
-BSkFQwnrv3Dmm2U3Q2EVV18jfqxmH5pYtqsp/gDrtzlxawU2cdp3PIA4L9Zc7toG
-gCeD5L/eatQf2ArjSR8hDSQPVFZNUIyP2cMzBdY+Lcz0oHKRsbgA/Z3vSGTFhTuV
-ZJl2iBzs7l6TTJ4PZmL4mksWC0XUbKgf8Sd9y206XjXULFuPfcOKf6/12DoYTUkd
-2eHjt8FZ24csFGUR9TRC9AqzuyuvVGniNpfHBMeZ/6OSRsQMCEGECReua3C0H0Rh
-cyBCbHV1bCA8ZGFzYmx1dWxAZnJxcmVjLmNvbT6JAh8EMAEIAAkFAlTRQIQCHQAA
-CgkQVMKPT/WhqUn2Ag/+K3ZI7NsL7RheeoYXWvBteiuoT/qrgIpQKi+d7XuUuJYp
-mIj4tVOknFpmSVo/q/IMqh+gJhlP9yVRToLHSLSZrzVJsb9cGUbL1d/xXxNMZFHL
-sxIhilVxpOFWZt4TYd8hXyWk3Qzb6bXl5rd+VRpv3b2HN4vN4rdXOxqEDqhsbfOD
-QDBdx6SdhfAa4EFeS9IMemjFrza2GBzySrciNRY7Ysx5JM1ac39QTF2RQSzglvAe
-xVXOITc/kz1P4TcybUfRB4J4LkIvch4LmuvYOw2UFhOAsDR8+mm+Iy+O5HviE77S
-SuT4aHyZBQxhtAC7P5JB+32TUkXXn4YK/PZst0Eor0M9ntC6U1cda4DsRmwDZvoM
-NsjxyXxV6iXoDLKKlDeMQx5wP+Tj11gTO6cI5gka6+/CKFiKB9x5YwSRS5z9nnH3
-KyGMTpJeNOFjBL/jqxyes7eqQDIsrHpiboGvoUrXsj1JzAPptWFoHqkZoJ6601uW
-S6Eax6ZM5qAjMYD0Qx6zcjdjGD2xe0W82XtWqNzmo6ZQ8qGL0rExlhbbop5jirlj
-xO0Pszq8fudnhHoB2BD0xMU9WuaaI9vRj/bRtis7TnfqO18In6Hybew3C9X42i7T
-Hh5igOpk48CHkyGl7OXBl2q09TFUCOrHrB7OaEr0DzsX7ZCl3amDPq2wZg737PeJ
-Aj8EEwECACkFAlQusCcCGyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIX
-gAAKCRBUwo9P9aGpSX7yD/9P7bV5/Fa3loeckvKvMB+mzdOPLnBhLQff5QEbLrqk
-JcD9BDfIvXYnUbLa3iEBTUoJpGAA8hEdcnbtV5WNXmJpnoMkH4C4QJocXt4InHoa
-OBxdvG6u8twpq9s/eE5DnuwEB9r86lEoB79XGw9RwpqnvH7RNuL1u6V1wmQTkfZj
-fmM9Q/f4q2W1/TFW37ruj9d3I+HI1cOYAUaJNo3KY4Coogk7/XwZ+CpmF2p8RwoL
-vOq5JFmv4UQ3/660JyGJDovgzJqvq58m3Ia9efujdSEScOID44UlYw2WkdN6BC99
-+oXOrZPJMBLMRcF+4ZyXld2gSa385IerSsk9dqVu7Wsv1EqxvoBHP+8kzOMd4BGj
-su8oTb2KOrD3SWqm0QV7zAOsoNZf5eGP0Q1zGkm9kf8LBkzUltRGRNFI5VwykaSD
-bt1gUImGQbHXl4ASvkJTm4eKmL3vpuD4KYVZ5S6e6pUl0KwBDSjQHQj/L76nRm2T
-HQurZXWpo6+D21OZ+x7VlllbNIgN8VOfHDWssaPh78MbkaPuxnjmX5XCtig6Wj5B
-Rtc05TlscvUFNXUI8HTBDLm4cYcVM2a58SjT0h/k9kt0EU9VqwdwfA5DoPCo591T
-0vfVh9rk6hFS/POOemvKr2655H//foBC8jU+3/MPLStwSqWer7dSPtwCXOOBegM9
-x7QtRGF2aWQgUnVuZ2UgPGRhdmlkLnJ1bmdlQGNhbXB1cy50dS1iZXJsaW4uZGU+
-iQI/BBMBAgApBQJULrAEAhsjBQkJZgGABwsJCAcDAgEGFQgCCQoLBBYCAwECHgEC
-F4AACgkQVMKPT/WhqUlexBAAk0hk4XxFCINtq4ub47LUJXk2V0fdOW72ZEzbcF3Y
-c5R4c2tlTlFHtLJMMn7WmEAdFstP2JHKPb/d1++/BNT5etRaYOAV1hpPvMqs/ELf
-CS3cPKeYgbznElEiIyARwz2Nzbc8ItcuyOCQcHJ2RLHuF7+7HqzKg6JaH00uEZ4/
-UqP0MKOX0VOyBfDW0+vKin2yXrnzNNBhVhWKPtzDtrDViYy+KYbVnnJnzInm/PTI
-jBlLBBtmCyS3aUwpf2BXFVtwd/uwyVZ6hI4zgGwulJqAfIg/eUsKs02/CKdqjhJd
-8f8nsFt8XPznLtsVQrb/4M0hwacl9uv1SaI/rCg+QLKkPkhiE07PotOgEYZVC0Xa
-xnBaGyDyAQd3+ykIa0T2XT6xcVaLGw4+ZYwgDVtOTYwykqg8BEvHuLBlkl2PPWqH
-HbvGCP8FQc9rRVpsNZ6t2rBkvr3M7BsJRi0w3ZKJS+3jymjHnzK01lmB12/LKkPf
-PPWjP1+rRm19kOyMvdiTgiOVYK5C4xv8KxPpU2Whmj1cQPaFxlraab2CEWSS+98C
-izTgB6iReTzTpnEWu3xFk6bM9Zf+M0lu/KKJx0dxXzFLd5CDWHWshDts/WpLjMnn
-dAWccZYhjpadjxU6wJuQpsOnQyUIYZ3cAjcmyRp9XRkJ2nAYBY1OycwdmTVwFaZ7
-ShW0KkRhdmlkIFJ1bmdlIDxydW5nZUBwb29sLm1hdGgudHUtYmVybGluLmRlPokC
-PwQTAQIAKQUCVC6/VQIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA
-AAoJEFTCj0/1oalJKegQAKiTSHcfVsurJzB48cohoDz+VMtGJGGuMTOvM0JJ8Ym3
-22q4Irz84IPq+8SsE1pAQQbcUU6MLjH1Owdzmb1azxM7u8W/HnSZRK6hfs2QAu0f
-R9sQXoaO8/d71ijMrtmM9eIrpoSeY+N/CGBs55F4ZDk0+Nz25q5n5pdiOKfvN1mo
-XMiSx9p5LW+92gIBj3oIHUzuc9qumaxPl/55HMrLRQJSySRkMlirngkO+9Qlxcoj
-YpVRUvjFCJci9LUwZsqpwIJmrNxaATlPH/OSjKEKCMQPER4tOMVr6d+acw8uF/ok
-bQvmlld5Us1NIDuNYibsNqX7Cxtuuhia3Wg6Ma8H+nf0xlc9mf0NQ/7gGNTG2eHM
-IhxgITVx8Caa8j7BLOmuol4Ogl52BPetJlWYIvHrWoqEXo/amgBzGdIqxll378BB
-Mn+TwIO6KTqPp3PYPVgLtOJVAngYnClAdI/fvyopCsBGMNDAmOAxKLLBp4hMzpKG
-pQhr9jSulkzHaNM4G5Iw9LuKrqF2S2j4h8RWLfBocmSJBfmpBnDkLpFgLp5Fl25z
-u/VWCzcTbLi+DRJVPjcsty1ot2EqG3xXdBlonT4odR2z8PazXWD2kBosmUi1xbIJ
-M4jlVSUFjV+d2pA+gSTUXQggsoOQFceT68rRukGP/9A+mq9aXhhlT3BfsVbTJrxK
-tB1EYXZpZCBSdW5nZSA8ZGF2ZUBjLWJhc2Uub3JnPokCPQQTAQgAJwUCViZ/SAIb
-IwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBUwo9P9aGpSS1WD/0W
-wfHT56gldxzliBrZ/0ZAeFc0XC4T2QQ4dunscO9Bby8bvHa/UZbo15ZvQ1zvKOq3
-03nEXEkNO6xhYu5ssR+0aX39wOT1ZeMRGUE3FddGkchgpdqknE1myOIkHr8vX1Qw
-WvzYbSgiUdVdtfPp0VDK4d32I0HWmZKar4XC3CFSD1AAQBFlvaR/xTDRAeRGsAmb
-yDI/6HvGVM/vbl+4lasRMdWUGv3GpkO8Z9JCcp/KTXJVmIuL3jdWMBA0uibLiFIX
-J9+pL/ZTJs3qcNEWsukxS5yBot8KxB0613OKMtNuaTylit43/sEYGgIwF3PmRkPw
-NxXa99tQzjCe2gGPpEzZ/sg5oxVs7hWD2DR6NBplg6MrJg6bF+tQOJlc71XoAgl2
-+DOroyuYObxJ24dS6/+GRI7ZmJIBMIHIEIXWc1SP4sCL9yhpCFKPED2EC7obX1zN
-67M7nAFsEO4yWKECMjUEwbQ15Ch4EzvjXNvXjeAiyErVGx/8GfJxHmygtU6m7eY8
-eVUxM90eRQCdR1lt35M00XxAYNPrnps4TbqZL+XTxvvB0O3WvPyVZzpOB5ioR9M8
-0Hl8sa8JYvDtbrDafMVykdr7bbm4Rp95rjUV+fDrDtp/rNlzteqn/c1wYV1IWrGx
-DvOcNCEyWT4Ce0rzG2fkKXVhKnuuimPsvdn+tyVWAbkCDQRPptXhARAAyFcOVyOn
-MPzrmbmJsh0GM8SGSG75n9zwlXn3n6IPdcd28A8M5XUAx/h1v23bm3xITqjJjf7F
-ECcIROCAvSQwj5CjT710zqj2acR6rkeII04SLCfE9kUq79PSg/jb4qesVUvN48YY
-MsOCSLEXwU1QYrsP+mnLVdrKHhH1d4jmbBYY9DPpVAH4b0UezHQEcqm0mnqMQ6pd
-GkK4BjAe2HKpxV3iLkWgYhA+utwKh8wANzhfi0mQsnKJ0oJx13SBqQCGjsizGwTk
-WKe47WRzFM8lbdzyEi/EuHTE1o0cvbzG2YnA67TULqQ6xvpEoHoIRcMYrqMjAIzG
-MkcN434ViQx1j6y5manddU8PKGgwXCN2fCy8tUM4pxFo1laET2AZT1RWPktB/j76
-1olI6ywundJ7q2q1+EpCgzEWwcO815UEzdtlgQ4hhg2yvXrP1BQGYGqDzixfKMlf
-wg7Pag/U7TE0CbgGO5YNBKzhBrnCxEOrLdRcO7cABgY9/ZfM450a8dks0A7zqs1F
-DwR+aNYZSNGircbsmrN+Xc4Uu2jaWbE+XlBjLr72J19wSLx3g4lEsnVS8e9cS3YX
-BFk/72ke07zzlv2zJDBDutXiQEixUEnXt+4Sz55t45twrRM78KBrjdkhIOcjPWpb
-ndWP5Vm8IXfjbI7w8Hmp6lRaLbRx1mmUrdMAEQEAAYkCJQQYAQIADwUCT6bV4QIb
-DAUJCWYBgAAKCRBUwo9P9aGpSSh6EACfqMRa+MlxmUTii3L4s0WrcZfq24y1keVH
-DW5h7Wof0IhZb5I3xU2Q8hLUQ/qXA13X2aECOKIY6ePbvBffGyNPq1rFSOR4kZh7
-zOZ5yI+STuBBMqvFzJl+caOUcCm+YZWJxsZ71w5q13rbMnm6dyjohPdIIRYhxVxa
-b18CXvZ+GDb1qetHuF3r9DI1gCSHZ7WA5Nsc2VMY1dPN1o3iCACn5tBHPlHucCue
-Ybn+UWzRyDqqCmrBl+I326YOW4xWEohoqJyRpsD/EzUftxI7hmuPoSelZLaUXA3+
-4cjQg0xz5s+AUpU+9KH1gg5civHXGi2rt4rsBKQ/XLzRclwY11Z4jxLzFnN2MfxE
-xQ+baQq0gijjjOba86lQbC+JSV4fuVRK79iw/SDpndzvyeRzb367FA2ZKz4rBVJb
-xHfIhoONpMo0kVB0lpAlcby18M+bNpfF2sRqPthbST5JnvxbXBWIosbzrfEEKt28
-ahbbsKrkVw8bxvDr+ssJSRGMrW56zmfbCGUkohYy4XoQM2xvUEh4tvRGK3kPQ/+b
-eNFnQAlaIzKed1n4M7qpWvdaLvbnFEvULNSgTJ83O7AH3ueKVaTXUelrJjit2QOj
-LEKYN4+JCkQzi/KPw7JGCqJaVdAdVOWzuzNJgQo9NIRR6g54Pm2E2NyeuO40gWJO
-iXokUDiPnw==
-=sElg
------END PGP PUBLIC KEY BLOCK-----
diff --git a/pages/about.rst b/pages/about.rst
index 6277c04..3e47099 100644
--- a/pages/about.rst
+++ b/pages/about.rst
@@ -16,9 +16,10 @@ Maintainer
Contact
-------
-| E-Mail: dave @ thisdomain (`0xF5A1A949 <../cert/dave@sleepmap.de.asc>`_)
+| E-Mail: dave@sleepmap.de (PGP key ``1793DAD5D803A8FFD7451697BB992F9864FAD168``, previously ``91BD8815FE0040FA7FF5D68754C28F4FF5A1A949``)
+| IRC: dvzrv @ {`libera <https://libera.chat/>`_, `hackint <https://hackint.org/>`_, `oftc <https://www.oftc.net/>`_}
+| Matrix: @dvzrv:matrix.org
| XMPP: dvzrv @ thisdomain
-| IRC: dvzrv @ {freenode,hackint,oftc}
| Mobile: +4917647373363
Disclosure
diff --git a/posts/2015/201502-ssh-tunnel-and-postfix.rst b/posts/2015/201502-ssh-tunnel-and-postfix.rst
index 7f18974..ee17b75 100644
--- a/posts/2015/201502-ssh-tunnel-and-postfix.rst
+++ b/posts/2015/201502-ssh-tunnel-and-postfix.rst
@@ -1,7 +1,7 @@
.. title: SSH tunnel with single hop, using systemd-networkd and autossh
.. date: 2015-02-01 20:00 UTC+02:00
.. modified: 2015-02-01 20:00
-.. tags: archlinux, autossh, ssh, tunnel, systemd, systemd.network, postfix, TUN
+.. tags: arch linux, autossh, ssh, tunnel, systemd, systemd.network, postfix, TUN
.. category: admin
.. slug: ssh-tunnel-with-single-hop-using-systemd-networkd-and-autossh
.. summary: HOWTO on setting up a SSH tunnel with the help of a systemd-networkd between two machines, with no direct access to each other and modifying Postfix to use that tunnel.
diff --git a/posts/2015/201504-linux-audio-conference-2015.rst b/posts/2015/201504-linux-audio-conference-2015.rst
index 1df6bdb..be2f852 100644
--- a/posts/2015/201504-linux-audio-conference-2015.rst
+++ b/posts/2015/201504-linux-audio-conference-2015.rst
@@ -1,7 +1,7 @@
.. title: Linux Audio Conference 2015
.. date: 2015-04-03 06:00 UTC+02:00
.. modified: 2015-02-01 20:00
-.. tags: archlinux, systemd, real-time, lac, pro-audio, thesoundofpeople
+.. tags: arch linux, systemd, real-time, lac, pro-audio, thesoundofpeople
.. slug: linux-audio-conference-2015
.. authors: David Runge
.. summary: Installation and workshop at this years Linux Audio Conference
diff --git a/posts/2016/201609-letsencrypt.rst b/posts/2016/201609-letsencrypt.rst
index 4c85993..364c3dc 100644
--- a/posts/2016/201609-letsencrypt.rst
+++ b/posts/2016/201609-letsencrypt.rst
@@ -1,7 +1,7 @@
.. title: Let's encrypt it all
.. date: 2016-09-29 20:00 UTC+02:00
.. modified: 2016-09-30 04:00 UTC+02:00
-.. tags: acme, archlinux, certbot, certificate, dovecot, hidden service, letsencrypt, nginx, openssl, owncloud, postfix, prosody, roundcube, security, ssl, systemd, tls, vpn
+.. tags: acme, arch linux, certbot, certificate, dovecot, hidden service, letsencrypt, nginx, openssl, owncloud, postfix, prosody, roundcube, security, ssl, systemd, tls, vpn
.. category: admin
.. slug: lets-encrypt-it-all
.. summary: A short review on half a year of using |website-letsencrypt| for my services.
diff --git a/posts/2016/201610-uwsgi.rst b/posts/2016/201610-uwsgi.rst
index 886672b..9e6bb50 100644
--- a/posts/2016/201610-uwsgi.rst
+++ b/posts/2016/201610-uwsgi.rst
@@ -1,7 +1,7 @@
.. title: Securely serving webapps using uWSGI
.. date: 2016-10-08 09:00 UTC+02:00
.. modified: 2016-10-08 05:00 UTC+02:00
-.. tags: application server, archlinux, cgit, mediawiki, nginx, owncloud, php, python, redis, roundcube, security, sockets, systemd, uwsgi, webapps, wordpress
+.. tags: application server, arch linux, cgit, mediawiki, nginx, owncloud, php, python, redis, roundcube, security, sockets, systemd, uwsgi, webapps, wordpress
.. category: admin
.. slug: securely-serving-webapps-using-uwsgi
.. summary: An introductory on securely and dynamically serving many webapps with the help of |website-nginx| and |website-uwsgi| with |website-systemd| on |website-archlinux|
diff --git a/posts/2022/arch-a-recap.rst b/posts/2022/arch-a-recap.rst
new file mode 100644
index 0000000..9ac0b19
--- /dev/null
+++ b/posts/2022/arch-a-recap.rst
@@ -0,0 +1,294 @@
+.. title: Arch, a recap
+.. slug: arch-a-recap
+.. date: 2022-01-30 18:0:00 UTC+02:00
+.. tags: arch linux, pro-audio, packaging
+.. category: archlinux
+.. link:
+.. description:
+.. type: text
+
+One of the things, that has kept me (increasingly) busy over the past few years
+is my involvement with the |linux distribution| |arch linux|.
+While I have been using |linux| for probably about 14 years it is frankly hard to
+pinpoint when exactly I went down the rabbit hole that this operating system/
+ecosystem/ community is (relevant |xkcd|). However, I can elaborate on my
+motivation and where that got me.
+
+.. TEASER_END
+
+As a musician of a varying background (from band-based rock music to solo
+performances on guitar or with a modular synthesizer) I have found myself
+evaluating the available pieces of software that are commonly used in music
+production (e.g. |daws| and |audio plug-ins|). Most of them are |proprietary|
+and only available for Windows or macOS (both proprietary as well). During my
+studies a lot of the software in use has also not been |free|, but was provided
+by the university with a *student discount* (e.g. Operating Systems (OSes),
+|ides| or certain types of |vpls|).
+I got increasingly annoyed by dealing with intransparent proprietary OSes,
+|vendor lock-in| schemes, paying for software updates and being driven into
+software piracy for working with so-called *industry standards*.
+
+Some time during the studies for my B.Sc. I decided to "try out Linux", not
+knowing what that would mean actually. So there I was, booting an |ubuntu| Live
+CD and clicking around in an interface, that would install the OS alongside a
+still existing Windows 7. At that point I did not yet know about the joys of
+missing or failing |device drivers|. Many hard fights with the |x window
+system| later I settled on |ubuntu studio| for a while, as it had many nice
+audio related pieces of software available out-of-the-box.
+
+I have always been a person that is interested in *"how things work"*. Soon I
+realized, that the Linux ecosystem consisted of people that thought quite
+similarly. Through various (often distribution specific) online documentation,
+forums, mailing lists and the documentation of software projects for the first
+time I felt as if I could actually learn something that mattered, because it
+was not sold in a box and instead had a community of like-minded people
+gathering around it.
+I found quite appealing that a lot of things were *not polished* and that some
+things were *not easy*, because it provided the sense of achieving something or
+*getting good at something*. Where in Windows land I would have reinstalled the
+OS upon getting intermittent |bluescreens|, in Linux land I just kept reading
+about a certain topic until I was able to fix it myself.
+
+Probably a year after dipping my toes into Linux I bought a new laptop (my
+previous one decided to commit suicide by desoldering its GPU). At that time it
+seemed like a good idea to not dual-boot anymore, as apart from an occasional
+game session I was not using Windows anymore.
+Due to a friend of one of my fellow students I got introduced to Arch Linux,
+which that person used in a (to me) bizarrely minimal fashion by booting from a
+USB stick, as the hard drive in his laptop was broken.
+
+After installing Arch Linux for the first time (probably around 2008) I
+realized quite early on that I would rather continue using it instead of Ubuntu
+Studio, which by that time had given me many issues due to unclear
+configuration management, documentation and graphics driver handling.
+The |arch wiki| already back then was an excellent source of knowledge (and
+still is to this day). Although some articles lack structure or are sometimes
+outdated, it is this trove of knowledge that I had been missing with less
+hands-on distributions up to then.
+The |aur| offered an entrypoint for me to understand how distribution |package
+management| works and how to build my own packages, that I could install using
+the |pacman| package manager. This new found knowledge made me realize how
+inefficient my work on Windows had been in the past (a realization that had not
+fully dawned upon me on Ubuntu Studio as their update model follows a certain
+cadence in which new versions of softwares are updated and otherwise only gain
+bugfix releases). I was suddenly enabled to build packages myself of software
+that I liked and used and I was able to alter existing packages to e.g. fix
+problems or to extend their functionality. I was enabled to upgrade my entire
+system with a single command, while on Windows I had to scavenge websites to
+download installers and run those without knowing whether they were compatible.
+
+As my main focus shifted even further towards pro-audio applications, |dsp|
+languages and recording practices with my M.Sc., I of course do have to mention
+the accumulation of knowledge that |linux audio| represents (e.g. with the
+|linux audio wiki|). It is an invaluable, although by now partially outdated
+and not actively maintained point of - often distribution agnostic -
+information on all things audio on Linux. This ecosystem is what drove and/ or
+documented the development and use of many of the projects at the center of
+what it means to achieve low-latency audio on Linux such as |jack|.
+
+After 2011 I started to conceptualize the Arch Linux distribution also as a
+social construct, that relies on individuals to develop and change it (by
+|getting involved|). While Arch is a distribution that can be used for many
+purposes, the lack of structure or features in e.g. the pro-audio section was
+apparent (although partially covered by packages in the AUR). I was able to do
+most of the projects I was working on at that time using |supercollider| but
+sometimes ran into issues that e.g. Ubuntu Studio had solved in a distribution
+specific way (e.g. by providing packages for the |realtime kernel| to achieve
+very low latencies while recording).
+
+Around 2017 it became apparent that many of the packages that I was using on a
+day-to-day basis were starting to fall behind on updates or had not been
+updated in a long time. It turned out that two packagers that had been active
+packaging audio related software were missing in action or were extremely
+unresponsive. I realized, that unlike a company supported endeavor, Arch Linux
+was a community driven effort and as such required help.
+
+At the time of writing, Arch Linux consists of |arch linux developers|, |arch
+linux trusted users| and |arch linux support staff|. While the first group
+somewhat defines the direction of the distribution itself and takes care of the
+most centric package repositories (``[core]`` and ``[extra]``), the second
+group historically has been an additional group of packagers that takes care of
+the ``[community]`` repository and the AUR and the last group is keeping a lot
+of the infrastructure (e.g. wiki, forums, mailing lists, IRC channels, servers,
+hosted applications) alive.
+
+For outsiders it is possible to join the Support Staff by starting to help
+maintain infrastructure together with the existing staff.
+When looking at the Trusted Users group the barrier of entry is a bit higher,
+as the person gains access to package repositories that are used by thousands
+of users. As such newcomers have to follow a vetting process and be sponsored
+by existing group members (this is similar, but much less clearly defined, for
+Developers).
+
+At the end of 2017 I was able to apply as Trusted User with the help of Ray
+Rashif, who had been maintaining the packages I wanted to help improve and
+update.
+
+Admittedly, the application process has been a bit daunting at the time, but it
+also made me realize, how much I could still improve my package scripts and the
+amount of work that is sometimes required to get things right.
+
+Since becoming a Trusted User in 2017 I have added many new packages in the
+context of a pro-audio package group and spent time on various other packaging
+areas as well.
+In 2019 I have been promoted to Developer and spent some more time on
+non-packaging topics on the side, such as infrastructure improvements
+(|releng|, |arch-release-promotion| and |arch-repo-management|), installation
+medium (|archiso|) and various community related topics (setting up an |rfc
+process| and help holding |arch linux conferences|).
+
+I will follow up on packaging and best practices in an upcoming article
+(hopefully in the not so distant future) and shed some light on the
+non-packaging topics in further articles as well.
+
+That's it for now! I hope you enjoyed reading a user story, that eventually led
+to getting more involved with an international community of (very talented)
+developers working on a challenging project with many facets. As you can
+imagine there are always many more stories to tell, but I tried to give a
+general overview. Maybe I could even get someone interested in reaching out and
+lending a hand in further developing this amazing beast that is Arch Linux :-)
+
+.. |linux distribution| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Linux_distribution">Linux distribution</a>
+
+.. |arch linux| raw:: html
+
+ <a target="blank" href="https://www.archlinux.org">Arch Linux</a>
+
+.. |linux| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Linux">Linux</a>
+
+.. |xkcd| raw:: html
+
+ <a target="blank" href="https://xkcd.com/456/">XKCD</a>
+
+.. |proprietary| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Proprietary_software">proprietary</a>
+
+.. |daws| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Digital_audio_workstation">Digital Audio Workstations (DAWs)</a>
+
+.. |audio plug-ins| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Audio_plug-in">audio plugin-ins</a>
+
+.. |free| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Free-software_license">free</a>
+
+.. |ides| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Integrated_development_environment">Integrated Development Environments (IDEs)</a>
+
+.. |vpls| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Visual_programming_language">Visual Programming Languages (VPLs)</a>
+
+.. |vendor lock-in| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Vendor_lock-in">vendor lock-in</a>
+
+.. |ubuntu| raw:: html
+
+ <a target="blank" href="https://ubuntu.com/">Ubuntu</a>
+
+.. |device drivers| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Device_driver">device drivers</a>
+
+.. |x window system| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/X_Window_System">X Window System</a>
+
+.. |ubuntu studio| raw:: html
+
+ <a target="blank" href="https://ubuntustudio.org/">Ubuntu Studio</a>
+
+.. |bluescreens| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Blue_Screen_of_Death">bluescreens</a>
+
+.. |arch wiki| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/">Arch Wiki</a>
+
+.. |aur| raw:: html
+
+ <a target="blank" href="https://aur.archlinux.org">AUR</a>
+
+.. |package management| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Package_manager">package management</a>
+
+.. |pacman| raw:: html
+
+ <a target="blank" href="https://archlinux.org/pacman/">pacman</a>
+
+.. |dsp| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Digital_signal_processing">DSP</a>
+
+.. |linux audio| raw:: html
+
+ <a target="blank" href="https://linuxaudio.org/">Linux Audio</a>
+
+.. |linux audio wiki| raw:: html
+
+ <a target="blank" href="https://wiki.linuxaudio.org/">Linux Audio Wiki</a>
+
+.. |jack| raw:: html
+
+ <a target="blank" href="https://jackaudio.org/">JACK</a>
+
+.. |getting involved| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/Getting_involved">getting involved</a>
+
+.. |supercollider| raw:: html
+
+ <a target="blank" href="https://supercollider.github.io/">SuperCollider</a>
+
+.. |realtime kernel| raw:: html
+
+ <a target="blank" href="https://wiki.linuxfoundation.org/realtime/start">realtime kernel</a>
+
+.. |arch linux developers| raw:: html
+
+ <a target="blank" href="https://archlinux.org/people/developers/">Developers</a>
+
+.. |arch linux trusted users| raw:: html
+
+ <a target="blank" href="https://archlinux.org/people/trusted-users/">Trusted Users</a>
+
+.. |arch linux support staff| raw:: html
+
+ <a target="blank" href="https://archlinux.org/people/support-staff/">Support Staff</a>
+
+.. |releng| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/releng/">releng</a>
+
+.. |arch-release-promotion| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/arch-release-promotion/">arch-release-promotion</a>
+
+.. |arch-repo-management| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/arch-repo-management/">arch-repo-management</a>
+
+.. |archiso| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/archiso/">archiso</a>
+
+.. |rfc process| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/rfcs/">RFC process</a>
+
+.. |arch linux conferences| raw:: html
+
+ <a target="blank" href="https://conf.archlinux.org/">Arch Linux Conferences</a>
+
diff --git a/posts/2022/managing-binary-package-repositories.rst b/posts/2022/managing-binary-package-repositories.rst
new file mode 100644
index 0000000..89f203f
--- /dev/null
+++ b/posts/2022/managing-binary-package-repositories.rst
@@ -0,0 +1,193 @@
+.. title: Managing binary package repositories
+.. slug: managing-binary-package-repositories
+.. date: 2022-07-02 13:19:59 UTC+02:00
+.. tags: arch linux, packaging, repod, dbscripts
+.. category: archlinux
+.. link:
+.. description:
+.. type: text
+
+In `Packaging for Arch Linux
+<https://sleepmap.de/2022/packaging-for-arch-linux>`_ I described the ins and
+outs of binary repository management and some of the issues that come with the
+tooling currently used by |arch linux|.
+
+In this article I will highlight the work on new tooling and its features.
+
+Since my last write-up on this topic, the project formerly known as
+``arch-repo-management`` has been renamed to ``repod`` (as in *repo-d*) and has
+just seen its first minor release. 🎉
+
+You can find its documentation at https://repod.archlinux.page.
+
+.. TEASER_END
+
+.. note::
+
+ The https://archlinux.page domain has recently been acquired by Arch Linux to
+ serve as the common platform for documentation of projects driven by the
+ distribution.
+
+Please note, that |repod| 0.1.0 is still alpha grade software and **should
+not** be used to actually manage binary package repositories at this point in
+time!
+
+However, it is already possible to do a few things with the software and if you
+are able to test it or are interested in helping develop it, that is very much
+welcomed!
+
+On Arch Linux you can install it using |pacman|:
+
+.. code:: sh
+
+ pacman -S repod
+
+On other distributions (even on macOS!) you may install it using |pip| (|repod|
+is |available on pypi|) until your respective package management system makes
+the software available to you on a system level:
+
+.. code:: sh
+
+ pip install --user repod
+
+Working on repod
+----------------
+
+Since 2021 I have been on and off working on what is now |repod|. The project
+is written in typed |python| and is extensively tested using |pytest|.
+
+Work first began after |arch conf| 2019, at which a working group had looked
+into improving the workflows currently employed by the distribution and pushing
+for tooling that would allow moving away from an |svn| monorepo based approach
+to a deconstructed |git| setup.
+
+A proof of concept (PoC) to mimic the behavior of |dbscripts| had been created,
+but after 2019 this work laid dormant.
+
+Over 2021 I have spent time to transform parts of the PoC into a Python project
+following best practices for development (e.g. type hints following |pep0484|,
+100% test coverage, data validation using |pydantic| models), exposing first
+features in scripts.
+
+In 2022 more work has been done to extend validation and transform the project
+into a package based setup for easier handling and extension in the future.
+
+Concepts of repod
+-----------------
+
+Contrary to |dbscripts|, |repod| follows a paradigm in which it is largely
+decoupled from the |source repository| of the binary packages it maintains and
+aims at becoming a self-contained service.
+
+Package files and their signatures are consumed, relevant metadata is extracted
+and transferred to a |management repository|, which is where the state of
+each |binary repository| is kept.
+
+Available packages in a given |binary repository| are exposed to |pacman| via
+|sync database| files. The |management repository| contents can be
+(transparently and reproducibly) transformed into |sync database| files and
+vice versa.
+
+The above functionality is exposed on the command line via |repod-file|.
+
+Upcoming work
+-------------
+
+As mentioned above, |repod| is not yet stable and still misses quite a few
+features.
+The following topics (and more) will be worked on in the next milestones (not
+necessarily in this order):
+
+* file handling (moving package files from staging areas to actual repositories)
+* signature validation (PGP signature validation of package files)
+* handling of debug packages
+* consolidate schema of |management repository|
+* improve logging throughout the project
+* git backend to transparently expose changes to the |management repository|
+* caching for |management repository| state (e.g. to allow fast searches)
+* API to interact with a |repod| instance over the wire in an authenticated fashion
+* client-side tooling to interact with |repod|'s API
+
+There is still a lot of work to be done, so if you have a background in
+|Python| development and are interested in working on a project that is very
+close to the distribution and will likely improve the workflow of many people
+while making binary repository management more transparent to the user, have a
+look at the project's |contribution guidelines| and do not hesitate to reach
+out!
+
+.. |arch linux| raw:: html
+
+ <a target="blank" href="https://archlinux.org">Arch Linux</a>
+
+.. |repod| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/repod">repod</a>
+
+.. |pacman| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/pacman.8">pacman</a>
+
+.. |pip| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/pip.1">pip</a>
+
+.. |available on pypi| raw:: html
+
+ <a target="blank" href="https://pypi.org/project/repod/">available on pypi</a>
+
+.. |python| raw:: html
+
+ <a target="blank" href="https://www.python.org/">Python</a>
+
+.. |pytest| raw:: html
+
+ <a target="blank" href="https://docs.pytest.org/en/latest/">pytest</a>
+
+.. |arch conf| raw:: html
+
+ <a target="blank" href="https://conf.archlinux.org/">Arch Conf</a>
+
+.. |svn| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/svn.1">svn</a>
+
+.. |git| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/git.1">git</a>
+
+.. |dbscripts| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/dbscripts">dbscripts</a>
+
+.. |pep0484| raw:: html
+
+ <a target="blank" href="https://peps.python.org/pep-0484/">PEP 0484</a>
+
+.. |pydantic| raw:: html
+
+ <a target="blank" href="https://pydantic-docs.helpmanual.io/">pydantic</a>
+
+.. |source repository| raw:: html
+
+ <a target="blank" href="https://repod.archlinux.page/repositories/source_repository.html">source repository</a>
+
+.. |management repository| raw:: html
+
+ <a target="blank" href="https://repod.archlinux.page/repositories/management_repository.html">management repository</a>
+
+.. |binary repository| raw:: html
+
+ <a target="blank" href="https://repod.archlinux.page/repositories/binary_repository.html">binary repository</a>
+
+.. |sync database| raw:: html
+
+ <a target="blank" href="https://repod.archlinux.page/repositories/sync_database.html">sync database</a>
+
+.. |repod-file| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/repod-file.1">repod-file</a>
+
+.. |contribution guidelines| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/repod/-/blob/79a0fa9aa4a4d9def6dad24805f9bbff0388f734/CONTRIBUTING.md">contribution guidelines</a>
+
diff --git a/posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst b/posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst
new file mode 100644
index 0000000..15ce8fb
--- /dev/null
+++ b/posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst
@@ -0,0 +1,182 @@
+.. title: New PGP key ID 1793DAD5D803A8FFD7451697BB992F9864FAD168
+.. slug: new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168
+.. date: 2022-04-30 10:35:57 UTC+02:00
+.. tags: chain of trust, gnupg, gpg, infrastructure, openpgp, sequoia, sq, web key directory, web of trust
+.. category: admin
+.. link:
+.. description:
+.. type: text
+
+As my current |PGP| key ``91BD8815FE0040FA7FF5D68754C28F4FF5A1A949`` will be
+expired soon, I have created a new one to replace it.
+
+You can get my new key ``1793DAD5D803A8FFD7451697BB992F9864FAD168`` as well as
+the old one and the cross-signatures required to establish the |chain of trust|
+between the two via Web Key Directory (|WKD|) (which should be used
+automatically by ``gpg >= 2.1.23``).
+
+To not deal with the rather convoluted |gnupg| tooling I have created a
+deployment method for this using |sequoia-pgp|'s |sq|, about which you can read
+in the rest of this article.
+
+.. TEASER_END
+
+Key servers
+===========
+
+Historically, there has been a set of |key servers|, which have been used to
+distribute the public keys of users centrally and/ or in a synchronized
+fashion. These key servers have been widely relied upon, but they suffer(ed)
+from a lot of issues in regards to privacy, stability and speed. Most notably
+the Synchronized Key Server (|SKS|) system collapsed under its technical debt
+and had to be shut down.
+
+To this day there are still other large, non-synchronized keyserver systems
+around (e.g. |hockeypuck|, which drives https://keyserver.ubuntu.com), but they
+all suffer from the fact, that a large centralized setup, in which keys are
+only ever appended, does not scale.
+
+Additionally, not all keyserver systems support all key types or signatures on
+keys, which is problematic, as they can not reflect upon |chain of trust|
+between two or more keys. This is very problematic for the |web of trust| of
+|PGP|.
+
+Web Key Directory
+=================
+
+At the time of writing the |WKD| system is formalized in
+|draft-koch-openpgp-webkey-service-11|. It describes a decentralized way of
+providing public key material via a given domain's webserver, by exposing
+specially crafted files.
+
+WKD Deployment
+==============
+
+Personally, I believe that the |gpg| commandline interface is incredibly
+convoluted and very complex. I therefore used |sequoia-pgp|'s |sq| instead to
+combine PGP public key material and prepare the required directory structure.
+
+In my personal |wkd| project I assembled a simple system consisting of easy to
+prepare directories in which to place PGP public keys, which are converted to a
+keyring using |sq keyring join|, converted into a |WKD| structure using |sq wkd
+generate| and synchronized using |rsync|.
+
+As I do not provide an ``openpgpkey`` subdomain, I am using a direct domain
+directory structure (see |WKDHosting| for further details).
+
+Using keys from WKD
+===================
+
+In theory all that is required for |gpg| to make use of |WKD| is a version
+``>=2.1.23``. However, its use can be somewhat confusing:
+
+.. code:: sh
+
+ gpg --locate-keys dave@sleepmap.de
+
+The above only returns the new key
+``1793DAD5D803A8FFD7451697BB992F9864FAD168``, but not the old
+``91BD8815FE0040FA7FF5D68754C28F4FF5A1A949``. It is entirely opaque to the user
+as to why.
+
+Meanwhile with |sq wkd get| it is possible to return the public key material of
+both keys:
+
+.. code:: sh
+
+ sq wkd get dave@sleepmap.de
+
+The certificates can be inspected directly using |sq inspect|:
+
+.. code:: sh
+
+ sq inspect --certifications <(sq wkd get dave@sleepmap.de)
+
+Additionally, the certificates can be imported into an existing |gnupg| based
+keyring:
+
+.. code:: sh
+
+ gpg --import <(sq wkd get dave@sleepmap.de)
+
+
+Using |WKD|, the need for providing a separate PGP public key file in the
+context of this website has been made obsolete and I have therefore instead
+replaced it with plain mentions of the PGP key IDs on the `about page
+<https://sleepmap.de/about/>`_.
+
+.. |PGP| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Pretty_Good_Privacy">PGP</a>
+
+.. |chain of trust| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Chain_of_trust">chain of trust</a>
+
+.. |web of trust| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Web_of_trust">web of trust</a>
+
+.. |WKD| raw:: html
+
+ <a target="blank" href="https://wiki.gnupg.org/WKD">WKD</a>
+
+.. |gnupg| raw:: html
+
+ <a target="blank" href="https://gnupg.org/">gnupg</a>
+
+.. |sequoia-pgp| raw:: html
+
+ <a target="blank" href="https://sequoia-pgp.org/">sequoia-pgp</a>
+
+.. |sq| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/sq.1">sq</a>
+
+.. |key servers| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Key_server_(cryptographic)">key servers</a>
+
+.. |SKS| raw:: html
+
+ <a target="blank" href="https://github.com/SKS-Keyserver/sks-keyserver">SKS</a>
+
+.. |hockeypuck| raw:: html
+
+ <a target="blank" href="https://github.com/hockeypuck/hockeypuck">hockeypuck</a>
+
+.. |draft-koch-openpgp-webkey-service-11| raw:: html
+
+ <a target="blank" href="https://tools.ietf.org/id/draft-koch-openpgp-webkey-service-11.html">draft-koch-openpgp-webkey-service-11</a>
+
+.. |gpg| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/gpg.1">gpg</a>
+
+.. |wkd| raw:: html
+
+ <a target="blank" href="https://git.sleepmap.de/dave/wkd.git/">wkd</a>
+
+.. |sq keyring join| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/sq-keyring-join.1">sq keyring join</a>
+
+.. |sq wkd generate| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/sq-wkd-generate.1">sq wkd generate</a>
+
+.. |rsync| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/rsync.1">rsync</a>
+
+.. |WKDHosting| raw:: html
+
+ <a target="blank" href="https://wiki.gnupg.org/WKDHosting">WKDHosting</a>
+
+.. |sq wkd get| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/sq-wkd-get.1">sq wkd get</a>
+
+.. |sq inspect| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/sq-inspect.1">sq inspect</a>
diff --git a/posts/2022/packaging-for-arch-linux.rst b/posts/2022/packaging-for-arch-linux.rst
new file mode 100644
index 0000000..0b27eeb
--- /dev/null
+++ b/posts/2022/packaging-for-arch-linux.rst
@@ -0,0 +1,1152 @@
+.. title: Packaging for Arch Linux
+.. slug: packaging-for-arch-linux
+.. date: 2022-04-06 13:22:53 UTC+02:00
+.. tags: arch linux, packaging, reproducible builds, arch-repo-management, dbscripts
+.. category: archlinux
+.. link:
+.. description:
+.. type: text
+
+In `Arch, a recap <https://sleepmap.de/2022/arch-a-recap>`_ I elaborated a bit
+on my reasons for getting involved with Arch Linux. In this post I would like
+to highlight a few technical details and give a "behind the scenes" when it
+comes to packaging on and for Arch Linux.
+This post is written from the viewpoint of a distribution packager, but it
+is likely to contain information also useful to people packaging on different
+distributions or for private purposes.
+
+.. TEASER_END
+
+|arch linux| is a |linux distribution|, that offers binary packages in
+|software repositories| (aka. repos). To achieve this, packages are built from
+source files using tooling that is developed by the distribution and various
+volunteers. The resulting binary packages are then provided to users on mirrors
+of the distribution (i.e. package files and their cryptographic signatures are
+provided by |web servers|) and are downloaded, verified, validated and
+installed using a |package manager|.
+
+.. note::
+
+ Other distributions may use different concepts. E.g. |gentoo linux| offers
+ installation media that is used to install a base system. From then on users
+ rebuild the software on their systems themselves based on distribution
+ provided source files. There are no binary packages for users to install.
+
+The upsides of a central software package system facilitating binary repos are
+
+- users do not have to build the software on their systems themselves, which
+ e.g. for web browsers can take a very long time and eat a lot of energy
+- software for the entire system can be updated with one command and only takes
+ as long as download and extraction of a given set of packages
+
+Packages
+========
+
+When looking at the concept of binary software packages it probably helps to
+consider the point of view from e.g. Windows and macOS, which both provide
+software to users in different ways and give a good case for comparison. In
+case you already know how binary packages function and compare, skip this
+section.
+
+For brevity I will skip the proprietary app stores in the below examples as
+they abstract the concept of software installation to the point where this is
+opaque to the user and delivers no direct comparison in the context of packages
+(while under the hood most app stores use the below mentioned technologies).
+
+Windows
+-------
+
+On Windows software is usually provided by the means of an installer (e.g.
+shipped as a ``.exe`` or ``.msi`` file). An installer usually needs to be
+downloaded from thirdparty websites (often without verification) and then
+executed one-by-one. The installer often already contains the (prebuilt) files
+to be installed (sometimes files are also downloaded by the installer
+application on-the-fly), offers some form of modification (e.g. the
+installation location), installs the bundled or downloaded files and modifies
+the system's registry (e.g. for auto-start or other features). Although
+Microsoft has attempted to consolidate its installation backends, the user
+experience is usually still a mixed bag.
+System updates (those modifying the operating system) are handled by the OS
+itself and the user usually has not much of a say when/ how that happens (this
+can be modified to some extent). Additionally, some hardware may not use the
+latest version of Windows due to software-based |planned obsolescence|.
+
+MacOS
+-----
+
+On macOS software can be installed using images or installers (shipped as e.g.
+``.dmg`` and ``.pkg`` respectively). The download of the files in question
+usually functions in the same way as it does on Windows (unverified downloads
+from thirdparty websites). Where with images the user experience is usually
+*"drag and drop"* from a mounted image to the list of applications, installers
+on the other hand offer similar functionality to how installers work on Windows
+(e.g. setup auto-starting).
+System updates, similar to those on Windows are handled by macOS itself and
+also here software enforced |planned obsolescence| is a thing.
+
+Looking at the above examples it becomes clear, that automation on both
+platforms is quite terrible: The distinction between OS updates and *"other
+software"* leads to a mix and match approach towards updates, that is (if at
+all) only partly remedied by externally developed and provided package managers
+for some of the *"other software"* (e.g. |homebrew| or |chocolatey|), but at
+best remains a fragmented experience for the user.
+
+Linux
+-----
+
+On distributions that offer binary package repositories, users use a package
+manager to install packages and to upgrade **all software** [1]_ on their
+system.
+Packages are essentially |archive files|, that are downloaded, verified and
+extracted by the package manager. As the files contained in (distribution)
+packages follow a well-defined location schema (e.g. |filesystem hierarchy
+standard| or |file-hierarchy|), the system can check for file conflicts and
+users can usually have reasonable assumptions about where files of a package
+are located (package managers usually also track the files of all packages).
+Additional functionality, such as post install scripts (e.g. to create users or
+to change ownership on files) are usually
+contained in package files and executed after installation. However, on systemd
+based distributions, much of the post installation tasks have been streamlined
+with the help of |sysusers.d| and |tmpfiles.d| (more on that later). Some
+distributions also make use of non-standardized hooks (see |alpm-hooks| for how
+this is implemented for |pacman|), that are used by the package manager for
+certain tasks on files that are not owned by one specific package (e.g. update
+font cache).
+
+Build tooling
+=============
+
+The most basic build tooling for Arch Linux - |makepkg| - is bundled with
+|pacman_website| (the package manager used to install all software packages on the
+distribution). It is used in conjunction with a |PKGBUILD|, which as a package
+source file describes where/ how to get a package's source files (and in which
+version), how to build and test it (if applicable) and how/ where to install
+it.
+
+In case you have experience with |bash|: Both ``makepkg`` and ``PKGBUILDs`` are
+written in it.
+
+When building packages with plain ``makepkg``, the built package will be
+created in the context of the user's system and as such will make use of the
+software available on the user's system. While this works (given all
+dependencies are met) it is not recommended to do so, as the user's
+system may use custom packages or settings to ``makepkg`` (see |makepkg.conf|),
+that can alter the outcome of the build, which may make the package unusable on
+another system.
+
+Clean chroots
+=============
+
+To enable builds, that are done in a clean environment (i.e. one that only has
+official distribution packages installed and does not depend on configuration
+or custom packages on a local system), Arch Linux and various contributors have
+created special build tooling, which is contained in the |devtools| project.
+
+With the help of |makechrootpkg| one can run ``makepkg`` in a |systemd-nspawn|
+based |chroot|, which will only have the packages installed, that are required
+for building, testing and running a given package.
+
+Using |makechrootpkg| and its various repository-specific symlinks is how Arch
+Linux packagers build all packages in the official repositories.
+
+.. note::
+
+ It is generally advisable to build **all packages** in a clean environment.
+
+An implict upside of using ``makechrootpkg`` to build packages is, that
+|checkpkg| and |namcap| are being run on the resulting package, which can give
+valuable hints at possible improvements of the package.
+
+Building packages
+=================
+
+First off: There are sometimes a lot of subtleties involved with packaging and
+especially producing packages that are of good quality. In the following
+sections I will discuss a few tools and packaging specifics, that may seem
+quite overwhelming or complicated at first. Luckily, a lot of the tooling is
+fairly well documented and it is probably always good to remember, that
+everyone is a learner and that as the tooling and the best practices evolve,
+this is an open-ended topic.
+
+A good starting point is always to use ``makechrootpkg`` and to adhere to the
+|arch package guidelines|.
+
+.. note::
+
+ There is the |arch package guidelines category| of more specific guidelines
+ for various programming languages and special use-cases.
+
+Getting package build sources
+-----------------------------
+
+The act of getting the sources for a binary package is described in the context
+of the |arch build system| (ABS). While users without write access to the Arch
+Linux source repositories can rely upon |asp| to get to the package build
+sources, the official packagers rely on a rather organically grown packaging
+workflow, that is described in |howto be a packager|.
+
+At the time of writing, Arch Linux still relies on two monolithic |svn|
+repositories for the package build sources (one for the ``[core]`` and
+``[extra]`` repositories and one for the ``[community]`` and ``[multilib]``
+repositories) which are exported to |git| via |git-svn| on the official Arch
+Linux Github organization (|svntogit-packages| and |svntogit-community|,
+respectively).
+
+.. note::
+
+ Work is underway to switch to |git| for the package build sources. However,
+ this has implications for maintaining state of resulting binary repositories
+ (this is currently done in the svn repositories). While |dbscripts| has been
+ used for managing the state for many years, it is likely to be replaced by
+ |arch-repo-management| in the future.
+ Additionally, it should be mentioned, that such a switch is not trivial after
+ 20 years, if one is also concerned with the technical feasibility and
+ maintainability of the tooling in use.
+
+PKGBUILDs
+---------
+
+As mentioned earlier, |PKGBUILD| files are really just |bash| scripts, that are
+being evaluated by |makepkg|. As such they define a few variables and functions
+(some of which are required, others only being optional).
+
+The below example shows a bare minimum example, derived from the prototype
+files, that can be found in ``/usr/share/pacman/``:
+
+.. code:: sh
+
+ # Maintainer: Your Name <youremail@domain.com>
+ pkgname=dummy-package
+ pkgver=0.1.0
+ pkgrel=1
+ pkgdesc="A dummy package"
+ arch=(any)
+ url="https://my-upstream.link/to/dummy-package"
+ license=(GPL3)
+ depends=(another-package)
+ optdepends=('some-additional: for additional feature X')
+ source=(https://my-upstream.link/to/$pkgname-$pkgver.tar.gz)
+ b2sums=('THISISADUMMYCHECKSUM')
+
+ package() {
+ make DESTDIR="$pkgdir" install -C $pkgname-$pkgver
+ }
+
+To go through the essentials of this very minimalistic example, which assumes
+that we have a project using |make| to install a few files:
+
+- While the ``Maintainer`` comment is technically not required, it is always
+ helpful for others trying to contact the author of a given package build
+ source
+- ``pkgname``: The name of the package. Refer to the wiki section
+ |pkgbuild#pkgname| for further info (e.g. restrictions)
+- ``pkgver``: The (upstream) version of the package. Refer to the wiki section
+ |pkgbuild#pkgver| for further info (e.g. restrictions)
+- ``pkgrel``: The release version of the package, which identifies the build of
+ the particular package in version ``pkgver``. This is a string specific to
+ Arch Linux (see |pkgbuild#pkgrel|) and *is not related to the upstream
+ version* of the software.
+- ``pkgdesc``: A short description of what this package provides
+- ``arch``: The architecture of the resulting package. As this is an array, it
+ can contain several entries (``makepkg`` will envoke a build for each
+ architecture). At the time of writing Arch Linux only supports the ``x86_64``
+ and ``any`` architectures.
+- ``url``: The URL of the upstream project (e.g. a website or a link to the
+ |version control| sources)
+- ``license``: The licenses that apply to the project. This again is an array
+ and may contain several licenses. In case licenses that are not covered by
+ the |licenses package| are encountered, their license files must be installed
+ in the ``package()`` function (refer to the wiki section |pkgbuild#license|
+ for further information).
+- ``depends``: An array of runtime dependencies for the package. They will be
+ installed automatically during build when building with ``makechrootpkg`` or
+ ``makepkg -s``.
+- ``optdepends``: An array of optional dependencies and a short description
+ about their purpose. These packages will not be installed during build time
+ (for this ``makedepends`` needs to be used).
+- ``source``: An array of resources for ``makepkg`` to retrieve. As |makepkg|
+ is able to handle various |version control| systems, local and remote files,
+ as well as to rename files, it is advisable to read the relevant man page
+ section for ``makepkg``.
+- ``b2sums``: An array of checksums for all resources in the ``source`` array.
+ It is advisable to use either (or all of) ``sh256sums``, ``sha512sums`` or
+ ``b2sums`` as older hashing mechanisms are by now unsafe (see
+ |pkgbuild#integrity|). The checksums are used to guard against changing (and
+ potentially malicious) upstream resources. The resources and checksums for a
+ new version of a given package may be retrieved and updated using
+ |updpkgsums| (contained in the |pacman-contrib| package).
+- ``package()``: This function defines all steps necessary to install the files
+ of the upstream project to an empty location (represented by the *magic
+ variable* ``"$pkgdir"``), that will contain all installable files of the
+ package. This function is called using |fakeroot|, which means that to the
+ installing processes it looks like they are being executed by ``root``.
+
+PGP validation
+--------------
+
+Upstream project resources (e.g. signed source tarballs or git tags/ commits)
+can be validated using |pgp|.
+
+.. note::
+
+ While other mechanisms are theoretically possible (e.g. |signify| or
+ |cosign|), they are currently not implemented in the context of |makepkg|.
+
+Technically all that is required for this is,
+that the ``validpgpkeys`` array in the PKGBUILD contains at least one
+retrievable PGP key ID and that the ``source`` array contains either a ``.sig``
+or ``.asc`` file valid for one of the resources, or that a git object to be
+checked is targetted using the ``?signed`` identifier (see
+|makepkg#signature_checking| and |pkgbuild#using_vcs_sources|).
+
+Although it is advisable to have cryptographic signature validation (e.g.
+using |pgp|) for releases, this should only be considered under the following
+circumstances in regards to an upstream project:
+
+* there is a track record of signing releases with the same key ID and the
+ project specifically provides the expectable key ID publicly (e.g. on the
+ website)
+* keeps a |chain of trust| between multiple and/or successive key IDs
+* no key easily used by multiple users is used (e.g. Github's PGP key, which
+ can be used by multiple users of a given Github project and is not handled by
+ the users themselves)
+
+The first point is usually easy to check up on, while the 2nd might require
+getting in touch with the project developers if it happens (or happened in the
+past) - this is the case more often than you would think and does block package
+updates, as a new key ID must not be trusted without investigating the cause
+for a missing |chain of trust| to prevent a potential |supply chain attack|!
+
+.. note::
+
+ I am contemplating to prepare an |arch linux rfc| for this, as the handling
+ of PGP signed sources is not well defined for the distribution and often
+ leads to mishandling (e.g. using new PGP key IDs without having a |chain of
+ trust|).
+
+The 3rd point practically provides a false sense of security: A PGP key signed
+a release of a project, but in actuality multiple members of a project may have
+access to this functionality. From the outside it is impossible to tell who
+triggered a release and signed off on it (it could easily be malicious because
+someone's Github account has been hacked).
+
+Reproducibility
+---------------
+
+Arch Linux as a distribution is committed to packages becoming bit-for-bit
+reproducible (have a look at the overarching |reproducible builds| project for
+more background information on the general topic). The status of the current
+packages in the official repositories is tracked on
+https://reproducible.archlinux.org, which is backed by |rebuilderd|.
+
+After building a package it can be rebuilt using |makerepropkg|, which may use
+|diffoscope| on the resulting package in case it is not reproducible.
+
+As the use of ``makerepropkg`` requires the ``PKGBUILD`` used to build the
+initial package, it can not be used when only a package file is available.
+However, for that use-case |repro| may be used.
+
+.. note::
+
+ Both tools make use of the |buildinfo| files contained in each binary
+ package.
+
+Dealing with the strange
+========================
+
+In `building packages <#building-packages>`_ we have looked at some of the more
+basic use-cases. The following sub-sections will deal with more uncommon or
+very specific ones as well as problems at the intersection of build tooling and
+binary repository management.
+
+Split packages
+--------------
+
+There are situations, in which one wants to build several packages from a
+single ``PKGBUILD``. Those are usually:
+
+- the documentation of the project is very large
+- certain features (e.g. language bindings) are not required by the main
+ application or use-case of the project
+- specific functionality would require a large tree of dependencies but is not
+ required for the main application or use-case
+
+In all three cases this can be handled using a split package setup in which the
+extra functionality (as a package) is declared an optional dependency of the
+main package.
+
+To create a split package, the ``pkgname`` variable of the ``PKGBUILD`` is
+turned into an array, containing multiple package names, while the ``pkgbase``
+variable (see |pkgbuild#pkgbase|) should be set. Additionally, the generic
+``package()`` function needs to be split up into specific functions for each
+package (``prepare()``, ``build()`` and ``check()`` are shared).
+
+Using the example from `PKGBUILDs <#pkgbuilds>`_, this is how it would look
+like when e.g. splitting out documentation (assuming that the upstream project
+provides separate install targets for the components).
+
+.. code:: sh
+
+ # Maintainer: Your Name <youremail@domain.com>
+ pkgbase=dummy-package
+ pkgname=(dummy-package dummy-package-docs)
+ pkgver=0.1.0
+ pkgrel=1
+ pkgdesc="A dummy package"
+ arch=(any)
+ url="https://my-upstream.link/to/dummy-package"
+ license=(GPL3)
+ makedepends=(another-package)
+ source=(https://my-upstream.link/to/$pkgname-$pkgver.tar.gz)
+ b2sums=('THISISADUMMYCHECKSUM')
+
+ package_dummy-package() {
+ depends=(another-package)
+ optdepends=(
+ 'dummy-package-docs: for documentation'
+ 'some-additional: for additional feature X'
+ )
+
+ make DESTDIR="$pkgdir" install-scripts -C $pkgname-$pkgver
+ }
+
+ package_dummy-package-docs() {
+ make DESTDIR="$pkgdir" install-docs -C $pkgname-$pkgver
+ }
+
+Binary repository management
+----------------------------
+
+The resulting packages of a build process can be installed on a local machine,
+but are often of course more useful, if more systems can install them as well.
+For this purpose the repository sync databases exist, which |pacman| uses (see
+|libalpm_databases|) to retrieve the difference between a remote package
+repository and a local machine's state and to figure out which packages to
+upgrade.
+
+The most rudimentary actions (adding and removing packages, optionally signing
+a database) on a binary repository can be done using |repo-add| and
+|repo-remove|, which are shipped with |pacman|. As the tooling is very basic,
+it does not offer any form of state tracking (i.e. a log of actions, such as
+additions or removals done to a sync database by a specific user).
+
+At the time of writing Arch Linux packagers make use of |dbscripts| for the
+binary repository management, which also does (a form of) state tracking by
+interacting with and using the the two |svn|-based monorepos for package build
+sources for this purpose.
+The tooling consists of a set of shell scripts (making use of |repo-add| and
+|repo-remove| internally), that are being called by authorized users on a
+specific host over |ssh|. The user authentification is therefore done using
+|ssh| while the user authorization is implemented using plain unix groups
+(different sets of packagers have access to ``[core]`` and ``[extra]`` vs.
+``[community]`` and ``[multilib]`` - often only for historical reasons).
+However, this setup is showing its age and comes with its own set of pitfalls:
+
+- changes to repositories are not externally auditable
+- package data is only checked rudimentarily
+- integrity of repository sync databases can not be guaranteed
+- repository sync databases can not be rebuilt to a specific state
+- setting the target binary repository for a package is a manual operation
+- due to the blocking nature of dbscripts, it is possible to brick the state of
+ a repository if e.g. connection to the host running dbscripts is lost during
+ the move of packages between two
+ repositories
+- it is not possible to setup rebuild-specific staging repositories on the fly
+- many users need |ssh| access to a machine
+
+This all being said, work is underway with |arch-repo-management| to provide a
+more manageable and easy to configure solution that runs as a service and does
+not rely on multiple users to have direct access on a target system.
+One of the project's main focusses is to be able to verify incoming package
+data and to fully decouple the state from the repository sync databases (to be
+able to rebuild them whenever needed).
+Going forward it should become more easy to setup ephemeral staging
+repositories to build against and safer to move data due to more atomic
+repository operations, while allowing externals to audit each repository's
+history. Currently the project is still far from being usable though and there
+are quite a few things left to be implemented. Switching from the current setup
+in which both package build sources and binary repository state are handled by
+one |version control| system, to one where these concerns are separated is a
+hard problem, especially when one wants to get this right.
+I hope that going forward we will end up with a solution that can be easily
+contributed to and reused also outside of Arch Linux. I will write another post
+in the coming months, that highlights work and concepts of
+|arch-repo-management|.
+
+Distributing trust
+------------------
+
+Packagers use the |makepkg.conf| variables ``PACKAGER`` and ``GPGKEY`` to set
+the packager user ID (i.e. name and e-mail address) and the PGP key ID used for
+signing created packages.
+
+Other users that wish to use packages signed by someone else need to import
+that other user's PGP public key using |pacman-key|.
+
+Arch Linux maintains a |web of trust| between a set of main signing keys and
+all packagers and between all packagers amongst themselves (see the |main keys|
+page for an extensive overview). This setup allows for user systems to evaluate
+whether a given package signature done by a packager is considered trusted (see
+|pacman.conf#package_and_database_signature_checking| for further info).
+These constructs are system-wide PGP keyrings for the use with |pacman| and can
+be handled with |pacman-key|.
+
+.. note::
+
+ The main signing keys are considered **fully trusted** on a user system. They
+ define the root trust for the distribution which is handed down to the
+ packagers.
+
+In the |archlinux-keyring| project the distribution trust of Arch Linux is
+maintained as a set of decomposed PGP public keys and the signatures on them.
+The custom tooling ``keyringctl`` (which uses |sequoia|'s ``sq`` under the
+hood) is used to maintain (e.g. import public keys and signatures) a PGP
+keyring that is packaged in the |archlinux-keyring package| and which is
+automatically added and updated upon install.
+
+More than or equal to three main signing key holders are required to uphold
+the web of trust. More than or equal to three valid main key signatures are
+required for a packager key (if it is itself still valid) to be allowed for
+distributing packages in the official Arch Linux repositories.
+
+.. note::
+
+ Writing the new tooling ``keyringctl`` to manage the distribution trust has
+ been a huge topic of the past year, that |Levente Polyak| and I have been
+ working on, as the previous setup was very brittle. I will elaborate a bit
+ more on that topic in an upcoming post.
+
+
+Sonames
+-------
+
+Linux distributions mostly build C and C++ libraries and executables using
+|dynamic linking|. This implies, that shared libraries usually provide a
+|soname| (e.g. ``libexample.so.1``), which is in turn used (i.e. linked
+against) by one or more other libraries or executables.
+If the |application binary interface| (ABI) of the library in question changes,
+its |soname| should be increased as well (e.g. ``libexample.so.2``). If a
+package with an updated soname is released and installed, without rebuilding
+any of the packages depending on it, those will fail to load (the now
+non-existent) ``libexample.so.1`` shared object.
+
+A common task as a packager is therefore to do rebuilds for libraries and
+executables when a soname change is introduced. Depending on the library
+introducing the soname change or the library/executable being affected by it,
+this is sometimes a bit of a painful and time consuming experience.
+While it is not unheard of that projects either forget to introduce a soname
+change (silently breaking consumers) or accidentally downgrade their soname,
+consumers are more likely to run into trouble because of not yet implementing
+changes introduced by the ABI change (requiring patches not yet included in a
+stable release).
+
+To safeguard against cases in which soname changes went unnoticed and packages
+are pushed to the repositories, it is possible to make use of |makepkg|'s
+builtin dependency resolution. Extending upon the example in `PKGBUILDs
+<#pkgbuilds>`_ and assuming that ``libexample`` is the package providing
+``libexample.so``:
+
+.. code:: sh
+
+ # Maintainer: Your Name <youremail@domain.com>
+ pkgname=libexample
+ pkgver=1.0.0
+ pkgrel=1
+ pkgdesc="A dummy library"
+ arch=(any)
+ url="https://my-upstream.link/to/libexample"
+ license=(GPL3)
+ depends=(glibc)
+ provides=(libexample.so)
+ source=(https://my-upstream.link/to/$pkgname-$pkgver.tar.gz)
+ b2sums=('THISISADUMMYCHECKSUM')
+
+ build() {
+ make -C $pkgname-$pkgver
+ }
+
+ package() {
+ make DESTDIR="$pkgdir" install -C $pkgname-$pkgver
+ }
+
+.. code:: sh
+
+ # Maintainer: Your Name <youremail@domain.com>
+ pkgname=dummy-package
+ pkgver=0.1.0
+ pkgrel=1
+ pkgdesc="A dummy package"
+ arch=(any)
+ url="https://my-upstream.link/to/dummy-package"
+ license=(GPL3)
+ depends=(another-package libexample libexample.so)
+ optdepends=('some-additional: for additional feature X')
+ source=(https://my-upstream.link/to/$pkgname-$pkgver.tar.gz)
+ b2sums=('THISISADUMMYCHECKSUM')
+
+ build() {
+ make -C $pkgname-$pkgver
+ }
+
+ package() {
+ make DESTDIR="$pkgdir" install -C $pkgname-$pkgver
+ }
+
+If during build time ``libexample`` provided ``libexample.so.1``, the resulting
+``dummy-package`` will now depend on ``libexample`` and ``libexample.so=1-64``,
+which ``libexample`` provides.
+
+If the ``libexample`` package is then updated while accidentally including a
+soname bump to ``libexample.so.2``, |pacman| will prevent this package from
+being upgraded on a user's system, because it can no longer provide
+``libexample.so.1``, which is required by its consumers (i.e.
+``dummy-package``).
+This only helps against immediate breakage on already installed systems. On
+systems that are about to be installed it would lead to pacman not being able
+to resolve the dependencies and bailing out. It is therefore to be considered a
+stop-gap solution which allows for fixing the package(s) in question, while not
+immediately breaking consumers of ``libexample``.
+
+In the future this feature will be directly built into |makepkg|, removing the
+manual process of identifying shared libraries (and their sonames) which are
+provided by packages.
+
+.. note::
+
+ To identify the sonames provided by a package, |find-libprovides| can be
+ used. Reversely, to identify the sonames required by a specific package
+ |find-libdeps| can be used.
+
+Debug packages
+--------------
+
+The ability to debug software using e.g. |gdb| is very powerful, as it allows
+users to provide vital information about failing software to the packagers and
+upstream projects. For this to work, a package's debug symbols need to be
+provided to the debugger.
+In February 2022 Arch Linux has started using |debug packages and debuginfod|,
+which allows just that.
+
+Creating a package and additionally also building its debug symbols has now
+become as easy as adding ``debug`` to the ``options`` array in a |pkgbuild|
+(until this option eventually is added to the default for packagers of the
+distribution).
+
+.. note::
+
+ At the time of writing not all issues with non-|file-hierarchy| compliant
+ files and directories have been solved yet, but a large set of debug packages
+ have already been built across all official repositories.
+
+Creating users
+--------------
+
+Historically, system users and groups for packages have been created
+using ``.install`` scripts (see |pkgbuild#install|). This had the downside of
+requiring a specific |user identifier| (UID) and/or |group identifier| (GID)
+(see |UID/ GID database| for specific assignments) if file ownerships also
+needed to be handled in the context of a package.
+Additionally, the user and group creation was not standardized and required a
+script (run as ``root``), which was only run *after* creating and installing
+the package and therefore not easily testable.
+
+With the adoption of |systemd| and specifically |sysusers.d| the workflow has
+changed to installing a single file in the context of a package to the vendor
+location ``/usr/lib/sysusers.d/``. Based on the |systemd| |alpm-hooks| setup
+the configuration is applied using |systemd-sysusers|.
+
+Changing files after package installation
+-----------------------------------------
+
+Similar to how system users and groups have been created in the past, file
+modifications (e.g. ownership, |extended file attributes| or |setuid|) have
+been done using ``.install`` scripts or directly in PKGBUILDs. The problem with
+this approach was, that it required the specific assignment and pinning of UIDs
+and GIDs when creating the required users and groups, *before* doing the file
+modifications (e.g. using |chown|).
+
+This task has been made less complex with |tmpfiles.d|, which allows for
+packaging a single file in a package to the vendor location
+``/usr/lib/tmpfiles.d/``. Due to the ordering of |alpm-hooks| first users
+and groups are created and only afterwards the file configuration is applied
+using |systemd-tmpfiles|, allowing for diverse scenarios.
+
+Packaging
+=========
+
+Working on packages for software written in different languages (e.g. |php|,
+|python|, |ruby|, |c|, |c++| or |rust|) using various build systems surely
+makes for a very interesting Github profile eventually (due to providing issue
+reports and fixes to many projects).
+
+You can find the |list of my packages| amongst the official repositories.
+Moreover I currently maintain two |unofficial user repositories|: |[realtime]|
+and |[pro-audio-legacy]|
+
+Packaging can be a fun but also a very time consuming and frustrating pastime.
+As such there are many many more examples and specifics I could list (but this
+article is already quite dense I am afraid).
+
+.. note::
+
+ None of the Arch Linux package maintainers are payed for their work, which
+ they do solely in their free time and the project is not a commercial
+ endeavor. Some dependency chains are fairly complex and require time and
+ care. The reasons as to why a package is not updated is not always obvious to
+ the outside and it could be due to various technical problems or the packager
+ just lacking the time. Please be mindful about this and instead of getting
+ upset try to lend a helping hand packaging (it is usually much appreciated)
+ or consider |getting involved|.
+
+At any rate, I hope I could spark your curiosity! If you are interested in
+finding out more about packaging for specific languages or best practices,
+the following are some good starting points:
+
+* |arch package guidelines| and |arch package guidelines category|
+* |#archlinux| and |#archlinux-aur| on |libera.chat|
+
+.. note::
+
+ Update: I have fixed some typos. Thanks to Andreas Schleifer (Segaja) for
+ noticing them!
+
+ Update: I have fixed more typos. Thanks to `doesntthinkmuch
+ <https://www.reddit.com/user/doesntthinkmuch/>`_ for noticing them.
+
+.. [1] I am excluding `flatpak <https://flatpak.org/>`_ and `snap
+ <https://snapcraft.io/>`_ in this article as they follow an app-store/
+ per-user installation paradigm. However, they relate to system's packaging
+ in that they provide precompiled binaries in a predefined format.
+
+.. |arch linux| raw:: html
+
+ <a target="blank" href="https://archlinux.org">Arch Linux</a>
+
+.. |linux distribution| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Linux_distribution">Linux distribution</a>
+
+.. |software repositories| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Software_repository">software repositories</a>
+
+.. |web servers| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Web_server">web servers</a>
+
+.. |package manager| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Package_manager">package manager</a>
+
+.. |gentoo linux| raw:: html
+
+ <a target="blank" href="https://www.gentoo.org/">Gentoo Linux</a>
+
+.. |planned obsolescence| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Planned_obsolescence">planned obsolescence</a>
+
+.. |homebrew| raw:: html
+
+ <a target="blank" href="https://brew.sh/">Homebrew</a>
+
+.. |chocolatey| raw:: html
+
+ <a target="blank" href="https://chocolatey.org/">Chocolatey</a>
+
+.. |archive files| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Archive_file">archive files</a>
+
+.. |filesystem hierarchy standard| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard">filesystem hierarchy standard</a>
+
+.. |file-hierarchy| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/core/systemd/file-hierarchy.7.en">file-hierarchy</a>
+
+.. |tmpfiles.d| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/tmpfiles.d.5.en">tmpfiles.d</a>
+
+.. |sysusers.d| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/sysusers.d.5.en">sysusers.d</a>
+
+.. |alpm-hooks| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/alpm-hooks.5">alpm-hooks</a>
+
+.. |makepkg| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/makepkg.8">makepkg</a>
+
+.. |pacman| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/pacman.8">pacman</a>
+
+.. |pacman_website| raw:: html
+
+ <a target="blank" href="https://archlinux.org/pacman/">Pacman</a>
+
+.. |PKGBUILD| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/core/pacman/PKGBUILD.5.en">PKGBUILD</a>
+
+.. |bash| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Bash_(Unix_shell)">Bash</a>
+
+.. |makepkg.conf| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/makepkg.conf.5">makepkg.conf</a>
+
+.. |devtools| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/devtools">devtools</a>
+
+.. |makechrootpkg| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/makechrootpkg.1">makechrootpkg</a>
+
+.. |systemd-nspawn| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/systemd-nspawn.1">systemd-nspawn</a>
+
+.. |chroot| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/chroot.1.en">chroot</a>
+
+.. |checkpkg| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/checkpkg.1">checkpkg</a>
+
+.. |namcap| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/namcap.1">namcap</a>
+
+.. |arch package guidelines| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/Arch_package_guidelines">Arch package guidelines</a>
+
+.. |arch package guidelines category| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/Category:Arch_package_guidelines">Arch package guidelines category</a>
+
+.. |arch build system| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/Arch_Build_System">Arch Build System</a>
+
+.. |asp| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/asp.1">asp</a>
+
+.. |howto be a packager| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/DeveloperWiki:HOWTO_Be_A_Packager">HOWTO be a packager</a>
+
+.. |svn| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/svn.1">svn</a>
+
+.. |git| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/git.1">git</a>
+
+.. |git-svn| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/extra/git/git-svn.1.en">git-svn</a>
+
+.. |svntogit-packages| raw:: html
+
+ <a target="blank" href="https://github.com/archlinux/svntogit-packages">svntogit-packages</a>
+
+.. |svntogit-community| raw:: html
+
+ <a target="blank" href="https://github.com/archlinux/svntogit-community">svntogit-community</a>
+
+.. |dbscripts| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/dbscripts">dbscripts</a>
+
+.. |arch-repo-management| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/arch-repo-management">arch-repo-management</a>
+
+.. |make| raw:: html
+
+ <a target="blank" href="https://www.gnu.org/software/make/">make</a>
+
+.. |pkgbuild#pkgname| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/PKGBUILD#pkgname">PKGBUILD#pkgname</a>
+
+.. |pkgbuild#pkgver| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/PKGBUILD#pkgver">PKGBUILD#pkgver</a>
+
+.. |pkgbuild#pkgrel| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/PKGBUILD#pkgrel">PKGBUILD#pkgrel</a>
+
+.. |version control| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Version_control">version control</a>
+
+.. |licenses package| raw:: html
+
+ <a target="blank" href="https://archlinux.org/packages/core/any/licenses/">licenses package</a>
+
+.. |pkgbuild#license| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/PKGBUILD#license">PKGBUILD#licenses</a>
+
+.. |pkgbuild#integrity| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/PKGBUILD#Integrity">PKGBUILD#Integrity</a>
+
+.. |updpkgsums| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/updpkgsums.8">updpkgsums</a>
+
+.. |pacman-contrib| raw:: html
+
+ <a target="blank" href="https://archlinux.org/packages/?q=pacman-contrib">pacman-contrib</a>
+
+.. |fakeroot| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/fakeroot.1">fakeroot</a>
+
+.. |pgp| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Pretty_Good_Privacy">PGP</a>
+
+.. |signify| raw:: html
+
+ <a target="blank" href="https://github.com/aperezdc/signify">signify</a>
+
+.. |cosign| raw:: html
+
+ <a target="blank" href="https://github.com/sigstore/cosign">cosign</a>
+
+.. |makepkg#signature_checking| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/Makepkg#Signature_checking">makepkg#signature_checking</a>
+
+.. |pkgbuild#using_vcs_sources| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/PKGBUILD.5.en#USING_VCS_SOURCES">PKGBUILD#USING_VCS_SOURCES</a>
+
+.. |chain of trust| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Chain_of_trust">chain of trust</a>
+
+.. |supply chain attack| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Supply_chain_attack">supply chain attack</a>
+
+.. |arch linux rfc| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/rfcs">Arch Linux RFC</a>
+
+.. |reproducible builds| raw:: html
+
+ <a target="blank" href="https://reproducible-builds.org/">Reproducible Builds</a>
+
+.. |rebuilderd| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/rebuilderd.1">rebuilderd</a>
+
+.. |makerepropkg| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/makerepropkg.1">makerepropkg</a>
+
+.. |diffoscope| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/diffoscope.1">diffoscope</a>
+
+.. |repro| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/repro.8">repro</a>
+
+.. |buildinfo| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/core/pacman/BUILDINFO.5.en">.BUILDINFO</a>
+
+.. |pkgbuild#pkgbase| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/PKGBUILD#pkgbase">PKGBUILD#pkgbase</a>
+
+.. |libalpm_databases| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/libalpm_databases.3">libalpm_databases</a>
+
+.. |repo-add| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/repo-add.8">repo-add</a>
+
+.. |repo-remove| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/repo-add.8">repo-remove</a>
+
+.. |ssh| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/ssh.1">ssh</a>
+
+.. |web of trust| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Web_of_trust">web of trust</a>
+
+.. |main keys| raw:: html
+
+ <a target="blank" href="https://archlinux.org/master-keys/">main keys</a>
+
+.. |pacman.conf#package_and_database_signature_checking| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/pacman.conf.5#PACKAGE_AND_DATABASE_SIGNATURE_CHECKING">pacman.conf#PACKAGE_AND_DATABASE_SIGNATURE_CHECKING</a>
+
+.. |pacman-key| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/pacman-key.8">pacman-key</a>
+
+.. |archlinux-keyring| raw:: html
+
+ <a target="blank" href="https://gitlab.archlinux.org/archlinux/archlinux-keyring/">archlinux-keyring</a>
+
+.. |sequoia| raw:: html
+
+ <a target="blank" href="https://sequoia-pgp.org/">sequoia</a>
+
+.. |archlinux-keyring package| raw:: html
+
+ <a target="blank" href="https://archlinux.org/packages/core/any/archlinux-keyring/">archlinux-keyring package</a>
+
+.. |Levente Polyak| raw:: html
+
+ <a target="blank" href="https://leventepolyak.net/">Levente Polyak</a>
+
+.. |dynamic linking| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Dynamic_linker">dynamic linking</a>
+
+.. |soname| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Soname">soname</a>
+
+.. |application binary interface| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Application_binary_interface">application binary interface</a>
+
+.. |find-libprovides| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/find-libprovides.1">find-libprovides</a>
+
+.. |find-libdeps| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/find-libdeps.1">find-libdeps</a>
+
+.. |gdb| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/gdb.1">gdb</a>
+
+.. |debug packages and debuginfod| raw:: html
+
+ <a target="blank" href="https://archlinux.org/news/debug-packages-and-debuginfod/">debug packages and debuginfod</a>
+
+.. |pkgbuild#install| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/PKGBUILD#install">PKGBUILD#install</a>
+
+.. |user identifier| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/User_identifier">user identifier</a>
+
+.. |group identifier| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Group_identifier">group identifier</a>
+
+.. |UID/ GID database| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/DeveloperWiki:UID_/_GID_Database">UID/ GID database</a>
+
+.. |systemd| raw:: html
+
+ <a target="blank" href="https://systemd.io/">systemd</a>
+
+.. |systemd-sysusers| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/systemd-sysusers.8">systemd-sysusers</a>
+
+.. |extended file attributes| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Extended_file_attributes#Linux">extended file attributes</a>
+
+.. |setuid| raw:: html
+
+ <a target="blank" href="https://en.wikipedia.org/wiki/Setuid">setuid</a>
+
+.. |chown| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/chown.1">chown</a>
+
+.. |systemd-tmpfiles| raw:: html
+
+ <a target="blank" href="https://man.archlinux.org/man/systemd-tmpfiles.8">systemd-tmpfiles</a>
+
+.. |php| raw:: html
+
+ <a target="blank" href="https://www.php.net/">PHP</a>
+
+.. |python| raw:: html
+
+ <a target="blank" href="https://www.python.org/">Python</a>
+
+.. |ruby| raw:: html
+
+ <a target="blank" href="https://www.ruby-lang.org/en/">Ruby</a>
+
+.. |c| raw:: html
+
+ <a target="blank" href="https://www.iso.org/standard/74528.html">C</a>
+
+.. |c++| raw:: html
+
+ <a target="blank" href="https://isocpp.org/">C++</a>
+
+.. |rust| raw:: html
+
+ <a target="blank" href="https://www.rust-lang.org/">Rust</a>
+
+.. |#archlinux| raw:: html
+
+ <a target="blank" href="ircs://irc.libera.chat/archlinux">#archlinux</a>
+
+.. |#archlinux-aur| raw:: html
+
+ <a target="blank" href="ircs://irc.libera.chat/archlinux-aur">#archlinux-aur</a>
+
+.. |libera.chat| raw:: html
+
+ <a target="blank" href="https://libera.chat/">libera.chat</a>
+
+.. |list of my packages| raw:: html
+
+ <a target="blank" href="https://archlinux.org/packages/?sort=&q=&maintainer=dvzrv&flagged=">list of my packages</a>
+
+.. |unofficial user repositories| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/Unofficial_user_repositories">unofficial user repositories</a>
+
+.. |[realtime]| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/Unofficial_user_repositories#realtime">[realtime]</a>
+
+.. |[pro-audio-legacy]| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/Unofficial_user_repositories#pro-audio-legacy">[pro-audio-legacy]</a>
+
+.. |getting involved| raw:: html
+
+ <a target="blank" href="https://wiki.archlinux.org/title/Getting_involved">getting involved</a>
+
diff --git a/posts/2023/grants-for-operating-systems.md b/posts/2023/grants-for-operating-systems.md
new file mode 100644
index 0000000..270fdac
--- /dev/null
+++ b/posts/2023/grants-for-operating-systems.md
@@ -0,0 +1,158 @@
+<!--
+.. title: Grants for Operating Systems
+.. slug: grants-for-operating-systems
+.. date: 2023-11-14 10:00:00 UTC+01:00
+.. tags: arch linux, funding, ngi, nlnet, prototype fund, software development, sovereign tech fund
+.. category: archlinux
+.. link:
+.. description:
+.. type: text
+-->
+
+Over the past years I have written (unsuccessful) funding applications for free software projects, associated with the [Arch Linux] Operating System.
+This article is about my experiences with applying for numerous funds and my advice for people trying to get their work funded.
+
+TL;DR: Writing funding applications is extremely tedious and the selection process mostly intransparent and discouraging. Depending on what you apply for and who you apply with, you may never get funding due to other, additional factors.
+
+<!-- TEASER_END -->
+
+## Projects, projects, projects
+
+For some time now, I have been working as a freelance software developer. As such, my work time is more flexible, than that of an employee.
+As *my hobby*, I have - aside from packaging - been working on several projects related to [Arch Linux], such as [archiso], [releng], [repod] and more recently [ALPM related Rust crates].
+As you can probably imagine, working on a software project can be very time consuming, especially when it comes to longterm maintenance efforts or improving legacy code.
+With all of the above projects I have mainly been working on infrastructure related topics. Do note, that even this handful of projects is just a small subset of all the infrastructure related [software projects], that keep Arch Linux rolling. All of these are developed and maintained by volunteers in their free time. This is very different from Linux distributions with commercial backing (e.g. [Fedora] or [Ubuntu]), which often have a budget for internal projects.
+
+After spending significant time with packaging and package related tooling, I did quite a bit of work on [repod], in the hopes of improving the package repository management story for [Arch Linux] (see [Managing binary package repositories]).
+This allowed me to estimate work packages and get a grip on how long implementation of certain features would take.
+Most of the work on the project took long consecutive hours and was therefore not necessarily something just for a quiet afternoon or evening.
+At this point I was contemplating to work full-time on the project for a bit to get more features off the ground.
+
+## Funds
+
+As a German citizen I am blessed with local, as well as European assocations and foundations, that provide funding programs for free software projects.
+In 2022 I evaluated the programs of [ProtoType Fund] (funded by German tax money, driven by [Open Knowledge Foundation Deutschland e.V.]) and [NLnet] (funded by [European Commission] money).
+Both have funded projects big and small over the past years and select their projects in several rounds per year based on received applications, which are reviewed by a public jury or an intransparent gremium of unknown people.
+Funds are provided to freelance individuals or small groups of freelancing individuals.
+
+[ProtoType Fund] has - as the name implies - a focus on prototypes of public interest tech, which can be funded with up to 47.500€ for six months per project. The association selects projects with the help of a rotating, publicized [ProtoType Fund jury].
+
+[NLnet] interfaces with several programs of varying points of focus, which it maintains with several other organizations and provides funds between 5.000 and 50.000€ per project. The foundation selects projects using a multi-stage process based on an unknown set of *"independent experts from the internet and open source field, academia and the public sector"*.
+Large funding sums, that are handed out by [NLnet], are in fact provided by the [European Commission] *Next Generation Internet* ([NGI]) initiative and are made available to [NLnet] and a set of other organizations through [NGI Assure] and [NGI Zero], to be spent on projects.
+
+In 2023 I evaluated the [Sovereign Tech Fund], which is a relatively young organization, that offers funding for maintenance and improvement of existing ecosystems. Spending German tax money, the organization provides projects world-wide with funding starting at 150.000€.
+The review process for applications is coupled with German law and no specific information on jury or reviewing experts can be found.
+
+## Writing applications
+
+As mentioned in the beginning, writing applications is quite tedious, especially if you are not used to writing these types of texts.
+My takeaways from having written a few by now, and not being a professional in that field, is:
+
+* ensure that the content and framing of your application is a good match for the theme of the grant you apply for
+* start early
+* do several iterations
+* invite people from various backgrounds to read the application and provide feedback
+* use simple language
+* do not get too technical (non-technical people will review your application, too)
+* stay concise
+* ensure you specifically target mentioned points of interest (aka. "hit the buzzwords")
+
+Although this process may seem overwhelming at first, it is useful to look at it from the angle of promoting your project to non-technical people and those unaware of your field of interest.
+It is important to stay concise while doing so. All application forms have either a char limit (😬), or a word limit.
+
+To give a rough outline of an application process, it is worth noting, that although one has handed in an application, the review process only starts after the deadline of the application process has been reached.
+Depending on organization, the review process may take between four weeks up to three months for an applicant to receive some form of acknowledgement or turn down.
+If the funding organization has a multi-stage process, they may get back with further questions and clarifications.
+
+### ProtoType Fund
+
+In 2022 I wrote applications for [repod] in two funding rounds (12 and 13) of [ProtoType Fund].
+While the process was straight forward, the char limit of the submission form proved quite annoying.
+
+The evaluation process took around eleven weeks in the first application round and ten in the second. Both applications were turned down.
+There seem to have been 171 applicants in round 12 (of which 21 - 12.28% - were selected) and 150 in round 13 (of which 23 - 13.45% - were selected).
+The numbers outline, that competition is quite high for these grants.
+
+Although a project like [repod] meets probably some of the funding criteria, in hindsight it is likely too much of a backend and infrastructure project to be of real interest to [ProtoType Fund].
+Unfortunately, [ProtoType Fund] does not provide any specific feedback when turning down an applicant (the answer is kept quite formal and generic). This makes it very hard to understand whether a problem with the form or the topic of the application has been the grounds for rejection.
+
+### NLnet
+
+In 2022 I also started writing applications for [repod] for [NLnet] managed funds (i.e. [NGI Assure] and [User-Operated Internet Fund]). The application process was straight forward, this time with an enforced word limit. Due to technical issues, I did not receive a confirmation email for the applications, but after prompting the [NLnet] team about it, they replied swiftly and confirmed them manually.
+
+Both applications were turned down within seven weeks in the first review round. To the applicant it is unfortunately not transparent how many other projects applied and even finding a program-specific list of funded projects is a bit tedious on the organization's website. The email answer did not provide further details as to whether a problem with the form or the topic of the application has been the grounds for rejection. Receiving a generic rejection message makes iterating on potentially just misaligned applications not possible.
+
+In a second round in 2022 I applied again for [repod] for [NLnet]'s [User-Operated Internet Fund], [NGI Assure] and [NGI Zero Entrust] programs. All three were again turned down within seven weeks in the first review round (in fact I only ever got rejection mails for the [NGI Assure] and [User-Operated Internet Fund] programs, but after contacting [NLnet], it became clear that the rejection mail for [NGI Zero Entrust] just got lost).
+
+In a third round in 2023 I applied for a new set of [ALPM] related projects (more on those in a future article) with [NLnet]'s [NGI Zero Core] program. After a bit more than seven weeks I received a reply, that the application had been chosen for the second round of reviews and that I would receive further questions. Three days later I received a list of more in-depth questions, that I needed to answer (and did to the best of my abilities).
+Six weeks later I received the rejection for this application as well, again with a generic message.
+
+### Sovereign Tech Fund
+
+In 2023 I applied for funding for the [ALPM] related projects as part of the *"Improving FOSS Developer Tooling"* topic of the [Sovereign Tech Fund challenges].
+The application process was fairly well laid out, albeit on a tight schedule.
+
+After a bit more than eight weeks I received a generic rejection email, that again does not help the applicant to improve on their application.
+Another seven weeks later, the organization announced the [selected projects of the challenges program]: Nine out of 70 (12.86%) projects had been selected.
+
+A more generic application for [Sovereign Tech Fund] for the [ALPM] projects has also been sent, but given the above success stories, I am not holding my breath.
+Furthermore, the organization appears to target more mainstream and industrially interesting Operating System projects such as the [Yocto Project] and [Gnome Foundation] (which each are backed by other companies and foundations as well).
+
+## Conclusion
+
+Although the previous sections read rather depressing (which admittedly they are to me), I think there are a few takeaways to be had from all this.
+
+Several things come to mind, when evaluating past experiences with funding organizations:
+
+* organizations providing funding for free software projects are very important for the ecosystem as a whole and there should be more of them
+* the industry at large should be funding all software they rely on for their business (news flash: most do not)
+* organizations providing funding opportunities should be more transparent about how their decision making processes work (especially if they are handling public money)
+
+For people trying to apply for funding for their free software project I would like to provide the following advice:
+
+* write applications with several people to bounce off ideas and to share the discouragement of receiving many rejections
+* get ready for many rejections, unless you happen to hit a funding organization's sweet spot
+* getting funding for infrastructure related topics, especially on Operating Systems without a huge interest in marketing, is *hard*
+* write *many* applications
+* document your process, as it is easy to lose track of ongoing applications due to the long waiting time and low probability of receiving a grant
+* if you are working on a low-level backend related topic, [ProtoType Fund] is likely not what you should be applying for
+* do not apply for funding for a topic, that you might be working on (slowly) in your free time, to not block yourself on waiting for a reply from a funding organization
+
+To sum up my past efforts:
+
+* I wrote seven applications for [repod] and three for [ALPM] projects (half of which were probably terrible)
+* out of ten only one even got considered for a second round review
+* in total I waited 56 weeks on replies since March 2022 (not counting still ongoing applications), averaging on 8.5 weeks per application
+
+I will likely try to apply for funding again at some point in the future (but most likely not with [NLnet], but more on that in the next article).
+However, if you are interested in funding any of my work for [Arch Linux], consider contracting me for a project or sponsoring me on [GitHub].
+
+Closing, I would like to thank everyone, that helped write and/ or improve any of the applications written in the past years.
+
+[Arch Linux]: https://archlinux.org
+[archiso]: https://gitlab.archlinux.org/archlinux/archiso
+[releng]: https://gitlab.archlinux.org/archlinux/releng
+[repod]: https://gitlab.archlinux.org/archlinux/repod
+[ALPM related Rust crates]: https://gitlab.archlinux.org/archlinux/alpm
+[software projects]: https://wiki.archlinux.org/title/Getting_involved#Software_projects
+[Fedora]: https://fedoraproject.org/
+[Ubuntu]: https://ubuntu.com/
+[Managing binary package repositories]: https://sleepmap.de/2022/managing-binary-package-repositories/
+[ProtoType Fund]: https://prototypefund.de/en/
+[Open Knowledge Foundation Deutschland e.V.]: https://okfn.de/en/
+[NLnet]: https://nlnet.nl/
+[NGI]: https://www.ngi.eu/
+[ALPM]: https://gitlab.archlinux.org/archlinux/alpm
+[User-Operated Internet Fund]: https://nlnet.nl/useroperated/index.html
+[NGI Assure]: https://www.ngi.eu/ngi-projects/ngi-assure
+[NGI Zero]: https://www.ngi.eu/ngi-projects/ngi-zero/
+[NGI Zero Core]: https://nlnet.nl/core
+[NGI Zero Entrust]: https://nlnet.nl/entrust
+[ProtoType Fund jury]: https://prototypefund.de/en/apply/jury/
+[Sovereign Tech Fund]: https://sovereigntechfund.de/en/
+[Sovereign Tech Fund challenges]: https://sovereigntechfund.de/en/challenges/
+[selected projects of the challenges program]: https://mastodon.social/@sovtechfund/111261375834330869
+[European Commission]: https://en.wikipedia.org/wiki/European_Commission
+[Yocto Project]: https://yoctoproject.org/
+[Gnome Foundation]: https://foundation.gnome.org/
+[GitHub]: https://github.com/dvzrv/
diff --git a/posts/2023/operating-system-bias-in-next-generation-internet-and-nlnet.md b/posts/2023/operating-system-bias-in-next-generation-internet-and-nlnet.md
new file mode 100644
index 0000000..39fe311
--- /dev/null
+++ b/posts/2023/operating-system-bias-in-next-generation-internet-and-nlnet.md
@@ -0,0 +1,293 @@
+<!--
+.. title: Operating System Bias in Next Generation Internet and NLnet
+.. slug: operating-system-bias-in-next-generation-internet-and-nlnet
+.. date: 2023-11-16 13:00:00 UTC+01:00
+.. tags: alpm, arch linux, european commission, funding, guix, next generation internet, ngi, nix, nixos, nixos foundation, nlnet, package manager, software development
+.. category: archlinux
+.. link:
+.. description:
+.. type: text
+-->
+
+In [Grants for Operating Systems] I discussed my journey through the grant application writing business since beginning of last year.
+To keep things light and somewhat focused, I left out a topic, that I would like to write about in more detail in the following sections.
+
+It's about selection bias in grants provided by Next Generation Internet ([NGI]), that can be applied for directly or through [NLnet].
+
+<!-- TEASER_END -->
+
+---
+📝 Before going into further detail, I would like to point out several things:
+
+* I believe funding programs such as [NGI] and [NLnet] are a very important pillar of a free and decentralized computing world
+* I *do not* wish any harm upon any of the involved organizations or any of their employees
+* This article is here to document my personal experiences and findings based on publicly available data, in the hopes of addressing what appears to be a selection bias
+* Although none of the [Arch Linux] related funding requests discussed in my previous article have been approved, I have been involved with Operating System agnostic projects, funded through [NLnet], but applied for by other people, in the past
+---
+
+## Round two
+
+With my latest [NLnet] application for funding work on [ALPM] projects, I managed to reach round two.
+
+To give a bit of preliminary background on what those projects are about (a more detailed article on them will follow):
+
+During the work on [repod] I noticed, that many of the metadata files used in [Arch Linux]'s packaging do not have a specification and no common parsers and validators. This required writing a lot of additional code for the consumption and validation of those files and I noticed that several efforts across other languages and projects existed.
+I realized, that it would be best to provide central specifications, parsers and writers, which could be used all across the stack. As such, the [ALPM] projects are a very [Arch Linux] packaging specific attempt at improving the tooling of this community-driven distribution.
+
+Given the above, it felt rather strange to read loaded questions in my set of round two questions, that implied users seeking more guarantees should just move to distribution agnostic functional [package manager]s, such as [Nix] or [Guix], as those could be combined with [Arch Linux] without effort.
+
+I attempted to reply by outlining why funding for the packaging subsystem of community-driven distributions is important and that "just replace everything with Nix" is not the answer for [Arch Linux] and its users.
+
+ > Using a package management system other than pacman on Arch Linux is not supported and is in fact likely to break the system.
+ > Users that wish to use nix or guix can use dedicated distributions such as NixOS.
+ >
+ > Arch Linux and its maintainers have spent decades building up expertise in integrating their custom package management system with various init systems, dedicated tooling and languages.
+ > Arch Linux follows central principles (https://wiki.archlinux.org/title/Arch_Linux#Principles), that encourage a simple, rolling release, “follow upstream” approach. As such it differs from other distributions.
+ >
+ > Arch Linux’s thousands of users are familiar with its package management system. A radical change, such as replacing the package management subsystem is nothing that can be done on a whim or is even realistic given the steep learning curve of learning one.
+ >
+ > Working on the Arch Linux Package Management framework ensures the diversity in a small set of original, community driven Linux distributions (such as Debian, Arch Linux, NixOS), for which public funding is essential.
+
+Other questions revolved around topics such as comparison with other standardization and file format efforts, allotted time for the work (which was deemed too high), future changes to file formats and generalizing parsers using structured format.
+
+As mentioned in my previous article, my application was rejected after another six weeks after my reply. As the rejection message was generic, I do not know whether any of the answers (or all of them) were dissatisfactory.
+
+## Investigating Bias
+
+The [package manager] related questions in my second round review struck me as very odd and led me to do some deeper investigation into the [NLnet] and [NGI] funding setup and to ask a few people, that received OS-agnostic funding about their experiences.
+
+People's experience with the review process seems to be largely identical to mine. However, in at least one occasion an applicant got an actual specific (non-generic) reason for their rejected [NLnet] application towards an [NGI Zero] grant (which was surprising even to them).
+In at least one other case, a person was asked to make their application run on [NixOS] after receiving their final payment.
+
+I started to look further into the [NixOS] story in this context and discovered several connections between [NLnet] and [NixOS Foundation].
+
+For the unaware: [Nix] is the system [package manager] used on [NixOS] and [NixOS Foundation] has the mission to *"[..] support the Nix ecosystem's infrastructure, and projects implementing the purely functional deployment model."* [^1]
+I use [Nix] and [NixOS] interchangeably throughout the following subsections, as the [package manager] is tightly coupled with the Operating System.
+
+Through membership in [NGI Zero], [NixOS Foundation] is part of [NGI Zero Core], [NGI Zero Entrust], [NGI Zero PET] and [NGI Zero Review] (see [background info on NGI Zero Core], [background info on NGI Zero Entrust], [background info on NGI Zero PET] and [background info on NGI Zero Review], respectively).
+
+In an attempt at giving an overview of [Nix] and [Guix] vs. other Operating System and system [package manager] projects funded by [NLnet], I went through several program pages to collect affiliated projects. This proved to be not so easy, as the website follows varying style approaches and does not offer a search functionality, which hinders filtering by keyword. So please take the following numbers with a grain of salt!
+
+I manually searched through overview pages linked to in the following sections, using `nix` and `guix` as search term to correlate projects, that stand in some relation to [NixOS Foundation]/ [NixOS] or [Guix].
+I did the same using the `OS`, `operating system` and `package` search terms to sieve through projects, that have some relation to other specific general-purpose Operating Systems and do not provide generic features (e.g. VPN or firewall stack on Linux, etc.), or concern themselves with other system [package manager]s.
+The percentages for occurrences are rounded up to the 2nd position after decimal point.
+
+Do note, that the [NLnet] projects largely appear to be not tied to specific Operating Systems!
+
+### NGI Assure
+
+There are 145 [ongoing NGI Assure projects].
+
+Eight [Nix] related (5.52%):
+
+* [https://nlnet.nl/project/Dream2nix](https://nlnet.nl/project/Dream2nix)
+* [https://nlnet.nl/project/Dream2nix-Python](https://nlnet.nl/project/Dream2nix-Python)
+* [https://nlnet.nl/project/Nix-TypeInference](https://nlnet.nl/project/NixOS-Services)
+* [https://nlnet.nl/project/NixOS-Clevis](https://nlnet.nl/project/NixOS-Services)
+* [https://nlnet.nl/project/NixOS-Services](https://nlnet.nl/project/NixOS-Services)
+* [https://nlnet.nl/project/NixOS-UEFI](https://nlnet.nl/project/NixOS-UEFI)
+* [https://nlnet.nl/project/Tvix](https://nlnet.nl/project/Tvix)
+* [https://nlnet.nl/project/p4-nix](https://nlnet.nl/project/p4-nix)
+
+Seven [Guix] related (4.83%):
+
+* [https://nlnet.nl/project/GNUMes-ARM_RISC-V](https://nlnet.nl/project/GNUMes-ARM_RISC-V)
+* [https://nlnet.nl/project/GNUMes-RISCV](https://nlnet.nl/project/GNUMes-RISCV)
+* [https://nlnet.nl/project/GNUMes-RISCV-bootstrap](https://nlnet.nl/project/GNUMes-RISCV-bootstrap)
+* [https://nlnet.nl/project/GNUMesTower](https://nlnet.nl/project/GNUMesTower)
+* [https://nlnet.nl/project/Gash](https://nlnet.nl/project/Gash)
+* [https://nlnet.nl/project/Guix-P2P](https://nlnet.nl/project/Guix-P2P)
+* [https://nlnet.nl/project/Guix-Riscv64](https://nlnet.nl/project/Guix-Riscv64)
+
+Three other OSes, mostly special purpose or mobile (2.07%):
+
+* [https://nlnet.nl/project/MaemoLeste-Telepathy](https://nlnet.nl/project/MirageVPN)
+* [https://nlnet.nl/project/MirageVPN](https://nlnet.nl/project/MirageVPN)
+* [https://nlnet.nl/project/OpenCryptoLinux](https://nlnet.nl/project/OpenCryptoLinux)
+
+I was not able to find any other system [package manager] related projects.
+
+### NGI Zero Core
+
+There are 21 [ongoing NGI Zero Core projects].
+
+I was not able to find any [Nix] related projects.
+
+One [Guix] related (4.76%):
+
+* [https://nlnet.nl/project/GuixDaemon-Guile](https://nlnet.nl/project/GuixDaemon-Guile)
+
+Four other Operating System related projects, mostly special purpose or mobile (19.05%):
+
+* [https://nlnet.nl/project/MobileSettings](https://nlnet.nl/project/MobileSettings)
+* [https://nlnet.nl/project/SlintAndroid](https://nlnet.nl/project/SlintAndroid)
+* [https://nlnet.nl/project/WPE-Android](https://nlnet.nl/project/WPE-Android)
+* [https://nlnet.nl/project/pmOS-23-24](https://nlnet.nl/project/pmOS-23-24)
+
+I was not able to find any other system [package manager] related projects.
+
+### NGI Zero Entrust
+
+There are 150 [ongoing NGI Zero Entrust projects].
+
+Six [Nix] related (4%) projects:
+
+* [https://nlnet.nl/project/CloudHostingServicePortability](https://nlnet.nl/project/CloudHostingServicePortability)
+* [https://nlnet.nl/project/Genealogos](https://nlnet.nl/project/Genealogos)
+* [https://nlnet.nl/project/GorgonCI](https://nlnet.nl/project/GorgonCI)
+* [https://nlnet.nl/project/Liminix](https://nlnet.nl/project/Liminix)
+* [https://nlnet.nl/project/NixDebugAdaptor](https://nlnet.nl/project/NixDebugAdaptor)
+* [https://nlnet.nl/project/SelfPrivacy](https://nlnet.nl/project/SelfPrivacy)
+
+I was not able to find any [Guix] related projects.
+
+Six other Operating System related projects, mostly special purpose or Android (4%):
+
+* [https://nlnet.nl/project/Irdest-OpenWRT-BLE](https://nlnet.nl/project/Irdest-OpenWRT-BLE)
+* [https://nlnet.nl/project/Makatea](https://nlnet.nl/project/Makatea)
+* [https://nlnet.nl/project/Replicant-Pinephone](https://nlnet.nl/project/Replicant-Pinephone)
+* [https://nlnet.nl/project/SeedVault-Integrity](https://nlnet.nl/project/SeedVault-Integrity)
+* [https://nlnet.nl/project/Spectrum-Applications](https://nlnet.nl/project/Spectrum-Applications)
+* [https://nlnet.nl/project/Trenchboot-AEM](https://nlnet.nl/project/Trenchboot-AEM)
+
+I was not able to find any other system [package manager] related projects.
+
+### NGI Zero PET
+
+There are 144 [ongoing NGI Zero PET projects].
+
+Three [Nix] related (2.1%):
+
+* [https://nlnet.nl/project/Robotnix](https://nlnet.nl/project/Robotnix)
+* [https://nlnet.nl/project/Spectrum](https://nlnet.nl/project/Spectrum)
+* [https://nlnet.nl/project/mobile-nixos](https://nlnet.nl/project/mobile-nixos)
+
+Three [Guix] related (2.1%):
+
+* [https://nlnet.nl/project/Cuirass](https://nlnet.nl/project/Cuirass)
+* [https://nlnet.nl/project/GNUMes](https://nlnet.nl/project/GNUMes)
+* [https://nlnet.nl/project/GNUMes-fullsource](https://nlnet.nl/project/GNUMes-fullsource)
+
+Eight other Operating System related projects, mostly special purpose or Android (5.56%):
+
+* [https://nlnet.nl/project/Seedvault](https://nlnet.nl/project/Seedvault)
+* [https://nlnet.nl/project/WireGuardonWindows](https://nlnet.nl/project/WireGuardonWindows)
+* [https://nlnet.nl/project/postmarketOS](https://nlnet.nl/project/postmarketOS)
+* [https://nlnet.nl/project/seL4-64bitVMM](https://nlnet.nl/project/seL4-64bitVMM)
+* [https://nlnet.nl/project/BetrustedOS](https://nlnet.nl/project/BetrustedOS)
+* [https://nlnet.nl/project/Dataspaces/](https://nlnet.nl/project/Dataspaces/)
+* [https://nlnet.nl/project/Replicant-graphics](https://nlnet.nl/project/Replicant-graphics)
+* [https://nlnet.nl/project/ReplicantUpdate](https://nlnet.nl/project/ReplicantUpdate)
+
+I was not able to find any other system [package manager] related projects.
+
+### Internet Hardening Fund
+
+There are 24 [projects of the Internet Hardening Fund].
+
+One [Nix] related (4.17%):
+
+* [https://nlnet.nl/project/webservicesecurity](https://nlnet.nl/project/webservicesecurity)
+
+I was neither able to find any [Guix] related projects, nor any related to other Operating Systems or other system [package manager]s.
+
+### User-Operated Internet Fund
+
+There are eleven [projects of the User-Operated Internet Fund].
+
+One is an Operating System specific project (9.10%).
+
+* [https://nlnet.nl/project/Armbian/](https://nlnet.nl/project/Armbian/)
+
+I was neither able to find any [Nix] or [Guix] related projects, nor any related to other system [package manager]s.
+
+### NGI Zero Review
+
+There are no publicly associated projects with the [NGI Zero Review] program, but the program itself promotes the use of [Nix] for *"[b]est practices on packaging and reproducible builds"* [^2] (see this [pull request towards the NixOS homepage to replace this problematic terminology]) for projects, that are mentored by it. It is unclear whether [NixOS Foundation] is compensated for this mentoring role.
+
+### Further data on NixOS Foundation and NGI Zero
+
+According to a [Summer of Nix 2022 interview], *"the [European Commission] through [DG CNECT] has partnerships with [NLnet] and the [NixOS Foundation]"*, funding several projects.
+Furthermore, the [European Commission] appears to be facilitating and encouraging the use of [NixOS] internally, trying to replace other operating systems. The platform [code.europa.eu] is mentioned as a place for development of software and services related to European Union institutions.
+
+When looking at the [NixOS Foundation's Financial Summary] for 2022, it shows an influx of 140.000€ of *"[f]unds from NLnet Foundation for the specific programs (i.e. Summer of Nix)"*. These are potentially for some of the above mentioned projects in the various [NLnet] related programs, for which [NixOS Foundation] may be handling payments to individuals (although [NLnet] grants are usually given to individuals). However, from reading the statement alone, it is unclear whether this is tied to individual grants, compensation for work on [NGI Zero Review], or even other things.
+
+The above data points at a direct or at least indirect monetary conflict of interest for [NixOS Foundation] in the context of [NGI Zero], which in my opinion ultimately serves as a bias for any decision making process done in the context of that coalition.
+My believe is, that the decision making process is therefore intrinsically skewed, because [NGI Zero] appears to be set up to promote one specific Operating System ([NixOS]) and [package manager] ([Nix]).
+Looking at the numbers, also [NGI Assure] appears to be affected by this.
+
+## Conclusion
+
+Considering the previous sections provides a rather depressing outlook for non-[NixOS] general-purpose Linux distributions, as well as for non-[Nix]/[Guix] package management systems, when it comes to funding opportunities through [NLnet] or [NGI].
+
+Of the 495 [NLnet] projects I sieved through (mostly superficially), 18 (3.64%) appear to be [Nix] related, eleven (2.22%) [Guix] related, while 22 (4.44%) account for the *entire rest* of Operating System specific projects. I was not able to find any other system [package manager] related project.
+
+While I am convinced, that people related to [NixOS] write great applications, for me it is hard to believe that there are so few (good) applications by developers working on other packaging ecosystems, that not a single one was ever able to receive funding.
+Relatedly, I neither believe, that it is right to ask those developers to replace their ecosystem with [Nix], nor be judged on the base of working on something that is not [Nix].
+As such I believe that the above list of projects does not provide a balanced funding reality.
+
+Therefore I would like to extend my points on funding organizations in my previous article:
+
+* Technological bias in funding organizations claiming to *"[..] reflect the openness, diversity and the inclusion that are at the core of European values"* [^3] should be circumvented, or otherwise clearly stated.
+
+Analogous, I would like to extend the advice for people trying to get their work funded by:
+
+* If you are working on an Operating System related topic and you are not working on [NixOS], consider whether your time will be well spent on applying for [NGI Zero] related funds or probably even [NLnet] programs in general, as - given the publicly available data - there appears to be a bias on the [European Commission] level at play, that will very likely lead to your project not being selected or it getting very hard to be selected.
+* If you are working on a system [package manager] other than [Nix] or [Guix], there is currently no data supporting the assumption, that this work would be funded when applying with [NLnet].
+
+As I am not sure how well received this article will be with some of the organizations, I have neither mentioned people, that have helped review or write my applications, nor those, that I have asked about their experiences.
+
+While I hope, that there will be no backlash towards people I interacted with, I realize, that this article may make some people uncomfortable and even undermine my chances of ever getting funding in the future. Either way, I believe it was the right thing to do and I arrive at the following conclusions and questions for myself:
+
+* Given the above data points, why does [NGI] (and [NLnet] by extension) not more clearly state, that they are (seemingly) not interested in funding work on other [package manager] ecosystems? While I do not know how many others have applied for similar projects to mine, nor do I claim to speak for this unknown number of people, I would have loved to not waste my time on an application, that seems to have little chance of ever being accepted.
+* The reasoning behind enforcing one specific [package manager] and Operating System in [NGI] is intransparent to outsiders. It is unclear to me when this decision was made, and under what circumstances the [European Commission] decided on it. The previously mentioned [Summer of Nix 2022 interview] seems to indicate, that the [European Commission] wants to switch to [NixOS] for its own services. This begs the question: Why do they not just contract with one of the [consulting companies available for professional support]? Biased funding on the other hand will have a huge impact on the ecosystem at large (and in my opinion not for the better).
+* There is *a lot of work* to be done in all community-driven Linux distributions and this work has merit. Focusing only on one distribution will achieve two things: Destroying diversity and invalidating the work thousands of people have been doing in their free time for decades (often even trying to make a living by providing services around those Operating Systems).
+
+There are many open questions and my hopes are, that the [European Commission], [NGI] and [NLnet] reevaluate their focus on seemingly funding only one packaging ecosystem.
+I would be happy to receive feedback from people related to other Linux distributions, that interacted with [NGI] and [NLnet], as well as from officials involved with the decision making process in the [European Commission], [NGI] and [NLnet] and will update the post accordingly.
+Writing this, I am still hopeful, that my post can be a first step towards improving the current situation and that funds directed at critical infrastructure projects will be distributed more evenly amongst widely used Operating System projects (big and small, well marketed and quiet).
+
+[^1]: [https://nixos.org/community/index.html](https://nixos.org/community/index.html)
+[^2]: [https://nlnet.nl/NGI0/review](https://nlnet.nl/NGI0/review)
+[^3]: [https://digital-strategy.ec.europa.eu/en/library/internet-humans-how-we-would-internet-future-be](https://digital-strategy.ec.europa.eu/en/library/internet-humans-how-we-would-internet-future-be)
+
+[Grants for Operating Systems]: https://sleepmap.de/2023/grants-for-operating-systems/
+[NLnet]: https://nlnet.nl/
+[ALPM]: https://gitlab.archlinux.org/archlinux/alpm
+[repod]: https://gitlab.archlinux.org/archlinux/repod
+[Arch Linux]: https://archlinux.org
+[NGI]: https://www.ngi.eu/
+[Guix]: https://guix.gnu.org/
+[package manager]: https://en.wikipedia.org/wiki/Package_manager
+[European Commission]: https://en.wikipedia.org/wiki/European_Commission
+[NixOS]: https://nixos.org/
+[Nix]: https://nixos.org/
+[NixOS Foundation's Financial Summary]: https://discourse.nixos.org/t/nixos-foundations-financial-summary-a-transparent-look-into-2022/28107#sources-of-incoming-funds-2
+[NGI]: https://www.ngi.eu
+[NGI Assure]: https://www.ngi.eu/ngi-projects/ngi-assure
+[User-Operated Internet Fund]: https://nlnet.nl/useroperated/index.html
+[ALPM]: https://gitlab.archlinux.org/archlinux/alpm
+[NGI Zero]: https://www.ngi.eu/ngi-projects/ngi-zero/
+[NLnet's current projects]: https://nlnet.nl/project/current.html
+[postmarketOS]: https://postmarketos.org/
+[QubesOS]: https://www.qubes-os.org/
+[NixOS Foundation]: https://nixos.org/nixos/foundation.html
+[NGI Zero Core]: https://nlnet.nl/core
+[NGI Zero Entrust]: https://nlnet.nl/entrust
+[NGI Zero PET]: https://nlnet.nl/PET
+[NGI Zero Review]: https://nlnet.nl/NGI0/review
+[ongoing NGI Assure projects]: https://nlnet.nl/thema/NGIAssure.html
+[ongoing NGI Zero Core projects]: https://nlnet.nl/thema/NGIZeroCore.html
+[ongoing NGI Zero Entrust projects]: https://nlnet.nl/thema/NGI0Entrust.html
+[ongoing NGI Zero PET projects]: https://nlnet.nl/thema/NGIZeroPET.html
+[projects of the Internet Hardening Fund]: https://nlnet.nl/internethardening/
+[projects of the User-Operated Internet Fund]: https://nlnet.nl/thema/User-operatedInternetFund.html
+[background info on NGI Zero Core]: https://nlnet.nl/core/background/index.html
+[background info on NGI Zero Entrust]: https://nlnet.nl/entrust/background/index.html
+[background info on NGI Zero PET]: https://nlnet.nl/PET/background/index.html
+[background info on NGI Zero Review]: https://nlnet.nl/NGI0/review/background/index.html
+[pull request towards the NixOS homepage to replace this problematic terminology]: https://github.com/NixOS/nixos-homepage/pull/1077
+[Summer of Nix 2022 interview]:https://www.youtube.com/watch?v=I7wdcJ3YhoU&t=310s
+[DG CNECT]: https://knowledge4policy.ec.europa.eu/organisation/dg-cnect-dg-communications-networks-content-technology_en
+[code.europa.eu]: https://code.europa.eu
+[consulting companies available for professional support]: https://nixos.org/community/commercial-support
diff --git a/state_data.json b/state_data.json
deleted file mode 100644
index e6fc5b9..0000000
--- a/state_data.json
+++ /dev/null
@@ -1,3 +0,0 @@
-{
- "last_deploy": "2019-04-20T23:42:40.798717"
-} \ No newline at end of file