diff options
| -rw-r--r-- | conf.py | 21 | ||||
| -rw-r--r-- | posts/2022/managing-binary-package-repositories.rst | 193 | ||||
| -rw-r--r-- | posts/2022/new-pgp-key-id-1793dad5d803a8ffd7451697bb992f9864fad168.rst | 182 | ||||
| -rw-r--r-- | posts/2023/grants-for-operating-systems.md | 158 | ||||
| -rw-r--r-- | posts/2023/operating-system-bias-in-next-generation-internet-and-nlnet.md | 293 |
5 files changed, 835 insertions, 12 deletions
@@ -951,23 +951,20 @@ 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 © {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://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>' + '<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>" ) @@ -1039,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/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/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 |