Open Forms is now 0.4.0 - and the GUI Builder is here

A quick recap for the newcomers

Ever been to a conference where you set up a booth or tried to collect quick feedback and experienced the joy of:

• Captive portal logout
• Timeouts
• Flaky Wi-Fi drivers on Linux devices
• Poor bandwidth or dead zones

This is exactly what happened while setting up a booth at GUADEC. The Wi-Fi on the Linux tablet worked, we logged into the captive portal, the chip failed, Wi-Fi gone. Restart. Repeat.

We eventually worked around it with a phone hotspot, but that locked the phone to the booth. A one-off inconvenience? Maybe. But at any conference, summit, or community event, at least one of these happens reliably.

So I looked for a native, offline form collection tool. Nothing existed without a web dependency. So I built one.

Open Forms is a native GNOME app that collects form inputs locally, stores responses in CSV, works completely offline, and never touches an external service. Your data stays on your device. Full stop.

What's new in 0.4.0 - the GUI Form Builder

The original version shipped with one acknowledged limitation: you had to write JSON configs by hand to define your forms.

Now, I know what you're thinking. "Writing JSON to set up a form? That's totally normal and not at all a terrible first impression for non-technical users." And you'd be completely wrong, to me it was normal and then my sis had this to say "who even thought JSON for such a basic thing is a good idea, who'd even write one" which was true. I knew it and hence it was always on the roadmap to fix, which 0.4.0 finally fixes.

Open Forms now ships a full visual form builder.

Design a form entirely from the UI - add fields, set labels, reorder things, tweak options, and hit Save. That's it. The builder writes a standard JSON config to disk, same schema as always, so nothing downstream changes.

It also works as an editor. Open an existing config, click Edit, and the whole form loads up ready to tweak. Save goes back to the original file. No more JSON editing required.

Libadwaita is genuinely great

The builder needed to work well on both a regular desktop and a Linux phone without me maintaining two separate layouts or sprinkling breakpoints everywhere. Libadwaita just... handles that.

The result is that Open Forms feels native on GNOME and equally at home on a Linux phone, and I genuinely didn't have to think hard about either. That's the kind of toolkit win that's hard to overstate when you're building something solo over weekends.

The JSON schema is unchanged

If you already have configs, they work exactly as before. The builder is purely additive, it reads and writes the same format. If you like editing JSON directly, nothing stops you. I'm not going to judge, but my sister might.

Also thanks to Felipe and all others who gave great ideas about increasing maintainability. JSON might become a technical debt in future, and I appreciate the insights about the same. Let's see how it goes.

Install

Snap Store

snap install open-forms

Flatpak / Build from source

See the GitHub repository for build instructions. There is also a Flatpak release available .

What's next

• A11y improvements
• Maybe and just maybe an optional sync feature
• Hosting on Flathub - if you've been through that process and have advice, please reach out

Open Forms is still a small, focused project doing one thing. If you've ever dealt with Wi-Fi pain while collecting data at an event, give it a try. Bug reports, feature requests, and feedback are all very welcome.

And if you find it useful - a star on GitHub goes a long way for a solo project. 🙂

Open Forms on GitHub

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.

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. hat 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 defuct 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.

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 it. 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 A I, 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.

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.

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.

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!

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?

Fedora Silverblue makes a frequent occurrence in my niri release notes screenshots.

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-analyzer s 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 Ctrl Alt F3 , 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 . ^{1 2} 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 Super T spawns the toolbox Alacritty, while the less convenient Super Shift T 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!

• Up too early. Dropped H. into XJTAG before her epic Asian trip. Lovely to meet up with John Hall and catch up after a couple of decades.
• Tried to pack, and gather together things for the Church's Men's walking weekend.
• Published the next strip: Ejecting a do-er, "if in doubt, kick them out!"; cancellation based on un-proven allegation seems to be the spirit of the age: