In 1998, while I was Technical Services Manager at ICONZ, I read Eric Raymond's essay on the cathedral and the bazaar for the first time. It did not teach me a new idea. It gave me language for a practice I was already running: release early, release often, and let the people actually using the thing find the bugs you cannot. The same office ran a running argument that never quite settled, Linux people against the BSD people, a close cousin of the Tanenbaum-Torvalds fight happening in public at the same time. My own view was settled then and has not moved since: Linux won because it shipped, because the driver support turned up, because the package ecosystem outgrew anything a smaller, more careful project could match. Production needs beat theoretical cleanliness, every time I watched it happen.
But there is a narrower thing the BSD side was quietly right about, and this October gave it a dated, public example.
Three releases landed inside nine days this month, and none of them is remarkable on its own. Read together, they say something none of them says alone.
On 15 October 2026, Canonical shipped Ubuntu 26.10 and named Linux kernel 7.3 as the kernel it carries. Canonical's own release notes are specific about what that means: the kernel images are built as "7.3.0-9.9", and the notes say plainly that this build is "based on 7.3-rc6", a release candidate. Not the finished kernel. A release candidate is Linus Torvalds' own judgement that a tree is close to ready, issued while he is still deciding whether it actually is. The Register noticed the gap the next day and did not dress it up: its 16 October piece states that "the release version of Ubuntu 26.10 comes with a pre-release kernel, and machines will get updated to the completed 7.3 as soon as it's available." That is the trade press, in print, calling a shipped product unfinished on the day it shipped.
Three days later, on 18 October 2026, Torvalds released the finished Linux 7.3: 18,765 non-merge commits from 3,021 developers, 807 of them submitting for the first time. Two features worth knowing even if you never touch a kernel source tree: a new pseudo-filesystem called failfs, paired with a file-descriptor-based alternative to chroot called fchroot(2), giving processes a way to isolate themselves from parts of the filesystem without the path-based tricks that isolation has relied on for decades; and a completion of nested sub-schedulers inside the kernel's programmable scheduling framework, letting one scheduling policy delegate whole groups of processes to a different policy underneath it. Those are the kind of features a release note buries in the middle. The date they arrived on is the one that matters here, because it is not the date Ubuntu's own box said they would.
Canonical's reasoning, stated in its own release notes, was not evasive about any of this: the previous two cycles, 7.1 and 7.2, had shipped on time with no delays, so the kernel team judged 7.3 a reasonable bet despite a compressed schedule. That is a dated engineering trade-off, made in the open, not a cover-up discovered after the fact. It is also exactly the kind of bet that only makes sense if you accept that a distribution's release date and a kernel's release date are two different clocks, running on two different authorities, that happen to usually agree. Ubuntu 26.10 also carries GNOME 51 and a nine-month support window running to July 2027, which is the context that makes the bet rational rather than careless: a short support window rewards shipping the newest kernel close to on schedule, even three days early, far more than it rewards waiting for a tag to catch up.
Five days after the kernel, on 20 October 2026, the OpenBSD project released OpenBSD 8.0, its 61st release in a cadence that has not moved in thirty years. New in this one: virtual machine management gaining support for up to 64 virtual CPUs per guest, x2apic mode support for guest virtual machines, and interrupt support for a modern virtual device standard. None of that is the point. The point is what OpenBSD's release page does not need to say: kernel, userland and documentation ship as one thing, "8.0", because there is no separate distribution sitting between the project and the user with its own calendar to keep. OpenBSD cannot produce Ubuntu's kind of gap. Not because its engineers are more careful, though they might be, but because there is nobody else in the room positioned to make a competing claim about what "8.0" contains.
That is the thing the BSD argument, stripped of the production-versus-theory fight I settled thirty years ago, was quietly right about. A single authority over a single version string closes a gap that a layered one leaves open by construction.
"Release" is doing three different jobs in the sentence "Ubuntu 26.10 ships Linux kernel 7.3", and the sentence gives you no way to tell which job is which. A kernel release is a tag one person applies to a tree on the date he judges it ready, and the date moves if the tree is not. A distribution release is a calendar commitment made months earlier that the tree has to be ready for, regardless of whether the kernel's own schedule agrees, so when it is not ready the distribution ships what exists and calls it by the name it expects the finished thing to carry. A BSD-style release is neither of those, because there is no second party positioned to disagree with the first about what the current version is. Three structures, three different relationships between a claim and a fact, and the same six-character string, "7.3", sitting on top of all of them as if it meant one thing.
Worth naming in one sentence, because it is not a story about any single country's regulation: Canonical is a UK-headquartered commercial vendor; the kernel's own release authority, Torvalds and the Linux Foundation, is a US-based nonprofit structure; OpenBSD's project leadership sits in Canada. Three different legal and commercial geographies, and not one of the three dates in this story depends on any of their governments acting. The gap is a property of organisational structure, whether a distribution layer exists at all, not of law.
I have watched this exact confusion cost real time in my own work, on systems with far higher stakes than a desktop upgrade: a build sheet says one thing, the artefact that actually got deployed says another, and nobody notices until something downstream behaves in a way the paperwork cannot explain. The instinct to read a version number as settled fact, rather than as a claim somebody is making, is not a kernel problem. It is a habit that needs breaking everywhere a number gets printed on a release.
None of this makes Ubuntu's choice wrong, and it would be just as lazy to call OpenBSD's model simply better. Ubuntu's bet traded a few days of version mismatch for the ability to ship a newer kernel on a schedule its users can plan around; that is a reasonable trade for most desktops and most servers, and it was a known, disclosed trade-off the moment it was made, not a surprise sprung on anyone. OpenBSD's model trades away exactly the flexibility that let Ubuntu make that bet in the first place: there is no faster-moving kernel to target, because there is no kernel separate enough from the release to move independently. Each model is the right one for what it is trying to do. What neither model does is tell you, from the version string alone, which of three different kinds of authority you are actually trusting when you read it.
Episodes 35 and 36 of this series both asked a version of the authority question one layer down the stack: who gets to claim they wrote a line of code, and who gets to require that claim be disclosed. This fortnight's three releases ask it one layer up. Before you get to who wrote the code, you have to settle who gets to say what the finished thing is even called, and the honest answer, this October, is that more than one party can answer that question for the same piece of software, in the same week, and both be telling the truth.
The reason any of this is checkable at all is itself an open-source fact, not a regulatory one. Canonical's own release notes say, in writing, that the shipped kernel is a release candidate, not the finished tree. Torvalds' own tag history records the exact day 7.3 became real. OpenBSD's own release page states its version the way it always has, because the project keeps no second ledger that could ever disagree with the kernel. None of that transparency was mandated by a regulator or a customer contract; it exists because publishing the release process, not just the release, is the norm these three projects were built on, and it is why The Register could write "pre-release kernel" in a headline rather than guess at it. A closed vendor's shipping date is a claim you take on trust. An open one's is a record you can check.
The same question, who gets to say what you are running, has a harder answer once the system is not a desktop. United States Space Force ground segment software runs substantially on Linux, and the people who operate and accredit it cannot afford to discover three days late that the kernel their build notes named was not the kernel that shipped. A security accreditation or an incident response team starts from one assumption this fortnight quietly tested: the version string is a fact, not a claim awaiting confirmation. Defence procurement and assurance processes built around Linux and BSD-derived stacks exist to verify what a build actually contains, not to trust what its release notes say, because the cost of that assumption failing scales with what the system runs. Ubuntu's three-day gap was survivable on a laptop. The same gap, unverified, is not a story anyone tells about a ground station.
You have spent thirty years reading version numbers off release notes, package managers and "about" screens, trusting that the number tells you what you are actually running. This fortnight, the number printed on a brand-new Ubuntu install described a kernel that did not exist yet. If you had to bet your own production systems on only one of the three authorities in this story, the distribution's calendar, the kernel maintainer's judgement, or a project with no distribution layer at all standing between you and the code, which one would you actually trust to tell you the truth about what is running, and why isn't it the one most of us default to?
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] Canonical. "Ubuntu 26.10 release notes." 15 October 2026. https://documentation.ubuntu.com/release-notes/26.10/
[2] The Register. "Ubuntu Stonking Stingray swims into spotlight with pre-release kernel." 16 October 2026. https://www.theregister.com/os-platforms/2026/10/16/ubuntu-stonking-stingray-swims-into-spotlight-with-pre-release-kernel/5303580
[3] OpenBSD Project. "OpenBSD 8.0." 20 October 2026. https://www.openbsd.org/80.html
[4] OSTechNix. "Linux Kernel 7.3 Is Officially Released: 5 Key Features You Must Know." 18 October 2026. https://ostechnix.com/linux-kernel-7-3-released/