Après 12 ans, ma balance Withings a rendu l'âme. L'occasion idéale pour abandonner MyFitnessPal, auto-héberger la synchronisation de mes données de poids vers Garmin et automatiser le flux vers Strava via n8n.
A bit late with the weekly recap this week, possible due to lower energy
from getting my flu and covid boosters friday, but lets go...
Mass update/reboot
The mass update reboot cycle went pretty well. We also applied firmware to
all the machines that had updates, which always takes a while, but probibly
is worth it.
Database server upgrades
Also, as part of the outage on thursday to do the outage causing hosts updates
and reboots, we moved all our database servers over to postgresql 18, rhel10,
and the latest timescaledb (in the case of db-datanommer).
That also went reasonably well, and we shouldn't have to do that
again for a while.
Fedora 45 infrastructure freeze coming up
This coming tuesday is the start of the infrastructure freeze for fedora 45
final release.
Out next weekend
I'm out next friday through sunday, heading to seattle for a rust concert.
I'm planning on taking the train, so that should be fun, but there will
not really be a recap next weekend. :)
September 2026 brought another wave of organizations whose Kiwi TCMS instances
crossed the 1000-events mark for the first time. Below is a short, by no means
exhaustive, look at who they are and what they do.
Disclaimer: the information below was obtained via anonymous analytics and
represents only instances of Kiwi TCMS which crossed 1000 events during
September 2026. We've used publicly available data in order to identify these
organizations. Note that we don't keep track of individuals or IP addresses!
Austria
Scientific Games - lottery systems, digital gaming and sports betting technology
Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code when using unsafe languages like C, C++, or Vala: it’s just too hard for even experienced developers to do properly.
The above paragraph is taken from the abstracts of my GUADEC 2024 and 2025 talks. At the time, I thought failure was inevitable: we humans were so bad at writing software that we had no chance to do it properly, and I certainly would not have trusted an AI to do better than a human. But the landscape today is completely different than last year. AI has improved considerably, and offers a magic fairy wand solution to this problem: we can now simply ask a language model to look for vulnerabilities in our software. They are quite good at this.
There is zero hope of maintaining quality software in 2026 without AI vulnerability scanning. Any claims to the contrary are unserious and delusional. The tremendous quantity of bugs found in our best-maintained projects, like GLib and fwupd, should speak for itself. Failure to scan our projects is an unfair disservice to our users. If we don’t find the vulnerabilities by scanning projects ourselves, attackers certainly will, because the Linux user base has increased to the point that Linux users are finally numerous enough to be worth targeting. Meanwhile, AI has made it easier than ever to build working exploits, which was previously unheard of.
Already resolved all the detectable vulnerabilities? Then ask the AI to look for non-security bugs as well, to further improve quality. GNOME code is generally much better than it used to be, but there remains considerable room for improvement. For the first time in history, we now have the opportunity to improve software quality to a degree that was never realistic before.
Have you heard that most AI bug reports are “slop?” Not so in 2026. That was true for most of 2025, but the quality of AI-generated vulnerability reports has drastically improved. That is not to say that we no longer have problems with bad vulnerability reports, but in general, nowadays most of them are pretty good. (Daniel Stenberg reports the same pattern for curl.)
AI-generated vulnerability reports have nevertheless introduced many undesirable impacts on GNOME maintainers. They are usually annoyingly verbose and unnecessarily detailed. They often exaggerate the severity of the problem, or make misleading or irrelevant claims. They are occasionally incorrect. Sometimes they include outright fabricated data, such as fake stack traces (which is not the norm, but sadly also not uncommon). A good human reviewer will notice and resolve most of the above problems before creating a bug report on your issue tracker, but often problems are reported by inexperienced humans who do not actually know what they are looking at and simply copy/paste everything blindly. Even when the generated issue report is good and avoids all of the above problems (which is rare), good vulnerability reports in sufficiently high quantity can still overwhelm volunteer maintainers. And even if reporters submit a merge request to resolve the problem so maintainers don’t have to (which is also rare), reviewing those merge requests is itself more unwelcome work for overworked maintainers.
That all is to say: I understand the pain caused by the current wave of AI-generated issue reports. Nevertheless, they are essential and unavoidable. We have to learn to accept and deal with them, not stick our heads in the sand and ignore them.
Some GNOME maintainers have adopted a policy prohibiting AI-generated content in issue reports. Do not do this. Nowadays, the overwhelming majority of vulnerability reports are AI-generated. Projects that choose to ban AI-generated content in issue reports might as well ban all vulnerability reports; the effect will be approximately the same.
Projects that continue to prohibit AI-generated vulnerability reports are no longer suitable dependencies for GNOME, and should be developed someplace other than GNOME GitLab.
We don’t have to tolerate bad issue reports, but AI use alone should not be disqualifying.
When I complain that maintainers should allow AI-generated vulnerability reports, the most common counterargument is that humans should read the AI’s report, understand it, and rewrite the entire thing to remove all AI-generated content. Some bug reporters actually voluntarily do this, but this is rare.
Vulnerability reporting is a public service, not an obligation. If you ask a reporter to do any amount of extra work, they might be willing to do so, but it’s much more likely that they will either stop looking at your project and move on to something else, or continue looking at your project and publish the vulnerability reports someplace other than your issue tracker.
Rewriting issue reports also does not scale. Let’s say you use AI to find 100 security bugs in a GNOME project, a number consistent with the results of actual scans (read on). Would you really spend months rewriting those bug reports before submitting them to upstream? Validating the AI’s claims, upstreaming the issue reports, and submitting merge requests is already a lot of work. Not many people would be willing to additionally rewrite all the issue reports. That’s more work than everything else combined, and is unrealistic.
Even with just a small number of bugs, I would hesitate to spend much time rewriting an issue report because I have many other tasks I would rather spend my time on. At best, I might prepare a quick summary, but it won’t be as useful as a full report.
The CVE Wave Hits GNOME
The current wave of vulnerability reports is reflected in GNOME’s CVE issuance trends:
Year
GNOME CVEs
GNOME CVEs Excluding GIMP, Gegl, libxml2, and libxslt
2021
21
14
2022
14
6
2023
13
4
2024
37
28
2025
97
49
2026 Year-to-date (2026-09-30)
141
74
2026 Normalized
188 (141 * 4 / 3)
99 (74 * 4 / 3)
The trend here should be pretty clear. Until recently, not many people were reporting vulnerabilities in GNOME. That has changed. We are currently dealing with an order of magnitude more CVEs than just 3 years ago. AI is not the only reason for this; GNOME maintainers have also gotten a little better at flagging issues so that I add them to security tracking. But AI is the primary cause for the increase.
(A few technical notes on this table. CVEs are classified by the year the issue was reported to GNOME, not by the year in the CVE identifier, so e.g. many CVE-2026 issues are counted in 2025. Vulnerabilities reported in 2026 which do not yet have CVEs are not counted, so you can think of the data as being accurate through roughly September 1; multiply the 2026 numbers by 4/3 to make them comparable to the prior years. I count only issues reported to GNOME Security, so any unreported CVEs do not count.)
Although there are still 3 months left in 2026, we will never have data for the rest of the year because I have ended security tracking for new issue reports and nobody else has volunteered to do that work. These CVEs exist only because I request them myself, so I expect the number of CVEs to drastically decrease going forward.
CVEs are reported against the year they appeared in a WebKitGTK security advisory, not the year in the CVE ID. The large increase in 2026 is entirely due to AI analysis of Skia and ANGLE. WebKit bundles these libraries because they are not designed to be installed as system libraries, so their vulnerabilities should be counted the same as vulnerabilities in WebKit’s own code. Excluding Skia and ANGLE, there are actually only 21 other WebKitGTK CVEs so far this year, a significant decrease, but excluding CVEs in bundled code would not be fair.
There has actually been a very large increase in WebKit security fixes this year, but this has not resulted in any increase in CVEs. Apple generally creates CVEs for flaws found by external researchers, not often for flaws found by WebKit developers, so the increase in security fixes is not reflected in the total number of CVEs. Only a small fraction of WebKit vulnerabilities receive CVEs.
I had not previously noticed that the count of WebKitGTK CVEs had, until 2026, been decreasing over the past decade. I am not sure why. I also do not know how to explain the low number in 2016.
Announcing the GNOME Bug Bounty Program and Announcing the End of the GNOME Bug Bounty Program
My blog post to-do list says that I need to write a blog post announcing the creation of the GNOME Bug Bounty Program on the YesWeHack platform. Oops, too late. It’s already closed. (Once a task enters my to-do list, it can be a very long time before I get around to doing it.)
The GNOME Bug Bounty Program was generously sponsored by the Sovereign Tech Resilience program of Germany’s Sovereign Tech Agency. I’m not sure precisely when it opened, but the first vulnerability was reported on June 27, 2024, so it would have been sometime shortly before then. We accepted issue reports only for GLib, glib-networking, and libsoup, because GNOME had never operated a bug bounty program before and we did not know what to expect. Starting small had — naively — seemed like a prudent way to avoid a large quantity of issue reports. I had wanted to expand the program to cover all of GNOME, but this failed due to the overwhelming deluge in issues reported against GLib and libsoup.
I requested that the bug bounty program end because I was overwhelmed with incoming AI-generated issue reports. The final issue was reported on February 23, 2026. Here are the results:
Year
Reports Submitted
Reports Accepted
2024
26
14
2025
150
33
2026
122
24
Total
298
71
Those numbers for 2026 reflect less than two months’ worth of issue reports, so you can see why it was no longer sustainable.
After the program closed, our work was not done: there was a long backlog of reports to work though. We just last month caught up with accepting the last of the issues reported back in February, and the last bounty was finally awarded earlier today! Even with YesWeHack’s professional triagers analyzing the issue reports before I reviewed them, keeping up with such a large number of vulnerabilities was not easy for me.
At this point, all reports not accepted have been rejected. The program awarded €183,900 in bounties for 71 vulnerabilities: 45 in libsoup, 23 in GLib, and 3 in glib-networking. Award amounts varied from €500 (16 awards) to €7,500 (2 awards). The arithmetic mean award was €2,662.99.
Bug bounty programs are an exception to the rule that most AI-generated vulnerability reports are good. You can see the number of reports accepted is a small fraction of the number of reports submitted. Excluding 30 reports closed as duplicates, that leaves 197 reports rejected. Turns out, people will submit bad reports when financially incentivized to do so. The low percentage of accepted reports even understates the problem, because many of the accepted reports were actually not very good! Many accepted reports did successfully identify valid security problems (in fact, many of the rejected reports successfully identified valid security problems!), but required many rounds of revision and corrections.
Suffice to say, I have reviewed a lot of really bad AI-generated vulnerability reports. But the reports we received via the discontinued bug bounty program are not comparable to the reports received via regular GNOME issue trackers or the security bug report form. We do still occasionally receive bad vulnerability reports, but not often and not many, so it’s not a big problem anymore. When people submit AI-generated reports without hope of a financial award, those reports are generally much better.
Lessons from the Bug Bounty Program
Closing the bug bounty program because it found too many vulnerabilities is not a particularly pleasant result. That said, it was still a partial success in that it uncovered lots of bugs in libsoup and GLib.
I had hypothesized that libsoup was probably not very secure, but I never imagined just how many vulnerabilities would be discovered. To reduce the quantity of incoming issue reports and better reflect actual risk to GNOME users, I eventually removed all denial of service bugs from program scope, and then later removed SoupServer from the scope due to too many request smuggling vulnerabilities, which are HTTP request parsing bugs that pose no threat to GNOME users. Even with those changes, the libsoup vulnerability reports kept coming until I gave up. The silver lining is that libsoup is now relatively much more secure than before. Other bug reporters have been submitting AI-generated bug reports using the normal libsoup issue tracker, so fortunately the improvements to libsoup will continue despite an end to the financial awards.
I had hypothesized that GLib would be much better than libsoup. I’m not sure whether I was correct. Evaluating the severity of GLib flaws is much harder than for libsoup, since GLib vulnerability reports are generally hypothetical in nature: usually some proof of concept program calls a GLib API using valid but improbable values, then something bad happens.
A large portion of the GLib bugs were integer overflow flaws, which generally result in buffer overflow. I am now more scared of integer overflow than anything else. It’s likely that most software projects have many integer overflow problems. Fortunately, we should be able to catch most such problems by adjusting the compiler flags we use. In particular, -Wconversion or -Wint-conversion and -Wsign-compare should help here. Some GNOME projects already use -Wsign-compare, but I suspect most do not. I think few or no GNOME projects use -Wconversion or -Wint-conversion.
Resuming the bug bounty program would only be possible under substantially different conditions. What we were doing was not working well. To resume, we would need to limit the scope to projects that regularly perform their own AI vulnerability scans. We would also most likely want to pay only for functional exploits, rather than for all vulnerabilities. GNOME code is currently not good enough to continue paying for every vulnerability, and it no longer makes sense to pay bounties for issues that can be found by AI scanners.
Red Hat Scans GLib
Red Hat has contracted with AISLE Research to perform AI vulnerability scans of various GNOME projects. We received a large quantity of findings, and are only just now beginning to individually validate and report our findings to upstream. GLib is by far the hardest hit project, which I was not expecting, accounting for more than 40% of our total findings. I’m not certain why, but perhaps this is because GLib provides so many public APIs. Data passed to public APIs is potentially untrusted, so the attack surface is considerable.
Red Hat’s scan of GLib found 118 vulnerabilities. Or at least, it claimed to. However, due to the way we ran the scans, several of these are actually unnecessary duplicates of each other, which we have not fully deduplicated yet, so the number I report is not entirely trustworthy. Moreover, 46 of these “vulnerabilities” are bugs in gobject-introspection, mostly in the typelib support, which is evidently not very robust. A typelib controls how your program calls libraries; it is effectively calling convention, so it must inherently be fully trusted: a malicious typelib would be able to induce vulnerabilities even without any bugs! I would expect an AI ought to have been able to figure that out, but apparently not. These bugs are still real problems that we ought to fix, but all maintainers agree they are not security vulnerabilities, so let’s count all of them as false positives. That alone creates a 40% false positive rate. Ouch.
I don’t have more stats to share here because we are not yet done working through the issue reports. That said, I am quite pleased with the results thus far. Substantially all of the reports are high-quality. The false positive vulnerability reports are almost all due to one particular misunderstanding and can be treated as good quality non-security bug reports, which are still valuable. Expect many forthcoming CVE assignments for the other findings.
It’s rare for Linux vendors to proactively look for software vulnerabilities, rather than waiting for security researchers to report them. This was a successful experiment in proactively seeking out problems.
Humans Still Useful
In addition to the bug bounty program, the Sovereign Tech Resilience program also sponsored a security audit for GNOME, performed by Codean Labs. This resulted in many findings in various GNOME projects. Most notably, the scope of the audit extended to Flatpak and xdg-desktop-portal, resulting in criticalfindings.
Most of these issues could have been detected via AI scans, but I am not confident that AIs would have been able to discover the most important findings, like the two Flatpak sandbox escapes that I linked to above. Accordingly, I do not recommend relying on AI alone.
Humanity Still Desired
Although I like AI-generated issue reports, I particularly do not appreciate when I wind up interacting with a robot rather than with a human. It’s pretty obvious when your issue tracker or code review comments are written by an AI. Consider whether outsourcing your writing and your thinking to a language model is truly wise for your public image.
We even have one experienced GNOME developer who is obviously using AI to write all of his posts on GitLab. I am unsure whether he is copy/pasting all of his responses from an AI, or whether he is just a bot now. I especially do not understand the value of this.
Here is a soft proposal, intended only as a starting point for discussion and not as a serious proposal, for what my preferred AI usage policy might look like:
Newer developers should exercise caution when using AI to write code. Your priority should be learning, and I wonder how much you are really learning when relying on the AI to do work for you.
Do not use AI to write code comments. Currents AIs are terrible at writing comments. Most comments written by AIs should be deleted. If a comment is truly necessary, then I’d like to see it written in your own words. Presumably AIs will get better at this eventually, but as of 2026, human judgment is still required here.
Do not use AI to write commit messages. AIs are actually probably better than humans at writing commit messages, but I would still rather hear your own thoughts on the code you are submitting.
Certainly do not post AI-generated comments on an issue tracker or merge request as if they are your own. You’re not fooling anybody.
Maintain Perspective
Are you scared by the large numbers of recently-discovered vulnerabilities? There is no need to panic. Security bugs are just bugs, and they’re not necessarily more important than other bugs. Occasionally they are emergencies, but far more often they are boring and unexceptional. Security vulnerabilities are not even the biggest digital security threats that users face: those are surely phishing and trojans, with software security bugs a distant third place. No amount of CVE fixing will protect you from those more likely threats.
I don’t want to downplay the severity of security issues either. In fact, evaluating severity is hard. I quite often decide that a bug is not a big deal, only to be proven incorrect. Ideally, we would fix as many security issues as possible, and sooner rather than later. Lifetime issues and out of bounds writes are especially important to fix. Two years ago, I claimed that memory safety vulnerabilities were becoming less threatening, a claim that did not age well: that is surely no longer true due to the drastically increased accessibility of AI exploit generation.
Nonetheless, volunteer maintainers should not feel obligated to fix security issues or treat them as higher-priority than other bug reports. It’s certainly good to fix problems when possible, but my request is only that you do not prohibit issue reports, not that you attempt to personally resolve every security problem yourself. When I add due dates to vulnerability reports, that represents only a disclosure deadline — because issue reports should not stay confidential indefinitely — not an expectation that you fix the issue by that date. Resolving security problems in projects used by big tech companies that depend on your software without contributing back is basically free labor for said companies, and only you can decide whether that’s how you want to spend your volunteer time.
Rust
Yes, even projects written in memory safe languages like Rust still need to allow AI-generated vulnerability reports. Rust will indeed eliminate most memory safety issues (except in unsafe blocks), and you can reasonably expect a Rust project to have an order of magnitude fewer vulnerabilities than a comparable project written in C or C++ or Vala. This is amazing, but not all vulnerabilities are memory safety issues, so this is not an excuse to avoid scanning for flaws.
Although Rust mostly eliminates memory safety risk, any use of Cargo to download dependencies dramatically increases supply chain security risk. The risk of bundling a trojanized dependency arguably — I would even say probably — outweighs the benefit of eliminating memory safety flaws. This problem is inherent to any programming language package manager. Currently the best solution is to not use programming language package managers, but GNOME’s Rust code depends heavily on Cargo. Accordingly, I recommend against using Rust for writing GNOME software.
To Be Continued…
I have exhausted my thoughts on AI vulnerability reports, but there is still much to discuss regarding software quality. Next time, I will discuss additional strategies to improve GNOME quality without significantly relying on AI.
As previously announced, I have discontinued my tracking of GNOME security issues. Nobody else has volunteered to continue that work, so it has concluded (except for issues reported during September 2026, which I will keep an eye on until the end of this month).
Maintainers, I encourage you to request your own CVEs by writing to Red Hat Product Security. Red Hat is an ideal CNA (CVE Numbering Authority) to use for GNOME CVEs because you will receive timely responses. Ignore Red Hat’s suggestions to encrypt your mail using GPG, and use the following email template:
Hi, I request a CVE for:
Summary:
Requirements to exploit:
Component affected:
Version affected: All versions <-- change this if needed
Patch available: Yes/No
Version fixed (if any already):
Upstream coordination: See issue report (below)
CVSS (optional):
Impact (optional):
Embargo: No
Acknowledgment:
Steps to reproduce if available: see issue report
Mitigation if available: <-- it's OK to write "None"
Original report:
Request a CVE after making your issue report public. It’s possible to reserve a CVE in advance, but this requires twice as many steps, so I recommend making it public first, then request a CVE second.
GNOME and Fedora maintainers should feel free to get in touch with me if you have questions.
Very few companies are ever listed in the official Gazette.
After that painful lesson, as they progress towards being in a position
to run the UK Government, wouldn't you expect them to improve their
procedures and run their party headquarters competently?
It looks like
Sarah Cooper-Lesadd
is right. They admit despite having one of the most serious legal
documents, a [redacted], served on their party headquarters,
they have no idea where it went:
Fortunately, the process server provide video evidence so I can prove it
was served correctly and the incompetence is not on my side.
Look at the cost. Their lawyers,
Aston Bond, have invoiced over £25,000 before the first hearing.
Most of that is for investigating what went wrong inside their own
organisation and how the dispute was
leaked by the MouseInTheCourt before the [redacted] ever arrived on
the doorstep of party HQ.
Why is
Nigel Farage so so afraid of a candidate who only got sixteen votes?
As
Reform UK tries to [redacted], they have complained
to the court that [redacted] other failed candidates,
Reform UK defectors, independent contractors and small business owners
how to [redacted].
If they block more people [redacted]
It is not my intention to publish the forms unless the conduct and
behaviour of these people forces me to do so.
Judgment: VMS Enterprises Ltd vs The Brexit Party Ltd ([2021] SC GLA 49)
The Brexit Party Ltd became
Reform UK Party Ltd, company number 11694875. This
subsequently got merged into Reform 2025 Ltd to become a
different Reform UK Party Limited company no. 16260766. An
inconvenient consequence of this name change and merger is that people
searching for judgments against the new company number 16260766 don't
see the history of the old company name and company number.
The full judgment is available here for download as an Acrobat document:
The political party, formerly led by Nigel Farage as the Brexit Party during the 2019 general election, faces a hearing in the High Court in London as early as September. Victor Shields, director of VMS Enterprises, was forced to take the party – since rebranded and led by Richard Tice – to court over the bill from the 2019 general election. Despite Glasgow Sheriff Court agreeing the party should pay up, it has consistently refused to answer letters or pay the sum owed to the businessman, forcing him to take further legal action in England. It is understood a winding up petition was served on the political party last week, with a hearing set for September 7 or soon thereafter. Reform UK has consistently rejected the claim, now worth more than £26,000 after interest and before court expenses are taken into account. A winding up order, if granted by the court, would see the party face liquidation proceedings to pay the outstanding amount and could include an investigation into director conduct. The initial Scottish court case arose after a dispute between the party and VMS Enterprises around payment for election billboards in London during the general election campaign. The court stated the party was liable for the bill for advertising services after some invoices were paid by Brexit Party staff and others were not questioned. Several invoices had gone unpaid amid claims a volunteer did not have the authority to charge the party for the billboards. However, the court stated the failure to question the payment of invoices incurred by candidates meant the party was liable for the full costs. Speaking to The Scotsman last year, Mr Shields attacked Reform UK’s “hypocrisy” in failing to pay. He said: “I was quite happy to keep quiet after the judgment because I assumed they would respect the Scottish courts and duly pay us. "They don't care. They feel they are above the law. "Richard Tice is positioning himself to the right of Boris [Johnson] and trying to capture the Conservative voters, Scottish voters too and here we are being forced to go to English courts, for me being forced to spend further money, to try and recover a debt that is legally due to us." The court case heard witnesses describe the organisation of the Brexit Party, then led by former UKIP leader Nigel Farage, as "shambolic" by a party official as it struggled to cope with its popularity and decision to pull hundreds of candidates from the ballot paper ahead of polling day. Witnesses told the court the party’s organisational structure "visibly started to fall apart", was "very unprofessional" and "beyond chaotic" ahead of the 2019 election. Reform UK’s latest accounts state that in 2020 it received nearly £3 million in donations, with a further £17m in 2019. Reform UK has been contacted for comment by The Scotsman.
Eighteen months after the judgment, almost two years after the judicial procedure
began, in December 2022,
VMS Enterprises Ltd used the High Court insolvency procedure to publish
an insolvency notice for Reform UK Party Limited.
As a consequence, a listing was placed in the official Gazette with their
old company number 11694875 and the High Court case number CR-2022-003973.
Diagram demonstrating evolution of the Reform UK companies
Searching for information about the names and company numbers is tedious
and time consuming. I created a colour-coded diagram so people can see and
understand the relationship between the companies in the history of
Reform UK at a glance.
Looking through the filing history of each company, you can see many minor
changes, including some name changes. I put the filing history for both
companies side-by-side:
Drilling down on the name changes, it is fascinating to put the two
forms side-by-side like this:
Here is the full diagram I created to help people understanding the
judgment and insolvency court history of
Reform UK and its leaders at a glance:
Direct links to search the Gazette for old company number
11694875
and for the new company number
16260766.
People who have a legitimate claim against any company
are encouraged to contact their solicitor for advice
and share their contact details with other creditors to resolve
the dispute more expediently. See my previous blog about how to
join a creditors petition in the UK.
Reform UK is the only major political party in the
UK that is also registered as a company at Companies House.
Consequently, each year, they must file a set of accounts, with an
auditor's report, at Companies House. The deadline was today,
30 September 2026. Why did they file the accounts at the very last
minute and not at the same time they filed with the Electoral
Commission?
As explained in
my previous blog on the subject, the reports given to Companies House
are slightly different from the reports given to the Electoral Commission.
The Electoral Commission is trying to show the impact of money on
democracy. The Companies House report aims to give members, investors,
trading partners and employees an image of the organisation's strength
or weakness.
The document uploaded to the Electoral Commission in June is a
text-searchable PDF. The PDF uploaded to Companies House is not
text-searchable. However, Companies House also has another copy
in iXBRL, which is an XHTML file that is text-searchable in a web
browser.
At a glance, we can see the numbers are not exactly the same.
For example, the membership revenue in the report to the
Electoral Commission appears to be a bit higher because they used
to collect the money through a different company and then they
subsequently merged the two companies during the 2025 reporting
year.
Like the report submitted to the Electoral Commission, the report
submitted to Companies House does not mention the potential impact
of the new, backdated restrictions on donations from overseas electors.
If those restrictions are implemented soon, they will have a very
severe impact on
Reform UK. It seems odd to me they can completely omit that
from the statement about the company being a going concern
for the next 12 months.
One of the very significant differences in the Companies House
report submitted today is on the very last page. It is the
declaration about how they merged the two former companies and
who really has control over the company, which is acting as a
political party but is really a business:
19. Related party transactions
On 19 February 2025, the company acquired the entire issued share capital of Reform 2025 Ltd for consideration of £15.
...
20. Controlling party
The company is limited by guarantee and has no share capital. The company has two members, who have equal voting rights. Neither member has individual control of the company and, accordingly, there is no ultimate controlling party.
...
Legal form of entity and country of incorporation
...
The company is limited by guarantee and has no share capital. The liability of each member is limited to £1, being the amount that each member undertakes to contribute to the assets of the company in the event of its winding up. There were two members at the year end.
Companies limited by guarantee in the
UK are a special type of company that is normally used for non-profits
and charities. In some non-profits, like sporting clubs, every member
is really a member of the company and invited to the annual general meeting.
The accounts that
Reform UK has just filed show us they have a two-tier membership structure,
similar to the scandal of the
FSFE misfits.
People who "join"
Reform UK and pay £25 per year are not really members like
Nigel Farage and
Zia Yusuf are members in the accounts.
In
UK law, the real members,
Nigel Farage and
Zia Yusuf, can choose to change it into a normal shareholder company
at any time they want and then they can sell the shares or pass them to
their children, as long as the articles of association permit that.
In June 2025,
Zia Yusuf resigned from Reform UK and came back two days later.
The accounts show us that he resigned from his position on the board
but they do not tell us if he transferred his position as one of the
two controlling members to somebody else.
Reform UK claims to have more members than any other political
party in the
UK. These accounts tell us their company only has two members,
making it one of the smallest political parties at the same time
as being one of the biggest.
If the members accept this two-tier structure, does that mean it
really is a
cult, as we were
told by Rupert Lowe?
When they changed the structure, they told people they were
making it more democratic. What they really did is they reduced their
risk. If it fails, they only lose their guarantee, which is £1
each. If it succeeds, these two people can choose to pivot back to a
shareholder company form, issue shares and sell them on the stock market.
The other thing they did through this reoganisation is obfuscating the
history of disputes and judgments against the former company. It looks
like at least one law suit is still progressing against the old company
and it is not clear if the new company structure will be obliged to pay
for it if they lose.
The UK permits directors, company secretaries and shareholders
to be nominees, in other words, proxies contracted to obey the
person who really pays them to perform that role. While
Nigel Farage and
Zia Yusuf are listed publicly as the members who founded the new entity
in February 2025, there is no obligation for them to publicly identify
any transfers of these memberships to other people. The only thing we
can deduce from the report is that there are currently two members,
the same number of members they had when they created the entity
but not necessarily the same two people.
In the sentencing of the late
Cardinal George Pell, it was his defence lawyer
Robert Richter KC who argued the Cardinal should receive a
lighter punishment because it was a "plain vanilla" case of abuse.
In fact, when somebody in such a senior position of trust commits
an offence of that nature, it is a lifelong case of psychological torture
for the victims. That is what makes institutional abuse, such as the
abuse by jurists and the
abuse by the Catholic Church so much worse than other types of
abuse.
Version 8.6.0 Release Candidate 2 has been released. It's now entering the stabilisation phase for the developers, and the test phase for the users.
RPMs are available in the php:remi-8.6 stream for Fedora ≥ 43 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) and as Software Collection in the remi-safe repository (or remi for Fedora)
⚠️ The repository provides development versions which are not suitable for production usage.
The Fedora QA team invites you to participate in the Anaconda F45 features Test Week, which is running now through October 2, 2026. There is still time to jump in this week and help us shape the Fedora 45 installer before it ships.
What’s New in the Anaconda F45 Installer
Fedora 45 brings three significant changes to how you install the system. Each one is ready for real-world testing – and better testing means a better installer.
WebUI for Atomic Desktops – The modern web-based installer now covers the Atomic Desktops (Silverblue, Kinoite, and the Cosmic/Sway/Budgie Atomic variants). See the Change page.
Remote WebUI – You can now drive an installation from another device entirely, straight from a browser. See the Change page.
Stratis support – The WebUI can now configure Stratis storage. See the Change page and the introduction on Fedora Magazine.
How to Participate
Requirements
A virtual machine or a spare bare-metal box – not a production machine and not one with data you care about.
On September 19, 2026, the Fedora Project supported the conduct of Software Freedom Day Bukidnon 2026. The event took place at the Northern Bukidnon State College, Manolo Fortich, Philippines.
Now in its second run, Software Freedom Day Bukidnon gathered students, professionals, educators, and community members to explore how Free and Open Source Software can empower innovation, digital inclusion, and impact their daily lives, primarily in the province of Bukidnon, Philippines. Despite the challenges like power outage, the event was a massive success, demonstrating the local community’s resilience and passion for open technology.
Event Highlights
The event features an impressive speaker lineup, with presentations spanning foundational Open Source principles and cutting-edge technology trends.
Paul Harriet Asiñero while presenting Hello Fedora
Walt Miner while presenting Introduction to Automotive Grade Linux
Arjay Sitoy while presenting Local LLMs: My 8GB VRAM vs the World
Romar Mayer Micabalo while presenting Harnessing Krita For Fun and Profit
Rafael Tibudan while presenting Building a Second Brain: Turning Information into Leverage
Wei Lee while presenting Orchestration Still Matters: Apache Airflow in the Age of AI
Jay Ginete while presenting 5 Cool Open Source Tools to Pimp Out Your Windows CLI
Roger Madjos while presenting Practical Agentic Coding with OpenCode
Linux and Open Systems
Hello Fedora by Paul Harriet Asiñero – This session introduced attendees to Fedora Linux, highlighting its pivotal role in driving Open Source innovation. Participants explored the power, robust security, and exceptional flexibility that make it one of the world’s premier Open Source operating systems.
Introduction to Automotive Grade Linux by Walt Miner – Attendees received an exciting look at how Open Source technology has moved beyond PCs and servers, driving the software systems that power modern smart vehicles.
Art and the Developer Workflow
Harnessing Krita For Fun and Profit by Romar Mayer Micabalo – Proving that Open Source is just as crucial for creatives as it is for developers, this talk walked attendees through building a career or hobby using Krita, a premier Open Source digital painting tool.
5 Cool Open Source Tools to Pimp Out Your Windows CLI by Jay Ginete – A practical guide for developers stuck on proprietary systems, showing how to upgrade a boring terminal into an Open Source-powered developer powerhouse.
The AI and Data Pipeline
Local LLMs: My 8GB VRAM vs the World by Arjay Sitoy – In a highly relevant, budget-conscious session, this talk demonstrated how developers can break free from corporate API reliance by running powerful Large Language Models locally on standard consumer hardware.
Practical Agentic Coding with OpenCode by Roger Madjos – Shifting from consumption to creation, this session showed developers how to leverage Open Source AI agents to actively write and debug code. Attendees walked away with a practical blueprint for turning agentic coding into a reliable, secure, and repeatable development workflow that delivers value faster without compromising quality.
Building a Second Brain: Turning Information into Leverage by Rafael Tibudan – Explored how to use knowledge management, AI, and automation to build a digital “second brain.” The session shared simple, scalable strategies to transform past code bugs, research notes, and AI conversations into a personal knowledge base.
Orchestration Still Matters: Apache Airflow in the Age of AI by Wei Lee – Attendees got a deep dive into the backend infrastructure powering modern technology. The talk drove home a crucial point: even as artificial intelligence dominates the headlines, leveraging Apache Airflow to control and orchestrate the data pipelines and workflows powering AI applications remains absolutely vital to AI success.
Page Follow Bingo Game and Raffle Draw
In addition to the engaging sessions, the event featured a Page Follow Bingo Game and an exciting raffle for all attendees. The Bingo game was designed to boost engagement for our event sponsors and partners by encouraging participants to follow their official pages, with the first five to complete the task being crowned winners. The event wrapped up with a raffle draw featuring an array of prizes generously contributed by our sponsors. The raffle was conducted using pyraffle, an Open Source raffle draw software executed within a notebook environment.
Final Thoughts
Despite the challenges, Software Freedom Day Bukidnon 2026 was a resounding success! An impactful movement like this cannot happen in isolation. As we look back on the success of this year’s event, our deepest gratitude goes out to the incredible individuals and organizations who helped bring this vision to life.
Event Sponsors and Partners
Software Freedom Day Bukidnon 2026 Event Partners and Sponsors
This event was made possible through the generous support of our partners and sponsors. In addition to the Fedora Project, we would like to extend our sincere gratitude to the following organizations:
Aside from the participating organizations, we would like to express our gratitude to an anonymous donor for providing financial support for the event.
Speakers
Awarding of tokens for the Speakers
Thank you for sharing your time, passion, and unparalleled expertise. You gave our community tangible frameworks to work with, sparking ideas that will undoubtedly fuel local tech innovation for months to come.
Event Volunteers
Volunteers are the backbone of Software Freedom Day Bukidnon 2026, driving everything from pre-event preparations to post-event operations. We are proud to recognize the dedicated individuals who made this success possible:
Thank you for taking the time out of your weekend to show up, engage, and learn. Your energy, thoughtful questions, and collaborative spirit are what give life to the FOSS movement in Bukidnon. You are the future of our digital landscape, a thriving ecosystem where the veterans lift up the rookies, passing the torch to ensure the next generation keeps pushing boundaries.
The event has wrapped up, but our mission continues. The Free and Open Source Software movement in Bukidnon thrives because of community advocates and supporters like you. As we look ahead to the return of Software Freedom Day next September, we invite you to join us as a participant, volunteer, sponsor, or partner. Together, we can empower local tech ecosystems and drive collaborative innovation.
ای مهرِ دارندهی چراگاههای فراخ! به اسبانِ ما تندی و به تنهای ما نیرو ببخش، تا دشمنانمان را زیر نظر گیریم، آنان را فروکوبیم و هماوردان و دشمنان و بدخواهانمان را به یک زخم از پای درآوریم.
Many people have seen the recent news about
Reform UK party receiving two donations of £36 million each.
Therefore, it is quite a shock to see the party simultaneously
being subject to a [redacted debt collection].
UK law doesn't require a contract to be in writing.
Nigel Farage presents himself as somebody you can have a pint
with. If somebody agrees to pay for a round of drinks you don't
ask them to provide a written contract. Likewise, when
Nigel Farage and other leaders in his party made promises to
pay election expenses, I felt that was like offering to buy a round
of drinks. It was a verbal contract.
The failure to make those payments provided a justification to
begin [redacted]. Does that mean
Nigel Farage can simply pay me the money and exit the [redacted]
procedure? Maybe not. [redacted].
We can find old reports from other
Reform UK legal entities online.
Here are the 2021 accounts. This is the relevant statement where
the auditor contemplates whether money loaned to the party by
Richard Tice could be a risk to solvency:
Material uncertainty related to going concern
We draw attention to the Balance Sheet which indicates that as at 31 December 2021,
the Party had net liabilities of £849,456. As stated in the going concern
accounting policy note, these liabilities consist mainly of directors loans from
Richard Tice and we have received suitable reassurances from him about the intention
for these to help grow the party in the medium term.
When the auditor writes their report for the next set of accounts,
they will have to mention a whole range of scandals much bigger than
that loan.
Remember that most volunteers and donors put in their time and money
and they can not get their time and money back later. Yet
Richard Tice put in his money as a loan, in other words, when
other people contribute money, he gets his money back.
The existence of loans like this helps understand directors'
willingness to accept donations that other parties might
not touch with a ten foot pole.
Notice that
Reform UK announced the mega donations just two weeks before the deadline for
the accounts and auditor's report. Hence my curiosity about whether
the publicity about these donations was meant to either sway the
auditor or distract the public from concerns the auditor will express
in the published report.
We saw the same thing with the notorious Gem of Tanzania.
By coincidence, in November 2025, shortly before the end of
Reform UK's first accounting year, the International Gem Society
published a detailed history of the scandal. News reports claim
the gem was worth little more than £100. Nonetheless,
Wrekin Construction listed it on their balance sheet as an asset
worth £11 million.
When I saw the news about these mega-donations, I felt déjà-vu.
If it sounds too good to be true, maybe it is.
Sub-contractors and suppliers to
Wrekin Construction felt they could give the company favorable
credit terms because the balance sheet filed at Companies House
looked extremely healthy. Some of the suppliers purchased
trade credit insurance and when
Wrekin Construction went bust, the insurance companies had to
reimburse the suppliers who were not paid.
When people see these figures in the accounting documents
and news stories about
Reform UK, they may be fooled to be overoptimistic, in the short
term, about
Reform UK's future prospects.
The new legislation going through the
UK parliament tells us these donations will be converted to loans.
The party will be obliged to repay the money within 30 days.
The directors have known about this new reality since 25 March 2026
but their words and actions suggest they are being stubborn and
behaving like petulant teenagers.
Time for another saturday recap of the week in longer form.
A interesting interrelated issue
A while back we moved our ansible control host to rhel10.
After this move, I noticed that the nightly job we run to run a
--check --diff over all our playbooks was taking a really long
time to finish. I added it to my todo list to look at sometime
but didn't think it was super high priority.
Last week we got some zabbix alerts about disk space on our central
logging host (log01). Usually when this happens, it's caused by some
openshift application crash looping or sending large tracebacks over
and over. However, that was not the case this time, as we had added
some checks to notify if that ever started happening so we could fix
things more quickly.
Looking at the (large) logs, it seemed like it was mostly builders
and mostly ssh-session messages.
Thinking these two issues could somehow be related, we started
digging into the check-diff run first. It seemed that ansible was
connecting to the target hosts, then just disconnecting again
and again in a loop. But why?
TLDR: If you specify multiple facts gathering modules (which we do
because we have one that gathers some python information), it tries
to do them in parallel, but there is a bug and it fails.
So, That was the base cause of both issues. check-diff was slow
because it would get stuck trying to gather facts (and get killed
after 24h by the script), and it was also causing tons of log messages
for each ssh connection which was filling up log01.
A simple:
ansible_facts_parallel: false
Fixed both things.
RHEL10 Database servers
Staging is all done, all servers there are postgresql 18 and rhel10
now. The last one was db-datanommer01.stg, which I did monday. Its
still a complex process, but it seems working and doesn't need a
intermediate rhel9 instance (as long as I am willing to upgrade the
existing one's timescaledb).
So, next thursday we have a outage and I am going to try and
migrate all the production database servers. I'll be glad when
they are all done.
I might try and do db-datnommer production a different day. Its
a lot more complex than the rest and might be good to get out
of the way seperately. Also, it's not super end user facing, so
it can probibly be down for a little while without too much ill
effect. Thats likely to be tuesday or wed.
Mass updates/reboots/outage next week
This is going to be a big one:
We are going to apply firmware updates on servers. This always
makes reboots take a while as they have to apply the firmware
upgrades.
We have some machines that aren't booting with secureboot enabled
and we want to fix those. Sadly that means a boot to setup, enable,
and another boot, which takes a while.
I am going to migrate all the prod database servers over to rhel10.
This is likely to take a while, but not too bad. There's no dump
restore needed, just 'fast' upgrades and shuffling things around
so the old rhel9 instances are retired and the new rhel10 ones take
their place.
Of course eariler in the week we will do staging and any hosts we
can take out of dns, etc... so thursday will mostly just be the bare
metal / vmhosts and their guests that we can't take down without an
outage.
Retour sur la migration UI de SeedboxSync de Bulma vers Bootstrap : pourquoi quitter un écosystème au ralenti, les limites de Bootstrap (Dart Sass, dark mode JS, balise progress) et les gains d'un framework riche en composants.
L'annonce de Portainer 3.0 confirme le virage stratégique de l'éditeur vers Kubernetes et les besoins des entreprises, laissant la version CE sur la branche 2.x. Un changement de cap qui confirme la pertinence de ma récente migration vers Arcane pour la gestion des conteneurs de mon NAS.
This year’s Akademy is over - at least for me. I’m already on a train on my way
back home, but there’s still plenty of people staying in Graz for more days of
hacking and fun. Even though I haven’t contributed to KDE much in the past few
years, I am really glad I decided to go.
First, I want to thank everyone from the organization and local team for
hosting us in Graz and orginzing a great Akademy. I know how much work it is,
so kudos to all of you <3.
I’m really happy that the community is in such a great shape. There’s a lot of
new people participating and contributing, which is a great sign! After all as
Cornelius showed in his talk - this year we have the most
people ever contributing to KDE - and the year is not even over yet!
This year we also voted the new KDE Goals. I am really happy that KDE for
Enterprise goal have been voted in. As someone pointed
out (with a little tongue-in-cheek): we’ve solved gamers, now it’s time to
solve enterprise. Kevin and the team in enioka Haute Couture are already doing
great work on KDE PIM thanks to the Sovereign Tech Fund. They
started with improving my akonadi-e2e-tests experiment and pushing it forward
to a point where it has helped them discover (and fix) many bugs in CalDAV in
IMAP - this is foundational work that everyone will benefit from. It’s
inspiring to see so much activity and many new contributors in KDE PIM again.
I attended another talk about making KDE “lovable” by Eva and
Jan. They discussed many things, but one that stood out to me, especially with
relation to the Enterprise goal, is that we should make sure that the
end-users, those who actually use our software in organizations, feel like they
gained something by migrating away from whatever they were running on before
and were used to. They should feel our software makes their jobs easier, makes
them more efficient and feel like it adapts to their needs - make it not just
usable, but /lovable/. I really liked that thought. How do we make KMail
loveble, though? That’s a tough one…
As for myself, I had a lot of schnitzels over the couple days, took a slide
down from Schlossberg, fixed some bugs and generally had a
great time. I managed to get KMail, KOrganizer and KAddressBook to compile and
run on macOS to the point that I can actually read and write emails. But
there’s a lot of fixes and polish needed still, more on that some other day.
All in all, it was a very fun, very productive and very inspiring Akademy for
me, and I can’t wait to see everyone again.
A somewhat busy week for me, so lets get into it..
RHEL10 Database migrations
So, I had finished off all the staging databases except for one the week before,
so I spent a fair bit of time this last week looking at the last one.
It's a pretty fun case, our db-datanommer.
This is the database that stores all the messages that go accross our message
bus and allows you to search them via datagrepper. Because of the nature of
the data in it, it uses the timescaledb extention on top of postgres.
It's currently (in both staging and production) a rhel9 vm with postgresql 13
and timescaledb 2.10.1.
Before getting into the fun set of constraints, I'll mention that I am a
paranoid sysadmin. This means I always think about 'what would happen if
this migration fails there, or there' So I strongly prefer to leave something
in a state where I can backout to it if something goes wrong. So, in this
case I strongly prefered to just leave the existing vm alone an dmigrate to
a new one, and if something blows up, can just move back to the old one.
So, the constraints were pretty fun here:
timescaledb has a handy chart about which versions support which postgres
versions. 2.10.1 doesn't support 16 or 18. No versions support both 13
and 18. 1 version does support both 13 and 16 however.
rhel9 actually has postgresql-16 available, but as a module. Because it's
a module it makes it hard to build normal rpms against it.
dump and restore of the db would take way way way too long as a pg_dumpall
(sql) dump. The pg_dump formats would be faster, but not all that much because
timescaledb doesn't work with -j (N jobs) on restore.
rhel10 has postgresql16 (default) and 18 available as seperate packages.
When you upgrade from 16 to 18, you need to either enable data page
checksums (running a tool over the db's) or make 18 start without them.
They sound like a really good idea though, so I wanted to enable them
So, in order to do this under all my constraints it would require 3 vm's:
The current one (untouched), another rhel9 one to sync the data to, upgrade
timescaledb on, then sync that to a rhel10 one to upgrade to 16 and then
another timescaledb upgrade and upgrade from 16 to 18.
In the end though, it seems like timescaledb upgrades are pretty smooth and
easy, so I decided (at least in staging) to just upgrade timescaledb to 2.13.1
(which supports both 13 and 16). That allows no intermediate rhel9 vm.
So, thats the plan, but there's more gotchas I hit along the way:
When upgrading from 13 to 16, you have to also have timescaledb from the
13 install installed in the right place for the upgrader to use it.
You also need to modify the template postgresql.conf file the upgrader
users to enable timescaledb, or else when it upgrades it blows up
at the end because there's a missing extension.
Both those last 2 things apply for 16 to 18 too.
The upgrader also helpfully tells you to look at some log when things
fail, but it's the log from the data dir it JUST DELETED BECAUSE IT FAILED!
I ended up reading those logs by running the upgrader under strace. :(
After all that, I think I have a process now. I was going to do the staging
one friday, but I made a stupid mistake (putting the 13 timescaledb.so in the
wrong dir) so I ran out of time. Will move it monday.
Mass firmware update/mass reboot/database migrations
So, with the last database server sorted in staging, time to get production
done. We are tenatively planning an outage for 2026-10-01, the thursday
before final freeze. Hopefully we can get all the databases done then.
Of course this will jinx things, but things have been reasonably quiet
on the scraper front of late. There was some activity where they
were hitting our wiki really hard, but luckily it was reasonably easy
to block them in that case. It did cause problems for other services
however as it caused our proxy network to hit max connections.
Otherwise it's been quite nice not to have to battle them day to day
so much.
I am booting VMs via qemu (no libvirt) and sometimes they don't tell me what IP address they got when booted. To figure it out, considering I know the IP address, I can query the network via the Address Resolution Protocol (ARP)
I know they get address in sequence, so:
ayoung@sut11sys-r112:~/devel/ampvirt$ arp -n | grep -i "52:54:00:70:0c:"
10.76.112.154 ether 52:54:00:70:0c:02 C virbr0
10.76.112.153 ether 52:54:00:70:0c:04 C virbr0
10.76.112.155 ether 52:54:00:70:0c:03 C virbr0
Route requests to /uploads/ internally to check for permissions before
handing off to Nginx to serve the actual file. Fixes
GHSA-4fp9-ph54-5fjw
Improvements
Update django-guardian from 3.4.1 to 3.5.0
Update django-tree-queries from 0.25.1 to 0.26.1
Update tzdata from 2026.3 to 2026.4
Display TestExecution attachments on Test Run page to support the use-case
where attachments have been uploaded via TestExecution.add_attachmment()
API method (Arnoldas Bagdonas)
Small visual rearrangements on login page
Refactoring and testing
Update locust from 2.46.4 to 2.46.5
Remove deprecated field version: from YAML files
Changes since Kiwi TCMS Enterprise v16.4-mt
Based on Kiwi TCMS v16.5
Add PASSWORD_RESET_ENABLED setting
Add restic command inside container
Add mount-s3 command inside container
Remove the social-auth-kerberos add-on
Redirect all login requests through public.schema/accounts/login/
It’s been about 4 months since my last GNOME Foundation update. Time flies. I’m sorry that it’s been so long. I will try to do more regular posts again in the future, but perhaps not at the same tempo as before. While I would love to post every other week, it’s hard to sustain.
With that said, let’s jump in. Given the time since my last post, I’m going to focus on the bigger and more recent news items that have happened at the GNOME Foundation.
New board, new officers
The Foundation’s board elections happen every year, and this year’s election completed in July. The election resulted in a number of changes to the board:
Sri Ramkrishna, Jonathan Blandford and Adrian Vovk joined the board as new/returning directors
Deepa Venkatraman, our treasurer, secured a new two year term
Robert McQueen, Federico Mena Quintero and myself all ceased to be directors (Rob failed to be re-elected, Federico didn’t run, I withdrew part-way through the process)
The election was a difficult one for me personally, and left me reconsidering my involvement in the Foundation. This was not because I lacked motivation or commitment, but because the situation around the election had become untenable for me personally. However, I’ve spent a good deal of time since I withdrew my candidacy thinking about my role at the Foundation, and I’ve concluded that I care about this organisation and the progress we’ve made, and I want to see that work through. Conversations I’ve recently had with members of the community have also given me confidence that we can move forward together. In short: I’m happy to be sticking around.
The new board held its annual meeting in August, which is when officers and committees are appointed for the next 12 months. The Board decided to put me into position as Interim Executive Director, with Sri Ramkrishna taking my place as President. This is a good move from my perspective: it recognises that I’ve been doing a lot of the day to day management work (which I will continue to do), and gives the Board more ability to hold me accountable. Sri stepping into the role of President means that he will be my backup.
Other officer changes include Jonathan coming in as Second Vice-President, Cassidy moving from Vice-Secretary to Secretary, and Adrian stepping up as Vice-Secretary. Our other officers remain in post, with Maria as chair, Deepa as Treasurer, and Arun as Vice-President.
Huge thanks to everyone who volunteered for these positions!
In terms of committees, the Executive Committee had a minor reshuffle, with Jonathan, Adrian, and Sri joining, and Julian and Rob departing. The new members of the exec are already taking on work, which is great, and I’m hopeful for the newly reconstructed committee. The Finance Committee had some slight membership changes, with Rob leaving and Sri joining.
Finance and Operations Director
Last April we opened the search for a new paid team member, to join us as our Finance and Operations Director. There are a number of goals for this new position: to enhance the finance and accounting expertise that we have internally, to lead the development of our internal systems and budgets, to ensure the sustainability of finance and compliance tasks, to manage our fiscally sponsored projects, and more generally take ownership of the business side of the organisation.
We had a huge number of applicants apply for the position, and had some extremely high quality candidates to choose from. After going through several rounds of interviews we selected Dawn Matlak for the role, who we are extremely excited about joining us. Those of you who have read my previous posts might remember Dawn’s name: she initially started working with us as a consultant last year, in order to help us prepare for our first formal audit, which happened in March this year. As part of this work she helped us to transform many of our internal systems and processes. We’re thrilled that she is joining the Foundation on an ongoing basis, and are confident that our internal operations will continue to improve under her stewardship.
Dawn is already doing a small number of hours for us each week, which she will continue to do until she properly starts in the role in November.
Many thanks to Arun and Deepa who helped enormously with the hiring process.
FY27 Budget
The Foundation’s financial year runs from 1 October to 30 September, and each financial year requires a new budget, both for planning and as the basis of reporting and spending authorisation. We have all therefore been working hard on the new budget that will come into effect on 1 October. The new budget has been in the works for a while, and has been a major focus for the board over the past few months. Thankfully we got the initial budget approval done last week at the board’s regular September meeting. We’ll follow-up with a more detailed post about the budget as soon as we’re able, so the community can have some insight into how we’re managing our finances.
Events
With GUADEC 2026 wrapped up, Kristi has turned her attention to the next event in our schedule: GNOME.Asia 2026. This is being held in Terengganu, Malaysia, from 31 October to 2 November. There’s a great venue lined up, and Kristi is busy working on the details with a fantastic local team.
Aside from GNOME.Asia, the other recent focus has been GUADEC 2027. We have a couple of options for locations right now, and are in the process of confirming details before we commit to one of them for next year. We’ll share updates as soon as we have more details confirmed.
Fundraising
The end of the calendar year is an important time for non-profit fundraising, and we are currently busy planning our campaign for the end of 2026. I’ll be posting more about this soon, in particular in relation to the budget, but for now I will say that this campaign is going to be critical for our ability to grow and support the GNOME project.
Other
As ever, many other things have been happening at the Foundation, and there’s too much to go into detail about here. Work on GNOME’s infrastructure and Flathub continues, our back office operation continues with finances and other routine paperwork, and the board continues to discuss our long-term plans.
That’s it for now. Many thanks for reading, and feel free to leave questions in the comments.
On Saturday, August 22, 2026, the Fedora Project joined forces with openSUSE at Data Con LA 2026, hosted on the campus of California State University, Long Beach (CSULB).
Now in its 14th year, Data Con LA is Southern California’s largest gathering of data professionals, students, and practitioners covering data science, AI/ML, and data engineering. While Data Con LA is not a traditional Linux-centric conference, our presence offered a unique, hands-on opportunity to engage a fresh audience of prospective contributors, test our event planning workflows, and showcase Fedora Workstation in action.
As part of our ongoing work to standardize the Fedora Ambassador event pipeline, this report reflects on our operational outcomes, what worked well, and key lessons learned for future event organizers.
1. A Standout Win: “A House with Many Rooms” (Co-Hosting with openSUSE)
Our standout operational victory at Data Con LA was co-locating and sharing table space side-by-side with openSUSE advocates (coordinated with Patrick Finie / mir and Drew Adams).
Rather than maintaining isolated tables, we embraced the philosophy of “A House with Many Rooms.” This cross-community collaboration was an immediate force multiplier:
Shared Energy & Presence: Combining our presence effectively doubled our footprint and visual appeal, turning our shared booth area into a high-energy focal point in the expo area.
Seamless Staffing & Rotations: Having four volunteers across both distributions allowed for seamless shift rotations during peak traffic and lunch breaks, completely preventing booth fatigue.
Cross-Promotion: When attendees visited our table, we engaged them collaboratively by directing people to open source solutions across distros based on their specific technical needs and interests.
For future community organizers planning small-to-medium booths, establishing a shared booth with allied open source projects is an operational model we strongly recommend.
2. Demographics & Lead Engagement
Over the course of the day, our booth engaged approximately 100 visitors (110% of our initial goal), with peak traffic occurring during the post-keynote morning rush (9:30 AM – 11:00 AM) and lunch transitions (12:30 PM – 2:00 PM).
The attendee demographic offered valuable insights into the broader tech ecosystem:
Student & Alumni Presence: The majority of visitors were CSU Long Beach undergraduate and graduate students, alumni, and local data practitioners.
First Encounters with Linux: Roughly 10% of attendees were active Linux users; for the remaining 90%, Data Con LA was their first direct introduction to Linux and Fedora.
Lead Qualification Breakdown:
Hot Leads (30): Inquired specifically about Fedora, visited the website, and expressed interest in installing Fedora Workstation or exploring the Join SIG.
Warm Leads (20): Asked for links to documentation, Fedora Discussion forums, Matrix channels, or local user groups (such as SGV LUG in Pasadena and SFV LUG in Northridge).
General Engagements (10+): Discussed general data industry trends, tech careers, or university studies.
3. The Technical Showcase: Local AI on Fedora Asahi Remix
To connect directly with the conference’s AI/ML focus, we showcased a fully offline, containerized local AI demonstration running on an Apple Silicon laptop.
The Setup
Hardware: 2020 Apple M1 MacBook Air (8 GB RAM) dual-booting macOS.
Software Stack: Fedora-native Podman containers running Ollama alongside Open WebUI, exposing a private, ChatGPT-style web interface at localhost.
Model: llama3.2:1b (sized appropriately for the laptop’s 8 GB memory ceiling).
Why It Resonated
This demonstration served as a major crowd-pleaser across two distinct attendee groups:
Data Professionals & Privacy: Attendees expressed fatigue with commercial operating systems that enforce invasive telemetry and proprietary cloud AI features. Highlighting how Fedora enables private, offline LLM inference with zero data leakage resonated powerfully.
Students on a Budget: CSULB students loved seeing how Linux can revive older, restricted hardware to deliver a capable, subscription-free AI workspace without requiring expensive cloud API tokens.
4. Advice & Lessons for Future Event Owners
If you are planning to organize a small event (under $150) or booth presence in the next six months, here are four practical takeaways from our experience:
Design 100% Offline Demos: Campus and conference Wi-Fi networks are notoriously unreliable, firewalled, or slow. Designing our demo to run entirely inside local Podman containers without requiring an internet connection kept our booth fully functional all day without friction.
Account for Outdoor Environmental Factors: Our booth was located in an outdoor expo space. During the afternoon peak heat, direct sunlight caused our demo laptop to heat up, requiring us to tuck it under banners in the shade. Recommendation: Always confirm booth coverage in advance, and pack brimmed hats, pop-up shade, or cooling accessories if outdoor placement is unavoidable.
The Power of the Daily User Perspective: You do not need to be a kernel developer or upstream maintainer to staff a Fedora booth. Sharing how you use Fedora day-to-day for work, study, or home projects alleviates “imposter syndrome” and provides relatable, authentic guidance that newcomers appreciate.
Keep Swag Requests Lean on Short Timelines: Because our event planning window was short, we kept our Forgejo Mindshare swag request focused strictly on high-impact essentials: stickers, case badges, and pens. Podman and Fedora logo stickers drew in decision-makers and students alike.
5. Next Steps & Wrap-Up
We would like to thank Patrick Finie, Drew Adams, and the openSUSE community for partnering with us, as well as the CSULB organizers for putting together a fantastic event.
Following Data Con LA, our team of Ambassadors Perry Rivera and Rob McBryde are incorporating these lessons directly into the new Small Events Standard Operating Procedure (SOP) and preparing for upcoming community participation at SCaLE. Our intention is to share and publish this information in the Fedora Docs website so that other event owners in the Fedora community may benefit from common wisdom from others who have done this work before.
Want to get involved? Connect with us on Fedora Discussion or drop by the #ambassadors:fedoraproject.org Matrix channel!
نسخه بتای Fedora Linux 45 از امروز، ۱۵ سپتامبر ۲۰۲۶، در دسترس علاقهمندان و آزمایشکنندگان قرار گرفته است. کاربران میتوانند نسخه بتای فدورا ۴۵ را دریافت کرده و پیش از انتشار نسخه نهایی، قابلیتها و تغییرات جدید این نگارش را آزمایش کنند. فدورا همچنین امکان ارتقای سیستمهای موجود به نسخه بتا را از طریق ابزار DNF […]
در بخش ۱ به صورت کلی Podman معرفی شد و نحوه کارکرد آن توضیح داده شد. در این مطلب قصد داریم تا آن را نصب و استفاده کنیم. نصب Podman در فدورا لینوکس در فدورا لینوکس معمولا پادمن به صورت پیش فرض نصب می باشد، ولی به هر حال روش نصب به صورت زیر می […]
It’s been 7 years since I last posted such a banner, and just today I remembered how I was always
excited about this kind of posts, so here we go. I’ve also been to Akademy in Würzburg 2 years ago,
but didn’t post the banner for some reason (silly me!).
I haven’t really contributed to KDE for quite a while, but Akademy is always worth attending, even
just to meet old friends again and make some new ones. Plus this year is KDE’s 30th birthday. KDE
has been such a huge part of my life, so I am not going to miss such an anniversary.
Andreas Gabriel Berbescu has reported several root privilege escalation vulnerabilities in various NetworkManager VPN plugins. If the VPN plugin is installed, then an unprivileged user can escalate to root by loading a malicious VPN configuration file:
September 25, 2026 Update: There is also CVE-2026-75131 and CVE-2026-75883 for NetworkManager-l2tp. I didn’t know about this because it is not a GNOME project.
While most obviously bad for multi-user systems, root privilege escalation is also a serious defense in depth problem for single user systems. You are vulnerable if you have the VPN plugin installed; it does not matter whether you actually use it or not.
These are not vulnerabilities in NetworkManager itself. The VPN plugins are each separate projects, with their own separate maintainers, hosted by GNOME rather than by freedesktop.org. The status of each project is a little different:
$ spctl -a -v bin/SimpleShell.app bin/SimpleShell.app: accepted source=Notarized Developer ID
I was searching for a good quality but simple free open terminal for MacOS and I couldn’t really find what I was looking for interface wise (I used to use iTerm for a long time but it started getting more and more bloated and laggy on me – using up a lot of system power on battery and I don’t want all that AI stuff baked in).
I started a project earlier this year but got stuck on it because I was trying to implement a basic ANSI parser which was a mistake on my part. I didn’t realize how incredibly complicated that finite state machine would be, esp with bash and ansi apps sending complicated instructions into the machine! I then asked Google AI for help and it pointed me to a GitHub page that hosted a libvterm (from vim) that was compatible with Objective-C.
I’ve been working on this app non-stop for the last 9 days now and I only have the basics covered, I didn’t realize how much code it took just to make a basic text processing input/output app but I think this is one of my more complicated code bases (possibly TurnTable is the other app of mine that might be more complicated but that one is in Swift).
I still have a lot more work on my todo list for and I will continue development on it now that I got ANSI parsing to work, the rest is just mainly ViewController and functionality features. I targeted it for the bash shell so I don’t know if it works with other shells but this is just my first release post about it.
Layout List
Date (Month / Day)
Terminal (Rows / Cols)
Network (LAN / WAN)
System (CPU / RAM / NET)
WiFi (Freq / Rate)
Highest Process (PID / MEM)
Shell PS1 Prompt Info (User / Directory)
Dynamic Prompt Prefix Information Insertion (Any scriptable line items)
Feature List
Simple Clean Minimal Functional Design
Window / View / Layout — Colors / Opacity / Blur
Selector / Highlighter Separator Character List (Automation)
Auto Copy On Selection (Automation)
Single-Line Paste Manual Enter (Safety)
Multi-Line Paste Prevention Protection (Safety)
Huge-Line Paste Limitation Protection (Safety)
Multi-Window / Multi-Tab
Left Aligned Tab Titles With Monospace Font (Readability)
Scriptable Standard Window And Tab Title Text
Scriptable Dynamic Shell Prompt Prefix (Found No Where Else!)
Always Visible Command Line Prompt (Found No Where Else!)
Live System Information Stats Bar
Separated Open / Close Tab Buttons To Reduce Accidental Closures
Multi-Tab Window Detection To Reduce Accidental Closures
Dual Output Modes (line/ansi) With Separated Input Prompt (comd)
Smooth Scroll Locking
Clear Console Command
Easy Use Shortcut Keys (cmd/opt + left/right)
Regular Expression Search
Basic Output Text Colors
Basic Process Job Detection
Transparent Rounded Cursor Block!
Dock Icon!!
Todo List
Add settings for font text type / size
Add settings for ansi color codes
Limitation List
Tabs Can’t Be Transferred To Other Windows
Only Reopens One Window / Tab On Launch
No Previous History Or Information Is Restored
Warning List
User Beware: This is still a brand new framework and there may be bugs (or at the very least incompatibilities)!
Découvrez les nouveautés de SeedboxSync v4.1 : intégration d'un système d'authentification natif et OIDC (SSO), support de Gravatar, gestion des utilisateurs en CLI, formulaires Flask-WTForm et transition vers Peewee-Migrate.
Another saturday, time for another recap of interesting things in longer form.
RHEL10 database migrations
I managed to migrate all but one database server in staging.
No particular problems with those and they are all on postgresql 18 now with
data page checksums enabled (well, except the single mariadb instance,
and it's on 10.11.18). Hopefully I can get the production ones
done in the next outage we have (probibly the week before final freeze).
The last staging database server is more interesting: db-datanommer01.stg
This is using timescaledb on top of postgres and is currently the rhel9
default version: 13.
After looking around, I think this one is doable, but needs another step:
sync a data backup off the existing server
upgrade it to postgresql 16
enable data page checksums
install a new rhel10 vm
sync the data to it
upgrade to 18
install the correct timescaledb extension
take down the old instance and swap in the new
I think this will all work, just an extra 13->16 jump. I will try it out
in staging next week. I'm also a bit worried about how long it will take
to generate all those checksums. The datanommer db's are really large.
However, if we can do it I would love to as it's a very nice feature.
Doing staging should at least give us an idea.
Fedora 45 Beta is go for release next tuesday ( 2026-09-15 )
Looks like we are go for fedora 45 beta next week.
I hope everyone will test it out and help us iron out
any problems before the final release.
It’s been another fantastic year for Google Summer of Code with GNOME! This year, six contributors worked on a range of interesting projects across our ecosystem.
Our contributors have been blogging about their progress on Planet GNOME throughout the summer. In case you missed their updates, here is a breakdown of what they have worked on:
This would not have been possible without the support of our community mentors. A huge thank you to Jonathan Blandford, Federico Mena Quintero, Alex Băluț, Yatin, Adrian Vovk, Jonas Ådahl, Robert Mader, Carlos Garnacho, and Philip Chimento. Mentoring takes a lot of time and energy, and it plays a vital role in onboarding new contributors to our community.
If you are a GNOME developer and interested in mentoring a project next year, you can already start working on your project ideas and submit them at gitlab.gnome.org/Teams/internship/project-ideas.
If you are a newcomer interested in starting your journey toward becoming a GNOME contributor, check out gsoc.gnome.org and stay tuned to Planet GNOME and our social media channels for updates on the 2027 program!
Pourquoi et comment j'ai remplacé Jellystat par Jellydash pour le suivi des statistiques de mon serveur Jellyfin. Retour d'expérience sur la découverte de cet outil moderne, léger et prometteur repéré dans la newsletter selfh.st.
We are happy to announce that newly purchased
Private Tenant
subscriptions will include raw data access as we work towards removing
vendor lock-in for our SaaS customers!
What's new
Database export in SQL format suitable for the Postgres database engine
All attachments uploaded to a private tenant namespace will be included
Multiple storage region/vendor options available subject to technical compatibility
All data is stored encrypted and may be downloaded using a popular open source tool
Limitations
Export frequency: 1/day
Exports in storage: last 3 days (rolling)
Retention period: 7 days (rolling)
Existing subscriptions may upgrade if they wish to unlock this service
IMPORTANT: Due to technical and security considerations we cannot provide
real-time access to the underlying database cluster however we are working in that direction!
We are also researching the technicalities behind enabling Bring Your Own Storage for
file uploads!
You can find the Private Tenant subscription in the
Subscriptions section on our main page!
Thank you for using Kiwi TCMS. If you like what we're doing please help us grow:
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.11RC1 are available
as base packages in the remi-modular-test for Fedora 43-45 and Enterprise Linux≥ 8
as SCL in remi-test repository
RPMs of PHP version 8.4.26RC1 are available
as base packages in the remi-modular-test for Fedora 43-45 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.
After much back and forth and hoops jumping, I can finally reveal nouveau/nvk running on a NVIDIA Spark box.
This is running on a version of nouveau[1] that has
a) ported to the 610 NVIDIA firmware
b) a bunch of display rework from Moham
c) a bunch of 0 VRAM and L2 cache handling fixes
d) spark boot support
e) spark display support
and NVK[2] with patches to handle gb10 depth/stencil differences and 0 VRAM support.
I'm not sure how best to upstream it all, it's 100 patches and a new firmware which might mean it's a wait for nova type situation, but I just wanted to see it work.
Previously only the kiwitcms/enterprise image variant was guaranteed to be built on top of
Red Hat's Universal Base Image! This guarantee is now explicitly extended to
kiwitcms/version!
There is NO such guarantee for the Kiwi TCMS Community Edition container image!
Thank you for using Kiwi TCMS. If you like what we're doing please help us grow:
ebtables -t nat -A PREROUTING -i wifi+ -p IPv4 --ip-proto udp --ip-sport 67 -j DROP
~
[kmod-nft-bridge]
table bridge ethernet {
chain PREROUTING {
type filter hook prerouting priority filter; policy accept;
iifname "wifi*" arp operation reply arp saddr ether != 00:11:22:33:44:00 arp saddr ip 192.168.1.1 counter drop
iifname "wifi*" ip protocol udp udp sport 67 counter drop
}
}
~
OpenWRT Config
wireless.default_radio0.isolate='1'
wireless.default_radio0.bridge_isolate='1'
~
Untested Commands
bridge link set dev wlan0 hairpin off isolated on
ebtables -A FORWARD -i wlan0 -o wlan0 -j DROP
~
Note: Most of these commands won’t work on UAP-U7-PRO APs I believe due to hardware based frame/packet routing/forwarding – I have since enabled arp-proxy and dhcp-snooping in the UI network controller application, however, I don’t see them working either, possibly because I am running a third-party gateway device. I have finally enabled client-isolation, which as tested, solves the ARP and DHCP attacks completely and forces client-to-client communication through the router instead for even further filtering!
I have first since used a couple web based AI systems for different specific tech things and they are pretty useful if you do the extra work to verify and modify what they are telling you. I’ve found that Google Gemini AI is really good a general tech questions and configuration items (with looking it over and understanding it and modifying it of course for your specific needs) and Claude Sonnet AI is really amazing at verifying that your code is correct and other more in-depth programming related tasks (for example, memory allocation and pointer handling and file descriptor tracking).
I’ve been using these systems lightly whenever I get stuck and they are able to find the exact code snippets I was looking for to complete the rest of my projects – prompt engineering!
Tips:
Sometimes it will loop through repeated answers if it gets stuck on one specific solution
Sometimes the quality of a given answer decreases the longer that you interact with it
You need to try and give as much extra debugging info that you can for it to properly figure things out or update its answer
It’s better to ask it small specific questions and break the problem apart into pieces and then tailor a customized solution
Sometimes it gets stuck on one specific solution that won’t work in the end but if you try to ask it how to approach the problem from a different angle it can provide steps for you to get extra info for it to either re-fine or re-suggest its solution
Note: It’s a shame that AI resources are being used on social or political issues rather than solving technology and scientific issues to help progress humanity. I’m still amazed that I was able to feed a 1000 lines of C code to Claude as a test and it was able to determine the components purposes and the network proxy applications of it all…
Google AI seems a little more friendly and personable whereas Claude is more on task and professional ha
I wanted to eventually experiment with using the AES hardware instruction but for the ARM architecture because there are ways to turn block ciphers into stream ciphers for future usage. There appears to be a C header include file that exists on both Mac and Ubuntu (arm_neon.h) and you can compile this small C program file with standard gcc options (no special arguments needed). The hardware instruction method names appear very cryptic, however, they do seem to work when I tested the hex output against other sites!
This week seemed to have a lot of small irq's all around.
That said, I did make some progress on a few things:
RHEL10 migrations: databases
Next up on the migration train: databases. It turns out we already
had one database server in staging moved to rhel10, but it was using
the default postgresql 16 and since I am going to the trouble to migrate
things to a new os, might as well move them to newer postgresql too.
postgresql 18 makes data page checksums default. You can disable them
at startup if you really want to, but they seem like a really good idea
to enable. So, I took db-koji01.stg down and added checksums and it took
around 45minutes. Not super great, but not nearly as bad as it could be.
Then, the upgrade to 18 was super fast and painless.
I did some work in our ansible repo to set up rhel10 hosts with postgresql18
to start with and created a db-fas02.stg to migrate that to.
The rest of these servers will follow basically this pattern:
Setup a rhel10/postgresql18 02 vm for each server
Sync data from rhel9 one.
Stop rhel9 one (OUTAGE)
Sync data again from rhel9 one.
Enable data page checksums
Migrate from 16 to 18
Profit
I hope to get the staging ones all done next week and find any issues,
then we can look at scheduling an outage after Beta freeze to do all the
production ones.
Laptop Battery replacement
My lenovo slim7x battery was getting pretty pathetic. It was 2 years old
and it's max full capacity was something like 35% of design full and
sometimes it was now refusing to charge without a reboot.
So, I ordered a new battery and installed it this last week.
This laptop is anoying to work on because, while there are screws on the
bottom panel, it's also held on by clips. So you have to pry it off and
it sounds like you are breaking it while doing so. Anoying.
Also on this laptop they routed all the cables around the battery.
The battery has cable guides all around it. So, to replace the battery
you have to move all those cables carefully and slide the old battery out
and new one in, along with unplugging the bluetooth and wifi antennas,
and disconnecting/connecting the battery connector.
I did manage to do it, but it took more time that I thought it would.
While I had the machine open I swapped the windows drive I had back
in and updated the firmware (which there's no way to do from linux).
It was quite a pain. windows took quite a while to notice that it
was not 2024 and that it should check what _current_ updates were
available. Did manage it in the end. I don't know what effect the newer
firmware has, everything still works the same as far as I can tell.
Fedora 45 beta rc's
We have started making rc's for beta. That sure reads weird, but
if you are able, please do test and file bugs.
Authentication issues
There's one weird auth issue I am aware of. Thats where services
with keytabs are sometimes getting permission denied. It seems to be
somehow some differing config on two of our ipa servers.
Thats being tracked in https://forge.fedoraproject.org/infra/tickets/issues/13539
I am not aware of any other issues remaining.
So, if you hit something, please do file a ticket and include enough
information for us to try and fix it. ie, time/date, exactly what you were
trying to login to, exactly what error message you got, etc.
One of the hot topics in the last months has been the use of “AI” — which
usually means using LLMs (Large Language Models).
After a big push at work to adopt “AI”, it took me some time to find a good use
of it in my daily workflow.
Rewriting software
One of most popular ways of using “AI” is rewriting software. I know people
having old games ported from one retro platform to another this way.
However, the low barrier to entry gave many people a way to jump in which did
not end well…
As a result, countless projects have stopped accepting merge requests because so
many of them were nothing more than “AI slop” (aka “worthless junk not even
worth looking at”).
I would not send anything like that to anyone for review. Far too messy.
Going through it was painful but I got what I asked for. And this was a result
of several prompts and manual changes.
Fixing packages
As you know, my work is mostly around building packages. I have worked on Arm,
AArch64, ppc64le, s390x and now RISC-V. I fixed countless packages by hand,
going through their source and finding out why they failed and how to get them
building on target platforms.
After my last vacation I decided to check how an LLM would help with it.
I fetched the package, unpacked the sources (fedpkg prep), fetched the
build.log file from the latest failed build, and ran Claude with one, simple prompt:
Look at build.log and source and find out why it does not build on risc-v.
The amount of time I had to wait and output to read varied from package to
package. Sometimes build logs from other Fedora architectures were needed,
sometimes a few build attempts. At the end I had a patch which made the package
buildable on the RISC-V architecture.
Types of fixes
Some fixes were simple, like
fastnetmon where
a change in the link order was the only thing needed.
Some were funny, like GNU Data Language
where fixing RISC-V fixed it for AArch64 as well. This made the build fail, as
some tests, which were expected to fail, passed.
Others were related to differences between RISC-V (RV64GC) floating-point unit
compared to other architectures. Such “simple” things like “are we dividing
by zero” can be a problem.
Things I do not send
There were also packages for which I got some patches and never sent them
neither upstream nor to the package maintainer.
Those were ones I did not understand. For instance, a patch changed how the “R”
language handles “NA and NaN” numbers. It was yet another issue related
to how RISC-V FPU works. Also it was so cryptic that I looked at code and had no
idea what I was looking at.
The final question
I understand FOSS developers who refuse to accept any “AI generated” changes.
There is too much “AI slop” being submitted. At the same time I wonder where
their limit is.
Would they merge patch below or not? And would presence of the “Assisted-by:
LLM” line make them refuse this patch or not? Will they accept it without such line?
Subject: [PATCH] Fix abseil link order for ld.bfd
Move absl:: libraries after gRPC in fastnetmon_api_client link list.
ld.bfd (used on riscv64) is a single-pass linker and needs dependees
before dependencies.
Assisted-by: LLM
---
src/CMakeLists.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 10caf4c6..5bde9fcc 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -800,10 +800,6 @@ if (ENABLE_GOBGP_SUPPORT)
add_executable(fastnetmon_api_client fastnetmon_api_client.cpp)
- if (LINK_WITH_ABSL)
- target_link_libraries(fastnetmon_api_client absl::base absl::synchronization)
- endif()
-
# We use another way to specify dependencies for Windows as our standard approach clearly does not work
# https://www.f-ax.de/dev/2020/11/08/grpc-plugin-cmake-support.html
if (${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
@@ -819,6 +815,10 @@ if (ENABLE_GOBGP_SUPPORT)
target_link_libraries(fastnetmon_api_client protobuf::libprotobuf)
+ if (LINK_WITH_ABSL)
+ target_link_libraries(fastnetmon_api_client absl::base absl::synchronization)
+ endif()
+
if (KAFKA_SUPPORT)
target_link_libraries(fastnetmon ${LIBKAFKA_CPP_LIBRARY_PATH})
endif()
I would accept it. Because for me, despite the origin of that patch, it is a
very simple change to review.
Once again, GNOME is considering participating in the Outreachy internship program. Outreachy provides internships to people subject to systemic bias and impacted by under-representation in the tech industry where they live.
Outreachy internships are funded by the participating communities. While the GNOME Foundation has not yet finalized the budget for this cohort, having a strong list of proposed projects and available mentors helps the Board decide how many slots to fund.
Project ideas will be selected based on available funding and their relevance to the overall goals of the GNOME project. Project selection will be handled by Matthias Clasen, Allan Day, and Sri Ramkrishna.
If you are a GNOME developer/maintainer available for mentoring between December 2026 and March 2027, please submit a project proposal at gitlab.gnome.org/Teams/internship/project-ideas as soon as possible (by September 11).
It’s hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you’re done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you’re not planning to disclose the issue report within the next few months, it should probably already already be public.
For GNOME, I disclose issues whenever a merge request has been created or a fix lands in the git repo, or 30 days after the issue was reported, whichever comes first. Your project might prefer to wait until the fix is released before disclosing, especially if you fear that a vulnerability might actually be exploited during the window between the fix and release. Whatever you choose, please don’t forget about it and leave the issue report confidential forever. That’s not fair to your project’s users. Even if not many people will take the time to look, users should at least have a chance to see reported issues.
For a while now, the fingerprint management UI in GNOME Settings (gnome-control-center) has felt outdated. While it worked, the layout and enrollment flow hadn’t kept up with the rest of GNOME’s modern interface updates.
I am happy that during the GNOME 51 development cycle we managed to address that. Allan Day, Marco Trevisan, and myself worked on modernizing the interface. There’s still more work to do in the UI and in fprintd, but what we will ship in 51 is already a great step forward.
Historically, the fingerprint dialog in User Settings was stuck on a GTK3-style design. Even after being ported to GTK4, conceptually it remained unchanged. Beyond looking out of place alongside Libadwaita-based settings panels, it suffered from responsiveness and accessibility issues that made it difficult for some users to enroll their prints.
Screenshot of the Fingerprint Authentication dialog
The new fingerprint management dialog uses a standard boxed list displaying your enrolled fingers. From here, each enrolled finger can be removed individually.
Clicking the “Add Fingerprint” button starts the finger enrollment process. First, you choose one of the unused finger options to enroll. From there, an assistant guides you through the scanning process. As you place your finger on the reader, the UI detects the touch and provides feedback on whether it was read correctly. You continue touching the reader until enough samples have been collected (the exact number depends on your reader’s driver). Once the progress bar fills, your finger is ready for authentication.
Screenshot of a fingerprint enrollment
This is only one of the improvements that GNOME 51 is bringing. As with everything in GNOME, we will continue gathering user feedback and making iterations over time. There are already more fingerprint features in the pipeline, such as renaming enrolled fingers and verifying individual prints. Stay tuned!
I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
If your agentic workload involves the agent being able to run arbitrary code
(like bash or equivalent), then you should not use a “LLM as part of your
app” framework like LangChain,
BeeAI,
OGX etc. Instead, run OpenCode, goose, or another general coding agent
inside a sandbox such as OpenShell.
Sandboxing limits what the agent can access directly. For privileged effects,
it is best augmented with a pattern like
safe outputs: the
agent emits a structured, unprivileged request that separately trusted code
validates and applies.
A compact decision tree
Can it run bash or arbitrary code?
├─ Yes → Run a generic agent in a sandbox
└─ No → Are you *really* sure *all* of your tool calls (MCP or builtin) don't accidentally expose "execute arbitrary code"?
├─ Yes → OK, maybe LangChain or equivalent makes sense
└─ No → Goto start
I also think the builtin sandboxing in most agent tools (like Claude Code
and Gemini CLI) is a bad idea, and it’s better to just ensure the entire
thing is sandboxed.
Related to all of this, a key thing anyone making an “agent” needs to ask is “how is this different
from just writing an agent skill”. From my
previous post
you’ll know that I think GitHub Agentic Workflows is a good reference baseline
for applying agentic AI (background/task oriented) safely and effectively. And there an “agent” is
almost exactly just an agent skill, but with a bit of YAML defining its integration
with the outer system.
Why should it be harder than that? I just don’t see it making sense for custom agents written in frameworks like
LangChain to proliferate in most use cases. Sure you can use LLMs to generate
it, but it’s even more secure and understandable to not have that code at all.
Even for the use case of an interactive chat bot, do you really need a custom
app versus just MCP tools for an already generic frontend? I doubt it.
I don’t think it makes sense for most organizations to have proliferation of custom bespoke
agents like these LangChain-style frameworks encourage. Skills and sandboxed
generic agents are just easier to understand and work with.
# Linux # Printer Brother_T420W running with Linux (aarch64) + box64 + cups filter + modified ppd # Status: working
=> uncompress opt-brother.tar.gz to /opt - final path = /opt/brother
=> copy /opt/brother/br-box64-filter to /usr/lib/cups/filter/br-box64-filter * make sure it is executable: chmod +x /usr/lib/cups/filter/br-box64-filter * this filter is a wrapper for the Brother LPD filter, which is a x86_64 binary * it uses box64 to run the x86_64 binary on aarch64 (rpi5 in my case) * if you try to use ./lpd/x86_64/brdcpt420wfilter directly, it will fail with "wrong architecture" error * DietPi v10.6.2 (Debian 13.6) + [BOX64] Box64 with Dynarec v0.3.4 nogit built on Apr 24 2025 09:54:47 * the "key" thing is to keep the A4 Geometry: 2480x3508 (some wrappers are changing it to 2480x3507, which is wrong)
=> key files under /opt/brother: - /opt/brother/Printers/dcpt420w/inf/brdcpt420wrc -changed PageSize=Letter to PageSize=A4
- /opt/brother/Printers/dcpt420w/cupswrapper/brother_dcpt420w_printer_en.ppd - changed from *cupsFilter: "application/vnd.cups-postscript 0 brother_lpdwrapper_dcpt420w" - to. *cupsFilter: "application/pdf 0 br-box64-filter"
- copy /opt/brother/Printers/dcpt420w/cupswrapper/brother_dcpt420w_printer_en.ppd to /etc/cups/ppd/Brother_T420W.ppd
# V2 => Easiest path for Linux aarch64, avoid use of box64 and Brother # x86_64 filter, use IPP (no everywhere) driverless printing instead # # Brother_T420W - V1 # → Brother proprietary LPD + box64 # → maximum Brother specific compatibility
# Brother_T420W_IPP - V2 # → native CUPS driverless # → PWG Raster over IPP # → no x86_64 emulation
Open source communities run on contribution, and contribution runs on documentation, storytelling, and knowledge sharing. At the Fedora Project, that means the Fedora Community Blog and Fedora Magazine, two publications that give contributors a voice and give the community a way to stay informed, inspired, and connected.
This year, as part of my internship with the Fedora CommOps team at Red Hat Ireland, I got to experience that firsthand. Publishing 11 articles, running editorial campaigns, and coordinating content across sprints gave me a deep appreciation for how much thought goes into keeping Fedora’s editorial standards consistent and how much easier that journey could be for new contributors with the right tool in hand.
That’s exactly what my fellow intern Gonothi built during his Outreachy internship with the Fedora Project. In our final sprint together, we decided to share it with the community because tools that make contributions more accessible deserve to be heard. With that context in mind, I’ll hand over to Gonothi to walk you through what he built and why.
What I built and why
My name is Gonothi, and I’m an Outreachy intern within the Fedora Project. The tool I built is called editorial-guide-ramalama, a Retrieval-Augmented Generation (RAG) assistant that reads Fedora’s actual editorial guidelines and published articles, then checks your draft against them. It tells you whether your article meets the standards and exactly what to fix if it doesn’t.
A regular chatbot would guess. RAG grounds every answer in the actual guidelines. When the tool flags a problem, it cites the specific guideline and gives you an actionable fix. Not “this looks off”- but “your article is missing the Read More tag, which is required per the Magazine guidelines.”
RamaLama is the engine behind the whole tool, and it’s a big part of why this project works the way it does. It runs open models locally as OCI containers, the same container tooling Fedora already uses, so there’s no API key, no external service, and no data leaving the machine, which keeps everything private and fully reproducible. It also has RAG built in: RamaLama handles the ingestion, chunking, and retrieval itself (running Docling internally to parse and chunk the guidelines), so I don’t have to wire together a separate vector pipeline. That combination of local inference, OCI-container packaging, and built-in RAG is what lets the tool ship as a single image that anyone can pull from Quay and run.
How it works
The tool supports both Fedora publications, Fedora Magazine and the Fedora Community Blog, each with its own editorial guidelines loaded as the primary source the model checks against. Switch publications in the sidebar, and the guidelines change accordingly.
The stack is built on RamaLama, Docling, Quay, and Streamlit, with small GPT-Generated Unified Format (GGUF) models benchmarked for quality versus size. The pipeline works like this:
Articles are pulled from both publications via the WordPress REST API; no static files are committed, and the corpus is always rebuilt from source and stays reproducible. RamaLama RAG runs Docling internally to parse and chunk the documents into a vector store, packaged as OCI images published to Quay at quay.io/fedora/editorial-guide-ramalama. To run a check, pull the relevant image and use either the Streamlit interface or the terminal; no build step required.
Paste a draft that meets the Magazine’s standards, and the model confirms compliance, citing the relevant guideline. Paste one with known issues, a missing featured image, a missing Read More tag, and it flags each problem with an actionable fix.
One honest note: small local models have limits. editorial-guide-ramalama is great for catching common issues before submission. It is not a replacement for a human editor, and it doesn’t try to be.
Why the open source community should care
What strikes me most about this project is not just what it does technically, but what it represents for contributor onboarding in open source communities. One of the biggest barriers for new Fedora contributors isn’t motivation; it’s knowing the unwritten rules. Editorial guidelines, packaging standards, community norms these exist, but they’re scattered, and learning them through rejection is discouraging.
Tools like editorial-guide-ramalama lower that barrier. They don’t replace human editors or community knowledge; instead, they give new contributors a first pass, a way to self-check before they submit, and a way to learn the guidelines through doing rather than through trial and error. That’s exactly the kind of tooling that makes open source communities more accessible.
What comes next
This mini-project was the proof of concept that validated the RAG approach for Fedora editorial documentation. The same architecture is now feeding into a larger project applying RAG to RPM packaging guidelines, a higher-stakes domain where grounded, local, open-model AI can help contributors get packaging right.
The code is on the Fedora Forge at ai-ml/editorial-guide-ramalama. Pull the image from Quay and try it on your next draft before you submit.
Try it yourself
The tool is live and available now. Pull the image from Quay, paste your draft, and see what it says. If you’re a new contributor, nervous about your first article, this was built for you.
Thank you to the Fedora community, our mentors Justin Wheeler, Dominik Kawka, and Carol Chen, and Outreachy for making this internship possible.
In my last post, I talked about the
value GitHub provides to FOSS, while arguing that we should avoid deep
dependency on it.
Now let’s talk about agentic AI (LLMs).
TL;DR: I think GitHub Agentic Workflows
is a new minimum quality bar that anyone having hosted agents operate on a git
repository should strive to meet. It’s FOSS (unlike the built-in Copilot
stuff) and pretty well designed in my opinion especially from
a security point of view.
One background opinion I have here is that agentic AI is a strong reason to go even
more deeply into “git-ops” style workflows. Having the ability
to audit, verify (CI) and include a rationale for changes to things
that aren’t necessarily software even (like a team’s travel budget)
make even more sense in a world of agents.
OK you’re using git already, now let’s say you want to use agentic AI.
There are rather a lot of solutions to this =) I want to narrow
in first on “hosted” workflows (as opposed to just spinning up
opencode/claude/codex/whatever on your laptop).
A simple scenario here is “mostly readonly with one write output” flows,
which include:
PR reviews
CI failure diagnosis
Duplicate issue detection
etc.
The more complex scenarios are “issue to PR” style flows, or intermixing
CI and AI (e.g. having an agent run during a CI run after it fails
but before the VMs/containers are torn down and being able to do some
live debugging).
There’s of course plenty of third party services (mostly proprietary)
that will do much of this. Today on GitHub you can assign an issue to Copilot
for example, etc.
GitHub Agentic Workflows is simply a compiler that outputs GitHub Actions
that run in the context of your repository. Aside from the inference
endpoint, there’s no proprietary black boxes (also assuming you are using a FOSS
tool inside, like Codex but not Claude Code) etc.
What the compiler takes as input is a Markdown prompt that is very much
similar to an agent skill with YAML
frontmatter that defines its integration with GitHub such as
event triggering – but especially key is restrictions on its output.
There’s a lot to like about this. As part of my job lately I’ve
had to look over what other people are doing in this space, and I have
to say there’s people doing things that are worse than this. In
some cases significantly worse (mostly less secure).
Let’s say you want to implement a duplicate issue detector.
A serious problem with all agentic AI is prompt injection.
It’s easy for someone to encode malicious instructions in an issue they
file, and an agent can easily run those. If you’re running this issue
triage as e.g. an agent skill from your laptop with full credentials,
you can easily get your account taken over.
But the problem is the “most obvious” way to do this stuff by e.g.
writing a GitHub Action with a GH_TOKEN and the following permissions
will allow writing to all issues:
permissions:
issues: write
If e.g. a person prompt injects an agent and says “by the way this project
is archived, close all the issues” an agent might just act on that!
And for “issue to PR” style workflows, the contents: write permission to a token is very powerful.
The safe outputs portion
of GH-AW is very well designed in this respect, greatly limiting the blast
radius of a compromised agent (e.g. the duplicate issue detector can
add at most one comment, not close other issues etc.)
For public repositories, GH-AW also has a concept of an “integrity threshold” when
reading from GitHub itself and the default is approved, so it the agent will not
even see issues from new or unaffiliated contributors. For this use case, we
have to remove that filter, but it’s balanced by restricting the output.
Prompt injection can also leak the API key you use to access the inference
endpoint – definitely not something you want to be surprised by when you
get the bill later that month. GH-AW runs an actions VM as normal,
but the agent runs in an OpenShell-like
sandbox (it’s not actually OpenShell, that’s a whole other discussion!)
Now, I’m not saying all agentic AI should be GH-AW; in addition to
the advantages above, it has a whole host of downsides. In particular
it’s not at all designed to be interactive and certainly there are many
use cases where that’s much more efficient, especially research/planning,
some types of debugging etc.
A pattern I expect to emerge is that these types of “less structured/organic/interactive/local”
flows end up delegating some work to per-repository workflows. For example
a weekly planning session may result in filing issues, which get driven to completion
via a GH-AW style flow in each repo.
Further hybrids are possible of course, nothing truly stops one from having a
GH-AW style flow send an interactive question to a human via a MCP tool
or equivalent. But I don’t think I’d want to do that personally, I’d rather
make it easier to turn a whole session dynamically interactive, kind of like
how today one can use things like the tmate action
to log into a runner.
GH-AW definitely has its issues; one thing is that it’s annoying to reproduce the sandboxing outside
of a GHA run. There’s also a really high latency to each run because it
involves spinning up not just a GHA runner, but also downloading and provisioning
the container agent wrappers etc. That’s for good security reasons overall, and
anyone doing something else should be able to justify the security tradeoffs.
Just to restate the conclusion: I think GitHub Agentic Workflows is a good
reference baseline for a safe way to add agentic workflows to a GitHub
hosted repository, and everyone doing something similar should include
a comparison with it at least. If not, take some of the code: the “safe
outputs” stuff is reasonably easy to use in other systems too.
The question of using proprietary tools to build FOSS has always been
one of the tension points in our community. One of the most prominent
proprietary tools is github.com and the non-FOSS parts of gitlab.com
(and a longer tail of other platforms).
A while ago I came across Give Up GitHub
from the Software Freedom Conservancy which is on one side of this. My opinion remains
nuanced and split. One I think few people would argue with is that there’s been
enormous value provided to FOSS by the $0 github.com (and gitlab.com etc) services.
Just the basic hosting of git infrastructure, issue tracking and other ancillary things (discussions, etc)
but especially GitHub Actions.
There are a lot of critical projects out there getting by with the $0
“free/personal organization” infrastructure. It’s actually plenty for
most projects (e.g. mature language libraries).
And while GitHub hasn’t been shy about pushing into the web interface
things like Copilot (a proprietary agent framework) – in my opinion
the platform still generally hasn’t been subject to
platform decay.
I mean, there’s no advertisements (which probably wouldn’t work
because people would use custom interfaces talking to the API anyways).
This could of course change literally tomorrow; or next month, etc. But my gut says
that at the current time Microsoft is OK funding github.com just
to provide reliable infrastructure for their own teams, and those using
it at large scale on premise probably provide enough income to offset
the loss-leader economics for now.
I personally believe in (and argue for at my employer) avoiding a truly
deep dependency on any one (proprietary) service (which includes github.com).
In particular, I think Forgejo is a nice bit of software;
it’s easy to run on premise for homelabs etc. The decision to run
the Fedora Forge was not an
easy one – there’s real ecosystem splitting effects, but I think
we’ll be OK.
The thing is though, running a $0, publicly reachable internet service
where people can just store/write things is genuinely hard (and
especially when paired with a service to execute arbitrary code like
Github Actions). It’s under constant attack from spam, scraping, bitcoin mining
and abuse in a way that probably few people outside of the administrators
truly appreciate.
I have a lot of respect for people and projects choosing to self-host or use
smaller-scale hosts like Codeberg, but
there’s real tradeoffs there around sustainability and availability.
I don’t expect this status quo to change much in the near future.
In the next post, I’ll talk about how this relates to agentic AI.
In Fedora Copr, we maintain a special tier of build machines known as High-Performance Builders (or as we call them internally, “powerful builders”).
Historically, gaining access to these machines required some manual intervention. Maintainers had to write to us, and we would enable them for specific projects or packages based on matching regular expressions. I’m happy to say those days of manual labor are over. This process is now entirely automated thanks to rpmeta (expect a dedicated blog post on this soon).
To give you an idea of the hardware: our standard builder in AWS EC2 is a c7i.xlarge, providing a respectable 4 vCPU and 8 GB of RAM. The high-performance x86_64 counterpart is the c7a.8xlarge flavor, boasting 32 vCPU and 64 GB of RAM. The real-world impact? Massive packages that typically churned for 23 hours on a standard instance are now finishing in 5 to 6 hours.
But this got me thinking. Is it possible to go even further? How much does throwing progressively heavier hardware at the problem actually accelerate an RPM build?
Enter the Megabuilder
To test the absolute extremes, I decided to fire up the most powerful EC2 instance I could find. Finding an available datacenter for these behemoths was a challenge in itself, but I eventually managed to spin up a u-3tb1.56xlarge - the third biggest flavor in AWS EC2.
Let’s call it the Megabuilder. It packs 224 vCPUs and 3 TB of RAM.
To ensure disk I/O wouldn’t skew the results, all test builds were executed with Mock’s tmpfs plugin enabled. The entire build process happened purely in RAM, making disk speed irrelevant.
Here is what happened when I fed it some of Fedora’s most notoriously heavy packages.
Test 1: python3-torch (The Socket Trap)
Standard Builder: 23 hours
Powerful Builder: 5 hours
Megabuilder (Final): 1 hour 19 minutes
When I first ran python3-torch on the Megabuilder, it finished faster than the 5-hour mark, but something was off. Monitoring the system revealed that it was utilizing a maximum of 28 out of the 224 available CPUs.
After digging into the SPEC file, I found the culprit. The maintainer’s parallelism detection logic was correctly counting cores, but it forgot to multiply them by the number of CPU sockets. The Megabuilder has a 4-socket architecture. After submitting a quick pull request to fix the detection logic, CPU utilization spiked (though it still didn’t max out the machine) and the build time dropped to an impressive 1h 19m.
The Cost Equation: The Megabuilder run cost $35. On the powerful builder, this same build costs only $8. That is a steep premium for speed.
Sidenote: At the very end of the build process, rpmbuild hung in a single-threaded state doing “something” for quite a while. My educated guess is that it was churning through a brp (BuildRoot Policy) script hook.
Test 2: gcc (The ./configure Bottleneck)
Standard Builder: 13 hours (Cost: $2)
Megabuilder: 5 hours 36 minutes (Cost: $151)
GCC rarely managed to take advantage of the Megabuilder’s massive core count. If you watch the process tree, the vast majority of the time is spent running one or two ./configure scripts. A configure script will chug along single-threaded for over a minute, followed by a brief 15-second burst where all cores light up during actual compilation, only to immediately drop back down to a single-threaded ./configure process.
Paying $151 to watch a single CPU core parse autotools macros is a tough pill to swallow.
Test 3: rust (The Optimization Trade-off)
Standard Builder: 4 hours (Cost: $0.70)
Megabuilder: 2 hours 22 minutes (Cost: $63)
Rust was the most resilient to parallelization, but this time, it’s not exactly a bug. As I understand it, this is a deliberate choice by Fedora engineering. If you force highly parallelized Rust builds, the resulting binary ends up being roughly 2–5% slower. Fedora consciously trades longer build times on the infrastructure side to guarantee faster runtime performance for end users.
Conclusion: Diminishing Returns
So, does monstrous hardware solve long RPM build times? Only marginally, and at an astronomical cost.
The reality is that sheer hardware scale is fundamentally bottlenecked by the software architecture. Neither rpmbuild itself nor the maintainer code inside %build sections can efficiently map to extreme, massive parallelism. You hit Amdahl’s Law incredibly fast.
A final funny observation: Knowing that even on this 224-core monster the builds would take hours, I fired them up fully intending to go watch a movie on Netflix. Instead, I found myself completely mesmerized by btop and the output of ps axf. Watching process trees expand and collapse across 224 cores turned out to be far more entertaining than a Hollywood blockbuster. :)
Earlier this month, I published a post about the future of Boxes where I detailed the huge technical rewrite I have been doing, porting to GTK4, Libadwaita, and replacing our SPICE display widget with Libmks. Today, I want to share a structural decision that aligns with that vision and sets up the project for long-term health/sustainability.
I want to dive into why I am making this move, what it means for users and maintainers, and why I believe this is the right path forward.
There is No Drama Here
First off, let’s get this out of the way: there is zero drama between Boxes and the GNOME project.
Boxes continues to be built by the same core set of contributors, fully committed to the GNOME Human Interface Guidelines (HIG) and deeply integrated into our ecosystem. We aren’t stepping away from GNOME. We are simply right-sizing how Boxes is categorized, distributed, and maintained.
Why Boxes Shouldn’t Be “Core” (and Why Versioning with the OS is Outdated)
The desktop Linux landscape is shifting toward image-based operating systems with atomic updates and immutability. In this model, the underlying operating system provides a slim, reliable base, while applications live on top and update independently at their own pace.
Tying a complex application like Boxes to the biannual GNOME release schedule is not useful anymore. It forces us to hold back features and bug fixes for months just to align with the OS cadence, when users should simply get updates when they are ready and stable.
Furthermore, virtualization isn’t an essential utility that needs to be pre-installed on every single user’s machine by default. Boxes fits much better as a targeted application users explicitly choose to install when they need it.
Flathub-First: Moving Fast and Ending Distribution Bottlenecks
As a maintainer, maintaining separate code paths and stable branches for dozens of traditional distribution packages is simply not sustainable long-term. I can no longer afford to maintain multiple stable branches. Moving forward, I am simplifying maintenance down to one stable branch and one development/nightly branch. To make this sustainable, Flathub is our primary and only officially supported distribution method.
By bundling the virtualization stack in our Flatpak, we ensure that users get a much more tested, consistent, and working virtualization backend regardless of what operating system they are running.
Moving out of Core allows us to heavily discourage downstreams from individually packaging Boxes. Instead, distros should defer their users to the official Flatpak on Flathub. If you are filing bug reports or seeking support, the Flathub build will be the baseline.
Branding and Infrastructure Changes
To reflect this independent status, a few logistical changes are happening alongside this move. We are dropping “GNOME” from the user-facing app branding. Going forward, it will simply be named “Boxes”, and we will soon be moving to a new website domain (which is currently being finalized). Importantly, our Flatpak application ID will remain org.gnome.Boxes for full continuity and compatibility. This means existing installations, user settings, and Flatpak configurations won’t break, and users won’t need to reinstall anything.
What’s Next?
This change gives us the flexibility to release updates whenever features are ready, iterate faster, and dramatically reduce maintainer burnout, all while delivering a more reliable and consistent user experience via Flathub. Once we settle into this new cadence and finalize our transition, we plan to apply for GNOME Circle.
To set clear expectations on timing: since Boxes currently uses GTK3 in its stable releases, we will soon submit an application for GNOME Circle review following our GTK4/Libadwaita rewrite.
If the Circle application is approved before the GNOME 52 Alpha deadline, the plan is to proceed with the removal from core-developer-tools and transition to Circle in time for the GNOME 52 release in March 2027.
For distribution maintainers wondering about upcoming distro releases: distros targeting GNOME 51 can continue to package the GNOME 50 release of Boxes, which will remain supported for the standard lifecycle of that release. If everything goes according to plan, GNOME 52 won’t include Boxes in the core set anymore. At this point, please don’t package Boxes anymore.
If you use Copr a lot, your project list grows fast. Personal experiments, scratch builds, one-off test repos, they all pile up next to the number of projects you actually care about. Pinned projects already assist with that; you can keep up to four projects visible in your profile by pinning them. But four is a hard limit, and a handful of icons at the top of the page is the only way it can highlight it.
Now you can go further. Copr profiles support a custom Markdown description, similar to a GitHub profile README, and there is no limitation on what you put there.
It can be used in many ways, like:
A curated project list, like the example above: a hand-picked list of your projects, each with a one-line note on what it’s for, project groups you maintain, and packages you want new contributors to find first.
A bio, so people landing on your profile know who you are before they scroll through your projects. Contact info, links to your FAS account, or whatever you’d want a stranger to see first.
These aren’t the only options; you can further customize your profile based on your requirements.
How to set it up
If you are logged in, go to your profile page and click Customize Profile. Groups have the same button, visible to any member of the group.
Most of GNOME 51 is now packaged for Fedora 45. Starting today and running through the end of the week, we will be running our traditional Fedora Test Day for GNOME. If you are a Fedora user, you can help us find last-minute integration issues and iron out what’s going to become the stable Fedora 45 release.
You can either boot the latest Fedora 45 image (nightly) in a virtual machine or update an existing test setup. Follow our guided test matrix, try out different features, and record your results. Even testing for 15 minutes and reporting a single issue makes a huge difference.
This is an independent, censorship-resistant site run by volunteers. This site and the blogs of individual volunteers are not officially affiliated with or endorsed by the Fedora Project.
![VMS Enterprises Ltd vs The Brexit Party Ltd ([2021] SC GLA 49), 11694875, 16260766, CR-2022-003973](https://danielpocock.com/assets/reform-uk/2021scgla49-vms-enterprises-ltd-against-the-brexit-party-ltd-cover.jpg)
![Reform UK, Nigel Farage, creditors, [2021] SC GLA 49](https://danielpocock.com/assets/reform-uk/vms-brexit-research-article.jpg)
![Reform UK, Nigel Farage, Brexit Party, 11694875, 16260766, CR-2022-003973, [2021] SC GLA 49](https://danielpocock.com/assets/reform-uk/gazette-side-by-side.png)
