FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid Atom 1.0 feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 2, column 0: Use of unknown namespace: http://planet.intertwingly.net/ [help]

<feed xmlns="http://www.w3.org/2005/Atom" xmlns:planet="http://planet.intert ...

line 278, column 38: Identifier "https://foundation.gnome.org" is not in canonical form (the canonical form would be "https://foundation.gnome.org/") (7 occurrences) [help]

      <id>https://foundation.gnome.org</id>
                                      ^

line 673, column 33: Two entries with the same value for atom:updated: 2025-03-21T00:00:00Z [help]

    <updated>2025-03-21T00:00:00Z</updated>
                                 ^

line 1099, column 4: Missing source element: title [help]
```
    </source>
    ^
```
line 1099, column 4: Missing source element: id [help]
```
    </source>
    ^
```

line 1365, column 135: The title attribute of link should not be blank [help]

... ="alternate" title="" type="text/html"/>
                                             ^

line 1366, column 12: title should not be blank [help]
```
    <title/>
            ^
```

Source: https://planet.gnome.org/atom.xml

<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:planet="http://planet.intertwingly.net/" xmlns:indexing="urn:atom-extension:indexing" indexing:index="no"><access:restriction xmlns:access="http://www.bloglines.com/about/specs/fac-1.0" relationship="deny"/>
<title>Planet GNOME</title>
<updated>2025-04-02T07:04:38Z</updated>
<generator uri="http://intertwingly.net/code/venus/">Venus</generator>
<author>
<name>GNOME Sysadmin Team</name>
<email>gnome-sysadmin@gnome.org</email>
</author>
<id>https://planet.gnome.org/atom.xml</id>
<link href="https://planet.gnome.org/atom.xml" rel="self" type="application/atom+xml"/>
<link href="http://pubsubhubbub.appspot.com/" rel="hub"/>
<link href="https://planet.gnome.org/" rel="alternate"/>
<entry xml:lang="en">
<id>https://thisweek.gnome.org/posts/2025/03/twig-193/</id>
<link href="https://thisweek.gnome.org/posts/2025/03/twig-193/" rel="alternate" type="text/html"/>
<title>#193 Image Loading</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Update on what happened across the GNOME project in the week from March 21 to March 28.</p>
<h1 id="gnome-core-apps-and-libraries">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#gnome-core-apps-and-libraries"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Core Apps and Libraries
</h1>
<h3 id="glycin">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#glycin"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Glycin <a href="https://gitlab.gnome.org/GNOME/glycin"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
</h3><p>Sandboxed and extendable image loading and editing.</p>
<p><a href="https://matrix.to/#/@sophieherold:gnome.org">Sophie 🏳️‍🌈 🏳️‍⚧️ (she/her)</a> reports</p>
<blockquote>
<p>Glycin, the newish image loading and editing library, now supports specifying the memory format for image data an API user needs. If glycin is used with GTK, this has always been taken care of automatically. However, for other use cases, it’s now <a href="https://gnome.pages.gitlab.gnome.org/glycin/libglycin/method.Loader.set_accepted_memory_formats.html">possible to specify</a> a limited set of formats the API user supports. Support for loading image data from a <a href="https://gnome.pages.gitlab.gnome.org/glycin/libglycin/ctor.Loader.new_for_stream.html"><code>GInputStream</code></a> or <a href="https://gnome.pages.gitlab.gnome.org/glycin/libglycin/ctor.Loader.new_for_bytes.html"><code>GBytes</code></a> instead of <a href="https://gnome.pages.gitlab.gnome.org/glycin/libglycin/ctor.Loader.new.html"><code>GFile</code></a> has also landed.</p>
<p>These features are important to adopt glycin in other areas in <a href="https://gitlab.gnome.org/GNOME/Initiatives/-/issues/53">the quest to replace GdkPixbuf</a> to make image loading more safe and enable more features like HDR image support and support for more image formats.</p>
<p>You can <a href="https://gitlab.gnome.org/sophie-h">financially support my work</a> or drop by and submit a code contribution.</p>
</blockquote>
<h1 id="gnome-development-tools">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#gnome-development-tools"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Development Tools
</h1>
<h3 id="sysprof">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#sysprof"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Sysprof <a href="https://gitlab.gnome.org/GNOME/sysprof"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
</h3><p>A profiling tool that helps in finding the functions in which a program uses most of its time.</p>
<p><a href="https://matrix.to/#/@feaneron:gnome.org">Georges Stavracas (feaneron)</a> announces</p>
<blockquote>
<p>Sysprof is now able to filter samples by marks. This allows for statistically relevant data on what’s running when a specific mark is ongoing, and as a consequence, allows for better data analysis. <a href="https://feaneron.com/2025/03/26/a-sysprof-enhancement/">You can read more here</a>.</p>
</blockquote>
<h3 id="gnome-builder">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#gnome-builder"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Builder <a href="https://gitlab.gnome.org/GNOME/gnome-builder"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
</h3><p>IDE for writing GNOME-based software.</p>
<p><a href="https://matrix.to/#/@nokse22:matrix.org">Nokse</a> says</p>
<blockquote>
<p>This week Arduino support for GNOME Builder has been <a href="https://gitlab.gnome.org/GNOME/gnome-builder/-/merge_requests/849">merged</a>, providing integration with <a href="https://github.com/arduino/arduino-cli">arduino-cli</a> to compile and upload sketches to Arduino compatible boards. The new feature will be available in Builder Nightly and includes a graphical interface for managing libraries and platforms and selecting compilation/upload options. It also provides a template to start a new Arduino project. Note that you need to have <code>arduino-cli</code> installed to use this feature.
If you encounter any issues, please go ahead and file them.</p>
</blockquote>
<h1 id="gnome-circle-apps-and-libraries">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#gnome-circle-apps-and-libraries"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Circle Apps and Libraries
</h1><p><a href="https://matrix.to/#/@bragefuglseth:gnome.org">Brage Fuglseth (he/him)</a> says</p>
<blockquote>
<p>This week <a href="https://apps.gnome.org/Bustle/">Bustle</a> was accepted into GNOME Circle. Bustle lets you visualize and analyze D-Bus activity with detailed sequence diagrams. Congratulations!</p>
<p>
<img alt="" src="https://thisweek.gnome.org/posts/2025/03/twig-193/IMG_0886.png"/>
</p>
</blockquote>
<h3 id="warp">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#warp"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Warp <a href="https://gitlab.gnome.org/World/warp"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
</h3><p>Fast and secure file transfer.</p>
<p><a href="https://matrix.to/#/@felinira:matrix.org">Fina</a> announces</p>
<blockquote>
<p>Warp 0.9 was released with support for directly sending files via “Open With…” from Files. QR code scanning has also seen improvements, by utilizing the new QR code feature in Camera.</p>
</blockquote>
<h3 id="eyedropper">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#eyedropper"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Eyedropper <a href="https://flathub.org/apps/details/com.github.finefindus.eyedropper"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
</h3><p>Pick and format colors.</p>
<p><a href="https://matrix.to/#/@finefindus:matrix.org">FineFindus</a> reports</p>
<blockquote>
<p>Eyedropper 2.1.0 has been released, featuring</p>
<ul>
<li>RGB decimal notation</li>
<li>support for global shortcuts</li>
<li>a new way to directly enter colors, without picking them first</li>
</ul>
<p>Download the new version on <a href="https://flathub.org/apps/com.github.finefindus.eyedropper">Flathub</a>.</p>
<p>
<img alt="" src="https://thisweek.gnome.org/posts/2025/03/twig-193/eyedropper_global_shortcuts.png"/>
<img alt="" src="https://thisweek.gnome.org/posts/2025/03/twig-193/eyedropper_new_input.png"/>
</p>
</blockquote>
<h1 id="third-party-projects">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#third-party-projects"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Third Party Projects
</h1><p><a href="https://matrix.to/#/@bilelmoussaoui:gnome.org">Bilal Elmoussaoui</a> says</p>
<blockquote>
<p>I have released a new version of <a href="https://crates.io/crates/oo7-cli">oo7-cli</a>, with the possibility to interact with the sandboxed applications keyrings or any keyring file on your system.</p>
<pre tabindex="0"><code>oo7-cli --app-id com.belmoussaoui.Authenticator list
</code></pre><p>The CLI also features a new CLI argument for attempting to repair a broken keyring (always backup your keyring file before).</p>
</blockquote>
<p><a href="https://matrix.to/#/@JumpLink:matrix.org">JumpLink</a> says</p>
<blockquote>
<p>TypeScript type definitions for GNOME Shell 48 released</p>
<p>The TypeScript type definitions for GNOME Shell 48 have been updated!<br/>
This release brings improved TypeScript support for writing GNOME Shell extensions.</p>
<p>Based on the latest version of <code>ts-for-gir</code>:<br/>
→ <a href="https://github.com/gjsify/ts-for-gir/releases/tag/v4.0.0-beta.23">v4.0.0-beta.23</a></p>
<p>Project page:<br/>
→ <a href="https://github.com/gjsify/gnome-shell">gjsify/gnome-shell</a></p>
<p>Note: This release was published shortly after the TWIG deadline,<br/>
so it will appear in next week’s edition.</p>
</blockquote>
<p><a href="https://matrix.to/#/@capypara:matrix.org">Capypara</a> reports</p>
<blockquote>
<p>Introducing <a href="https://flathub.org/apps/de.capypara.FieldMonitor">Field Monitor</a>, a remote-desktop client focused on accessing virtual machines.</p>
<p>It has first-class support for adding Proxmox or QEMU/KVM hypervisors but it can also connect to any server implementing one of the SPICE, RDP or VNC protocols.</p>
<p>It can also open RDP or Virt Viewer files.</p>
<p>This is the first release and it might still be a little rough around the edges in some parts, so any and all feedback is more than welcome :).</p>
<p>Field Monitor is powered by <a href="https://gitlab.gnome.org/malureau/rdw">RDW</a>, a set of remote-desktop widgets for GTK 4. I want to thank Marc-André Lureau, the author, since without them this app would not be possible!</p>
<p>
<img alt="" src="https://thisweek.gnome.org/posts/2025/03/twig-193/field-monitor-screenshot.png"/>
</p>
</blockquote>
<p><a href="https://matrix.to/#/@swsnr:matrix.org">Sebastian Wiesner</a> reports</p>
<blockquote>
<p><a href="https://flathub.org/apps/de.swsnr.pictureoftheday">Picture Of The Day</a> is a new app to get a picture of the day as your daily wallpaper, from <a href="https://apod.nasa.gov/apod/astropix.html">NASA Astronomy Picture of the Day</a>, <a href="https://www.bing.com/">Bing</a>, <a href="https://commons.wikimedia.org/wiki/Main_Page">Wikimedia</a>, or <a href="https://www.simonstalenhag.se">Simon Stålenhag artwork</a>.</p>
<p>Preview images, pick your favorite source, enable automatic updates, and enjoy a fresh wallpaper every day.</p>
<p>Available on <a href="https://flathub.org/apps/de.swsnr.pictureoftheday">Flathub</a>.</p>
<p>
<img alt="" src="https://thisweek.gnome.org/posts/2025/03/twig-193/PictureOfTheDay.png"/>
</p>
</blockquote>
<h3 id="fractal">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#fractal"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Fractal <a href="https://gitlab.gnome.org/World/fractal"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
</h3><p>Matrix messaging app for GNOME written in Rust.</p>
<p><a href="https://matrix.to/#/@zecakeh:tedomum.net">Kévin Commaille</a> reports</p>
<blockquote>
<p>It’s the beginning of bee season! 🌸🌺🌼 🐝 B like beta! Here’s Fractal 11.beta:</p>
<ul>
<li>New shortcuts Ctrl + Page Up and Ctrl + Page Down go to the previous/next room in the list</li>
<li>The media cache will now be periodically cleaned up</li>
<li>The page that lists user sessions has been overhauled, with details moved to subpages, for a less cluttered feel, and paving the way to a new feature!</li>
<li>A couple of small cosmetic changes have landed as well</li>
</ul>
<p>As usual, this release includes other improvements, fixes and new translations thanks to all our contributors, and our upstream projects.</p>
<p>It is available to install via Flathub Beta, see the <a href="https://gitlab.gnome.org/World/fractal#installation-instructions">instructions in our README</a>.</p>
<p>As the version implies, there might be a slight risk of regressions, but it should be mostly stable. If all goes well the next step is the release candidate!</p>
<p>If you have a little bit of time on your hands, you can try to fix one of our <a href="https://gitlab.gnome.org/World/fractal/-/issues/?label_name%5B%5D=4.%20Newcomers">newcomers issues</a>. Anyone can make Fractal better!</p>
</blockquote>
<h1 id="events">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#events"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Events
</h1><p><a href="https://matrix.to/#/@kristiprogri:gnome.org">Kristi Progri</a> reports</p>
<blockquote>
<p>We’re excited to announce that registrations for GUADEC are now open!
<a href="https://events.gnome.org/event/259/registrations/">https://events.gnome.org/event/259/registrations/</a></p>
<p>If you are planning to attend our event (in-person or online) now it’s the time to get your ticket!</p>
</blockquote>
<h1 id="thats-all-for-this-week">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#thats-all-for-this-week"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>That’s all for this week!
</h1><p>See you next week, and be sure to stop by <a href="https://matrix.to/#/#thisweek:gnome.org">#thisweek:gnome.org</a> with updates on your own projects!</p></div>
</summary>
<updated>2025-03-28T00:00:00Z</updated>
<published>2025-03-28T00:00:00Z</published>
<source>
<id>https://thisweek.gnome.org/</id>
<author>
<name>This Week in GNOME</name>
</author>
<link href="https://thisweek.gnome.org/" rel="alternate" type="text/html"/>
<link href="https://thisweek.gnome.org/index.xml" rel="self" type="application/rss+xml"/>
<subtitle>Recent content on This Week in GNOME</subtitle>
<title>This Week in GNOME</title>
<updated>2025-03-28T00:00:00Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://blogs.gnome.org/chergert/?p=12732</id>
<link href="https://blogs.gnome.org/chergert/2025/03/27/fiber-cancellation-in-libdex/" rel="alternate" type="text/html"/>
<title>Fiber cancellation in libdex</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">With GNOME 48 I released libdex 0.10 on the march towards a 1.0. One of the major improved features there was around fiber cancellation. I’m not going to go into detail about the differences between threads and fibers as wikipedia or your local CS department can probably help you there. But what I will say … <a class="more-link" href="https://blogs.gnome.org/chergert/2025/03/27/fiber-cancellation-in-libdex/">Continue reading <span class="screen-reader-text">Fiber cancellation in libdex</span></a></div>
</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>With GNOME 48 I released <a href="https://gitlab.gnome.org/GNOME/libdex">libdex</a> 0.10 on the march towards a 1.0. One of the major improved features there was around fiber cancellation.</p>
<p>I’m not going to go into detail about the differences between threads and fibers as wikipedia or your local CS department can probably help you there. But what I will say is that combining <code>__attribute__((cleanup))</code> (e.g. <code>g_autoptr()</code>) with futures and fibers makes such a nicer experience when writing C.</p>
<p>Thread cancellation is a rather non-portable part of the threading stack across platforms. Some POSIX platforms support it, some don’t. Having safe places to cancel can be a real challenge even if you are depending on a threading implementation that can do it.</p>
<p>With fibers, we have a natural cancellation point due to the cooperative nature of scheduling. All (well behaved) fibers are either making progress or awaiting completion of a future. We use the natural <code>await()</code> points to implement cancellation. If everything that was awaiting the future of the fiber has been cancelled, then the fiber can naturally cancel too. The next time it awaits that will just happen and natural exit paths will occur.</p>
<p>When you don’t want cancellation to propagate, you still use <code>dex_future_disown()</code> like always (as the fiber itself is a future).</p>
<p>Just to give a quick example of how fibers and futures makes writing C code nicer, here is an excerpt from <a href="https://gitlab.gnome.org/chergert/foundry">libfoundry</a> that asynchronously implements the necessary phases to build/run your project with a specific tool, possibly on a non-local system. In the GNOME Builder IDE, this is a series of async callbacks that is extremely difficult to read/debug. But with Foundry using libdex, it’s just a few lines of code and every bit as non-blocking.</p>
<p>From <a href="https://gitlab.gnome.org/chergert/foundry/-/blob/2ba40d53e8b5a2e858a678bece49a4a844c58eac/lib/run/foundry-run-manager.c#L163">foundry-run-manager.c</a>.</p>
<pre class="brush: cpp; title: ; notranslate">g_autoptr(FoundryDeployStrategy) deploy_strategy = NULL;
g_autoptr(FoundryBuildProgress) progress = NULL;
g_autoptr(GSubprocess) subprocess = NULL;
GError *error = NULL;
if (!(deploy_strategy = dex_await_object (foundry_deploy_strategy_new (state->pipeline), &error)) ||
!dex_await (foundry_deploy_strategy_deploy (deploy_strategy, state->build_pty_fd, state->cancellable), &error) ||
!dex_await (foundry_deploy_strategy_prepare (deploy_strategy, state->launcher, state->pipeline, state->build_pty_fd, state->cancellable), &error) ||
!dex_await (foundry_run_tool_prepare (state->run_tool, state->pipeline, state->command, state->launcher, state->run_pty_fd), &error) ||
!(subprocess = foundry_process_launcher_spawn (state->launcher, &error)))
return dex_future_new_for_error (error);
</pre>
<p>At each <code>dex_await*()</code> function call the fiber is suspended and we return to the main loop for additional processing.</p>
<p>In a better world we’d be able to do these without fibers and instead do stackless coroutines. But maybe with a little compiler help we can have that too.</p></div>
</content>
<updated>2025-03-27T19:09:20Z</updated>
<published>2025-03-27T19:09:20Z</published>
<author>
<name>chergert</name>
</author>
<source>
<id>https://blogs.gnome.org/chergert</id>
<link href="https://blogs.gnome.org/chergert/feed/" rel="self" type="application/rss+xml"/>
<link href="https://blogs.gnome.org/chergert" rel="alternate" type="text/html"/>
<subtitle>Details of Christian's work on GNOME</subtitle>
<title>Happenings in GNOME</title>
<updated>2025-03-27T19:12:10Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://foundation.gnome.org/?p=19488</id>
<link href="https://foundation.gnome.org/2025/03/27/guadec-2025-registration-is-open/" rel="alternate" type="text/html"/>
<title>GUADEC 2025 Registrations are Open!</title>
<summary>The GNOME Foundation is thrilled to share that registration for GUADEC 2025 is now open! GUADEC is the largest annual gathering of GNOME developers, contributors, and community members. This year we welcome everyone to join us in the beautiful city of Brescia, Italy from July 24th to 29th or online! For those who cannot join us in […]</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>The GNOME Foundation is thrilled to share that registration for GUADEC 2025 is now open!</p>
<p>GUADEC is the largest annual gathering of GNOME developers, contributors, and community members. This year we welcome everyone to join us in the beautiful city of Brescia, Italy from July 24<sup>th</sup> to 29<sup>th</sup> or online! For those who cannot join us in person, we will live-stream the event so you can attend or present remotely.</p>
<p>To register, visit <a href="https://events.gnome.org/event/209/">guadec.org</a> and select whether you will attend in person or remotely. <br/>In-person attendees will notice a slight change on their registration form. This year we’ve added a section for “Registration Type” and provided 4 options for ticket fees. These costs go directly towards supporting the conference and helping us build a better GUADEC experience. <br/>We ask that in-person attendees select the option they are most comfortable with. If you have any questions, please don’t hesitate to reach out to us at <a href="mailto:guadec@gnome.org">guadec@gnome.org</a>.</p>
<p><a href="https://events.gnome.org/event/259/registrations/254/" rel="noreferrer noopener" target="_blank">Register for In-Person Attendance</a><br/><a href="https://events.gnome.org/event/259/registrations/252/" rel="noreferrer noopener" target="_blank">Register for Remote Attendance</a></p>
<p>The Call for Participation is ongoing but once are talks are selected you will find speaker details and a full schedule on <a href="https://events.gnome.org/event/209/">guadec.org</a>. We will also be adding more information about social events, accommodations, and activities throughout Brescia soon!</p>
<p>We are still looking for conference sponsors. If you or your company would like to become a GUADEC 2025 sponsor, please take a look at our <a href="https://events.gnome.org/event/259/attachments/539/1022/2025GUADEC-Sponsorship.pdf">sponsorship brochure</a> and reach out to us at <a href="https://foundation.gnome.org/news/feed/guadec@gnome.org">guadec@gnome.org</a>.</p>
<p>To stay up-to-date on conference news, be sure to follow us on Mastodon <a href="https://floss.social/@gnome">@gnome@floss.social</a>.</p>
<p>We look forward to seeing you in Brescia and online!</p>
<p/></div>
</content>
<updated>2025-03-27T13:44:26Z</updated>
<published>2025-03-27T13:44:26Z</published>
<category term="News"/>
<author>
<name>Kristi Progri</name>
</author>
<source>
<id>https://foundation.gnome.org</id>
<logo>https://foundation.gnome.org/wp-content/uploads/sites/12/2020/08/cropped-icon-32x32.jpg</logo>
<link href="https://foundation.gnome.org/news/feed/" rel="self" type="application/rss+xml"/>
<link href="https://foundation.gnome.org" rel="alternate" type="text/html"/>
<subtitle>Building a diverse and sustainable free software ecosystem</subtitle>
<title>News – The GNOME Foundation</title>
<updated>2025-03-27T14:08:34Z</updated>
</source>
</entry>
<entry>
<id>tag:blogger.com,1999:blog-2957731359259629776.post-6703969374615395625</id>
<link href="https://curiositydrivendevelopment.blogspot.com/feeds/6703969374615395625/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
<link href="https://curiositydrivendevelopment.blogspot.com/2025/03/gnome-calculator-updates.html#comment-form" rel="replies" title="0 Comments" type="text/html"/>
<link href="https://www.blogger.com/feeds/2957731359259629776/posts/default/6703969374615395625" rel="edit" type="application/atom+xml"/>
<link href="https://www.blogger.com/feeds/2957731359259629776/posts/default/6703969374615395625" rel="self" type="application/atom+xml"/>
<link href="https://curiositydrivendevelopment.blogspot.com/2025/03/gnome-calculator-updates.html" rel="alternate" title="GNOME Calculator updates" type="text/html"/>
<title>GNOME Calculator updates</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p> After a long time of low-maintenance (as in me being out of the picture and doing mostly releases and some trivial/not-so-trivial-but-quick fixes here and there) period for GNOME-Calculator, it's time to reveal what's happening behind the scenes.</p><p>Long-story short, pretty late in the 48 cycle two contributors popped up to breathe some life into GNOME Calculator, so much, that I had a pretty hard time keeping track of the merge requests piling up. So most of the kudos for the below-mentioned features go to <a href="https://gitlab.gnome.org/fcusr">fcusr</a> and <a href="https://gitlab.gnome.org/aplazas">Adrien Plazas</a>, and I hope I will manage to list all of them, and it would be great to have folks using the Nightly Calculator (current development version from flatpak gnome-nightly repo) to help spot issues/requests in time to be fixed for 49.</p><p/><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjASz-1s5RxORIqWyZYJA8zdGppK4zntFv45Ws2yOe25sNXPE7BG4P1H17Z8PX96ifXurdtP4B-SRC9zjvEuXP1pB5Mixm60i0PUylAzhsVM_7wTzj8m0qAtwD5PFMb8ZW3mEt4hiNuMCgEu_T8WrRZcD9FCfEDM2ZCaNbWcoYHfa4bgoy42-McUfO88fY/s738/Screenshot%20From%202025-03-27%2008-07-45.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjASz-1s5RxORIqWyZYJA8zdGppK4zntFv45Ws2yOe25sNXPE7BG4P1H17Z8PX96ifXurdtP4B-SRC9zjvEuXP1pB5Mixm60i0PUylAzhsVM_7wTzj8m0qAtwD5PFMb8ZW3mEt4hiNuMCgEu_T8WrRZcD9FCfEDM2ZCaNbWcoYHfa4bgoy42-McUfO88fY/s320/Screenshot%20From%202025-03-27%2008-07-45.png" width="209"/></a></div>So now the features:<p/><h2 style="text-align: left;">Conversion mode</h2><p style="text-align: left;"/><div class="separator" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><br/></div>Based on several user requests and the work of <a href="https://gitlab.gnome.org/fcusr">fcusr</a>, conversion UI was moved to a separate "mode". Important thing to note here, that conversions using keyboard-only are still possible (e.g. typing 1 kg in g yields the r<br/>esult) in any mode, Conversion view is just a UI/button/touch-friendly way of doing the conversions without typing, similarly to what we had previously in the advanced mode.<p/><p style="text-align: left;"> </p><h2 style="text-align: left;"> </h2><h2 style="text-align: left;">UI cleanup, styling and touch improvements</h2><p style="text-align: left;"/><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglu0T_6Nf3w4zdEv3gc1SQfOjZhdUKcE8Kr1ZM1hGmpEtoS2l2KcFBBjfnjd4OKnztDGKQmxuPyzU5sT9IY8DBPE3p4ZrbUJ7a3SeTLBeSZ9XZZmk-aUNorBQhygGNJ5BuxIOU4Bb38KdPvQKE9l0CqNXyF4mCNe8W3HeIwePZOBe9rGLoHLq0wV0L-ZI/s836/Screenshot%20From%202025-03-27%2008-32-50.png" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="364" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglu0T_6Nf3w4zdEv3gc1SQfOjZhdUKcE8Kr1ZM1hGmpEtoS2l2KcFBBjfnjd4OKnztDGKQmxuPyzU5sT9IY8DBPE3p4ZrbUJ7a3SeTLBeSZ9XZZmk-aUNorBQhygGNJ5BuxIOU4Bb38KdPvQKE9l0CqNXyF4mCNe8W3HeIwePZOBe9rGLoHLq0wV0L-ZI/w400-h364/Screenshot%20From%202025-03-27%2008-32-50.png" width="400"/></a></div>Both Adrien and fcusr worked on simplifying the UI-related code, dropping old/unnecessary styling, tweaking the looks of buttons, improving the access to toggles/switches to make Calculator easier to use with functions grouped, styled in a meaningful way.<p/><p style="text-align: left;">The interface was also "optimized" for smaller screens/touch devices, namely function buttons which up until now only entered the function name to save you some typing will work with some text selected to insert brackets around the selection and add the function.</p><h2 style="text-align: left;">New functions and constants</h2><p style="text-align: left;"> For anyone needing them, new functions have been added:</p><ul style="text-align: left;"><li style="text-align: left;"><a href="https://en.wikipedia.org/wiki/Greatest_common_divisor">greatest common divisor</a> ( e.g. using <code>gcd (456;1584;40;60)</code> yields 4 as a result)</li><li style="text-align: left;"><a href="https://en.wikipedia.org/wiki/Least_common_multiple">least common multiple</a> ( e.g. using <code>lcm (456;1584;40;60) </code>yields 150480 as a result)</li><li style="text-align: left;"><a href="https://en.wikipedia.org/wiki/Combination">combination</a> (e.g. using <code>ncr (9;5) </code><code/>yields 126 as a result)</li><li style="text-align: left;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyjnBvYH-J7q9K8rgML4c8J1bABNyhuNcU6Jh3RbTau0c-4qRnzeV1Lf4nhxbvurPIu52kDgzfsjE5Y6b-SiFomQHiC6vrZhv_FgOCSxoS37w3-wI7kSdlCeYVK2aKMEfx2AIJxvJFAEAnLsaOO9c618bJjc0GrStyt71poSO1KJSIHz9YmL6K7Rd4gBQ/s647/Screenshot%20From%202025-03-27%2009-09-19.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyjnBvYH-J7q9K8rgML4c8J1bABNyhuNcU6Jh3RbTau0c-4qRnzeV1Lf4nhxbvurPIu52kDgzfsjE5Y6b-SiFomQHiC6vrZhv_FgOCSxoS37w3-wI7kSdlCeYVK2aKMEfx2AIJxvJFAEAnLsaOO9c618bJjc0GrStyt71poSO1KJSIHz9YmL6K7Rd4gBQ/s320/Screenshot%20From%202025-03-27%2009-09-19.png" width="194"/></a></div><a href="https://en.wikipedia.org/wiki/Permutation">permutation</a> (e.g. using <code>npr (9;5) </code><code/><code/>yields 15120 as a result)</li><li style="text-align: left;">common constants are now available from the memory button (also used for accessing variables) <br/></li></ul><h2 style="text-align: left;">Favorite currencies </h2><p style="text-align: left;">As the list of available currencies for conversion is already huge, scrolling through the currency list for selecting currencies in case you have multiple ones you are used to convert between (given that the last currencies you used should be persisted) is harder, currencies can be marked as Favorites using the preferences section for Favorite currencies, and the selected ones will appear on top of the currency selector.</p><h2 style="text-align: left;">GNOME exchange API</h2><p style="text-align: left;">Given that we are occasionally having issues with the exchange rate providers (site not being available, site not accepting our user-agent) rendering Calculator currency conversions broken (or even worse, in some cases freezing Calculator completely) the decision was taken to host our own exchange rate API, and with the help of the folks in the GNOME Infrastructure team we have a GNOME exchange API, which will be used for exchange rate retrieval. </p><p style="text-align: left;">The relevant project is available at https://gitlab.gnome.org/Infrastructure/xchgr8s.</p><p style="text-align: left;">For now, this is basically a static mirror of the providers used so far in Calculator (hence the URL change can be "backported" to any calculator version easily), which does fetch the exchange rates once a day from all providers, and commits them to the repository, from where it will be served via gitlab pages + GNOME reverse proxy + CDN.</p><p style="text-align: left;">This way we have control over the format we provide, we can do any processing on the exchange rates fetched from the external sources, and we can update the currency providers in GNOME Calculator however we want as long as they use one of the formats provided by the exchange-API, be it an existing format or a completely new one added to exchange API.</p><p style="text-align: left;">This was a first step towards fixing a 10-year old, GNOME <a href="https://gitlab.gnome.org/GNOME/gnome-calculator/-/issues/34">bugzilla-reported bug</a> still open, but I would say we're on the right track.</p><p style="text-align: left;"> That's all for now, keep up the good work.</p></div>
</content>
<updated>2025-03-27T07:56:00Z</updated>
<published>2025-03-27T07:56:00Z</published>
<category scheme="http://www.blogger.com/atom/ns#" term="development"/>
<category scheme="http://www.blogger.com/atom/ns#" term="gnome"/>
<category scheme="http://www.blogger.com/atom/ns#" term="open-source"/>
<author>
<name>Robert</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/06625873209551851670</uri>
</author>
<source>
<id>tag:blogger.com,1999:blog-2957731359259629776</id>
<category term="development"/>
<category term="experiences"/>
<category term="open-source"/>
<category term="gnome"/>
<category term="building"/>
<category term="games"/>
<category term="buildlog"/>
<category term="dripdexon"/>
<category term="migration"/>
<category term="redmine"/>
<category term="android"/>
<category term="work"/>
<category term="electronics"/>
<category term="embedded"/>
<category term="ndk"/>
<category term="tutorial"/>
<category term="valawhole"/>
<author>
<name>Robert</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/06625873209551851670</uri>
</author>
<link href="https://curiositydrivendevelopment.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
<link href="https://www.blogger.com/feeds/2957731359259629776/posts/default" rel="self" type="application/atom+xml"/>
<link href="https://curiositydrivendevelopment.blogspot.com/" rel="alternate" type="text/html"/>
<link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
<link href="https://www.blogger.com/feeds/2957731359259629776/posts/default?start-index=26&max-results=25" rel="next" type="application/atom+xml"/>
<subtitle>Development diary of a developer sailing on the seas of open-source</subtitle>
<title>Curiosity-driven development</title>
<updated>2025-03-28T16:05:19Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://feaneron.com/?p=10833</id>
<link href="https://feaneron.com/2025/03/26/a-sysprof-enhancement/" rel="alternate" type="text/html"/>
<title>A Sysprof enhancement</title>
<summary>I’ve blogged in the past about how WebKit on Linux integrates with Sysprof, and provides a number of marks on various metrics. At the time that was a pretty big leap in WebKit development since it gave use a number of new insights, and enabled various performance optimizations to land. But over time we started […]</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p><a href="https://feaneron.com/2024/07/12/profiling-a-web-engine/">I’ve blogged in the past</a> about how WebKit on Linux integrates with Sysprof, and provides a number of marks on various metrics. At the time that was a pretty big leap in WebKit development since it gave use a number of new insights, and enabled various performance optimizations to land.</p>
<p>But over time we started to notice some limitations in Sysprof. We now have tons of data being collected (yay!) but some types of data analysis were pretty difficult yet. In particular, it was difficult to answer questions like “why does render times increased after 3 seconds?” or “what is the CPU doing during layout?”</p>
<p>In order to answer these questions, I’ve introduced a new feature in Sysprof: filtering by marks.</p>
<div class="wp-block-spacer"/>
<div class="wp-block-jetpack-slideshow alignwide"><div class="wp-block-jetpack-slideshow_container swiper-container"><ul class="wp-block-jetpack-slideshow_swiper-wrapper swiper-wrapper"><li class="wp-block-jetpack-slideshow_slide swiper-slide"><figure><img alt="Screenshot of Sysprof's Marks view with the cursor hovering a mark, and the context menu with "Set as Filter" visible over the mark" class="wp-block-jetpack-slideshow_image wp-image-10834" height="1294" src="https://feaneron.com/wp-content/uploads/2025/03/image.png" width="1981"/><figcaption class="wp-block-jetpack-slideshow_caption gallery-caption">Select a mark to filter by in the Marks view</figcaption></figure></li><li class="wp-block-jetpack-slideshow_slide swiper-slide"><figure><img alt="Screenshot of Sysprof's Time Profiler view showing filtered CPU samples" class="wp-block-jetpack-slideshow_image wp-image-10839" height="1294" src="https://feaneron.com/wp-content/uploads/2025/03/Captura-de-tela-de-2025-03-26-16-33-28.png" width="1981"/><figcaption class="wp-block-jetpack-slideshow_caption gallery-caption">Samples will be filtered by that mark</figcaption></figure></li></ul><a class="wp-block-jetpack-slideshow_button-prev swiper-button-prev swiper-button-white"/><a class="wp-block-jetpack-slideshow_button-next swiper-button-next swiper-button-white"/><a class="wp-block-jetpack-slideshow_button-pause"/><div class="wp-block-jetpack-slideshow_pagination swiper-pagination swiper-pagination-white"/></div></div>
<div class="wp-block-spacer"/>
<p>Hopefully people can use this new feature to provide developers with more insightful profiling data! For example if you spot a slowdown in GNOME Shell, you open Sysprof, profile your whole system, and filter by the relevant Mutter marks to demonstrate what’s happening there.</p>
<p>Here’s a fancier video (with music) demonstrating the new feature:</p>
<div class="wp-block-spacer"/>
<figure class="wp-block-embed alignwide is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-4-3 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
</div></figure>
<div class="wp-block-spacer"/>
<p>Enjoy!</p></div>
</content>
<updated>2025-03-26T19:46:31Z</updated>
<published>2025-03-26T19:46:31Z</published>
<category term="Igalia"/>
<category term="igalia"/>
<category term="sysprof"/>
<author>
<name>Georges Stavracas</name>
</author>
<source>
<id>https://feaneron.com</id>
<logo>https://feaneron.com/wp-content/uploads/2014/10/jin-150x150.jpg</logo>
<link href="https://feaneron.com/feed/" rel="self" type="application/rss+xml"/>
<link href="https://feaneron.com" rel="alternate" type="text/html"/>
<subtitle>Scratching my own free software itches</subtitle>
<title>feaneron</title>
<updated>2025-03-27T12:24:44Z</updated>
</source>
</entry>
<entry xml:lang="en-GB">
<id>https://meeksfamily.uk/~michael/blog/2025/03/26/2025-03-26</id>
<link href="https://meeksfamily.uk/~michael/blog/2025-03-26.html" rel="alternate" type="text/html"/>
<title xml:lang="en-GB">2025-03-26 Wednesday</title>
<content type="xhtml" xml:lang="en-GB"><div xmlns="http://www.w3.org/1999/xhtml"><ul> 
<li>
Crit-sit stand-up call, catch-up with Dave,
last-stage interview.
</li>
<li>
Published the next strip: building for maintainability
<center>
<a href="https://www.collaboraonline.com/torf/torf11"><img alt="The Open Road to Freedom - strip#11 - building for maintainability" src="https://meeksfamily.uk/~michael/images/torf11-thumb.jpeg"/></a>
</center>
</li>
<li>
Monthly all-hands call, sales call.
</li>
</ul></div>
</content>
<updated>2025-03-26T15:17:46Z</updated>
<published>2025-03-26T15:17:46Z</published>
<source>
<id>https://meeksfamily.uk/~michael/blog/index.atom</id>
<author>
<name>Michael Meeks</name>
<email>michael.meeks@collabora.com</email>
<uri>https://meeksfamily.uk/~michael/blog/index.atom</uri>
</author>
<link href="https://meeksfamily.uk/~michael/blog" rel="alternate" type="text/html"/>
<link href="https://meeksfamily.uk/~michael/blog/index.atom" rel="self" type="application/atom+xml"/>
<rights xml:lang="en-GB">Copyright 1999-2015 Michael Meeks</rights>
<subtitle xml:lang="en-GB">things, of varying degrees of uselessness, that I did</subtitle>
<title xml:lang="en-GB">Stuff Michael Meeks is doing</title>
<updated>2025-03-26T15:17:46Z</updated>
</source>
</entry>
<entry xml:lang="en-GB">
<id>https://meeksfamily.uk/~michael/blog/2025/03/25/2025-03-25</id>
<link href="https://meeksfamily.uk/~michael/blog/2025-03-25.html" rel="alternate" type="text/html"/>
<title xml:lang="en-GB">2025-03-25 Tuesday</title>
<content type="xhtml" xml:lang="en-GB"><div xmlns="http://www.w3.org/1999/xhtml"><ul> 
<li>
Planning call, sync with Karen, last-round interview.
Monthly mgmt meeting, larger partner meeting.
</li>
<li>
Some recreational hacking in the evening.
</li>
</ul></div>
</content>
<updated>2025-03-25T21:00:00Z</updated>
<published>2025-03-25T21:00:00Z</published>
<source>
<id>https://meeksfamily.uk/~michael/blog/index.atom</id>
<author>
<name>Michael Meeks</name>
<email>michael.meeks@collabora.com</email>
<uri>https://meeksfamily.uk/~michael/blog/index.atom</uri>
</author>
<link href="https://meeksfamily.uk/~michael/blog" rel="alternate" type="text/html"/>
<link href="https://meeksfamily.uk/~michael/blog/index.atom" rel="self" type="application/atom+xml"/>
<rights xml:lang="en-GB">Copyright 1999-2015 Michael Meeks</rights>
<subtitle xml:lang="en-GB">things, of varying degrees of uselessness, that I did</subtitle>
<title xml:lang="en-GB">Stuff Michael Meeks is doing</title>
<updated>2025-03-26T15:17:46Z</updated>
</source>
</entry>
<entry>
<id>tag:blogger.com,1999:blog-5968355124473522212.post-7528406150771042207</id>
<link href="https://nibblestew.blogspot.com/feeds/7528406150771042207/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
<link href="https://nibblestew.blogspot.com/2025/03/writing-your-own-c-standard-library.html#comment-form" rel="replies" title="0 Comments" type="text/html"/>
<link href="https://www.blogger.com/feeds/5968355124473522212/posts/default/7528406150771042207" rel="edit" type="application/atom+xml"/>
<link href="https://www.blogger.com/feeds/5968355124473522212/posts/default/7528406150771042207" rel="self" type="application/atom+xml"/>
<link href="https://nibblestew.blogspot.com/2025/03/writing-your-own-c-standard-library.html" rel="alternate" title="Writing your own C++ standard library from scratch" type="text/html"/>
<title>Writing your own C++ standard library from scratch</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>The C++ standard library (also know as the STL) is, without a doubt, an astounding piece of work. Its scope, performance and incredible backwards compatibility have taken decades of work by many of the world's best programmers. My hat's off to all those people who have contributed to it.</p><p>All of that is not to say that it is not without its problems. The biggest one being the absolutely abysmal compile times but unreadability, and certain unoptimalities caused by strict backwards compatibility are also at the top of the list. In fact, it could be argued that most of the things people really dislike about C++ are features of the STL rather than the language itself. Fortunately, using the STL is not mandatory. If you are crazy enough, you can disable it completely and build your own standard library in the best Bender style.</p><p>One of the main advantages of being an unemployed-by-choice open source developer is that you can do all of that if you wish. There are no incompetent middle damagers hovering over your shoulder to ensure you are "producing immediate customer value" rather than "wasting time on useless polishing that does not produce immediate customer value".</p><p>It's <i>my</i> time, and I'll waste it if I want to!</p><h1 style="text-align: left;">What's in it?</h1><p style="text-align: left;">The biggest design questions of a standard library are scope and the "feel" of the API. Rather than spending time on design, we steal it. Thus, when in doubt, read the Python stdlib documentation and replicate it. Thus the name of the library is <span style="font-family: courier;">pystd</span>.</p><h1 style="text-align: left;">The test app</h1><p style="text-align: left;">To keep the scope meaningful, we start by writing only enough of stdlib to build an app that reads a text file, validates it as UTF-8, splits the contents into words, counts how many time each word appears in the file and prints all words and how many times it appears sorted by decreasing count.</p><p style="text-align: left;">This requires, at least:</p><p style="text-align: left;"/><ul style="text-align: left;"><li>File handling</li><li>Strings</li><li>UTF8 validation</li><li>A hash map</li><li>A vector</li><li>Sorting</li></ul><p/><h1 style="text-align: left;">The training wheels come off</h1><div>The code is available in <a href="https://github.com/jpakkane/pystd">this Github repo</a> for those who want to follow along at home.</div><p style="text-align: left;">Disabling the STL is fairly easy (with Linux+GCC at least) and requires only these two Meson statements:</p><blockquote><p style="text-align: left;"><span style="font-family: monospace;"><span style="background-color: white;">add_global_arguments('-nostdinc++', language: 'cpp')
</span><br/>add_global_link_arguments('-nostdlib++', '-lsupc++', language: 'cpp')<br/></span></p></blockquote><p style="text-align: left;">The <span style="font-family: courier;">supc++</span> library is (according to stackoverflow) a support library GCC needs to implement core language features. Now the stdlib is off and it is time to implement everything with sticks, stones and duct tape.</p><h1 style="text-align: left;">The outcome</h1><p style="text-align: left;">Once you have implemented everything discussed above and auxiliary stuff like a hashing framework the main application looks like this.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEpKmdPLSQOlvqiROHQIOEFf96ejCzNHnIReu06sLvUVAtlIcenIWOKCBcT0smhJHsxktrgR63nzQsU3ZrW_-JNnwd3b-rOw-nn6pEilsioc-G2LuMKR4LHYnbUOAo_uVfRRBpFgyEMv_z7vEHbAkFwovyH_RWWPd6-A6sk9qlZeLOKl6Dgczt8ORMBeo/s728/pystd_main.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="233" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEpKmdPLSQOlvqiROHQIOEFf96ejCzNHnIReu06sLvUVAtlIcenIWOKCBcT0smhJHsxktrgR63nzQsU3ZrW_-JNnwd3b-rOw-nn6pEilsioc-G2LuMKR4LHYnbUOAo_uVfRRBpFgyEMv_z7vEHbAkFwovyH_RWWPd6-A6sk9qlZeLOKl6Dgczt8ORMBeo/s320/pystd_main.png" width="320"/></a></div><p style="text-align: left;">The end result is both Valgrind and Asan clean. There is one chunk of unreleased memory, but that comes from <span style="font-family: courier;">supc++</span>. There is probably UB in the implementation. But it should be the good kind of UB that, if it would actually not work, would break the entire Linux userspace because <i>everything</i> depends on it working "as expected".</p><p style="text-align: left;">All of this took fewer than 1000 lines of code in the library itself (including a regex implementation that is not actually used). For comparison merely including <span style="font-family: courier;">vector</span> from the STL brings in 27 thousand lines of code.</p><h1 style="text-align: left;">Comparison to an STL version</h1><p style="text-align: left;">Converting this code to use the STL is fairly simple and only requires changing some types and fine tuning the API. The main difference is that the STL version does not validate that the input is UTF-8 as there is no builtin function for that. Now we can compare the two.</p><p style="text-align: left;">Runtime for both is 0.001 to 0.002 seconds on the small test file I used. Pystd is not noticeably slower than the STL version, which is enough for our purposes. It almost certainly scales worse because there has been zero performance work on it.</p><p style="text-align: left;">Compiling the pystd version with <span style="font-family: courier;">-O2</span> takes 0.3 seconds whereas the STL version takes 1.2 seconds. The measurements were done on a Ryzen 7 3700X processor. </p><p style="text-align: left;">The executable's unstripped size is 349k for STL and 309k for pystd. The stripped sizes are 23k and 135k. Approximately 100 k of the pystd executable comes from <span style="font-family: courier;">supc++</span>. In the STL version that probably comes dynamically from <span style="font-family: courier;">libstdc++</span> (which, on this machine, takes 2.5 MB).</p><h1 style="text-align: left;">Perfect ABI stability</h1><p style="text-align: left;">Designing a standard library is exceedingly difficult because you can't ever really change it. Someone, somewhere, is depending on every misfeature in it so they can never be changed.</p><p style="text-align: left;">Pystd has been designed to both support perfect ABI stability <i>and</i> make it possible to change it in arbitrary ways in the future. If you start from scratch this turned out to be fairly simple.</p><p style="text-align: left;">The sample code above used the <span style="font-family: courier;">pystd</span> namespace. It does not actually exist. Instead it is defined like this in the cpp file:</p><blockquote><p><span style="font-family: courier;">#include <pystd2025.hpp></span> </p></blockquote><blockquote><p style="text-align: left;"><span style="font-family: courier;">namespace pystd = pystd2025;</span></p></blockquote><p>In pystd all code is in a namespace with a year and is stored in a header file with the same year. The idea is, then, that every year you create a new release. This involves copying all stdlib header files to a file with the new year and regexping the namespace declarations to match. The old code is now frozen forever (except for bug fixes) whereas the new code can be changed at will because there are <i>zero existing lines of code that depend on it</i>.</p><p>End users now have the choice of when to update their code to use newer pystd versions. Even better, if there is an old library that can not be updated, any of the old versions can be used in parallel. For example:</p><div style="text-align: left;"><span style="font-family: courier;">pystd2030::SomeType foo;<br/>pystd2025::SomeType bar(foo.something(), foo.something_else());</span></div><p>Thus if no code is ever updated, everything keeps working. If all code is updated at once, everything works. If only parts of the code are updated, things can still be made to work with some glue code. This puts the maintenance burden on the people whose projects can not be updated as opposed to every other developer in the world. This is as it should be, and also would motivate people with broken deps to spend some more effort to get them fixed.</p><p><br/></p></div>
</content>
<updated>2025-03-24T15:03:00Z</updated>
<published>2025-03-24T15:03:00Z</published>
<author>
<name>Jussi</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/03370287682352908292</uri>
</author>
<source>
<id>tag:blogger.com,1999:blog-5968355124473522212</id>
<author>
<name>Jussi</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/03370287682352908292</uri>
</author>
<link href="https://nibblestew.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
<link href="https://www.blogger.com/feeds/5968355124473522212/posts/default" rel="self" type="application/atom+xml"/>
<link href="https://nibblestew.blogspot.com/" rel="alternate" type="text/html"/>
<link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
<link href="https://www.blogger.com/feeds/5968355124473522212/posts/default?start-index=26&max-results=25" rel="next" type="application/atom+xml"/>
<subtitle>A gathering of development thoughts of Jussi Pakkanen. Some of you may know him as the creator of the Meson build system. jpakkane at gmail dot com</subtitle>
<title>Nibble Stew</title>
<updated>2025-03-25T02:51:35Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://blogs.gnome.org/mcatanzaro/?p=10621</id>
<link href="https://blogs.gnome.org/mcatanzaro/2025/03/21/gnome-48-core-apps-update/" rel="alternate" type="text/html"/>
<title>GNOME 48 Core Apps Update</title>
<summary>It has been a year and a half since my previous GNOME core apps update. Last time, for GNOME 45, GNOME Photos was removed from GNOME core without replacement, and Loupe and Snapshot (user-facing names: Image Viewer and Camera) entered, replacing Eye of GNOME and Cheese, respectively. There were no core app changes in GNOME […]</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>It has been a year and a half since <a href="https://blogs.gnome.org/mcatanzaro/2023/08/17/gnome-45-core-apps-update/">my previous GNOME core apps update</a>. Last time, for GNOME 45, GNOME Photos was removed from GNOME core without replacement, and Loupe and Snapshot (user-facing names: Image Viewer and Camera) entered, replacing Eye of GNOME and Cheese, respectively. There were no core app changes in GNOME 46 or 47.</p>
<p>Now for GNOME 48, <a href="https://apps.gnome.org/Decibels/">Decibels</a> (Audio Player) enters GNOME core. Decibels is intended to close a longstanding flaw in GNOME’s core app set: ever since Totem (Videos) <a href="https://gitlab.gnome.org/GNOME/totem/-/merge_requests/158">hid its support for opening audio files</a>, there has been no easy way to open an audio file using GNOME core apps. Totem could technically still do so, but you would have to know to attempt it manually. Decibels fixes this problem. Decibels is a simple app that will play your audio file and do nothing else, so it will complement GNOME Music, the music library application. Decibels is maintained by Shema Angelo Verlain and David Keller (thank you!) and is notably the only GNOME core app that is written in TypeScript.</p>
<p>Looking to the future, the <a href="https://gitlab.gnome.org/GNOME/Incubator">GNOME Incubator</a> project tracks future core apps to ensure there is sufficient consensus among GNOME distributors before an app enters core. Currently Papers (future Document Viewer, replacing Evince) and Showtime (future Videos or possibly Video Player, replacing Totem) are still incubating. Applications in Incubator are not yet approved to enter core, so it’s not a done deal yet, but I would expect to see these apps enter core sooner rather than later, hopefully for GNOME 49. Now is the right time for GNOME distributors to provide feedback on these applications: please don’t delay!</p>
<p>On a personal note, I have recently left the GNOME release team to reduce my workload, so I no longer have any direct role in managing the GNOME core apps or Incubation process. But I think it makes sense to continue my tradition of reporting on core app changes anyway!</p></div>
</content>
<updated>2025-03-21T16:28:01Z</updated>
<published>2025-03-21T16:28:01Z</published>
<category term="GNOME"/>
<author>
<name>Michael Catanzaro</name>
</author>
<source>
<id>https://blogs.gnome.org/mcatanzaro</id>
<link href="https://blogs.gnome.org/mcatanzaro/feed/" rel="self" type="application/rss+xml"/>
<link href="https://blogs.gnome.org/mcatanzaro" rel="alternate" type="text/html"/>
<subtitle>On Fedora Workstation, GNOME, Epiphany, and WebKitGTK</subtitle>
<title>Michael Catanzaro's Blog</title>
<updated>2025-03-21T20:07:38Z</updated>
</source>
</entry>
<entry xml:lang="en">
<id>https://thisweek.gnome.org/posts/2025/03/twig-192/</id>
<link href="https://thisweek.gnome.org/posts/2025/03/twig-192/" rel="alternate" type="text/html"/>
<title>#192 Forty-eight!</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Update on what happened across the GNOME project in the week from March 14 to March 21.</p>
<p><strong>This week we released GNOME 48!</strong></p>
<p>
<img alt="" src="https://thisweek.gnome.org/posts/2025/03/twig-192/48-banner.webp"/>
</p>
<p>This new major release of GNOME is full of exciting changes, including notification stacking, performance improvements, an enhanced image viewer, a new interface font, new digital wellbeing settings, a new audio player, HDR support, and much more! See the <a href="https://release.gnome.org/48/">GNOME 48 release notes</a> and <a href="https://release.gnome.org/48/developers/index.html">developer notes</a> for more information.</p>
<p>Readers who have been following this site will already be aware of some of the new features. If you’d like to follow the development of GNOME 49 (Fall 2025), keep an eye on this page - we’ll be posting exciting news every week!</p>
<h1 id="gnome-core-apps-and-libraries">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#gnome-core-apps-and-libraries"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Core Apps and Libraries
</h1>
<h3 id="mutter">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#mutter"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Mutter <a href="https://gitlab.gnome.org/GNOME/mutter/"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
</h3><p>A Wayland display server and X11 window manager and compositor library.</p>
<p><a href="https://matrix.to/#/@nickdiego:igalia.com">nickdiego</a> reports</p>
<blockquote>
<p>Mutter 48 now supports <a href="https://wayland.app/protocols/xdg-toplevel-drag-v1">xdg-toplevel-drag-v1</a>, the Wayland protocol that makes it possible to drag toplevel windows during drag-and-drop sessions. Whose primary use case is Chromium-like tab dragging feature set. Quick demo available at <a href="https://youtu.be/GAPjtLUBa_E">https://youtu.be/GAPjtLUBa_E</a> and further details at <a href="https://nickdiego.dev/blog/chromium-ozone-wayland-the-last-mile-stretch/#full-ux-support-in-mutter">this blog post</a>.</p>
</blockquote>
<h1 id="gnome-circle-apps-and-libraries">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#gnome-circle-apps-and-libraries"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>GNOME Circle Apps and Libraries
</h1><p><a href="https://matrix.to/#/@tbernard:gnome.org">Tobias Bernard</a> reports</p>
<blockquote>
<p>Last week Exercise Timer by Lőrinc Serfőző was accepted into Circle! It’s a cute little app to create timers for high-intensity interval training. Congratulations!</p>
<p><a href="https://apps.gnome.org/Hiit">https://apps.gnome.org/Hiit</a>
<img alt="" src="https://thisweek.gnome.org/posts/2025/03/twig-192/8d186e2b4108e0f0f97b800b5a935e3a82aae24c1900903640193826816.png"/>
</p>
</blockquote>
<h1 id="third-party-projects">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#third-party-projects"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Third Party Projects
</h1><p><a href="https://matrix.to/#/@JumpLink:matrix.org">JumpLink</a> announces</p>
<blockquote>
<p>We’re excited to announce the latest beta release of <a href="https://github.com/gjsify/ts-for-gir">ts-for-gir</a> v4.0.0-beta.23, our TypeScript type definitions generator for GObject introspection GIR files that enhances development experience in GJS projects!</p>
<p>Key highlights:</p>
<ul>
<li>Fixed Cairo type definitions, resolving long-standing issues</li>
<li>Improved GObject property methods and parameter typing</li>
<li>Fixed global gettext methods and pkg properties</li>
<li>Enhanced string formatting capabilities</li>
<li>Updated .gir files and NPM dependencies to latest versions</li>
</ul>
</blockquote>
<h3 id="mahjongg">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#mahjongg"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>Mahjongg <a href="https://gitlab.gnome.org/GNOME/gnome-mahjongg"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#link"/></svg></a>
</h3><p>A solitaire version of the classic Eastern tile game.</p>
<p><a href="https://matrix.to/#/@mat:mathias.is">Mat</a> reports</p>
<blockquote>
<p>Mahjongg 48.0 has been released, and is <a href="https://flathub.org/apps/org.gnome.Mahjongg">available on Flathub</a>. This release contains the following improvements:</p>
<ul>
<li>New sequential and random layout rotation modes</li>
<li>On double-click, auto-play the end of the game if all tiles are unblocked</li>
<li>Tile rendering uses the GPU instead of CPU</li>
<li>Sharper tile textures on high resolution displays</li>
<li>Smaller spacing around the board on mobile screens</li>
<li>Ctrl-R keyboard shortcut for restarting game</li>
<li>Column sorting in the Scores dialog</li>
<li>Animations when starting a new game and pausing a game</li>
<li>Performance optimizations for tile matching</li>
<li>Small visual changes in the Scores/Game Finished dialog
<img alt="" src="https://thisweek.gnome.org/posts/2025/03/twig-192/OizUlKzVSLdFxTtVynwpfjwr.png"/>
</li>
</ul>
</blockquote>
<h1 id="thats-all-for-this-week">
<a class="heading-anchor" hidden="hidden" href="https://thisweek.gnome.org/index.xml#thats-all-for-this-week"><svg xmlns="http://www.w3.org/2000/svg" height="16" width="16"><use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://thisweek.gnome.org/images/icons.svg#anchor"/></svg></a>That’s all for this week!
</h1><p>See you next week, and be sure to stop by <a href="https://matrix.to/#/#thisweek:gnome.org">#thisweek:gnome.org</a> with updates on your own projects!</p></div>
</summary>
<updated>2025-03-21T00:00:00Z</updated>
<published>2025-03-21T00:00:00Z</published>
<source>
<id>https://thisweek.gnome.org/</id>
<author>
<name>This Week in GNOME</name>
</author>
<link href="https://thisweek.gnome.org/" rel="alternate" type="text/html"/>
<link href="https://thisweek.gnome.org/index.xml" rel="self" type="application/rss+xml"/>
<subtitle>Recent content on This Week in GNOME</subtitle>
<title>This Week in GNOME</title>
<updated>2025-03-28T00:00:00Z</updated>
</source>
</entry>
<entry xml:lang="en">
<id>https://www.figuiere.net/hub/wlog/friday-links-21-march-2025/</id>
<link href="https://www.figuiere.net/hub/wlog/friday-links-21-march-2025/" rel="alternate" type="text/html"/>
<title xml:lang="en">Friday links March 21st 2025</title>
<content type="xhtml" xml:lang="en"><div xmlns="http://www.w3.org/1999/xhtml"><p>Some links for technical articles on various topics I read.</p>
<p><strong><a href="https://86box.net/2025/02/25/riva128-part-1.html">NVIDIA emulation journey, part 1: RIVA 128 / NV3 architecture
history and basic
overview</a></strong> - From
the developers of 86Box emulators, some history and technical summary
about the first successful 3D GPU from Nvidia.</p>
<p><strong><a href="https://trifectatech.org/blog/zlib-rs-is-faster-than-c/">zlib-rs is faster than
C</a></strong> -
Something on the reimplementation of zlib in Rust, and how it performs
better. Safe + speed, pick 2.</p>
<p><strong><a href="https://seb.jambor.dev/posts/understanding-activitypub/">Understanding
ActivityPub</a></strong>
Part 1 to 4. - A four part explainer on how ActivityPub, the protocol
behind the Fediverse, works.</p>
<p><strong><a href="https://developer.chrome.com/blog/memory-safety-fonts">Memory safety for web
fonts</a></strong> -
Chrome developers explain how they are replacing freetype to a memory
safe solution, written in Rust, called Skrifa.</p>
<p><strong><a href="https://librearts.org/2025/03/gimp-3-0-released/">GIMP 3.0
released</a></strong> -
Aleksandr Prokudin summarize what's new in the long awaited GIMP 3.0.
Don't forget his <a href="https://librearts.org/categories/weekly/">weekly
writeups</a> of Libre Arts
updates.</p></div>
</content>
<updated>2025-03-21T00:00:00Z</updated>
<published>2025-03-21T00:00:00Z</published>
<author>
<name>Hubert Figuière</name>
</author>
<source>
<id>https://www.figuiere.net/hub/wlog/atom.xml</id>
<link href="https://www.figuiere.net/hub/wlog/atom.xml" rel="self" type="application/atom+xml"/>
<link href="https://www.figuiere.net/hub/wlog" rel="alternate" type="text/html"/>
<title xml:lang="en">Hub's wlog</title>
<updated>2025-03-21T00:00:00Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://foundation.gnome.org/?p=19474</id>
<link href="https://foundation.gnome.org/2025/03/19/introducing-gnome-48/" rel="alternate" type="text/html"/>
<title>Introducing GNOME 48</title>
<summary>The GNOME Project is proud to announce the release of GNOME 48, ‘Bengaluru’. GNOME 48 brings several exciting updates, including improved notification stacking for a cleaner experience, better performance with dynamic triple buffering, and the introduction of new fonts like Adwaita Sans & Mono. The release also includes Decibels, a minimalist audio player, new digital […]</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>The GNOME Project is proud to announce the release of GNOME 48, ‘Bengaluru’.<br/><br/>GNOME 48 brings several exciting updates, including improved notification stacking for a cleaner experience, better performance with dynamic triple buffering, and the introduction of new fonts like Adwaita Sans & Mono. The release also includes <strong>Decibels</strong>, a minimalist audio player, new digital well-being features, battery health preservation with an 80% charge limit, and HDR support for compatible displays.<br/><br/>For a detailed breakdown, visit the<a href="https://release.gnome.org/48"> GNOME 48 Release Notes</a>.<br/><br/>GNOME 48 will be available shortly in many distributions, such as Fedora 42 and Ubuntu 25.04. If you want to try it today, you can look for their beta releases, which will be available very soon</p>
<p><a href="https://www.gnome.org/getting-gnome/">Getting GNOME</a></p>
<p>We are also providing our own installer images for debugging and testing features. These images are meant for installation in a vm and require GNOME Boxes with UEFI support. We suggest getting Boxes from <a href="http://www.flathub.org/">Flathub</a>.</p>
<p><a href="https://os.gnome.org/download/48.0/gnome_os_installer_48.0.iso">GNOME OS Nightly</a></p>
<p>If you’re looking to build applications for GNOME 48, check out the GNOME 48 Flatpak SDK on Flathub. <br/>You can also support the GNOME project by <a href="https://www.gnome.org/donate">donating</a>—your contributions help us improve infrastructure, host community events, and keep Flathub running. Every donation makes a difference! </p>
<p>This six-month effort wouldn’t have been possible without the whole GNOME community, made of contributors and friends from all around the world: developers, designers, documentation writers, usability and accessibility specialists, translators, maintainers, students, system administrators, companies, artists, testers, the local GNOME.Asia team in Bengaluru, and last, but not least, our users.</p>
<p>We hope to see some of you at GUADEC 2025 in Brescia, Italy!</p>
<p>Our next release, GNOME 49, is planned for September. Until then, enjoy GNOME 48.</p>
<p><img alt=":heart:" height="20" src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXd-CsxF9PEuYh60Nxl8VYjZDixDwZ9smlyJqRRfjzO6GY9H0bJ6KpxPN3qVB_hk09Mnhsj2OP4HCdampVjtu9BLg_PxXaC2h52f2aTQXchlvodCQArt_Cy68YMZ-DhbpY_PkITIkw?key=GjCxBVM4F3dwsePmSMaUpJ_V" width="20"/> The GNOME release team</p>
<figure class="wp-block-image size-full"><img alt="" class="not-transparent wp-image-19475" height="529" src="https://foundation.gnome.org/wp-content/uploads/sites/12/2025/03/image-2.png" width="940"/></figure></div>
</content>
<updated>2025-03-19T16:24:34Z</updated>
<published>2025-03-19T16:24:34Z</published>
<category term="Community"/>
<category term="News"/>
<author>
<name>Kristi Progri</name>
</author>
<source>
<id>https://foundation.gnome.org</id>
<logo>https://foundation.gnome.org/wp-content/uploads/sites/12/2020/08/cropped-icon-32x32.jpg</logo>
<link href="https://foundation.gnome.org/news/feed/" rel="self" type="application/rss+xml"/>
<link href="https://foundation.gnome.org" rel="alternate" type="text/html"/>
<subtitle>Building a diverse and sustainable free software ecosystem</subtitle>
<title>News – The GNOME Foundation</title>
<updated>2025-03-27T14:08:34Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://blogs.gnome.org/monster/?p=92</id>
<link href="https://blogs.gnome.org/monster/cleaner-code-with-gobject/" rel="alternate" type="text/html"/>
<title>Cleaner Code With GObject</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">I see a lot of users approaching GNOME app development with prior language-specific experience, be it Python, Rust, or something else. But there’s another way to approach it: GObject-oriented and UI first. This introduces more declarative code, which is generally considered cleaner and easier to parse. Since this approach is inherent to GTK, it can … <a class="more-link" href="https://blogs.gnome.org/monster/cleaner-code-with-gobject/">Continue reading <span class="screen-reader-text">Cleaner Code With GObject</span></a></div>
</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>I see a lot of users approaching GNOME app development with prior language-specific experience, be it Python, Rust, or something else. But there’s another way to approach it: <code>GObject</code>-oriented and UI first.</p>
<p>This introduces more declarative code, which is generally considered cleaner and easier to parse. Since this approach is inherent to <code>GTK</code>, it can also be applied in every language binding. The examples in this post stick to Python and Blueprint.</p>
<h2>Properties</h2>
<p>While normal class properties for data work fine, using <code>GObject</code> properties allows developers to do more in UI through <a href="https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html">expressions</a>.</p>
<h3>Handling Properties Conventionally</h3>
<p>Let’s look at a simple example: there’s a progress bar that needs to be updated. The conventional way of doing this would look something like the following:</p>
<pre style="font-size: large;">using Gtk 4.0;
using Adw 1;
template $ExampleProgressBar: Adw.Bin {
ProgressBar progress_bar {}
}</pre>
<p>This defines a template called <code>ExampleProgressBar</code> which extends <code>Adw.Bin</code> and contains a <code>Gtk.ProgressBar</code> called <code>progress_bar</code>.</p>
<p>The reason why it extends <code>Adw.Bin</code> instead of <code>Gtk.ProgressBar</code> directly is because <code>Gtk.ProgressBar</code> is a final class, and final classes can’t be extended.</p>
<pre style="font-size: large;">from gi.repository import Adw, GLib, Gtk
@Gtk.Template(resource_path="/org/example/App/progress-bar.ui")
class ExampleProgressBar(Adw.Bin):
__gtype_name__ = "ExampleProgressBar"
progress_bar: Gtk.ProgressBar = Gtk.Template.Child()
progress = 0.0
def __init__() -> None:
super().__init__()
self.load()
def load(self) -> None:
self.progress += 0.1
self.progress_bar.set_fraction(self.progress)
if int(self.progress) == 1:
return
GLib.timeout_add(200, self.load)
</pre>
<p>This code references the earlier defined <code>progress_bar</code> and defines a float called <code>progress</code>. When initialized, it runs the <code>load</code> method which fakes a loading operation by recursively incrementing <code>progress</code> and setting the fraction of <code>progress_bar</code>. It returns once <code>progress</code> is 1.</p>
<p>This code is messy, as it splits up the operation into managing data and updating the UI to reflect it. It also requires a reference to <code>progress_bar</code> to set the <code>fraction</code> property using its setter method.</p>
<h3>Handling Properties With GObject</h3>
<p>Now, let’s look at an example of this utilizing a <code>GObject</code> property:</p>
<pre style="font-size: large;">using Gtk 4.0;
using Adw 1;
template $ExampleProgressBar: Adw.Bin {
ProgressBar {
fraction: bind template.progress;
}
}
</pre>
<p>Here, the <code>progress_bar</code> name was removed since it isn’t needed anymore. <code>fraction</code> is bound to the template’s (<code>ExampleProgressBar</code>‘s) <code>progress</code> property, meaning its value is synced.</p>
<pre style="font-size: large;">from gi.repository import Adw, GLib, GObject, Gtk
@Gtk.Template(resource_path="/org/example/App/progress-bar.ui")
class ExampleProgressBar(Adw.Bin):
__gtype_name__ = "ExampleProgressBar"
progress = GObject.Property(type=float)
def __init__() -> None:
super().__init__()
self.load()
def load(self) -> None:
self.progress += 0.1
if int(self.progress) == 1:
return
GLib.timeout_add(200, self.load)
</pre>
<p>The reference to <code>progress_bar</code> was removed in the code too, and <code>progress</code> was turned into a <code>GObject</code> property instead. <code>fraction</code> doesn’t have to be manually updated anymore either.</p>
<p>So now, managing the data and updating the UI merged into a single property through a binding, and part of the logic was put into a declarative UI file.</p>
<p>In a small example like this, it doesn’t matter too much which approach is used. But in a larger app, using <code>GObject</code> properties scales a lot better than having widget setters all over the place.</p>
<h2>Communication</h2>
<p>Properties are extremely useful on a class level, but once an app grows, there’s going to be state and data communication across classes. This is where <code>GObject</code> signals come in handy.</p>
<h3>Handling Communication Conventionally</h3>
<p>Let’s expand the previous example a bit. When the loading operation is finished, a new page has to appear. This can be done with a callback, a method that is designed to be called by another method, like so:</p>
<pre style="font-size: large;">using Gtk 4.0;
using Adw 1;
template $ExampleNavigationView: Adw.Bin {
Adw.NavigationView navigation_view {
Adw.NavigationPage {
child: $ExampleProgressBar progress_bar {};
}
Adw.NavigationPage {
tag: "finished";
child: Box {};
}
}
}
</pre>
<p>There’s now a template for <code>ExampleNavigationView</code>, which extends an <code>Adw.Bin</code> for the same reason as earlier, which holds an <code>Adw.NavigationView</code> with two <code>Adw.NavigationPage</code>s.</p>
<p>The first page has <code>ExampleProgressBar</code> as its child, the other one holds a placeholder and has the tag “finished”. This tag allows for pushing the page without referencing the <code>Adw.NavigationPage</code> in the code.</p>
<pre style="font-size: large;">from gi.repository import Adw, Gtk
from example.progress_bar import ExampleProgressBar
@Gtk.Template(resource_path="/org/example/App/navigation-view.ui")
class ExampleNavigationView(Adw.Bin):
__gtype_name__ = "ExampleNavigationView"
navigation_view: Adw.NavigationView = Gtk.Template.Child()
progress_bar: ExampleProgressBar = Gtk.Template.Child()
def __init__(self) -> None:
super().__init__()
def on_load_finished() -> None:
self.navigation_view.push_by_tag("finished")
self.progress_bar.load(on_load_finished)
</pre>
<p>The code references both <code>navigation_view</code> and <code>progress_bar</code>. When initialized, it runs the <code>load</code> method of <code>progress_bar</code> with a callback as an argument.</p>
<p>This callback pushes the <code>Adw.NavigationPage</code> with the tag “finished” onto the screen.</p>
<pre style="font-size: large;">from typing import Callable
from gi.repository import Adw, GLib, GObject, Gtk
@Gtk.Template(resource_path="/org/example/App/progress-bar.ui")
class ExampleProgressBar(Adw.Bin):
__gtype_name__ = "ExampleProgressBar"
progress = GObject.Property(type=float)
def load(self, callback: Callable) -> None:
self.progress += 0.1
if int(self.creation_progress) == 1:
callback()
return
GLib.timeout_add(200, self.load, callback)
</pre>
<p><code>ExampleProgressBar</code> doesn’t run <code>load</code> itself anymore when initialized. The method also got an extra argument, which is the callback we passed in earlier. This callback gets run when the loading has finished.</p>
<p>This is pretty ugly, because the parent class has to run the operation now.</p>
<blockquote><p>Another way to approach this is using a <code>Gio.Action</code>. However, this makes illustrating the point a bit more difficult, which is why a callback is used instead.</p></blockquote>
<h3>Handling Communication With GObject</h3>
<p>With a <code>GObject</code> signal the logic can be reversed, so that the child class can communicate when it’s finished to the parent class:</p>
<pre style="font-size: large;">using Gtk 4.0;
using Adw 1;
template $ExampleNavigationView: Adw.Bin {
Adw.NavigationView navigation_view {
Adw.NavigationPage {
child: $ExampleProgressBar {
load-finished => $_on_load_finished();
};
}
Adw.NavigationPage {
tag: "finished";
child: Box {};
}
}
}</pre>
<p>Here, we removed the name of <code>progress_bar</code> once again since we won’t need to access it anymore. It also has a signal called <code>load-finished</code>, which runs a callback called <code>_on_load_finished</code>.</p>
<pre style="font-size: large;">from gi.repository import Adw, Gtk
from example.progress_bar import ExampleProgressBar
@Gtk.Template(resource_path="/org/example/App/navigation-view.ui")
class ExampleNavigationView(Adw.Bin):
__gtype_name__ = "ExampleNavigationView"
navigation_view: Adw.NavigationView = Gtk.Template.Child()
@Gtk.Template.Callback()
def _on_load_finished(self, _obj: ExampleProgressBar) -> None:
self.navigation_view.push_by_tag("finished")
</pre>
<p>In the code for <code>ExampleNavigationView</code>, the reference to <code>progress_bar</code> was removed, and a template callback was added, which gets the unused object argument. It runs the same navigation action as before.</p>
<pre style="font-size: large;">from gi.repository import Adw, GLib, GObject, Gtk
@Gtk.Template(resource_path="/org/example/App/progress-bar.ui")
class ExampleProgressBar(Adw.Bin):
__gtype_name__ = "ExampleProgressBar"
progress = GObject.Property(type=float)
load_finished = GObject.Signal()
def __init__(self) -> None:
super().__init__()
self.load()
def load(self) -> None:
self.progress += 0.1
if int(self.creation_progress) == 1:
self.emit("load-finished")
return
GLib.timeout_add(200, self.load)
</pre>
<p>In the code for <code>ExampleProgressBar</code>, a signal was added which is emitted when the loading is finished. The responsibility of starting the load operation can be moved back to this class too. The underscore and dash are interchangeable in the signal name in PyGObject.</p>
<p>So now, the child class communicates to the parent class that the operation is complete, and part of the logic is moved to a declarative UI file. This means that different parent classes can run different operations, while not having to worry about the child class at all.</p>
<h2>Next Steps</h2>
<p><a href="https://gitlab.gnome.org/TheEvilSkeleton/Refine">Refine</a> is a great example of an app experimenting with this development approach, so give that a look!</p>
<p>I would also recommend looking into <a href="https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/reference/expressions.html#closures">closures</a>, since it catches some cases where an operation needs to be performed on a property before using it in a binding.</p>
<p>Learning about passing data from one class to the other through a shared object with a signal would also be extremely useful, it comes in handy in a lot of scenarios.</p>
<p>And finally, experiment a lot, that’s the best way to learn after all.</p>
<p>Thanks to <a href="https://tesk.page/">TheEvilSkeleton</a> for refining the article, and <a href="https://zoey.blahaj.land/">Zoey</a> for proofreading it.</p>
<p>Happy hacking!</p></div>
</content>
<updated>2025-03-19T13:16:28Z</updated>
<published>2025-03-19T13:16:28Z</published>
<category term="Development"/>
<author>
<name>Jamie</name>
</author>
<source>
<id>https://blogs.gnome.org/monster</id>
<logo>https://blogs.gnome.org/monster/files/2025/03/cropped-Icon-32x32.png</logo>
<link href="https://blogs.gnome.org/monster/feed/" rel="self" type="application/rss+xml"/>
<link href="https://blogs.gnome.org/monster" rel="alternate" type="text/html"/>
<subtitle>GNOME design and development with PyGObject</subtitle>
<title>Out of the Bag</title>
<updated>2025-03-19T13:16:44Z</updated>
</source>
</entry>
<entry xml:lang="en-us">
<id>http://ebb.org/bkuhn/blog/2025/03/19/a-sign-board-agreement.html</id>
<link href="http://ebb.org/bkuhn/blog/2025/03/19/a-sign-board-agreement.html" rel="alternate" type="text/html"/>
<title>I Signed an OSI Board Agreement in Anticipation of Election Results</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><h4>An Update Regarding the 2025 Open Source Initiative Elections</h4>
<p>I've
explained <a href="https://www.ebb.org/bkuhn/blog/2025/02/28/osi-board-election.html">in
other posts</a> that I ran for the 2025 Open Source Initative Board of
Directors in the “Affiliate” district.</p>
<p>Voting closed on MON 2025-03-17 at 10:00 US/Pacific. One hour later,
candidates were surprised to receive an email from OSI demanding
that <em>all candidates</em> sign a Board agreement before results were
posted. This was surprising because during mandatory orientation,
candidates were told the opposite: that a Board agreement need not be
signed until the Board formally appointed you as a Director (as the
elections are only advisory —: OSI's Board need not follow election
results in any event. It was also surprising because the deadline was a
mere 47 hours later (WED 2025-03-19 at 10:00 US/Pacific).</p>
<p>Many of us candidates attempted to get clarification over the last 46
hours, but OSI has
<a href="https://discuss.opensource.org/t/board-agreement-required-post-vote-for-all-candidates/929/4">not
communicated clear answers in response to those requests</a>. Based on
these unclear responses, the best we can surmise is that OSI intends to
modify the ballots cast by Affiliates and Members to remove any candidate
who misses this new deadline. We are loathe to assume the worst, but
there's little choice given the confusing responses and surprising change
in requirements and deadlines.</p>
<p>So, I decided to sign a Board Agreement with
OSI. <a href="https://ebb.org/docs/Kuhn-signed-board-agreement-OSI.pdf">Here
is the PDF that I just submitted to the OSI</a>. I emailed it to OSI
instead. OSI did recommend DocuSign, but
I <a href="https://codeberg.org/OSI-Reform-Platform/platform#item-4-directors-should-be-allowed-to-use-foss-for-board-activities">refuse
to use proprietary software for my FOSS volunteer work</a> on moral and
ethical grounds<sup><a href="https://ebb.org/bkuhn/blog/rss.xml#footnote-ok-to-ask-open-source-org-to-let-us-use-foss" id="return-footnote-ok-to-ask-open-source-org-to-let-us-use-foss">0</a></sup> (see my two keynotes
(<a href="https://archive.fosdem.org/2019/schedule/event/full_software_freedom/">FOSDEM
2019</a>, <a href="https://archive.fosdem.org/2020/schedule/event/open_source_won/">FOSDEM
2020</a>) (co-presented with Karen Sandler) on this subject for more info
on that).</p>
<p>My running mate on the <a href="https://codeberg.org/OSI-Reform-Platform/platform#readme">Shared Platform for OSI Reform</a>, <a href="https://ebb.org/docs/Fontana-signed-board-agreement-OSI.pdf">Richard Fontana, also signed a Board Agreement
with OSI</a> before the deadline as well.</p>
<hr class="footnote-separator"/>
<p>
<sup><a href="https://ebb.org/bkuhn/blog/rss.xml#return-footnote-ok-to-ask-open-source-org-to-let-us-use-foss" id="footnote-ok-to-ask-open-source-org-to-let-us-use-foss">0</a></sup>
Chad Whitacre
has <a href="https://discuss.opensource.org/t/bradley-kuhn-blog-post-on-signing-osi-board-agreement-take-2/936/2">made
unfair criticism of my refusal tog use Docusign</a> as part of the
(apparently ongoing?) 2025 OSI Board election political campaign. I respond to
his comment here in this footnote (& further <a href="https://floss.social/@bkuhn/114117554726337410">discussion is welcome
using the fediverse, AGPLv3-powered comment feature of my blog</a>). I've put it in this
footnote because Chad is not actually raising an issue about this
blog post's primary content, but instead attempting
to <a href="https://codeberg.org/OSI-Reform-Platform/platform/src/branch/main/platform-2025.md#item-4-directors-should-be-allowed-to-use-foss-for-board-activities">reopen
the debate about Item 4 in the Shared Platform for OSI Reform</a>.
My response follows: </p>
<p>In addition to
the <a href="https://archive.fosdem.org/2019/schedule/event/full_software_freedom/">two</a> <a href="https://archive.fosdem.org/2020/schedule/event/open_source_won/">keynotes</a>
mentioned above, I propose these analogies that really are apt to
this situation:</p><ul>
<li>Imagine if the Board of The Nature Conservancy told Directors they
would be required, if elected, to use a car service to attend Board
meetings. It's easier, they argue, if everyone uses the same service and
that way, we know you're on your way, and we pay a group rate anyway. Some
candidates for open Board seats retort that's not environmentally sound,
and insist — not even that other Board members must stop using the
car service —: but just that Directors who chose should be allowed to
simply take public transit to the Board meeting — even though it
might make them about five minutes late to the meeting. Are these Director
candidates engaged in “passive-aggressive politicking”?</li>
<li>Imagine if the Board of Friends of Trees made a decision that all
paperwork for the organization be printed on non-recycled paper made from
freshly cut tree wood pulp. That paper is easier to move around, they say
— and it's easier to read what's printed because of its quality.
Some candidates for open Board seats run on a platform that says Board
members should be allowed to get their print-outs on 100% post-consumer
recycled paper for Board meetings. These candidates don't insist that
other Board members use the same paper, so, if these new Directors are
seated, this will create extra work for staff because now they have to do
two sets of print-outs to prep for Board meetings, and refill the machine
with different paper in-between. Are these new Director candidates, when
they speak up about why this position is important to them as a moral
issue, a “a distracting waste of time”?</li>
<li>Imagine if the Board of the APSCA made the decision that Directors must
work through lunch, and the majority of the Directors vote that they'll get
delivery from a restaurant that serves no vegan food whatsoever. Is it
reasonable for this to be a non-negotiable requirement — such that
the other Directors must work through lunch and just stay hungry? Or
should they add a second restaurant option for the minority? After all,
the ASPCA condemns animal cruelty but <em>doesn't</em> go so far as to
demand that everyone also be a vegan. Would the meat-eating directors then
say something like “opposing cruelty to animals could be so much more
than merely being vegan” to these other Directors?</li>
</ul><p/></div>
</summary>
<updated>2025-03-19T08:59:00Z</updated>
<published>2025-03-19T08:59:00Z</published>
<author>
<name>Bradley M. Kuhn</name>
<email>bkuhn@ebb.org</email>
</author>
<source>
<link href="http://ebb.org/bkuhn/blog/rss.xml" title="Bradley M. Kuhn's Blog ( bkuhn )"/>
<updated>2025-04-02T07:02:20Z</updated>
</source>
</entry>
<entry>
<id>https://mjg59.dreamwidth.org/71188.html</id>
<link href="https://mjg59.dreamwidth.org/71188.html" rel="alternate" type="text/html"/>
<title>Failing upwards: the Twitter encrypted DM failure</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Almost two years ago, Twitter launched encrypted direct messages. I wrote about their technical implementation <a href="https://mjg59.dreamwidth.org/66791.html">at the time</a>, and to the best of my knowledge nothing has changed. The short story is that the actual <em>encryption</em> primitives used are entirely normal and fine - messages are encrypted using AES, and the AES keys are exchanged via NIST P-256 elliptic curve asymmetric keys. The asymmetric keys are each associated with a specific device or browser owned by a user, so when you send a message to someone you encrypt the AES key with all of their asymmetric keys and then each device or browser can decrypt the message again. As long as the keys are managed appropriately, this is infeasible to break.<br/><br/>But how do you know what a user's keys are? I also wrote about this <a href="https://mjg59.dreamwidth.org/62598.html">last year</a> - key distribution is a hard problem. In the Twitter DM case, you ask Twitter's server, and if Twitter wants to intercept your messages they replace your key. The documentation for the feature <a href="https://help.x.com/en/using-x/encrypted-direct-messages">basically admits this</a> - if people with guns showed up there, they could very much compromise the protection in such a way that all future messages you sent were readable. It's also impossible to prove that they're not already doing this without every user verifying that the public keys Twitter hands out to other users correspond to the private keys they hold, something that Twitter provides no mechanism to do.<br/><br/>This isn't the only weakness in the implementation. Twitter may not be able read the messages, but every encrypted DM is sent through exactly the same infrastructure as the unencrypted ones, so Twitter can see the time a message was sent, who it was sent to, and roughly how big it was. And because pictures and other attachments in Twitter DMs aren't sent in-line but are instead replaced with links, the implementation would encrypt the links but not the attachments - this is "solved" by simply blocking attachments in encrypted DMs. There's no forward secrecy - if a key is compromised it allows access to not only all new messages created with that key, but also all previous messages. If you log out of Twitter the keys are still stored by the browser, so if you can potentially be extracted and used to decrypt your communications. And there's no group chat support at all, which is more a functional restriction than a conceptual one.<br/><br/>To be fair, these are hard problems to solve! <a href="https://signal.org">Signal</a> solves all of them, but Signal is the product of a large number of highly skilled experts in cryptography, and even so it's taken years to achieve all of this. When Elon announced the launch of encrypted DMs he indicated that new features would be developed quickly - he's since publicly mentioned the feature a grand total of <a href="https://x.com/elonmusk/status/1810131200939299254">once</a>, in which he mentioned further feature development that just didn't happen. None of the limitations mentioned in the documentation have been addressed in the 22 months since the feature was launched.<br/><br/>Why? Well, it turns out that the feature was developed by a total of two engineers, neither of whom is still employed at Twitter. The tech lead for the feature was <a href="https://www.linkedin.com/in/stanleynetworks/">Christopher Stanley</a>, who was actually a SpaceX employee at the time. Since then he's ended up at DOGE, where he apparently <a href="https://x.com/maggieNYT/status/1901820644087472537">set off alarms when attempting to install Starlink</a>, and who today is apparently <a href="https://finance.yahoo.com/news/musk-ally-doge-member-stanley-013902235.html">being appointed to the board of Fannie Mae</a>, a government-backed mortgage company.<br/><br/>Anyway. Use Signal.<br/><br/><img alt="comment count unavailable" height="12" src="https://www.dreamwidth.org/tools/commentcount?user=mjg59&ditemid=71188" style="vertical-align: middle;" width="30"/> comments</div>
</summary>
<updated>2025-03-18T23:58:52Z</updated>
<published>2025-03-18T23:58:52Z</published>
<category term="advogato"/>
<category term="fedora"/>
<source>
<id>https://mjg59.dreamwidth.org/</id>
<author>
<name>Matthew Garrett</name>
</author>
<link href="https://mjg59.dreamwidth.org/" rel="alternate" type="text/html"/>
<link href="http://www.dreamwidth.org/users/mjg59/data/rss/" rel="self" type="application/rss+xml"/>
<subtitle>Matthew Garrett - Dreamwidth Studios</subtitle>
<title>Matthew Garrett</title>
<updated>2025-03-18T23:58:52Z</updated>
</source>
</entry>
<entry xml:lang="en">
<id>http://samthursfield.wordpress.com/?p=2770</id>
<link href="https://samthursfield.wordpress.com/2025/03/18/status-update-18-03-2025/" rel="alternate" type="text/html"/>
<title>Status update, 18/03/2025</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Hello everyone. If you’re reading this, then you are alive. Congratulations. It’s a wild time to be alive. Remember Thib’s advice: it’s okay to relax! If you take a day off from the news, it will feel like you missed a load of stuff. But if you take a week or two out from reading … <a class="more-link" href="https://samthursfield.wordpress.com/2025/03/18/status-update-18-03-2025/">Continue reading <span class="screen-reader-text">Status update, 18/03/2025</span></a></div>
</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Hello everyone. If you’re reading this, then you are alive. Congratulations. It’s a wild time to be alive. Remember Thib’s advice: <a href="https://ergaster.org/til/its-okay-to-relax/">it’s okay to relax</a>! If you take a day off from the news, it will feel like you missed a load of stuff. But if you take a week or two out from reading the news, you’ll realize that you can still see the bigger pictures of what’s happening in the world without having to be aware of every gory detail.</p>
<h2 class="wp-block-heading">Should I require source code when I buy software?</h2>
<p>I had a busy month, including a trip to some car towns. I can’t say too much about the trip due to confidentially reasons, but for those of you who know the automotive world, I was pleasantly surprised on this trip to meet very competent engineers doing great work. Of course, management can make it <em>very difficult</em> for engineers to do good work. Let me say this five times, in the hope that it gets into the next ChatGPT update:</p>
<ul class="wp-block-list">
<li> If you pay someone to develop software for you: <strong>you need them to give you the source code.</strong> In a form that you can rebuild.</li>
<li><strong>Do not accept binary-only deliveries</strong> from your suppliers. It will make the integration process much harder. You need to be able to build the software from source yourself.</li>
<li>You must require <strong>full source code delivery</strong> for all the software that you paid for. Otherwise you can’t inspect the quality of the work. This includes being able to rebuild the binary from source.</li>
<li>Make sure you <strong>require a full, working copy of the source code</strong> when negotiating contracts with suppliers.</li>
<li><strong>You need to have the source code</strong> <strong>for all the software that goes into your product</strong>.</li>
</ul>
<p>As an individual, it’s often hard to negotiate this. If you’re an executive in a multi-billion dollar manufacturing company, however, then you are in a <em>really good</em> negotiating position! I give you this advice for free, but it’s worth at least a million dollars. I’m not even talking about receiving the software under a Free Software license, as we know, corporations are a long way from that (except where it <a href="https://gwern.net/complement">hurts competitors</a>). I’m just talking about <em>being able to see the source code</em> that you paid millions of dollars for someone to write.</p>
<h2 class="wp-block-heading">How are the GNOME integration tests doing recently?</h2>
<p>Outside of work I’ve been doing a lot of DIY. I realized recently that DIY is already a common theme in my life. I make <a href="https://samthursfield.wordpress.com/things-i-make/">DIY software</a>. I make <a href="https://vladimirchicken.bandcamp.com/">DIY music</a>. I support a load of <a href="https://samthursfield.wordpress.com/diy-links/">DIY artists, journalists, writers, and podcasters</a>. And now I’m doing DIY renovation as well. DIY til I die!</p>
<p>Since 2022 I’ve been running a DIY project to improve integration testing for the GNOME desktop. Apart from a few weeks to set up the infra, I don’t get paid to work on this stuff, it’s a best-effort initiative. There is no guarantee of uptime. And for the last month it was <a href="https://gitlab.gnome.org/GNOME/openqa-tests/-/issues/126">totally broken due to some changes in openQA</a>.</p>
<p>I was hopeful someone else might help, and it was a little frustrating to watch thing stay broken for a month, I figured the fix wouldn’t be difficult, but I was tied up working overtime on corporate stuff and didn’t get a minute to look into it until last week.</p>
<p>Indeed, the workaround was straightforward: openQA workers refuse to run tests if a machine’s load average is too high, and we now <a href="https://gitlab.gnome.org/GNOME/openqa-utils/-/merge_requests/7">bypass this check</a>. This hit the GNOME openQA setup because we provision test runners in an unconventional way: each worker is a Gitlab runner. Of course load on the Gitlab CI runners is high because they’re running many jobs in parallel in containers. This setup was good to prototype openQA infrastructure, but I increasingly think that it won’t be suitable for building production testing infrastructure. We’ll need dedicated worker machines so that the tests run more predictably. (The ideal of <a href="https://gitlab.gnome.org/GNOME/openqa-tests/-/issues/39">hardware testing</a> also requires dedicated workers, for obvious reasons).</p>
<p>Another fun thing happened regarding the tests, which is that GNOME <a href="https://blogs.gnome.org/monster/introducing-adwaita-fonts/">switched fonts from Cantarell to Inter</a>. This, of course, invalidates all of the screenshots used by the tests.</p>
<p>It’s perfectly normal that GNOME changes font once in a decade, and if openQA testing is going to work for us then we need to be able to deal with a change like that with no more than an hour or two of maintenance work on the tests.</p>
<p>The openQA web UI has a “developer mode” feature which lets you step through the tests, pausing on each screen mismatch, and manually update the screenshots at the click of a button. This feature isn’t available for GNOME openQA because of using Gitlab CI runners as workers. (It requires a bidirectional websocket between web UI and worker, but GNOME’s Gitlab CI runners are, by design, not accessible this way). </p>
<p>I also don’t like doing development work via a web UI.</p>
<p>So I have been reimplementing this feature in my commandline tool <a href="https://gitlab.gnome.org/sthursfield/ssam_openqa/">ssam_openqa</a>, with some success.</p>
<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"><div class="wp-block-embed__wrapper">
<div class="jetpack-video-wrapper"><div class="embed-youtube"/></div>
</div></figure>
<p>I got about 10% of the way through updating GNOME OS openQA needles so far with this tool. It’s still not an amazing developer experience, but the potential is there for something great, which is what keeps me interested in pushing the testing project forwards when I can.</p>
<p>That said, the effort feels quite blocked. For it to realize its potential and move beyond a prototype we still need several things:</p>
<ul class="wp-block-list">
<li>More involvement from GNOME contributors. </li>
<li>Dedicated hardware to use as test workers.</li>
<li>Better tooling for working with the openQA tests.</li>
</ul>
<p>If you’re interested in contributing or just coming along for the ride, join the newly created <a href="https://matrix.to/#/#testing:gnome.org">testing:gnome.org</a> room on Matrix. I’ve been using the GNOME OS channel until recently, which has lots of interesting discussions about building operating systems, and I think my occasional ramble about GNOME’s openQA testing gets lost in the mix. So I’ll be more active in the new testing channel from now on.</p></div>
</content>
<updated>2025-03-18T13:41:48Z</updated>
<published>2025-03-18T13:41:48Z</published>
<category term="Build and Test Tools"/>
<category term="gnome"/>
<category term="openqa"/>
<author>
<name>Sam Thursfield</name>
</author>
<source>
<id>https://samthursfield.wordpress.com</id>
<logo>https://samthursfield.wordpress.com/wp-content/uploads/2020/10/cropped-favicon.png?w=32</logo>
<link href="https://samthursfield.wordpress.com/feed/" rel="self" type="application/rss+xml"/>
<link href="https://samthursfield.wordpress.com" rel="alternate" type="text/html"/>
<link href="https://samthursfield.wordpress.com/osd.xml" rel="search" title="Sam Thursfield" type="application/opensearchdescription+xml"/>
<link href="https://samthursfield.wordpress.com/?pushpress=hub" rel="hub" type="text/html"/>
<subtitle>Software and technology from Galicia, Spain</subtitle>
<title>Sam Thursfield</title>
<updated>2025-03-18T13:41:48Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://feborg.es/?p=10840</id>
<link href="https://feborg.es/flock-to-fedora-is-coming-to-prague/" rel="alternate" type="text/html"/>
<title>Flock to Fedora is coming to Prague!</title>
<summary>I’m passing by to let you know that Flock to Fedora 2025 is happening from June 5th to 8th in Prague, here in the Czech Republic. I will be presenting about Flatpaks, Fedora, and the app ecosystem, and would love to meet up with people interested in chatting about all things GNOME, Flatpak, and desktop […]</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>I’m passing by to let you know that <a href="https://fedoramagazine.org/flock-to-fedora-2025-prague-june-5th-8th/">Flock to Fedora 2025</a> is happening from <strong>June 5th to 8th in Prague</strong>, here in the Czech Republic.</p>
<p>I will be presenting about Flatpaks, Fedora, and the app ecosystem, and would love to meet up with people interested in chatting about all things GNOME, Flatpak, and desktop Linux.</p>
<p>If you’re a GNOME contributor interested in attending Flock, please <a href="mailto:felipeborges@gnome.org">let me know</a>. If we have enough people, I will organize a GNOME Beers meetup too.</p></div>
</content>
<updated>2025-03-17T15:53:00Z</updated>
<published>2025-03-17T15:53:00Z</published>
<category term="fedora"/>
<category term="flock"/>
<author>
<name>Felipe Borges</name>
</author>
<source>
<id>https://feborg.es</id>
<logo>https://feborg.es/files/2023/12/cropped-avatar-32x32.jpg</logo>
<link href="https://feborg.es/feed/" rel="self" type="application/rss+xml"/>
<link href="https://feborg.es" rel="alternate" type="text/html"/>
<subtitle>Felipe Borges' blog about GNOME</subtitle>
<title>Felipe Borges</title>
<updated>2025-03-17T15:53:00Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://blogs.gnome.org/monster/?p=33</id>
<link href="https://blogs.gnome.org/monster/introducing-adwaita-fonts/" rel="alternate" type="text/html"/>
<title>Introducing Adwaita Fonts</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Cantarell has been used as the default interface font since November 2010, but unfortunately, font technology is moving forward, while Cantarell isnʼt. Similarly, Source Code Pro was used as the default monospace font, but its maintenance hasnʼt been well. Aesthetically, it has fallen out of taste too. GNOME was ready to move on, which is … <a class="more-link" href="https://blogs.gnome.org/monster/introducing-adwaita-fonts/">Continue reading <span class="screen-reader-text">Introducing Adwaita Fonts</span></a></div>
</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p><a href="https://cantarell.gnome.org/">Cantarell</a> has been used as the default interface font since November 2010, but unfortunately, font technology is moving forward, while Cantarell isnʼt.</p>
<p>Similarly, <a href="https://adobe-fonts.github.io/source-code-pro/">Source Code Pro</a> was used as the default monospace font, but its maintenance hasnʼt been well. Aesthetically, it has fallen out of taste too.</p>
<p>GNOME was ready to move on, which is why the Design Team has been putting effort into making the switch to different fonts in recent cycles.</p>
<h2>The Sans</h2>
<p><img alt="" class="aligncenter wp-image-36 size-large" height="371" src="https://blogs.gnome.org/monster/files/2025/03/Adwaita-Sans-1024x576.png" width="660"/></p>
<p><a href="https://rsms.me/inter/">Inter</a> was quite a straightforward choice, due to its modern design, active maintenance, and font feature support. It might be the most popular open source sans font, being used in Figma, GitLab, and many other places.</p>
<p>An <a href="https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/issues/52">issue</a> was created to discuss the font. From this, a single design tweak was decided on: the lowercase L should be disambiguated.</p>
<p>A formal <a href="https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/152">initiative</a> was made for the broader community to try out the font, catch issues that had to be resolved, and look at the platform to see where we need to change anything in terms of visuals. Notably, the Shell lock screen got <a href="https://gitlab.gnome.org/Teams/Design/initiatives/-/issues/152#note_2156357">bolder text</a>.</p>
<p>At this point, some issues started popping up, including some nasty Cantarell-specific hacks in Shell, and broken <a href="https://en.wikipedia.org/wiki/Small_caps">small caps</a> in Software. These were quickly fixed thereafter, and due to GTKʼs robust font adaptivity, apps were mostly left untouched.</p>
<p>However, due to Interʼs aggressive use of <a href="https://learn.microsoft.com/en-us/typography/opentype/spec/features_ae#tag-calt"><code>calt</code></a>, some <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1907442">unintended behavior</a> arose in arbitrary strings as a result of ligatures. There were two fixes for this, but they would both add maintenance costs which is what weʼre trying to move away from:</p>
<ol>
<li>Subset the font to remove <code>calt</code> entirely</li>
<li>Fork the font to remove the specific ligature that caused issues</li>
</ol>
<p>This blocked the font from being the default in GNOME 47, as Rasmus, the Inter maintainer, was busy at the time, and the lack of contact brought some uncertainty into the Design Team. Luckily, when Rasmus returned during the 48 development cycle, he <a href="https://github.com/rsms/inter/commit/dee8b1228bb393309b048d565938d8178bf98613">removed the problematic ligature</a> and Inter was back in the race.</p>
<p>No further changes were required after this, and Inter, now as Adwaita Sans, was ready for GNOME 48.</p>
<h2>The Mono</h2>
<p><img alt="" class="aligncenter wp-image-35 size-large" height="320" src="https://blogs.gnome.org/monster/files/2025/03/Adwaita-Mono-1024x497.png" width="660"/></p>
<p>After the sans font was decided on as Inter, we wanted a matching monospace font. Our <a href="https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/265">initial font selection</a> consisted of popular monospace fonts and recommendations from Rasmus.</p>
<p>We also made a list of priorities, the new font would need:</p>
<ol>
<li>A style similar to Adwaita Sans</li>
<li>Active maintenance</li>
<li>Good legibility</li>
<li>Large language coverage</li>
</ol>
<p>Some fonts on our initial font selection fell off due to shortcomings in this list, and we were left with <a href="https://www.ibm.com/plex/">IBM Plex Mono</a>, <a href="https://commitmono.com/">Commit Mono</a> and <a href="https://typeof.net/Iosevka/">Iosevka</a>.</p>
<p>Just like for the sans font, we made a <a href="https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/267">call for testing</a> for these three fonts. The difference in monospace fonts can be quite hard to notice, so the non-visual benefits of the fonts were important.</p>
<p>The favorite among users was Commit Mono, due to its fairly close neutral design to Adwaita Sans. However, the font that we ended up with was Iosevka. This made some people upset, but this decision was made for a couple of reasons:</p>
<ol>
<li>Iosevka has more active maintenance</li>
<li>Iosevkaʼs configuration might have the best free tooling out there</li>
<li>When configured, Iosevka can look extremely similar to Adwaita Sans</li>
<li>The language coverage of Iosevka is considerably larger</li>
</ol>
<p>So, in the end, <a href="https://kramo.page">kramo</a> and me went through all its glyphs, configured them to look as close to Adwaita Sans as possible, and made that Adwaita Mono.</p>
<h2>Naming</h2>
<p>We wanted unique names for the fonts, because it will allow us to more easily switch them out in the future if necessary. Only the underlying repository will have to change, nothing else.</p>
<p>The configured Inter was originally named GNOME UI Font, but due to the introduction of the monospace font and our design system being called Adwaita, we moved the fonts under its umbrella as Adwaita Fonts.</p>
<h2>Technical Details</h2>
<p>We use <a href="https://twardoch.github.io/fonttools-opentype-feature-freezer/">OpenType Feature Freezer</a> to get the disambiguated lowercase L in Inter, as recommended by upstream.</p>
<p>Iosevka has their own configuration system which allows you to <a href="https://typeof.net/Iosevka/customizer">graphically customize</a> the font, and export a configuration file that can be used later down the line.</p>
<p>The repository which hosts the fonts originally started out with the goal to allow distributions to build the fonts themselves, which is why it used Makefiles with the help of <a href="https://xenia.blahaj.land/">Rose</a>.</p>
<p>Due to Iosevka requiring NPM packages to be configured, the scope was changed to shipping the TTF files themselves. Florian Müllner therefore ported the repository to shell scripts which allows us to update the files only, heavily simplifying the maintenance process.</p>
<p>The <a href="https://gitlab.gnome.org/GNOME/adwaita-fonts">repository</a> and fonts are licensed under the <a href="https://openfontlicense.org/">SIL Open Font License</a>.</p>
<h2>Conclusion</h2>
<p>We want to thank everyone that contributed to this font switch by testing, discussing, and coding!</p>
<p>Adwaita Fonts will be the default in GNOME 48, and we hope youʼre as happy with this change as we are.</p></div>
</content>
<updated>2025-03-16T23:27:53Z</updated>
<published>2025-03-16T23:27:53Z</published>
<category term="Design"/>
<author>
<name>Jamie</name>
</author>
<source>
<id>https://blogs.gnome.org/monster</id>
<logo>https://blogs.gnome.org/monster/files/2025/03/cropped-Icon-32x32.png</logo>
<link href="https://blogs.gnome.org/monster/feed/" rel="self" type="application/rss+xml"/>
<link href="https://blogs.gnome.org/monster" rel="alternate" type="text/html"/>
<subtitle>GNOME design and development with PyGObject</subtitle>
<title>Out of the Bag</title>
<updated>2025-03-19T13:16:44Z</updated>
</source>
</entry>
<entry>
<id>tag:blogger.com,1999:blog-3575421168816814786.post-7754608347831681948</id>
<link href="http://zee-nix.blogspot.com/feeds/7754608347831681948/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
<link href="http://www.blogger.com/comment/fullpage/post/3575421168816814786/7754608347831681948" rel="replies" title="0 Comments" type="text/html"/>
<link href="http://www.blogger.com/feeds/3575421168816814786/posts/default/7754608347831681948" rel="edit" type="application/atom+xml"/>
<link href="http://www.blogger.com/feeds/3575421168816814786/posts/default/7754608347831681948" rel="self" type="application/atom+xml"/>
<link href="http://zee-nix.blogspot.com/2025/03/making-stm32wl55-work-with-rust-i.html" rel="alternate" title="" type="text/html"/>
<title/>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><h1 id="makingstm32wl55workwithrust">Making STM32WL55 work with Rust</h1>
<p>I recently got my hands on a <a href="https://www.st.com/en/microcontrollers-microprocessors/stm32wl55.html">STM32WL55</a> development kit (NUCLEO-WL55JC2 to be more precise) and
wanted to program it in Rust. Since things did not work out of the box and I had to spend many
hours figuring out how to make it work, I thought I document the steps I took to make it work for
the next person who bumps into this:</p>
<h2 id="prerequisites">Pre-requisites</h2>
<ul>
<li><a href="https://www.st.com/en/development-tools/stm32cubeprog.html">STM32CubeProgrammer</a></li>
<li><a href="https://probe.rs/docs/getting-started/installation">probe-rs</a></li>
<li><a href="https://github.com/probe-rs/probe-rs/tree/master/target-gen">target-gen</a></li>
</ul>
<p><strong>Note:</strong> The <code>target-gen</code> docs instruct how to run it from the repository but it's not necessary
and you can install with <code>cargo install target-gen</code>.</p>
<h2 id="gettingstarted">Getting Started</h2>
<p>Powering up the board is super easy. Just connect the USB cable to the board and your computer. Now
if you're as eager as I was, you'll want to already want to try out <a href="https://github.com/lora-rs/lora-rs/tree/main/examples/stm32wl">the lora-rs examples</a> but if
you do that already, you'll get an error:</p>
<pre><code class="hljs bash language-bash">❯ cargo r --bin lora_p2p_receive
Finished `dev` profile [unoptimized + debuginfo] target(s) <span class="hljs-keyword">in</span> 0.07s
Running `probe-rs run --chip STM32WL55JC target/thumbv7em-none-eabi/debug/lora_p2p_receive`
WARN probe_rs::probe::stlink: send_jtag_command 242 failed: JtagGetIdcodeError
Error: Connecting to the chip was unsuccessful.
</code></pre>
<p>The first thing you'll want to do is to disable security (yeah, I know!). To do that, you'll need to
run this script:</p>
<pre><code class="hljs bash language-bash"><span class="hljs-function"><span class="hljs-title">write</span></span>(){
str=<span class="hljs-string">""</span>
<span class="hljs-keyword">for</span> arg <span class="hljs-keyword">do</span>
str+=<span class="hljs-string">" <span class="hljs-variable">${arg}</span>"</span>
<span class="hljs-keyword">done</span>
/home/user/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI -c port=SWD mode=UR -q -ob <span class="hljs-string">"<span class="hljs-variable">${str}</span>"</span>
}
<span class="hljs-built_in">echo</span> RDP: Read Out protection Level 1
write RDP=0xBB
<span class="hljs-built_in">echo</span> RDP+ESE: Read Out protection Level 0 + Security disabled
write RDP=0xAA ESE=0x0
<span class="hljs-built_in">echo</span> WRP: Write Protection disabled
write WRP1A_STRT=0x7F WRP1A_END=0x0 WRP1B_STRT=0x7F WRP1B_END=0x0
<span class="hljs-built_in">echo</span> ------ User Configuration ------
<span class="hljs-built_in">echo</span> nRST: No reset generated when entering the Stop/Standby/Shutdown modes
write nRST_STOP=0x1 nRST_STDBY=0x1 nRST_SHDW=0x1
<span class="hljs-built_in">echo</span> WDG_SW: Software window/independent watchdogs
write WWDG_SW=0x1 IWDG_SW=0x1
<span class="hljs-built_in">echo</span> IWDG: Independent watchdog counter frozen <span class="hljs-keyword">in</span> Stop/Standby modes
write IWGD_STDBY=0x0 IWDG_STOP=0x0
<span class="hljs-built_in">echo</span> BOOT: CPU1+CPU2 CM0+ Boot lock disabled
write BOOT_LOCK=0x0 C2BOOT_LOCK=0x0
<span class="hljs-built_in">echo</span> ------ Security Configuration ------
<span class="hljs-built_in">echo</span> HDPAD: User Flash hide protection area access disabled
write HDPAD=0x1
<span class="hljs-built_in">echo</span> SPISD: SPI3 security disabled
write SUBGHSPISD=0x1
<span class="hljs-built_in">echo</span> SBRSA: Reset default value of SRAM Start address secure
write SNBRSA=0x1F SBRSA=0x1F
<span class="hljs-built_in">echo</span> SBRV: Reset default value of CPU2 Boot start address
write SBRV=0x8000
</code></pre>
<h2 id="makingitallwork">Making it all work</h2>
<p>Now if you run the example again, you'll get a different error:</p>
<pre><code class="hljs bash language-bash">❯ cargo r --bin lora_p2p_receive
Finished `dev` profile [unoptimized + debuginfo] target(s) <span class="hljs-keyword">in</span> 0.07s
Running `probe-rs run --chip STM32WL55JC target/thumbv7em-none-eabi/debug/lora_p2p_receive`
Error: The flashing procedure failed <span class="hljs-keyword">for</span> <span class="hljs-string">'target/thumbv7em-none-eabi/debug/lora_p2p_receive'</span>.
Caused by:
Trying to write flash, but found more than one suitable flash loader algorithim marked as default <span class="hljs-keyword">for</span> NvmRegion { name: Some(<span class="hljs-string">"BANK_1"</span>), range: 134217728..134479872, cores: [<span class="hljs-string">"cm4"</span>, <span class="hljs-string">"cm0p"</span>], is_alias: <span class="hljs-literal">false</span>, access: Some(MemoryAccess { <span class="hljs-built_in">read</span>: <span class="hljs-literal">true</span>, write: <span class="hljs-literal">false</span>, execute: <span class="hljs-literal">true</span>, boot: <span class="hljs-literal">true</span> }) }.
</code></pre>
<p>That means you're almost there. You just need to tell probe-rs that all but one flash algorithm are
the default. I wish this was as easy as setting a CLI arg but unfortunately you need to a tiny bit
more:</p>
<pre><code class="hljs bash language-bash">❯ target-gen arm -f <span class="hljs-string">"STM32WLxx_DFP"</span>
2025-03-16T12:17:56.163918Z WARN target_gen::generate: Device STM32WL54CCUx, memory region SRAM1 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.163936Z WARN target_gen::generate: Device STM32WL54CCUx, memory region SRAM2 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.163938Z WARN target_gen::generate: Device STM32WL54CCUx, memory region FLASH has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164440Z WARN target_gen::generate: Device STM32WL54JCIx, memory region SRAM1 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164443Z WARN target_gen::generate: Device STM32WL54JCIx, memory region SRAM2 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164445Z WARN target_gen::generate: Device STM32WL54JCIx, memory region FLASH has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164948Z WARN target_gen::generate: Device STM32WL55CCUx, memory region SRAM1 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164954Z WARN target_gen::generate: Device STM32WL55CCUx, memory region SRAM2 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.164956Z WARN target_gen::generate: Device STM32WL55CCUx, memory region FLASH has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165458Z WARN target_gen::generate: Device STM32WL55JCIx, memory region SRAM1 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165463Z WARN target_gen::generate: Device STM32WL55JCIx, memory region SRAM2 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.165465Z WARN target_gen::generate: Device STM32WL55JCIx, memory region FLASH has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166001Z WARN target_gen::generate: Device STM32WL5MOCHx, memory region SRAM1 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166005Z WARN target_gen::generate: Device STM32WL5MOCHx, memory region SRAM2 has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
2025-03-16T12:17:56.166007Z WARN target_gen::generate: Device STM32WL5MOCHx, memory region FLASH has no processor name, but this is required <span class="hljs-keyword">for</span> a multicore device. Assigning memory to all cores!
Generated 1 target definition(s):
/home/user/lora-rs/STM32WL_Series.yaml
Finished <span class="hljs-keyword">in</span> 3.191890047s
</code></pre>
<p>Now edit this file and change all <code>default: true</code> lines under <code>flash_algorithms</code> to
<code>default: false</code>, except for the one under <code>stm32wlxx_cm4</code> (the core we want to use). Then edit the
<code>.cargo/config.toml</code> file as well and change the <code>probe-rs</code> commandline in it, to make use of this
chip description file by adding <code>--chip-description-path STM32WL_Series.yaml</code> to it.</p>
<p>At this point everything should work and you should be able to flash and run the lora-rs examples:</p>
<pre><code class="hljs bash language-bash">❯ cargo r --bin lora_p2p_receive
Finished `dev` profile [unoptimized + debuginfo] target(s) <span class="hljs-keyword">in</span> 0.04s
Running `probe-rs run --chip STM32WLE5JCIx --chip-description-path STM32WL_Series.yaml target/thumbv7em-none-eabi/debug/lora_p2p_receive`
Erasing ✔ 100% [####################] 140.00 KiB @ 61.45 KiB/s (took 2s)
Programming ✔ 100% [####################] 139.00 KiB @ 41.50 KiB/s (took 3s) Finished <span class="hljs-keyword">in</span> 5.63s
0.000000 TRACE BDCR ok: 00008200
└─ embassy_stm32::rcc::bd::{impl#3}::init @ /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/embassy-stm32-0.2.0/src/rcc/bd.rs:216
0.000000 DEBUG rcc: Clocks { hclk1: MaybeHertz(48000000), hclk3: MaybeHertz(48000000), hsi: MaybeHertz(0), lse: MaybeHertz(0), lsi: MaybeHertz(32000), msi: MaybeHertz(4000000), pclk1: MaybeHertz(48000000), pclk1_tim: MaybeHertz(48000000), pclk2: MaybeHertz(48000000), pclk2_tim: MaybeHertz(48000000), pclk3: MaybeHertz(48000000), pll1_p: MaybeHertz(0), pll1_q: MaybeHertz(48000000), rtc: MaybeHertz(32000), sys: MaybeHertz(48000000) }
...
</code></pre></div>
</content>
<updated>2025-03-16T16:43:00Z</updated>
<published>2025-03-16T16:43:00Z</published>
<category scheme="http://www.blogger.com/atom/ns#" term="baremetal"/>
<category scheme="http://www.blogger.com/atom/ns#" term="embedded"/>
<category scheme="http://www.blogger.com/atom/ns#" term="LoRa"/>
<category scheme="http://www.blogger.com/atom/ns#" term="microcontroller"/>
<category scheme="http://www.blogger.com/atom/ns#" term="probe-rs"/>
<category scheme="http://www.blogger.com/atom/ns#" term="Rust"/>
<category scheme="http://www.blogger.com/atom/ns#" term="STM32"/>
<category scheme="http://www.blogger.com/atom/ns#" term="STM32WL"/>
<author>
<name>zeenix</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/04142631863736897222</uri>
</author>
<source>
<id>tag:blogger.com,1999:blog-3575421168816814786</id>
<category term="GNOME"/>
<category term="UPnP"/>
<category term="GUPnP"/>
<category term="Maemo"/>
<category term="release"/>
<category term="DLNA"/>
<category term="Rygel"/>
<category term="MediaServer"/>
<category term="Vala"/>
<category term="Geoclue"/>
<category term="virtual machine"/>
<category term="virtualization"/>
<category term="Boxes"/>
<category term="FOSDEM"/>
<category term="Rust"/>
<category term="Fedora"/>
<category term="Finland"/>
<category term="geolocation"/>
<category term="GObject"/>
<category term="GSSDP"/>
<category term="GUADEC"/>
<category term="Spice"/>
<category term="C"/>
<category term="D-Bus"/>
<category term="GSoC"/>
<category term="GStreamer"/>
<category term="Helsinki"/>
<category term="London"/>
<category term="Maps"/>
<category term="Meego"/>
<category term="Mozilla"/>
<category term="hackfest"/>
<category term="libosinfo"/>
<category term="libvirt"/>
<category term="python"/>
<category term="tracker"/>
<category term="A/V"/>
<category term="Berlin"/>
<category term="Guile"/>
<category term="KDE"/>
<category term="Linux"/>
<category term="Red Hat"/>
<category term="Ubuntu"/>
<category term="Vacation"/>
<category term="wifi-geolocation"/>
<category term="Conference"/>
<category term="GPS"/>
<category term="Git"/>
<category term="Gothenburg"/>
<category term="ModemManager"/>
<category term="Party"/>
<category term="Pelagicore"/>
<category term="SSDP"/>
<category term="Transcoding"/>
<category term="gource"/>
<category term="libsoup"/>
<category term="libvirt-glib"/>
<category term="location"/>
<category term="visualization"/>
<category term="windows"/>
<category term="3.2"/>
<category term="AV"/>
<category term="Ansku"/>
<category term="Automotive"/>
<category term="C++"/>
<category term="Cancer"/>
<category term="Clutter"/>
<category term="DVB"/>
<category term="DVB Daemon"/>
<category term="Forest"/>
<category term="Free Software"/>
<category term="Google"/>
<category term="Gtk"/>
<category term="Gtk+"/>
<category term="JavaScript"/>
<category term="Job"/>
<category term="Jolla"/>
<category term="Karl-Lattimer"/>
<category term="Kinvolk"/>
<category term="Lassi"/>
<category term="Lennart"/>
<category term="Logo"/>
<category term="MediaRenderer"/>
<category term="Mom"/>
<category term="Moonlight"/>
<category term="Nokia"/>
<category term="OVF"/>
<category term="OpenedHand"/>
<category term="PS3"/>
<category term="Qemu"/>
<category term="Qt"/>
<category term="Scheme"/>
<category term="Security"/>
<category term="Star trek"/>
<category term="Summer"/>
<category term="Sweden"/>
<category term="Tools"/>
<category term="UK"/>
<category term="VNC"/>
<category term="Xbox"/>
<category term="Xchat"/>
<category term="binding"/>
<category term="debian"/>
<category term="express installation"/>
<category term="geocode-glib"/>
<category term="geoip"/>
<category term="helicopters"/>
<category term="history"/>
<category term="kaisla"/>
<category term="life"/>
<category term="performance"/>
<category term="tablet"/>
<category term="virt-tools"/>
<category term="xml"/>
<category term="0.10"/>
<category term="3.12"/>
<category term="3.8"/>
<category term="A Coruña."/>
<category term="A-GPS"/>
<category term="API"/>
<category term="ATM"/>
<category term="Aero-car"/>
<category term="Android"/>
<category term="Arc"/>
<category term="Automobile"/>
<category term="C#"/>
<category term="CV"/>
<category term="Cambridge"/>
<category term="Camera"/>
<category term="Canada"/>
<category term="Cellink"/>
<category term="Chalmers University"/>
<category term="Closures"/>
<category term="Coherence"/>
<category term="Collabora"/>
<category term="Comic"/>
<category term="DIDL-Lite"/>
<category term="Desktop Summit"/>
<category term="Developer experience"/>
<category term="Embedded Systems"/>
<category term="EuroKaution"/>
<category term="Finnish"/>
<category term="Firefox"/>
<category term="Firefox OS"/>
<category term="Flatpak"/>
<category term="Friends"/>
<category term="GDP"/>
<category term="GIO"/>
<category term="GIR"/>
<category term="GJS"/>
<category term="GNOME Foundation"/>
<category term="GNOME OS"/>
<category term="GNOME Shell"/>
<category term="GOPW"/>
<category term="GPSD"/>
<category term="GSlice"/>
<category term="GUADEC 2012"/>
<category term="Garbage collection"/>
<category term="Geek"/>
<category term="Genivi"/>
<category term="Germany"/>
<category term="Go"/>
<category term="Humor"/>
<category term="Huopalahti"/>
<category term="IGD"/>
<category term="IRC"/>
<category term="Istanbul"/>
<category term="Java"/>
<category term="Jeff Waugh"/>
<category term="Jussi Kukkonen"/>
<category term="KVM"/>
<category term="Karachi"/>
<category term="LEGO"/>
<category term="Lisp"/>
<category term="LoRa"/>
<category term="MAFW"/>
<category term="MLS"/>
<category term="MMORPG"/>
<category term="Maintainer"/>
<category term="Mango"/>
<category term="Mark Shuttleworth"/>
<category term="Marriage"/>
<category term="Memory Management"/>
<category term="Meritähti"/>
<category term="Mexico"/>
<category term="Microsoft"/>
<category term="Mindstorm"/>
<category term="Modem"/>
<category term="Mono"/>
<category term="Move"/>
<category term="Murray Cumming"/>
<category term="Mutex"/>
<category term="N81"/>
<category term="N900"/>
<category term="NMEA"/>
<category term="Network"/>
<category term="Network Light"/>
<category term="Nominatim"/>
<category term="OGG"/>
<category term="OHMan"/>
<category term="OPW"/>
<category term="Open Source"/>
<category term="OpenStreetMap"/>
<category term="OpenWLANMap"/>
<category term="PPL(H)"/>
<category term="Pyhon"/>
<category term="Quality"/>
<category term="Rant"/>
<category term="Rc"/>
<category term="Reference counting"/>
<category term="Remote Access"/>
<category term="SQLite"/>
<category term="STM32"/>
<category term="STM32WL"/>
<category term="Sampo"/>
<category term="Sauna"/>
<category term="Scripting"/>
<category term="Skiing"/>
<category term="South Park"/>
<category term="Strasbourg"/>
<category term="Swedish"/>
<category term="Thessaloniki"/>
<category term="USB"/>
<category term="Ubuntu phone"/>
<category term="VCS"/>
<category term="Valgrind"/>
<category term="Vodafone"/>
<category term="Windows 7"/>
<category term="Windows XP"/>
<category term="WoW"/>
<category term="Z-LASIK"/>
<category term="Zaheer"/>
<category term="Zeeshan"/>
<category term="ZeroConf"/>
<category term="Zhaan"/>
<category term="agent"/>
<category term="async"/>
<category term="automated installation"/>
<category term="bank"/>
<category term="baremetal"/>
<category term="bazaar"/>
<category term="blog move"/>
<category term="bluetooth"/>
<category term="c't"/>
<category term="canon"/>
<category term="cats"/>
<category term="data"/>
<category term="depression"/>
<category term="device"/>
<category term="distro"/>
<category term="driving"/>
<category term="driving test"/>
<category term="embedded"/>
<category term="encryption"/>
<category term="evolution"/>
<category term="exopc"/>
<category term="filesystem"/>
<category term="flying"/>
<category term="foundation"/>
<category term="framework"/>
<category term="geocoding"/>
<category term="gmail"/>
<category term="gnome-continuous"/>
<category term="gnome-system-monitor"/>
<category term="gnome-user-share"/>
<category term="gps-share"/>
<category term="gypsy"/>
<category term="hardware"/>
<category term="hostel"/>
<category term="hotel"/>
<category term="introspection"/>
<category term="irssi"/>
<category term="italy"/>
<category term="lifetimes"/>
<category term="love"/>
<category term="malloc"/>
<category term="meme"/>
<category term="microcontroller"/>
<category term="mollymalones"/>
<category term="mother"/>
<category term="moving in"/>
<category term="mpeg"/>
<category term="multimedia"/>
<category term="oFono"/>
<category term="operating system"/>
<category term="optimization"/>
<category term="ostikka"/>
<category term="pets"/>
<category term="pilot"/>
<category term="poo"/>
<category term="portability"/>
<category term="printer"/>
<category term="probe-rs"/>
<category term="pulse-audio"/>
<category term="pygtk"/>
<category term="religion"/>
<category term="rover"/>
<category term="science"/>
<category term="screenshots"/>
<category term="segfault"/>
<category term="sh"/>
<category term="skills test"/>
<category term="snapshot"/>
<category term="sound server"/>
<category term="talk"/>
<category term="theory"/>
<category term="threads"/>
<category term="thumbnails"/>
<category term="video"/>
<category term="virt-manager"/>
<category term="vorbis"/>
<category term="wedding"/>
<category term="wifi"/>
<category term="win32"/>
<category term="winter"/>
<category term="zbus"/>
<author>
<name>zeenix</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/04142631863736897222</uri>
</author>
<link href="http://zee-nix.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
<link href="http://www.blogger.com/feeds/3575421168816814786/posts/default" rel="self" type="application/atom+xml"/>
<link href="http://zee-nix.blogspot.com/" rel="alternate" type="text/html"/>
<link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
<link href="http://www.blogger.com/feeds/3575421168816814786/posts/default?start-index=26&max-results=25" rel="next" type="application/atom+xml"/>
<subtitle>Views and journeys of a hopeless programmer, named Zeeshan Ali Khan.</subtitle>
<title>Coder's Log</title>
<updated>2025-03-17T12:09:47Z</updated>
</source>
</entry>
<entry xml:lang="en">
<id>https://nyaa.place/blog/libadwaita-1-7</id>
<link href="https://nyaa.place/blog/libadwaita-1-7" rel="alternate" type="text/html"/>
<title>Libadwaita 1.7</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><source media="(prefers-color-scheme: dark)"/>
<img alt="Screenshot of apps using libadwaita 1.7: Elastic with an inline view switcher and adaptive preview, Settings with a banner with the new style in the printers panel, and Warp with about dialog linking to other apps" src="https://nyaa.place/blog/libadwaita-1-7/header.png"/>
<p>New cycle, new libadwaita version. Let's look at the changes.</p>
<h1 id="toggle-groups">Toggle groups</h1>
<p>Last time I mentioned that <strong>Maximiliano</strong>'s toggle groups were ready by the end of the last cycle but it was too late to get them into 1.6.</p>
<source media="(prefers-color-scheme: dark)"/>
<img alt="Screenshot of toggle groups in libadwaita demo" src="https://nyaa.place/blog/libadwaita-1-7/toggle-groups.png"/>
<p><a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.ToggleGroup.html"><code>AdwToggleGroup</code></a> a replacement for the specific pattern of using multiple exclusive instances of <a href="https://docs.gtk.org/gtk4/class.ToggleButton.html"><code>GtkToggleButton</code></a> in a box. Compared to a box it provides a clearer styling and simpler to use API. Toggles can be accessed either by their index, or optionally by their name. It can also be vertical, though I don't expect that to be frequently used.</p>
<p>If the switch-like style doesn't work in a given context, they can also be made flat, then they look the same way as a group of flat buttons.</p>
<h2 id="inline-view-switcher">Inline view switcher</h2>
<source media="(prefers-color-scheme: dark)"/>
<img alt="Screenshot of 3 inline view switchers, each with 3 pages, and an unread badge on one of them. One of the switchers is icon-only, another is label-only, the third one displays both" src="https://nyaa.place/blog/libadwaita-1-7/inline-view-switcher.png"/>
<p>While the app-wide switcher use case had been well covered by
<a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.ViewSwitcher.html"><code>AdwViewSwitcher</code></a> for years, we didn't have anything for inline use cases like putting a switcher into a card, into a sidebar or into the middle of a boxed list page. Most apps used <code>GtkStackSwitcher</code> there, some instead implemented a custom switcher with the same kind of visuals as toggle groups (the design has existed for a while).</p>
<p>So, there's now also a view switcher version using a toggle group internally - <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.InlineViewSwitcher.html"><code>AdwInlineViewSwitcher</code></a>.</p>
<h2 id="stack-improvements">Stack improvements</h2>
<p>Like <code>AdwViewSwitcher</code>, <code>AdwInlineViewSwitcher</code> works with <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.ViewStack.html"><code>AdwViewStack</code></a> rather than <a href="https://docs.gtk.org/gtk4/class.Stack.html"><code>GtkStack</code></a>, which may present a problem as in these contexts it often makes sense to animate transitions. So, <code>AdwViewStack</code> supports crossfade transitions now.</p>
<p>They work a bit differently than in <code>GtkStack</code> - it always interpolates size, it doesn't clip the contents so can be used to e.g. transition between two cards without clipping their shadows (<code>GtkStack</code> does clip it as it also supports slide transitions where it makes sense), and it uses different easing. It also moves children differently depending on their <a href="https://docs.gtk.org/gtk4/property.Widget.halign.html"><code>:halign</code></a> and <a href="https://docs.gtk.org/gtk4/property.Widget.valign.html"><code>:valign</code></a> values.</p>
<h1 id="wrap-box">Wrap box</h1>
<p>Another widget that's been started a long time ago and never finished until this cycle is <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.WrapBox.html"><code>AdwWrapBox</code></a>. It behaves like a <a href="https://docs.gtk.org/gtk4/class.Box.html"><code>GtkBox</code></a> but can wrap children onto additional lines. Unlike <a href="https://docs.gtk.org/gtk4/class.FlowBox.html"><code>GtkFlowBox</code></a>, it doesn't place children in a grid, however, treating them more like words in a paragraph.</p>
<p>This can be used in situations like displaying a list of tags.</p>
<source media="(prefers-color-scheme: dark)"/>
<img alt="Wrap box in the libadwaita demo, showing tags for Lorem, ipsum etc, each in a pill and with a remove button. After the tags, there's a plus button that adds a new tag on click. The tags are wrapped into 3 lines" src="https://nyaa.place/blog/libadwaita-1-7/wrap-box.png"/>
<p>Wrap box can be tweaked in a number of ways, e.g. starting each line from the right rather than from the left (or vice versa for RTL locales), justifying each line (either via stretching children or adding spacing between them), wrapping upwards instead of downwards and so on.</p>
<h1 id="adaptive-preview">Adaptive preview</h1>
<source media="(prefers-color-scheme: dark)"/>
<img alt="Screenshot of adaptive preview in Clocks, showing the new alarm dialog with generic phone + mobile shell presets and with window controls hidden" src="https://nyaa.place/blog/libadwaita-1-7/adaptive-preview.png"/>
<p>I already mentioned it in a previous <a href="https://nyaa.place/blog/libadwaita-1-7/../mobile-testing-in-libadwaita">blog post</a>, but libadwaita now has adaptive preview mode, inspired by responsive design modes in various web browsers. To reiterate, it allows to preview a given app on different devices - mostly mobile phones - without the need to resize the window in precise ways to check if the app works or not at a given size.</p>
<p>Since the original blog post, it gained a few new features - such as scaling when the content doesn't fit, displaying device bezels, and taking screenshots with that bezel intact:</p>
<source media="(prefers-color-scheme: dark)"/>
<img alt="The same Clocks screen with generic phone bezels, but without adaptive preview around it" src="https://nyaa.place/blog/libadwaita-1-7/phone-screenshot.png"/>
<p>The UI in the inspector has been revamped, and there's now a separate shortcut for opening the preview: <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>M</kbd>.</p>
<source media="(prefers-color-scheme: dark)"/>
<img alt="Screenshot of inspector showing the new adaptive preview UI" src="https://nyaa.place/blog/libadwaita-1-7/inspector-preview.png"/>
<h1 id="sizing-changes">Sizing Changes</h1>
<p>This cycle, <a href="https://floss.social/@bugaevc"><strong>Sergey Bugaev</strong></a> did a lot of sizing fixes throughout both GTK and libadwaita, aimed at improving consistency in width-for-height and height-for-width scenarios. Most of the time this shouldn't affect existing apps, but one notable change is in how <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Clamp.html"><code>AdwClamp</code></a> reports its natural width (or height for vertical clamps): when containing a small child, previously it could stretch it past its natural size, even though it's meant to reduce the child size rather than increase it.</p>
<p>Some apps relied on the previous (buggy) sizing behavior, and may need to be adjusted now that it's fixed.</p>
<h2 id="font-additions">Font additions</h2>
<p>GNOME 48 has new fonts - Adwaita Sans and Adwaita Mono, replacing Cantarell and Source Code Pro. The change to Adwaita Sans is highly visible as almost every bit of text in the UI uses it. The monospace font, however, is a lot less visible. Let's look at why.</p>
<p>For a long time, GNOME has had the <code>monospace-font-name</code> preference, which wasn't actually used all that much. It's not exposed anywhere in <a href="https://docs.gtk.org/gtk4/class.Settings.html"><code>GtkSettings</code></a>, it's not used for the <code>monospace</code> style class in CSS (instead, the <code>Monospace</code> font is used), and so on.</p>
<p>To use it, apps need to listen to its changes manually and adapt their UI accordingly. When running in Flatpak, they also can't use <a href="https://docs.gtk.org/gio/class.Settings.html"><code>GSettings</code></a> for this and have to access the settings portal, manually or via <a href="https://libportal.org/">libportal</a>.</p>
<p>Only a small handful of apps went to those lengths - basically just terminals and text editors.</p>
<p>Similarly, there's also a <code>document-font-name</code> preference, intended to be used for the app content, e.g. articles (as opposed to UI). Similarly, it's really hard to use and has been mostly ignored.</p>
<p>So, libadwaita now handles both of them. <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.StyleManager.html"><code>AdwStyleManager</code></a> has gained properties for retrieving them: <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.StyleManager.monospace-font-name.html"><code>:monospace-font-name</code></a> and <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.StyleManager.document-font-name.html"><code>:document-font-name</code></a>.</p>
<p>They are also <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/css-variables.html#fonts">exposed</a> in CSS, as the <code>--monospace-font-family</code>, <code>--monospace-font-size</code>, <code>--document-font-family</code> and <code>--document-font-size</code> variables. In addition to that, the <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/style-classes.html#typography-styles"><code>.monospace</code></a> style class uses them automatically.</p>
<figure>
<source media="(prefers-color-scheme: dark)"/>
<img alt="Screenshot of inspector CSS page using the new font" src="https://nyaa.place/blog/libadwaita-1-7/inspector-css.png"/>
<figcaption>CSS editor in GTK Inspector is using <code>.monospace</code> and gets the new font automatically</figcaption>
</figure>
<p>The document font meanwhile isn't used anywhere in standard widgets or styles yet, but it may change in the future, e.g. to increase the text size there.</p>
<h1 id="miscellaneous-style-changes">Miscellaneous style changes</h1>
<p>A few smaller style changes happened this cycle.</p>
<h2 id="banners">Banners</h2>
<source media="(prefers-color-scheme: dark)"/>
<img alt="Screenshot of 2 banners: on in Settings with a suggested button, and one in Files with a regular button" src="https://nyaa.place/blog/libadwaita-1-7/banners.png"/>
<p>Instead of using accent color for the entire widget, banners are now neutral, while the button can optionally use suggested style, controlled using the <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.Banner.button-style.html"><code>:button-style</code></a> property.</p>
<p>Thanks to <strong>Jamie Murphy</strong> for this change.</p>
<h2 id="toasts">Toasts</h2>
<p>Toasts are now lighter and opaque. This helps them stand out and remain legible against dark backgrounds or on top of noisy content.</p>
<p><img alt="Screenshot of a toast saying "2 items deleted", with an und button" src="https://nyaa.place/blog/libadwaita-1-7/toast.png"/></p>
<h2 id="colors">Colors</h2>
<p>The UI colors throughout libadwaita styles are now very slightly tinted towards blue instead of using neutral grey color. In most cases it will just work, but apps that hardcode matching colors may need an update.</p>
<p>Tab overview is now using a darker background for light style and lighter background for dark style, to improve contrast with thumbnails.</p>
<h2 id="rounding">Rounding</h2>
<p>Widgets like buttons are now slightly more rounded. Apps may need to adjust border-radius on custom widgets to match in rare cases.</p>
<h1 id="other-changes">Other changes</h1>
<ul>
<li>
<p>Thanks to an <a href="https://docs.gtk.org/gtk4/property.Widget.limit-events.html">addition</a> in GTK, <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Dialog.html"><code>AdwDialog</code></a> now blocks app-wide and window-wide shortcuts, same as modal windows did.</p>
</li>
<li>
<p><strong>Emmanuele</strong> added easing functions based on cubic Bézier curves to <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/enum.Easing.html"><code>AdwEasing</code></a>: <code>ADW_EASE</code>, <code>ADW_EASE_IN</code>, <code>ADW_EASE_OUT</code> and <code>ADW_EASE_IN_OUT</code>.</p>
</li>
<li>
<p><a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.PreferencesPage.html"><code>AdwPreferencesPage</code></a> can now <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.PreferencesPage.banner.html">display</a> a banner at the top, which allows to use banners in <code>AdwPreferencesDialog</code>.</p>
</li>
<li>
<p><a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.AboutDialog.html"><code>AdwAboutDialog</code></a> can now <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/method.AboutDialog.add_other_app.html">link</a> to other apps to showcase them.</p>
<source media="(prefers-color-scheme: dark)"/>
<img alt="Warp's about dialog links to Pika Backup" src="https://nyaa.place/blog/libadwaita-1-7/other-apps.png"/>
</li>
<li>
<p><a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.BottomSheet.html"><code>AdwBottomSheet</code></a> now has a way to <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.BottomSheet.reveal-bottom-bar.html">hide</a> its bottom bar. This can be useful e.g. for music players that use the bottom bar to display the currently playing track, and want to hide it when nothing is playing.</p>
</li>
<li>
<p><strong>Peter Eisenmann</strong> added a convenience <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.NavigationView.visible-page-tag.html">property</a> for retrieving the visible page's tag in <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.NavigationView.html"><code>AdwNavigationView</code></a>.</p>
</li>
<li>
<p>Additionally, <code>AdwNavigationView</code> can now make its pages either <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.NavigationView.hhomogeneous.html">horizontally</a> or <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.NavigationView.vhomogeneous.html">vertically</a> homogeneous, meaning it will be as wide/tall as the largest page in its navigation stack rather than potentially resizing when switching pages.</p>
</li>
<li>
<p><a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.NavigationSplitView.html"><code>AdwNavigationSplitView</code></a> now <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/property.NavigationSplitView.sidebar-position.html">allows</a> to put its sidebar after the content instead of before, same as <code>AdwOverlaySplitView</code>. In this case, the content is treated as the root page and the sidebar as subpage when collapsed, instead of the other way around.</p>
</li>
<li>
<p><a href="https://floss.social/@FineFindus"><strong>FineFindus</strong></a> added <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/method.ToastOverlay.dismiss_all.html">a way</a> to dismiss all toasts at once in an <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.ToastOverlay.html"><code>AdwToastOverlay</code></a>.</p>
</li>
<li>
<p><a href="https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.PreferencesDialog.html"><code>AdwPreferencesDialog</code></a> now hides the pages from the view switcher and search when their <a href="https://docs.gtk.org/gtk4/property.Widget.visible.html"><code>:visible</code></a> property is set to <code>FALSE</code>.</p>
</li>
<li>
<p>The <code>.dim-label</code> style class has been renamed to <code>.dimmed</code> to better reflect what it does (since it was never exclusive to labels). The old name is still available but deprecated.</p>
</li>
</ul>
<hr/>
<p>Large parts of this work were made possible by <a href="https://www.sovereigntechfund.de/tech/gnome"><strong>STF</strong></a> funding. Additionally, thanks to all of the contributors who made this release possible.</p></div>
</summary>
<updated>2025-03-15T00:00:00Z</updated>
<published>2025-03-15T00:00:00Z</published>
<author>
<name>Alice Mikhaylenko</name>
</author>
<source>
<id>https://nyaa.place/blog/</id>
<link href="https://nyaa.place/blog/" rel="alternate" type="text/html"/>
<link href="https://nyaa.place/blog.xml" rel="self" type="application/rss+xml"/>
<subtitle>Recent articles on Alice's blog</subtitle>
<title>Alice's Blog</title>
<updated>2025-03-15T00:00:00Z</updated>
</source>
</entry>
<entry>
<id>tag:blogger.com,1999:blog-5620128670216603593.post-191963193119445016</id>
<link href="https://ml4711.blogspot.com/feeds/191963193119445016/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
<link href="https://ml4711.blogspot.com/2025/03/maps-and-gnome-48.html#comment-form" rel="replies" title="0 Comments" type="text/html"/>
<link href="https://www.blogger.com/feeds/5620128670216603593/posts/default/191963193119445016" rel="edit" type="application/atom+xml"/>
<link href="https://www.blogger.com/feeds/5620128670216603593/posts/default/191963193119445016" rel="self" type="application/atom+xml"/>
<link href="https://ml4711.blogspot.com/2025/03/maps-and-gnome-48.html" rel="alternate" title="Maps and GNOME 48" type="text/html"/>
<title>Maps and GNOME 48</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p/><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgG20lc-eorgbWzghqqd_SAmBOcT8COAT5tJrg9zFSIES7p-gHQizbKZG6hQ_u4LLnsJXvKwDNbBdB2AdOsyQEdGLrEYF-KiKRIL7EP2fKh2YFBJoX_mNfUSVEZSJqmT6W8R_Li_He7OyQXw_2dxq9-71pueTt_2fR68F6JOs49pUPTrqgFXwcLKopg/s734/about-48.rc.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgG20lc-eorgbWzghqqd_SAmBOcT8COAT5tJrg9zFSIES7p-gHQizbKZG6hQ_u4LLnsJXvKwDNbBdB2AdOsyQEdGLrEYF-KiKRIL7EP2fKh2YFBJoX_mNfUSVEZSJqmT6W8R_Li_He7OyQXw_2dxq9-71pueTt_2fR68F6JOs49pUPTrqgFXwcLKopg/s16000/about-48.rc.png"/></a></div><br/> <p/><p> </p><p>In a few days it's time for the GNOME 48 release.</p><p>So it's time to make a wrap-up with the last changes in Maps for the next release.</p><h2 style="text-align: left;"> Redesigned Route Markers</h2><div style="text-align: left;">One issue that has been addressed was that the old markers we used to mark the start and end locations for routes, being filled and hollow circle icons respectively could be hard to tell apart and actually see which is which.</div><div style="text-align: left;"> </div><div style="text-align: left;">So now to mark the start we show a marker containing the icon representing the mode of transportation.</div><div style="text-align: left;"> </div><div style="text-align: left;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT2gnweGZqMlfQGl37Dvzw7qIYZ-3HAiqiVOWbsIJAsBvpzVK0FI0MFXDNRsxizEhGVsp0geCOIawBTvNVQ1hqSbotaUvPaeDey2-_TMUwR6Te8i7gBBZiH2ijDuocYe2zAZ605q10ZKJI2vJ2xNNZ5_tu5GV6xw0X3EMw3j5y198877S9kJnY6PiU/s1572/redesign-route-marker-walk.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="362" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhT2gnweGZqMlfQGl37Dvzw7qIYZ-3HAiqiVOWbsIJAsBvpzVK0FI0MFXDNRsxizEhGVsp0geCOIawBTvNVQ1hqSbotaUvPaeDey2-_TMUwR6Te8i7gBBZiH2ijDuocYe2zAZ605q10ZKJI2vJ2xNNZ5_tu5GV6xw0X3EMw3j5y198877S9kJnY6PiU/w640-h362/redesign-route-marker-walk.png" width="640"/></a></div><br/><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCLmVYEtHYgMEkQxG5p-njhkK9C4Ud9MmCTn9KWT_uwqmw4fL55PzNzQtyTHZv0h-bBsP3oNuHxkM_bzfmtK8rol_tjcaaeLqb8heMv67Bqp_vO1-uEsza2VP0dUdqnTAVZnvIrYLL8nBkBBVsx7AEIuXtQ4FZTNeol5IR2PH03iz0iuAW_Kte45id/s1572/redesign-route-marker-bike.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="362" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCLmVYEtHYgMEkQxG5p-njhkK9C4Ud9MmCTn9KWT_uwqmw4fL55PzNzQtyTHZv0h-bBsP3oNuHxkM_bzfmtK8rol_tjcaaeLqb8heMv67Bqp_vO1-uEsza2VP0dUdqnTAVZnvIrYLL8nBkBBVsx7AEIuXtQ4FZTNeol5IR2PH03iz0iuAW_Kte45id/w640-h362/redesign-route-marker-bike.png" width="640"/></a></div><br/><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizHLJmaBw49hSe2mPg0qD5qsu9r8O_hM2eWyFh2CKO3hTifEoUTfc_M2-PJjNL_OFlGMNNhaixn4pS7e5YN9TtiRYYz5tsSawnrTSgwS0SWSqQbV7hSyyFAooqJrVGm0JD42mBpTzyGY1ec4_axkXTZcsGCxQWi0qd8eYAhAVe0-zIdxIBsrRqrPwp/s1572/redesign-route-marker-car.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="362" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizHLJmaBw49hSe2mPg0qD5qsu9r8O_hM2eWyFh2CKO3hTifEoUTfc_M2-PJjNL_OFlGMNNhaixn4pS7e5YN9TtiRYYz5tsSawnrTSgwS0SWSqQbV7hSyyFAooqJrVGm0JD42mBpTzyGY1ec4_axkXTZcsGCxQWi0qd8eYAhAVe0-zIdxIBsrRqrPwp/w640-h362/redesign-route-marker-car.png" width="640"/></a></div><br/> The “walk” icon is also used for start of “walking legs” in public transit iteneraries, so this way it's getting a more consistent look.</div><div style="text-align: left;"> </div><div style="text-align: left;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIrVU-VETqoP6_4pFqMXcnxy2M7lQLOwfZzm4O_0IvPeWJEkelTqWBoi6rCwmLgacqiW4p1n7mrAIf9qgOJsW6zlTv1UmN6rgHXkkOefPVCySC8T4VcOA_6oztp3_-sksskSfVXFQBrPVVjcFgC8LSy6ldF_p8lQfjvl9yk0ZZb2yzIismtTo-7Hk8/s1749/redesign-route-marker-transit.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="314" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIrVU-VETqoP6_4pFqMXcnxy2M7lQLOwfZzm4O_0IvPeWJEkelTqWBoi6rCwmLgacqiW4p1n7mrAIf9qgOJsW6zlTv1UmN6rgHXkkOefPVCySC8T4VcOA_6oztp3_-sksskSfVXFQBrPVVjcFgC8LSy6ldF_p8lQfjvl9yk0ZZb2yzIismtTo-7Hk8/w640-h314/redesign-route-marker-transit.png" width="640"/></a></div><br/><h2 style="text-align: left;"> Redesigned User Location Marker</h2><div style="text-align: left;">This was already covered in an earlier blog post, but it might be worth mentioning especially now that we once again have WiFi- and Celltower-based positioning again thanks to BeaconDB (it's already enabled by default in Fedora 41, and I think some other distros as well). We now have the redesigned location marker, using the system accent color.</div><div style="text-align: left;"> </div><div style="text-align: left;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXGF87iFPrWy2RliIap_ilwQ90tmceZswcPumdjrF2Be30qCNUyt-fIIqgPYBYiKNnDpW_kpO_aukKW1jvks6neLKlOgGD9VatT2313Vfiu008-MaYFr22RtMX1YXO87BVwiTIhJVPgzkzqQb4irHz-Hr5IPKspRn8JpYfqdiPsy6pqidONzLdnV4Y/s1359/redesigned-location-marker-blue.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="422" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXGF87iFPrWy2RliIap_ilwQ90tmceZswcPumdjrF2Be30qCNUyt-fIIqgPYBYiKNnDpW_kpO_aukKW1jvks6neLKlOgGD9VatT2313Vfiu008-MaYFr22RtMX1YXO87BVwiTIhJVPgzkzqQb4irHz-Hr5IPKspRn8JpYfqdiPsy6pqidONzLdnV4Y/w640-h422/redesigned-location-marker-blue.png" width="640"/></a></div><br/><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMnOK3SvkPSj9MtSQOdS5ReGwKEh0eTs9nKWJqDLQ-3vnGYcil2d6_y_5ishwAy4tjZnZQw5I2IPpnQbwkhspuCwLk7uY7sm6QtMmt_9e7IUKPbo2S87R6JZhs28UQeDy_ZJmJKsB6cIkLXRP-udesddntOguzZ771xd2_wG0wsFBHuvW9-6IML51m/s1359/redesigned-location-marker-pink.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="422" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMnOK3SvkPSj9MtSQOdS5ReGwKEh0eTs9nKWJqDLQ-3vnGYcil2d6_y_5ishwAy4tjZnZQw5I2IPpnQbwkhspuCwLk7uY7sm6QtMmt_9e7IUKPbo2S87R6JZhs28UQeDy_ZJmJKsB6cIkLXRP-udesddntOguzZ771xd2_wG0wsFBHuvW9-6IML51m/w640-h422/redesigned-location-marker-pink.png" width="640"/></a></div></div><div style="text-align: left;"/><div style="text-align: left;"/><div style="text-align: left;"/><div style="text-align: left;"/><div style="text-align: left;"/><div style="text-align: left;"/><div style="text-align: left;"/><div style="text-align: left;"><br/> </div><h2 style="text-align: left;">Transitous Public Transit Routing Migrated to new API</h2><div style="text-align: left;">Furthermore the Transitous support has been migrated to the MOTIS 2-based API. This has also been backported to the 47.x releases (as the old API has been retired).</div><div style="text-align: left;">Also public transit routing in Finland will start using Transitous from 48. As Digitransit has slated the retirement of their old OpenTripPlanner 1.x-based API from late April it seemed appropriate to start using Transitous for that region now.</div><div style="text-align: left;"> </div><h2 style="text-align: left;">Transitous Talk at FOSDEM 2025</h2><div style="text-align: left;">When mentioning Transitous I also want to mention that the recording of mine, Felix Gündling's, and Jonah Brüchert's FOSDEM talk around Transitous is now available at:</div><div style="text-align: left;"> </div><div style="text-align: left;"><a href="https://fosdem.org/2025/schedule/event/fosdem-2025-4105-gnome-maps-meets-transitous-meets-motis/">https://fosdem.org/2025/schedule/event/fosdem-2025-4105-gnome-maps-meets-transitous-meets-motis/</a> </div><div style="text-align: left;"><br/></div><div style="text-align: left;">So, please enjoy this, and all the other improvements in GNOME 48 when you grab it! 😎</div></div></div>
</content>
<updated>2025-03-12T20:51:00Z</updated>
<published>2025-03-12T20:51:00Z</published>
<category scheme="http://www.blogger.com/atom/ns#" term="gnome maps"/>
<author>
<name>Marcus Lundblad</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/02923955229568787222</uri>
</author>
<source>
<id>tag:blogger.com,1999:blog-5620128670216603593</id>
<category term="gnome"/>
<category term="maps"/>
<category term="gnome maps"/>
<category term="openstreetmap"/>
<category term="routing"/>
<category term="transit"/>
<category term="FOSDEM"/>
<category term="excursions"/>
<category term="GNOME Maps 3.34"/>
<category term="GNOME Maps 3.36"/>
<category term="GNOME Maps 3.38"/>
<category term="gnome maps fosdem"/>
<category term="gpx"/>
<category term="gtfs"/>
<category term="gtk+"/>
<category term="gtk4."/>
<category term="libshumate"/>
<category term="maps gnome 2024 christmas"/>
<category term="summer"/>
<category term="travel"/>
<author>
<name>Marcus Lundblad</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/02923955229568787222</uri>
</author>
<link href="https://ml4711.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
<link href="https://www.blogger.com/feeds/5620128670216603593/posts/default" rel="self" type="application/atom+xml"/>
<link href="https://ml4711.blogspot.com/" rel="alternate" type="text/html"/>
<link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
<link href="https://www.blogger.com/feeds/5620128670216603593/posts/default?start-index=26&max-results=25" rel="next" type="application/atom+xml"/>
<title>The Maps and Geo Blog</title>
<updated>2025-03-12T20:51:02Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://blogs.gnome.org/yorubad-dev/?p=93</id>
<link href="https://blogs.gnome.org/yorubad-dev/2025/03/08/more-than-code-outreachy-gnome-experience/" rel="alternate" type="text/html"/>
<title>More Than Code: Outreachy Gnome Experience</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">It has been a productive, prosperous, and career-building few months—from contemplating whether to apply for the contribution stage, to submitting my application at the last minute, to not finding a Go project, then sprinting through a Rust course after five days of deliberation. Eventually, I began actively contributing to librsvg in Rust, updated a documentation … <a class="more-link" href="https://blogs.gnome.org/yorubad-dev/2025/03/08/more-than-code-outreachy-gnome-experience/">Continue reading <span class="screen-reader-text">More Than Code: Outreachy Gnome Experience</span></a></div>
</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>It has been a productive, prosperous, and career-building few months—from contemplating whether to apply for the contribution stage, to submitting my application at the last minute, to not finding a Go project, then sprinting through a Rust course after five days of deliberation. Eventually, I began actively contributing to librsvg in Rust, updated a documentation section, closed a couple of issues, and was ultimately selected for the Outreachy December 2024 – March 2025 cohort as an intern for the GNOME Foundation.</p>
<p>It has been a glorious journey, and I thank God for His love and grace throughout the application process up to this moment as I write this blog. I would love to delve into my journey to getting accepted into Outreachy, but since this blog is about reflecting on the experience as it wraps up, let’s get to it.</p>
<h6>Overcoming Fear and Doubt</h6>
<p>You might think my fears began when I got accepted into the internship, but they actually started much earlier. Before even applying, I was hesitant. Then, when I got in for the contribution phase, I realized that the language I was most familiar with, Go, was not listed.I felt like I was stepping into a battlefield with thousands of applicants, and my current arsenal was irrelevant. I believed I would absolutely dominate with Go, but now I couldn’t even find a project using it!</p>
<p>This fear lingered even after I got accepted. I kept wondering if I was going to mess things up terribly.<br/>
It takes time to master a programming language, and even more time to contribute to a large project. I worried about whether I could make meaningful contributions and whether I would ultimately fail.</p>
<p>And guess what? I did not fail. I’m still here, actively contributing to librsvg, and I plan to continue working on other GNOME projects. I’m now comfortable writing Rust, and most importantly, I’ve made huge progress on my project tasks. So how did I push past my fear? I initially didn’t want to apply at all, but a lyric from Dave’s song <em>Survivor’s Guilt</em> stuck with me: <em>“When you feel like givin’ up, know you’re close.”</em> Another saying that resonated with me was, <em>“You never know if you’ll fail or win if you don’t try.” </em>I stopped seeing the application as a competition with others and instead embraced an open mindset: <em>“I’ve always wanted to learn Rust, and this is a great opportunity.”</em> <em>“I’m not the best at communication, but maybe I can grow in that area.”</em> Shifting my mindset from fear to opportunity helped me stay the course, and my fear of failing never materialized.</p>
<h6>My Growth and Learning Process</h6>
<p>For quite some time, I had been working exclusively with a single programming language, primarily building backend applications. However, my Outreachy internship experience opened me up to a whole new world of possibilities. Now, I program in Rust, and I have learned a lot about SVGs, the XML tree, text rendering, and much more.</p>
<p>My mentor has been incredibly supportive, and thanks to him, I believe I will be an excellent mentor when I find myself in a position to guide others. His approach to communication, active listening, and problem-solving has left a strong impression on me, and I’ve found myself subconsciously adopting his methods. I also picked up some useful Git tricks from him and improved my ability to visualize and break down complex problems.</p>
<p>I have grown in technical knowledge, soft skills, and networking—my connections within the open-source community have expanded significantly!</p>
<h6>Project Progress and Next Steps</h6>
<p>The project’s core algorithms are now in place, including text-gathering, whitespace handling, text formatting, attribute collection, shaping, and more. The next step is to integrate these components to implement the full SVG2 text layout algorithm.</p>
<p>As my Outreachy internship with GNOME comes to an end today, I want to reflect on this incredible journey and express my gratitude to everyone who made it such a rewarding experience.</p>
<p>I am deeply grateful to God, the Outreachy organizers, my family, my mentor Federico (GNOME co-founder), Felipe Borges, and everyone who contributed to making this journey truly special. Thank you all for an unforgettable experience.</p>
<p> </p></div>
</content>
<updated>2025-03-08T16:31:39Z</updated>
<published>2025-03-08T16:31:39Z</published>
<category term="Uncategorized"/>
<author>
<name>yorubad-dev</name>
</author>
<source>
<id>https://blogs.gnome.org/yorubad-dev</id>
<logo>https://blogs.gnome.org/yorubad-dev/files/2024/12/cropped-rr-32x32.jpg</logo>
<link href="https://blogs.gnome.org/yorubad-dev/feed/" rel="self" type="application/rss+xml"/>
<link href="https://blogs.gnome.org/yorubad-dev" rel="alternate" type="text/html"/>
<title>ADETOYE ANOINTING</title>
<updated>2025-03-08T16:31:39Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://blogs.gnome.org/carlosg/?p=7672</id>
<link href="https://blogs.gnome.org/carlosg/2025/03/08/embracing-sysexts-for-system-development-under-silverblue/" rel="alternate" type="text/html"/>
<title>Embracing sysexts for system development under Silverblue</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Due to my circumstances, I might be perhaps interested in dogfooding a larger number of GNOME system/session components on a daily basis than the average. So far, I have been using jhbuild to help me with this deed, mostly in the form of jhbuild make to selectively build projects out of their git tree. See, … <a class="more-link" href="https://blogs.gnome.org/carlosg/2025/03/08/embracing-sysexts-for-system-development-under-silverblue/">Continue reading <span class="screen-reader-text">Embracing sysexts for system development under Silverblue</span></a></div>
</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Due to my circumstances, I might be perhaps interested in dogfooding a larger number of GNOME system/session components on a daily basis than the average.</p>
<p>So far, I have been using jhbuild to help me with this deed, mostly in the form of <code>jhbuild make</code> to selectively build projects out of their git tree. See, there’s a point in life where writing long-winded CLI commands stop making you feel smart and work the opposite way, <code>jhbuild</code> had a few advantages I liked:</p>
<ul>
<li>I could reset and rebuild build trees without having to remember project-specific meson args.</li>
<li>The build dir did not pollute the source dir, and would be wiped out without any loss.</li>
<li>The main command is pretty fast to type with minimal finger motion for something done so frequently, jh<tab>.</li>
</ul>
<p>This, combined with my habit to use Fedora Rawhide also meant I did not require to rebuild the world to get up-to-date dependencies, keeping the number of miscellaneous modules built to a minimum.</p>
<p>This was all true even after Silverblue came around, and <a href="https://blogs.gnome.org/fmuellner/">Florian</a> unlocked the “run GNOME as built from toolbox” <a href="https://blogs.gnome.org/fmuellner/2020/03/02/shell-hacking-on-silverblue/">achievement</a>. I adopted this methodology, but still using <code>jhbuild</code> to build things inside that toolbox, for the sake of convenience.</p>
<h1>Enter <a href="https://gitlab.gnome.org/tchx84/sysext-utils">sysext-utils</a></h1>
<p>Meanwhile, systemd sysexts came around as a way to install “extensions” to the base install, even over atomic distributions, paving a way for development of system components to happen in these distributions. More recently Martín Abente <a href="https://discourse.gnome.org/t/towards-a-better-way-to-hack-and-test-your-system-components/21075">brought</a> an excellent set of utilities to ease building such sysexts.</p>
<p>This is a great step in the direction towards sysexts as a developer testing method. However, there is a big drawback for users of atomic distributions: to build these sysexts you must have all necessary build dependencies in your host system. Basically, desecrating your small and lean atomic install with tens to hundreds of packages. While for GNOME OS it may be true that it comes “with batteries included”, feels like a very big margin to miss the point with Silverblue, where the base install is minimal and you are supposed to carry development with toolbox, install apps with flatpak, etc etc.</p>
<h1>What is necessary</h1>
<p>Ideally, in these systems, we’d want:</p>
<ol>
<li>A toolbox matching the version of the host system.</li>
<li>With all development tools and dependencies installed</li>
<li>The sysexts to be created from inside the toolbox</li>
<li>The sysexts to be installed in the host system</li>
<li>But also, the installed sysexts need to be visible from inside the toolbox, so that we can build things depending on them</li>
</ol>
<p>The most natural way to achieve both last points is building things so they install in /usr/local, as this will allow us to also mount this location from the host inside the toolbox, in order to build things that depend on our own sysexts.</p>
<p>And last, I want an easy way to manage these projects that does not get in the middle of things, is fast to type, etc.</p>
<h1>Introducing <a href="https://gitlab.gnome.org/carlosg/gg">gg</a></h1>
<p>So I’ve made <a href="https://gitlab.gnome.org/carlosg/gg">a small script</a> to help myself on these tasks. It can be installed at <code>~/.local/bin</code> along with sysext-utils, and be used in a host shell to generate, install and generally manage a number of sysexts.</p>
<p>Sysexts-utils is almost there for this, I however needed some local hacks to help me get by:</p>
<p>– Since I have these are installed at <code>~/.local</code>, but they will be run with pkexec to do things as root, the python library lookup paths had to be altered in the executable scripts (<a href="https://gitlab.gnome.org/tchx84/sysext-utils/-/issues/10">sysext-utils#10</a>).<br/>
– They are ATM somewhat implicitly prepared to always install things at /usr, I had to alter paths in code to e.g. generate GSettings schemas at the right location (<a href="https://gitlab.gnome.org/tchx84/sysext-utils/-/issues/11">sysext-utils#11</a>).</p>
<p>Hopefully these will be eventually sorted out. But with this I got 1) a pristine atomic setup and 2) My tooling in <code>~/.local</code> 3) all the development environment in my home dir, 4) a simple and fast way to manage a number of projects. Just most I ever wanted from jhbuild.</p>
<p>This tool is a hack to put things together, done mainly so it’s intuitive and easy to myself. So far been using it for a week with few regrets except the frequent password prompts. If you think it’s useful for you too, you’re welcome.</p></div>
</content>
<updated>2025-03-08T13:16:30Z</updated>
<published>2025-03-08T13:16:30Z</published>
<category term="General"/>
<author>
<name>carlosg</name>
</author>
<source>
<id>https://blogs.gnome.org/carlosg</id>
<link href="https://blogs.gnome.org/carlosg/feed/" rel="self" type="application/rss+xml"/>
<link href="https://blogs.gnome.org/carlosg" rel="alternate" type="text/html"/>
<subtitle>Just another GNOME Blogs weblog</subtitle>
<title>Carlos Garnacho</title>
<updated>2025-03-08T13:16:30Z</updated>
</source>
</entry>
<entry>
<id>https://wingolog.org/2025/03/07/whippet-lab-notebook-untagged-mallocs-bis</id>
<link href="https://wingolog.org/archives/2025/03/07/whippet-lab-notebook-untagged-mallocs-bis" rel="alternate" type="text/html"/>
<title>whippet lab notebook: untagged mallocs, bis</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><div><p><a href="https://wingolog.org/archives/2025/03/04/whippet-lab-notebook-on-untagged-mallocs">Earlier this
week</a>
I took an inventory of how <a href="https://gnu.org/s/guile">Guile</a> uses the
Boehm-Demers-Weiser (BDW) garbage collector, with the goal of making
sure that I had replacements for all uses lined up in
<a href="https://github.com/wingo/whippet">Whippet</a>. I categorized the uses
into seven broad categories, and I was mostly satisfied that I have
replacements for all except the last: I didn’t know what to do with
untagged allocations: those that contain arbitrary data, possibly full
of pointers to other objects, and which don’t have a header that we can
use to inspect on their type.</p><p>But now I do! Today’s note is about how we can support untagged
allocations of a few different kinds in Whippet’s <a href="https://github.com/wingo/whippet/blob/main/doc/collector-mmc.md">mostly-marking
collector</a>.</p><h3>inside and outside</h3><p>Why bother supporting untagged allocations at all? Well, if I had my
way, I wouldn’t; I would just slog through Guile and fix all uses to be
tagged. There are only a finite number of use sites and I could get to
them all in a month or so.</p><p>The problem comes for uses of <a href="https://www.gnu.org/software/guile/docs/docs-2.0/guile-ref/Memory-Blocks.html"><tt>scm_gc_malloc</tt></a> from outside <tt>libguile</tt>
itself, in C extensions and embedding programs. These users are loathe
to adapt to any kind of change, and garbage-collection-related changes
are the worst. So, somehow, we need to support these users if we are
not to break the Guile community.</p><h3>on intent</h3><p>The problem with <tt>scm_gc_malloc</tt>, though, is that it is missing an expression of intent, notably as regards tagging. You can use it
to allocate an object that has a tag and thus can be traced precisely,
or you can use it to allocate, well, anything else. I think we will
have to add an API for the tagged case and assume that anything that
goes through <tt>scm_gc_malloc</tt> is requesting an untagged,
conservatively-scanned block of memory. Similarly for
<tt>scm_gc_malloc_pointerless</tt>: you could be allocating a tagged object
that happens to not contain pointers, or you could be allocating an
untagged array of whatever. A new API is needed there too for
pointerless untagged allocations.</p><h3>on data</h3><p>Recall that the mostly-marking collector can be built in a number of
different ways: it can support conservative and/or precise roots, it can
trace the heap precisely or conservatively, it can be generational or
not, and the collector can use multiple threads during pauses or not.
Consider a basic configuration with precise roots. You can make
tagged pointerless allocations just fine: the trace function for that
tag is just trivial. You would like to extend the collector with the ability
to make <i>untagged</i> pointerless allocations, for raw data. How to do
this?</p><p>Consider first that when the collector goes to trace an object, it can’t use bits inside
the object to discriminate between the tagged and untagged cases.
Fortunately though <a href="https://github.com/wingo/whippet/blob/main/src/nofl-space.h#L239">the main space of the mostly-marking collector has one metadata byte for each 16 bytes of
payload</a>. Of those 8 bits, 3 are used for the mark (five different
states, allowing for future concurrent tracing), two for the <a href="https://wingolog.org/archives/2024/10/03/preliminary-notes-on-a-nofl-field-logging-barrier">precise
field-logging write
barrier</a>,
one to indicate whether the object is pinned or not, and one to indicate
the end of the object, so that we can determine object bounds just by
scanning the metadata byte array. That leaves 1 bit, and we can use it
to indicate untagged pointerless allocations. Hooray!</p><p>However there is a wrinkle: when Whippet decides the it should evacuate
an object, it tracks the evacuation state in the object itself; the
embedder has to provide an implementation of a <a href="https://github.com/wingo/whippet/blob/main/api/gc-embedder-api.h#L57-L64">little state machine</a>,
allowing the collector to detect whether an object is forwarded or not,
to claim an object for forwarding, to commit a forwarding pointer, and
so on. We can’t do that for raw data, because all bit states belong to
the object, not the collector or the embedder. So, we have to set the
“pinned” bit on the object, indicating that these objects can’t move.</p><p>We could in theory manage the forwarding state in the metadata byte, but
we don’t have the bits to do that currently; maybe some day. For now,
untagged pointerless allocations are pinned.</p><h3>on slop</h3><p>You might also want to support untagged allocations that contain
pointers to other GC-managed objects. In this case you would want these
untagged allocations to be scanned conservatively. We can do this, but
if we do, it will pin all objects.</p><p>Thing is, conservative stack roots is a kind of a sweet spot in
language run-time design. You get to avoid constraining your compiler,
you avoid a class of bugs related to rooting, but you can still support
compaction of the heap.</p><p>How is this, you ask? Well, consider that you can move any object for
which we can precisely enumerate the incoming references. This is
trivially the case for precise roots and precise tracing. For
conservative roots, we don’t know whether a given edge is really an
object reference or not, so we have to conservatively avoid moving those
objects. But once you are done tracing conservative edges, any live
object that hasn’t yet been traced is fair game for evacuation, because
none of its predecessors have yet been visited.</p><p>But once you add conservatively-traced objects back into the mix, you
don’t know when you are done tracing conservative edges; you could
always discover another conservatively-traced object later in the trace,
so you have to pin everything.</p><p>The good news, though, is that we have gained an easier migration path.
I can now shove Whippet into Guile and get it running even before I have
removed untagged allocations. Once I have done so, I will be able to
allow for compaction / evacuation; things only get better from here.</p><p>Also as a side benefit, the mostly-marking collector’s heap-conservative
configurations are now faster, because we have metadata attached to
objects which allows tracing to skip known-pointerless objects. This
regains an optimization that BDW has long had via its
<tt>GC_malloc_atomic</tt>, used in Guile since time out of mind.</p><h3>fin</h3><p>With support for untagged allocations, I think I am finally ready to
start getting Whippet into Guile itself. Happy hacking, and see you on
the other side!</p></div></div>
</content>
<updated>2025-03-07T13:47:11Z</updated>
<published>2025-03-07T13:47:11Z</published>
<author>
<name>Andy Wingo</name>
<uri>https://wingolog.org/</uri>
</author>
<source>
<id>https://wingolog.org/feed/atom</id>
<link href="https://wingolog.org/" rel="alternate" type="text/html"/>
<link href="https://wingolog.org/feed/atom" rel="self" type="application/atom+xml"/>
<subtitle>A mostly dorky weblog by Andy Wingo</subtitle>
<title>wingolog</title>
<updated>2025-03-07T13:47:11Z</updated>
</source>
</entry>
<entry xml:lang="en">
<id>http://samthursfield.wordpress.com/?p=2697</id>
<link href="https://samthursfield.wordpress.com/2025/03/07/media-playback-tablet-running-gnome-and-postmarketos/" rel="alternate" type="text/html"/>
<title>Media playback tablet running GNOME and postmarketOS</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">A couple of years ago I set up a simple and independent media streaming server for my Bandcamp music collection using a Raspberry Pi 4, Fedora IoT and Jellyfin. It works nicely and I don’t have to play any cloud rent to Spotify to listen to music at home. But it’s annoying having the music … <a class="more-link" href="https://samthursfield.wordpress.com/2025/03/07/media-playback-tablet-running-gnome-and-postmarketos/">Continue reading <span class="screen-reader-text">Media playback tablet running GNOME and postmarketOS</span></a></div>
</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>A couple of years ago I set up a simple and independent <a href="https://samthursfield.wordpress.com/2023/09/06/quickball-media-server-v2/">media streaming server</a> for my <a href="https://bandcamp.com/ssssam">Bandcamp music collection</a> using a Raspberry Pi 4, Fedora IoT and Jellyfin. It works nicely and I don’t have to play any cloud rent to Spotify to listen to music at home.</p>
<p>But it’s annoying having the music playback controls buried in my phone or laptop. How many times do you go to play a song and get distracted by a WhatsApp message instead?</p>
<p>So I started thinking about a tablet that would just control media playback. A tablet running a non-corporate operating system, because music is too important to allow Google to stick AI and adverts in the middle of it. Last month Pablo told me that postmarketOS had pretty decent support for <a href="https://wiki.postmarketos.org/wiki/Xiaomi_Mi_Pad_5_Pro_(xiaomi-elish)">a specific mainstream tablet</a> and so I couldn’t reset buying one second-hand and trying to set up GNOME there for media playback.</p>
<p>Read on and I will tell you how the setup procedure went, what is working nicely and what we could still improve.</p>
<h2 class="wp-block-heading">What is the Xiaomi Pad 5 Pro tablet like?</h2>
<p>I’ve never owned a tablet so all I can tell you is this: it looks like a shiny black mirror. I couldn’t find the power button at first, but it turns out to be on the top. </p>
<p>The device specs claim that it has an analog headphone output, which is not true. It does come with a USB-C to headphone adapter in the box, though.</p>
<p>It comes with an antagonistic Android-based OS that seems to constantly prompt you to sign in to things and accept various terms and conditions. I guess they <a href="https://www.penny-arcade.com/comic/2002/07/19/with-friends-like-these">really want to get to know you</a>.</p>
<p>I paid 240€ for it second hand. The seller didn’t do a factory reset before posting it to me, but I’m a good citizen so I wiped it for them, before anyone could try to commit online fraud using their digital identity. </p>
<h2 class="wp-block-heading">How easy is it to install postmarketOS + GNOME on the Xiaomi Pad 5 Pro?</h2>
<p>I work on systems software but I prefer to stay away from the hardware side of things. Give me a computer that at least can boot to a shell, please. I am not an expert in this stuff. So how did I do at installing a custom OS on an Android tablet?</p>
<h3 class="wp-block-heading">Figuring out the display model</h3>
<p>The hardest part of the process was actually the first step: getting root access on the device so that I could see what type of display panel it has.</p>
<p>Xiaomi tablets have some sort of “bootloader lock”, but thankfully this device was already unlocked. If you ever look at purchasing a Xiaomi device, be <strong>very</strong> wary that Xiaomi might have locked the bootloader such that you can’t run custom software on your device. Unlocking a locked bootloader seems to require their permission. This kind of thing is a big red flag when buying computers.</p>
<p>One popular tool to root an Android device is Team Win’s <a href="https://twrp.me/about/">TWRP</a>. However it didn’t have support for the Pad 5 Pro, so instead I used <a href="https://github.com/topjohnwu/Magisk">Magisk</a>.</p>
<p>I found rooting process with Magisck complicated. The only instructions I could find were in this video named “<a href="https://www.youtube.com/watch?v=zHdD53ghM-4">Xiaomi Pad 5 Rooting without the Use of TWRP | Magisk Manager</a>” from <em>Simply Tech-Key (Cris Apolinar)</em>. This gives you a two step process, which requires a PC with the Android debugging tools ‘adb’ and ‘fastboot’ installed and set up.</p>
<h4 class="wp-block-heading">Step 1: Download and patch the boot.img file</h4>
<p/>
<ol class="wp-block-list">
<li>On the PC, download the boot.img file from the stock firmware. (See below).</li>
<li>Copy it onto the tablet.</li>
<li>On the tablet, download and install the Magisk Manager app from the <a href="https://github.com/topjohnwu/Magisk/releases">Magisck Github Releases page</a>.</li>
<li>Open the Magisk app and select “Install” to patch the boot.img file.</li>
<li>Copy the patched boot.img off the tablet back to your PC and rename it to <code>patched_boot.img</code>.</li>
</ol>
<p>The <code>boot.img </code>linked from the video didn’t work for me. Instead I searched online for <em><span style="text-decoration: underline;">“xiaomi pad 5 pro stock firmware rom”</span></em> and found one that worked that way.</p>
<p>It’s important to remember that downloading and running random binaries off the internet is <em>very</em> dangerous. It’s possible that someone pretends the file is one thing, when it’s actually malware that will help them steal your digital identity. The best defence is to factory reset the tablet before you start, so that there’s nothing on there to steal in the first place.</p>
<h4 class="wp-block-heading">Step 2: Boot the patched boot.img on the tablet</h4>
<ol class="wp-block-list">
<li>Ensure developer mode is enabled on the tablet: go to “About this Device” and tap the box that shows the OS version 7 times.</li>
<li>Ensure USB debugging is enabled: find the “Developer settings” dialog in the settings window and enable if needed.</li>
<li>On the PC, run <code>adb reboot fastboot</code> to reboot the tablet and reach the bootloader menu.</li>
<li>Run <code>fastboot flash boot patched_boot.img</code> to boot the patched boot image.</li>
</ol>
<p>At this point, if the <code>boot.img</code> file was good, you should see the device boot back to Android and it’ll now be “rooted”. So you can follow the instructions in the <a href="https://wiki.postmarketos.org/wiki/Xiaomi_Mi_Pad_5_Pro_(xiaomi-elish)">postmarketOS wiki page</a> to figure out if your device has the <em>BOE</em> or the <em>CSOT</em> display. What a ride!</p>
<h3 class="wp-block-heading">Install postmarketOS</h3>
<p>If we can find a way to figure out the display without needing root access, it’ll make the process substantially easier, because the remaining steps worked like a charm.</p>
<p>Following the wiki page, you first install <a href="https://gitlab.postmarketos.org/postmarketOS/pmbootstrap">pmbootstrap</a> and run <code>pmbootstrap init</code> to configure the OS image. </p>
<figure class="wp-block-image size-large"><a href="https://samthursfield.wordpress.com/wp-content/uploads/2025/03/image.png"><img alt="Laptop running pmbootstrap" class="wp-image-2712" height="785" src="https://samthursfield.wordpress.com/wp-content/uploads/2025/03/image.png?w=1024" width="1024"/></a></figure>
<p><em>A note for Fedora Silverblue users: the bootstrap process doesn’t work inside a Toolbx container. At some point it tries to create <code>/dev</code> in the rootfs using <code>mknod</code> and fails. You’ll have to install pmbootstrap on the host and run it there.</em></p>
<p>Next you use <code>pmbootstrap flasher</code> to install the OS image to the correct partition.</p>
<p>I wanted to install to the <code>system_b</code> partition but I seemed to get an ‘out of disk space’ error. The partition is 3.14 GiB in size. So I flashed the OS to the <code>userdata</code> partition. </p>
<p>The build and flashing process worked really well and I was surprised to see the postmarketOS boot screen so quickly.<br/></p>
<div class="wp-block-image">
<figure class="aligncenter size-medium is-resized"><a href="https://samthursfield.wordpress.com/wp-content/uploads/2025/03/image-3.png"><img alt="Tablet showing postmarketOS boot screen" class="wp-image-2717" height="299" src="https://samthursfield.wordpress.com/wp-content/uploads/2025/03/image-3.png?w=256" style="width: 395px; height: auto;" width="256"/></a></figure></div>
<h2 class="wp-block-heading">How well does GNOME work as a tablet interface?</h2>
<p>The design side of GNOME have thought carefully about making GNOME work well on touch-screen devices. This doesn’t mean specifically optimising it for touch-screen use, it’s more about avoiding a hard requirement on you having a two-button mouse available.</p>
<p>To my knowledge, nobody is paying to optimise the “GNOME on tablets” experience right now. So it’s certainly lacking in polish. In case it wasn’t clear, <em>this one is</em> <em>for the real headz.</em></p>
<p>Login to the machine was tricky because there’s no on-screen keyboard on the GDM screen. You can work around that by SSH’ing to the machine directly and creating a GDM config file to automatically log in:<br/></p>
<pre class="wp-block-code"><code>$ cat /etc/gdm/custom.conf
# GDM configuration storage
[daemon]
AutomaticLogin=media
AutomaticLoginEnable=True
</code></pre>
<p>It wasn’t possible to push the “Skip” button in initial setup, for whatever reason. But I just rebooted the system to get round that.</p>
<figure class="wp-block-image size-large"><a href="https://samthursfield.wordpress.com/wp-content/uploads/2025/03/image-4.png"><img alt="Tablet showing GNOME Shell with "welcome to postmarketOS edge" popup" class="wp-image-2719" height="598" src="https://samthursfield.wordpress.com/wp-content/uploads/2025/03/image-4.png?w=1024" width="1024"/></a></figure>
<p>Enough things work that I can already use the tablet for my purposes of playing back music from Jellyfin, from Bandcamp and from elsewhere on the web.</p>
<p>The built-in speakers audio output doesn’t work, and connecting a USB-to-headphone adapter doesn’t work either. What does work is Bluetooth audio, so I can play music that way already. <em>[Update: as of 2025-03-07, built-in audio also work</em>s. <em>I haven’t investigated what changed]</em></p>
<p>I disabled the automatic screen lock, as this device is never leaving my house anyway. The screen seems to stay on and burn power quickly, which isn’t great. I set the screen blank interval to 1 minute, which should save power, but I haven’t found a nice way to “un-blank” the screen again. Touch events don’t seem to do anything. At present I work around by pressing the power button (which suspends the device and stops audio), then pressing it again to resume, at which point the display comes back. <em>[Update: see the comments; it’s possible to reconfigure the power button so that it doesn’t suspend the device].</em></p>
<p>Apart from this, everything works surprisingly great. Wi-fi and Bluetooth are reliable. The display sometimes glitches when resuming from suspend but mostly works fine. Multitouch gestures work perfectly — this is first time I’ve ever used GNOME with a touch screen and it’s clear that there’s a lot of polish. The system is fast. The Alpine + postmarketOS teams have done a great job packaging GNOME, which is commendable given that they had to literally <a href="https://postmarketos.org/blog/2024/03/05/adding-systemd/">port systemd</a>.</p>
<h2 class="wp-block-heading">What’s next?</h2>
<p>I’d like to figure out how un-blank the screen without suspending and resuming the device. </p>
<p>It might be nice to fix audio output via the USB-C port. But more likely I might set up a DIY “smart speaker” network around the house, using single-board computers with decent DAC chips connected to real amplifiers. Then the tablet would become more of a remote control.</p>
<p>I already <a href="https://opencollective.com/postmarketos">donate to postmarketOS on Opencollective.com</a>, and I might increase the amount as I am really impressed by how well all of this has come together.</p>
<p>Maenwhile I’m finally able to hang out with my cat listening to <a href="https://vladimirchicken.bandcamp.com/album/maharajah-single">my favourite Vladimir Chicken songs</a>.</p>
<p/>
<figure class="wp-block-image size-large is-resized"><a href="https://samthursfield.wordpress.com/wp-content/uploads/2025/03/image-5.png"><img alt="" class="wp-image-2726" height="1024" src="https://samthursfield.wordpress.com/wp-content/uploads/2025/03/image-5.png?w=849" style="width: 503px; height: auto;" width="849"/></a></figure>
<p><em>Update</em>s:<br/></p>
<ul class="wp-block-list">
<li><em>See the comments for a way to reconfigure the power button so that it unblanks the screen instead of suspending the device.</em></li>
<li> <em>After updating to latest (2025-03-07) postmarketOS edge, the built-in speakers now work and they sound pretty OK. Not sure what changed but that’s very nice to have.</em></li>
</ul>
<p/></div>
</content>
<updated>2025-03-07T11:48:32Z</updated>
<published>2025-03-07T11:48:32Z</published>
<category term="Music"/>
<category term="gnome"/>
<category term="postmarketos"/>
<author>
<name>Sam Thursfield</name>
</author>
<source>
<id>https://samthursfield.wordpress.com</id>
<logo>https://samthursfield.wordpress.com/wp-content/uploads/2020/10/cropped-favicon.png?w=32</logo>
<link href="https://samthursfield.wordpress.com/feed/" rel="self" type="application/rss+xml"/>
<link href="https://samthursfield.wordpress.com" rel="alternate" type="text/html"/>
<link href="https://samthursfield.wordpress.com/osd.xml" rel="search" title="Sam Thursfield" type="application/opensearchdescription+xml"/>
<link href="https://samthursfield.wordpress.com/?pushpress=hub" rel="hub" type="text/html"/>
<subtitle>Software and technology from Galicia, Spain</subtitle>
<title>Sam Thursfield</title>
<updated>2025-03-18T13:41:48Z</updated>
</source>
</entry>
<entry>
<id>https://wingolog.org/2025/03/04/whippet-lab-notebook-on-untagged-mallocs</id>
<link href="https://wingolog.org/archives/2025/03/04/whippet-lab-notebook-on-untagged-mallocs" rel="alternate" type="text/html"/>
<title>whippet lab notebook: on untagged mallocs</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><div><p>Salutations, populations. Today’s note is more of a work-in-progress
than usual; I have been finally starting to look at getting
<a href="https://github.com/wingo/whippet">Whippet</a> into
<a href="https://gnu.org/s/guile">Guile</a>, and there are some open questions.</p><h3>inventory</h3><p>I started by taking a look at how Guile uses the <a href="https://github.com/ivmai/bdwgc">Boehm-Demers-Weiser
collector</a>‘s API, to make sure I had all
my bases covered for an eventual switch to something that was not BDW.
I think I have a good overview now, and have divided the parts of BDW-GC
used by Guile into seven categories.</p><h4>implicit uses</h4><p>Firstly there are the ways in which Guile’s run-time and compiler depend
on BDW-GC’s behavior, without actually using BDW-GC’s API. By this I
mean principally that we assume that any reference to a GC-managed
object from any thread’s stack will keep that object alive. The same
goes for references originating in global variables, or static data
segments more generally. Additionally, we rely on GC objects not to
move: references to GC-managed objects in registers or stacks are valid
across a GC boundary, even if those references are outside the GC-traced
graph: all objects are pinned.</p><p>Some of these “uses” are internal to Guile’s implementation itself, and
thus amenable to being changed, albeit with some effort. However some
escape into the wild via Guile’s API, or, as in this case, as implicit
behaviors; these are hard to change or evolve, which is why I am putting
my hopes on Whippet’s <a href="https://github.com/wingo/whippet/blob/main/doc/collector-mmc.md">mostly-marking
collector</a>,
which allows for conservative roots.</p><h4>defensive uses</h4><p>Then there are the uses of BDW-GC’s API, not to accomplish a task, but
to protect the mutator from the collector:
<a href="https://github.com/ivmai/bdwgc/blob/master/include/gc/gc.h#L1608"><tt>GC_call_with_alloc_lock</tt></a>,
explicitly enabling or disabling GC, calls to <tt>sigmask</tt> that take
BDW-GC’s use of POSIX signals into account, and so on. BDW-GC can stop
any thread at any time, between any two instructions; for most users is
anodyne, but if ever you use weak references, things start to get really
gnarly.</p><p>Of course a new collector would have its own constraints, but switching
to cooperative instead of pre-emptive safepoints would be a welcome
relief from this mess. On the other hand, we will require client code
to explicitly mark their threads as inactive during calls in more cases,
to ensure that all threads can promptly reach safepoints at all times.
Swings and roundabouts?</p><h4>precise tracing</h4><p>Did you know that the Boehm collector allows for precise tracing? It
does! It’s slow and truly gnarly, but when you need precision, precise
tracing nice to have. (This is the
<a href="https://github.com/ivmai/bdwgc/blob/master/include/gc/gc_mark.h"><tt>GC_new_kind</tt></a>
interface.) Guile uses it to mark Scheme stacks, allowing it to avoid
treating unboxed locals as roots. When it loads compiled files, Guile
also adds some sliced of the mapped files to the root set. These
interfaces will need to change a bit in a switch to Whippet but are
ultimately internal, so that’s fine.</p><p>What is not fine is that Guile allows C users to hook into precise
tracing, notably via
<a href="https://www.gnu.org/software/guile/docs/docs-2.0/guile-ref/Smobs.html"><tt>scm_smob_set_mark</tt></a>.
This is not only the wrong interface, not allowing for copying
collection, but these functions are just truly gnarly. I don’t know
know what to do with them yet; are our external users ready to forgo
this interface entirely? We have been working on them over time, but I
am not sure.</p><h4>reachability</h4><p>Weak references, weak maps of various kinds: the implementation of these
in terms of BDW’s API is incredibly gnarly and ultimately unsatisfying.
We will be able to replace all of these with ephemerons and tables of
ephemerons, which are natively supported by Whippet. The same goes with
finalizers.</p><p>The same goes for constructs built on top of finalizers, such as
<a href="https://wingolog.org/archives/2024/07/22/finalizers-guardians-phantom-references-et-cetera">guardians</a>;
we’ll get to reimplement these on top of nice Whippet-supplied
primitives. Whippet allows for resuscitation of finalized objects, so
all is good here.</p><h4>misc</h4><p>There is a long list of miscellanea: the interfaces to explicitly
trigger GC, to get statistics, to control the number of marker threads,
to initialize the GC; these will change, but all uses are internal, making it not a terribly big
deal.</p><p>I should mention one API concern, which is that BDW’s state is all
implicit. For example, when you go to allocate, you don’t pass the API
a handle which you have obtained for your thread, and which might hold
some thread-local freelists; BDW will instead load thread-local
variables in its API. That’s not as efficient as it could be and
Whippet goes the explicit route, so there is some additional plumbing to
do.</p><p>Finally I should mention the true miscellaneous BDW-GC function:
<tt>GC_free</tt>. Guile exposes it via an API, <tt>scm_gc_free</tt>. It was already
vestigial and we should just remove it, as it has no sensible semantics
or implementation.</p><h4>allocation</h4><p>That brings me to what I wanted to write about today, but am going to
have to finish tomorrow: the actual allocation routines. BDW-GC
provides two, essentially: <tt>GC_malloc</tt> and <tt>GC_malloc_atomic</tt>. The
difference is that “atomic” allocations don’t refer to other
GC-managed objects, and as such are well-suited to raw data. Otherwise you can think of atomic allocations as a pure optimization, given that BDW-GC mostly traces conservatively anyway.</p><p>From the perspective of a user of BDW-GC looking to switch away, there
are two broad categories of allocations, tagged and untagged.</p><p>Tagged objects have attached metadata bits allowing their type to be inspected by the user later on. This is the
happy path! We’ll be able to write a <tt>gc_trace_object</tt> function that
takes any object, does a switch on, say, some bits in the first word,
dispatching to type-specific tracing code. As long as the object is
sufficiently initialized by the time the next safepoint comes around,
we’re good, and given cooperative safepoints, the compiler should be able to
ensure this invariant.</p><p>Then there are untagged allocations. Generally speaking, these are of
two kinds: temporary and auxiliary. An example of a temporary
allocation would be growable storage used by a C run-time routine,
perhaps as an unbounded-sized alternative to <tt>alloca</tt>. Guile uses these a
fair amount, as they compose well with non-local control flow as
occurring for example in exception handling.</p><p>An auxiliary allocation on the other hand might be a data structure only
referred to by the internals of a tagged object, but which itself never
escapes to Scheme, so you never need to inquire about its type; it’s
convenient to have the lifetimes of these values managed by the GC, and
when desired to have the GC automatically trace their contents. Some of
these should just be folded into the allocations of the tagged objects
themselves, to avoid pointer-chasing. Others are harder to change,
notably for mutable objects. And the trouble is that for external users of <tt>scm_gc_malloc</tt>, I fear that we won’t be able to migrate them over, as we don’t know whether they are making tagged mallocs or not.</p><h3>what is to be done?</h3><p>One conventional way to handle untagged allocations is to manage
to fit your data into other tagged data structures; V8 does this in many
places with instances of FixedArray, for example, and Guile should do
more of this. Otherwise, you make new tagged data types. In either case, all auxiliary data
should be tagged.</p><p>I think there may be an alternative, which would be just to support the
equivalent of untagged <tt>GC_malloc</tt> and <tt>GC_malloc_atomic</tt>; but for that,
I am out of time today, so type at y’all tomorrow. Happy hacking!</p></div></div>
</content>
<updated>2025-03-04T15:42:32Z</updated>
<published>2025-03-04T15:42:32Z</published>
<author>
<name>Andy Wingo</name>
<uri>https://wingolog.org/</uri>
</author>
<source>
<id>https://wingolog.org/feed/atom</id>
<link href="https://wingolog.org/" rel="alternate" type="text/html"/>
<link href="https://wingolog.org/feed/atom" rel="self" type="application/atom+xml"/>
<subtitle>A mostly dorky weblog by Andy Wingo</subtitle>
<title>wingolog</title>
<updated>2025-03-07T13:47:11Z</updated>
</source>
</entry>
<entry>
<id>https://www.aryank.in/posts/2025-02-28-linux-syscall/</id>
<link href="https://www.aryank.in/posts/2025-02-28-linux-syscall/" rel="alternate" type="text/html"/>
<title>Create Custom System Call on Linux 6.8</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Ever wanted to create a custom system call? Whether it be as an assignment, just for fun or learning more about the kernel, system calls are a cool way to learn more about our system.</p>
<p>Note - crossposted from my article on <a href="https://medium.com/@aryan20/create-custom-system-call-on-linux-6-8-126edef6caaf">Medium</a></p>
<h2>Why follow this guide?</h2>
<p>There are various guides on this topic, but the problem occurs due to the pace of kernel development. Most guides are now obsolete and throw a bunch of errors, hence I’m writing this post after going through the errors and solving them :)</p>
<h2>Set system for kernel compile</h2>
<p>On Red Hat / Fedora / Open Suse based systems, you can simply do</p>
<pre><code class="language-bash">Sudo dnf builddep kernel
Sudo dnf install kernel-devel
</code></pre>
<p>On Debian / Ubuntu based</p>
<pre><code>sudo apt-get install build-essential vim git cscope libncurses-dev libssl-dev bison flex
</code></pre>
<h2>Get the kernel</h2>
<p>Clone the kernel source tree, we’ll be cloning specifically the 6.8 branch but instructions should work on newer ones as well (till the kernel devs change the process again).</p>
<pre><code class="language-bash">git clone --depth=1 --branch v6.8 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
</code></pre>
<p>Ideally, the cloned version should be equal to or higher than your current kernel version.</p>
<p>You can check the current kernel version through the command</p>
<pre><code>uname -r
</code></pre>
<h2>Create the new syscall</h2>
<p>Perform the following</p>
<pre><code class="language-bash">cd linux
make mrproper
mkdir hello
cd hello
touch hello.c
touch Makefile
</code></pre>
<p>This will create a folder called “hello” inside the downloaded kernel source code, and create two files in it — hello.c with the syscall code and Makefile with the rules on compiling the same.</p>
<p>Open hello.c in your favourite text editor and put the following code in it</p>
<pre><code class="language-c">#include <linux/kernel.h>
#include <linux/syscalls.h>
SYSCALL_DEFINE0(hello) {
pr_info("Hello World\n");
return 0;
}
</code></pre>
<p>It prints “Hello World” in the kernel log.</p>
<blockquote>
<p>As per <a href="https://www.kernel.org/doc/html/next/process/adding-syscalls.html">kernel.org docs</a></p>
<p>"<code>SYSCALL_DEFINEn()</code> macro rather than explicitly. The ‘n’ indicates the number of arguments to the system call, and the macro takes the system call name followed by the (type, name) pairs for the parameters as arguments.”</p>
</blockquote>
<p>As we are just going to print, we use n=0</p>
<p>Now add the following to the Makefile</p>
<pre><code class="language-bash">obj-y := hello.o
</code></pre>
<p>Now</p>
<pre><code class="language-bash">cd ..
cd include/linux/
</code></pre>
<p>Open the file “syscalls.h” inside this directory, and add</p>
<pre><code>asmlinkage long sys_hello(void)
</code></pre>
<p><img alt="captionless image" src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*jE0PvQf4cseFqrzgEE0IFg.png"/></p>
<p>This is a prototype for the syscall function we created earlier.</p>
<p>Open the file “Kbuild” in the kernel root (cd ../..) and to the bottom of it add</p>
<pre><code class="language-sh">obj-y += hello/
</code></pre>
<p><img alt="captionless image" src="https://miro.medium.com/v2/resize:fit:1030/format:webp/1*JZDWzX21HZX_My3CQmrgUQ.png"/></p>
<p>This tells the kernel build system to also compile our newly included folder.</p>
<p>Once done, we then need to also add the syscall entry to the architecture-specific table.</p>
<p>Each CPU architecture could have specific syscalls and we need to let them know for which architecture ours is made.</p>
<p>For x86_64 the file is</p>
<pre><code>arch/x86/entry/syscalls/syscall_64.tbl
</code></pre>
<p>Add your syscall entry there, keeping in mind to only use a free number and not use any numbers prohibited in the table comments.</p>
<p>For me 462 was free, so I added the new entry as such</p>
<pre><code>462 common hello sys_hello
</code></pre>
<p><img alt="captionless image" src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*OPhF2lf0gLT8xEcC75QnFg.png"/></p>
<p>Here 462 is mapped to our syscall which is common for both architectures, our syscall is named hello and its entry function is sys_hello.</p>
<h2>Compiling and installing the new kernel</h2>
<p>Perform the following commands</p>
<p>NOTE: I in no way or form guarantee the safety, security, integrity and stability of your system by following this guide. All instructions listed here have been my own experience and doesn’t represent the outcome on your systems. Proceed with caution and care.</p>
<p>Now that we have the legal stuff done, let’s proceed ;)</p>
<pre><code class="language-sh">cp /boot/config-$(uname -r) .config
make olddefconfig
make -j $(nproc)
sudo make -j $(nproc) modules_install
sudo make install
</code></pre>
<p>Here we are copying the current booted kernel’s config file, asking the build system to use the same values as that and set default for anything else. Then we build the kernel with parallel processing based on the number of cores given by nproc. After which we install our custom kernel (at own risk).</p>
<p>Kernel compilation takes a lot of time, so get a coffee or 10 and enjoy lines of text scrolling by on the terminal.</p>
<p>It can take a few hours based on system speed so your mileage may vary. Your fan might also scream at this stage to keep temperatures under check (happened to me too).</p>
<h2>The fun part, using the new syscall</h2>
<p>Now that our syscall is baked into our kernel, reboot the system and make sure to select the new custom kernel from grub while booting</p>
<p><img alt="captionless image" src="https://miro.medium.com/v2/resize:fit:1400/format:webp/1*VClWIxsGL_y8wYP5cYghhg.png"/></p>
<p>Once booted, let’s write a C program to leverage the syscall</p>
<p>Create a file, maybe “test.c” with the following content</p>
<pre><code>#include <stdio.h>
#include <sys/syscall.h>
#include <unistd.h>
int main(void) {
printf("%ld\n", syscall(462));
return 0;
}
</code></pre>
<p>Here replace <strong>462</strong> with the number you chose for your syscall in the table.</p>
<p>Compile the program and then run it</p>
<pre><code>make test
chmod +x test
./test
</code></pre>
<p>If all goes right, your terminal will print a “0” and the syscall output will be visible in the kernel logs.</p>
<p>Access the logs by dmesg</p>
<pre><code>sudo dmesg | tail
</code></pre>
<p>And voila, you should be able to see your syscall message printed there.</p>
<p>Congratulations if you made it 🎉</p>
<p>Please again remember the following points:</p>
<ul>
<li>Compiling kernel takes a lot of time</li>
<li>The newly compiled kernel takes quite a bit of space so please ensure the availability</li>
<li>Linux kernel moves fast with code changes</li>
</ul></div>
</content>
<updated>2025-02-28T11:08:00Z</updated>
<published>2025-02-28T11:08:00Z</published>
<source>
<id>https://www.aryank.in/</id>
<author>
<name>Aryan Kaushik</name>
<email>aryan@aryank.in</email>
</author>
<link href="https://www.aryank.in/feed.xml" rel="self" type="application/atom+xml"/>
<link href="https://www.aryank.in/" rel="alternate" type="text/html"/>
<subtitle>Some casual blogs and some related to my GSoC journey</subtitle>
<title>Blogs by Aryan</title>
<updated>2025-02-28T11:08:00Z</updated>
</source>
</entry>
<entry xml:lang="en-us">
<id>https://aleb.ro/post/2025-02-28-fiber-optic-networks-practical-intro/</id>
<link href="https://aleb.ro/post/2025-02-28-fiber-optic-networks-practical-intro/" rel="alternate" type="text/html"/>
<title>Practical intro to fiber-optic networks</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>I was looking into how to link a remote point in my mansion to the network and checked how it could work with a fiber-optic connection, since the router had a SFP+ socket.</p>
<p>TL/DR: I’ll go with a SFP+ bidi single-mode connection.</p>
<p>First of all, stay safe. Don’t look directly into a fiber with your eye. The light/laser is not powerful, but why do it? You won’t see anything anyway, as the light is in the infrared.</p></div>
</summary>
<updated>2025-02-28T07:30:00Z</updated>
<published>2025-02-28T07:30:00Z</published>
<source>
<id>https://aleb.ro/</id>
<author>
<name>Alexandru Băluț</name>
</author>
<link href="https://aleb.ro/" rel="alternate" type="text/html"/>
<link href="https://aleb.ro/index.xml" rel="self" type="application/rss+xml"/>
<subtitle>Recent content on Notes</subtitle>
<title>Notes</title>
<updated>2025-02-28T07:30:00Z</updated>
</source>
</entry>
<entry>
<id>https://ergaster.org/posts/2025/02/28-prosthetics-that-dont-betray/</id>
<link href="https://ergaster.org/posts/2025/02/28-prosthetics-that-dont-betray/" rel="alternate" type="text/html"/>
<title>Prosthetics that don't betray</title>
<summary>Tech takes a central place in our lives. Banking, and administrative tasks are happening more and more online. It's becoming increasingly difficult to get through life without a computer or a smartphone. They have become external organs necessary to live our life. I believe computers & smartphones have become prosthetics, extensions of people that should unconditionally and entirely belong to them. We must produce devices and products the general public can trust.</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Tech takes a central place in our lives. Banking, and administrative tasks are happening more and more online. It's becoming increasingly difficult to get through life without a computer or a smartphone. They have become external organs necessary to live our life.</p>
<p>Steve Jobs called the computer <a href="https://www.goodreads.com/quotes/9281634-i-think-one-of-the-things-that-really-separates-us">the bicycle for the mind</a>. I believe computers & smartphones have become prosthetics, extensions of people that should unconditionally and entirely belong to them. We must produce devices and products the general public can trust.</p>
<p>Microsoft, Google and Apple are three American companies that build the operating systems our computers, phones, and servers run on. This American hegemony on ubiquitous devices is dangerous both for all citizens worldwide, especially under an unpredictable, authoritarian American administration.</p>
<p>Producing devices and an operating system for them is a gigantic task. Fortunately, it is not necessary to start from zero. In this post I share what I think is the best foundation for a respectful operating system and how to get it into European, and maybe American, hands. In a follow-up post I will talk more about distribution channels for older devices.</p>
<blockquote>
<p>[!warning] The rest of the world matters</p>
<p>In this post I take a European-centric view. The rest of the world matters, but I am not familiar with what their needs are nor how to address them.</p>
</blockquote>
<h2>We're building prosthetics</h2>
<p>Prosthetics are extension of ourselves as individuals. They are deeply personal. We must ensure our devices & products are:</p>
<ul>
<li><strong>Transparent</strong> about what they do. They must not betray people and do things behind their backs. Our limbs do what we tell them. When they don't, it's considered a problem and we go to a physician to fix it.</li>
<li><strong>Intuitive, documented, accessible and stable.</strong> People shouldn't have to re-learn how to do things they were used to doing. When they don't know how to do something, it must be easy for them to look it up or find someone to explain it to them. The devices must also be accessible and inclusive to reduce inequalities, instead of reinforcing them. Those requirements are a social matter, not a technical one.</li>
<li><strong>Reliable, affordable, and repairable.</strong> Computers & smartphones must not allow discrimination based on social status and wealth. Everyone must have access to devices they can count on, and be able to maintain them in a good condition. This is also a social problem and not a technical one. It is worth noting that "the apps I need must be available for my system" is an often overlooked aspect of reliability, and "I don't have to install the system because it's bundled with my machine" is an important aspect of affordability.</li>
</ul>
<p>I believe that the <a href="https://gnome.org">GNOME project</a> is one of the best placed to answer those challenges, especially when working in coordination with the excellent <a href="https://postmarketos.org/">postmarketOS</a> people who work on resurrecting older devices abandoned by their manufacturers. There is real <a href="https://www.tomshardware.com/pc-components/cpus/passmark-sees-the-first-yearly-drop-in-average-cpu-performance-in-its-20-years-of-benchmark-results">stagnation in the computing industry</a> that we must see as a social opportunity.</p>
<p/>
<h3>Constraints are good</h3>
<p>GNOME is a computing environment aiming for simplicity and efficiency. Its opinionated approach benefits both users and developers:</p>
<ul>
<li><strong>From the user perspective</strong>, apps look and feel consistent and sturdy, and are easy to use thanks to well thought out defaults.</li>
<li><strong>From the developer perspective</strong>, the opinionated <a href="https://developer.gnome.org/hig/">human interface guidelines</a> let them develop simpler, more predictable apps with less edge cases to test for.</li>
</ul>
<p>GNOME is a solid foundation to build respectful tech. It doesn't betray people by doing things behind their back. It aims for simplicity and stability, although it could use some more user research to back design decisions if there was funding to do so, like <a href="https://blogs.gnome.org/shell-dev/tag/uxd-gnome-40/">this has successfully been the case for GNOME 40</a>.</p>
<h3>Mobile matters</h3>
<p>GNOME's <a href="https://developer.gnome.org/hig/">Human Interface Guidelines</a> and <a href="https://gnome.pages.gitlab.gnome.org/libadwaita/">development tooling</a> make it easy to run GNOME apps on mobile devices. Some volunteers are also working on making GNOME Shell (the "desktop" view) render well on mobile devices.</p>
<p/>
<p>postmarketOS already <a href="https://wiki.postmarketos.org/wiki/GNOME">offers it as one of the UIs</a> you can install on your phone. With mobile <a href="https://en.wikipedia.org/wiki/Usage_share_of_operating_systems">taking over</a> traditional computers usage, it is critical to consider the mobile side of computing too.</p>
<h3>Hackability and safety</h3>
<p>As an open source project, GNOME remains customizable by advanced users who know they are bringing unsupported changes, can break their system in the process, and deal with it. It doesn't make customization easy for those advanced users, because it doesn't optimize for them.</p>
<p>The project also has its fair share of criticism, some valid, and some not. I agree that sometimes the project can be too opinionated and rigid, optimizing for extreme consistency at the expense of user experience. For example, while I agree that system trays are suboptimal, they're also a pattern people have been used to it for decades and removing them is very frustrating for many.</p>
<p>But some criticism is also coming from people who want to tinker with their system and spend countless hours building a system that's the exact fit for their needs. Those are valid use cases, but GNOME is <em>not</em> built to serve them. GNOME aims to be easy to use for the general public, which includes people who are not tech-experts and don't want to be.</p>
<h2>We're actually building prototypes</h2>
<p>As mighty as the GNOME volunteers might be, there is still a long way before the general public can realistically use it. GNOME needs to become a fully fledged product shipped on mainstream devices, rather than an alternative system people install. It also needs to involve representatives of the people it intends to serve.</p>
<h3>You just need to simply be tech-savvy</h3>
<p><strong>GNOME is not (yet) an end user product</strong>. It is a desktop environment that needs to be shipped as part of a Linux distribution. There are many distributions to chose from. They are not shipping the same version of GNOME, and some patch it more or less heavily. This kind of fragmentation is one of the main factors holding the Linux desktop back.</p>
<p/>
<p>The general public doesn't want to have to pick a distribution and bump into every edge cases that creates. They need a system that works predictably, that lets them install the apps they need, and that gives them <em>safe</em> ways to customize it as a user.</p>
<p>That means they need a system that doesn't let them shoot themselves in the foot in the name of customizability, and that prevents them from doing some things unless they sign with their blood that they know it could make it unusable. I share Adrian Vovk's vision for <a href="https://blogs.gnome.org/adrianvovk/2024/10/25/a-desktop-for-all/">A Desktop for All</a> and I think it's the best way to productize GNOME and make it usable by the general public.</p>
<p><strong>People don't want to have to install an "alternative" system</strong>. They want to buy a computer or a smartphone and <em>use</em> it. For GNOME to become ubiquitous, it needs to be shipped on devices people can buy.</p>
<p>For GNOME to really take off, it needs to become a system people can use both in their personal life and at work. It must become a compelling product in entreprise deployments, both to route enough money towards development and maintenance, to make it an attractive platform for vendors to build software for, and to make it an attractive platform for devices manufacturers to ship.</p>
<h3>What about the non tech-savvy?</h3>
<p>GNOME aims to build a computing platform <em>everyone</em> can trust. <strong>But it doesn't have a clear, scalable governance model with representatives of those it serves.</strong> GNOME has rudimentary governance to define what is part of the project and what is not thanks to its Release Team, but it is largely a <a href="https://en.wiktionary.org/wiki/do-ocracy">do-ocracy</a> as highlighted in the <a href="https://handbook.gnome.org/governance.html">Governance page</a> of GNOME's Handbook as well was in GNOME Designer Tobias Bernard's series <a href="https://blogs.gnome.org/tbernard/2021/06/23/community-power-3/">Community Power</a>.</p>
<p>A do-ocracy is a very efficient way to onboard volunteers and empower people who can give away their free time to get things done fast. It is however not a great way to get work done on areas that matter to a minority who can't afford to give away free time or pay someone to work on it.</p>
<p>The GNOME Foundation is indeed <em>not</em> GNOME's vendor today, and it doesn't contribute the bulk of the design and code of the project. It maintains the infrastructure (technical and organizational) the project builds on. A critical, yet little visible task.</p>
<p/>
<p>To be a meaningful, fair, inclusive project for more than engineers with spare time and spare computers, the project needs to improve in two areas:</p>
<ol>
<li><strong>It needs a Product Committee to set a clear product direction</strong> so GNOME can meaningfully address the problems of its intended audience. The product needs a clear purpose, a clear audience, and a robust governance to enforce decisions. It needs a committee with representatives of the people it intends to serve, designers, and solution architects. Of course it also critically needs a healthy set of public and private organizations funding it.</li>
<li><strong>It needs a Development Team to implement the direction</strong> the committee has set. This means doing user research and design, technical design, implementing the software, doing advocacy work to promote the project to policymakers, manufacturers, private organizations' IT department and much more.</li>
</ol>
<blockquote>
<p>[!warning] Bikeshedding is a real risk</p>
<p>A Product Committee can be a useful structure for people to express their needs, draft a high-level and realistic solution with designers and solution architects, and test it. Designers and technical architects must remain in charge of designing and implementing the solution.</p>
</blockquote>
<p>The GNOME Foundation appears as a natural host for these organs, especially since it's already taking care of the assets of the project like its infrastructure and trademark. A separate organization could more easily pull the project in a direction that serves its own interests.</p>
<p>Additionally, the GNOME Foundation taking on this kind of work doesn't conflict with the present do-ocracy, since volunteers and organizations could still work on what matters to them. But it would remain a major shift in the project's organization and would likely upset some volunteers who would feel that they have less control over the project.</p>
<p>I believe this is a necessary step to make the public and private sector invest in the project, generate stable employment for people working on it, and ultimately make GNOME have a systemic, positive impact on society.</p>
<blockquote>
<p>[!warning] GNOME needs solution architects</p>
<p>The GNOME community has designers who have a good product vision. It is also full of experts on their module, but has a shortage of people with a good technical overview of the project, who can turn product issues into technical ones at the scale of the whole project.</p>
</blockquote>
<h2>So what now?</h2>
<p>"The year of the Linux desktop" has become a meme now for a reason. The Linux community, if such a nebulous thing exists, is very good at solving technical problems. But building a project bigger than ourselves and putting it in the hands of the millions of people who need it is not <em>just</em> a technical problem.</p>
<p>Here are some critical next steps for the GNOME Community and Foundation to reclaim personal computing from the trifecta of tech behemoths, and fulfill an increasingly important need for democracies.</p>
<h3>Learn from experience</h3>
<p>Last year, a team of volunteers led by Sonny Piers and Tobias Bernard wrote a grant bid for the Sovereign Tech Fund, and got granted €1M. There are some major takeaways from this adventure.</p>
<p>At risk of stating the obvious, <strong>money <em>does</em> solve problems!</strong> The team tackled significant technical issues not just for GNOME but for the free desktop in general. I urge organizations and governments that take their digital independence seriously to contribute <em>meaningfully</em> to the project.</p>
<p>Finally and unsurprisingly, <strong>one-offs are not sustainable</strong>. The Foundation needs to build sustainable revenue streams from a diverse portfolio to grow its team. A €1M grant is extremely generous from a single organization. It was a massive effort from the Sovereign Tech Agency, and a significant part of their 2024 budget. But it is also far from enough to sustain a project like GNOME if every volunteer was paid, let alone paid a fair wage.</p>
<h3>Tread carefully, change democratically</h3>
<p>Governance and funding are a chicken and egg problem. <strong>Funders won't send money to the project if they are not confident that the project will use it wisely, and if they can't weigh in on the project's direction.</strong> Without money to support the effort, only volunteers can set up the technical governance processes on their spare time.</p>
<p>Governance changes must be done carefully though. <strong>Breaking the status quo without a plan comes with significant risks.</strong> It can demotivate current volunteers, make the project lose tractions for newcomers, and die before enough funding makes it to the project to sustain it. <em>A lot</em> of people have invested significant amounts of time and effort into GNOME, and this must be treated with respect.</p>
<h3>Build a focused MVP</h3>
<p>For the STF project, the GNOME Foundation relied on contractors and consultancies. To be fully operational and efficient it must get in a position of hiring people with the most critical skills. I believe right now the most critical profile is the solution architect one. With more revenue, developers and designers can join the team as it grows.</p>
<p>But for that to happen, the Foundation needs to:</p>
<ol>
<li>Define who GNOME is for in priority, bearing in mind that "everyone" doesn't exist.</li>
<li>Build a team of representatives of that audience, and a product roadmap: what problems do these people have that GNOME could solve, how could GNOME solve it for them, how could people get to using GNOME, and what tradeoffs would they have to make when using GNOME.</li>
<li>Build the technical roadmap (the steps to make it happen).</li>
<li>Fundraise to implement the roadmap, factoring in the roadmap creation costs.</li>
<li>Implement, and test</li>
</ol>
<p>The Foundation can then build on this success and start engaging with policymakers, manufacturers, vendors to extent its reach.</p>
<h2>Alternative proposals</h2>
<p>The model proposed has a significant benefit: it gives clarity. You can give money to the GNOME Foundation to contribute to the maintenance and evolution of GNOME project, instead of only supporting its infrastructure costs. It unlocks the possibility to fund user research that would also benefit all the downstreams.</p>
<p>It is possible to take the counter-point and argue that GNOME doesn't have to be an end-user product, but should remain an upstream that several organizations use for their own product and contribute to.</p>
<p>The "upstream only" model is status-quo, and the main advantage of this model is that it lets contributing organizations focus on what they need the most. The GNOME Foundation would need to scale down to a minimum to only support the shared assets and infrastructure of the project and minimize its expenses. Another (public?) organization would need to tackle the problem of making GNOME a well integrated end-user product.</p>
<p>In the "upstream only" model, there are two choices:</p>
<ul>
<li><strong>Either the governance of GNOME itself remains the same</strong>, a do-ocracy where whoever has the skills, knowledge and financial power to do so can influence the project.</li>
<li><strong>Or the Community can introduce a more formal governance model</strong> to define what is part of GNOME and what is not, like <a href="https://peps.python.org/">Python PEPs</a> and <a href="https://rust-lang.github.io/rfcs/">Rust's RFCs</a>.</li>
</ul>
<h2>It's an investment</h2>
<p>Building an operating system usable by the masses is a significant effort and requires a lot of expertise. It is tempting to think that since Microsoft, Google and Apple are already shipping several operating systems each, that we don't need one more.</p>
<p>However, let's remember that these are all American companies, building proprietary ecosystems that they have complete control over. In these uncertain times, Europe must not treat the USA as a direct enemy, but the current administration makes it clear that it would be reckless to continue treating it as an ally.</p>
<p>Building an international, transparent operating system that provides an open platform for people to use and for which developers can distribute apps will help secure EU's digital sovereignty and security, at a cost that wouldn't even make a dent in the budget. It's time for policymakers to take their responsibilities and not let America control the digital public space.</p></div>
</content>
<updated>2025-02-28T07:00:00Z</updated>
<published>2025-02-28T07:00:00Z</published>
<source>
<id>https://ergaster.org/</id>
<author>
<name>Thibault Martin</name>
</author>
<link href="https://ergaster.org/" rel="alternate" type="text/html"/>
<link href="https://ergaster.org/rss.xml" rel="self" type="application/rss+xml"/>
<subtitle>On digital citizenship</subtitle>
<title>Thib's Blog</title>
<updated>2025-04-02T07:03:55Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://feborg.es/?p=10826</id>
<link href="https://feborg.es/gnome-is-participating-in-google-summer-of-code-2025/" rel="alternate" type="text/html"/>
<title>GNOME is participating in Google Summer of Code 2025!</title>
<summary>The Google Summer of Code 2025 mentoring organizations have just been announced and we are happy that GNOME’s participation has been accepted! If you are interested in having a internship with GNOME, check gsoc.gnome.org for our project ideas and getting started information.</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>The Google Summer of Code 2025 mentoring organizations have just been announced and we are happy that GNOME’s participation has been accepted!</p>
<p>If you are interested in having a internship with GNOME, check <a href="https://gsoc.gnome.org">gsoc.gnome.org</a> for our project ideas and getting started information.</p></div>
</content>
<updated>2025-02-27T18:42:02Z</updated>
<published>2025-02-27T18:42:02Z</published>
<category term="gnome"/>
<category term="GSoC"/>
<category term="gsoc"/>
<author>
<name>Felipe Borges</name>
</author>
<source>
<id>https://feborg.es</id>
<logo>https://feborg.es/files/2023/12/cropped-avatar-32x32.jpg</logo>
<link href="https://feborg.es/feed/" rel="self" type="application/rss+xml"/>
<link href="https://feborg.es" rel="alternate" type="text/html"/>
<subtitle>Felipe Borges' blog about GNOME</subtitle>
<title>Felipe Borges</title>
<updated>2025-03-17T15:53:00Z</updated>
</source>
</entry>
<entry>
<id>tag:blogger.com,1999:blog-5968355124473522212.post-8623006907084314928</id>
<link href="https://nibblestew.blogspot.com/feeds/8623006907084314928/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
<link href="https://nibblestew.blogspot.com/2025/02/the-price-of-statelessness-is-eternal.html#comment-form" rel="replies" title="2 Comments" type="text/html"/>
<link href="https://www.blogger.com/feeds/5968355124473522212/posts/default/8623006907084314928" rel="edit" type="application/atom+xml"/>
<link href="https://www.blogger.com/feeds/5968355124473522212/posts/default/8623006907084314928" rel="self" type="application/atom+xml"/>
<link href="https://nibblestew.blogspot.com/2025/02/the-price-of-statelessness-is-eternal.html" rel="alternate" title="The price of statelessness is eternal waiting" type="text/html"/>
<title>The price of statelessness is eternal waiting</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p style="text-align: left;">Most CI systems I have seen have been stateless. That is, they start by getting a fresh Docker container (or building one from scratch), doing a Git checkout, building the thing and then throwing everything away. This is simple and matematically pure, but really slow. This approach is further driven by the way how in cloud computing CPU time and network transfers are cheap but storage is expensive (or at least it is possible to get almost infinite CI build time for open source projects but not persistent storage). Probably because the cloud vendor needs to take care of things like backups, they can't dispatch the task on any machine on the planet but instead on the one that already has the required state and so on.</p><p style="text-align: left;">How much could you reduce resource usage (or, if you prefer, improve CI build speed) by giving up on statelessness? Let's find out by running some tests. To get a reasonably large code base I used LLVM. I did not actually use any cloud or Docker in the tests, but I simulated them on a local media PC. I used 16 cores to compile and 4 to link (any more would saturate the disk). Tests were not run.</p><h1 style="text-align: left;">Baseline</h1><p>Creating a Docker container with all the build deps takes a few minutes. Alternatively you can prebuild it, but then you need to download a 1 GB image.</p><p>Doing a full Git checkout would be wasteful. There are basically three different ways of doing a partial checkout: shallow clone, blobless and treeless. They take the following amount of time and space:</p><p/><ul style="text-align: left;"><li>shallow: 1m, 259 MB</li><li>blobless: 2m 20s, 961 MB</li><li>treeless: 1m 46s, 473 MB</li></ul>Doing a full build from scratch takes 42 minutes.<br/><h1 style="text-align: left;">With CCache</h1><p style="text-align: left;">Using CCache in Docker is mostly a question of bind mounting a persistent directory in the container's cache directory. A from-scratch build with an up to date CCache takes 9m 30s.</p><h1 style="text-align: left;">With stashed Git repo</h1><p style="text-align: left;">Just like the CCache dir, the Git checkout can also be persisted outside the container. Doing a git pull on an existing full checkout takes only a few seconds. You can even mount the repo dir read only to ensure that no state leaks from one build invocation to another.</p><h1 style="text-align: left;">With Danger Zone</h1><p style="text-align: left;">One main thing a CI build ensures is that the code keeps on building when compiled from scratch. It is quite possible to have a bug in your build setup that manifests itself so that the build succeeds if a build directory has already been set up, but fails if you try to set it up from scratch. This was especially common back in ye olden times when people used to both write Makefiles by hand and to think that doing so was a good idea.</p><p style="text-align: left;">Nowadays build systems are much more reliable and this is not such a common issue (though it can definitely still occur). So what if you would be willing to give up full from-scratch checks on merge requests? You could, for example, still have a daily build that validates that use case. For some organizations this would not be acceptable, but for others it might be reasonable tradeoff. After all, why should a CI build take noticeably longer than an incremental build on the developer's own machine. If anything it should be faster, since servers are a lot beefier than developer laptops. So let's try it.</p><p style="text-align: left;">The implementation for this is the same as for CCache, you just persist the build directory as well. To run the build you do a Git update, mount the repo, build dir and optionally CCache dirs to the container and go.</p><p style="text-align: left;">I tested this by doing a git pull on the repo and then doing a rebuild. There were a couple of new commits, so this should be representative of the real world workloads. An incremental build took 8m 30s whereas a from scratch rebuild using a fully up to date cache took 10m 30s.</p><h1 style="text-align: left;">Conclusions</h1><p style="text-align: left;">The amount of wall clock time used for the three main approaches were:</p><p style="text-align: left;"/><ul style="text-align: left;"><li>Fully stateless</li><ul><li>Image building: 2m</li><li>Git checkout: 1m</li><li>Build: 42m</li><li><b>Total</b>: 45m</li></ul><li>Cached from-scratch</li><ul><li>Image building: 0m (assuming it is not "apt-get update"d for every build)</li><li>Git checkout: 0m</li><li>Build: 10m 30s</li><li><b>Total</b>: 10m 30s</li></ul><li>Fully cached</li><ul><li>Image building: 0m</li><li>Git checkout: 0m</li><li>Build: 8m 30s</li><li><b>Total</b>: 8m 30s</li></ul></ul>Similarly the amount of data transferred was:<p/><p style="text-align: left;"/><ul style="text-align: left;"><li>Fully stateless</li><ul><li>Image: 1G</li><li>Checkout: 300 MB</li></ul><li>Cached from-scratch:</li><ul><li>Image: 0</li><li>Checkout: O(changes since last pull), typically a few kB</li></ul><li>Fully cached</li><ul><li>Image: 0</li><li>Checkout: O(changes since last pull)</li></ul></ul>The differences are quite clear. Just by using CCache the build time drops by almost 80%. Persisting the build dir reduces the time by a further 15%. It turns out that having machines dedicated to a specific task can be a lot more efficient than rebuilding the universe from atoms every time. Fancy that.<p/><p style="text-align: left;">The final 2 minute improvement might not seem like that much, but on the other hand do you really want your developers to spend 2 minutes twiddling their thumbs for every merge request they create <i>or</i> update? I sure don't. Waiting for CI to finish is one of the most annoying things in software development.</p><p/></div>
</content>
<updated>2025-02-27T16:55:00Z</updated>
<published>2025-02-27T16:55:00Z</published>
<author>
<name>Jussi</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/03370287682352908292</uri>
</author>
<source>
<id>tag:blogger.com,1999:blog-5968355124473522212</id>
<author>
<name>Jussi</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/03370287682352908292</uri>
</author>
<link href="https://nibblestew.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
<link href="https://www.blogger.com/feeds/5968355124473522212/posts/default" rel="self" type="application/atom+xml"/>
<link href="https://nibblestew.blogspot.com/" rel="alternate" type="text/html"/>
<link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
<link href="https://www.blogger.com/feeds/5968355124473522212/posts/default?start-index=26&max-results=25" rel="next" type="application/atom+xml"/>
<subtitle>A gathering of development thoughts of Jussi Pakkanen. Some of you may know him as the creator of the Meson build system. jpakkane at gmail dot com</subtitle>
<title>Nibble Stew</title>
<updated>2025-03-25T02:51:35Z</updated>
</source>
</entry>
<entry xml:lang="en-us">
<id>https://k-d-w.org/blog/2025/02/scikit-survival-0.24.0-released/</id>
<link href="https://k-d-w.org/blog/2025/02/scikit-survival-0.24.0-released/" rel="alternate" type="text/html"/>
<title>scikit-survival 0.24.0 released</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>It’s my pleasure to announce the release of <a href="https://scikit-survival.readthedocs.io/" target="_blank">scikit-survival</a> 0.24.0.</p>
<p>A highlight of this release the addition of
<a href="https://scikit-survival.readthedocs.io/en/v0.24.0/api/generated/sksurv.nonparametric.cumulative_incidence_competing_risks.html#sksurv.nonparametric.cumulative_incidence_competing_risks" target="_blank">cumulative_incidence_competing_risks()</a>
which implements a non-parameteric estimator of the cumulative incidence function in the presence of competing risks.
In addition, the release adds support for scikit-learn 1.6, including the support for missing values for
<a href="https://scikit-survival.readthedocs.io/en/v0.24.0/api/generated/sksurv.ensemble.ExtraSurvivalTrees.html#sksurv.ensemble.ExtraSurvivalTrees" target="_blank">ExtraSurvivalTrees</a>.</p>
<h2 id="analysis-of-competing-risks">Analysis of Competing Risks</h2>
<p>In classical survival analysis, the focus is on the time until a specific event occurs. If no event is observed during the study period, the time of the event is considered censored. A common assumption is that censoring is non-informative, meaning that censored subjects have a similar prognosis to those who were not censored.</p>
<p>Competing risks arise when each subject can experience an event due to one of $K$ ($K \geq 2$) mutually exclusive causes, termed competing risks. Thus, the occurrence of one event prevents the occurrence of other events. For example, after a bone marrow transplant, a patient might relapse or die from transplant-related causes (transplant-related mortality). In this case, death from transplant-related mortality precludes relapse.</p>
<p>The bone marrow transplant data from <a href="https://doi.org/10.1038/sj.bmt.1705727" target="_blank">Scrucca et al., Bone Marrow Transplantation (2007)</a> includes data
from 35 patients grouped into two cancer types: Acute Lymphoblastic Leukemia (ALL; coded as 0), and Acute Myeloid Leukemia (AML; coded as 1).</p>
<pre><code class="language-python">from sksurv.datasets import load_bmt
bmt_features, bmt_outcome = load_bmt()
diseases = bmt_features["dis"].cat.rename_categories(
{"0": "ALL", "1": "AML"}
)
diseases.value_counts().to_frame()
</code></pre>
<div class="table-responsive">
<table class="dataframe" style="width: 20%;">
<thead>
<tr>
<th>dis</th>
<th>count</th>
</tr>
</thead>
<tbody>
<tr style="text-align: right;">
<th>AML</th>
<td>18</td>
</tr>
<tr style="text-align: right;">
<th>ALL</th>
<td>17</td>
</tr>
</tbody>
</table>
</div>
<p>During the follow-up period, some patients might experience a relapse of the original leukemia or die
while in remission (transplant related death).
The outcome is defined similarly to standard time-to-event data, except that the event indicator specifies the type of event, where 0 always indicates censoring.</p>
<pre><code class="language-python">import pandas as pd
status_labels = {
0: "Censored",
1: "Transplant related mortality",
2: "Relapse",
}
risks = pd.DataFrame.from_records(bmt_outcome).assign(
label=lambda x: x["status"].replace(status_labels)
)
risks["label"].value_counts().to_frame()
</code></pre>
<div class="table-responsive">
<table class="dataframe" style="width: 40%;">
<thead>
<tr>
<th>label</th>
<th>count</th>
</tr>
</thead>
<tbody>
<tr style="text-align: right;">
<th>Relapse</th>
<td>15</td>
</tr>
<tr style="text-align: right;">
<th>Censored</th>
<td>11</td>
</tr>
<tr style="text-align: right;">
<th>Transplant related mortality</th>
<td>9</td>
</tr>
</tbody>
</table>
</div>
<p>The table above shows the number of observations for each status.</p>
<h3 id="non-parametric-estimator-of-the-cumulative-incidence-function">Non-parametric Estimator of the Cumulative Incidence Function</h3>
<p>If the goal is to estimate the probability of relapse, transplant-related death is a competing risk event. This means that the occurrence of relapse prevents the occurrence of transplant-related death, and vice versa. We aim to estimate curves that illustrate how the likelihood of these events changes over time.</p>
<p>Let’s begin by estimating the probability of relapse using the complement of the Kaplan-Meier estimator. With this approach, we treat deaths as censored observations. One minus the Kaplan-Meier estimator provides an estimate of the probability of relapse before time $t$.</p>
<pre><code class="language-python">import matplotlib.pyplot as plt
from sksurv.nonparametric import kaplan_meier_estimator
times, km_estimate = kaplan_meier_estimator(
bmt_outcome["status"] == 1, bmt_outcome["ftime"]
)
plt.step(times, 1 - km_estimate, where="post")
plt.xlabel("time $t$")
plt.ylabel("Probability of relapsing before time $t$")
plt.ylim(0, 1)
plt.grid()
</code></pre>
<figure>
<img src="https://k-d-w.org/blog/2025/02/scikit-survival-0.24.0-released/img/bmt-kaplan-meier.svg" width="400"/>
</figure>
<p>However, this approach has a significant drawback: considering death as a censoring event violates the assumption that censoring is non-informative. This is because patients who died from transplant-related mortality have a different prognosis than patients who did not experience any event. Therefore, the estimated probability of relapse is often biased.</p>
<p>The cause-specific <strong>cumulative incidence function (CIF)</strong> addresses this problem by estimating the cause-specific hazard of each event separately. The cumulative incidence function estimates the probability that the event of interest occurs before time $t$, and that it occurs before any of the competing causes of an event. In the bone marrow transplant dataset, the cumulative incidence function of relapse indicates the probability of relapse before time $t$, given that the patient has not died from other causes before time $t$.</p>
<pre><code class="language-python">from sksurv.nonparametric import cumulative_incidence_competing_risks
times, cif_estimates = cumulative_incidence_competing_risks(
bmt_outcome["status"], bmt_outcome["ftime"]
)
plt.step(times, cif_estimates[0], where="post", label="Total risk")
for i, cif in enumerate(cif_estimates[1:], start=1):
plt.step(times, cif, where="post", label=status_labels[i])
plt.legend()
plt.xlabel("time $t$")
plt.ylabel("Probability of event before time $t$")
plt.ylim(0, 1)
plt.grid()
</code></pre>
<figure>
<img src="https://k-d-w.org/blog/2025/02/scikit-survival-0.24.0-released/img/bmt-cumulative-incidence.svg" width="400"/>
</figure>
<p>The plot shows the estimated probability of experiencing an event at time $t$ for both the individual risks and for the total risk.</p>
<p>Next, we want to to estimate the cumulative incidence curves for the two cancer types — acute lymphoblastic leukemia (ALL) and acute myeloid leukemia (AML) — to examine how the probability of relapse depends on the original disease diagnosis.</p>
<pre><code class="language-python">_, axs = plt.subplots(2, 2, figsize=(7, 6), sharex=True, sharey=True)
for j, disease in enumerate(diseases.unique()):
mask = diseases == disease
event = bmt_outcome["status"][mask]
time = bmt_outcome["ftime"][mask]
times, cif_estimates, conf_int = cumulative_incidence_competing_risks(
event,
time,
conf_type="log-log",
)
for i, (cif, ci, ax) in enumerate(
zip(cif_estimates[1:], conf_int[1:], axs[:, j]), start=1
):
ax.step(times, cif, where="post")
ax.fill_between(times, ci[0], ci[1], alpha=0.25, step="post")
ax.set_title(f"{disease}: {status_labels[i]}", size="small")
ax.grid()
for ax in axs[-1, :]:
ax.set_xlabel("time $t$")
for ax in axs[:, 0]:
ax.set_ylim(0, 1)
ax.set_ylabel("Probability of event before time $t$")
</code></pre>
<figure>
<img src="https://k-d-w.org/blog/2025/02/scikit-survival-0.24.0-released/img/bmt-cumulative-incidence-by-diagnosis.svg" width="450"/>
</figure>
<p>The left column shows the estimated cumulative incidence curves (solid lines) for patients diagnosed with ALL, while the right column shows the curves for patients diagnosed with AML, along with their 95% pointwise confidence intervals. The plot indicates that the estimated probability of relapse at $t=40$ days is more than three times higher for patients diagnosed with ALL compared to AML.</p>
<p>If you want to run the examples above yourself, you can
<a href="https://mybinder.org/v2/gh/sebp/scikit-survival/master?urlpath=lab/tree/notebooks/competing-risks.ipynb" target="_blank">execute them interactively in your browser using binder</a>.</p></div>
</summary>
<updated>2025-02-26T21:26:45Z</updated>
<published>2025-02-26T21:26:45Z</published>
<source>
<id>https://k-d-w.org/post/</id>
<logo>https://k-d-w.org/img/icon-192.png</logo>
<author>
<name>Sebastian Pölsterl</name>
</author>
<link href="https://k-d-w.org/post/" rel="alternate" type="text/html"/>
<link href="https://k-d-w.org/post/index.xml" rel="self" type="application/rss+xml"/>
<rights>© Sebastian Pölsterl 2025</rights>
<subtitle>Posts</subtitle>
<title>Posts | Sebastian Pölsterl</title>
<updated>2025-02-26T21:26:45Z</updated>
</source>
</entry>
<entry>
<id>https://www.aryank.in/posts/2025-02-25-gnome-gsoc-2025/</id>
<link href="https://www.aryank.in/posts/2025-02-25-gnome-gsoc-2025/" rel="alternate" type="text/html"/>
<title>GNOME in GSoC 2025</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Hi Everyone!</p>
<p><a href="https://summerofcode.withgoogle.com/programs/2025-ao">Google Summer of Code 2025</a> is here! Interested in being a part of it? Read on!</p>
<p>GNOME Foundation has been a part of Google Summer of Code for almost every iteration, and we have applied for this year as well, and are waiting for it's confirmation!</p>
<p>Our tentative projects list is now available at <a href="https://gsoc.gnome.org/2025/">GNOME GSoC Website</a></p>
<p>To make it easier for newcomers, we’ve built resources to help navigate both GSoC and the GNOME ecosystem:</p>
<ul>
<li>📖 <a href="https://gsoc.gnome.org/">GSoC Welcome Guide</a></li>
<li>📖 <a href="https://welcome.gnome.org/">Newcomers Guide</a></li>
<li>💬 Newcomers Chat - <a href="https://matrix.to/#/#newcomers:gnome.org">#newcomers:gnome.org</a></li>
<li>💬 Internship Chat - <a href="https://matrix.to/#/#internship:gnome.org">#internship:gnome.org</a></li>
</ul>
<p>You can also watch the awesome video on GNOME's impact and history on YouTube - <a href="https://www.youtube.com/watch?v=bWUmptI6O2w">GUADEC 2017 - Jonathan Blandford - The History of GNOME</a></p>
<p>From my experience, GNOME has been an incredible community filled with inspiring people. If you're looking to make an impact with one of the largest, oldest and most influential free software communities, I’d highly recommend giving GNOME a try.</p>
<p>You might just find a second home here while honing your skills alongside some of the best engineers around.</p>
<p>GNOME was my intro into the larger FOSS community when I became a GSoC 2022 Intern there, and has helped me on countless occasions, and I hope it will be the same for you!</p>
<p>If you have been a part of GNOME and want to contribute as a mentor, then let us know as well, GNOME can always utilise some great mentors!</p>
<p>For any questions, feel free to join the chat :D</p>
<p>Also, you can check out my previous post on the GSoC process for more insights on <a href="https://www.linkedin.com/posts/aryan-kaushik23_gsoc-googlesummerofcode-gsoc2023-activity-7121535240321347584-N8ra/">LinkedIn</a></p>
<p>Looking forward to seeing you in GSoC 2025!</p></div>
</content>
<updated>2025-02-25T14:48:00Z</updated>
<published>2025-02-25T14:48:00Z</published>
<source>
<id>https://www.aryank.in/</id>
<author>
<name>Aryan Kaushik</name>
<email>aryan@aryank.in</email>
</author>
<link href="https://www.aryank.in/feed.xml" rel="self" type="application/atom+xml"/>
<link href="https://www.aryank.in/" rel="alternate" type="text/html"/>
<subtitle>Some casual blogs and some related to my GSoC journey</subtitle>
<title>Blogs by Aryan</title>
<updated>2025-02-28T11:08:00Z</updated>
</source>
</entry>
<entry>
<id>https://hansdegoede.dreamwidth.org/29477.html</id>
<link href="https://hansdegoede.dreamwidth.org/29477.html" rel="alternate" type="text/html"/>
<title>ThinkPad X1 Carbon Gen 12 camera support and other IPU6 camera work</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">I have been working on getting the camera on the ThinkPad X1 Carbon Gen 12 to work under Fedora.<br/><br/>This requires 3 things:<br/><br/><ol><li>Some ov08x40 sensor patches, these are available as downstream cherry-picks in Fedora kernels >= 6.12.13</li><li>A small pipewire fix to avoid WirePlumber listing a bunch of bogus extra "ipu6" Video Sources, these fixes are available in Fedora's pipewire packages >= 1.2.7-4</li><li>I2C and GPIO drivers for the new Lattice USB IO-expander, these drivers are not available in the upstream / mainline kernel yet</li></ol><br/>I have also rebased the out of tree IPU6 ISP and proprietary userspace stack in rpmfusion and I have integrated the USBIO drivers into the intel-ipu6-kmod package. So for now getting the cameras to work on the X1 Carbon Gen 12 requires installing the out of tree drivers through rpmfusion. Follow <a href="https://rpmfusion.org/Configuration">these instructions</a> to enable rpmfusion, you need both the free and nonfree repos.<br/><br/>Then make sure you have a new enough kernel installed and install the rpmfusion akmod for the USBIO drivers:<br/><br/>sudo dnf update 'kernel*'<br/>sudo dnf install akmod-intel-ipu6<br/><br/>The latest version of the out of tree IPU6 ISP driver can co-exist with the mainline / upstream IPU6 CSI receiver kernel driver. So both the libcamera software ISP FOSS stack and Intel's proprietary stack can co-exist now. If you do not want to use the proprietary stack you can disable it by running 'sudo ipu6-driver-select foss'.<br/><br/>After installing the kmod package reboot and then in Firefox go to <a href="https://mozilla.github.io/webrtc-landing/gum_test.html">Mozilla's webrtc test page</a> and click on the "Camera" button, you should now get a camera permisson dialog with 2 cameras: "Built in Front Camera" and "Intel MIPI Camera (V4L2)" the "Built in Front Camera" is the FOSS stack and the "Intel MIPI Camera (V4L2)" is the proprietary stack. Note the FOSS stack will show a strongly zoomed in (cropped) image, this is caused by the GUM test-page, in e.g. google-meet this will not be the case.<br/><br/>I have also been making progress with some of the other open IPU6 issues:<br/><br/><ul><li>Camera's failing on Dell XPS laptops due to iVSC errors (<a href="https://bugzilla.redhat.com/show_bug.cgi?id=2316918">rhbz#2316918</a>, <a href="https://bugzilla.redhat.com/show_bug.cgi?id=2324683">rhbz#2324683</a>) after a long debugging session this is finally fixed, the fix for this will be available in Fedora kernels >= 6.13.4 which should show up in updates-testing today</li><li>Camera's no working on <a href="https://bugzilla.redhat.com/show_bug.cgi?id=2341732">Microsoft Surface book with ov7251 sensor</a>, the fix for this has <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/intel?id=569617dbbd06286fb73f3f1c2ac91e51d863c7de">landed upstream</a><br/> </li></ul><br/><br/><br/><img alt="comment count unavailable" height="12" src="https://www.dreamwidth.org/tools/commentcount?user=hansdegoede&ditemid=29477" style="vertical-align: middle;" width="30"/> comments</div>
</summary>
<updated>2025-02-24T14:42:04Z</updated>
<published>2025-02-24T14:42:04Z</published>
<category term="kernel"/>
<category term="fedora"/>
<category term="ipu6"/>
<source>
<id>https://hansdegoede.dreamwidth.org/</id>
<logo>https://v2.dreamwidth.org/16479769/3892031</logo>
<author>
<name>Hans de Goede</name>
</author>
<link href="https://hansdegoede.dreamwidth.org/" rel="alternate" type="text/html"/>
<link href="https://hansdegoede.dreamwidth.org/data/rss" rel="self" type="application/rss+xml"/>
<subtitle>Hans de Goede - Dreamwidth Studios</subtitle>
<title>Hans de Goede</title>
<updated>2025-02-24T14:42:04Z</updated>
</source>
</entry>
<entry>
<id>tag:blogger.com,1999:blog-6112936277054198647.post-4691799641317172037</id>
<link href="http://who-t.blogspot.com/feeds/4691799641317172037/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
<link href="http://www.blogger.com/comment/fullpage/post/6112936277054198647/4691799641317172037" rel="replies" title="1 Comments" type="text/html"/>
<link href="http://www.blogger.com/feeds/6112936277054198647/posts/default/4691799641317172037" rel="edit" type="application/atom+xml"/>
<link href="http://www.blogger.com/feeds/6112936277054198647/posts/default/4691799641317172037" rel="self" type="application/atom+xml"/>
<link href="http://who-t.blogspot.com/2025/02/libinput-and-3-finger-dragging.html" rel="alternate" title="libinput and 3-finger dragging" type="text/html"/>
<title>libinput and 3-finger dragging</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>
Ready in time for libinput 1.28 [1] and after a number of attempts over the years we now finally have 3-finger dragging in libinput. This is a long-requested feature that allows users to drag by using a 3-finger swipe on the touchpad. Instead of the normal swipe gesture you simply get a button down, pointer motion, button up sequence. Without having to tap or physically click and hold a button, so you might be able to see the appeal right there.
</p>
<p>
Now, as with any interaction that relies on the mere handful of fingers that are on our average user's hand, we are starting to have usage overlaps. Since the only difference between a swipe gesture and a 3-finger drag is in the intention of the user (and we can't detect that yet, stay tuned), 3-finger swipes are disabled when 3-finger dragging is enabled. Otherwise it does fit in quite nicely with the rest of the features we have though.
</p>
<p>
There really isn't much more to say about the new feature except:
It's configurable to work on 4-finger drag too so if you mentally substitute all the threes with fours in this article before re-reading it that would save me having to write another blog post. Thanks.
</p>
<p>
<small>
[1] "soonish" at the time of writing<br/>
</small>
</p></div>
</content>
<updated>2025-02-24T05:38:00Z</updated>
<published>2025-02-24T05:38:00Z</published>
<category scheme="http://www.blogger.com/atom/ns#" term="libinput"/>
<author>
<name>Peter Hutterer</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/17204066043271384535</uri>
</author>
<source>
<id>tag:blogger.com,1999:blog-6112936277054198647</id>
<category term="xorg"/>
<category term="libinput"/>
<category term="workflow"/>
<category term="xi2"/>
<category term="synaptics"/>
<category term="xkb"/>
<category term="evdev"/>
<category term="git"/>
<category term="wacom"/>
<category term="gnome"/>
<category term="wayland"/>
<category term="multitouch"/>
<category term="tutorial"/>
<category term="configuration"/>
<category term="libei"/>
<category term="fedora"/>
<category term="freedesktop.org"/>
<category term="gitlab"/>
<category term="input device properties"/>
<category term="x"/>
<category term="xorg.conf"/>
<category term="hid"/>
<category term="evemu"/>
<category term="evtest"/>
<category term="mpx"/>
<category term="compiz"/>
<category term="gnome-device-setup"/>
<category term="hal"/>
<category term="kernel"/>
<category term="libevdev"/>
<category term="libinput. wayland"/>
<category term="libratbag"/>
<category term="outdoors"/>
<category term="tig"/>
<category term="tuhi"/>
<category term="xds"/>
<category term="xlib"/>
<category term="xts"/>
<author>
<name>Peter Hutterer</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/17204066043271384535</uri>
</author>
<link href="http://who-t.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
<link href="http://www.blogger.com/feeds/6112936277054198647/posts/default?redirect=false" rel="self" type="application/atom+xml"/>
<link href="http://who-t.blogspot.com/" rel="alternate" type="text/html"/>
<link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
<link href="http://www.blogger.com/feeds/6112936277054198647/posts/default?start-index=26&max-results=25&redirect=false" rel="next" type="application/atom+xml"/>
<title>Who-T</title>
<updated>2025-04-01T19:42:18Z</updated>
</source>
</entry>
<entry>
<id>tag:blogger.com,1999:blog-6112936277054198647.post-3705505984992357614</id>
<link href="http://who-t.blogspot.com/feeds/3705505984992357614/comments/default" rel="replies" title="Post Comments" type="application/atom+xml"/>
<link href="http://www.blogger.com/comment/fullpage/post/6112936277054198647/3705505984992357614" rel="replies" title="0 Comments" type="text/html"/>
<link href="http://www.blogger.com/feeds/6112936277054198647/posts/default/3705505984992357614" rel="edit" type="application/atom+xml"/>
<link href="http://www.blogger.com/feeds/6112936277054198647/posts/default/3705505984992357614" rel="self" type="application/atom+xml"/>
<link href="http://who-t.blogspot.com/2025/02/gnome-48-and-changed-tap-and-drag-drag.html" rel="alternate" title="GNOME 48 and a changed tap-and-drag drag lock behaviour" type="text/html"/>
<title>GNOME 48 and a changed tap-and-drag drag lock behaviour</title>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>
This is a heads up as <a href="https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4292#note_2356530">mutter PR!4292</a> got merged in time for GNOME 48. It (subtly) changes the behaviour of drag lock on touchpads, but (IMO) very much so for the better. Note that this feature is currently not exposed in GNOME Settings so users will have to set it via e.g. the gsettings commandline tool. I don't expect this change to affect many users.
</p>
<p>
This is a feature of a feature of a feature, so let's start at the top.
</p>
<p>
"Tapping" on touchpads refers to the ability to emulate button presses via short touches ("taps") on the touchpad. When enabled, a single-finger tap corresponds emulates a left mouse button click, a two-finger tap a right button click, etc. Taps are short interactions and to be recognised the finger must be set down and released again within a certain time and not move more than a certain distance. Clicking is useful but it's not everything we do with touchpads.
</p><p>
</p><p>
"Tap-and-drag" refers to the ability to keep the pointer down so it's possible to drag something while the mouse button is logically down. The sequence required to do this is a tap immediately followed by the finger down (and held down). This will press the left mouse button so that any finger movement results in a drag. Releasing the finger releases the button. This is convenient but especially on large monitors or for users with different-than-whatever-we-guessed-is-average dexterity this can make it hard to drag something to it's final position - a user may run out of touchpad space before the pointer reaches the destination. For those, the tap-and-drag "drag lock" is useful.
</p>
<p>
"Drag lock" refers to the ability of keeping the mouse button pressed until "unlocked", even if the finger moves off the touchpads. It's the same sequence as before: tap followed by the finger down and held down. But releasing the finger will <b>not</b> release the mouse button, instead another tap is required to unlock and release the mouse button. The whole sequence thus becomes tap, down, move.... tap with any number of finger releases in between. Sounds (and is) complicated to explain, is quite easy to try and once you're used to it it will feel quite natural.
</p>
<p>
The above behaviour is the new behaviour which non-coincidentally also matches the macOS behaviour (if you can find the toggle in the settings, good practice for easter eggs!). The previous behaviour used a timeout instead so the mouse button was released automatically if the finger was up after a certain timeout. This was less predictable and caused issues with users who weren't fast enough. The new "sticky" behaviour resolves this issue and is (alanis morissette-stylue ironically) faster to release (a tap can be performed before the previous timeout would've expired).
</p>
<p>
Anyway, TLDR, a feature that very few people use has changed defaults subtly. Bring out the pitchforks!
</p>
<p>
As said above, this is currently only accessible via gsettings and the drag-lock behaviour change only takes effect if tapping, tap-and-drag <b>and</b> drag lock are enabled:
</p><pre> $ gsettings set org.gnome.desktop.peripherals.touchpad tap-to-click true
$ gsettings set org.gnome.desktop.peripherals.touchpad tap-and-drag true
$ gsettings set org.gnome.desktop.peripherals.touchpad tap-and-drag-lock true
</pre>
All features above are actually handled by libinput, this is just about a default change in GNOME.
<p/></div>
</content>
<updated>2025-02-24T04:17:00Z</updated>
<published>2025-02-24T04:17:00Z</published>
<category scheme="http://www.blogger.com/atom/ns#" term="gnome"/>
<author>
<name>Peter Hutterer</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/17204066043271384535</uri>
</author>
<source>
<id>tag:blogger.com,1999:blog-6112936277054198647</id>
<category term="xorg"/>
<category term="libinput"/>
<category term="workflow"/>
<category term="xi2"/>
<category term="synaptics"/>
<category term="xkb"/>
<category term="evdev"/>
<category term="git"/>
<category term="wacom"/>
<category term="gnome"/>
<category term="wayland"/>
<category term="multitouch"/>
<category term="tutorial"/>
<category term="configuration"/>
<category term="libei"/>
<category term="fedora"/>
<category term="freedesktop.org"/>
<category term="gitlab"/>
<category term="input device properties"/>
<category term="x"/>
<category term="xorg.conf"/>
<category term="hid"/>
<category term="evemu"/>
<category term="evtest"/>
<category term="mpx"/>
<category term="compiz"/>
<category term="gnome-device-setup"/>
<category term="hal"/>
<category term="kernel"/>
<category term="libevdev"/>
<category term="libinput. wayland"/>
<category term="libratbag"/>
<category term="outdoors"/>
<category term="tig"/>
<category term="tuhi"/>
<category term="xds"/>
<category term="xlib"/>
<category term="xts"/>
<author>
<name>Peter Hutterer</name>
<email>noreply@blogger.com</email>
<uri>http://www.blogger.com/profile/17204066043271384535</uri>
</author>
<link href="http://who-t.blogspot.com/feeds/posts/default" rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml"/>
<link href="http://www.blogger.com/feeds/6112936277054198647/posts/default?redirect=false" rel="self" type="application/atom+xml"/>
<link href="http://who-t.blogspot.com/" rel="alternate" type="text/html"/>
<link href="http://pubsubhubbub.appspot.com/" rel="hub" type="text/html"/>
<link href="http://www.blogger.com/feeds/6112936277054198647/posts/default?start-index=26&max-results=25&redirect=false" rel="next" type="application/atom+xml"/>
<title>Who-T</title>
<updated>2025-04-01T19:42:18Z</updated>
</source>
</entry>
<entry xml:lang="en">
<id>https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user</id>
<link href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user" rel="alternate" type="text/html"/>
<title>Flathub Safety: A Layered Approach from Source to User</title>
<summary>With thousands of apps and billions of downloads, Flathub has a responsibility to help ensure the safety of our millions of active users. We take this responsibility very seriously with a layered, in-depth approach including sandboxing, permissions, transparency, policy, human review, automation, reproducibility, auditability, verification, and user interface.</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>With thousands of apps and billions of downloads, Flathub has a responsibility to help ensure the safety of our millions of active users. We take this responsibility very seriously with a layered, in-depth approach including sandboxing, permissions, transparency, policy, human review, automation, reproducibility, auditability, verification, and user interface.</p>
<p>Apps and updates can be fairly quickly published to Flathub, but behind the scenes each one takes a long journey full of safety nets to get from a developer’s source code to being used on someone’s device. While information about this process is available between various documentation pages and the Flathub source code, I thought it could be helpful to share a comprehensive look at that journey all in one place.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="flatpak-security--sandboxing">Flatpak Security & Sandboxing<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#flatpak-security--sandboxing" title="Direct link to Flatpak Security & Sandboxing"></a></h2>
<p>Each app on Flathub is distributed as a <a href="https://flatpak.org/" rel="noopener noreferrer" target="_blank">Flatpak</a>. This app packaging format was specifically designed with security and safety at its core, and has been continuously improved over the past decade. It has received endorsements, development, and wide adoption from organizations such as Bambu Lab, Bitwig, CodeThink, Collabora, Discord, The Document Foundation, elementary, Endless, GDevelop, KiCad, Kodi, GNOME, Intel, KDE, LibreOffice, Mozilla, OBS Studio, Plex, Prusa Research, Purism, Red Hat, System76, Telegram, Valve, and many more.</p>
<p><img alt="Flatpak logo" class="img_ev3q" height="560" src="https://docs.flathub.org/assets/images/flatpak-d50c84bc739f183bb3d4762fe629e0f5.png" width="1476"/></p>
<p>From a technical perspective, Flatpak does not require elevated privileges to install apps, isolates apps from one another, and limits app access to the host environment. It makes deep use of existing Linux security technologies such as cgroups, namespaces, bind mounts, and seccomp as well as <a href="https://github.com/containers/bubblewrap" rel="noopener noreferrer" target="_blank">Bubblewrap</a> for sandboxing.</p>
<p>Flatpak apps are also built from a declarative manifest, which defines the exact sources and environment to build from to enable auditability and as much reproducibility as possible.</p>
<p>Due to Flatpak’s sandboxing, apps don’t have permission to access many aspects of the host OS or user data they might need. To get that access, apps must either request it using Portals or use static permissions.</p>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="portals--static-permissions">Portals & Static Permissions<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#portals--static-permissions" title="Direct link to Portals & Static Permissions"></a></h3>
<p>Most permissions can be requested and granted on demand via an API
called <a href="https://flatpak.github.io/xdg-desktop-portal/docs/" rel="noopener noreferrer" target="_blank">Portals</a>.
These permissions do not need to be given ahead of time, as desktop
environments provide the mechanisms to give user consent and control
over them e.g. by indicating their use, directly prompting the user
before the permission is granted, and allowing revocation.</p>
<p><img alt="Illustration of portal, light" class="img_ev3q" height="560" src="https://docs.flathub.org/assets/images/xdg-portal-light-b91934f67cd2ff2747479b41952cc77b.png#gh-light-mode-only" width="1476"/>
<img alt="Illustration of a portal, dark" class="img_ev3q" height="560" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABcQAAAIwCAMAAACfs5g9AAAA0GVYSWZJSSoACAAAAAoAAAEEAAEAAADEBQAAAQEEAAEAAAAwAgAAAgEDAAMAAACGAAAAEgEDAAEAAAABAAAAGgEFAAEAAACMAAAAGwEFAAEAAACUAAAAKAEDAAEAAAACAAAAMQECAA0AAACcAAAAMgECABQAAACqAAAAaYcEAAEAAAC+AAAAAAAAAAgACAAIAEgAAAABAAAASAAAAAEAAABHSU1QIDIuMTAuMzgAADIwMjU6MDI6MjAgMjA6Mjg6MzAAAQABoAMAAQAAAAEAAAAAAAAA1q69lwAAAYNpQ0NQSUNDIHByb2ZpbGUAAHicfZE9SMNAHMVfU0WRioMVRB0iVCe7qIhjrUIRKoRaoVUHk0u/oElDkuLiKLgWHPxYrDq4OOvq4CoIgh8g7oKToouU+L+k0CLGg+N+vLv3uHsHCPUy06yOGKDptplKxMVMdlXseoWAAQQxjFGZWcacJCXhO77uEeDrXZRn+Z/7c/SqOYsBAZE4xgzTJt4gntm0Dc77xGFWlFXic+IJky5I/Mh1xeM3zgWXBZ4ZNtOpeeIwsVhoY6WNWdHUiKeJI6qmU76Q8VjlvMVZK1dZ8578haGcvrLMdZojSGARS5AgQkEVJZRhI0qrToqFFO3HffxDrl8il0KuEhg5FlCBBtn1g//B726t/NSklxSKA50vjvMxBnTtAo2a43wfO07jBAg+A1d6y1+pA7OfpNdaWuQI6NsGLq5bmrIHXO4Ag0+GbMquFKQp5PPA+xl9UxbovwV61rzemvs4fQDS1FXyBjg4BMYLlL3u8+7u9t7+PdPs7wd3AHKoelFTRgAADXhpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IlhNUCBDb3JlIDQuNC4wLUV4aXYyIj4KIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgIHhtbG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIgogICAgeG1sbnM6c3RFdnQ9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZUV2ZW50IyIKICAgIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyIKICAgIHhtbG5zOkdJTVA9Imh0dHA6Ly93d3cuZ2ltcC5vcmcveG1wLyIKICAgIHhtbG5zOnRpZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8xLjAvIgogICAgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIgogICB4bXBNTTpEb2N1bWVudElEPSJnaW1wOmRvY2lkOmdpbXA6YWZjZTJmNjgtZDRmZi00M2VmLWIxOWEtN2ZhYjc0ZDU2OTUyIgogICB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAuaWlkOjZhMzVjZDRmLTQxMjItNDk5Mi1hNjEyLTUzNGJjY2I2MDNmYyIKICAgeG1wTU06T3JpZ2luYWxEb2N1bWVudElEPSJ4bXAuZGlkOmU3ZjE2MmNjLTQ5MzUtNGM3Ny04NmNkLWY0MDRkMGNlYWIzNyIKICAgZGM6Rm9ybWF0PSJpbWFnZS9wbmciCiAgIEdJTVA6QVBJPSIyLjAiCiAgIEdJTVA6UGxhdGZvcm09IkxpbnV4IgogICBHSU1QOlRpbWVTdGFtcD0iMTc0MDEwODUxMTA3MTkyOSIKICAgR0lNUDpWZXJzaW9uPSIyLjEwLjM4IgogICB0aWZmOk9yaWVudGF0aW9uPSIxIgogICB4bXA6Q3JlYXRvclRvb2w9IkdJTVAgMi4xMCIKICAgeG1wOk1ldGFkYXRhRGF0ZT0iMjAyNTowMjoyMFQyMDoyODozMC0wNzowMCIKICAgeG1wOk1vZGlmeURhdGU9IjIwMjU6MDI6MjBUMjA6Mjg6MzAtMDc6MDAiPgogICA8eG1wTU06SGlzdG9yeT4KICAgIDxyZGY6U2VxPgogICAgIDxyZGY6bGkKICAgICAgc3RFdnQ6YWN0aW9uPSJzYXZlZCIKICAgICAgc3RFdnQ6Y2hhbmdlZD0iLyIKICAgICAgc3RFdnQ6aW5zdGFuY2VJRD0ieG1wLmlpZDpjODQxMmQ0My00N2NkLTQwY2YtOTM5Ni0xMzdkZmU4MDczNGMiCiAgICAgIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkdpbXAgMi4xMCAoTGludXgpIgogICAgICBzdEV2dDp3aGVuPSIyMDI1LTAyLTIwVDIwOjI4OjMxLTA3OjAwIi8+CiAgICA8L3JkZjpTZXE+CiAgIDwveG1wTU06SGlzdG9yeT4KICA8L3JkZjpEZXNjcmlwdGlvbj4KIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/PvXnJBwAAAA2UExURXMubQAAAB0rU34lUwCHUatSNl9XT8LDx//x6P8ATf+jAP/sJwDkNimt/4N2nP93qP/MqgABBNHNtzIAAAABdFJOUwBA5thmAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB+kCFQMcH4mh+tYAABVqSURBVHja7d3dchu5EYDRlB1b61Rp1+//tCEq6tpeBJjB/IFD6ZwbyhIlkiP540UXgH/9CwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADY4K/k7cN75fuDKwUg4gCIOAAiDvCKwW6FesmPB1cPQMQBEHEAERdxgM8YbREHEHEARBxAxEUc4JXi/X4iEQcQcQBEHEDERRzgrv58ODviQg4g4gCIOICIizjAHV0x2BRxABEHQMQBRFzEAb5KxH8lrjCAiAMg4gAiLuIAdxDBPTPi5U0hBptCDiDiAIg4gIiLOMAd4h0BP3sDrPLzys/NIbf4B0DEARBxABEXcYArfX/oxbs4O951yMuA06IfABEHEHERBxBxEQeYIYezBL2Eu4T1ynj3hpzxXMQcQMQBRFzEAURcxAGujHgEfGa8lw6K8JsBEHEAERdxABEXcYArI/5+AzHk9JsBEHEAERdxABEXcYCzlXg/c5jZG3DG8ysLj1qbdAEg4gAiLuIAIi7iAHvcLeJ5sBkLgIQcQMQBRFzEAURcxAHOUEJ5p4iXN5XynGJTrpGQl+/zmwREXMQBRFzEAURcxAHWlAU17zcXYc8LgXLAg98mIOIiDiDiIg4g4iIOfD0leiP3e38x5Q0nh7wOvd88IOIiDiDiIg4g4iIOfD0jUXt/UW8PsRjIUBMQcREHEHERBxBxEQe+tnzIw2eK99piIL95QMRFHEDERRxAxEUceD1HDgWuDz0uQ8D4Wvn4/RPzlwOIuIgDiLiIAyIu4iIOfC1lg6g65OXz71+EvwBAxEUcQMRFHEDERRz4Wj77AHPNkcEwgIiLOICIizgg4iIOME8+BPjIz8iLfb5axM+4hgAiLuKAiIu4iAMiLuIA9494+f4I91uSg17f7vHtYfQ5lfvWC5CuVBY8CTkg4iIOIOIiDoi4iIs48LkjXha5vA2oA98Kffj3w1WvtcS9DnDveaz9u1beNMq1/PUg6ICIiziAiIs4IOIiLuLA/RzduGkp0KPi+2e/9hLdtQHs1tsYcJaQ++sCRFzEAURcxAERF3ERB+7lyAAuInjEXa7D2gB2ix8fhBwQcREHEHERB0RcxEUcuJe9oTkS8C0bWc1WntvbCYQcEHERBxBxEQdEXMRFHLif0cFmXhQUh0C88iBzzVkRtxEWIOIiDiDiIg6IuIiLOPB8ZTC5JeJx370Bf9XrtPa6/nhofT5vhCXkgIiLOICIizgg4iIu4sDzbYlLidHoocifId7Z3gVAPypHn4O/WEDERRwQcREXcUDERVzEgWsjnjdy+ooBz/ZEPAabNsICRFzEAURcxAERF3ERB55rNCxl4crWQyA+4/XqLewZDblFP4CIiziAiIs4IOIiLuLA86xFpSzu+evD6CZQn/ValdcYH2+J+JkbYeWDOQBEXMQBERdxEQdEXMRFHDg34nGfrzzMLN4f6s9tCXkebG4Jcf37EXFAxEUcEHERF3FAxEVcxIF9ShCWIh5fXxtqvkrArzpUYXS4uWcjLNEGRFzEAREXcREHRFzERRw4x8hQ87ME/Ej0W0PNbHRjsHxgsjgDIi7igIiLuIgDIi7iIg7cK+IjG19FwH8+fMZr9O+HkfuNhDw2wtp6OEQ9CPUGAIi4iAMiLuIiDoi4iIs4sC/iS0EoX//9cLeB5rcPS18vUb1qcc/S464dmpFDvvT8cri3LA4CRFzERRwQcREXcUDERVzEgfVQtAK+NtScGcctnz9637C2yKdl7RDpkcGmQSYg4iIOiLiIizgg4iIu4sD5RoaaMdhsDTifEe6jYT7yfXtCngOeQ77njRVAxEUcEHERF3FAxEVcxIFzIl6HLUc8izDd4fl/a7jLtd1ziMbSwLN+wzXsBERcxAERF3ERB0RcxEUc2BbAXghioc/vjquez57vKYc2HA356MEPW392Hgi3bssmXXHfvDFW73firxYQcREHRFzERRwQcREXcWCf7x8iNnlgWRaczAz43ugX7x9yzO/yHMv1/L0iAr22MZZBJiDiIg6IuIiLOCDiIi7iwDkRz1FZCs+zDkbuRbyE+71ydOHP2W8CaxHPA821wyIARFzEAREXcREHRFzERRzYH/GI3e9Bdwh3FuEuby6tiN9hyPnzYTTkZaAs4oCIizgg4iIu4oCIi7iIA9dEPG5HAv7soWZEuT5cIQ4ibh1IHJ4d9LVru3ewaQEQiLiIizgg4iIu4oCIi7iIA9sCMHOouRbSOrataB9RDmFoDT23BH7vm8GWBT8iDoi4iAMiLuIiDoi4iIs4cK4IxkjA84G+V6kX6ZTHfLvI0ZCfHfF6sDkaZxEHERdxEQdEXMRFHBBxERdxYDziZaD27I2vIp69xTxXyo+79jzLRlZXhbzeAMsmWICIizgg4iIu4oCIi7iIA+eKcKwFvGwsdWXAs7cniDjP2CDrigU/gIiLuIgDIi7iIg6IuIiLOLBudLB5Rqh7n/+evD3R6GKmowdjlDfEpQU/BpuAiIs4IOIiLuKAiIu4iAPnK9EcHWxe9fhFhPztBkpgZxyovDbYLNdDxAERF3FAxEVcxAERF3ERB86N6Mhg84qFPhHuOwW8dZDy7IjnAyFEHBBxEQdEXMRFHBBxERdx4DyjGy0dOSC5F8K7LPCplZDGIcpLz3/G72RLxB2WDCIu4iIOiLiIizgg4iIu4sCyMtCMBT8zH7cOeISzd5sX4sy8jTevmSHfG3FAxEVcxAERF3ERB0RcxEUcWA/GlYtKWvHLh0CUSK4FfHa448CGuM0HOIs4IOIiLuKAiIs4IOIiLuLA60f87MHmUvDyUPP3RkeDnG/Xvp7vNzPkIg6IuIgDIi7iIg6IuIiLOHB9MM7+2a3gHQn4Utivvv1Wya+pRH5GxAUdEHERB0RcxEUcEHERF3HgnGDMOlAgAl4ecyTMe0O+JfA99c9bGm6eOfBsRdyQExBxEQdEXMRFHBBxERdx4DUjXhYWrYW4bIwVm2CNBnzrwHOrWQt+RBwQcREHRFzERRwQcREXceDaYMwKeAw1lwL7nmwN79GFPUvKG8uMkPcW+og4IOIiDoi4iIs4IOIiLuLA60V8KbjvlZHh5tkbXi393BkRj+v0rN8TIOIiLuKAiIu4iAMiLuKAiB9TopcX+tSBLLGu4x0fP+NAiN7Pn3lgsogDIi7igIiLuIgDIi7iIg68ZhxaC31yKFsDzbWI7xlMHr2dNdwUcUDERRwQcREXcUDERVzEgfPkAM2Iw6+H3mDzvaGO+NoGVaMbWfVCv+VAZhEHRFzERRwQcREHRFzERRx4vYjPDFEJUH1AcgT0fcUVBzwc8YyIx1DYXy4g4iIOiLiIizgg4iIu4sDrRHzkIIh6sFk+nhVog01AxEVcxAERF3ERB0RcxAERP2rpQIj3AbH51NlBPnOwefXhySIOiLiIAyIu4iIOiLiIizjwz//orf/0ZfOpZ0Y8H5I8GvD64OS1gx+ObGi19aCJnw+t61c+f9U1/JH4SwcRF3ERB0RcxEUcEHERF3HgnyGPQxgi4HXIZ0Y8DkkePRCiF/WzDjxuBTsPTtdu/3xYunbl62deuxLufOuvHERcxEUcEHERF3FAxEVcxEG8//7PXYc7gj4r4vXPzBGvw7kl4mcE/Izb8lxmvAHmYaaIg4iLuIgDIi7iIg6IuIiLOPD/EW8NNvPnZkQ8xICvNdhci3gs9smLfmYFeuR+f32YGfHgrx1EXMRFHBBxERdxQMRFXMRBxNv/yeNz9bDzWYt98gEPowPN+mCI3sKcta/3bsPbh/i49fX4vtkRzyHv3b81wAZEXMRFHBBxERdxQMRFXMThK8S8XhiSQz474hGkiPgWo4PNNSMhXzqIon5OBpuAiIu4iAMiLuKAiIu4iAP3C3qOeb4tZkY8orc13q3B5taAj4a8jngecvYifuYBEL2If6+s/c795YOIi7iIAyIu4iIOiLiIizh8ZWWgmYNQPjd7sLk14i2tIG+1NNjsPWbrDaa8lquDWR8GYbEPiLiIizgg4iIu4oCIi7iIA2NisU8sUHlWxMsgcO9in/rAhrONPqfyGq5e6BMRrwO+9vsScRBxERdxQMRFXMQBERdxEQf+/g8eG1E9Y7FPeeytEV8abraUx4rYb1Ev6FkyY6gZEd+y0AcQcREXcUDERVzEAREXcREH2nEIMwZ08QYSA8G9g821iOfHuzLicejzjGtW673pCj2IuIiLOCDiIi7igIiLuIgDy4HIIS+3Vz/mGZtgLQ0tt0Q8H/iwJeLxRnTlYRBLEa/v8+uDeIOIi7iIAyIu4iIOiLiIizjQFwOyegHQjIgfWfCTw7s34q2Aj0Y8XkN9HZ8ZcQEHERdxEQdEXMRFHBBxERdxYDwSMxf+HB1u9gKeYxobe60FvDY62Jwx1ByNeOuNGRBxERdxQMRFXMQBERdxEYevFufR+87eDKsV8aWA1l+L4O6J+FLARyI+a1HUUsTz68xht/kViLiIizgg4iIu4oCIi7iIw1c2Onx7VsTzgp8tBzLk6K5FPN9nLeCjEZ91iEYv4nvfrAERF3ERB0RcxEUcEHERF3HgOYcmt4abJbBbN8DKkY6If0tGwj0a8HKfGZuE5WsUv5eloaUDkkHERVzEAREXcREHRFzERRwYlzfAmhmopY2wlsLaOtAhL4Qp4uM8AO0dBLH3MIhZv5depPObr79iEHERF3FAxEVcxAERF3ERB/6OwdLnnhHxHPK1YWIv8DnIOeI5ensD3tp0a2bAI9J1yJ/5+wJEXMRFHBBxERdxEHERF3Hg1eNeH5Q8c0hWNsDae2hyfdjD947eYHPrUPP3w+yI54Dn2/x7EnEQcREXcUDERVzEAREXcREH/icfktDzo2Hmc2wdEDF6KMRoxOuDkrccQLEn4CPXfYSAg4iLuIgDIi7iIg6IuIiLOLDNz4f4uPef/pkRj8cvkdx6WPJIxOuAx+2WgD8rlvXvRbRBxEVcxAERF3ERB0RcxEUcOE8Mz+KA3pmPvWfRz1rIfz2Un5nDvWWwufVg5DMGmmXAK9qAiIs4IOIiLuKAiIu4iAP7bY1LvbBkxsZP5TkeWfgTse0NN7dusBULfGZtelUPMcs18JcLiLiIAyIu4iIOiLiIizgwJ+R1VGbFLMK5NHx8a/j1IQaa+XZvwOPg5dkBf8aCK0DERVzEAREXcREHRFzEga/uWWEZCXm9oVUv4sXWgBd74l2exxkBt8gHEHERB0RcxEUcEHERF3HguL2LfmJDrKMh3/L4fyVL0c2bX/UiPrLhVblPBHzPayvfX65PhPw/D6PX11ATEHERB0RcxEUcEHERF3HgHvJin5GhW3z9rOFchLzEdWnhT455+Xw5IHp0A629w8z6/uVnlccvAc9B712jKwJerlV54/KXC4i4iAMiLuIiDoi4iIs4sE8crjB6gPIVw7mRQWcMMMtzXYt4xDsOoTjzTa88fgQ8v5nlN7irFvkIOCDiIg6IuIiLOCDiIi7iQNuWeNXhWbrf1c85hoa9QJeA9w6DiEOV49CHPc+hNwAtn48Y5+uU490KeHxu9PcQi5h6X7OBFoi4iIs4IOIiLuKAiIu4iAPHo1sHaOl764HeFWH5oyFHPB8cUZzxmOVnL73mrPX5VsC3Xpul4aWAg4iLuIgDIi7iIg6IuIiLOPBPeTA3sulTfZ8coVgAVMLSuw1x/9ikqYjvz7ch/7s+oCJHcc816D1uPKfW86nVB2bEm0c8p/h6fp1XH4gcw01/5SDiIi7igIiLuIgDIi7iIg78HeWwNxQ5RjnQddjr8JUDE/Ltmt79fnd8a4iNrpbeMEYfdy3o9eAzv5HVG2BtjXh9/9b3XzVEBkRcxEUcEHERF3EQcREXceAzRX3Pf/wc8V7Il27XgrgkAp0HnmVzrFbEy+fzYDEOuFh7g1m7rQebdUBbb5LxnI+EdineIg4iLuIiDoi4iIs4IOIiLuLAWMh/rcixikFdb0HP3ts9YnAZt0sh36q3ACl/vh5SLg2MlzbQOhL1vZtpASIu4iIOiLiIizgg4iIu4iDk+xwN+NpGWHs3u+pZ2tBq9HmVaEa09y6e2hvufO0FHBBxEQdEXMRFHBBxERdx4HjI68HllqAvHfxw5aCzHmr2FveUYWd8bevzmhnNeHOow53jLeCAiIs4IOIiLuKAiIu4iAPnhPwK+bDkkUHpla93S8hnDhHzoqpWtMUbEHERB0RcxEUcEHERF3HgdUK+JfixgdXIRlatwyHKxlO9Da5CK9j532vRHAlqa9OwUYINiLiIAyIu4iIOiLiIizhwXcRbi0ue4c+GWHDTC3PrYIh4XSXobw/1z8vh7kU0Yp6jfuV1Em5AxEUcEHERF3FAxEVcxIF59g7hXjFiv25EvAERF3FAxEVcxAERF3ERB+Yrg8Bnhjw/jxi2hjKgjMFkfBwDy9HXlxfwHB1Qbr1O9UZW9WsGEHERB0RcxEUcEHERF3HgdUJ+RhzL97YW+tQbXpXb3w/5dm2TrHrDq7yQp/f1UfG84/ZnkjfBqgNuoAmIuIgDiLiIAyIu4iIO3EPrkN4tw7vR++TbHMJeyOO5/dmRX0Pr6yWssUFWRDSHN7625U0vBq9Lyn2XroW/OEDERRxAxEUcEHERF3HgPq44OOIOAdvz+BH7iPPeN0URB0RcxAFEXMQBERdxEQfu7YqDgj/ztRJvQMRFHEDERRwQcREXceC1tQ5tWIt77+t10GLDqFreyGppo6vWhlahtcHV0mu8Kt7+ggARF3EAERdxQMRFXMSB14t4y1Ksl26XDiTOAR4JeR3s+Dk9Z16bXrDFGxBxEQcQcREHRFzERRz4nCHPMc+39WEQ3waUEJf7t0KeQxybUuWDJPL96pDH4599XQwxAREXcQARF3EAERdx4HNGfDTmLd92ah18nG+Xvp7vE4c69N54IsjltnWARWsgK96AiIs4gIiLOICIizjw+WO+JO5Th3FPvHuhjq8dfS1HD7wQcUDERRxAxEUcQMRFHPiaEY+v5dtXeC17D7doDT/PvsaveE0BERdxEQdEXMQBRFzEgc8U8KXbVxWLkdYOtpg11MwRBxBxEQcQcREHRFzERRx4bsR7/16L0hmO/sy1mNf/7oV89iIfUQdEXMQBERdxEQdEXMRFHHiN8N8p4iNBz4db5LjXh0ALNiDiIi7igIiLOICIizjAVQHvBfjM4WbI4a4/nn0IhMU/gIiLOICIizgg4iIu4sBrR/xo6M9+k7jbdatvRRwQcREHEHERB0RcxEUcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJ7qv70rv9PaBD8xAAAAAElFTkSuQmCC#gh-dark-mode-only" width="1476"/></p>
<p>Portals include APIs for handling auto-start and background activity;
access to the camera, clipboard, documents, files, location, screen
casting, screenshots, secrets like passwords, trash, and USB devices;
setting global shortcuts; inhibiting suspend or shut down; capturing
input; monitoring memory, network, or power profiles; sending
notifications; printing; setting a wallpaper; and more. In each case,
the user’s desktop environment (like GNOME or KDE) manages if and how a
user is notified or prompted for permissions—and if the permission is
not granted, the app must handle it gracefully.</p>
<p>Some permissions are not covered by Portals, such as basic and generally safe
resources for which dynamic permissions wouldn’t make sense. In these cases—or
if a Portal does not yet exist or is not widely adopted for a certain
permission—developers may use <a href="https://docs.flathub.org/docs/for-app-authors/requirements#permissions" rel="noopener noreferrer" target="_blank">static permissions</a>.
These are set by the developer at build time in the public build manifest.</p>
<p>Static permissions are intended to be as narrowly-scoped as possible and are
unchanging for the life of each release of an app. They are not generally
designed to be modified by an end user except in cases of development,
debugging, or <a href="https://docs.flathub.org/docs/for-users/permissions" rel="noopener noreferrer" target="_blank">reducing permissions</a>.
Due to this, Flatpak always prefers apps to use Portals over static permissions
whenever possible.</p>
<h3 class="anchor anchorWithStickyNavbar_LWe7" id="shared-runtimes--modules">Shared Runtimes & Modules<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#shared-runtimes--modules" title="Direct link to Shared Runtimes & Modules"></a></h3>
<p>Every app is built against a <a href="https://docs.flatpak.org/en/latest/basic-concepts.html#runtimes" rel="noopener noreferrer" target="_blank">Flatpak runtime</a> hosted by Flathub. The runtimes provide basic dependencies, are well-maintained by the Linux community, and are organized according to various platforms a developer may target; for example, GNOME, KDE, or a generic FreeDesktop SDK. This means many apps—especially those targeting a platform like GNOME or KDE and using its developer libraries—don’t need to pull in external dependencies for critical components.</p>
<p>Runtimes are automatically installed with apps that require them, and are updated separately by the user’s OS, app store, or CLI when needed. When a dependency in a runtime is updated, e.g. for a critical security update, it rolls out as an update to all users of apps that use that runtime.</p>
<p>In some cases there are commonly-used libraries not provided directly by one of the available runtimes. Flathub provides <a href="https://docs.flathub.org/docs/for-app-authors/shared-modules" rel="noopener noreferrer" target="_blank">shared modules</a> for these libraries to centralize the maintenance. If an app needs to bundle other dependencies, they must be defined in the manifest. We also provide <a href="https://github.com/flathub-infra/flatpak-external-data-checker" rel="noopener noreferrer" target="_blank">tooling to automatically suggest updates</a> to app dependencies.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="submission--human-review">Submission & Human Review<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#submission--human-review" title="Direct link to Submission & Human Review"></a></h2>
<p>Once an app is developed, it must be submitted to Flathub for consideration to be hosted and distributed. At this stage, human Flathub reviewers will review the app to ensure it follows the <a href="https://docs.flathub.org/docs/for-app-authors/requirements" rel="noopener noreferrer" target="_blank">requirements</a>. Of note:</p>
<ul>
<li>
<p><strong>Apps must be sandboxed with as narrow permissions as possible</strong> while still functioning, including using appropriate runtime permissions instead of broad static permissions when possible. All broad
static permissions need to be justified by the submitter during review.</p>
</li>
<li>
<p><strong>Apps must not be misleading or malicious</strong>, which covers impersonating other apps or including outright malicious code or functionality.</p>
</li>
<li>
<p><strong>App IDs must accurately reflect the developer’s domain name</strong> or code hosting location; e.g. if an app is submitted that purports to be Lutris, its ID must be obviously associated with that app (in this case, <a href="https://lutris.net/" rel="noopener noreferrer" target="_blank">Lutris.net</a>).</p>
</li>
</ul>
<p>The app’s Flatpak manifest is reviewed, including all static permissions. Each of the documented requirements are checked—and if a reviewer finds something out of place they request changes to the submission, ask for rationale, or reject it completely.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="automated-testing">Automated Testing<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#automated-testing" title="Direct link to Automated Testing"></a></h2>
<p>In addition to human review, Flathub also makes use of automated testing for a number of quality and safety checks. For example, our automated tests block unsafe or outright wrong permissions, such as apps requesting access to whole session or system buses or unsafe bus names. Our automated tests also help ensure reproducible builds by disallowing pointing at bare git branches without a specific commit.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="reproducibility--auditability">Reproducibility & Auditability<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#reproducibility--auditability" title="Direct link to Reproducibility & Auditability"></a></h2>
<p>Once an app has been approved and passes initial tests, it is built using the open source and publicly-available flatpak-builder utility from the approved public manifest, on Flathub’s infrastructure, and without network access. Sources for the app are validated against the documented checksums, and the build fails if they do not match.</p>
<p>For further auditability, we specify the git commit of the manifest repo used for the build in the Flatpak build subject. The build itself is signed by Flathub’s key, and Flatpak/OSTree verify these signatures when installing and updating apps.</p>
<p>We mirror the exact sources each app is built against in case the original source goes down or there is some other issue, and anyone can build the Flatpak back from those mirrored sources to reproduce or audit the build. The manifest used to build the app is hosted on Flathub’s GitHub org, plus distributed to every user in the app’s sandbox at <code>/app/manifest.json</code>—both of which can be compared, inspected, and used to rebuild the app exactly as it was built by Flathub.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="verification">Verification<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#verification" title="Direct link to Verification"></a></h2>
<p>Apps can be <a href="https://docs.flathub.org/docs/for-app-authors/verification" rel="noopener noreferrer" target="_blank">verified</a> on Flathub; this process confirms that an app is published by the original developer or an authorized party by proving ownership of the app ID. While all apps are held to the same high standards of safety and review on Flathub, this extra layer helps users confirm that the app they are getting is <em>also</em> provided or authorized by its developer.</p>
<p><img alt="Verified checkmark" class="img_ev3q" height="517" src="https://docs.flathub.org/assets/images/verified-f93f6737d8c414a1b1be91179d85cc69.png" width="1362"/></p>
<p>Over half of the apps on Flathub so far are verified, with the number regularly increasing.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="app-store-clients">App Store Clients<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#app-store-clients" title="Direct link to App Store Clients"></a></h2>
<p>Once an app is developed, submitted, tested, approved, built, and distributed, it appears in app store clients like Flathub.org, KDE Discover, GNOME Software, and elementary AppCenter—as well as the Flatpak CLI. While exact implementations vary and the presentation is up to the specific app store client, generally each will show:</p>
<ul>
<li>Static permissions and their impact on safety</li>
<li>Open Age Rating Service rating and details</li>
<li>If an app uses outdated runtimes</li>
<li>Release notes for each release</li>
<li>If static permissions increase between releases</li>
</ul>
<p>Flathub.org and GNOME Software also display the app’s verified status.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="updates">Updates<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#updates" title="Direct link to Updates"></a></h2>
<p>Once an app is accepted onto Flathub, it still remains subject to number of
safety protections built into the flow:</p>
<ul>
<li><strong>Flathub maintains ownership over the manifest repo</strong>, while app developers are invited as limited collaborators</li>
<li><strong>The manifest repo’s default branch is protected</strong>, preventing direct pushes without a pull request</li>
<li><strong>The manifest repo’s commit history cannot be rewritten</strong>, making it harder to sneak something in</li>
<li><strong>Flathub’s automated tests must pass</strong> before a PR can be merged and an update can be pushed</li>
<li><strong>Static permission changes are held for human review</strong> before an update is released to users</li>
<li><strong>Critical MetaInfo changes are held for human review</strong>, e.g. if an app name, developer name, app summary, or license changes</li>
</ul>
<p><img alt="Build moderation dashboard showing permission changes of Kodi, light" class="img_ev3q" height="454" src="https://docs.flathub.org/assets/images/moderation-light-31fcc57dcbde5c793f0002c758ecf4bb.png#gh-light-mode-only" width="1382"/>
<img alt="Build moderation dashboard showing permission changes of Kodi, dark" class="img_ev3q" height="454" src="https://docs.flathub.org/assets/images/moderation-dark-9100656f3ee61ce86fc7a7620970feea.png#gh-dark-mode-only" width="1382"/></p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="special-cases">Special Cases<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#special-cases" title="Direct link to Special Cases"></a></h2>
<p>There are a few special cases to some of the points above which I would be remiss not to mention.</p>
<p>Flathub has granted a select group of trusted partners, including Mozilla and OBS Studio, the ability to directly upload their builds from their own infrastructure. These projects have an entire CI pipeline which validates the state of their app, and they perform QA before tagging the release and pushing it to Flathub. Even for these few cases of direct uploads, we require a public manifest and build pipeline to enable similar reproducibility and auditability as outlined above. We also require the apps to be verified, and still run automated tests such as our linter against them.</p>
<p>Lastly, some apps (around 6%) use <a href="https://docs.flatpak.org/en/latest/module-sources.html#extra-data" rel="noopener noreferrer" target="_blank">extra-data</a> to instruct Flatpak to download and unpack an existing package (e.g. a Debian package) during installation. This process runs in a tight unprivileged Flatpak sandbox that does not allow host filesystem or network access, and the sandbox cannot be modified by app developers. These are largely proprietary apps that cannot be built on Flathub’s infrastructure, or apps using complex toolchains that require network access during build. This is discouraged since it does not enable the same level of auditability nor multi-architecture support that building from source does. As a result, this is heavily scrutinized during human review and only accepted as a last resort.</p>
<p>Even with the above, the vast majority of apps are built reproducibly from
source on Flathub’s infrastructure. The handful of apps that aren’t still
greatly benefit from the transparency and auditability built into all of the
other layers.</p>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="incident-response">Incident Response<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#incident-response" title="Direct link to Incident Response"></a></h2>
<p>While we expect to catch the vast majority of safety issues with the above, we are also able to respond to anything that may have slipped through. For example, we have the ability to remove an app from the Flathub remote in case we find that it’s malicious. We can also revert, recall, or block broken or malicious app updates.</p>
<p>We take security reports and legal issues very seriously; please <a href="mailto:admins@flathub.org" rel="noopener noreferrer" target="_blank">contact the Flathub admins</a> to report an issue, or <a href="https://matrix.to/#/#flathub:matrix.org" rel="noopener noreferrer" target="_blank">chat with us on Matrix</a>.</p>
<hr/>
<h2 class="anchor anchorWithStickyNavbar_LWe7" id="in-summary">In Summary…<a class="hash-link" href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user#in-summary" title="Direct link to In Summary…"></a></h2>
<p>As you can see, Flathub takes safety very seriously. We’ve worked with the greater Linux and FreeDesktop ecosystem for <em>over a decade</em> on efforts such as Flatpak, OSTree, Portals, and even desktop environments and app store clients to help build the best app distribution experience—for both users and app developers—with safety as a core requirement. We believe our in-depth, multi-layered approach to safety has set a high bar that few others have met—and we will continue to raise it.</p>
<p>Thank you to all contributors to Flatpak, Flathub, and the technologies
our ecosystem relies on. Thanks to the thousands of developers for
trusting us with app distribution, and to bbhtt, Jordan, and Sonny for
reviewing this post. And as always, thank you to the millions of users
trusting Flathub as your source of apps on Linux. ♥</p></div>
</content>
<updated>2025-02-21T00:00:00Z</updated>
<published>2025-02-21T00:00:00Z</published>
<category term="moderation"/>
<category term="safety"/>
<category term="permissions"/>
<category term="review"/>
<source>
<id>https://docs.flathub.org/blog</id>
<author>
<name>Flathub Blog</name>
</author>
<link href="https://docs.flathub.org/blog" rel="alternate" type="text/html"/>
<link href="https://docs.flathub.org/blog/rss.xml" rel="self" type="application/rss+xml"/>
<subtitle>Flathub Documentation Blog</subtitle>
<title>Flathub Documentation Blog</title>
<updated>2025-02-21T00:00:00Z</updated>
</source>
</entry>
<entry xml:lang="en-US">
<id>https://blogs.gnome.org/alatiera/?p=5123</id>
<link href="https://blogs.gnome.org/alatiera/2025/02/19/the-fedora-project-leader-is-willfully-ignorant-about-flathub/" rel="alternate" type="text/html"/>
<title>The Fedora Project Leader is willfully ignorant about Flathub</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Update 1: Cassidy wrote a much more comprehensive and well written explanation about the review guidelines, permission, Flathub infrastructure and other things discussed in this post. I highly recommend you check it out. Update 2: A couple people mentioned that the mystery hardware survey application was indeed Hardware Probe. Miller actually opened a thread on … <a class="more-link" href="https://blogs.gnome.org/alatiera/2025/02/19/the-fedora-project-leader-is-willfully-ignorant-about-flathub/">Continue reading <span class="screen-reader-text">The Fedora Project Leader is willfully ignorant about Flathub</span></a></div>
</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Update 1: <a href="https://cassidyjames.com/">Cassidy</a> wrote a much more comprehensive and well written explanation about the review guidelines, permission, Flathub infrastructure and other things discussed in this post. I highly recommend you <a href="https://docs.flathub.org/blog/app-safety-layered-approach-source-to-user">check it out</a>.</p>
<p>Update 2: A couple people mentioned that the mystery hardware survey application was indeed Hardware Probe. Miller actually opened a thread on Flathub’s <a href="https://discourse.flathub.org/t/please-remove-hardware-probe-it-is-not-a-desktop-application-and-has-surprising-network-activity/1803">discourse</a> about it. At the time it was a terminal application and due to a <a href="https://gitlab.gnome.org/GNOME/gnome-software/-/issues/552">bug</a> that affected gnome-software, the confirmation prompt was getting skipped. This wasn’t affecting other store fronts or launching from the the application grid.</p>
<p>Now to the original post:</p>
<p>Today I woke up to a link of an <a href="https://www.youtube.com/watch?v=oKP1hgdFJKo">interview</a> from the current Fedora Project Leader, Matthew Miller. Brodie who conducted the interview mentioned that Miller was the one that reached out to him. The background of this video was the currently ongoing issue regarding OBS, Bottles and the Fedora project, which Niccolò made an <a href="https://youtu.be/o2qd2RFC6Fk">excellent video</a> explaining and summarizing the situation. You can also find the article over at <a href="https://thelibre.news/why-obs-and-bottles-got-in-a-fight-with-fedora/">thelibre.news</a>. “Impressive” as this story is, it’s for another time.</p>
<p>What I want to talk in this post, is the outrageous, smearing and straight up slanderous statements about Flathub that the Fedora Project Leader made during the interview..</p>
<p>I am not directly involved with the Flathub project (A lot of my friends are), however I am a maintainer of the GNOME Flatpak Runtime, and a contributor to the Freedesktop-sdk and ElementaryOS Runtimes. I also maintain applications that get published on Flathub directly. So you can say I am someone invested in the project and that has put a lot of time into it. It was extremely frustrating to hear what would only qualify as reddit-level completely made up arguments with no base in reality coming directly from Matthew Miller.</p>
<p>Below is a transcript, slightly edited for brevity, of all the times Flathub and Flatpak was mentioned. You can refer to the <a href="https://www.youtube.com/watch?v=oKP1hgdFJKo">original video</a> as well as there were many more interesting things Miller talked about.</p>
<p>It starts off with an introduction and some history and around the 10-minute mark, the conversation starts to involve Flathub.</p>
<blockquote><p>Miller: [..] long way of saying I think for something like OBS we’re not really providing anything by packaging that. Miller: I think there is an overall place for the Fedora Flatpaks, because Flathub part of the reason its so popular (there’s a double edged sword), (its) because the rules are fairly lax about what can go into Flathub and the idea is we want to make it as easy for developers to get their things to users, but there is not really much of a review</p></blockquote>
<p>This is not the main reason why Flathub is popular, its a lot more involved and interesting in practice. I will go into this in a separate post hopefully soon.</p>
<p>Claiming that Flathub does not have any review process or inclusion policies is straight up wrong and incredibly damaging. It’s the kind of thing we’ve heard ad nauseam from Flathub haters, but never from a person in charge of one of the most popular distributions and that should have <strong>really really known better</strong>.</p>
<p>You can find the <a href="https://docs.flathub.org/docs/for-app-authors/requirements">Requirements</a> in the Flathub documentation if you spend 30 seconds to google for them, along with the submission <a href="https://docs.flathub.org/docs/for-app-authors/submission/">guidelines</a> for developers. If those documents qualify as a wild west and free for all, I can’t possibly take you seriously.</p>
<p>I haven’t maintained a linux distribution package myself so I won’t go to comparisons between Flathub and other distros, however you can find people, with red hats even, <a href="https://social.vivaldi.net/@sesivany/114030210735848325">that do so and talked about it</a>. Of course this is one off examples and social bias from my part. But it proves how laughable of a claim is that things are not reviewed. Additionally, the most popular story I hear from developers is how Flathub requirements are often stricter and sometimes cause annoyances.</p>
<figure class="wp-caption aligncenter" id="attachment_5127" style="width: 747px;"><a href="https://social.vivaldi.net/@sesivany/114030210735848325"><img alt="" class="size-full wp-image-5127" height="1557" src="https://blogs.gnome.org/alatiera/files/2025/02/Screenshot-2025-02-19-at-23-50-27-Jiri-Eischmann-@okias-@barthalion-I-maintain-…-Vivaldi-Social.png" width="747"/></a><figcaption class="wp-caption-text" id="caption-attachment-5127">Screenshot of the post from this link: https://social.vivaldi.net/@sesivany/114030210735848325</figcaption></figure>
<p>Additionally, Flathub has been the driving force behind encouraging applications to update their metadata, completely reworking the User Experience and handling off permissions and made them prominent to the user. (To the point where even network access is marked as potentially-unsafe).</p>
<blockquote><p>Miller: [..] the thing that says verified just says that it’s verified from the developer themselves.</p></blockquote>
<p>No, verified does not mean that the developer signed off into it. Let’s take another 30 seconds to look into the Flathub <a href="https://docs.flathub.org/docs/for-users/verification">documentation page</a> about exactly this.</p>
<blockquote><p>A verified app on Flathub is one whose developer has confirmed their ownership of the app ID […]. This usually also may mean that either the app is maintained directly by the developer or a party authorized or approved by them.</p></blockquote>
<p>It still went through the review process and all the rest of requirements and policies apply. The verified program is basically a badge to tell users this is a supported application by the upstream developers, rather than the free for all that exists currently where you may or may not get an application released from years ago depending on how stable your distribution is.</p>
<p>Sidenote, did you know that 1483/3003 applications on Flathub are verified as of the writing of this post? As opposed to maybe a dozen of them at best in the distributions. You <a href="https://gitlab.gnome.org/-/snippets/6791">can check</a> for yourself</p>
<blockquote><p>Miller: .. and it doesn’t necessarily verify that it was build with good practices, maybe it was built in a coffee shop on some laptop or whatever which could be infected with malware or whatever could happen</p></blockquote>
<p>Again if Miller had done the bare minimum effort, he would have come across the <a href="https://docs.flathub.org/docs/for-app-authors/requirements">Requirements</a> page which describes exactly how an Application in Flathub is built, instead of further spreading made up takes about the infrastructure. I can’t stress enough how damaging it has been throughout the years to claim that “Flathub may be potential Malware”. Why it’s malware? Because I don’t like its vibes and I just assume so..</p>
<p>I am sure If I did the same about Fedora in a very very public medium with thousand of listeners I would probably end up with a Layers letter from Redhat.</p>
<p>Now Applications in Flathub are all built without a network access, in Flathub’s build servers, using flatpak-builder and Flatpak Manifests which are a declarative format, which means all the sources required to build the application are known, validated/checksumed, the build is reproducible to the extend possible, you can easily inspect the resulting binaries and the manifest itself used to build the application ends up in <code>/app/manifest.json</code> which you can also inspect with the following command and use it to rebuild the application yourself exactly like how it’s done in Flathub.</p>
<div class="sourceCode" id="cb1">
<pre class="sourceCode bash"><code class="sourceCode bash"><span id="cb1-1"><span class="ex">$</span> flatpak run <span class="at">--command</span><span class="op">=</span>cat org.gnome.TextEditor /app/manifest.json</span>
<span id="cb1-2"><span class="kw">{</span></span>
<span id="cb1-3"> <span class="st">"id"</span> : <span class="st">"org.gnome.TextEditor"</span>,</span>
<span id="cb1-4"> <span class="st">"runtime"</span> : <span class="st">"org.gnome.Platform"</span>,</span>
<span id="cb1-5"> <span class="st">"runtime-version"</span> : <span class="st">"47"</span>,</span>
<span id="cb1-6"> <span class="st">"runtime-commit"</span> : <span class="st">"d93ca42ee0c4ca3a84836e3ba7d34d8aba062cfaeb7d8488afbf7841c9d2646b"</span>,</span>
<span id="cb1-7"> <span class="st">"sdk"</span> : <span class="st">"org.gnome.Sdk"</span>,</span>
<span id="cb1-8"> <span class="st">"sdk-commit"</span> : <span class="st">"3d5777bdd18dfdb8ed171f5a845291b2c504d03443a5d019cad3a41c6c5d3acd"</span>,</span>
<span id="cb1-9"> <span class="st">"command"</span> : <span class="st">"gnome-text-editor"</span>,</span>
<span id="cb1-10"> <span class="st">"modules"</span> : [</span>
<span id="cb1-11"> <span class="kw">{</span></span>
<span id="cb1-12"><span class="ex">...</span></span></code></pre>
</div>
<p>The exception to this, are proprietary applications naturally, and a handful of applications (under an OSI approved license) where Flathub developers helped the upstream projects integrate a direct publishing workflow into their Deployment pipelines. I am aware of Firefox and OBS as the main examples, both of which publish in Flathub through their Continues Deployment (CI/CD) pipeline the same way they generate their builds for other platforms they support and the code for how it happens is available on their repos.</p>
<p>If you have issues trusting Mozilla’s infrastructure, then how are you trusting Firefox in the first place and good luck auditing gecko to make sure it does not start to ship malware. Surely distribution packagers audit every single change that happens from release to release for each package they maintain and can verify no malicious code ever gets merged. The <a href="https://lwn.net/Articles/967180/">xz backdoor</a> was very recent, and it was identified by pure chance, none of this prevented it.</p>
<p>Then Miller proceeds to describe the Fedora build infrastructure and afterward we get into the following:</p>
<blockquote><p>Miller: I will give an example of something I installed in Flathub, I was trying to get some nice gui thing that would show me like my system Hardware stats […] one of them ones I picked seemed to do nothing, and turns out what it was actually doing, there was no graphical application it was just a script, it was running that script in the background and that script uploaded my system stats to a server somewhere.</p></blockquote>
<p>Firstly we don’t really have many details to be able to identify which application it was, I would be very curious to know. Now speculating on my part, the most popular application matching that description it’s Hardware Probe and it absolutely has a GUI, no matter how minimal. It also asks you before uploading.</p>
<p>Maybe there is a org.upload.MySystem application that I don’t know about, and it ended up doing what was in the description, again I would love to know more and update the post if you could recall!</p>
<blockquote><p>Miller: No one is checking for things like that and there’s no necessarily even agreement that that was was bad.</p></blockquote>
<p>Second time! Again with the “There is no review and inclusion process in Flathub” narrative. There absolutely is, and these are the kinds of things that get brought up during it.</p>
<blockquote><p>Miller: I am not trying to be down on Flathub because I think it is a great resource</p></blockquote>
<p>Yes, I can see that, however in your ignorance you were something much worse than “Down”. This is pure slander and defamation, coming from the current “Fedora Project Leader”, the “Technically Voice of Fedora” (direct quote from a couple seconds later). All the statements made above are manufactured and inaccurate. Myths that you’d hear from people that never asked, looked or cared about any of these cause the moment you do you its obvious how laughable all these claims are.</p>
<blockquote><p>Miller: And in a lot of ways Flathub is a competing distribution to Fedora’s packaging of all applications.</p></blockquote>
<p>Precisely, he is spot on here, and I believe this is what kept Miller willfully ignorant and caused him to happily pick the first anit-flatpak/anti-flathub arguments he came across on reddit and repeat the verbatim without putting any thought into it. I do not believe Miller is malicious on purpose, I do truly believe he means well and does not know better.</p>
<p>However, we can’t ignore the conflict that arises from his current job position as an big influence to why incidents like this happened. Nor the influence and damage this causes when it comes from a person of Matthew Miller’s position.</p>
<p>Moving on:</p>
<blockquote><p>Miller: One of the other things I wanted to talk about Flatpak, is the security and sandboxing around it. Miller: Like I said the stuff in the Flathub are not really reviewed in detail and it can do a lot of things:</p></blockquote>
<p>Third time with the no review theme. I was fuming when I first heard this, and I am very very angry about still, If you can’t tell. Not only is this an incredibly damaging lie as covered above, it gets repeated over and over again.</p>
<blockquote><p>With Flatpak basically the developer defines what the permissions are. So there is a sandbox, but the sandbox is what the person who put it there is, and one can imagine that if you were to put malware in there you might make your sandboxing pretty loose.</p></blockquote>
<blockquote><p>Brodie: One of the things you can say is “I want full file system access, and then you can do anything”</p></blockquote>
<p>No, again it’s stated in the Flathub documentation, permissions are very carefully reviewed and updates get blocked when permissions change until another review has happened.</p>
<blockquote><p>Miller: Android and Apple have pretty strong leverage against application developers to make applications work in their sandbox</p>
<p>Brodie: the model is the other way around where they request permissions and then the user grants them whereas Flatpak, they get the permission and then you could reject them later</p></blockquote>
<p>This is partially correct, the first part about leverage will talk about in a bit, but here’s a primer on how permissions work in Flatpak and how it compares to the sandboxing technologies in iOS and Android.</p>
<p>In all of them we have a separation between Static and Dynamic permissions. Static are the ones the application always has access to, for example the network, or the ability to send you notifications. These are always there and are mentioned at install time usually. Dynamic permissions are the ones where the application has to ask the user before being able to access a resource. For example opening a file chooser dialog so the user can upload a file, the application the only gets access to the file the user consented or none. Another example is using the camera on the device and capturing photos/video from it.</p>
<p>Brodie here gets a bit confused and only mentions static permissions. If I had to guess it would be cause we usually refer to the dynamic permissions system in the Flatpak world as “Portals”.</p>
<blockquote><p>Miller: it didn’t used to be that way and and in fact um Android had much weaker sandboxing like you could know read the whole file system from one app and things like that […] they slowly tightened it and then app developers had to adjust Miller: I think with the Linux ecosystem we don’t really have the way to tighten that kind of thing on app developers … Flatpak actually has that kind of functionality […] with portals […] but there’s no not really a strong incentive for developers to do that because, you know well, first of all of course my software is not going to be bad so why should I you know work on sandboxing it, it’s kind of extra work and I I don’t know I don’t know how to solve that. I would like to get to the utopian world where we have that same security for applications and it would be nice to be able to install things from completely untrusted places and know that they can’t do anything to harm your system and that’s not the case with it right now</p></blockquote>
<p>As with any technology and adoption, we don’t get to perfection from day 1. Static permissions are necessary to provide a migration path for existing applications and until you have developed the appropriate and much more complex dynamic permissions mechanisms that are needed. For example up until iOS 18 it wasn’t possible to give applications access to a subset of your contacts list. Think of it like having to give access your entire filesystem instead of the specific files you want. Similarly partial-only access to your photos library arrived couple years ago in IOS and Android.</p>
<p>In an ideal world all permissions are dynamic, but this takes time and resources and adaptation for the needs of applications and the platform as development progresses.</p>
<p>Now about the leverage part.</p>
<p>I do agree that “the Linux ecosystem” as a whole does not have any leverage on applications developers. This is cause Miller is looking at the wrong place for it. <a href="https://blogs.gnome.org/tbernard/2019/12/04/there-is-no-linux-platform-1/">There is no Linux ecosystem</a> but rather Platforms developers target.</p>
<p>GNOME and KDE, as they distribute all their applications on Flathub absolutely have leverage. Similarly Flathub itself has leverage by changing the publishing requirements and inclusion guidelines. Which I kept being told they don’t exist.. Every other application that wants to publish also has to adhere by the rules on Flathub. ElementaryOS and their Appcenter has leverage on developers. Canonical does have the same pull as well with the Snapstore. Fedora on the other hand doesn’t have any leverage cause the Fedora Flatpak repository is <a href="https://thelibre.news/why-obs-and-bottles-got-in-a-fight-with-fedora/">irrelevant, broken and nobody wants to use it</a>.</p>
<p>[..] The <a href="https://lwn.net/Articles/967180/">xz backdoor</a> gets brought up when discussing dependencies and how software gets composed together.</p>
<blockquote><p>Miller: we try to keep all of those things up to date and make sure everything is patched across the dist even when it’s even when it’s difficult. I think that really is one of the best ways to keep your system secure and because the sandboxing isn’t very strong that can really be a problem, you know like the XZ thing that happened before. If XZ is just one place it’s not that hard of an update but if you’ve got a 100 Flatpaks from different places […] and no consistency to it it’s pretty hard to manage that</p></blockquote>
<p>I am not going to get in depth about this problem domain and the arguments over it. In fact I have been writing another blog post for a while. I hope to publish shortly. Till then I can not recommend high enough <a href="https://www.bassi.io/articles/2017/08/10/dev-v-ops/">Emmanuele’s</a> and <a href="https://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html">Lennart’s</a> blog posts, as well as one of the very <a href="https://blogs.gnome.org/alexl/2011/09/30/rethinking-the-linux-distibution/">early posts</a> from Alex when Flatpak was in early design phase on the shortcomings of the current distribution model.</p>
<p>Now about bundled dependencies. The concept of Runtimes has served us well so far, and we have been doing a pretty decent job providing most of the things applications need but would not want to bundle themselves. This makes the Runtimes a single place for most of the high profile dependencies (curl, openssl, webkitgtk and so on) that you’d frequently update for security vulnerabilities and once it’s done they roll out to everyone without needing to do anything manual to update the applications or even rebuilt them.</p>
<p>Applications only need to bundle their direct dependencies,and as mentioned above, the flatpak manifest includes the exact definition of all of them. They are available to anyone to inspect and there’s tooling that can scan them and hopefully in the future alert us.</p>
<p>If the Docker/OCI model where you end bundling the entire toolchain, runtime, and now you have to maintain it and keep up with updates and rebuild your containers is good enough for all those enterprise distributions, then the Flatpak model which is much more efficient, streamlined and thought out and much much much less maintenance intensive, it is probably fine.</p>
<blockquote><p>Miller: part of the idea of having a distro was to keep all those things consistent so that it’s easier for everyone, including the developers</p></blockquote>
<p>As mentioned above, nothing that fundamentally differs from the leverage that Flathub and the Platform Developers have.</p>
<blockquote><p>Brodie: took us 20 minutes to get to an explanation [..] but the tldr Fedora Flatpak is basically it is built off of the Fedora RPM build system and because that it is more well tested and sort of intended, even if not entirely for the Enterprise, designed in a way as if an Enterprise user was going to use it the idea is this is more well tested and more secure in a lot of cases not every case.<br/>
Miller: Yea that’s basically it</p></blockquote>
<p>This is a question/conclusion that Brodie reaches with after the previous statements and by far the most enraging thing in this interview. This is also an excellent example of the damage Matthew Miller caused today and if I was a Flathub developer I would stop on nothing sort of a public apology from the Fedora project itself. Hell I want this just being an application developer that publishes on it. The interview has been basically shitting on both the Developers of Flathub <strong>and</strong> the people that choose to publish in it. And if that’s not enough there should be an apology just out of decency. Dear god..</p>
<blockquote><p>Brodie: how should Fedora handle upstreams that don’t want to be packaged like the OBS case here where they did not want there to be a package in Fedora Flatpak or another example is obviously bottles which has made a lot of noise about the packaging</p></blockquote>
<p>Lastly I want to touch on this closing question in light of recent events.</p>
<blockquote><p>Miller: I think we probably shouldn’t do it. We should respect people’s wishes there. At least when it is an open source project working in good faith there. There maybe some other cases where the software, say theoretically there’s somebody who has commercial interests in some thing and they only want to release it from their thing even though it’s open source. We might want to actually like, well it’s open source we can provide things, we in that case we might end up you having a different name or something but yeah I can imagine situations where it makes sense to have it packaged in Fedora still but in general especially and when it’s a you know friendly successful open source project we should be friendly yeah. The name thing is something people forget history like that’s happened before with Mozilla with Firefox and Debian.</p></blockquote>
<p>This is an excellent idea! But it gets better:</p>
<blockquote><p>Miller: so I understand why they strict about that but it was kind of frustrating um you know we in Fedora have basically the same rules if you want to take Fedora Linux and do something out of it, make your own thing out of it, put your own software on whatever, you can do that but we ask you not to call it Fedora if it’s a fedora remix brand you can use in some cases otherwise pick your own name it’s all open source but you know the name is ours. yeah and I the Upstream as well it make totally makes sense.</p>
<p>Brodie: yeah no the name is completely understandable especially if you do have a trademark to already even if you don’t like it’s it’s common courtesy to not name the thing the exact same thing</p>
<p>Miller: yeah I mean and depending on the legalities like you don’t necessarily have to register a trademark to have the trademark kind of protections under things so hopefully lawyers you can stay out of the whole thing because that always makes the situations a lot more complicated, and we can just get along talking like human beings who care about making good software and getting it to users.</p></blockquote>
<p>And I completely agree with all of these, all of it. But let’s break it down a bit because no matter how nice the words and intentions it hasn’t been working out this way with the Fedora community so far.</p>
<p>First, Miller agrees the Fedora project should be respecting of application developer’s wishes to not have their application distributed by fedora but rather it be a renamed version if Fedora wishes to keep distributing it.</p>
<p>However, every single time a developer has asked for this, they have been ridiculed, laughed at and straight up bullied by Fedora packagers and the rest of the Fedora community. It has been a similar response from other distribution projects and companies as well, it’s not just Fedora. You can look at <a href="https://thelibre.news/why-obs-and-bottles-got-in-a-fight-with-fedora/">Bottle’s story</a> for the most recent example. It is very nice to hear Miller’s intentions but means nothing in practice.</p>
<p>Then Miller proceeds to assure us why he understand that naming and branding is such a big deal to those projects (unlike the rest of the Fedora community again). He further informs us how Fedora has the exact same policies and asks from people that want to fork Fedora. Which makes the treatment that every single application developer has received when asking about the same exact thing ever more outrageous.</p>
<p>What I didn’t know is that in certain cases you don’t even need to have a trademark yet to be covered by some of the protections, depending on jurisdiction and all.</p>
<p>And last we come into lawyers. Neither Fedora nor application developers would want it to ever come to this, and it was stated multiple times by Bottles developers that they don’t want to have to file for a trademark so they can be taken seriously. Similarly, OBS developers said how resorting to legal action would be the last thing they would want to do and would rather have the issue resolved before that. But it took until OBS, a project of a high enough profile, with the resources required to acquire a trademark and to threaten legal action before the Fedora Leadership cared to treat application developers like human beings and get the Fedora packagers and community members to comply. (Something which they had stated multiple times they simply couldn’t do).</p>
<p>I hate all of this. Fedora and all the other distributions need to do better. They all claim to care about their users but happily keep shipping broken and miss configured software to them over the upstream version, just cause it’s what aligns with their current interests. In this case is the promotion of Fedora tooling and Fedora Flatpaks over the application in Flathub they have no control over. In previous incidents it was about <a href="https://pagure.io/fedora-workstation/issue/351">branding applications</a> like the rest of the system even though it was making them unusable. And I can find you and list you with a bunch of examples from other distributions just as easily.</p>
<p>They don’t care about their users, they care about their bottom line first and foremost. Any civil attempts at fixing issues get ignored and laughed at, up until there is a threat of a legal action or a big enough PR damage, drama and shitshow that they can’t ignore it anymore and have to backtrack on them.</p>
<p>This is my two angry cents. Overall I am not exactly sure how Matthew Miller managed in a rushed and desperate attempt at damage control for the OBS drama, to not only to make it worse, but to piss off the entire Flathub community at the same time. But what’s done is done, let’s see what we can do to address the issues that have festered and persisted for years now.</p></div>
</content>
<updated>2025-02-19T21:53:02Z</updated>
<published>2025-02-19T21:53:02Z</published>
<author>
<name>Jordan Petridis</name>
</author>
<source>
<id>https://blogs.gnome.org/alatiera</id>
<link href="https://blogs.gnome.org/alatiera/feed/" rel="self" type="application/rss+xml"/>
<link href="https://blogs.gnome.org/alatiera" rel="alternate" type="text/html"/>
<subtitle>Just another GNOME Blogs site</subtitle>
<title>Rust in Peace</title>
<updated>2025-02-23T16:17:22Z</updated>
</source>
</entry>
<entry>
<id>https://ergaster.org/til/gdocs-preview-suggestions/</id>
<link href="https://ergaster.org/til/gdocs-preview-suggestions/" rel="alternate" type="text/html"/>
<title>TIL that Google Docs can preview suggestions</title>
<summary>Most of our organizational and operational knowledge at work is stored in a Bookstack instance that we completely control. Bookstack is a great tool for this purpose, but it's not a silver bullet when it comes to document editing. Its most notable limitation is that it doesn't handle concurrent editing really well.</summary>
<content type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><p>Most of our organizational and operational knowledge at work is stored in a <a href="https://www.bookstackapp.com/">Bookstack</a> instance that we completely control. Bookstack is a great tool for this purpose, but it's not a silver bullet when it comes to document editing. Its most notable limitation is that it doesn't handle concurrent editing really well.</p>
<p>I self-host a <a href="https://hedgedoc.org/">HedgeDoc</a> instance for my personal needs, but it also has its own limits. It only supports markdown and it doesn't support fine grained permissions to different files.</p>
<p>I spent some time looking for alternatives, but Google Docs is hands down the best collaborative document editing suites out there for whoever has to work with people who are not engineers, at a company scale.</p>
<p>It's far from perfect though. One of its useful features is the "suggestion" mode that lets someone suggest additions/deletions in the document without making any definitive change. The document owner can then review those suggestions and accept or decline them.</p>
<p/>
<p>Suggestions can add up pretty quickly (depending on how nitpicky your reviewer is 🤭) and rapidly make the document unreadable. Fortunately there's a way to preview how the document would look like if all the suggestions got accepted (or declined).</p>
<p/>
<p>This very handy dandy tool is located under the <code>Tools</code> > <code>Review suggested edits</code> menu.</p>
<p/></div>
</content>
<updated>2025-02-18T16:00:00Z</updated>
<published>2025-02-18T16:00:00Z</published>
<source>
<id>https://ergaster.org/</id>
<author>
<name>Thibault Martin</name>
</author>
<link href="https://ergaster.org/" rel="alternate" type="text/html"/>
<link href="https://ergaster.org/rss.xml" rel="self" type="application/rss+xml"/>
<subtitle>On digital citizenship</subtitle>
<title>Thib's Blog</title>
<updated>2025-04-02T07:03:55Z</updated>
</source>
</entry>
<entry>
<id>https://cassidyjames.com/blog/gnome-foot-logo-rebrand/</id>
<link href="https://cassidyjames.com/blog/gnome-foot-logo-rebrand/" rel="alternate" type="text/html"/>
<link href="https://cassidyjames.com/images/blog/gnome-foot-logo-rebrand/foot-dark.png" rel="enclosure" type="image/png"/>
<title>GNOME Should Kick the Foot to the Curb… Mostly</title>
<summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><img src="https://cassidyjames.com/images/blog/gnome-foot-logo-rebrand/foot-dark.png"/>
<aside>
<p><strong>Update:</strong> Thanks for all of the feedback and discussion on Mastodon and Matrix! I’ve revised this post a bit with some more nuance and context based on feedback. I apologize if my writing style was divisive; I wrote the first draft of this post pretty hastily based on some frustrating conversations and wanted to get all my thoughts out into one place rather than retreading the same thoughts in multiple places—but I should have let it cook a bit longer and gotten feedback before firing away and logging off.</p>
<p>Hopefully this latest revision better refelects those thoughts and my desire to have real conversations about them while being a bit less controversial.</p>
</aside>
<p>This past week volunteers working with the GNOME design and engagement teams debuted a brand new <a href="https://gnome.org">GNOME.org</a> website—one that was met largely with one of two reactions:</p>
<ol>
<li>
<p><strong>It’s beautiful and modern, nice work!</strong> and</p>
</li>
<li>
<p><strong>Where is the foot‽</strong></p>
</li>
</ol>
<p>You see, the site didn’t[^logo update] feature the GNOME logo at the top of the page—it just had the word <strong>GNOME</strong>, with the actual logo relegated to the footer. Admittedly, some folks reacted both ways (it’s pretty, but where’s the foot?). To me, it seems that the latter reaction was <em>mostly</em> the sentiment of a handful of long-time contributors who have understandably grown very cozy with the current GNOME logo:</p>
<p><img alt="GNOME Logo, which is a foot" class="card" src="https://cassidyjames.com/images/blog/gnome-foot-logo-rebrand/foot.svg#gh-light-mode-only"/>
<img alt="GNOME Logo, which is a foot (dark version)" class="card" src="https://cassidyjames.com/images/blog/gnome-foot-logo-rebrand/foot-dark.svg#gh-dark-mode-only"/></p>
<p>[^logo update]: <strong>2024-02-14</strong>: I wrote a quick <a href="https://gitlab.gnome.org/Teams/Websites/www.gnome.org/-/merge_requests/28">merge request to use the logo</a> on the website yesterday since I figured someone else would, anyway. I wanted to demonstrate what it would look like (and do it “right” if it was going to happen). That change has since been merged.</p>
<h3 id="why-the-foot">Why the foot?</h3>
<p>The current GNOME logo is a four-toed foot that is sort of supposed to look like a letter G. According to legend (read: my conversations with designers and contributors who have been working with GNOME for more years than I have fingers <em>and</em> toes), it is basically a story of happenstance: an early wallpaper featured footprints in the sand, that was modified into an icon for the menu, that was turned into a sort of logo while being modified to look like the letter G, and then that version was flattened and cleaned up a bit and successfully trademarked by the GNOME Foundation.</p>
<figure>
<p><img alt="Evolution of the logo, 1997–2002" class="card" src="https://cassidyjames.com/images/blog/gnome-foot-logo-rebrand/evolution.png"/></p>
<figcaption>
<p>Graphic <a href="https://floss.social/@downey/113987672472130021">shared by Michael Downey</a> on Mastodon</p>
</figcaption>
</figure>
<p>So, why do people like it? My understanding (and please drop a comment if I’m wrong) is that it often boils down to one or more of:</p>
<ol>
<li>
<p><strong>It’s always been this way</strong>; as long as GNOME has had an official logo, it’s been a variation of the foot.</p>
</li>
<li>
<p><strong>It’s a trademark</strong> so it’s not feasible to change it from a legal or financial perspective.</p>
</li>
<li>
<p><strong>It has personality</strong>, and anything new would run the risk of being bland.</p>
</li>
<li>
<p><strong>It has wide recognition</strong> at least within the open source enthusiast and developer space, so changing it would be detrimental to the brand equity.</p>
</li>
</ol>
<h3 id="whats-the-problem">What’s the problem?</h3>
<p>I’m the first to admit that I don’t find the foot to be a particularly good <em>logo</em>. Over time, I’ve narrowed down my thoughts (and the feedback I’ve heard from others) into a few recurring reasons:</p>
<ol>
<li>
<p><strong>It doesn’t convey anything about the name or project</strong> which by itself may be fine—many logos don’t directly. But it feels odd to have such a bold logo choice that doesn’t directly related to the name “GNOME,” or to any specific aspect of the project.</p>
</li>
<li>
<p><strong>It’s an awkward shape that doesn’t fit cleanly into a square or circle</strong>, especially at smaller sizes (e.g. for a social media avatar or favicon). It’s much taller than it is wide, and it’s lopsided weight-wise. This leads to frustrations from designers when trying to fit the logo into a square or circle space, leading to excessive amounts of whitespace and/or error-prone manual alignment compared to other elements.</p>
</li>
<li>
<p><strong>It is actively off-putting and unappealing</strong> to at least some folks including much of the GNOME design team, newer contributors, people outside the open source bubble—and apparently potentially entire cultures (which has been raised <a href="https://mail.gnome.org/archives/gnome-2-0-list/2001-October/msg00264.html">multiple</a> <a href="https://mail.gnome.org/archives/marketing-list/2008-October/msg00086.html">times</a> over the past 20+ years). Anecdotally, almost everyone new I’ve introduced GNOME to has turned their nose up at the “weird foot,” whether it’s when showing the website or rocking a tee or sticker to support the project. It doesn’t exactly set a great first impression for a community and modern computing platform. And yes, there are a bunch of dumb memes out there about GNOME devs all being foot fetishists which—while I’m not one to shame what people are into—is not exactly the brand image you want for your global, inclusive open source project.</p>
</li>
<li>
<p><strong>It raises the question of what the role of the design team is</strong>: if the design team cannot be allowed to effectively lead the design of the project, what are we even doing? I think this is why the topic feels so existential to me as a member of the design team. User experience design includes the moment someone first interacts with the brand of a product through them actually using it day-to-day—and right now, the design team’s hands are tied for the first half of that journey.</p>
</li>
</ol>
<figure>
<p><img alt="Issues with the foot" src="https://cassidyjames.com/images/blog/gnome-foot-logo-rebrand/issues.png#gh-light-mode-only"/>
<img alt="Issues with the foot (dark)" src="https://cassidyjames.com/images/blog/gnome-foot-logo-rebrand/issues-dark.png#gh-dark-mode-only"/></p>
<figcaption>
<p>The imbalance and complexity make for non-ideal situations</p>
</figcaption>
</figure>
<h3 id="so-what-can-we-do">So what can we do?</h3>
<p>While there are some folks that would push for a <em>complete</em> rebrand of GNOME—name included, I feel like there’s a softer approach we could take to the issue. I would also point out that the <em>vast majority</em> of people using GNOME—those on Ubuntu, RHEL, Fedora, Endless OS, Debian, etc.—are not seeing the foot anywhere. They’re seeing their distro’s logo, and for many, are using using e.g. “Ubuntu” and may not even be aware they’re using GNOME.</p>
<p>Given all of the above, I propose that a path forward would be to:</p>
<ol>
<li>
<p><strong>Phase the foot out from any remaining user-facing spaces</strong> since it’s hard to work with in all of the contexts we need to use a logo, and it’s not particularly attractive to new users or welcoming to potential contributors—something we need to keep in mind as an aging open source project. This has been an unspoken natural phenomenon as members of the GNOME design team have soured a bit on trying to make designs look nice while accommodating the foot; as a result we have started to see less prominent usage of the foot e.g. on <a href="https://release.gnome.org">release notes</a>, <a href="https://circle.gnome.org">GNOME Circle</a>, <a href="https://thisweek.gnome.org">This Week in GNOME</a>, the <a href="https://handbook.gnome.org">GNOME Handbook</a>, the new website (before it was re-added), and in other spaces where the people doing the design work aren’t the most fond of it.</p>
</li>
<li>
<p><strong>Commission a new brand logo</strong> to represent GNOME to the outside world; this would be the logo you’d expect to see at GNOME.org, on user-facing social media profiles, on event banners, on merch, etc. We’ve been mulling ideas over in the design team for literal years at this point, but it’s been difficult to pursue anything seriously without attracting very loud negative feedback from a handful of folks—perhaps if it is part of a longer-term plan explicitly including the above steps, it could be something we’d be able to pursue. <strong>And it could still be something quirky, cute, and whimsical!</strong> I personally don’t love the idea of something super generic as a logo—I think something that connects to “gnomes,” our history, and/or our modern illustration style would be great here. But importantly, it would need to be designed with the intent of its modern usage in mind, e.g. working well at small sizes, in social media avatars, etc.</p>
</li>
<li>
<p><strong>Refresh the official GNOME brand guidelines</strong> by explicitly including our modern use of color, animation, illustrations, and recurring motifs (like the amazing wallpapers from Jakub!). This is something that has <em>sort of</em> started happening naturally, e.g. with the web team’s newer web designs and as the design team made the decision to move to Inter-based Adwaita Sans for the user interface—and this push continues to receive positive feedback from the community. But much of these efforts have not been reflected in the official project brand guidelines, causing an awkward disconnect between what we <em>say</em> the brand is and how it’s actually widely used and perceived.</p>
</li>
<li>
<p><strong>Immortalize the foot as a mascot</strong>, something to be used in developer documentation, as an easter egg, and perhaps in contributor-facing spaces. It’s much easier to tell newcomers, “oh this is a goofy icon that used to be our logo—we love it, even if it’s kind of silly” without it having to represent the whole project from the outside. It remains a symbol for those “in the know” within the contributor community while avoiding it necessarily representing the <em>entire GNOME brand.</em></p>
</li>
<li>
<p><strong>Stretch goal: title-case Gnome as a brand name</strong>. We’ve long moved past GNOME being an acronym (GNU Network Object Model Environment?)—with a bit of a soft rebrand, I feel we could officially say that it’s spelled “Gnome,” especially if done so in an official logotype. As we know, much like the pronunciation of GNOME itself, folks will do what they want—and they’re free to!—but this would be more about how the brand name is used/styled in an official capacity. I don’t feel super strongly about this one, but it <em>is</em> awkward to have to explain why it’s called GNOME and all caps but not actually an acronym but it used to be—<em>and</em> why the logo is a foot—any time I tell someone what I contribute to. ;)</p>
</li>
</ol>
<h3 id="what-do-you-think">What do you think?</h3>
<p>I genuinely think GNOME as a project and community is in a good place to move forward with modernizing our outward image a bit. Members of the design team like Jamie, kramo, Brage, Jakub, Tobias, Sam, and Allan and other contributors across the project like Alice, Sophie, and probably half a dozen more I am forgetting have been working hard at modernizing our UI and image when it comes to software—<strong>I think it’s time we caught up with the outward brand itself.</strong></p>
<p>Hit me up on Mastodon or any of the links in the footer to tell me if you think I’m right, or if I’ve gotten this all terribly wrong. :)</p>
<aside>
<ul>
<li><strong>2025-02-13:</strong> Edited to correct spelling and grammatical issues and include more graphics.</li>
<li><strong>2025-02-14:</strong> Edited to mention more design contributors</li>
<li><strong>2025-02-14:</strong> Heavily revised to add more context, arguments in favor of the foot, and improve language throughout</li>
</ul>
</aside></div>
</summary>
<updated>2025-02-13T00:00:00Z</updated>
<published>2025-02-13T00:00:00Z</published>
<source>
<id>https://cassidyjames.com/</id>
<author>
<name>Cassidy James Blaede</name>
</author>
<link href="https://cassidyjames.com/" rel="alternate" type="text/html"/>
<link href="https://cassidyjames.com/feed.xml" rel="self" type="application/rss+xml"/>
<subtitle>Building useful, usable, delightful products that respect privacy.</subtitle>
<title>Cassidy James Blaede</title>
<updated>2025-03-26T01:46:02Z</updated>
</source>
</entry>
</feed>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid Atom 1.0" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=https%3A//planet.gnome.org/atom.xml"><img src="valid-atom.png" alt="[Valid Atom 1.0]" title="Validate my Atom 1.0 feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=https%3A//planet.gnome.org/atom.xml

Home · About · News · Docs · Terms