The content outlines activities related to the Vintage Computer Fest Midwest, emphasizing user experiences with Butterknife and Butterbian through polls. It notes upcoming events, links to participant projects, and provides resources for further information, including various YouTube channels and a Discord group for the Linux community.

La Comunidad KDE es una comunidad responsable y no solo se preocupa en lanzar novedades sino que también en mejorarlas. Me complace presentar la primera actualización de KDE Gear 26.08 que apareció hace casi un mes. Más estabilidad, mejores traducciones y pequeñas mejoras para las aplicaciones de nuestro entornos de trabajo.

Primera actualización de KDE Gear 26.08

A pesar de lo que puedan pensar muchas personas, las aplicaciones no son perfectas. Entre las líneas de código se pueden colar errores de tipografía o que el usuario realice alguna opción que en un principio no estaba prevista por los desarrollador, por poner solo un par de ejemplos de imperfecciones.

Este no es un problema del Software Libre ya que el Software actual funciona de esta manera ya que no se piensa en él como un producto final que se encierra en una caja y se olvida. En la actualidad se sabe que el Software está vivo y sería estúpido ir guardando las mejoras sin dejarlas a disposición del gran público.

Con esto se gana en rapidez y evolución pero puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones.

La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses y actualizaciones mensuales para subsanar errores.

Por ello me congratula compartir con vosotros la primera actualización de KDE Gear 26.04 que nos ofrece un buen número de errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.

Aquí podéis encontrar la lista completa de cambios de KDE Gear 26.08.1, pero por poner unos cuantos ejemplos de los errores que sea han resuelto tenemos:

• kdeconnect: Se corrigió la orientación de una flecha dentro del plasmoide (commit; corrige el error #524889).
• kongress: Se corrigió la apertura del mapa de la sala desde una charla (commit).
• okular: Se corrigió un cierre inesperado al guardar documentos (commit; corrige los errores #477153 y #505130).

Más información: KDE Gear 26.08.01

La entrada Primera actualización de KDE Gear 26.08 se publicó primero en KDE Blog.

Tumbleweed es una distribución de GNU/Linux «Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión «rolling release» o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios esta semana.

Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:

• https://victorhck.gitlab.io/tumbleweed_snapshots/

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:

• https://dominique.leuenberger.net/blog/2026/09/tumbleweed-review-of-the-week-2026-37/

Esta semana se han publicado 4 Snapshots  (0904, 0907, 0908, y 0909). Que pueden parecer pocas, pero que actualizan partes muy importantes del sistema, por ejemplo: el kernel, el navegador, la suite ofimática LibreOffice o zypper. Pero veamos el detalle.

Estas son las actualizaciones en más detalle de esta semana:

• bubblewrap 0.12.0
• curl 8.22.0
• expat 2.8.4
• gdm 50.3
• gpg2 2.5.22
• gpgme 2.2.0
• libarchive 3.8.9
• libgcrypt 1.12.3
• LibreOffice 26.8.0.3
• libvirt 12.7.0
• libxml2 2.15.4
• libzypp 17.38.15
• Linux Kernel 7.2.3 & 7.2.4
• Mesa 26.2.2
• MozillaFirefox 155.0 & 155.0.1
• ovmf 202608
• php8 8.5.10
• qemu 11.1.1
• re2c 4.6
• Samba 4.24.6
• SDL3 3.4.16
• wireplumber 0.5.17
• Xen 4.22.0_04
• yast2-bootloader 5.0.42
• zypper 1.14.101

Y para próximas snapshots, ya se están preparando las siguientes actualizaciones:

• Swig 4.5.0
• KDE Plasma 6.7.5
• KDE Frameworks 6.30
• KDE Gear 26.08.1
• fontconfig 2.18.3
• libnettle 4.0.0

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• ¿Por qué deberías utilizar openSUSE Tumbleweed?
• zypper dup en Tumbleweed hace todo el trabajo al actualizar
• ¿Cual es el mejor comando para actualizar Tumbleweed?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

This week saw the release of 4 snapshots (0904, 0907, 0908, and 0909).

It was a swift, steady week of updates, delivering several major items from our recent outlook. Core system elements and desktop utilities kept their momentum, keeping everything fully updated and robust while developers prepare for the major compiler and installer transitions currently brewing in staging.

These 4 snapshots delivered the following updates:

• bubblewrap 0.12.0
• curl 8.22.0
• expat 2.8.4
• gdm 50.3
• gpg2 2.5.22
• gpgme 2.2.0
• libarchive 3.8.9
• libgcrypt 1.12.3
• LibreOffice 26.8.0.3
• libvirt 12.7.0
• libxml2 2.15.4
• libzypp 17.38.15
• Linux Kernel 7.2.3 & 7.2.4
• Mesa 26.2.2
• MozillaFirefox 155.0 & 155.0.1
• ovmf 202608
• php8 8.5.10
• qemu 11.1.1
• re2c 4.6
• Samba 4.24.6
• SDL3 3.4.16
• wireplumber 0.5.17
• Xen 4.22.0_04
• yast2-bootloader 5.0.42
• zypper 1.14.101

As we close out this week’s chapter, here is a sneak peek at what is brewing in the staging projects for the coming days:

• Swig 4.5.0: YaST-related integration issues are still being addressed, tracked under boo#1275515.
• KDE Plasma 6.7.5
• KDE Frameworks 6.30
• KDE Gear 26.08.1
• fontconfig 2.18.3: Still held up as it breaks the AppStream test suite.
• libnettle 4.0.0: Remains explicitly excluded from main staging runs while developers work on resolving test suite breakages in libzypp.

Ayer fue lanzada la beta de Plasma 6.8. Así que, para los que disfruten de probar cosas nuevas es el momento de probar esta versión y reportar los errores que se encuentren. ¡No pierdas la oportunidad de contribuir al desarrollo de Plasma!

Lanzada la beta de Plasma 6.8

Tras los habituales meses de vida, Plasma 6.7empieza ver languidecer su reinado. Es el momento de probar la versión de escritorio que la va a sustituir. En otras palabras, ha sido lanzada la beta de Plasma 6.8 y estas son algunas de sus mejoras extraídas de su changelog, aunque os puedo recomendar la serie Esta Semana en Plasma del blog para verlo a fondo.

• Sustitución del fondo de pantalla predeterminado: El fondo de pantalla Waterfall ha sido reemplazado por la nueva imagen Hanabi en la suite de estilos Breeze.
• Soporte para el calendario nepalí: Se ha añadido compatibilidad con el calendario nepalí (Bikram Sambat) dentro de la applet de calendario alternativo (Alternatecalendar).
• Mejoras en las decoraciones de ventanas GTK4: Se corrigieron problemas como el desbordamiento de botones y la eliminación de esquinas redondeadas inapropiadas en ventanas GTK4 que no utilizan CSD (Client-Side Decorations).
• Compatibilidad con decoraciones solo de sombra: La librería de decoración de ventanas y Breeze añaden soporte nativo para decoraciones basadas únicamente en sombras (shadow-only decorations).
• Avances y rediseño en Discover: Se añadió una nueva función de vista previa de AppStream (AppStream Preview Backend), además de incluir el estado de progreso como una sección ordenable en la lista de tareas.
• Ajustes en el menú de Bluedevil (Bluetooth): Se ha reubicado el botón de configuración para sacarlo del menú tipo hamburguesa, mejorando la accesibilidad para el usuario.
• Integración del buscador en la applet de sesiones de Kate: Se ha sustituido el campo de texto estándar por un campo de búsqueda dedicado (SearchField).
• Centrado de la ubicación en el widget del tiempo: Se ha optimizado el diseño en la applet del clima para centrar la etiqueta con la ubicación dentro del panel superior.
• Rediseño del panel de permisos para Flatpak: La página del módulo de control (KCM) para gestionar los permisos de Flatpak se ha migrado al nuevo formato de formularios (Forms).
• Mejoras en la experiencia de fallos (DrKonqi): Se renovó la interfaz gráfica del visor de volcados de memoria (coredump-gui) a módulos QML y se ajustó el seguimiento para registrar y notificar múltiples bloqueos o cierres inesperados.

Si queréis la lista de cambios completa solo tenéis que ver el changelog.

Más información:KDE

Pruébalo y reporta errores

Todas las tareas dentro del mundo del Software Libre son importantes: desarrollar, traducir, empaquetar, diseñar, promocionar, etc. Pero hay una que se suele pasar por alto y de la que solo nos acordamos cuando las cosas no nos funcionan como debería: buscar errores.

Desde el blog te animo a que tú seas una de las personas responsables del éxito del nuevo lanzamiento de Plasma 6.8 de la Comunidad KDE. Para ello debes participar en la tarea de buscar y reportar errores, algo básico para que los desarrolladores los solucionen para que el despegue del escritorio esté bien pulido. Debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.

Para ello debes instalarte esta beta y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.

La entrada Lanzada la beta de Plasma 6.8 se publicó primero en KDE Blog.

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org. This community blog feed aggregator lists the featured highlights below from Sept. 4 - 10.

This week highlights the SUSE security spotlight covering the combined spring and summer review activity plus a command-injection vulnerability in wicked that allows remote root code execution via DHCP, the fifth bug-fix update of Plasma 6.7 and the release of KDE Frameworks 6.30, an openSUSE version-diff page that covers every package, the wrap-up of openSUSE’s Google Summer of Code, the release of Audacity 4.0, and Packman’s announcement that the repository will be discontinued unless a successor steps up.

Here is a summary and links for each post:

JPEG-XL, AppStream, and Better Media Processing

Matthias Klumpp reports on the AppStream 1.2.0 release, which makes JPEG-XL the new default image export format while redesigning the media processing pipeline with sandboxed workers. The post benchmarks JPEG-XL against PNG on Debian’s icon pool, showing bandwidth savings.

The syslog-ng Insider 2026-09: Performance; Openssl; Containers; Learning

Peter Czanik publishes the 141st issue of the syslog-ng Insider newsletter. It covers performance tuning options that can reach 7 million events per second in lab tests, nightly AlmaLinux-based containers published on Docker Hub, and the status of OpenSSL 4.0 support.

30th update of KDE Frameworks 6 and KCoreAddons library

The KDE Blog announces KDE Frameworks 6.30, the 30th monthly update of the libraries that underpin the KDE project, released on September 10. As part of a year-long series profiling each framework, the post introduces KCoreAddons library, which adds extensions and utilities on top of QtCore, from MIME management and automatic saving to backups, randomness generation and system user information.

The Other WTC Attack

Jakub Steiner shares a short, personal post recalling his 1993 visit to the top of the World Trade Center, unaware at the time that it had been bombed months earlier. He reflects on that 1993 attack, the truck bomb built from around 600 kilograms of homemade explosives plus hydrogen tanks, and how later events gave the story new weight.

SUSE Security Team Spotlight Spring/Summer 2026

The SUSE Security Team blog releases a combined spotlight covering its spring and summer review activity across dozens of D-Bus and Polkit policy rules, from upower and AppArmor’s aa-notify to fwupd and the transactional update notifier. The post also documents file-based root capabilities assigned in packages like cacti-spine’s CAP_NET_RAW and ksystemstats6’s CAP_PERFMON, and revisits the Apptainer setuid starter.

How to Keep a Script Running in the Background with SSH and tmux

Victorhck explains how to launch a script on a remote machine over SSH and keep it running in the background using a tmux session. The tutorial covers creating a named session, detaching with the tmux prefix and ‘d’, reconnecting later with tmux a -t, and closing the session when done.

“35 Years of Linux: 35 Curiosities That Changed Computing” by La Chica de Sistemas

The KDE Blog introduces the YouTuber La Chica de Sistemas, whose channel teaching Linux and Unix system administration it had long wanted to promote. It shares her video celebrating Linux’s 35th anniversary with 35 curiosities about the operating system that changed computing.

One Page, Every Package

The openSUSE News blog presents the openSUSE version diff tool, a machine-built comparison of source package versions across Tumbleweed and the current Leap releases. Pulled directly from the download.opensuse.org archive indexes, the page covers more than 17,500 source packages in a sortable, filterable table with downloadable JSON and CSV exports, categorizing each package as older, newer, equal or exclusive to one release.

Fifth Update of Plasma 6.7

The KDE Blog reports the fifth bug-fix update of Plasma 6.7 released on September 8. It recaps the branch’s recurring highlights such as independent virtual desktops per monitor, microphone volume testing, a light/dark theme switch, lunar calendar integration and print queue management, alongside the fixes in the new point release.

The Packman Repository Will Be Discontinued as of Jan 1, 2027

Victorhck translates the announcement from Packman’s maintainers that after 25 years, the project will be discontinued on January 1, 2027 unless a successor is found. The post recounts the history of the repository, the reasons behind stepping down, including the growth of Flatpak and the workload involved, and what a takeover would require.

Optimizing the sudo Test

Zoltán shares how the openQA sudo test for openSUSE and SLE was cut from about 9 minutes to 3 seconds while gaining broader coverage. He explains running the upstream test suite during the package build, porting functional tests to pytest, and adding a validator that checks the shipped sudoers file against common misconfigurations like targetpw.

Photos as a Substitute for KDE’s Gwenview Image Viewer

Victorhck looks at the Photos application as a substitute for KDE’s default Gwenview image viewer. The post examines what each viewer offers and what users should weigh before switching.

Synchronize the “scroll” in two tabs in the #KDE Kate editor

Victorhck shows how to synchronize the scroll position between two tabs in the KDE editor Kate. Using the View menu, Split View and Toggle Scroll Sync, Kate shows a chain icon and keeps both documents aligned so users can read and compare them together.

This Year’s Google Summer of Code Wrap Up

The openSUSE News blog wraps up the 2026 Google Summer of Code season in which openSUSE mentored eight contributors. Projects ranged from enhancing the git workflow build results page and benchmarking Uyuni on Kubernetes to an AI agent for root cause analysis, an MQTT publisher with Node-RED nodes, Uyuni’s API docs ported to OpenAPI, a new mgrctl get command and native LDAP support.

KDE Express Episode 75: Season 6 plus AkademyES and KDE Gear 26.08

The KDE Blog presents episode 75 of KDE Express, the podcast hosted by David Marzal returning after a hiatus. The episode spotlights Akademy-es 2026, scheduled for October 23-25 in Villaviciosa de Odón, and reviews KDE Gear 26.08 applications like Okular, Dolphin, Konsole and Minuet.

The Hacktivist Collective Autistici/Inventati Closes Its Services

Victorhck reports that after 25 years of providing privacy-preserving services to activists, the collective Autistici/Inventati is closing down. Following the U.S. government’s August 26 designation of the collective as a terrorist organization, it announced on September 6 that continuing to operate would endanger its users.

Audacity 4.0 Released, Renewing the Interface

The KDE Blog announces the release of Audacity 4.0, whose major update rebuilds the interface with Qt, introduces a new clip-based editing model, Guardable workspaces, HiDPI rendering and the new .aup4 project format. It lists the new recording, playback and effects features along with Audacity 3 functions not yet available.

Linux Saloon 218 | News Flight Night

Nathan Wolf posts episode 218 of the technology and Linux podcast and looks at California’s open-source legislation.

So Many Ways to Click and Scroll - This Week in Plasma

The KDE Blog translates this week’s Plasma development report, in which the last Plasma 6.8 features land along with fixes across the 6.6.7, 6.7.5 and 6.8 branches. It covers new ways to click and scroll, plus improvements to Discover, the task manager and other Plasma components.

Tumbleweed - Review of the Week 2026/36

Dominique Leuenberger and Victorhck review the six Tumbleweed snapshots of week 2026/36. Kernel 7.2.2, glibc 2.44, Rust 1.98, QEMU 11.1.0 and LLVM 23.1.0 were among the headline packages delivered to the rolling release.

Best Linux Distros for New Laptops in 2026 (Tested)

LinuxStans ranks seven distributions best suited to brand new laptops that need the freshest kernels, firmware and drivers. Fedora Workstation takes the top recommendation, with openSUSE Tumbleweed second for its rolling kernel updates and openQA snapshot testing, ahead of CachyOS, EndeavourOS, Pop!_OS, Ubuntu 26.04 LTS and Manjaro.

Complete Redesign of KDE Connect for Android

The KDE Blog reports on the complete redesign of KDE Connect for Android, the app that links a phone with Plasma desktops to share notifications, clipboard and files. The refresh brings a renewed visual interface to the app many users rely on daily.

Tiny Wins for Packagers: End-of-Week Update

The Open Build Service blog shares its end-of-week “Tiny Wins” update for packagers. Shipped fixes include preventing an encoding crash when writing YAML to temp files, repairing an osc branch crash for packages with an empty element, and updates to obs-service-node_modules and obs-service-source_validator.

View more blogs or learn to publish your own on planet.opensuse.org.

Yes, we know: version 23 came and went without a blog post. As it has happened before, we were busy enough with several tasks and blogging fell down the priority list. So consider this a two-for-one announcement covering the most relevant changes introduced in both Agama 23 and Agama 24.

But do not expect a long list of shiny new features. During the last months the team poured most of its energy into testing, polishing and fixing corner cases, so this post is a bit more modest than usual. Still, there are a few improvements worth highlighting.

Better interface to configure language and region​

Configuring the internationalization settings -language, keyboard layout and time zone- in previous versions of the web user interface used to require jumping into three separate full-page selectors. Those three settings now live together in a single form, each one as a searchable field that filters the available options as you type.

The matching is accent-insensitive, so typing "ingles" finds "Inglés". The time zone selector even shows the current local time and UTC offset for each entry. A single "Accept" button applies all the changes at once, saving a couple of round trips in the process.

Binding network connections to their devices​

Agama offers the possibility to configure several network connections. Some of those network connections can be associated with a specific network adapter, but telling several similar devices apart used to be tricky when the interface only offered their names and MAC addresses. The web UI now includes a "Browse with details..." option that opens a sortable table listing each device along with its type, IP addresses and connection state, so you can pick the right one with confidence.

In addition, other small improvements regarding the binding of network connections and devices were implemented here and there.

More usability and accessibility improvements​

Beyond the changes already mentioned, this stabilization phase brought a long tail of smaller usability and accessibility refinements scattered across the whole web interface: better keyboard navigation, more consistent forms, clearer wording, improved screen reader support and many other little touches. There are far too many to list here, but together they make the installer noticeably more pleasant to use.

More theming capabilities​

And things are especially pleasant when they feel consistent and in-place. To achieve that, every distribution can restyle the whole installer as explained in our previous blog post about theming Agama. Those styling capabilities keep growing: recent versions expanded the set of customizable roles and refined how the light, dark and high-contrast schemes are handled, giving products even more freedom to make Agama look like their own.

More possibilities to select storage devices​

But the recent Agama improvements go beyond the web user interface. When using JSON to configure the installation, for example in an unattended installation profile, it is often important to define how each individual disk or partition must be processed. That requires a reliable way to identify the devices in the system and to match them against the definitions in the JSON configuration. As you may know, that is done using a search section within each of those definitions.

We recently made those search sections much more expressive. In addition to the logical operators and, or and not to combine and nest conditions, it is now possible to match devices by their kernel driver, by their filesystem (type, label or simply whether they are formatted), by the ID type of a partition and even by the number and content of partitions or logical volumes within a disk or LVM volume group. That allows queries as specific as "the smallest of those NVMe disks that are bigger than 100 GiB and contain an ext4 partition".

Improved AutoYaST compatibility​

Talking about unattended installations, one of the key features of Agama is its ability to consume AutoYaST profiles. Agama reads those profiles and automatically converts them into its own configuration, which is then processed as usual. The latest versions improve that conversion for the network configuration and also handle errors more gracefully while processing AutoYaST profiles, resulting in a more intuitive user experience if some feature is not fully supported by Agama.

More to come​

With this stabilization phase behind us, the team is eager to switch back into a more innovative mode. So we hope the next release will bring a bunch of more exciting features to write about. Stay tuned!

Meanwhile, if you want a closer look at the development of Agama and wish to help shaping its future, you can take a look at the project at GitHub or drop by the #yast channel at Libera.chat.

Two weeks ago, I released AppStream 1.2.0. This release contains a lot of great changes, but one of the most important ones concerns how media are being handled, and AppStream’s default image export format.

AppStream is a Freedesktop metadata standard to describe software components. That can be anything from system services over fonts to console and graphical applications. AppStream metadata is supposed to give users enough information to decide whether they want to install a piece of software, to represent that piece of software, and to give the operating system enough information to decide whether a software component should be installed automatically and (to some extent) what capabilities and relations it has, to provide the user with sensible options.

Especially for the first two goals, and especially for GUI applications, AppStream supports icons and screenshots, which are used to showcase applications. Today, AppStream is used by all kinds of services, from Linux distributions over firmware updates to Flatpak and desktops directly. AppStream’s original design however comes from the perspective of Linux distributions in 2011, where you may want to browse the software catalog offline, without delay, and without pinging an external server (which could be a privacy concern).

Therefore, a common way to deploy an AppStream-enabled software repository is to ship all icons of all applications in the repository to the user as part of the repository metadata download. AppStream does support remote icon downloads nowadays, and for a while I thought that this would become the default eventually. However, especially in today’s world, having a bandwidth-saving, instantly responsive, privacy-protecting application browsing experience seems more important that ever.

PNG images are great!

The only format that AppStream supports for icons and screenshots (which are downloaded on-demand from your distributor’s CDN) has always been exclusively PNG. PNG images are perfect for icons, because they compress well (especially for common icon shapes), are fast and simple to load, and can be loaded anywhere, by any toolkit or webbrowser. They also ensure we deliver faithful screenshot images, even though we may have scaled or re-rendered them. Still though, PNG images are less great for screenshots, as they are not very efficient, which puts strain on any CDN that has to deliver them, as well as on people’s internet connections when browsing screenshots. Having smaller thumbnails alleviates that problem a little, but does not fully solve it.

But even for icons, PNG could be improved upon: In many cases, icons are re-downloaded with the repository metadata again and again, so having a large icon tarball adds up to the data transferred during metadata refreshes. AppStream also now supports large 128x128px icons, which nobody in 2012 expected we would need, adding even more data that will be re-downloaded. Saving some space here translates directly to lower bandwidth costs as well as faster downloads for users.

To improve PNG file sizes, the AppStream Compose library, which handles all image processing and metadata catalog composition, was running optipng on all generated PNG images. That does create smaller PNG images, but they were still relatively large compared to other image formats.

For a long time though, there was no alternative to PNG images for icons: There was no lossless image compression format that could give us the same quality as PNG images and that was also widely supported.

JPEG-XL vs PNG in AppStream

Since 2021 we have JPEG-XL (JXL), which offers a true lossless mode with often better compression than PNG. The issue was that JPEG-XL wasn’t widely supported. Then, in 2025, the PDF Association selected JPEG-XL as the preferred image format for HDR images in PDFs, and now we are finally getting browser support and more ubiquitous availability of the format (you can try it right now in Firefox!).

For screenshots, using JXL’s lossy mode, it has obvious and extreme size advantages over PNG, so supporting JXL or WebP for screenshot images was an obvious choice. If JXL would support the lossless case very well as well though, we could serve many use cases with the same exported image format, which is very attractive to me.

So, the obvious next question was whether it was worth the pain of switching the icon format, so I did some measurements on real icons. For that I used the AppStream component icon pool that Debian Unstable ships, which is almost 5000 application icons of various sizes, and converted them to PNG:

PNG images saved with libpng at effort=4, compression=9, then optimized using optipng -o2, JXL images encoded using vips jxlsave lossless=1 effort=7 strip=1 via VIPS/libjxl.

As the table shows, using lossless JXL images over size-optimized PNG images (using optipng’s default settings) provides a roughly 20% gain. This does not look like much, until you consider how often these files are downloaded: A 20% file size reduction may only save 1-2 MiB of disk space, but if they are downloaded over and over again by many clients, it will save a lot of bandwidth.

Interesting JXL encoding findings

As a sidequest, I was curious why some images were larger than their PNG counterparts when encoded with JXL, and what the ones that were significantly smaller were.

In short, the biggest size reductions for JXL existed on images that were already small as PNG, and contained large, flat color surfaces with hard edges and simple shapes. They were not very interesting, and much of JXL’s wins come from accumulating smaller gains across all files, which compound the bigger icons get (especially at 128x128px, where JXL truly shines).

The events were JXL loses to PNG are more interesting: For example, it does quite poorly with pixel-art images that have a lot of repeating patterns. Those are encoded well by PNG, but less efficiently by JXL. Take for example Vonsh:

My guess is that while PNG can exploit the repeating pixel patterns for compression, JXL’s predicts surrounding pixels from its neighbours, which fails too often and makes it pay almost full entropy per pixel. In this single rare case, the PNG is at 5.4 KiB, while the JXL is almost 8 KiB in size.

Other cases I looked at were arguably buggy input data, where color channels were hidden under the alpha channel of the input image. PNG could probably again exploit repeats, while we were forcing JXL to encode pixels that were invisible in the final image. This is arguably a problem with the original input data. Currently, AppStream does not make any changes to icons at all, but in future we might add a filter that removes invisible colors from images to solve this pathological case (it was only two icons out of 5000 though, so it is not a high priority).

The third case I found where JXL loses to PNG were icons with checkerboard-like patterns:

For those, PNG can likely again exploit the repeating patterns, while a checkerboard layout is pretty bad for left/top predictors like JXL’s. However, in this case the size difference (and loss for JXL) is only 450 bytes, so even though JXL loses to PNG, it does so not by much.

JXL in AppStream

Given these findings, JPEG-XL is the default image format starting with AppStream 1.2.0. AppStream Compose will encode all images losslessly as JXL, while screenshots are encoded in lossy mode at Q=90 effort=7. Since the optipng step does not happen for JXL images, this comes at no speed penalty and is even a bit faster on modern x86_64 CPUs (where libjxl can use SIMD). PNG is still available, and Compose can be told to switch between the two formats.

Upsides of JXL in AppStream right now

If you use JXL in Compose or the recent release of appstream-generator, you will get much smaller images and, for screenshots, will benefit from other JPEG-XL features such as progressive decoding, providing a far nicer user experience. libAppStream has supported JXL icons since version 1.1.3, so your clients will need that version or a newer one, and all software centers will have to support loading JXL images (which all of them do, provided the right plugins are installed).

Downsides of switching to JXL too quickly

JXL is a very new format, so web browsers might not yet display it if you are serving webpages. Your clients may also have bugs in processing JXL images, as the format is still “new”. For example, switching on JXL in Debian sent KDE Discover into an infinite loop on startup while trying to load the icons (an issue which has been fixed, but clients will need that patch first before JXL is switched on).

This currently makes JXL enablement only possible when you know that your clients can support it. This is the case for me in Debian Unstable and Debian 14, which are using JXL images for a few weeks now, but not for any older releases. Platforms like Flatpak have it even harder, because they do know even less about their clients. So, even though it has big advantages, you may want to hold off on using JXL right away, and force PNG by setting the ImageFormat key to png in appstream-generator‘s configuration, or passing --image-format=png to appstreamcli compose.

It is also worth mentioning that JPEG-XL is much, much slower on systems that do not have SIMD instructions or for which the libjxl/jxl-rs library does not have them (such as apparently riscv64 right now). If this is a concern, you might not want to switch to JXL right away.

Media pipeline improvements

Besides the JXL default change, AppStream 1.2.0 also comes with a complete overhaul of its media processing pipeline. While libappstream, AppStream’s main library, does not do any media processing and comes with very minimal dependencies to be embedded in client applications and used on servers, the same can not be said about libappstream-compose, AppStream’s library to build metadata generating applications (the server-side part, usually).

The compose library has to render fonts into font specimen cards, inspect translation files, render SVG images, decode all kinds of raster images, inspect video files, etc. Especially the fonts, and the fact that fonts can appear in SVG images, has caused issues in the past, as libappstream-compose is a heavily threaded library and most font libraries can only work from a single thread. This forced the library to essentially go into single-thread mode anytime anything that could touch a font was being processed.

AppStream also originally was created for a “safe world” where applications were vetted by the distributors before their metadata was processed. This is increasingly not the case, so it made sense to put at least a few guardrails on the most complex part of the pipeline: The media processing. As part of the change, media processing was split out into a separate worker process. This solved two problems at once: Font handling was isolated in a single-threaded binary – if we wanted to handle fonts in parallel, we could simply spawn more workers. And, being in a separate process, the media processing could now be sandboxed.

As part of the multiprocess changes, Compose also switched from using GdkPixbuf to VIPS for image processing. The latter allows for much more fine-grained control over the image output and encoding, and comes with a lot of well-maintained filters and operations, which made it possible to eliminate a fair chunk of AppStream’s hand-rolled image processing operations. As part of this transition, we unfortunately lost the ability to read XPM images, which dropped about 20-30 applications from the pool at Debian. But in the name of security, this is a sensible choice, especially since most XPM icons were very small and low-resolution, and applications using them could benefit from adding a high-quality PNG icon anyway. With VIPS, we also now restrict the amount of image formats we can load to a sensible set, so extremely niche or unexpected formats will be outright rejected (this includes sane-but-unusual formats for screenshots and icons, such as TIFF images).

The Compose library, with all of these changes, will now just request high-level operations (e.g. “render a font card for this font to a JXL image”) from the worker, and provide it with input data in sealed memfds and output locations as FDs as well. On Linux systems, the worker will use Landlock if available, to block all write access to the filesystem, deny device access and deny TCP and UDP as well. The sandbox can certainly be tightened a fair bit in future, but this was a good and safe start to gain some experience with it without having things break too easily, given the many places Compose is used in (also, Landlock’s API is surprisingly nice to use, so it was easier than I thought to add in this early version).

With all of these changes, the libappstream-compose library is now also officially marked API-stable, so you should be able to rely on it in future to build new things (its API has barely changed in the past, and now with the new media API and defaults change in place, it was time to declare it stable).

I want to see / try this!

Currently, the easiest way to have a look at the new data is to check out Debian Unstable. If you have a JXL-enabled browser, you can also see the icons in AppStream Generator’s HTML pages for Debian Sid. If you are using appstream-generator for your distribution, you will also get much more pleasant statistics and HTML pages, as well as fully deterministic media output and a whole bunch of security updates, so, update to its recent 1.0 release.

Please keep in mind that if you switch to JXL, the client tools receiving the image data have to support it. Support varies depending on the Linux distribution, so, test it first and switch the default back to PNG in case you encounter any issues.

What’s next?

With so many features and changes landed, the next changes in AppStream will focus on improving what already exists and fixing any issues (there will be more blogposts about the other features 1.2.x delivers!). Testing with the entire Debian archive as data source makes me fairly confident though that there will not be many problems. In the longer term, tightening the media processing sandbox will also be something we might want to do, e.g. by hiding parts of the filesystem tree or filtering syscalls.

For JPEG-XL, one obvious question is “Will you add support for it to the Freedesktop icon-theme specification as supported format alongside PNG, SVG(Z), and XPM?”. For on-disk icon repositories, JXL’s space-savings are less compelling, and it being HDR-capable is also not necessarily a killer feature (PNG can go a long way!). However, JPEG-XL’s ability to immediately decode larger images at reduced resolution without resampling could legitimately be very powerful here, as applications could ship a single large image and quickly decode it at 1/2, 1/4 or 1/8 the size for different purposes in their UI. JPEG-XL also supports spot-color extra channels, which applications could use as masks to recolor raster icons at render time. This could be incredibly nice to color symbolic icons on-the-fly without any SVG and CSS. JXL also provides richer metadata, which might be neat for (license/author) documentation. So, the answer here is: Maybe it makes sense to allow another format, but this will have to be discussed first, as it would force JXL into every toolkit and desktop, which is a much bigger ask than supporting it only in AppStream.

As always, let me know what you think and please report any issues or bugs directly against AppStream or AppStream Generator if you encounter problems that are with the tools, and not with a project’s metadata.

Two weeks ago, I released AppStream 1.2.0. This release contains a lot of great changes, but one of the most important ones concerns how media are being handled, and AppStream’s default image export format.

AppStream is a Freedesktop metadata standard to describe software components. That can be anything from system services over fonts to console and graphical applications. AppStream metadata is supposed to give users enough information to decide whether they want to install a piece of software, to represent that piece of software, and to give the operating system enough information to decide whether a software component should be installed automatically and (to some extent) what capabilities and relations it has, to provide the user with sensible options.

Especially for the first two goals, and especially for GUI applications, AppStream supports icons and screenshots, which are used to showcase applications. Today, AppStream is used by all kinds of services, from Linux distributions over firmware updates to Flatpak and desktops directly. AppStream’s original design however comes from the perspective of Linux distributions in 2011, where you may want to browse the software catalog offline, without delay, and without pinging an external server (which could be a privacy concern).

Therefore, a common way to deploy an AppStream-enabled software repository is to ship all icons of all applications in the repository to the user as part of the repository metadata download. AppStream does support remote icon downloads nowadays, and for a while I thought that this would become the default eventually. However, especially in today’s world, having a bandwidth-saving, instantly responsive, privacy-protecting application browsing experience seems more important that ever.

PNG images are great!

The only format that AppStream supports for icons and screenshots (which are downloaded on-demand from your distributor’s CDN) has always been exclusively PNG. PNG images are perfect for icons, because they compress well (especially for common icon shapes), are fast and simple to load, and can be loaded anywhere, by any toolkit or webbrowser. They also ensure we deliver faithful screenshot images, even though we may have scaled or re-rendered them. Still though, PNG images are less great for screenshots, as they are not very efficient, which puts strain on any CDN that has to deliver them, as well as on people’s internet connections when browsing screenshots. Having smaller thumbnails alleviates that problem a little, but does not fully solve it.

But even for icons, PNG could be improved upon: In many cases, icons are re-downloaded with the repository metadata again and again, so having a large icon tarball adds up to the data transferred during metadata refreshes. AppStream also now supports large 128x128px icons, which nobody in 2012 expected we would need, adding even more data that will be re-downloaded. Saving some space here translates directly to lower bandwidth costs as well as faster downloads for users.

To improve PNG file sizes, the AppStream Compose library, which handles all image processing and metadata catalog composition, was running optipng on all generated PNG images. That does create smaller PNG images, but they were still relatively large compared to other image formats.

For a long time though, there was no alternative to PNG images for icons: There was no lossless image compression format that could give us the same quality as PNG images and that was also widely supported.

JPEG-XL vs PNG in AppStream

Since 2021 we have JPEG-XL (JXL), which offers a true lossless mode with often better compression than PNG. The issue was that JPEG-XL wasn’t widely supported. Then, in 2025, the PDF Association selected JPEG-XL as the preferred image format for HDR images in PDFs, and now we are finally getting browser support and more ubiquitous availability of the format (you can try it right now in Firefox!).

For screenshots, using JXL’s lossy mode, it has obvious and extreme size advantages over PNG, so supporting JXL or WebP for screenshot images was an obvious choice. If JXL would support the lossless case very well as well though, we could serve many use cases with the same exported image format, which is very attractive to me.

So, the obvious next question was whether it was worth the pain of switching the icon format, so I did some measurements on real icons. For that I used the AppStream component icon pool that Debian Unstable ships, which is almost 5000 application icons of various sizes, and converted them to PNG:

PNG images saved with libpng at effort=4, compression=9, then optimized using optipng -o2, JXL images encoded using vips jxlsave lossless=1 effort=7 strip=1 via VIPS/libjxl.

As the table shows, using lossless JXL images over size-optimized PNG images (using optipng’s default settings) provides a roughly 20% gain. This does not look like much, until you consider how often these files are downloaded: A 20% file size reduction may only save 1-2 MiB of disk space, but if they are downloaded over and over again by many clients, it will save a lot of bandwidth.

Interesting JXL encoding findings

As a sidequest, I was curious why some images were larger than their PNG counterparts when encoded with JXL, and what the ones that were significantly smaller were.

In short, the biggest size reductions for JXL existed on images that were already small as PNG, and contained large, flat color surfaces with hard edges and simple shapes. They were not very interesting, and much of JXL’s wins come from accumulating smaller gains across all files, which compound the bigger icons get (especially at 128x128px, where JXL truly shines).

The events were JXL loses to PNG are more interesting: For example, it does quite poorly with pixel-art images that have a lot of repeating patterns. Those are encoded well by PNG, but less efficiently by JXL. Take for example Vonsh:

My guess is that while PNG can exploit the repeating pixel patterns for compression, JXL’s predicts surrounding pixels from its neighbours, which fails too often and makes it pay almost full entropy per pixel. In this single rare case, the PNG is at 5.4 KiB, while the JXL is almost 8 KiB in size.

Other cases I looked at were arguably buggy input data, where color channels were hidden under the alpha channel of the input image. PNG could probably again exploit repeats, while we were forcing JXL to encode pixels that were invisible in the final image. This is arguably a problem with the original input data. Currently, AppStream does not make any changes to icons at all, but in future we might add a filter that removes invisible colors from images to solve this pathological case (it was only two icons out of 5000 though, so it is not a high priority).

The third case I found where JXL loses to PNG were icons with checkerboard-like patterns:

For those, PNG can likely again exploit the repeating patterns, while a checkerboard layout is pretty bad for left/top predictors like JXL’s. However, in this case the size difference (and loss for JXL) is only 450 bytes, so even though JXL loses to PNG, it does so not by much.

JXL in AppStream

Given these findings, JPEG-XL is the default image format starting with AppStream 1.2.0. AppStream Compose will encode all images losslessly as JXL, while screenshots are encoded in lossy mode at Q=90 effort=7. Since the optipng step does not happen for JXL images, this comes at no speed penalty and is even a bit faster on modern x86_64 CPUs (where libjxl can use SIMD). PNG is still available, and Compose can be told to switch between the two formats.

Upsides of JXL in AppStream right now

If you use JXL in Compose or the recent release of appstream-generator, you will get much smaller images and, for screenshots, will benefit from other JPEG-XL features such as progressive decoding, providing a far nicer user experience. libAppStream has supported JXL icons since version 1.1.3, so your clients will need that version or a newer one, and all software centers will have to support loading JXL images (which all of them do, provided the right plugins are installed).

Downsides of switching to JXL too quickly

JXL is a very new format, so web browsers might not yet display it if you are serving webpages. Your clients may also have bugs in processing JXL images, as the format is still “new”. For example, switching on JXL in Debian sent KDE Discover into an infinite loop on startup while trying to load the icons (an issue which has been fixed, but clients will need that patch first before JXL is switched on).

This currently makes JXL enablement only possible when you know that your clients can support it. This is the case for me in Debian Unstable and Debian 14, which are using JXL images for a few weeks now, but not for any older releases. Platforms like Flatpak have it even harder, because they do know even less about their clients. So, even though it has big advantages, you may want to hold off on using JXL right away, and force PNG by setting the ImageFormat key to png in appstream-generator‘s configuration, or passing --image-format=png to appstreamcli compose.

It is also worth mentioning that JPEG-XL is much, much slower on systems that do not have SIMD instructions or for which the libjxl/jxl-rs library does not have them (such as apparently riscv64 right now). If this is a concern, you might not want to switch to JXL right away.

Media pipeline improvements

Besides the JXL default change, AppStream 1.2.0 also comes with a complete overhaul of its media processing pipeline. While libappstream, AppStream’s main library, does not do any media processing and comes with very minimal dependencies to be embedded in client applications and used on servers, the same can not be said about libappstream-compose, AppStream’s library to build metadata generating applications (the server-side part, usually).

The compose library has to render fonts into font specimen cards, inspect translation files, render SVG images, decode all kinds of raster images, inspect video files, etc. Especially the fonts, and the fact that fonts can appear in SVG images, has caused issues in the past, as libappstream-compose is a heavily threaded library and most font libraries can only work from a single thread. This forced the library to essentially go into single-thread mode anytime anything that could touch a font was being processed.

AppStream also originally was created for a “safe world” where applications were vetted by the distributors before their metadata was processed. This is increasingly not the case, so it made sense to put at least a few guardrails on the most complex part of the pipeline: The media processing. As part of the change, media processing was split out into a separate worker process. This solved two problems at once: Font handling was isolated in a single-threaded binary – if we wanted to handle fonts in parallel, we could simply spawn more workers. And, being in a separate process, the media processing could now be sandboxed.

As part of the multiprocess changes, Compose also switched from using GdkPixbuf to VIPS for image processing. The latter allows for much more fine-grained control over the image output and encoding, and comes with a lot of well-maintained filters and operations, which made it possible to eliminate a fair chunk of AppStream’s hand-rolled image processing operations. As part of this transition, we unfortunately lost the ability to read XPM images, which dropped about 20-30 applications from the pool at Debian. But in the name of security, this is a sensible choice, especially since most XPM icons were very small and low-resolution, and applications using them could benefit from adding a high-quality PNG icon anyway. With VIPS, we also now restrict the amount of image formats we can load to a sensible set, so extremely niche or unexpected formats will be outright rejected (this includes sane-but-unusual formats for screenshots and icons, such as TIFF images).

The Compose library, with all of these changes, will now just request high-level operations (e.g. “render a font card for this font to a JXL image”) from the worker, and provide it with input data in sealed memfds and output locations as FDs as well. On Linux systems, the worker will use Landlock if available, to block all write access to the filesystem, deny device access and deny TCP and UDP as well. The sandbox can certainly be tightened a fair bit in future, but this was a good and safe start to gain some experience with it without having things break too easily, given the many places Compose is used in (also, Landlock’s API is surprisingly nice to use, so it was easier than I thought to add in this early version).

With all of these changes, the libappstream-compose library is now also officially marked API-stable, so you should be able to rely on it in future to build new things (its API has barely changed in the past, and now with the new media API and defaults change in place, it was time to declare it stable).

I want to see / try this!

Currently, the easiest way to have a look at the new data is to check out Debian Unstable. If you have a JXL-enabled browser, you can also see the icons in AppStream Generator’s HTML pages for Debian Sid. If you are using appstream-generator for your distribution, you will also get much more pleasant statistics and HTML pages, as well as fully deterministic media output and a whole bunch of security updates, so, update to its recent 1.0 release.

Please keep in mind that if you switch to JXL, the client tools receiving the image data have to support it. Support varies depending on the Linux distribution, so, test it first and switch the default back to PNG in case you encounter any issues.

What’s next?

With so many features and changes landed, the next changes in AppStream will focus on improving what already exists and fixing any issues (there will be more blogposts about the other features 1.2.x delivers!). Testing with the entire Debian archive as data source makes me fairly confident though that there will not be many problems. In the longer term, tightening the media processing sandbox will also be something we might want to do, e.g. by hiding parts of the filesystem tree or filtering syscalls.

For JPEG-XL, one obvious question is “Will you add support for it to the Freedesktop icon-theme specification as supported format alongside PNG, SVG(Z), and XPM?”. For on-disk icon repositories, JXL’s space-savings are less compelling, and it being HDR-capable is also not necessarily a killer feature (PNG can go a long way!). However, JPEG-XL’s ability to immediately decode larger images at reduced resolution without resampling could legitimately be very powerful here, as applications could ship a single large image and quickly decode it at 1/2, 1/4 or 1/8 the size for different purposes in their UI. JPEG-XL also supports spot-color extra channels, which applications could use as masks to recolor raster icons at render time. This could be incredibly nice to color symbolic icons on-the-fly without any SVG and CSS. JXL also provides richer metadata, which might be neat for (license/author) documentation. So, the answer here is: Maybe it makes sense to allow another format, but this will have to be discussed first, as it would force JXL into every toolkit and desktop, which is a much bigger ask than supporting it only in AppStream.

As always, let me know what you think and please report any issues or bugs directly against AppStream or AppStream Generator if you encounter problems that are with the tools, and not with a project’s metadata.

Dear syslog-ng users,

This is the 141st issue of syslog-ng Insider, a monthly newsletter that brings you syslog-ng-related news.

New performance tuning possibilities in syslog-ng

On April’s fool’s day, I shared that syslog-ng can reach 7 million EPS. This test lab result was in part possible thanks to a few performance enhancements coming to syslog-ng version 4.12. How 7 million EPS is possible? Before diving deeper, let me repeat it: 7 million EPS is just a lab testing result, not (yet) possible in the real world. However, the technologies enabling this are already available on the development branch of syslog-ng, or have been available for ages, just not tested or promoted enough.

https://www.syslog-ng.com/community/b/blog/posts/new-performance-tuning-possibilities-in-syslog-ng

Nightly syslog-ng containers based on Alma Linux

For many years, the syslog-ng project provided container images based on Debian. Most of our users run syslog-ng on RHEL & compatibles, and have asked for an RPM-based container. So, nightly containers based on Alma Linux are now also available. A while ago, I prepared a small test project to run syslog-ng in an Alma Linux container: https://www.syslog-ng.com/community/b/blog/posts/experimental-syslog-ng-container-image-based-on-alma-linux However, that was only an experiment which I never updated. Fast forward to today: nightly syslog-ng containers based on the latest syslog-ng git snapshot package builds are now available on the Docker Hub!

https://www.syslog-ng.com/community/b/blog/posts/nightly-syslog-ng-containers-based-on-alma-linux

The status of OpenSSL 4.0 support in syslog-ng

OpenSSL 4.0 was released just over a month ago. So, how is its support progressing in syslog-ng? Well, Git master already supports it, and the patch is easy to backport to earlier releases. At the same time, version 4.12 will support OpenSSL 4.0 out of the box.

https://www.syslog-ng.com/community/b/blog/posts/the-status-of-openssl-4-0-support-in-syslog-ng

Learning syslog-ng

How can you learn syslog-ng? There are many possibilities, depending on your time and budget. Possibilities range from tutorial series through reading the documentation to instructor-led training. Find out which one is for you!

https://www.syslog-ng.com/community/b/blog/posts/learning-syslog-ng

Your feedback and news, or tips about the next issue are welcome. To read this newsletter online, visit: https://syslog-ng.com/blog/