Agreguesi i feed

President Trump threatened a "substantial" new tariff on the European Union after Brussels fined Google more than $1 billion over alleged illegal trade practices. "The European Union will pay a very big price for this illegal and highly unethical conduct, which I have consistently warned them about," Trump wrote on Truth Social. "The penalties will be entirely reversed and, we anticipate, a substantial TARIFF to be placed on them at the earliest possible moment." Politico reports: The president's threat came just a day after U.S. Trade Representative Jamieson Greer warned that the EU's action against Google -- two fines totaling over $1 billion -- could imperil the bloc's relationship with the White House. At risk: the Turnberry deal, which Trump and European Commission President Ursula von der Leyen signed last fall, that capped U.S. tariffs on EU exports at 15 percent. [...] But the president's social media post could signal a coming breach. "The United States of America is not a 'PIGGYBANK' for Europe, nor will we allow it to be!" Trump wrote.

Read more of this story at Slashdot.

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

Version:7.1.5 (stable) Released:2026-07-24 Source:linux-7.1.5.tar.xz PGP Signature:linux-7.1.5.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-7.1.5

Version:6.18.40 (longterm) Released:2026-07-24 Source:linux-6.18.40.tar.xz PGP Signature:linux-6.18.40.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.18.40

Version:6.6.145 (longterm) Released:2026-07-24 Source:linux-6.6.145.tar.xz PGP Signature:linux-6.6.145.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.6.145

Version:6.1.178 (longterm) Released:2026-07-24 Source:linux-6.1.178.tar.xz PGP Signature:linux-6.1.178.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-6.1.178

Version:5.15.212 (longterm) Released:2026-07-24 Source:linux-5.15.212.tar.xz PGP Signature:linux-5.15.212.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-5.15.212

Version:5.10.261 (longterm) Released:2026-07-24 Source:linux-5.10.261.tar.xz PGP Signature:linux-5.10.261.tar.sign Patch:full (incremental) ChangeLog:ChangeLog-5.10.261

Two newly fixed storage bugs in Kubernetes showed more than just a problem with path traversal. They found a common security flaw in the cloud: powerful parts often think that requests accepted by a higher system are safe to run. This is a simple lesson for the platform and security teams: RBAC can accept a request without showing that its parameters will stay within a certain filesystem boundary. This is clear from a new study from SentinelLabs into flaws in the Kubernetes CSI drivers for NF...

Version:next-20260723 (linux-next) Released:2026-07-23

A Linux server can be fully patched, hardened, and compliant, yet still leave investigators unable to explain how an attacker got in. Without reliable Linux logging, even a well-secured system can become impossible to investigate.

A large volume of Linux security updates and advisories this week across major distributions once again, but it wasn't just the volume that was the story. Where maintainers and security teams focused their attention was evident in the concentration of fixes targeting Linux kernel updates, identity services, DNS infrastructure, and internet-facing software.

AI entered software development at full speed this year, and it is significantly impacting open-source projects as well. In this article, I discuss several trends I have recently observed in open source in connection with AI, and how these trends are changing the world of open-source software.

This article was originally published on my Czech blog, but it received such an overhelming response that I decided to translate it into English and publish it here as well.

Project Inflation

One of the trends that AI brings in general is an explosion of content. Search results are filled with generated websites, and social networks are inundated with generated images and videos. Source code is no exception. Today, GitHub is drowning in an ever-increasing number of repositories.

However, it is not as if a larger number of high-quality projects are being created. On the contrary, these are projects where you have no idea whether you can rely on them or not. In the past, if you stumbled upon a more extensive project with thousands of lines of code, there was a certain assumption that if someone went to the trouble of creating something like that, they would have some knowledge of the problem, a personal connection to their creation, and some willingness to maintain it going forward.

You can no longer rely on this at all. Today, you can generate a project with several thousand lines of code in a matter of moments. It could be complete nonsense or even something dangerous; it could be something functional that someone generated for their own immediate needs and posted to GitHub, but with no interest in turning it into an open-source project. Because a repository with code doesn’t make an open-source project. The difference between a piece of code on GitHub and an open-source project is that an open-source project solves problems and use cases for its users, not just the author’s one-off need. And most authors of such quick-and-dirty code simply aren’t interested in doing that.

This is clearly visible in projects like MeshCore, for instance. There are dozens of forks of everything imaginable. Missing a feature in the official MeshCore firmware? You just fork it, vibe-code the missing piece, and dump it on GitHub as MeshCore-UltimateEdition. The problem is that it was created with minimal effort, the author usually has no relationship to it, gets bored after a month, and it becomes abandonware before it even has a chance to age.

About ten years ago, people started saying that the concept of Linux repositories had run its course. In the 2000s, they were practically the only source of Linux software. If a project didn’t make it into distribution repositories, it had a problem. But then the number of open-source projects grew at such a rate that distributions couldn’t keep up. Users had to start getting their software elsewhere, and software authors learned to do without distributions. Just a few years ago, the “everything I need, I find in Debian” approach seemed definitively dead.

However, it is possible that curated software sources – like Linux distribution repositories – will make a comeback. The open-source software world is becoming so chaotic that users will once again start appreciating sources containing curated software that someone has vetted for them and that they can rely on six months down the road.

Review Overwhelm

Another trend that AI has triggered in open source is ‘review overwhelm’. Previously, writing code acted as a natural filter because it required a non-trivial amount of effort and time investment. That is now gone, making code creation fast and easy. But someone still has to review this code before it goes into serious production. The review processes that worked in open-source projects for years are now at their capacity limits.

In GNOME 50, support for Google Drive was removed because nobody had been maintaining it for a long time. Users were naturally unhappy about it, and eventually, one user stepped up, re-added the support, and submitted it upstream to the gvfs project.

A colleague responsible for maintaining that project lamented that it was a change involving 4,000 lines of code. Even though it seems to work at a basic level, it was clearly generated using AI. He will still have to go through it line by line to verify that it actually works as intended and meets the code quality standards required to commit to maintaining it long-term.

Most of the effort has thus shifted from code creation to code review, which is typical for AI. The problem in open source, however, is that developers experienced enough to review and merge code were already a bottleneck before AI. Now, the problem has deepened significantly. And in the example above, my colleague can count himself lucky that the contributor is responsive and has shown long-term interest in the issue.

Today, that is more of a rare exception. Common contributions consist of someone wildly vibe-coding something without any deeper interest or understanding of the subject, and throwing it over the wall to the maintainers.

I have a fairly recent experience with this in Meshy. Someone submitted a pull request with 9,000 lines of changed code, which was supposed to add support for macOS. I spent an hour one evening doing a very quick review, and even during that short time, I ran into numerous issues: the code was blatantly AI-generated, several thousand lines were just completely useless replacements of single quotes with double quotes, parts of the code unrelated to the problem were modified, and it overwrote all the changes I had made in the main branch over the last few weeks.

The author never responded to my comments and I never heard from him again. My takeaway was that even that one hour was too big of a time investment for contributions like that, and next time I will reject them much faster.

Some projects are responding to this situation by tightening basic contribution requirements. For example, Flathub’s decision to reject AI-generated apps caused quite a stir. Many people criticized it as shooting themselves in the foot, but you have to look at their reality.

Flathub currently hosts several thousand apps, with more added every day. Only three people handle the reviews. Although their review process is highly automated, they do it very thoroughly, and a lot of manual input is still required. It’s clear their goal isn’t just to spot the worst slop, but to maintain a relatively high standard of code hygiene. In the last six months, I submitted two apps to Flathub, and the review process ultimately contributed to improving the quality of the apps themselves.

However, this has now clashed with the reality of people submitting completely vibe-coded apps without a shred of personal effort. The ticket template for requesting inclusion asks a few questions, including a requirement to upload a short video showing how the app works. It really isn’t demanding, and anyone can put it together in 15 minutes. Yet even that is too much effort for creators of AI slop.

Instead of fulfilling these minimal requirements, some labeled it an attack on Linux’s freedom and immediately vibe-coded an alternative to Flathub that was supposed to be open to everyone. Unsurprisingly, it barely lasted a month.

Not only do open-source maintainers lack the capacity to satisfy this demand for code review, but they are also losing the motivation to do it. Often, it would be faster for them to write the feature themselves, but the review process was historically how they cultivated new long-term contributors and potential successors. When someone sends you a vibe-coded contribution that cost them zero effort and which they likely don’t even understand, how do you expect to mentor them into a contributor who will help the project in the long run?

Open-source software was never just about the end result; it was also about the process – where contributors build a relationship with the project and grow into someone who will eventually pass that on to others. This stands in sharp contrast to the world of AI, where it’s all about the result. As fast as possible, with as little effort as possible.

Declining Motivation to Publish Code

In the 1990s, Francis Fukuyama declared democracy and liberal economics to be the ultimate victors in the arrangement of the world order. Today, as democracy erodes globally and the existing economic order crumbles, that looks like a prematurely bold statement to say the least. Similarly, just a few years ago, impressed by the developments of the last few decades, some hailed open source as the ultimate winner among software development models. Are we about to face a sobering reality check similar to Fukuyama’s thesis?

Lately, I’ve been observing a subtle, yet present trend of stepping back from open-source development. One argument against open development I hear concerns the aforementioned review overload. For some projects, the costs associated with being overwhelmed by AI slop can outweigh the benefits of useful community contributions. They might still publish the source code for transparency’s sake, but they transform from an open-development project into an open-source, closed-development project. And those who don’t care as much about transparency may close off the source code entirely.

Another argument against making source code public is the fear of license circumvention. Today’s LLMs train on source code regardless of its license and can then easily generate a similar solution that you can publish under whatever license you choose.

This isn’t an issue for permissive licenses, as the author has already accepted that anyone can do practically whatever they want with the code. However, AI poses a direct threat to copyleft licenses like the GNU GPL. Authors usually choose these to ensure their work remains open forever and that anyone who uses it shares their improvements back with the community. If an LLM trains on a project you’ve worked on for years and then generates a very similar solution published under a proprietary license, it effectively bypasses this principle.

Take MeshCore again as an example: the protocol itself and the firmware are open-source, but the clients are closed. Recently, it came to light in the community that a core team member secretly applied for the MeshCore trademark and started vibe-coding his own closed-source solutions based on the available code. MeshCore founder Scott Powell cited this as something that reaffirmed his decision to keep the client source code private. Specifically, he wrote:

So, I see open source, in the age of AI, as offering up your blood, sweat and tears for others to rip-off, but in innumerable ways.

We may disagree with Powell’s perspective, but it represents a legitimate stance that I see more and more often around me. I see lifelong open-source advocates – people who used to publish every last helper script because they wanted to share – who now keep those things to themselves, offering them to others only upon request. They have reasons similar to Powell’s.

Open source also grew out of the need to share. Writing code was hard; maintaining it was even harder. Why should everyone implement the same thing independently? Let’s join forces in an open-source project, write a shared library, and everyone can benefit from the results. The infrastructure powering the Internet today was built on this foundation. But AI is suppressing this need.

For instance, I encounter opinions that WordPress is dead because “I can just easily generate my own CMS.” In my view, that severely underestimates what an open-source project actually provides. It is so much more than just writing code, and this strategy of swapping a dependency on an open-source project for a dependency on an LLM might not pay off in the long run.

Nevertheless, the reliance on shared open-source components has indeed decreased to some extent. AI might not replace everything, but why depend on a large external library when you don’t even need 10% of its functionality, if AI can quickly rip off that 10% for you after learning from the original library? And once you have your own implementation, why would you contribute improvements back to a shared open-source project?

The final argument against publishing source code that I’ve been hearing lately is security. Granted, I’ve heard this argument throughout the two decades I’ve been involved in open source, but it has never been this loud. For years, critics have claimed that open source is insecure because it allows attackers to study the code and hunt for vulnerabilities. In response, open-source advocates argue that security through obscurity is not real security and that open-source software is safer because “given enough eyeballs, all bugs are shallow.”

Today, however, open-source projects are literally flooded with security vulnerability reports generated by AI. The volume is so unprecedented that it is genuinely easy to fall into the trap of believing closed code is safer. It’s interesting to note that while news headlines cover how many bugs AI has found, they rarely mention how many security bugs AI has fixed. Fixing them still requires a deep understanding of the codebase and is still done by human programmers. And just like reviewing pull requests, it is overwhelming their capacity.

In this case, though, I believe it’s just a temporary trend. Open-source projects will eventually wade through these security reports, the general security of maintained open-source software will improve, and the ecosystem will benefit in the end. As for the other trends mentioned in this article, it’s hard to say. I’m not quite as unconditionally optimistic there.

• Tech. planning call, sync with Caolan, lunch with J. Pleased to be mentioned in the Irish Parliament - go Ireland!
• Really pleased to see Collabora Online 26.04 released for customer use: the foundation of another year of development and improvement. Thanks to our partners for supporting our press release, and for our customers and partners for funding much of the awesome team that create a slew of fun new features alongside the community.

Putting on my Planet GNOME editor hat for a quick PSA!

Planet GNOME is a convenient aggregator for personal blogs by members of our community. While all content must follow our Code of Conduct, the views expressed in these posts are solely those of the individual authors.

They don’t represent or reflect the opinions of the GNOME Project as an entity or community.

To help highlight this, we’ve added a “Voices of the community” tagline to the website header. It links directly to our “Add feed” section, which also emphasizes that Planet collects the latest posts from personal blogs.

Enjoy the personal insights and variety of perspectives!

Northrop Grumman has launched a private satellite-servicing mission to attach life-extending "jetpacks" to aging communications satellites in geosynchronous orbit. "It's the second satellite-saving mission to launch this month, all part of a growing, money-saving effort to keep spacecraft running as long as possible," reports Phys.org. From the report: Launched by SpaceX, Northrop Grumman's mission robotic vehicle -- dubbed MRV -- and its jetpacks will spend the next year angling into the proper orbit 22,300 miles (36,000 kilometers) above Earth. Hundreds of satellites orbit at this so-called geosynchronous orbit, where they match the speed of Earth's rotation and keep to the same part of the sky for continuous coverage. Once in place by mid-2027, the minivan-sized spacecraft will use its 10-foot (9-meter) arms to attach a jetpack to an aging communication satellite. Then it will zip off to two more satellites in need. For its debut flight, the spacecraft was accompanied by three electric-propelled jetpacks that peeled away separately following liftoff. Like the MRV, the jetpacks will use their own xenon gas thrusters to get to the desired orbit. Once in place, the jetpacks will wait for the robot to grab them, one at a time, and plug them into their designated satellites. Each jetpack -- the size of a washing machine -- will provide the necessary oomph for an out-of-gas satellite to keep operating for several more years instead of retiring. If it works, it will be a boon for satellite operators SES of Luxembourg and Optus of Australia, saving them millions of dollars in replacement costs.

Read more of this story at Slashdot.

Longtime Slashdot reader BeaverCleaver shares a report from the BBC: The wreckage of a Pan American Airways plane has been found 74 years after it plunged into the Atlantic Ocean in a crash that prompted mandatory airline safety briefings. The Clipper Endeavor was found 2,000ft (610m) below sea level off the coast of Puerto Rico with a sonar-equipped drone. It went down on April 11, 1952, following multiple-engine failure shortly after take-off. Everyone onboard survived the impact -- but passengers struggled to locate life vests and rafts as the plane rapidly sank. Of the 69 passengers and crew onboard, just 17 survived. The disaster led to sweeping reforms in aviation safety, including compulsory pre-flight safety briefings on every commercial flight. [...] Today, before every commercial flight, cabin crew are required to outline where a plane's exits are, as well as the location of life vests and how to inflate them.

Read more of this story at Slashdot.

Most Linux teams don't struggle to find vulnerabilities anymore. They struggle to decide which ones deserve attention first. Between daily scanner results, vendor advisories, and hundreds of new CVEs each month, the challenge isn't visibility—it's prioritization.

When Felipe first emailed us about the GUADEC 2026 travel grant, we were thrilled to learn that we were going to have the opportunity to attend the conference in person.

This was my first GUADEC, and it was a pleasure to meet the GNOME community and put faces to names. The conference was held in A Coruña, Spain, which turned out to be an amazing city with great food, friendly people, and beautiful views along the coast.

Community

The first thing I would like to mention was how patient and open the community was to both my fiancée Laureen and me. We knew going into the conference that we were much more junior than many of the developers attending, but everyone was incredibly approachable.

I received a great deal of help debugging issues in my local development environment, as well as guidance on some of the more difficult parts of my GSoC project.

Talks

The talks were very informative and I took way too many notes to include them all here without turning this into a novel. That said, I wanted to write a short summary of a couple of talks that I found interesting:

Varlink for System Components

Sebastian Wick gave a talk about modernizing the system component stack. His proposed idea for allowing more memory safety and zero cost abstractions was to write components in Rust, however this introduces the issue of introspection. For asynchronous functionality, Tokio and Glib both have main loops, and moving data between the loops can introduce a lot of overhead. GObject bindings can also make Rust's memory safety essentially moot.

Sebastian spoke about potentially not using GObject in some cases, and instead exposing more functionality over IPC using Varlink. Varlink is language agnostic, and services could be consumed from many languages without requiring GObject bindings. This process also would be very simple, allowing signals to occur as JSON strings that are easily observable. This would require some new crates to replace Glib functionality, and some more complicated functionality like file thrashing and sftp could be particularly difficult.

It is early, the ecosystem is still being built, but Sebastian argued that usage patterns will evolve and getting involved now will help shape the future of GNOME and Rust.

Using GTK in C++ with Peel

Sergey Bugaev hosted a workshop on using GTK from C++ with Peel. Peel is a library that allows you to use GTK in C++ to make GTK applications and widgets. Sergey made a simple widget that can draw using stylus input, and he walked us through the process of creating a simple application using Peel. The workshop was very informative.

I really regret not coding his example myself, I wish a recording of the lecture had been taken. That said, his repo can be found at https://gitlab.gnome.org/bugaevc/peel and his readme has instructions for usage and a basic code example.

Debugging with Tracy

Ivan Molodetskikh gave a talk that seemed really handy to me about using Tracy to profile performance for Mutter, GNOME shell, and applications. I had never heard of Tracy before this talk, however the capabilities seemed very handy. Tracy visualizes "zones" on a timeline, allowing you to see exactly where execution time is being spent across threads. The Tracy zones must nest correctly, where parent zones cannot end before their child zones. It can also show where threads are waiting. This allows for a very clear visualization of where time is being spent in the application, and can help identify bottlenecks or bugs.

The major downside to Tracy is that it requires a lot of setup, and the application must be compiled with the Tracy client library. Ivan gave a fairly in-depth breakdown of how to add Tracy profiling to an application, and I will go back to the recording of his talk to actually implement it in the future.

Technical Take Aways for My Project

• Sergey Bugaev helped me get the GIR generation for my C API working correctly. We also improved the FFI by exposing PitiviTimelineRuler directly in the public header rather than accepting a generic GtkWidget* and performing a runtime type check. This makes the API more type-safe and simplifies the Rust implementation. The GIR generation currently works after calling gtk::init() from pitivi_timeline_ruler_get_type(), but Sergey pointed out that this approach will likely fail in CI because the generated scanner shouldn't require GTK to be initialized this way. I'm still trying to build a solid mental model of how GIR generation and introspection work, so if anyone has experience with bindings, I'd love to hear your thoughts.

• Federico also spent some time reviewing my project with me. He suggested refactoring PitiviTimelineRuler so all of the mutable drawing state lives inside a single RefCell rather than several individual ones, I think the result would look something like this:

#[derive(Default)] struct DrawingState { cache: BTreeMap<...>, font: Option<...>, handler_id: Option<...>, } #[derive(Properties)] #[properties(wrapper_type = super::MyWidget)] pub struct MyWidget { #[property(get, set)] zoom_level: Cell<u64>, state: RefCell<DrawingState>, } Thanks to GNOME Foundation

I want to give a special thanks to the GNOME Foundation for granting us the travel grant to attend GUADEC 2026. It was a wonderful experience and I look forward to attending future conferences in person!

A full-resolution album of these photos is available under CC BY 4.0 for anyone in the GNOME community to reuse. https://www.flickr.com/photos/204880226@N08/albums/72177720334807665/

"General Motors has been pulling a Tim Cook and boosting its software and subscription business," reports Business Insider. During the automaker's Tuesday earnings call, executives said they're increasingly leaning on software subscriptions like OnStar and Super Cruise to generate high-margin recurring revenue long after customers buy their vehicles. GM says OnStar brought in about $800 million in the second quarter, while Super Cruise revenue grew about 70% year over year. From the report: GM says its software business keeps roughly 70 cents of every dollar it brings in. That's a rare level of profitability in the auto industry, as many car sales generate just four to 10 cents per sales dollar. [...] GM expects to add about 1 million OnStar subscribers this year, bringing the total close to 13 million. Super Cruise, GM's hands-free, eyes-on driving system, is growing even faster. GM added about 70,000 subscribers during the quarter and expects to end the year with more than 850,000. Revenue from the service increased about 70% from a year earlier. And a lot of drivers are sticking around after the free period ends. GM said between 30% and 40% of eligible owners continue paying after their included three-year Super Cruise subscription expires. [..] "We do think we have tremendous levers, multiple levers of growth," Barra said on the call. "We definitely think there's a lot of opportunity at GM to grow, improve margins, and become less cyclical." "Software and services are becoming increasingly important to how customers experience GM vehicles and how we deliver value beyond the initial purchase," a spokesperson previously told Business Insider. "As vehicles become more software-defined, we can introduce new digital experiences through updates and optional services rather than hardware changes."

Read more of this story at Slashdot.