Planet GNOME

The GNOME Foundation is delighted to announce the appointment of Steven Deobald as our new Executive Director. Steven brings decades of experience in free software, open design, and open documentation efforts to the Foundation, and we are excited to have him lead our organization into its next chapter.

“I’m incredibly excited to serve the GNOME Foundation as its new full-time Executive Director,” said Steven Deobald. “The global network of contributors that makes up the GNOME community is awe-inspiring. I’m thrilled to serve the community in this role. GNOME’s clear mission as a universal computing environment for everyone, everywhere has remained consistent for a quarter century—that kind of continuity is exceptional.”

Steven has been a GNOME user since 2002 and has been involved in numerous free software initiatives throughout his career. His professional background spans technical leadership, business development, and nonprofit work, and he was one of the founding members of Nilenso, India’s first worker-owned tech cooperative. Having worked with projects like XTDB and Endatabas and founding India’s first employee-own, he brings valuable experience in open source product development. Based in Halifax, Canada, Steven is well-positioned to collaborate with our global community across time zones.

“Steven’s wealth of experience in open source communities and his clear understanding of GNOME’s mission make him the ideal leader for the Foundation at this time,” said Robert McQueen, GNOME Foundation Board President. “His vision for transparency and financial resilience aligns perfectly with our goals as we support and grow the diversity and sustainability of GNOME’s free software personal computing ecosystem.”

Steven plans to focus on increasing transparency about the people and processes behind GNOME, reestablishing the Foundation’s financial stability, and building resilience across finances, people, documentation, and processes to ensure GNOME thrives for decades to come. You can read more from Steven in his introductory post on his GNOME blog.

Heartfelt Thanks to Richard Littauer

The GNOME Foundation extends its deepest gratitude to Richard Littauer, who has served as Interim Executive Director for the past ten months. Despite initially signing on for just two months while simultaneously moving to New Zealand and beginning a PhD program, Richard extended his commitment to ensure stability during our search for a permanent director.

During his tenure, Richard worked closely with the board and staff to pass a balanced budget, secure additional funding, support successful events including GUADEC, and navigate numerous challenges facing the Foundation. His dedication to ensuring GNOME’s continued success, often while working across challenging time zones, has been invaluable.

“I knew this day would come at some point,” Richard shared in his farewell post. “My time has been exceedingly difficult… I feel that I have done very little; all of the gains happened with the help of others.” Richard’s humility belies the significant impact he made during his time with us, creating a solid foundation for our new Executive Director.

Richard will return full-time to his PhD studies at Te Herenga Waka Victoria University of Wellington, but remains available to the GNOME community and can be reached via Mastodon, his website, or at richard@gnome.org.

Looking Ahead

As we welcome Steven and thank Richard, we also recognize the dedicated contributors, volunteers, staff, and board members who keep GNOME thriving. The Foundation remains committed to supporting the development of a free and accessible desktop environment for all users around the world.

The GNOME community can look forward to meeting Steven at upcoming events and through community channels. We encourage everyone to join us in welcoming him to the GNOME family and supporting his vision for the Foundation’s future.

During this quarter, all employees are asked to become familiar with using AI technologies. In the last months I explored using AI for code editing and pull request reviews, but I wrote about that separately. But today is another Red Hat day of learning, so I looked at something more hands-on: Install and run InstructLab on my own laptop again, and experiment with it. TL/DR: This just reinforced my experience from the last two years about AI being too bad and too expensive for what I would expect it to do.

Goal In the Cockpit team we spend a lot of our time on PR reviews. That’s time well spent – we all learn from each other, it keeps the code quality high and ourselves honest. But most certainly there is room for optimization: There are always silly or boring things like typos, inconsistent formatting, or inefficient algorithms; and humans also have selective and subjective sight, i.e. are often missing things.

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

GNOME Foundation

steven announces

We have our first Foundation Report since I joined as ED! I hope these are less verbose and less rambling in the future… and also less focused on the minutiae of what I spent my week on. With each passing week, they will (hopefully) come to encompass more of what’s going on at the Foundation, at a higher level. For now, I’m meeting many, many lovely folks and finding out just how hard everyone is working.

Read the long ramble on my blog.

Internships

Felipe Borges announces

We are happy to announce that five contributors are joining the GNOME community as part of Google Summer of Code 2025!

This year’s contributors will work on backend isolation in GNOME Papers, adding eBPF profiling to Sysprof, adding printing support in GNOME Crosswords, and Vala’s XML/JSON/YAML integration improvements. Let’s give them a warm welcome!

In the coming days, our new contributors will begin onboarding in our community channels and services. Stay tuned to Planet GNOME to read their introduction blog posts and learn more about their projects.

If you want to learn more about Google Summer of Code internships with GNOME, visit gsoc.gnome.org.

GNOME Core Apps and Libraries Video Player (Showtime) ↗

Watch without distraction

kramo says

Video Player (codenamed Showtime) is replacing Videos (Totem) as GNOME’s default video player.

It will be included in GNOME 49, but it can already be installed from Flathub.

Third Party Projects

Jan Lukas says

I’ve released the first version of Typewriter to flathub. It is a, as of now, basic Typst editor with built-in live preview, template browser and export dialog. If you’re interested in a local-first Typst experience come join and contribute code and ideas.

Gitlab flathub

ranfdev announces

I’m announcing that DistroShelf is finally available on flathub ! Sometimes, there are certain programs that aren’t available on your favorite distro… They are available for Ubuntu, but you don’t want to reinstall your OS just for that program.

* DistroShelf enters the chat *

It enables you to run containers that are highly integrated with your host system, using distrobox. In other words, it lets you install that program you want, inside a Ubuntu container. Then, you can use the program as if it were installed on your real distro! The program will see all your folders, all your devices… as you expect.

But you can run more than simple ubuntu containers! You can run pretty much any distro you want. I use it to run a development environment with the latest and greatest tools, inside an arch linux container.

Try it while it’s hot!

Parabolic ↗

Download web video and audio.

Nick says

Parabolic V2025.5.0 is here!

This release contains a complete redesign of the Qt/Windows app that features a much more modern experience. yt-dlp was also updated to the latest version to fix many website validation issues and some other features/fixes were added.

Please note, as many of you may have seen already, development of Parabolic and the set of Nickvision apps has slowed down. This is due to me starting a new full-time job and thus leaving only the weekends for me to work on these projects. This does not mean I am stopping development, it just means that releases, updates, and fixes will unfortunately take longer now. I appreciate all of your support and patience for these updates. Any C++ developers who would like to work on the projects with me as well are more than welcome too and are encouraged to reach out to me on Matrix!

Here’s the full changelog:

• Added the display of the file size of a format if it is available
• Fixed an issue where file paths were not truncated correctly
• Redesigned the Qt app for a more modern desktop experience
• Updated yt-dlp to fix some website validation issues

GNOME Websites

Felipe Borges announces

It’s alive! Welcome to the new planet.gnome.org!

A few months ago, I announced that I was working on a new implementation of Planet GNOME, powered by GitLab Pages. This work has reached a point where we’re ready to flip the switch and replace the old Planet website.

This was only possible thanks to various other contributors, such as Jakub Steiner, who did a fantastic job with the design and style, and Alexandre Franke, who helped with various papercuts, ideas, and improvements.

As with any software, there might be regressions and issues. It would be a great help if you report any problems you find.

If you are subscribed to the old Planet’s RSS feed, you don’t need to do anything. But if you are subscribed to the Atom feed at https://planet.gnome.org/atom.xml, you will have to switch to the RSS address at https://planet.gnome.org/rss20.xml

Miscellaneous

Sid says

GNOME GitLab now uses macOS runners sponsored by MacStadium for managing our macOS CI pipeline. The setup consists of 2 Mac mini (M1, 8-core CPU, 10-core GPU, 16GB RAM, 1TB SSD) along with Orka (Orchestration with Kubernetes on Apple) virtualization. This is a significant bump in hardware specs compared to the current solution, allowing us to run more builds simultaneously. Thanks to MacStadium for sponsoring this infrastructure upgrade!

For more details refer to https://blogs.gnome.org/sid/2025/04/27/macstadium-sponsors-gnome-macos-ci-infrastructure/.

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'm usually not a huge fan of personal growth books. As I pointed out in my Blinkist review, most books of this genre are 300 pages long when all the content would fit on 20. I read Deep Work by Cal Newport, with an open but skeptical mind.

A case for deep work

The book is split in two main sections. In the first section, the author makes a case for deep work. He argues that deep work is economically viable because it can help you learn new skills fast, a distinctive trait to successful people in tech, especially when competing with increasingly intelligent machines. This argument is surprisingly timely now, at the peak of the AI bubble.

He then explains that deep work is rare because in the absence of clear indicators of productivity, most people default to appearing very active shuffling things around. This argument clearly resonated with my experience for all my career.

Newport closes the first section by explaining why deep work is actually important for us humans because it limits our exposure to pettiness, makes us empirically happier than shallow work, and because it helps us find meaning to our work.

Rules for deep work

In the second section, the author lays out the four rules to enable deep work:

1. Decide the length of your deep work sessions, establish a ritual for them, keep track of your consistency and hold yourself accountable to it, and refrain from overworking since it decreases your global productivity.
2. Since the Internet can be very distracting, establish some time blocks with Internet and some without, and enforce the rule strictly even if it seems silly.
3. Pick up the right tools for your job by assessing the positive but also the negative impact. Most of the time that means "get off social media." Also avoid fast-paced entertainment since it can undo all the day training and embrace boredom as a way to train your focus.
4. Use every minute of your day intentionally by scheduling them, even if that means redoing your schedule several time as new priorities emerge. Quantify the depth of your work and ask your boss for a shallow work budget. Finish early so your day is tightly time boxed and shallow work becomes even more expensive (so easier to refuse). Become hard to reach so you don't spend your day in your inbox.

An insightful book

Like in all personal growth books, storytelling takes many pages in Deep Work, but here it supports nicely the argument of the author. The book was pleasant to read and helped me question my relationship to technology and work.

In the first section the author backs his claims about the importance of focus with evidences from academic studies. Of course since the second section is all about establishing new rules to allow deep work, it's not possible to have proofs that it works. With that said, I bought a late edition and would have liked an "augmented" conclusion with evidence from people who used the methodology successfully in the real world.

You can find my key takeaways from the book by having a look at my reading notes.

I would like to have my blog indexed on GNOME Planet. GNOME Planet’s repo, however, doesn’t appear to be licensed – there’s no note about the license on https://gitlab.gnome.org/Infrastructure/planet-web, and no license file in the repo.

It would be difficult to add a license now, as there have been thousands of commits to the repo, with a lot of individual contributors. Relicensing might require contacting each one of these authors.

But I don’t like committing to repositories which are not licensed. I’m not even sure I can – do I maintain my copyright, or does the new owner? How would that fall out in court? In which jurisdiction is gnome-planet – the US?

So I asked ChatGPT (itself a pretty odd legal move) whether I could license a commit. Unsurprisingly, it says that no, you can’t, because a repository is a work in itself, and that license would take over. This is obviously garbage. When I asked it to clarify, it said that you might be able to, but it would “violate norms”. Sure, that seems accurate, but I am glad that ChatGPT is not my lawyer.

I figure, if my work is my work, there’s no reason I can’t license a change to a file. Whether not that license will be enforced is anyone’s guess, but legally, I should be responsible for my own lines of code. So, I opened this pull-request: https://gitlab.gnome.org/Infrastructure/planet-web/-/merge_requests/163. I noted in the commit that the license is an MIT license, and then I noted that in the PR comment field, too.

Technically, the MIT license demands that the license be shared with the commit. So I’ve just amended the commit to include the license, too, which satisfies my needs.

I don’t think that there will ever be a technical issue with licensing for this repo. And I don’t know if Felipe will merge my commit. But it is an interesting experiment.

➜ planet-web git:(feat/add-my-feed) git show HEAD commit 3acaff792c635e9c277d892f37b45997b0b57d70 (HEAD -> feat/add-my-feed, richardlitt/feat/add-my-feed) Author: Richard Littauer <richard+github@burntfen.com> Date: Tue May 6 09:38:38 2025 +1200 Adding my ID This commit is licensed under an MIT license. MIT License Copyright (c) 2025 Richard Littauer Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. diff --git a/config/gnome/config.ini b/config/gnome/config.ini index 9ea71857..4829be43 100644 --- a/config/gnome/config.ini +++ b/config/gnome/config.ini @@ -3513,3 +3513,7 @@ outreachy = 1 [https://conduct.gnome.org/feed/] name = Code of Conduct Committee #nick = + +[https://blogs.gnome.org/richardlitt/feed/] +name = Richard Littauer's blog +nick = richardlitt

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

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

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

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

# Safety in the Community

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

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

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

CoC Links

• Code of Conduct
• Report an Incident

# Opaque Context

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

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

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

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

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

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

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

# Good Faith

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

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

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

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

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

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

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

# Trust and Accountability

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

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

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

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

# Final Thoughts

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

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

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

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

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

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

The complexity question

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

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

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

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

Iterating things the native way

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

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

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

So given that you have a callback function like this:

the split function becomes:

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

Iterating things the Python way

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

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

Current status

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

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

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

April was light.

exempi

Released Exempi 2.6.6 to fix security issues from upstream.

libopenraw

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

Released alpha.10 on May 1st.

I knew this day would come at some point. It is time for me to say farewell to the GNOME Foundation in my capacity as the Interim Executive Director.

Last summer, Rob McQueen messaged me in mid-June asking if I could come on and help GNOME out as the Interim Executive Director. I had applied for the position the year before, and so he was familiar with my work. Some of the other board members knew me well, too – Karen Sandler and Michael Downey had both crossed my paths many times through SustainOSS. Rob wanted me to start as soon as possible, and to fill in as much as I could.

I told him, in no uncertain tones, that this was flat-out impossible.

First, I was one week away from moving to New Zealand from Vermont. The international move had been planned for a couple of years, and was right in the middle of happening. I had signed on to do a PhD at Te Herenga Waka Victoria University of Wellington. I already had a job as one of the co-organizers of CURIOSS and SustainOSS, where I also hosted a weekly podcast. And I had a job as a language consultant, making languages for novelists. I didn’t have a house lined up in Wellington. I would be arriving in winter.

Rob asked very nicely. Somehow, I said yes – on the condition that I would do it part-time, and that they would ramp up their efforts to find a permanent ED as soon as possible, and that under no account would that be me. I signed up for a two-month contract.

That was ten months ago. I went on to renew the contract for another month, and then another two. For the last five months, I have been working with very limited hours and helping where absolutely necessary.

Today, I am happy to say that I am rolling off, because a new Executive Director – a permanent one – has been hired. I am overjoyed. This is exactly what GNOME needs, and I think that he is the right person for the job.

My time has been exceedingly difficult. In the first couple of days on the job, I realized that I would be needed back at GUADEC in Denver, so I flew back from New Zealand for it. I met many on the staff and the board for the first time. For many reasons, that week was incredibly stressful. Slowly, slowly, things got better.

I feel that I have done very little; all of the gains happened with the help of others.

Because of Zana’s leadership and amazing institutional memory, and Michael Downey and Pablo Correa Gómez’s meticulous financial help, we were able to pass a balanced budget through the board, on time. Thank you.

Because of Rob’s long hours and all-encompassing understanding of GNOME, we were able to secure more funding from the Dalio Foundation to help move us forward. Thank you.

Because of Allan Day’s incredibly steady hand and ceaseless effort, we were able to navigate some incredibly difficult conversations that the board was having. Thank you.

Because of the staff – Kristi, Anisa, Zana, Melissa, and Caroline – we managed to host not just a fantastic GUADEC, but also other great events around the globe. Thank you.

Because he was open to be peer-pressured into taking it, Julian Sparber made amazing minutes from all of the meetings we attended. Thank you.

Because of Bart, everything kept running. I think this is what Bart does. Thanks Bart.

Because of Holly’s generosity, I was able to take over much more smoothly. Thank you for your time, Holly.

Because of Federico Mena Quintero and the Code of Conduct Committee, many issues were resolved with contributors, and I’m not talking only about elephants in rooms. I cannot overstate how hard this work is and how much of a struggle it is to do it well. I’m constantly grateful for them keeping spaces safe.

That also applies to other people in the community – thank you, Sri Ramkrishna, Deepesha Burse, Justin Wheeler. I’m missing people. I’m grateful anyway.

Because of Thibault Martin, I was able to figure out what was going on and how to ensure that everyone under STF contracts got paid. Thibault, I miss our almost daily meetings! Thank you.

Because of people in the wider community, I was able to get expert help for tough questions. Thank you to our lawyers, our accountants, and, of course, people like Deb Nicholson of PSF and Robin Riley of Matrix and Leah Silen of NumFOCUS and Gunner of Aspiration and Abby Cabunoc Mayes of SustainOSS and Duane O’Brien and so many, many others. There are many, many people in open source and in the computing space that rely on or support GNOME without ever being thanked, and in some cases without knowing it. Thanks to my partner, Julia – she woke up for those 2:00am board meetings, too (although she mostly fell back asleep). Thank you.

Cassidy Blaede and Philip Chimento stepped up to fill board seats, and because of them we have a stronger board. Karen Sandler, you’re my favorite person. Erik Albers, your calm presence kept all of us on track at the GUADEC board meetings. Thank you.

Because of our sponsors, and everyone on our advisory board, GNOME is able to continue doing what it does. Advisors, thanks for smiling and nodding as I said nothing at all over nachos in Denver. You’re doing the good work. Thank you.

And then, of course, there’s the rest. People like Sid T – I’ve rarely met someone as dedicated and perseverant as Sid. It’s because of him that MacStadium is now sponsoring us. Sid, thank you.

Adrian, thank you. Marie, thank you. Tobias, thank you. Alexandre, thank you.

I could, and should, go on. I know I’ve missed people. I’m not perfect. My time here wasn’t perfect. I’ve lost many, many hours of sleep, not only due to the 2:00am calls, but because some of the decisions I have had to deal with have stretched me, and made me so much more appreciative of the work of other executive directors I know who run similar foundations. (Karen and Michael, when do you sleep). I’ve made mistakes. They are my own, and I am sorry.

Since starting, I have had a single minded goal to make sure that GNOME survives until the next executive director and that I make their job easier. I hope I have succeeded in that goal. But, again, I didn’t accomplish that on my own. That’s not how an Interim Executive Director works. For the last few months, Allan, Rob, Julian, and Zana have been working overtime to allow me to focus on my own work. I am thankful for them, and I think you should be, too.

Steven will do a great job. I wish you the best time of it, Steven – you couldn’t ask for a better community to work with.

I am not, in fact, dying, although this does sound rather eulogaic. I’m just going to spend more time as a user now. I might even have time to post updates on this blog. I hope so.

Reach out whenever, anyone, everyone. I like connecting people. And I like doing what I can to help. You can find me on Mastodon, at my website, and at https://richard.social. Or at richard@gnome. I’ll keep checking it.

Until then,
Thanks.

P.S. It really is pronounced /gno:m/, it’s just so much more fun that way. And the foot logo should stay, alright, it’s a good logo.

 

Some links for technical articles on various topics I read.

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

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

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

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

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

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

We have replaced Buildbot with a custom service, and we hope you haven't noticed.

Vorarbeiter is a German word for "foreman" and a living proof of my school-related trauma. The new service is a middleman between GitHub and GitHub Actions. It has been happily humming since April 21st, and largely does what Buildbot did: builds apps, with a sprinkle of publishing logic.

While what happens under the hood is solid, there is no UI yet. Flathub bot will still inform developers about build status for their pull requests, but there is little visibility of what happens post-merge.

Additionally, Vorarbeiter no longer allows to manually publish, cancel or delete builds. The publishing happens every hour regardless of the age of the build. The previous 3-hour-long delay was too conservative, and barely anyone was giving a final test for a post-merge builds. Similarly, cancelling builds doesn't seem as necessary as before. GitHub Actions runners are ephemeral and new commits on the same branch or pull request will automatically cancel the previous in-progress build.

Last but not least, because of limitations of the free GitHub Actions runners, some apps are designated as large builds. Large builds take place on machines provisioned in AWS, boasting faster CPUs and larger disks to accommodate heavier requirements.

While large builds do not incur costs per se thanks to the generous AWS credits for open source projects program, we still want to be mindful of how much credits we are spending, which is why we don't run large runners all the time. This is possible thanks to RunsOn, which handles all the magic for us. It receives pipeline events from GitHub and provisions new machines automatically within seconds, and tears them down the moment the build is finished. This is completely invisible to developers, but is both faster and more cost-effective, even if we were to pay the bill ourselves.

There is still more work to be done. I want to improve observability of the new service to make sure we can have automatic alerts when we have an abnormal build error rate or unprocessed publishing queue. In fact, we already notify maintainers and Flathub admins when a build triggered on the master branch failed, but there is potential to be more proactive here.

The unsolved challenge so far is caching. Every new pipeline re-downloads Flatpak runtimes, SDKs, and source code needed to build the app. Ideally, we should cache at least the runtimes, but with runners being ephemeral, we should also attempt to implement a distributed solution for ccache to reduce build times.

Given the challenging circumstances, this is more than good enough, though! If you encounter any issues with the new workflow, don't hesitate to open an issue in the project's GitHub repository.

WebKitGTK has a bunch of different confusing API versions. Here are the three API versions that are currently supported by upstream:

• webkitgtk-6.0: This is WebKitGTK for GTK 4 (and libsoup 3), introduced in WebKitGTK 2.40. This is what’s built by default if you build WebKit with -DPORT=GTK.
• webkit2gtk-4.1: This is WebKitGTK for GTK 3 and libsoup 3, introduced in WebKitGTK 2.32. Get this by building with -DPORT=GTK -DUSE_GTK3=ON.
• webkit2gtk-4.0: This is WebKitGTK for GTK 3 and libsoup 2, introduced in WebKitGTK 2.6. Get this by building with -DPORT=GTK -DUSE_GTK3=ON -DUSE_SOUP2=ON.

webkitgtk-6.0 contains a bunch of API changes, and all deprecated APIs were removed. If you’re upgrading to webkitgtk-6.0, then you’re also upgrading your application from GTK 3 to GTK 4, and have to adapt to much bigger GTK API changes anyway, so this seemed like a good opportunity to break compatibility and fix old mistakes for the first time in a very long time.

webkit2gtk-4.1 is exactly the same as webkit2gtk-4.0, except for the libsoup API version that it links against.

webkit2gtk-4.0 is — remarkably — mostly API stable since it was released in September 2014. Some particular C APIs have been deprecated and don’t work properly anymore, but no stable C APIs have been removed during this time, and library ABI is maintained. (Caveat: WebKitGTK used to have unstable DOM APIs, some of which were removed before the DOM API was eventually stabilized. Nowadays, the DOM APIs are all stable but deprecated in webkit2gtk-4.1 and webkit2gtk-4.0, and removed in webkitgtk-6.0.)

If you are interested in history, here are the older API versions that do not matter anymore:

• webkit2gtk-5.0: This was an unstable API version used during development of the GTK 4 API, intended for WebKit developers rather than application developers. It was obsoleted by webkitgtk-6.0.
• webkit2gtk-3.0: original API version of WebKitGTK for GTK 3 and libsoup 2, obsoleted by webkit2gtk-4.0. This was the original “WebKit 2” API version, which was only used by a few applications before it was removed one decade ago (history).
• webkitgtk-3.0: note the missing “2”, this is “WebKit 1” (predating the modern multiprocess architecture) for GTK 3. This API version was widely-used on Linux, and its removal one decade ago precipitated a security crisis which I called The Great API Break. (This crisis was worth it. Modern WebKit’s multiprocess architecture is far more secure than the old single-process architecture.)
• webkitgtk-1.0: the original WebKitGTK API version, this is “WebKit 1” for GTK 2. This API version was also widely-used on Linux before it was removed in The Great API Break.

Fedora and RHEL users, are you confused by all the different confusing downstream package names? Here is your map:

• webkitgtk6.0, webkit2gtk4.1, and webkit2gtk4.0: This is the current binary package naming in Fedora, corresponding precisely to the WebKitGTK API version to reduce confusion.
• webkit2gtk3: old name for webkit2gtk4.0, still used in RHEL 9 and RHEL 8
• webkitgtk4: even older name for webkit2gtk4.0, still used in RHEL 7
• webkitgtk3: this is the webkitgtk-3.0 API version, still used in RHEL 7
• webkitgtk: this is webkitgtk-1.0, used in RHEL 6

Notably, webkit2gtk4.0, webkit2gtk3, and webkitgtk4 are all the same thing.

Introduction:

GNOME GitLab now uses macOS runners from MacStadium for managing our macOS CI pipeline. This offers significant improvements in supporting the GNOME platform on macOS. In this blog, we’ll cover the event timeline of macOS CI in GNOME GitLab and the technical details of the new infrastructure setup from MacStadium.

Background:

Around mid 2023, the GNOME Infrastructure Team decided to retire the existing macOS CI runners for a handful of reasons as explained in this post by Emmanuele Bassi. They were x86_64 runners which were quite outdated technically, as they were replaced by better and faster Apple Silicon M series ARM SoCs (specifically Apple M1) from Nov 2020.

There was no macOS CI in GNOME GitLab since then. GNOME core projects like GTK, GLib and few apps still provided macOS support on a best effort basis: meaning development and testing would be done on user machines. Though this is far from perfect, this provided some basic macOS support for GNOME projects.

Infrastructure help from René:

René de Hesselle is a member of Inkscape’s Project Leadership Committee and an open source developer who specializes in building, packaging and porting applications to the macOS platform. Looking into the macOS CI issues GNOME projects were facing, René offered to help with the macOS effort in GNOME, which was greatly appreciated by GNOME developers.

René has been assisting core libraries like GLib, GTK and GNOME apps to build in macOS. To address the macOS CI limitation, René went a step further and provided a self hosted GitLab macOS CI runner. With assistance from the GNOME Infrastructure Team, the self hosted runner was made available to projects across GNOME. This proved to be really useful, as it increased the pace of development in macOS.

Scalability and Sustainability Issues:

Over time, as more projects switched to using the self hosted macOS CI runner, it was becoming evident that this solution would not be effective for the scale of GNOME and not sustainable in the long term. René opened this topic for discussion in this post.

It was quite evident that we needed an enterprise solution to offer scalable and sustainable macOS CI service. This is when MacStadium’s FOSS program was highlighted as a possible solution in GNOME Discourse.

MacStadium, FOSS and GNOME:

MacStadium is well known in the open source world for sponsoring developers of open source projects for the Apple platform, including macOS, iOS, tvOS, and watchOS.

The GNOME Team got in touch with MacStadium for sponsoring macOS CI runners under their FOSS program. Though the MacStadium FOSS program was not available as it was already at capacity, MacStadium was excited in partnering with GNOME. Special thanks to Lauren Cabana (Director, Marketing) from MacStadium for actively pursuing this effort and making this collaboration possible.

MacStadium Orka Cluster solution:

As part of this collaboration, MacStadium has offered the following infrastructure setup based on our requirements:

• Orka (Orchestration with Kubernetes on Apple) Cluster.
• Dedicated network with firewall and VPN.
• 1 TB NAS storage.
• 2 x Mac mini (M1, 8-core CPU, 10-core GPU, 16GB RAM, 1TB SSD).

This is a significant bump in hardware specs compared to the current solution, allowing us to run more builds simultaneously. But the biggest benefit is having access to a turnkey solution that provides ephemeral machines: build isolation is no longer a concern and restrictions on customizability can be lifted, making it possible to open macOS CI instance-wide on GNOME GitLab with minimal administrative oversight. This setup is located in MacStadium’s Dublin data center.

Thanks to MacStadium for sponsoring this infrastructure upgrade!

Thanks and Mentions:

• Richard Littauer – for interfacing with MacStadium via calls / emails and active participation.
• René de Hesselle – for actively taking part in all technical discussions.
• Philip Withnall – for coordinating efforts within GNOME.
• Bartłomiej Piotrowski – for setting up GNOME / MacStadium accounts.

This post is a response to what Tobias posted yesterday on his blog. I would really prefer not be writing it. There are many other things that I would prefer to be doing, and I do not enjoy engaging in public disagreements. I honestly find all of this very stressful and unpleasant, but here we are.

For context, I joined the board in July last year, having previously been on the board from 2015 to 2021. This means that I wasn’t on the board during some of the events and decisions described in Tobias’s post. I am assuming that I am not one of the unnamed individuals he is calling on to resign, though I would be significantly impacted if that were to happen.

The post here is a personal view, based on my close involvement with the issues described in Tobias’s post. As such, it is not an official board position, and other directors may disagree with me on some points. It’s possible that the board may produce its own official statement in the future, but boards are inherently slow-moving beasts, and I wanted to get something posted sooner rather than later.

I want to start by saying that it is difficult to respond to Tobias’s post. The Foundation has a policy that we don’t comment on specific code of conduct cases, in order to protect the privacy of those involved. And, when you get down to it, this is mostly about the particulars of one specific case. Without being able to discuss those particulars, it is hard to say very much at all. That, in my opinion, is the elephant in the room.

The other reason that it is difficult to respond is there are just so many broad brush accusations in the blog post. It presents power conflicts and financial mismanagement and reckless behaviour and so on and so forth. It’s impossible to address every point. Instead, what I will do is provide a fairly high-level view of each of the two main themes in the post, while calling out what I consider to be the main inaccuracies. The first of those themes is the code of conduct decision, and the second relates to the performance of the Foundation.

The big elephant

In the blog post, Tobias throws around a lot of accusations and suggestions about the code of conduct decision to suspend Sonny Piers from the GNOME project. His description of the chain of events is both misleading and a misrepresentation of what happened. Then there’s an accusation of recklessness, as well as an accusation that the code of conduct decision was somehow politically motivated. All of this is clearly intended to question and undermine the code of conduct decision, and to present a picture of mismanagement at the foundation.

My view is that, despite the various twists and turns involved in the decision making process for this case, and all the questions and complexities involved, it basically boils down to one simple question: was the decision to suspend Sonny the correct one? My view, as someone who has spent a significant amount of time looking at the evidence, talking to the people involved, and considering it from different perspectives, is that it was. And this is not just my personal view. The board has looked at this issue over and over, and we have had other parties come in to look at it, and we have always come to the conclusion that some kind of suspension was appropriate. Our code of conduct committee came to this conclusion. Multiple boards came to this conclusion. At least one third party who looked at the case came to this conclusion.

I understand why people have concerns and questions about the decision. I’m sympathetic to the experiences of those individuals, and I understand why they have doubts. I understand that some of them have been badly affected. However, ultimately, the board needs to stand up for the code of conduct. The code of conduct is what provides safety for our community. We do not get to set it aside when it becomes inconvenient.

The argument that the code of conduct decision was somehow politically motivated is false. We even had an external reviewer come in and look at the case, who confirmed this. Their report was provided to Tobias already. He continues to make this accusation despite it standing in opposition to the information that we have provided him with.

Tobias seems to think that Sonny’s importance to the GNOME project should have been taken into account in our decision for the code of conduct case. To me, this would imply that project leaders would operate according to a different, less stringent, set of conduct rules from other contributors. I believe that this would be wrong. The code of conduct has to apply to everyone equally. We need to protect our community from leaders just as much as we need to protect them from anyone else.

No one is suggesting that the management of the code of conduct decision was good. Communication and management should have been better. Community members were significantly impacted. We have sincerely apologised to those involved, and are more than willing to admit our failings. We’ve also been working to ensure that these problems don’t happen again, and that’s something that I personally continue to spend time and energy on.

However, to understand those failings, you also have to look back at the situation we faced last year: we had just lost an ED, board members were burned out, and our processes were being tested in a way that they never had been before. We still had all the usual board and foundation work that needed taking care of. In the middle of it all, elections happened and the board membership changed. It was a complex, shifting, and demanding situation, which looks rather different in retrospect to how it was experienced at the time. We learned a lot of lessons, that’s for sure.

The other elephant

The other part of Tobias’s post addresses the performance of the Foundation.

He points out various problems and challenges, some of which are real. Unfortunately, while being convenient, the theory that all of these challenges are the result of the incompetence of a few individuals is, like most convenient answers, incorrect. The reality is more complex.

One of the major factors for the Foundation’s current situation is our recent history with Executive Directors. Neil left as ED in November 2022. It took us about a year to hire Holly, who was ED for seven months, during which time she had to take a non-trivial amount of time off [1]. And the Foundation is a small organisation – there aren’t lots of people around to pick up the slack when someone leaves. Given these circumstances, it’s unsurprising that the Foundation’s plans have changed, or that they didn’t happen in the way we’d hoped.

This is why the current board has been focusing on and expending considerable effort in recruiting a new executive director, who will be joining us very soon. Hurrah!

Tobias’s proposition that anyone who tries to change the Foundation gets burned out or banned is not true. I am living proof of this. I have changed the Foundation in the past, and continue to change it as part of my role as director. The Foundation today is radically different from the one I first joined in 2015, and continues to evolve and change. A lot of this is due to the interventions of previous and current directors over time.

Amid all this, it’s also important not to forget all the things that the Foundation has been successfully doing in recent years! I went into some of this in my recent blog post, which provides more details than I can here. It is worth stressing that the ongoing successes of the Foundation are mostly thanks to the dedication of its staff. We’ve run successful conferences. We’ve supported Flathub during which time it has experienced extraordinary growth. We’ve supported development programs. And the organisation has kept running, sailing through our taxes and registrations and all those other bureaucratic requirements.

On resignations

From the outside the GNOME Foundation can seem a little opaque. Part of the reason for that is that, as a board, we have to deal with sensitive and confidential matters, so much of the work we do happens behind closed doors. However, when you are on the board you quickly learn that it is really much like any other community-based open source team: there’s usually more work to do than we have capacity for, and the majority of the work gets done by a small minority of contributors.

Speaking as part of that minority, I don’t think that it would be beneficial for members of the board to resign. It would just mean fewer people being available to do the work, and we are already stretched for resources. I’m also of the view that no one should be asked to resign in response to upholding the code of conduct. Conduct work is difficult and important. It requires tough decisions. As a community we need to support the people doing it.

And if people think we should have different directors, well, that’s what the elections are for.

Closing

Readers might wonder why the Foundation has not spoken publicly about this topic (reminder: I’m not speaking on behalf of the Foundation here). The main reasons are confidentiality and legal concerns. We also tried very hard to respect the wishes of those who have been involved and affected. Now with Tobias’s post it is harder to avoid saying things in public. I’m personally skeptical of how useful this is: with opaque and complex issues like these, public discussions tend to generate more questions than they do answers. Contributor relationships are unfortunately likely going to get damaged. But again, here we are.

It should be said that while the foundation hasn’t spoken publicly about these issues, we have expended significant effort engaging with community members behind the scenes. We’ve had meetings where we’ve explained as much of what has happened as we can. We even went so far as to commission an external report which we made available to those individuals. We continue to work on improving our processes in response to the, ahem, feedback we’ve received. I personally remain committed to this. I know that progress in some areas has been slow, but the work continues and is meaningful.

Finally: I am sure that there are contributors who will disagree with what I’ve written here. If you are one of those people, I’m sorry that you feel that way. I still appreciate you, and I understand how difficult it is. It is difficult for all of us.

[1] Edit: we were extremely lucky to have Richard Littauer as interim ED for the second half of 2024, and he did a huge amount. However, Richard was only working for us part-time, so was unable to deliver on strategic initiatives.

The desktop team in Red Hat has another open position. We’re looking for someone to work on Flatpak automation, for someone who enjoys working on infrastructure. Although the job description states 2+ years of experience, it’s suitable for juniors. Formal experience can be replaced by relevant open source contributions. Being onsite in Brno, Czech Republic is preferred, but not required. We’re open to hiring good candidates elsewhere, too.

If you’d like to know more about the job before formally applying, don’t hesitate to contact me on Mastodon, Signal, Matrix (@eischmann at fedora.im), or email.

After more than an year after, Boatswain 5.0 is finally out. It took me a long time to push it to the finish line, but I’m relatively happy with how it turned out, and it brings some nice features.

Let’s take a quick look at what’s new in this release!

New Devices

Boatswain 5.0 comes with support for 2 new device models from Elgato: Stream Deck Plus, and Stream Deck Neo.

Support for Elgato Stream Deck Plus came after the massively successful fundraising campaign from last year. A huge thanks to everyone that contributed to it!

As for Elgato Stream Deck Neo, I tentatively introduced support for it without actually having a device to test, so if there’s anyone out there that can test it, that’d be absolutely appreciated.

Support for Stream Deck Plus was probably the main reason it took so long to release Boatswain 5.0. The entirety of the app was originally written under the assumption that all devices were simply a grid of buttons. Introducing a touchscreen, and dials that act as buttons, required basically rewriting most of the app.

I used this opportunity to make Boatswain able to handle any kind of device, with any kind of layout. Everything is represented as regions in a grid layout. Simple Stream Deck devices just contain a button grid; Stream Deck Plus contains a button grid, a touchscreen, and a dial grid.

Keyboard Shortcuts

The new Keyboard Shortcut action allows executing any keyboard shortcut – or any keyboard event in general – on the desktop. This seems to work better than I could have anticipated!

Under the hood, this action uses the Remote Desktop portal be able to inject input on the desktop. Locally controlling the desktop was probably not on the original goals of the portal, but alas, it fit the use case perfectly!

Paired with folders, Keyboard Shortcuts are very powerful, especially for large and complex software with a large number of shortcuts.

Next Steps

This release might be a little disappointing as it took so long, and yet didn’t come as packed with new features. And yet, this was the largest release of Boatswain, perhaps larger than the initial release even.

I’ve reached a point where I’m mostly satisfied with how the internals work now. So much so that, right after the Boatswain 5.0 release, I was able to split the core logic of the app into an internal library, and hide device-specific details from the rest of the app. This paved the way for adding a testing framework using umockdev, and also will allow adding support for devices from other brands such as Loupedeck. If you have any Stream Deck-like device and wish to see it supported in Boatswain, now’s your chance!

For Boatswain 6, I personally want to focus on 2 major features:

1. Make Boatswain use the new USB portal. One of my goals with Boatswain is to make it a reference app, using the most modern platform features available – and adding missing features if necessary. The USB portal is an obvious choice!
2. Remove X11 support. This might come as a controversial decision, but I don’t personally use X11 anymore, do not support it, and will not work on fixing bugs that only exist there. As such, I think it’s fair to just remove X11 support from the apps that I maintain. Practically speaking, this just means removing --socket=fallback-x11, and users can add back this permission using Flatseal; but please do not expect any kind of support anymore.

Some features that would be lovely to have, but we currently don’t have either because we lack platform support (i.e. portals), or simply because nobody sat down and wrote it:

1. Tracking the current desktop state, such as the focused app, the session idle state, etc. This will be useful for contextual actions.
2. Clipboard integration. In theory people can simulate this using the Keyboard Shortcuts action, but proper clipboard integration will work better and in more cases.
3. Picking and launching apps from the host system. This needs to happen through portals which currently don’t exist.
4. A fancy visual icon editor so that people can create their pretty icons in the app! If any UI designer is reading, please consider yourself assigned to this little project.
5. Support for custom backgrounds in the touchscreen. I did not have time to finish it before the 5.0 release, but it shouldn’t be too hard to add it.
6. A proper testing framework!

Finally, I’d like to thank my Ko-Fi and YouTube supporters for all the patience and for enabling me to do this work. The fundraiser campaign last year was a massive success, and I’m happy to see the all this progress! You all are awesome and I truly appreciate the support.

Keep an eye on this space as there may be more good news in the near future!

Over the last two years I’ve worked a bit in my spare time on the user documentation of GIMP, a Free & Open Source Image Editor.
While I personally still consider it pretty bad user documentation regarding style inconsistency, duplication of topics, “organic growth”, and lack of task orientation, I managed to put some lipstick on that pig across nearly 900 commits.
I was sometimes rather ruthless pushing my changes (plus I am only a simple contributor and not a GIMP developer) so I’d like to thank Jacob Boerema for their patience and lenience.

In particular that led to

• pretty consistent and up-to-date user interface dialog screenshots using the default theme (a fun game in a repository with about 2000 images and no filename scheme whatsoever),
• less trivial screenshots; people know how menus look like and all their entries are covered by accompanying text anyway (which created more work for translators),
• all application icons updated to the default monochrome theme, in SVG format, located in one single directory within the docs repository, using the same filenames as in the GIMP code repository (so there’s theoretically a chance of maintenance),
  
• adding some icons to text because “click the fifth icon” isn’t particularly user-friendly (especially for RTL folks),
  
• slightly less quadruplication of string variants expressing the same meaning (which created more work for translators).

An interesting remaining issue is whether to remove outdated ancient localized screenshots and where to draw the line. Does having localized strings in the screenshot (not everybody prefers English) outweigh an outdated user interface in the screenshot (wrong numbers of buttons, or dropdowns instead of radio buttons)? Your mileage may vary.

Obviously there is much more to do, for example maybe rewriting everything from scratch or splitting screenshot files of translatable UI dialogs and non-translatable example images mashed into one single image file into two separate files because, again, translators and lower maintenance costs.

If you enjoy dealing with Docbook and all its quirks, see the open GIMP help issues or even write merge requests.

If my phone is making me miserable my constantly nagging me for attention, surely the solution must be to ditch it and take a dumb phone that can only place calls and send texts?

Except calls are particularly intrusive interruptions, and the only texts I receive are from couriers. My family and friends use iMessage or Signal. And what about the pictures I can snap in a few seconds by pulling my phone from my pocket? What about GPS navigation? What about those parking lots where you can only pay with an app? What if I need to order a cab in a country I don't speak the language of? What about using my phone app as a 2FA from the bank as the PSD2 practically requires?

I thought about using a dumb down smartphone like the Lite Phone III or any of the other dumbed-down Android phones. In practice it doesn't work for me, because most of them either don't let me use the apps I need or let me break out of the dumb mode to use the app. At this point, why using a dumbed down smartphone at all?

I don't need a dumb(ed down smart)phone. I need the convenience of my smartphone, but I need to use intentionally instead of being dragged to it. My phone was already in silent mode all the time because I can't stand being interrupted loudly by it unless it's an actual emergency. But whenever a notification pops on the screen it brightens up, drags my attention to it, and even if I don't want to interact with it it stays in the back of my head until I finally unlock the phone and have a look at what it's all about.

What I was missing was a sense of priority for notifications. To stay focused on what I cared about, I needed my phone to hold back the unimportant notifications and tell me when something important happened. I could already deny some app the authorization to display notifications, but that's a double edged sword. If I do so with messaging apps I end up compulsively checking them to see if I missed anything important.

What solved it for me was the Focus feature of the iPhone. Instead of using the Do Not Disturb mode, I've configured the Personal Focus profile. I configured it so

• No notifications at all appear on my screen.
• If my favorite contacts call me I will be notified.
• If someone calls me twice within three minutes it will bypass the protection.
• If an app has a Time Sensitive notification to send me, it will bypass the protection.

All the rest is filtered out. As a result I have a phone that doesn't actively nag me for attention. Because it notifies me when something truly important happens, I don't have to check it regularly out of Fear Of Missing Out. This tweak is part of a broader effort to reclaim my attention capacity.