Linux 7.3: He Was Joking About the AI
[No navigation links for this narrative-series episode; separator retained per S23]
A few months ago I sat in a meeting with two architects and a service designer who were confident, genuinely confident, that AI would collapse into a bubble and that the hallucinations would drive everyone back to doing things the old way. Neither of them had used a large language model. Not once. A few months on, everyone around them uses one daily, and the two sceptics still have not touched one. Their claim was not wrong because they were foolish. It was wrong because it never had to survive contact with the thing it was about.
On 6 September 2026, Linus Torvalds released Linux 7.3-rc2 and called it unusually heavy for a point in the cycle that is normally the quietest, the week after the merge window closes, when maintainers catch their breath. He could not point to one clean cause, so he closed his announcement with a joke: everyone would probably blame it on AI, because whether that was really the cause or not, it was an easy thing to blame. Two of the three research streams that feed my own weekly research process read that line back as a finding. One of them did not even get the person right. It credited the joke to Greg Kroah-Hartman, the kernel's stable-tree maintainer, who had said something real about AI four days earlier and was not joking at all.
This is the kind of thing that happens to a sentence once nobody's name travels with it, and it is worth being precise about what actually happened, because the precise version is more interesting than "the AI got confused."
Torvalds' 7.3-rc2 announcement did what these announcements always do: a paragraph on what landed, a note on what still needs eyes, and, this time, an aside about the release feeling larger than usual for no cause he could name. Four or more independently run outlets, covering the release separately, characterised that aside the same way: a joke, not a diagnosis. That much is well corroborated across separately operated newsrooms. The exact wording is a different claim, and this session I could not reach either the kernel mailing list archive or the outlet that broke the story directly to confirm it word for word, so I am not quoting it verbatim here. What is not in doubt is the tone: an admission that he did not know the cause, followed by a shrug in the direction of the easiest available culprit.
My own research pipeline runs AI-assisted intelligence sweeps every week to keep this series current, and part of what those tools are for is catching exactly this kind of thing before it reaches a draft. This week, two of the three streams read Torvalds' announcement and repeated the joke back as an actual causal claim. One of those two also put the wrong name on it. Kroah-Hartman had, in fact, said something real about AI that week. Just not that.
On 2 September 2026, four days before Torvalds' joke, Phoronix reported that Kroah-Hartman had forewarned of a rough 7.3 cycle because of continuing AI and large-language-model submission volume. He was not joking. He gave a number: he was personally filtering the USB subsystem review queue, which stood at 1,732 of 4,807 messages when he first posted about it, and had come down to 1,094 of 4,170 once the straightforward fixes were cleared. On the workload, he told a colleague, "This is going to be a rough -rc cycle," and, more broadly, "It's going to be a long 18 months," adding that the number does not seem to get any shorter. He also said something that matters more than either figure: refusing a change that looks like an obvious bug fix is hard, even when he suspects it is not what it claims to be, and he does not want to be the one who blocks something that turns out to be genuine.
That is a serious, dated, directly quoted statement about a real problem, made four days before an unrelated joke about a different specific thing. Two real people said two real, adjacent things about AI in the same kernel cycle, and an automated reading process merged them into one. I cannot see inside either research product's own process well enough to say exactly how that merge happened. What I can say is that the shape fits: a name, a topic, and a week close enough together that a system built to summarise, not to verify identity, filled the gap with the wrong person.
There is a control case for this, and it sits in the same person's own words. On 9 and 16 August 2026, a month before the joke, Torvalds used a different phrase, "the new normal," to describe the AI-tool-assisted review volume behind that earlier cycle's own size. That was not a joke. Coverage of it at the time read no wink in it at all; it was a straightforward diagnosis, delivered a month before the same person made a throwaway remark about a different release. Both of my research streams had access to that August material through my own prior weekly passes, and neither one confused the two statements with each other. What slipped this week was not Torvalds' seriousness in general. It was the specific register of one sentence, in one announcement, in one particular week. The diagnosis and the joke are both real statements from the same person about a related but distinct phenomenon, and only one of them kept its tone once it had passed through a summariser.
The same release that supplies this irony also supplies its answer. Buried in the same 7.3-rc2 changelog, alongside the joke nobody checked, is a large, genuinely machine-assisted contribution nobody is arguing about: Kees Cook's tree-wide, tool-driven conversion of memory-allocation calls across hundreds of files to a safer form. Nobody treats that as suspect, even though a code-transformation tool did most of the mechanical work, because Kees Cook's name is on it. If it breaks something, he is who gets asked, and everyone in the tree knows that in advance.
That is the whole distinction the Cathedral and the Bazaar essay drew in 1998, applied to a case Eric Raymond never had to think about: a reading process with no equivalent of a Signed-off-by line. Code that enters the kernel carries a name and a certificate of origin. A characterisation of what a maintainer said, once it leaves his mailbox and passes through an automated summariser, carries neither. This episode is a smaller, funnier version of the argument I made about the Linux Foundation taking over a shared trust-attestation standard two weeks ago, and about a company reportedly trying to buy a registry outright last week. Both of those asked what happens to the bazaar's institutions as they mature. This one drops the same question all the way down to a single sentence: who is responsible for what a piece of text says, once a human name is no longer reliably attached to the reading of it.
Kroah-Hartman's queue numbers deserve a moment on their own, because they say something about where this pressure actually lands. Going from 1,732 unread messages in one subsystem's queue to 1,094 is real, measurable progress, and it still leaves more than a thousand messages one person is reading, one at a time, deciding which are genuine fixes and which are noise dressed as fixes. That is not a story about AI breaking open source. It is a story about a maintainer doing exactly the job the bazaar has always asked of maintainers, at a volume the bazaar did not have to handle in 1998 or even in 2020.
The practical question this raises is not really about kernel maintainers. It is about anyone whose job now includes reading something an AI tool summarised and repeating the summary in their own professional voice, in a meeting, in a report, in a LinkedIn post. The bazaar has a well-worn mechanism for checking whether code can be trusted, tracing authorship all the way through to who signed off on it. It has nothing equivalent for checking whether a characterisation can be trusted, and that gap will not close itself. Before repeating something a tool or a colleague has summarised for you, the same questions apply whether the source is a kernel mailing list or a market report: find the primary source, check whether the register was serious or offhand, confirm whose name is actually attached to it, and only then repeat it in your own words.
The kernel already tried to write a rule for half of this problem. Linux 7.0 introduced the Assisted-by tag, a formal requirement that a patch touched by an AI coding tool says so in its own history, alongside the human name that remains accountable for it. That policy governs how code is written. It says nothing about how a release announcement is read, and this week is the gap between those two showing itself: the writing side has a rule with a named author's signature attached, the reading side does not, and a joke walked straight through the hole.
I have spent thirty years in architecture and security consulting, across government, banking, transport, and aviation, and I have lost count of how many times a colleague's hedge in a meeting, or a joke in a hallway, has turned up two levels down the chain as a firm finding. What actually stops it, when something does, is rarely a policy document. It is one person going back to ask the original source what they meant, before repeating it any further.
The kernel has run its own version of this question since before automated summarisers existed. Every patch that reaches Torvalds' tree carries a Signed-off-by line, a Developer's Certificate of Origin under which a named person attests they wrote the change or have the right to submit it, and accepts responsibility if it turns out to be wrong. It is not a formality; it is what makes review possible at bazaar scale, thousands of contributors and one accountable name attached to every line of history. That is why Kees Cook's machine-assisted conversion draws no objection while an unattributed characterisation draws a correction. The bazaar solved code authorship long ago. It has never had to solve the authorship of a summary, and this week it found out why that gap matters.
The same distinction operates at defence scale. The United States Air Force's Platform One programme maintains Iron Bank, an accredited repository of hardened open-source container images that military systems draw on with a documented, attributable lineage: known provenance rather than a download and a hope. Ground software supporting United States Space Force operations runs on the same open foundations this series has traced back to a Helsinki student's Usenet post, and the same rule applies there as in the kernel tree: a component enters a defence system because a named process vouched for it, not because a summary sounded plausible. Attribution and verification are not the same act, and an acquisition process that confuses them inherits the kernel's own hardest lesson at a scale where the mistake is not a mailing list correction but a fielded system.
In your own professional world, has a colleague's hedge, joke, or offhand caveat in a meeting or an email ever been picked up by someone further down the chain and repeated as a firm finding, in a way that caused a real problem before someone caught it? And when it was caught, was it a person checking back with the original source, or something more structural?
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." He can be reached at andreas@thehambergerreport.com. A Concise History of Linux chronicles the operating system that changed the world and the lessons it holds for the AI era.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
[1] Phoronix. "Greg KH Forewarns Of 'Rough' Linux 7.3 Kernel Cycle Due To Continued AI Churn." 2 September 2026. https://www.phoronix.com/news/Linux-7.3-Rough-Cycle
[2] TheNextWeb. "Torvalds joked that AI made Linux 7.3-rc2 this big, and nobody checked." September 2026. (No URL captured in the source research package; the package's own fetch could not verify a literal page URL string, so none is cited here.)
[3] Phoronix, OSTechNix, and Neowin. Linux 7.3-rc2 release coverage, including Kees Cook's Coccinelle-driven kmalloc_obj conversion and the Nouveau driver fixes for NVIDIA Blackwell hardware. 6 September 2026. (No URL captured for this multi-source coverage in the source research package.)
[4] Torvalds, Linus. Linux 7.3-rc2 announcement. linux-kernel mailing list. 6 September 2026. (Primary source; not directly accessible this session via lore.kernel.org, which returned HTTP 403 through its bot-protection layer. Content and characterisation corroborated through the secondary press listed above.)