Planet GNOME

Update: Thanks for all of the feedback and discussion on Mastodon and Matrix! I’ve revised this post a bit with some more nuance and context based on feedback. I apologize if my writing style was divisive; I wrote the first draft of this post pretty hastily based on some frustrating conversations and wanted to get all my thoughts out into one place rather than retreading the same thoughts in multiple places—but I should have let it cook a bit longer and gotten feedback before firing away and logging off.

Hopefully this latest revision better refelects those thoughts and my desire to have real conversations about them while being a bit less controversial.

This past week volunteers working with the GNOME design and engagement teams debuted a brand new GNOME.org website—one that was met largely with one of two reactions:

1. It’s beautiful and modern, nice work! and

2. Where is the foot‽

You see, the site didn’t[^logo update] feature the GNOME logo at the top of the page—it just had the word GNOME, with the actual logo relegated to the footer. Admittedly, some folks reacted both ways (it’s pretty, but where’s the foot?). To me, it seems that the latter reaction was mostly the sentiment of a handful of long-time contributors who have understandably grown very cozy with the current GNOME logo:

[^logo update]: 2024-02-14: I wrote a quick merge request to use the logo on the website yesterday since I figured someone else would, anyway. I wanted to demonstrate what it would look like (and do it “right” if it was going to happen). That change has since been merged.

Why the foot?

The current GNOME logo is a four-toed foot that is sort of supposed to look like a letter G. According to legend (read: my conversations with designers and contributors who have been working with GNOME for more years than I have fingers and toes), it is basically a story of happenstance: an early wallpaper featured footprints in the sand, that was modified into an icon for the menu, that was turned into a sort of logo while being modified to look like the letter G, and then that version was flattened and cleaned up a bit and successfully trademarked by the GNOME Foundation.

Graphic shared by Michael Downey on Mastodon

So, why do people like it? My understanding (and please drop a comment if I’m wrong) is that it often boils down to one or more of:

1. It’s always been this way; as long as GNOME has had an official logo, it’s been a variation of the foot.

2. It’s a trademark so it’s not feasible to change it from a legal or financial perspective.

3. It has personality, and anything new would run the risk of being bland.

4. It has wide recognition at least within the open source enthusiast and developer space, so changing it would be detrimental to the brand equity.

What’s the problem?

I’m the first to admit that I don’t find the foot to be a particularly good logo. Over time, I’ve narrowed down my thoughts (and the feedback I’ve heard from others) into a few recurring reasons:

1. It doesn’t convey anything about the name or project which by itself may be fine—many logos don’t directly. But it feels odd to have such a bold logo choice that doesn’t directly related to the name “GNOME,” or to any specific aspect of the project.

2. It’s an awkward shape that doesn’t fit cleanly into a square or circle, especially at smaller sizes (e.g. for a social media avatar or favicon). It’s much taller than it is wide, and it’s lopsided weight-wise. This leads to frustrations from designers when trying to fit the logo into a square or circle space, leading to excessive amounts of whitespace and/or error-prone manual alignment compared to other elements.

3. It is actively off-putting and unappealing to at least some folks including much of the GNOME design team, newer contributors, people outside the open source bubble—and apparently potentially entire cultures (which has been raised multiple times over the past 20+ years). Anecdotally, almost everyone new I’ve introduced GNOME to has turned their nose up at the “weird foot,” whether it’s when showing the website or rocking a tee or sticker to support the project. It doesn’t exactly set a great first impression for a community and modern computing platform. And yes, there are a bunch of dumb memes out there about GNOME devs all being foot fetishists which—while I’m not one to shame what people are into—is not exactly the brand image you want for your global, inclusive open source project.

4. It raises the question of what the role of the design team is: if the design team cannot be allowed to effectively lead the design of the project, what are we even doing? I think this is why the topic feels so existential to me as a member of the design team. User experience design includes the moment someone first interacts with the brand of a product through them actually using it day-to-day—and right now, the design team’s hands are tied for the first half of that journey.

The imbalance and complexity make for non-ideal situations

So what can we do?

While there are some folks that would push for a complete rebrand of GNOME—name included, I feel like there’s a softer approach we could take to the issue. I would also point out that the vast majority of people using GNOME—those on Ubuntu, RHEL, Fedora, Endless OS, Debian, etc.—are not seeing the foot anywhere. They’re seeing their distro’s logo, and for many, are using using e.g. “Ubuntu” and may not even be aware they’re using GNOME.

Given all of the above, I propose that a path forward would be to:

1. Phase the foot out from any remaining user-facing spaces since it’s hard to work with in all of the contexts we need to use a logo, and it’s not particularly attractive to new users or welcoming to potential contributors—something we need to keep in mind as an aging open source project. This has been an unspoken natural phenomenon as members of the GNOME design team have soured a bit on trying to make designs look nice while accommodating the foot; as a result we have started to see less prominent usage of the foot e.g. on release notes, GNOME Circle, This Week in GNOME, the GNOME Handbook, the new website (before it was re-added), and in other spaces where the people doing the design work aren’t the most fond of it.

2. Commission a new brand logo to represent GNOME to the outside world; this would be the logo you’d expect to see at GNOME.org, on user-facing social media profiles, on event banners, on merch, etc. We’ve been mulling ideas over in the design team for literal years at this point, but it’s been difficult to pursue anything seriously without attracting very loud negative feedback from a handful of folks—perhaps if it is part of a longer-term plan explicitly including the above steps, it could be something we’d be able to pursue. And it could still be something quirky, cute, and whimsical! I personally don’t love the idea of something super generic as a logo—I think something that connects to “gnomes,” our history, and/or our modern illustration style would be great here. But importantly, it would need to be designed with the intent of its modern usage in mind, e.g. working well at small sizes, in social media avatars, etc.

3. Refresh the official GNOME brand guidelines by explicitly including our modern use of color, animation, illustrations, and recurring motifs (like the amazing wallpapers from Jakub!). This is something that has sort of started happening naturally, e.g. with the web team’s newer web designs and as the design team made the decision to move to Inter-based Adwaita Sans for the user interface—and this push continues to receive positive feedback from the community. But much of these efforts have not been reflected in the official project brand guidelines, causing an awkward disconnect between what we say the brand is and how it’s actually widely used and perceived.

4. Immortalize the foot as a mascot, something to be used in developer documentation, as an easter egg, and perhaps in contributor-facing spaces. It’s much easier to tell newcomers, “oh this is a goofy icon that used to be our logo—we love it, even if it’s kind of silly” without it having to represent the whole project from the outside. It remains a symbol for those “in the know” within the contributor community while avoiding it necessarily representing the entire GNOME brand.

5. Stretch goal: title-case Gnome as a brand name. We’ve long moved past GNOME being an acronym (GNU Network Object Model Environment?)—with a bit of a soft rebrand, I feel we could officially say that it’s spelled “Gnome,” especially if done so in an official logotype. As we know, much like the pronunciation of GNOME itself, folks will do what they want—and they’re free to!—but this would be more about how the brand name is used/styled in an official capacity. I don’t feel super strongly about this one, but it is awkward to have to explain why it’s called GNOME and all caps but not actually an acronym but it used to be—and why the logo is a foot—any time I tell someone what I contribute to. ;)

What do you think?

I genuinely think GNOME as a project and community is in a good place to move forward with modernizing our outward image a bit. Members of the design team like Jamie, kramo, Brage, Jakub, Tobias, Sam, and Allan and other contributors across the project like Alice, Sophie, and probably half a dozen more I am forgetting have been working hard at modernizing our UI and image when it comes to software—I think it’s time we caught up with the outward brand itself.

Hit me up on Mastodon or any of the links in the footer to tell me if you think I’m right, or if I’ve gotten this all terribly wrong. :)

• 2025-02-13: Edited to correct spelling and grammatical issues and include more graphics.
• 2025-02-14: Edited to mention more design contributors
• 2025-02-14: Heavily revised to add more context, arguments in favor of the foot, and improve language throughout

As promised, I wanted to write a blog post about this application.

Enter TeX is a TeX / LaTeX text editor previously named LaTeXila and then GNOME LaTeX. It is based on the same libraries as gedit.

Renames

LaTeXila was a fun name that I picked up when I was a student back in 2009. Then the project was renamed to GNOME LaTeX in 2017 but it was not a great choice because of the GNOME trademark. Now it is called Enter TeX.

By having "TeX" in the name is more future-proof than "LaTeX", because there is also Plain TeX, ConTeXt and GNU Texinfo. Only LaTeX is currently well supported by Enter TeX, but the support for other variants would be a welcome addition.

Note that the settings and configuration files are automatically migrated from LaTeXila or GNOME LaTeX to Enter TeX.

There is another rename: the namespace for the C code has been changed from "Latexila" to "Gtex", to have a shorter and better name.

Other news

If you're curious, you can read the top of the NEWS file, it has all the details.

If I look at the achievements file, there is also the port from Autotools to Meson that was done recently and is worth mentioning.

Known issue for the icons

Enter TeX unfortunately suffers from a combination of changes in adwaita-icon-theme and GThemedIcon (part of GIO). Link to the issue on GitLab.

Compare the two screenshots and choose the one you prefer:

As an interim solution, what I do is to install adwaita-icon-theme 41.0 in the same prefix as where Enter TeX is installed (not a system-wide prefix).

To summarize

• LaTeXila -> GNOME LaTeX -> Enter TeX
• C code namespace: Latexila -> Gtex
• Build system: Autotools -> Meson
• An old version of adwaita-icon-theme is necessary.

This article was written by Sébastien Wilmet, currently the main developer behind Enter TeX.

A new year begins, a good time to share some various news about gedit.

gedit-text-editor.org

gedit has a new domain name for its website:

gedit-text-editor.org

Previously, the gedit homepage was on the GNOME wiki, but the wiki has been retired. So a new website has been set up.

Some work on the website is still necessary, especially to better support mobile devices (responsive web design), and also for printing the pages. If you are a seasoned web developer and want to contribute, don't hesitate to get in touch!

Wrapping-up statistics for 2024

The total number of commits in gedit and gedit-related git repositories in 2024 is: 1042. More precisely:

300 enter-tex 365 gedit 52 gedit-plugins 50 gspell 13 libgedit-amtk 54 libgedit-gfls 47 libgedit-gtksourceview 161 libgedit-tepl

It counts all contributions, translation updates included.

The list contains two apps, gedit and Enter TeX. The rest are shared libraries (re-usable code available to create other text editors).

Enter TeX is a TeX/LaTeX editor previously named LaTeXila and GNOME LaTeX. It depends on Gedit Technology and drives some of its development. So it makes sense to include it alongside gedit. A blog post about Enter TeX will most probably be written, to shed some light on this project that started in 2009.

Onwards to 2025

The development continues! To get the latest news, you can follow this blog or, alternatively, you can follow me on Mastodon.

This article was written by Sébastien Wilmet, currently the main developer behind gedit.

For at least the last 15 years, the translations of GNOME into Czech have been in excellent condition. With each release, I would only report that everything was translated, and for the last few years, this was also true the vast majority of the documentation. However, last year things started to falter. Contributors who had been carrying this for many years left, and there is no one to take over after them. Therefore, we have decided to admit it publicly: GNOME currently has no Czech translators, and unless someone new takes over, the translations will gradually decline.

Personally, I started working on GNOME translations in 2008 when I began translating my favorite groupware client – Evolution. At that time, the leadership of the translation team was taken over by Petr Kovář, who was later joined by Marek Černocký who maintained the translations for many years and did an enormous amount of work. Thanks to him, GNOME was almost 100% translated into Czech, including the documentation. However, both have completely withdrawn from the translations. For a while, they were replaced by Vojtěch Perník and Daniel Rusek, but the former has also left, and Dan has now come to the conclusion that he can no longer carry on the translations alone.

I suggested to Dan that instead of trying to appeal to those who the GNOME translations have relied on for nearly two decades—who have already contributed a lot and are probably facing some form of burnout or have simply moved on to something else after so many years—it would be better to reach out to the broader community to see if there is someone from a new generation who would be willing and energetic enough to take over the translations. Just as we did nearly two decades ago.

It may turn out that an essential part of this process will be that the GNOME translations into Czech will decline for some time.Because the same people have been doing the job for so many years, the community has gotten used to taking excellent translations for granted. But it is not. Someone has to do the work. As more and more English terms appear in the GNOME interface, perhaps dissatisfaction will motivate someone to do something about it. After all, that was the motivation for the previous generation to get involved.

If someone like that comes forward, Dan and I are willing to help them with training and gradually hand over the project. We may both continue to contribute in a limited capacity, but the project needs someone new, ideally not just one person, but several, because carrying it alone is a path to burnout. Interested parties can contact us in the mailing list of the Czech translation team at diskuze-l10n-cz@lists.openalt.org.

Hey all, the video of my FOSDEM talk on Whippet is up:

Slides here, if that’s your thing.

I ended the talk with some puzzling results around generational collection, which prompted yesterday’s post. I don’t have a firm answer yet. Or rather, perhaps for the splay benchmark, it is to be expected that a generational GC is not great; but there are other benchmarks that also show suboptimal throughput in generational configurations. Surely it is some tuning issue; I’ll be looking into it.

Happy hacking!

In an earlier blog post I wrote about a potential way of speeding up C++ compilations (or any language that has a big up-front cost). The basic idea is to have a process that reads in all stdlib header code that is suspended. Compilations are done by sending the actual source file + flags to this process, which then forks and resumes compilation. Basically this is a way to persist the state of the compiler without writing (or executing) a single line of serialization code.

The obvious follow up question is what is the speedup of this scheme. That is difficult to say without actually implementing the system. There are way too many variables and uncertainties to make any sort of reasonable estimate.

So I implemented it. 

Not in an actual compiler, heavens no, I don't have the chops for that. Instead I implemented a completely fake compiler that does the same steps a real compiler would need to take. It spawns the daemon process. It creates a Unix domain socket. It communicates with the running daemon. It produces output files. The main difference is that it does not actually do any compilation, instead it just sleeps to simulate work. Since all sleep durations are parameters, it is easy to test the "real" effect of various schemes.

The code is in this GH repo.

The default durations were handwavy estimates based on past experience. In past measurements, stdlib includes take by far the largest chunk of the total compilation time. Thus I estimated that compilation without this scheme would take 5 seconds per file whereas compilations with it would take 1 second. If you disagree with these assumptions, feel free to run the test yourself with your own time estimates.

The end result was that on this laptop that has 22 cores a project with 100 source files took 26 seconds to compile without the daemon and 7 seconds with it. This means the daemon version finished in just a hair over 25% of a "regular" build.

Wouldn't you want your compilations to finish in a quarter of the time with zero code changes? I sure would.

(In reality the speedup is probably less than that. How much? No idea. Someone's got to implement that to find out.)

For fun, I decided to ask to "explain the themes in the Yocto Project release names". It went about as well as I expected, to be honest:

The Yocto Project follows a thematic naming convention for its release names. The themes have evolved over time:

So far so good.

Types of Birds (Older Releases) Early Yocto Project releases were named after different bird species. Examples include:

Incorrect, that was not one of the themes.

Dizzy (a reference to Dizzy Gillespie, but also sounds like a bird name)

A jazz musician that "sounds like a bird name"? One hell of a stretch, and not the reference.

Fido (a breed of pigeon)

From what I can tell, Fido is not a breed of pigeon. Also not the reference.

Jethro (a reference to Jethro Tull, but also resembles a bird-like theme)

Jethro Tull the rock band? Not the reference.

I do wonder why it decided the theme was types of birds, then made up one bird breed and listed two musicians that "sound like" bird names.

Continuing on...

Muppets Characters (Mid-Series) The Yocto Project later transitioned to naming releases after characters from The Muppets, a popular puppet show created by Jim Henson. Examples include:

No, it didn't.

Krogoth (a lesser-known Muppet)

Krogoth is so lesser-known that the Muppets Wiki doesn't mention it, so I think this is made-up.

Morty (another Muppet character)

According to the Muppets Wiki "Morty is Rick Moranis' agent. He is seen in Muppets Tonight episode 202 [in 1997]".

Considering how incorrect everything else is I actually think this is more likely to be a coincidence than an actual reference to reality. There's been a lot of characters over the decades of shows.

Rocko (potentially a reference to Rocko from Rocko’s Modern Life, though not strictly Muppet-related)

"not strictly"? A cartoon from the 1990s by some of the people that later gave us Spongebob Squarepants is not the reference for this release.

Sci-Fi and Fantasy References (Current Theme) The most recent trend in Yocto release names leans toward science fiction and fantasy references. Examples include:

Surprisingly, this is not the current theme.

Langdale (a reference to a location, possibly inspired by British landscapes, but also fits a fantasy tone)

Oh you're close, go on you can do it!

Mickledore (a name with a Tolkien-esque or fantasy feel)

I can only imagine why that is...

Nanbield (continuing the theme of mysterious, fantasy-like names)

I give up.

Remember people: verify everything that LLMs say, as they are first-rate bullshit artists.

These are my notes for setting up a “deploy-to-remote-webserver” workflow with ssh and an sftp-only chroot, in case someone might find it useful.

Compiled from various bits and pieces around the internet.

Setting up SSH

• Add a group: groupadd -r remote-deploy. This will add a system group
• Create a folder for authorized keys for users in that group: mkdir -p /etc/ssh/authorized
• Modify ssh_config

AuthorizedKeysFile /etc/ssh/authorized/%u .ssh/authorized_keys Match Group remote-deploy ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no X11Forwarding no PasswordAuthentication no Setting up the chroot jail

It is important that the path up until the home folder is owned by root:root. Below that, create a folder that is owned by the user and any supplementary group you might need to access (e.g. www-data)

mkdir -p /path/to/chroot/jail/deploy-user chown -R root:root /path/to/chroot/jail/deploy-user chmod -R 755 /path/to/chroot/jail/deploy-user mkdir /path/to/chroot/jail/deploy-user/public chown deploy-user:www-data /path/to/chroot/jail/deploy-user chmod 755 /path/to/chroot/jail/deploy-user Setting up the individual user(s)

• Add a user to the group created above: useradd -g remote-deploy -M -d /path/to/chroot/jail -s /usr/sbin/nologin deploy-user
• Generate a new pair of keys and move the public key to the newly configured added keystore

ssh-keygen -o deploy-user -t ed25519 mv deploy-user.pub /etc/ssh/authorized/deploy-user Setting up the gitlab pipeline

• Obtain the host key frm the remote host. To be able to make the variable masked in Gitlab later, it needs to be encoded: ssh-keyscan -q deploy-host.example.com 2>/dev/null | bas64 -w0

• Log into your gitlab instance, go to Settings->CI/CD->Variables

  • Click on “Add variable”

  • Set “Masked and Hidden” and “Protect variable”

  • Add a comment like “SSH host key for deploy host”

  • Set name to SSH_HOST_KEY

  • Paste output of the keyscan command

  • Create another variable with the same Settings

  • Add a comment like “SSH private key for deploy user”

  • Set name to SSH_PRIVATE_KEY

  • Paste output of base64 -w0 deploy-user, where deploy-user is the private key generated above

• Setting up ssh in the pipeline script

mkdir ~/.ssh echo -n $SSH_HOST_KEY | base64 -d > ~/.ssh/known_hosts # If necessary, start ssh-agent eval `ssh-agent` echo -n $SSH_PRIVATE_KEY | base64 -d | ssh-add -

In my previous post, I alluded to an exciting development for PipeWire. I’m now thrilled to officially announce that Asymptotic will be undertaking several important tasks for the project, thanks to funding from the Sovereign Tech Fund (now part of the Sovereign Tech Agency).

Some of you might be familiar with the Sovereign Tech Fund from their funding for GNOME, GStreamer and systemd – they have been investing in foundational open source technology, supporting the digital commons in key areas, a mission closely aligned with our own.

We will be tackling three key areas of work.

ASHA hearing aid support

I wrote a bit about our efforts on this front. We have already completed the PipeWire support for single ASHA hearing aids, and are actively working on support for stereo pairs.

Improvements to GStreamer elements

We have been working through the GStreamer+PipeWire todo list, fixing bugs and making it easier to build audio and video streaming pipelines on top of PipeWire. A number of usability improvements have already landed, and more work on this front continues

A Rust-based client library

While we have a pretty functional set of Rust bindings around the C-based libpipewire already, we will be creating a pure Rust implementation of a PipeWire client, and provide that via a C API as well.

There are a number of advantages to this: type and memory safety being foremost, but we can also leverage Rust macros to eliminate a lot of boilerplate (there are community efforts in this direction already that we may be able to build upon).

This is a large undertaking, and this funding will allow us to tackle a big chunk of it – we are excited, and deeply appreciative of the work the Sovereign Tech Agency is doing in supporting critical open source infrastructure.

Watch this space for more updates!

Introduction

If you use SteamOS and you like to install third-party tools or modify the system-wide configuration some of your changes might be lost after an OS update. Read on for details on why this happens and what to do about it.

As you all know SteamOS uses an immutable root filesystem and users are not expected to modify it because all changes are lost after an OS update.

However this does not include configuration files: the /etc directory is not part of the root filesystem itself. Instead, it’s a writable overlay and all modifications are actually stored under /var (together with all the usual contents that go in that filesystem such as logs, cached data, etc).

/etc contains important data that is specific to that particular machine like the configuration of known network connections, the password of the main user and the SSH keys. This configuration needs to be kept after an OS update so the system can keep working as expected. However the update process also needs to make sure that other changes to /etc don’t conflict with whatever is available in the new version of the OS, and there have been issues due to some modifications unexpectedly persisting after a system update.

SteamOS 3.6 introduced a new mechanism to decide what to to keep after an OS update, and the system now keeps a list of configuration files that are allowed to be kept in the new version. The idea is that only the modifications that are known to be important for the correct operation of the system are applied, and everything else is discarded1.

However, many users want to be able to keep additional configuration files after an OS update, either because the changes are important for them or because those files are needed for some third-party tool that they have installed. Fortunately the system provides a way to do that, and users (or developers of third-party tools) can add a configuration file to /etc/atomic-update.conf.d, listing the additional files that need to be kept.

There is an example in /etc/atomic-update.conf.d/example-additional-keep-list.conf that shows what this configuration looks like.

Sample configuration file for the SteamOS updater

Developers who are targeting SteamOS can also use this same method to make sure that their configuration files survive OS updates. As an example of an actual third-party project that makes use of this mechanism you can have a look at the DeterminateSystems Nix installer:

https://github.com/DeterminateSystems/nix-installer/blob/v0.34.0/src/planner/steam_deck.rs#L273

As usual, if you encounter issues with this or any other part of the system you can check the SteamOS issue tracker. Enjoy!

1. A copy is actually kept under /etc/previous to give the user the chance to recover files if necessary, and up to five previous snapshots are kept under /var/lib/steamos-atomupd/etc_backup ︎

You want background playback? You get background playback! Shortwave 5.0 is now available and finally continues playback when you close the window, resolving the “most popular” issue on GitLab!

Shortwave uses the new Flatpak background portal for this, which means that the current playback status is now also displayed in the “Background Apps” menu.

The recording feature has also been overhauled. I have addressed a lot of user feedback here, e.g. you can now choose between 3 different modes:

• Save All Tracks: Automatically save all recorded tracks
• Decide for Each Track: Temporarily record tracks and save only the ones you want
• Record Nothing: Stations are played without recording

In addition to that the directory for saving recorded tracks can be customized, and users can now configure the minimum and maximum duration of recordings.

There is a new dialog window with additional details and options for current or past played tracks. For example, you no longer need to worry about forgetting to save your favorite track when the recording is finished – you can now mark tracks directly during playback so that they are automatically saved when the recording is completed.

You don’t even need to open Shortwave for this, thanks to the improved notifications you can decide directly when a new track gets played whether you want to save it or not.

Of course the release also includes the usual number of bug fixes and improvements. For example, the volume can now be changed using the keyboard shortcut.

Enjoy!

With apps made for different form factors, it can be hard to find what works for your specific device. For example, we know it can be a bit difficult to find great apps that are actually designed to be used on a mobile phone or tablet. To help solve this, we’re introducing a new collection: On the Go.

As the premier source of apps for Linux, Flathub serves a wide range of people across a huge variety of hardware: from ultra powerful developer workstations to thin and light tablets; from handheld gaming consoles to a growing number of mobile phones. Generally any app on Flathub will work on a desktop or laptop with a large display, keyboard, and mouse or trackpad. However, devices with only touch input and smaller screen sizes have more constraints.

Revealing the App Ecosystem​

Using existing data and open standards, we’re now highlighting apps on Flathub that report as being designed to work on these mobile form factors. This new On the Go collection uses existing device support data submitted by app developers in their MetaInfo, the same spec that is used to build those app’s listings for Flathub and other app store clients. The collection is featured on the Flathub.org home page for all devices.

Many of these apps are adaptive across screen sizes and input methods; you might be surprised to know that your favorite app on your desktop will also work great on a Linux phone, tablet, or Steam Deck’s touch screen. We aim to help reveal just how rich and well-rounded the app ecosystem already is for these devices—and to give app developers another place for their apps to shine and be discovered.

Developers: It’s Up to You​

As of this writing there are over 150 apps in the collection, but we expect there are cases where app developers have not provided the requisite device support data.

If you’re the creator of an app that should work well on mobile form factors but isn’t featured in the collection, take a minute to double-check the documentation and your own apps’s MetaInfo to ensure it’s accurate. Device support data can also be used by native app store clients across form factors to determine what apps are displayed or how they are ranked, so it’s a good idea to ensure it’s up to date regardless of what your app supports.

At LaOficina we are currently working on a project to digitize family photographs and one of the challenges is the correct traceability of intellectual property. In this case we have encountered the difficulty of knowing the exact conditions of the received material, a situation that is not new and which is already addressed by the RightsStatements vocabulary, which includes 12 terms that are used, among others, by the Europeana community. Therefore, it is obvious that we need to add this vocabulary to our Wikibase Suite instance. By the way, as an exercise, I have taken the opportunity to compose it from scratch as an independent OWL ontology. It is very simple, but probably it has some conceptual flaws. If it is useful to someone, please use it without restrictions: righstatements-ontology.ttl

If you find something wrong please reach me.

So a we are a little bit into the new year I hope everybody had a great break and a good start of 2025. Personally I had a blast having gotten the kids an air hockey table as a Yuletide present :). Anyway, wanted to put this blog post together talking about what we are looking at for the new year and to let you all know that we are hiring.

Artificial Intelligence
One big item on our list for the year is looking at ways Fedora Workstation can make use of artificial intelligence. Thanks to IBMs Granite effort we know have an AI engine that is available under proper open source licensing terms and which can be extended for many different usecases. Also the IBM Granite team has an aggressive plan for releasing updated versions of Granite, incorporating new features of special interest to developers, like making Granite a great engine to power IDEs and similar tools. We been brainstorming various ideas in the team for how we can make use of AI to provide improved or new features to users of GNOME and Fedora Workstation. This includes making sure Fedora Workstation users have access to great tools like RamaLama, that we make sure setting up accelerated AI inside Toolbx is simple, that we offer a good Code Assistant based on Granite and that we come up with other cool integration points.

Wayland
The Wayland community had some challenges last year with frustrations boiling over a few times due to new protocol development taking a long time. Some of it was simply the challenge of finding enough people across multiple projects having the time to follow up and help review while other parts are genuine disagreements of what kind of things should be Wayland protocols or not. That said I think that problem has been somewhat resolved with a general understanding now that we have the ‘ext’ namespace for a reason, to allow people to have a space to review and make protocols without an expectation that they will be universally implemented. This allows for protocols of interest only to a subset of the community going into ‘ext’ and thus allowing protocols that might not be of interest to GNOME and KDE for instance to still have a place to live.

The other more practical problem is that of having people available to help review protocols or providing reference implementations. In a space like Wayland where you need multiple people from multiple different projects it can be hard at times to get enough people involved at any given time to move things forward, as different projects have different priorities and of course the developers involved might be busy elsewhere. One thing we have done to try to help out there is to set up a small internal team, lead by Jonas Ådahl, to discuss in-progress Wayland protocols and assign people the responsibility to follow up on those protocols we have an interest in. This has been helpful both as a way for us to develop internal consensus on the best way forward, but also I think our contribution upstream has become more efficient due to this.

All that said I also believe Wayland protocols will fade a bit into the background going forward. We are currently at the last stage of a community ‘ramp up’ on Wayland and thus there is a lot of focus on it, but once we are over that phase we will probably see what we saw with X.org extensions over time, that for the most time new extensions are so niche that 95% of the community don’t pay attention or care. There will always be some new technology creating the need for important new protocols, but those are likely to come along a relatively slow cadence.

High Dynamic Range

HDR support in GNOME Control Center

As for concrete Wayland protocols the single biggest thing for us for a long while now has of course been the HDR support for Linux. And it was great to see the HDR protocol get merged just before the holidays. I also want to give a shout out to Xaver Hugl from the KWin project. As we where working to ramp up HDR support in both GNOME Shell and GTK+ we ended up working with Xaver and using Kwin for testing especially the GTK+ implementation. Xaver was very friendly and collaborative and I think HDR support in both GNOME and KDE is more solid thanks to that collaboration, so thank you Xaver!

Talking about concrete progress on HDR support Jonas Adahl submitted merge requests for HDR UI controls for GNOME Control Center. This means you will be able to configure the use of HDR on your system in the next Fedora Workstation release.

PipeWire
I been sharing a lot of cool PipeWire news here in the last couple of years, but things might slow down a little as we go forward just because all the major features are basically working well now. The PulseAudio support is working well and we get very few bug reports now against it. The reports we are getting from the pro-audio community is that PipeWire works just as well or better as JACK for most people in terms of for instance latency, and when we do see issues with pro-audio it tends to be more often caused by driver issues triggered by PipeWire trying to use the device in ways that JACK didn’t. We been resolving those by adding more and more options to hardcode certain options in PipeWire, so that just as with JACK you can force PipeWire to not try things the driver has problems with. Of course fixing the drivers would be the best outcome, but for some of these pro-audio cards they are so niche that it is hard to find developers who wants to work on them or who has hardware to test with.

We are still maturing the video support although even that is getting very solid now. The screen capture support is considered fully mature, but the camera support is still a bit of a work in progress, partially because we are going to a generational change the camera landscape with UVC cameras being supplanted by MIPI cameras. Resolving that generational change isn’t just on PipeWire of course, but it does make the a more volatile landscape to mature something in. Of course an advantage here is that applications using PipeWire can easily switch between V4L2 UVC cameras and libcamera MIPI cameras, thus helping users have a smooth experience through this transition period.
But even with the challenges posed by this we are moving rapidly forward with Firefox PipeWire camera support being on by default in Fedora now, Chrome coming along quickly and OBS Studio having PipeWire support for some time already. And last but not least SDL3 is now out with PipeWire camera support.

MIPI camera support
Hans de Goede, Milan Zamazal and Kate Hsuan keeps working on making sure MIPI cameras work under Linux. MIPI cameras are a step forward in terms of technical capabilities, but at the moment a bit of a step backward in terms of open source as a lot of vendors believe they have ‘secret sauce’ in the MIPI camera stacks. Our works focuses mostly on getting the Intel MIPI stack fully working under Linux with the Lattice MIPI aggregator being the biggest hurdle currently for some laptops. Luckily Alan Stern, the USB kernel maintainer, is looking at this now as he got the hardware himself.

Flatpak
Some major improvements to the Flatpak stack has happened recently with the USB portal merged upstream. The USB portal came out of the Sovereign fund funding for GNOME and it gives us a more secure way to give sandboxed applications access to you USB devcices. In a somewhat related note we are still working on making system daemons installable through Flatpak, with the usecase being applications that has a system daemon to communicate with a specific piece of hardware for example (usually through USB). Christian Hergert got this on his todo list, but we are at the moment waiting for Lennart Poettering to merge some pre-requisite work into systemd that we want to base this on.

Accessibility
We are putting in a lot of effort towards accessibility these days. This includes working on portals and Wayland extensions to help facilitate accessibility, working on the ORCA screen reader and its dependencies to ensure it works great under Wayland. Working on GTK4 to ensure we got top notch accessibility support in the toolkit and more.

GNOME Software
Last year Milan Crha landed the support for signing the NVIDIA driver for use on secure boot. The main feature Milan he is looking at now is getting support for DNF5 into GNOME Software. Doing this will resolve one of the longest standing annoyances we had, which is that the dnf command line and GNOME Software would maintain two separate package caches. Once the DNF5 transition is done that should be a thing of the past and thus less risk of disk space being wasted on an extra set of cached packages.

Firefox
Martin Stransky and Jan Horak has been working hard at making Firefox ready for the future, with a lot of work going into making sure it supports the portals needed to function as a flatpak and by bringing HDR support to Firefox. In fact Martin just got his HDR patches for Firefox merged this week. So with the PipeWire camera support, Flatpak support and HDR support in place, Firefox will be ready for the future.

We are hiring! looking for 2 talented developers to join the Red Hat desktop team
We are hiring! So we got 2 job openings on the Red Hat desktop team! So if you are interested in joining us in pushing the boundaries of desktop linux forward please take a look and apply. For these 2 positions we are open to remote workers across the globe and while the job adds list specific seniorities we are somewhat flexible on that front too for the right candidate. So be sure to check out the two job listings and get your application in! If you ever wanted to work fulltime on GNOME and related technologies this is your chance.

In talking with someone about “preferred form for modification” over the weekend at FOSDEM, the FSF (now sort-of-OSI?) four freedoms came up. They’re not bad, but they’re extremely developer-focused in their “use case”. This is not a new observation, of course, but the changed technical and social context of AI seems to be bringing it to the fore that different users have different variations on the values and why open is so important to them.

Here’s a very quick, rough cut of what I proposed instead as key freedoms, and who those matter for. These are not exclusive (eg in many cases developers also care about replication; businesses obviously frequently care about modification, etc.) but compared to the original four freedoms, convey that different stakeholders have different needs—all of which have been served, but not explicitly called out as metrics, by the FOSS movement over the years.

• modification (foremost, for developers): We like to play with things, and often can make them better in the process. Enough said.
• replication (foremost, for scientists): It’s not really science if you can’t replicate it, and you can’t replicate it if it isn’t really yours. High overlap with modification and transparency, but something other constituencies can often live without.
• transparency (foremost, for governments): you can’t effectively regulate what you can’t understand, and it’s never OK for something that needs to be regulated to be opaque. (Obviously we allow this all the time but as we’re all reminded this week that leads to all kinds of malignancies.)
• cost of re-use (foremost, for business): This is perhaps the least unique, but it’s important to remember that statistically businesses very rarely modify open source. They pick and choose what they use, and compose them in almost entirely unique ways, but that’s a property of architectural design and cost, not of ability to modify.

These of course get you to mostly the same place as the traditional four freedoms. But importantly for the discussion of “open in AI”, replication and transparency require a focus on data, while for many businesses (and certainly for most developers) weights are sufficient and may well be preferred in many/most cases.

One could imagine other use cases and priorities, of course. But I wanted to bang this out quick and there was a nice symmetry to having four. Leave more on the various socials :)

It’s that time again, and we are in our 7th year doing this conference (if you include LAS GNOME).

This year, LAS will be held in Tirana, Albania and we are going all out this year to make it the best conference representing apps on Linux.

For those who don’t know or have not heard of Linux App Summit, the idea is to have desktops work together to help enable application developers to build apps on the Linux platform. It’s a parallel effort to the Flathub and Snapstore app stores.

LAS is positioned to promote third party developers, inform the ecosystems are the advances on the desktop, and for developers, designers, and contributors working on the desktops to meet each other and discuss how to move the platform forward as a community.

LAS’s success depends on all of you. If you’re passionate about making Linux as a viable alternative to proprietary platform then we need your help! Linux enables local control of your technology that you can adapt to your needs. Build local ecosystems enabling a local economy. A community driven platform will protect your privacy, safety, and security without bowing to shareholders or to politicians. This is the place to tell us about it!

So, I ask all of you to attend LAS, help drive our numbers up. Have a great idea that you won’t to share with this ecosystem of developers? Implemented something on a phone, in an automobile, or something else? Have a great concept? Want to update all of us on what the next version of your app is going to do?

Through here, we can find out what is missing? What do we need to do move forward? What are the trends we should be looking at?

Feel free to reach out to our team and we’ll be happy to answer any questions at info@linuxappsummit.org.

You can submit a talk at https://iinuxappsummit.org/cfp. You can register for the conference at https://linuxappsummit.org/register.

Can’t come in person or give the talk in person? Not to worry! LAS is a hybrid conference and you can attend from remote even though we would love to meet you in person.

Finally, we are looking for sponsors. If you know of a company who would make a great sponsor please reach out. If you’re interested in sponsoring LAS, you can email us at sponsors@linuxappsummit.org. For more info at https://linuxappsummit.org/sponsor.

 

 

As my Outreachy internship with GNOME concludes, I’m reflecting on the journey, the effort, the progress, and, most importantly, the future I envision in tech.

The past few months as an intern have been both challenging and incredibly rewarding. From quickly learning a new programming language to meet project demands, to embracing test-driven development and tackling progressively complex tasks, every experience has been a stepping stone. Along the way, I’ve honed my collaboration and communication skills, expanded my professional network, and developed a deep appreciation for the power of community and open source.

This Outreachy internship has been a pivotal experience, solidifying these values and teaching me the importance of embracing challenges and continuously improving my technical and interpersonal skills, preparing me for the next stage of my engineering career. The supportive environment I found in the GNOME community has been instrumental to my growth. I’m incredibly grateful for my mentor, Federico, who exemplified what true mentorship should be. He showed me the importance of collaborative spirit, genuine understanding of team members, and even taking time for laughter – all of which made transitioning to a new environment seamless and comfortable. His guidance fostered open communication, ensuring seamless synchronization and accessibility. Just before writing this, I had a call with Federico, Felipe (the GNOME Internship Coordinator, an awesome person!), and Aryan to discuss my career post-internship.

While the career advice was invaluable, what truly stood out was their collaborative willingness to support my growth. This dedication to fostering progress is something I deeply admire and will strive to make a core part of my own engineering culture.

My journey from intern to engineer has been significantly shaped by the power of community, and I’m now ready to push myself further, take on new challenges, and build a solid, impactful, and reputable career in technology.

Skills

I possess a strong foundation in several key technologies essential for software and infrastructure engineering.

My primary languages are Golang and Rust, allowing me to build high-performance and reliable systems. I also have experience with Python. I’m a quick learner and eager to expand my skillset further.

Career Goals

My ultimate career aspiration is to secure a role that challenges me to grow as an engineer while contributing to impactful and innovative projects. I am particularly drawn to:

• • Cultivating a culture of creativity and structured development while optimizing myself to become the best engineer I can be—just like my Outreachy experience.
  • Developing and sustaining critical infrastructure that powers large-scale, globally utilized systems, ensuring reliability, security, and seamless operation.
  • Exploring opportunities at MANGA or other big tech companies to work on complex systems, bridging software engineering, security, and infrastructure.

motivations

While the challenge of growth is my primary motivation, the financial stability offered by these roles is also important, enabling me to further invest in my personal and professional development.

Relocation is a significant draw, offering the opportunity to experience different cultures, gain new perspectives and immerse myself in a global engineering community.

As an introverted and private person, I see this as a chance to push beyond my comfort zone, engage with a diverse range of collaborators, and build meaningful connections.

Job Search

I am actively seeking software engineering, infrastructure, and site reliability roles. I am particularly interested in opportunities at large tech companies, where I can contribute to complex systems and further develop my expertise in Golang and Rust after concluding my Outreachy internship with Gnome is concluded in march 2025.

exploring the opportunities

I’m eager to explore software engineering, open source, infrastructure, and site reliability roles. If your team is seeking someone with my skills and experience, I’d welcome a conversation. Connect with me via email or LinkedIn.

I’m excited about the future and ready to take the next step in my career. With the foundation I’ve built during this internship, I’m confident in my ability to make a meaningful impact in the tech industry

We just had a GTK hackfest at FOSDEM. A good time for an update on whats new and exciting in GTK, with an eye towards 4.18.

Requirements

You can no longer call gdk_display_get_default() or gdk_display_open() before gtk_init(). This was causing problems due to incomplete initialization, so we made it fail with a (hopefully clear) error message. If you are affected by this, the usual fix is to just call gtk_init() as early as possible.

On Windows, we have a hard requirement on Windows 10 now. All older versions are long unsupported, and having to deal with a maze of ifdefs and unavailable APIs makes development harder than it should be. Dropping support for very old versions also simplifies the code down the stack, in Pango and GLib.

The same idea applies to macOS, where we now require macOS 10.15.

Spring cleaning

The old GL renderer has been removed. This may be unwelcome news for people stuck on very old drivers and hardware. But we will continue to make the new renderers work as well as possible on the hardware that they can support.

The X11 and Broadway backends have been deprecated, as a clear signal that we intend to remove them in the GTK 5. In the meantime, they continue to be available. We have also deprecated GtkShortcutsWindow, since it needs a new design. The replacement will appear in libadwaita, hopefully next cycle.

It is worth reminding everybody that there is no need to act on deprecations until you are actively porting your app to the next major version of GTK, which is not on the horizon yet.

Incremental improvements

Widget layout and size allocation has received quite a bit of attention this cycle, with the goal of improving performance (by avoiding binary search as much as possible) and correctness. Nevertheless, these changes have some potential for breakage, so if you see wrong or suboptimal layouts in applications, please let us know.

GTK has had difficulties for a while getting its pointer sizes right with fractional scaling on Wayland, but this should all be solved in GTK 4.18. No more huge pointers. Fixing this also required changes on the mutter side.

New beginnings

Accessibility in GTK 4.18 is taking a major step forward, with the new AccessKit backend, which gives us accessibility on  Windows and macOS, for the very first time. The at-spi backend is still the default on Linux, and has seen a number of improvements as well.

And, maybe the biggest news: We have an Android backend now. It is still experimental, so you should expect some rough edges and loose ends. For example, there is no GL renderer support yet. But it is exciting that you can just try gtk4-demo on your phone now, and have it mostly work.

Enjoy!

Introduction Built on jj and fzf, jj-fzf offers a text-based user interface (TUI) that simplifies complex versioning control operations like rebasing, squashing, and merging commits. This post will guide you through integrating jj-fzf into your Emacs workflow, allowing to switch between emacs and jj…

I finally got distracted enough to finish my website that has been saying "under construction" for over a year, since I set up this server for my Sharkey instance.

I've wanted to do this for a while - one, so that I actually have a home page, and two, so that I can move my blog here instead of using WordPress.

Setup

Initially I wanted to use a static generator like Hugo, but then I discovered that the web server I'm using (Caddy) can do templates. That's perfectly enough for a simple blog, so I don't actually need a separate generator. This very article is a markdown document, parsed and embedded into a nice-looking page and RSS feed using templates.

In addition, I get all the niceties I couldn't get before:

• Using Markdown instead of HTML with WordPress-specific additions for e.g. image galleries.

• Proper code listings with syntax highlighting (you'll have to view this on the original page though, not from Planet GNOME or your RSS reader):

  <property name="child"> <object class="AdwToastOverlay" id="toast_overlay"> <property name="child"> <object class="AdwNavigationView" id="nav_view"/> </property> </object> </property>

• Dark mode support, incl. for images (again, no clue if this works on Planet GNOME):

  Me writing this very post in Apostrophe

• Just simple niceties like smaller monospace font - I do this a lot and I don't particularly like the way the WordPress theme I was using presents it.

• Finally, while migrating my old posts I had an opportunity to update broken links (such as to the old documentation) and add missing alt text as in quite a few images I set WordPress description instead of alt text and never noticed. If you really want the old version, it's still on the old website and each migrated article links to its original counterpart.

So yeah, so far this was fairly pleasant, I expected much worse. There are still a bunch of things I want to add (e.g. previewing images at full size on click), but it's not like my old blog had that either.