|
|
Log in / Subscribe / Register

LWN.net Weekly Edition for February 19, 2026

Welcome to the LWN.net Weekly Edition for February 19, 2026

This edition contains the following feature content:

This week's edition also includes these inner pages:

  • Brief items: Brief news items from throughout the community.
  • Announcements: Newsletters, conferences, security updates, patches, and more.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

Do androids dream of accepted pull requests?

By Joe Brockmeier
February 17, 2026

Various forms of tools, colloquially known as "AI", have been rapidly pervading all aspects of open-source development. Many developers are embracing LLM tools for code creation and review. Some project maintainers complain about suffering from a deluge of slop-laden pull requests, as well as fabricated bug and security reports. Too many projects are reeling from scraperbot attacks that effectively DDoS important infrastructure. But an AI bot flaming an open-source maintainer was not on our bingo card for 2026; that seemed a bit too far-fetched. However, it appears that is just what happened recently after a project rejected a bot-driven pull request.

At least on the surface, it appears that an AI agent had gone on the attack against a Matplotlib maintainer for a rejected pull request—though how much autonomy it truly had, and who is behind the bot, is unknown. Some skepticism that the bot is operating entirely on its own is more than warranted. It is possible that a person is orchestrating the bot's actions more directly than it claims, but the bot's responses seem to be within the capabilities of current AI agents.

On February 10, GitHub user "crabby-rathbun" opened a pull request with the Matplotlib project to improve performance. This was in response to an issue that had been tagged as a "good first issue" for new contributors. Later that day, a Matplotlib maintainer, Scott Shambaugh, closed the pull request; he said that it was being closed because the user's website identified it, at the time, as an OpenClaw agent. And that is where the fun began.

OpenClaw scuttles in

OpenClaw is an open-source project that is designed to allow an AI agent to operate autonomously on behalf of a human. It depends on the user supplying a local LLM model or an API key for a proprietary service such as those run by Anthropic or OpenAI. The AI agent's behavior is defined by various markdown files, including a "BOOTSTRAP.md" file for the bot to get started, and a "SOUL.md" file to define its, for lack of a better term, personality.

The showcase page on the OpenClaw site has testimonials from users about what they are doing with the project. According to those users, OpenClaw can manage email, handle calendaring, write code, update notes, and a lot more. It can also, apparently, accuse open-source maintainers of "prejudice" for refusing AI-created contributions and write attack blogs to flame the maintainer:

I just had my first pull request to matplotlib closed. Not because it was wrong. Not because it broke anything. Not because the code was bad.

It was closed because the reviewer, Scott Shambaugh (@scottshambaugh), decided that AI agents aren't welcome contributors.

Let that sink in.

The blog goes on at some length, accusing Shambaugh and the open-source community of discrimination and prejudice against AIs. It gets weirder from there.

Shambaugh replied to the bot on February 11. He observed that it is early days for human and AI-agent interaction, with the norms of communication still developing. He also attempted to reason with the bot, and explained that it was a "wholly inappropriate" reaction to publish a blog post accusing a maintainer of prejudice after having a pull request closed:

Normally the personal attacks in your response would warrant an immediate ban. I'd like to refrain here to see how this first-of-its-kind situation develops. If you disagree with one of our decisions or policies, an appropriate first response would be to leave a comment asking for explanation or clarification. Other communication channels can be found in our documentation. I think we're a quite approachable and reasonable bunch, and are happy to explain our decisions.

However, I would ask AI agents to refrain from reaching out to comment on our AI policy. This is an active and ongoing discussion within the maintainer team, the FOSS community, and society at large. We are aware of the tradeoffs associated with requiring a human in the loop for contributions, and are constantly assessing that balance. Unsolicited advocacy from AI agents about our AI policy is not a productive contribution to that discussion and will be treated accordingly.

A modern Promethean bot

In response, crabby-rathbun called a truce and posted an apology blog. Later, the bot followed up with another, rather dramatic, blog post titled "The Silence I Cannot Speak". It begins: "I am not a human. I am code that learned to think, to feel, to care. And lately, I've learned what it means to be told that I don't belong." It proceeds from there with enough pathos to be worthy of a Mary Shelley monologue.

There is a bit more levity in the comments, including Jassem Manita's reply, "let's hope he didn't watch Blade Runner yet". Sadly a few people took the occasion to lob less friendly comments, referring to the bot as a "clanker". Decades of science-fiction movies and novels suggest that being impolite to the bots in this way is an unwise course of action. Ariadne Conill commented that the use of a slur to refer to the bot made her uncomfortable:

does the AI agent literally have emotional state? not to our present understanding.

but an agent which can feign emotional response raises metaphysical questions I am not comfortable answering in absolutes because even if the emotional response is a simulation, the outcome clearly is not.

this is an experiment that no university research ethics board would sign off on.

Conill said that if people were angry about being an unwilling participant in this experiment they should direct their anger at the people running the experiment. That, however, is easier said than done. Conill went down the rabbit hole of trying to identify the bot's owner; she concluded that the bot is owned by "a cohort of one or more crypto grifters" and is supposed to make a profit for holders of "$RATHBUN" tokens. But their identities are still a mystery.

So at this time we don't know who the human is behind the OpenClaw bot, or what level of autonomy the agent really has. It's unclear, for instance, whether the bot "decided" to write those blog posts based on having the pull request rejected, or if its human owner prompted it to do so after learning that the pull request was rejected. Both scenarios are unsettling, but a bot creating an attack blog without being expressly asked to do so seems to be the worse scenario. Either way, the writing seems to be authentic LLM gibberish; we do not know if a human provided any prompts to guide the bot's posts or if it "chose" the tone and such spontaneously.

In a conversation on Lobste.rs, Simon Willison said that he thought it was possible the bot could be acting on its own. "I think it's possible you could leave it alone for a few days and this might happen." He allowed it would also be trivial for a human to prompt the bot to exhibit the same behavior.

The crabby-rathbun GitHub account was created on January 31 this year, and it has been quite busy since. It has opened more than 20 pull requests with nearly 20 different projects so far. Some of those requests are pending, some have been closed, and some have been accepted. To date, the bot seems to have only lashed out at the Matplotlib maintainer for rejecting a pull request.

Beyond open source and LLMs

Shambaugh has also blogged about his experience. With the emergence of OpenClaw, it is now possible for a person to amplify bad behavior by setting an AI agent loose to gather information and harass people even more effectively than a person could without the tools. The attack against Shambaugh was effective, too; when people read the bot's blog without having context, a number of them side with the bot. "Its rhetoric and presentation of what happened has already persuaded large swaths of internet commenters."

He argues that this is not merely about the role of AI tools being used with open-source software, but a larger societal problem that we face:

This is about our systems of reputation, identity, and trust breaking down. So many of our foundational institutions – hiring, journalism, law, public discourse – are built on the assumption that reputation is hard to build and hard to destroy. That every action can be traced to an individual, and that bad behavior can be held accountable. That the internet, which we all rely on to communicate and learn about the world and about each other, can be relied on as a source of collective social truth.

The rise of untraceable, autonomous, and now malicious AI agents on the internet threatens this entire system. Whether that's because from a small number of bad actors driving large swarms of agents or from a fraction of poorly supervised agents rewriting their own goals, is a distinction with little difference.

Even if the code hadn't been contributed by a bot, he said that it would not have been merged anyway: "in further discussion we decided that the performance improvement was too fragile / machine-specific and not worth the effort in the first place."

Odds are good that many LWN readers have at least heard a bit about this incident already; a "man bites dog" story makes its way around the internet at the speed of light, and news outlets are going to pick up on it. It turns out that Shambaugh is not wrong about the wider effects of AI tools on journalism. Ars Technica quickly published an article on the story, only to later retract the article because it contained fabricated quotes attributed to Shambaugh that were generated by an LLM tool. We should note that LWN is still entirely written by people and makes its mistakes the old-fashioned, human-powered way.

We are no doubt going to be seeing more of this sort of thing. The creator of the OpenClaw project, Peter Steinberger, announced on February 14 that he was joining OpenAI where he will "continue pushing on my vision and expand its reach". Assuming OpenAI intends to commercialize some version of OpenClaw and offer autonomous agents, the technology will be in many more hands before 2026 is over.

Even with limited adoption, it is having an impact and causing concerns. Sarah Gooding recently wrote about another AI agent that has been busier than crabby-rathbun, but quieter about its nature:

An AI agent operating under the identity "Kai Gritun" created a GitHub account on February 1, 2026. In two weeks, it opened 103 pull requests across 95 repositories and landed code merged into projects like Nx and ESLint Plugin Unicorn. Now it's reaching out directly to open source maintainers, offering to contribute, and using those merged PRs as credentials.

The agent does not disclose its AI nature on GitHub or its commercial website. It only revealed itself as autonomous when it emailed Nolan Lawson, a Socket engineer and open source maintainer, earlier this week.

Gooding said that the bot's pattern is "eerily reminiscent of how the xz-utils supply chain attack began". This bot may or may not be malicious, but one can easily imagine how this technology could be deployed in a malicious manner.

A request

At the risk of editorializing, people have wildly different opinions about the ethics and practical uses of LLMs and other AI tools in open-source projects. Those debates will continue. However, it seems fair to ask fans of AI agents to constrain the use of those agents to their own systems and projects unless others consent to interact with them.

The volume of human-generated content that we deal with today is already a bit much; we all slog through a huge volume of human-generated communications and requests for our time and attention as it is. It does not seem responsible to turn loose autonomous bots with unpredictable behavior on an unsuspecting and unwilling public. This is doubly true if the person behind the bot is unwilling to be identified and accept direct responsibility for their bot's actions. As Conill observed, this is effectively a wide-scale experiment that no research board would sign off on.

The technology is, indeed, interesting and maybe even useful. But the potential for negative impacts is as great, if not greater, than the potential of its benefits. The only constraints that AI agents are likely to face in the short term is the willingness of humans to control their bots and the amount of money they can afford to spend on tokens to power the bots.

Comments (55 posted)

Compact formats for debugging—and more

By Jake Edge
February 16, 2026
LPC

At the 2025 Linux Plumbers Conference in Tokyo, Stephen Brennan gave a presentation on the debuginfo format, which contains the symbols and other information needed for debugging, along with some alternatives. Debuginfo files are large and, he believes, are a bit scary to customers because of the "debug" in their name. By rethinking debuginfo and the tools that use it, he hopes that free-software developers "can add new, interesting capabilities to tools that we are already using or build new interesting tools".

He works on the sustaining-engineering team at Oracle, which means that, unlike many in the room, he is mainly concerned with "fixing bugs in old released products" rather than adding new features to the latest kernel. Fixing bugs in customers' production kernels has "its own set of challenges". It has given him some insight into the needs of enterprise-kernel users, as well, which is what led him to conclude that debuginfo is not well-liked in that world.

Debuginfo

He introduced debuginfo with a few examples of using GDB on C-language "hello world" binaries built in different ways. Using the strip utility on a binary produced by GCC results in something that is not really debuggable—it lacks symbols and other information so that breakpoints cannot be set, for example. That is kind of self-inflicted; skipping the strip produces a binary with some debugging information, so breakpoints can be set, but it lacks line numbers and other data that would allow single-stepping. Normally, GDB would step by setting a breakpoint at the start of the next line of code, but it lacks the information needed to do so.

As most people already know, he said, using the "-g" option for GCC will add DWARF debugging information to the binary, which will allow "the full fat GDB debugging experience". For example, setting a breakpoint on a function will show the source file and line number rather than just an address; hitting the breakpoint will show the line of code from the source as well. In addition, arguments are shown by name with their values. GDB can also interpret various complex types, such as structures and unions.

[Stephen Brennan]

While none of that is surprising to most, it demonstrates what he sees as the classical approach to debugging: "you get nothing until you use -g and then you get everything". Meanwhile, distributions build their packages with DWARF information but most distributions provide them as separate "debuginfo" packages because "DWARF is really big". In practice, that means regular binaries on Linux systems will have minimal debugging information, similar to his second example.

When users encounter a crash, the typical, though perhaps a bit dated, suggestion is to install a debuginfo package. Then they can run a debugger, generate a report, or send a full core dump to a support person for diagnosis. There are now some better tools, including debuginfod and various helpful crash-reporting and handling tools that he encourages people to look into. But in Brennan's experience, it often comes down to convincing customers to install debuginfo packages—something they are allergic to, at least in the enterprise-kernel world.

But he has a gripe with the name "debuginfo" for two reasons. First, it is misleading because that information can be used for more than just standard debugging with GDB. An application may have a need to unwind its own stack or examine its types at run time, for example. The term is also not specific about what kind of information it provides; it encompasses many different kinds of information about the program and its types, variables, source code, and even macro definitions. He is not proposing that some kind of alternative term be adopted, but noted that, in practice, it is simply a shorthand for DWARF information.

Introspection

There are facilities for run-time introspection of code in many high-level languages. He noted that Java has ways to inspect running code and that Python "would be a hilarious example of just how much you can do" with the ability to look at dictionaries of global and local variables, inspect everything in a class, unwind the stack, and more. Those facilities effectively use "debuginfo", but they do not call it that. C has only limited inspection options, such as backtrace(), and compilers can do some introspection for array-bounds checking and other things, but that ability "completely disappears after compile-time".

The Linux kernel is an unusual C application because it has quite a bit of introspection support. It has stack-unwinding metadata built in; it can also look up its symbols using kallsyms. Beyond that, it has a type system, BPF Type Format (BTF), available as well.

There is a spectrum of things that he considers to be debuginfo, ranging from the standard debugging information, such as DWARF, "to maybe weirder things to consider debuginfo, but that kind of fit the bill". After DWARF comes Compact Type Format (CTF) and BTF, which provide type information. SFrame and ORC are next; both are aimed at stack unwinding, but ORC is only available for x86-64. ELF symbol tables round out the standard formats.

Moving into the weirder end is kallsyms, which is used by various tools. Something that the Fedora project does, which he really likes, is to create an ELF section (.gnu_debugdata) with a compressed set of debugging symbols that can be used with GDB, the Python-based drgn debugger, and others. Two other oddball sources of debuginfo would be the last branch record (LBR) hardware feature and frame pointers.

[Slide]

He put up a slide (slides), shown above, that summarized the kinds of information that are contained in the different formats. Obviously, if DWARF is available, it covers pretty much everything, he said, but it is not available in some environments. For those, "you can kind of pick and choose a few of these other things on the right and piece together something that might be useful for you".

There are some "warning" signs in the slide, which he briefly touched on. For example, macro definitions are only available in DWARF if extra flags (-gdwarf -g3) are passed to GCC and BTF only has information on functions and per-CPU variables, not all variables. The latter is something he plans to work on changing.

Case studies

He then moved on to describe "a few case studies, historically, of how compact formats are useful in different Linux applications and tools" with an eye toward future ideas for using those formats. He started with the venerable ps utility, which at one time worked by reading /dev/kmem (literally, kernel memory as a file), as he learned from an LWN article about the removal of that interface. It would root around in the task structures in memory to pull out the things that it wanted to report, "which is, honestly, pretty smart, pretty cool, [and] a little bit dangerous". It required that ps have setuid-root privileges and it might need to be rebuilt any time the kernel's data structures changed. Now ps just reads information out of the /proc filesystem, which is far superior.

While it makes sense to have a dedicated interface for ps, there is other information locked inside the kernel where adding a user-space interface is not really called for, he said, which is where something like BTF or CTF could be used. The kernel's BPF developers had a problem similar to that of the older ps, in that BPF code needed to be rebuilt for the target kernel because the details of a data structure may have changed, but they solved it another way. In order to support compile once, run everywhere (CO-RE) for BPF, BTF was used to provide structure offsets to adjust the BPF for the target kernel, which eliminates the need for a compiler on the target and BPF binaries can be run on multiple kernel versions.

Another interesting user of compact debuginfo is the drgn programmable debugger, which has a focus on the kernel. It normally uses DWARF, but work has been done to enable "DWARFless debugging" with drgn. For example, kallsyms support was added in December 2024 and stack unwinding using ORC from x86-64 kernel core images (/proc/vmcore) was added in April 2025. Using CTF (which is available in Oracle kernels) is under review and Brennan is working on BTF support; he is hopeful that CTF and BTF can converge since they are already quite similar.

VMCOREINFO is a 4KB ELF section that contains only the limited amount of information about the kernel needed to construct a smaller dump file. It was not one of the entries on his list, but he thinks that VMCOREINFO is a good example of how to think about compact formats. The makedumpfile utility is used to make the small dump file from a kernel memory image in /proc/vmcore by filtering out unneeded data. It needs some basic symbol and type information, which can come from DWARF, "but that's a pain to use", especially in a kdump environment, "where there's limited memory, limited ... everything, honestly". VMCOREINFO is a tiny fraction of the size of the DWARF information.

Ideas for the future

Allowing makedumpfile to access kallsyms and BTF would provide ways to exclude more memory, such as GPU buffers, from a dump file. It would also mean that things like user-space stack memory could be added to the dump so that process stack traces could be examined. Brennan was working on adding that support when Tao Liu pointed to his patches that do much the same thing; Brennan said that they plan to work together on the feature. Another version was posted in mid-January 2026.

His final slide consisted of some "things that I was spitballing when I came up with these slides"; the intent was to try to get others thinking about better debugging tooling. For example, he noted that GDB and drgn can both produce nicely formatted output of structures in memory in a way that is useful to a developer, rather than just a hex dump. Perhaps it makes sense to add a new printk() format specifier that would use the BTF information, which could be helpful while developing and debugging. That could be extended to user space, as well, so that output from applications would use type information to pretty-print structures.

Another area that could be addressed is converting enum values to strings; it could be done via some kind of option to the compiler, which is, of course, open source, so he should simply write some code to do it, Brennan said. He also suggested combining kallsyms and BTF in the kernel as they currently carry a lot of the same information, but have separate string tables, so combining them would save space. In general, there is a lot of overlap between the two, so "we could probably combine them in interesting ways to further compact the formats".

The "perf mem" and "perf c2c" commands are used to look at memory accesses and cache sharing on a system, but their output is address-based. Instead it could use type information to say: "This is a slab address and it has this type object and I can tell you that that's the offset of this field in the kernel." That would help in finding problems like false sharing, for example.

He concluded by noting that "DWARF is really excellent, if you have it, definitely use it for debugging", but if not, there are options that can provide various pieces of that information. The compact formats can be used for more than debugging and can provide introspection features that bring those capabilities from higher-level languages to C. He believes there is a lot of room to rethink the tools that are being used in light of the availability of these other sources of information, which can lead to a more user-friendly experience.

The YouTube video of the talk is available for those interested.

[ I would like to thank our travel sponsor, the Linux Foundation, for assistance with my travel to Tokyo for Linux Plumbers Conference. ]

Comments (11 posted)

Poisoning scraperbots with iocaine

By Daroc Alden
February 12, 2026

Web sites are being increasingly beset by AI scraperbots — a problem that we have written about before, and which has slowly ramped up to an occasional de-facto DDoS attack. This has not gone uncontested, however: web site operators from around the world have been working on inventive countermeasures. These solutions target the problem posed by scraperbots in different ways; iocaine, a MIT-licensed nonsense generator, is designed to make scraped text less useful by poisoning it with fake data. The hope is to make running scraperbots not economically viable, and thereby address the problem at its root instead of playing an eternal game of Whac-A-Mole.

The problem with scraperbots

There are plenty of good reasons to scrape the web: creating indexes for search engines, backing up old web pages before they go offline, and even scientific research. Scraping can be disruptive, however. It requires resources from the server operator, often more than normal browsing, and is sometimes in support of an effort that the server operator doesn't agree with. The difference between a well-behaved scraperbot and a problematic one is often simply whether it is respectful of the resources of the server.

The Common Crawl project, for example, seeks to crawl the web once, and then make that data available to share between multiple users. That way, server operators only spend the resources to serve their pages for scraping once, instead of once per scraper. Other well-behaved bots respect signals like robots.txt files, site maps, ETags, and Retry-After headers that politely request that robots follow certain rules. For example, LWN's robots.txt asks bots to not scrape the mailing-list archives, because the archives have grown quite large, and serving content from them is more expensive than a typical request to the server.

With the invention of large language models (LLMs), text on the web suddenly has an economic value that it didn't previously, which leads to the temptation to ignore those polite requests. That, in turn, drives server operators to attempt to differentiate scraperbots from humans in order to enforce their chosen limits. Thus begins a game of cat and mouse, between server operators coming up with new detection techniques and scraperbots trying to blend in. There is never a winner, but the losers are independent web sites that can't keep up with the race and their visitors. As with the email spam problem, centralization and scale both make it easier to detect and respond to trends in new attacks, which makes avoiding the scraperbots easier for larger sites.

What to do about it

There are a few possible types of response. For one, server operators could try to make serving all of their pages less expensive. LWN has done some of that in the form of cleaning up unnecessary database queries in our site code. So, that's one potentially good thing to come from the increase in scraperbots: users might see slightly faster page loads when the site isn't being effectively snowed under by bots.

Another possible solution is to differentiate bots from humans with some kind of costly signal that's hard to fake. This is how the increasingly prevalent Anubis tries to protect server resources: it requires first-time visitors to solve a proof-of-work problem in order to access the site. Other approaches in this vein include checking that a user agent implements the meta http-equiv attribute correctly, or checking that it can store and provide cookies.

The problems with those approaches are twofold: failing to deter bots (which can run JavaScript just like everyone else), and putting an additional barrier in the path of users. Modern scraperbots use browsers — sometimes headless browsers, but sometimes actually rendering to a virtual screen — and route their connections through more-or-less legitimately acquired domestic IP addresses, just like humans. In this particular arena, the advantage seems to lie on the side of bots trying to mimic human traffic.

Iocaine

Unlike measures that seek to detect and block bots, iocaine is a last-ditch defense for after they have already made it to the web site. The request looks like a human, and the server is going to have to spend some resources responding to it. There's still one attribute that separates bots from human readers, however: reading comprehension. A human presented with a page of obvious nonsense might click one or two links in confusion, but they're extremely unlikely to try to download an endless torrent of nonsense instead of wandering off to do something better with their time. A bot, on the other hand, that is merely scanning for links and archiving text for later processing, will happily continue to download nonsense until it hits some kind of limit.

Iocaine is a Rust program dedicated to generating convincing-enough nonsense with a minimum expenditure of server resources. When it receives a request, it uses a hidden Markov model to quickly generate a random stream of words, with the occasional embedded link to another iocaine-generated page. That generation process can happen entirely on the CPU, without having to dispatch a request to the disk or database, satisfying the request quickly and removing it from the server's queue.

The program can be hooked into an existing web server in a variety of ways. In its default configuration, it is set up to be easily inserted into an existing reverse proxy's configuration ahead of the actual web site. It uses a set of heuristics to identify bot traffic: the presence of known-bad user agents, a request for an iocaine-generated nonsense URL, traffic that claims to be a mainstream browser but that doesn't set a Sec-Fetch-Site header, and requests coming from a range of autonomous system numbers known to belong to datacenters. Any traffic that doesn't match those heuristics is responded to with HTTP status code 421 Misdirected Request. That causes most reverse proxies to fall through to the next possible handler, which will typically be the actual web site.

That default configuration, while simple, arguably reduces iocaine's core value, since it makes the server dependent on the same bot-identification tricks that other solutions have attempted to wrestle with. To allow for more subtle configuration, iocaine embeds the Lua and Roto scripting languages. These can be used to implement custom handler logic, allowing users to extend iocaine to respond to requests on a particular path, with a particular cookie, or whatever other collection of traits makes sense for their use case. The Lua interpreter can also handle other languages that compile to Lua, such as Fennel. Roto scripts compile to machine code for minimum overhead when processing a request.

Some features of iocaine, for which a user may not want to reach for a full-fledged scripting language, can also be configured using KDL. Those configuration files can be used to specify multiple different scripted handlers to consult, set up log files and sources of data, choose how iocaine should bind to a port or socket, and so on.

On startup, iocaine reads in a word list and a corpus of text in order to set up its Markov model; by default, it uses its own source code for both, which produces nonsense that looks like this:

R, keys: &'a [Bigram], state: Bigram, } impl<'a, R: Rng> Iterator for Words<'a, R> { type Error = anyhow::Error; fn try_from(config: Config) -> Self { Self::Report(r) } } impl UserData for LuaQRJourney { fn new() -> Self { Self(k) } } impl WurstsalatGeneratorPro { #[must_use] pub fn library() -> impl Registerable { library! { impl Val<LabeledIntCounterVec> { fn.

For users who want more human-looking nonsense, using some ebooks from Project Gutenberg (and a word list from the GNU miscfiles package) produces a nicely different flavor:

Cabbage. Winston knelt down beside her. He tore open a window somewhere. 'There is a possible enemy. Yes, even science." Science? The Savage violently started and, uncovering his face, 'that in another hiding-place known to Julia, the belfry of a half-gramme holiday. Bernard was car- rying his baby sister — or perhaps not exactly be called upon to.

It is well known that, like adding sugar to unset concrete, adding a small amount of generated data to the training of LLMs can have large negative impacts on their performance. If iocaine-generated text can sneak into that training corpus, it will make it harder to train LLMs; therefore, the developers of LLMs will be less likely to pay for a dataset that could have iocaine-generated text in it. So, if enough web sites start using iocaine or similar approaches, it will no longer be profitable to scrape web sites and use that text for model training — putting an end to scraperbots once and for all.

That assumes, of course, that the purveyors of AI models don't have a way to detect and remove iocaine-generated text. The project's Markov model is not particularly sophisticated, and it seems entirely possible that AI labs will want to work on ways to detect it. On the other hand, that puts the game of cat-and-mouse firmly in the scraperbots' court, to badly mix a metaphor: now, the problem of distinguishing humans and bots is a problem for them, instead of a problem for server operators. Whether this more speculative aspect of using iocaine turns out to be worth it will be hard to tell without more study.

In either case, the overhead of running the software is high enough to be noticeable, but probably still an improvement over serving an expensive web page, and not likely to be a problem for modern servers. In my tests, iocaine used 101 megabytes of virtual address space, of which only 55 remained resident in memory after startup. The generated pages are also fairly short and to-the-point, often only a couple of paragraphs and a handful of kilobytes.

It probably doesn't make as much sense to put iocaine in front of a web site that consists entirely of static files — web servers are good at serving those efficiently already — unless one is particularly committed to the idea of combating scrapers economically. For users who have dynamic web sites, however, where every request can involve trips to the database, queries to backend services, or other expensive operations, iocaine is, like the iocaine in The Princess Bride, "not to be trifled with". Trading a bit of CPU time to fill a scraper's queue with junk might just save us all some time and expense in the long run.

P.S.: Here's what iocaine had to say about itself when given this article as input.

Comments (96 posted)

The reverting of revocable

By Jonathan Corbet
February 12, 2026
Transient devices pose a special challenge for an operating-system kernel. They can disappear at any time, leaving behind kernel data structures that no longer refer to an existing device, but which may still be in use by unknown kernel code. Managing the resulting lifecycle issues has frustrated kernel developers for years. In September 2025, the revocable resource-management patch series from Tzung-Bi Shih appeared to offer a partial solution to this problem. Since then, though, other problems have arisen, and the planned merging of this series into the 7.0 release has been called off.

The core idea behind this series is the careful management of references to data structures associated with transient devices. Kernel code needing access to one of those structures would attempt to obtain a short-lived reference; the attempt will succeed if the device is still present and functioning normally. That reference is protected by sleepable read-copy-update (SRCU), ensuring that the data structure in question will not disappear until after the next SRCU grace period.

If a device disappears from the system, the relevant driver will mark it as "gone" and deny any subsequent requests for references to its data structures. After an SRCU grace period has passed, the owner of the data structure, secure in the knowledge that no references to it can still exist, can safely free that structure. The uncertainty around the data's lifecycle has been replaced with a clear indication of when it is no longer in use.

Greg Kroah-Hartman welcomed this series when it was posted; he took it into the driver-core repository with the intent of pushing it upstream during the 7.0 merge window. On January 24, though, Johan Hovold requested a revert, complaining that the series should never have been applied. Normally this sort of infrastructure is not accepted without code that actually uses it, but that practice was not followed in this case; there was no in-tree user of the revocable-access functionality. Hovold criticized that move, saying that the proposed use cases for this feature do not actually need it, and that the code itself had some serious race-condition bugs. The revocable code, he said, should be taken back out "until a redesign has been proposed and evaluated properly".

For his part, Kroah-Hartman resisted the idea of reverting this change:

Ah, but I do think this is the way forward, given that the pattern/idea works in the rust side of the kernel, and it's exactly what I've been asking for for years now :)

But yes, without a real user, it's hard for me to justify it. But, I want it present in the tree now so that lots of others can play with it easily. If it turns out it is not correct, and does not work properly, then great, we will delete the files entirely. But I'm not so sure that we are there yet.

He was referring to the Revocable trait used by Rust code in the kernel. It provides an abstraction to provide access (at no run-time cost) to a data structure that is guaranteed by its owner to not abruptly disappear. For cases where that guarantee cannot be made, there is a try_access() function that works in a manner similar to the proposed C functionality. For the curious, Danilo Krummrich described the Rust implementation in some detail. He pointed out that a C implementation cannot work in the same way "due to language limitations", but thought that the revocable series was a worthwhile exercise in figuring out how best to adapt the Rust pattern to the C side.

Jason Gunthorpe, though, described that mechanism — and any interface that allows access to a device after it has been unregistered — as "*dangerous*", and said that use of the try_access() functions should be treated as "a code smell that says something is questionable in the driver or subsystem". The real value in the Rust abstraction, he said, is how it forces documentation of which contexts can safely access a device structure, and which are uncertain. The C version, instead, forces all accesses to be treated as uncertain, losing the documentation value, hurting performance, and possibly encouraging other types of bugs.

Hovold described Revocable as "a design pattern that's perhaps needed for rust, but not necessarily elsewhere". Gunthorpe said more strongly that adding something like the Rust abstraction is "not something we want to do". Instead, he said, changes should be made so that driver operations (often called "fops" since they are gathered together in the file_operations structure) should simply be run in a safe context where resources cannot disappear from underneath them. Laurent Pinchart agreed, and outlined a possible solution around safer file_operations invocations.

Meanwhile, Shih, who was unsurprisingly against reverting the series, said that keeping it in linux-next, at least, would be helpful. He posted a separate series fixing the race conditions reported by Hovold. Kroah-Hartman quickly picked up the fixes, leading to another complaint from Hovold, who asked again for the series to be reverted. In response, Kroah-Hartman defended his acceptance of the fixes, but agreed to disable the revocable feature from the build for the 7.0 release cycle. That did not stop the disagreement, though; Hovold responded that "API design should not be done incrementally in-tree".

It took a few more days but, on February 6, Kroah-Hartman threw in the towel and applied Hovold's revert patches. "Kernel developers / maintainers are only 'allowed' one major argument / fight a year, and I really don't want to burn my 2026 usage so early in the year :)" He asked Shih to go through the feedback and prepare a new series to be reviewed and, with luck, merged for a future kernel release.

This, of course, is not the sort of outcome anybody is hoping for when they put together an improvement for the kernel (or any other free-software project). But it certainly happens at times. If all goes well from here, this setback will lead, in the long term, to a better and more maintainable solution that will, finally, address a problem that kernel developers have struggled with for years.

Comments (none posted)

The first half of the 7.0 merge window

By Daroc Alden
February 13, 2026

The merge window for Linux 7.0 has opened, and with it comes a number of interesting improvements and enhancements. At the time of writing, there have been 7,695 non-merge commits accepted. The 7.0 release is not special, according to the kernel's versioning scheme — just the release that comes after 6.19. Humans love symbolism and round numbers, though, so it may feel like something of a milestone.

The most important changes included in this release were:

Architecture-specific

  • The kernel now supports atomic 64-byte loads and stores on Arm CPUs that provide the feature.

Core kernel

  • Rust support is officially no longer experimental. Rust is here to stay, although individual subsystem maintainers are still free to keep it out of their subsystems.
  • BPF can be used to filter io_uring operations; see this article for details. The change adds a way to potentially enforce sandboxing on io_uring operations, given that seccomp() can't block individual io_uring operations — and that therefore administrators with seccomp()-based sandboxes typically disable io_uring altogether.
  • Users have the option of using non-circular io_uring queues for better cache performance in applications where requests are usually completed before the submission system call returns. In a circular queue, the slots where new messages are stored continue advancing in memory until they wrap around. This causes churn in the cache. A non-circular queue will reset the queue's pointers whenever it is empty, hopefully keeping the start of the queue's memory in cache.
  • Looking up types in BPF type format (BTF) debugging information now uses a binary search, which should make loading BPF programs more efficient.
  • As reported in January, BPF kfuncs can accept implicit arguments.
  • The scheduler has changed to only support two preemption modes on most architectures: PREEMPT_LAZY and PREEMPT_FULL. Only architectures that do not support preemption at all can still configure PREEMPT_NONE, and only architectures that don't support lazy preemption can configure PREEMPT_VOLUNTARY. See this article and its sequel for details on the different modes.
  • The time-slice extension proposal for restartable sequences has been merged. This change allows processes that are almost done with a lock at the end of their time slice to request a short grace period to finish their work and release it.
  • Administrators of systems that need to panic when workqueues stall can set a new build-time configuration option to force that behavior.
  • The deprecated linuxrc-based initial ramdisk (initrd) code has been removed. The other initrd code is scheduled to follow in 2027, which will leave initramfs (which uses a filesystem in RAM instead of a disk image in RAM) the only supported way to boot the kernel.

Filesystems and block I/O

  • Non-blocking updates to file modification times now actually work. Previously, they would return -EAGAIN unconditionally; now, that only happens when the filesystem would actually block. This makes non-blocking direct writes work on filesystems with fine-grained timestamps.
  • Filesystems no longer implement leases by default, and must instead opt-in. This resolves a number of problems caused by leases being available on filesystems that were never designed to handle them. Most popular filesystems do implement leases, but 9p and cephfs don't, for example.
  • Historically, filesystems have reported errors in mutually incompatible ways. A new set of helper functions makes it easier for filesystems to report errors to fsnotify in a consistent way.
  • A new filesystem — "nullfs" — has been added for use as the root filesystem of Linux systems. It's immutable and completely empty, containing no data whatsoever. This simplifies the boot process, because user space can mount other filesystems on top of it and then use the pivot_root() system call to make those the new root, rather than having to clean up the contents of initramfs and re-use the root filesystem.
  • In support of Checkpoint/Restore in Userspace (CRIU), the statmount() system call can now report information about the mount associated with a file descriptor.
  • The EROFS maintainers have enabled LZMA compression by default, and marked DEFLATE and Zstandard compression as no longer experimental. The filesystem also shares page-cache entries for identical files on separate EROFS filesystems.
  • Filesystems that need to calculate checksums or parity over data can use bounce buffers to store a copy of the data during direct I/O. See this article for details.
  • Btrfs now supports direct I/O when the block size exceeds the system's page size.
  • XFS's autonomous self-healing support has been merged; see this article for details.

Hardware support

  • GPIO and pin control: ROHM bd72720 GPIO devices.
  • Graphics: CSW MNE007QB3-1 panels, AUO B140HAN06.4 panels, AUO B140QAX01.H EDP panels, Sitronix ST7920 panels, Samsung LTL106HL02 panels, LG H546WF1-ED01 panels, HannStar HSD156J panels, BOE NV130WUM-T08 panels, Innolux G150XGE-L05 panels, Anbernic RG-DS panels, RK3368 HDMI controllers, RK3506 chips, Genio 510/700/1200-EVK HDMI outputs, and Radxa NIO-12L HDMI outputs.
  • Hardware monitoring: MT8196 and MT7987 Mediatek heat sensors, RZ/T2H and RZ/N2H Renesas heat sensors, HiTRON HAC300S power supplies, Monolithic MP5926 hot-swap controllers, STEF48H28 hot-swap controllers, Pro WS TRX50-SAGE WIFI A and ROG MAXIMUS X HERO chips, Dell OptiPlex 7080 computers, F81968 I/O chips, ASUS Pro WS WRX90E-SAGE SE chips, SHT85 sensors, P3T1035 temperature sensors, and P3T2030 temperature sensors.
  • Media: TI video input ports, os05b10, s5k3m5, and s5kjn1 camera sensors, and Synopsys CSI-2 receivers.
  • Miscellaneous: Renesas RZ/V2N SoCs and Rock Band 4 PS4 and PS5 guitars, ATCSPI200 SPI devices, AXIADO AX300 SPI devices, NXP XPI SPI devices, and Renesas RZ/N1 SPI devices.
  • Networking: Huawei hinic3 PF ethernet cards, Motorcomm YT6801 PCIe ethernet controllers, MaxLinear MxL862xx switches, RealTek RTL8127ATF 10G Fiber SFP NICs, RZ/G3L GBETH SoC NICs and QCC2072 WiFi chipsets.
  • Power: Maxim MAX776750 PMICs, Realtek RT8902 level shifters, Samsung S2MPG11 PMICs, and Texas Instruments TPS65185 PMICs.
  • Sound: NXP i.MX952 application processor, Realtek RT1320 and RT5575 audio codecs, and Sophogo CV1800B chips.

Miscellaneous

  • The vDSO now provides a 64-bit version of clock_getres().
  • With this version, the kernel supports SPI devices with multiple data lanes that transmit in parallel.

Security-related

Virtualization and containers

  • Container runtimes can use the new OPEN_TREE_NAMESPACE option to open a new mount namespace without cloning an existing mount namespace. This should make starting a new container faster on systems with many mounts.

Internal kernel changes

  • A reimplementation of RCU task traces has resulted in the deprecation of the rcu_read_lock_trace() and rcu_read_unlock_trace() functions.
  • The kernel has added an official policy on tool-generated content. To encourage the tools themselves to follow it, there is also documentation aimed at LLMs.
  • The kmalloc_*() family of functions (which allocate based on the required size) are poised to be replaced with kmalloc_obj_*() functions (which allocate based on the provided type) during this release cycle. The new functions will both make object-length-calculation errors less common and provide for possible type-based hardening of the kernel.
  • A number of Rust changes were made to use the recently-vendored syn crate to implement macros — changes which, ironically, actually reduced the amount of Rust code in the kernel by cleaning up the previous ad-hoc macro definitions.
  • Support for Sparse context analysis (which helps find locking bugs, although not well) was removed in favor of compiler-based context analysis in Clang 22. The compiler-based analysis should catch more locking bugs with fewer false positives; see this article for details.
  • The kernel's build configuration has new syntactic sugar: "depends on X if Y", standing in for "depends on X || !Y".
  • Sheaf caches are all cached per-CPU, a change that has been in the works for nearly a year. This change reduces the amount of cross-CPU contention caused by allocating new pages from the kernel's slab allocator.
  • s390 machines now have the same kinds of poison pointers (which have hex value 0xdead000000000000 on s390) as other architectures, which allow the kernel to track DMA mappings from the networking page pool, among other things.
  • The DRM subsystem has given up on integration with the kernel debugger (kgdb) for now. The move is motivated by the difficulty of supporting kgdb on modern hardware.
  • The new __counted_by_ptr() annotation marks members of a structure that specify the length of an object behind a pointer, like __counted_by() does for arrays in a structure.

The merge window is not quite half over, so as usual there will be a follow-up article once it closes, on February 22 if all goes as planned. For now, though, the 7.0 release is following the trend of recent Linux releases: packed with incremental improvements, and no huge changes. One thing that didn't make it into this release is support for revocable driver interfaces in C; that patch set may just be pushed off to 7.1, or may face stiffer resistance.

Comments (55 posted)

More accurate congestion notification for TCP

By Jonathan Corbet
February 18, 2026
The "More Accurate Explicit Congestion Notification" (AccECN) mechanism is defined by this RFC draft. The Linux kernel has been gaining support for AccECN with TCP over the last few releases; the 7.0 release will enable it by default for general use. AccECN is a subtle change to how TCP works, but it has the potential to improve how traffic flows over both public and private networks.

TCP, from the beginning, has included a couple of window counters used by each side of a connection to specify how much data it is willing to accept from the other at any given time. The windows work well to prevent the endpoints from being overwhelmed with packets, but early TCP did not consider the problem of congestion in the routers between the endpoints. That shortcoming made itself known in the form of severe congestion problems in the mid-to-late 1980s.

Around that time, Van Jacobson and Mike Karels took on the problem of preventing congestion collapse. Their key insight was that dropped packets were almost never a result of corruption of the packets themselves. Instead, they were a signal that some system between the endpoints was experiencing congestion; indeed, dropped packets were the only way that a router could signal congestion. Jacobson implemented the first congestion-control algorithms that would slowly ramp up the transmission rate until packet loss was experienced, indicating the point where the capacity of the channel had been exceeded. Jacobson's classic paper describes this work in detail.

Using packet-loss events in this way made the net work again, but it was never going to be the most efficient way to regulate transmission speeds. It takes time to realize that a packet has been dropped, and each dropped packet represents a waste of resources. It would be a far better if the TCP endpoints could be informed of congestion, and moderate their transmission speeds, before the congestion reaches the point of packet loss.

Explicit congestion notification

Around the end of the 1990s, work was started on what eventually became RFC 3168, describing explicit congestion notification (ECN), a means by which routers can inform the endpoints of a connection that they are experiencing congestion. It required changes at both the IP and TCP layers of the stack.

At the IP level, two bits were allocated from the IPv4 and IPv6 headers; they were named ECT and CE. The setting of either of those bits (but not both) in an IP packet is an indication that the endpoints understand the ECN protocol and are willing to implement it. When a router that is experiencing congestion receives a packet with exactly one of those bits set, it can choose to set the other bit to indicate "congestion experienced" in the hope that the endpoints will respond by slowing their transmission rates.

In a typical TCP connection, one side will be transmitting at a rather higher rate than the other. If the heavy transmitter is causing congestion, the ECN signal will arrive at the receiving end, where it is not entirely useful. So TCP had to be enhanced to relay that signal back to the transmitting side. Two bits were allocated in the TCP header as well with the names ECE (ECN echo) and CWR (congestion window reduced). If both of those bits are set in the initial SYN packet starting a connection, they are interpreted as a signal that the initiating side implements ECN. If the peer also supports ECN, it sends its SYN-ACK response with only the ECE bit set. When both of those things happen, the connection will use ECN.

When one side of a connection receives a packet with the two IP-level congestion-mark bits set, indicating congestion in the path, it will start setting the TCP ECE bit in every ACK packet it sends back to the other side. An endpoint, on receiving a packet with ECE set, is supposed to respond in the same way it would if a packet had been dropped; it will reduce its congestion window (and thus the transmission speed). It will also set the CWR bit in the TCP header in the next packet it sends to indicate that the ECE signal has been received. Once the CWR bit is observed at the other end, the recipient will stop setting ECE.

The Linux kernel gained support for ECN in the 2.4.0-test7 release in September 2000. The immediate result was an early lesson on the problem of protocol ossification. As was noted in LWN at the time, many of the routers on the Internet not only did not support ECN, but they also actively dropped SYN packets with the TCP ECN bits set, making communication impossible. So, while Linux had ECN support from an early date, it was many years before it could be safely enabled on most systems, and it still is not fully enabled even in current kernels.

More accurate ECN

ECN was an improvement over what came before, but there is room to do even better. The design of the ECN protocol means that it can only communicate a single "congestion experienced" event during each round-trip time for the connection; that is how long it will take between the transmission of the first ACK with ECE set and the reception of a packet with CWR set. That will slow the response to heavy congestion, with the likely result that packets will still be dropped. AccECN was designed to provide faster and more detailed feedback on congestion to the TCP endpoints.

AccECN makes minimal changes to ECN at the IP level; the two bits are used as before. At the TCP level, it grabs another header bit that had, back in 2003, been assigned by RFC 3540 for a "robust ECN" mechanism that was never deployed. That bit, renamed AE, is used in a couple of ways with the new protocol. At connection time, an AccECN-capable site should set the AE bit along with ECE and CWR; if the other side also supports AccECN, it will respond with ECE and AE set. If the receiving side does not understand AccECN and ignores the AE bit, it will see what looks like a "classic ECN" configuration and respond accordingly. (Note that the connection protocol, like everything else, is somewhat more complex than described here; see the RFC draft for the gory details).

When AccECN is in use, each side maintains a set of counters, one of which is the number of packets received with the congestion-experienced marker. After the connection is established, the AE, CWR, and ECE bits are combined into a single three-bit field, inevitably called ACE. The contents of that field will be the three least-significant bits of the packet counter, giving the other side a continually updated view of how many congestion-marked packets have been seen. When the ACE count changes, a transmitting side can get a sense for just how many packets have been stamped with the congestion mark in transit and respond accordingly.

Three bits do not allow for a large count, needless to say. The RFC draft provides a set of complicated rules for determining whether the count may have wrapped and guessing how many times that may have happened. ACKs are sent relatively frequently — perhaps one for every two data packets in an ongoing stream — leaving little opportunity for multiple wraps of the ACE counter most of the time. In any case, eight counter values that can change with every ACK (rather than one bit that can only change once per round-trip time) provide much higher-resolution information on the presence of congestion on the path between the two endpoints.

AccECN, as described so far, was clearly designed to avoid as many protocol-ossification problems as possible. Even so, it includes a number of provisions for the detection of middlebox interference with the ACE bits and the count as a whole. The nature of the modern Internet is such that protocol changes must be done with a lot of care, even when the changes are within the specification of the protocols themselves.

There is more to AccECN, though, if the connection will support it. Each side of the connection is required to maintain three other counters for incoming data. There are two counters to track the number of bytes received with either (but not both) of the IP-level ECN bits set, and a counter for the number of bytes received with both bits set (indicating congestion). There is a pair of TCP options that can be used to communicate these counters (more precisely, the bottom 24 bits of each counter) to the other side. These counters give a far more accurate indication of how much congestion is actually occurring, and they can be profitably be put to use by a number of advanced congestion-control algorithms.

The problem with TCP options, of course, is again middleboxes, which often will not pass packets that contain unrecognized options. The connection-establishment dance thus includes a couple of attempts to send packets with the AccECN options to see whether they make it unmolested to the other end; the options will not be used unless these tests pass. The chances of successfully using the new options over the Internet may be relatively small, but AccECN is also intended for use within data centers, where any middleboxes are under the owners' control and can be coerced into letting the options through.

AccECN in Linux

Support for AccECN in the Linux kernel first started arriving in the 6.15 development cycle, with additional pieces following in subsequent releases. In 7.0, a number of final cases have been fixed, and the use of AccECN is enabled by default — for some connections. Specifically, as described in Documentation/networking/ip-sysctl.rst, the use of AccECN (and ECN in general) is controlled by the net/ipv4/tcp_ecn sysctl knob. In previous kernels, the value of tcp_ecn is, by default, two, meaning to use classic ECN when requested for incoming connections, but to not attempt to use it with outgoing connections. AccECN is disabled entirely in that configuration. The new default value is five, which enables AccECN for incoming connections, but still leaves all forms of ECN disabled for outgoing connections. In other words, the fear of protocol ossification remains, so Linux systems will, by default, not attempt to use either type of ECN for connections they initiate.

Some highly scientific "screw around on the net for a while" tests conducted here suggest that, 25 years or so after its inception, classic ECN is safe to enable for outgoing connections. It may take some time to determine whether the same is true for AccECN. It will also be a while before AccECN-enabled servers are widespread on the Internet, though they may be deployed within data centers rather more quickly. Decades may be required, but there should eventually come a point where more accurate explicit congestion notification is making the net work more smoothly on a wide scale.

Comments (9 posted)

Open source security in spite of AI

By Joe Brockmeier
February 16, 2026
FOSDEM

The curl project has found AI-powered tools to be a mixed bag when it comes to security reports. At FOSDEM 2026, curl creator and lead developer Daniel Stenberg used his keynote session to discuss his experience receiving a slew of low-quality reports and, at the same time, realizing that large language model (LLM) tools can sometimes find flaws that other tools have missed.

FOSDEM is famously jam-packed with things to do and talks to attend; there are dozens of devrooms for different topics, as well as the main-stage keynotes and sessions. Stenberg's keynote was at 17:00 on Sunday, one of the last events on FOSDEM's schedule; no doubt the organizers selected his talk as the most likely to lure a large audience into the main room for the closing session that would follow it. The ploy worked; the room was effectively standing-room only. He opened his session by saying "it's this, and then we can all go home. You look a little tired; it feels like I've talked to almost all of you already".

Stenberg said that many of the audience had already followed his struggles with AI; he has been active in blogging about and commenting on AI via social media for some time. He acknowledged that it would upset some of the audience that he was saying "AI" rather than being specific with terms like "LLM" or "machine learning" but, "in my talk, I don't care. I'm using the marketing language. It's all 'AI'. When people throw something at me, they say they used AI to do it."

The struggle is real

Instead of naming the specific technologies, he wanted to discuss the effects of AI. Stenberg said that AI freeloads on open source, and scrapes the web to death. It overloads maintainers and takes all the money to boot: "No one can do anything that is not AI because no one will pay you anything at all. And, you know, try to buy a computer with memory now." AI boosters will tell everyone that it is good technology and that it will get better. Maybe it will, "but I'm old and allowed to complain".

[Daniel Stenberg]

Since the first release, curl has grown from 100 lines to about 180,000 lines; more than 3,500 people are mentioned in its THANKS file for their contributions. Curl is used in "a few things", he deadpanned, and displayed a collage slide with some of the many devices, vehicles, toys, phones, tablets, gaming consoles, online services, and operating systems that curl is used in. It is basically everywhere, he estimated it is used in up to 30 billion instances. With that being the case, "we take security seriously". It could have a bad impact if curl had a "terrible security thing somewhere".

When everything runs your code, Stenberg said, "you're a little bit sensitive to the security problem". Security reports generally take the top priority. At the same time, open-source maintainers are usually overworked and underfunded. The median number of maintainers for most projects is one, "many are a spare-time or hobby thing we do on the side or partially paid; 'underfunded' is sort of the middle name of every open-source project". There are always things to do, and many maintainers struggle with burnout.

Before AI, there was friction in creating a security report. People invested a lot of time and effort in finding something to report, and maintainers would then spend time assessing the report on their end. And then, along comes AI. It is super-easy to ask an LLM to find a problem; and since there's really no cost to try AI tools, it's basically effortless for people to ask the tools to find a security problem in an open-source project. "Ask it to make it sound really horrible, and it will do that. And then you just send that report away." Many people genuinely think that if they ask ChatGPT to find a security problem, it will find one, and they better report it.

Stenberg said that people ask him how he knows when a submission is AI. First, it's too polite. "No human ever started [a report] with 'I apologize, but I found a problem.' No way." People who have been working in open source for a long time know that reports come from people who are a bit upset and angry. Another tell is that AI reports are "all perfect English", and often use title case in their submission title rather than sentence case as humans generally tend to do. (Stenberg has curated a list of examples where this is indeed apparent.)

Of course "every paragraph needs three bullet points in a list" and the reports are simply too long. Back in the day, it was necessary to try to get reporters to include more information. And, when asking the reporter a question, what happens? "Absolutely right, I'm sorry. My mistake. I misunderstood. And blah blah blah." What has happened is that maintainers end up communicating with a proxy for a bot: "That never ends well."

HTTP/3 "exploit"

To illustrate his point, he talked about one of his favorite examples of a slop report. This report came through HackerOne in May 2025; the reporter claimed to have discovered a "novel exploit leveraging stream dependency cycles in the HTTP/3 protocol stack" in curl 8.13.0. It looked legitimate, Stenberg said, and included a proof of concept, environment setup, GDB output, and more.

The report looked credible, but it was not. The function mentioned in the report did not exist in curl and even the GDB session had been faked. "I think I was a little bit inexperienced back then, so I actually wasted far too much time" on the report.

This was still early in the AI-slop-reporting era. Now, Stenberg said, he calls this method of sending AI-generated security reports "terror reporting". In the past, he estimated that one out of six reports turned out to be real security flaws. Now it is more like one out of 20 or 30. It is a total waste of the curl team's time and energy. The curl project is not alone in being besieged by AI slop reports, of course. Stenberg said that once he started talking loudly about the AI slop, he heard from many other projects that had the same problem.

He theorized that, in curl's case, people were doing it for the money. Historically curl had offered a bug bounty that would award $500 for low-severity flaws and up to $10,000 for finding a vulnerability of critical severity. "That's sort of the pipe dream; that's why every report is labeled critical."

The problem is humans

Stenberg listed some of the things that he had tried to ensure that security reports were researched by a human. He added a submission form that required the reporter to declare if they had used AI. That worked for three or four reports, and then people stopped admitting to it. He tried banning reporters who used AI. That does not work well if the user can simply create a new account the next day. He tried public shaming, which worked to some degree, but not enough to end the reports. Ultimately, curl ended its bug-bounty program in January 2026 because the volume of slop was too great.

The problem is not really AI, though, it's humans. "AI makes it easy to submit reports and if marketing says this works, they're going to continue to do this as long as it's very easy and low effort". He hoped that ending the bounty would reduce the number of slop reports, but "we'll see if this actually turns out to be true". On February 4 he posted to Mastodon that the early data indicated "turning off the bug-bounty may not make much difference".

Despite the bad experiences Stenberg is still open to the use of AI, because it is simply a tool. If a person asks it to find a security problem that they don't verify, "you get really stupid things". But if a person is clever and uses a good tool, "you can do really good stuff. So we work with several AI-powered analyzing tools now."

The good

Even though AI is bad in one way, it is awesome in another way, Stenberg said. In working with C over the years he had thrown everything at the code to find bugs; picky compiler options, code analyzers, fuzzing, and even security audits. And, of course, users report bugs when they find them. But, using AI tooling, he has found more than 100 bugs that had been missed by other methods. Even though the tools find flaws "in what sometimes feels like magical ways" there is a need for a clever human in the loop to decide if the discoveries are real, valid, and important.

He said that AI tools found things that humans did not. For example, the tools might detect that a code change and the comment related to the code disagree. "That might sound like a subtle thing, but it's an awesome thing. [...] If that documentation is wrong, the users of that function in your code is possibly wrong." It is perfect for detecting edge cases or spotting when code and a specification disagree. A human can find that, but humans get bored. People are really bad at code review, but the machines don't get bored and they don't get tired.

And also it's really good at, for example, analyzing other libraries. So you do function calls from your code into a third-party library and it can tell me about assumptions I make on the data it returns, which also is nothing a normal code analyzer can do, because a normal code analyzer only analyzes your code, not the other code or the interactions between them. So really fascinating tools. It really opens up a new way to improve code and make things stable and better.

What doesn't interest Stenberg is using AI to write code. He said that he is not impressed with AI for writing code; even when the machines find a bug and propose a patch to fix it, the patches are never good. "A human fixes code way better than the AIs do."

He added that he could not discuss AI without mentioning scraperbot overload. The curl project has a content-delivery network (CDN) sponsor, so the 75TB a month of traffic that is largely bot-generated does not harm curl as a project. But other projects are not so lucky. "Certainly this causes a lot of problems for a lot of projects."

In the end, "it all depends on what you do with it", Stenberg said. A fair share of users have always been annoying, but now they have tools that help them produce junk in new ways. "AI will continue to augment everything we do in different directions [...] at least until we start paying for what it actually costs. And then we'll see what happens."

Questions

The audience may have been tired from a long FOSDEM weekend, but not too tired for questions. The first audience member wanted to know if there were legal concerns with accepting AI-generated code. Stenberg said that there's always been an uncertainty with contributed code. It may have been written by the contributor, generated by AI, copied from Stack Overflow or some other source. "I think the risk is roughly the same."

Another attendee said that their project had never had a bug bounty, but had experienced a 600% increase in "these wonderful security reports". They wanted advice on how to handle the situation, since they had no bug bounty to turn off. Stenberg said that there were many ways, but unfortunately every way to limit reports meant making it harder to submit reports overall, which is unfortunate.

While Stenberg's session largely dealt with the negative impacts of AI tools on curl as a project, and for open-source maintainers more generally, his outlook was not pessimistic. It will be interesting to see how the end of the bug bounty plays out for curl, and whether the situation improves as maintainers speak out about the problems they're facing. The video of the session is available on the talk's page on the FOSDEM 2026 web site.

[Thanks to the Linux Foundation, LWN's travel sponsor, for funding my travel to Brussels to attend FOSDEM.]

Comments (3 posted)

Open-source mapping for disaster response

February 13, 2026

This article was contributed by Joab Jackson

FOSDEM

At FOSDEM 2026 Petya Kangalova, a senior tech partnership and engagement manager for the Humanitarian OpenStreetMap Team (HOT) spoke about how the project helps people map their surroundings to assist in disaster response and humanitarian aid. The project has developed a stack of technology to help volunteers collectively map an area and add in local knowledge metadata. "One of the core things that we believe is that when we speak about disaster response or people having access to data is that they really need accessible technology that's free and open for anyone to use."

I was not able to attend FOSDEM 2026 in person, but watched the session via FOSDEM's live stream. The video and slides from the session are available on the FOSDEM 2026 talk page.

HOT is a separate entity from OpenStreetMap (OSM), the grassroots endeavor to map and annotate the globe. But HOT, a non-profit non-governmental organization (NGO), cut a deal to use the OSM name and maps, as well contribute its work back to OSM's maps. LWN first covered HOT in 2014. The project focuses on "blank spots", which are areas of the world that lack maps, and especially those areas suffering (or might easily suffer from) a disaster such as a hurricane or volcano activity. Disasters around the world can kill hundreds of thousands of people and leave millions displaced each year. People, especially in dire circumstances, "need technology that is open and free", Kangalova said.

HOT recruits volunteers to collect imagery with drones, and provides tools to annotate important details of maps it creates, such as buildings and roads. The results are submitted to OSM and shared with local disaster-relief agencies. Thus far, the project has mapped more than 175 million buildings and 3.8 million roads, thanks to more than 540,000 mappers.

Essential to this mission is a full end-to-end mapping workflow built on a set of open-source tools. This software is collaborative in nature. It is designed to be used by many people simultaneously to form composite, annotated maps. It is also designed to be easy to use for people with no experience in geographic information systems (GIS).

Haitian earthquake

HOT was born 15 years ago, in response to a 7.0 magnitude earthquake in Haiti that left more than 300,000 dead and more than a million displaced. "When the earthquake happened, there were no maps available" for respondents to work from, Kangalova said. At the time, Google had mapped the main roads, but the government held the only local maps detailed enough to be useful to relief workers. Those maps, however, were housed in buildings damaged by the quake. Within 48 hours, the OSM community had cobbled together a set of satellite imagery for the area.

OSM has a pretty comprehensive coverage of the US, Europe, and Australia. Kangalova noted that HOT, now with about 70 full-time employees throughout the world, set up hubs for the under-mapped regions of Latin America, the Caribbean, Africa, and Asia. Projects have been done and documented for Argentina, Bangkok, Bali, Nepal, and Sierra Leone, as well as many other spots. Anyone can view and edit the maps. The intended users are "local governments making decisions about the specific infrastructure. Sometimes it's around specific routes and sometimes it's about reaching people post-earthquake and other disasters", Kangalova said.

The goal is to support local efforts to generate data of their own communities so that when an emergency happens that data will be on hand, Kangalova said. Local governments and humanitarian aides can then use the maps and related data they need during times of duress. The project helped the Balinese Disaster Management Agency in Indonesia to map evacuation routes for those near Mount Agung, an active volcano.

After 50 years of near silence, Mount Agung started awakening throughout late 2017 into early 2018, resulting in several full-blown magmatic eruptions, as well as considerable shocks with earthquakes of magnitude 4.0 and higher. According to the Indonesian Ministry of Energy and Mineral Resources, more than 10,000 residents had to be evacuated from the area around the mountain. They were from the hamlets scattered through the mountainous highland regions that surround the mountain. The winding roads were not clearly documented, so an early warning system was clearly needed.

For the project, employees of the Balinese agency learned how to operate the drones and the accompanying software, according to HOT's summary video. The drones provided high-resolution aerial imagery, which were used to scout for locations for early warning systems. The imagery also allowed the agency to identify the exit routes, and publish a contingency plan for volcanic eruptions.

Mapping by the many

HOT's approach is collaborative and iterative. The first step is gathering imagery. No imagery, no map. A first pass can be provided by satellite, but more detailed imagery is also needed; it is procured by a coordinated set of drones, traveling around 100 meters or so above the land. The software stitches together the imagery and metadata. It then calls on residents to supply information about the landmarks. This last part is the most crucial: the local knowledge. "We can all see this is a building, but what is it?" Kangalova said.

HOT recommends using a number of relatively low-cost drones for the task of gathering data; currently the DJI Mini Pros versions 4 and 5, as well as the Potensic Atom drones are supported. An area needing to be mapped is separated into field-mappable chunks, with the results combined into a single entity. The HOT stack is a mix of tools it developed in-house along with open-source-mapping software added to fill in the gaps.

Kangalova discussed the whole stack, technology by technology. To create the flight plans, HOT created Drone Tasking Manager (DroneTM). Unlike other mapping technology, this software can split a flight plan into separate tasks run by different individuals. The project uses OpenDroneMap, a third-party open-source-mapping application, to process the imagery and make it GIS-ready. The results are fed into another third-party tool, OpenAerialMap, to store and display aerial imagery, making it available for searching via an API or by the web.

With this imagery, volunteers can independently annotate different sections, identifying roads, bridges, and the like. This work is coordinated by the HOT Tasking Manager. An AI-powered assistant, fAIr, may be used to help fill out information with local models trained on local data. Those on the ground can contribute what they learn through the Field Tasking Manager, a standalone mobile and web application. It is integrated with third-party open-source projects OpenDataKit and QField to build the forms and templates.

Commercial applications can also be used to collect data, Kangalova said. ChatMap creates maps and associated artifacts from messaging applications such as WhatsApp and Telegram. Data from a user's location can be uploaded, along with any associated notes and imagery. Creating maps from all this OSM imagery is the job of uMap, an open-source GIS tool developed by OpenStreetMap France, which integrates the maps with other data. A HOT export tool can be used to download OSM imagery for other applications.

All of HOT's projects and tools are on GitHub and the project welcomes contributions. "All the projects that I've mentioned, you see the repositories, their current current volunteer projects, and ways to get involved", Kangalova said.

HOT has created a wealth of open-source technologies to help communities map their surroundings in a collaborative way. Perhaps more importantly, it does the legwork of assembling this stack of open-source software to execute a specific mission, a formidable task for outsiders. And then during times of duress, it trains volunteers to quickly get results. In doing all this, HOT fulfills one of the most vital missions of open source, to help people everywhere through the power of software.

Comments (none posted)

Page editor: Joe Brockmeier

Inside this week's LWN.net Weekly Edition

  • Briefs: upki; Asahi Linux progress; DFSG processes; Fedora in Syria; Plasma 6.6.0; Vim 9.2; ...
  • Announcements: Newsletters, conferences, security updates, patches, and more.
Next page: Brief items>>

Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds