A year and a half ago, shortly after the GNOME 45 release, I opened a pair of Pull Requests to deprecate and remove the X11 Session.
A lot has happened since. The GNOME 48 release addressed all the remaining blocking issues, mainly accessibility regressions, but it was too late in the development cycle to drop the session as well.
Now the time has come.
We went ahead and disabled the X11 session by default and form now on it needs to be explicitly enabled when building the affected modules. (gnome-session, GDM, mutter/gnome-shell). This does not affect XWayland, it’s only about the X11/Xorg session and related functionality. GDM’s ability to launch other X11 sessions will be also preserved.
Usually we release a single Alpha snapshot, but this time we have released earlier snapshots (49.alpha.0), 3 weeks ahead of the normal schedule, to gather as much feedback and testing as possible. (There will be another snapshot along the complete GNOME 49 Alpha release).
If you are a distributor, please try to not change the default or at least let us (or me directly) know why you’d need to still ship the X11 session.
As I mentioned in the tracking issue ticket, there 3 possible scenarios.
The most likely scenario is that all the X11 session code stays disabled by default for 49 with a planned removal for GNOME 50.
The ideal scenario is that everything is perfect, there are no more issues and bugs, we can go ahead and drop all the code before GNOME 49.beta.
And the very unlikely scenario is that we discover some deal-breaking issue, revert the changes and postpone the whole thing.
Having gathered feedback from our distribution partners, it now depends entirely on how well the early testing will go and what bugs will be uncovered.
You can test GNOME OS Nightly with all the changes today. We found a couple minor issues but everything is fixed in the alpha.0 snapshot. Given how smooth things are going so far I believe there is a high likely-hood there won’t be any further issues and we might be able to proceed with the Ideal scenario.
TLDR: The X11 session for GNOME 49 will be disabled by default and it’s scheduled for removal, either during this development cycle or more likely during the next one (GNOME 50). There are release snapshots of 49.alpha.0 for some modules already available. Go and try them out!
Imagine a punchy, news-broadcast-sounding intro tune and probably some 3D text swinging around a shiny, silver globe. Dun da da dun: The June 6th, 2025 GNOME Foundation Report!
Sorry. These reports need a little colour or I’m going to get bored of writing them. Also sorry this one is late again! Busy week.
## Fundraising
This week’s big activity (for me) was preparing a fundraising proposal for the Board of Directors at a special meeting on Tuesday. The day before, everyone on staff patiently listened to me shout and spit and sweat and then patiently gave me feedback. Thanks y’all.
Sidenote: I love the notion of a “special meeting.” I know it’s not meant to feel cute and silly, but it feels very cute and silly. That said, we got a lot done!
The Board is on-board. Yay. We had a project kickoff the next day. We have a repo, we have some early work done already. I’m not allowed to make any promises. So you’ll just have to watch this space, I guess.
## Treasurer
During the special meeting, it was voted that we would make an offer to a new Treasurer. I’m really looking forward to this announcement if they accept!
## Project Wall!
The Staff project wall is really taking off, and it feels like we have some momentum with it now. Too many things in flight and too many cards in the “blocked” column, but we’re steadily improving.
## Vaultwarden
Bart’s hooked us up with Vaultwarden for the Foundation’s shared passwords, as our tooling was a little broken and/or scattered previously. Yay! Thanks Bart.
## Digital Wellbeing Frontend
We held a Digital Wellbeing meeting on Tuesday and we now have a Call for Proposals up:
If you still know C and you want to help take this project over the line, it’s a neat piece of integration work.
## 501(c)3s
I met my friend Brihas, who is also an Executive Director of another 501(c)3. It was good to pick his brain about:
Limits to capital retention: Despite a widely-held misconception, there aren’t any.
990 Schedule B redactions: When and why. The GNOME Foundation fully redacts our Schedule Bs… that seemed weird to me at first but he says it’s fairly common, which agrees with what others have told me.
How to keep the Board engaged: Whether one has a Working Board or not (we do), “engagement” in this question refers to the level of governance, not execution. He said his organization has found real benefit in a stricter adherence to Policy Governance. I’m inclined toward a stricter form of this model myself, and would encourage potential Board members (this year and in future years) to glance through that Wikipedia page.
How to take vacation: He prepares a year in advance. Seems about right.
## Meeting The Matts
I had a chance to sit down with an old friend (Matt Godbolt, of Compiler Explorer fame) and a new friend (Matt Hartley, of Framework Computer fame). We talked variously about how to raise money, the future of the Linux desktop, the “sandwich problem” (that GNOME neither has the name recognition of Linux nor the product recognition of distros), and the fact that every cool kid at Strange Loop 2024 was running a Framework, not a Mac.
I left both calls super excited to talk to them both again. Great folks. (I also just noticed their respective website have very similar gear favicons.)
## Grants
I got to talk to Richard! He’s still very busy. He had some grant suggestions. It was nice to see him.
## End of 10
I’ve still got an eye toward the https://endof10.org/ project. Increasingly, I have a fantasy of a simple, brightly-coloured A4 that explains how to get started with GNOME, in ~6 steps, if you’re coming from Windows:
what’s the equivalent of the “start” button? (do they still… call it that?)
how do I run a program?
how do I install a program?
how do I start the web browser? which one should I use? how do I get chrome[ium]?
where are my files?
where are my settings?
Extras for the back side of the paper:
“modern” apps: Discord, Slack, Spotify, Telegram, Signal, etc.
how to install games
GNOME-specific features (virtual desktops and such)
core platform apps
“everyday” settings: wifi, bluetooth, light/dark mode, etc.
GNOME Online Accounts and Office files
What do you think? Would you want to help with this? Is this a silly idea? Does this already exist somewhere?
## Meeting People
I had a nice conversation with Lorenz, as he’s the only Board candidate I hadn’t spoken to yet. I met Sumana Harihareswara, who is extremely cool and I ran out of time while picking her brain about the various ways the GNOME Foundation can start its own grants program. I got some advice from Federico about how to improve our docs-creation process… among other things, he had the pretty sensible idea of just letting people barf streams of consciousness at me (or other folks comfortable with reStructuredText) and letting the documentation gnomes clean it up before publishing it. Seems legit! I had my first formal feedback session with Rosanna — she had prepared a 5-point structured document and I had to admit to her it was the most rigorous feedback I’ve ever received.
## UN Open Source Week
I found a couch to crash on in NYC and a cheap flight, so I’ll be there! If you’re in NYC the week of the 16th to the 20th, reach out!
That’s all for this week. See you in the next one and I’m sorry I didn’t make it in time for TWIG again.
Summer reading rec, and ask for more recs: “cozy sci-fi” is now a thing and I love it. Characters going through life, drinking hot beverages, trying to be comfortable despite (waves hands) everything. Mostly coincidentally, doing all those things in post-dystopian far-away planets (one fictional, one Jupiter).
Novellas, perfect for summer reads. Find a sunny nook (or better yet, a rainy summer day nook) and enjoy. (New Mossa and Pleiti comes out Tuesday, yay!)
A complex socio-technical system, bounding boldly, perhaps foolishly, into the future. (Original via NASA)
This book is about things I know a fair bit about, like international trade sanctions, money transfers, and technology (particularly the intersection of spying and data pipes). So in some sense I learned very little.
But the book efficiently crystallizes all that knowledge into a very dense, smart, important observation: that some aspects of American so-called “soft” (i.e., non-military) power are in increasingly very “hard”. To paraphrase, the book’s core claim is that the US has, since 2001, amassed what amounts to several, fragmentary “Departments of Economic War”. These mechanisms use control over financial and IP transfers to allow whoever is in power in DC to fight whoever it wants. This is primarily China, Russia, and Iran, but also to some extent entities as big as the EU and as small as individual cargo ship captains.
The results are many. Among other things, the authors conclude that because this change is not widely-noticed, it is undertheorized, and so many of the players lack the intellectual toolkit to reason about it. Relatedly, they argue that the entire international system is currently more fragile and unstable than it has been in a long time exactly because of this dynamic: the US’s long-standing military power is now matched by globe-spanning economic control that previous US governments have mostly lacked, which in turn is causing the EU and China to try to build their own countervailing mechanisms. But everyone involved is feeling their way through it—which can easily lead to spirals. (Threaded throughout the book, but only rarely explicitly discussed, is the role of democracy in all of this—suffice to say that as told here, it is rarely a constraining factor.)
Tech as we normally think of it is not a big player here, but nevertheless plays several illustrative parts. Microsoft’s historical turn from government fighter to Ukraine supporter, Meta’s failed cryptocurrency, and various wiretapping comes up for discussion—but mostly in contexts that are very reactive to, or provocative irritants to, the 800lb gorillas of IRL governments.
Unusually for my past book reports on governance and power, where I’ve been known to stretch almost anything into an allegory for open, I’m not sure that this has many parallels. Rather, the relevance to open is that these are a series of fights that open may increasingly be drawn into—and/or destabilize. Ultimately, one way of thinking about this modern form of power dynamics is that it is a governmental search for “chokepoints” that can be used to force others to bend the knee, and a corresponding distaste for sources of independent power that have no obvious chokepoints. That’s a legitimately complicated problem—the authors have some interesting discussion with Vitalik Buterin about it—and open, like everyone else, is going to have to adapt.
The research and history in this book are amazing, but the terminology does not quite capture what it is trying to share out as learnings. (It’s also very dry.)
The key takeaway: good people, doing hard work, in systems that slowly learn to handle variation, can be completely unprepared for—and incapable of handling—things outside the scope of that variation.
It’s definitely the best book about the political analysis of the New York Times in the age of the modern GOP. Also probably good for a lot of technical organizations handling the radical-but-seemingly-small changes detailed in Underground Empire.
A book about how interfaces between humans and technology is hard. (I mean clothes, but also everything else.) Delightful and wide-ranging; maybe won’t really learn any deep lessons here but it’d be a great way to force undergrads to grapple with Hard Human Problems That Engineers Thought Would Be Simple.
It’s summer, which means its time for GSoC/Outreachy. This is the third year the Crosswords team is participating, and it has been fantastic. We had a noticeably large number of really strong candidates who showed up and wrote high-quality submissions — significantly more than previous years. There were a more candidates then we could handle, and it was a shame to have to turn some down.
In the end, Tanmay, Federico, and I got together and decided to stretch ourselves and accept three interns for the summer: Nancy, Toluwaleke, and Victor. They will be working on word lists, printing, and overlays respectively, and I’m so thrilled to have them helping out.
A result of this is that there will be a larger number of Crossword posts on planet.gnome.org this summer. I hope everyone is okay with that, and encourages them so they stay involved with GNOME and Free Software.
Release
This last release was mostly a bugfix release. The intern candidates outdid themselves this year by fixing a large number of bugs — so many that I’m releasing this to get them to users. Some highlights:
Mahmoud added an open dialog to the game and got auto-download of puzzles working. He also created an arabic .ipuz file to test with which revealed quite a few rendering bugs.
Arabic Crossword
Toluwaleke refined the selection code. This was accidentally marked as a newcomer issue, and was absolutely not supposed to be. Nevertheless, he nailed it and has left selection in a much healthier state.
[ It’s worth highlighting that the initial MR for this issue is a masterclass in contributions, and one of the best MRs I’ve ever received. If you’re a potential GSoC intern, you could learn a lot from reading it. ]
Victor fixed divided cells and a number of small behavior bugs. He also did methodical research into other crossword editors.
Divided Cells
Patel and Soham contributed visual improvements for barred and acrostic puzzles
In addition, GSoC-alum Tanmay has kept plugging on his Acrostic editor. It’s gotten a lot more sophisticated, and for the first time we’re including it in the stable build (albeit as a Beta). This version can be used to create a simple acrostic puzzle. I’ll let Tanmay post about it in the coming days.
Coordinates
Specs are hard, especially for file formats. We made an unfortunate discovery about the ipuz spec this cycle. The spec uses a coordinate system to refer to cells in a puzzle — but does not define what the coordinate system means. It provides an example with the upper left corner being (0,0) and that’s intuitively a normal addressing system. However, they refer to (ROW1, COL1) in the spec, and there are a few examples in the spec that start the upper left at (1, 1).
When we ran across this issue while writing libipuz we tried a few puzzles in puzzazz (the original implementation) to confirm that (0,0) was the intended origin coordinate. However, we have run across some implementations and puzzles in the wild starting at (1,1). This is going to be pretty painful to untangle, as they two interpretations are largely incompatible. We have a plan to detect the coordinate system being used, but it’ll be a rough heuristic at best until the spec gets clarified and revamped.
By the Numbers
With this release, I took a step back and took stock of my little project. The recent releases have seemed pretty substantial, and it’s worth doing a little introspection. As of this release, we’ve reached:
85KLOC total. 60KLOC in the app and 25KLOC in the library
Over 100 unencumbered puzzles in the base puzzle sets. This number needs to grow.
All in all, not too shabby, and not so little anymore.
A Final Request
Crosswords has an official flatpak, an unofficial snap, and Fedora and Arch packages. People have built it on Macs, and there’s even an APK that exists. However, there’s still no Debian package. That distro is not my world: I’m hoping someone out there will be inspired to package this project for us.
Implementing a variant type in C++ is challenging to say the least. I tried looking into the libstd++ implementation and could not even decipher where the actual data is stored. There is a lot of inheritance going on and helper classes that seem to be doing custom vtable construction and other metaprogramming stuff. The only thing I could truly grasp was a comment saying // "These go to eleven". Sadly there was not a comment // Smell my glove! which would seem more suitable for this occasion.
A modern stdlib does need a variant, though, so I had to implement one. To make it feasible I made the following simplifying assumptions.
All types handled must be noexcept default constructible, move constructible and movable. (i.e. the WellBehaved concept)
If you have a properly allocated and aligned piece of memory, placement new'ing into it works (there may be UB-shenanigans here due to the memory model)
The number of different types that a variant can hold has a predefined static maximum value.
You don't need to support any C++ version older than c++26.
The last one of these is the biggest hurdle, as C++26 will not be released for at least a year. GCC 15 does have support for it, though, so all code below only works with that.
The implementation
At its core, a Pystd variant is nothing more than a byte buffer and an index specifying which type it holds:
The functions to compute max size and alignment requirements for types are simple to implement. The main problem lies elsewhere, specifically: going from a type to the corresponding index, going from a compile time index value to a type and going from a runtime index to the corresponding type.
The middle one is the simplest of these. As of C++26 you can directly index the argument pack like so:
using nth_type = T...[compile_time_constant];
Going from type to an index is only slightly more difficult:
Going from a runtime value to a type is the difficult one. I don't know how to do it "correctly", i.e. the way a proper stdlib implementation does it. However, since the number of possible types is limited at compile time, we can cheat (currently only 5 types are supported):
Unrolling (type) loops like its 1988! This means you can't have variants with hundreds of different types, but in that case you probably need an architectural redesign rather than a more capable variant.
With these primitives implementing public class methods is fairly simple.
The end result
The variant implementation in Pystd and its helper code took approximately 200 lines of code. It handles all the basic stuff in addition to being exception safe for copy operations (implemented as copy to a local variable + move). Compile times remain in fractions of a second per file even though Pystd only has a single public header.
It works in the sense that you can put different types in to it, switch between them and so on without any compiler warnings, sanitizer issues or Valgrind complaints. So be careful with the code, I have only tested it, not proven it correct.
No performance optimization or even measurements have been made.
This Week in GNOME, and this entire month is dedicated to the joys and struggles of all two-spirit, lesbian, gay, bi, trans, queer, inter, pan, asexual, aromantic, and non-binary people.
We celebrate the invaluable work of all 2SLGBTQIA+ contributors and users, across all different backgrounds and experiences. As a special highlight this month and to feel proud all year round, we have worked together to create two new desktop backgrounds, released with GNOME 48.2.
If your distribution does not yet provide the new backgrounds, you can download them manually from here:
We can’t afford to stay silent in times when history is literally beingerased, and fundamental human rights are being revoked. Silence is complicity. We will not falter at this attempt to divide queer communities. We also encourage everyone to be as outspoken as they can be.
Never forget: We are stronger together.
In light of these circumstances it is especially encouraging to see the community of queer contributors growing steadily. We are here and we are not going anywhere - the GNOME community is and will always stand with queer people. We’ve got your back.
This summer we’re asking the question: What if we just started using GNOME OS as our primary OS?
It’s still early days for GNOME OS, but it’s finally ready for wider testing by developers and early adopters, on real hardware. Join us for a 3-month challenge from today until September 1st, file and fix some issues, and win a a OnePlus 6 with Linux Mobile or a limited-edition shirt 🌈👕
Heads-up: GTK changed GtkImage behavior when displaying GdkPaintable to strictly use the :pixel-size property and/or -gtk-icon-size CSS property instead of stretching the paintable to the allocated size.
The change is available in the nightly SDK and will be in GTK 4.19.2 and eventually in GNOME 49 SDK, but not in any stable releases/SDK. If your app relies on that (such as for displaying covers or avatars), it may need an update.
After months of technical debt cleanups, architectural changes, and small UX improvements, Papers has landed a considerable rework of the user interface for creating and editing annotations. New simplified shorcuts have been added, the number of clicks to create highlight (and similar type) annotations has been reduced, and it’s now possible to dynamically change color and annotation type just from the context menu! This has been a greatly requested feature and truly team work between all Papers maintainers: Qiu Wenbo, camelcasenick, lbaudin, and me, as well as other community member like our newest GSoC student Ahmed Fatthi. We hope you all enjoy it!
This past weeks I’ve implemented crash recovery in Apostrophe. If for some reason the application closes before a file has been properly saved or discarded, next time you open Apostrophe it’ll be restored. Then you’ll be able to save the changes, discard them or continue working in the file were you left.
I’m thrilled to announce the release of Bouncer! Bouncer is an application to help you choose the correct firewall zone for Wi-Fi networks. You may have seen other operating systems that, when you connect to a new Wi-Fi network, prompt for the type of network (e.g. home, public, work). That’s what Bouncer does. When you choose the network type, it is associated with that network and automatically used in the future. This can be useful to keep people from connecting to your laptop while using coffee shop Wi-Fi!
Check it out on Flathub! Please note that there may be additional setup steps beyond just installation. Details are on Flathub and in the README.
This week, I released a template for developing GNOME applications using TypeScript!
What makes this template unique? It leverages esbuild to transpile TypeScript code into JavaScript, offering several advantages: the ability to use TypeScript paths for absolute imports, direct support for importing .ui files in your code (similar to the functionality provided by gjspack), seamless integration of npm dependencies (as long as they don’t rely on Node.js or other runtimes), and support for modern syntax features like decorators.
In the future, I plan to develop a plugin for esbuild that will simplify the import of Blueprint files.
Crosswords 0.3.15 has been released (announcement)!
This is a quality-of-life release with a large number of bug fixes and improvements. It also includes the first version of the editor that can generate acrostic puzzles. You can download it at flathub, and it will be available in Fedora momentarily.
Highlights include:
Beta version of Acrostic editor
Use C-O to open files from everywhere in the game
Autodownload puzzle-sets on startup
Highlight the first letter of each clue answer for acrostics
Thumbnailer works with arrowwords
A cleaned up “Save As…” experience in the editor
Autofill selection vastly improved in the editor
Word list speedups and fixes
Barred puzzles render better
Dividers render correctly
Cell labels measure and layout text correctly
That last fix lets us display Arabic crosswords.
Happy Puzzling!
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!
As I wrote in my last post, Twitter's new encrypted DM infrastructure is pretty awful. But the amount of work required to make it somewhat better isn't large.
When Juicebox is used with HSMs, it supports encrypting the communication between the client and the backend. This is handled by generating a unique keypair for each HSM. The public key is provided to the client, while the private key remains within the HSM. Even if you can see the traffic sent to the HSM, it's encrypted using the Noise protocol and so the user's encrypted secret data can't be retrieved.
But this is only useful if you know that the public key corresponds to a private key in the HSM! Right now there's no way to know this, but there's worse - the client doesn't have the public key built into it, it's supplied as a response to an API request made to Twitter's servers. Even if the current keys are associated with the HSMs, Twitter could swap them out with ones that aren't, terminate the encrypted connection at their endpoint, and then fake your query to the HSM and get the encrypted data that way. Worse, this could be done for specific targeted users, without any indication to the user that this has happened, making it almost impossible to detect in general.
This is at least partially fixable. Twitter could prove to a third party that their Juicebox keys were generated in an HSM, and the key material could be moved into clients. This makes attacking individual users more difficult (the backdoor code would need to be shipped in the public client), but can't easily help with the website version[1] even if a framework exists to analyse the clients and verify that the correct public keys are in use.
It's still worse than Signal. Use Signal.
[1] Since they could still just serve backdoored Javascript to specific users. This is, unfortunately, kind of an inherent problem when it comes to web-based clients - we don't have good frameworks to detect whether the site itself is malicious.
(Edit: Twitter could improve this significantly with very few changes - I wrote about that here. It's unclear why they'd launch without doing that, since it entirely defeats the point of using HSMs)
When Twitter[1] launched encrypted DMs a couple of years ago, it was the worst kind of end-to-end encrypted - technically e2ee, but in a way that made it relatively easy for Twitter to inject new encryption keys and get everyone's messages anyway. It was also lacking a whole bunch of features such as "sending pictures", so the entire thing was largely a waste of time. But a couple of days ago, Elon announced the arrival of "XChat", a new encrypted message platform built on Rust with (Bitcoin style) encryption, whole new architecture. Maybe this time they've got it right?
tl;dr - no. Use Signal. Twitter can probably obtain your private keys, and admit that they can MITM you and have full access to your metadata.
The new approach is pretty similar to the old one in that it's based on pretty straightforward and well tested cryptographic primitives, but merely using good cryptography doesn't mean you end up with a good solution. This time they've pivoted away from using the underlying cryptographic primitives directly and into higher level abstractions, which is probably a good thing. They're using Libsodium's boxes for message encryption, which is, well, fine? It doesn't offer forward secrecy (if someone's private key is leaked then all existing messages can be decrypted) so it's a long way from the state of the art for a messaging client (Signal's had forward secrecy for over a decade!), but it's not inherently broken or anything. It is, however, written in C, not Rust[2].
That's about the extent of the good news. Twitter's old implementation involved clients generating keypairs and pushing the public key to Twitter. Each client (a physical device or a browser instance) had its own private key, and messages were simply encrypted to every public key associated with an account. This meant that new devices couldn't decrypt old messages, and also meant there was a maximum number of supported devices and terrible scaling issues and it was pretty bad. The new approach generates a keypair and then stores the private key using the Juicebox protocol. Other devices can then retrieve the private key.
Doesn't this mean Twitter has the private key? Well, no. There's a PIN involved, and the PIN is used to generate an encryption key. The stored copy of the private key is encrypted with that key, so if you don't know the PIN you can't decrypt the key. So we brute force the PIN, right? Juicebox actually protects against that - before the backend will hand over the encrypted key, you have to prove knowledge of the PIN to it (this is done in a clever way that doesn't directly reveal the PIN to the backend). If you ask for the key too many times while providing the wrong PIN, access is locked down.
But this is true only if the Juicebox backend is trustworthy. If the backend is controlled by someone untrustworthy[3] then they're going to be able to obtain the encrypted key material (even if it's in an HSM, they can simply watch what comes out of the HSM when the user authenticates if there's no validation of the HSM's keys). And now all they need is the PIN. Turning the PIN into an encryption key is done using the Argon2id key derivation function, using 32 iterations and a memory cost of 16MB (the Juicebox white paper says 16KB, but (a) that's laughably small and (b) the code says 16 * 1024 in an argument that takes kilobytes), which makes it computationally and moderately memory expensive to generate the encryption key used to decrypt the private key. How expensive? Well, on my (not very fast) laptop, that takes less than 0.2 seconds. How many attempts to I need to crack the PIN? Twitter's chosen to fix that to 4 digits, so a maximum of 10,000. You aren't going to need many machines running in parallel to bring this down to a very small amount of time, at which point private keys can, to a first approximation, be extracted at will.
Juicebox attempts to defend against this by supporting sharding your key over multiple backends, and only requiring a subset of those to recover the original. I can't find any evidence that Twitter's does seem to be making use of this,Twitter uses three backends and requires data from at least two, but all the backends used are under x.com so are presumably under Twitter's direct control. Trusting the keystore without needing to trust whoever's hosting it requires a trustworthy communications mechanism between the client and the keystore. If the device you're talking to can prove that it's an HSM that implements the attempt limiting protocol and has no other mechanism to export the data, this can be made to work. Signal makes use of something along these lines using Intel SGX for contact list and settings storage and recovery, and Google and Apple also have documentation about how they handle this in ways that make it difficult for them to obtain backed up key material. Twitter has no documentation of this, and as far as I can tell does nothing to prove that the backend is in any way trustworthy. (Edit to add: The Juicebox API does support authenticated communication between the client and the HSM, but that relies on you having some way to prove that the public key you're presented with corresponds to a private key that only exists in the HSM. Twitter gives you the public key whenever you communicate with them, so even if they've implemented this properly you can't prove they haven't made up a new key and MITMed you the next time you retrieve your key)
On the plus side, Juicebox is written in Rust, so Elon's not 100% wrong. Just mostly wrong.
But ok, at least you've got viable end-to-end encryption even if someone can put in some (not all that much, really) effort to obtain your private key and render it all pointless? Actually no, since you're still relying on the Twitter server to give you the public key of the other party and there's no out of band mechanism to do that or verify the authenticity of that public key at present. Twitter can simply give you a public key where they control the private key, decrypt the message, and then reencrypt it with the intended recipient's key and pass it on. The support page makes it clear that this is a known shortcoming and that it'll be fixed at some point, but they said that about the original encrypted DM support and it never was, so that's probably dependent on whether Elon gets distracted by something else again. And the server knows who and when you're messaging even if they haven't bothered to break your private key, so there's a lot of metadata leakage.
Signal doesn't have these shortcomings. Use Signal.
[1] I'll respect their name change once Elon respects his daughter
[2] There are implementations written in Rust, but Twitter's using the C one with these JNI bindings
[3] Or someone nominally trustworthy but who's been compelled to act against your interests - even if Elon were absolutely committed to protecting all his users, his overarching goals for Twitter require him to have legal presence in multiple jurisdictions that are not necessarily above placing employees in physical danger if there's a perception that they could obtain someone's encryption keys
Transparency report for July 2024 to May 2025 – GNOME Code of Conduct Committee
GNOME’s Code of Conduct is our community’s shared standard of behavior for participants in GNOME. This is the Code of Conduct Committee’s periodic summary report of its activities from July 2024 to May 2025.
The current members of the CoC Committee are:
Anisa Kuci
Carlos Garnacho
Christopher Davis
Federico Mena Quintero
Michael Downey
Rosanna Yuen
All the members of the CoC Committee have completed Code of Conduct Incident Response training provided by Otter Tech, and are professionally trained to handle incident reports in GNOME community events.
Since July 2024, the committee has received reports on a total of 19 possible incidents. Of these, 9 incidents were determined to be actionable by the committee, and were further resolved during the reporting period.
Report about an individual in a GNOME Matrix room acting rudely toward others. A Committee representative discussed the issue with the reported individual and adjusted room permissions.
Report about an individual acting in a hostile manner toward a new GNOME contributor in a community channel. A Committee representative contacted the reported person to provide a warning and to suggest methods of friendlier engagement.
Report about a discussion on a community channel that had turned heated. After going through the referenced conversation, the Committee noted that all participants were using non-friendly language and that the turning point in the conversation was a disagreement over a moderator’s action. The committee contacted the moderator and reminded them to use kinder words in the future.
Report related to technical topics out of the scope of the CoC committee. The issue was forwarded to the Board of Directors.
Report about members’ replies in community channels; after reviewing the conversation the CoC committee decided that it was not actionable. The conversation did not violate the Code of Conduct.
Report about inappropriate and insulting comments made by a member in social moments during an offline event. The CoC Committee sent a warning to the reported person.
Report against two members making comments the reporter considered disrespectful in a community channel. After reading through the conversation, the Committee did not see any violations to the CoC. No actions were taken.
Report on someone using abrasive and aggressive language in a community channel. After reading the conversation, the Committee agrees with this assessment. As this person had previously been found to have violated the CoC, the Committee has banned the person from the channel for one month.
Report about ableist language in a GitLab merge request. The reported person was given warning not to use such language.
Report against GNOME in general without any specifics. A request for more information was sent, and after no reply after a number of months, the issue has been closed with no action.
Report against the moderating team’s efforts to keep discussions within the Code of Conduct. No action was taken.
Report about a contributor being aggressive to the reporter who is working with them, on multiple occasions. The CoC committee talked both to the reporter and the reported person, and also to other people working with them in order to solve the disagreements. The result was that the reporter had some patterns on their behavior that made it difficult to collaborate with them too. The conclusion was that all parties acknowledged their wrong behaviors and will work on improving that and be more collaborative.
Report about a disagreement with a maintainer’s decision. The report was non-actionable.
Report about a contributor who set up harassment campaigns against Foundation and non-Foundation members. This person has been suspended indefinitely from participation in GNOME.
Report about a moderator being hostile in community channels; this was not the first report we received about this member so they got banned from the channel.
Report about a blog syndicated in planet.gnome.org. The committee evaluated the blog in question and found it not to contravene the CoC, so it took no action afterwards.
Five reports, unrelated to each other, with technical support requests. These were marked as not actionable.
Report with a general comment about GNOME, marked as not actionable.
A question about where to report security issues; informed the reporter about security@gnome.org.
Changes to the CoC Committee procedures
The Foundation’s Executive Director commissioned an external review of the CoC Committee’s procedures in October of 2024. After discussion with the Foundation Board of Directors, we have made the following changes to the committee procedures:
Establish a “chain of command” for requesting tasks to be performed by sysadmins after an incident report.
Clarify the procedures for notifying affected people and teams or committees after a report.
Clarify the way notifications are made about a report’s consequences, and update the Committee’s communications infrastructure in general.
Specify how to handle reports related to Foundation staff or contractors.
The history of changes can be seen in this merge request to the repository for the Code of Conduct.
CoC Committee blog
We have a new blog at https://conduct.gnome.org/blog/, where you can read this transparency report. In the future, we hope to post materials about dealing with interpersonal conflict, non-violent communication, and other ideas to help the GNOME community.
Meetings of the CoC committee
The CoC committee has two meetings each month for general updates, and weekly ad-hoc meetings when they receive reports. There are also in-person meetings during GNOME events.
Ways to contact the CoC committee
https://conduct.gnome.org – contains the GNOME Code of Conduct and a reporting form.
conduct@gnome.org – incident reports, questions, etc.
I apologize that I’m a little late updating my blog, but over the past two weeks, I’ve been diving into Vala’s compiler and exploring how JSON (de)serialization could be integrated. My mentor, Lorenz, and I agreed that focusing on JSON is a good beginning.
Understanding the Vala Compiler
Learning the steps it takes to go from Vala code to C code is absolutely fascinating.
Vala’s Compiler 101
The first step in the compiler is the lexical analysis. This is handled by valascanner.vala, where your Vala code gets tokenized, which breaks up your code into chunks called tokens that are easier for the compiler to understand.
switch (begin[0]) {
case 'f':
if (matches (begin, "for")) return TokenType.FOR;
break;
case 'g':
if (matches (begin, "get")) return TokenType.GET;
break;
</pre>
The code above is a snippet of Vala's scanner, it's responsible for recognizing specific keywords like 'for' and 'get' and returning the appropriate token type.
Next is syntax analysis and the creation of the abstract syntax tree (AST). In Vala, it’s managed by valaparser.vala, which checks if your code structure is correct, for example, if that pesky ‘}’ is missing.
inline bool expect (TokenType type) throws ParseError {
if (accept (type)) {
return true;
}
switch (type) {
case TokenType.CLOSE_BRACE:
safe_prev ();
report_parse_error (new ParseError.SYNTAX ("following block delimiter %s missing", type.to_string ()));
return true;
case TokenType.CLOSE_BRACKET:
case TokenType.CLOSE_PARENS:
case TokenType.SEMICOLON:
safe_prev ();
report_parse_error (new ParseError.SYNTAX ("following expression/statement delimiter %s missing", type.to_string ()));
return true;
default:
throw new ParseError.SYNTAX ("expected %s", type.to_string ());
}
}
</pre>
This is a snippet of Vala's parser, it tries to accept a specific token type, like again that '}'. If '}' is there, it continues parsing. Else if not, it throws a syntax error.
Then comes semantic analysis, the “meat and logic,” as I like to call it. This happens in valasemanticanalyzer.vala, where the compiler checks if things make sense. Do the types match? Are you using the correct number of parameters?
public bool is_in_constructor () {
unowned Symbol? sym = current_symbol;
while (sym != null) {
if (sym is Constructor) {
return true;
}
sym = sym.parent_symbol;
}
return false;
}
</pre>
This code is a snippet of Vala's semantic analyzer, which helps the compiler understand if the current code is a constructor. Starting from the current symbol, which represents where the compiler is in the code, it then moves through its parent symbols. If it finds a parent symbol that is a constructor, it returns true. Else if the parent symbol is null, it returns false.
After that, the flow analysis phase, located in valaflowanalyzer.vala, analyzes the execution order of the code. It figures out how control flows through the program, which is useful for things like variable initialization and unreachable code.
public override void visit_lambda_expression (LambdaExpression le) {
var old_current_block = current_block;
var old_unreachable_reported = unreachable_reported;
var old_jump_stack = jump_stack;
mark_unreachable ();
jump_stack = new ArrayList ();
le.accept_children (this);
current_block = old_current_block;
unreachable_reported = old_unreachable_reported;
jump_stack = old_jump_stack;
}
</pre></code>
The snippet of Vala's flow analyzer ensures that control flow, like unreachable code or jump statements, is properly analyzed within the lambda expression.
After all that, we now want to convert the Vala code into C code using a variety of Vala files in the directories ccode and codegen.
All of these classes inherit from valacodevisitor.vala, which is basically the mother of classes that provides the visit_* methods that allow each phase in the compiler to walk the source code tree.
I know this brief isn’t all of what there is to understand about the compiler, but it’s a start. Also, let’s take a moment to appreciate everyone who has contributed to Vala’s compiler design, it’s truly an art 🎨
The Coding Period Begins!!!
Now that GSoC’s official coding period is here, I’m continuing my research on how to implement JSON support.
Right now, I’m still learning the codegen phase AKA the phase of converting vala into C, I’m exploring json glib and starting to work on a valajsonmodule.vala in the code gen.
Another thing I want to work on is the Vala docs. The docs aren’t bad, but I’ve realized the information is pretty limited the deeper you get into the compiler.
I’m excited that this is starting to slowly make sense, little by little.
Nowadays XDG Desktop Portal plays an important part in interaction between apps and the system, providing much needed security and unifying the experience, regardless of the desktop environment or toolkit you're using. While one could say it was created for sandboxed Flatpak apps, portals could bring major advantages to unsandboxed, host apps as well:
- Writing universal code: you don't need to care about writing desktop-specific code, as different desktops and toolkits will provide their own implementations
- Respecting the privacy of the user: portals use a permission system, which can be granted, revoked and controlled by the user. While host apps could bypass them, user can still be presented with dialogs, which will ask for permission to perform certain actions or obtain information.
Okay, so they seem like a good idea after all. Now, how do we use them?
More often than not, you don't actually have to manually call the D-Bus API - for many of the portals, toolkits and desktop will interact with them on your behalf, exposing easy to use high-level APIs. For example, if you're developing an app using GTK4 on GNOME and want to inhibit suspend or logout, you would call gtk_application_inhibit which will actually prefer using the Inhibit portal over directly talking to gnome-session-manager. There are also convenience libraries to help you, available for different programming languages.
That sounds easy, is that all? Unfortunately, there are some caveats.
The fact that we can safely say that flatpaks are first-class citizen when interacting with portals, compared to host apps, is a good thing - they offer many benefits, and we should embrace them. However, in the real world there are many instances of apps installed without sandbox, and the transition will take time, so in the meantime we need to make sure they play correctly with portals as well.
One such instance is the getting the information about the app - in flatpak land, it's obtained from a special .flatpak-info file located in the sandbox. In the host apps though, xdg-desktop-portal tries to parse the app id from the systemd unit name, only accepting "app-" prefixed format, specified in the XDG standardization for applications. This works for some applications, but unfortunately not all, at least at this time. One such example is D-Bus activated apps, which are started with "dbus-" prefixed systemd unit name, or the ones started from the terminal with even different prefixes. In all those cases, the app id exposed to the portal is empty.
One major problem, when xdg-desktop-portal doesn't have access to the app-id, is undoubtedly failure of inhibiting logout/suspend when using the Inhibit portal. Applications on GNOME using GTK4 will call gtk_application_inhibit, which in turn calls xdg-desktop-portal-gtk inhibit portal implementation, which finally talks to the gnome-session-manager D-Bus API. However, it requires app-id to function correctly, and will not inhibit the session without it. The situation should get better in the next release of gnome-session but it could still cause problems for the user, not knowing the name of the application that is preventing logout/suspend.
Moreover, while not as critical, other portals also rely on that information in some way. Account portal used for obtaining the information about the user will mention the app display name when asking for confirmation, otherwise will call it the "requesting app", which the user may not recognize, and is more likely to cancel. Location portal will do the same, and Background portal won't allow autostart if it's requested.
GNOME Shell logout dialog when Nautilus is copying files, inhibiting indirectly via portal
How can we make sure our host apps play well with portals?
Fortunately, there are many ways to make sure your host app interacts correctly with portals. First and foremost, you should always try to follow the XDG cgroup pathname standardization for applications. Most desktop environments already follow the standard, and if they don't, you should definitely report it as a bug. There are some exceptions, however - D-Bus activated apps are started by the D-Bus message bus implementations on behalf of desktops, and currently they don't put the app in the correct systemd unit. There is an effort to fix that on the dbus-broker side, but these things take time, and there is also the case of apps started from the terminal, which have different unit names altogether.
When for some reason your app was launched in a way that doesn't follow the standard, you can use the special interface for registering with XDG Desktop Portal, the host app Registry, which overwrites the automatic detection. It should be considered a temporary solution, as it is expected to be eventually deprecated (with the details of the replacement specified in the documentation), nevertheless it lets us fix the problem at present. Some toolkits, like GTK, will register the application for you, during the GtkApplication startup call.
There is one caveat, though - it needs to be the first call to the portal, otherwise it will not overwrite the automatic detection. This means that when relying on GTK to handle the registration, you need to make sure you don't interact with the portal before the GtkApplication startup chain-up call. So no more gtk_init in main.c, which on Wayland uses Settings portal to open display, all such code needs to be moved just after the application startup chain-up. If for some reason you really cannot do that, you'll have to call the D-Bus method yourself, before any portal interaction is made.
The end is never the end...
If you made it this far, congratulations and thanks for taking this rabbit hole with me. If it's still not enough, you can check out the ticket I reported and worked on in nautilus, giving even more context to how we ended up here. Hope you learned something that will make your app better :)
Today marks the end of the community bonding period, and the start of the coding period, of GSoC.
In the last two weeks, I’ve been looking into other crossword editors that are on the market, in order to see what features they have that we should implement. I compiled everything I saw into a findings document.
Once that was done, I went through the document and distilled it down into a final list. I also added other feature ideas that I already had in mind.
Eventually, through a discussion with my mentor, we decided that I should start by tackling a bug that I found. This will help me get more familiar with the fill algorithm code, and it will inform my decisions going forward, in terms of what features I should work on.
So far, GNOME OS has mostly been used for testing in virtual machines, but what if you could just use it as your primary OS on real hardware?
Turns out you can!
While it’s still early days and it’s not recommended for non-technical audiences, GNOME OS is now ready for developers and early adopters who know how to deal with occasional bugs (and importantly, file those bugs when they occur).
The Challenge
To get GNOME OS to the next stage we need a lot more hardware testing. This is why this summer (June, July, and August) we’re launching a GNOME OS daily-driving challenge. This is how it works:
10 points for daily driving GNOME OS on your primary computer for at least 4 weeks
1 point for every (valid, non-duplicate) issue created
You can sign up for the challenge and claim points by adding yourself to the list of participants on the Hedgedoc. As the challenge progresses, add any issues and MRs you opened to the list.
The person with the most points on September 1 will receive a OnePlus 6 (running postmarketOS, unless someone gets GNOME OS to work on it by then). The three people with the most points on September 1 (noon UTC) will receive a limited-edition shirt (stay tuned for designs!).
Using GNOME OS Nightly means you’re running the latest latest main for all of our projects. This means you get all the dope new features as they land, months before they hit Fedora Rawhide et al.
For GNOME contributors that’s especially valuable because it allows for easy testing of things that are annoying/impossible to try in a VM or nested session (e.g. notifications or touch input). For feature branches there’s also the possibility to install a sysext of a development branch for system components, making it easy to try things out before they’ve even landed.
More people daily driving Nightly has huge benefits for the ecosystem, because it allows for catching issues early in the cycle, while they’re still easy to fix.
Is my device supported?
Most laptops from the past 5 years are probably fine, especially Thinkpads. The most important specs you need are UEFI and if you want to test the TPM security features you need a semi-recent TPM (any Windows 11 laptop should have that). If you’re not sure, ask in the GNOME OS channel.
Does $APP work on GNOME OS?
Anything available as a Flatpak works fine. For other things, you’ll have to build a sysext.
Generally we’re interested in collecting use cases that Flatpak doesn’t cover currently. One of the goals for this initiative is finding both short-term workarounds and long-term solutions for those cases.
GNOME OS uses systemd-sysupdate for updating the system, which doesn’t yet support delta updates. This means you have to download a new 2GB image from scratch for every update, which might be an issue if you don’t have regular access to a fast internet connection.
The current installer is temporary, so it’s missing many features we’ll have in the real installer, and the UI isn’t very polished.
Anything else I should know before trying to install GNOME OS?
Update the device’s firmware, including the TPM’s firmware, before nuking the Windows install the computer came with (I’m speaking from experience)!
My first two books were written online using Pressbooks in a browser. A change in the company’s pricing model prompted me to migrate another edition of the second book to LaTeX. Many enjoyable hours were spent searching online for how to implement everything from the basics to special effects. After a year and a half a nearly finished book suddenly congealed.
Here’s what I’m using: Fedora’s TeX Live stack, Emacs (with AUCTeX and the memoir class), Evince, and the Citations flatpak, all on a GNOME desktop. The cover of the first book was done professionally by a friend. For the second book (first and second editions) I’ve used the GNU Image Manipulation Program.
For print on demand, Lulu.com. The company was founded by Bob Young, who (among other achievements) rejuvenated a local football team, coincidentally my dad’s (for nearly 80 years and counting). Lulu was one of the options recommended by Adam Hyde at the end of the Mallard book sprint hosted by Google. Our book didn’t get printed in time to take home, so I uploaded it to Lulu and ordered a few copies with great results. My second book is also on Amazon’s KDP under another ISBN; I’m debating whether to do that again.
Does this all need to be done from GNOME? For me, yes. The short answer came from Richard Schwarting on the occasion of our Boston Summit road trip: “GNOME makes me happy.”
The long answer…
In my career working as a CAD designer in engineering, I’ve used various products by Autodesk (among others). I lived through the AutoCAD-MicroStation war of the 1990s on the side of MicroStation (using AutoCAD when necessary). MicroStation brought elegance to the battle, basing their PC and UNIX ports on their revolutionary new Mac interface. They produced a student version for Linux. After Windows 95 the war was over and mediocrity won.
Our first home computer was an SGI Indy, purchased right in the middle of that CAD war. Having experienced MicroStation on IRIX I can say it’s like running GNOME on a PC: elegant if not exquisite compared to the alternative.
For ten years I was the IT guy at a small engineering company. While carrying out my insidious plan of installing Linux servers and routers, I was able to indulge certain pastimes, building and testing XEmacs (formerly Lucid Emacs) and fledgling GNOME on Debian unstable/experimental. Through the SGI Linux effort I got to meet online acquaintances from Sweden, Mexico, and Germany in person at Ottawa Linux Symposium and Debconf .
At the peak of my IT endeavours, I was reading email in Evolution from OpenXchange Server on SuSE Enterprise Server while serving a Windows workstation network with Samba. When we were acquired by a much larger company, my Linux servers met with expedient demise as we were absorbed into their global Windows Server network. The IT department was regionalized and I was promoted back into the engineering side of things. It was after that I encountered the docs team.
These days I’m compelled to keep Windows in a Box on my GNOME desktop in order to run Autodesk software. It’s not unusual for me to grind my teeth while I’m working. A month ago a surprise hiatus in my day job was announced, giving me time to enjoy GNOME, finish the book, and write a blog post.
So yes, it has to be GNOME.
In 2004 I used LaTeX in XEmacs to write a magazine article that was ultimately published in the UK. This week, for old times’ sake, I installed XEmacs (no longer packaged for Fedora) on my desktop. This requires an EPEL 8 package on CentOS 9 in Boxes. It can be seen in the screenshot. The syntax highlighting is real but LaTeX-mode isn’t quite operational yet.
After some discussion about where to announce our Pride Month celebrations, I’ve decided it might be easiest to do it on my own blog. It’s a little more personal that way. And if I say something silly or out of turn, it’s on me.
Let me begin by trying to explain why Pride feels particularly important in the world of Free Software.
Free Software Is Inclusive
GNOME is a weird project. It’s not a household name, like Linux. Nor is it a shrinkwrapped brand, like Red Hat, SUSE, or Ubuntu. But it is a massive, collective software project that includes many different components under its umbrella.
What binds all these interconnected projects together if not a brand and not a singular BDFL technical vision? It is the founding principle and vision for the project: everyone should be allowed in. To use GNOME, to modify GNOME, and to collaborate on GNOME.
GNOME has more active threads of contribution than any one person could possibly follow and more active users than we could possibly count. So this simple mission of making a desktop that includes everyone is actually a lot harder than it seems. Will it run on a 14-year-old Chromebook? Perhaps that’s the only computer someone has access to. Is it translated into Farsi? Perhaps that’s the only language the user reads. “Everyone” is a lot of people — and the world is a big place.
Pride Is Inclusive
Far be it from me to equate the mission of an open source project with that of a worldwide civil rights movement. But Pride carries a very similar message: everyone is allowed in. Everyone should be allowed into a country or city or business. Everyone is allowed to be themselves.
I’m very fortunate. I live in Halifax. It is, as far as I can tell, the Gayest City in Canada. Year-round, the Pride flag hangs from our bridges, is painted on crosswalks, and fills storefront windows. The rainbow adorns backpacks, laptops, skateboards, cars, and checkout counters. On an individual level, the Pride flag is a symbol of safety: “I promise you’re safe with me.” On a societal level, it’s an invitation: “You are welcome here.”
I know that not everyone is this lucky.
Pride Is Not The Same Everywhere
Pride is a celebration of how far the community has come. The 1970s and 1980s feel far away and the decades-long fight for liberation (in countries where liberation has begun) provides us with the history and war stories we all benefit from today.
But GNOME is global. And for many in the global 2SLGBTQIA+ (queer) community, the war is ongoing. Or it’s barely even begun. In some countries, members of the community are shunned, silenced, ostracized, harmed, or killed. Most of us know someone who didn’t survive.
We also need to demonstrate support for everyone because no one is safe simply because they live in a city filled with rainbow flags. Many of us still struggle with our identity and our place in society, no matter where we live.
And so Pride is bittersweet: a celebration of the freedom Pride represents but also an awareness of the dangers that continue to exist.
A Request To The Foundation
While discussing Pride preparations, there was a simple request, addressing these dangers, from one queer Foundation Member: “We just want to know you have our back.”
To all GNOME’s queer users and contributors: absolutely, the Foundation has your back. Not just this June, but always.
May everyone enjoy a peaceful and joyful Pride Month!
(Special thanks to Laura Kramolis for her thoughtful feedback and guidance while writing this post.)
In my first two weeks as an Outreachy intern with GNOME, I’ve been getting familiar with the project I’ll be contributing to and settling into a rhythm with my mentor, Jonathan Blandford. We’ve agreed to meet every Monday to review the past week and plan goals for the next — something I’ve already found incredibly grounding and helpful.
What I’m Working On: The Word Score Project
My project revolves around improving how GNOME’s crossword tools (like GNOME Crosswords) assess and rank words. This is part of a larger effort to support puzzle constructors by helping them pick better words for their grids — ones that are fun, fresh, and fair.
But what makes a “good” crossword word?
This is what the Word Score project aims to answer. It proposes a scoring system that assigns numerical values to words based on multiple measurable traits, such as:
Lexical interest (e.g. does it contain unusual bigrams/trigrams like “KN” or “OXC”?),
Frequency in natural language (based on datasets like Google Ngrams),
Familiarity to solvers (which may differ from frequency),
Definition count (some words like SET or RUN are goldmines for cryptic clues),
Sentiment and appropriateness (nobody wants a vulgar word in a breakfast puzzle).
The goal is to build a system that supports both the autofill functionality and the word list interface in GNOME Crosswords, giving human setters better tools while respecting editorial judgment. In other words, this project isn’t about replacing setters — it’s about enhancing their toolkit.
You can read more about the project’s goals and philosophy in our draft document: Thoughts on Scoring Words (final link coming soon).
Week 1: Building and Breaking Puzzles
During my first week, I spent time getting familiar with the project environment and experimenting with crossword puzzle generation. I created test puzzles to better understand how word placement, scoring, and validation work under the hood.
This hands-on experimentation helped me form a clearer mental model of how GNOME Crosswords structures and fills puzzles — and why scoring matters. The way words interact in a grid can make some fills elegant and others feel forced or unplayable.
Week 2: Wrestling with libipuz and Introspection
In the second week, my focus shifted to working on libipuz, a C library that parses and exports puzzles using the IPUZ format. but getting libipuz working with GNOME’s introspection system proved more challenging than expected.
Initially, I tried to use it inside the crosswords container, but it wasn’t cooperating. After some digging (and rebuilding), we decided to create a separate container specifically for libipuz to enable introspection and allow scripting in languages like Python and JavaScript to interact with it.
This also gave me a deeper understanding of how GNOME handles language bindings via GObject Introspection — something I hadn’t worked with before, but I’m quickly getting the hang of.
Bonus: Scrabble-Inspired Scoring Script
As a side exploration, I also wrote a quick Python script that calculates Scrabble-style scores for words. While Scrabble scoring isn’t the same as what we want in crosswords (it values rare letters like Z and Q), it gave me a fun way to experiment with scoring mechanics and visualize how simple rules change the ranking of word lists. This mini-project helped me warm up to the idea of building more complex scoring systems later on.
What’s Next?
In the coming weeks, I’ll continue refining the scoring dimensions, writing more scripts to calculate traits (especially frequency and lexical interest), and exploring how this scoring system can be surfaced in GNOME Crosswords. I’m excited to see how this evolves — and even more excited to share updates as I go.
The first two weeks of my Google Summer of Code (GSoC) journey with GNOME Papers have been both exciting and productive. I had the opportunity to meet my mentors, discuss the project goals, and dive into my first major task: improving the way document mutex locks are handled in the codebase.
🤝 Mentor Meeting & Planning
We kicked off with a meeting to get to know each other and to discuss the open Merge Request 499. The MR focuses on moving document mutex locks from the libview/shell layer down to the individual backends (DjVu, PDF, TIFF, Comics). We also outlined the remaining work and clarified how to approach it for the best results.
When Signal introduced Stories, I didn't understand why. To me, Signal is all about giving as little information to as few people as possible but still being able to have a social life.
I didn't use any app that had stories. Only a few friends published Instagram stories, and many more followed public stories. I thought of stories as "broadcast content to as many people as possible," which is the opposite of what Signal is about for me.
It turns out I was wrong. Signal lets you curate who can see your stories. By default, all your contacts can see your stories, but you can also create smaller circles of people who will see them, or you can create stories from existing Signal groups.
Since I've realized that social media like Mastodon affect me more (negatively) than I thought, I've significantly reduced what I read and publish there. But I still want to share happy moments with friends. So, I gave Signal stories a go, and it has been more fun and useful than I thought.
When I publish a story on Signal, I know who will read it. It's not for the public, but it's for friends. I can publish more personal things, and people reply more genuinely. Friends ask where I am or how I'm doing at the moment. We listen to each other. And, to my great satisfaction, a few friends have started publishing stories since I started!
I also publish different things on Signal stories than on Mastodon. On Mastodon, I shared thoughts or, let's be honest, hot takes. On Signal, I share moments. I share what I do and experience, not necessarily what I think.
The UX is still a bit clunky, stories feel poorly integrated into Signal, and I don't understand why Signal broadcasts stories to your whole address book by default. But I enjoy having a place where I can share privately and spontaneously what I'm doing with a short list of people I trust and care about.
[!info] Signal is good tech, help them
If you've never tried Signal stories, I strongly encourage you to do so. If you use Signal and can afford it, consider supporting them financially; they deserve it.
Keep up the good work, Signal. You're an excellent app and a great nonprofit, and I wish more organizations took inspiration from you.
Continuing our volunteer effort to make GNOME Calendar fully accessible with a keyboard, we fixed a major bug that was causing the focus to disappear into the abyss when the user tried to tab into the month view in merge request !576. This means, as of this commit, events should now be completely functional and accessible within the month view. Additionally, the merge request changes the keyboard and focus behavior within the month view: Events can only be cycled using arrow buttons, the focus can’t escape the month view with arrow buttons, and entering/exiting the month view can only be done with tab. These improvements will be available on GNOME 49.
This cycle GNOME Web received tremendous new features and bug fixes. I took the chance and started to work on our bug
list and squashed over 100 bugs and added several new features. Among those are:
UI files switched to blueprint format
Adblocker now tries to load locale specific adblocker list in addition to the default one
URL bar received an inline completion
URL bar is now on bottom in narrow mode
Bottom action bar hides and reveals automatically in narrow mode
Reader mode got an estimated reading time based on Firefox implementation
PKCS #11 (smartcard) persistence support
Moved passwords from preferences to it’s own dialog
Security popover has been replaced with an adaptive dialog
WebApp additional URL handling has been changed and thus base domains are now compared instead of full domains
Ability to quit and uninstall web apps from their menu
Search now handles case sensitive and full word searches
Mute button in URL bar for single tab pages
Background portal support
Bookmark editing mode (Arak)
Thanks to Jamie, Arak and kramo for their support and fixes. We are going to deliver one of the best releases.
The first public version of Gradia was released this Sunday.
Gradia is designed to improve the presentation of your screenshots on platforms where you have limited control, such as social media. It allows you to add a custom gradient background, add padding, change the aspect ratio, and more.
The app is designed for quick edits of mostly screenshots and does not aim to be a full-fledged image editor. However, I do have aspirations to add simple annotation features like a freehand pen mode and an arrow drawing tool.
Hello everyone! This week, at ALT Gnome and ALT Linux Team, we are introducing Folder Manager — a folder manager for the GNOME and Phosh application menu, designed to simplify and automate the organization of applications into folders by category.
Folder Manager is a convenient utility for managing app folders in GNOME and Phosh. Built with Vala using GTK4 and Libadwaita, it adheres to GNOME HIG guidelines and ensures a clean and modern interface for application menu organization.
Key Features:
Create and Delete Folders: Instantly create, rename, or delete application folders through a user-friendly graphical interface.
Category-Based Autofill: When creating a folder, select a category (e.g. Office, Chat, Games), and Folder Manager will automatically include all applications belonging to that category.
Manual Management: Add or remove individual applications from folders manually, for precise control over organization.
Filtering and Search: Easily locate applications by name using built-in search and filtering tools within the interface.
Designed for GNOME and Phosh: Provides full compatibility with both GNOME Shell and the mobile-oriented Phosh environment.
Folder Manager helps keep your application menu organized, improves accessibility, and enhances your desktop experience. Try it today and bring structure and clarity to your GNOME workspace!
Packet is an app that lets you send and receive files wirelessly from Android devices using Quick Share, or another device with Packet.
It just received an update! The status indicator now shows the connection state, the in-app help has been rewritten to be easier to understand, and an error page is shown if the app can’t run, so it’s easier to troubleshoot. This update also brings lots of smaller under-the-hood improvements and fixes.
Newelle, AI assistant for Gnome, got updated to 0.9.7, improving local documents reading performances, adding thinking support for Gemini models, other minor improvements and updated translations
Versions 2.2.3 and 2.3.0 of Pipeline were released. Pipeline now hides videos which require payment by default from the feed, as those cannot yet be played using Pipeline anyway. If you want them to keep showing up because you are using an external player which supports those, you can change the behavior in the filter settings. If you are using an external player, you can now spawn it again in case it failed by clicking the thumbnail of the video, instead of needing to go back to the feed and clicking the video again. Startup performance of Pipeline also got significantly improved, on my device from over 3s to under 1s. Finally, the releases fix quite a few bugs:
Videos sometimes being duplicated in the watch-later list.
Videos starting to play with low resolution.
Error searching when the result contains videos with over 2 billion views.
Errors fetching information for a single video for some videos.
We’ve started a Farsi-language podcast version of This Week in GNOME! Each week we read and summarize the latest TWIG post in Farsi, covering GNOME Core updates, Circle apps, and community news. The goal is to help Farsi-speaking users stay connected with the GNOME ecosystem.
We’ve released 3 episodes so far (199, 200, 201) and keep episode scripts + audio files on GitHub. You can listen on Spotify, Castbox, Podcast Index, or via RSS feed.
Ahmed Fatthi started his GSoC internship in Papers getting a complex work related to locking merged! Ahmed will be working on isolating documents, so that eventually Papers can be as secure managing documents as Loupe is managing images! Keep posted to his blog for more updates: https://ahmedfatthi.pages.dev/
Previously it was mentioned that Python and C++ do iteration quite differently. Python has "statefull" objects that have a .next() method that returns a new object or throws a StopIteration exception. Incidentally Rust does exactly the same thing, except that it uses an optional type rather than an exception. C++ does not work like this, instead it has a concept of a "start" and "end" of a sequence and the machinery keeps incrementing the start until it reaches the end.
At the end of last post it was said that it is difficult to integrate an object of the former type with C++'s native language facilities, at least without macros.
Now we'll look how to integrate an object of the former type with C++'s native language facilities without any macros.
In fact, it only took fewer than 30 lines of code to do. The caveat being that it is probably fairly easy to break it. But it works for me.
Here it is being used.
There is also a second, similar helper class that takes ownership of the object being iterated over.
Hi, we’ve started a new project: a Farsi-language podcast version of This Week in GNOME.
Each week, we read and summarise the latest TWIG post in Farsi, covering updates from GNOME Core, GNOME Circle apps, and other community-related news. Our goal is to help Persian-speaking users and contributors stay connected with the GNOME ecosystem.
The podcast is hosted by me (Revisto), along with Mirsobhan and Hadi. We release one short episode per week.
Since I also make music, I created a short theme for the podcast to give it more identity and consistency across episodes. It’s simple, but it adds a nice touch of production value that we hope makes the podcast feel more polished.
We’re also keeping a GitHub repository in which I’m uploading each of my episode scripts (in Farsi) in Markdown + audio files. The logo and banner assets have been uploaded in SVG as well for transparency.
Thanks to the work of Christian Gmeiner, support for annotating time regions using Sysprof marks has landed in Mesa.
That means you’ll be able to open captures with Sysprof and see the data along other useful information including callgraphs and flamegraphs.
I do think there is a lot more we can do around better visualizations in Sysprof. If that is something you’re interested in working on please stop by #gnome-hackers on Libera.chat or drop me an email and I can find things for you to work on.
I'm happy to share that 3 major IPU6 camera related kernel changes from linux-next have been backported to Fedora and have been available for about a week now the Fedora kernel-6.14.6-300.fc42 (or later) package:
Support for the OV02C10 camera sensor, this should e.g. enable the camera to work out of the box on all Dell XPS 9x40 models.
Support for the OV02E10 camera sensor, this should e.g. enable the camera to work out of the box on Dell Precision 5690 laptops. When combined with item 3. below and the USBIO drivers from rpmfusion this should also e.g. enable the camera on other laptop models like e.g. the Dell Latitude 7450.
Support for the special handshake GPIO used to turn on the sensor and allow sensor i2c-access on various new laptop models using the Lattice MIPI aggregator FPGA / USBIO chip.
If you want to give this a test using the libcamera-softwareISP FOSS stack, run the following commands:
Note the colors being washed out and/or the image possibly being a bit over or under exposed is expected behavior ATM, this is due to the software ISP needing more work to improve the image quality. If your camera still does not work after these changes and you've not filed a bug for this camera already please file a bug following these instructions.
See my previous blogpost on how to also test Intel's proprietary stack from rpmfusion if you also have that installed.
Since the set of rpmfusion intel-ipu6-kmod + ipu6-camera-* package updates from last February the FOSS libcamera-softwareISP and Intel's proprietary stack using the Intel hardware ISP can now co-exist on Fedora systems, sharing the mainline IPU6-CSI2 receiver driver.
Because of this it is no longer necessary to blacklist the kernel-modules from the other stack. Unfortunately when the rpmfusion packages first generated "/etc/modprobe.d/ipu6-driver-select.conf" for blacklisting this file was not marked as "%ghost" in the specfile and now with the February ipu6-camera-hal the file has been removed from the package. This means that if you've jumped from an old ipu6-camera-hal where the file was not marked as "%ghost directly to the latest you may still have the modprobe.d conf file around causing issues. To fix this run:
and then reboot. I'll also add this as post-install script to the ipu6-camera-hal packages, to fix systems being broken because of this.
If you want the rpmfusion packages because your system needs the USBIO drivers, but you do not want the proprietary stack, you can run the following command to disable the proprietary stack:
sudo ipu6-driver-select foss
Or if you have disabled the prorietary stack in the past and want to give it a try, run:
sudo ipu6-driver-select proprietary
To test switching between the 2 stacks in Firefox go to Mozilla's webrtc test page and click on the "Camera" button, you should now get a camera permisson dialog with 2 cameras: "Built in Front Camera" and "Intel MIPI Camera (V4L2)" the "Built in Front Camera" is the FOSS stack and the "Intel MIPI Camera (V4L2)" is the proprietary stack. Note the FOSS stack will show a strongly zoomed in (cropped) image, this is caused by the GUM test-page, in e.g. google-meet this will not be the case.
Unfortunately switching between the 2 cameras in jitsi does not work well. The jitsi camera selector tries to show a preview of both cameras at the same time and while one stack is streaming the other stack cannot access the camera. You should be able to switch by: 1. Selecting the camera you want 2. Closing the jitsi tab 3. wait a few seconds for the camera to stop streaming 4. open jitsi in a new tab.
Note I already mentioned most of this in my previous blog post but it was a bit buried there.
Hello. It is May, my favourite month. I’m in Manchester, mainly as I’m moving projects at work, and its useful to do that face-to-face.
For the last 2 and a half years, my job has mostly involved a huge, old application inside a big company, which I can’t tell you anything about. I learned a lot about how to tackle really, really big software problems where nobody can tell you how the system works and nobody can clearly describe the problem they want you to solve. It was the first time in a long time that I worked on production infrastructure, in that, we could have caused major outages if we rolled out bad changes. Our team didn’t cause any major outages in all that time. I will take that as a sign of success. (There’s still plenty of legacy application to decommission, but it’s no longer my problem).
During that project I tried to make time to work on end to end testing of GNOME using openQA as well… with some success, in the sense that GNOME OS still has working openQA tests, but I didn’t do very well at making improvements, and I still don’t know if or when I’ll ever have time to look further at end-to-end testing for graphical desktops. We did a great Outreachy internship at least with Tanju and Dorothy adding quite a few new tests.
Several distros test GNOME downstream, but we still don’t have much of a story of how they could collaborate upstream. We do still have the monthly Linux QA call so we have a space to coordinate work in that area… but we need people who can do the work.
My job now, for the moment, involves a Linux-based operating system that is intended to be used in safety-critical contexts. I know a bit about operating systems and not much about functional safety. I have seen enough to know there is nothing magic about a “safety certificate” — it represents some thinking about risks and how to detect and mitigate them. I know Codethink is doing some original thinking in this area. It’s interesting to join in and learn about what we did so far and where it’s all going.
Giving credit to people
The new GNOME website, which I really like, describes the project as “An independent computing platform for everyone”.
There is something political about that statement: it’s implying that we should work towards equal access to computer technology. Something which is not currently very equal. Writing software isn’t going to solve that on its own, but it feels like a necessary part of the puzzle.
If I was writing a more literal tagline for the GNOME project, I might write: “A largely anarchic group maintaining complex software used by millions of people, often for little or no money.” I suppose that describes many open source projects.
Something that always bugs me is how a lot of this work is invisible. That’s a problem everywhere: from big companies and governments, down to families and local community groups, there’s usually somebody who does more work than they get credit for.
But we can work to give credit where credit is due. And recently several people have done that!
Outgoing ED Richard Littauer in “So Long and Thanks For All the Fish” shouted out a load of people who work hard in the GNOME Foundation to make stuff work.
Then incoming GNOME ED, Steven Deobald wrote a very detailed “2025-05-09 Foundation Report” (well done for using the correct date format, as well), giving you some idea about how much time it takes to onboard a new director, and how many people are involved.
It was a pleasant surprise how easy it was to switch—from the user’s
point of view, you just pass --with-gc=heap-conservative-parallel-mmc
to Guile’s build (on the wip-whippet branch); when developing I also pass --with-gc-debug, and I
had a couple bugs to fix—but, but, there are still some issues. Today’s
note thinks through the ones related to heap sizing heuristics.
growable heaps
Whippet has three heap sizing
strategies:
fixed, growable, and adaptive
(MemBalancer). The adaptive policy
is the one I would like in the long term; it will grow the heap for processes with a high allocation rate, and shrink when they go
idle. However I won’t really be able to test heap shrinking until I get
precise tracing of heap edges, which will allow me to evacuate sparse
blocks.
So for now, Guile uses the growable policy, which attempts to size the
heap so it is at least as large as the live data size, times some
multiplier. The multiplier currently defaults to 1.75×, but can be set
on the command line via the GUILE_GC_OPTIONS environment variable.
For example to set an initial heap size of 10 megabytes and a 4×
multiplier, you would set
GUILE_GC_OPTIONS=heap-size-multiplier=4,heap-size=10M.
Anyway, I have run into problems! The fundamental issue is
fragmentation. Consider a 10MB growable heap with a 2× multiplier,
consisting of a sequence of 16-byte objects followed by 16-byte holes.
You go to allocate a 32-byte object. This is a small object (8192 bytes
or less), and so it goes in the Nofl space. A Nofl mutator holds on to
a block from the list of sweepable blocks, and will sequentially scan
that block to find holes. However, each hole is only 16 bytes, so we
can’t fit our 32-byte object: we finish with the current block, grab
another one, repeat until no blocks are left and we cause GC. GC runs,
and after collection we have an opportunity to grow the heap: but the
heap size is already twice the live object size, so the heuristics say
we’re all good, no resize needed, leading to the same sweep again,
leading to a livelock.
I actually ran into this case during Guile’s bootstrap, while allocating
a 7072-byte vector. So it’s a thing that needs fixing!
observations
The root of the problem is fragmentation. One way to solve the problem
is to remove fragmentation; using a semi-space collector comprehensively
resolves the issue,
modulo
any block-level fragmentation.
However, let’s say you have to live with fragmentation, for example
because your heap has ambiguous edges that need to be traced conservatively. What can we do?
Raising the heap multiplier is an effective mitigation, as it increases
the average hole size, but for it to be a comprehensive solution in
e.g. the case of 16-byte live objects equally interspersed with holes,
you would need a multiplier of 512× to ensure that the largest 8192-byte
“small” objects will find a hole. I could live with 2× or something,
but 512× is too much.
We could consider changing the heap organization entirely. For example,
most mark-sweep collectors (BDW-GC included) partition the heap into
blocks whose allocations are of the same size, so you might have some
blocks that only hold 16-byte allocations. It is theoretically possible
to run into the same issue, though, if each block only has one live
object, and the necessary multiplier that would “allow” for more empty
blocks to be allocated is of the same order (256× for 4096-byte blocks
each with a single 16-byte allocation, or even 4096× if your blocks are
page-sized and you have 64kB pages).
My conclusion is that practically speaking, if you can’t deal with
fragmentation, then it is impossible to just rely on a heap multiplier
to size your heap. It is certainly an error to live-lock the process,
hoping that some other thread mutates the graph in such a way to free up
a suitable hole. At the same time, if you have configured your heap to
be growable at run-time, it would be bad policy to fail an allocation,
just because you calculated that the heap is big enough already.
It’s a shame, because we lose a mooring on reality: “how big will my
heap get” becomes an unanswerable question because the heap might grow
in response to fragmentation, which is not deterministic if there are
threads around, and so we can’t reliably compare performance between
different configurations. Ah well. If reliability is a goal, I think
one needs to allow for evacuation, one way or another.
for nofl?
In this concrete case, I am still working on a solution. It’s going to
be heuristic, which is a bit of a disappointment, but here we are.
My initial thought has two parts. Firstly, if the heap is growable but
cannot defragment, then we need to reserve some empty blocks after each
collection, even if reserving them would grow the heap beyond the
configured heap size multiplier. In that way we will always be able to
allocate into the Nofl space after a collection, because there will
always be some empty blocks. How many empties? Who knows. Currently
Nofl blocks are 64 kB, and the largest “small object” is 8kB. I’ll
probably try some constant multiplier of the heap size.
The second thought is that searching through the entire heap for a hole
is a silly way for the mutator to spend its time. Immix will reserve a
block for overflow allocation: if a medium-sized allocation (more than
256B and less than 8192B) fails because no hole in the current block is
big enough—note that Immix’s holes have 128B granularity—then the
allocation goes to a dedicated overflow block, which is taken from the
empty block set. This reduces fragmentation (holes which were not used
for allocation because they were too small).
Nofl should probably do the same, but given its finer granularity, it
might be better to sweep over a variable number of blocks, for example
based on the logarithm of the allocation size; one could instead sweep
over clz(min-size)–clz(size) blocks before taking from the empty block list, which would at least bound the
sweeping work of any given allocation.
fin
Welp, just wanted to get this out of my head. So far, my experience
with this Nofl-based heap configuration is mostly colored by live-locks,
and otherwise its implementation of a growable heap sizing policy seems
to be more tight-fisted regarding memory allocation than BDW-GC’s
implementation. I am optimistic though that I will be able to get
precise tracing sometime soon, as measured in development time; the
problem as always is fragmentation, in that I don’t have a hole in my
calendar at the moment. Until then, sweep on Wayne, cons on Garth,
onwards and upwards!
I savored every episode, knowing this was going to be one of those rare shows, like Severance season one, that you only get to experience for the first time once. It pulls you into a vivid, immersive world that’s equal parts mesmerizing and unsettling. A place you’re fascinated by, but would never want to be put in. The atmosphere seeps into you — the sound design, the environments, the way it all just lingers under your skin. You can’t shake it off.
And now I’ve watched the final 12. episode and I already miss it. So I need to say: watch it. It’s something special.
The series is a full-length expansion of the short Scavengers by Joseph Bennett and Charles Huettner (With visible improvements across the board). They’ve cited Nausicaä as a major influence, but if you’re into Akira, you’ll catch a few visual nods there too. It’s brutal. It’s gorgeous. And honestly, I haven’t been this excited about an animated series in a long time.
Neither Netflix nor HBO wanted to greenlight the second season. But the show has come to a very satisfying closure, so I’m not complaining.
First of all, what's outlined here should be available in libinput 1.29 but I'm not 100% certain on all the details yet so any feedback (in the libinput issue tracker) would be appreciated. Right now this is all still sitting in the libinput!1192 merge request. I'd specifically like to see some feedback from people familiar with Lua APIs. With this out of the way:
Come libinput 1.29, libinput will support plugins written in Lua. These plugins sit logically between the kernel and libinput and allow modifying the evdev device and its events before libinput gets to see them.
The motivation for this are a few unfixable issues - issues we knew how to fix but we cannot actually implement and/or ship the fixes without breaking other devices. One example for this is the inverted Logitech MX Master 3S horizontal wheel. libinput ships quirks for the USB/Bluetooth connection but not for the Bolt receiver. Unlike the Unifying Receiver the Bolt receiver doesn't give the kernel sufficient information to know which device is currently connected. Which means our quirks could only apply to the Bolt receiver (and thus any mouse connected to it) - that's a rather bad idea though, we'd break every other mouse using the same receiver. Another example is an issue with worn out mouse buttons - on that device the behavior was predictable enough but any heuristics would catch a lot of legitimate buttons. That's fine when you know your mouse is slightly broken and at least it works again. But it's not something we can ship as a general solution. There are plenty more examples like that - custom pointer deceleration, different disable-while-typing, etc.
libinput has quirks but they are internal API and subject to change without notice at any time. They're very definitely not for configuring a device and the local quirk file libinput parses is merely to bridge over the time until libinput ships the (hopefully upstreamed) quirk.
So the obvious solution is: let the users fix it themselves. And this is where the plugins come in. They are not full access into libinput, they are closer to a udev-hid-bpf in userspace. Logically they sit between the kernel event devices and libinput: input events are read from the kernel device, passed to the plugins, then passed to libinput. A plugin can look at and modify devices (add/remove buttons for example) and look at and modify the event stream as it comes from the kernel device. For this libinput changed internally to now process something called an "evdev frame" which is a struct that contains all struct input_events up to the terminating SYN_REPORT. This is the logical grouping of events anyway but so far we didn't explicitly carry those around as such. Now we do and we can pass them through to the plugin(s) to be modified.
The aforementioned Logitech MX master plugin would look like this: it registers itself with a version number, then sets a callback for the "new-evdev-device" notification and (where the device matches) we connect that device's "evdev-frame" notification to our actual code:
libinput:register(1) -- register plugin version 1
libinput:connect("new-evdev-device", function (_, device)
if device:vid() == 0x046D and device:pid() == 0xC548 then
device:connect("evdev-frame", function (_, frame)
for _, event in ipairs(frame.events) do
if event.type == evdev.EV_REL and
(event.code == evdev.REL_HWHEEL or
event.code == evdev.REL_HWHEEL_HI_RES) then
event.value = -event.value
end
end
return frame
end)
end
end)
This file can be dropped into /etc/libinput/plugins/10-mx-master.lua and will be loaded on context creation.
I'm hoping the approach using named signals (similar to e.g. GObject) makes it easy to add different calls in future versions. Plugins also have access to a timer so you can filter events and re-send them at a later point in time. This is useful for implementing something like disable-while-typing based on certain conditions.
So why Lua? Because it's very easy to sandbox. I very explicitly did not want the plugins to be a side-channel to get into the internals of libinput - specifically no IO access to anything. This ruled out using C (or anything that's a .so file, really) because those would run a) in the address space of the compositor and b) be unrestricted in what they can do. Lua solves this easily. And, as a nice side-effect, it's also very easy to write plugins in.[1]
Whether plugins are loaded or not will depend on the compositor: an explicit call to set up the paths to load from and to actually load the plugins is required. No run-time plugin changes at this point either, they're loaded on libinput context creation and that's it. Otherwise, all the usual implementation details apply: files are sorted and if there are files with identical names the one from the highest-precedence directory will be used. Plugins that are buggy will be unloaded immediately.
If all this sounds interesting, please have a try and report back any APIs that are broken, or missing, or generally ideas of the good or bad persuation. Ideally before we ship it and the API is stable forever :)
[1] Benjamin Tissoires actually had a go at WASM plugins (via rust). But ... a lot of effort for rather small gains over Lua
Call for Participation – Promo Team for endof10.org
We are putting out a call for participation to create a small team to promote End of 10. Supporting the endof10 gives us a unique opportunity to reach disaffected Windows users who are forced to buy a new computer to use the latest Windows 11.
What
This team will work on promoting the End Of 10 Project (and its website) and encourage migration from Windows to GNOME or a sister desktop project. Most important is to grow our user base and grow our app ecosystem.
Who
We are looking for a diverse global team 4-5 people who can help with creating a promotion and coordinating with the KDE and End Of 10 teams.
Why
The promotion will be used to educate the public on re-using their windows 10 computers in new ways by running on a community supported operating system.
How
You can participate by reaching out to us on #engagement:gnome.org on Matrix.
If you are interested in End Of 10 but don’t feel you can commit to the Promo Team, you are welcome to join #endof10-en:kde.org on Matrix.
With Foundry I want to make LSP management much easier than it currently is in Builder.
We have the foundry lsp run python3 command where python3 can be replaced with any language for which there is an installed LSP plugin. This will start an LSP using all the abstractions (including cross-container execution) and provide it via stdin/stdout.
But what happens when you have a half-dozen language servers for Python with new ones added every week? There is a simple builtin tool now.
Keep in mind the language identifiers should match GtkSourceView language identifiers.
# Make clangd the preferred LSP for C
foundry lsp prefer clangd c
# Make sourcekit-lsp preferred LSP for C++
foundry lsp prefer sourcekit-lsp cpp
# Make ruff the preferred LSP for Python3
foundry lsp prefer ruff python3
If there is a clear LSP that your project should be using by all contributors, add --project and it will update the value in the projects settings.
I’m not a professional web designer. I’ve been making websites for decades, but I haven’t kept up with the latest browser quirks and common approaches. What I do have is a solid grasp of the web’s foundations—thanks to my time teaching IP networking at the university.
My journey with Linux started when I struggled to get PHP running on Windows. (To my surprise, my student side project autoroku.cz kept running in production for years.)
At SUSE I’ve tasted the DRY principles while working on a Rails project, SUSE Studio. I left PHP behind and embraced static site generators like Middleman, then Jekyll as it integrated into GitHub. But over time, maintenance fatigue pushed me further—back to basics. No SASS. No site generators. Just clean, modern HTML and CSS.
People are often surprised to see major projects like gnome.org, brand.gnome.org, circle.gnome.org and my own jimmac.eu built with plain HTML. Yes you do repeat yourself and inconsistencies creep in. But with integrated version control and web based editors, fixes are a click away. More people can edit plain HTML than any bespoke stack.
Do I miss some form of include()? Sure. Would I reach for Jekyll+markdown when someone else is responsible for the content? Probably. But for focused, small sites, nothing beats good old HTML.
It’s everyone’s favorite time of year, election season! …Okay, maybe not the most exciting thing—but an extremely important one nonetheless.
For anyone who doesn’t know, GNOME is comprised of many parts: individual contributors and maintainers, adhoc teams of volunteers, a bunch of open source software in the form of apps and libraries, a whole bunch of infrastructure, and—importantly—a nonprofit foundation. The GNOME Foundation exists to help manage and support the organizational side of GNOME, act as the official face of the project to third parties, and delegate authority when/where it makes the most sense. The GNOME Foundation itself is governed by its elected Board of Directors.
If you contribute to GNOME, you’re eligible to become a member of the GNOME Foundation, which gets you some perks (like an @gnome.org email address and Matrix account, blog hosting and syndication, and access to Nextcloud and video conferencing tools)—but most importantly, GNOME Foundation members vote to elect the Board of Directors. If you contribute to GNOME, I highly recommend you become a member: it looks good for you, but it also helps ensure the GNOME Foundation is directly influenced and governed by contributors themselves.
I’m Running for the Board!
I realized today I never actually announced this on my blog (just via social media), but this past March I was appointed to the GNOME Foundation Board of Directors to fill a vacancy.
However, the seat I filled was up for re-election in this very next cycle, so I’m happy to officially announce: I’m running for the GNOME Foundation Board of Directors! As part of announcing my candidacy, I was asked to share why I would like to serve on the board. I posted this on the GNOME Discourse, but for convenience, I’ve copied it below:
Hey everyone,
I’m Cassidy (cassidyjames pretty much everywhere)! I have been involved in GNOME design since 2015, and was a contributor to the wider FreeDesktop ecosystem before that via elementary OS since around 2010. I am employed by Endless, where I am the community architect/experience lead.
I am particularly proud of my work in early design, communication, and advocacy around both the FreeDesktop color scheme (i.e. dark style) and accent color preferences, both of which are now widely supported across FreeDesktop OSes and the app ecosystem. At elementary I coordinated volunteer projects, lead the user experience design, launched and managed OEM partnerships, and largely maintained our communication by writing and editing regular update announcements and other blog posts. Over the past year I helped organize GUADEC 2024 in Denver, and continue to contribute to the GNOME design team and Flathub documentation and curation.
I was appointed to the GNOME Foundation board in March to fill a vacancy, and I am excited to earn your vote to continue my work on the board. If elected, I will continue my focus on:
Clearer and more frequent communication from the GNOME Foundation, including by helping write and edit blog posts and announcements
Exploring and supporting fundraising opportunities including with users, OEMs, and downstream projects
Ensuring Flathub continues to be recognized as the premier Linux app store, especially as it moves to enable financially supporting the developers of FOSS apps
More widely communicating the impact, influence, and importance of GNOME and Flathub to raise awareness beyond the existing contributor community
Helping ensure that the Foundation reflects the interests of the contributor community
I feel like the GNOME Foundation is at an important transformation point, and I look forward to helping steer things in the right direction for an effective, sustainable organization in support of the GNOME community. Regardless of whether I am elected, I will continue to contribute to design and communication as much as I’m able.
Thank you for your consideration!
Become a Member, and Vote!
Voting will be open for two weeks beginning June 5, 2025. If you contribute to GNOME, now is a great time to ensure you’re a member so you can vote in time; check the GNOME Discourse announcement for all of the specific dates and details. And don’t forget to actually vote once it begins. :)
It’s strange being alive while so much bad shit is going on in the world, right? With our big brains that invented smartphones, quantum computers and Haskell, surely we could figure out how to stop Benjamin Netenyahu from starving hundreds of thousands of children? (Or, causing “high levels of acute food insecurity” as the UN refer to it).
Nothing in the world is simple, though, is it.
Back in 1914 when European leaders kicked off the First World War, the collective imagination of a war dated back to an era where the soldiers wore colourful jackets and the most sophisticated weapon was a gun with a knife attached. The reality of WWI was machine guns, tanks and poison gas. All that new technology took people by surprise, and made for one of the deadliest wars in history.
If you’re reading this, then however old or young you are, your life has been marked by rapid technological changes. Things are still changing rapidly. And therein lies the problem.
In amongst the bad news I am seeing some reasons to be optimistic. The best defense against exploitation is education. As a society it feels like we’re starting to get a grip on why living standards for everyone except the rich are nosediving.
Lets go back to an older technology which changed the world centuries ago: books. I am going to recommend a few books.
Technofeudalism (by Yannis Varoufakis)
The book’s preface outlines the theory: capital has mutated into a much more powerful and dangerous form of itself. Two things caused it: the “privatization of the internet”, and the manner in which Western governments and central banks responded to the financial crisis of 2008. The strongest part of the book is the detailed telling of this story, from the beginnings of capitalism and its metamorphoses during the 20th century, to the panicked central banks keeping interest rates near zero for over a decade, effectively printing money and giving it to the wealthy, who in turn decided it was best to hang onto all of it. Out of this he declares capitalism itself is dead, replaced by a more powerful force: technofuedalism.
Yanis’ concept of technofuedalism is this:
Markets, the medium of capitalism, have been replaced by digital trading platforms which look like, but as not, markets and are better understood as fiefdoms. And profit, the engine of capitalism, has been replaced with its feudal predecessor: rent. Specifically, it is a form of rent that must be paid for access to those platforms and to the cloud more broadly.
Many people depend on cloud platformsfor basic needs. For example, access to work. Think about how many people earn a living through apps: Uber drivers, food delivery couriers, freelancers advertising via Google or Meta, and so on. But it’s not just individuals. Many capitalist businesses now rely on sites like Amazon.com for most of their sales. Everyone has to pay cloud rent to the overlord.
Yanis likens this to a colonial town where all the shops are owned by the same guy, who happens to be named Jeff. This isn’t your traditional monopoly, though — because cloud platforms also “personalize” your experience of the site. You get recommendations perfectly tailed to your needs. For consumers, the platform owners control what you see. For participants, they control who is paying attention. This he calls cloud capital.
The concept of cloud capital needs better definition in the book, but I think the attention economy is the most interesting aspect, and it is what leads to the other counterintuitive side effect: many people creating value for cloud platforms do it for little or no money. Apple doesn’t pay you to make app store apps. Tiktok don’t pay you to upload videos. The book claims that capitalist companies like General Motors pay about 80% of their income to workers as salary payments, while Big Tech companies tend to spend less than 1% of their income paying workers.
In my last status update I mentioned some disillusionment with open source projects in the age of AI. Here’s another perspective: contributing to some open source projects now feels like giving free labour to cloud platform owners.
The Free Software movement dates from the 1980s, when operating systems were a source of power. Microsoft created an illegal monopoly on operating systems in the 90s and became the richest and most powerful company in the world; but today, operating systems are a commodity, and Microsoft makes more money from its cloud platform Azure.
It’s great that we maintain ethical, open computing platforms like GNOME, but the power struggle has moved on. I don’t expect to see huge innovations in desktop or mobile operating systems in the next decade.
Meanwhile, maintaining ethical cloud platforms is still a minority pursuit. Writing software doesn’t feel like the difficult part, here. The work needed if we have the will to climb out of this technofuedal hole is community organization and communication. The most valuable thing the major cloud platforms have is our attention. (And perhaps the most valuable thing we have in the open source world, is our existing communities and events, such as the Linux App Summit).
Why does this book give me hope? It gives a structure to the last 18 years of fucked up goings on in the world of power and politics. And it helps us analyze exactly what makes the big tech companies of the USA and China so powerful.
If the cloudalists got to you already and you don’t have the attention span to buy and read a book any more, don’t worry! There’s also a video.
The Trading Game (by Gary Stevenson)
I’m late to the party with this one. Gary started a blog ten years ago (wealtheconomics.org), and now runs a online video channel (GarysEconomics).
He knows a lot about money and the super-rich. He knows that people are addicted to accumulating wealth and power. He knows that living standards for working people are getting worse. He knows that politicians won’t admit that the two things are linked. And he has over a million subscribers to his channel who know that too.
Why does it give me hope? First, he’s focused on helping us understand the problem. He does have a clickbait solution — “Tax wealth, not work” — but he also acknowledges that it’s slow, difficult and messy to affect national politics. He’s realistic about how difficult it is to tax the super-rich in a world of tax havens. And he’s been going at it for 10 years already.
Careless People (by Sarah Wynn-Williams)
I listened to long discussion of this book on a podcast called Chisme Corporativo, run by two chicas from Mexico working to demystify the world of big business and USA power that controls much of the world.
The fact that Chisme Corporativo exists makes me very happy. If we’re going to live in a world where US corporations have more power than your own government — particularly the case in Latin America — then it makes a lot of sense to learn about US corporations, the people who run them, and why they make the decisions they do.
The book review quotes a part where Mark Zuckerberg finally realized that Facebook was instrumental in the first Tromp election campaign, and just how much power that endows the company with.
And he digested this bombshell for three hours, and his thought process led him to this: “Maybe I should run for president!”
That’s the type of person we are dealing with.
What’s next
Inequality keeps rising and living standards are getting worse for everyone except the super rich. But we are learning more and more about the people and the processes responsible. Information is a seed for bringing society into better balance again.
I’m going to leave you with this quote I stole blatantly from Gary Stevenson’s website:
“If we can really understand the problem, the answer will come out of it, because the answer is not separate from the problem.” ― J. Krishnamurti
Have you read any of these books? What else would you add to this list?
We’re happy to have released gst-dots-viewer, a new development tool that makes it easier to visualize and debug GStreamer pipelines. This tool, included in GStreamer 1.26, provides a web-based interface for viewing pipeline graphs in real-time as your application runs and allows to easily request all pipelines to be dumped at any time.
What is gst-dots-viewer?
gst-dots-viewer is a server application that monitors a directory for .dot files generated by GStreamer’s pipeline visualization system and displays them in your web browser. It automatically updates the visualization whenever new .dot files are created, making it simpler to debug complex applications and understand the evolution of the pipelines at runtime.
Key Features
Real-time Updates: Watch your pipelines evolve as your application runs
Interactive Visualization:
Click nodes to highlight pipeline elements
Use Shift-Ctrl-scroll or w/s keys to zoom
Drag-scroll support for easy navigation
Easily deployable in cloud based environments
How to Use It
Start the viewer server:
gst-dots-viewer
Open your browser at http://localhost:3000
Enable the dots tracer in your GStreamer application:
GST_TRACERS=dots your-gstreamer-application
The web page will automatically update whenever new pipeline are dumped, and you will be able to dump all pipelines from the web page.
New Dots Tracer
As part of this release, we’ve also introduced a new dots tracer that replaces the previous manual approach to specify where to dump pipelines. The tracer can be activated simply by setting the GST_TRACERS=dots environment variable.
Interactive Pipeline Dumps
The dots tracer integrates with the pipeline-snapshot tracer to provide real-time pipeline visualization control. Through a WebSocket connection, the web interface allows you to trigger pipeline dumps. This means you can dump pipelines exactly when you need them during debugging or development, from your browser.
Future Improvements
We plan on adding more feature and have this list of possibilities:
Additional interactive features in the web interface
Enhanced visualization options
Integration with more GStreamer tracers to provide comprehensive debugging information. For example, we could integrate the newly released memory-tracer and queue-level tracers so to plot graphs about memory usage at any time.
This could transform gst-dots-viewer into a more complete debugging and monitoring dashboard for GStreamer applications.
This is my first blog post on Planet GNOME and actually, my first blog post ever! I’ll be using this space to share updates on my Google Summer of Code 2025 project and other GNOME contributions I make along the way or even after GSoC ends. Of course, most posts for now will focus on my GSoC work.
🛠️ My GSoC Project: Improving JSON, XML, and YAML Integration in Vala
My GSoC project is about improving how Vala handles JSON, XML, and YAML. Right now, working with these formatting languages in Vala can be tedious. I’ll be contributing improvements to make parsing and emitting data in these formats easier and more intuitive for developers.
I’ll also be diving into some compiler design topics and exploring Vala projects that already use these formats, to better understand current pain points and use cases.
Thanks 🙏
Also, big thanks to Felipe Borges for maintaining Planet GNOME, and to my mentor Lorenz Wildberg, who will be mentoring me on this project. 💙
I will be contributing to GNOME Crosswords, as part of the Google Summer of Code 2025 program. My project adds construction aids to the Crosswords editor. These aids provide hints, warnings, and data that help the user create better crossword puzzles.
To learn more about GNOME Crosswords, check out this GUADEC presentation that Jonathan Blandford, the creator of Crosswords, gave last year.
Crossword construction
Constructing a crossword puzzle is tricky. Constructing a good crossword puzzle is even trickier. The main difficulty lies in finding the right words to fill the grid.
Initially, it’s quite easy. The grid starts off completely empty, so the first few words that you add don’t have any restrictions on them (apart from word length). But as you fill the grid with more and more words, it becomes increasingly difficult to find words to fill the remaining rows/columns. That’s because a remaining row, for example, will have a few of its cells already filled in by the words in the intersecting columns. This restricts the list of possible words for that row.
Something you can run into is that halfway through the construction process, you realize that one or more rows/columns cannot be filled at all, because no word meets the constraints imposed on it by the prefilled cells! In that case, you would need to backtrack and delete some of the intersecting words and try again. Of course, trying to replace a word could lead to other words on the grid needing to be replaced too—so you can get a domino effect of groups of rows/columns on the grid needing to be redone!
And that’s just what you have to deal with to create a valid crossword puzzle. To create a good crossword puzzle, there are many more things to consider, some of which impose further restrictions on the words that you can use. For example:
Are the words interesting?
Are there any words that are so uncommon as to feel unfair?
Does the puzzle have a good variety of parts of speech?
Suffice it to say, creating a good crossword puzzle is difficult. Thankfully, crossword construction software can make this process easier—certainly not easy—but easier. For example, the GNOME Crosswords editor gives you a list of possible words for each row/column, taking into account any cells in the row/column that are already filled with a letter. We can consider this feature a “construction aid.”
The goal of my GSoC project is to add additional construction aids to the Crosswords editor. These aids will help the user create better crossword puzzles.
Construction aids
Here’s a list of potential construction aids that this project can add:
Warning for unches (unchecked cells).
Warning for non-dictionary-words.
Warning for words with low familiarity.
Indicator for average familiarity of words.
Warning for crosswordese (overused crossword words).
Heat map for hard-to-fill cells.
Parts-of-speech distribution graph.
Right now, we are in the community bonding period of the GSoC program (May 8 to June 1). During this period, I will work with my mentors to determine which construction aid or aids this project should add, what they should look like, and how they should be implemented. By the end of the month, I will have created some design docs laying all this out. That will make it much easier to hit the ground running, once the coding period starts, in June.
Hey all, just a lab notebook entry today. I’ve been working on the
Whippet GC library for about three
years now, learning a lot on the way. The goal has always been to
replace Guile’s use of the Boehm-Demers-Weiser
collector
with something more modern and maintainable. Last year I finally got to
the point that I felt Whippet was
feature-complete,
and taking into account the old adage about long arses and brief videos,
I think that wasn’t too far off. I carved out some time this spring and for the
last month have been integrating Whippet into Guile in anger, on the
wip-whippet
branch.
the haps
Well, today I removed the last direct usage of the BDW collector’s API
by Guile! Instead, Guile uses Whippet’s API any time it needs to
allocate an object, add or remove a thread from the active set, identify
the set of roots for a collection, and so on. Most tracing is still
conservative, but this will move to be more precise over time. I
haven’t had the temerity to actually try one of the Nofl-based
collectors yet, but that will come soon.
Code-wise, the initial import of Whippet added some 18K lines to Guile’s
repository, as counted by git diff --stat, which includes
documentation and other files. There was an unspeakable amount of autotomfoolery to get Whippet in Guile’s ancient build system. Changes to Whippet during the course of
integration added another 500 lines or so. Integration of Whippet
removed around 3K lines of C from Guile. It’s not a pure experiment, as
my branch is also a major version bump and so has the freedom to
refactor and simplify some things.
Things are better but not perfect. Notably, I switched to build weak
hash tables in terms of buckets and chains where the links are
ephemerons, which give me concurrent lock-free reads and writes but not
resizable tables. I would like to somehow resize these tables in
response to GC, but haven’t wired it up yet.
Accessibility in the free and open source world is somewhat of a sensitive topic.
Given the principles of free software, one would think it would be the best possible place to advocate for accessibility. After all, there’s a collection of ideologically motivated individuals trying to craft desktops to themselves and other fellow humans. And yet, when you look at the current state of accessibility on the Linux desktop, you couldn’t possibly call it good, not even sufficient.
It’s a tough situation that’s forcing people who need assistive technologies out of these spaces.
I think accessibility on the Linux desktop is in a particularly difficult position due to a combination of poor incentives and historical factors:
The dysfunctional state of accessibility on Linux makes it so that the people who need it the most cannot even contribute to it.
There is very little financial incentive for companies to invest in accessibility technologies. Often, and historically, companies invest just enough to tick some boxes on government checklists, then forget about it.
Volunteers, especially those who contribute for fun and self enjoyment, often don’t go out of their ways to make the particular projects they’re working on accessible. Or to check if their contributions regress the accessibility of the app.
The nature of accessibility makes it such that the “functional progression” is not linear. If only 50% of the stack is working, that’s practically a 0%. Accessibility requires that almost every part of the stack to be functional for even the most basic use cases.
There’s almost nobody contributing to this area anymore. Expertise and domain knowledge are almost entirely lost.
In addition to that, I feel like work on accessibility is invisible. In the sense that most people are simply apathetic to the work and contributions done on this area. Maybe due to the dynamics of social media that often favor negative engagement? I don’t know. But it sure feels unrewarding. Compare:
Now, I think if I stopped writing here, you dear reader might feel that the situation is mostly gloomy, maybe even get angry at it. However, against all odds, and fighting a fight that seems impossible, there are people working on accessibility. Often without any kind of reward, doing this out of principle. It’s just so easy to overlook their effort!
So as we prepare for the Global Accessibility Awareness Day, I thought it would be an excellent opportunity to highlight these fantastic contributors and their excellent work, and also to talk about some ongoing work on GNOME.
If you consider this kind of work important and relevant, and/or if you need accessibility features yourself, I urge you: please donate to the people mentioned here. Grab these people a coffee. Better yet, grab them a monthly coffee! Contributors who accept donations have a button beneath their avatars. Go help them.
Calendar
GNOME Calendar, the default calendaring app for GNOME, has slowly but surely progressing towards being minimally accessible. This is mostly thanks to the amazing work from Hari Rana and Jeff Fortin Tam!
Back when I was working on fixing accessibility on WebKitGTK, I found the lack of modern tools to inspect the AT-SPI bus a bit off-putting, so I wrote a little app to help me through. Didn’t think much of it, really.
Of course, almost nothing I’ve mentioned so far would be possible if the toolkit itself didn’t have support for accessibility. Thanks to Emmanuele Bassi GTK4 received an entirely new accessibility backend.
Over time, more people picked up on it, and continued improving it and filling in the gaps. Matthias Clasen and Emmanuele continue to review contributions and keep things moving.
One particular contributor is Lukáš Tyrychtr, who has implemented the Text interface of AT-SPI in GTK. Lukáš contributes to various other parts of the accessibility stack as well!
On the design side, one person in particular stands out for a series of contributions on the Accessibility panel of GNOME Settings: Sam Hewitt. Sam introduced the first mockups of this panel in GitLab, then kept on updating it. More recently, Sam introduced mockups for text-to-speech (okay technically these are in the System panel, but that’s in the accessibility mockups folder!).
Please join me in thanking Sam for these contributions!
Having apps and toolkits exposing the proper amount of accessibility information is a necessary first step, but it would be useless if there was nothing to expose to.
Thanks to Mike Gorse and others, the AT-SPI project keeps on living. AT-SPI is the service that receives and manages the accessibility information from apps. It’s the heart of accessibility in the Linux desktop! As far as my knowledge about it goes, AT-SPI is really old, dating back to Sun days.
Samuel Thibault continues to maintain speech-dispatcher and Accerciser. Speech dispatcher is the de facto text-to-speech service for Linux as of now. Accerciser is a venerable tool to inspect AT-SPI trees.
Eitan Isaacson is shaking up the speech synthesis world with libspiel, a speech framework for the desktop. Orca has experimental support for it. Eitan is now working on a desktop portal so that sandboxed apps can benefit from speech synthesis seamlessly!
One of the most common screen readers for Linux is Orca. Orca maintainers have been keeping it up an running for a very long time. Here I’d like to point out that we at Igalia significantly fund Orca development.
I would like to invite the community to share a thank you for all of them!
I tried to reach out to everyone nominally mentioned in this blog post. Some people preferred not to be mentioned. I’m pretty sure I’ve never got to learn about others that are involved in related projects.
I guess what I’m trying to say is, this list is not exhaustive. There are more people involved. If you know some of them, please let me encourage you to pay them a tea, a lunch, a boat trip in Venice, whatever you feel like; or even just reach out to them and thank them for their work.
If you contribute or know someone who contributes to desktop accessibility, and wishes to be here, please let me know. Also, please let me know if this webpage itself is properly accessible!
A Look Into The Future
Shortly after I started to write this blog post, I thought to myself: “well, this is nice and all, but it isn’t exactly robust.” Hm. If only there was a more structured, reliable way to keep investing on this.
Coincidentally, at the same time, we were introduced to our new executive director Steven. With such a blast of an introduction, and seeing Steven hanging around in various rooms, I couldn’t resist asking about it. To my great surprise and joy, Steven swiftly responded to my inquiries and we started discussing some ideas!
Conversations are still ongoing, and I don’t want to create any sort of hype in case things end up not working, but… maaaaaaybe keep in mind that there might be an announcement soon!
Huge thanks to the people above, and to everyone who helped me write this blog post
¹ – Jeff doesn’t accept donations for himself, but welcomes marketing-related business
Now that the new planet.gnome.org website is live, we have added Libravatar and Gravatar support. Instead of having the Planet website host user images itself, we are giving members the choice to use profile images/avatars from these services.
I am Varun R Mallya, a 3rd-year engineering student at the Indian Institute of Technology, Roorkee. I’m now part of the GNOME community as a Google Summer of Code 2025 intern :). I will be working on the Sysprof project under the mentorship of Christian Hergert.
What I’ll be doing in the coming weeks
My proposal titled “Adding eBPF profiling capabilities to Sysprof” aims to add eBPF profiling capabilities to Sysprof. This will allow users to profile their applications using eBPF, which is a powerful and flexible tracing technology for the Linux kernel. The project will involve implementing a new backend for Sysprof that uses eBPF to collect profiling data, as well as integrating this backend into the existing Sysprof user interface.
I’ll start off by mostly validating what I wrote in the proposal and building small eBPF programs that achieve the functionality, even if inefficiently. My proposal aims to replace the data we got from /proc files using equivalent eBPF programs. Each time I manage to extract data for a type of /proc file, I will write a blog on how it works and exactly how I did it. It will indirectly serve as documentation for people who want to continue work on this after I’m done with it.
After I’m done with this, I’ll add a pipeline to Sysprof that will compile these programs and add them to the final ELF. This will involve a lot of work to make it compatible with older kernel versions since a small part of what I’m doing relies on features available in newer kernels (I might be wrong here, but I don’t know yet—I’m talking about bpf timers and bpf iterators). This will involve BTF and CORE, which I’m currently reading about.
About me
I like any kind of systems programming mostly. eBPF certainly gets me excited and I’ve been doing a lot of reading on it, to be very honest. I’ve also been working on a few open-source projects like GCC-Rust (GCC’s new independent Rust compiler btw, check it out), Reth (The Rust implementation of Ethereum), WasmEdge (A WebAssembly runtime) and I’m also involved in a few projects in my university. I’m actually a Mechanical Engineering student undergoing training, so I’m currently doing some research on drone swarming and GPU-based fluid simulations under my profs. Apart from this, I work on libp2p for Protocol Labs (currently doing some interop work between the Python and Go implementations of it.)
To which I want to say: yes! But this question does not really have a simple yes-or-no answer. There is lots of nuance to it. A better question would be:
Is this system usable for *me* ?
Accessibility is about making our software usable (and, ideally, pleasant to use) for as many people as we can.
It has been a year since we last gave an update on accessibility (a11y) in and around GTK. Time to look at what has happened in this space since then. On the surface, it might seem that the answer is: not much. But lets look a bit closer.
A new backend
We merged the AccessKit a11y backend in GTK 4.18. This is pretty big news for GTK on platforms other than Linux. For the very first time, GTK applications can be accessible on Windows and macOS. This is also the first rust dependency in GTK.
If you want to try it out, build GTK with the -Daccesskit=enabled build option, and set
GTK_A11Y=accesskit
in the environment. The AccessKit backend works on Linux as well, but we are still defaulting to at-spi here. If you are ever uncertain which a11y backend GTK is using, you can find this information in the inspector.
The new backend was created by Matt Campbell as part the STF initiative.
Keyboard shortcuts in orca
One of the remaining gaps in the Wayland a11y support was the lack of support for the special keyboard shortcuts that are traditionally provided by the orca screen reader.
Another result of the STF initiative was a prototype for a new a11y protocol, including support for these shortcuts, but it was not complete and unmerged.
Thankfully, Lukáš Tyrychtr and Carlos Garnacho cooperated on extracting the relevant parts and completed the shortcuts support. This closes one of the biggest remaining “Wayland accessibility” gaps in GNOME 48.
An accessible web browser
Georges Basile Stavracas Neto put a lot of effort into making webkitgtk accessible, in particular when it is used in a flatpak sandbox. You can watch his GUADEC talk from last year to learn all about the complexities of this task. But he succeeded, so GNOME Web is now a fully accessible, fully sandboxed web browser.
This was work was also supported by the STF initiative.
A new accessibility tool
Elevado is a new tool to let you browse and explore what apps expose on the a11y bus. The existing tool for this, accerciser, has not been in active development for a long time, so it is good to have an alternative.
The new tool just got ported to rust, so its cool. And it just saw its first release. Try it out!
Elevado was started by Georges to help with his work on a11y in webkitgtk.
The long tail
Beyond these big headline features, there have been many smaller improvements to a11y in GTK and related libraries:
A number of missing accessible labels, tooltips and key bindings have been added in the file chooser
List boxes now provide information to make orca say the right thing
The a11y overlay in the GTK inspector will now show you when your buttons are too small as click targets
ATs can receive notification about platform state (such as focus) changes, and custom accessible implementations can emit such notifications
We now provide information about shortcuts and mnemonics for actions in the form that orca expects
Reporting of text attributes has been improved (a contribution from the LibreOffice team)
libadwaita toast notifications are now announced to AT
The accessible representation of many libadwaita action row widgets has been improved
Summary
Accessibility in GNOME is continuously improving, thanks to the contributions of many people. Thanks to everybody who helps!
With Newsflash being one of the earliest gtk-rs applications it went through a lot of iterations already as the ecosystem evolved:
from just slapping widgets together in structs to subclassing support in gtk-rs
from just cloning everything to weak references with the clone!-macro
from GtkBuilder xml to blueprint
from interacting with Listboxes directly to GLib.ListModel based ListViews
And now that the boilerplate is down and ergonomics are at a good level, I felt is was finally time to go all in on gobject properties, bindings and signals.
Now the code is much easier to reason about while also dropping about ~2k lines:
While refactoring was the main focus point and the reason why I felt the major version jump was justified, it doesn’t mean there are no new features to play with.
Enclosures to the front row
So far Image, Audio and Video attachments were hidden behind a small button in the header bar. No more. With Newsflash 4.0 the article view is a hybrid of Gtk for the header with title, author, date, etc. And a web view for the HTML content. This means Newsflash can show widgets for attachments right in the article itself.
Audio WidgetImage WidgetVideo Widget
Misc
Clear article pane if selection in article list goes away
Allow manual hiding of the sidebar
New user agent based on app name
Option to set custom user agent per feed (only relevant for Local RSS)
Subcategories (also mostly only relevant for Local RSS)
Local RSS: in addition to etags, use cache-control header to reduce traffic to feeds
And many smaller fixes and improvements you can read about in the change log.
Sadly I had to deactivate the webkit DMABuf Renderer for now. I discovered a bug creating the now needed larger frame buffers for articles. Fingers crossed that this will get fixed and the DMABuf render can be re-activated.
Available on flathub beta channel
Version 4.0.0-beta1 is available on the flathub beta channel. The first few bugs have already been found and squashed. But I’m sure there are more to discover.
Make sure to back up your data and settings before switching to the beta in case a migration eats your database. ~/.var/app/io.gitlab.news_flash.NewsFlash/config/news-flash/
~/.var/app/io.gitlab.news_flash.NewsFlash/data/news-flash/
This is a response to Allan’s response to my most recent blog post. For context, I think it’s important to note that I’m happy that Allan is on the board now, along with some of the other new members coming from the community who joined in the past year. As I think I made clear in my last post, my concerns with the Foundation are with some of its structures, and the leadership predating this year’s board. I have huge respect for the effort Allan has put into the Foundation since he rejoined the board last year, I know it’s thankless work in difficult circumstances. I don’t know why Allan felt the need to issue a personal reply, seeing as this is not about him. However, since he did, I wanted to clarify a few points.
The Ban Itself
From the perspective of many people in the community, especially volunteers not affiliated with any company, Sonny was our representative on the board, trying to fix long-standing problems with the Foundation. Those of us who worked closely with him on the STF team knew how difficult and frustrating this was for him. In that already tense, low-trust situation, Sonny being banned the way he was obviously looks political — how could it not?
If you ban a board member after they try to address the community’s concerns with the Foundation you really need to do a good job communicating why you’re not just getting rid of uncomfortable opposition. What we got instead was silence and appeals to authority. Of course, given that trust in the structures was low to begin with, that was not very convincing to anyone who knew some of the backstory. “Trust me, I’ve seen more evidence” doesn’t work when there are serious concerns about the process as a whole.
My sense is that a big part of the problem is that the board/CoCC never tried to talk things through with Sonny to clear up potential misunderstandings in the CoC complaint, and as a result everyone is operating off of different facts.
Due to CoC confidentiality and the alleged infractions having happened in private settings without other parties present it’s incredibly hard to find any common ground here. I still think a mediation with everyone involved would have been a good path forward, but we’ve seen no interest from the Foundation side in continuing/re-starting something like that. Therefore, it seems we’re at an impasse — those who trust the structures will continue to do so, and those who don’t will continue not to.
The Aftermath
Allan’s post makes the claim that those of us criticizing the way this has been handled are asking for people who make important contributions to the project to be treated differently in the eyes of the CoC — I’m not sure where this is coming from, because nobody has asked for that.
However, in doing something as drastic as an immediate, long-term ban the board and CoC committee should be concerned with avoiding collateral damage. Other community members who are directly or indirectly affected should not be left hanging with no communication and lots of extra work.
Some thought should be put into which modules, programs, or initiatives might be affected by a ban, and measures taken to avoid adverse effects. None of that was done in this case. As an example: I was working with Sonny on a daily basis co-organizing the STF project, and even I didn’t get any official communication of Sonny’s ban when it happened.
In this case, the fallout from messing this up was massive. I don’t think I need to repeat what this meant for the STF project and contractors, but it didn’t stop there. For example, Sonny’s two Google Summer of Code interns also lost all contact to their mentor, with zero communication from anyone. Other volunteers had to scramble and fill in for Sonny, to avoid the interns failing their GSoC evaluations.
Independently of the questions around the validity of the ban itself, the damage caused by the way it has been (mis-)handled has been severe enough that someone should take accountability for it. While it’s true that some directors have apologized to the STF team in private, this does not seem sufficient given the gravity of the failures. There need to be some concrete consequences if the Foundation wants to be credible again in the eyes of the community.
The Independent Review
It’s true that there was an external review of the CoC decision, but unfortunately it did not bring any clarity. This is primarily because the evidence of the case itself was not examined at all, it was only a review of CoC procedures. The report we got was extremely vague and only made high-level process recommendations, it did not answer any of the actual questions around the ban.
This is why I’m confused about the claim that the report said the ban was justified — I’m assuming this was a misunderstanding. In my (and others, see e.g. Andy’s perspective) reading of the report, it only says that such a ban is within the purview of the CoC committee, and does not comment on the merits of this particular case.
There’s obviously a lot more to say, but my goal here was just to clear up a few misconceptions I’ve seen in recent discussions.
I’d like to thank everyone who has reached out and expressed their solidarity after the previous post. It’s clear that even a year later, many people across the community are still feeling hurt, confused, and isolated by the way this has been handled. Between that and the people who seem to think the elephant is just fine where it is and should be actively ignored I think we unfortunately have a lot to work through as a community.
I’d also like to thank Allan for the work he has done and is continuing to do on the Foundation side. I know having to deal with the fallout from this ban on top of everything else is not making things any easier. This situation really sucks for everyone, and I hope we can bring it behind us.
May 12 is the International ME/CFS Awareness Day. Since I have been living with ME/CFS for some time, I want to use this day as an opportunity to talk a bit about this topic.
The Illness
The main symptom of ME/CFS is an intolerance against physical, cognitive, and emotional exertion. For me, that means that activities like preparing dinner or cleaning my room can overload my body. Usually, the full consequences of this only become visible after roughly 24 hours. The state after such an overload is also called a crash. The resulting symptoms for me include exhausted muscles, feeling like I got the flue, pain in joints and muscles, disrupted sleep, brain fog, headaches, and more. Depending on the severity, these symptoms will disappear again after a day or a week of rest. Not resting during a crash, is an easy way to prolong the symptoms and just feeling incredibly miserable. Following these limitations is a bit challenging at times. Therefore, some of these symptoms are quite a frequent issue for me.
In contrast to severe cases of ME/CFS, I’m usually still having a considerable amount of energy available, with a score of 30 on the CFIDS Disability Scale. Cases with a score 0, which implies being constantly bedridden and unable to care for oneself, do exist. One of the recent more prominent cases has been the one of Diana (Physics Girl).
While I am able to manage my every day life, having to manage my resource that much, and planning ahead for basic tasks like my weekly hair wash is quite exhausting. Not having extra resources available for unexpected events in life is honestly also pretty frightening at times. Due to ME/CFS and other disabilities like Autism, I have been at “full reduced earning capacity” for more than 10 years now. That’s the formal term in Germany for people that can’t work at least 3 hours per day.
Perspectives for Treatment
ME/CFS is a syndrome, a label for a collection of symptoms that have been observed in many patients. Nobody knows what’s the cause, how it works, or even if it’s one illness or a bunch of illnesses that all manifest similarly. Equally, there is no direct treatment. There are some treatments that can be tried to manage some of the symptoms, but usually, it needs some luck to find anything that has any positive effect. Generally, ME/CFS can get better on its own. But, like everything with ME/CFS, the likeliness of this happening is unknown.
The key in managing ME/CFS is pacing. That means knowing one’s body’s limits and trying to not exceed them. This is especially important since, as described before, the main symptoms have a very delayed onset, making it impossible to just rely on the direct feedback of one’s body. If the body is clearly reacting, I am already deep in crash territory. For me, that especially means to limit physical activities like vacuuming to not more than 30 minutes and to lie down afterward. Walking is currently possible up to about 1 km on good days. But I am still struggling to follow what I know is good for me. But I am improving.
ME/CFS can be caused by infections like influenza or COVID. While COVID can cause a lot of different health issues, often lumped together under the vague term ‘long COVID’, ME/CFS is one of these potential long term effects. ME/CFS has long been mostly ignored by medical research, or worse, been labeled as a psychological problem that can be fixed by “just going out more” – which of course just worsens the symptoms. Even still, large studies are published that try to support these theories. While these studies are of laughable quality (German), they managed to hinder proper research and treatment for ME/CFS for far too long. What’s even more infuriating is that some of these studies seems to be influenced by insurances that want to avoid claims by ME/CFS patients. But COVID brought ME/CFS enough attention that things are slowly changing. A lot of trials for vastly different medications are ongoing. ME/CFS has also reached such an importance that treatment and research for it is explicitly mentioned twice in the coalition agreement of Germany’s new government. Research is slowly getting an idea of what is happening in the body of ME/CFS patients. Damaged Mitochondria, immune system reactions, changes in blood cells, involvement of the nervous system, abnormalities in brain MRI’s, and many more. However, it is still very much unclear which of these things are cause and which are effect.
Working on GNOME
I am very happy that I have the capacities to contribute to GNOME. Programming has been calming and fulfilling for me for a very long. I wish I could contribute more, but slowly chipping away on my projects is also fine :) Since last year, I have also started to accept donations and do a bit of contract work like for GNOME STF. This extra money, on top of my social benefits, helps me to buy some nice woodworking tools (I rarely have energy to use, oh no) or give me the luxury of not having to contemplate if I can afford to take a taxi to a doctor’s appointment. I am very grateful for that!
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.
