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.

In the past I may have spoken critically on Truetype fonts and their usage in PDF files. Recently I have come to the conclusion that it may have been too harsh and that Truetype fonts are actually somewhat nice. Why? Because I have had to add support for CFF fonts to CapyPDF. This is a font format that comes from Adobe. It encodes textual PostScript drawing operations into binary bytecode. Wikipedia does not give dates, but it seems to have been developed in the late 80s - early 90s. The name CFF part is an abbeviation for "complicated font format".

Double-checks notes.

Compact font format. Yes, that is what I meant to write. Most people reading this have probably not ever even seen a CFF file so you might be asking why is supporting CFF fonts even a thing nowadays? It's all quite simple. Many of the Truetype (and especially OpenType) fonts you see are not actually Truetype fonts. Instead they are Transfontners, glyphs in disguise . It is entirely valid to have a Truetype font that is merely an envelope holding a CFF font. As an example the Noto CJK fonts are like this. Aggregation of different formats is common in font files, and the main reason OpenType fonts have like four different and mutually incompatible ways of specifying color emoji. None of the participating entities were willing to accept anyone else's format so the end result was to add all of them. If you want Asian language support, you have to dive into the bowels of the CFF rabid hole.

As most people probably do not have sufficient historical perspective, let's start by listing out some major computer science achievements that definitely existed when CFF was being designed.

• File format magic numbers
• Archive formats that specify both the offset and size of the elements within
• Archive formats that afford access to their data in O(number of items in the archive) rather than O(number of bytes in the file)
• Data compression

CFF chooses to not do any of this nonsense. It also does not believe in consistent offset types. Sometimes the offsets within data objects refer to other objects by their order in the index they are in. Sometimes they refer to number of bytes from the beginning of the file. Sometimes they refer to number of bytes from the beginning of the object the offset data is written in. Sometimes it refers to something else. One of the downsides of this is that while some of the data is neatly organized into index structures with specified offsets, a lot of it is just free floating in the file and needs the equivalent of three pointer dereferences to access.

Said offsets are stored with a variable width encoding like so:

This makes writing subset CFF font files a pain. In order to write an offset value at some location X, you first must serialize everything up to that point to know where the value would be written. To know the value to write you have to serialize the the entire font up to the point where that data is stored. Typically the data comes later in the file than its offset location. You know what that means? Yes, storing all these index locations and hotpatching them afterwards once you find out where the actual data pointed to ended up in. Be sure to compute your patching locations correctly lest you end up in lengthy debugging sessions where your subset font files do not render correctly. In fairness all of the incorrect writes were within the data array and thus 100% memory safe, and, really, isn't that the only thing that actually matters?

One of the main data structures in a CFF file is a font dictionary stored in, as the docs say, "key-value pairs". This is not true. The "key-value dictionary" is neither key-value nor is it a dictionary. The entries must come in a specific order (sometimes) so it is not a dictionary. The entries are not stored as key-value pairs but as value-key pairs. The more accurate description of "value-key somewhat ordered array" does lack some punch so it is understandable that they went with common terminology. The backwards ordering of elements to some people confusion bring might, but it perfect sense makes, as the designers of the format a long history with PostScript had. Unknown is whether some of them German were.

Anyhow, after staring directly into the morass of madness for a sufficient amount of time the following picture emerges.

Final words

The CFF specification document contains data needed to decipher CFF data streams in nice tabular format, which is easy to convert to an enum. Trying it fails with an error message saying that the file has prohibited copypasting. This is a bit rich coming from Adobe, whose current stance seems to be that they can take any document opened with their apps and use it for AI training . I'd like to conclude this blog post by sending the following message to the (assumed) middle manager who made the decision that publicly available specification documents should prohibit copypasting:

YOU GO IN THE CORNER AND THINK ABOUT WHAT YOU HAVE DONE! AND DON'T EVEN THINK ABOUT COMING BACK UNTIL YOU ARE READY TO APOLOGIZE TO EVERYONE FOR YOU ACTIONS!

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.

• Breakfast, to the venue with some friends; pottered around talking to people, spoke briefly in the Government dev-room to lots of friendly faces.
• Lunch, got chatting in the queue for chips to several interesting people; back to the booth - before heading back and out to Kasbah in the evening - for a mercifully belly-dancing-free meal.
• Back to chat to Caolan & his lovely daughter - it was bring-a-family-member-to-work weekend, catch up until late.

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

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

• Motivation

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