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>Wed, 11 Mar 2026 15:48:43 +0530</lastBuildDate>
    
        <atom:link href="https://bbhtt.in/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Diary#1</title>
      <link>https://bbhtt.in/posts/diary-1/</link>
      <pubDate>Wed, 11 Mar 2026 15:48:43 +0530</pubDate>
      
      <guid>https://bbhtt.in/posts/diary-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 the other one, I&amp;rsquo;ve just started
working on. 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&amp;rsquo; &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 (2026). 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. 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 have been
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 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
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 than anyone else), maintaining a bunch of Flatpaks (around 19)
and whatever random issues people ping me on.&lt;/p&gt;
&lt;p&gt;Dealing with the so-called &amp;ldquo;Fedora drama&amp;rdquo; in parallel with all of this
has also been quite frustrating. People can only take so much constant
criticism and nitpicking from the sidelines. I don&amp;rsquo;t think Fedora&amp;rsquo;s
philosophy (or that of similar distributions) is ever going to fully
align with Flathub&amp;rsquo;s, since to me, the differences exist at a fundamental
level. That said, I do think both sides could still take inspiration
from each other and adapt where it makes sense. Ideally, changes like
this should happen organically over time and a small volunteer-run
project maintained by 4–5 people shouldn&amp;rsquo;t be publicly criticized by
&amp;ldquo;public figures&amp;rdquo;. 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
most of the deployment and &amp;ldquo;hooking&amp;rdquo; work there but now there is a nice
reproducibility dashboard.&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 all of the
infrastructure and maintains the BuildStream (and related tooling), most
of the general maintenance of the SDK itself has been handled by about
3–4 volunteers (including me) over the past few years. One of those
maintainers unfortunately became inactive last year, and since then I&amp;rsquo;ve
again been handling a large portion of the general maintenance on my
own. This includes working on several Freedesktop SDK–related projects,
such as the mesa-git extension, the freedesktop-sdk docker images,
the binary seed, and various other bits of tooling. Most of it is
generally uninteresting but tedious work like fixing builds, backporting
patches (security patches), fixing CI, deciding on ABI breaks and
freezes. Sometimes I end up having to fix some Buildstream plugin as
well. I also developed a couple of tooling to help me with automating
some of this which lives in the freedesktop-sdk-utils and the main
freedesktop-sdk repo. One particularly large change that happened last
year was the license work. Among the SDK maintainers it was generally
known that we weren&amp;rsquo;t installing license files for built modules.
However, we weren&amp;rsquo;t really aware of the potential legal implications
(if any). The &amp;ldquo;Fedora drama&amp;rdquo; led to a number of distribution maintainers
taking a closer look at the project, and the issue of missing license
files ended up being amplified a lot. When the confidential issue was
opened about it, there was a sense of urgency around addressing it. At
the time I wasn&amp;rsquo;t aware that This was a direct consequence of that
situation. If I had known, I probably wouldn&amp;rsquo;t 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 was happening in parallel with the upcoming 25.08
release and we even had to revive branches from two or three years ago
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. 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&amp;rsquo;ve ended up maintaining most of the generators there.
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.&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’ve been following their music, solo
releases and the pinks on their socials. 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 and welcome to my little corner of the internet!&lt;/p&gt;
&lt;p&gt;You might know me by my online alias, &lt;em&gt;bbhtt&lt;/em&gt;, which is just a blend of
some letters of my real name, Boudhayan Bhattcharya. I live in India and
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 occasionally 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://letterboxd.com/bbhtt/films/&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;movies&lt;/a&gt;,
TV shows, and &lt;a href=&#34;https://anidb.net/user/983003&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;anime&lt;/a&gt;, and I&amp;rsquo;m always
listening to &lt;a href=&#34;https://open.spotify.com/user/m18qz71984e1gjbkfbd36zwmi&#34;target=&#34;_blank&#34; rel=&#34;noopener noreferrer&#34;&gt;music&lt;/a&gt;.
Although, most of the time, I&amp;rsquo;m lost in some random YouTube binge.&lt;/p&gt;
&lt;p&gt;I also try to read 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 sometimes I 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;Unless otherwise stated, all textual 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>