This will be the first post in what may become a series of occasional status updates or a personal diary. I might ramble or overshare at times, and there won’t be anything particularly important or interesting here.
I’ve been meaning to write something like this for a while, but never quite found the time or motivation. I’ve always liked the idea of keeping a record of my thoughts, experiences, and small updates. It feels nice to know I can someday look back at these posts and recollect. It also feels nice to share these thoughts, even though I don’t really know who the audience (apart from myself) will be, if anyone.
Health
I guess I will start this by writing about my health.
I’ve generally been healthy all my life. Apart from the usual seasonal fevers or occasional stomach issues, I’ve never really had any health problems that I can remember. As a result, I guess I’ve never done any regular checkups or tried to be consciously healthy, like doing exercises. Things changed a bit last November. I developed a fever just before winter was approaching, but this time, to my surprise, it didn’t come with the usual set of symptoms like a runny nose or cold. I didn’t think much of it at first and took some paracetamol. But after 3-4 days, it wasn’t going away, and I got a little worried. So I went to a physician to get it checked out. During the checkup, he measured my blood pressure, and the result surprised both of us - 150/110 mmHg. That was unusually high for someone of my age, even with a fever. He prescribed me some medication for blood pressure along with treatment for the fever. The fever itself went away after about a week - it was a false alarm, but the bigger problem was my high blood pressure. I got a bit scared. I took the BP medicine for a week, but I was a bit hesitant to continue it after that. I decided to get a second opinion a month later. That time, my blood pressure was measured to be 160/80 mmHg, which again was high. However, after discussing things further, the doctor suggested it might be too early to jump straight to regular medication. There was also the possibility of me having whitecoat syndrome. He recommended that I try out some lifestyle changes first to “manage” (see if it naturally decreases) the high BP - things like regular walks, exercise, etc., for 3-4 months, after which I was supposed to do a 24-hour ABPM test. So I’ve been doing morning walks for the last three months or so, almost daily. I usually walk around 10–12 km a day, and I track it in the Google Fit app, which says I’ve logged about 922515 steps over the last four months. It comes out to roughly 7700 steps per day on average, which is quite a jump from previously doing almost nothing. Unfortunately, I seem to have strained a tendon in my right leg, probably from overdoing it, so I haven’t walked at all this month. Hopefully, it will recover by next month. I also completed the ABPM test last week. The daytime and nighttime averages came out to be 124/80 mmHg and 123/75 mmHg, and at the clinic, it was 140/80 mmHg. It’s still a bit on the higher side, but it has gone down in the last three months. I’ve also been trying to “de-stress” in various ways, like reducing my “online” time (more on that later). Hopefully things turn out to be ok.
Work
The next part is going to be a bit about my work and PhD.
The latter has been stressful and frustrating lately for various reasons, and I won’t really get into it. I did manage to submit my first paper to the IJB last week. The review process takes quite a bit of time, so I’ll have to wait and see how that goes. In the meantime, I’ve also been working on two more papers. One of them is essentially finished, and I’ve sent it to my guide for feedback, while I’ve just started working on the other one. I think at this point I just want to get some publications, get the Doctorate, and move on to doing my own research independently. I was meant to do a PhD in Algebraic Topology as that was my specialisation during Masters but I didn’t find a guide for it and had to choose Mathematical Biology as a second option. My dream/wish is to do something in Algebraic Topology later on.
This semester, I’m also teaching a course on introductory ODEs and PDEs. I finished the ODE portion of the course last week. I used SL Ross’ Introduction to Ordinary Differential Equations as a reference, which is a pretty standard introductory text on this. We covered definition, formation, classification, and existence-uniqueness theorems in January. For first order linear ODEs, we covered separable, homogeneous, exact, and Bernoulli differential equations, and for second order ODEs (both variable and constant coefficients, homogenous and non-homogeneous), we covered the methods of reduction of order and variation of parameters. Euler-Cauchy equations and power series solutions. Personally, I find the method of variation of parameters to be particularly useful, so I heavily relied on it. Some people find it to be computationally lengthy, but it can be applied to a wide range of problems, and in my opinion, learning a more or less general method like that is much better for the long term. The mid-semester exams happened last week, so I now have a pile of 40 or 50 answer scripts waiting to be graded.
FOSS
The next part is about the FOSS stuff I usually do. Most of it can roughly be grouped into three areas - Flathub, Flatpak, and the Freedesktop SDK.
Flathub
A large portion of my time related to Flathub goes into the main Flathub repository, mostly reviewing submissions. I think I started doing this around 2022, and at that time, there were three of us reviewing - me, Bart and Hub. However, things changed over time, and reviewing hundreds of submissions every month has its tax to pay. So for the past couple of years, it has mostly been just me and Hub handling all the review work.
This would normally be fine if not for the constant influx of extremely low-quality, AI-generated pull requests, or PRs that completely ignore the requirements clearly laid out in the documentation, and even the PR template. Reviewing these is not just frustrating—it’s genuinely exhausting. It’s becoming harder to tell what’s malicious versus what’s submitted by someone with little to no understanding of software. To make matters worse, many LLM-generated submissions now look superficially “legitimate,” so each one takes extra time and effort to verify. In a lot of cases, it’s not even apparently visible from comments, repository structure, commit details and hygiene, and someone has to audit the entire codebase, which is hardly possible or practical given the volume, for someone working full-time on this, let alone for volunteers.
A lot of submitters also seem overconfident, sometimes even entitled, as if their PRs are expected to be accepted. There’s often a lack of basic awareness that closing a PR means rejection, and some submissions will get rejected. As a result, closing PRs frequently leads to follow-up emails, DMs, or repeated submissions. These quickly escalate into arguments and, eventually, bans. The class of “over-confident” AI slop generators, also have been writing various hitpieces on socials, crying injustice and flaming which has been extra annoying. I’ve even been pinged during important IRL situations (e.g., while undergoing a blood test).
I don’t think banning the use of LLMs completely is practical right now but I absolutely want to place an outright ban on “AI-slop” submissions, but alas some of the other reviewers/admins sometimes think otherwise or when I make a mistake, “slop” gets in. Maybe this is because, there is no clear metric of determining what counts as slop and the judgement varies from person to person.
I’m also very frustrated that people from within our own circles started submitting AI-generated spammy PRs to various FOSS projects. When an app maintainer raised concerns, I responded bluntly, asking to stop the spam. The reply I got was that apparently I didn’t know what I was talking about, and that if it “physically hurts” me, I should just ignore it, which is about as fair as telling someone who is receving death threats, to just stop being on the internet and close all their emails.
I don’t really have a problem with people using LLMs as a learning aid, or for translations, or even for writing code - provided the output is not entirely “slop” and the person is not acting with malicious interests in mind and willing to take full responsibility for it, including being open to feedback, staying sensibly engaged, and being present to fix issues. That, however, is not what’s happening here in general.
I suspect most of these AI-generated submissions are aimed at padding CVs or GitHub profiles and generating revenue when paid apps become available. I also suspect that the people submitting them will rarely become sustained platform or FOSS contributors and while that’s not a requirement in any way, it is generally nice. I suspect that the applications themselves will be buggy and when all the interest eventually fades, it will join the graveyard of unmaintained apps on EOL runtimes. None of this is a requirement to create and distribute open source applications in way and it never should be. The entire contract is that there is none but all of this is generally nice. I would be glad to be proven wrong on any of these and if that happens it will not be my “loss”, but rather a better application and, potentially, a new long-term contributor.
Anyways, right now, it seems that I’m being forced out of what I love doing, and I have no control over that. This is not something anyone should have to deal with. I try to be reasonable, but this has become an increasingly difficult situation.
I’ve developed and maintain a number of GitHub actions in that repository (and in the flathub-infra org) to automate parts of the review process. The automation helps, but a large portion of the submissions is still difficult to filter automatically and needs to be reviewed manually. One of these actions is currently a fairly large shell script. At one point, I started converting it to Python, but I ended up dropping the ball on it. I intend to pick it up again at some point. All of this has also made me lose some of the implicit trust (whatever that means) I used to have. I tend to be much stricter when reviewing and accepting submissions. Looking at the trend of new submissions being accepted, it has noticeably decreased around the time I took over: 674 in 2022, 672 in 2023, 562 in 2024, and around 355 in 2025. The other large time sink here is dealing with various “infra” issues and requests people open, reviewing moderation requests (looking at the DB, I reviewed almost 10x more moderation requests than anyone else), maintaining a bunch of Flatpaks (around 19), and dealing with whatever random issues people ping me on.
Dealing with the so-called “Fedora drama” alongside all of this has also been quite frustrating. Fedora maintains its own Flatpak repository built from RPM packages, and from what I could tell, it was not particularly well-maintained, likely due to limited contributor resources. That in itself is not a problem for me. However, when OBS requested that Fedora stop distributing or at least rebrand the Fedora Flatpak of OBS, I think it would have been reasonable for them to comply. Unfortunately, that did not happen, and instead the OBS developers were harassed and strongly criticised. Since their preferred distribution channel was Flathub, it also got pulled into this mess. At the same time, a portion of the Fedora community pushed for enabling the Flathub remote by default. I think Fedora wanting to prefer and promote its own outputs to its users is perfectly reasonable. It is also reasonable if they do not want to enable Flathub by default and simply state that it is blocked because of the above situation. However, instead of saying that directly, what followed was a wave of constant scrutiny, criticism and arbitrary demands directed at Flathub at both the technical and policy levels. Some Fedora contributors also argued that their distribution had superior approaches to these problems.
In reality, anyone who has worked on both sides knows that the same kinds of challenges exist across the FOSS ecosystem. Raising concerns or proposing changes is perfectly valid, especially if there is also a willingness to help implement them. That part seemed to be largely absent. The people maintaining Flathub, most of whom are volunteers, can only absorb so much constant criticism and nitpicking from the sidelines. Several Fedora contributors also hold positions in the GNOME Foundation, and later, there were attempts to push some of these changes through that avenue as well. Ultimately, I suspect Fedora’s philosophy, and that of some similar distributions, will never fully align with Flathub’s. To me, the differences seem fairly fundamental. That said, both sides could still have learned from each other and adopted ideas where it made sense. At least from my perspective, after so much mud being thrown and so much energy being spent, that opportunity now feels largely closed. Ideally, changes like this should develop organically over time, especially when a volunteer- run project, maintained by only a handful of people, is involved. Public criticism from prominent figures rarely helps move things in a constructive direction. Anyways…
Moving on to flatpak-builder-lint, I’m still maintaining it mostly solo. I took over the project in its early days, and at the time, it was quite controversial. For the first 5–6 years, Flathub had very minimal build validation, so people weren’t really used to their builds being blocked. When the linter started introducing many new checks (and therefore new breaking changes), it naturally caused a lot of frustration. On top of that, the linter CI wasn’t fully testing everything at the time, which led to additional breakages. Over the past couple of years, I’ve tried to stabilise things by improving the existing checks, adding many new ones, removing some vague or problematic ones, and introducing proper CI and test coverage. Whenever breaking changes were introduced, I tried to communicate them by opening issues on affected repositories - at times that meant opening 70–80 issues. I think all of that effort paid off. Over the past few months, I haven’t really had to add a lot of new code, and the complaints have stopped. These days, the biggest time sink is reviewing exception PRs, which I’m again at it mostly alone. Often this involves looking at the app’s code, running the application itself, knowing about Flatpak and portal developments, including what random libraries or frameworks support, asking maintainers questions for context, and making “judgment calls”.
Moving on to the documentation repository, there isn’t much to say here, except that I’m currently the only person actively writing and maintaining the docs. Over the past few year I’ve added a large number of maintenance documents, new policies, inclusion criteria, requirements, and other guidelines. Some of the documentation ends up being fairly technical, since writing it often requires familiarity with the tooling and the underlying code. Similarly, only reviewers who are familiar with the submission process can realistically write the submission and review criteria. I think I’ve done a decent job of keeping everything up-to-date.
Moving on to flatpak-external-data-checker, these days it has more or less turned into another low (read “no”) activity repository, since, as far as I can tell, Endless no longer uses it internally, and one of the main maintainers has also become inactive. Over the past year or so, I did a couple of sweeps through the issue tracker and landed a number of fixes and new features, with reviews from Will. A year is a long time, though, and while writing this, I opened the commit log in another tab to remind myself what exactly I worked on. Looking at it now, it seems that most of it is again just me. I guess I’ll simply refer to future me at it too.
The next thing is flathub-repro-checker, which I came up with last year. The fact that Flathub stores an application’s sources after the build and that it can be rebuilt from those exact sources with the generated manifest was “common knowledge” to me. However, the process itself was tedious and largely manual. Since I had previously worked on a large number of reproducibility fixes for Freedesktop SDK, and that project used a tool to automate the process, I wanted something similar for Flathub as well. The initial version was a fairly large ~1200 LoC Python script up until version 0.1.10. Recently, I finally managed to find the time to refactor it into a proper project. Bart and I also discussed how it could be deployed for Flathub. I think he ended up doing all the deployment and “hooking” work there, but now there is a nice reproducibility dashboard for Flathub.
The next big change for Flathub last year was switching to Vorarbeiter. Bart wrote all the code for it. I worked on getting the linter Docker image ready to be used in the Vorarbeiter pipelines. Some of that involved patching Flatpak and flatpak-builder at times. I also reviewed some of the initial Vorarbeiter code and pointed out a few security issues. Once it was deployed and working, I added a number of smaller features, such as improvements around PR annotations, handling cancelled builds, and some bot commands. Since then, I’ve continued to push occasional fixes whenever issues come up - usually discovered through random pings, the Sentry dashboard, or other reports. I don’t remember most of it now. Apart from all these, pretty much every repo in the flathub-infra org was touched by me in one way or another last year.
Freedesktop SDK
Moving on to Freedesktop SDK, while Codethink helps with the infrastructure and maintains BuildStream and related tooling, most of the general maintenance of the SDK itself has been handled by about 3 to 4 volunteers, including me. I started contributing around 2023, and since then, git shortlog tells me that I have the highest number of commits to the project, around 4000 commits spread across nearly 1000 MRs. Alas, one of the long time maintainer unfortunately became inactive last year, and since then, I have been handling a large portion of the general maintenance on my own.
The default permissions given to Freedesktop SDK contributors is Gitlab’s “Developer” role. However, that is quite restrictive as one cannot retrigger protected branch pipelines, create tags, change scheduled pipelines, or push updates to merge requests from forks. I was fine with this until being involved meant situations started coming up where a branch pipeline failed and needed to be retriggered, or when I needed to push fixes to a contributor’s merge request. Releases would also sometimes get delayed because the few people with the permissions required to make a release were busy or inactive. Occasionally, we also need to make emergency releases when Mesa introduces critical bugs that end up breaking hundreds of Flathub applications at once. Normally, in open source projects, I think that after someone has contributed for a long time and invested significant time and effort, they should be given more responsibility and higher permissions, especially since people with those permissions are being less active. That did not really happen here. Most of that control seems to remain concentrated among a few people, who generally don’t really maintain the SDK itself. This became a constant source of friction for me because I was one of the most active contributors and frequently needed to retrigger branch pipelines or perform other routine tasks. Over the past year or so, I asked several times for my Gitlab role to be bumped, and also suggested that other active contributors should receive higher permissions as well. Unfortunately, that never happened. The contributor who became inactive last year had been working on the project even longer than I had, and they also did not have the permissions they reasonably needed. At one point, I had to strongly protest giving “Developer” access to internal Codethink people who have never has/will contributed to the project, and fortunately, that stopped.
Another recurring source of friction for me was how some development priorities were handled. Since the SDK is used as a base for certain Codethink stuff, they sometimes assign interns or engineers to work on features they need. This occasionally resulted in large patch sets, the integration of old or difficult-to-maintain software, or new CI jobs being added without sufficient maintenance capacity. I often pushed back on these changes because they increased the long-term maintenance burden for me, since I am doing most of it. At times, it felt like there was more focus on meeting specific downstream needs than on maintainability and long term stability of the SDK itself. Nevertheless, I am grateful to Codethink for supporting the project through its infrastructure and engineering needs.
The work here also includes several freedesktop-sdk-related projects, such as the mesa-git extension, the freedesktop-sdk Docker images, the binary seed, and various other pieces of tooling. Most of this work is not very visible. It mostly consists of tedious maintenance tasks such as fixing builds, backporting patches, including security fixes, repairing CI failures, and helping decide when ABI breaks or freezes should happen. Occasionally, I also had to fix issues in BuildStream plugins. I also developed a few small tools to help automate parts of this workflow. These live in the freedesktop-sdk-utils repository and in the main freedesktop-sdk repository.
One particularly large change last year involved the license work. Among the SDK maintainers, it was generally known that we were not installing license files for built modules. However, we were not really aware of the potential legal implications. The “Fedora drama” led a number of distribution maintainers to take a closer look at the project, and the issue of missing license files ended up being amplified significantly. When the confidential issue was opened about it, there was a sense of urgency to address the “problem”. At the time, I was not aware that this was a direct consequence of that broader situation. If I had known, I probably would not have been as enthusiastic about jumping in. Nevertheless, I ended up creating the initial framework for handling license installation, with input from Adrian and a few other people. This work was happening in parallel with the upcoming 25.08 release, and we even had to revive branches from two or three years ago in order to fix them. In the end, I ended up doing a large portion of that work.
Flatpak
Moving on to Flatpak-related work, most Flatpak projects have been fairly dormant for several years, mainly because many of the original maintainers moved on to other projects. As part of the license work mentioned earlier, there was interest in bringing the same license installation framework to flatpak-builder. Sebastian implemented the feature, and through a series of events, I ended up reviewing, merging, and creating a release with it. Since Flathub had accumulated a number of patches over time, I also took the opportunity to upstream them one by one. That more or less marked the beginning of my involvement there. Since then, I ended up doing a bit of work around flatpak-builder, making several releases, introducing the stable/unstable release policy, cleaning up the issue tracker, fixing various bugs, merging PRs that had been sitting around for years, and adding a bunch of new features along the way. That also somehow spilt over into the Flatpak itself. I ended up reviewing a number of PRs there, merged some fixes, cleaned up parts of the issue tracker, and reviewed a couple of security patches.
I’m not really an expert in C, more so in GLib-flavoured C. I’m not really a software person either. The only formal programming I learned was basic Python during my Bachelor’s in Mathematics. Most of what I know now I picked up by reading documentation, browsing issues, and looking at other people’s code online. So large C codebases like Flatpak, with security boundaries and a long history of stability, and on which so many people depend, still give me an uneasy feeling. I think flatpak-builder should’ve been written in something like Python, as it is essentially a large “command runner”. Python, for me, has always felt more natural and faster to write and understand. I think it would be great to have the original maintainers like Alex back at everything again, but I’m doubtful.
Two other things that take some of my time are documentation work and maintaining most of the generators in the flatpak-builder-tools. Since many of the original maintainers are no longer active, I am now maintaining most of them. Last year, I added linting, type-checking, and CI improvements for many of them, fixed several bugs in the node, pip, dotnet, and cargo generators, reviewed and merged the new generator for Deno, and I’m currently reviewing the pnpm generator.
That concludes this part about the FOSS work I’ve been doing. I’ve been involved in this for about 4–5 years now, all in my free time, and I’d like to continue doing it for free in my own time. Lately, though, the amount of friction and frustration has been increasing, and I’ve been trying (and failing) to take some breaks. To “de-stress”, I’ve turned off notifications for several apps on my phone, stopped interacting entirely on some, and instead of checking emails daily like I used to, I now let them pile up for a few days before going through them. This leads to a pile of 300-400 emails a week, but whatever. I think in my time, I’ve seen a lot of projects become inactive. As a result, the community around it slowly wanes away, the project loses relevance and gets replaced by something else, or becomes a graveyard. I don’t really want that to happen, and that has been my main motivation for all this. Rather than writing something new, I try to contribute and help with existing things where possible.
Leisure
After all of the above, I hardly get any free time, but whenever I do, I listen to a lot of music and watch YouTube. Sometime in late 2024, I fell into the K-pop rabbit hole through Blackpink, and since then, I have been following their music, solo releases, and both their solo and group activities. I follow the Pinks on their socials, and last year I ended up watching most of their livestreams and fan content on YouTube. I’ve probably exhausted all Blackpink content available on the internet by now, and at this point, I think it is fair to say that I deeply adore them and am quite invested in them. That also led me to discover other artists such as Lee Hi, Taeyeon, Bol4, IU and AKMU. K-pop also eventually led to K-dramas, and over time, I’ve watched quite a few shows. Right now I’m watching Boyfriend on Demand.
Last year, I tried to get back into gaming. I bought two controllers for myself (one of them has TMR sticks), and I bought a bunch of games on Steam. I have been playing Dead Cells whenever I find time. So far, I’ve only managed to reach the Clock Room stage, but it has been fun.
I think that’s about it for this post. It ended up being quite a bit longer than I expected, but it was nice to reflect on things a bit.