Stability Is the Feature: What Linux 7.0 Is Actually Optimising For
[NAVIGATION LINKS: not applicable for narrative series]
LINUX WEDNESDAYA Concise History of Linux: Episode 15
Sometime last month, I clicked a button in the AWS console. The default AMI was Ubuntu 26.04 LTS. I accepted it, the instance started, and within seconds I was doing actual work. I had no idea which kernel version was running. I did not need to know.
That is perhaps the most significant thing I can tell you about Linux in 2026.
In 2003, I knew exactly which kernel version was running. I had compiled it myself, with hand-tuned flags, in the cave under the Auckland bungalow. Yoper Linux, the distribution I founded, reached number one on DistroWatch on the strength of one metric: speed. Boot times. Startup performance. Every unnecessary package removed, every cycle recovered. The fastest desktop Linux distribution in the world, built in New Zealand, by a team that measured success in seconds.
Twenty years later, I am clicking a button and inheriting Linux 7.0 by default, and I do not notice.
That is not a story about apathy. It is a story about what Linux has become so good at that it has become invisible. And Linux 7.0, which Linus Torvalds released on 12 April 2026 with a version number he described as the result of being "easily confused" and "not good with big numbers," is the most precise statement of what the kernel is now optimising for.
It is not speed. Not primarily. The kernel is optimising for stability at the language level, and it has been doing so for years.
The Mainframe Lesson
Running Linux on mainframe hardware, as I have done at various points across my career, reorders your priorities in ways that stay with you.
When you deploy Linux on that class of platform, the performance question is largely answered before you begin. The hardware delivers the throughput. What you are actually engineering for is something different: the system must not fall over. The overnight batch must complete. The workload must not lose data. In that environment, stability is not a secondary virtue sitting behind performance in the priority stack. It is the requirement. Performance is what the platform provides. Stability is what the kernel must guarantee.
That distinction, between what the platform provides and what the operating system must protect, stayed with me across every subsequent architecture engagement. Not every system has the same threat model. Not every deployment is optimising for the same thing. What looks like a performance trade-off from one angle is often a stability investment from another. The same logic applies well beyond kernel engineering: build for uptime before you build for throughput. The enterprise architecture community calls it architectural intention; the kernel community just calls it engineering for the boring case. The name does not matter. The discipline does.
Linux 7.0 is a stability investment. It is also, in its own way, the logical conclusion of thirty years of kernel engineering.
What Is Actually in the Release
Rust has been part of the Linux kernel since version 6.1 in December 2022, carrying an explicit "experimental" label throughout. In Linux 7.0, that label is removed. Rust is now a first-class language in the kernel tree, with one practical consequence that matters immediately: kernel builds now require only stable Rust releases, anchored to the Debian stable toolchain. Previously, reproducible kernel builds required nightly Rust releases, which created a fragility the kernel community found uncomfortable. The coexistence model, Rust for new code and C for existing subsystems with no forced migrations of working code, was formalised as explicit kernel policy at the 2025 Linux Kernel Maintainers Summit in Tokyo. It is now documented architecture rather than informal convention.
Why does this matter? According to kernel security research, approximately two-thirds of Linux kernel CVEs across the kernel's history trace to a single class of bug: memory-safety errors. Buffer overflows. Use-after-free vulnerabilities. Null pointer dereferences. CVE-2024-1086, a use-after-free in the nf_tables subsystem, had been present in the kernel for over a decade before discovery; CISA confirmed active exploitation in 2025 by RansomHub and Akira ransomware groups for privilege escalation. CVE-2025-21756, in the vsock subsystem, gave attackers root access and a path from virtual machine to host, a direct threat to multi-tenant cloud environments.
Two of the ransomware groups that have been active against New Zealand infrastructure used that kernel bug for privilege escalation. The class of code that produced CVE-2024-1086 does not compile in conformant Rust.
Rust prevents these bugs at compile time, before the code runs. The ownership model enforced by the compiler makes use-after-free errors impossible to write in conformant Rust code. The class of vulnerability responsible for two-thirds of kernel CVEs does not exist in code the Rust compiler accepts.
That is what removing "experimental" from Rust in the kernel actually means. It is not a language preference. It is a systematic response to a documented vulnerability pattern that C code has been unable to eliminate in thirty years.
Linux 7.0 also introduces ML-DSA post-quantum signatures for kernel module authentication, replacing SHA-1-based module-signing schemes, which are simultaneously removed. This is the kernel's first operational step toward post-quantum cryptographic infrastructure. The decision is not theoretical: "harvest now, decrypt later" attacks against SHA-1-signed modules fall within the practical threat horizon for adequately resourced adversaries. The kernel is moving ahead of that horizon rather than reacting to it.
In the 7.0 release announcement, Torvalds commented on the unusually high volume of small fixes in the final development week. He attributed it to AI-assisted bug reporting: "I suspect it's a lot of AI tool use that will keep finding corner cases for us for a while, so this may be the 'new normal' at least for a while."
The person who wrote the first kernel commit in 1991 is describing AI tooling as the likely permanent future of kernel quality assurance. The 28-hour compile I ran in 1994 on a 486, patient, manual, one person and a floppy disk, and the AI-assisted corner-case discovery of 2026 are two points on the same line. The line was never primarily about speed.
One more feature deserves mention: autonomous XFS filesystem self-healing. Linux 7.0's XFS implementation now tracks metadata errors in real time via a background daemon that can initiate online repairs while the filesystem remains mounted. Minor disk corruption can be fixed without taking the system offline. You do not notice it is happening. The system keeps running.
That, precisely, is what stability means in practice.
The Metric Shift
In the Yoper era, I measured a distribution's quality by how fast it booted. By how responsive the desktop felt on modest hardware. By whether we could shave another second off the login screen. Those were legitimate metrics. They served real users on real hardware in 2003.
The Ubuntu 26.04 instance I spun up in AWS last month will run for months. Perhaps years. It will serve requests from real users, process real data, and participate in systems that did not exist when Yoper reached number one on DistroWatch. Boot time is irrelevant. The question that matters is whether the system is still running next Tuesday.
The kernel has been answering that question for thirty years. Linux 7.0's answer involves memory-safe systems code, post-quantum module authentication, and AI-assisted quality assurance. The overhead being eliminated is not startup time. It is the overhead of writing unsafe code.
Modern Bridge
The version bump question, does 7.0 mean anything or is it just counting convention, turns out to be exactly the right question to ask about the state of the Linux landscape in 2026.
Canonical's Ubuntu 26.04 LTS ships with opt-in LLM tooling and a prospective mechanism for AI-related configuration controls in future releases. The open-source community response has been pointed: including proprietary AI components as default-adjacent options in an LTS release is a Cathedral decision imposed on a Bazaar community. It is the same structural argument Torvalds made against Tanenbaum in 1992, that shipped working code beats perfect theory arrived at eventually, being inverted. The community is asking whether AI convenience defaults are worth the governance cost before those defaults become normalised.
The kernel community ran this negotiation already, over four years, in the Rust adoption debate. New language in the kernel tree. Sustained opposition from C maintainers. Technical review cycles. Compromise on the coexistence model. The result is memory safety at scale, written into the kernel's forward architecture. The process was slow. The outcome is durable.
The distribution layer is now running the same negotiation about AI integration, at higher speed and with less process. Whether the outcome is similarly durable is not yet clear.
Separately: Anthropic, AWS, Google, Google DeepMind, Microsoft, GitHub, and OpenAI have all committed grants to the OpenSSF Alpha-Omega project, the open-source supply chain security initiative. The companies whose products run on Linux, and whose AI training ran on Linux-based systems, are now funding the security infrastructure of the foundation they have built on.
The kernel continues compiling. The version number increments. The community continues arguing about what defaults mean.
The overhead being eliminated, slowly, across releases, is the cost of building on unsafe foundations.
You have been on both sides of this: building a distribution where every second of boot time mattered, and deploying infrastructure where the question is whether the system is still running next week. What changed for you? And if you were building a Linux distribution today, not for a developer laptop but for the infrastructure that runs the actual world, what would you optimise for, and what would you sacrifice to get it?
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. They do not represent the views of my employer, 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. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is an Auckland-based enterprise architect, security leader, and technology strategist with more than 30 years of experience across New Zealand's public and private sectors. He founded Yoper Linux, which reached number one on DistroWatch, and spent two years as Pre-Sales Specialist for Novell ANZ, selling SUSE Linux Enterprise Server across Australia and New Zealand. He holds the linux.co.nz domain and the LINUX number plate. He can be reached at linux@linux.co.nz.
A Concise History of Linux chronicles the operating system that changed the world, and the lessons it holds for the AI era.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
[1] 9to5Linux. "Linux Kernel 7.0 Released." 12 April 2026. https://9to5linux.com
[2] StorageNewsletter. "Linux Kernel 7.0 Released by Linus Torvalds." 21 April 2026. https://storagenewsletter.com
[3] Linuxiac. "Linux 7.0 Released: Rust Promoted, Post-Quantum Signatures, and More." 12 April 2026. https://linuxiac.com
[4] OSTechNix. "Linux Kernel 7.0: Key Features and Changes." April 2026.
[5] FOSS Linux. "Linux 7.0 Security and Memory Safety Analysis." April 2026.
[6] CIQ Blog. "Linux Kernel CVE Landscape Retrospective." January 2026.
[7] CISA. "Known Exploited Vulnerabilities Catalogue: CVE-2024-1086." 2025. https://cisa.gov/known-exploited-vulnerabilities-catalog
[8] National Vulnerability Database. "CVE-2025-21756." 2026. https://nvd.nist.gov
[9] Botmonster. "2025 Linux Kernel Maintainers Summit Outcomes, Tokyo." April 2026.
[10] Linux Foundation. "OpenSSF Alpha-Omega Project: 2026 Grant Commitments." April 2026. https://linuxfoundation.org
[11] LXer. "Ubuntu 26.04 LTS Ships with AI Tooling and Kill Switch Option." Late April 2026.
[12] Torvalds, Linus. Linux Kernel 7.0 Release Announcement (kernel mailing list). 12 April 2026. Cited via StorageNewsletter [2] and OSTechNix [4].