The intersection of open source development and artificial intelligence (AI) is currently a minefield of valid excitement and legitimate anxiety.
Recently, the Fedora Project introduced the Fedora AI-Assisted Contributions Policy.
The full policy text outlines the basic ground rules.
I was informally involved in the drafting process.
Since its rollout, I am actively adjusting my own workflow to comply with its requirements.
For those outside the Fedora ecosystem, the policy establishes basic ground rules for how AI can be used in the project.
It operates on three main pillars:
Accountability:
You can use AI, but you own the output.
The human contributor is always the author and fully accountable for the submission’s quality, license compliance, and utility.
Transparency:
If a significant part of a contribution is taken unchanged from an AI tool, you must disclose it (typically via an Assisted-by: commit trailer).
Evaluation Limits:
AI cannot act as the final judge on substantive contributions or evaluate a person’s standing within the community.
As someone who relies on these tools, I want to share my perspective on why this policy matters, the harsh realities of enforcing it, and why we must tactically embrace AI to protect the future of software freedom.
The "Accountability" Reality and the Threat of "Slop"
On paper, the Accountability clause looks like a strong deterrent against low-quality, automated spam.
In reality, it functions primarily as a legal liability shield.
If a contributor breaks a system by submitting AI-generated falsehoods, the policy simply puts the fault at their feet.
It does not, however, stop the spam.
We saw this clearly during a recent round of the Outreachy internship program.
We had a record number of contributions recorded, but very few were actually merged.
The volume of noise and sloppy contributions ballooned compared to past rounds.
Many newcomers ignored the transparency mandate and flooded our git repositories with low-quality contributions.
What actually deterred this "AI slop" wasn’t the text of the policy; it was the tangible enforcement mechanism of internship eligibility.
The primary consequence of submitting AI spam isn’t legal prosecution.
It is reputational damage.
The Ethical Elephant in the Room
This brings us to the loudest objection from the open source community: the ethics of AI generation.
Many maintainers deeply feel that LLMs are fundamentally engaged in theft.
Maintainers recognize that the companies behind the LLMs extracted immense value from 40+ years of open source material without contributing value back, bypassing licenses and author attribution entirely.
I sympathize with the maintainers who hold this objection.
It is frustrating to watch value extracted without reciprocity.
However, I do not share the same sense of existential panic as other maintainers.
My view goes that the old rules simply no longer apply.
Open source projects must evolve to survive.
Instead of playing defense and fighting a philosophical war we cannot win, we need to think about how to tactically use AI to advance the interests of software freedom in a time when it has never been more threatened.
The Fedora AI-Assisted Contributions Policy Dual Mandate
When used responsibly, AI has the potential to be a massive equalizer.
It can lower the barrier to entry for non-native English speakers drafting documentation and help junior developers navigate legacy codebases with decades or more of context.
Democratizing access is how we attract the next generation of open source contributors and strengthen the social fabric of our community.
This includes Fedora!
But there is a dark side to this democratization.
Dumping a massive volume of low-effort, AI-facilitated contributions onto the laps of Fedora maintainers is a recipe for disaster.
Many Fedora contributors are already stretched thin, doing more than is required of them.
Forcing them to review a tidal wave of "AI slop" breeds deep resentment; to them, it feels like the active "enshittification" of our own community.
This is why we cannot focus solely on the people side of AI inclusion.
We must carefully balance it by providing maintainers with the resources, support, and AI-facilitated tooling they need to survive.
Practical improvements need deeper research and evaluation, such as using AI for advanced automated testing, scaling review workflows, and complex code refactoring.
We should use AI to improve the quality and efficiency of our community’s work, ensuring that the same technology that lowers the barrier to entry also helps maintainers manage the gates.
If we handle this correctly, AI won’t replace the community.
It will empower a more inclusive, diverse, and heavily-fortified one.
The Fedora AI-Assisted Contributions Policy is our first step.
Review the official Fedora Project policy to see the framework in action.
Let’s keep the process open, keep the declarations honest, and tactically build the future of open source together.
During my work on the RISC-V 64-bit architecture port of Fedora, I created
several pull requests to Fedora packages. And some were stalled…
Non-responsive maintainer process
Fedora project has a process called ‘non-responsive maintainer’.
You check is maintainer on vacation, check latest activity and open a bug asking
for action.
The problem was that it linked to fedora_active_user.py script
which does not work since Fedora 41. During cycle of that release the
python-fedora package got retired and no one updated the script.
Let me look
As my actions brought some complains (and some discussions) I decided to take a
look at the script and make it work with current Fedora releases. Created pull
request, mailed original author etc.
There was no answer of any kind so I decided to take over maintaining the
script. Rewrote it to be Python 3 only, moved from urllib to requests,
refactored some repeated code into functions etc.
Then started checking service by service how to get things working better.
Turned out that script had several assumptions which not always apply.
FAS has separate email for Bugzilla
Fedora Accounts Service (FAS) has a separate field for the Bugzilla email. I did
not had to look for testing accounts for this because that’s my case — I use
‘short’ Red Hat email in Bugzilla due to Single Sign-On (SSO) service we use and
my ‘long’ one for the rest. So fedora-active-user script grabs user
information from FAS and checks for separate Bugzilla email and use it if present.
FAS query requires Kerberos
To query FAS you need Kerberos ticket. Both urllib and requests packages
have a way to use it for authentication — one extra package is needed to make
it work.
Lack of valid ticket is caught and info is provided to the user.
Bugzilla is tricky
Querying Bugzilla service is the trickiest part. You can request data but there
is no warranty that you get the latest one. Sure, there is the ‘order’ field for
a query but it feels like a mere suggestion. It is nothing strange to get 2008
entries next to 2023 ones.
Wanna help?
For now, I am hosting
fedora-active-user on GitHub. Will
move it to Fedora Forge later this year. Feel free to open issues, send pull
requests if you have suggestions or changes.
Current version is not the best one. It is a bit better than it was two weeks ago.
At the moment package is present in Fedora rawhide. I am waiting for branches
for stable releases and updates will follow.
Example output
$ fedora-active-user --user hrw
Last action on koji:
2026-05-04 built fedora-active-user-26.05.04-1.fc45
2024-09-12 built python-system-calls-6.11.0-1.fc42
2024-01-08 built python-system-calls-6.7.0-1.fc40
2023-09-18 built python-system-calls-6.6.0-1.fc40
2023-05-08 built python-system-calls-6.4.0-2.fc39
2022-08-06 built python-system-calls-5.19.0-2.fc37
2022-07-25 built python-system-calls-5.19.0-1.fc36
2022-07-25 built python-system-calls-5.19.0-1.fc37
2022-01-10 built python-system-calls-5.16.2-1.fc36
2021-11-15 built python-system-calls-5.16.0-1.fc35
Last package updates on bodhi:
2026-05-04 fedora-active-user-26.05.04-1.fc45
2024-09-12 python-system-calls-6.11.0-1.fc42
2024-01-08 python-system-calls-6.7.0-1.fc40
2023-09-18 python-system-calls-6.6.0-1.fc40
2023-05-08 python-system-calls-6.4.0-2.fc39
2022-08-06 python-system-calls-5.19.0-2.fc37
2022-07-25 python-system-calls-5.19.0-1.fc36
2022-07-25 python-system-calls-5.19.0-1.fc37
2022-01-10 python-system-calls-5.16.2-1.fc36
2021-11-15 python-system-calls-5.16.0-1.fc35
2021-11-15 python-system-calls-5.16.0-1.fc36
2021-09-21 python-system-calls-5.15.5-1.fc36
Last actions performed according to fedmsg:
2026-05-04 hrw commented on the pull-request rpms/prusa-slicer#67
2026-05-04 hrw's Badges rank changed from 272 to 260
2026-05-04 hrw was awarded the badge `Missed the Train`
2026-05-04 hrw commented on update fedora-active-user-26.05.04-1.fc45 (karma: 0)
2026-05-04 fedora-active-user-26.05.04-1.fc45 was tagged into f45 by bodhi
2026-05-04 fedora-active-user-26.05.04-1.fc45 was untagged from f45-updates-candid
2026-05-04 hrw's fedora-active-user-26.05.04-1.fc45 bodhi update has met stable te
2026-05-04 fedora-active-user-26.05.04-1.fc45 was untagged from f45-updates-testin
2026-05-04 fedora-active-user-26.05.04-1.fc45 was tagged into f45-updates-testing-
2026-05-04 fedora-active-user-26.05.04-1.fc45 was untagged from f45-signing-pendin
Last emails on Fedora mailing lists:
2026-04-29 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
2026-04-17 mjuszkiewicz@redhat.com as Marcin Juszkiewicz mailed devel@lists.fedora
Bugzilla activity (may not be the latest):
No activity found on Bugzilla
Looks like I still need to work on querying Bugzilla ;D
Last week in Rijeka we held Science festival 2015. This is the (hopefully not unlucky) 13th instance of the festival that started in 2003. Popular science events were organized in 18 cities in Croatia.
I was invited to give a popular lecture at the University departments open day, which is a part of the festival. This is the second time in a row that I got invited to give popular lecture at the open day. In 2014 I talked about The Perfect Storm in information technology caused by the fall of economy during 2008-2012 Great Recession and the simultaneous rise of low-cost, high-value open-source solutions. Open source completely changed the landscape of information technology in just a few years.
In 2012 University of Rijeka became NVIDIAGPU Education Center (back then it was called CUDA Teaching Center). For non-techies: NVIDIA is a company producing graphical processors (GPUs), the computer chips that draw 3D graphics in games and the effects in modern movies. In the last couple of years, NVIDIA and other manufacturers allowed the usage of GPUs for general computations, so one can use them to do really fast multiplication of large matrices, finding paths in graphs, and other mathematical operations.
Viewpoints are not detailed reviews of the topic, but instead, present the author's view on the state-of-the-art of a particular field.
The first of two articles stands for open source and open data. The article describes Quantum Chemical Program Exchange (QCPE), which was used in the 1980s and 1990s for the exchange of quantum chemistry codes between researchers and is roughly equivalent to the modern-day GitHub. The second of two articles questions the open-source software development practice, advocating the usage and development of proprietary software. I will dissect and counter some of the key points from the second article below.
But there is a story from the workshop which somehow remained untold, and I wanted to tell it at some point. One of the attendants, Valérie Vaissier, told me how she used proprietary quantum chemistry software during her Ph.D.; if I recall correctly, it was Gaussian. Eventually, she decided to learn CP2K and made the switch. She liked CP2K better than the proprietary software package because it is available free of charge, the reported bugs get fixed quicker, and the group of developers behind it is very enthusiastic about their work and open to outsiders who want to join the development.
Over the last few years, AMD has slowly been walking the path towards having fully opensourcedrivers on Linux. AMD did not walk alone, they got help from RedHat, SUSE, and probably others. Phoronix also mentions PathScale, but I have been told on Freenode channel #radeon this is not the case and found no trace of their involvement.
AMD finally publically unveiled the GPUOpen initiative on the 15th of December 2015. The story was covered on AnandTech, Maximum PC, Ars Technica, Softpedia, and others. For the open-source community that follows the development of Linux graphics and computing stack, this announcement comes as hardly surprising: Alex Deucher and Jammy Zhou presented plans regarding amdgpu on XDC2015 in September 2015. Regardless, public announcement in mainstream media proves that AMD is serious about GPUOpen.
I believe GPUOpen is the best chance we will get in this decade to open up the driver and software stacks in the graphics and computing industry. I will outline the reasons for my optimism below. As for the history behind open-source drivers for ATi/AMD GPUs, I suggest the well-written reminiscence on Phoronix.
Even though the open sourcing of a bunch of their software is a very nice move from Microsoft, I am still not convinced that they have changed to the core. I am sure there are parts of the company who believe that free and open source is the way to go, but it still looks like a change just on the periphery.
All the projects they have open-sourced so far are not the core of their business. Their latest version of Windows is no more friendly to alternative operating systems than any version of Windows before it, and one could argue it is even less friendly due to more Secure Boot restrictions. Using Office still basically requires you to use Microsoft's formats and, in turn, accept their vendor lock-in.
Put simply, I think all the projects Microsoft has opened up so far are a nice start, but they still have a long way to go to gain respect from the open-source community. What follows are three steps Microsoft could take in that direction.
In June 2014, Elon Musk opened up all Tesla patents. In a blog post announcing this, he wrote that patents "serve merely to stifle progress, entrench the positions of giant corporations and enrich those in the legal profession, rather than the actual inventors." In other words, he joined those who believe that free knowledge is the prerequisite for a great society -- that it is the vibrancy of the educated masses that can make us capable of handling the strange problems our world is made of.
The movements that promote and cultivate this vibrancy are probably most frequently associated with terms "Open access" and "open source". In order to learn more about them, we Q&A-ed VedranMiletić, the Rocker of Science -- researcher, developer and teacher, currently working in computational chemistry, and a free and open source software contributor and activist. You can read more of his thoughts on free software and related themes on his great blog, NudgedElasticBand. We hope you will join him, us, and Elon Musk in promoting free knowledge, cooperation and education.
Today I vaguely remembered there was one occasion in 2006 or 2007 when some guy from the academia doing something with Java and Unicode posted on some mailing list related to the free and open-source software about a tool he was developing. What made it interesting was that the tool was open source, and he filed a patent on the algorithm.
Hobbyists, activists, geeks, designers, engineers, etc have always tinkered with technologies for their purposes (in early personal computing, for example). And social activists have long advocated the power of giving tools to people. An open hardware movement driven by these restless innovators is creating ingenious versions of all sorts of technologies, and freely sharing the know-how through the Internet and more recently through social media. Open-source software and more recently hardware is also encroaching upon centers of manufacturing and can empower serious business opportunities and projects.
The free software movement is cited as both an inspiration and a model for open hardware. Free software practices have transformed our culture by making it easier for people to become involved in producing things from magazines to music, movies to games, communities to services. With advances in digital fabrication making it easier to manipulate materials, some now anticipate an analogous opening up of manufacturing to mass participation.
You seem to be using Sphinx for your teaching materials, right? As far as I can see, it doesn't have an online WYSIWYG editor. I would be interested in comparison of your solution with e.g. MediaWiki.
While the advantages and the disadvantages of static site generators, when compared to content management systems, have been written about and discussed already, I will outline our reasons for the choice of Sphinx below. Many of the points have probably already been presented elsewhere.
The last day of July happened to be the day that Domagoj Margan, a former student teaching assistant and a great friend of mine, set up his own DigitalOceandroplet running a web server and serving his professional website on his own domain domargan.net. For a few years, I was helping him by providing space on the server I owned and maintained, and I was always glad to do so. Let me explain why.
A mirror is a local copy of a website that's used to speed up access for the users residing in the area geographically close to it and reduce the load on the original website. Content distribution networks (CDNs), which are a newer concept and perhaps more familiar to younger readers, serve the same purpose, but do it in a way that's transparent to the user; when using a mirror, the user will see explicitly which mirror is being used because the domain will be different from the original website, while, in case of CDNs, the domain will remain the same, and the DNS resolution (which is invisible to the user) will select a different server.
Free and open-source software was distributed via (FTP) mirrors, usually residing in the universities, basically since its inception. The story of Linux mentions a directory on ftp.funet.fi (FUNET is the Finnish University and Research Network) where Linus Torvalds uploaded the sources, which was soon after mirrored by Ted Ts'o on MIT's FTP server. The GNU Project's history contains an analogous process of making local copies of the software for faster downloading, which was especially important in the times of pre-broadband Internet, and it continues today.
Back in summer 2017. I wrote an article explaining why we used Sphinx and reStructuredText to produce teaching materials and not a wiki. In addition to recommending Sphinx as the solution to use, it was general praise for generating static HTML files from Markdown or reStructuredText.
This summer I made the conversion of teaching materials from reStructuredText to Markdown. Unfortunately, the automated conversion using Pandoc didn't quite produce the result I wanted so I ended up cooking my own Python script that converted the specific dialect of reStructuredText that was used for writing the contents of the group website and fixing a myriad of inconsistencies in the writing style that accumulated over the years.
Tough question, and the one that has been asked and answeredoverandover. The simplest answer is, of course, it depends on many factors.
As I started blogging at the end of my journey as a doctoral student, the topic of how I selected the field and ultimately decided to enroll in the postgraduate studies never really came up. In the following paragraphs, I will give a personal perspective on my Ph.D. endeavor. Just like other perspectives from doctors of not that kind, it is specific to the person in the situation, but parts of it might apply more broadly.
This month we had Alumni Meeting 2023 at the Heidelberg Institute for Theoretical Studies, or HITS for short. I was very glad to attend this whole-day event and reconnect with my former colleagues as well as researcherscurrentlyworking in the area of computational biochemistry at HITS. After all, this is the place and the institution where I worked for more than half of my time as a postdoc, where I started regularly contributing code to GROMACS molecular dynamics simulator, and published some of my best papers.
My employment as a research and teaching assistant at Faculty of Informatics and Digital Technologies (FIDIT for short), University of Rijeka (UniRi) ended last month with the expiration of the time-limited contract I had. This moment has marked almost two full years I spent in this institution and I think this is a good time to take a look back at everything that happened during that time. Inspired by therecentposts by the PI of my group, I decided to write my perspective on the time that I hope is just the beginning of my academic career.
I'm back from my vacation, so time for another weekly recap...
Vacation
Week before last I had a lovely time away in hawaii (The big island).
I saw volcanoes (we missing lava fountaining by like 15minutes), lava
tubes (really cool (literally) and dark), botanical gardens (unreal flowers),
had a dinner/sunset cruise with history and finally a sunset/stargazing
trip to the top of mona kea. Super fun! Wish I had another week there to
lounge on the beach. If you ever have a chance to go, take it!
I did look at my email and such the first day or so, but after that
I was too busy and never took my laptop out even until I got back.
Fedora 44 released!
Of course first thing monday on getting back was that we were go for
fedora 44 release tuesday!
Release went pretty smoothly overall and I hope everyone enjoys the release.
Infra freeze ends
Of course with the release on tuesday, we end our infrastructure freeze on
wed. For some reason this time we had a pretty big pile of pending pull
requests, which I attempted to merge and deploy.
The bulk of them were moving our openshift applications from deploymentconfig
(which was a openshift specific object) to deployment (which is a k8s native
object). Openshift still supports deploymentconfig, but it will go away
and it sprews deprecation notices and the sooner we get moved the better.
I ran into some problems with a few applications that had preexisting
issues in staging when I went to test there. There were also some problems
on some applications with selectors (where it chooses how to map a service
on to a deployment). In one case (fmn) the app had two builds for two
different things and one of them was a newer api version and updated
the database, but then the second one couldn't handle that. Had to update
it upstream to get the db versions to match.
Anyhow, there's only a very few left now. Looking forward to being done
paying down this tech debt. :)
scrapers
What weekly recap would be complete without some scraper news? :)
This time they started hitting cgit links on fedorapeople.org (where
contributors can have git repos). I setup anubis there which mostly
quashed them. That did break some redirects tho, so we will need
to fix that.
Scrapers have also been hitting the wiki pretty hard from time to time.
It's not easy to just put that behind anubis because it's in the base
fedoraproject.org domain and we don't want some things there behind it.
For now we just increased resources for the backend, but we will probibly
have to figure out how to setup anubis there before long.
Loadouts for Genshin Impact v0.1.16 is OUT NOW with the addition of support for recently released characters like Linnea and for recently released weapons like Golden Frostbound Oath from Genshin Impact Luna VI or v6.5 Phase 2. Take this FREE and OPEN SOURCE application for a spin using the links below to manage the custom equipment of artifacts and weapons for the playable characters.
Automated dependency updates for GI Loadouts by @renovate[bot] in #516
Resolve the SEST assets alignment issue by @gridhead in #524
Change the default artifact to None by @gridhead in #526
Update dependency pillow to v12.2.0 [SECURITY] by @renovate[bot] in #527
Update dependency pytest to v9.0.3 [SECURITY] by @renovate[bot] in #528
Resolve the DGFT assets alignment issue by @gridhead in #525
Switch packaging from PyInstaller to Nuitka by @gridhead in #518
Update GitHub workflows with Fedora Linux 43 by @gridhead in #523
Update dependency python to 3.13 || 3.14 by @renovate[bot] in #529
Update dependency nuitka to v4 by @renovate[bot] in #530
Automated dependency updates for GI Loadouts by @renovate[bot] in #517
Introduce the recently added weapon Golden Frostbound Oath by @gridhead in #533
Introduce the recently added character Linnea to the roster by @gridhead in #532
Document the evolving Windows SmartScreen errors by @gridhead in #541
Stage the release v0.1.16 for Genshin Impact Luna VI (v6.5 Phase 2) by @gridhead in #542
Automated dependency updates for GI Loadouts by @renovate[bot] in #534
Characters
One character has debuted in this version release.
Linnea
Linnea is a bow-wielding Geo character of five-star quality.
Linnea - Workspace and Results
Weapons
One weapon has debuted in this version release.
Golden Frostbound Oath - Workspace
Appeal
While allowing you to experiment with various builds and share them for later, Loadouts for Genshin Impact lets you take calculated risks by showing you the potential of your characters with certain artifacts and weapons equipped that you might not even own. Loadouts for Genshin Impact has been and always will be a free and open source software project, and we are committed to delivering a quality experience with every release we make.
Disclaimer
With an extensive suite of over 1558 diverse functionality tests and impeccable 100% source code coverage, we proudly invite auditors and analysts from MiHoYo and other organizations to review our free and open source codebase. This thorough transparency underscores our unwavering commitment to maintaining the fairness and integrity of the game.
The users of this ecosystem application can have complete confidence that their accounts are safe from warnings, suspensions or terminations when using this project. The ecosystem application ensures complete compliance with the terms of services and the regulations regarding third-party software established by MiHoYo for Genshin Impact.
All rights to Genshin Impact assets used in this project are reserved by MiHoYo Ltd. and Cognosphere Pte., Ltd. Other properties belong to their respective owners.
I’m taking a stab at more-frequent updates plus a structure around those. I personally hate to
“announce” things that are highly fluid / tentative because I try hard not to propagate noise, but I
think I can do better than once every 6 months.
If you’re short on time, jump to the status brief below for the 30-second version. If
you have any suggestions for how to improve this space, hit me up in Matrix or email.
Quite a few articles about AI costs getting out of control.
For something different I recommend the podcast about the origins of Rose Bikes.
Quote of the Week
What they found instead was that “who is on a team matters less than how the team members interact, structure their work, and view their contributions” (Google 2015). In other words, it all comes down to team dynamics.
GNOME is once again participating in GSoC. This year, we have 6 contributors working on adding Debug Adapter Protocol support to GJS, incorporating vocab-style puzzles into GNOME Crosswords, creating a native GTK4/Rust rewrite of the Pitivi timeline ruler, porting gitg to GTK4, implementing app uninstallation in the GNOME Shell app grid, and enabling recovery from GPU resets.
As we onboard the contributors, we will be adding them to Planet GNOME, where you can get to know them better and follow their project updates.
GSoC is a great opportunity to welcome new people into our project. Please help them get started and make them feel at home in our community!
Special thanks to our community mentors, who are donating their time and energy to help welcome and guide our new contributors: Philip Chimento, Jonathan Blandford, Yatin, Alex Băluț, Alberto Fanjul, Adrian Vovk, Jonas Ådahl, and Robert Mader.
A new upstream version of Libblockdev was released on Monday (April 27th) – 3.5.0. This release brings both new functions and a large number of bug fixes.
Btrfs plugin: recursive deletion of subvolumes and device stats
Two new functions have been added to the btrfs plugin.
bd_btrfs_delete_subvolume_recursive can be used to remove a btrfs subvolume and all its children in one call. This was prompted by an issue reported for blivet-gui requesting this feature. While we could do this manually, using the new btrfs --recursive option can noticeably speed up this operation.
bd_btrfs_device_stats can be used to get device statistics for a btrfs volume. This is equivalent to the btrfs device stats command. In the future we want to bring this functionality to UDisks and ultimately to Cockpit, which requested this feature.
Crypto plugin: open with flags
All “open” functions in the crypto plugin were extended to allow passing the activation flags to libcryptsetup. This for example allows enabling discard when opening encrypted devices. These new functions will be used in the next version of UDisks to correctly support options specified in /etc/crypttab.
NVMe plugin: listing namespaces for a controller
bd_nvme_find_namespaces_for_ctrl is a new utility function to find all namespaces associated with a given controller. This mirrors the existing bd_nvme_find_ctrls_for_ns function but performs the reverse operation.
Bug fixes
The biggest chunk of the changes in this release are various bug fixes. As described in my previous post, we started experimenting with using LLM for code review and for libblockdev the result is over a hundred issues fixed, mostly memory and resource leaks, logical issues in error paths and various issues in tests and documentation.
At the time of writing, libblockdev 3.5.0 is already available in Fedora Rawhide and Debian Unstable and on its way to Fedora 44. The latest builds for testing and bleeding-edge enthusiasts can be always found in our Copr repository.
I read more in this stretch than made it into this post. As I sorted it, I realized the leftovers would turn into snark about Kash Patel, a pointer to the Sam Altman bio/promo piece, or an essay about Sugey Amaya as a case study in systems gone bad. You don’t need me for that.
Instead, here are some pieces on the Czech Republic, technology, being American, and more.
Disclaimer: I work at Microsoft on upstream Linux in Azure. These are my personal notes and opinions.
The way Europe considers poverty is refreshing. There is a concept called ‘social deprivation’ that measures whether individuals and families can participate in society. The score is based on the ability to do things like afford a week’s vacation away from home. The NGO in this article built a “‘minimum decent wage’ for full-time work in the Czech Republic, [which is] enough to cover the needs of an adult with a child, leisure time and some savings.” This calculation came out to CZK 48,336 per month and compares very favorably to the average gross wage of 49,215 per month. On the face of it this is great. However, the median wage was only 45,523 and the statutory minimum is 20,000. There is still work to do.
When I first moved to the Czech Republic, I noticed that business names were often ‘odd.’ It is common to see the legal name of a business printed in small print on a receipt or even on the window or front door of the shop. Many were just names and some seemed completely unrelated to the store I was in. As I understand it, the names are a vestige of the way non-corporations are organized here. Briefly, you have to “wear your own skin” into the market place. So if you are forming a single-person entity (self-employment and the like) your name is the name of the entity. Getting a DBA (Doing Business As) doesn’t remove your name from the business, instead it just tacks on more words.
But the unrelated names had a much more interesting backstory. It was, as I understood it, common to start a business by buying an existing one. This was done because the established business had a track record with all the banks and government ministries. It was already registered and on the books. You didn’t have to fight the red tape, you just assumed the work of someone who had already done it. It also meant that your restaurant might be called, “Alpha Shoes” (a fictitious example). Thankfully the red tape has lessened and I understand this practice has died out.
All of this is to say that I don’t plan to buy my AI inferencing from a shoe company.
all three of the remaining Brno K2 cars (including the retro car and Party Šalina) in operation on the Červinkova–Česká–Maloměřický most route. The program will culminate with a convoy of all three cars through the city centre, with a photoshoot on namesti Svobody at 5pm.
Sadly the Party Tram is no more, but we still have the Cafe Tram!
I understand why the word ‘lazy’ is used here. But we are not doing ourselves any favors by redefining words away from their connotative meanings to prove points. The primary officially stated reason we had to invent ‘open source’ was because ‘free software’ is a language conflict that gives us the even more tortured ‘FLOSS.’ Let’s do ourselves favors and be direct. The criticism of unchecked LLM software bloat is valid. Don’t hide that great point behind something most people don’t want to be called.
The harness is what you add to the agent. The AGENTS.md files. The skills. The custom MCP tools. The hand-crafted linters. The system prompts. The recipes and subrecipes. The extension configurations. The provider choices. The permission policies.
I loved this definition of harness. It fits so well what most people are trying to do in their workflows, just like we do with our operating systems and desktops. I find it highly ironic that it comes out via a write up on a project dedicated to building … agents and harness frames.
Claude 4.6 had a section specifically clarifying that “Donald Trump is the current president of the United States and was inaugurated on January 20, 2025”, because without that the model’s knowledge cut-off date combined with its previous knowledge that Trump falsely claimed to win the 2020 election meant it would deny he was the president. That language is gone for 4.7, reflecting the model’s new reliable knowledge cut-off date of January 2026.
Claude avoids saying “genuinely”, “honestly”, or “straightforward”.
In the context of our current world, somehow these things feel right and wrong at the same time.
I recently had to use Gnome after a long time away and I couldn’t put my finger on why I didn’t like it. I remembered happily using it for years and now it was a mess. This essay did a really good job of putting my thoughts into words. As a bonus, his screenshots include files named ‘farts’ which is my go to placeholder and the bemusing “[m]aybe someday our children will live in a post-files world, but that is not our reality.”
The title of the book is Everything But The Burden, as in, non-black people want to take everything from us except the weight of our history.
I occasionally watch an African American content creator on Instagram (@bmotheprince - I don’t know how to link to Instagram and I use someone else’s account so … get off my lawn! :P). His humor is mostly about the generational divide in the US, but it is an occasional window into African American culture. I also periodically listen to F.D Signifier for US cultural deep dives and … again … insights into African American culture. So I was drawn to this article about ‘unc’ which I had derived a definition for from the way these two men use it. I am glad to say I was mostly right. That said, damn that book title hits hard.
This article set me off so badly I debated penning an angry letter to the editor, but had a coffee instead. They profiled three people: a woman who relocated to Tbilisi, which on the face of it is an interesting choice until you realize she is actually from there and had immigrated to America; a digital nomad trying to skip around the world and go through spend/save cycles in different economies; and a man who moved to Mexico with literally no plan and wound up teaching English online and writing for a content mill. He has since returned home broke with the intention of pivoting into insurance.
Only one of these people is even trying to save money. Other than the guy who never found a career path, none seem particularly focused on integrating with where they live and are instead focused on having a luxury lifestyle. The article jumps straight into the idea that they are avoiding US income tax, which not every article needs to explain in detail, but at least don’t short-hand it, and it doesn’t acknowledge any local costs. They’ve chosen not to avail themselves of real retirement savings options or in most cases local healthcare options by refusing to be more than “just visiting.” Additionally, many digital nomads seem to believe they never have local tax obligations (they do) and while the article doesn’t confirm our digital nomad is doing that, the coda on taxation implies it in this case too.
I didn’t leave the US to achieve cheaper living costs. I also didn’t leave over politics. I have worked hard at integrating into Czech society, as much as my laziness about learning the language allows. I participate in the local tax system and the local healthcare system. My quality of life is objectively better than I enjoyed in the US, and I am currently, as I was previously, in tech and earn well. Not every American abroad wants to go back to the US, and the US systems that make that hard are failing Americans who didn’t leave, not solely Americans who did. I am trying hard not to write an essay here and instead focus on my coffee.
Thankfully our household doesn’t get sick too often, but I can promise you I always have to Google, ‘what is Paracetamol’ and ‘what is normal human body temperature in Celsius.’
We could do slow news again. I found this article via a game of Bracket City and it reminded me why I try not to read headlines too frequently. News needs more time to develop and marinate than the 24-second cycle gives us. I used to subscribe to The Week, which publishes a roundup of major events after they have had time to gel. Having a child has made time more precious so I let my subscription lapse, but I still recommend the format if you want your life back from the news cycle.
They don’t produce many articles, which is actually great because what they write is long and goes deeper into a topic than most people would desire, but I strongly recommend putting Low Tech Magazine into your RSS reader. This article was one I thought would be a dud, but it turns out that hand carts are way more interesting than I ever imagined. Did you know they had sails …
My score: 2 out of 8. I mostly got the wrong definition for these British insults. According to the test, I am a plonker. That’ll be “Unc Plonker” to you.
We are happy to announce the general availability of Fedora Asahi Remix 44. This release brings Fedora Linux 44 to Apple Silicon Macs.
Fedora Asahi Remix is developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project. This release incorporates all of the exciting improvements brought by Fedora Linux 44. Fedora Asahi Remix 44 also retires our vendored Mesa and virglrenderer packages. Users who have not already manually done so will be automatically transitioned to the upstream Mesa and virglrenderer packages provided by the upstream Fedora repositories.
Fedora Asahi Remix offers KDE Plasma 6.6 as our flagship desktop experience, with all of the new and exciting features brought by Fedora KDE Plasma Desktop 44. Plasma Setup replaces the previous Calamares-based setup wizard, providing a Plasma-native experience for user account creation and system setup. Additionally, Plasma Login Manager is now the default greeter and session manager, replacing SDDM. This applies to new installs only; users upgrading from previous versions of Fedora Asahi Remix will not have their configuration changed.
A GNOME variant is also available, featuring GNOME 50, with both desktop variants matching what Fedora Linux offers. Fedora Asahi Remix also provides a Fedora Server variant for server workloads and other types of headless deployments. Finally, we offer a Minimal image for users that wish to build their own experience from the ground up.
You can install Fedora Asahi Remix today by following our installation guide. Existing systems running Fedora Asahi Remix 42 or 43 can be updated following the usual Fedora upgrade process. Upgrades via GNOME’s Software application are unfortunately not supported; either KDE’s Plasma Discover or DNF’s System Upgrade command must be used.
Fedora has released Fedora KDE Plasma Desktop Edition 44 to the public.
The Fedora KDE Plasma Desktop Edition is suitable for many needs. It combines the reliable and trusted Fedora Linux base with the KDE Plasma Desktop environment. It provides a selection of KDE applications that are simple by default, but powerful when needed.
KDE Plasma 6.6
The KDE community makes your life easier with the latest release of KDE Plasma. It builds upon the foundations of Plasma 6 to provide a seamless, friendly, and familiar experience.
Fedora KDE 44 ships with Plasma 6.6.4 featuring:
Custom global theme creation by saving the current theme setup
More options for using color accent in windows with tint intensity for window frames
Support for connecting to Wi-Fi networks by scanning QR codes
Per-application volume adjustment from the task manager
New grayscale filter for colorblindness correction
New screen magnifier feature that tracks the mouse pointer
New “Slow keys” and “reduced motion” settings
Spectacle can do OCR scanning of images to capture text
Per-window filter from screencast through the menu in the title bar
Beyond just the updates included in KDE Plasma 6.6, there are some major new features with Fedora KDE on Fedora Linux 44.
Fresh installations now use the brand-new Plasma Setup and Plasma Login Manager. These provide a more cohesive and integrated experience from the moment the computer is powered on the first time. The installation process has been simplified. It now enables you to easily set up a computer with Fedora KDE Plasma Desktop for a friend or a loved one.
The on-screen keyboard uses the new Plasma Keyboard, providing a fresh and future-forward implementation for keyboard input.
Fedora Linux 44 general updates
Some broader changes in Fedora Linux also directly impact Fedora KDE Plasma Desktop Edition, notably:
PackageKit now uses version 5 of the DNF package manager as the backend.
Support for select Qualcomm-based laptops.
The /etc/pki/tls/cert.pem file no longer exists by default. This may impact some programs that expect this file to provide system CA certificates instead of leveraging behaviors built into cryptographic security libraries to offer this information.
Fedora Ready is ready for Fedora KDE
The Fedora KDE Plasma Desktop 44 edition is fully supported within the Fedora Ready program. Fedora KDE is actively engaging with hardware vendors to support Fedora KDE Plasma Desktop on their devices.
We are pleased to announce that Star Labs offers preinstalled Fedora KDE Plasma Desktop as an option for their portfolio of devices. As makers of computers with an open source ethos embedded into the core of their products with even open source firmware powered by Coreboot, they share many of the same principles the Fedora community values. This is a very exciting moment for Fedora KDE and we look forward to deepening our collaboration with Fedora Ready participants and extending to other vendors. If you are a vendor potentially interested in Fedora Ready, please reach out!
I’m happy to announce that we have sealed bootable container images ready for testing for the Fedora Atomic Desktops!
What are sealed bootable container images?
Sealed bootable container images include all the components needed to create a fully verified boot chain, from the firmware to the operating system composefs image. This relies on Secure Boot and thus only supports system booting with UEFI on x86_64 & aarch64.
The components are:
systemd-boot as bootloader
a Unified Kernel Image (UKI) which includes the Linux kernel, an initrd and the kernel command line
a composefs repository with fs-verity enabled. This is managed by bootc.
Both systemd-boot and the UKI are signed for Secure Boot. The images are test images so the components are not signed with the official keys from Fedora.
The main direct benefit that we will get from this support is that we will be able to enable passwordless disk unlocking using the TPM in a way that will be reasonably secure by default.
We welcome testing and feedback! Please see the list of known issues and report new issue at github.com/travier/fedora-atomic-desktops-sealed. We’ll redirect them as needed to the right upstream projects.
Beware, those are testing images. The root account does not have a password set and sshd is enabled, by default, to make debugging easier. The UKI and systemd-boot are signed for Secure Boot but, since those are test images, they are not signed with the official keys from Fedora. Don’t use those images in production.
Where can I get more details about how this works?
If you want to know more about how sealed images work (i.e. how we make bootable containers, UKI and composefs work together to create a verified boot chain), see the following presentations and documentation:
Fedora Linux 44 has been released! So, let’s see what is included in this new release for the Fedora Atomic Desktop variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
Changes for all Atomic Desktops
Issue tracker moved to the new Fedora forge
We have moved the cross-variants issue tracker to the new Fedora forge. This is the best place to file issues that impacts all variants or to coordinate work between all of them. If you have issues specific to a given desktop environment then we usually prefer to track them in each respective SIG trackers. These are available on the README for the atomic-desktops organization.
Unified documentation, hosted on the new forge
The unified documentation for all Atomic Desktops is finally live! Unfortunately the translations have not been migrated so we will need help to re-translate everything again, once the translation setup is ready with the new forge. It should be mostly copy/paste from the previous docs and this time we will only have to translate the docs once and not for every (new) variant.
Some AppImages are still using an old AppImage runtime that relies on FUSE 2 libraries being available on the host. See the Discussion thread for examples on how to check the runtime of an AppImage.
If some of your AppImages do not work on Fedora Atomic Desktops 44, we recommend:
Looking for a Flatpak for the application and giving it another try. Consider helping upstream package their application as a Flatpak.
Reporting the issue upstream so that they are aware that they should use a newer runtime. Consider helping upstream with this as well.
EncFS or CryFS backends for Plasma Vaults are removed
KDE upstream no longer recommends using the EncFS nor CryFS backends for Plasma Vaults, notably because they rely on the FUSE 2 libraries. If you are using one of those backends, you should migrate your data to a new vault using the only maintained backend (gocryptfs). Ideally this should occur before the update to Fedora Linux 44. If you have already updated to Fedora Linux 44 and need access to your data, you can layer the needed packages (cryfs or fuse-encfs) using rpm-ostree install <package>, then migrate your data and finally reset the layers with rpm-ostree reset.
Dropping compatibility for pkla Polkit rules
Support for the legacy pkla Polkit rules format has been removed. It is unlikely that you were relying on support for those rules as most of the ecosystem has moved on to the new JavaScript based format.
Unified out of the box experience with KDE Plasma Setup (OEM installation)
Thanks to the new Plasma Setup, it is now possible to install the system with Anaconda with minimal configuration and then complete the installation on the first boot by creating a new user and selecting the timezone. This is great when you want to install Fedora Kinoite on a computer and don’t want to setup a user in advance.
As always, I heavily recommend checking them out, especially if you feel like some things are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra media codec, out of tree kernel drivers, etc.).
What’s Next
Helping us with a few nasty bugs
If you have an interest in contributing to Fedora Atomic Desktops, here are some bugs that we will have to fix in the short term. We would greatly appreciate help with:
Fixing root mount options (atomic-desktops#72): This is a long standing and mostly invisible bug that impacts performance.
Moving away from nss-altfiles (atomic-desktops#108): This is another long standing source of issues that new users regularly face.
A lot of work is happening to make the transition to Bootable Containers as smooth as possible for our existing users. You can look at the road map for this transition at atomic-desktops#26.
Fedora Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. If you want to rebase to Fedora Linux 44 on your Fedora Silverblue system, this article tells you how. It not only shows you what to do, but also how to revert things if something unforeseen happens.
Update your existing system
Prior to actually doing the rebase to Fedora Linux 44, you should apply any pending updates. Enter the following in the terminal:
$ rpm-ostree update
or install updates through GNOME Software and reboot.
Note
rpm-ostree is the underlying atomic technology that all the Fedora Atomic Desktops use. The techniques described here for Silverblue will apply to all of them with proper modifications for the appropriate desktop.
Rebasing using GNOME Software
GNOME Software shows you that there is new version of Fedora Linux available on the Updates screen.
First thing to do is download the new image, so select the Download button. This will take some time. When it is done you will see that the update is ready to install.
Select the Restart & Upgrade button. This step will take only a few moments and the computer will restart when the update has completed. After the restart you will end up in a new and shiny release of Fedora Linux 44. Easy, isn’t it?
Rebasing using terminal
If you prefer to do everything in a terminal, then this part of the guide is for you.
Rebasing to Fedora Linux 44 using the terminal is easy. First, check if the 44 branch is available:
$ ostree remote refs fedora
You should see the following in the output:
fedora:fedora/44/x86_64/silverblue
If you want to pin the current deployment (meaning that this deployment will stay as an option in GRUB until you remove it), you can do this by running this command:
# 0 is entry position in rpm-ostree status $ sudo ostree admin pin 0
To remove the pinned deployment use the following command:
# 2 is entry position in rpm-ostree status $ sudo ostree admin pin --unpin 2
Next, rebase your system to the Fedora Linux 44 branch.
$ rpm-ostree rebase fedora:fedora/44/x86_64/silverblue
Finally, the last thing to do is restart your computer and boot to Fedora Linux 44.
How to roll back
If anything bad happens (for instance, if you can’t boot to Fedora Linux 44 at all) it’s easy to go back. At boot time, pick the entry in the GRUB menu for the version prior to Fedora Linux 44 and your system will start in that previous version rather than Fedora Linux 44. If you don’t see the GRUB menu, try to press ESC during boot. To make the change to the previous version permanent, use the following command:
$ rpm-ostree rollback
That’s it. Now you know how to rebase Fedora Silverblue to Fedora Linux 44 and roll back. So why not do it today?
FAQ
Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.
Question: Can I skip versions during a rebase of Fedora Linux? For example from Fedora Silverblue 41 to Fedora Silverblue 44?
Answer: Although it could sometimes be possible to skip versions during rebase, it is not recommended. You should always update to one version prior (41->42->43->44 for example) to avoid unnecessary errors.
Question: I have rpm-fusion layered and I get errors during rebase. How should I do the rebase?
Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:
After doing this you can follow the guide in this blog post.
Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?
Yes, you can follow the Rebasing using the terminal part of this guide for every Fedora Atomic Desktop. Just use the corresponding branch. For example, for Kinoite use fedora:fedora/44/x86_64/kinoite
This article highlights a few noteworthy changes in the latest release of Fedora Workstation that we think you will love. Upgrade today from the official website, or upgrade your existing install using GNOME Software or through the terminal with dnf system-upgrade.
GNOME 50
Fedora Linux 44 Workstation ships with the latest GNOME release, GNOME 50. This comes with a long list of refinements to your desktop, including everything from accessibility, to color management and remote desktop.
As part of the Digital Wellbeing initiative, new native Parental Controls let you set screen time limits and bedtimes directly from Settings.
Many of the applications that are installed by default on the Fedora Workstation have also seen improvements, from the Document Viewer to the File Manager and the Calendar.
To learn more about these and other changes, you can read the GNOME 50 release notes.
I’m excited to announce that Fedora Linux 44 is here! Keep reading to discover highlights of Fedora Linux 44, or if you are ready, just jump right in and give Fedora Linux 44 a try!
Thanks to everyone who helped!
Thank you and congrats to everyone who has contributed to this release. And thanks to everyone who showed up for the virtual release party last Friday. We celebrated a little early this year, just after the go/no-go meeting made the release official. If you weren’t able to join us live, you can watch the recording and hear about some of the great work from the contributors involved.
Looking to upgrade?
If you have an existing system, Upgrading Fedora Linux to a New Release is easy. In most cases, it’s not very different from just rebooting for regular updates, except you’ll have a little more time to grab a coffee.
As usual with Fedora Linux, there are just too many individual changes and improvements to go over in detail. You’ll want to take a look at the release notes for that.
Notable User Visible Changes
Anaconda
For those of you installing fresh Fedora Linux 44 Spins, you may notice a change in how Anaconda handles network devices. Anaconda now only creates network profiles for devices configured during installation (by boot options, kickstart, or interactively in UI) instead of providing default profiles for all devices. This change will simplify post-installation network configuration for users who need to customize after installation.
Workstation
Fedora Linux 44 Workstation ships with the latest GNOME release, GNOME 50. This comes with a long list of refinements to your desktop, including everything from accessibility to color management and remote desktop. Many of the applications that are installed by default on Fedora Workstation have also seen improvements, from Document Viewer to File Manager and Calendar. To learn more about these and other changes, you can read the GNOME 50 release notes.
KDE Plasma Desktop
KDE Plasma Desktop: If you are a KDE user, you should also notice a couple of very obvious changes. Fedora KDE Plasma Desktop 44 is based on the latest Plasma 6.6, which includes the new Plasma Login Manager and Plasma Setup to provide a more cohesive and integrated experience from the moment the computer is powered on for the first time. The installation process has been simplified, enabling you to easily set up Fedora KDE Plasma Desktop for a computer for a friend or a loved one.
Plumbing Upgrades
Beyond the user-visible changes, there are some important plumbing changes user should be aware of.
OpenSSL Cert File Handling Improvements
The loading time of OpenSSL has been improved by making use of directory-hash support for ca-certificates. This improvement required changes to where some certificate bundles are stored on the filesystem. You can read the specific Change details for more information.
The MariaDB default version is now 11.8
MariaDB packages use a versioned package layout, which allows Fedora to deliver both, mariadb-10.11 and mariadb-11.8 for users. The “distribution default” unversioned MariaDB packages now install the 11.8 versions in Fedora Linux 44. User doing upgrades to Fedora Linux 44 won’t notice the change in the default. For new users installing MariaDB for the first time, unless you specify the version, you’ll now get 11.8 by default.
Wine NTSYNC
The NTSYNC kernel module is enabled for select packages by package recommendation (notably Wine and Steam), which can improve compatibility and performance when running Windows applications (especially games). When packages that recommend the wine-ntsync package are installed, the package recommendation ensures NTSYNC is configured automatically on subsequent boots, so that users don’t have to manually enable NTSYNC.
Fedora Cloud boot partition using Btrfs
The /boot partition has been replaced with a Btrfs subvolume for Fedora Cloud images that support it. This results in better space utilization and smaller images.
If you hit a snag
If you run into a problem, visit our Ask Fedora user support forum. This forum includes a category where we collect common issues and solutions or work-arounds.
Just drop by and say “hello”
Drop by our “virtual watercooler” on Fedora Discussion and join a conversation, share something interesting, and introduce yourself. We’re always glad to see new people!
Although OpenSSL 4.0 released just two weeks ago, the syslog-ng project has already received a GitHub issue complaining that we do not support it. So, before we would allocate too much effort on it: what should we expect?
This raises the question that if it is not an LTS release, then can we stay on version 3.x and skip 4.x altogether? When will Linux distributions start using it?
Looking at Repology, there are already a few places where OpenSSL 4.0 is available. This includes Gentoo, the community where the GitHub issue originated from, and also various FreeBSD ports. The current list is available at: https://repology.org/project/openssl/versions
Fedora is planning to use OpenSSL 4.0 as default starting from the next release: https://fedoraproject.org/wiki/Changes/OpenSSL40 However, OpenSSL 3.x will most likely stay supported for backwards compatibility.
I am also curious if there are any other projects which have added support for OpenSSL 4.0. If so, then what are your experiences? Was porting your code to use OpenSSL 4.0 difficult?
I am all in for supporting the latest technologies, but currently, even if we have an open request for OpenSSL 4.0 support, I do not feel that I have enough information to prioritize its development.
Smoke testing – You want to know if your system commands actually work, not just when you run them the way the docs say, but when users (or their scripts) feed them garbage.
AI is excellent at generating potential edge cases, and tracking systems are already all too eager to collect new tickets. I’m being careful not to dump every AI finding into Bugzilla; I don’t want to clutter the backlog and mainly waste developer time on theoretical bugs. Or Should I?
Plus, segfaults don’t lie – either the system crashed or it didn’t, and those are the issues that actually deserve the ticket.
Throwing Random Arguments at System Binaries Until They Crash
Script to do the work:
A pretty straightforward bash script, vibing with AI-generated chaos.
Grab all binaries from /usr/bin and /usr/sbin
Parse --help for flags (--whatever, -x, you know the drill)
Pick random combos of those flags (1-4 per run)
Feed them garbage: broken JSON/XML, binary junk, path traversal attempts, format strings, absurdly long lines
Only logs actual crashes – SIGSEGV, SIGABRT, SIGILL, SIGBUS. Exit code 1 from bad args gets ignored.
Core logic looks like this:
# Extract flags from --help
flags=$(timeout 3s "$bin" --help 2>&1 |
grep -aoE -e '--[a-zA-Z0-9_-]+' -e '-[a-zA-Z]' |
grep -avE 'help|version|usage')
# Pick random flags (1-4 of them)
chosen=$(echo "$flags" | shuf -n $((1 + RANDOM % 4)))
# Add a random test file
fuzz_file="$WORKSPACE/$(random_pick: bad.json, random.bin, longline.txt, ...)"
# Run it
timeout 5s "$bin" $chosen $fuzz_file
Script skips the obvious no go zones – package managers, rm, network tools, editors. I’m glad to see the script finish with the machine still answering.
Look, these are edge cases. Nobody’s actually running edgepaint --wtf malformed.json in prod. But segfaults are segfaults – the binary should bail with “invalid option” or “bad input”, not dump core.
Now What?
So I’ve got a pile of crashes. Some in critical components. All reproducible.
File bugs for all of them? That’s a lot of BZ tickets for “yes hm this crashes if you feed it random garbage with weird flags”. Developers have better things to do.
Ignore them? They’re real bugs. And some of these are in grub2 and perl – not exactly throwaway packages.
Fedora 44 has been released!
🎉 So let’s see what is included in this new release for the Fedora Atomic Desktops variants
(Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
We have moved the cross-variants issue tracker to the new Fedora forge.
This is the best place to file issues that impacts all variants or to coordinate work between all of them.
If you have issues specific to a given desktop environment then we usually prefer to track them in each respective SIG trackers.
They are listed on the README for the atomic-desktops organization.
Unified documentation, hosted on the new forge
The unified documentation for all Atomic Desktops is finally live!
Unfortunately the translations have not been migrated so we will need help to re-translate everything again, once the translation setup is ready with the new forge.
It should be mostly copy/paste from the previous docs and this time we will only have to translate the docs once and not for every (new) variant.
Some AppImages are still using an old AppImage runtime that relies on FUSE 2 libraries being available on the host.
See the discussion thread for examples on how to check the runtime of an AppImage.
If some of your AppImages do not work on Fedora Atomic Desktops 44, we recommend:
Looking for a Flatpak for the application and giving it another try. Consider helping upstream package their application as a Flatpak.
Reporting the issue upstream so that they are aware that they should use a newer runtime. Consider helping upstream with this as well.
EncFS or CryFS backends for Plasma Vaults are removed
KDE upstream no longer recommend using the EncFS nor CryFS backends for Plasma Vaults, notably because they rely on the FUSE 2 libraries.
If you are using one of those backends, you should migrate your data to a new Vault using the only maintained backend (gocryptfs).
Ideally this should occur before the update to Fedora 44.
If you have already updated to Fedora 44 and need access to your data, you can layer the needed packages (cryfs or fuse-encfs) using rpm-ostree install <package>, then migrate your data and finally reset the layers with rpm-ostree reset.
Dropping compatibility for pkla polkit rules
Support for the legacy pkla polkit rules format has been removed.
It is unlikely that you were relying on support for those rules as most of the ecosystem has moved on to the new Javascript based format.
Unified out of the box experience with KDE Plasma Setup (OEM installation)
Thanks to the new Plasma Setup, it is now possible to install the system with Anaconda with minimal configuration and then complete the installation on the first boot by creating a new user and selecting the timezone.
This is great when you want to install Fedora Kinoite on a computer and don’t want to setup a user in advance.
As always, I heavily recommend checking them out, especially if you feel like some things
are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra
media codec, out of tree kernel drivers, etc.).
What’s next
Helping us with a few nasty bugs
If you are interested in contributing to Fedora Atomic Desktops, here are some bugs that we will have to fix in the short term.
We would greatly appreciate help with:
Fixing root mount options (atomic-desktops#72):
This is a long standing and mostly invisible bug that impacts performance.
Moving away from nss-altfiles (atomic-desktops#108):
This is another long standing source of issues that new users regularly face.
A lot of work is happening to make the transition to Bootable Containers as smooth as possible for our existing users.
You can look at the roadmap for this transition at atomic-desktops#26.
Sealed bootable container images include all the components needed to create a fully verified boot chain, from the firmware to the operating system composefs image.
This relies on Secure Boot and thus only supports system booting with UEFI on x86_64 & aarch64.
The components are:
systemd-boot as bootloader,
a Unified Kernel Image (UKI) which includes the Linux kernel, an initrd and the kernel command line,
a composefs repository with fs-verity enabled. This is managed by bootc.
Both systemd-boot and the UKI are signed for Secure Boot.
The images are test images so the components are not signed with the official keys from Fedora.
The main direct benefit that we will get from this support is that we will be able to enable passwordless disk unlocking using the TPM in a way that will be reasonably secure by default.
We welcome testing and feedback! Please see the list of known issues and report new issue at github.com/travier/fedora-atomic-desktops-sealed.
We’ll redirect them as needed to the right upstream projects.
Beware, those are testing images. The root account does not have a password set and sshd is enabled, by default, to make debugging easier.
The UKI and systemd-boot are signed for Secure Boot but, since those are test images, they are not signed with the official keys from Fedora.
Don’t use those images in production.
Where can I get more details about how this work?
If you want to know more about how sealed images work (i.e. how we make bootable containers, UKI and composefs work together to create a verified boot chain), see the following presentations and documentation:
Some time ago I used a feature in KDE called “Run a command” when an event triggered. It triggered for me when a calendar event fired and used Piper TTS to read the event to me out loud. A small popup and a pling don’t work for me.
I tried to get the feature back into KDE, but since the merge request isn’t going anywhere and people don’t give details how to implement it correctly I wrote Sigrun now. It is named after a Norse Valkyrie and is short for Signal Run.
It is a systemd service running as a user and listening on DBus signals. Once it finds a configured one, it runs its command. The desktop doesn’t matter.
Here is the rule that reads my calendar reminders aloud via kde-tts.py:
I’ve not updated this space in quite some time as I am still discovering new opportunities and
obstacles within the problem space. Plus, my priorities tend to shift based on whomever is around
and offering to help, which is noise I try to avoid propagating.
However, I do generally try to produce weekly(-ish) status updates in the Matrix
channel, and I’ve decided to start providing something
similar here since I do see some hits against the RSS feed.
While working on the new git signing feature for
tumpa-cli I noticed that some of
the commits can not be verified. For a moment I freaked out and then thought it
must be a problem in my code. But, I could not dig enough. Opus 4.7 helped me
to find the eaxct commit in git's history and a reproducer. I reported the issue to the
maintainers
and they are working on a fix.
\xc2\xa7 aka § was the cause for me.
msg.txt body
sign stdin (tee'd)
stored commit body
verify
git 2.43 (host)
... 20 a7 0a
... 20 c2 a7 0a
... 20 c2 a7 0a
OK
git 2.53 (CI, docker)
... 20 a7 0a
... 20 a7 0a
... 20 c2 a7 0a
BAD
git 2.43 transcoded the message to UTF-8 BEFORE calling the signer;
signer and storage saw the same bytes (c2 a7). git 2.53 hands the
signer the RAW bytes (a7) and transcodes only on the way to the
commit object (c2 a7). The invariant "bytes fed to gpg.program at
sign time equal the bytes a verifier sees when it reads the commit
back" is broken.
git config i18n.commitEncoding iso-8859-1 is supposed to be the configuration
if we have non UTF-8 characters. But, I never knew about this configuration
before I found the bug.
I want to thank my friends in Anthropic for letting me use the tools and
techonology to keep building.
If you work with patches and git am, then you’re probably used to seeing patches fail to apply. For example:
$ git am CVE-2025-14512.patch
Applying: gfileattribute: Fix integer overflow calculating escaping for byte strings
error: patch failed: gio/gfileattribute.c:166
error: gio/gfileattribute.c: patch does not apply
Patch failed at 0001 gfileattribute: Fix integer overflow calculating escaping for byte strings
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
This is sad and frustrating because the entire patch has failed, and now you have to apply the entire thing manually. That is no good.
Here is the solution, which I wish I had learned long ago:
$ git config --global am.threeWay true
This enables three-way merge conflict resolution, same as if you were using git cherry-pick or git merge. For example:
$ git am CVE-2025-14512.patch
Applying: gfileattribute: Fix integer overflow calculating escaping for byte strings
Using index info to reconstruct a base tree...
M gio/gfileattribute.c
Falling back to patching base and 3-way merge...
Auto-merging gio/gfileattribute.c
CONFLICT (content): Merge conflict in gio/gfileattribute.c
error: Failed to merge in the changes.
Patch failed at 0001 gfileattribute: Fix integer overflow calculating escaping for byte strings
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Now you have merge conflicts, which you can handle as usual. This seems like a better default for pretty much everybody, so if you use git am, you should probably enable it.
I’ve no doubt that many readers will have known about this already, but it’s new to me, and it makes me happy, so I wanted to share. You’re welcome, Internet!
Motivation: dealing with multiple Toolbox containers¶
Lately, I've been getting annoyed by my current Bash prompt offering me a poor
UX when dealing with multiple Toolbox containers.
The prompt lacked crucial information: to which of the running containers a
given shell belongs to?
I did a quick search to see if there's an easy fix I'm missing out but it turned
out there is a long-standing desire to improve Toolbox's UX in this respect and
multiple approaches have been discussed/tried. Here are some relevant tickets:
Discovering the old and new version of Bash Color Prompt¶
After looking around on how to update my Bash prompt to become
"container name"-aware, I came across Fedora's shell-color-prompt package
which was conveniently just a dnf install bash-color-prompt away (strangely,
the source package is named shell-color-prompt while the binary package is
named bash-color-prompt, see also RHBZ #2291024).
My attempts at configuring the Bash prompt to be "container name"-aware with the
help of shell-color-prompt didn't look very promising.
I had a little epiphany when discovering that shell-color-prompt's maintainer,
Jens Petersen, recently wrote a replacement for it: namely Bash Color Prompt
(bcp). Jens describes it as having a cleaner declarative approach for creating
one's custom Bash prompt.
It worked and its declarative approach at creating a custom Bash prompt was
really easy to follow and tailor to my needs.
Currently, until the new version of Bash Color Prompt (bcp) is packaged in
Fedora (and other distributions), a simple way to install it is to just grab the
bash-color-prompt.sh file directly from its GitHub repository and put it
somewhere in your home directory.
Afterwards, just source and configure it in your .bashrc file. Here is how
I've done it:
# Use the new Bash Color Prompt (bcp) by Jens Petersen (Red Hat) to handle PS1.# NOTE: Temporarily, I've just copied the script from:# https://github.com/juhp/bash-color-prompt/blob/main/bash-color-prompt.shif[-f$HOME/bash-color-prompt.sh];thensource$HOME/bash-color-prompt.sh
fi# Configure bcp.
bcp_layout(){localexit_code=$1# hexagonbcp_container
# opening [bcp_append"["# user@host or user@container(host)localuser_color="green"if[[$EUID-eq0]];thenuser_color="red";filocalmachine="\h"if[-f/run/.containerenv];thencontainer_name=$(grep-oP'(?<=name=")[^"]+'/run/.containerenv)machine="$container_name(\h)"fibcp_append"\u@$machine ""$user_color;bold"bcp_title"\u@$machine:\w"# directorybcp_append"\w""blue"# git statusbcp_git_branch" ""magenta""yellow"# status indicatorif[[$exit_code-ne0]];thenbcp_append" ✘$exit_code""red;bold"fi# actual prompt charbcp_append"]\$ ""default"}# Initialize bcp.
bcp_init
This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infrastructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.
Week: 20 – 24 April 2026
Fedora Infrastructure
This team is taking care of day to day business regarding Fedora Infrastructure. It’s responsible for services running in Fedora infrastructure. Ticket tracker
[Badges/Outreachy] refactor: Extract duplicated search dropdowns and error handling into reusable components [Suggested]
[Badges/Outreachy] Refactor: Replace hardcoded email domain with config variable [Approved][Resolved]
[Badges/Outreachy] cleanup: remove dead template infrastructure from app.py[Suggested]
[Badges/Outreachy] fix: add missing session.commit() in opt_out [Approved]
[Badges/Outreachy] Add get_persons_by_nickname with pagination to TahrirDatabase [Rejected]
This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure. It’s responsible for services running in CentOS Infratrusture and CentOS Stream. CentOS ticket tracker CentOS Stream ticket tracker
This team is taking care of day to day business regarding Fedora releases. It’s responsible for releases, retirement process of packages and package builds. Ticket tracker
Fedora 44 Final release preparation
RISC-V
This is the summary of the work done regarding the RISC-V architecture in Fedora.
F44 rebuild: we’re halfway through; getting through about 300 builds/day. (NB: This is still pretty decent, given the reduced builders we have. Fedora also has a non-trivial number of ‘noarch’ packages; they can get imported into RISC-V Koji without a rebuild.)
Tried out an upcoming server hardware called SpacemiT K3. I got 24h remote access (with some limitations). Uploaded some basic data. Ran an initial benchmark of building ‘binutils’:
K3 is ~6.5x faster at compiling ‘binutils’ compared to our current build horse P550. (NB: this is not a 100% apples-to-apples comparison, as P550 is on Fedora, while the K3 is on some FrankenLinux, so the default compiler flags from the host differ.)
Started a thread with a few folks on a backup plan to improve reliability of builder hardware. Roughly: until server-grade hardware is widely accessible, see if we can get a few of the current “workhorse” (SiFive P550), and make them available somewhere so that they can be easily hooked to RISC-V Koji.
Conferences: RISC-V EU Summit schedule preparation is done.
QE
This team is taking care of quality of Fedora. Maintaining CI, organizing test days and keeping an eye on overall quality of Fedora releases.
Rmdepcheck (replacement for rpmdeplint repoclosure) improvements: swapped out the core implementation from XML parsing to clever dnf commands to make it simpler, more robust, faster, and work properly on EPEL packages/updates
Forgejo
This team is working on introduction of https://forge.fedoraproject.org to Fedora and migration of repositories from pagure.io.
[Forgejo] Participated in the Fedora Forge Sprint Planning meeting call
[Forgejo] Strategized the collaboration on the private issues feature inclusion
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for parallel installation, the perfect solution for such tests, and as base packages.
RPMs of PHP version 8.5.6RC1 are available
as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux≥ 8
as SCL in remi-test repository
RPMs of PHP version 8.4.21RC1 are available
as base packages in the remi-modular-test for Fedora 42-44 and Enterprise Linux≥ 8
as SCL in remi-test repository
ℹ️ The packages are available for x86_64 and aarch64.
ℹ️ PHP version 8.3 is now in security mode only, so no more RC will be released.
A bit of a mixed bag today. Good reads are the Agents and the Era of Overproduction and AI reshaping values at Enode blog posts.
Podcast-wise, give Driverless World and the Pedro Sánchez episode a listen.
Quote of the Week
“It’s like the free puppy,” I continue. “It’s not the upfront capital that kills you, it’s the operations and maintenance on the back end.”
Before I knew it, I found myself already at the second day of the FOSSAsia 2026 conference on 10th March 2026 after a rather eventful previous day. While I did plan to wake up a little later, I realized that I had to prepare for my presentation on the Fedora Badges Revamp Project that was scheduled later that day. This was the only proposal that got selected, and the other one on the Fedora Forgejo Migration Project did not make it, so I had to ensure that I was well prepared for this. After some rounds of talk rehearsals and some quick bites of breakfast, Samyak Jain and I exited Lumen Bangkok Udomsuk Hotel to be greeted by comparatively cooler weather on that day. Since it was more of the same choices on the breakfast menu, we were able to leave the hotel as early as 0945am Indochina Time. Climbing the long escalator to finally make it to the FOSSAsia 2026 event venue, we noticed just how much the community booth layouts had changed that day. For instance, the GNOME Foundation community booth was now positioned beside those of the Debian Project and the TeaLinuxOS Project.
Manifest #1
I had a mixed feeling about this, while this did allow for the corridor to be widened, the space for volunteer staffing at the community booths of the GNOME Foundation, Debian Project, and TeaLinuxOS Project was severely restricted. This meant that it was quite a struggle for folks who had to move away from or into the booth locations, as that required the folks around them to be moved as well. Just like the day before, we decided to assist Aaditya Singh with booth operations, all while trying to finish off the last hundred Fedora Project stickers that we had saved up from our participation at DevConf.IN 2026. While we had previously signed up for the ExpressVPN-sponsored FOSSAsia hackathon on Internet Security Development Using Artificial Intelligence, we ultimately decided to give away our designated slot to other younger participants who could not register in time. We discussed just how important this hackathon participation was for budding folks who were getting started with free and open source software, but not so much for us, since we have been around the scene for a long while now.
Manifest #2
This opened us up further for many impromptu conversations, ideation discussions, booth visits, and of course, scheduled presentations. After leaving Samyak at the hallway track, I headed into a newer arrangement of community booths in the second corridor. Since my work laptop had malfunctioning cooling, which made screeching loud noises, I had to use his laptop to deliver my presentation later that day. Not only did I ensure that I downloaded my slide deck and speaker notes onto his computing device well in advance, but I also took care to avoid display inactivity suspensions and ensure an ample laptop battery charge. After a quick round through the community booths, I headed into the hall where the ExpressVPN-sponsored FOSSAsia hackathon was taking place, purely out of curiosity. Informing one of the co-located volunteers about my involvement as a visitor and not as a participant, they allowed me into the room to chat with the fellow participants. Since the hackathon was duration gated, I took extra care to curb my nosiness and allow the teams to work their magic.
Manifest #3
Out of all the participating groups that I interacted with in the competition hall, my conversations with the likes of Saksham Sirohi and Arnav Angarkar about their ideas stayed with me. They knew how they had to limit their actual implementation and were focused on delivering an MVP (Minimum Viable Product) that could be expanded upon. I also took some time to have a quick conversation with ExpressVPN employees who were serving as competition moderators there to understand what they look for in a certain implementation. Getting myself a cup of boba tea (and skipping it because I did not like it), I met up with the likes of Ajinkya R. and Dakshita Thakkar at the hallway track. On returning to the collective, I decided to lend my assistance to Pongsakorn S. at the KDE e.V. community booth as well, besides helping Aaditya at the GNOME Foundation community booth. I learned that he was using OpenSUSE Leap on his personal laptop and was interested in RPM packaging, while I was placing some of the last fifty Fedora Project stickers on the booth table.
Manifest #4
In contrast to the unoccupied booths from yesterday, it was endearing to see how the likes of Aaditya and Pongsakorn stood their ground at their respective booths, even when the footfall on the second day was noticeably smaller than the day before. Amidst our conversations, I connected them with each other, and Aaditya even took the chance to showcase the GNOME Foundation community quiz application that he had been working on. Following the community quiz activity idea from the Fedora Project Community Presence at DevConf.IN 2026, he wanted to use the remaining GNOME-styled tee-shirts as prizes for folks who attempted the quiz and got all the answers right at the hardest difficulty. Needless to state explicitly, I gave the quiz a try, not because I wanted another tee, but because I wanted to appreciate what he had been working on. A part of me also wanted to take on this hardest-difficulty question challenge to understand how much I knew about the GNOME Foundation and to see if I could learn things I did not know about the community and its activities in the process.
Collection #1
While I got most questions correct on the first attempt, it took me three attempts to get the satisfaction of having all the answers right. Departing from the booth and weaving through a thin collection of mostly booth attendants, event volunteers, and talk presenters, I made it to Mitchell Yue's talk on the Lynx Framework and how it could be used to move from web development to native applications at around 1000am Indochina Time. I was intrigued to learn about this development library, which made use of native bindings for impressive performance. I was even more taken aback (but positively) when I was gifted a ByteDance tee-shirt for asking how it differed from the usual QtWebEngine bindings, as I was well-versed in Qt. This act of brand advocacy definitely seemed to have encouraged the audience to share more feedback or ask more questions during the talk. Heading back to the Debian Project community booth, I shared my experiences from my splurge at Animate Store from the previous day with Ananthu CV before helping Abhijit PA get some cold coffee from the reception desk.
Collection #2
We were also joined by Shreenivas at the GNOME Foundation community booth, which allowed us to pace ourselves while tending to questions and feedback from booth visitors. During a brief visit from Daniel J Blueman, he connected with Aaditya to understand where he could report bugs and improvements for the GNOME desktop. He seemed to have been plagued by problems with the use of external monitors on his ARM-based (Advanced RISC Machines) SoC-powered (System on Chips) laptop on his fresh Debian Linux installation. Meanwhile, I wasted no time unofficially promoting my presentation on the Fedora Badges Revamp Project to the enthusiastic folks from the day before who visited our booth. Meanwhile, I also gave a quick demonstration on how RPM packaging works to a relentlessly curious Pongsakorn, who wanted to package their Rust application for Fedora Linux. Using one of my own hobby projects, Loadouts for Genshin Impact, I showed him how to write an RPM specfile and how programming-language-specific macros could help make things easier.
Manifest #5
As I was not sure if something like the PyProject RPM Macros for Rust existed, I wanted our conversation to be an entry point for them into the RPM packaging tooling ecosystem. While answering his question about Linux kernel package versioning on Fedora Rawhide, I also fielded a question about conflicting packages from Abhijit. Since he was experienced with how the Debian Linux packaging process would handle this, he was curious to know how RPM package management tools would address the situation. Using various examples of how software packages are related to one another, I explained how this linking not only mapped dependencies but conflicts as well. At around 1230pm Indochina Time, I wrapped up my lunch and connected with Simon Strohmenger, who was visiting the community booth then. He shared how he worked on funding free and open source software events across Europe and supporting critical engineering ecosystem resources and was also curious to know more about what I had to share regarding the AI-assisted Contribution Policy from the Fedora Project.
Manifest #6
After sharing contact details with each other, he also checked in with me on whether I would be willing to present a proposal on best practices in contributor onboarding and retention in free and open source software communities. In our conversations, we realized just how crucial it had become to discuss governance policies among grassroots collaborators to ensure that their implementation does not come off as a negative surprise. I also shared my approaches to using LLM (Large Language Model) tooling to assist project maintainers and budding contributors by automatically addressing various low-hanging fruits. Empathizing with how stressful and overwhelming it ends up being for the maintainers and newcomers, respectively, AI tooling could be utilized for these positive purposes instead of worrying about its popularized contemporary taboo perspective. While I could not get him to participate in my Fedora Badges Revamp Project talk later that day, he said that he would send over some of his engineering friends, as he found the general idea of awarding contributions fascinating.
Manifest #7
Since there were not a lot of folks present at the event apart from those who had some activity to participate in, Aaditya struggled to distribute the remaining GNOME-styled tee-shirts. On the other hand, we had been extremely successful in distributing the stickers, so we were able to advocate for our projects from the community booth. At around 0130pm Indochina Time, I checked in with the event volunteers about the allegedly malfunctioning livestreaming functionality in one of the presentation halls. Amidst my attempts to have that fixed before my talk began in about three hours, I briefly met up with Saksham again in the hallway, who mentioned his plans to expand the hackathon project, and I shared the idea of "releasing (software) fast and releasing often." It was an absorbing sight to see how the participants at the ExpressVPN-sponsored FOSSAsia Hackathon were helping each other with a gargantuan variety of problem statements. Such a sight (and evidence of friendly competition) is something one would rarely get to see outside of free and open-source software communities.
Manifest #8
I was thankfully able to get myself caffeinated at around 0330pm Indochina Time, as with the activities moving slowly throughout that that day, I found myself zoning out every now and then. After addressing the livestreaming issue, I met up with some folks from AWS (Amazon Web Services) who were visiting our trinity community booth lineup and had previously worked with the likes of David Duncan and Rich Bowen. Since they had experience with Amazon Linux, they reflected on how Fedora Linux provided them with an innovation-driven upstream distribution to build upon. After that one last conversation with them, Aaditya decided to start packing up the booth at around 0430pm Indochina Time, while I kept myself busy helping him with the tooling. With the time being barely fifteen minutes away from my presentation's commencement, Samyak returned to the GNOME Foundation community booth. Pongsakorn also found his companion back when Tomas returned to the KDE e.V. community booth, and I was ready for my talk to be delivered at the tail end of the event.
Collection #3
As the presentation designated training room had my slide deck already fetched, I did not have to bother with sharing my screen. There were some technical issues with the clicker device, though, as it failed to switch slides when the window was in fullscreen mode. I decided not to settle for windowed mode to save time, while Norbert Preining introduced me in the speaker area at around 0445pm Indochina Time. For a presentation scheduled at the tail end of the conference, it was reassuring to see that I still had around twenty attendees in the hall who were curious to know what I had to offer. Being the deciding moment that I had been practicing regularly for, I wanted to ensure that I was doing justice to their time (and attention) and that of the remote attendees. Thanks to Samyak's laptop and the regular touchups, the fifteen-minute-long presentation went largely well, and I also addressed some feedback and questions from both the in-person attendees and the hall host, Norbert. After finishing my talk, we headed into the competition hall where the four judges had assembled, by then.
Collection #4
After briefly waiting for the participating teams to propose their project ideas and for the judges to complete their evaluations, our collective made our way into the main hall to witness the winner announcements at around 0530pm Indochina Time. As the winners were announced and the event concluded, Samyak and I deliberated on our evening plans, as we did not intend to continue our stay with the FOSSAsia 2026 attendees at the Night Market. After his proposal was turned down by the folks he was planning to invite, we formed a group of four, including him, Soundarya Rangarajan, Aaditya, and myself, to visit Bangkok Chinatown. This idea felt strategically sound as it had become a little too late to visit the riverside for a calming evening boat ride dinner, and coincidentally, Soundarya was staying at the same hotel as Samyak and me. After making a quick drop of Aaditya's belongings at my hotel room and taking some time to re-energize ourselves after the long second day, we started looking for cabs using the Grab application at around 0700pm Indochina Time.
Collection #5
Amidst the heavy Bangkok evening traffic, we struggled to get a ride until we finally secured one after about thirty minutes of waiting through the Bolt service. I was not a fan of the service, as the toll expenses were not accounted for in the final billing, thus resulting in us having to pay for them separately. What I was a fan of, though, was the taxi driver assigned to us, as the cheerful person did not let the piling traffic and the linguistic barrier prevent him from having a friendly chat with us. With the use of Google Translate, he graciously helped us plan our course and described what we could expect in Bangkok Chinatown. And he could not have been more right - because when we got off the Bolt ride, the view of the neon filled, slightly humid hustle and bustle of Chinatown was a scene that nothing could even compare to. Weaving through the visitor crowd at the periphery, our first stop was, of course, a stall selling the world-famous Mango Sticky Rice for just 100 Thai Baht per plate. We finally got to experience firsthand just how true the people were who sang nothing but praises of this exclusive snack!
Collection #6
We dove deeper into our little roadside dining adventure with some Coconut Egg Sweet Crepes and Japanese Fried Octopus Balls before deciding to split into groups of two, as it did not sit right by Aaditya and myself, since the cuisines there were mostly non-vegetarian. As Samyak and Soundarya headed their way at around 0830pm Indochina Time, him and I decided to get even more creative by digging into some Shrimp Meat Dimsum Dumplings and Fried Crab Meat Rolls. After finishing off with some Fried Sweet Maple Fish and Ripe Alphonso Mango Slices, all for amazing bargains, we navigated the confusing pathways to reach Jam Jam Eatery Chinatown. As Aaditya's belongings were in my room, we left for the hotel at around 0915pm Indochina Time without waiting much longer. It was not that I had my fill of exploration, but I felt responsible to ensure he made it back safely at BTS Punnawithi to his hotel room. After hanging out in my hotel room and discussing industrial mentorship ideas, I decided to see him off and call it a day at around 1200am Indochina Time.
So, let’s see what is included in this new release for the Fedora Atomic Desktop variants (Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
You attended the F44 Virtual Release Party!
comments? additions? reactions?
As always, comment on the fediverse: https://fosstodon.org/@nirik/116506323315055393