A few weeks ago I was invited to talk about firmware updates for servers using fwupd/LVFS at Prem’Day 2025 . I gave the hardware vendors a really hard time, and got lots of instant feedback from customers in the the audience from the “little green thumbs” that people could raise. The main takeaway from the Prem’Day community seemed to be that proprietary tooling adds complexity without value, and using open ecosystems enable users to better operate their infrastructure.

Since getting back to the UK I’ve had some really interesting discussions with various companies; there might be some nice announcements soon.

Recently, Tobias Bernard posted a retrospective of his (and our) experience engaging with the GNOME Foundation regarding the removal of Sonny Piers from our community, followed by a response from Allan Day. I know it's difficult and stressful to talk about; a lot of people just want it to go away. It took a long time to write this.

The details regarding the removal of Sonny Piers will never be publicized, but I respectfully disagree that all discussion of the community impact should happen internally. Regardless of the circumstances at the time, the GNOME Foundation made a decision to publicly remove Sonny Piers from the community and if we are asked to assume good faith, we should be able expect the same good faith when we criticize governance.

# Safety in the Community

The case of Sonny Piers includes GNOME Foundation membership, a seat on the board of directors and employment as a project coordinator. Circumstances these complex do not relate to the Code of Conduct Committee (CoCC) in its typical operation.

The Engagement Team also plays an active role in day-to-day moderation, as well as the community members from diverse backgrounds serving as moderators in the many project channels. Recently a member of the CoCC helped organize a communication channel and new guidelines for moderators, which has already improved coordination and response times across the various platforms.

The GNOME community is a safe place to engage in open source and the matters discussed here should not prevent you from reporting an incident or flagging content for moderation.

CoC Links

• Code of Conduct
• Report an Incident

# Opaque Context

The following is a very incomplete timeline, providing some amount context for my personal perspective.

In July 2024, many of us in the community were shocked to hear that Sonny Piers had been removed as a GNOME Foundation director, stripped of his membership, had all accounts locked and a permanent ban put in place. More unsettling, he was named as the recipient of a Code of Conduct complaint, but obviously without any details regarding the incident.

With such limited information, for many there was little justification to protest the decision itself, except that the degree of disciplinary action implied behaviour extremely out of character for Sonny.

By October, three months had passed and lacking any meaningful resolution, enough concern had grown in parts of the community to have a conversation. It was decided to compose a letter directly to the Board and, after lengthy discussion of the content, those that agreed signed and it was received generally well by the Board.

The resulting meetings were draining for everyone involved, often with visible exertion of good faith from those present. The many constructive results include several amendments to CoCC procedures, more comprehensive and equitable agreements for contractors, and a fair amount of clarification regarding the constraints the Board was under at the time.

By December, I had withdrawn from most social spaces in the community. During the period of engagement with the Board, there were a conspicuous number of public references made to toxic influencers and after a very disappointing comment from a relevant party, I closed my Mastodon account. Aside from compounding the stress of the meetings, I considered I might be compelled to publicly defend Sonny and compromise our efforts with the Board.

In January, Tobias published Re-Decentralizing Development and seeing the reactions include sentiments like "Cult of Sonny" more or less vindicated my decision to withdraw from social spaces. Some clearly assumed there had been no effort to resolve the matter internally and the spectre of a toxic influencer meant attempts to engage publicly were unlikely to be taken in good faith.

# Good Faith

There are legitimate concerns about an effort to undermine the Code of Conduct (CoC), for the sake of meritocracy. In other words, there are those concerned about different rules being applied to those who contribute more substantially or have more social capital. This is not paranoia; it's the state of justice in many of our real-world societies.

The opposing concern is that the CoC has been used as a tool to defend the status quo or enforce minority opinion as policy. Or as Tobias puts it:

[...] we’re now in a situation where large parts of the community do not trust our CoC structure because they feel it can be weaponized as part of internal power struggles.

Code of Conduct reports must be confidential and the decisions of the committee must be unimpeachable; under no circumstance can they become a matter of public opinion.

Unsurprisingly, there are very few situations that justify revealing any participant of a Code of Conduct report. Doing so has resulted in reputational damage such that an uncensored Google search of the name "Sonny Piers" returns pages of tabloid smear and speculation of criminality. Yet in the many months since, there has been no indication that this served the interests of community safety.

Although I acknowledge the community ban has since been relaxed to one year, I would like if we could each appreciate that to be stripped of membership, barred from ever holding a position in the Foundation and permanently banned from all community spaces is to be told, "You are irredeemable" . Again, in the time of Sonny's absence, there have been no signs that the safety of the community ever warranted a permanent ban.

The good faith assumption seems to be that these actions were taken to send a message: the Code of Conduct will be enforced, regardless of a person's stature in the community. Unfortunately, if that was the intention, a number in the community have already expressed confusion that this situation received treatment so different from their own.

# Trust and Accountability

I spent a fair amount of time recently deciding whether I would renew my Foundation membership or not. Those in the Foundation working to rectify the breakdown of communication and policy are the reason I decided to stay. However, there are also those in the Foundation who have made me feel an unwelcome bystander to the very public condemnation of a colleague, only be told not to cause a fuss.

I strongly believe the CoCC operated on an unfounded assumption of bad faith: that Sonny Piers is a toxic influence to be immediately and permanently removed from the community. Since July, none of the corroborating signs have surfaced; few have had more contact with Sonny than a short email response, there has been no public appeal to gather signatures, no coup d'état in the Foundation and, with two months left on the community ban, fears of him being exempt from the rules seem moot.

A number of the recent policy improvements were prompted by the findings of the external review commissioned by the Foundation, but I'd like to clarify this was an assessment of whether the Code of Conduct Committee acted within its scope and authority; not a judicial review. The severity of corrective action has not been justified, nor did any review findings or policy changes apply retroactively.

While the Foundation has and will continue to improve, it seems unlikely we will see accountability for the mishandling of a situation that has caused damage to an individual, to the community and trusting relationships. For trust to be restored, we must be assured that Code of Conduct Committee is free from conflicts of interest and is only applied in the interests of community safety.

# Final Thoughts

I don't know what to do about this. I know there are those in the Foundation working very hard to improve the situation and those on the Board aware that they can just ignore criticism until their seat is up for re-election.

The GNOME Foundation is becoming a more important part of the GNOME project every year, but it is still extremely opaque to most of us. If there is a way to educate oneself as a voter I do not know it, and we must accept that has become a serious problem.

We can not have confidence in leaders elected on vague familiarity and then expect accountability from elections separated by two years. And the GNOME Foundation can not build trust in governance by appealing to its own authority.

This blog post talked about the "self written C++ standard library" I wrote for the fun of it ( code here ).

The post got linked by Hackernews and Reddit. As is usual the majority of comments did not talk about the actual content but instead were focused on two tangential things. The first one being "this is not a full implementation of the C++ standard library as specified by the ISO standard, therefore the author is an idiot". I am, in actual fact, an idiot, but not due to project scope but because I assumed people on the Internet to have elementary reading comprehension skills. To make things clear: no, this is not an implementation of the ISO standard library. At no point was such a thing claimed. There is little point in writing one of those, there are several high quality implementations available. "Standard library" in this context means "a collection of low level functions and types that would be needed by most applications".

The second discussion was around the fact that calling the C++ standard library "STL" was both wrong and proof that the person saying that does not understand the C++ language. This was followed by several "I am a C++ standard library implementer and everyone I know calls it the STL". Things deteriorated from there.

The complexity question

Existing container implementations are complex by necessity. They need to handle things like types that can not be noexcept moved or copied. The amount of rollback code needed explodes very quickly and needs to be processed every time the header is included (because of templates). A reasonable point against writing your own containers is that eventually you need to support all the same complexity as existing ones because people will insert "bad" types into your container and complain when things fail. Thus you need to have all the same nasty, complex and brittle code as an STL implementation, only lacking decades of hardening to shake out all the bugs.

That is true, but the beauty of having zero existing users is that you can do something like this:

This is basically a concept that requires the type given to be noexcept-movable (and some other things that could arguably be removed). Now, instead of allowing any type under the sun, all containers require all types they get instantiated with to be WellBehaved . This means that the library does not have to care at all about types behaving badly because trying to use those results in a compiler error. A massive amount of complexity is thus eliminated in a single stroke.

There are of course cases when you need to deal with types that are not well behaved. If you can tolerate a memory allocation per object, the simple solution is to use unique_ptr . OTOH if you have types that can't be reliably moved and which are so performance critical that you can't afford memory allocations, then you are probably going to write your own container code anyway. If you are in the position that you have badly behaved types that you can't update, can't tolerate an allocation and can't write your own containers, then that is your problem .

Iterating things the native way

One of the most common things I do with strings in Python is to split them on whitespace. In Python this is simple as there is only one string type, but in native code things are more complicated. What should the return type of mystring.split() be?

• vector<string>
• vector<string_view>
• A coroutine handle
• The method should be a full template so you can customize it to output any custom string type (as every C++ code base has at least three of them)
• Something ranges something something

There is probably not a single correct answer. All of the options have different tradeoffs. Thus I implemented this in two ways. The first returns a vector<string> as you would get in Python. The second one was a fully general, lazy and allocation-free method that uses the most unloved of language features: the void pointer.

So given that you have a callback function like this:

the split function becomes:

This is as fully general as you can get without needing to muck about with templates, coroutines or monads (I don't actually know what monads are, I'm just counting on the fact that mentioning them makes you look cool). The cost is that the end user needs to write a small adapter lambda to use it.

Iterating things the Python way

The Python iteration protocol is surprisingly simple. The object being iterated needs to provide a .next() method that either returns the next value or throws a StopIteration exception. Obviously exceptions can't be used in native code because they are too slow, but the same effect can be achieved by returning an optional<T> instead. Here's a unit test for an implementation of Python's range function.

Sadly there is not a simple way to integrate this to native loop constructs without macros and even then it is a bit ugly.

Current status

The repo has basic functionality for strings (regular and enforced UTF-8), regexes and basic containers.

Building the entire project has 8 individual compilation and linking steps and takes 0.8 seconds when using a single core on this laptop computer. Thus compiling a single source file with optimizations enabled takes ~ 0.1 seconds. Which is nice.

The only cheat is that pystd uses ctre for regexes and it is precompiled.

Welcome! In classic new-blog tradition, I felt it was a good idea to explain the title given to this little corner of blogs.gnome.org — and provide fair warning as to what sort of thoughts I’ll post here.

GNOME is the Computer

I’ve spent a lot of time lately answering the question “what is GNOME?” This question usually comes from my friends outside the tech industry. They work on film sets and fishing boats. They work in law firms, book stores, and hospitals. I don’t usually have a whiteboard handy to explain what GNOME is, so I’ve found myself approaching the question like this:

Me: Have you heard of “Linux”?

Them: Yes.

Me: Okay, so. When you open your laptop and the thing you see is Windows? And when you unlock your phone and the thing you see is iOS? When you use a Linux computer, the thing you see is GNOME.

I’m committing multiple sins with this oversimplification but if any of my friends are willing to let me elaborate, I do. That rarely happens. To these folks, and to me, GNOME is the computer. It’s the human part. The UI. The UX. The part you touch.

An Environment for Everyone

For those few friends who do permit me to elaborate, I’ll spend a moment explaining free desktops. But if they’re willing to put up with me, I’ll turn the conversation back to GNOME.

After spending over two decades in the software industry, I’ve developed a deep appreciation for simple, opinionated, well-designed software. After a bicycle crash and three botched surgeries in 2014, I’ve also developed a deep appreciation for accessible software.

The word “accessibility” contains a lot of nuance. Our industry tends to associate that word with an icon of a little human, arms outstretched. Of course it’s important for software to reach folks like me, who need to use computers in specific ways. But “accessibility” goes much farther than that.

The root of accessibility is access :

• Does the computer speak your language?
• Does the computer understand your culture?
• Can you afford it?
• Can you share it?
• Can you fix it yourself?
• Is it really yours?

Unlike most desktop software these days, GNOME can answer “yes” to all these questions.

GNOME is Infrastructure

Not only does accessible computing for everyone already exist, it is everywhere . I’ve seen GNOME in schools, wood shops, trading firms, government offices, universities, and every software company in my 20-year career.

Infrastructure — whether libraries, parks, roads, or sewers — is a drab topic compared to “computing for everyone”. But it is no less important. Really, it is the other side of that coin and I’ll have a lot more to say on this topic.

This blog will live at the intersection of these three topics: GNOME’s identity, mission, and reach.

Welcome! In classic new-blog tradition, I felt it was a good idea to explain the title given to this little corner of blogs.gnome.org — and provide fair warning as to what sort of thoughts I’ll post here.

GNOME is the Computer

I’ve spent a lot of time lately answering the question “what is GNOME?” This question usually comes from my friends outside the tech industry. They work on film sets and fishing boats. They work in law firms, book stores, and hospitals. I don’t usually have a whiteboard handy to explain what GNOME is, so I’ve found myself approaching the question like this:

Me: Have you heard of “Linux”?

Them: Yes.

Me: Okay, so. When you open your laptop and the thing you see is Windows? And when you unlock your phone and the thing you see is iOS? When you use a Linux computer, the thing you see is GNOME.

I’m committing multiple sins with this oversimplification but if any of my friends are willing to let me elaborate, I do. That rarely happens. To these folks, and to me, GNOME is the computer. It’s the human part. The UI. The UX. The part you touch.

An Environment for Everyone

For those few friends who do permit me to elaborate, I’ll spend a moment explaining free desktops. But if they’re willing to put up with me, I’ll turn the conversation back to GNOME.

After spending over two decades in the software industry, I’ve developed a deep appreciation for simple, opinionated, well-designed software. After a bicycle crash and three botched surgeries in 2014, I’ve also developed a deep appreciation for accessible software.

The word “accessibility” contains a lot of nuance. Our industry tends to associate that word with an icon of a little human, arms outstretched. Of course it’s important for software to reach folks like me, who need to use computers in specific ways. But “accessibility” goes much farther than that.

The root of accessibility is access :

• Does the computer speak your language?
• Does the computer understand your culture?
• Can you afford it?
• Can you share it?
• Can you fix it yourself?
• Is it really yours?

Unlike most desktop software these days, GNOME can answer “yes” to all these questions.

GNOME is Infrastructure

Not only does accessible computing for everyone already exist, it is everywhere . I’ve seen GNOME in schools, wood shops, trading firms, government offices, universities, and every software company in my 20-year career.

Infrastructure — whether libraries, parks, roads, or sewers — is a drab topic compared to “computing for everyone”. But it is no less important. Really, it is the other side of that coin and I’ll have a lot more to say on this topic.

This blog will live at the intersection of these three topics: GNOME’s identity, mission, and reach.

April was light.

exempi

Released Exempi 2.6.6 to fix security issues from upstream.

libopenraw

Some minor fixes in the thumbnail extraction, with JXL support and locate larger Panasonic previews. Extract the exposure bias for Fuijfilm files. Added the latest Canon cameras (still the support of CR3 is work in progress).

Released alpha.10 on May 1st.

This blog post talked about the "self written C++ standard library" I wrote for the fun of it ( code here ).

The post got linked by Hackernews and Reddit. As is usual the majority of comments did not talk about the actual content but instead were focused on two tangential things. The first one being "this is not a full implementation of the C++ standard library as specified by the ISO standard, therefore the author is an idiot". I am, in actual fact, an idiot, but not due to project scope but because I assumed people on the Internet to have elementary reading comprehension skills. To make things clear: no, this is not an implementation of the ISO standard library. At no point was such a thing claimed. There is little point in writing one of those, there are several high quality implementations available. "Standard library" in this context means "a collection of low level functions and types that would be needed by most applications".

The second discussion was around the fact that calling the C++ standard library "STL" was both wrong and proof that the person saying that does not understand the C++ language. This was followed by several "I am a C++ standard library implementer and everyone I know calls it the STL". Things deteriorated from there.

The complexity question

Existing container implementations are complex by necessity. They need to handle things like types that can not be noexcept moved or copied. The amount of rollback code needed explodes very quickly and needs to be processed every time the header is included (because of templates). A reasonable point against writing your own containers is that eventually you need to support all the same complexity as existing ones because people will insert "bad" types into your container and complain when things fail. Thus you need to have all the same nasty, complex and brittle code as an STL implementation, only lacking decades of hardening to shake out all the bugs.

That is true, but the beauty of having zero existing users is that you can do this:

This is basically a concept that requires the type given to be noexcept-movable (and some other things that could arguably be removed). Now, instead of allowing any type under the sun, all containers require all types they get instantiated with to be WellBehaved . This means that the library does not have to care at all about types behaving badly because trying to use those results in a compiler error. A massive amount of complexity is thus eliminated in a single stroke.

There are of course cases when you need to deal with types that are not well behaved. If you can tolerate a memory allocation per object, the simple solution is to use unique_ptr . OTOH if you have types that can't be reliably moved and which are so performance critical that you can't afford memory allocations, then you are probably going to write your own container code anyway. If you are in the position that you have badly behaved types that you can't update, can't tolerate an allocation and can't write your own containers, then that is your problem .

Iterating things the native way

One of the most common things I do with strings in Python is to split them on whitespace. In Python this is simple as there is only one string type, but in native code things are more complicated. What should the return type of mystring.split() be?

• vector<string>
• vector<string_view>
• A coroutine handle
• The method should be a full template so you can customize it to output any custom string type (as every C++ code base has at least three of them)
• Something ranges something something

There is probably not a single correct answer. All of the options have different tradeoffs. Thus I implemented this in two ways. The first returns a vector<string> as you would get in Python. The second one was a fully general, lazy and allocation-free method that uses the most unloved of language features: the void pointer.

So given that you have a callback function like this:

the split function becomes:

This is as fully general as you can get without needing to muck about with templates, coroutines or monads (I don't actually know what monads are, I'm just counting on the fact that mentioning them makes you look cool). The cost is that the end user needs to write a small adapter lambda to use it.

Iterating things the Python way

The Python iteration protocol is surprisingly simple. The object being iterated needs to provide a .next() method that either returns the next value or throws a StopIteration exception. Obviously exceptions can't be used in native code because they are too slow, but the same effect can be achieved by returning an optional<T> instead. Here's a unit test for an implementation of Python's range function.

Sadly there is not a simple way to integrate this to native loop constructs without macros and even then it is a bit ugly.

Current status

The repo has basic functionality for strings (regular and enforced UTF-8), regexes and basic containers.

Building the entire project has 8 individual compilation and linking steps and takes 0.8 seconds when using a single core on this laptop computer. Thus compiling a single source file with optimizations enabled takes ~ 0.1 seconds. Which is nice.

The only cheat is that pystd uses ctre for regexes and it is precompiled.

Some links for technical articles on various topics I read.

The Defer Technical Specification: It Is Time - Explains the proposal for the next C language standard for defer .

A guide to implement ActivityPub in a static site (or any website) - A guide to implement ActivityPub in a static website.

20 years of git - An history of git and its early days.

Celebrating Git's 20th anniversary with creator Linus Torvalds - An interview with Linus Torvalds on the 20 years of git.

I use Zip Bombs to Protect my Server - A technique of serving compressed zeros that a lot of bots don't handle properly.

6 usability improvements in GCC 15 - New in a GCC 15 near you, better error messages.

Update on what happened across the GNOME project in the week from April 25 to May 02.

GNOME Core Apps and Libraries

Calendar

A simple calendar application.

Hari Rana | TheEvilSkeleton reports

As part of our volunteer-driven accessibility initiative in GNOME Calendar, and for the first time in the 10+ years of Calendar’s existence, we finally completed and merged the first step needed to have a working calendar app for people who rely on keyboard navigation. This merge request in particular makes the event widgets focusable with navigation keys (arrow left/up/right/down) and activatable with space/enter.

Most of GNOME Calendar’s layout and widgets consist of custom widgets and complex calculations, both independently and according to other factors (window size, height and width of each cell, number of events, positioning, etc.), so these widgets need to be minimal to have as little overhead as possible. This means that these widgets also need to have the necessary accessibility features reimplemented or even rethought, including and starting with the event widgets.

Third Party Projects

francescocaracciolo reports

Newelle 0.9.5 Released: Internet Access, Improved Document Reading

🔎 Implemented Web Search with SearXNG, DuckDuckGo, and Tavily 🌐 Website Reading: ask questions about websites (Write #url to embed it) 🔢 Improved inline LaTeX support 🗣 New empty chat placeholder 📎 Improved Document reading: semantic search will only be done if the document is too long 💭 New thinking widget 🧠 Add vision support for llama4 on Groq and possibility to choose provider on OpenRouter 🌍 New translations (Traditional Chinese, Bengali, Hindi) 🐞 Various bug fixes

Source Code Install it from Flathub

Elias Projahn announces

I have published the initial release of a classical music player and organizer designed for GNOME, which will eventually become a full-fledged tool for managing your personal library of classical music. The application is called Musicus and also comes with a small pre-made music library containing recordings that are in the public domain (based on EU legislation). This makes it very easy to try out the app, which is available as a Flatpak bundle . Please note that the application is not yet stable and mature. This is why I am looking for feedback on the design, functionality and, if you are interested in contributing , you!

Hari Rana | TheEvilSkeleton reports

Since Upscaler has just reached 150,000 installs on Flathub, I’m releasing Upscaler 1.5.0! Upscaler is an app that allows you to upscale images locally, securely, and completely offline.

Thanks to Zoey Ahmed’s wonderful contribution, this release introduces the long overdue functionality to load multiple images at once and add them to the queue. This avoids having to load and add each image to the queue, which will significantly speed up the process of adding images to the queue.

The entire async and threading model was ported to the asyncio and threading modules, thanks to the long await ed (pun very much intended) asyncio integration in PyGObject that was made available recently.

Loading images has become much faster and smoother, while using less memory as a direct result of the asyncio and threading port.

This release also makes saving the resulting images completely optional. Additionally, there is now a copy button to copy images without saving them. As such, the process to upscale images has gotten more straightforward than ever – just load the image, set the desired scaling factor and the image type.

The progress rows have gotten a redesign to make them more reminiscent to typical rows with progress bars.

You can get Upscaler 1.5.0 on Flathub: https://flathub.org/apps/io.gitlab.theevilskeleton.Upscaler

Turtle

Manage git repositories in Nautilus.

Philipp announces

Turtle goes async again

Turtle 0.13 was released with proper Nautilus async plugin support!

Turtle switched back to the async update_file_info_full method recently and with this version many improvements have been made to reduce turtle service dbus calls to speed up emblem calculations. There is now also a setting to restrict emblems and the context menu to home folders, to even further reduce unnecessary service calls.

Making async possible again

Turtle used a workaround for a while, because there was a crash in Nautilus when update_file_info_full is used. This issue was fixed with this MR which is available in Nautlius 48+ and has also been backported to Nautilus 47.2 and 46.4.

The flatpak version still uses the sync workaround, because there is no way to guarantee the package is installed on a distro with a Nautilus version including the fix.

Packaging stuff

There was also some progress with debian and fedora packages of Turtle.

If you want to test the package now, there is PPA for Ubuntu 24.04 with the Nautilus fix backported.

Fractal

Matrix messaging app for GNOME written in Rust.

Kévin Commaille reports

A new version of Fractal numbered Eleven? Stranger things have happened… Features come running up that hill:

• Support for login using the OAuth 2.0 API (as used by matrix.org, which recently made the switch to Matrix Authentication Service)
• Overhaul of the page that lists user sessions, with details moved to subpages, for a less cluttered feel, and allowing to rename sessions!
• Rearranged account settings, with a new Safety tab that includes a setting to toggle media preview visibility
• BlurHashes for images and videos, that are used as placeholders while the media is loading or if the preview is disabled
• Contiguous state events are grouped behind a single item

As usual, this release includes other improvements and fixes thanks to all our contributors, and our upstream projects.

We want to address special thanks to the translators who worked on this version. We know this is a huge undertaking and have a deep appreciation for what you’ve done. If you want to help with this effort, head over to Damned Lies .

This version should be available shortly on Flathub .

If you want to join the gang, you can start by fixing one of our newcomers issues . We are always looking for new members!

Blueprint

A markup language for app developers to create GTK user interfaces.

Sophie 🏳️‍🌈 🏳️‍⚧️ (she/her) reports

Blueprint is now part of the GNOME Nightly SDK and is expected to be part of the GNOME 49 SDK. This means, apps relying on blueprint won’t have to install it manually anymore.

Blueprint is an alternative to defining GTK/Libadwaita user interface via .ui XML-files ( GTK Builder files ). The goal of blueprint is to provide UI definitions that require less boilerplate than XML and are easier to learn. Blueprint also provides a language server for IDE integration.

Many of our GNOME Circle apps are already built with blueprint, as well as some Core and Incubator apps.

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!