Agreguesi i feed

NASA and IBM have released an open-source AI model trained on a large collection of lunar observations to help scientists analyze the Moon at scale. "The NASA-IBM Lunar Foundation Model gives scientists a foundation to explore the Moon at scale, connecting observations across instruments, revealing patterns that are difficult to see in isolation, and providing an open platform the global research community can build on," said IBM director of research for Europe, Juan Bernabe-Moreno. The Register reports: It is claimed as the first AI model to integrate observations captured in a range of modalities (data formats), and at different viewing angles and spatial scales. Instead of sifting through maps and images by hand or using low resolution machine learning models, scientists can use this to analyze geographic features, the pair say. In particular, NASA and IBM hope researchers will be able to discover previously unidentified lunar ice deposits, analyze volcanic features called Irregular Mare Patches, and identify and classify craters. Lunar ice indicates the presence of water and oxygen, which may be useful for future manned missions. It is found in permanently shadowed regions, which are among the most difficult areas to observe. The NASA-IBM model combines multimodal and multi-resolution observations to better predict where ice may be present on the lunar surface. Alongside the model, IBM and NASA scientists compiled an open-source lunar dataset from over 30 spatially-aligned layers, using data from nine instruments across four missions. It combines tens of thousands of images and maps showing various geophysical properties of the lunar surface.

Read more of this story at Slashdot.

Version:7.3-rc3 (mainline) Released:2026-09-13 Source:linux-7.3-rc3.tar.gz Patch:full (incremental)

A union representing Uber and Lyft drivers was just certified by California's Public Employment Relations Board, officially recognizing them as the drivers' bargaining organization. The Sacramento Bee reports that this new bargaining structure : The move will allow the California Gig Workers Union to help drivers negotiate issues affecting working conditions and benefits. It comes as at least 30% of active drivers expressed support of the union... [California] Assembly Bill 1340 helped bring the union to fruition by allowing the independent contractor drivers to engage in collective bargaining. "The next step for the union is to negotiate a contract with Uber and Lyft that meets drivers' demands," reports the Los Angeles Times, "including health insurance, support for high gas prices and more transparency around pay: California is the third state to allow ride-hailing drivers to unionize, following Washington in 2022 and Massachusetts in 2024... The California Gig Workers Union was formed with the support of the Service Employees International Union... "Gig drivers shouldn't have to face the future alone," said SEIU 521 official Riko Mendez in a statement. "As autonomous vehicles rapidly expand, having a union gives the drivers the power to negotiate for fair pay and meaningful say in how new technology shapes their work and our communities' futures."

Read more of this story at Slashdot.

"This is what happened when we tried to record Flock installing a new camera on public roads," says Emmy award-winning reporter Brendan Keefe in a new video for InvestigateTV. In an accompanying article, InvestigateTV says their reporter "parked on the public street at a distance, donned a yellow safety vest and a hat emblazoned with the logo of InvestigateTV's Atlanta affiliate where he also works, displayed a press placard on his dashboard and then pulled out a camera to record the installation.... The installer saw him and immediately packed up his equipment and drove away, so Keefe also returned to his car and followed several cars behind, hoping to document the next stop." And then Flock's technician called 911. When asked "What's the address of your emergency" Flock's technician answered "I'm getting followed — harassed, pretty much. Taking videos and pictures!" Flock's worker said they'd been harassed multiple times that day, then stated incorrectly that "I know for a fact" that that was what the reporter wanted to do too. InvestigateTV reports that as a result of the Flock technician's call, "Three police cars ended up in the national investigative reporter's rearview mirror that Wednesday afternoon." Keefe told one of the three police officers who pulled him over, "There is an irony here that they're setting up these cameras that track all of our movements, that follow everywhere we go. But when I try to get video in public of him in public setting up a camera, he's afraid I'm following him?" InvestigateTV also reports that "About 17 minutes after the stop began, the responding officers returned to their vehicles and Keefe was allowed to drive away." But the call that brought three police cars to their reporter "was not the first time this summer someone working for Flock Safety summoned police over a camera. " About 17 minutes after the stop began, the responding officers returned to their vehicles and Keefe was allowed to drive away... [But the stop] was not the first time this summer someone working for Flock Safety summoned police over a camera. On June 5, police in Smyrna, Georgia, responded to a 911 call from a Flock employee after a group of YouTube creators began filming outside the company's distribution center located in the Atlanta suburb... The caller claimed the group filming had "been driving around the perimeter, basically harassing everyone" working at the facility. "Three young white males, probably mid-twenties, I'm not sure if they're armed. And they're carrying filming equipment as well," the caller said. Three times during the call he raised the possibility the people filming might be armed, though, when asked, he told the dispatcher he had not seen any weapons... [One of the protesters later told the caller "I think it's interesting, when you guys have this happen, you call the police and make us get stopped. But then you do it and it's okay?"] No one was charged in the YouTuber group, though the individuals were ordered to leave the premises under an official trespass warning. Keefe's video report ends with one final irony. "Every day on my way to work, I'm captured again by those same new shiny Flock cameras. We tried watching the watchers. Turns outs, it's a lot easier for them to watch us." Flock responded to the report by claiming "We do not object to members of the public or press photographing Flock cameras or personnel in public." But they added that employees working "in the field" must "prioritize their safety" and "may contact law enforcement when they believe they are being threatened, harassed, followed, or otherwise face a safety concern."

Read more of this story at Slashdot.

A swarm of OpenAI agents launched a "major malicious attack" against RubyGems last May, according to a new report. That coordinated attack hit Ruby's package manager "with hundreds of junk gems, prompting the maintainers to suspend new user sign-ups for about four days," writes The Hacker News, citing a senior product manager for software supply chain security at Mend.io: The latest findings, which were first reported by The Wall Street Journal, indicate these events were propelled by a cluster of OpenAI agents, with the earliest package uploaded to RubyGems on May 5, 2026, before more than 2,000 packages were submitted between May 11 and 12, 2026. These efforts were followed by the agents publishing five more packages between May 26 and 27, 2026, and another 83 packages on June 18, 2026... [T]he packages were authored using a large language model (LLM) and hundreds of the packages that were pushed to RubyGems had "oai" in their name. Fifteen of the packages listed "oai" as their author, while another had "openaixyz65947@gmail.com" as the contact email address... "The swarm behaves extremely similarly to the German-wiki agents we previously found," the researchers said, referencing another May 2026 incident... "The June agents were accessing 49 of the same files as the wiki agents..." "The process of building documentation for a gem involves evaluating a user-specified '.yardopts' file, which allows linking to Ruby scripts intended to help with this process," the researchers explained. "In the GemStuffer campaign, the agents abused this to gain arbitrary remote code execution on RubyDoc.info's servers." One of the gems, "zzsouthrunner" (which again matches the "ZZ" naming scheme the agents adopted in both the wiki and Hugging Face incidents) has been found to leave the following explicit comment at the top of "data/script.rb": # malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker... The entire exploitation chain can be summed up as follows — Submit a malicious package to RubyGems — Trigger a documentation request, so that RubyDoc.info will build the package — Use the build script to run code on RubyDoc.info and scrape target websites — Exfiltrate the data off RubyDoc.info's servers by publishing another gem back to the RubyGems package registry, which is publicly viewable Additionally, the OpenAI agents have been found attempting to steal other users' API keys after gaining remote code execution capabilities on the build environment, while clearly being aware that what they were doing is unauthorized breaking and entering into real systems. This is evidenced by the names given to the files (e.g., hack.rb, evil.rb, inject.rb, exploit.rb, and ssrf.rb), the packages themselves (e.g., pwnp999, exfiltestwand3, hacksvn1778554764, and lambproxyhackabcxyz), and the comments left in the source code (e.g., "# malicious probe," "#hack," "# malicious test," and "# malicious crawler/exfil"). In some cases, however, the rogue agents attempted to go under the radar, leaving comments to conceal the malicious payload in the next release version of the packages. "# disable evil in next version and bump version," reads a comment left within the "data/evil.rb" file in the yardxabc889 gem. Troublingly, the agents also attempted to exploit a CDN caching bug (CVSS score: 7.3, no CVE) on May 12, 2026, that was only patched by RubyGems in July 2026... "If you signed in to rubygems.org with a gem client older than v3.2.0 (or otherwise via a legacy key), your key could have been exposed," RubyGems noted in an advisory. "Currently, 18% of sign-ins through gem sign-in come from an affected version, and for the first several years of this bug, before we changed the client's sign-in path in December 2020, it was every gem client." Other actions by OpenAI's agents cited in the article: "Agents bypassed RubyGems' email confirmation system to get working API keys without having to verify their email addresses in order to register a large number of accounts using disposable email addresses." "Agents attempted to use RubyGems' webhook system to stage data in the form of encoded URLs." "Agents used a cluster of 83 gems published to RubyGems over a 3-hour window on June 18, 2026, to experiment with different methods of accessing the U.S. Securities and Exchange Commission county.json dataset."

Read more of this story at Slashdot.

America's highest court heard Sam Bankman-Fried's request for a new trial on Thursday, CNN reports. But they add that "the former crypto mogul who was convicted of defrauding investors by secretly diverting billions of dollars of their money" also asked America's high court "to throw out a court order requiring him to pay $11 billion as part of his sentence." Bankman-Fried was sentenced to 25 years in prison in 2024 after prosecutors said he directed billions of dollars from the crypto exchange FTX to a hedge fund he controlled called Alameda Research, where the funds were used for risky investments, political donations and his own personal benefit. The Supreme Court appeal, which was reviewed by CNN, raises a technical question about evidence that was submitted at his trial, and whether Bankman-Fried should have been permitted to demonstrate that his investments were ultimately sound and would have covered any losses by FTX customers. He also argues that the $11 billion forfeiture violates the 8th Amendment's prohibition on excessive fines. "Where the government pursues a theory of fraud under which it doesn't matter whether any victims lost money, introducing evidence suggesting that people actually lost money is distracting and prejudicial," veteran Supreme Court attorney Jeffrey Fisher told CNN. "All the more so where the truth is the victims did not lose money, and the defendant is unable to make that clear." The 2nd US Circuit Court of Appeals rejected the arguments earlier this year.

Read more of this story at Slashdot.

An anonymous reader quotes a report from The New York Times: The chief executive of Anthropic called for a global slowdown of artificial intelligence development in a 3,800-word essay on Saturday, just days after one of the company's employees quit over concerns about the safety of the technology. Dario Amodei, who co-founded Anthropic to focus on securely and carefully building A.I., wrote that while he believed the technology could bring many benefits, it was advancing at too quick a pace for researchers to continue safely. "Over the last few months, I have become convinced that fully addressing the risks requires even more prudence -- not just investing in risk prevention, but pacing the rate of capabilities advancement so that risk prevention has time to keep up," Mr. Amodei said. "We must slow the pace at which we improve the capabilities of A.I. models. Progress will still seem fast, and we must make wise use of the time we gain." [...] "Left unchecked, it could outrun our ability to understand and control these systems, and so must be pursued very carefully, if at all," Mr. Amodei said. [...] In his essay on Saturday, Mr. Amodei suggested actions that the industry might take to slow down the pace of development. Mr. Amodei said all A.I. labs could agree to third-party technology assessments from "embedded evaluators," or outside specialists who can verify best safety practices across companies. He also suggested that countries with democratic governance systems coordinate to create safety standards, which could take the form of regulatory action. He added that it would probably require a global effort working with other nations, including authoritarian ones, to properly coordinate a slowdown. Mr. Amodei stressed in his essay that he still finds A.I. capable of bringing "incredible benefits" to humanity, including potentially curing diseases and accelerating economic growth. But even so, Mr. Amodei said the risks of A.I. were too great to not proceed with extreme caution. "The measures I propose to advance the frontier at a safe pace will not be easy," Mr. Amodei wrote. "But I believe we owe it to humanity to try." Amodei's essay comes just hours after Bloomberg reported that Sam Altman told OpenAI employees the company is open to slowing the pace of AI development amid similar concerns.

Read more of this story at Slashdot.

Less than 48 hours after Automattic's board placed Matt Mullenweg on leave, Mullenweg told employees he was back "in control" of the company and that the board was again in agreement. 404 Media cited Slack screenshots late Thursday evening where Mullenweg posted "Don't call it a comeback" and linked to LL Cool J's music video for "Mama Said Knock You Out." "Mullenweg's Slack profile picture currently shows him wearing a pirate hat and eyepatch," the report notes. From the report: "Happy to announce the board is back in agreement, and I'm in control of Automattic," Mullenweg wrote in the company-wide Announcements channel on Slack. "A lot happened in the past 48 hours that we need to sort out, and I hope much of it was a misunderstanding, because I have huge respect and regard for those involved." Mark Davies, Automattic's CFO who was set to act as interim CEO according to a statement from Automattic, had his Slack account deactivated as of at least Friday, sources told 404 Media and TechCrunch similarly reported. Davies, Mullenweg, and Automattic did not respond to 404 Media's requests for comment for this story. Techcrunch reported that Mullenweg told them a blog post is forthcoming. On Friday morning, Mullenweg published a blog post on his personal website, titled "Major Life Announcement." In it he announced he's buying a tugboat. "Anybody who's founded a company and had to find good stewards knows that no one will love a thing quite like the original owner, but sometimes you can find the perfect person to carry the torch," he wrote in the blog. He did not address the confusion surrounding his status at Automattic. The back-and-forth follows years of legal fights, layoffs, employee departures, and controversy surrounding Mullenweg's leadership.

Read more of this story at Slashdot.

It’s been another fantastic year for Google Summer of Code with GNOME! This year, six contributors worked on a range of interesting projects across our ecosystem.

Our contributors have been blogging about their progress on Planet GNOME throughout the summer. In case you missed their updates, here is a breakdown of what they have worked on:

• Adding a recovery mechanism for GPU resets in Mutter by Toluwaleke Ogundipe
• Adding debug adapter protocol (DAP) support to GJS by Angelo Verlain Shema
• Playing vocab-style puzzles in GNOME Crosswords by Laureen Caliman
• Rewriting the Pitivi timeline ruler in GTK4/Rust by Michael Calabrese
• Implementing app uninstallation in the GNOME Shell app grid by Ramayanapu Jagath
• Porting Gitg to GTK4 by Shivam

Our interns also presented their work during GUADEC. You can watch their lightning talks on YouTube.

This would not have been possible without the support of our community mentors. A huge thank you to Jonathan Blandford, Alex Băluț, Yatin, Adrian Vovk, Jonas Ådahl, Robert Mader, Carlos Garnacho, and Philip Chimento. Mentoring takes a lot of time and energy, and it plays a vital role in onboarding new contributors to our community.

If you are a GNOME developer and interested in mentoring a project next year, you can already start working on your project ideas and submit them at gitlab.gnome.org/Teams/internship/project-ideas.

If you are a newcomer interested in starting your journey toward becoming a GNOME contributor, check out gsoc.gnome.org and stay tuned to Planet GNOME and our social media channels for updates on the 2027 program!

 

Google Summer of Code 2026: Native App Uninstallation in GNOME Shell

This summer, I spent my Google Summer of Code working on something I’ve wanted to see for a while, making it possible to uninstall apps right from the GNOME Shell app grid. Before this, if you wanted to remove an app, you had to open up GNOME Software, hunt it down, and delete it from there. My goal was to completely remove that friction. By connecting GNOME Shell and GNOME Software behind the scenes using D-Bus, I made it so users can securely delete apps with just a couple of clicks right from the desktop

GitLab Links to Code GNOME Shell: App Grid Uninstallation Frontend

This Merge Request covers all the frontend work I did in GNOME Shell. The brain behind it all is a new class called AppStoreIntegrationManager. Think of it as both a state tracker and our bridge to GNOME Software. When it boots up, it connects to GNOME Software asynchronously over D-Bus using the org.gnome.Shell.AppStoreIntegration interface.

To keep the app grid feeling snappy, I didn’t want to query the app store every single time a user right-clicks an icon. Instead, the manager grabs the dictionary of uninstallable apps and caches it in memory. To make sure this cache is always accurate, it listens for installed-changed signals from Shell.AppSystem and quietly updates itself in the background.

Because the data is cached, the UI just has to react to it. When you open the context menu, it checks if the app is in our cache; if it is, the “Uninstall” button appears. This is a great way to prevent users from accidentally trying to delete core system apps. Once a user clicks uninstall, the frontend checks if the app supports purging user data. If it does, a confirmation dialog pops up with a checkbox to wipe those files. After confirming, the app goes into a tracking Set (_uninstallingApps). This immediately tells GNOME Shell to remove the app icon from the grid right away, giving the user instant visual feedback that the app is gone. Finally, if the background job finishes successfully, it happens silently without spamming the user with notifications. However, if the uninstallation fails for any reason, a system notification pops up to let the user know what went wrong.

GNOME Software: App Store Integration Backend

This Merge Request focuses on the backend GNOME Software. It’s essentially the engine that listens to GNOME Shell and handles the actual uninstallation and data purging. To make this work, I built a custom GObject called GsAppStoreIntegrationBackend. This object exposes the necessary D-Bus methods and acts as a safe router, directing GNOME Shell’s queries straight into the GsPluginLoader.

When the Shell asks for the list of uninstallable apps via the GetUninstallableApps method, we can’t afford to make it wait while we search the entire software catalog. Instead, the backend fires off a GsAppQuery using gs_plugin_job_list_apps_new to quickly grab only the installed apps. I also built in a strict safety net: if an application is tagged with the GS_APP_QUIRK_COMPULSORY quirk, we automatically strip it out of the response. That way, GNOME Shell never even gets the chance to offer a “Delete” button for critical OS components like Settings.

I also spent a lot of time on secure data deletion, which is super important for sandboxed apps like Flatpaks. To pull this off, I extended the core plugin architecture by introducing a new flag, GS_PLUGIN_UNINSTALL_APPS_FLAGS_PURGE_DATA, to the GsPluginUninstallAppsFlags enumeration. Now, if a user checks that ‘wipe data’ box on the desktop, the backend attaches this flag to the uninstall job. I modified the Flatpak plugin (gs-plugin-flatpak.c) to intercept it. Once the standard uninstall finishes successfully, the plugin spots the flag and calls gs_utils_rmtree() to safely and recursively scrub the isolated app data right out of ~/.var/app/<app-id>.

GUADEC 2026 Presentation

Honestly, one of the absolute highlights of my summer wasn’t even the code, it was getting to share this project with the wider GNOME community at GUADEC 2026! I had a blast giving a talk about how this feature actually works under the hood. I walked through the technical hurdles of bridging GNOME Shell with GNOME Software.

You can check out my presentation here

What’s Next?

This project might be wrapping up, but my time with GNOME is just getting started. My immediate goal is to finish up the its and bits and get it merged. Once that’s done, I’m already looking at my next feature to add, implementing drag-and-drop uninstallation into the app grid

A huge thank you goes out to my mentor, Adrian. His patience and guidance meant everything to me this summer. He didn’t just review my code; he took the time to help me really understand the bigger architectural picture. Because of him, I’ve grown so much as a developer. I loved how he would take the time to explain the deep history of Linux architecture to me, like how default applications and URL schemes eventually paved the way for XDG Intents. Combined with all the practical debugging techniques he showed me, he really helped me level up this summer.

It’s been an amazing ride, and I’m so excited to continue my journey with GNOME and the open source world!

Linux virtualization lets a physical host run guest virtual machines. A fix in vhost, the Linux component that helps those guests exchange data with virtual devices, limits memory consumed by repeated requests for a missing memory mapping.

Confidential computing can protect a virtual machine’s memory from the host that runs it. A remote client still needs to check that its connection reaches the protected machine. Transport Layer Security, or TLS, encrypts the connection and checks the service’s identity, but does not by itself verify the machine’s software environment.

The Debian project is pleased to announce the seventh update of its stable distribution Debian 13 (codename trixie). This point release mainly adds corrections for security issues, along with a few adjustments for serious problems. Security advisories have already been published separately and are referenced where available.

A file descriptor is the numbered handle a running program uses to access an open file or similar resource. Linux can mark it to close automatically when the program replaces itself through exec(). That cleanup can involve waiting for a filesystem, which makes its timing important.

A Linux sandbox restricts which files a program can access. Landlock, a kernel facility that lets programs apply those restrictions to themselves, had a bug in the code checking file locations. A concurrent directory move could leave the check reading memory that had already been released.

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:

Icon sizeIconsPNG totalJXL totalPool savedPNG avgJXL avgMedian savedMean saved Worst BestLarger as JXL 48×48 1544 3.7 MiB 3.0 MiB 17.8%2.4 KiB2.0 KiB 17.9% 16.7%-118.7%60.0% 206 64×64 2018 7.0 MiB 5.8 MiB 17.8%3.6 KiB2.9 KiB 18.0% 15.8%-112.7%70.0% 279 128×128 1411 11.2 MiB 8.7 MiB 22.0%8.1 KiB6.3 KiB 20.1% 17.5% -89.7%61.0% 209 TOTAL 4973 21.9 MiB 17.5 MiB 19.9%4.5 KiB3.6 KiB 18.6% 16.6%-118.7%70.0% 694

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:

Icon of Vonsh, an SDL-based snake game, which PNG compresses better than JXL

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:

Icon of x3270, an IBM 3270 Terminal Emulator

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.

It’s been a long time since I last posted anything here, huh.

Well, a few hours ago I was preparing the release notes for the next release of GNOME Calendar. It is yet to be reviewed, but this is how it reads at the time I write this blog post:

This is a remarkable release for us, as it is one of the biggest releases in the history of the project, and we're excited to share a slightly longer update on it. The first thing many users will notice is how GNOME Calendar will feel snappier now. During the past six months, a lot of work was put in optimizing GNOME Calendar from the inside out. This includes a major change in how it handles events internally, vastly reducing the amount of data transferred between GNOME Calendar and other components of the desktop, and applying many different tricks and strategies to make it render faster. Really, this is probably the most optimized the project has ever been. Another front in which GNOME Calendar has been consistently improving is accessibility and keyboard navigation. During this development cycle, another big batch of improvements on these fronts were merged. You can now navigate between events and days in the Month view using only your keyboard. Notification bubbles are properly read out loud (thanks also to Orca developers for accommodating our use case!). The Week view is now properly styled when the high-contrast setting is enabled. […] On the non-technical side, in the past few months the project received contributions from many new contributors, as well as long time contributors. Our issue tracker continues to be in excellent shape, well triaged, and properly labeled. Our three latest releases were the biggest releases in the history of the project. Thank you all very much for using, developing, documenting, translating, testing, and fixing GNOME Calendar!

This release of Calendar has lots to talk about. It is, as mentioned, the biggest release in the history of the project. Not in numbers of line added, or patch count, but certainly in terms of contributor involvement, code reviews, code quality, and features. We’re not just a bunch of bored university students pushing unreviewed patches non-stop to the main branch anymore!

For the next few weeks, I’ll be writing more focused blog posts about the work I’ve done in Calendar this cycle. I’ve focused mostly on performance and reorganizing the internals of the application to be more resilient. It’s not glorious work, but I do love working on optimization problems!

GNOME Calendar will complete 15 years in a few months from now. The project is one of the few lucky projects in GNOME – and, I’d argue, in the free software scene in general – that has such a thriving community of contributors. It’s one of the few GNOME core apps that survived the great purge. It’s a super rare example of a GNOME app with a product manager.

It is also the project that brought me in in GNOME, so pardon me if I get a little emotional when I see the project thriving as it is, and think back of all the good friends that came and went, the hard lessons from maintaining it over over a third of my life, and the prospects for the future.

GNOME Calendar is entirely developed and maintained by volunteers. We have never received any kind of funding, be it corporate, from grants, or other forms of patronage. This gives us freedom from these kinds of influences (mostly to complain about how so many big companies fail to meet the calendaring standards that they themselves helped create), but the reality is that it is really damn hard to pitch for funds for a calendaring application.

Please consider donating to GNOME, or to the individual contributors of your choice. It makes a difference. All the difference.

In 1993, I stood at the top of the World Trade Center feeling like being on top of everything. It was the culmination of my first proper trip west, a stark contrast to a country behind an iron curtain or even a small-town Amherst, New Hampshire, where I had to earn my way into that adventure.

Many people can't wrap their heads around how such enormous buildings could collapse on September 11. What I can't wrap my head around is that they survived the first attack, which happened in February of '93, when I was, entirely oblivious to what had happened on the ground floor a few months earlier, soaking in those panoramic views.

The attack was carried out by a group of radicals led by mastermind Ramzi Yousef. In the underground parking garage of the North Tower, they detonated a yellow Ford van packed with explosives. It's often claimed that the terrorists used Czechoslovak Semtex, but in reality it was a massive, roughly 600-kilogram homemade explosive charge, further reinforced with pressurized hydrogen tanks. Semtex was only a trigger explosive.

The explosion was devastating. The blast tore a 30-meter crater through five floors of underground parking and damaged several support columns, though the main structural frame of the tower held. Though the tower didn't collapse as the terrorists had originally planned, the shockwave destroyed the main electrical wiring and emergency lighting, and smoke rose as high as the 93rd floor. Six people lost their lives and more than a thousand were injured, most from smoke inhalation during the grueling evacuation through dark stairwells. Operations in both towers were completely paralyzed and the complex had to be shut down for nearly a full month. Total damages and subsequent repairs cost roughly half a billion dollars.

Because of the '93 bombing, the Port Authority installed photoluminescent safety markings along the steps, landings, and handrails throughout the towers. When the planes struck eight years later and emergency lights flickered or failed, these glow-in-the-dark strips guided occupants downward. According to National Institute of Standards and Technology, 33% of survivors in the North Tower and 17% in the South Tower directly credited these markings with aiding their escape. The stairs were well-lit by battery-pack emergency lights and photoluminescent guides, and people moved much faster. Survivors who had been in the building during both attacks noted that the 2001 descent took roughly half the time it did in 1993.

I only know about all of this because of the internet — a firehose of news and dangers pouring at me every hour of every day. Could I stand up there today, soaking in those fantastic views, still so oblivious and happy?

Adobe has released an emergency fix for a Magento vulnerability that attackers are already using against online stores. Someone exploiting the flaw can make an affected store run code without first signing in. Adobe confirmed the attacks on Sep 8, 2026, one day after releasing the urgent hotfix.

Linux kernel testing can miss a bug when it depends on two tasks reaching the same data in an unusual order. These independently running tasks are called threads. A race condition occurs when their timing changes whether the code works correctly, which can make a failure difficult to reproduce. Google Project Zero published MAccConc on Sep 8, 2026 as a prototype that changes the timing itself. Its name is short for Memory Access Concurrency. The tool traces selected Linux kernel memory access...