Introduction

Over the past couple of weeks, I have been working on understanding and improving def-extractor.py , a Python script that processes dictionary data from Wiktionary to generate word lists and definitions in structured formats. My main task has been to refactor the script to use configuration files instead of hardcoded values, making it more flexible and maintainable.

In this blog post, I’ll explain:

1. What the script does
2. How it works under the hood
3. The changes I made to improve it
4. Why these changes matter

What Does the Script Do?

At a high level, this script processes huge JSONL (JSON Lines) dictionary dumps, like the ones from Kaikki.org , and filters them down into clean, usable formats.

The def-extractor.py script takes raw dictionary data (from Wiktionary) and processes it into structured formats like:

• Filtered word lists (JSONL)
• GVariant binary files (for efficient storage)
• Enum tables (for parts of speech & word tags)

It was originally designed to work with specific word lists (Wordnik, Broda, and a test list), but my goal is to make it configurable so it could support any word list with a simple config file.

How It Works (Step by Step)

1. Loading the Word List

The script starts by loading a word list (e.g., Wordnik’s list of common English words). It filters out invalid words (too short, contain numbers, etc.) and stores them in a hash table for quick lookup.

2. Filtering Raw Wiktionary Data

Next, it processes a massive raw-wiktextract-data.jsonl file (theWiktionary dump) and keeps only entries that:

• Match words from the loaded word list
• Are in the correct language (e.g., English)

3. Generating Structured Outputs

After filtering, the script creates:

• Enum tables (JSON files listing parts of speech & word tags)
• GVariant files (binary files for efficient storage and fast lookup)

---

What Changes have I Made?

1. Added Configuration Support

Originally, the script uses hardcoded paths and settings. I modified it to read from .config files , allowing users to define:

• Source word list file
• Output directory
• Word validation rules (min/max length, allowed characters)

Before (Hardcoded):

WORDNIK_LIST = "wordlist-20210729.txt"
ALPHABET = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"

After (Configurable):

ini

[Word List]
Source = my-wordlist.txt
MinLength = 2
MaxLength = 20

2. Improved File Path Handling

Instead of hardcoding paths, the script now constructs them dynamically:

output_path = os.path.join(config.word_lists_dir, f"{config.id}-filtered.jsonl")

Why Do These Changes Matter?

Flexibility -Now supports any word list via config files.
Maintainability – No more editing code to change paths or rules.
Scalability -Easier to add new word lists or languages.
Consistency -All settings are in configs.

Next Steps?

1. Better Error Handling

I am working on adding checks for:

• Missing config fields
• Invalid word list files
• Incorrectly formatted data

2. Unified Word Loading Logic

There are separate functions ( load_wordnik() , load_broda() ).

I want to merged them into one load_words(config) that would works for any word list.

3. Refactor legacy code for better structure

Try It Yourself

1. Download the script: [ wordlist-Gitlab ]
2. Create a . conf config file
3. Run: python3 def-extractor.py --config my-wordlist.conf filtered-list

Happy coding!

Over the past few weeks, Ignacy and I have made good progress on the next phase of features for parental controls in GNOME: a refresh of the parental controls UI, support for screen time limits for child accounts, and basic web filtering support are all in progress. I’ve been working on the backend stuff, while Ignacy has been speedily implementing everything needed in the frontend.

Ignacy is at GUADEC, so please say hi to him! The next phase of parental controls work will involve changes to gnome-control-center and gnome-shell, so he’ll be popping up all over the stack.

I’ll try and blog more soon about the upcoming features and how they’re implemented, because there are necessarily quite a few moving parts to them.

• Mail chew, research.
• Published the next strip around investing in the future and making a splash:
  
• Somehow this afternoon & evening is an highly contended zone for meetings - Collabora monthly management call, GNOME Advisory Board, Customer call and TDF Advisory Board all competing for the same slot.
• Band practice in the evening.

I won’t be traveling this summer for GUADEC, so here is a quick rundown of what I would talk about if I were there.

Personally, I feel like Foundry has the potential to be far more useful than Builder alone. This is probably a good time to write about how it got here and where I intend to take it. Hopefully with your help!

Read the Slides Here

In an earlier blog post we found that optimizing the memory layout of a red-black tree does not seem to work . A different way of implementing an ordered container is to use a B-tree. It was originally designed to be used for on-disk data. The design principle was that memory access is "instant" while disk access is slow. Nowadays this applies to memory access as well, as cache hits are "instant" and uncached memory is slow.

I implemented a B-tree in Pystd . Here is how all the various containers compare. For test data we used numbers from zero to one million in a random order.

As we can see, an unordered map is massively faster than any ordered container. If your data does not need to be ordered, that is the one you should use. For ordered data, the B-tree is clearly faster than either red-black tree implementation.

Tuning the B-tree

B-trees have one main tunable parameter, namely the spread factor of the nodes. In the test above it was five, but for on disk purposes the recommended value is "in the thousands". Here's how altering the value affects performance.

The sweet spot seems to be in the 256-512 range, where the operations are 60% faster than standard set . As the spread factor grows towards infinity, the B-tree reduces to just storing all data in a single sorted array. Insertion into that is an O(N^2) algorithm as can be seen here.

Getting weird

The B-tree implementation has many assert calls to verify the internal structures. We can compile the code with -DNDEBUG to make all those asserts disappear. Removing redundant code should make things faster, so let's try it.

There are 13 measurements in total and disabling asserts (i.e. enabling NDEBUG ) makes the code run slower in 8 of those cases. Let's state that again, since it is very unexpected: in this particular measurement code with assertions enabled runs faster than the same code without them. This should not be happening. What could be causing it?

I don't know for sure, so here is some speculation instead.

First of all a result of 8/13 is probably not statistically significant to say that enabling assertions makes things faster. OTOH it does mean that enabling them does not make the code run noticeably slower. So I guess we can say that both ways of building the code are approximately as fast.

As to why that is, things get trickier. Maybe GCC's optimizer is just really good at removing unnecessary checks. It might even be that the assertions give the compiler more information so it can skip generating code for things that can never happen. I'm not a compiler engineer, so I'll refrain from speculating further, it would probably be wrong in any case.

Motivation

Opportunity is upon us! For the past few years, the desktop Linux user base has been growing at a historically high rate. StatCounter currently has us at 4.14% desktop OS market share for Q2 2025. For comparison, when Fedora Workstation was first released in Q4 2014, desktop Linux was at 1.38%. Now, StatCounter measures HTTP requests, not computers, but it’s safe to say the trend is highly encouraging. Don’t trust StatCounter? Cloudflare reports 2.9% for Q2 2025 . One of the world’s most popular websites reports 5.1%. And although I was unable to figure out how to make a permanent link to the results, analytics.usa.gov is currently reporting a robust 6.2% for the past 90 days, and increasing. The Linux user base is already much larger than I previously suspected would ever be possible, and it seems to be increasing quickly. I wonder if we are perhaps nearing an inflection point where our user base may soon increase even more considerably. The End of 10 and enthusiastic YouTubers are certainly not hurting.

Compared to its peers, Fedora is doing particularly well. It’s pretty safe to say that Fedora is now one of the 2 or 3 most popular and successful desktop Linux operating systems, a far cry from its status 10 years ago, when Fedora suffered from an unfortunate longstanding reputation that it was an unstable “test bed” OS only suitable for experienced technical users. Those days are long gone; nowadays, Fedora has an army of social media users eager to promote it as a reliable, newcomer-friendly choice.

But we cannot stop here. If we become complacent and content ourselves with the status quo, then we will fail to take maximum advantage of the current opportunity.

Although Fedora Workstation works well for most users, and although quality and reliability has improved considerably over the past decade, it is still far too easy for inexperienced users to break the operating system. Today’s Fedora Workstation is fundamentally just a nicer version of the same thing we already had 10 years ago. The original plan called for major changes that we have thus far failed to deliver, like “Robust Upgrades,” “Better upgrade/rollback control,” and “Container based application install.” These critical goals are notably all already achieved by Fedora Silverblue, the experimental image-based alternative to Fedora Workstation, but few Fedora users benefit because only the most experienced and adventurous users are willing to install Silverblue. I had long assumed that Silverblue would eventually become the next Fedora Workstation, and that the Silverblue code name would eventually be retired. This is now an explicit project goal of Fedora’s Strategy 2028 , and it is critical for Fedora’s success. The Fedora Workstation of the future must be:

• Safe and image-based by default: an atomic operating system composed of RPMs built on bootc. Most users should stick with image-based mode because it’s much harder to break the OS, and easier to troubleshoot when something does go wrong.
• Flexible if you so choose: converting the image-based OS into the traditional package-based OS managed by RPM and dnf must be allowed, for users who prefer or require it. Or alternatively, if converting is not possible, then installing a traditional non-atomic Fedora must remain possible. Either way, we must not force users to use image-based desktops if they do not want to, so no need to panic. But image-based must eventually become the new default.

Silverblue is not ready yet, but Fedora has a large community of developers and should be able to eventually resolve the remaining problems.

But wait, wasn’t this supposed to be a blog post about Flathub? Well, consider that with an image-based OS, you cannot easily install traditional RPM packages. Instead, in Fedora Silverblue, desktop applications are installed only via Flatpak. (This is also true of Fedora Kinoite and Fedora’s other atomic desktop variants.) So Fedora must have a source of Flatpaks, and that source must be enabled by default, or there won’t be any apps available.

(Don’t like Flatpak? This blog post is long enough already, so I’ll ask you to just make a leap of faith and accept that Flatpak is cool. Notably, Flatpak applications that keep their bundled dependencies updated and do not subvert the sandbox are much safer to use than traditional distro-packaged applications.)

In practice, there are currently only two interesting sources of Flatpaks to choose from: Fedora Flatpaks and Flathub. Flathub is the much better choice, and enabling it by default should be our end goal. Fedora is already discussing whether to do this. But Flathub also has several disadvantages, some of which ought to be blockers.

Why Flathub?

There are important technical differences between Fedora’s Flatpaks, built from Fedora RPMs, vs. Flathub’s Flatpaks, which are usually built on top of freedesktop-sdk . But I will not discuss those, because the social differences are more important than the technical differences.

Users Like Flathub

Feedback from Fedora’s user base has been clear: among users who like Flatpaks, Flathub is extremely popular. When installing a Flatpak application, users generally expect it to come from Flathub. In contrast, many users of Fedora Flatpaks do not install them intentionally, but rather by accident, only because they are the preferred software source in GNOME Software. Users are often frustrated to discover that Fedora Flatpaks are not supported by upstream software developers and have a different set of bugs than upstream Flatpaks do. It is also common for users and even Fedora developers to entirely remove the Fedora Flatpak application source.

Not so many users prefer to use Fedora Flatpaks. Generally, these users cite some of Flathub’s questionable packaging practices as justification for avoiding use of Flathub. These concerns are valid; Flathub has some serious problems, which I will discuss in more detail below. But improving Flathub and fixing these problems would surely be much easier than creating thousands of Fedora Flatpak packages and attempting to compete with Flathub, a competition that Fedora would be quite unlikely to win.

Flathub is drastically more popular than Fedora Flatpaks even among the most hardcore Fedora community members who participate in change proposal debate on Fedora Discussion. (At time of writing, nearly 80% of discussion participants favor filtering out Fedora Flatpaks .)

This is the most important point. Flathub has already won.

Cut Out the Middleman

In general, upstream software developers understand their software much better than downstream packagers. Bugs reported to downstream issue trackers are much less likely to be satisfactorily resolved. There are a variety of ways that downstream packagers could accidentally mess up a package, whether by failing to enable a feature flag, or upgrading a dependency before the application is compatible with the new version. Downstream support is almost never as good as upstream support.

Adding a middleman between upstream and users really only makes sense if the middleman is adding significant value. Traditional distro-packaged applications used to provide considerable value by making it easy to install the software. Nowadays, since upstreams can distribute software directly to users via Flathub, that value is far more limited.

Bus Factor is Critical

Most Flatpak application developers prefer to contribute to Flathub. Accordingly, there are very few developers working on Fedora Flatpaks. Almost all of the Fedora Flatpaks are actually owned by one single developer who has packaged many hundreds of applications. This is surely not a healthy situation.

Bugs in Fedora Flatpaks are reported on the Fedora Flatpak SIG issue tracker . This SIG notably does not have a list of active members, but rather a years-old list of people who are interested in joining the SIG , who are encouraged to attend the first meeting. Needless to say the SIG does not seem to be in a very good state.

I suspect this situation is permanent, reflecting a general lack of interest in Fedora Flatpak development, not just a temporary shortfall of contributors. Quality is naturally going to be higher where there are more contributors. The quality of Fedora Flatpak applications is often lower than Flathub applications, sometimes significantly so. Fedora Flatpaks also receive significantly less testing than Flathub Flatpaks. Upstream developers do not test the Fedora Flatpaks, and downstream developers are spread too thin to have plausible hope of testing them adequately.

Focus on What Really Matters

Fedora’s main competency and primary value is the core operating system, not miscellaneous applications that ship on top of it for historical reasons.

When people complain that “distros are obsolete,” they don’t mean that Linux operating systems are not needed anymore. Of course you need an OS on which to run applications. The anti-distro people notably all use distros.

But it’s no longer necessary for a Linux distribution to attempt to package every open source desktop application. That used to be a requirement for a Linux operating system to be successful, but nowadays it is an optional activity that we perform primarily for historical reasons, because it is what we have always done rather than because it is still truly strategic or essential. It is a time-consuming, resource-intensive side quest that no longer makes sense and does not add meaningful value.

The Status Quo

Let’s review how things work currently:

• By default, Fedora Workstation allows users to install open source software from the following sources: Fedora Flatpaks, Fedora RPMs, and Cisco’s OpenH264 RPM.
• The post-install initial setup workflow, gnome-initial-setup, suggests enabling third-party repositories. If the user does not click the Enable button, then GNOME Software will make the same suggestion the first time it is run. Clicking this button enables all of Flathub, plus a few other RPM repositories .

Fedora will probably never enable software sources that contain proprietary software by default, but it’s easy to enable searching for proprietary software if desired.

(Technically, Fedora actually has a filter in place to allow hiding any Flathub applications we don’t want users to see. But since Fedora 38, this filter is empty, so no apps are hidden in practice. The downstream filter was quite unpopular with users, and the mechanism still exists only as a safety hatch in case there is some unanticipated future emergency.)

The Future

Here are my proposed requirements for Fedora Workstation to become a successful image-based OS.

This proposal applies only to Fedora Workstation (Fedora’s GNOME edition). These proposals could just as well apply to other Fedora editions and spins, like Fedora KDE Plasma Desktop, but different Fedora variants have different needs, so each should be handled separately.

Flathub is Enabled by Default

Since Flathub includes proprietary software, we cannot include all of Flathub by default. But Flathub already supports subsets . Fedora can safely enable the floss subset by default, and replace the “Enable Third-Party Repositories” button with an “Enable Proprietary Software Sources” button that would allow users to switch from the floss subset to the full Flathub if they so choose.

This goal can be implemented today, but we should wait because Flathub has some problems that we ought to fix first. More on that below.

All Default Applications are Fedora Flatpak Applications

All applications installed by default in Fedora Workstation should be Fedora Flatpaks. (Or almost all. Certain exceptions, like gnome-control-center, would make more sense as part of the OS image rather than as a Flatpak.)

Notice that I said Fedora Flatpaks, not Flathub. Fedora surely does need to control the handful of applications that are shipped by default. We don’t want to be at the mercy of Flathub to provide the core user experience.

There has been recent progress towards this goal , although it’s not ready yet.

All Other Applications are Flathub Flatpaks

With the exception of the default Fedora Flatpak applications, Flathub should be the only source of applications in GNOME Software.

It will soon be time to turn off GNOME Software’s support for installing RPM applications, making it a Flatpak-only software center by default. (Because GNOME Software uses a plugin architecture, users of traditional package-based Fedora who want to use GNOME Software to install RPM applications would still be able to do so by installing a subpackage providing a plugin, if desired.)

This requirement is an end goal. It can be done today, but it doesn’t necessarily need to be an immediate next step.

Flathub Must Improve

Flathub has a few serious problems, and needs to make some policy changes before Fedora enables it by default. I’ll discuss this in more detail next.

Fedora Must Help

We should not make demands of Flathub without helping to implement them. Fedora has a large developer community and significant resources. We must not barge in and attempt to take over the Flathub project; instead, let’s increase our activity in the Flathub community somewhat, and lend a hand where requested.

The Case for Fedora Flatpaks

Earlier this year, Yaakov presented The Case for Fedora Flatpaks . This is the strongest argument I’ve seen in favor of Fedora Flatpaks. It complains about five problems with Flathub:

• Lack of source and build system provenance: on this point, Yaakov is completely right. This is a serious problem, and it would be unacceptable for Fedora to embrace Flathub before it is fixed. More on this below.
• Lack of separation between FOSS, legally encumbered, and proprietary software: this is not a real problem. Flathub already has a floss subset to separate open source vs. proprietary software; it may not be a separate repository, but that hardly matters because subsets allow us to achieve an equivalent user experience. Then there is indeed no separate subset for legally-encumbered software, but this also does not matter. Desktop users invariably wish to install encumbered software; I have yet to meet a user who does not want multimedia playback to work, after all. Fedora cannot offer encumbered multimedia codecs, but Flathub can, and that’s a major advantage for Flathub. Users and operating systems can block the multimedia extensions if truly desired. Lastly, some of the plainly-unlicensed proprietary software currently available on Flathub does admittedly seem pretty clearly outrageous, but if this is a concern for you, simply stick to the floss subset.
• Lack of systemic upgrading of applications to the latest runtime: again, Yaakov is correct. This is a serious problem, and it would be unacceptable for Fedora to embrace Flathub before it is fixed. More on this below.
• Lack of coordination of changes to non-runtime dependencies: this is a difference from Fedora, but it’s not necessarily a problem. In fact, allowing applications to have different versions of dependencies can be quite convenient, since upgrading dependencies can sometimes break applications. It does become a problem when bundled dependencies become significantly outdated, though, as this creates security risk. More on this below.
• Lack of systemic community engagement: it’s silly to claim that Flathub has no community. Unresponsive Flathub maintainers are a real problem, but Fedora has an unresponsive maintainer problem too, so this can hardly count as a point against Flathub. That said, yes, Flathub needs a better way to flag unresponsive maintainers.

So now we have some good reasons to create Fedora Flatpaks. But maintaining Flatpaks is a tremendous effort. Is it really worth doing if we can improve Flathub instead?

Flathub Must Improve

I propose the following improvements:

• Open source software must be built from source on trusted infrastructure.
• Applications must not depend on end-of-life runtimes.
• Applications must use flatpak-external-data-checker to monitor bundled dependencies wherever possible.
• Sandbox holes must be phased out, except where this is fundamentally technically infeasible.

Let’s discuss each point in more detail.

Build Open Source from Source

Open source software can contain all manner of vulnerabilities. Although unlikely, it might even contain malicious backdoors. Building from source does nothing to guarantee that the software is in any way safe to use (and if it’s written in C or C++, then it’s definitely not safe ). But it sets an essential baseline: you can at least be confident that the binary you install on your computer actually corresponds to the provided source code, assuming the build infrastructure is trusted and not compromised. And if the package supports reproducible builds , then you can reliably detect malicious infrastructure, too!

In contrast, when shipping a prebuilt binary, whoever built the binary can easily insert an undetectable backdoor; there is no need to resort to stealthy obfuscation tactics . With proprietary software, this risk is inherent and unavoidable: users just have to accept the risk and trust that whoever built the software is not malicious. Fine. But users generally do not expect this risk to extend to open source software, because all Linux operating systems fortunately require open source software to be built from source. Open source software not built from source is unusual and is invariably treated as a serious bug .

Flathub is different. On Flathub, shipping prebuilt binaries of open source software is, sadly, a common accepted practice. Here are several examples. Flathub itself admits that around 6% of its software is not built from source , so this problem is pervasive, not an isolated issue. (Although that percentage unfortunately considers proprietary software in addition to open source software, overstating the badness of the problem, because building proprietary software from source is impossible and not doing so is not a problem.)

Security is not the only problem. In practice, Flathub applications that do not build from source sometimes package binaries only for x86_64, leaving aarch64 users entirely out of luck, even though Flathub normally supports aarch64, an architecture that is important for Fedora. This is frequently cited by Flathub’s opponents as major disadvantage relative to Fedora Flatpaks.

A plan to fix this should exist before Fedora enables Flathub by default. I can think of a few possible solutions:

• Create a new subset for open source software not built from source, so Fedora can filter out this subset. Users can enable the subset at their own risk. This is hardly ideal, but it would allow Fedora to enable Flathub without exposing users to prebuilt open source software.
• Declare that any software not built from source should be treated equivalent to proprietary software, and moved out of the floss subset. This is not quite right, because it is open source, but it has the same security and trust characteristics of proprietary software, so it’s not unreasonable either.
• Set a flag date by which any open source software not built from source must be delisted from Flathub. I’ll arbitrarily propose July 1, 2027, which should be a generous amount of time to fix apps. This is my preferred solution. It can also be combined with either of the above.

Some of the apps not currently built from source are Electron packages. Electron takes a long time to build, and I wonder if building every Electron app from source might overwhelm Flathub’s existing build infrastructure. We will need some sort of solution to this. I wonder if it would be possible to build Electron runtimes to provide a few common versions of Electron. Alternatively, Flathub might just need more infrastructure funding.

Tangent time: a few applications on Flathub are built on non-Flathub infrastructure, notably Firefox and OBS Studio. It would be better to build everything on Flathub’s infrastructure to reduce risk of infrastructure compromise, but as long as this practice is limited to only a few well-known applications using trusted infrastructure, then the risk is lower and it’s not necessarily a serious problem. The third-party infrastructure should be designed thoughtfully, and only the infrastructure should be able to upload binaries; it should not be possible for a human to manually upload a build. It’s unfortunately not always easy to assess whether an application complies with these guidelines or not. Let’s consider OBS Studio. I appreciate that it almost follows my guidelines, because the binaries are normally built by GitHub Actions and will therefore correspond with the project’s source code, but I think a malicious maintainer could bypass that by uploading a malicious GitHub binary release? This is not ideal, but fortunately custom infrastructure is an unusual edge case, rather than a pervasive problem.

Penalize End-of-life Runtimes

When a Flatpak runtime reaches end-of-life (EOL), it stops receiving all updates, including security updates. How pervasive are EOL runtimes on Flathub? Using the Runtime Distribution section of Flathub Statistics and some knowledge of which runtimes are still supported , I determined that 994 out of 3,438 apps are currently using an EOL runtime. Ouch. (Note that the statistics page says there are 3,063 total desktop apps, but for whatever reason, the number of apps presented in the Runtime Distribution graph is higher. Could there really be 375 command line apps on Flathub?)

Using an EOL runtime is dangerous and irresponsible, and developers who claim otherwise are not good at risk assessment. Some developers will say that security does not matter because their app is not security-critical. It’s true that most security vulnerabilities are not actually terribly important or worth panicking over, but this does not mean it’s acceptable to stop fixing vulnerabilities altogether. In fact, security matters for most apps. A few exceptions would be apps that do not open files and also do not use the network, but that’s really probably not many apps.

I recently saw a developer use the example of a music player application to argue that EOL runtimes are not actually a serious problem. This developer picked a terrible example. Our hypothetical music player application can notably open audio files. Applications that parse files are inherently high risk because users love to open untrusted files. If you give me a file, the first thing I’m going to do is open it to see what it is. Who wouldn’t? Curiosity is human nature. And a music player probably uses GStreamer, which puts it at the very highest tier of security risk (alongside your PDF reader, email client, and web browser). I know of exactly one case of a GNOME user being exploited in the wild: it happened when the user opened a booby-trapped video using Totem, GNOME’s GStreamer-based video player. At least your web browser is guaranteed to be heavily sandboxed; your music player might very well not be .

The Flatpak sandbox certainly helps to mitigate the impact of vulnerabilities, but sandboxes are intended to be a defense in depth measure. They should not be treated as a primary security mechanism or as an excuse to not fix security bugs. Also, too Flatpak many apps subvert the sandbox entirely.

Of course, each app has a different risk level. The risk of you being attacked via GNOME Calculator is pretty low. It does not open files, and the only untrusted input it parses is currency conversion data provided by the International Monetary Fund. Life goes on if your calculator is unmaintained. Any number of other applications are probably generally safe. But it would be entirely impractical to assess 3000 different apps individually to determine whether they are a significant security risk or not. And independent of security considerations, use of an EOL runtime is a good baseline to determine whether the application is adequately maintained, so that abandoned apps can be eventually delisted. It would not be useful to make exceptions.

The solution here is simple enough:

• It should not be possible to build an application that depends on an EOL runtime, to motivate active maintainers to update to a newer runtime. Flathub already implemented this rule in the past, but it got dropped at some point.
• An application that depends on an EOL runtime for too long should eventually be delisted. Perhaps 6 months or 1 year would be good deadlines.
• A monitoring dashboard would make it easier to see which apps are using maintained runtimes and which need to be fixed.

Monitor Bundled Dependencies

Flatpak apps have to bundle any dependencies not present in their runtime. This creates considerable security risk if the maintainer of the Flathub packaging does not regularly update the dependencies. The negative consequences are identical to using an EOL runtime.

Fortunately, Flathub already has a tool to deal with this problem: flatpak-external-data-checker . This tool automatically opens pull requests to update bundled dependencies when a new version is available. However, not all applications use flatpak-external-data-checker, and not all applications that do use it do so for all dependencies, and none of this matters if the app’s packaging is no longer maintained.

I don’t know of any easy ways to monitor Flathub for outdated bundled dependencies, but given the number of apps using EOL runtimes, I assume the status quo is pretty bad. The next step here is to build better monitoring tools so we can better understand the scope of this problem.

Phase Out Most Sandbox Holes (Eventually)

Applications that parse data are full of security vulnerabilities, like buffer overflows and use-after-frees. Skilled attackers can turn these vulnerabilities into exploits, using carefully-crafted malicious data to gain total control of your user account on your computer. They can then install malware, read all the files in your home directory, use your computer in a botnet, and do whatever else they want with it. But if the application is sandboxed, then a second type of exploit, called a sandbox escape, is needed before the app can harm your host operating system and access your personal data, so the attacker now has to exploit two vulnerabilities instead of just one. And while app vulnerabilities are extremely common, sandbox escapes are, in theory , rare.

In theory, Flatpak apps are drastically safer than distro-packaged apps because Flatpak provides a strong sandbox by default. The security benefit of the sandbox cannot be understated: it is amazing technology and greatly improves security relative to distro-packaged apps. But in practice, Flathub applications routinely subvert the sandbox by using expansive static permissions to open sandbox holes. Flathub claims that it carefully reviews apps’ use of static permissions and allows only the most narrow permissions that are possible for the app to function properly. This claim is dubious because, in practice, the permissions of actual apps on Flathub are extremely broad , as often as not making a total mockery of the sandbox.

While some applications use sandbox holes out of laziness, in many cases it’s currently outright impossible to sandbox the application without breaking key functionality. For example, Sophie has documented many problems that necessitate sandbox holes in GNOME’s image viewer, Loupe. These problems are fixable, but they require significant development work that has not happened yet. Should we punish the application by requiring it to break itself to conform to the requirements of the sandbox? The Flathub community has decided that the answer is no: application developers can, in practice, use whatever permissions they need to make the app work, even if this entirely subverts the sandbox.

This was originally a good idea. By allowing flexibility with sandbox permissions, Flathub made it very easy to package apps, became extremely popular, and allowed Flatpak itself to become successful. But the original understanding of the Flatpak community was that this laxity would be temporary: eventually, the rules would be tightened and apps would be held to progressively higher standards, until sandbox holes would eventually become rare. Unfortunately, this is taking too long. Flatpak has been around for a decade now, but this goal is not within reach.

Tightening sandbox holes does not need to be a blocker for adopting Flathub in Fedora because it’s not a problem relative to the status quo in Fedora. Fedora Flatpaks have the exact same problem, and Fedora’s distro-packaged apps are not sandboxed at all (with only a few exceptions, like your web browser). But it’s long past time to at least make a plan for how to eventually phase out sandbox holes wherever possible. (In some cases, it won’t ever be possible; e.g. sandboxing a file manager or disk usage analyzer does not make any sense.) It’s currently too soon to use sticks to punish applications for having too many sandbox holes, but sticks will be necessary eventually, hopefully within the next 5 years. In the meantime, we can immediately begin to use carrots to reward app developers for eliminating holes. We will need to discuss specifics.

We also need more developers to help improve xdg-desktop-portal, the component that allows sandboxed apps to safely access resources on the host system without using sandbox holes. This is too much work for any individual; it will require many developers working together.

Software Source Prioritization

So, let’s say we successfully engage with the Flathub project and make some good progress on solving the above problems. What should happen next?

Fedora is a community of doers. We cannot tell Fedora contributors to stop doing work they wish to do. Accordingly, it’s unlikely that anybody will propose to shut down the Fedora Flatpak project so long as developers are still working on it. Don’t expect that to happen.

However, this doesn’t mean Fedora contributors have a divine right for their packaged applications to be presented to users by default. Each Fedora edition (or spin) should be allowed to decide for itself what should be presented to the user in its software center. It’s time for the Fedora Engineering Steering Committee (FESCo) to allow Fedora editions to prefer third-party content over content from Fedora itself.

We have a few options as to how exactly this should work:

• We could choose to unconditionally prioritize all Flathub Flatpaks over Fedora Flatpaks, as I proposed earlier this year ( Workstation ticket , LWN coverage ). The precedence in GNOME Software would be Flathub > Fedora Flatpaks .
• Alternatively, we could leave Fedora Flatpaks with highest priority, and instead apply a filter such that only Fedora Flatpaks that are installed by default are visible in GNOME Software. This is my preferred solution; there is already an active change proposal for Fedora 43 ( proposal , discussion ), and it has received considerable support from the Fedora community. Although the proposal only targets atomic editions like Silverblue and Kinoite for now, it makes sense to extend it to Fedora Workstation as well. The precedence would be Filtered Fedora Flatpaks > Flathub .

When considering our desired end state, we can stop there; those are the only two options because of my “All Other Applications are Flathub Flatpaks” requirement: in an atomic OS, it’s no longer possible to install RPM-packaged applications, after all. But in the meantime, as a transitional measure, we still need to consider where RPMs fit in until such time that Fedora Workstation is ready to remove RPM applications from GNOME Software.

We have several possible precedence options. The most obvious option, consistent with my proposals above, is: Flathub > Fedora RPMs > Fedora Flatpaks . And that would be fine, certainly a huge improvement over the status quo, which is Fedora Flatpaks > Fedora RPMs > Flathub.

But we could also conditionally prioritize Flathub Flatpaks over Fedora Flatpaks or Fedora RPMs, such that the Flathub Flatpak is preferred only if it meets certain criteria. This makes sense if we want to nudge Flathub maintainers towards adopting certain best practices we might wish to encourage. Several Fedora users have proposed that we prefer Flathub only if the app has Verified status, indicating that the Flathub maintainer is the same as the upstream maintainer. But I do not care very much whether the app is verified or not; it’s perfectly acceptable for a third-party developer to maintain the Flathub packaging if the upstream developers do not wish to do so, and I don’t see any need to discourage this. Instead, I would rather consider whether the app receives a Probably Safe safety rating in GNOME Software. This would be a nice carrot to encourage app developers to tighten sandbox permissions. (Of course, this would be a transitional measure only, because eventually the goal is for Flathub to be the only software source.)

There are many possible outcomes here, but here are my three favorites, in order:

1. My favorite option: Filtered Fedora Flatpaks > Probably Safe Flathub > Fedora RPMs > Potentially Unsafe Flathub . Fedora Flatpaks take priority, but this won’t hurt anything because only applications shipped by default will be available, and those will be the ones that receive the most testing. This is not a desirable end state because it is complicated and it will be confusing to explain to users why a certain software source was preferred. But in the long run, when Fedora RPMs are eventually removed, it will simplify to Filtered Fedora Flatpaks > Flathub, which is elegant.
2. A simple option, the same thing but without the conditional prioritization: Filtered Fedora Flatpaks > Flathub > Fedora RPMs .
3. Alternative option: Probably Safe Flathub > Fedora RPMs > Potentially Unsafe Flathub > Unfiltered Fedora Flatpaks . When Fedora RPMs are eventually removed, this will simplify to Flathub > Unfiltered Fedora Flatpaks. This alternative option behaves almost the same as the above, except allows users to manually select the Fedora Flatpak if they wish to do so, rather than filtering them out. But there is a significant disadvantage: if you uninstall an application that is installed by default, then reinstall the application, it would come from Flathub rather than Fedora Flatpaks, which is unexpected. So we’ll probably want to hardcode exceptions for default apps to prefer Fedora Flatpaks.
4. The corresponding simple option without conditional prioritization: Flathub > Fedora RPMs > Unfiltered Fedora Flatpaks .

Any of these options would be fine.

Conclusion

Flathub is, frankly, not safe enough to be enabled by default in Fedora Workstation today. But these problems are fixable. Helping Flathub become more trustworthy will be far easier than competing against it by maintaining thousands of Fedora Flatpaks. Enabling Flathub by default should be a strategic priority for Fedora Workstation.

I anticipate a lively debate on social media, on Matrix, and in the comments. And I am especially eager to see whether the Fedora and Flathub communities accept my arguments as persuasive. FESCo will be considering the Filter Fedora Flatpaks for Atomic Desktops proposal imminently, so the first test is imminent.

## Opaque Stuff

• some preliminary internal policy drafts

## Annual Report

Most of this week was spent creating a draft of the 2025 annual report. I’ve never created an annual report for a non-profit before, so it was a fun exercise! It did consume enough time that I’ll be creating my GUADEC slides on the airplane, though.

Thanks to everyone who contributed to the Annual Report / 2025 Successes issue in GitLab. I know this was a bit of a scramble, and I appreciate everyone taking the time to chip in.

The draft is at the bottom of that issue. You can use Toolbx (as described in the README) or Mise to run it locally. If your GNOME contributions from this year are missing, please shout at me on Matrix! I’m certain I’m missing achievements from the past 18 months.

## 501(c)(3) Details

I was curious to know if an annual report was a legal requirement for 501(c)(3)s in California. Much like limits to retaining capital, the answer is “no” … but there is a sort of soft compliance value in producing an annual report in the same way that it looks better to the IRS if a non-profit doesn’t sit on a half-billion dollars like a cave dragon. (Not naming any names, of course.)

We spent a bit of time this past week looking at the Public Support Test . This is yet another great reason to have regular, recurring, unrestricted contributions from a wide variety of GNOME users. These donations don’t just keep GNOME humming but they also validate the Foundation as a 501(c)(3). The Public Support Test takes users’ love of GNOME and transmogrifies it into IRS compliance.

The language on that page is obnoxiously vague (UNITS, people) so let’s take a look at the first and most important sentence to see what it actually means:

The simplest definition of the IRS public support test states that at least 1/3 (33.3%) of donations must be given by donors who give less than 2% of the nonprofit’s overall receipts.

“33.3% of donations” specifically means dollars . The “2% of receipts” also just means, uh, dollars . It’s unclear to me why they don’t just, you know, say that. Anyway, this explanation/example is clearer than any of the 3 listed on the page, in my opinion:

If your nonprofit’s total support over 5 years is $1,000,000:

• 2% = $20,000
• If Donor A gives $50,000, only $20,000 counts toward public support
• The extra $30,000 is still counted as total revenue, but not toward the “public support” percentage

This rule only applies to large individual, corporate, or private foundation donors — not to:

• Government grants
• Public charities
• Broad-based fundraising (small donors)

In short, while it’s possible to pass the Public Support Test with revenue from grants and other charities, the most resilient public support (and revenue stream!) comes from individual donors like you. (Or, like, your users if you’re a hacker.)

## Hackers

While the Steven Levy book ( Hackers , 1984) is a bit dated now, there’s just so much I love about it. It was easily my favourite Covid lockdown read. In the earlier days of GNOME, I remember the term “hacker” being thrown around a lot more. I’d like to encourage folks to bring that back.

However, I’d also like to lean into the idea that “hacking” has more to do with its original definition than it came to mean thanks to ESR’s essays, or whatever. “Hacking” is just the activity of tearing down a system, understanding it, and building something new (and hopefully better) out of it. You can hack on design. You can hack on linguistics. You can hack on event management. You can hack on gardening.

“Contributor” is such a boring word (and ambiguous when donors are in play). When I say “hacker” in the above section, I’m referring to anyone who contributes to GNOME in this way. Not just developers.

## Retaining Capital

I’ve had a couple people tussle with me a bit recently — over the idea that the GNOME Foundation should hold onto enough capital to see it through some rough times. At least one of these conversations was off the back of my earlier comment in the June 6th Foundation Report that 501(c)(3)s have no capital retention limits whatsoever . Because they don’t.

I need to clear the air, here. I’m not suggesting that the GNOME Foundation hold on to $20 million USD and slowly fritter it away. I am suggesting that, in conjunction with continuously fighting for smaller recurring revenue sources, the Foundation should ensure it has enough capital reserve to continue operations for a reasonable length of time. Given that the Foundation has run a deficit for 5 years in a row, I would say “a reasonable length of time” is… 5 years. But I know the Board will never set a half-decade-long reserve policy, so my suggestion is 12 months while we’re in lean times (which is to say, now) and 18 to 24 months when the Foundation is in a healthier financial position.

How much is that? For the sake of argument, let’s say our monthly burn rate is $41,666. (It’s not, but I like round numbers.) That means an 18-month capital reserve would be $1.5 million. If you are the sort of person who jumps at that number and says “oh my god! that’s a ton of money!” then I suggest starting a small business, growing it, and deciding what you consider a safe reserve policy for the wellbeing of your 5-100 employees (which is your responsibility, as a business owner). $1.5 million is a lot of money for an individual. It is not a lot for a corporation of any size whatsoever.

But we could cut! The current wording of the Board Reserves Policy uses the words “core spending.” This language drives me a little nuts. It implies there is a “core” to the Foundation that we can drop services and staff to somehow achieve. That’s absurd. If we can cut spending and still retain our core functionality as a non-profit, we should do that immediately , not when we start burning the capital reserve. We run this organization on donations. Some of those donations come from extremely generous people on low incomes. It is my responsibility, under the policy direction of the Board, to responsibly steward the organization such that we take those donations seriously and respect every dollar donated by GNOME’s users. There are many approaches to this: one is to ensure the GNOME Foundation isn’t spending money it shouldn’t or running programs that don’t benefit GNOME, but another is to build network resilience and cross-functional execution into our staff (me included), to ensure that all operations are “core” operations.

Okay, diatribe over.

## Community Health

I met Tobias on Monday (and Adrian on Friday) to chat about some efforts we can make to increase the health of the GNOME community, with respect to interactions between individuals. One topic that’s come up (not only with Tobias and Adrian) is a private space for Foundation Members. At the moment, we don’t really have such a space, so we air our grievances in the relative public of Matrix and Discourse. That’s not ideal. A healthy debate — or even an outright argument with heated emotion — might leave the participants in friendly standing at the end, but leave the peanut gallery aghast or agog.

I had a similar conversation with Aaron Prisk and Mauro Gaspari from Canonical later in the week. We need better spaces for hashing out certain discussions, with varying degrees of transparency. Ultimately, the execution is always public. We’re not going to lock down GitLab and start throwing tarballs over the wall to our users. Usually the collaboration can be public, too. But sometimes the earlier stages need to take place in a coffee shop, not the town square.

These are ideas that require contemplation and iteration, obviously. But I’d love to hear your thoughts.

## More Friends

I met Amy Parker from OpenSSL this week. It’s amazing to me just how friendly and cool people are out there in the wider Freie Software community. We’ve all got some variation of the same difficulties ( Open Source Foundations: They Are Weird ), and it’s hugely reassuring to have a massive, global network of allies fighting alongside us.

## Preliminary Board Assignments

The new board members met on Tuesday to discuss potential officer positions and committee assignments. Nobody was murdered. It was a productive conversation. Yay for us.

## More Resilience and More Resilience

We keep chipping away at the GNOME Foundation’s services, inching our way to a position where we’ll have at least three (3) owners/signatories/root users for every service, bank account, and tool. This week was another long Tuesday call with Rosanna, mostly around banks and banking tools. Thanks for the help, Rosanna!

We also met our bank’s account manager later in the week. We finally ( finally ) have two people with signing authority. Hooray!

## Meeting the Bookkeepers

Deepa (our new treasurer) and I had a lovely conversation with our primary bookkeeper on Friday to take an initial look at the draft 2023/2024 financial report we’ll use for the Annual Report.

We have a long list of questions for both our bookkeepers. We have a primary bookkeeper who, naturally, keeps our books. We also have an advisory bookkeeper who helps with the stickier non-profit accounting and treasury questions.

## GUADEC

It’s GUADEC soon! The GNOME Foundation’s Advisory Board meets on July 23rd, then the conference, and then we have Sunday and Monday for a bit of a “Board Hack Day” … trying to clear out old issues, resolve unfinished business, and give the year with the new board a strong start.

If you’ll be at GUADEC, I’ll see you there! Until next week.

Intro

Hi everyone, sorry for the late post. Midterms are this week for GSoC, which means I’m halfway through GSoC. It’s been an incredible experience so far, and I know it’s going to continue to be great.

API vs. ABI

What is the difference between an application programming interface versus an application binary interface? In the beginning, this question tripped me out and confused me, because I wasn’t familiar with ABIs. Understanding what an ABI is has helped me decide which libraries I should consider using in the codegen phase. When talking about Vala, Vala is designed to use a C ABI. First, let’s understand what they are separately and then compare them.

API

Personally, I think Understanding API’s is more popular and well known. An API is usually, at a high level, defined by two software components or computers communicating with each other using a set of definitions and protocols. This definition I always thought was pretty vague and expansive. When dealing with code-level APIs, I like to understand it as APIs are existing entities in the user code (source code) that have functions, constants, structures, etc. You can think of it as when you write code, you access libraries through an API. For example, when you write print ( ' hello world ' ) in Python, print () is a part of Python’s standard library API.

ABI

ABI, on the other hand, is very similar, but instead of the compiler time, they are executed during runtime. Runtime means when your program is done compiling (going through the lexical, syntax, semantic analysis, etc) and the machine is actually running your executable. Its goals are very low-level and entails how compiled code should interact, particularly in the context of operating systems and libraries. It has protocols and standards for how the OS handles your program, such as storage, memory, hardware, and about how your compiled binary works with other compiled components.

YAML Libraries

I’ve started to look into YAML and XML (mainly YAML). I’ve looked into many different libraries dealing with YAML, some such as pluie-yaml , libyaml-glib , glib-yaml , and libyaml . To my understanding and research, there are no well-maintained YAML libraries that integrate GObject or GLib. The goal is to find a well-maintained library that I can use in the codegen.

Pluie yaml

I mentioned pluie-yaml , but this library isn’t a C library like json-glib , it’s a shared Vala library. The good thing is that the codegen can use pure Vala libraries because Vala libraries have a C ABI, however, the bad part is that this library is not well-maintained. The last activity was 7 years ago.

Libyaml glib

Libyaml-glib is a GLib binding of libyaml, plus a GObject builder that understands YAML. Just like pluie, it’s not a C library. It’s written in Vala. And just like pluie, it’s not well-maintained, with the last activity even stretching to longer, 9 years ago.

Glib yaml

Glib-yaml is a GLib-based YAML parser written in C. It again, just like the other libraries, doesn’t pass the maintenance check since it’s been years of no updates or commits in the repo. Going all the way back to 13 years ago. It’s also only a parser, and it doesn’t serialize or emit YAML, so even if it were well-maintained, I’d still need to emit YAML either manually or find another library that does so.

Libyaml

In conclusion, libyaml is the C library that I will be using for parsing and emitting YAML. It has a C ABI, and it’s the most well-maintained out of all of the other libraries. Vala already has a VAPI file binding it, yaml-0.1.vapi . However, there is no GObject or GLib integration, unlike json-glib, but that should be fine.

• Up hyper-early, got to work instead of trying to sleep: much more productive, another half a day's work.
• Found some lost A/C folk, and helped them maintain our system.
• Sync with Dave, Sarper, Thorsten, Mitch helped me unwind some Apple account horrors.
• Published the next strip on a topic that plagues engineers: having a wonderful product or service is futile without a proper marketing & sales process.