I published three Rust crates:

• name-to-handle-at: Safe, low-level Rust bindings for Linux name_to_handle_at and open_by_handle_at system calls
• pidfd-util: Safe Rust wrapper for Linux process file descriptors (pidfd)
• listen-fds: A Rust library for handling systemd socket activation

They might seem like rather arbitrary, unconnected things - but there is a connection!

systemd socket activation passes file descriptors and a bit of metadata as environment variables to the activated process. If the activated process exec's another program, the file descriptors get passed along because they are not CLOEXEC. If that process then picks them up, things could go very wrong. So, the activated process is supposed to mark the file descriptors CLOEXEC, and unset the socket activation environment variables. If a process doesn't do this for whatever reason however, the same problems can arise. So there is another mechanism to help prevent it: another bit of metadata contains the PID of the target. Processes can check it against their own PID to figure out if they were the target of the activation, without having to depend on all other processes doing the right thing.

PIDs however are racy because they wrap around pretty fast, and that's why nowadays we have pidfds. They are file descriptors which act as a stable handle to a process and avoid the ID wrap-around issue. Socket activation with systemd nowadays also passes a pidfd ID. A pidfd ID however is not the same as a pidfd file descriptor! It is the 64 bit inode of the pidfd file descriptor on the pidfd filesystem. This has the advantage that systemd doesn't have to install another file descriptor in the target process which might not get closed. It can just put the pidfd ID number into the $LISTEN_PIDFDID environment variable.

Getting the inode of a file descriptor doesn't sound hard. fstat(2) fills out struct stat which has the st_ino field. The problem is that it has a type of ino_t, which is 32 bits on some systems so we might end up with a process identifier which wraps around pretty fast again.

We can however use the name_to_handle syscall on the pidfd to get a struct file_handle with a f_handle field. The man page helpfully says that "the caller should treat the file_handle structure as an opaque data type". We're going to ignore that, though, because at least on the pidfd filesystem, the first 64 bits are the 64 bit inode. With systemd already depending on this and the kernel rule of "don't break user-space", this is now API, no matter what the man page tells you.

So there you have it. It's all connected.

Obviously both pidfds and name_to_handle have more exciting uses, many of which serve my broader goal: making Varlink services a first-class citizen. More about that another time.

27 Mar 2026 12:15am GMT

Update on what happened across the GNOME project in the week from March 20 to March 27.

GNOME Releases

Sophie (she/her) reports

GNOME 48.10 has been released. This is the final release for GNOME 48. If you are still using the GNOME 48 runtime on Flathub, you can update to the GNOME 50 runtime directly. The GNOME 48 runtime will be marked as end of life (EOL) on April 11. Apps that are still using the runtime at this point will trigger warnings for their users.

GNOME Core Apps and Libraries

Khalid Abu Shawarib reports

Version 50 of Fonts was released this week!

This release includes a redesigned fonts preview grid that is more responsive when scrolling, and have a uniform text baseline.

Moreover, the search bar is now always visible, and supports type-to-search in the main font preview grid.

Python Bindings (PyGObject) ↗

Python language bindings for GNOME platform libraries.

Arjan announces

PyGObject 3.56.2 has been released. This release contains a few fixes:

• Fix issue when do_dispose is called while the garbage collector is running.
• retain object floating state for get-/set-property calls.

As always, the latest version is available on PyPI and the GNOME download server.

GNOME Circle Apps and Libraries

Sophie (she/her) says

As you may already have learned from the GNOME 50 release notes, Sessions has been accepted into GNOME Circle.

Sessions is a simple visual timer application designed specifically for the pomodoro technique. The app is maintained by Felicitas Pojtinger.

Warp ↗

Fast and secure file transfer.

Fina reports

Warp 1.0 has been released, finally breaking the light speed barrier. New features include a new shortcuts dialog, runtime and translation updates. Engage!

Video Trimmer ↗

Trim videos quickly.

YaLTeR reports

I released Video Trimmer 26.03 with an improvement suggested by one of the users: the prefilled filename in the save dialog now includes the trimming timestamps. This way, there are no filename conflicts when extracting several fragments from a video.

I also added several CLI flags to pre-set the start and end timestamp, and the precise trim and remove audio options.

Identity ↗

Compare images and videos.

YaLTeR reports

Identity 26.03 is out with a new time display when hovering the mouse over the video seek bar. I also added Ctrl+2..9 hotkeys to set the zoom level from 200% to 900%.

The window title now shows the current filename, which is helpful with many open tabs. Finally, you can pass the initial --zoom and --display mode on the command line.

Third Party Projects

Haydn Trowell reports

The latest version of Typesetter, the minimalist Typst editor, brings:

• Built-in, automatic grammar checking (currently English only).
• Tooltips for Typst errors and warnings in the editor.
• Keyboard shortcuts for navigating spelling errors.
• New translations: Czech (p-bo), Dutch (flipflop97), Finnish (Jiri Grönroos), Polish (michalfita), Swedish (haaninjo), and Vietnamese (namthien).

Get it on Flathub: https://flathub.org/apps/net.trowell.typesetter

If you want to help bring Typesetter to your language, translations can be contributed via Weblate: https://translate.codeberg.org/engage/typesetter/

Andrea Fontana announces

Hideout is a simple, GTK-based encryption tool written in D, designed specifically for non-technical users who need to password-protect their files without complexity. It follows GNOME's design principles to provide a clean and intuitive experience. On Flathub: https://flathub.org/apps/it.andreafontana.hideout

Jeffry Samuel reports

Nocturne has been released, it allows users to manage their local music libraries with optional Navidrome / Subsonic integration. It includes features such as:

• Playlists
• Automatic lyrics fetching
• Play queue managing
• Album and artist sorting
• Fast searching

For more information visit the website or repository

https://jeffser.com/nocturne/ https://github.com/Jeffser/Nocturne

Anton Isaiev says

RustConn (connection manager for SSH, RDP, VNC, SPICE, Telnet, Serial, Kubernetes, MOSH, and Zero Trust protocols)

Versions 0.10.3-0.10.8 landed this week with changes driven entirely by user feedback:

• Security: RDP passwords no longer exposed in /proc; SSH agent passphrase files are zeroized before deletion; legacy XOR credentials migrated to AES-256-GCM transparently
• Embedded viewer performance: eliminated per-frame pixel buffer allocations (8-33 MB depending on resolution) for SPICE, VNC, and RDP by switching to persistent Cairo surfaces with in-place updates; RDP frame extraction now uses row-based memcpy + bulk SIMD-friendly R↔B swap
• HiDPI fixes: resolved blurry/artifact RDP rendering on HiDPI displays caused by double-scaling; fixed cursor artifacts from transparent padding bleed on scaled displays
• Flatpak sandbox: Zero Trust CLIs (gcloud, Azure, Teleport, OCI) now work correctly by redirecting config paths to writable sandbox directories; fixed CLI detection using extended PATH
• KeePassXC integration: fixed all vault operations failing when KDBX file is password-protected (password was passed as None in 10 call sites)
• Passbolt CLI 0.4.2 compatibility: fixed deserialization failures from field naming changes
• Highlight rules: built-in defaults (ERROR, WARNING, CRITICAL, FATAL) now always apply, not just when per-connection rules exist
• Code quality: shared CairoBackedBuffer module, deduplicated regex compilations, extracted parse_protocol_type() to eliminate 3 duplicate implementations

Thank you for the growing interest in RustConn. All of this work is driven purely by user feedback - every bug report and feature request shapes the project. I reached what I considered "my ideal" months ago, but it turns out users know better. The result is an open-source connection manager that, in my honest opinion, is now more capable and convenient than its commercial competitors - built by engineers, for engineers.

A special thanks to the community members who package RustConn for AUR and other distribution repositories, and to those who ported it to FreeBSD. Seeing people take the time to bring RustConn to new platforms is the strongest signal that the project fills a real need.

Constructive feedback is always welcome: https://github.com/totoshko88/RustConn/issues Project: https://github.com/totoshko88/RustConn Flatpak: https://flathub.org/en/apps/io.github.totoshko88.RustConn

xjuan reports

Cambalache's First Major Milestone!

After more than 5 years, 1780 commits and 20k lines of handcrafted, artisanal Python code I am very pleased to announce Cambalache 1.0 !!!

Cambalache is a WYSIWYG (What You See Is What You Get) tool that allows you to create and edit user interfaces for Gtk 4 and 3 applications.

Read more about it at https://blogs.gnome.org/gtk/2026/03/20/cambalaches-first-major-milestone/

Solitaire ↗

Play Patience Games

Will Warner announces

Solitaire is a new app to play paitence games! It has been about a year since I started working on this, and I am excited to say that Solitaire is now avalible on Flathub. Solitaire has a solver that will tell you if the game you are playing has become impossible to win, and provides hints that are guaranteed to lead to a win. The app features six games: Klondike, FreeCell, Tri Peaks, Spider, Pyramid, and Yukon. Solitaire will also keep track of your scores, using moves or time based scoring. It even lets you change what the cards look like, with seven card themes to choose from.

Shell Extensions

sri 🚀 says

GNOME Shell extensions reviews have become delayed due to our main reviewer being cut off from the Internet. The backlog is getting long and while some community members have stepped up the progress is slow. Much appreciation to those who are stepping up. Please be aware that the review delay means that extensions being updated to GNOME 50 are being delayed.

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!

27 Mar 2026 12:00am GMT

On March 17 we released systemd v260 into the wild.

In the weeks leading up to that release (and since then) I have posted a series of serieses of posts to Mastodon about key new features in this release, under the #systemd260 hash tag. In case you aren't using Mastodon, but would like to read up, here's a list of all 21 posts:

• Post #1: NvPCR Measurements for Activated DDIs
• Post #2: Varlink Transport Plugins
• Post #3: Well-Known Varlink Services
• Post #4: .mstack Overlay Mount Stacks
• Post #5: RefreshOnReload= in Service Units
• Post #6: FANCY_NAME= in /etc/os-release
• Post #7: BindNetworkInterface= in Service Units
• Post #8: importctl pull-oci for Acquiring OCI Containers
• Post #9: systemd-report and Metrics API
• Post #10: udev's tpm2_id built-in and the TPM2 Quirks Database
• Post #11: Devicetree/CHID Database
• Post #12: Varlink IPC for systemd-networkd
• Post #13: systemd-vmspawn knows --ephemeral now
• Post #14: systemd-loginds's xaccess Concept
• Post #15: Unprivileged Portable Services
• Post #16: Image Policy Improvements
• Post #17: LUKS Volume Key Fixation
• Post #18: Journal Varlink Access
• Post #19: Nested UID Range Delegation
• Post #20: PrivateUsers=managed
• Post #21: bootctl install as Varlink API

I intend to do a similar series of serieses of posts for the next systemd release (v261), hence if you haven't left tech Twitter for Mastodon yet, now is the opportunity.

My series for v261 will begin in a few weeks most likely, under the #systemd261 hash tag.

In case you are interested, here is the corresponding blog story for systemd v259, here for v258, here for v257, and here for v256.

26 Mar 2026 11:00pm GMT

26 Mar 2026 10:03pm GMT

I wanted to dip my toes into Kubernetes for my homelab, but I knew I would need some flexibility to experiment. So instead of deploying k3s directly on my server, I

1. Installed a base Debian on my server, encrypting the disk with LUKS and using LVM to partition it.
2. Installed the Proxmox hypervisor on that base Debian
3. Spun up a Debian VM, and installed k3s on it.

Proxmox supports several storage plugins. It allows me to create LVM Local Volumes for the VM disks for example.

This setup allows me to spin up fresh VMs for my experiments, all while leaving my production k3s intact. This is great, but it came up with two problems:

1. When I provision the VM for k3s I need to allocate it a massive amount of disk space. This is because k3s uses a local path provisioner to provision new Persistent Volumes directly on the VM.
2. I can't take snapshots of the Persistent Volumes when doing backups. There's a risk that the data will change while I perform the backup.

The situation looks like the following.

On the LVM disk of the host, I create a VM for k3s. This VM has a virtual disk that doesn't rely on LVM, so it can't create LVM Logical Volumes. The local provisioner can only create volumes on the virtual disk, because it can't escape the VM to create volumes on the Proxmox host.

Because the volumes are created on the virtual disk that doesn't rely on LVM, I can't use LVM snapshots to take snapshots of my volumes.

[!question] Why not LVM Thin?

One solution to address the massive disk requirement could be to use LVM Thin: it would allow me to allocate a lot of space in theory, but in practice in only fills up as the VM storage gets used.

I don't want to use LVM Thin because it puts me at risk of overprovisioning. I could allocate more storage than I actually have, and it would be difficult to realize that my disks are filling up before it's too late.

My colleague Quentin mentioned the Proxmox CSI Plugin. It is a plugin that replaces k3s' local path provisioner. Instead of creating the kubernetes Persistent Volumes inside the VM, it calls the Proxmox host, asks it to create a LVM Logical Volume and binds it to a Persistent Volume in kubernetes.

Using the Proxmox CSI volume, the situation would look like this.

It solves the two problems for me:

1. I can now only provision a small disk for the k3s VM, since the Persistent Volumes will be created outside of the VM.
2. Since Proxmox will create LVM Logical Volumes to provision the Persistent Volumes, I can either do a LVM Snapshot from Proxmox or use Kubernete's Volume Snapshot feature, with some caveats.

Setting up the Proxmox-CSI-Plugin for k3s can be a bit involved, but I'm writing a longer blog post about it.

25 Mar 2026 10:00am GMT

When open source nonprofits ask for donations, one common answer is "I only want to fund code, I don't want to fund anything else." GNOME has created a Fellowship Program to fund direct work on GNOME, a program entirely funded by donations. This is a testament to the Foundation's maturity, as it becomes a direct contributor to the project it stewards.

Let's take a step back to address the code-only argument. It is a misguided reaction, but I can see where its proponents are coming from. In the world of proprietary software, you pay to get your software. You don't realize that this bundles the marketing, accounting, legal, and even HR costs.

In the open source world, everyone can see who contributes code and how that code is built and packaged to create a software solution. A lot of things are not shown in git commits though. A few of them are:

• What did it take to create the Human Interface Guidelines to have a coherent suite of applications? How many designers had to meet, what research did they have to do, did they have to meet in person?
• What did it take to create the Developer Documentation to onboard new developers, help them make their first steps, and turn them into bigger contributors over the years?
• What did it take to build a website to advertize all the cool apps that follow the GNOME HIG?
• What did it take to set up the infrastructure the code lives on, and that builds the software we all love?

GNOME, like many other open source projects, is first and foremost a community. This is a group of people with diverse backgrounds, diverse opinions, who try to find common ground to solve problems. They don't always agree on how to solve problems, nor necessarily on what even is a problem in the first place.

The role of The GNOME Foundation is to provide a place to support its community. Its role is to help its contributors find common ground. Its role is to give them the tools and opportunities to do so.

Some people still don't value this, and want The GNOME Foundation to be a vendor for GNOME. They want to fund developers to produce code, because that's a very visible metric.

For them, and for everyone who's ever wanted to give back to GNOME without knowing how, The GNOME Foundation has created a Fellowship Program. It will directly fund a person to work on what few people want to do in their spare time: maintenance.

Round one focuses on sustainability: improving tooling, build systems, test infrastructure, automation, documentation, developer productivity, and ongoing maintainability. We are not funding feature development: the goal is for each fellowship to leave the project in a more efficient and sustainable state.

This is only fueled by our donations. If you want a direct pipeline between your money and GNOME development, this is it. Donate to GNOME, we can't afford not to have them when Big Tech has so much influence on our lives.

24 Mar 2026 7:00pm GMT

Sustaining GNOME by directly funding contributors

The GNOME Foundation is excited to announce the GNOME Fellowship program, a new initiative to fund community members working on the long-term sustainability of the GNOME project. We're now accepting applications for our inaugural fellowship cycle, beginning around May 2026.

GNOME has always thrived because of its contributors: people who invest their time and expertise to build and maintain the desktop, applications, and platform that millions rely on. But open source contribution often depends on volunteers finding time alongside other commitments, or on companies choosing to fund development amongst competing priorities. Many important areas of the project - the less glamorous but critical infrastructure work - can go underinvested.

The fellowship program changes that. Thanks to the generous support of Friends of GNOME donors, we can now directly fund contributors to focus on what matters most for GNOME's future. Programs such as this rely on ongoing support from our donors, so if you would like to see this and similar programs continue in future, please consider setting up a recurring donation.

What's a Fellowship?

A fellowship is funding for an individual to spend dedicated time over a 12 month period working in an area where they have expertise. Unlike traditional contracts with rigid scopes and deliverables, fellowships are built on trust. We're backing people and the type of work they do, giving them the flexibility to tackle problems as they find them.

This approach reduces bureaucratic overhead for both contributors and the Foundation. It lets talented people do what they do best: identify important problems and solve them.

Focus: Sustainability

For this first cycle, we're seeking proposals focused on sustainability work that makes GNOME more maintainable, efficient, and productive for developers. This includes areas like build systems, CI/CD infrastructure, testing frameworks, developer tooling, documentation, accessibility, and reducing technical debt.

We're not funding new features this round. Instead, we want to invest in the foundations that make future development and contributions easier and faster. The goal is for each fellowship to leave the project in better shape than we found it.

Apply Now

We have funding for at least one 12-month fellowship paid between $70,000 and $100,000 USD per year based on experience and location. Applicants can propose full-time, half-time work, or either - half-time proposals may allow us to support multiple fellows.

Applications are open to anyone with a track record in GNOME or relevant experience, with some restrictions due to US sanctions compliance. A GNOME Foundation Board committee will review applications and select fellows for this inaugural cycle.

Full details, application requirements, and FAQ are available at fellowship.gnome.org. Applications close on 20th April 2026.

Thank You to Friends of GNOME

This program is possible because of the individuals and organizations who support GNOME through Friends of GNOME donations. When we ask for donations, funding contributor work is exactly the kind of initiative we have in mind. If you'd like to sustain this program beyond its first year, consider becoming a Friend of GNOME. A recurring donation, no matter how small, gives us the predictability to expand this program and others like it.

Looking Ahead

This is a pilot program. We're optimistic, and if it succeeds, we hope to sustain and grow the fellowship program in future years, funding more contributors across more areas of GNOME. We believe this model can become a sustainable way to invest in the project's long-term health.

We can't wait to see your proposals!

24 Mar 2026 12:26pm GMT

As I talked about in a couple of blog posts now I been working a lot with AI recently as part of my day to day job at Red Hat, but also spending a lot of evenings and weekend time on this (sorry kids pappa has switched to 1950's mode for now). One of the things I spent time on is trying to figure out what the limitations of AI models are and what kind of use they can have for Open Source developers.

One thing to mention before I start talking about some of my concrete efforts is that I more and more come to conclude that AI is an incredible tool to hypercharge someone in their work, but I feel it tend to fall short for fully autonomous systems. In my experiments AI can do things many many times faster than you ordinarily could, talking specifically in the context of coding here which is what is most relevant for those of us in the open source community.

So one annoyance I had for years as a Linux user is that I get new hardware which has features that are not easily available to me as a Linux user. So I have tried using AI to create such applications for some of my hardware which includes an Elgato Light and a Dell Ultrasharp Webcam.

I found with AI and this is based on using Google Gemini, Claude Sonnet and Opus and OpenAI codex, they all required me to direct and steer the AI continuously, if I let the AI just work on its own, more often than not it would end up going in circles or diverging from the route it was supposed to go, or taking shortcuts that makes wanted output useless.On the other hand if I kept on top of the AI and intervened and pointed it in the right direction it could put together things for me in very short time spans.
My projects are also mostly what I would describe as end leaf nodes, the kind of projects that already are 1 person projects in the community for the most part. There are extra considerations when contributing to bigger efforts, and I think a point I seen made by others in the community too is that you need to own the patches you submit, meaning that even if an AI helped your write the patch you still need to ensure that what you submit is in a state where it can be helpful and is merge-able. I know that some people feel that means you need be capable of reviewing the proposed patch and ensuring its clean and nice before submitting it, and I agree that if you expect your patch to get merged that has to be the case. On the other hand I don't think AI patches are useless even if you are not able to validate them beyond 'does it fix my issue'.

My friend and PipeWire maintainer Wim Taymans and I was talking a few years ago about what I described at the time as the problem of 'bad quality patches', and this was long before AI generated code was a thing. Wim response to me which I often thought about afterwards was "a bad patch is often a great bug report". And that would hold true for AI generated patches to. If someone makes a patch using AI, a patch they don't have the ability to code review themselves, but they test it and it fixes their problem, it might be a good bug report and function as a clearer bug report than just a written description by the user submitting the report. Of course they should be clear in their bug report that they don't have the skills to review the patch themselves, but that they hope it can be useful as a tool for pinpointing what isn't working in the current codebase.

Anyway, let me talk about the projects I made. They are all found on my personal website Linuxrising.org a website that I also used AI to update after not having touched the site in years.

Elgato Light GNOME Shell extension

Elgato Light GNOME Shell extension

The first project I worked on is a GNOME Shell extension for controlling my Elgato Key Wifi Lamp. The Elgato lamp is basically meant for podcasters and people doing a lot of video calls to be able to easily configure light in their room to make a good recording. The lamp announces itself over mDNS, and thus can be controlled via Avahi. For Windows and Mac the vendor provides software to control their lamp, but unfortunately not for Linux.

There had been GNOME Shell extensions for controlling the lamp in the past, but they had not been kept up to date and their feature set was quite limited. Anyway, I grabbed one of these old extensions and told Claude to update it for latest version of GNOME. It took a few iterations of testing, but we eventually got there and I had a simple GNOME Shell extension that could turn the lamp off and on and adjust hue and brightness. This was a quite straightforward process because I had code that had been working at some point, it just needed some adjustments to work with current generation of GNOME Shell.

Once I had the basic version done I decided to take it a bit further and try to recreate the configuration dialog that the windows application offers for the full feature set which took me quite a bit of back and forth with Claude. I found that if I ask Claude to re-implement from a screenshot it recreates the functionality of the user interface first, meaning that it makes sure that if the screenshot has 10 buttons, then you get a GUI with 10 buttons. You then have to iterate both on the UI design, for example telling Claude that I want a dark UI style to match the GNOME Shell, and then I also had to iterate on each bit of functionality in the UI. Like most of the buttons in the UI didn't really do anything from the start, but when you go back and ask Claude to add specific functionality per button it is usually able to do so.

Elgato Light Settings Application

So this was probably a fairly easy thing for the AI because all the functionality of the lamp could be queried over Avahi, there was no 'secret' USB registers to be set or things like that.
Since the application was meant to be part of the GNOME Shell extension I didn't want to to have any dependency requirements that the Shell extension itself didn't have, so I asked Claude to make this application in JavaScript and I have to say so far I haven't seen any major differences in terms of the AIs ability to generate different languages. The application now reproduce most of the functionality of the Windows application. Looking back I think it probably took me a couple of days in total putting this tool together.

Dell Ultrasharp Webcam 4K

Dell UltraSharp 4K settings application for Linux

The second application on the list is a controller application for my Dell UltraSharp Webcam 4K UHD (WB7022). This is a high end Webcam I that have been using for a while and it is comparable to something like the Logitech BRIO 4K webcam. It has mostly worked since I got it with the generic UVC driver and I been using it for my Google Meetings and similar, but since there was no native Linux control application I could not easily access a lot of the cameras features. To address this I downloaded the windows application installer and installed it under Windows and then took a bunch of screenshots showcasing all features of the application. I then fed the screenshots into Claude and told it I wanted a GTK+ version for Linux of this application. I originally wanted to have Claude write it in Rust, but after hitting some issues in the PipeWire Rust bindings I decided to just use C instead.

I took me probably 3-4 days with intermittent work to get this application working and Claude turned out to be really good and digging into Windows binaries and finding things like USB property values. Claude was also able to analyze the screenshots and figure out the features the application needed to have. It was a lot of trial and error writing the application, but one way I was able to automate it was by building a screenshot option into the application, allowing it to programmatically take screenshots of itself. That allowed me to tell Claude to try fixing something and then check the screenshot to see if it worked without me having to interact with the prompt. Also to get the user interface looking nicer, once I had all the functionality in I asked Claude to tweak the user interface to follow the guidelines of the GNOME Human Interface Guidelines, which greatly improved the quality of the UI.

At this point my application should have almost all the features of the Windows application. Since it is using PipeWire underneath it is also tightly integrated with the PipeWire media graph, allowing you to see it connect and work with your application in PipeWire patchbay applications like Helvum. The remaining features are software features of Dell's application, like background removal and so on, but I think that if I decided to to implement that it should be as a standalone PipeWire tool that can be used with any camera, and not tied to this specific one.

Red Hat Planet

The application shows the worlds Red Hat offices and include links to latest Red Hat news.

The next application on my list is called Red Hat Planet. It is mostly a fun toy, but I made it to partly revisit the Xtraceroute modernisation I blogged about earlier. So as I mentioned in that blog, Xtraceroute while cute isn't really very useful IMHO, since the way the modern internet works rarely have your packets jump around the world. Anyway, as people pointed out after I posted about the port is that it wasn't an actual Vulkan application, it was a GTK+ application using the GTK+ Vulkan backend. The Globe animation itself was all software rendered.

I decided if I was going to revisit the Vulkan problem I wanted to use a different application idea than traceroute. The idea I had was once again a 3D rendered globe, but this one reading the coordinates of Red Hats global offices from a file and rendering them on the globe. And alongside that provide clickable links to recent Red Hat news items. So once again maybe not the worlds most useful application, but I thought it was a cute idea and hopefully it would allow me to create it using actual Vulkan rendering this time.

Creating this turned out to be quite the challenge (although it seems to have gotten easier since I started this effort), with Claude Opus 4.6 being more capable at writing Vulkan code than Claude Sonnet, Google Gemini or OpenAI Codex was when I started trying to create this application.
When I started this project I had to keep extremely close tabs on the AI and what is was doing in order to force it to keep working on this as a Vulkan application, as it kept wanting to simplify with Software rendering or OpenGL and sometimes would start down that route without even asking me. That hasn't happened more recently, so maybe that was a problem of AI of 5 Months ago.

I also discovered as part of this that rendering Vulkan inside a GTK4 application is far from trivial and would ideally need the GTK4 developers to create such a widget to get rendering timings and similar correct. It is one of the few times I have had Claude outright say that writing a widget like that was beyond its capabilities (haven't tried again so I don't know if I would get the same response today). So I started moving the application to SDL3 first, which worked as I got a spinning globe with red dots on, but came with its own issues, in the sense that SDL is not a UI toolkit as such. So while I got the globe rendered and working the AU struggled badly with the news area when using SDL.

So I ended up trying to port the application to Qt, which again turned out to be non-trivial in terms of how much time it took with trial and error to get it right. I think in my mind I had a working globe using Vulkan, how hard could it be to move it from SDL3 to Qt, but there was a million rendering issues. In fact I ended up using the Qt Vulkan rendering example as a starting point in the end and then 'porting' the globe over bit by bit, testing it for each step, to finally get a working version. The current version is a Vulkan+Qt app and it basically works, although it seems the planet is not spinning correctly on AMD systems at the moment, while it seems to work well on Intel and NVIDIA systems.

WMDock

WmDock fullscreen with config application.

This project came out of a chat with Matthias Clasen over lunch where I mused about if Claude would be able to bring the old Window Maker dockapps to GNOME and Wayland. Turns out the answer is yes although the method of doing so changed as I worked on it.

My initial thought was for Claude to create a shim that the old dockapps could be compiled against, without any changes. That worked, but then I had a ton of dockapps showing up in things like the alt+tab menu. It also required me to restart my GNOME Shell session all the time as I was testing the extension to house the dockapps. In the end I decided that since a lot of the old dockapps don't work with modern Linux versions anyway, and thus they would need to be actively ported, I should accept that I ship the dockapps with the tool and port them to work with modern linux technologies. This worked well and is what I currently have in the repo, I think the wildest port was porting the old dockapp webcam app from V4L1 to PipeWire. Although updating the soundcontroller from ESD to PulesAudio was also a generational jump.

XMMS resuscitated

XMMS brought back to life

So the last effort I did was reviving the old XMMS media player. I had tried asking Claude to do this for Months and it kept failing, but with Opus 4.6 it plowed through it and had something working in a couple of hours, with no input from me beyond kicking it off. This was a big lift,moving it from GTK2 and Esound, to GTK4, GStreamer and PipeWire. One thing I realized is that a challenge with bringing an old app back is that since keeping the themeable UI is a big part of this specific application adding new features is a little kludgy. Anyway I did set it up to be able to use network speakers through PipeWire and also you can import your Spotify playlists and play those, although you need to run the Spotify application in the background to be able to play sound on your local device.

Monkey Bubble

Monkey Bubble was a game created in the heyday of GNOME 2 and while I always thought it was a well made little game it had never been updated to never technologies. So I asked Claude to port it to GTK4 and use GStreamer for audio.This port was fairly straightforward with Claude having little problems with it. I also asked Claude to add highscores using the libmanette library and network game discovery with Avahi. So some nice little.improvements.

All the applications are available either as Flatpaks or Fedora RPMS, through the gitlab project page, so I hope people enjoy these applications and tools. And enoy the blasts from the past as much as I did.

Worries about Artifical Intelligence

When I speak to people both inside Red Hat and outside in the community I often come across negativity or even sometimes anger towards Artificial Intelligence in the coding space. And to be clear I to worry about where things could be heading and how it will affect my livelihood too, so I am not unsympathetic to those worries at all. I probably worry about these things at least a few times a day. At the same time I don't think we can hide from or avoid this change, it is happening with or without us. We have to adapt to a world where this tool exists, just like our ancestors have adapted to jobs changing due to industrialization and science before. So do I worry about the future, yes I do. Do I worry about how I might personally get affected by this? yes, I do. Do I worry about how society might change for the worse due to this? yes, I do. But I also remind myself that I don't know the future and that people have found ways to move forward before and society has survived and thrived. So what I can control is that I try to be on top of these changes myself and take advantage of them where I can and that is my recommendation to the wider open source community on this too. By leveraging them to move open source forward and at the same time trying to put our weight on the scale towards the best practices and policies around Artificial Intelligence.

The Next Test and where AI might have hit a limit for me.

So all these previous efforts did teach me a lot of tricks and helped me understand how I can work with an AI agent like Claude, but especially after the success with the webcam I decided to up the stakes and see if I could use Claude to help me create a driver for my Plustek OpticFilm 8200i scanner. So I have zero backround in any kind of driver development and probably less than zero in the field of scanner driver specifically. So I ended up going down a long row of deadends on this journey and I to this day has not been able to get a single scan out of the scanner with anything that even remotely resembles the images I am trying to scan.

My idea was to have Claude analyse the Windows and Mac driver and build me a SANE driver based on that, which turned out to be horribly naive and lead nowhere. One thing I realized is that I would need to capture USB traffic to help Claude contextualize some of the findings it had from looking at the Windows and Mac drivers.I started out with Wireshark and feeding Claude with the Wireshark capture logs. Claude quite soon concluded that the Wireshark logs wasn't good enough and that I needed lower level traffic capture. Buying a USB packet analyzer isn't cheap so I had the idea that I could use one of the ARM development boards floating around the house as a USB relay, allowing me to perfectly capture the USB traffic. With some work I did manage to set up my LibreComputer Solitude AML-S905D3-CC arm board going and setting it in device mode. I also had a usb-relay daemon going on the board. After a lot of back and forth, and even at one point trying to ask Claude to implement a missing feature in the USB kernel stack, I realized this would never work and I ended up ordering a Beagle USB 480 USB hardware analyzer.

At about the same time I came across the chipset documentation for the Genesys Logic GL845 chip in the scanner. I assumed that between my new USB analyzer and the chipset docs this would be easy going from here on, but so far no. I even had Claude decompile the windows driver using ghidra and then try to extract the needed information needed from the decompiled code.
I bought a network controlled electric outlet so that Claude can cycle the power of the scanner on its own.

So the problem here is that with zero scanner driver knowledge I don't even know what I should be looking for, or where I should point Claude to, so I keept trying to brute force it by trial and error. I managed to make SANE detect the scanner and I managed to get motor and lamp control going, but that is about it. I can hear the scanner motor running and I ask for a scan, but I don't know if it moves correctly. I can see light turning on and off inside the scanner, but I once again don't know if it is happening at the correct times and correct durations. And Claude has of course no way of knowing either, relying on me to tell it if something seems like it has improved compared to how it was.

I have now used Claude to create two tools for Claude to use, once using a camera to detect what is happening with the light inside the scanner and the other recording sound trying to compare the sound this driver makes compared to the sounds coming out when doing a working scan with the MacOS X application. I don't know if this will take me to the promised land eventually, but so far I consider my scanner driver attempt a giant failure. At the same time I do believe that if someone actually skilled in scanner driver development was doing this they could have guided Claude to do the right things and probably would have had a working driver by now.

So I don't know if I hit the kind of thing that will always be hard for an AI to do, as it has to interact with things existing in the real world, or if newer versions of Claude, Gemini or Codex will suddenly get past a threshold and make this seem easy, but this is where things are at for me at the moment.

23 Mar 2026 4:07pm GMT

At this point in history, AI sociopaths have purchased all the world's RAM in order to run their copyright infringement factories at full blast. Thus the amount of memory in consumer computers and phones seems to be going down. After decades of not having to care about memory usage, reducing it has very much become a thing.

Relevant questions to this state of things include a) is it really worth it and b) what sort of improvements are even possible. The answers to these depend on the task and data set at hand. Let's examine one such case. It might be a bit contrived, unrepresentative and unfair, but on the other hand it's the one I already had available.

Suppose you have to write script that opens a text file, parses it as UTF-8, splits it into words according to white space, counts the number of time each word appears and prints the words and counts in decreasing order (most common first).

The Python baseline

This sounds like a job for Python. Indeed, an implementation takes fewer than 30 lines of code. Its memory consumption on a small text file [update: repo's readme, which is 1.3k] looks like this.

Peak memory consumption is 1.3 MB. At this point you might want to stop reading and make a guess on how much memory a native code version of the same functionality would use.

The native version

A fully native C++ version using Pystd requires 60 lines of code to implement the same thing. If you ignore the boilerplate, the core functionality fits in 20 lines. The steps needed are straightforward:

1. Mmap the input file to memory.
2. Validate that it is utf-8
3. Convert raw data into a utf-8 view
4. Split the view into words lazily
5. Compute the result into a hash table whose keys are string views, not strings

The main advantage of this is that there are no string objects. The only dynamic memory allocations are for the hash table and the final vector used for sorting and printing. All text operations use string views , which are basically just a pointer + size.

In code this looks like the following:

Its memory usage looks like this.

Peak consumption is ~100 kB in this implementation. It uses only 7.7% of the amount of memory required by the Python version.

Isn't this a bit unfair towards Python?

In a way it is. The Python runtime has a hefty startup cost but in return you get a lot of functionality for free. But if you don't need said functionality, things start looking very different.

But we can make this comparison even more unfair towards Python. If you look at the memory consumption graph you'll quite easily see that 70 kB is used by the C++ runtime. It reserves a bunch of memory up front so that it can do stack unwinding and exception handling even when the process is out of memory. It should be possible to build this code without exception support in which case the total memory usage would be a mere 21 kB. Such version would yield a 98.4% reduction in memory usage.

23 Mar 2026 2:06pm GMT

23 Mar 2026 1:51pm GMT

When you're looking at source code it can be helpful to have some evidence indicating who wrote it. Author tags give a surface level indication, but it turns out you can just lie and if someone isn't paying attention when merging stuff there's certainly a risk that a commit could be merged with an author field that doesn't represent reality. Account compromise can make this even worse - a PR being opened by a compromised user is going to be hard to distinguish from the authentic user. In a world where supply chain security is an increasing concern, it's easy to understand why people would want more evidence that code was actually written by the person it's attributed to.

git has support for cryptographically signing commits and tags. Because git is about choice even if Linux isn't, you can do this signing with OpenPGP keys, X.509 certificates, or SSH keys. You're probably going to be unsurprised about my feelings around OpenPGP and the web of trust, and X.509 certificates are an absolute nightmare. That leaves SSH keys, but bare cryptographic keys aren't terribly helpful in isolation - you need some way to make a determination about which keys you trust. If you're using someting like GitHub you can extract that information from the set of keys associated with a user account¹, but that means that a compromised GitHub account is now also a way to alter the set of trusted keys and also when was the last time you audited your keys and how certain are you that every trusted key there is still 100% under your control? Surely there's a better way.

SSH Certificates

And, thankfully, there is. OpenSSH supports certificates, an SSH public key that's been signed by some trusted party and so now you can assert that it's trustworthy in some form. SSH Certificates also contain metadata in the form of Principals, a list of identities that the trusted party included in the certificate. These might simply be usernames, but they might also provide information about group membership. There's also, unsurprisingly, native support in SSH for forwarding them (using the agent forwarding protocol), so you can keep your keys on your local system, ssh into your actual dev system, and have access to them without any additional complexity.

And, wonderfully, you can use them in git! Let's find out how.

Local config

There's two main parameters you need to set. First,

1

git config set gpg.format ssh

because unfortunately for historical reasons all the git signing config is under the gpg namespace even if you're not using OpenPGP. Yes, this makes me sad. But you're also going to need something else. Either user.signingkey needs to be set to the path of your certificate, or you need to set gpg.ssh.defaultKeyCommand to a command that will talk to an SSH agent and find the certificate for you (this can be helpful if it's stored on a smartcard or something rather than on disk). Thankfully for you, I've written one. It will talk to an SSH agent (either whatever's pointed at by the SSH_AUTH_SOCK environment variable or with the -agent argument), find a certificate signed with the key provided with the -ca argument, and then pass that back to git. Now you can simply pass -S to git commit and various other commands, and you'll have a signature.

Validating signatures

This is a bit more annoying. Using native git tooling ends up calling out to ssh-keygen², which validates signatures against a file in a format that looks somewhat like authorized-keys. This lets you add something like:

1

* cert-authority ssh-rsa AAAA…

which will match all principals (the wildcard) and succeed if the signature is made with a certificate that's signed by the key following cert-authority. I recommend you don't read the code that does this in git because I made that mistake myself, but it does work. Unfortunately it doesn't provide a lot of granularity around things like "Does the certificate need to be valid at this specific time" and "Should the user only be able to modify specific files" and that kind of thing, but also if you're using GitHub or GitLab you wouldn't need to do this at all because they'll just do this magically and put a "verified" tag against anything with a valid signature, right?

Haha. No.

Unfortunately while both GitHub and GitLab support using SSH certificates for authentication (so a user can't push to a repo unless they have a certificate signed by the configured CA), there's currently no way to say "Trust all commits with an SSH certificate signed by this CA". I am unclear on why. So, I wrote my own. It takes a range of commits, and verifies that each one is signed with either a certificate signed by the key in CA_PUB_KEY or (optionally) an OpenPGP key provided in ALLOWED_PGP_KEYS. Why OpenPGP? Because even if you sign all of your own commits with an SSH certificate, anyone using the API or web interface will end up with their commits signed by an OpenPGP key, and if you want to have those commits validate you'll need to handle that.

In any case, this should be easy enough to integrate into whatever CI pipeline you have. This is currently very much a proof of concept and I wouldn't recommend deploying it anywhere, but I am interested in merging support for additional policy around things like expiry dates or group membership.

Doing it in hardware

Of course, certificates don't buy you any additional security if an attacker is able to steal your private key material - they can steal the certificate at the same time. This can be avoided on almost all modern hardware by storing the private key in a separate cryptographic coprocessor - a Trusted Platform Module on PCs, or the Secure Enclave on Macs. If you're on a Mac then Secretive has been around for some time, but things are a little harder on Windows and Linux - there's various things you can do with PKCS#11 but you'll hate yourself even more than you'll hate me for suggesting it in the first place, and there's ssh-tpm-agent except it's Linux only and quite tied to Linux.

So, obviously, I wrote my own. This makes use of the go-attestation library my team at Google wrote, and is able to generate TPM-backed keys and export them over the SSH agent protocol. It's also able to proxy requests back to an existing agent, so you can just have it take care of your TPM-backed keys and continue using your existing agent for everything else. In theory it should also work on Windows³ but this is all in preparation for a talk I only found out I was giving about two weeks beforehand, so I haven't actually had time to test anything other than that it builds.

And, delightfully, because the agent protocol doesn't care about where the keys are actually stored, this still works just fine with forwarding - you can ssh into a remote system and sign something using a private key that's stored in your local TPM or Secure Enclave. Remote use can be as transparent as local use.

Wait, attestation?

Ah yes you may be wondering why I'm using go-attestation and why the term "attestation" is in my agent's name. It's because when I'm generating the key I'm also generating all the artifacts required to prove that the key was generated on a particular TPM. I haven't actually implemented the other end of that yet, but if implemented this would allow you to verify that a key was generated in hardware before you issue it with an SSH certificate - and in an age of agentic bots accidentally exfiltrating whatever they find on disk, that gives you a lot more confidence that a commit was signed on hardware you own.

Conclusion

Using SSH certificates for git commit signing is great - the tooling is a bit rough but otherwise they're basically better than every other alternative, and also if you already have infrastructure for issuing SSH certificates then you can just reuse it⁴ and everyone wins.

21 Mar 2026 7:38pm GMT

Hello there,

If you're an avid reader of blogs, you'll know this medium is basically dead now. Everyone switched to making YouTube videos, complete with cuts and costume changes every few seconds because, I guess, our brains work much faster now.

The YouTube recommendation algorithm, problematic as it is, does turn up some interesting stuff, such this video entitled "Why Work is Starting to Look Medieval":

It is 15 minutes long, but it does include lots of short snippets and some snipping scissors, so maybe you'll find it a fun 15 minutes. The key point, I guess, is that before we were wage slaves we used to be craftspeople, more deeply connected to our work and with a sense of purpose. The industrial revolution marked a shift from cottage industry, where craftspeople worked with their own tools in their own house or workshop, to modern capitalism where the owners of the tools are the 1%, and the rest of us are reduced to selling our labour at whatever is the going rate.

Then she posits that, since the invention of the personal computer, influencers and independent content creators have begun to transcend the structures of 20th century capitalism, and are returning to a more traditional relationship with work. Hence, perhaps, why nearly everyone under 18 wants to be a YouTuber. Maybe that's a stretch.

This message resonated with me after 20 years in the open source software world, and hopefully you can see the link. Software development is a craft. And the Free Software movement has always been in tacit opposition to capitalism, with its implied message that anyone working on a computer should have some ownership of the software tools we use: let me use it, let me improve it, and let me share it.

I've read many many takes on AI-generated code this year, and its really only March. I'm guilty one of these myself: AI Predictions for 2026, in which I made a link between endless immersion in LLM-driven coding and more traditional drug addictions that has now been corroborated by Steve Yegge himself. See his update "The AI Vampire" (which is also something of a critique of capitalism).

I've read several takes that the Free Software movement has won now because it is much easier to understand, share and modify programs than ever before. See, for example, this one from Bruce Perens on Linquedin: "The advent of AI and its capability to create software quickly, with human guidance, means that we can probably have almost anything we want as Free Software.".

I've also seen takes that, in fact, the capitalism has won. Such as the (fictional) MALUSCorp: "Our proprietary AI robots independently recreate any open source project from scratch. The result? Legally distinct code with corporate-friendly licensing. No attribution. No copyleft. No problems.".

One take I haven't seen is what this means for people who love the craft of building software. Software is a craft, and our tools are the operating system and the compiler. Programmers working on open source, where code serves as reference material and can live in the open for decades, will show much more pride in their code than programmers in academia and industry, whose prototypes or products just need to get the job done. The programmer is a craftsperson, just like the seamstress, the luthier and the blacksmith. But unlike clothes, guitars and horseshoes, the stuff we build is intangible. Perhaps as a result, society sees us less like craftspeople and more like weird, unpopular wizards.

I've spent a lot of my career building and testing open source operating systems, as you can see from these 30 different blog posts, which include the blockbuster "Some CMake Tips", the satisfying "Tracker Meson", and or largely obsolete "How BuildStream uses OSTree".

It's really not that I have some deep-seated desire to rewrite all of the world's Makefiles. My interest in operating systems and build tools has always came from a desire to democratize these here computers. To free us from being locked into fixed ways of working designed by Apple, Google, Microsoft. Open source tools are great, yes, but I'm more interested in whether someone can access the full power of their computer without needing a university education. This is why I've found GNOME interesting over the years: it's accessible to non-wizards, and the code is right there in the open, for anyone to change. That said, I've always wished we GNOME focus more on customizability, and I don't mean adding more preferences. Look, here's me in 2009 discovering Nix for the first time and jumping straight to this: "So Nix could give us beautiful support for testing and hacking on bits of GNOME".

So what happened? Plenty has changed, but I feel that hacking on bits of GNOME hasn't become meaningfully easier in the intervening 17 years. And perhaps we can put that largely down to the tech industry's relentless drive to sell us new computers, and our own hunger to do everything faster and better. In the 1980s, an operating system could reasonably get away with running only one program at a time. In the 1990s, you had multitasking but there was still just the one CPU, at least in my PC. I don't think there was any point in the 2000s when I owned a GPU. In the 2010s, my monitor was small enough that I never worried about fractional scaling. And so on. For every one person working to simplify, there are a hundred more paid to innovate. Nobody gets promoted for simplicity.

I can see a steadily growing interest in tech from people who aren't necessarily interested in programming. If you're not tired of videos yet, here's a harp player discussing the firmware of a digital guitar pedal (cleverly titled "What pedal makers don't want you to see"). Here's another musician discussing STM32 chips and mesh networks under the title "Gadgets For People Who Don't Trust The Government". This one does not have costume changes every few seconds.

So we're at an inflection point.

The billions pumped into the AI bubble come from a desire by rich men to take back control of computing. It's a feature, not a bug, that you can't run ChatGPT on a consumer GPU, and that AI companies need absolutely all of the DRAM. They could spend that money on a programme like Outreachy, supporting people to learn and understand today's software tools … but you don't consolidate power through education. (The book Careless People, which I recommend last year, will show you how much tech CEOs crave raw power).

In another sense, AI models are a new kind of operating system, exposing the capabilities of a GPU in a radical new interface. The computer now contains a facility that can translate instructions in your native language into any well-known programming language. (Just don't ask it to generate Whitespace). By now you must know someone non-technical who has nevertheless automated parts of their job away by prompting ChatGPT to generate Excel macros. This is the future we were aiming for, guys!

I'm no longer sure if the craft I care about is writing software, or getting computers to do things, or both. And I'm really not sure what this craft is going to look like in 10 or 20 years. What topics will be universally understood, what work will be open to individual craftspeople, and what tools will be available only to states and mega-corporations? Will basic computer tools be universally available and understood, like knives and saucepans in a kitchen? Will they require small scale investment and training, like a microbrewery? Or will the whole world come to depend on a few enourmous facilities in China?

And most importantly, will I be able to share my passion for software without feeling like a weird, unpopular wizard any time soon?

21 Mar 2026 6:29pm GMT

Hello and welcome to another update on what's been happening at the GNOME Foundation. It's been two weeks since my last update, and there's been plenty going on, so let's dive straight in.

GNOME 50!

My update wouldn't be complete without mentioning this week's GNOME 50 release. It looks like an amazing release with lots of great improvements! Many thanks to everyone who contributed and made it such a success.

The Foundation plays a critical role in these releases, whether it's providing development infrastructure, organising events where planning takes place, or providing development funding. If you are reading this and have the means, please consider signing up as a Friend of GNOME. Even small regular donations make a huge difference.

Board Meeting

The Board of Directors had its regular monthly meeting on March 9th, and we had a full agenda. Highlights from the meeting included:

• The Board agreed to sign the Keep Android Open letter, as well as endorsing the United Nations Open Source Principles.
• We heard reports from a number of committees, including the Executive Committee, Finance Committee, Travel Committee, and Code of Conduct Committee. Committee presentations are a new addition to the Board meeting format, with the goal of pushing more activity out to committees, with the Board providing high-level oversight and coordination.
• Creation of a new bank account was authorized, which is needed as part of our ongoing finance and accounting development effort.
• The main discussion topic was Flathub and what the organizational arrangements could be for it in the future. There weren't any concrete decisions made here, but the Board indicated that it's open to different options and sees Flathub's success as the main priority rather than being attached to any particular organisation type or location.
• The next regular Board meeting will be on April 13th.

Travel

The Travel Committee met both this week and last week, as it processed the initial batch of GUADEC sponsorship applications. As a result of this work the first set of approvals have been sent out. Documentation has also been provided for those who are applying for visas for their travel.

The membership of the current committee is quite new and it is having to figure out processes and decision-making principals as it goes, which is making its work more intensive than might normally be the case. We are starting to write up guidelines for future funding rounds, to help smooth the process.

Huge thanks to our committee members Asmit, Anisa, Julian, Maria, and Nirbheek, for taking on this important work.

Conferences

Planning and preparation for the 2026 editions of LAS and GUADEC have continued over the past fortnight. The call for papers for both events is a particular focus right now, and there are a couple of important deadlines to be aware of:

• If you want to speak at LAS 2026, the deadline for proposals is 23 March - that's in just three days.
• The GUADEC 2026 call for abstracts has been extended to 27 March, so there is one more week to submit a talk.

There are teams behind each of these calls, reviewing and selecting proposals. Many thanks to the volunteers doing this work!

We are also excited to have sponsors come forward to support GUADEC.

Accounting

The Foundation has been undertaking a program of improvements to our accounting and finance systems in recent months. Those were put on hold for the audit fieldwork that took place at the beginning of March, but now that's done, attention has turned to the remaining work items there.

We've been migrating to a new payments processing platform since the beginning of the year, and setup work has continued, including configuration to make it integrate correctly with our accounting software, migrating credit cards over from our previous solution, and creating new web forms which are going to be used for reimbursement requests in future.

There are a number of significant advantages to the new system, like the accounting integration, which are already helping to reduce workloads, and I'm looking forward to having the final pieces of the new system in place.

Another major change that is currently ongoing is that we are moving from a quarterly to a monthly cadence for our accounting. This is the cycle we move on to "complete" the accounts, with all data inputted and reconciled by the end of the cycle. The move to a monthly cycle will mean that we are generating finance reports on a more frequent basis, which will allow the Board to have a closer view on the organisation's finances.

Finally, this week we also had our regular monthly "books" call with our accountant and finance advisor. This was our usual opportunity to resolve any questions that have come up in relation to the accounts, but we also discussed progress on the improvements that we've been making.

Infrastructure

On the infrastructure side, the main highlight in recent weeks has been the migration from Anubis to Fastly's Next-Gen Web Application Firewall (WAF) for protecting our infrastructure. The result of this migration will be an increased level of protection from bots, while simultaneously not interfering in peoples' way when they're using our infra. The Fastly product provides sophisticated detection of threats plus the ability for us to write our own fine-grained detection rules, so we can adjust firewall behaviour as we go.

Huge thanks to Fastly for providing us with sponsorship for this service - it is a major improvement for our community and would not have been possible without their help.

That's it for this update. Thanks for reading and be on the lookout for the next update, probably in two weeks!

20 Mar 2026 3:42pm GMT

Update on what happened across the GNOME project in the week from March 13 to March 20.

This week we released GNOME 50!

This new major release of GNOME is full of exciting changes, including improved parental controls, many accessibility enhancements, expanded document annotation capabilities, calendar updates, and much more! See the GNOME 50 release notes and developer notes for more information.

Readers who have been following this site will already be aware of some of the new features. If you'd like to follow the development of GNOME 51 (Fall 2026), keep an eye on this page - we'll be posting exciting news every week!

GNOME Circle Apps and Libraries

gtk-rs ↗

Safe bindings to the Rust language for fundamental libraries from the GNOME stack.

Julian 🍃 reports

I've added a chapter about accessibility to the gtk4-rs book. While I researched the topic beforehand and tested all examples with a screenreader, I would still appreciated additional feedback from people experienced with accessibility.

Eyedropper ↗

Pick and format colors.

FineFindus reports

Eyedropper 2.2.0 is out now, bringing support for color picking without having the application open. It also now supports RGB in decimal notation and improves support for systems without a proper portal setup.

As always, you can download the latest release from Flathub.

Third Party Projects

JumpLink announces

The TypeScript type definitions generator ts-for-gir v4.0.0-beta.41 is out, and the big news is that we now have browsable API documentation for GJS TypeScript bindings, live at https://gjsify.github.io/docs/. As a bonus, the same work also greatly improved the inline TypeScript documentation, hover docs in your editor are now much richer and more complete.

Anton Isaiev reports

RustConn is a GTK4/libadwaita connection manager for SSH, RDP, VNC, SPICE, Telnet, Serial, Kubernetes, and Zero Trust protocols. Core protocols use embedded Rust implementations - no external dependencies required.

The 0.10.x series brings 8 new features and a major platform upgrade:

New features:

• MOSH protocol support with predict mode, UDP port range, and server binary path
• Session recording in scriptreplay-compatible format with per-connection toggle and sensitive output sanitization
• Text highlighting rules - regex-based pattern matching with customizable colors, per-connection and global
• Ad-hoc broadcast - send keystrokes to multiple terminals simultaneously
• Smart Folders - dynamic connection grouping by protocol, tags, or host glob pattern
• Script credentials - resolve passwords from external commands with a Test button
• Per-connection terminal theming - background, foreground, and cursor color overrides
• CSV import/export with auto column mapping and configurable delimiter

Platform changes:

• GTK-rs bindings upgraded to gtk4 0.11, libadwaita 0.9, vte4 0.10
• Flatpak runtime bumped to GNOME 50 with VTE 0.80
• Migrated to AdwSpinner, AdwShortcutsDialog, AdwSwitchRow, and AdwWrapBox (cfg-gated)
• FreeRDP 3.24.0 bundled in Flatpak - external RDP works out of the box on Wayland
• rdp file association - double-click to open and connect
• Split view now works with all VTE-based protocols

0.10.2 is a follow-up with 11 bug fixes for session recording, MOSH dispatch, highlight rules wiring, picocom detection in Flatpak, sidebar overflow, and RDP error messages.

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

Quadrapassel ↗

Fit falling blocks together.

Will Warner reports

Quadrapassel 50.0 has been released! This release has a lot of improvements for controls and polishes the app. Here is what's new:

• Made game view and preview exactly fit the blocks
• Improved game controller support
• Stopped duplicate keyboard events
• Replaced the libcanberra sound engine
• Fixed many small bugs and stylistic issues

You can get Quadrapassel on Flathub.

Documentation

Jan-Willem says

This week Java was added to the programming languages section on developer.gnome.org and many of the code examples were translated to Java.

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!

20 Mar 2026 12:00am GMT

One of the most optimized algorithms in any standard library is sorting. It is used everywhere so it must be fast. Thousands upon thousands of developer hours have been sunk into inventing new algorithms and making sort implementations faster. Pystd has a different design philosophy where fast compilation times and readability of the implementation have higher priority than absolute performance. Perf still very much matters, it has to be fast, but not at the cost of 10x compilation time.

This leads to the natural question of how much slower such an implementation would be compared to a production quality one. Could it even be faster? (Spoilers: no) The only way to find out is to run performance benchmarks on actual code.

To keep things simple there is only one test set, sorting 10'000'000 consecutive 64 bit integers that have been shuffled to a random order which is the same for all algorithms. This is not an exhaustive test by any means but you have to start somewhere. All tests used GCC 15.2 using -O2 optimization. Pystd code was not thoroughly hand optimized, I only fixed (some of the) obvious hotspots.

Stable sort

Pystd uses mergesort for stable sorting. The way the C++ standard specifies stable sort means that most implementations probably use it as well. I did not dive in the code to find out. Pystd's merge sort implementation consists of ~220 lines of code. It can be read on this page.

Stdlibc++ can do the sort in 0.9 seconds whereas Pystd takes .94 seconds. Getting to within 5% with such a simple implementation is actually quite astonishing. Even when considering all the usual caveats where it might completely fall over with a different input data distribution and all that.

Regular sort

Both stdlibc++ and Pystd use introsort. Pystd's implementation has ~150 lines of code but it also uses heapsort, which has a further 100 lines of code). Code for introsort is here, and heapsort is here.

Stdlibc++ gets the sort done in 0.76 seconds whereas Pystd takes 0.82 seconds. This makes it approximately 8% slower. It's not great, but getting within 10% with a few evening's work is still a pretty good result. Especially since, and I'm speculating here, std::sort has seen a lot more optimization work than std::stable_sort because it is used more.

For heavy duty number crunching this would be way too slow. But for moderate data set sizes the performance difference might be insignificant for many use cases.

Note that all of these are faster (note: did not measure) than libc's qsort because it requires an indirect function call on every comparison i.e. the comparison method can not be inlined.

Compiling the stdlib version takes 0.68 seconds while the Pystd version takes 0.33 seconds. Without optimizations the times are 0.55 and 0.21 seconds, respectively.

Where does the time go?

Valgrind will tell you that quite easily.

This picture shows quite clearly why big O notation can be misleading. Both quicksort (the inner loop of introsort) and heapsort have "the same" average time complexity but every call to heapsort takes approximately 4.5 times as long.

19 Mar 2026 1:49pm GMT

Two years have passed since I last shared my Friday app icon sketches, but the sketching itself hasn't stopped.

For me, it's the best way to figure out the right metaphors before we move to final pixels. These sketches are just one part of the GNOME Design Team's wider effort to keep our icons consistent and meaningful-it is an endeavor that's been going on for years.

If you design a GNOME app following the GNOME Design Guidelines, feel free to request an icon to be made for you. If you are serious and apply for inclusion in GNOME Circle, you are way more likely to get a designer's attention.

Previously

19 Mar 2026 12:00am GMT