fidzu : GNOME

Terry Godier wrote a beautiful essay "The Boring Internet". The internet isn't dying, he argues, just the commercial veneer glued on top of it is. Underneath all the engagement metrics and algorithmic feeds, there's still an older, slower, more federated web. One built on protocols nobody owns. RSS feeds still work (thank you, Aaron), people can set up websites and blogs.

Lets start a webring in 2026

Don't worry, I haven't pushed too many pixels and gone a little cuckoo. But it's a fun exercise to remind what the web once was. We'll silently skip over the fact that I actually started using gopher first, but even web surfing didn't begin on a search engine back in the day. It was web rings, later followed by index sites.

Start

Not long ago I posted about designing app icons for 3rd party GNOME app developers. The post generated quite some buzz and some old and new faces started showing up to help with the backlog. So obviously I'd like to take you on a webring tour of all the designers responsible for making the GNOME app ecosystem a little less awkward to browse on Flathub.

Let me introduce you to Brage. He's been around for a couple of years now, helping to tame the flames of the reddit community, helping with the GNOME Circle project to improve the quality of GNOME apps in the wild, creating illustrations for initial states in apps, authoring some noteworthy apps himself. So thank you, Brage, welcome to the 90s!

Next Up: Brage Fuglseth

10 Jun 2026 12:00am GMT

Linux App Summit 2026 Social Media Retrospective

This is my personal retrospective post - there will likely be some version of this that will go out to various stakeholders.

I want to start off by giving huge praise to our organizing team that worked really hard this year in putting this event together. Couldn't ask for a better team to work with. Our organizing team is a mix of KDE and GNOME people.

This post will focus on the outreach, fundraising, and social media campaign since that was the bulk of the work I did for LAS this year.

Linux App Summit (LAS) for those who don't know is a conference organized around the goal of encouraging developing apps on the Linux platform. With
the advent of technologies like Flatpak, we had the technology to be able to ship apps directly to users instead of through the distros. Opening
an opportunity for a bi-directional relationship between app developers and the users of their apps.

This year marks the 10th year I've been involved in organizing LAS and its previous incarnation, LAS GNOME. LAS is organized jointly by GNOME and KDE who help fund and promote the conference jointly. It is a showcase of how we can unite and do impactful things.

I was not able to attend this year due to other commitments. I hope other who did attend will weigh in and let us know how it was in-person.

Let's get to it!

Challenging Myself

I wanted to challenge myself this year and really bring in the kind of engagement that I could be proud of. I've not really had the kind of time I wanted to work on this and it was time to really focus and see what could be done with a proper plan. The goal I wanted to take myself is driving awareness and growing attendance on what our app ecosystem is doing.

What does that entail?

Improving our social media game

The underlying problem I have identified is that Linux and apps was not getting into the headspace of developers. It still felt that this conference was unknown even in our own spaces. We need to break out of Mastodon and start exploring different platforms and content.

In previous years, we were using Buffer since it was free but it was really difficult and unwieldy. We could only schedule 3 days in advance and at times the posts would just drop. We needed to first change the tools we used to really improve our engagement with the world.

With help from the sysadmins at the GNOME Foundation (thank you, GF and Andrea Veri and Bart!), we were able to install Mixpost a self-host social media platform. The two great things about Mixpost is 1) analytics of the posts and social media platforms we were active on and not so active on 2) have a workspace around all our social media accounts and have a team of people working in it with an editorial flow and content calendar. This allowed us to share the workload of posting among many members. For instance, when I wasn't around, Aryan Kaushik was able to take it over and post. Mixpost is now also being used for various GNOME's accounts as well. The software continues to improve and hopefully they'll get around to single-signon support.

With the ability to actually have metrics, the next step is to actually take goals for each of the social media accounts we had and see if we could meet them. Below is a table of the targets I took and the results from February 2026 - May 2026. Instagram was actually started in the beginning of May.

Social Media	Start Count	Target Count	Result
Mastodon	596	796	926
LinkedIn	534	700	619
BlueSky	0	100	39
YouTube	1420	N/A	1610
Instagram	0	N/A	42

Overall, I think we did ok! The high count for Mastodon was because of the great work of the GNOME and KDE accounts on mastodon boosting our posts and helping promoting them before, during, and after LAS. I noticed doing things like polls on mastodon got a lot of attention without needing boosts from the other accounts.

We had decent engagement on LinkedIn. Certainly better than in the past. The trick though is that LinkedIn requires a different lens when you post. Since it is mostly focus on B2B and B2C type of messaging you need to write them differently. I didn't do it this time because writing social media posts is hard and takes a lot of time and thought.

I didn't take any goals for YouTube since we did not conceive that we would create content targeted for YouTube. In a spur of the moment, I did a 'podcast style' conversation between Matthias Clasen and myself talking about LAS. That gave us about 354 views. Which was encouraging and gives us some idea how organic content on YouTube would be received.

Bluesky was a new account for us. So we started with zero. We gained 39 followers. That might not seem like a lot given the time frame but BlueSky is an interesting platform when it comes to engagement. You can get quite a bit of engagement even if the follower count is low. I think given more time on the platform we'll be able to make that 100+ if we keep posting content. I think hashtags matter here and playing with the right kind of hashtag and content matters. Bluesky is also was a great experiment when you didn't have big accounts like GNOME and KDE boosting you.

The media partners we had 9to5Linux, Tuxdigital, It's FOSS, and Linux Magazine all helped in this regard by using their accounts boost our posts in these other platforms and give us visibility. Thank you to our media partners for helping out and we hope we can work with them closer next year. I'll like to engage with them further to see how we can help each other out including contributing content. Another idea is to reach out to the speakers of these talks and get them to write some articles that could be contributed based on their talks.

Finally, Instagram. This is an untapped gold mine. I was skimming through the platform looking for GNOME/KDE/Linux desktop type posts to see how well content did. Saw one young lady, who showed off her GNOME desktop with some caption and it gave her 130k views. It was about 10 seconds long. That was impressive. I posted a short video talking about Linux App Summit, and while I got about 130 views - the analytics said most stopped watching after 9 seconds of the 4 minute video I posted. That hurt my pride. I resolved to do better and get better engagement with a 10-15 second video that packed more information and visually more stimulating. As of now the LAS account is still gaining followers despite not posting for 2 weeks. Once again, the media partners helped by liking my posts while the other accounts lay idle.

Working with YouTube Influencers

One other aspects of my plan on boosting the visibility of LAS was to start working with influencers on various platforms. I made a few attempts with a few I knew but was only able to get on one podcast - Tux Digital. Michael Tunnell was kind enough to invite Aleix Pol and myself on his show. For an hour and half, we answered questions and did some bantering. We even went in some organic directions that was fun! I know I had fun, I hope Aleix did too. The exposure was pretty good with approximately 8k+ views for that episode that was 90 minutes. The feedback to the video was very positive with many resolving to attend the conference. Unfortunately, I didn't set up utm links so that I know where people came from.

Through social media and influencers, we hoped to break out of our media ecosystem and branch out to platforms that developers and Linux enthusiasts hang out and consume content. Meeting where developers are needs to be something we will need to focus on going forward.

Results

The in-person conference was a success, we had 110 people at the conference, the venue capacity was 100. We had 156 people who registered for the conference, this is about a 71% conversion rate. The industry average for free in-person events is 50%. For LAS, this is unprecedented because we usually had a much worse turnover rate historically. At one point, a few years ago I had started looking into doing registration fees to give people some reason to go and not ghost the conference.

For online this year, we had about 50 online registrations but it's hard to gauge anything about online participation since we freely published the YouTube link on social media.

The results for the conference for online had the following results on YouTube:

The above numbers show views within the 24 hour period of each day. These are really good numbers where we've more than doubled our viewership on one of the two days compared to last year. Ostensibly, it shows that our social media did build awareness.

Here is the (still increasing) numbers as of now on Youtube:

First Day: 2k views
Second day: 2.7k views

The videos are currently being broken up into individual talks. But the individual talks as of now are averaging about 300 views or so with the top one being 900+ views for Lennart's keynote.

The aggregate views for all the 13 individual talk videos posted so far is 4.9k. If we combined that with the combined 2k and 2.7k views, we can simplistically (mathematically speaking) would be 9.6k. Interestingly enough, that is not a big difference from the 8k views of Tux Digital podcast that Aleix and I were on. 😀

In regards, to the people who attended Linux App Summit, 16 people filled out the surveys and by in-large most of the people who attended heard about LAS through word of mouth and not so much through social media. So, that's an interesting data point. I expect that is because of people like Lorenz Wildberg (thank you!) who did on the ground outreach.

Interestingly, enough our online views were quite good compared to say SCALE which peaked at 7.1k views for one talk but in general the average views was less than the average views than at LAS. Our subject matter is increasingly important.

Also to be clear, views do not translate to people.

Looking towards 2027, we'll want to increase our in-person attendance while doubling our online views. Something we will be focusing on when we organize for next year.

Next Steps

Our organizing team will be posting relevant individual talks on social media once all the individual videos have been posted. I hope you all share those with everyone.

Secondly, we would love to add more people to our organizing team. Specifically, in order to really build out our outreach we need a lot more people to help network and reach out to developers from different communities and different platforms. This way we can start building relationships with other desktop projects, app developers, game developers, designers not just from Linux but from other platforms as well. For that we need a small army of advocates.

09 Jun 2026 11:18pm GMT

Gom is a very old object mapper I wrote to bridge GObject to SQLite. It made a lot of assumptions about the world based on when it was prototyped.

The past couple years had me using it again for the documentation search in Manuals. Typically, I would have just built Manuals to parse all the XML files on disk and hold them in memory. That's how both Devhelp and Builder always did things. Once we started supporting Flatpak SDKs that was no longer realistic. You could have numerous SDKs all with copies of the overlapping data and it just became easier to have a query model.

One of the more performance critical limitations was the locking model. When gom-1.0 was written, it was not common for distributions to compile SQLite with locking support. So you just created a single thread and did your work over there.

Bolting fulltext search and many other missing features onto the old ABI just wasn't realistic. Especially when I've wanted to make the thing properly async for years. One of my other projects, Libdex is just right over there and perfect for this sort of problem.

The landscape changed and so do our horizons.

A new informed ABI

In the years after Gom was prototyped, I worked at a commercial database company and learned a great deal about implementing the internals of both that database and more traditional RDBMS. That left a certain cringe on my mouth whenever looking at my code predating it. Knowing how things get done inside the database allows for building better APIs to interact with it.

This time everything is async. Queries are modeled like you do with a compiler. Lowered into the back-end specific implementation. There can be an entity map and real transactions which allows you to read back the same instance despite which query inflated it.

The Center

Your early stage objects are the GomRepository, GomDriver, and GomRegistry.

The registry describes the entities that can exist within the repository. This is handy because it allows us to pre-compile information into a model that is both immutable and fast at runtime. Compare that to methods like g_object_class_list_properties() which is a performance bottleneck of its own.

The driver is very obvious. It is our abstraction layer for the database engines. Currently we have support for SQLite and PostgreSQL.

The repository is the center of the center. It is how you query, insert, update, delete, transact, and more. It is likely your application instance owns one of these unless of course you use Gom as your file format in which case you'll have one per "document".

Two Access Models

This new version of Gom can support either the entity mapping you're used to or; optionally, raw access to relations/projections via the GomCursor.

As the cursor moves through the resulting rows you will have access to all the projections requested in the query. Though it holds enough information to allow you to gom_cursor_materialize() the row into an GomEntity subclass.

If you want a snapshot of that cursor row without materializing, you can use GomRecord which can also conveniently be used in GListModel for integration into GTK applications.

Most of the time, you'll use materialization. And even then it is likely to happen through automated collections rather than with a cursor directly. More on that later.

Sessions

As I mentioned, there was no concept of transactions previously.

In this iteration we have GomSession. It is your standard identity-map layer with transaction-scoping. If you perform multiple queries for the same record, the session will ensure you get the same instance back. That is essential when you do local mutations on an instance and what to see that reflected in followup queries.

Additionally, it makes it nice to have multiple views of an object with an editor or listview and needing them to stay in sync.

Relationship Modeling

Support for relationships was adhoc previously. We had some functions named in ways that made you think you could, but I assure you, they were not well tested.

This time around you can model your GomEntity with 1:1, 1:M, M:M, inverse, self-referencing, all while handling proper delete rules. Combing this with the session support mentioned previously is crucial.

So now you should be able to show related models easily in GtkListView while keeping the paginated-and-lazy model beneath it transactional.

Migrations

In the previous version migrations were dynamic, but largely controlled by Gom itself. Very inflexible.

This time around we have things broken down into Migrator and Migration.

You can use built-in implementations like the EntityMigrator or implement your own. CustomMigrator makes that easy. Especially since you can inject your own migrations at just the right point.

Internally, libgom-2 can snapshot your GomRegistry at specific versions based on the provided metadata. Then it performs a diff between two versions of the registry to determine what migration work must be done.

You can just as easily use a SqlMigration with custom SQL scripts. This stuff is all highly composable now to get exactly what you need.

Live List Models

I've written many ways to get live SQLite results into GTK over the past two decades. I think one of the first was a GtkTreeModel implementation for GTK 2 which could do it. With that in mind, it was still rather annoying when making Manuals so I set off to make that convenient.

We have GomRecordListModel, GomEntityListModel, GomRelatedListModel, GomQueryModel all of which have practical uses based on application needs.

But in short, most of those are lazy and support transaction-backed stable identities for entities. Very useful when you have a list of items and an editor loaded in another frame, both of which must reflect the same data.

Expression Trees

This time around I implemented proper expression trees. They model the query, relations, and projections in a manner that allows the driver to lower into a query much more accurately.

You can model things like function-calls cleanly all of which required writing manual SQL before. If you did anything outside of what gom could generate previously, it became madness to maintain.

Vectors

This version of libgom embeds the vec1 extension for SQLite. That means we can store vectors in your records and query them. GomVector makes that easier to manage as a property within your application entity.

I can think of a few things this will be useful for, maybe you can too.

Profiling

This version of libgom has profiling support with another project of mine, Sysprof. The whole library emits profiler marks about what is going on so that it is easy for you to figure out why something might be slow in your application.

Since we've already done the integration of Sysprof into GLib/GObject, GTK, Pango, Libdex, and GNOME Shell/Mutter you can very quickly get an idea with details of what is going on in your application. Click record, select the problem area, zoom, and it is often pretty clear. You can have flamegraphs, callgraphs, and timing marks all in one place.

Local First with Sync Coordination

One of my personal motivations for this is around building a native sync protocol for applications I'm building. I wrote numerous SQLite-based sync protocols for the now defunct catch.com before they were acquired by apple. That means I know multiple wrong ways to do it.

This time around, I want to put it right in the data-mapper at the point where you have the most insight. So libgom has the right abstractions in place to build that. The GomSyncCoordinator manages the process and GomSyncTransport is the abstraction-point for service integration.

You work with GomDelta at this layer. The application can provide you with a GomMergePolicy to help make decisions which allow for contextually doing the right thing.

This part is still very new. I'm still building the other side of it but landing the shape early allows me to mock and test things comprehensively before committing to the ABI.

My goal is building a practical, robust, and correct implementation for personal local first features.

A small personal note: as I wrote in my recent update from France, I am no longer employed by Red Hat. Work like this is currently self-funded, out of pocket, while my family and I settle into a new chapter. If you find it useful, a note of encouragement or a contribution means a lot right now. It helps make it possible to keep improving the free software infrastructure many of us rely on.

09 Jun 2026 7:48pm GMT

Many GNOME projects have adopted a policy banning all contributions generated by LLMs. This policy was originally developed by Sophie for Loupe, but is now used in many other notable places:

This project does not allow contributions generated by large languages models (LLMs) and chatbots. This ban includes, but is not limited to, tools like ChatGPT, Claude, Copilot, DeepSeek, and Devin AI. We are taking these steps as precaution due to the potential negative influence of AI generated content on quality, as well as likely copyright violations.

This ban of AI generated content applies to all parts of the projects, including, but not limited to, code, documentation, issues, and artworks. An exception applies for purely translating texts for issues and comments to English.

AI tools can be used to answer questions and find information. However, we encourage contributors to avoid them in favor of using existing documentation and our chats and forums. Since AI generated information is frequently misleading or false, we cannot supply support on anything referencing AI output.

I won't attempt to argue that you should allow use of AI for writing code. If you wish to ban LLM-generated code, fine. That's probably inadvisable, but I am not going to object.

But this policy is far stricter than that. Notably, it strictly prohibits AI-generated content in issue reports (except to translate text). Don't do this! Prohibiting bug reports is stupid and just makes your software worse. Please make sure your project's AI policy allows for at least AI-generated static analysis results and AI-generated vulnerability reports. Otherwise, you prohibit entirely unobjectionable problem reports.

It's hard to imagine what could possibly be the value of prohibiting valid bug reports. AI-generated static analysis works well: the AI is able to think about your code, follow execution paths, and automatically discard most false positives to avoid bothering you with them, and the quality of reports is generally pretty high. They are far from perfect, but the same is true of humans.

Here is a typical example of an AI-generated static analysis finding:

2. Resource leak in update_credentials_cb on gnutls_credentials_set failure

  File: tls/gnutls/gtlsconnection-gnutls.c:169-172

  When gnutls_credentials_set() fails, the function returns without calling g_gnutls_certificate_credentials_unref(credentials). The credentials was either freshly allocated or ref-bumped, so it leaks.

Pasting this into an issue report clearly violates the ban on AI-generated content. And yet, why would you not want to receive a clear and concrete bug report for memory leak?

I understand not all maintainers are fond of AI, but is your dislike really so extreme that you would choose to ignore valid problems and intentionally make your software worse? If not, then your AI policy should thoughtfully consider how to handle AI-generated content in issue reports. Certainly do not adopt a policy that outright bans all AI-generated content in issue reports.

As an issue reporter, you could theoretically take the problem found by the AI and rephrase all the words, then claim that it is no longer AI-generated content because it is rewritten. This is a waste of time and usually results in a lower-quality, less-detailed result, but you could plausibly do that. Or, if you want to go above and beyond, you could just jump ahead to creating a merge request. But realistically, if your project does not allow any use of AI in issue reports, it's more likely that either (a) you won't receive the issue report in the first place, or (b) you won't receive such issue reports from experienced developers who read and respect your policy, while users who do not read your policy will continue to submit them.

What about security vulnerability reports? Since the start of this year, I have reviewed well over 100 vulnerability reports that I strongly suspect were generated by AI. To reach the "over 100" claim, I sadly only considered vulnerability reports submitted during a particularly heavy four week period, so this is an extremely loose lower bound. Suffice to say, I have seen a lot of them. The quality varies dramatically. Vulnerability reports are now often better or worse than before: better because an experienced human working with a good AI is able to find vulnerabilities that would have surely gone unnoticed without AI, and worse because an inexperienced human with a bad AI might create some pretty terrible issue reports, a significant proportion of which are just outright spam. Low-quality reports remain a problem, but nowadays most AI-generated issue reports are quite good.

Maintainers do not need to tolerate spammy vulnerability reports. If an issue report is bad, of course go ahead and close it. If it's really bad, then I sometimes don't even bother replying. But banning good vulnerability reports solely because some portion of the report was generated by AI is unacceptable. AI-assisted vulnerability reports are the new industry standard, and this is not likely to change. Prohibiting issue reports reduces the quality and safety of your software, punishing your users. This is too extreme.

08 Jun 2026 9:30pm GMT

Fibers are always a nice way to keep your async C code clean while using Libdex. However, occasionally you may want a lighter option which doesn't require a stack or saving registers for work doing little more than coordinating futures.

I've added Stackless Coroutines for this which still allows writing future-coordinating code. Though this will suspend/resume your coroutine by re-entering the function and jumping to the next position. Your threads stack is reused. State is saved in your closure state.

This isn't a new concept. It is really old just like fibers. What is useful is that this style of continuation passing may still be represented as a DexFuture and therefore composed like the others.

You can place these stackless coroutines in DexTaskGroup alongside fibers, threadpool work, and others. Cancellation will propagate to a clean exit point of the coroutine just like it would with a fiber.

Overhead is a bit lower than fibers in synthetic benchmarks depending on use. I was actually impressed our fiber implementation performed as well as it did head-to-head.

To make building your coroutine continuation easier, libdex provides a handy macro to create your typedef struct, _new(), and _free() helpers in a single macro expansion using DEX_DEFINE_CLOSURE_TYPE().

You use it like this:

DEX_DEFINE_CLOSURE_TYPE (MyTaskState, my_task_state,
  DEX_DEFINE_CLOSURE_VALUE (gsize, bytes),
  DEX_DEFINE_CLOSURE_POINTER (GBytes *, bytes_obj, g_bytes_unref),
  DEX_DEFINE_CLOSURE_OBJECT (GSocketConnection, conn))

Coroutines cannot use the exact syntax that fibers do for awaiting, which is a bummer, but a side-effect of trying to make something that works across Linux, Windows, FreeBSD, Solaris, macOS, etc. Particularly because the implementation must use switch/case to stay portable without address-of-label support on MSVC nor clang-cl.exe.

So awaiting is a bit more clear you're suspending/resuming the stackless coroutine.

DEX_DEFINE_CLOSURE_TYPE (LoadState, load_state,
  DEX_DEFINE_CLOSURE_OBJECT (GFile, file),
  DEX_DEFINE_CLOSURE_OBJECT (GFileInputStream, input),
  DEX_DEFINE_CLOSURE_OBJECT (GFileInfo, info),
  DEX_DEFINE_CLOSURE_VALUE (int, io_priority))

static DexFuture *
do_something (DexCoroutineContext *context,
              gpointer             user_data)
{
  LoadState *state = user_data;
  g_autoptr(GError) error = NULL;

  DEX_COROUTINE_BEGIN (context);

  DEX_COROUTINE_SUSPEND_OBJECT (
    &state->input, &error,
    dex_file_read (state->file, state->io_priority));

  if (error != NULL)
    return dex_future_new_for_error (g_steal_pointer (&error));

  DEX_COROUTINE_SUSPEND_OBJECT (
    &state->info, &error,
    dex_file_input_stream_query_info (
      state->input,
      G_FILE_ATTRIBUTE_STANDARD_SIZE,
      state->io_priority));

  if (error != NULL)
    return dex_future_new_for_error (g_steal_pointer (&error));

  /* maybe do something useful here */

  return dex_future_new_int64 (g_file_info_get_size (state->info));

  DEX_COROUTINE_END;
}

You do need to be careful about placing things on the stack, because they wont be there on the other side of that DEX_COROUTINE_SUSPEND_* macro expansion. That is because when the scheduler jumps back into your stackless coroutine, it will use a switch/case to jump to the next bit of code. Don't fear though, just add your state to your continuation which we've established is easy to do now.

If you don't like these macros, you can do things the manual way using dex_coroutine_context_suspend() and dex_coroutine_context_resume() who's APIs are not terrible either. They do require you make up your own program-counter regime though which for the macro case is basically just __COUNTER__.

You can spawn your coroutine using dex_scheduler_spawn_coroutine() or as part of a work-queue in DexLimiter with dex_limiter_run_coroutine().

dex_scheduler_spawn_coroutine (
  dex_thread_pool_scheduler_get_default (),
  my_coroutine,
  my_coroutine_new (),
  (GDestroyNotify) my_coroutine_free);

I hope you've enjoyed this attempt to make another 1970s technology useful in a modern world.

08 Jun 2026 1:05pm GMT

One of the many nice language features in Python are keyword arguments. They make some types of APIs concise and readable. Like so:

Unfortunately C does not have keyword arguments and, by extension, neither does C++. Adding them as a language feature would take 15-20 years of effort, most of which would consist of trying to convince people via email that such a feature is important and should be added.

There have been attempts to implement this via macros and template magic (link), but they have not seen widespread usage probably because they are using macros and template magic. However it turns out that with modern language features you can fake keyword arguments fairly convincingly. Like so:

The add_argument method takes a single argument which is a struct. The extra curly braces inside the parentheses boil down to "whatever the underlying argument is, construct it in place with these parameters". The dotted names are designated initializers, so those fields get the specified value whereas other fields get their default values.

And there you go, keyword arguments in C++. You just have to squint a bit and pretend not to see the extra curly braces.

08 Jun 2026 12:09pm GMT

As in previous years, This Week in GNOME and this entire month are dedicated to the joys and struggles of all two-spirit, lesbian, gay, bi, trans, queer, inter, pan, asexual, aromantic, and non-binary people. We celebrate the invaluable work and life of all 2SLGBTQIA+ contributors and users, across all backgrounds and experiences.

Attempts to divide queer communities are not stopping. Fundamental human rights, hard-won over decades of struggle, are still under attack.

But we are here and we are not going anywhere. The GNOME community stands with queer people, now and always.

Together we are stronger.

GNOME Core Apps and Libraries

File Previewer ↗

A previewer companion for GNOME Files.

Peter Eisenmann reports

The last few weeks have been busy for sushi, the previewer companion for nautilus. Not only did Corey Berla's GTK4 port finally land, but on top of that Tau Gärtli, Nokse and myself have made several modernizations. The major changes are:

• Dark mode support
• GTK4, libadwaita, glycin and (initial) Blueprint usage
• Rework layout of several previewers
• Nicer floating toolbars
• Modernize code to use EcmaScript modules
• Cleaned up deprecated function usages

You can test these changes in GNOME OS or by installing sushi and nautilus from the gnome-nightly Flatpak repository.

Greetings from GPN in Karlsruhe!

GJS ↗

Use the GNOME platform libraries in your JavaScript programs. GJS powers GNOME Shell, Polari, GNOME Documents, and many other apps.

JumpLink announces

I'm currently working on a TypeScript framework for GJS called gjsify, and it has just hit a new milestone: the TypeScript compiler (v6.x) now runs directly inside GJS, so Node.js is no longer needed to run tsc. Just install gjsify and invoke it with gjsify tsc. Beyond tsc, there are other handy commands too, like gjsify install as a drop-in replacement for npm install, all running natively in GJS.

Third Party Projects

Mikhail Kostin says

Vinyl v1.4.0 has been released! There is a lot of changes since v1.3.2. Over the course of a month, I tried to do as much work as possible on the functionality and accessibility of the player. I also want to say with confidence that Vinyl is the first GNOME music player with the ability to read lyrics directly from an ID3v2 tag.

Here is the list of changes that the app has undergone:

• Added opportunity to synced parse lyrics directly from ID3v2 tag
• Added a lot of shortcuts, for playback and UI
• Added functionality for a more detailed scan of covers (Ability to read covers separately for each track)
• Added a button to open the current directory for the playing track
• Added search by audio extension
• Added tooltips
• Changed track sorting, tracks are now sorted first by folder location rather than by tags
• The player has been localized into many languages ​​including German, Hindi, Czech, Slovak, Kazakh, Uzbek, Polish and Swedish

Today you can see the new version of the Vinyl on Flathub

balooii reports

First release of Contributor Atlas!

Contributor Atlas is a set of interactive visualizations that bring a project's contributor history to life. It's aimed at projects with a long legacy of contributors.

I built it for GIMP and its ecosystem, with nearly 30 years of contributors to explore, but the graphs are generic - you might find it useful for your own project too.

Explore the live GIMP dataset at the link below. I hope you find it as interesting as I do! https://contributor-atlas-4dab97.pages.gitlab.gnome.org

You can find the project at https://gitlab.gnome.org/balooii/contributor-atlas

mohfy says

This week i've released v2.0.0 of Quizbite, Quizbite is an educational app that let you create quizzes with multiple choice questions, play them and share them with your friends!

You can also export the quiz to PDF, where you can print the quiz if you want to study offline.

In version 2.0.0 we've added search for quizzes, added ability to review mistakes after taking the quiz, ability to edit a quiz after creation, and some fixes.

Get Quizbite on Flathub: https://flathub.org/en/apps/dev.mohfy.quizbite

Gitte ↗

A simple Git GUI for GNOME

Christian says

Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.6.0 release! 🎉

The headline feature this time is per-file stash operations: you can now apply, pop or drop individual files from a stash via handy context-menu entries, and stash only the files you've selected in the working copy view, instead of always stashing everything.

Commit messages also got a lot more interactive. URLs are turned into clickable links, #<id> and !<id> mentions are linkified for known forges, and authors and committers show up as mailto: links. After pushing to a known forge, Gitte now offers a "New merge / pull request" link button so you can jump straight to creating one.

There are new shortcuts to hide untracked files (Ctrl+Shift+H) and to toggle untracked directories without recursing into them, and the staged/unstaged sections in split view are now collapsible, with an option to reverse their order.

Under the hood the working copy view got a performance overhaul: Gitte can now browse the Linux kernel repository with 10k changed files with ease.

Gitte also resolves includeIf blocks when reading the Git configuration now. On top of that come colored pills in the branch info box, a pointer cursor on selectable diff lines, and the usual pile of smaller UI refinements and fixes.

And there's good news for BSD folks: Gitte is now available in the FreeBSD ports tree, so you can install it via pkg install deskutils/gitte.

Get it on Flathub, for macOS or have a look at the Code.

Miscellaneous

GNOME OS ↗

The GNOME operating system, development and testing platform

Felicitas Pojtinger says

The documentation for contributing to GNOME Build Metadata (the project which builds things such as GNOME OS, the GNOME Flatpak runtimes and GNOME OCI images) got a big overhaul! If you ever wanted to build your own version of GNOME OS, want to make changes to your running GNOME OS system or fix a bug you've found somewhere, or if you're just curious and want to learn more about how BuildStream, systemd-sysupdate/sysext or the Flatpak runtimes work, now is a great time to try it out! The new CONTRIBUTING.md document is a good place to start: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/blob/master/CONTRIBUTING.md

Damned Lies ↗

The internal application to manage localization of GNOME & friends modules

Guillaume Bernard announces

A few changes for Damned Lies arrived this week! Our translation platform has received two external contributions, and we have very cool new features:

• @kristjan.esperanto added a dark theme to Damned Lies. You now have the possibility to switch between dark and light themes, or use the auto-mode that will follow your browser and desktop default theme.

• @balooii implemented a feature to better reward contributors who work on a workflow. The current implementation of the commit action only mentions the author of the translation and the committer. With this change, all volunteers who worked on a translation workflow are mentioned in the commit message with Translated-by, Reviewed-by, and Contributed-by credits.

Then, we have a fix from another contributor, @codeurluce who started contributing with a newcomer feature to fix a glitch in the interface.

I also took the opportunity to work a bit on the Deneb theme that Damned Lies uses to enhance the contrast of the different buttons and elements. The gnome-boostrap-theme received a few updates that are now reflected in Damned Lies. As usual, if you find something odd, please report issues!

Finally, in the diff view (the one you see on vertimus workflows) between a file and a previous version of a PO file, you now see some of the non-printable characters, like newlines, tabs, or non break spaces. If you use some in your language you'd like to have, just ask!

This was a very intense week for Damned Lies, and if you'd like to plant a seed in the i18n ecosystem, please open an issue, contact us on the #i18n:gnome.org channel or ask for new features!

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!

06 Jun 2026 11:32am GMT

I've been using Fedora Silverblue on my desktop and laptop for the past, what, five years? Silverblue is Fedora's main atomic variant, a spiritual counterpart to Fedora Workstation. I also make niri, a scrollable-tiling Wayland compositor. In other words, a core system component that you cannot properly test from inside a container or VM-you really want it directly on the host. So, why would I choose an… immutable distro? How does that even work?

Atomic distributions have been slowly rising in popularity. Their main selling point is reliability: upgrades work by swapping the old system for the new one in one go across a reboot, rather than modifying the files in-place. Package conflicts and other errors are caught at the time of assembling the new version (in a separate folder), and therefore cannot break your running system. And if a successful update turns out buggy, atomic distros let you simply reboot back into the old version and keep using it as if nothing happened.

This "being able to reboot back" thing becomes even cooler once you realize that it works even across major distro upgrades! When the next Fedora Beta rolls around, I can just rebase my system on top of it to kick the tires, and if anything is broken, I can simply reboot back to stable Fedora (and then undo the rebase).

This is like learning about source code version control. A big weight off your mind any time you want to mess around with your OS. You can just go back.

So, by now there are plenty of atomic distributions to choose from. There's a whole host of Fedora atomic desktops, Endless OS, the gaming-focused Bazzite and other Universal Blue images. GNOME OS Nightly is atomic, as well as SteamOS powering the Steam Deck. Many of these are built with OSTree which is something of a "git for operating system binaries".

But, you may ask. What if I develop these operating system binaries? Aren't atomic distros immutable and all, how do I test my work?

Turns out, this is not a problem at all! In fact, the same tech that lets you go back after an update can also let you freely tinker with your host system and safely go back after a reboot. I'd say that thanks to this ability, atomic distributions provide even more benefit for system component developers than for others, given that they're constantly testing changes that may break their install.

So, let me show you how I do compositor development on Fedora Silverblue. We'll start with toolbox where most of the work happens, then proceed to the fun stuff.

Toolbox #

On your immutable host system, you need a place where you can install the development environment. Fedora Silverblue comes pre-installed with Toolbox, which provides just that-a terminal in a normal, mutable Fedora where you can sudo dnf install to your heart's content.

Under the hood, it's just a podman container with a whole range of things auto-mounted from the host: the Wayland socket, networking, devices, D-Bus, and everything else needed for apps to "just work" as much as possible from inside the container. You can even interact with it through podman commands:

┌ ~
└─ podman ps
CONTAINER ID  IMAGE                                         COMMAND               CREATED       STATUS         PORTS       NAMES
6ceccce5581e  registry.fedoraproject.org/fedora-toolbox:44  toolbox --log-lev...  2 months ago  Up 41 minutes              fedora-toolbox-44

Most of your development work happens here. Install all the libraries, compilers, editors, LSPs, debuggers, and the rest of the kitchen sink. Since all of this resides inside the same container, it can all talk to each other and work together.

One slightly annoying detail is that since your fully-configured editor is inside the toolbox, you can't use it to edit files accessible only on the host (e.g. configs in /etc-the system inside the toolbox has its own files there), but that is honestly a fairly minor problem in practice. Fedora Silverblue comes with nano, which works, and if editing host-only files is a frequent occurrence for you, you can always rpm-ostree install a more featureful editor. Another annoying problem is that currently, toolbox prevents SIGHUP from reaching apps, so if you run your favorite editor then close the terminal window, it will happily keep running in the background (along with all its rust-analyzers and such, eating several gigabytes of RAM).

So, running things in a toolbox works perfectly well for most development. CLI tools will run fine, GUI apps will run fine, you can build and install libraries inside the toolbox and test them on apps inside the same toolbox. Even with Wayland compositors, most of them can run as a window (gnome-shell --nested, or simply sway or niri), which is enough to test the majority of the code base.

Moreover, since ~2023, toolbox exposes everything necessary to run compositors on a TTY directly. You can switch to a different VT with CtrlAltF3, toolbox enter, then start a compositor, and it will work as is. This way you can test different input devices directly (trackpad, tablet, touchscreen), test monitor and GPU handling, do proper performance profiling, and so on. Just remember to install a terminal and some GUI apps inside the toolbox because launching the host ones into a toolbox compositor is a bit annoying.

While toolbox is somewhat Fedora-specific, for everything else there's distrobox. It's a separate project, but by and large has the same idea-let you easily install different distros as podman containers with automatic host integration. I mainly use it to build or test things on Arch, but I imagine most of what I wrote above works just as well with distrobox.

What if this isn't enough, though? Say, you're working on a component like NetworkManager or systemd that must run on the host system. Or, you want to be able to log in to a test build of your compositor along with the rest of the full desktop session. Let's look at an easy way to do that.

Unlocking the host #

Run sudo ostree admin unlock, also known as rpm-ostree usroverlay.¹² This will mount a mutable overlay filesystem over /usr for you to play around in. The overlay will last until the next reboot, at which point you'll be back to a clean working system.

Now you can simply sudo cp your development build into /usr/bin and restart the service you're testing.

This also works with libraries. Say, you want to test your changes in GTK against apps installed on the host.³ Build it inside the toolbox, then copy the binaries to the (unlocked) host, and there you have it. Binary compatibility is generally not a concern since Silverblue updates daily and very closely matches the regular Fedora that you build against inside the toolbox.

sudo cp is not a proper substitute for installing though, and you cannot use it as easily for many projects. So let's get some proper tooling on the host.

Layering development tooling #

Contrary to an apparently widespread belief, you can install packages on the host in Silverblue. This is called layering and is a perfectly normal and supported operation, primarily useful for adding system components such as terminals, window managers, or GPU drivers. Running rpm-ostree install alacritty will cause rpm-ostree to install, or layer, this package on top of the base Silverblue image every time it updates. After a reboot, you'll have Fedora with Alacritty, as if you installed it on a regular, non-atomic system.

If the change is sufficiently non-invasive, running sudo rpm-ostree apply-live lets you skip the reboot and have a newly installed program available right away.⁴

When should you layer (as opposed to installing in a toolbox)? Layering is more annoying and slower, and misses the benefit of throwing away a toolbox to start fresh. So, I limit layering to programs that must run on the host, and tools that I frequently need on the host.

Here's my list of layered packages that's been more or less unchanged for several Fedora releases:

┌ ~
└─ rpm-ostree status
State: idle
Deployments:
  fedora:fedora/42/x86_64/silverblue
                  Version: 42.20250824.0 (2025-08-24T02:55:42Z)
               BaseCommit: d58dc92e5b05b6a95a0d9352edd864f1292c1883b9b32ac2e6f0af1a2263395a
             GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944
                     Diff: 12 upgraded
      RemovedBasePackages: firefox firefox-langpacks 142.0-1.fc42
          LayeredPackages: alacritty distrobox dnf fastfetch fish foot fuzzel gamescope gdb
                           gnome-console google-roboto-fonts htop hyprlock i3 kanshi labwc
                           langpacks-ru lm_sensors lxqt-policykit mako nautilus-python
                           netconsole-service niri perf quickshell-git rocminfo strace sway
                           syncthing sysprof tmux trash-cli waybar wlsunset
            LocalPackages: edid-asus-1-1.fc34.noarch
                Initramfs: --include /etc/initramfs-overlay /

In this output, you can find:

• I removed Firefox with rpm-ostree override remove-I prefer the official build from Flathub.
• Terminals (must run on the host to access the full host filesystem⁵): alacritty, foot, gnome-console. My preferred shell: fish. Tool I frequently need: tmux.
• Services and tools that I want to run without a toolbox: syncthing, distrobox, netconsole-service, trash-cli, htop, fastfetch, lm_sensors, rocminfo.
• Desktop components: fuzzel, hyprlock, i3, kanshi, labwc, lxqt-policykit, mako, quickshell-git, sway, waybar, wlsunset.
• edid-asus and the initramfs-overlay provide the EDID for one of my monitors after AMDGPU broke it back in kernel 4.19.⁶

Along with these, I layer several development tools: gdb, strace, perf, sysprof. These frequently come in handy whenever I need to debug or profile programs running on the host (or do full-system profiling in case of Sysprof).

And then there's dnf. What?

Layering dnf #

What is dnf, a regular Fedora package manager, doing on an immutable Silverblue host system? By itself, it's not very useful indeed, since it can't modify /usr. (Though, it can dnf copr enable, which is convenient. rpm-ostree copr when?)

Where dnf on the host shines, however, is when you combine it with sudo ostree admin unlock. After unlocking, you can install whatever you need in the moment with dnf. This is much faster than rpm-ostree, never requires a reboot, and in fact a reboot makes it all clean up and go away, since it was all in a transient /usr overlayfs.

Example workflows:

• dnf debuginfo-install to debug/profile something on the host with symbols, report crashes, etc.
• dnf install some host-only program to test it. Follow up with rpm-ostree install if you decide to keep it.
• dnf builddep gtk4, then build and sudo ninja install GTK 4 right on the host to test it against host apps. If anything breaks, just reboot, and you're back to a clean working state.

Unlocking + layering dnf is a very powerful development workflow to the point where I'd almost want dnf included in Silverblue by default. Unfortunately, this workflow is also unobvious enough that the dnf maintainers accidentally prevented it from working some time ago (thankfully, quickly corrected). I understand the UX concern about having dnf visibly available when it cannot work outside this specific workflow, but perhaps Silverblue could just hide it somehow unless the host is unlocked, or rename the dnf binary?

Persistent unlocking #

Generally to put something persistently on the host, you'd just layer it with rpm-ostree install. However, sometimes what you want is a temporary change that also happens to persist across reboots.

This sounds weird, but consider testing a kernel build. You want it to be temporary and easy to roll back, but you kinda have to reboot into the new kernel. And you also don't want to spend extra time building and layering .rpms.

For this situation, ostree admin unlock comes with a --hotfix flag. It'll persist the temporary overlay across reboots, and will only reset itself once you explicitly make some change with rpm-ostree. Note that you never lose the ability to reboot into the previous, working system.

Summing it all up #

So, this is what my development workflow looks like.

• Most work happens in one kitchen-sink toolbox that I (like to but am not required to) reinstall every Fedora release to keep cruft from building up. This includes building and running niri on a TTY.
• After finishing a change, I unlock the host with sudo ostree admin unlock, copy over the niri binary, and re-log in to test it in my real session. This will automatically reset upon a reboot.
• When working on a long-running branch, I'll build a work-in-progress niri .rpm and layer it with rpm-ostree install to persist the new version across reboots.
• I use dnf install on the host when I want to throwaway-test something host-specific and have it automatically reset upon a reboot.

Over time I made a few small quality-of-life tweaks to smooth out some rough edges in this workflow.

For example, toolbox enter is a mouthful and always drops me into bash. Enter t, a script in my ~/.local/bin/, always available in $PATH:

#!/bin/bash

if [ $# -eq 0 ]; then
    command=fish
else
    command="$(printf "%q " "$@")"
fi

exec toolbox run -c fedora-toolbox-44 bash -ic "$command"

Now, typing t puts me in the toolbox directly into my dear fish shell. Typing

t some-program "with complex" arguments | grep "and stuff"

also works as expected, with correct argument passing thanks to printf "%q ".

This works for .desktop files too. Say, you installed VSCode in the toolbox and got a .desktop file. Just change:

Exec=/usr/share/code/code --ozone-platform-hint=auto %F

to:

Exec=t /usr/share/code/code --ozone-platform-hint=auto %F

and it'll run in the toolbox. (I understand distrobox handles .desktop files automatically.)

Note that I use toolbox run but route the command through bash. This is necessary to get all environment variables like $DEBUGINFOD_URLS that distros keep stubbornly putting in /etc/profile.d/ scripts, which of course don't get sourced without a bash -i.

Another quality-of-life improvement was binding a separate hotkey to spawning a terminal directly in the toolbox. I actually noticed that most of the time, when I open a terminal, I want to be in the toolbox, so now my SuperT spawns the toolbox Alacritty, while the less convenient SuperShiftT spawns the host Alacritty.

Furthermore, at some point I got tired of waiting for the…

┌ ~
└─ hyperfine -w 3 --shell=none 'true' 't true'
Benchmark 1: true
  Time (mean ± σ):     411.9 µs ±  35.8 µs    [User: 248.9 µs, System: 111.3 µs]
  Range (min … max):   374.1 µs … 1147.6 µs    5794 runs

Benchmark 2: t true
  Time (mean ± σ):     257.8 ms ±   2.0 ms    [User: 3.0 ms, System: 6.1 ms]
  Range (min … max):   255.2 ms … 260.5 ms    11 runs

Summary
  true ran
  625.92 ± 54.60 times faster than t true

…extra 250 ms for toolbox run, and wrote a script that keeps Alacritty running as a daemon inside (and outside) the toolbox, making opening a new terminal window always instant. As a bonus, this happens to fix the SIGHUP problem that I mentioned above: since Alacritty runs directly inside the toolbox, closing its window will properly close the terminal app running inside.

(Eventually I went even further and made a tiny service for fun that runs inside the toolbox, listens to a socket, and runs the command it receives. I only use it in .desktop files though instead of t to avoid the 250 ms delay.⁷)

What about other systems? #

I quite like my Silverblue setup. It very much works, and with the tools that it has, it lets me do anything that I might need.

Silverblue is not without its problems however, so I've been thinking about what parts of the experience I find important, and how well other distributions currently satisfy them.

1. The ability to reboot to a previous, working system. Most new atomic/immutable distros can do this since it's the main value proposition. It's also possible on NixOS. On traditional distros I think you can get something close with btrfs snapshots, but it requires a complex setup.

A/B updates tie closely into this, where rather than mutating the running system, an update is prepared in a separate folder, then atomically swapped with the previous system version (which remains available to boot into should something go awry).

2. Anti-hysteresis. The host system always stays clean, packages don't build up over time.

On a normal distro, a few months is enough for you to scarcely have any idea about all the random one-off packages you installed and forgot about, especially various development tooling and build dependencies not to mention the texlive-full installation. They use up disk space and time during system updates, sometimes cause conflicts and other annoying issues. Config migrations build up, and your system gradually drifts away from a clean well-tested upstream state.

Immutable distros solve this by not letting you install stuff on the host, and every updated rebuild of the host system starts from a fresh state, so there's no accumulation of junk.

NixOS and Silverblue do let you add (layer) packages, so they can build up, but:

• they make it sufficiently annoying, making you prefer non-host environments such as toolbox for one-off packages;
• even with layered packages, the system is rebuilt from a fresh state every update.

Technically, you could use toolbox for everything even on a normal Fedora Workstation, but this requires discipline and doesn't save you from config migrations, SELinux labeling changes, etc.

3. The ability to easily install things on the host. This is the part where many newer immutable distros fail to provide a good experience. I need to install programs on the host, whether it's because I want some host desktop components, or to test my own compositor, or whatever.

Often, I want to install something on the host quickly. For distros such as Universal Blue spins and other bootc-based systems, the suggested way to include components on the host is making your own downstream spin. But this works only for long-term packages: I don't want to spend time editing and kicking off a full system build just to test some new terminal or notification daemon, not to mention the whole question of how to keep such a custom system always up to date with its base distro.

Compare this with rpm-ostree install on Silverblue: one command, slow but tolerable, and the OS remains automatically updated with no extra setup.

Some systems are even more limited, like GNOME OS which is based on the Freedesktop SDK. The selection of tools and libraries available in the Freedesktop SDK is (intentionally) much more limited compared to most distros, so in many cases you'll find yourself having to go and build whatever you need from source. If that happens to be something big and complex like Qt (to try a hot new Quickshell-based desktop): good luck; I hope you didn't have plans for the weekend.

A common suggestion for these OSes is systemd-sysext that lets you build an image and overlay it over /usr. Florian Müllner gave a talk at the 2025 GUADEC showing a nice workflow for using sysexts for Mutter and GNOME Shell development and testing on immutable distros.

It's also possible to enforce system version compatibility checks in sysexts. A system like GNOME OS could build and ship a collection of sysexts version-locked to the runtime they were built against, and automatically updated together with the rest of the system using systemd-sysupdate, resulting in an experience similar to layered packages. (In fact, GNOME OS does have that, just the selection of sysexts is fairly small.)

Some software can be packaged into self-contained sysexts that work on most distros. The Flatcar sysext-bakery is one repository of such sysexts.

What's wrong then? Well, the main limitation of sysexts is that they are meant for tools without dependencies. They do not do any dependency resolution or support any dependencies other than, optionally, the base OS itself. Back to my example, while it's possible to build and ship sysexts for Qt apps that bundle Qt itself, all of those sysexts will carry their own copies of Qt. Even worse, since they are mounted into the same filesystem tree, conflicting files (say, different-version Qt binaries) will get mounted only from one of the sysexts, whichever one happens to mount last. So sysexts aren't a complete replacement for packages (nor are they intended to be).

4. The ability to make transient changes to the host. While I don't immediately see why you couldn't put a writable overlay on any regular distro like what ostree admin unlock does, I haven't seen anyone doing it, or any simple "no thinking necessary" tools for it.¹ Perhaps it's too easy to mess up outside immutable systems?

It's worth noting that some paths like /etc aren't usually covered by immutability and overlays, so you still need to be a bit careful.

Conclusion #

All in all, Silverblue appears to be a sweet spot between offering immutable/atomic guarantees with plenty of useful tooling bundled in, while also being a normal Fedora with a wide package selection available for both persistent layering and quick transient installation. I appreciate the QA and other behind-the-scenes work that goes into my ability to install Silverblue and be reasonably sure that it will work, and keep working, with all of my hardware, and that I won't have to hunt for packages to get a working bluetooth or what have you. My Silverblue installs are the longest I've kept any single distro, and I have no urge to reinstall because my host system remains clean and I know exactly what it comprises.

My issues with Silverblue mostly boil down to some rough edges and slowness of rpm-ostree, and some less than ideal Flatpak repository defaults. Having to do most of the work in a container is somewhat annoying at times, especially when dealing with nested containerization or VMs. But I'm not sure there's a better way fundamentally, without trading host system robustness. For the few things that do require it, I can always unlock the host.

I hope this post sheds some light on immutable system workflows and perhaps inspires you to try one. I'd also love to hear your feedback and suggestions! Did I miss something? Is there a better way of doing things? A new system that solves all problems and makes everything better? Please reach out to me on Mastodon or by email, linked at the bottom of the page!

05 Jun 2026 12:37pm GMT

Do not let the AI to remove the fun part from software development. We shouldn't allow gen AI to write software just because it "can". First, we must ask if it "should" do it, and even then, we should ask if we want to delegate the fun part, the thinking, the writing, the learning.

Remember what's important, journey before destination, we are the Code:

Do not let AI to destroy the community, do not let it destroy the technological knowledge commons.

tl;dr

Open Source maintainers are dealing with a lot of new reports and pressure to "fix" the project due to generative AI.

We need to find a way of stopping this and get back to something maintainable before all maintainers get burned out and look for a job in a farm:

• 100% secure software doesn't exists, so there will be always a possible CVE there. As Spaf said in 1989:

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.

• Fixing bugs, adds new bugs, and if you need to fix something quick, the probability of new bugs will be higher. Do not forget about the First Law of Programming:

If it works, don't touch it

• The amount of CVE reports is lowering the CVE credibility and quality, so if everything is a "high" security issue, we can't prioritize now and these reports are not different from random issues in github. Do not listen to The Boy Who Cried Wolf

• Stable software is sable because it doesn't change too much. It's something that we are willing to loose trying to reach the impossible of 100% secure software?

The actual problem

There's a lot of money in AI tech right now, and everyone is trying to make the best gen AI tool or just pretend that their tool is the best.

In relation with the software analysis and writing, targeting the open source is the obvious strategy.

1. It's interesting to scrap every line of code, patch, pull request, issue and discussion around software to train your model, so AI scrappers are DDoSing open source projects infrastructure.

2. To promote their tools or themselves, Security Researches are using AI to target any project, reporting High security vulnerabilities, with the only goal of getting a CVE number to say how good they are.

This second point is affecting maintainers, because now you are receiving a lot of poor quality security reports, that are generated with AI and that looks plausible and are hard to read. You need to spend a lot of time to check if there's an actual wolf there or if it's again this boy that's tricking me.

This is burning the energy of maintainers, that instead of doing something productive are wasting their limited time talking with a Stocatic Parrot.

Do not let the AI Bros to use classic manipulation techniques on you!

A lot of open source projects are maintained by volunteers that do the work with passion and love. And even if it's the job that paid your bills, the maintainer can feel the pressure. When someone put a lot of love in something and work on it during years, it's part of his identity, so attacking the software is like attacking the person behind it.

This is nothing new, and a lot of people take advantage of this emotional link to manipulate the maintainer to do something that he do not want to do.

AI bros are using these techniques, do not let them to manipulate you and define your project agenda.

Here's a (not complete) list of known manipulation techniques that you can detect (and disarm!) in your daily community work:

• Flooding the queue. Just create so many new issues that the actual maintainers can't deal with it. You feel responsible for the project and feel bad because your TO-DO list is growing.

• This software is not secure (doesn't do what I want), I will use this other one instead that's better. The classic, "GNOME doesn't allow me to change this specific preference, I'll use KDE from now on".

• This software is low quality, it doesn't follow the (my random) quality standards. Direct attack to the maintainer self-esteem.

• Gaslighting software development. LLM are expert at this and people that uses it just copy the tactic. When the maintainer detects something weird and just tries to blame the other person for reporting nonsense and wasting all people time, it starts to invent new arguments and ignore the previous interaction.

So, take it easy, and remember the best clause in almost any software project, THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU:

Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.

Is the software more insecure in 2026?

No. Anyone old enough could remember how insecure old software was. Do you remember windows 98? Do you remember the internet when everything was http (without that little s at the end), when people use ftp to logging into their server and modify the php code directly on production?

It's true that today we have more dependency on technology, but it's also true that everything is more secure, we have more and better cryptography, we have different levels of isolation, virtual environments, containers, virtual machines...

But we have the feeling that since AI can analyse all the software and look for vulnerabilities, we are doomed, because any stupid kid can hack my over engineered GNU/Linux machine!

First, that's not true, you need to know about security to get something useful from any AI tool. But even if it was true, what can you do about it? We need to be practical and find a balance between risk and usefulness, so do not overestimate the risk just because everyone is talking about it right now.

But even then, the security paranoia is not good for anyone. Software is inherently buggy, people write software and makes mistakes, so a possible vulnerability appears. In theory, these bugs are fixed when discovered, so it's always recommended to update to the latest version, because almost all known bugs will be fixed.

But it's also known that new versions comes with new functionality and code, and that means new "unknown" bugs or different behavior. That's a headache, so that's why the stable and Long Term Support are popular distributions, because "if it works, don't touch it".

Stable packages just get the fixes, not new features, but fixes are also code changes, so there's always a possibility to break something, even with a patch update.

The stable software has a lot of value, do not let the AI security paranoia destroy that, and convert everything in a rolling release with the latest and greatest (and possibly broken) software. Sometimes it's better to keep using something old, with known vulnerabilities that you can mitigate, than use the latest with unknown new vulnerabilities that you can't do anything about.

I will fight AI with AI

Please, do not do that. What I was trying to argue during this long post is not a technical problem. The current burnout problem in open source is a social problem, you can't fix it with a new layer of probabilistic tokens.

• Community reaction against AI. The current industry push for the usage of AI everywhere is affecting a lot of people, and as a reaction a lot of people are directly fighting back. Using gen AI just sends the message that you do not care enough to do it yourself, and destroy the trust on the project.

• It doesn't worth it. Even if the AI works (that it doesn't) it doesn't worth it. Writing code is easier than reviewing, you learn and grow with every new line of code that you write, delegating the fun part and personal growth part to an AI will make you work more miserable and you will be a junior forever.

• It doesn't create community. Think about it, it's hard to get someone involved in a software project, but who will want to read or improve the code produced by a gen AI? The only future collaborator will be another AI.

Take it easy

Just remember, you can always say no, there's no hurry, and there's no need to work on something that you don't want just because other people consider that important.

Free Source is something done by people, for people. The software is important, but the community around it is sometimes more important. We use Free source not because it's technically better (that it is), but because we trust who, how and why are writing it.

Remember why are you doing this, do not remove the Fun part, continue with the Just for Fun mood.

05 Jun 2026 10:00am GMT

I love adaptive interfaces and technology that blends in more than the average human. I've spent literally years tinkering with 'frecency' ordered lists, bought a meural screen and have recently been glorying in the fantastic GNOME Adaptive Brightness.

On that last point, whilst GNOME already has Automatic Screen Brightness, and it is a good feature, dmy3k's extension goes further on the specific machines with cool hardware: steadier behaviour with changing light, smoother transitions and brightness curves you can tune. One of the things I've been exploring with extensions recently is 'this feature, only more so' and adaptive brightness is a good example.

Living far from the equator, evenings happen. The room goes grey, the window stops being a useful light source and GNOME is still cheerfully in light mode because I told it to be bright at the time one takes screenshots. Night Light is already doing its bit by then. The display has warmed up, which is nice, but the rest of the interface lacks the level of 'darque' required. I wanted the normal GNOME appearance preference to follow the day as well: light while it still feels like day, dark once the evening has properly arrived. Users of other operating systems may be aware of this feature, but for the purposes of this blog post let us pretend that everything below is entirely unique.

So I hacked up Sunset Appearance, a small GNOME Shell extension for GNOME Shell 45 to 50. At civil dusk it writes the same setting GNOME Settings uses:

org.gnome.desktop.interface color-scheme = 'prefer-dark'

At civil dawn it sets it back to:

org.gnome.desktop.interface color-scheme = 'default'

My dad was an aviator, so I got to hear a lot of exciting words growing up, such as 'civil twilight', which always makes me think of Romeo and Juliet. Sunset turns out to be a surprisingly slippery concept, and very longitudinally mediated. In London in summer there can be plenty of useful light after the sun has dipped below the horizon, and the desktop does not need to go 'darque' the moment the sun touches the skyline. Nautical and astronomical twilight are too late for an interface preference, and in some places at some times of year they can fail to happen in the normal way at all.

Civil twilight is when the centre of the sun is 6 degrees below the horizon and when it really does feel like the world has changed character.

Location is awkward too, because civil dawn and dusk need latitude, longitude and date. There's some interesting fallback logic to infrequently get a coarse location (good enough for a city) and then fall back to cached data if available as Night Light already needs much the same information. Frequent readers will remember my concerns over London, Ontario being above London, England in many search boxes so there is no virtue in making the user type London into another small box. If neither source has usable coordinates, nothing changes.

Manual override behaviour is another thing that avoids annoyance. If the extension sets dark mode at dusk and I then change GNOME back to light mode, I meant that. After any override, it waits until the next scheduled dawn or dusk transition before touching the setting again.

Solar time code has an unreasonable number of edges for something everyone thinks they intuitively understand. Keeping with my aggressive policy on internationalisation the tests keep London as the ordinary case, then poke at time zones, date line longitudes, DST changes, Antarctic stations, Arctic towns, awkward offsets such as Lord Howe and Chatham and cases where civil dawn or dusk may not exist at all. My time reading brr and pretending to be in New Zealand to solve work bugs was not poorly spent.

Right now Sunset Appearance can be built from source. At some point I may choose to distribute it more widely, or even see if someone has already solved my problem better.

03 Jun 2026 9:50pm GMT

Not the best film ever, but in today's Hollywood landscape it's a rare breath of fresh air. Kane Parsons takes the internet meme concept he started on YouTube and actually makes a feature-length film that's doing great at the box office.

The mood is great. That unsettling stillness of these generic liminal spaces. For something that builds a feeling / mood, the flick would benefit from a butcher in the editing room. I'd probably still not give it the extra star, but this really isn't the kind of movie that needs the extra 20 minutes.

Biggest entertainment was definitely watching my son freak out in the third act. :)

★★★★☆

03 Jun 2026 12:00am GMT

This first blog post marks the opening of the internationalization blog! The i18n team will use it to share news and projects on the current plans. Don't forget to subscribe!

The i18n team has seen some changes recently, at the beginning of 2026 and we thought it was necessary to publicly announce this change and introduce ourselves a bit.

Before all, we want to greet and deeply thank all internationalization coordinators that participated in the project so far and made GNOME what is is now. We are a global software community of volunteers, leading the free software ecosystem and are accessible in many languages. With this, we cover almost everyone on Earth. Thank you very much Andre, Alexandre, Claude, Daniel, Gábor, Gil, Mario, Piotr, Petr, Kjartan and all the others. Without you this wouldn't have been possible.

What is internationalization?

Internationalization, or i18n for short, is the act of ensuring software or documentation can be used in other languages, countries, and cultures. This means designing and developing applications in a way that removes barriers to localization, making it possible to adapt them without requiring significant engineering changes.

In practice, this involves separating user-facing text from the source code, so it can be translated easily, and ensuring that the software correctly handles different character sets and writing systems, including right-to-left scripts. It also means being mindful of cultural conventions such as date and time formats, number formatting, currencies, and units of measurement.

Internationalization goes beyond text. It includes accommodating differences in sorting rules (collation), keyboard input methods, plural forms, and even layout considerations, as translated text can vary significantly in length. Developers must also ensure that their software supports Unicode and uses libraries or frameworks that simplify handling these variations.

For the GNOME community, internationalization is a collaborative effort between developers, designers, and translators. By preparing software properly, the i18n team enables localization contributors to focus on producing high-quality translations, ensuring that GNOME is accessible and welcoming to users all around the world.

A new team

The team has reborn with new faces: Anders Jonsson, Rafael Fontenelle and Guillaume Bernard, respectively coordinators of the Swedish, Brazilian Portuguese and French team. Let's introduce ourselves a bit…

Rafael (@rafaelff) is coordinator of the GNOME Brazilian Portuguese Team for more than 13 years after a short but intense period of contribution as translator. Besides GNOME, he contributes to the translation of Python Docs, R language, Fedora, TranslationProject (GNU projects, etc.) and others. Also maintains some packages in Arch Linux's AUR.

Anders (@ajonsson) is coordinator of the GNOME Swedish Team for over 10 years, translator in the Swedish branch of the Translation Project, and a member of the GIMP Team with a focus on internationalization questions and testing.

Guillaume (@gbernard) is coordinator of the GNOME French Team since this year after 14 years of contributions, first as a translator, reviewer and after a few years, he has been involved in submitting team's translations. He is the maintainer of GNOME Damnes Lies, our translation platform since 2020. He took this responsibility after years of dedication from Claude. Thank you again for this mentorship!

02 Jun 2026 12:00pm GMT

Nine months ago, I had to field quite a few angry comments from folks who told me they intended to drop their GNOME Foundation memberships in the wake of confusing and opaque board behaviour. I say to you now what I told each of them back in September:

Stay and fight.

The GNOME Foundation saw a much needed - and long overdue - changing of the guard back in August of 2025. In the past 12 months, the Foundation has finally made the improvements it should have been making over the past decade:

• 2025-05-09 - GNOME's infra team had its first management review - it was the cleanest infrastructure review I've performed in my career. [edit]
• 2025-05-16 - Foundation Reports begin in earnest as a first small step toward a transparent GNOME Foundation. We begin the hunt for a new Treasurer.
• 2025-05-23 - We started a Foundation Handbook to match handbook.gnome.org. (This has since migrated to a wiki.) We started moving all the Foundation's documents into a central location. Project management began at the Foundation for the first time ever.
• 2025-05-28 - The Foundation publicly acknowledged that attacks on our Matrix servers, using illegal images, constitute crimes.
• 2025-06-06 - Both donate.gnome.org and (later) fellowship.gnome.org are pitched and accepted by the board. We brought on Deepa Venkatraman as Treasurer. Bart Piotrowski set up vault.gnome.org for passwords.
• 2025-06-14 - Andrea Veri completed the transition to donated AWS resources for GNOME infra.
• 2025-06-20 - donate.gnome.org is released, thanks to the hard work of Bart, Sam Hewitt, and Jakub Steiner.
• 2025-06-26 - The "Donate Less" campaign begins, in anticipation of the outbound program that would become fellowship.gnome.org.
• 2025-07-05 - The concept of fellowship.gnome.org goes public. Work on the corresponding donate.gnome.org shell notification starts. We tightened fiscal controls. We added redundancy to all our financial, legal, and operational processes. We interviewed a pipeline of candidates and selected Ignacy Kuchciński to complete the work under the Digital Wellbeing grant.
• 2025-07-12 - We invited postmarketOS to the Advisory Board.
• 2025-07-21 - We started stabilizing the GNOME Foundation's finances for the long term by redefining the Board Reserve and taking a hard look at balancing year-on-year (annual recurring) revenue and expenses. We added the first-ever redundant signatories on bank accounts.
• 2025-08-08 - We created a shared online space for Advisory Board members to collaborate.
• 2025-09-05 - First corporate sponsor.
• 2025-09-12 - Deepa's budget process is "the best the Foundation has ever had," according to multiple directors.
• 2025-10-10 - Digital Wellbeing is delivered. The Foundation gets a much-needed credit card policy.
• 2025-10-24 - A new Finance Advisor arrives. (An important role at a 501c3.)
• 2025-11-28 - The budget is balanced. More importantly, the budget report contains the commitment to balancing recurring expenses and recurring revenue, continuously.
• 2025-12-19 - Deepa joins as a full director and remains Treasurer.
• 2026-01-09 - A new automated accounts payable and accounts receivable system is installed.
• 2026-03-20 - Financial reporting moves from quarterly to monthly.
• 2026-04-17 - The Fellowship Program begins! Users' donations come full-circle: a percentage of every donation now goes directly to developers.
• 2026-05-15 - Finances are on-target. The Foundation opens a position for Finance Director.
• 2026-05-29 - Four old finance platforms are retired as the finances of the Foundation are automated and simplified. The Foundation introduces a Concern Escalation Policy: if members feel that directors or staff are abusing their positions with policy violations, illegal activity, discrimination, or conflicted behaviour, they're provided the reassurance that they can blow the whistle without risk of retaliation.

That's a lot for one little nonprofit. But this is the beginning of GNOME Foundation 2.0, not the end. The work must continue and there is still plenty to be done.

If you let your membership expire in recent years, get it back. If you are thinking of leaving, don't. And if you are thinking of running for board elections, run.

The GNOME Foundation is the healthiest it's ever been. It's reducing costs and focusing on its actual mission: GNOME. The excellence demanded of GNOME hackers is now demanded of the Foundation, too. You can be a part of continuing that trajectory.

There has never been a more meaningful time to join the GNOME Foundation board.

EDIT: "GNOME's infra team had its first management review - it was the cleanest infrastructure review I've performed in my career." was previously "GNOME's infra team had its first management review - it was spotless." Someone on Reddit took issue with the use of the word "spotless". This edit serves to accommodate them.

01 Jun 2026 1:59am GMT

This article is also available in the B2B Services section on the gedit website.

Several business-to-business services are possible around gedit:

• Development of a new plugin.
• Development of a new text editor or Integrated Development Environment (IDE) based on the libgedit.
• Code maintenance.
• Training.
• Support.
• Creation of Long-Term Support (LTS) versions.
• Developer Experience (DX) guidance.
• […] Come with your own ideas to collaborate with the gedit project.

Target audience

• Operating System / Linux distributions: for your installed-by-default text editor.
• GTK-based desktop environments: to maintain a text editor or IDE, and to adhere to your Human Interface Guidelines (HIG).
• Scientific sector: to build developer tools.
• Education sector: to build easy-to-learn developer tools.
• New programming languages / development platforms: you're designing and implementing a new programming language, and you need developer tools for your users.
• Older programming languages users: you're a big organization and you have a lot of legacy code. You want better developer tools to be more productive.
• Markup or domain-specific languages: to better promote your language, you would like first-class support for it.

The libgedit shared libraries

gedit is not just a general-purpose text editor application, there is a "libgedit" underneath!

A lot of gedit features are implemented as re-usable code, as a set of shared libraries. So new apps - text editors and IDEs alike - can be built on top. There is an ongoing effort from the gedit project to make more code re-usable.

An example of an IDE based on the libgedit is Enter TeX.

The libgedit is in turn based on the very flexible GTK graphical toolkit.

GTK 3 or GTK 4

The libgedit currently targets GTK 3. If you want to develop with GTK 4, there is the GtkSourceView library (but it doesn't contain all the libgedit features). Another possibility is to first port the libgedit to GTK 4.

The plugin system

gedit has a powerful plugin system mechanism, to extend the application. You can leverage it for prototyping additional features, or as the final solution that requires less efforts than creating a new specialized text editor.

You can also combine the best of both approaches:

• First implement a feature that is based on libgedit.
• Then wrap your feature in a gedit plugin so it can readily be used.
• Finally, as an option, create a custom text editor app, re-using the same implementation of your feature(s), integrating everything well together.

Other developer tools

The text editor part is essential, it is the central feature of an IDE. But other developer tools can be developed as well.

For instance, Devhelp can be used for browsing and searching API documentation. Almost all its code is re-usable; like for gedit, there is a libdevhelp toolkit under the hood.

Advice to not start from scratch

A little advice: please don't create a new text editor or IDE from scratch, base your work on existing, high-level libraries like the libgedit. Even if it looks simple on paper, developing a feature-full text editor is a lot of work.

Use the libgedit from your preferred programming language

libgedit and GTK can be used from a wide range of programming languages, and the support for additional languages can be implemented too. This is thanks to GObject Introspection. See the list of language bindings for the GTK project.

Open-source or proprietary software

libgedit and GTK are licensed under the GNU Lesser General Public License (LGPL), which allows to develop proprietary software on top.

gedit plugins need to be distributed as free/libre software, under the GPL license.

Who to collaborate with

• Sébastien Wilmet, the current maintainer and main developer of gedit and libgedit.
• You? If you're or work for a consultancy company specialized in GNOME, GLib or GTK, and want to be part of this project, don't hesitate to get in touch!

30 May 2026 10:00am GMT

Update on what happened across the GNOME project in the week from May 22 to May 29.

GNOME Core Apps and Libraries

Maps ↗

Maps gives you quick access to maps all across the world.

mlundblad announces

Thanks to hard work by James Westman, Maps now supports dowloading map areas for offline use!

Document Viewer (Papers) ↗

View, search or annotate documents in many different formats.

lbaudin announces

Papers 50.2 and 49.7 were released this week with a (unusually high) number of bug fixes. Notably, several fractional scaling issues should be fixed thanks to the work of balooii, including both performance and display issues.

Libadwaita ↗

Building blocks for modern GNOME apps using GTK4.

Jamie (she/her) reports

The upcoming version of Libadwaita now supports binding properties to CSS Classes and vice versa, making it easier to dynamically toggle CSS classes on widgets. This will be available in the upcoming GNOME release.

GNOME Circle Apps and Libraries

Sophie (she/her) reports

We published a blog post with update from the Circle Committee. We are addressing our current review backlog, our new AI policy, new handling of submission issues, earlier reminders about outdated runtimes on Flathub, and new benefits for Circle projects.

Lőrinc Serfőző reports

A new version of Exercise Timer was released! This is a quality-of-life update for this simple app for high intensity interval training. Most notably, the training page has been updated with a custom progress indicator. Minor updates include an Undo option for deleted trainings and an update to the latest GNOME runtime. Get Exercise Timer from Flathub: https://flathub.org/en/apps/xyz.safeworlds.hiit

Resources ↗

Keep an eye on system resources

Sophie (she/her) says

Resources has been accepted into the GNOME Incubator, with the goal of eventually replacing the current System Monitor in GNOME Core. You can try the current development state via the nightly Flatpak or on GNOME OS.

If you find any issues or regressions compared to the current System Monitor app, please report them in the Resources issue tracker. The potential inclusion into Core is tracked under App Organization. Distributions are encouraged to package the app and report any issues they foresee with a possible transition to Resources.

Congrats and big thanks to nokyan for writing and maintaining this app!

Third Party Projects

Jan-Willem reports

This week I released Java-GI 1.0.0-RC1. As the version number suggests, this is the first step towards a "stable" release. With multiple cool apps already on Flathub, like Speed of Sound and Subsound, and several more in active development, I figured it's time for backward compatibility and API stability.

Notable improvements in this release are:

• Support for non-UTF8-encoded filenames
• Specialized exception types (deriving from GErrorException)
• Improved Windows support
• Bug fixes around memory management, class instantiation and nullability annotations.

Always wanted to build a GNOME app, using your Java (or other JVM language) skills? Give Java-GI a try!

lo reports

Nucleus version 3 is released! Nucleus is a periodic table app.

This update brings a theoretical indicator to Ununennium, as well as some updated properties for Ununennium. French and Italian translations were added and the app was updated to the GNOME 50 runtime as well.

Get it on Flathub: https://flathub.org/apps/page.codeberg.lo_vely.Nucleus

seja-arctic-fox says

I'm happy to annouce that VidCom 0.82 has just been released!

VidCom is a simple utility for archiving videos, written in C++, using ffmpeg for video compression. Major changes in this version include:

• Multiple stream and subtitle support, switching between mp4 and mkv containers as needed
• Faster seeking when Cut Feature is enabled
• Fix to correctly compute bitrate when Cut Feature is enabled
• Audio is now encoded in Archive mode as well. Previously it was just copied
• New cut widget and time setters
• UI rework to fit more into the GNOME ecosystem
• Switch to GNOME 50 Runtime
• Status pages for 'empty queue' and 'encoding' states
• Improved page for viewing results, which does not create a popup window anymore
• Popup messages changed to toasts
• Small UI desing adjustments; rounded thumbnail corners, better info distribution, formatting bugs
• UI refactor

VidCom is avaiable on Flathub and AUR. Source code can be viewed here

Anton Isaiev announces

RustConn Versions 0.15 Released

I want to thank everyone who opened a request or sponsored the project. All this time, the main features I shipped came from user requests. The most important ones: broadcast, a keyboard passthrough mode that disables the app shortcuts so they go straight to the remote desktop, Windows scripts, and a wizard for an easy start with predefined custom commands. I use all of this every day and it genuinely makes life simpler - which was the whole idea behind the project.

Homepage: https://github.com/totoshko88/RustConn Flathub: https://flathub.org/en/apps/io.github.totoshko88.RustConn

Solitaire ↗

Play Patience Games

Will Warner announces

Solitaire 50.2 is out!

Here is what's new:

• Added translations: Georgian (Ekaterine Papava), 'Chinese (China)' (lumingzh), Ukrainian (Yuri Chornoivan), Serbian (Марко Костић)
• Updated translations: Cornish (Flynn Peck), Slovenian (Martin S.), Basque (Asier Saratsua Garmendia)
• Updated the scores dialog
• Added an option to the preferences to set the seed for dealing
• Made unfinished games automatically save
• Fixed a bug where cards could be dragged from the foundations in Spider
• Made cards not get selected when dealt
• Increased the height of tableau in Klondike
• Added a 'Redeal Game' option to the new game dialog
• Made Tri-Peaks allow Ace + King card combinations

You can get Solitaire on Flathub

Gitte ↗

A simple Git GUI for GNOME

Christian reports

Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.5.0 release! 🎉

The headline feature this time is commit and tag signing. Gitte now supports GPG, X.509 and SSH signing, validates signatures right in the commit log, and ships a dedicated "Signing status" window that walks you through setting everything up. Encrypted signing keys are handled via a new gitte-askpass helper, and every relevant dialog (commit, merge, revert, create tag, …) gets a per-action override switch so you can decide whether to sign on a case-by-case basis. The default respects the repository configuration.

On top of that, the commit message, revert and create tag dialogs were overhauled, dialogs now carry descriptive subtitles for better discoverability, and there's a new Ctrl+O / Cmd+O shortcut to open a repository. Under the hood Gitte moved to the new git2 API, switched from polling to IO-event-based refreshes, and gained a Cornish translation (thanks to Flynn Peck!).

Get it on Flathub, for macOS or have a look at the Code.

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!

29 May 2026 7:49pm GMT

Welcome to another update about everything that's been happening at the GNOME Foundation. As has become my custom, this post covers a two week period, this time from 18 May until today, 29 May. As usual the Foundation continues to be busy, with events, infra, governance, and accounting activities all happening simultaneously. Read on for more information!

Events

Linux App Summit (LAS) 2026 was held in Berlin over the 16-17 May weekend. I've heard quite a few reports now, and everyone seemed extremely positive about the event. Kristi wrote a nice summary if you want more details.

The GNOME Foundation had two team members on the ground helping with running the event, which we co-organize with KDE. I'd like to take this opportunity to give a big thank you to the event's sponsors: openSUSE, Tuxedo, Nextcould and Codethink. This event wouldn't be possible without your support.

In addition to LAS, work is continuing on arrangements for GUADEC 2026. The deadline for travel sponsorship applications has now passed, and the Travel Committee has met to decide who will be funded. Notifications will be going out soon.

Board Elections

The process is officially underway for this year's Board elections. Terms on our Board of Directors are two years in length, and each year half the board seats are open for election. This year we have five seats being contested.

The 2026 election has a slightly different schedule to previous years. In the past, there was no gap between the candidacy period, in which people can announce their intention to run, and the voting period. This meant that there was little opportunity for last-minute candidates to participate in discussion prior to voting taking place.

To address this, we've added a one week discussion period to the schedule, which will run between 8 and 15 June, between the candidacy and voting periods. This will hopefully give us opportunity to have more structured and inclusive debate amongst the candidates. We are still figuring out what that might look like, so if people have ideas or want to help, let me know in the comments.

GNOME Fellowship

We are currently in the very final stages of confirming and announcing the successful candidates for the inaugural round of the Foundation's Fellowship program. Expect an announcement very soon.

Got a Concern?

Last week we introduced a new policy for handling of concerns about the Foundation, which is now part of the project handbook.

The new policy covers how to report concerns about people who are working for the Foundation, either in a paid or voluntary capacity. It also covers more general concerns about the Foundation.

The main goals of the policy are to:

• have a documented reporting procedure for those who have concerns relating to the Foundation
• clarify how concerns will be responded to
• provide reassurance for those reporting concerns, including that concern reports are welcome, are taken seriously, and will never result in retaliation

We hope that this policy will make it clear how you can inform us of a concern if you have one. We also want to emphasise that we want to hear concerns, so we can address them. Please do use the new reporting procedure.

Finance/Accounting

Work has continued on the finance and accounting operation over the past two weeks. Highlights include:

• Our transition to a monthly rather than quarterly close reached a significant milestone this week, with the completion of our April finance reports within three weeks of the previous month end. This is probably the fastest ever turnaround for our finance operation, and is a huge win for us in being able to effectively manage our finances.
• Following input from the board, corrections have now been sent to the accountants for our audit and annual tax filing.
• Applications are still open for our Director of Finance and Operations part-time contract. Candidates have until 4 June to submit.
• Finally, as I mentioned in my last update, we are in the process of retiring a number of finance platforms as we consolidate and streamline our operation. This week saw another platform retired, which brings the total number of eliminated platforms to four.

Infrastructure

Our infrastructure experienced a DDoS attack last weekend, which Bart and Andrea have been dealing with. Thankfully it seems that services weren't too badly affected, and we've already improved our protection against similar attacks in the future.

Also on the infra side, Bart wasn't at LAS this year, but he did spend some time writing two great posts about Flathub's internals: How does Flathub even work? and Why are Flathub downloads so slow sometimes?. They're a fascinating read if you're interested in Flathub.

That's it from me! As always, thanks for reading, and see you in two weeks.

29 May 2026 4:41pm GMT