index.xml

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Pixels</title>
    <link>https://bbhtt.in/</link>
    <description>Recent content on Pixels</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <copyright>CC BY-NC-SA 4.0</copyright>
    <lastBuildDate>Tue, 17 Mar 2026 11:42:50 +0530</lastBuildDate>
    
        <atom:link href="https://bbhtt.in/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Notes</title>
      <link>https://bbhtt.in/notes/</link>
      <pubDate>Tue, 17 Mar 2026 11:42:50 +0530</pubDate>
      
      <guid>https://bbhtt.in/notes/</guid>
      <description>&lt;p&gt;This is a place to share various teaching and study notes I often make.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;./first-order-linear-ode.pdf&#34;&gt;First order linear ODE&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;./first-order-separable-ode.pdf&#34;&gt;First order separable ODE&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;./variation-of-parameters.pdf&#34;&gt;Variation of parameters&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;./modelling.pdf&#34;&gt;Modelling differential equations&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;./mic2-mid-sem-qs-2026.pdf&#34;&gt;MIC2 mid semester questions 2026&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;./first-order-linear-pde.pdf&#34;&gt;First oder Linear PDE&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</description>
    </item>
    
    <item>
      <title>Diary#1</title>
      <link>https://bbhtt.in/posts/diary-1-1/</link>
      <pubDate>Fri, 13 Mar 2026 05:23:34 +0530</pubDate>
      
      <guid>https://bbhtt.in/posts/diary-1-1/</guid>
      <description>&lt;p&gt;This is going to be the first post in what might become a series of
occasional status updates or something like a personal diary. I might
overshare or ramble a bit at times and there generally won&amp;rsquo;t be anything
particularly important or interesting here.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve been meaning to write something like this for a while now, but
never really found the time or motivation to actually do it. I kind of
always liked the idea of keeping a record of what&amp;rsquo;s going on in my
life - my thoughts, experiences, and small updates. It feels nice to
know that someday I might be able to look back at these posts and
recollect. It also feels nice to share these thoughts, even though I
don&amp;rsquo;t really know who the audience (apart from me) is going to be — if
anyone.&lt;/p&gt;
&lt;p&gt;I guess I will start this by writing about my health.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve generally been healthy all my life. Apart from the usual seasonal
fevers or occasional stomach issues, I&amp;rsquo;ve never really had any health
problems that I can remember. As a result I guess I&amp;rsquo;ve never did any
regular checkups or tried to be consciously healthy like doing
exercises. Things changed a bit last November (2025). I developed a
fever just before winter was approaching, but this time to my
surprise it didn&amp;rsquo;t come with the usual set of symptoms like runny nose
or cold. I didn&amp;rsquo;t think much of it at first and took some paracetamol.
But after 3-4 days it wasn&amp;rsquo;t going away and I got a little scared. 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 like 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
scared a bit more. 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 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 &amp;ldquo;manage&amp;rdquo; (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&amp;rsquo;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&amp;rsquo;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&amp;rsquo;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 at the clinic it was 140/80 mmHg. It&amp;rsquo;s
still a bit on the higher side but it &lt;em&gt;has&lt;/em&gt; gone down in the last three
months. I&amp;rsquo;ve been also trying to &amp;ldquo;de-stress&amp;rdquo; in various ways like
reducing my &amp;ldquo;online&amp;rdquo; time (more on that later). Hopefully things turn
out to be ok.&lt;/p&gt;
&lt;p&gt;The next part is going to be a bit about my work and Ph.D.&lt;/p&gt;
&lt;p&gt;The latter has been stressful and frustrating lately for various
reasons, I won&amp;rsquo;t really get into. I did manage to submit my first paper
to IJB last week. The review process takes quite a bit of time, so I&amp;rsquo;ll
have to wait and see how that goes. In the meantime, I&amp;rsquo;ve also been
working on two more papers. One of them is essentially finished and I&amp;rsquo;ve
sent it to my guide for feedback while I&amp;rsquo;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 the Ph.D. in Algebraic Topology as that
was my specilisation during Masters but I didn&amp;rsquo;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.&lt;/p&gt;
&lt;p&gt;This semester I&amp;rsquo;m also teaching a course on introductory ODEs and PDEs.
I finished the ODE portion of the course last week. I used SL Ross&#39;
&lt;em&gt;Introduction to Ordinary Differential Equations&lt;/em&gt; 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, homogenous, exact and
Bernoulli differential equations and for second order ODEs (both
variable and constant coefficients, homogenous and non-homogenous) we
did the methods of reduction of order, 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
longer term. The mid-semester exams happened last week, so I now have a
pile of 40 or 50 answer scripts waiting to be graded.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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
barrage of the absolute worst, lowest quality AI-generated submission
PRs that we get. Reviewing these is hugely frustrating and downright
infuriating. Closing them often leads to people sending emails, matrix
pings/DMs or opening more PRs, which eventually escalates into arguments
and bans. I sometimes get pings when I&amp;rsquo;m doing something very important
IRL (like a few weeks ago, I had multiple pings when doing a blood test)
I don&amp;rsquo;t think anyone deserves to deal with this. I don&amp;rsquo;t really have a
problem with people using AI as a tool to assist them, but alas what we
usually end up getting is full-on AI slop without &lt;em&gt;any&lt;/em&gt; real human
thought or input. I try to be reasonable but it has been very
frustrating. I&amp;rsquo;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 are still difficult to filter automatically and need 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 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 &amp;ldquo;infra&amp;rdquo;
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.&lt;/p&gt;
&lt;p&gt;Dealing with the so-called &amp;ldquo;Fedora drama&amp;rdquo; 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 criticized. 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 criticism and arbitrary
demands directed at Flathub at both the technical and policy level. 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&amp;rsquo;s philosophy, and that of some similar distributions, will
never fully align with Flathub&amp;rsquo;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&amp;hellip;&lt;/p&gt;
&lt;p&gt;Moving on to flatpak-builder-lint, I&amp;rsquo;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&amp;rsquo;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&amp;rsquo;t fully testing everything
at the time, which led to additional breakages. Over the past couple of
years I&amp;rsquo;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
I think all of that effort paid off. Over the past few months I haven&amp;rsquo;t
I really had to add a lot of new code, and the complaints have stopped.
These days the biggest time sink there is reviewing exception PRs, which
I&amp;rsquo;m again at it mostly alone. Often this involves looking at the app&amp;rsquo;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 &amp;ldquo;judgement calls&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;Moving on to the documentation repository, there isn&amp;rsquo;t much to say
here, except that I&amp;rsquo;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.&lt;/p&gt;
&lt;p&gt;Moving on to flatpak-external-data-checker, these days it has more or
less turned into another low (read &amp;rsquo;no&amp;rsquo;) activity repository, since as
far as I can tell Endless no longer uses it internally, and one of the
main maintainers have 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&amp;rsquo;ll simply refer future me
at it too.&lt;/p&gt;
&lt;p&gt;The next thing is flathub-repro-checker, which I came up with last year.
The fact that Flathub stores an application&amp;rsquo;s sources after the build
and that it can be rebuilt from those exact sources with the generated
manifest was &amp;ldquo;common knowledge&amp;rdquo; 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 &amp;ldquo;hooking&amp;rdquo; work there but now there is a nice
reproducibility dashboard for Flathub.&lt;/p&gt;
&lt;p&gt;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, some bot commands. Since then I&amp;rsquo;ve continued to push
occasional fixes whenever issues come up - usually discovered through
random pings, the Sentry dashboard, or other reports. I don&amp;rsquo;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;The default permissions given to Freedesktop SDK contributors is
GitLab&amp;rsquo;s &amp;ldquo;Developer&amp;rdquo; 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&amp;rsquo;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 after someone has contributed for a long
time and invested significant time and effort, they should be given more
responsibility and higher permissions, espcially since people with those
are being less active. That did not really happen here. Most of that
control seems to remain concentrated among Codethink people, who
generally do not 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 &amp;ldquo;Developer&amp;rdquo; access to random Codethink people who never
has/will contributed to the project and fortunately that stopped.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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 &amp;ldquo;Fedora drama&amp;rdquo; 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 &amp;ldquo;problem&amp;rdquo;. 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,nand 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.&lt;/p&gt;
&lt;p&gt;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 spilled 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.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;m not really an expert in C, more so in GLib flavored C. I&amp;rsquo;m not really
a software person either. The only formal programming I learned was
basic Python during my Bachelor&amp;rsquo;s in Mathematics. Most of what I know
now I picked up by reading documentation, browsing issues, and looking
at other people&amp;rsquo;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 upon still give me an uneasy feeling. I think
flatpak-builder should&amp;rsquo;ve been written in something like Python, as it
is essentially a large &amp;ldquo;command runner&amp;rdquo;. 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&amp;rsquo;m doubtful.&lt;/p&gt;
&lt;p&gt;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&amp;rsquo;m currently reviewing the pnpm generator.&lt;/p&gt;
&lt;p&gt;That concludes this part about the FOSS work I&amp;rsquo;ve been doing. I&amp;rsquo;ve been
involved in this for about 4–5 years now, all in my free time, and I&amp;rsquo;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&amp;rsquo;ve been
trying (and failing) to take some breaks. To &amp;ldquo;de-stress&amp;rdquo;, I&amp;rsquo;ve turned
off notifications for several apps on my phone, 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 around 300-400 emails a week
but whatever. I think in my time, I&amp;rsquo;ve seen a lot of projects become
inactive. As a result the community around it slowly wanes away, the
project looses relevance and gets replaced by something else or becomes
a graveyard. I don&amp;rsquo;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.&lt;/p&gt;
&lt;p&gt;After all of the above I hardly get any free time, but whenever I do I
listen to a lot of &lt;a href=&#34;https://music.youtube.com/@bbhtt3305&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;music&lt;/a&gt; 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&amp;rsquo;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, AKMU, and Jeon Somi. K-pop also led me into watching
K-dramas, and over time I&amp;rsquo;ve watched quite a few &lt;a href=&#34;https://mydramalist.com/dramalist/bbhtt/completed&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;shows&lt;/a&gt;.
Right now I&amp;rsquo;m watching &lt;em&gt;Boyfriend on Demand&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;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&amp;rsquo;ve
only managed to reach the Clock Room stage, but it has been fun.&lt;/p&gt;
&lt;p&gt;I think that&amp;rsquo;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
a bit.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Closing the chapter on OpenH264</title>
      <link>https://bbhtt.in/posts/closing-the-chapter-on-openh264/</link>
      <pubDate>Sat, 22 Mar 2025 18:48:40 +0530</pubDate>
      
      <guid>https://bbhtt.in/posts/closing-the-chapter-on-openh264/</guid>
      <description>&lt;p&gt;People might have noticed me talking about dropping OpenH264 from
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Freedesktop SDK&lt;/a&gt;.
Here, I&amp;rsquo;ll try to go a bit into the history, the timeline and what led
to the final decision.&lt;/p&gt;
&lt;h2 id=&#34;a-bit-of-an-introduction&#34;&gt;A bit of an introduction&lt;/h2&gt;
&lt;p&gt;If you are unfamiliar with the Freedesktop SDK project: it was born out
of the initial &lt;a href=&#34;https://github.com/flatpak/freedesktop-sdk-images&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;1.6 Flatpak runtime image&lt;/a&gt;
created by &lt;a href=&#34;https://github.com/alexlarsson&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Alexander Larsson&lt;/a&gt; to
provide a host independent &amp;ldquo;runtime&amp;rdquo; for Flatpaks. Since then, with the
help of &lt;a href=&#34;https://www.codethink.co.uk/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Codethink&lt;/a&gt; and others, it grew
into an independent project maintained by the community that aims to
provide a &amp;ldquo;A minimal Linux runtime&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;Currently that includes the &lt;code&gt;org.freedesktop.{Sdk, Platform}&lt;/code&gt;
&lt;a href=&#34;https://docs.flatpak.org/en/latest/introduction.html#terminology&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Flatpak runtimes&lt;/a&gt;,
a bunch of other &lt;a href=&#34;https://docs.flatpak.org/en/latest/extension.html&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Flatpak extensions&lt;/a&gt;
such as the GL (Mesa) extensions, a bootable image stack that includes
things like the Linux kernel, firmware and drivers and a collection
of docker images.&lt;/p&gt;
&lt;p&gt;The runtimes (and more broadly the &amp;ldquo;Flatpak&amp;rdquo; stack) form the base for
the &lt;a href=&#34;https://gitlab.gnome.org/GNOME/gnome-build-meta/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;GNOME&lt;/a&gt; and
&lt;a href=&#34;https://invent.kde.org/packaging/flatpak-kde-runtime&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;KDE&lt;/a&gt; Flatpak
runtimes which are collectively used by 2000+ Flatpaks, while the
bootable stack along with other parts forms the base for things like
&lt;a href=&#34;https://os.gnome.org/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;GNOME OS&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id=&#34;some-history&#34;&gt;Some history&lt;/h2&gt;
&lt;p&gt;H.264 is one of the &lt;a href=&#34;https://www.cloudflare.com/learning/video/what-is-h264-avc/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;most widely used&lt;/a&gt;
codecs today but unfortunately it is patented with several patents
&lt;a href=&#34;https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_MPEG-4_AVC_expired_yet%3F&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;still active&lt;/a&gt;.
Patents like this are a blocker to shipping software dealing with the
codec in the base runtime (since we want it usable by a wide variety of
vendors and free of any legal grey areas) and unfortunately makes life
difficult for everyone involved.&lt;/p&gt;
&lt;p&gt;To workaround this and ship working software to users, 6 years ago, in
2019 the precursor to the OpenH264 extension, called the
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/1c1d87eb7f1e7952bf79825cfb65225f3a3c3e30&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;html5-codecs extension&lt;/a&gt;
was added to the Freedesktop runtime by Tom Coldrick. The idea was
simple - it would contain support for FFMPEG&amp;rsquo;s internal H.264 decoder
and would be an optional Flatpak extension since we were unable to ship
it in the runtime itself.&lt;/p&gt;
&lt;p&gt;Fast-forward a few months, in June 2019, &lt;a href=&#34;https://gitlab.com/ramcq&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Robert McQueen&lt;/a&gt;
opened an &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/815&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;issue&lt;/a&gt;
to include &lt;a href=&#34;https://github.com/cisco/openh264&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Cisco&amp;rsquo;s OpenH264&lt;/a&gt;
(commonly referred as &lt;code&gt;libopenh264&lt;/code&gt; too) as an extension to the runtime.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;libopenh264&lt;/code&gt; code is open source but due to the H.264 patents, no
vendor is legally allowed to distribute their own binaries (some vendors
build it themselves and hand it to Cisco but no one made that arrangement
for us). The solution to this was to distribute Cisco&amp;rsquo;s unmodified
binaries directly to the user which would effectively be free of any
royalties but the catch is, the binaries have
&lt;a href=&#34;https://www.openh264.org/BINARY_LICENSE.txt&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;some license restrictions&lt;/a&gt;
on them.&lt;/p&gt;
&lt;p&gt;So Endless around that time, added &lt;a href=&#34;https://docs.flatpak.org/en/latest/module-sources.html#extra-data&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;extra-data&lt;/a&gt;
support to Flatpak. This meant that the Flatpak extension metadata
would only contain an URL to Cisco&amp;rsquo;s binaries, checksums and a &amp;ldquo;recipe&amp;rdquo;
to make a working extension out of it. The binary would be downloaded
on the end user&amp;rsquo;s machine, inside a sandbox and then the &amp;ldquo;recipe&amp;rdquo;
would be executed to create a working extension. This avoids various
&amp;ldquo;redistribution&amp;rdquo; restrictions entirely since we aren&amp;rsquo;t shipping the
binary itself.&lt;/p&gt;
&lt;p&gt;However, one last catch remained with this approach. Unless the end user
system has downloaded the extension, a part of the ABI will be missing
from the base runtime itself. Additionally, the extension would also
get mounted to a non-standard location inside the Flatpak sandbox. So to
build something against that we needed a &amp;ldquo;public&amp;rdquo; library that is
included in the runtime itself.&lt;/p&gt;
&lt;p&gt;Endless came up with a stub OpenH264 library called &lt;a href=&#34;https://github.com/endlessm/noopenh264/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;noopenhh264&lt;/a&gt;,
as a solution to this. This would be kept ABI/API compatible to the
actual Cisco&amp;rsquo;s OpenH264 library and would live inside the runtime at
&lt;code&gt;$libdir&lt;/code&gt; to allow software to link to libopenh264 and provide a
fallback. At runtime, if the user downloads the actual OpenH264
extension, the stub library would get overridden by the library in
extension through Flatpak&amp;rsquo;s ld.so config and voilà, you have a working
OpenH264 setup!&lt;/p&gt;
&lt;h2 id=&#34;the-start-of-the-openh264-extension&#34;&gt;The start of the openh264 extension&lt;/h2&gt;
&lt;p&gt;Following the gruelling details above, in August 2019, Tom Coldrick
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/1638&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;again added&lt;/a&gt;
this &amp;ldquo;noopenh264&amp;rdquo; library to the runtime and set up the extension point
called &lt;code&gt;org.freedesktop.Platform.openh264&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;Around that time, the development of the &amp;ldquo;stub&amp;rdquo; noopenh264 library also
moved under the &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/noopenh264&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Freedesktop SDK umbrella&lt;/a&gt;
while the development of this extra-data extension was going on in a
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/openh264-extension&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;dedicated repository&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;I talked about a &amp;ldquo;recipe&amp;rdquo; of an extra-data Flatpak extension a while
back, which is nothing but a set of commands in a special file called
&lt;code&gt;apply_extra&lt;/code&gt; to stage and install the source. As an example, if it
was a &lt;code&gt;.deb&lt;/code&gt; it would be a sequence of &lt;code&gt;ar&lt;/code&gt; or &lt;code&gt;bsdtar&lt;/code&gt; commands to
extract it, then install it inside Flatpak&amp;rsquo;s extra-data prefix.&lt;/p&gt;
&lt;p&gt;The catch here is that using any utility like that makes the extension
directly dependent on a particular branch of the Flatpak runtime and thus
the API/ABI provided by it.&lt;/p&gt;
&lt;p&gt;As every yearly major release of the Freedesktop runtime is a completely
new ABI, we would need to continuously spin off new branches of the
OpenH264 extension i.e. for version 2.1.0 of libopenh264 we would need
&lt;code&gt;org.freedesktop.Platform.openh264//2.1.0-{18.08, 19.08, 20.08}&lt;/code&gt; branches
for the extension and so on. This would make it a bit of an chore to
update the extension in Freedesktop runtime itself and also for
our downstream runtimes.&lt;/p&gt;
&lt;p&gt;As a solution to this, a custom &lt;code&gt;apply_extra&lt;/code&gt; script was &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/openh264-extension/-/commit/8a80eaaab8cd6b6aa7e241e681bdbaeed5632e56&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;written&lt;/a&gt;,
which utilised only a few standard headers and would be &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/openh264-extension/-/commit/98601a6bcfd5a287106653bc69e54b58ce619c9e&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;built statically&lt;/a&gt;
against a fixed toolchain.&lt;/p&gt;
&lt;p&gt;The meant a bit of complexity, since we aren&amp;rsquo;t allowed to use most
things that would make this process easier but it also meant the final
extension was independent of the runtime API/ABI and was built on top
of &amp;ldquo;NoRuntime&amp;rdquo;.&lt;/p&gt;
&lt;h2 id=&#34;the-flaws-start-to-show-up&#34;&gt;The flaws start to show up&lt;/h2&gt;
&lt;p&gt;This entire setup worked quite well for a long time despite some
maintenance issues from Cisco. However there were some flaws.&lt;/p&gt;
&lt;p&gt;A while back I told that every vendor is forced to distribute binaries
hosted by Cisco at &lt;code&gt;https://ciscobinary.openh264.org&lt;/code&gt;. Unfortunately
&lt;code&gt;ciscobinary.openh264.org&lt;/code&gt; is missing a valid SSL certificate
&lt;a href=&#34;https://github.com/cisco/openh264/issues/909#issue-34658985&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;at least since 2014&lt;/a&gt;
and Cisco neither supplies GPG signatures nor strong checksums like
SHA-256 for the binary releases.&lt;/p&gt;
&lt;p&gt;This meant that we have no way to verify the authenticity of Cisco&amp;rsquo;s
binaries, opening us to various classes of MiTM and supply-chain
vulnerabilities. We reached out to Mozilla and via Fedora/RedHat to get
Cisco to fix this, as one can see the comments on the thread but
nothing ever happened.&lt;/p&gt;
&lt;p&gt;More recently (around 2024-2025), this SSL issue meant that the domain
started getting &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/24521#note_2329956598&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;DNS blocked&lt;/a&gt;
and would make the extra-data download fail, botching an install.&lt;/p&gt;
&lt;p&gt;Another critical issue was that if upstream did security fixes and then
released them with an ABI break, we couldn&amp;rsquo;t fix it for the Flatpak
runtimes. Distributing binaries directly through extra-data meant there
is no scope for cherry-picking patches and the ABI break meant the new
version would only be able go to a new branch of the runtime.&lt;/p&gt;
&lt;p&gt;We didn&amp;rsquo;t really have a choice here. If we dropped this extension
considering the potential flaws, the entirety of the Flatpak user base
would loose H.264 decoding and encoding support, so we had to live with
the setup.&lt;/p&gt;
&lt;h2 id=&#34;the-start-of-the-codecs-extra-extension&#34;&gt;The start of the codecs-extra extension&lt;/h2&gt;
&lt;p&gt;Around June 2024 &lt;code&gt;gdk-pixbuf&lt;/code&gt; due to a series of security issues,
&lt;a href=&#34;https://discourse.gnome.org/t/change-in-the-gdk-pixbuf-loaders-built-by-default-in-2-42-11/21845&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;dropped support&lt;/a&gt;
for a lot of &amp;ldquo;fringe&amp;rdquo; loaders. We immediately noticed the change as
we constantly analyse ABI in stable branches.&lt;/p&gt;
&lt;p&gt;To compensate for the dropped loaders, we &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/19916&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;decided&lt;/a&gt;
to add &lt;code&gt;webp, avif, jxl, heif&lt;/code&gt; support (with pixbuf loaders) to the
runtime. Around the same time, &lt;a href=&#34;https://gitlab.com/wjt&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Will Thompson&lt;/a&gt;
opened an &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1704&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;issue&lt;/a&gt;
to add &lt;code&gt;libheif&lt;/code&gt; to the runtime with the problematic HEIC decoder as a
runtime extension.&lt;/p&gt;
&lt;p&gt;Consequently, we decided that yet another extension just for two libheif
plugins is not worth the maintenance effort and these would rather be
in the &lt;code&gt;ffmpeg-full&lt;/code&gt; extension (This was the successor to the
&lt;code&gt;html5-codecs&lt;/code&gt; extension, created around 2019-2020). So I &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/20268&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;again&lt;/a&gt;
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/19942&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;added&lt;/a&gt;
&lt;code&gt;libx265, libde265&lt;/code&gt; and the corresponding libheif plugins to the
ffmpeg-full extension. After a few months I also &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/21970&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;added&lt;/a&gt;
&lt;code&gt;libx264&lt;/code&gt; to it too as we were already shipping &lt;code&gt;libx265&lt;/code&gt; and Cisco&amp;rsquo;s
OpenH264 had suboptimal encoding performance.&lt;/p&gt;
&lt;p&gt;I was happy with the result and all of this shipped in Freedesktop SDK
24.08. But some people were unhappy for valid reasons.&lt;/p&gt;
&lt;p&gt;When the &lt;code&gt;ffmpeg-full&lt;/code&gt; extension was created, due to various concerns
it was never added to the runtime or SDK manifest; it lived as an
optional &amp;ldquo;app&amp;rdquo; extension - meaning app developers would need to add a
&lt;a href=&#34;https://docs.flatpak.org/en/latest/extension.html#loading-existing-extensions&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;short snippet&lt;/a&gt;
in their Flatpak manifest to use it.&lt;/p&gt;
&lt;p&gt;This was problematic in some ways - sometimes app developers were
unaware of the extension or that they needed it and the app manifest
was missing the snippet that allowed to use the extension. This made
user and developer experience a bit poor. Once we started
shipping &lt;code&gt;libheif&lt;/code&gt; in &lt;code&gt;ffmpeg-full&lt;/code&gt;, it became slightly more
problematic as the actual libheif library was in the runtime but without
the extension it cannot decode any HEIF/HEIC image. So the extension
was practically mandatory. &lt;a href=&#34;https://github.com/tsdgeos&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Albert Astals Cid&lt;/a&gt;,
part of the team who maintains KDE Flatpaks on Flathub complained about
this and an &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1825&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;issue was opened by Erick555&lt;/a&gt;
to discuss the possibility of making ffmpeg-full a runtime extension.&lt;/p&gt;
&lt;p&gt;I was initially reluctant to do this for various reasons and the
situation was again a bit out of our hands (this time due to H.265
patents) but we asked various parties such as Endless and quite
surprisingly it turned out no one really had an objection to making it
a runtime extension or even make it auto-download along with the
runtime.&lt;/p&gt;
&lt;p&gt;Along with this change, we decided to rename the &lt;code&gt;ffmpeg-full&lt;/code&gt; extension
again, this time to &lt;code&gt;codecs-extra&lt;/code&gt; to better reflect the fact that it
will not only contain FFMPEG with patented parts but other libraries
too that deals with patented codecs. This would sort of be an equivalent
to the various &amp;ldquo;meta-packages&amp;rdquo; that distros provide for patented or
restricted codecs.&lt;/p&gt;
&lt;p&gt;Thus the seeds were planted and I switched &lt;code&gt;ffmpeg-full&lt;/code&gt; to
&lt;code&gt;codecs-extra&lt;/code&gt; a &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/24620&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;month ago&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;This is supposed to ship in Freedesktop SDK 25.08. The major change for
app developers is that there is no longer any need to have something
like&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;nt&#34;&gt;add-extensions&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;w&#34;&gt;  &lt;/span&gt;&lt;span class=&#34;nt&#34;&gt;org.freedesktop.Platform.ffmpeg-full&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;w&#34;&gt;    &lt;/span&gt;&lt;span class=&#34;nt&#34;&gt;version&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt; &lt;/span&gt;&lt;span class=&#34;s1&#34;&gt;&amp;#39;24.08&amp;#39;&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;w&#34;&gt;    &lt;/span&gt;&lt;span class=&#34;nt&#34;&gt;directory&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt; &lt;/span&gt;&lt;span class=&#34;l&#34;&gt;lib/ffmpeg&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;&lt;span class=&#34;w&#34;&gt;    &lt;/span&gt;&lt;span class=&#34;nt&#34;&gt;add-ld-path&lt;/span&gt;&lt;span class=&#34;p&#34;&gt;:&lt;/span&gt;&lt;span class=&#34;w&#34;&gt; &lt;/span&gt;&lt;span class=&#34;l&#34;&gt;.&lt;/span&gt;&lt;span class=&#34;w&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;in the manifest. &lt;code&gt;org.freedesktop.Platform.codecs-extra&lt;/code&gt; will be
automatically installed by the runtime and will be available to users.&lt;/p&gt;
&lt;h2 id=&#34;dropping-the-openh264-extension&#34;&gt;Dropping the openh264 extension&lt;/h2&gt;
&lt;p&gt;The above &lt;code&gt;codecs-extra&lt;/code&gt; change meant that we now didn&amp;rsquo;t really have an
use case for &lt;code&gt;org.freedesktop.Platform.openh264&lt;/code&gt; since &lt;code&gt;codecs-extra&lt;/code&gt;
had FFMPEG&amp;rsquo;s internal H.264 decoder and the &lt;code&gt;libx264&lt;/code&gt; encoder.&lt;/p&gt;
&lt;p&gt;So I initially disabled autodownload and considering the various &amp;ldquo;flaws&amp;rdquo;
with OpenH264 discussed above, I &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1834&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;opened an issue&lt;/a&gt;
for planned retirement in 26.08.&lt;/p&gt;
&lt;p&gt;This was completely overturned when a &lt;a href=&#34;https://github.com/cisco/openh264/security/advisories/GHSA-m99q-5j7x-7m9x&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;high severity flaw&lt;/a&gt;
was discovered in libopenh264 affecting versions 2.5.0 and earlier.&lt;/p&gt;
&lt;p&gt;The 23.08 branch of the Freedesktop runtime was locked to 2.2.0 and
upgrading to a fixed version was not possible due to multiple ABI breaks
and SONAME bumps upstream. Patching was also not an option as I said
earlier.&lt;/p&gt;
&lt;p&gt;We scrambled to mitigate this. For 23.08, we decided to make an
&amp;ldquo;ABI break&amp;rdquo; and &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1846&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;drop the extension&lt;/a&gt;
as updating was impossible. So I made a bit of an intimidating &lt;a href=&#34;https://discourse.flathub.org/t/upcoming-freedesktop-23-08-runtime-release-will-drop-openh264-extension/9022&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;announcement&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;But we still had 24.08 left which was on 2.4.1 and updating to the fixed
version i.e. 2.6.0 was again blocked due to an ABI bump.&lt;/p&gt;
&lt;p&gt;However, looking through the commits between 2.4.1 and 2.6.0 and
analysing the library through libabigail we couldn&amp;rsquo;t find an actual
ABI break that was made and considering Cisco in the past made
unnecessary SONAME bumps, we tried patching the 2.6.0 release to
provide the older ABI.&lt;/p&gt;
&lt;p&gt;I &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/openh264-extension/-/merge_requests/68&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;messed&lt;/a&gt;
with that venerable apply_extra and wrote a small utility to patch
SONAMEs. But upstream, in time, pointed us to the ABI break
and this idea had to be scrapped entirely. (I later found out why
liabigail was unable to show the ABI break after talking to Dodji
Seketeli, the libabigail maintainer.)&lt;/p&gt;
&lt;p&gt;We then &lt;a href=&#34;https://github.com/cisco/openh264/issues/3863&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;asked upstream&lt;/a&gt;
to provide a patch release 2.5.1 instead with the old ABI and to our
surprise they did within a few weeks! This shipped in 24.08.15 fixing
the 24.08 branch of the runtime.&lt;/p&gt;
&lt;p&gt;After all this debacle and the extra &amp;ldquo;headache&amp;rdquo;, none of us felt
comfortable shipping the openH264 extension anymore. Thus it was
&lt;a href=&#34;https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/24871&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;dropped&lt;/a&gt;
for the master branch, which means there won&amp;rsquo;t be any
&lt;code&gt;org.freedesktop.Platform.openh264&lt;/code&gt; extension or &lt;code&gt;noopenh264&lt;/code&gt; for 25.08+.&lt;/p&gt;
&lt;h2 id=&#34;epilogue&#34;&gt;Epilogue&lt;/h2&gt;
&lt;p&gt;Considering all things, I think and hope we made the correct decision
and hopefully the new &lt;code&gt;org.freedesktop.Platform.codecs-extra&lt;/code&gt; works
out. &lt;code&gt;libx264, libx265&lt;/code&gt; and others are built from source and there
are no binaries or extra-data involved. So we should theoretically be
able to patch and fix any issues that come up in the future.&lt;/p&gt;
&lt;p&gt;Apart from all this, I&amp;rsquo;m slightly worried at the prospects of legal
issues cropping up with this setup and also that the new extension
contains &amp;ldquo;too much&amp;rdquo;, but we will have to see where things flow.&lt;/p&gt;
&lt;p&gt;As a fun tidbit, I wasn&amp;rsquo;t aware that Fedora was also using our
&lt;code&gt;org.freedesktop.Platform.openh264&lt;/code&gt; extension. I caused a bit of work
for them as noopenh264 &lt;a href=&#34;https://gitlab.com/freedesktop-sdk/noopenh264/-/commit/2177b9cb3542d0c9ccba4d20e56516118f8e747d&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;moved home&lt;/a&gt;
once again, now to Fedora and they are looking for ways to make their
own OpenH264 extension similar to how we did.&lt;/p&gt;
&lt;p&gt;I hope the experience here helps anyone in the future wanting to maintain
such an extension and this will also serve as a reminder to how much
extra work patents like these causes.&lt;/p&gt;
&lt;p&gt;Lastly I&amp;rsquo;d like to thank Endless for giving us not only noopenh264 but
also extra-data support in Flatpak that made all this possible;
&lt;a href=&#34;https://gitlab.com/TheRealMichaelCatanzaro&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Michael Catanzaro&lt;/a&gt; and &lt;a href=&#34;https://gitlab.com/nanonyme&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Seppo Yli-Olli&lt;/a&gt;
for maintaining this setup for a long time; &lt;a href=&#34;https://gitlab.com/valentindavid&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Valentin David&lt;/a&gt;
for helping me in the last few days and everyone else who worked on
this ❤️&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Hello, World</title>
      <link>https://bbhtt.in/posts/hello-world/</link>
      <pubDate>Fri, 05 Apr 2024 09:32:40 +0530</pubDate>
      
      <guid>https://bbhtt.in/posts/hello-world/</guid>
      <description>&lt;p align=&#34;center&#34;&gt;
  &lt;img src=&#34;./cat.png&#34; alt=&#34;A cat standing on two legs with one hand on a bed and the other one stretched in the opposite direction - in a stuck position&#34; /&gt;
&lt;/p&gt;
</description>
    </item>
    
    <item>
      <title>About</title>
      <link>https://bbhtt.in/about/</link>
      <pubDate>Fri, 07 Jul 2023 12:44:33 +0530</pubDate>
      
      <guid>https://bbhtt.in/about/</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;I’m Nobody! Who are you? Are you – Nobody – too? Then there’s a pair of us!&lt;/em&gt; ~ Emily Dickinson&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Hello!&lt;/p&gt;
&lt;p&gt;You might know me by my online alias, &lt;em&gt;bbhtt&lt;/em&gt;, which is somewhat of a
clumsy attempt to derive a nickname from my real name, Boudhayan
Bhattacharya. I live in India and I have completed my B.Sc. (Honours) in
2021 and M.Sc. in Mathematics in 2023. Currently, I&amp;rsquo;m pursuing a Ph.D.
in Mathematics. I teach Mathematics for work and contribute to &lt;a href=&#34;https://en.wikipedia.org/wiki/Free_and_open-source_software&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;FOSS projects&lt;/a&gt;
during my free time.&lt;/p&gt;
&lt;p&gt;I love watching &lt;a href=&#34;https://www.imdb.com/user/ur212871697/ratings/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;movies and TV shows&lt;/a&gt;,
&lt;a href=&#34;https://myanimelist.net/animelist/bbhtt&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;anime&lt;/a&gt;, &lt;a href=&#34;https://mydramalist.com/dramalist/bbhtt&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;K-dramas&lt;/a&gt;,
and I&amp;rsquo;m almost always listening to &lt;a href=&#34;https://music.youtube.com/@bbhtt3305&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;music&lt;/a&gt;.
Although, most of the time, I&amp;rsquo;m probably lost in some random YouTube
binge. I also try to read (or listen to) books and play some games on
&lt;a href=&#34;https://steamcommunity.com/id/bbhtt/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Steam&lt;/a&gt; every now and then, and
occasionally mess around with casual online chess on Lichess.&lt;/p&gt;
&lt;p&gt;You can contact me via:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Email: &lt;a href=&#34;mailto:bbhtt@bbhtt.in&#34;&gt;bbhtt@bbhtt.in&lt;/a&gt;. My GPG key
is &lt;a href=&#34;./bbhtt.pub&#34;&gt;D26D 7533 9500 9DB2 B3B2 6094 0C32 51A2 4745 E484&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://matrix.org/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;[matrix]&lt;/a&gt;: &lt;a href=&#34;https://matrix.to/#/@bbhtt:matrix.org&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;@bbhtt:matrix.org&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;IRC: bbhtt on &lt;a href=&#34;ircs://irc.libera.chat/bbhtt,isuser&#34;&gt;Libera.chat&lt;/a&gt;, &lt;a href=&#34;ircs://irc.oftc.net/bbhtt,isuser&#34;&gt;OFTC&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The domain for this website is registered with
&lt;a href=&#34;https://www.hostinger.com/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Hostinger&lt;/a&gt;, while DNS and TLS
certificates are managed through &lt;a href=&#34;https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;Cloudflare&lt;/a&gt;.
The website itself is hosted as a static site on
&lt;a href=&#34;https://docs.github.com/en/pages&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;GitHub pages&lt;/a&gt;. No additional
analytics have been enabled beyond those collected by these services by
default (which cannot be disabled). Only Cloudflare among these services,
provides visible analytics, an example of which can be found
&lt;a href=&#34;./cloudflare_stats.png&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Unless otherwise stated, all content here is licensed under
&lt;a href=&#34;https://creativecommons.org/licenses/by-nc-sa/4.0/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;CC BY-NC-SA 4.0&lt;/a&gt;.&lt;/p&gt;
</description>
    </item>
    
  </channel>
</rss>