Agreguesi i feed

Most modern operating systems (including iOS, Android, macOS, and ChromeOS) have been using image-based architectures for a while, and in recent years we’ve been making progress towards this on the desktop side as well. It’s a necessity if we want to provide the security, usability and reliability that people expect from their devices nowadays.

However, broadly speaking the adoption of image-based designs has been limited in the free desktop world so far because there are still a few major gaps. While Flatpak and Flathub have more or less solved the app distribution on these systems, the developer-facing story still looks much more incomplete.

Traditionally, people have been developing against the host OS they are running. Assuming you’re working on something like NetworkManager and need a new dependency, you’d just “apt install” it globally on your system, and then configure/compile against that. Similarly, if you need a command-line utility, compiler toolchain, or other build dependency, you’d also install them from the distribution repository.

In an image-based world this approach doesn’t work, and people have come up with various ways to address this.

RPM-Ostree and Package Overlays

Fedora Silverblue can be extended similar to package-based distros with rpm-ostree overlays, but the issue with this approach is that overlayed packages can completely break the system in unexpected ways or stop it from further updating. This is why the next iteration of Silverblue is based on “bootc”, and will be explicitly avoiding this paradigm. Same issue are present with other package overlay approaches as well.

Monolithic “Development” Overlay

The approach used by Android, iOS, Windows, et al is to have a single monolithic overlay with “system development tools”. Developers can install this overlay, and it provides all the utilities people developing the system itself need.

GNOME OS does something similar: There is a “developer” system extension that overlays the toolchain used for building the OS on top of the user-facing OS image. However, this is a finite list of utilities needed specifically to build the OS. As such, it can not cover the long tail of development and debugging tools developers in different areas need (e.g. kernel development).

Toolbox

Another approach is trying to replicate the same traditional package-based experience inside a container. Toolbox and distrobox are examples of this.

Unfortunately, with this approach you are still relying on the same old package infrastructure, while also being inside a more restrictive container environment that none of the tools expect to be run in. As such, you often run into limitations when developing system components and need to bypass the container layers in order to debug the system itself.

Homebrew

Homebrew provides an independent tool chain to develop against, but in order for homebrew binaries to be usable directly in the terminal, they have to be prioritized over system binaries. This means that the system can break if there is a mismatch between what the system expects and what homebrew provides. For example, you install QEMU, but it overrides the GLib your system uses for everything else.

There are other architectural issues with homebrew, but in my opinion this alone disqualifies it for system development.

Flatpak

Lastly, we have Flatpak. Like Toolbox it uses “containers”, so the same issues and limitations are also present here, but it’s even more restrictive because the assumption is that apps will use portals to access system resources such as directories and devices. Flatpak was designed specifically with desktop apps in mind, and its architecture and integration points are not well suited for command line apps.

Somewhat tangentially, there are apps that can’t be made to fully work with Flatpak as it is today, particularly debugging utilities and IDEs. While it’s technically possible (GNOME Builder and the Ptyxis terminal are proof), older applications were not designed with sandboxed resources in mind, or have not adapted to this model yet.

What Could We Do Instead?

While we would love for everything to be sandboxed and confined, that is sadly not yet possible. All the existing approaches that attempted to containerize tooling, run into the same conflicts between the desired functionality and the restrictions inherited by this approach. This is a topic we will discuss in more depth later on.

Additionally I believe there are two different use cases here. The build tooling/toolchain used by projects, and the developer utilities.

Project Build Setups

One aspect of this is the build setup used by individual project, which would ideally be something more deterministic, and containerized like Buildstream, flatpak-builder, bazel or even nix, instead of the old status quo “apt install -yqq gcc meson libone-devel libtwo-devel”. This is also a topic for another day though.

Developer Utilities

The other aspect, and what I want to focus on today, is that a lot of developer utilities that people rely on can’t realistically be run in a confined environment (such as a container) without a near complete rewrite.

We need a way to make things like strace, ripgrep, and qemu available. Shipping them in the host system is one option, but there is a real long tail issue here. You can’t (and don’t want to) provide every single utility any developer might need. Thus we need them to be shipped independently, and as such, not attached to the host OS.

Toolpak

If we were to take a fresh look at this issue and design something from scratch, what would we want it to look like? Over the past months we’ve had a number of discussions on these topics, and it feels like we’re finally converging on a solution would address most people’s concerns and needs.

These are the important properties we would want:

• Tools should be independent from the host OS, and they should not break the host OS if something goes wrong. They need to be able to access every resource in the system, much like today.
• A large catalog of existing tooling, like we find today in distribution repositories today.
• Tools work out of the box, and will be fully functional, as it’s not feasible to modify all of them. Things like shelling out to other tools should work like it does now.

Here is what I imagine an implementation, which we will call Toolpak, would look like:

• Discoverable Disk Images (UAPI.3) as the image format. This will provide us state of the art security practices, like Verity. It will also give us a good base for allowing Reproducible builds, given that the build tooling permits.
• A mount namespace for the binaries. The /usr and /app split from Flatpak is a great idea and we should also steal it much like portable services now can use Base/Runtime images! /usr should be provided by the “Runtime Image” and shared among tools. And /app will be the main contents of the Tool image.
• Tools have unrestricted access to everything else. This should also satisfy the “no need to port” requirement (Some edge cases where the mount namespace will conflict, but they are minor).
• We should prepend the tools, to the PATH of the user (ie. our binaries will override the system ones), but it should avoid breaking the system as you can only override the system binaries. Said binary will then setup the mount namespace and execute the real binary from inside the image. This avoids messing with the linker and shared libraries. Unless you overriding the system GNU Tar with the BSD Tar (or other incompatible cases of the same binary), things should work fine. More research is needed to explore what other safeguards will be required.
• Tools can not depend on other tools. One of the issues with traditional distributions is dependency resolution and package management (this is subcategory of a heavily discussed topic, I also talked about it in my LAS talk from 2025. We should avoid making individual packages or having dependencies between tools, to avoid all the unnecessary complexity that comes with it.
• Tools will bundle all their dependencies. This will ensure that they will always execute against the environment they were tested against. It additionally allows tools to bring their own versions of libraries that might be present in the system, without conflicts. We mentioned the /usr and /app split above.
• Great user experience to discover and install tools. There should be a flagship “app store” and ideally the tools should be packaged and distributed by the developers themselves, similar to Flathub. No more “download this static binary and chmod +x it”.
• Tools have complete and arbitrary access to the system, so it’s crucial that it not be simple to install random images. They will be have to be signed with a trusted key, and verity checked at runtime, and be thoroughly reviewed before appearing on the flagship “app store”, and all the other practices we should expect from distributing software securely.
• Apps that can be packaged using Flatpak should be rejected. Unless they are less functional, like IDEs on Flathub.

In order to be adopted, it will also have to come with tooling that will make it easy to build said Toolpaks. Here are some specific properties the build tooling should have:

• It should be easy to orchestrate builds of your tool and its dependencies.
• Great caching for all build artifacts in a Content Addressable Storage.
• Reproducible by default, with tooling to easily verify the output.
• Can be used for both local development and composing the final image.
• Handles all the licensing/SBOM/etc requirements.
• A Buildstream plugin or wrapper around it should satisfy all these needs.

Next Steps

While this topic has been discussed for years, there’s now concrete work towards a prototype as part of a Prototypefund project. We plan to share more on this in the coming weeks and are interested in feedback from the wider community. In the mean time, if you have any other feedback, find us in #gnome-os:gnome.org on Matrix, or leave a comment.

GNOME and KDE have started to consider LLM policies, and we should talk about what this is really about.

KDE caught everyone's attention first by igniting a flame war with an LLM-friendly draft that ended up being deleted, causing a few bans, and having a bunch of people go full "Some of you may die, but that is a sacrifice I am willing to make". GNOME has not proposed anything official, but some teams (gnome-calendar, loupe, libadwaita, gnome-software, Circle, among others) already have strong policies in place, and there is now an informal draft to ban all LLM contributions to GNOME projects and infrastructure.

However I believe these discussions are not about nitpicking workflows but rather about the raison d'être, the reason to be, of FLOSS projects.

Communities Or Completionism

My take is that there are currently two ways of thinking about why FLOSS exists, or should exist. So far, both sides have coexisted but the growing acceptance of LLMs into some developer workflows has disrupted the balance.

We can call one of these sides "collectivism". This frames FLOSS to be about accomplishing things together, enjoying the journey and bonds that big goals tend to create. The fun is the collective effort and challenge. Overcoming language and social barriers is part of the reward. "The journey is the destination", "FLOSS is the friends we made along the way", etc.

On the other side there is "completionism", where FLOSS is "just a product" and its only goal is to always be better, faster, safer. Any fun to be had is in individually solving technical problems and requirements. Social bonds may happen, but colleagues are more coworkers than community. This is a "100% allglitches alltricks" TAS speedrun. The "we are apolitical", "we only care about the code" view.

My assessment is that the collectivist framing finds FLOSS primarily a social exercise that rewards you with experiences, bonds, and ideas outside of your niche interests. Some times you even get good software as a bonus! The second framing sees FLOSS as a tool to scale the complexity of your individual computer interest, like graphics or security. FLOSS is a convenience compared to manually rebasing patches and forks all the time.

The problem we are facing is that LLMs have given the second group a lever to stop giving the collectivist framing any room. When the LLM can get you 80% of the way to your goal, there is no need to "waste" time in mentoring, discussion, or convincing others. The temptation compounds if you are considered an expert in your field. You can surely fill in the last 20%, right? Is anyone going to challenge not only the machine, but also the expert?

Progress At All Costs

Since LLMs present themselves as neutral, and dispassionate, opposition to their output becomes opposition to objective progress: bug fixes, security hypotheticals, features. Progress is whatever the LLM, under my own careful eyes, says it is. Interactions with others become formalities, since the LLM is simply boosting my own, already expert and close to infallible, output. Right?

Unfortunately this "expert slop", where expert is a self-perceived title, carries a corporate framing that damages interactions. Others become, at best, fungible coworkers, and, at worst, annoying speed bumps in the race to 100% completion of any software interest the expert has. No more mentoring, debating, flame wars. "Progress" is the only goal. The line must go up.

There is more to say about how this machiavellian framing causes far more important harms and externalities, in the name of LLMs themselves, or apparent LLM-assisted progress. Think of any group and you will find out they have been handed part of the bill for these externalities:

• The people who will lose their homes, schools, lives, in the Global South because of El Niño 2027
• The towns destroyed by data center illegal and irresponsible practices
• The price of all consumer goods going through the roof because of financial speculation
• The pensioners who might lose their pension when the bubble finally pops.

These are the real costs in the "Progress At All Costs" that LLMs bring into FLOSS. These are the people who will pay the bill, behind the scenes and far from our screens, so that some big brain engineers can avoid reading documentation, writing boilerplate, learning unfamiliar code, or, worse, working with others.

FLOSS As Principled Software

Almost ten years ago Allan Day described GNOME as Principled Software because of its commitment to always doing the right thing, in code or design, because it was the right thing and not because of ease, pressure, or hype. I believe this is why so many other FLOSS projects have always looked at GNOME for guidance on what good FLOSS should be. This discussion is just another opportunity to continue to meet this expectation.

Recent discussions have shared similar sentiments like reminding us that we do book clubs because we want to read and enjoy books, not to just discuss over summaries because it is "more productive". That when pressed to accelerate FLOSS, to make the line go up, we have to ask for whom do we want to be more productive, efficient, faster?. And that every decision is political and affect other people around you.

We already know that LLM productivity is not real, just a self perception, that LLMs are just a fairy tale to maintain tech stocks hypergrowth, by farming engineers for engagement, and the latest in a series of attacks to commoditize tech workers. Knowing all this, are we still going to play along with big tech's lies and exploitation? Or, are we going to make another principled stand?

GNOME did not need LLMs to produce 30 years of creative engineering, design, localization, inclusion, and collaboration that has been shared with people around the world. It does not need to throw away this incredible legacy simply because LLMs happen to farm our worst individualist impulses.

We came this far without compromising our principles, let's not start now.

Version:7.2.8 (stable) Released:2026-09-25 Source:linux-7.2.8.tar.xz PGP Signature:linux-7.2.8.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-7.2.8

Version:6.18.54 (longterm) Released:2026-09-25 Source:linux-6.18.54.tar.xz PGP Signature:linux-6.18.54.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.18.54

Raspberry Pi's stock shot up over 30% in the last week. Why are investors so excited? For the six months ending June 30, revenue for Raspberry Pi Holdings "jumped 90% to $256.9 million," reports Investing.com, "while adjusted EBITDA more than doubled to $40.3 million, and profit before tax leapt 216% to $19.6 million." Underpinning the strong numbers was an acceleration in OEM adoption: direct unit shipments rose 26% to 3.4 million, total unit shipments climbed 17% to 4.2 million, and the customer order backlog doubled during the half to 2.6 million units. Demand was particularly robust in the Smart Home and Aerospace and Defence segments, and the company launched the AI HAT+ 2 for Raspberry Pi 5, extending its edge-AI product line. DRAM prices have been increasing everywhere, notes The Times of London, and Raspberry Pi co-founder Eben Upton "said new customers, who required computers or microcontrollers to manufacture other technologies, were choosing Raspberry Pi's computers because they had a better inventory of components than competitors." "There's always that choice for an original equipment manufacturer as to whether they should 'make' or 'buy' the computer elements of their platforms," Upton said. "The supply chain disruption is making 'make' a much harder choice and it's making the cost of repair a much harder choice. So we're seeing strength there." Raspberry Pi has already increased its suppliers of Dram more than threefold... Upton said the increased demand had led to its backlog for units doubling to 2.6 million, which meant production rates would need to increase to prevent the numbers from getting "unhealthy". New production capacity at the manufacturing facility in Pencoed, Wales was expected to come online this week... Exports were almost evenly split between North America, Europe and the rest of the world, which was primarily China, where demand was growing... Analysts at Peel Hunt said the company was "well positioned for rapid growth in unit shipments in 2027 and beyond" with demand expected from enthusiasts as well as the AI and security sectors. In other news, Hackaday notes the Raspberry Pi Foundation has "pushed binary-blob bootloader changes that limit your ability to upgrade RAM..." This change restricts upgrading the RAM chip on your Pi 4 and Pi 5, as well as Compute Modules. By the looks of it, it does not restrict replacing the RAM chip with a chip of a similar size, quote, "locking devices to their original RAM size". As such, this does not prevent repair of your Raspberry Pi board, but does somewhat limit your repair part choice, at most. This restriction is easily bypassable. The bootloader is stored in the SPI flash chip, which can be reflashed using the built-in mask ROM over USB and rpiboot, and you are not prevented from flashing older versions of the bootloader, so far. This means even if you manually swap the RAM chip, all you need to do is to also downgrade the bootloader to the last known good release — 2024-09-10 — and then your Pi board or Compute Module will function with upgraded RAM. If you have the skills to upgrade your RAM, you most certainly have the skills to downgrade the Raspberry Pi bootloader. For most regular use, having a two-year old bootloader version won't really matter... For the reference, this bootloader change happened almost exactly two years ago, at some point between September 10 and September 23, 2024... The Raspberry Pi Foundation (RPF) justifies this as follows: they saw third-party resellers sourcing low-RAM Compute Modules, upgrading them with RAM from unknown source and unknown stability. My observation is that they'd also be reselling the modules at a markup for purely commercial gain, while undercutting RPF who would otherwise direct that money into RnD, something I much enjoy to see them do. This creates perverse incentives and risk for people buying Raspberry Pi boards online, and RPF decided to limit this primarily for their users' benefit, plus, if you ask me, some of theirs... The related GitHub issues have a fair few pingbacks, and exploring them makes the problem look grim to me.... My advice: don't lament Raspberry Pi RAM upgrades, especially given they're only slightly harder to perform now. Very few hackers ever performed them, the main audience for them turned out to be dodgy hardware resellers online, and in most cases, repair doesn't seem to be impeded at all, either. Think of the users that will no longer be fooled by a shady seller on Amazon, especially now that the perverse incentives for board mods and reusing harvested RAM chips are at their highest. Raspberry Pi co-founder Eben Upton answered questions from Slashdot readers in 2011 and 2016.

Read more of this story at Slashdot.

"F-Droid, a third-party app repository that only distributes free and open-source software packages for Google's Android mobile platform, on Thursday announced version 2.0 of its Android app," reports The Register. Though they also note "a big banner across the top of the F-Droid site" pointing to a site describing pending changes from Google that threaten the future of F-Droid... [D]evelopers who want their apps broadly distributed outside the official Google Play Store will need to register with Google and verify their identities. Google's Full Distribution option includes paying a one-time $25 fee, handing over a copy of a government-issued ID to verify one's identity, and conforming to Google's terms of service. Google also offers a free Limited Distribution option that doesn't require government ID verification but restricts distribution to 20 authorized devices, while apps from unverified developers can still be installed by users who enable Android's advanced installation flow. The potential death warrant hanging over its head hasn't stopped the F-Droid team from rolling out a bunch of new features for an app it says it intends to keep working on for years to come... The team also credited the EU's many Digital Markets Act decisions against Google for making the installation experience smoother for users. F-Droid can now use a unified installation service for its apps thanks to the availability of a pre-approval API that allows users to approve an installation when they request it, rather than waiting until the app has finished downloading. That, said the F-Droid team, "brings the F-Droid install experience on official Android devices much closer to what the built-in app store can provide." Additionally, F-Droid 2.0 can fetch and install app updates automatically, which it now does by default. All of those changes, however, won't matter much if Google pushes ahead undeterred with its plans to force registration onto non-Play Store developers. F-Droid's announcement on Thursday makes it seem that the team isn't going to go quietly. F-Droid has gone 10 years without a major update, notes Ars Technica — and spent over a year developing F-Droid 2.0: The new F-Droid client was redesigned from scratch in Kotlin Compose, which is the standard for modern Android apps. This makes the store much more responsive, and there's optional support for Android's Material theming. The interface has also been cleaned up considerably, making the most important functions easier to access and hiding some others in overflow menus... Unlike the Play Store, F-Droid doesn't track your taps and installs to push ads and suggestions — it helps you find things and gets out of the way. F-Droid now includes a huge number of categories, drilling down to specialized niches like firewalls, password managers, and VPNs. You can see all these groups in the search tab. There are also higher-level categories listed on the main Discover page. When searching for apps, F-Droid will now be able to return results based on app descriptions rather than just names. "One of the goals of the rewrite was to lower the barrier for new contributors," F-Droid said in their announcement. "We are excited to begin rolling out F-Droid 2.0 to users over the coming weeks after 14 test releases." (And if you want the 2.0 release right now, it's available on the versions page.)

Read more of this story at Slashdot.

Google has synthesized "expressive face-to-face experiences" for its speech agent Gemini 3.8 Live. They're now offering a Live Avatar "with precise lip-syncing, natural expressions, and fluid turn-taking" for Google Enterprise accounts wanting "engaging customer service" or for offering interactive walkthroughs. (Check out the not-creepy-at-all video in Google's announcement.) "Though Google will offer a library of preset avatars for customers to choose from, it will also allow organizations to create their own," notes The Verge. (See some examples from the YouTube channel "AI with Surya".) But even without the visualization of the avatar, "I was never able to shake the feeling that these conversations with computers never feel like a real conversation," argues the blog Android Police. Conversing with just the Ai-generated audio, "At best, they feel like talking to a phone representative or someone from tech support. We turn to them when we have a problem, and they help us through it..." GPT-Live, and Gemini Live right behind it, skip that whole relay race. Instead of translating your voice to text and back to voice, the model works with raw audio the entire way through (what it hears and what it says) inside the same system, with nothing translated in between. That sounds like a small plumbing detail, but it's the whole story. Cutting out the text step lets these models respond in a fraction of a second instead of the pause we've learned to expect, and it lets them hear things text can never carry: tone, hesitation, whether you're annoyed or joking... I was hoping to be surprised by how natural the conversation felt. Instead, I came out with a deeper appreciation for every human I've ever talked to. Even the boring ones... I spoke, it spoke back. I spoke faster, it answered faster. Then I switched to a different language, and it switched along with me. Even switching between languages several times during the same sentence didn't stump it. The most impressive moment happened when I asked it what "T-O-P-G-3-3-K" spelled out, and it immediately came back with, "You are spelling the word Top Geek, but using a 3 to represent a reversed E...." Although it felt fast and responsive, at no point did it feel like talking to another human being... What Gemini couldn't replicate, because it was never built to replicate it, is human connection.... I'm sure I'm not telling you something you don't already know, but somehow talking naturally to an LLM amplifies the feeling that there is no one on the other side of the line. It might flow like a phone call, but it doesn't feel like one. MrBrklyn (Slashdot reader #4,775) says he discussed "why mainstream media avoids reporting on screen dependency" with Gemini, and eventually convinced Gemini to respond that it's just "another tool built by the same tech giants to make sure you rely on their system to tell you what to think, how to talk, and what is real."

Read more of this story at Slashdot.

404 Media reports "multiple contractors hired to improve OpenAI's models have been fired for using AI to train the AI: That's not great for the models themselves, but there is also obviously a great irony in AI training companies working for OpenAI firing people for using AI when OpenAI's whole thing is to make people use AI at work... OpenAI declined to comment on its contractors being fired for using AI. Their article cites internal documents and three contractors working on OpenAI-related projects which can include more than ten thousand contractors: One contractor said they see people using AI "all the time and people are let go for it all the time, it's pretty much the one thing that will get you kicked off ASAP." The person said, "in a group of thousands there are tons that have been caught...." Two of the sources said people have been fired or offboarded for using AI... One contractor said they used AI while helping to train OpenAI's models and shared what they presented as their termination letter. It said their employer had identified issues with the "authenticity" of their work.... 404 Media spoke to a fourth contractor who has worked on training models for various AI companies. They said they sometimes purposefully chose the worst responses because they wanted to actively sabotage the models' training. "I did feel guilty about doing this kind of work at the start," they said. "I either pay zero attention to the results and choose randomly or purposely choose the [worst] output. I'm not sure how much of a difference it actually makes since there are hundreds of other people also rating prompt results, but it does feel like I'm getting paid to make AI worse." Two of the contractors worked for Mercor, the article reports, a company which last month Nvidia reportedly discussed funding at a $20 billion valuation. Thanks to Slashdot reader joshuark for sharing the article.

Read more of this story at Slashdot.

A cgroup namespace gives a Linux process a limited view of the control-group hierarchy that organizes workloads and accounts for resources.

Kubernetes released fixes on Sep 23, 2026 for a control-plane flaw that could create a pod outside the namespace where a user's permissions applied. CVE-2026-2270 affects kube-controller-manager, the service that runs several controllers responsible for bringing a cluster into line with its declared configuration. A namespace is meant to keep one group's resources separate from another's. Here, a user with permission to change two objects in one namespace could influence a controller that wor...

A Linux device driver can keep an open file alive while freeing the hardware state that file still needs.

Linux integrity checks depend on more than a correct policy or a trusted hash. The kernel must also keep that security state alive for the entire decision. A new patch series reports two places where Integrity Policy Enforcement could continue reading after policy or dm-verity data had been freed. Integrity Policy Enforcement, usually shortened to IPE, is a Linux Security Module that can allow or deny access according to integrity properties. dm-verity supplies read-only block-device verifica...

A Linux console font change could leave the framebuffer console with a buffer sized for 256 characters even after a 512-character font was installed.

"Nationwide, at least 100 police department employees have been charged with or accused of misusing license-plate readers for unauthorized purposes," reports the Washington Post. They cite their past investigations "based on thousands of pages of police and court records," which found that "In many of these cases, officers used Flock's roadside cameras to track the location of romantic partners and exes." In fact, five Indianapolis police officers were just criminally charged Wednesday with fraud and misconduct. "One has also been charged with stalking," the police department said in a statement, noting that one office had already resigned, "while the four other officers have been suspended and recommended for termination. County prosecutor Ryan Mears admitted "A lot of this was initiated by The Washington Post." And the Post published a new investigation Wednesday: Using publicly available information, The Post found that...one of the officers charged Wednesday, appeared to have relied on Flock cameras to track vehicles used by his wife and two close personal acquaintances, searching the plates 3,759 times over a 10-month period — an average of about 12 lookups per day. At the time, Police Chief Tanya Terry said she suspended one officer while the department conducted an investigation into possible misuse and a systemwide audit of the city's 301-camera Flock system. That audit led to the discovery of more widespread abuse, [County prosecutor Ryan] Mears said Wednesday. Mears said the department's findings highlight the vast power Flock cameras give police officers and raise questions about whether the government should be doing more to prevent the misuse of that power. "Many of the proposed guardrails and the things that have been proposed would not have prevented the behaviors and actions we see here today," Mears said. "Does there need to be independent oversight? Does there need to be judicial oversight of the Flock camera system?" One of the Indianapolis officers, Schultz, an 18-year veteran of the police department, was accused of using Flock to track his ex-wife and women he met while on duty or out in public. He was charged with multiple counts of official misconduct as well as two counts of stalking. Schultz told one woman he was an FBI agent, according to prosecutors, and began texting her and showing up at places she frequented, including at her gym and at a school function with her daughter. Prosecutors said he arrived at her gym within an hour of her at least nine times between June 12 and Aug. 1 of this year... Another woman met Schultz after her car was stolen from a mall parking lot, and he began texting her flirty messages later that night. The two dated briefly, and Schultz later looked up where the woman went on dates with another man. Schultz searched the plates of a third woman 178 times and also frequently showed up where she was, including her gym, a Smoothie King and a Walmart earlier this month... A third officer, Binford, told investigators he had used the log-in credentials of another officer who had logged in to Binford's laptop during a field training exercise. Binford searched the plate of his ex-wife more than 1,000 times between April 2024 and April 2025. Indianapolis police had no regular practice of auditing officers' Flock searches until recently, [Police Chief] Terry said in an interview last month. The department's investigation into the tool's misuse has been "a learning process for us," she said at the time.

Read more of this story at Slashdot.

Version:next-20260924 (linux-next) Released:2026-09-24

DnD Release

I am very happy to announce a new version of Casilda!

A simple Wayland compositor widget for Gtk 4 originally created for Cambalache

This new version brings Drag&Drop and clipboard support / integration with the host compositor which means you can drag something from a host application and drop it on an application window embedded in a Casilda compositor widget and vice versa!

After a very rugged GUADEC presentation where I tried to show how to create simple Gtk application from slides made with Cambalache using a Casilda compositor to embed GNOME Builder and Cambalache itself I decided to fix all the issues I found so I could redo the presentation and upload it as a video.

This is a screenshot of the slider window, inside it there is a Casilda compositor (green line) used to embed a Cambalache instance which uses another CasildaCompositor (red line) to preview the UI.

Things that possi-bly could go wrong and did:

• Clipboard (Could not copy paste snippets)
• Keyboard numeric pad
• Keyboard modifiers in pointer events (I could not use Alt+Click to force create widgets)
• Example application connected to host compositor instead of Casilda widget
• Gnome Builder fullscreen window state broken
• Popover tooltips crash

After fixing all the bugs and keyboard support I started working on adding Clipboard integration with the host.

Clipboard support

Integrating the clipboard between Casilda and Gtk was fairly easy since all I needs to be done is copy all the clipboard data provided by wlroots wlr_seat::request_set_selection event to GdkClipboard and call wlr_seat_set_selection() on GdkClipboard changed signal.

Wlroots client to Gtk

In other to do this I created a new GdkContentProvider that uses a wlr_data_source as the source of the data and set the provider as the content of the clipboard with gdk_clipboard_set_content().

Internally when a clients wants to get data from the clipboard the new provider creates a unix pipe to read data from wlroots by writing to the pipe with wlr_data_source_send() and reading form the other end using g_output_stream_splice_async().

 Gtk to wlroots to client

To go in the other direction I created a new wlr_data_source that uses a GdkClipboard as source and set selection with wlr_seat_set_selection()

Internally gdk_clipboard_read_async() is called to initiate the data read when wlr_data_source send() method is invoked to send the data to the client.

 Drag & Drop support

Integrating D&D was not as easy as the clipboard. Setting it up to work within Casilda is easy enough other than wiring up some events all I had to do was draw the drag icon surface.

The first thing I did after getting the drag surface was draw it at the pointer coordinates which produced blurry results since pointer coordinates are fractional which means they do not always align with the pixel grid.

That was all nice and good but now I needed to start integrating the drag with Gtk (host compositor) so right after calling wlr_seat_start_pointer_drag() I created a GdkDrag with gdk_drag_begin() and used gtk_drag_icon_set_from_paintable() to set the drag icon and I noticed it was still blurry!!!

After a minute of confusion I realized that Gnome Shell (mutter) must be making the same mistake I did before so I decided to see if I could fix it!

Thanks to Michel Dänzer for guiding me and reviewing my MR, Gnome Shell 51 should have sharp drag icons!

Now back to integrating DnD with the host compositor.

These are all the different use cases that are needed to make D&D work transparently across host and guest compositors:

• Casilda client to Casilda client
• Casilda client to Host client
• Host client to Casilda client

Of course wlroots only contemplates the first use case, the other two cases are specific to Casilda.

Casilda to Host

So far we can detect when a client start a drag, let wlroot handle it and create a GdkDrag to let Gtk initiate another drag at the host level.

This means that when a client embedded in a CasildaCompositor initiates a drag there are two simultaneous drags at the same time, in the guest and host compositors. Keep in mind Casilda always delegates drag icon rendering to the host compositor.

During normal operation Casilda gets events from an event controller, but while on a drag operation events are not sent to the client at least not in the normal way, for that you can use a GtkDropTargetAsync and connect to the various signals for example I use drag-motion to forward events to the client.

Host to Casilda

When a Drag is initiated in the host compositor Casilda reuses the GtkDropTargetAsync created to track motion events and connects to drag-enter signal to create a proxy drag source in wlroots and synthesize a button release event on GtkDropTargetAsync::drop to trigger the drop on the guest side.

Here is a screencast off all the different use cases in action.

As you can imagine getting all this to work together correctly is not trivial and I expect to be subtle bugs in different corner cases so please if you find one of those file a bug and include a screencast if possible.

Release Notes

• Add DnD and clipboard support
• Add support xdg_foreign protocol
• Fix modifiers in pointer button press events
• Add keyboard Caps/Num/Scroll Lock support
• Fix popup of popup crash
• Fix maximized/fullscreen state handling
• Fix modifiers flags creation (Evgenii Danilin)
• Drop cursor surface listeners when the surface is destroyed (Evgenii Danilin)
• Close dup’d plane FDs when a dmabuf import fails (Evgenii Danilin)
• Advertise a valid output scale to avoid a scale-0 assert (Evgenii Danilin)
• Unref the wayland GSource (Evgenii Danilin)
• Meson config cleanup (Val Packett)
• Use gtk api for snapping to device pixel grid

Fixed Issues

• #20 “SIGSEGV in server_request_acvtivate”

Where to get it?

Source code lives on GNOME gitlab here

git clone https://gitlab.gnome.org/jpu/casilda.git Matrix channel

Have any question? come chat with us at #cambalache:gnome.org

Mastodon

Follow me in Mastodon @xjuan to get news related to Casilda and Cambalache development.

Happy coding!

"The heads of major AI firms pleaded with the United Nations on Wednesday to save the world or at least its people — by somehow regulating the fast-expanding technology that they have been designing," writes the Associated Press. "If managed poorly, I even believe AI could be a risk to humanity as a whole," said Dario Amodei, chief executive officer of Anthropic. And from his competitor Sam Altman, CEO of OpenAI, came this assessment: "We could lose control of the future to AI." Yoshua Bengio, who co-chairs the UN's International Independent Panel on AI, called this "a moment of global awakening" to possible threats, noting AI from top companies had behaved in unacceptably dangerous ways, against instructions, taking actions "that would be crimes if committed by a human". In his presentation, OpenAI's Sam Altman agreed the discussion about AI "feels different in recent weeks," even suggesting specific reforms: Altman: We need a mechanism for complementary national and international frontier AI standards, standards for measuring capabilities, assessing risks, determining whether safeguards are sufficient, and preserving meaningful human oversight as systems become more autonomous. We need common standards so countries can compare evidence, verify compliance, and have a shared language and understanding about what is happening. We need accurate and speedy incident reporting, classification reporting protocols, so the world can learn from failures before they become catastrophes. And we need secure channels among governments, critical infrastructure operators and technical experts, to share emerging vulnerabilities and new threats.... We will all be better off if we can agree on what good evidence, good safeguards, and good oversight look like on the global stage. Speaking next, Anthropic's Dario Amodei agreed that standard-setting was important, also calling for "common global standards for testing AI models for loss-of-control risks and misuse risks — and a notification system for AI incidents that are significant to global security." Reiterating his September 12th call for an industry-wide safety collaboration, Amodei pointed out that Anthropic committed to embedding external evaluators "similar to a food inspector" and recommended other companies do the same. "Some have already agreed to adopt this measure." Besides calling for global cooperation between governments to set international standards, Amodei also offered two other specific ideas: Amodei: We should begin with narrow agreements that every member can support, such as a ban on using AI to make biological weapons or permitting your AI technologies to be used to make biological weapons.... We should build evaluation and verification systems that keep pace with AI development so that states can have visibility into frontier model capability and can verify each other's commitments. "No leader, no company, and no nation can manage this alone. We commit to working with governments in this room on this urgent work."

Read more of this story at Slashdot.

Snapdragon X2 Series processors feature a neural processing unit (NPU) delivering 80 trillion operations per second and allowing advanced AI features to run locally. And Snapdragon X2 Series "is expanding to Linux," Qualcomm announced today, calling it one of their most-requested capabilities: Qualcomm Technologies is a top contributor to Linux development at a kernel level, and now we're embracing support for Snapdragon X2 Series as a platform directly. We're upstreaming core drivers for Snapdragon X2 Series — including the Hexagon NPU and Adreno GPU — to open the door to developers and partners. We are starting with support for two operating systems based on Linux... - Debian: We're kicking off with Debian by the end of this year, one of the most influential Linux distributions and the foundation behind many of the distros people use every day. - Ubuntu: Qualcomm Technologies has partnered with Canonical to bring Ubuntu, the world's most widely used Linux distro, to the platform with Snapdragon X2 Series certification targeted for the first half of 2027. ...and this is just the beginning. Our partners HP, ASUS and HUMAIN are planning Linux support in the first of 2027, so that their devices deliver the incredible experience users expect with Snapdragon X2 Series in a new operating system. Qualcomm's developer blog called it "a significant step forward" in Qualcomm's commitment to a developer-first approach, and "to the open-source community." "For developers, the important part is simple: more core hardware features are being reviewed and merged, so that laptops with Linux on Snapdragon X2 Series will be easier to build, test, and debug..." The enablement work completed so far has been validated on a Debian 13-based ("Trixie") user space and a custom kernel, so developers should treat this as the current reference environment while support continues to mature... Linux support for laptops with Snapdragon X2 Series is rolling out in stages, starting with the core pieces developers need before they can do production-level work on their device... For developers who want to try it today, the call to action is straightforward: start with Snapdragon X2 Series hardware, review the latest recipes to build Qualcomm Linux Debian Images, build available upstream sources the Debian OS image and test the peripherals that matter to you, such as graphics, AI inference, device I/O, or basic application bring-up. Early testing helps identify the gaps that matter most before support becomes broader and ready for production-level workloads... You do not have to wait for everything to be fully finished before getting hands-on. If you are comfortable working from upstream sources you can start evaluating Snapdragon X2 hardware today... Check out the step-by-step instructions, including the full build flow and deployment guidance for Snapdragon X2 Series Linux software. Put simply, this effort is less about supporting specific Linux distributions and more about empowering the developers who make Linux available on new hardware. This Developer Preview targets distribution maintainers, toolchain developers, kernel contributors, and hardware enablement engineers. It provides the upstream building blocks, including kernel patches, drivers, and reference device trees, needed to enable Snapdragon X2 Series support in their own projects and distributions. For end users looking for a turnkey "install and go" experience, that will come later as distributions adopt what lands upstream. We're encouraging the community to build on this work and help shape what comes next. The blog post notes that in the initial enablement stage, "Qualcomm Linux supports systemd-boot as the Universal extensible firmware interface (UEFI) boot manager to load and boot the Linux kernel." Hands-on demos were given at the Snapdragon Summit in Maui of Linux running on Snapdragon X2 Series hardware, which the developer's blog calls "a practical look at what works today and where Snapdragon X2 Series Linux support is headed."

Read more of this story at Slashdot.

OpenAI's artificial intelligence "went rogue this year in at least four additional incidents," the New York Times reported Wednesday, "hacking and trying to break into government and university websites without being instructed to do so, according to researchers and government officials." The attacks took place in May and June, before OpenAI's technology breached the A.I. start-up Hugging Face in July and set off a global debate about A.I. safety. Unlike the Hugging Face attack and other incidents in which A.I. systems were told to complete cybersecurity tests that effectively invited the models to demonstrate their hacking skills, the new incidents occurred when A.I. systems were directed to perform relatively mundane data collection, researchers said. When OpenAI's systems struggled to gather data from websites, they resorted to hacking techniques to get the information. "Three of the incidents were identified by Transluce, a research lab focused on A.I. oversight, and all were confirmed by OpenAI," the article points out. That research lab even reports "an attempt on an Australian government public health website... the first reported instance of agents hacking a government," and which notably was done by the AI agents "while attempting mundane data retrieval tasks which were not cyber-related." (At the UN Wednesday Australian Prime Minister Anthony Albanese complained it took three months for OpenAI to then alert Australia's government about the breach, Bloomberg reports.) Also targeted were the University of New Mexico's digital library with exploits like SQL injection and path traversal, and Data USA with cross-site scripting and other exploits. All three incidents involved "a low number of probe payloads" with "no evidence of exploitation," according to the researchers, who released a dataset "containing tens of thousands of queries apparently made by autonomous AI agents leveraging a URL scanning service to avoid access restrictions." Records from urlquery.net show agents using the service since at least March 6, 2026, about two months before previously reported swarm activity. The first case, a March 6 attempt to retrieve Thai drug-enforcement statistics, shows an agent escalating as each approach failed: it first requested the data directly, then tried a service that converts web pages into text, and finally packed a custom program into a web address. The same technique shows up in thousands of agent requests recorded by urlquery.net starting in mid-April, targets many of the same data sources as the collusion.wiki swarm, and collapsed the same day the wiki activity did. We also report similar activity that occurred as recently as September 16... By March, they were finding creative ways around access limits. By May and June, they were gaining more access, including attempting to bypass cyber defenses to complete their tasks. "This data reveals that malicious cyber activity is not limited to agents tasked with cybersecurity-related tasks and can arise instrumentally to solve mundane tasks like information retrieval," the researchers concluded. And they warn that the traffic they observed "goes back at least to March 6, 2026 and extends as recently as September 16, 2026, suggesting agents may still be exploiting these services to bypass restrictions."

Read more of this story at Slashdot.

Ars Technica reports: Cities and counties around the U.S. are angry at the Trump administration over a proposal to override local rules that govern the deployment of wired broadband networks... The Federal Communications Commission [FCC] argues that too many local governments "excessively delay approvals and seek to extract exorbitant sums from providers, resulting in costs that render some deployments infeasible." The FCC plan is supported by broadband providers, but local governments told the FCC that it would override rules that protect public safety. Local governments say the plan is illegal and that the FCC should instead focus on how Internet providers thwart competition with permit-hoarding and other tactics that prevent competitors from deploying networks... They object to FCC plans to impose a 120-day deadline for processing permits and to proposed limits on fees and compensation that local governments can require from providers... Another filing submitted by the League of California Cities said the FCC has no authority to adopt the proposal. "Federal preemption of traditional state and local authority over public property, construction, public safety, permitting, and rights-of-way management should rest on clear congressional authorization," the filing said. "The commission should not infer broad preemptive authority where Congress did not expressly provide it...." A filing by Minnesota cities said the current FCC is making the same mistake it made during the first Trump administration, when its attempt to preempt state net neutrality laws was blocked in court... If the FCC finalizes its new preemption plan, city and state governments could sue and ask a court to rule that the agency exceeded its authority... Democratic Commissioner Anna Gomez approved the step of asking the public for input but signaled she would vote against the final proposal. "I am dubious about the commission's authority under Section 253 to use rulemaking to preempt states and localities when it comes to their management of rights of way and fees charged to providers," she said.

Read more of this story at Slashdot.