A few months have passed since New Responsibilities was posted, so I thought I would provide an update.

Projects Maintenance

Of all the freedesktop projects I created and maintained, only one doesn't have a new maintainer, low-memory-monitor.

This daemon is what the GMemoryMonitor GLib API is based on, so it can't be replaced trivially. Efforts seem to be under way to replace it with systemd APIs.

As for the other daemons:

• switcheroo-control got picked up by Jonas Ådahl, one of the mutter maintainers. I'm looking forward to seeing this merge request fixed so we can have better menu items on dual-GPU systems
• iio-sensor-proxy added Dylan Van Assche to its maintenance team, assisting Guido Günther.
• power-profiles-daemon is now maintained by Marco Trevisan. It recently got support for separate system and CPU power profiles, and display power saving features are in the works.

(As an aside, there's posturing towards replacing power-profiles-daemon with tuned in Fedora. I would advise stakeholders to figure out whether having a large Python script in the boot hot path is a good idea, taking a look at bootcharts, and then thinking about whether hardware manufacturers would be able to help with supporting a tool with so many moving parts. Useful for tinkering, not for shipping in a product)

Updated responsibilities

Since mid-August, I've joined the Platform Enablement Team. Right now, I'm helping out with maintenance of the Bluetooth kernel stack in RHEL (and thus CentOS).

Blog backlog

Before being moved to a different project, and apart from the usual and very time-consuming bug triage, user support and project maintenance, I also worked on a few new features. I have a few posts planned that will lay that out.

FOSDEM 2024—a free event for software developers to meet, share ideas, and collaborate—is this coming weekend in Brussels, Belgium and we'll be there! Learn where you can find us or even sit down and discuss Flathub itself, metadata and build validation, upcoming changes, and anything else on your mind.

BoF: Saturday 16:00 CET​

The FOSDEM website describes BoFs pretty well:

BOF stands for Birds Of a Feather who, as the saying goes, flock together. FOSDEM has three meeting rooms that may be booked in 30 or 60 minute blocks for discussions. All the meetings are public so anyone who is interested can attend if there is enough space.

We've reserved a BoF room for Saturday, February 3 at 16:00 local time (CET, UTC+1); seating is on a first-come, first-served basis, so arrive promptly! We'll be meeting to discuss recent developments around metadata and build validation, other upcoming changes, and anything else on the minds of the attendees. Check the event for the exact room details (and any scheduling changes).

We hope to see you there!

Stands​

Various Flathub and Flatpak folks can also be found around associated stands:

• Kodi: building H, level 1, stand 4
• GNOME: building H, level 1, stand 5
• KDE: building H, level 1, stand 6
• Fedora Project: building AW, level 1, booth 4
• Linux on Mobile: building AW, level 1, booth 7

Find us to chat about Flathub, app submission and maintenance, Flatpak, and the Linux desktop app ecosystem.

I’m a firm believer in the importance of documentation for open source projects, particularly when it comes to onboarding new contributors. To attract and retain contributors, you need good docs.

Those docs aren’t just important for practical information on how to contribute (though that is important). They’re also important when it comes to understanding the more general aspects of a project, like how decisions are made, who the stakeholders are, what the history is, and so on. For new contributors, understanding these aspects of a project is essential to being able to participate. (They are also the aspects of a project that established contributors often take for granted.)

Of course, ensuring that you always have up to date project documentation isn’t easy. This is particularly true for large, long-running projects, where the tendency is for large amounts of documentation to get written and then eventually left to rot. As redundant and inaccurate docs accumulate, they increasingly misdirect and impede contributors.

This characterization has unfortunately has been true for GNOME for some time. For many years, the main source of project documentation has been the wiki and, for a long time, the vast majority of that wiki content has been either inaccurate or redundant. We can only assume that, with so much out of date information floating around, countless hours of have been lost, with existing contributors struggling to find the information they need, and new potential contributors being put off before they have even gotten started.

Enough with the preamble

The poor state of GNOME’s documentation has been something that I’ve wanted to tackle for some time, so it’s with great excitement that I’m happy to announce a new, completely rewritten documentation resource for the project: the GNOME Project Handbook (otherwise known as handbook.gnome.org).

The handbook is a new website whose goal is to provide accessible, well-maintained documentation about how to get stuff done within GNOME. It has a specific scope: it does not provide technical documentation for those using GNOME technologies, nor does it contain user documentation, nor does it attempt to provide public-facing home pages for apps and libraries. What it does contain is the information required to operate as a GNOME contributor.

The fact that handbook.gnome.org is able to have this relatively tight focus is thanks to a collection of other GNOME sites, each of which replaces a role previously played by the wiki. This includes apps.gnome.org, developer.gnome.org, and welcome.gnome.org. Thank you to the creators of those resources!

The handbook site itself is managed like any other GNOME project. There’s a repository that generates the site, issues can be reported, and changes can be proposed through merge requests. The hope is that this will avoid many of the maintenance issues that we previously had with the wiki.

Notable content

The handbook is composed of pages from the wiki, which have largely been rewritten, plus a decent amount of original content. There are some sections which I’m particularly excited about, and want to highlight.

Issue tracker guidelines

GNOME has had issue reporting and triage guidelines for almost two decades. However, it has been many years since they were actively maintained, and they were never updated when GNOME migrated from Bugzilla to GitLab. I think that a lot of contributors have forgotten that they even exist.

The handbook includes a fresh set of issue tracking guidelines, which have been updated for the modern era. They’re based on the old ones from many years ago, but have been substantially revised and expanded. The new guidelines cover how to report an issue, how to review issues for quality and relevance, and policies and best practices for maintainers. One exciting new aspect is guidelines for those who want to get started with issue review as a new contributor.

I’m hopeful that having clear processes and guidelines around issue tracking will have an enabling effect for contributors and maintainers, so they can be more forthright when it comes to issue management, and in so doing get our issues trackers into a better state.

Governance

The handbook has a page on governance! It describes how decisions are made in GNOME, the various roles in the project, who has authority, and how the project works. Us old hands tend to assume this stuff, but for new contributors it’s essential information, and we never documented it before.

How to submit a code change

Amazingly — incredibly! — until this day, GNOME has not documented how to submit a code change to the project. We just left people to figure it out by themselves. This is something that the handbook covers. If you’ve ever wanted to submit a change to GNOME and haven’t known how, give it a read over.

Infrastructure

The infrastructure pages aren’t new, but they were previously causing some confusion and so have been substantially rewritten. The new pages aim to make it really clear which services are available, how developer permissions are managed, and how to get access when you need it.

What next?

It’s still early days for the handbook. Most of the core content is in, but there will be issues and missing pieces. If you spot any problems, there’s an issue tracker. You can also submit merge requests or make suggestions (the project README has more information on this).

The plan is to retire the wiki. An exact time line for this has yet to be set (there will be an announcement when that happens). However, it’s encouraged to consult the handbook rather than the wiki from this point forward and, if you’re continuing to use the wiki for anything, to move that content elsewhere. There’s a migration guide with details about how to do this.

Many thanks to those who have helped with this project, including but not limited to: Jakub Steiner, Andrea Veri, Emmanuele Bassi, Michael Catanzaro, Brage Fuglseth, Florian Muellner, Alexandre Franke, Sebastian Wick, and Kolja Lampe.

This year’s GUADEC is going to be in the USA, making it difficult to attend both for Visa/border control reasons and because it’s not easy to get to from Europe without flying. Many of us want to avoid the massive emissions in particular (around 3 tons of CO2, which is half the yearly per-capita emissions in most European countries). If that’s you, too, you’re in luck because we’re doing yet another edition of the fabulous Berlin Mini GUADEC!

Berlin has one of the largest GNOME local groups in the world, and is relatively easy to get to from most of Europe by train (should be even easier now thanks to new night train options). At our last Mini GUADEC in 2022 we had people join from all over Europe, including Italy, Belgium, Czech Republic, and the UK.

The local Berlin community has grown steadily over the past few years, with regular events and local hackfests such as the Mobile and Local-first hackfests last year, including collaborations with other communities (such as postmarketOS and p2panda). We hope to make this year’s Mini GUADEC another opportunity for friends from outside the project to join and work on cool stuff with us.

We’re still in the process of figuring out the venue, but we can already announce that the 2024 Mini GUADEC will cover both the conference and BoF days (July 19-24), so you can already mark it on your calendars and start booking trains :)

If you already know you’re going to join, feel free to sign up by adding your name to this Hedgedoc, and join the Matrix room. If you don’t have a GNOME account, please email berlinminiguadec@mailup.net to let us know you’re coming.

See you in Berlin!

This is a follow-up from our Spam-label approach, but this time with MOAR EMOJIS because that's what the world is turning into.

Since March 2023 projects could apply the "Spam" label on any new issue and have a magic bot come in and purge the user account plus all issues they've filed, see the earlier post for details. This works quite well and gives every project member the ability to quickly purge spam. Alas, pesky spammers are using other approaches to trick google into indexing their pork [1] (because at this point I think all this crap is just SEO spam anyway). Such as commenting on issues and merge requests. We can't apply labels to comments, so we found a way to work around that: emojis!

In GitLab you can add "reactions" to issue/merge request/snippet comments and in recent GitLab versions you can register for a webhook to be notified when that happens. So what we've added to the gitlab.freedesktop.org instance is support for the :do_not_litter: (🚯) emoji [2] - if you set that on an comment the author of said comment will be blocked and the comment content will be removed. After some safety checks of course, so you can't just go around blocking everyone by shotgunning emojis into gitlab. Unlike the "Spam" label this does not currently work recursively so it's best to report the user so admins can purge them properly - ideally before setting the emoji so the abuse report contains the actual spam comment instead of the redacted one. Also note that there is a 30 second grace period to quickly undo the emoji if you happen to set it accidentally.

Note that for purging issues, the "Spam" label is still required, the emojis only work for comments.

Happy cleanup!

[1] or pork-ish
[2] Benjamin wanted to use :poop: but there's a chance that may get used for expressing disagreement with the comment in question

Recently, GTK gained not one, but two new renderers: one for GL and one for Vulkan.

Since naming is hard, we reused existing names and called them “ngl” and “vulkan”. They are built from the same sources, therefore we also call them “unified” renderers.

But what is exciting about them?

A single source

As mentioned already, the two renderers are built from the same source. It is modeled to follow Vulkan apis, with some abstractions to cover the differences between Vulkan and GL (more specifically, GL 3.3+ and GLES 3.0+). This lets us share much of the infrastructure for walking the scene graph, maintaining transforms and other state, caching textures and glyphs, and will make it easier to keep both renderers up-to-date and on-par.

Could this unified approach be extended further, to cover a Metal-based renderer on macOS or a DirectX-based one on Windows? Possibly. The advantage of the Vulkan/GL combination is that they share basically the same shader language (GLSL, with some variations). That isn’t the case for Metal or DirectX. For those platforms, we either need to duplicate the shaders or use a translation tool like SPIRV-Cross.

If that is the kind of thing that excites you, help is welcome.

Implementation details

The old GL renderer uses simple shaders for each rendernode type and frequently resorts to offscreen rendering for more complex content. The unified renderers have (more capable) per-node shaders too, but instead of relying on offscreens, they will also use a complex shader that interprets data from a buffer. In game programming, this approach is known as a ubershader.

The unified renderer implementation is less optimized than the old GL renderer, and has been written with a focus on correctness and maintainability. As a consequence, it can handle much more varied rendernode trees correctly.

Here is an harmless-looking example:

repeat {
  bounds: 0 0 50 50;
  child: border {
    outline: 0 0 4.3 4.3;
    widths: 1.3;
  }
}

New capabilities

We wouldn’t have done all this work, if there wasn’t some tangible benefit. Of course, there’s new features and capabilities. Lets look at some:

Antialiasing. A big problem with the old GL renderer is that it will just lose fine details. If something is small enough to fall between the boundaries of a single line of pixels, it will simply disappear. In particular this can affect  underlines, such as mnemonics. The unified renderers handle such cases better, by doing antialiasing. This helps not just for preserving fine detail, but also prevents jagged outlines of primitives.

Fractional scaling. Antialiasing is also the basis that lets us handle fractional scales properly. If your  1200 × 800 window is set to be scaled to 125 %, with the unified renderers, we will use a framebuffer of size 1500 × 1000 for it, instead of letting the compositor downscale a 2400 × 1600 image. Much less pixels, and a sharper image.

Arbitrary gradients. The old GL renderer handles linear, radial and conic gradients with up to 6 color stops. The unified renders allow an unlimited number of color stops. The new renderers also apply antialiasing to gradients, so sharp edges will have smooth lines.

Dmabufs. As a brief detour from the new renderers, we worked on dmabuf support and graphics offloading last fall. The new renderers support this and extend it to create dmabufs when asked to produce a texture via the render_texture api (currently, just the Vulkan renderer).

Any sharp edges?

As is often the case, with new capabilities comes the potential for new gotchas. Here are some things to be aware of, as an app developer:

No more glshader nodes. Yes, they made for some fancy demos for 4.0, but they are very much tied to the old GL renderer, since they make assumptions about the GLSL api exposed by that renderer. Therefore, the new renderers don’t support them.

You have been warned in the docs:

If there is a problem, this function returns FALSE and reports an error. You should use this function before relying on the shader for rendering and use a fallback with a simpler shader or without shaders if it fails.

Thankfully, many uses of the glshader node are no longer necessary, since GTK has gained new features since 4.0, such as mask nodes and support for straight-alpha textures.

Fractional positions. The old GL renderer is rounding things, so you could get away with handing it fractional positions. The new renderers will place things where you tell it. This can sometimes have unintended consequences, so should be on the lookout and make sure that your positions are where they should be.

In particular, look out for out for cairo-style drawing where you place lines at half-pixel positions so they fill out one row of pixels precisely.

Driver problems. The new renderers are using graphics drivers in new and different ways, so there is potential for triggering problems on that side.

Please file problems you see against GTK even if they look like driver issues, since it is useful for us to get an overview how well (or badly) the new code works with the variety of drivers and hardware out there.

But is it faster?

No, the new renderers are not faster (yet).

The old GL renderer is heavily optimized for speed. It also uses much simpler shaders, and does not do the math that is needed for features such as antialiasing. We want to make the new renderers faster eventually, but the new features and correctness make them very exciting, even before we reach that goal. All of the GPU-based renderers are more than fast enough to render todays GTK apps at 60 or 144 fps.

That being said, the Vulkan renderer comes close to matching and surpassing the old GL renderer in some unscientific benchmarks. The new GL renderer is slower for some reason that we have not tracked down yet.

New defaults

In the just-released 4.13.6 snapshot, we have made the ngl renderer the new default. This is a trial balloon — the renderers need wider testing with different apps too verify that they are ready for production. If significant problems appear, we can revert back to the gl renderer for 4.14.

We decided not make the Vulkan renderer the default yet, since it is behind the GL renderers in a few application integration aspects: the webkit GTK4 port works with GL, not with Vulkan, and GtkGLArea and GtkMediaStream currently both produce GL textures that the Vulkan renderer can’t directly import. All of these issues will hopefully be addressed in the not-too-distant future, and then we will revisit the default renderer decision.

If you are using GTK on very old hardware, you may be better off with the old GL renderer, since it makes fewer demands on the GPU. You can override the renderer selection using the GSK_RENDERER environment variable:

GSK_RENDERER=gl

Future plans and possibilities

The new renderers are a good foundation to implement things that we’ve wanted to have for a long time, such as

• Proper color handling (including HDR)
• Path rendering on the GPU
• Possibly including glyph rendering
• Off-the-main-thread rendering
• Performance (on old and less powerful devices)

Some of these will be a focus of our work in the near and medium-term future.

Summary

The new renderers have some exciting features, with more to come.

Please try them out, and let us know what works and what doesn’t work for you.

GNOME is partipating in the December 2023 – February 2024 round of Outreachy. As part of this project, our interns Dorothy Kabarozi and Tanju Achaleke have extended our end-to-end tests to cover some of GNOME’s accessibility features.

End-to-end testing, also known as UI testing, involves simulating user interactions with GNOME’s UI. In this case we’re using a virtual machine which runs GNOME OS, so the tests run on the latest, in-development version of GNOME built from the gnome-build-meta integration repo. The tests send keyboard & mouse events to trigger events in the VM, and use fuzzy screenshot comparisons to assert correct behavior. We use a tool called openQA to develop and run the tests.

Some features are easier to test than others. So far we’ve added tests for the following accessibility features:

• High contrast theme
• Large text theme
• Always-visible scrollbars
• Audio over-amplification (boost volume above 100%)
• Visual alerts (flash screen when the error ‘bell’ sound plays)
• Text-to-speech using Speech Dispatcher
• Magnifier (zoom)
• On-screen keyboard

In this screenshot you can see some of the tests:

Here’s a link to the actual test run from the screenshot: https://openqa.gnome.org/tests/3058

These tests run every time the gnome-build-meta integration repo is updated, so we can very quickly detect if a code change in the ‘main’ branch of any GNOME module has unintentionally caused a regression in some accessibility feature.

• GNOME’s accessibility features are seeing some design and implementation improvements at the moment, thanks to several volunteer contributors, investments from the Sovereign Tech Fund and Igalia, and more. As improvements land, the tests will need updating too. Screenshots can be updated using openQA’s web UI, available at https://openqa.gnome.org, there are instructions available. The tests themselves live in openqa-tests.git and are simple Perl programs using openQA’s testapi. Of course merge requests to extend and improve the tests are very welcome.

One important omission from the testsuite today is Orca, the GNOME screen reader. Tanju spent a long time trying to get this to work, and we do have a test that verifies text-to-speech using Speech Dispatcher. Orca itself is more complicated and we’ll need to spend more time to figure out how best to set up end-to-end tests for screen reading.

If you have feedback on the tests, we’d love to hear from you over on the GNOME Discourse forum.

And if you did not know already, that Core app is Evince, now renamed to Papers and submitted to Incubation this week. But if you’re still interested after the spoiler, let’s start from the beginning.

From some hacky patches to 80+ Merge Requests

How it all started

So for anybody that does not know me, I have been until now foremost a postmarketOS maintainer. GNOME is my platform of choice, and we often encounter bugs downstream. However, postmarketOS’s policy is upstream first, so I ended up doing a lot of things in GNOME. Most of those were small patches for various projects, and many of the issues we had with sizing and Phone usage have been polished through the years with help from people all across the stack. A big chunk of those was fixed through GTK4 ports and implementing new libadwaita patterns and widgets. However, Evince seemed to have been stuck on porting to GTK4, and we were still carrying some ugly patches. So I tried to do my best, and more than 1 and a half year ago pushed my first MR. What followed was a roller-coaster of emotions.

How it all continued

Sending a first patch to a project is something I have learned to really enjoy. It has that mix of excitement for the unknown, looking forward to that this is great, thanks, and the knowledge that I will certainly learn something in the process. But since one patch would not get a massive GTK4 MR solved, I did not stop there, and continue pushing MRs. After some time, I learned some things:

• Germán was the only active maintainer. So sometimes, things would move fast and he would merge a bunch of my MRs altogether. And sometimes they would stay there without a comment for weeks. And certainly time to answer questions and get me on-boarded into decades-old Evince code was certainly sparse. The few times he was able to, I learned a bunch, but it was still too little for the time I had available.
• Evince code is old, for the good, and for the bad. For the good, it concentrates the wisdom of years of development creating a Document Viewer. The authors had taken and tested many design decisions, and overall created a very solid application. For the bad, there was code that probably already existed in pre-glib times. And many things that are now straight-forward to do, had been re-implemented in a custom way. I am still very proud of having removed some non-functional code that if alive would have the right to vote in most countries that do.
• Evince is not just an application, but two libraries, libdocument and libview, which must remain stable. So many of the cleanups I would have wished to do would had to wait.

All these things created a dynamic where: I would have lots of time and motivation; hack in Evince to do some cleanups and forward-port stuff from the GTK4 MR; feel super happy about it and send some MRs; wait for some period that felt long to get any feedback; get totally demotivated about it; sometimes wait some more weeks until getting feedback, context-switching to something else; then get some feedback, but feel bad about it; finally get some motivation back, address the feedback, and back to the beginning. Of course, this wasn’t sustainable.

Getting help and reaching for help

In the middle of this process, FOSDEM 2023 happened. And it was a wonderful experience. I got to meet all these postmarketOS people I had been working with for more than a year, as well as many GNOME people from whom I knew, but that were certainly less aware of me. Despite that, everybody was super welcoming, and encouraging. And specially Tobias pushed me a bit and managed to get me apply for a grant (that I did not get) to improve Evince. In that process, we tried to approach Germán to talk, and see how could I help with Evince from a more “maintainership” role. Unfortunately, that did not work out. However, that did not solve the adaptability problems for Evince in mobile, so I had to continue trying.

Through all this process, Qiu Wenbo, the author of Evince’s GTK4 port, had continued to tirelessly rebase the GTK4 port on whichever changes we did. And we started to interact, as I moved from back-porting things to reviewing their MR more in-depth. But we still would not get where we wanted to be at full-speed with Germán’s limited time availability. So I reached to the Release Team at GUADEC, and then again some months later, and managed to schedule a very nice call with Germán. We talked about Evince, how would it be possible for me to help, and he created the evince-next branch. There it was (and still is) allowed to break the libraries’ API, remove deprecated functions and be less conservative. Of course, Qiu Wenbo and I sent a lot of MRs, and I tried to get myself entitled to merge stuff, but I was certainly not the main maintainer, and most things still needed Germán’s review. At some point, things to back-port run out. Any work I would like to do would require some hard and careful rebase of the GTK4 branch, and Qiu Wenbo had already context-switched to improvements after the port. It was clear, unfortunately, that the amount of human-power we were able to provide was well above Germán’s availability, and therefore, the changes we were dreaming of likely not fitting within Evince.

From a casual chat to Incubation in less than two months

Forking was an option that had been suggested to me since FOSDEM, and reiterated multiple times later. At first, I did not feel ready to take over the code-base. And when I did, I was terrified to do so alone. So mid-December, I asked Qiu Wenbo if he would be willing to fork and maintain the fork with me, with the goal of porting to GTK4, implement new mockups, and modernize the application. He was extremely enthusiastic about the idea, so we started to work on it, notifying both the Release Team and Germán. Our goal was getting the GTK4 MR in by the (gregorian) New Year, to then take care of the breakage later. And I have to admit, the results of the fork are already surpassing all my expectations. In less than 2 months, we’ve managed to merge close to 40 MRs, and already got some external contributors (Chris and FineFindus, yay!), with more people having showed interest. We also started the rebranding (still missing a slick icon!), and this week, applied with Papers for Incubation.

So the overall outcome, nowadays, is net positive. Although it will all depend a bit on the Incubation phase. At the same time, a fork is most of the times the result of some sort of failure. Probably not just of us individual contributors, but of the community as a whole. It is also a big shame to not have Germán next to us in this process. He holds extremely valuable knowledge about PDFs and documents in general, and certainly avoided me messing up more than once. At the same time, life is life, and we’re all volunteers doing our best. I can say, I am sincerely thankful from everything he has taught me, and wish him success in their endeavors. For us, we hope to see Papers flourish, and encourage others to jump on the train to make a modern, adaptive, touch, and multi-device-friendly document viewer for GNOME.

Happy Hacking!

Earlier this month we shared new app metadata guidelines in response to the growth and maturity of Flathub. Today we're proud to share about that growth in a bit more detail including a huge milestone, how we calculate stats, and what we believe is driving that growth.

Milestones​

To date, Flathub has served a total of 1.6 billion downloads of over 2,400 apps and their updates.

Since introducing verified apps last year, over 850 apps have been verified by their original authors; more than one third of all apps, with that number constantly increasing.

And finally, we're thrilled to announce that Flathub has surpassed one million active users. 🎉️

How We Measure Growth​

We have a public dashboard that shares some basic statistics, powered by an open source script. We don't track individual metrics from end user machines; instead, we look at downloads of specific artifacts from the Flathub infrastructure itself. This gives us a count of installs and updates over time, downloads per country (based on the origin of requests), and some derivative data like downloads of apps in different categories.

But how can we measure how many active users we have?

Since Flathub necessarily serves downloads of Flatpak runtimes (common platforms on which apps are built), we can estimate active users fairly well. For example, when installing or updating many apps, Flatpak will automatically install the base FreeDesktop SDK runtime on which the KDE and GNOME runtimes (and most other apps) are built. We can look at the number of downloads of updates to a recent release of this runtime to estimate how many active installs are out there getting Flatpaks from Flathub.

This methodology reveals that over the past few months there have been over a million updates of each of the latest FreeDesktop SDK runtime releases, meaning we've passed the one million active user mark.

If you'd like to explore more of this data yourself, there's this handy dashboard by Kristian Klausen (source), or you can always chat with us in #flathub on Matrix.

What's Driving Growth​

We attribute the growth of Flathub to a few developments over the years, and especially the last several months:

1. Popular app availability: Since we started Flathub, we've seen apps like Firefox, Google Chrome, Discord, VLC, Spotify, Telegram, Microsoft Edge, Steam, OBS Studio, Zoom, Thunderbird, and many more make their way into the store. These are many of the apps people want and expect, especially if they're coming to a Linux desktop for the first time. Each time another popular app hits Flathub, it makes both Flathub and Linux that much more compelling to users.

2. Verified apps: We've heard that some folks have held off installing specific apps or even using Flathub altogether because they didn't want a third-party maintainer redistributing an app they rely on; verifying apps solves this by assuring users their favorite app is actually coming from its developer. With an ever-increasing number of apps choosing to get verified—including both big names and many newer indie apps—the trust and adoption of Flathub increases.

3. Steam Deck: It's not just a meme; we suspect Flathub being included as the default app source for the Steam Deck's desktop mode has had a large positive effect on the usage of Flathub. Just look at some of the most popular apps: retro game emulators, game compatibility tools, gaming-oriented chat services, alternate game launchers—all the kinds of apps you'd expect Steam Deck users to want. And in fact, "game" is the single most common category of app on Flathub. It turns out selling "multiple millions" of devices has an impact on the ecosystem!

4. Linux distro adoption: In addition to shipping on Steam Deck, Flathub now comes included out of the box on at least Clear Linux, Endless OS, KDE Neon, Linux Mint, Pop!_OS, and Zorin OS—and as of Fedora 38, Flathub is available in its entirety when enabling third-party software sources. Flathub is the preferred app store for Linux, and its grassroots adoption across the Linux desktop ecosystem proves that.

5. New apps: Last but definitely not least, we've entered a thrilling chapter of Flathub as an ecosystem. It's not just another source to get popular, big-name apps you'd expect to be able to get anywhere else; Flathub has become the preferred app store for a growing number of indie, open source developers. Developers are increasingly submitting their own new apps and directing their users to Flathub; from all 50+ GNOME Circle apps to apps like Endless Key, Librum, Lightwave Explorer, Live Captions, and Planify, Flathub is the best way to get apps into the hands of Linux users.

And of course a large part of Flathub's continued growth has been due to the incredible work of the Flathub admins, contributors, and volunteers who have helped ensure Flathub remains the trustworthy and reliable service it has always been known as.

Here's to What's Next!​

It's easy to pat ourselves on the back for these milestones (and it's well deserved!), but equally important is to look forward. Over the coming months we're excited to continue tackling the roadmap we laid out last year, including continued work towards payments and the new organizational structure for Flathub.

We're also increasing our engagement with third-party developers and ISVs to share why they should bring their apps to the million-plus Flathub users on Linux, continuing to improve documentation, and working towards curation and improved presentation of apps. There's a lot more coming and always more to do; if you want to get involved, chat with us in #flathub on Matrix.

Thank you for reading, and happy downloading!

The Outreachy organizers have approved GNOME to participate in the current round of Outreachy!

The GNOME Foundation is interested in sponsoring 3 internship projects for the May to August cohort.

@mentors If you are interested in mentoring, please discuss project ideas in our Project Ideas repository.

• Feb. 23, 2024 is the deadline for mentors to submit new projects.

@interns Initial applications for the Outreachy May 2024 to Aug 2024 internships are due on Jan 29 at 4pm UTC: https://www.outreachy.org/apply/

The number of self-identified thoughtful-people-in-tech whose social media energy still goes primarily to Twitter doesn’t bode well for, well, anything. I’m genuinely not judgy of people whose thing is Just Being Online, but if part of the self-image you like to project is “oh, yes, I really dislike fascism and care about other people” then… yeah, I’m judging you for still being active on Twitter.

A few tips that have helped me move to the fediverse:

• If you were very dependent on your X following and don’t want to abandon that, that’s understandable. If so, follow the Xlast strategy: yes, continue to post on Twitter when that’s important for work, but do it a bit slowly and less interactively.
• Don’t treat Fedi like late-period twitter, when you were picky about who you followed and humble about who you interacted with. Treat it like early-period twitter, when we all followed quite a few randos, and said things like “hi” and “thanks for sharing that!” It’s a small town, not the big city.
• Filter aggressively: Mastodon has great filtering capabilities, which makes following a lot of people easier. And also makes my 2020 advice on social media in an election year very relevant.
• If at all possible, find a server that’s specific to your place (like sfba.social or cosocial.ca) or your interests (like hci.social). The server functionality isn’t great (it is telling that the default UX calls it a server and not a community) but it can help you get your footing.
• Use an alternate client. Phanpy.social is genuinely excellent, with the one exception that it doesn’t do RTs. If you need RTs and can’t be bothered to copy-paste, Mona is very nice.
• I’m also on Bluesky but (perhaps because of which of my follows migrated there instead of Fediverse) it has trended hyper-US-political, which I have not enjoyed.

If you want a better world, you can’t wait for others to build it for you. To borrow a favorite “urgent optimist” phrase, you’re working in the early days of a better nation. Or, if you prefer: you are the one you’ve been waiting for. That’s not necessarily easy, but I at least am having quite a bit of fun on the Fediverse. Come on in, the water is fine!

7 years since my last post (2017!), so many exciting things to talk about: the AV1 video codec was released, we at Two Orioles wrote an AV1 encoder (Eve) and decoder (dav1d). Covid happened. I became a US citizen. Happily married for 15 years. My two boys are now teenagers (and behaving like it). So, let’s talk about … taxes?

In 2017, Congress enacted the Tax Cuts and Jobs Act, which (very briefly) reduces business (permanent) and personal (expires after 2025) tax rates by a few percent points, along with some “magic” to pay for it; some might remember the changes to SALT deductions. In 2023, during tax filing for 2022, more of that magic became clear: the 2017 law included 5-year-deferred changes to section-174, which covers expenses related to “Research & Experimentation” (R&E). The change requires all R&E expenses to be amortized over 5 (domestic) or 15 (foreign) years, and explicitly adds software development as a section-174 expense for tax purposes. This might sound innocent, but it hits small businesses hard.

Imagine a small software development business with $1M in revenue. It might employ 5 software developers ($150k/yr each – all at 50% effective tax rate in NY) plus legal/accounting/bookkeeping ($25k/yr) and office expenses ($25k/yr), leaving $1M - 5x $150k - $25k - $25k = $200k as business profit or taxable income. The profit flows through to the LLC/S-corp owners, who pay 50% tax over that also. Total taxes (federal + state + local) paid: 50% * (5x $150k + $200k) = $475k.

Starting 2022, initial-midyear amortizations means it can deduct only 10% of its R&E expenses (including salaries and office), which means the effective taxable income flowing through to the LLC/S-corp owners is now $1M - 10% * (5x $150k + $25k) - $25k = $897.5k, taxed at 50%, resulting in total taxes increasing to 50% * (5x $150k + 897.5k) = $823.75k. Of course, this money doesn’t actually exist, so the business will go broke unless it lays off some of its employees or the owners take out loans (bonus points for today’s high interest rates). This supposedly slowly resolves itself after 5 years, as long as the business doesn’t grow (i.e. hire new employees) and salaries of existing employees don’t go up: a pretty crazy economic policy to encourage innovation. It’s worse if you hire people outside the US, because now the amortization period is 15 years.

Congress should fix this, and there has been some (late, slow) progress in this area. Unfortunately, the media hasn’t caught on. The NYT blasted the proposed legislation as a “corporate giveaway” that “would benefit profitable companies” who “already pay too little in taxes”. The WSJ called it “at best a modest boost to investment incentives”. Maybe these journalists should read Michele Hansen’s tweet, which lists individual stories from small businesses (like mine) who were hurt by this change in tax law: tax increases by 500%, effective tax rates of 500%, hiring freezes, layoffs, loans, debt – and speaking from personal experience: lots of tears.

Dear Congress: small businesses need you – please fix section 174.

Version 0.8.0 of the CapyPDF library has been released. The main new feature is support for form XObjects and printer's mark annotations.

Printer's marks are things like color bars, crop marks and registration marks (also known as "bullseye marks") that high end printers need for quality control. Here is a very simple document.

An experienced print operator would use the black lines to set up paper trimming. Traditionally these marks were drawn in the page's graphics stream. This is problematic because nowadays printers prefer to use their own custom marks instead of ones created by the document author. PDF solves this issue by moving these graphics operations to separate draw contexts (specifically "form XObjects", which are not actually forms, though they are XObjects) that can then be "glued" on top of the page. These annotations are shown in PDF viewer applications but they are not printed. I have no experience with high end RIP software, but presumably the operator can choose to either print the document's annotations or replace them with their custom QA marks.

As usual, to find out what features CapyPDF has and how to use them, look up either the public C header or the Python code used in unit tests.

Following my announcement a few days ago, in probably what has been record time, the Ko-Fi goal for the Elgato Stream Deck+ has been reached!

I’ve acquired the device and it’s already on its way, expected to reach me by the end of January ~ early February due to being an international purchase.

Thanks everyone for your your overwhelming support! This is really exciting.

One of the more recent design trends in GNOME has been the use of sidebars. It looks great, it’s functional, and it gives separation of content from hierarchy.

Builder, on the other hand, has been stuck a bit closer to the old-hat design of IDEs where the hierarchy falls strictly from the headerbar. This is simply because libpanel was designed before that design trend. Some attempt was made in Builder to make it look somewhat sidebar’ish, but that was the extent of it given available time.

Last week I had a moment of inspiration on a novel way we could solve it without uprooting the applications which use libpanel. You can now insert edge widgets in PanelDockChild which are always visible even when the child is not. Combining that with being able to place a headerbar inside a PanelDockChild along with your PanelFrames means you can get something that looks more familiar in modern GNOME.

If you’d like to improve things further, you know where to find the code.

… and why did it take so long for that to happen?

The year 2023 was a busy one in Toolbx land. We had two big releases, and one of the important things we did was to start offering built-in support for Arch Linux and Ubuntu.

What does that mean?

$ toolbox create --distro arch
$ toolbox create --distro ubuntu --release 22.04

It also means that we will do our best to treat Arch Linux and Ubuntu on equal terms with Fedora and avoid regressions.

Now, that last sentence has a lot more to it than may seem at first. So, I am going to try to unwrap it to show why I think this one of the important things we did in 2023. You may find it interesting if you want the set of supported Linux distributions to expand further. You can also skip the details and go straight to the end to get the jist of it.

Why go beyond Fedora?

Even though Toolbx was created for the immediate needs of Fedora Silverblue, it has long since exceeded the bounds of Fedora and OSTree based operating systems. At the same time, Toolbx only had built-in support for Fedora and Red Hat Enterprise Linux. This disconnect led to a lot of people eagerly asking for better support for Linux distributions beyond the Fedora family.

From the outside, it looks like just a matter of putting together a Containerfile that layers on some extra content on top of a base image, and then publishing it on some OCI registry somewhere. However, it’s not that simple.

Why did it take so long?

Toolbx is a glue. Given an existing host operating system and a desired command line environment, it will create and set up an OCI container with the desired CLI environment that has seamless access to the user’s home directory, the Wayland and X11 sockets, networking (including Avahi), removable devices (like USB sticks), systemd journal, SSH agent, D-Bus, ulimits, /dev and the udev database, etc..

The closest analogy I can think of is libosinfo generating scripts to perform automated installations of various operating systems as virtual machines. Except, Toolbx containers aren’t expected to be as cleanly or formally separated from the host as VMs are, and the world of OCI containers is designed for deploying server-side applications and services, not for the persistent interactive use that Toolbx offers. This means that Toolbx has to carefully make each host OS version match the container, and make the container fit for interactive use. For example, libosinfo doesn’t have to worry about making the VM’s command line shell prompt and /etc/resolv.conf work with that of the host’s, nor does it have to convert the cloud image of an OS into a variant suited for a desktop or laptop.

This means that Toolbx has to very carefully set up the container to work with the particular host operating system version in use. For example, there can be subtle differences between running a Fedora 39 container on a Fedora 38 host and vice versa. If there are three different Fedora versions that we care about (such as Fedoras 38, 39 and 40), then that’s nine different combinations of container and host OSes to support. Sometimes, the number of relevant versions goes from three to four, and the number of combinations jumps to sixteen. Now, add Red Hat Enterprise Linux to the mix. Assuming that we only care about the latest point-releases (such as RHELs 8.9 and 9.3), we are now looking at twenty-five to thirty-six combinations. In reality, it’s a lot more, because we care about more than just the latest RHEL point-releases.

You can see where this is going.

With this addition of Arch Linux and Ubuntu, we have added at least seven new versions that we care about. That’s a total of approximately one hundred and fifty combinations!

I can assure you that this isn’t a theoretical concern. Here’s a bug about domain name resolution being completely broken in Toolbx containers for Fedoras 39 and 40 on Red Hat Enterprise Linux 9 hosts.

Tests

So, to promise with a straight face that we will do our best to treat Arch Linux and Ubuntu on equal terms with Fedora and avoid regressions, we need to automate this. There’s no way a test matrix of this size can be tackled manually. Hence, tests.

However, it’s easier said than done, because it’s not just about having the tests. We also need to run them on as many different host operating system versions as possible. Unfortunately, most continuous integration systems out there either only offer containers, which are useless because Toolbx needs to be tested on the host OS, or they offer Ubuntu hosts. One exception is Software Factory, which runs an instance of Zuul CI, and offers Fedora and CentOS Stream hosts.

Currently, we have a test suite with more than three hundred tests that covers a good chunk of all supported OCI containers and images. All these tests are run separately on hosts representing all active Fedora versions, with subsets being run on CentOS Stream 9 and Ubuntu 22.04 hosts. We are working on ensuring that the entire test suite gets run on CentOS Stream 9 and Ubuntu 22.04, and are hoping to introduce CentOS Stream 8 and Ubuntu 24.04 hosts to the mix.

Plus, these aren’t just simple smoke tests. They don’t just create and start the containers, and check for a successful exit code. They comprehensively poke at various attributes of the containers’ runtime environment and error conditions to ensure that things really do work as advertised.

I think this is a pretty impressive set-up. It took time to build it, and it’s still not done, but I think it was worth it.

We have also been busy in Fedora, pushing the quality of the Toolbx stack up a notch, but that’s a topic for another post.

So, if you want to see built-in support for your favourite Linux distribution, then please help us by providing some test runners. Right now we could really use one for Arch Linux to maintain our existing support for it, and one for Debian because we want to include it in the near future.

Maintainers

Finally, since Toolbx is a glue, sometimes we need to drive changes into the Linux distributions that we claim to support. For example, changing the sysctl(8) configuration to make ping(8) work, fixes to the start-up scripts for Bash and Z shell, etc.. This means that we need maintainers who will own the work that’s specific to a particular Linux distribution. As a Fedora contributor, I can take care of Fedora, but I cannot sign up to take care of every single distribution that’s out there.

In that sense, I am delighted that we have a bunch of dedicated folks taking care of the Arch Linux and Ubuntu support. Namely, Morten Linderud for Arch Linux, and Andrej Shadura and Ievgen Popovych for Ubuntu.

Conclusion

Two things need to happen for us to add built-in support for a new Linux distribution.

First, we need test runners that let us run our upstream test suite on the host operating system, and not inside a container. Right now we could really use one for Arch Linux to maintain our existing support for it, and one for Debian because we want to include it in the near future.

Second, we need someone to step up to drive changes into the Linux distribution in question, and own the work that’s specific to it.

I am also going to add this to the Toolbx documentation, so that it’s easy to find in future.

Dear friends, comrades, partners in crime and moderate profit! I am pleased to announce the immediate availability of Chafa 1.14.0. There are release notes, but who's got time for that? All the fun stuff is in this post. You should be reading it instead.

Pixel perfection

Images can now be padded instead of stretched to fit their cell extent exactly –

– so I'll no longer have to explain why our 50kLOC monstrosity couldn't do pixel-perfect output, while sixcat (300LOC) did so effortlessly. Naturally, I had to make this as hard as possible for myself by splicing in padding before and after each row as they're processed for channel reordering and such, but on the plus side, this maximizes cache friendliness and parallelism behind a nice and homogeneous internal API.

You can get the old behavior back with --exact-size off. It defaults to auto, which will do the right thing (i.e. pad if image fits in viewport without scaling and scaling wasn't explicitly requested).

Another improvement in this vein is that sRGB is properly linearized in scaling operations now. This is pipelined along with everything else, and should be suitably fast.

Multiplexer passthrough

Previously, it was impossible to do better than character art inside multiplexers like tmux and GNU Screen. This is no longer the case; kitty has a new trick that allows for persistent raster image placement in these, which we implement. The above mentioned multiplexers have slight differences in their passthrough protocols; we support both with the new --passthrough argument.

We also support sixel passthrough. Sixels will be wrecked by multiplexer updates, so this is off by default. You can enable it with e.g. -f sixel --passthrough screen. tmux tends to dispose of the image immediately after we exit, so it may be a good idea to use --passthrough tmux -d 5 there so you get a chance to look at it first.

To my knowledge, Chafa is the only terminal graphics toolkit to offer passthrough for all four combinations of sixel/kitty and tmux/screen. I think the iTerm2 protocol would be doable too, if only.

MS Windows compatibility

It runs pretty well on Windows. You can use it in PowerShell. @oshaboy added support for ConHost, so it can technically be used on very old Windows versions – although this hasn't gotten much testing yet.

Python bindings

Erica Ferrua Edwardsdóttir's amazing Python bindings have been around for a while now, yet nary a peep from me on my blag. This shameful deficit stands in contrast to the stunning professionalism of her work. You need to do this:

pip install chafa.py

Do it now. Everything's well structured, the documentation is entertaining and well written, and there's even a tutorial. It's rare to see a project that simultaneously delivers and channels the spirit of F/OSS this well. You'll also find it on GitHub.

JavaScript enablement

Héctor Molinero Fernández started doing WebAssembly builds, which means you can now use the Chafa API from JavaScript. Like so:

npm install chafa-wasm

He also made a cool web app to show off all the bells and whistles!

Cheerleading aside, I've had no hand in either of these projects. The glory belongs to their respective maintainers, along with all of the praise, stars, code submissions ^{and issue reports, heh heh.}

Art!

@clort81 sent me this picture:

What's special about it? Well, it's character art!

You have to zoom in a bit before it becomes obvious; there're only two colors per character cell.

The glyphs are something else, though. You see, @clort81 wasn't happy with the limited offering of block drawing symbols in Unicode, and set out to create Blapinus, a 6125-glyph (!) hand-pixeled 6×12 PCF font with all the shapes you could ever want.

Plug that into your terminal (and Chafa), et voilà:

sudo cp blapinus.pcf.gz /usr/share/fonts/misc/
xterm -font -blap-*

Note that your fonts may live somewhere else, so relocate accordingly. Then inside XTerm, run:

chafa -f symbols --glyph-file blapinus.pcf.gz --symbols imported hello.png

If you see strange symbols in your output, you can try excluding some wide and ambiguous code points, e.g. --symbols imported-wide-ued00..uffff.

You can probably set this up in other terminals and display servers too, but know that it could be a long and winding path you're going down. Traveler beware. Or push the pedal to the metal and write a trip report. I'd love to read it.

If your terminal renders the font correctly, this can even have somewhat practical qualities:

First, it integrates perfectly with tmux and GNU Screen. Redraw, scrollback and editing just works, no passthrough tricks required.

Second, albeit lossy, the compression ratio is surprisingly good. Assuming four bytes per pixel, a 6×12 cell is 288 bytes uncompressed. We turn this into 39 bytes at most (a maximum of 36 bytes for the direct color sequence plus 3 bytes for the UTF-8 character), or an 86% reduction. Not bad, considering the compression dictionary is a 100kB font file.

Deflate will further compress this kind of data by 3/4, so if you're running this in a compressed ssh session, you can expect the total gain to be about 95%.

Prior art!

I've mentioned Mo Zhou's work before, but I'd be remiss not to bring it up here; they focused their considerable ML skills on a generator that takes a lot of the pain out of the font creation process. Just point it at an image collection, and by the magic of k-means clustering and a minimal increase in your carbon footprint, out pops a new font brimming with delectable puzzle pieces. You get scalable TTF, with SVG as an intermediate format, which is more agreeable with modern rendering stacks. Here it is in VTE:

This ML-generated font makes for a more organic look. There are unfortunately still some artifacts caused – presumably – by VTE's cell padding. The generator has offset hacks to work around it, but it's hard to make custom connective glyphs look perfect in every terminal.

You can read more about it in one of our longest-running GitHub issues. We're taking it all the way.

Cool applications

Chafa's found its way into the nooks and crannies of many a sweet application by now. I'd especially like to mention these three here:

ANSIWAVE BBS, the brainchild of Zach Oakes, is written in Nim and contains an embedded build of Chafa for character graphics generation. As a one-time (and sometimes) BBS sysop and denizen, this hits me right in the feels.

Felix is a nice file browser by Kyohei Uto written in Rust. It uses Chafa as an external image previewer.

kew, a terminal music player by the mysterious @ravachol, is written in C and uses the native Chafa API to generate cover previews. Development on this has been moving very quickly.

A laid-back place to chat about all this stuff

Issue trackers are formal and supposedly high-SNR. If you'd like a more relaxed place to chat about Chafa, your own programs, terminal graphics (modern or ancient), graphics programming in general or artistic expression related to any of these, drop by our secret business Matrix channel, #chafa:matrix.org. We'll be waiting.

I'm also enjoying Mastodon these days. Occasional announcements and amusements go there. It's good.

Thanks

Last, but not least: a big thank you to everyone who wrote code, reported bugs, filed suggestions and helped test this time around. And an extra big thanks to all the packagers and distributors who make the F/OSS world turn. You're the best.

Hello there ! Welcome back!.

As I reach the midpoint of my internship, I’m thrilled to share my journey into the intricate world of end-to-end testing for GNOME OS using the powerful tool, openQA. From initial bafflement to mastering complex tests, it’s been a roller coaster of learning and discovery. Here are a few things i have learned so far along this journey as it unfolds as an Outreachy Intern!

Key Takeaways

• End-to-End Testing Mastery: I’ve gained an in-depth understanding of end-to-end testing, a critical component in ensuring a smooth user experience in software development.
• Problem-Solving Skills: Tackling complex technical issues head-on has honed my problem-solving skills, a vital asset in any tech career.
• Continuous Learning: The tech field is ever-evolving, and this experience has instilled in me the importance of continual learning and adaptation.
• Learning to to collaborate and effectively communicate: I can not stress this enough! Do not be shy on this as silence eats you up more or even worse the uncomfortable feeling of not finishing the task and being stuck for long.
• Learning Git: There are some Git commands that i had seen but not used but while working on this project i had to master,still cant believe I can git rebase faster and excitingly without breaking things! Don’t forget i can git rebase -i HEAD~3 and squash multiple commits into 1 and even when nano editor played me a bit i did crack it in the end. Lastly I learned how to cherry pick commits and put them on on another branch and am till learning more. My mentors shared some resources that helped me along the way thanks to Sonny Piers and Sam Thursfield who were very quick to help. Checkout one of the resources that i looked at here :Handbook , some others are PDF’s I cannot share here.

As I continue this exciting journey, I’m reminded that mastering technology is as much about understanding its complexities as it is about embracing the learning process. To those embarking on a similar path, remember: every challenge is an opportunity to grow. Dive in, stay curious, and enjoy the ride in the world of tech testing!

Happy testing, and keep exploring!

Happy new year everyone! For better or worse we’re now well into the 2020s.

Here are some things I’ve been doing recently.

A post on the GNOME openQA tests: Looking back to 2023 and forwards to 2024. I won’t repeat the post here, go read it and see what I hope to see in 2024 with regards to QA testing.

I’m still mentoring Dorothy and Tanjuate to work on the tests and we’re about at the half way point of the Outreachy internship. Our initial goal was to test GNOME’s accessibility features and this work is nearly done, hopefully we’ll be showing it off this week. Here’s a sneak preview of the new gnome_accessibility testsuite…

These features are sometimes forgotten (at least by me) and I hope this testsuite can serve as a good demo of what accessibility features GNOME has, in addition to guarding against regressions.

It’s hard work to remotely mentor 2 interns on top of 35hrs/wk customer work and various internal work duties, so it’s great that Codethink are covering my time as a mentor, and it also helps that it’s winter and the outside world is hidden behind clouds most of the time. If only it was a face-to-face internship and I could hang out in Uganda or Cameroon for a while. Tanju and Dorothy are great to work with, if you’re looking to hire QA engineers then I can give a good reference for both.

I expect my open source side project for 2024 will still be the GNOME openQA tests, it ties in with a lot of activity around GNOME OS and it feels like we are pushing through useful workflow improvements for all of GNOME. Not that I’ve lost interest in other important stuff like desktop search, music recommendations and playing OpenTTD, but there is only so much you can do with a couple of hours a week.

What else? As usual I’ve been reviewing various speedups and SPARQL improvements from Carlos Garnacho in the Tracker search engine. I’m making plans to go to FOSDEM, so hopefully will see you there (especially if you want to talk about openQA). And I listed out my top 5 albums of 2023 which you should go listen to before doing anything else.

Following up on my previous blog post, due to popular demand, I started a small fundraiser campaign to acquire an Elgato Stream Deck Plus.

The goal is US$ 500, which should cover the costs of acquiring the device, and should pay for a few hours of reverse engineering work Boatswain development. Naturally, I’ll also document the USB format that these devices use, so that other developers out there can implement support in their own apps.

This particular model will be more complicated than other Stream Deck devices because it features a touch screen, and 4 activatable knobs. It will require a rather substantial rework of Boatswain so that it can support separate button grids, different button types, finger detection, and more.

I did reach out to Elgato, but they don’t seem interested in giving away one of their devices, or even a devboard, for me to hack on.

Whether or not this goal is reached, I’d like to thank all of the people that supported me on Ko-Fi and GitHub so far. Your support is truly humbling and it allowed me to write Boatswain in the first place, and much more!

Edit: since writing this article, I was let known that there is one other project that already reverse engineered parts of this device. I’ve adjusted the description to mention “Boatswain development” instead of “reverse engineering”.

$ findmnt /
TARGET SOURCE  FSTYPE  OPTIONS
/ overlay overlay ro,relatime,seclabel,lowerdir=/run/ostree/.private/cfsroot-lower::/sysroot/ostree/repo/objects,redirect_dir=on,metacopy=on

# touch /usr/new_file
touch: cannot touch '/usr/new_file': Read-only file system