Linux 7.2 crossed 43 million total lines in the kernel source tree during its June 2026 merge window, with Phoronix reporting 43,898,743 lines counted by
The cleanest way to misread the 43-million-line figure is to treat it as a scoreboard. Linux is not “better” because it has more code, nor is it automatically worse because the count keeps climbing. Line counts are crude instruments; they measure mass, not design quality.
But crude instruments can still tell us when something heavy is moving. Phoronix’s comparison between Linux 7.1 and the current Linux 7.2 development tree shows nearly a million additional counted lines between releases: from 42,924,382 total lines to 43,898,743. That jump includes blank lines, comments, and actual code, but the code-only portion also rose substantially, from 32,975,752 to 33,653,681.
That is not the profile of a project merely polishing old corners. It is the profile of a kernel absorbing another wave of hardware enablement, driver expansion, architectural cleanup, and subsystem churn. The Linux kernel is not a compact academic artifact; it is the place where the messy physical world introduces itself to software.
For WindowsForum readers, that should sound familiar. Windows and Linux are often discussed as cultural opposites, but the operating-system engineering problem underneath them is increasingly the same: every new GPU, accelerator, storage controller, laptop platform, USB variant, security feature, and power-management trick wants kernel-level cooperation. The kernel becomes a ledger of the industry’s accumulated complexity.
That means one modern GPU driver family accounts for a huge share of the kernel tree’s visible mass. It also explains why the “Linux kernel” can look bloated if viewed as one monolithic blob, even though most users will never exercise most of that code on a given machine. A server with Intel integrated graphics, a Steam Deck-class handheld, an AMD workstation GPU, and a cloud node running no display stack at all are all technically covered by the same upstream universe, but they do not all carry the same runtime reality.
This is where the line-count panic usually becomes misleading. Modern graphics drivers are not simple pieces of glue between an operating system and a framebuffer. They contain support for display engines, video codecs, memory management, scheduling, firmware interfaces, compute queues, power states, virtualization paths, debugging hooks, and generations of silicon whose differences matter.
That does not mean every line is sacred. It means the code is a symptom of a larger bargain. Linux promises broad hardware reach and upstream driver availability; vendors want mainline support for competitive reasons; users want their hardware to work without chasing binary blobs through distribution-specific packaging rituals. The bill comes due in maintenance.
That should, in theory, reduce the kernel’s burden. In practice, it reduces one kind of burden while another kind expands faster. Removing old CPU support can simplify assumptions and trim compatibility scaffolding, but it cannot offset the rate at which modern GPUs, laptop platforms, networking devices, accelerators, and firmware interfaces are being added or revised.
This is the central tension of Linux in 2026: the project can prune and still grow. It can remove museum hardware while adding the future’s peripherals. It can simplify architecture code while expanding driver code. It can kill unsafe APIs while growing the total surface area that needs review.
The public often imagines software cleanup as a visible slimming exercise. Kernel cleanup is more like structural reinforcement in a city that is still adding neighborhoods. Old bridges come down, but new interchanges appear at the edge of town.
This is one of Linux’s great strengths. The process is public, fast, and brutally iterative. Hardware enablement does not wait years for a monolithic operating-system release; it flows continuously through subsystem trees, review queues, and release candidates.
It is also one of Linux’s permanent risks. Every merge window turns ambition into maintenance debt. A driver merged today may need security fixes, build fixes, bisectability repairs, documentation updates, and compatibility handling for years. The code enters a social system, not just a repository.
That social system is large, but it is not infinite. Maintainers are people with review bandwidth, vendor priorities, day jobs, and burnout thresholds. The line count is therefore not a vanity metric; it is a proxy for how much coordination the kernel community must sustain.
A modern Windows installation depends on an enormous driver ecosystem that spans Microsoft, Intel, AMD, Nvidia, Realtek, Qualcomm, MediaTek, Synaptics, and countless smaller vendors. That code may not all live in one public Git tree counted by
Linux’s public tree makes the sprawl easier to quantify. Windows’ model often makes the sprawl easier to underestimate. Anyone who has debugged a bad storage driver, a broken Wi-Fi stack after a feature update, or a GPU driver regression knows that driver complexity is not an open-source problem. It is the cost of general-purpose computing on wildly variable hardware.
This is why the Linux line count should interest Windows administrators. It is a reminder that the operating system is no longer just the thing above the BIOS and below the apps. It is the negotiation layer between silicon vendors, cloud platforms, security researchers, firmware teams, and users who expect a laptop to wake instantly while running workloads that would have sounded absurd a decade ago.
More code can mean more attack surface, especially in drivers and subsystems exposed to untrusted input, device firmware, user-space interfaces, file formats, networking paths, and virtualization boundaries. Kernel bugs are especially consequential because the kernel sits at the center of privilege. A vulnerability in obscure driver code may not matter to every machine, but when it matters, it can matter catastrophically.
At the same time, smaller is not automatically safer. A compact kernel with proprietary out-of-tree driver blobs may present less visible source code while hiding equally serious defects from public review. A large upstream driver may be easier to audit, test, fuzz, and fix than a smaller vendor component distributed as an opaque binary.
Linux’s security story has always been a trade between exposure and visibility. The code is there for everyone to inspect, but “everyone” does not mean every line receives equal attention. The more the tree grows, the more important automated testing, static analysis, fuzzing, memory-safe language experiments, and disciplined subsystem ownership become.
This is where the Rust-for-Linux effort, compiler hardening, API removals, and old-code cleanup matter more than the headline count. The long-term security question is not whether Linux can avoid growth. It is whether Linux can make dangerous classes of growth less dangerous.
The
One of the more meaningful Linux 7.2-era cleanups reportedly involves the removal of kernel-side uses of
Line count treats all code as weight. Maintainers treat code as behavior. Removing an unsafe idiom from across subsystems can reduce risk even if the total tree grows during the same merge window. Conversely, adding thousands of lines for a well-isolated new driver may be less concerning than retaining a few dozen lines of tricky legacy code in a hot path.
This is why simplistic bloat arguments often miss the engineering reality. A kernel can become larger and safer at the same time. It can also become smaller and more brittle if cleanup is done carelessly. The direction of the line count tells us something, but not the thing that matters most.
The real question is whether the project is replacing bad complexity with better complexity. Hardware support is complex by nature; the goal is not to pretend otherwise. The goal is to put that complexity in reviewable, testable, maintainable places.
That transformation pushes driver stacks into the kernel. Memory sharing between CPU and GPU, scheduling of compute workloads, display timing, hotplug behavior, suspend and resume, firmware loading, and virtualization support all require careful coordination. The result is not a small driver in the old sense; it is a platform inside the platform.
For Linux users, upstream AMDGPU support has been a major success story. It has helped make AMD hardware attractive to desktop Linux users, workstation users, and gaming-focused distributions. It has also reduced the friction that historically came with closed or semi-closed graphics driver models.
But success has mass. A multi-million-line driver subtree becomes a maintenance institution. It needs vendor commitment, community review, regression testing, and distribution integration. It also changes the psychology of the kernel: when a single vendor driver family becomes one of the largest bodies of code in the tree, hardware strategy and kernel strategy become harder to separate.
But general-purpose operating systems keep colliding with general-purpose hardware. The Linux kernel is not merely an abstraction layer for POSIX processes. It is a global compatibility project for servers, phones, routers, embedded boards, laptops, desktops, supercomputers, development kits, industrial devices, and hardware that has not yet reached retail shelves.
A small kernel can exist when the target is narrow. An embedded RTOS, a research microkernel, a hypervisor, or a vendor-controlled appliance can be elegant because it gets to say no. Linux’s superpower is that it says yes more often than most systems can afford to.
That “yes” is not free. It expands the codebase, enlarges the test matrix, and creates awkward dependencies between maintainers and hardware vendors. Yet it is also why Linux became the default substrate for so much of modern infrastructure. The line count is the shadow cast by that victory.
Some users will get hardware support that did not exist before. Some will see better suspend behavior, display handling, filesystem fixes, or performance tuning. Others will encounter regressions, because that is what happens when software reaches this scale and runs on machines maintainers cannot physically test.
For administrators, the lesson is not to fear every new kernel. It is to treat kernel adoption as infrastructure change. A kernel update can alter hardware behavior, security posture, virtualization characteristics, filesystem handling, and driver availability. That is not “just another package” in any serious fleet.
Windows administrators already understand this in the form of cumulative updates, driver updates, firmware packages, and feature releases. Linux administrators sometimes benefit from a more modular distribution model, but the underlying risk remains. A new kernel is a new hardware contract.
Not every line is equally maintained. Some code is actively developed by vendors with paid engineering teams. Some is cared for by small maintainer groups. Some is effectively dormant until it breaks. Some is generated, repetitive, or hardware-table-heavy. Some sits in drivers for devices that only a small fraction of users will ever encounter.
The burden of the kernel is therefore unevenly distributed. A million lines in a heavily staffed subsystem may be healthier than ten thousand lines in a neglected driver that no one can test. A large comment block may help future maintainers; a small clever function may become a decade-long trap.
This is why the best kernel analysis tends to look past raw scale and toward governance. Who owns the code? Who tests it? Who responds when it breaks? Who has hardware? Who has authority to remove it? Who pays for the engineers whose work everyone else depends on?
The 43-million-line threshold is a reminder that Linux is not only a code project. It is an institution for assigning responsibility across the hardware industry.
Windows faces it through WHQL, Windows Update, vendor drivers, kernel-mode restrictions, virtualization-based security, hardware certification, and increasingly strict platform requirements. Linux faces it through upstreaming, maintainer review, distribution kernels, open driver stacks, and a culture that prizes visible development. Both models make trade-offs.
Microsoft can enforce platform rules in ways Linux often cannot. Linux can absorb vendor work into the open in ways Windows generally does not. Microsoft can break with old hardware through support policy and Windows version requirements. Linux can carry old hardware longer, then remove it through public technical argument. Neither approach eliminates complexity; each decides how to govern it.
The result is a strange convergence. Windows is becoming more controlled to preserve security and reliability across a sprawling ecosystem. Linux is becoming more selective because its historical willingness to carry everything has limits. Both are reacting to the same underlying fact: modern hardware platforms are too complex for operating systems to treat every compatibility promise as permanent.
Cloud providers need Linux to scale across server generations. Chip vendors need Linux support to sell into data centers, embedded systems, AI infrastructure, handhelds, developer boards, and workstations. Distributions need upstream kernels that work broadly enough to avoid carrying endless private patch stacks. Users expect new hardware to function sooner rather than later.
That success creates a gravitational pull. Vendors upstream code because being out-of-tree is painful. Maintainers accept code because hardware support is part of Linux’s value. Users benefit because mainline support reduces fragmentation. Then the tree grows, and everyone argues about bloat.
The argument is healthy, but only if it stays honest. Linux is not growing because maintainers forgot how to delete files. It is growing because the industry keeps asking Linux to be everywhere.
This is one reason kernel maintainers are cautious about removal. Dropping old code can unlock cleanup and reduce burden, but it can also strand users who have no alternative. The Linux community’s debates over old x86 support show how technical and cultural considerations intertwine. At some point, maintaining ancient compatibility becomes unreasonable; deciding that point is rarely painless.
The same problem exists in Windows, but it is mediated through commercial support lifecycles. Microsoft can declare hardware unsupported, and OEMs can move on. Linux has no single product manager with that authority. Its authority emerges through maintainer consensus, technical argument, and the practical reality of who is willing to keep code alive.
That makes Linux messier, but also more transparent. We can watch the trade-off happen in public.
Some complexity is accidental and should be removed. Some is defensive and should be celebrated. Some is vendor-driven and deserves scrutiny. Some is the unavoidable cost of supporting the machines people actually own. The art is in distinguishing these categories before reaching for slogans.
Linux’s growth should make users and administrators alert, not cynical. A large kernel needs better testing, clearer subsystem boundaries, more aggressive cleanup, and safer programming practices. It does not need performative nostalgia for a hardware world that no longer exists.
The danger is not that Linux has crossed an arbitrary threshold. The danger is that the industry may keep increasing the kernel’s responsibility faster than the kernel community can increase its review, testing, and maintenance capacity.
The practical reading is not “Linux is bloated” or “Linux is winning.” It is that operating systems now live under permanent pressure from hardware diversity, security expectations, and vendor acceleration. The kernel is where those pressures stop being marketing slides and become code.
This matters even if you never boot Linux on bare metal. It matters because Linux runs the cloud services Windows clients depend on, the Android devices users sync with, the routers and appliances in homes and offices, and the development environments increasingly used by Windows developers through virtualization and subsystem layers. Linux’s maintenance health is now part of the broader computing commons.
When that commons grows by nearly a million counted lines in a single development cycle, it is worth asking not whether the number is too large, but whether the institutions around it are strong enough.
cloc shortly before the expected Linux 7.2-rc1 release on June 28. The number is eye-catching, but the more important story is not bloat in the lazy sense. It is that modern operating systems are increasingly collections of hardware obligations, security responses, compatibility promises, and vendor ambitions — and Linux is now showing that burden in plain arithmetic.
The Kernel Is Growing Because the Hardware World Refuses to Sit Still
The cleanest way to misread the 43-million-line figure is to treat it as a scoreboard. Linux is not “better” because it has more code, nor is it automatically worse because the count keeps climbing. Line counts are crude instruments; they measure mass, not design quality.But crude instruments can still tell us when something heavy is moving. Phoronix’s comparison between Linux 7.1 and the current Linux 7.2 development tree shows nearly a million additional counted lines between releases: from 42,924,382 total lines to 43,898,743. That jump includes blank lines, comments, and actual code, but the code-only portion also rose substantially, from 32,975,752 to 33,653,681.
That is not the profile of a project merely polishing old corners. It is the profile of a kernel absorbing another wave of hardware enablement, driver expansion, architectural cleanup, and subsystem churn. The Linux kernel is not a compact academic artifact; it is the place where the messy physical world introduces itself to software.
For WindowsForum readers, that should sound familiar. Windows and Linux are often discussed as cultural opposites, but the operating-system engineering problem underneath them is increasingly the same: every new GPU, accelerator, storage controller, laptop platform, USB variant, security feature, and power-management trick wants kernel-level cooperation. The kernel becomes a ledger of the industry’s accumulated complexity.
The Line Count Is Less About Linux Than About Everyone Else
The most striking detail in the Phoronix report is not the total line count but the scale of the AMD graphics driver stack. Thedrivers/gpu/drm/amd subtree, covering AMDGPU and AMDKFD, reportedly sits around 6.36 million lines in the Linux 7.2 development tree, up from roughly 6.17 million in Linux 7.1.That means one modern GPU driver family accounts for a huge share of the kernel tree’s visible mass. It also explains why the “Linux kernel” can look bloated if viewed as one monolithic blob, even though most users will never exercise most of that code on a given machine. A server with Intel integrated graphics, a Steam Deck-class handheld, an AMD workstation GPU, and a cloud node running no display stack at all are all technically covered by the same upstream universe, but they do not all carry the same runtime reality.
This is where the line-count panic usually becomes misleading. Modern graphics drivers are not simple pieces of glue between an operating system and a framebuffer. They contain support for display engines, video codecs, memory management, scheduling, firmware interfaces, compute queues, power states, virtualization paths, debugging hooks, and generations of silicon whose differences matter.
That does not mean every line is sacred. It means the code is a symptom of a larger bargain. Linux promises broad hardware reach and upstream driver availability; vendors want mainline support for competitive reasons; users want their hardware to work without chasing binary blobs through distribution-specific packaging rituals. The bill comes due in maintenance.
Deleting the Past Does Not Automatically Shrink the Future
One reason the Linux 7.2 number lands with some irony is that it arrives alongside cleanup work and old-hardware retirements. Recent kernel cycles have seen renewed pressure to remove support for long-obsolete x86-era platforms, including i486-related code and other legacy paths that complicate modern development.That should, in theory, reduce the kernel’s burden. In practice, it reduces one kind of burden while another kind expands faster. Removing old CPU support can simplify assumptions and trim compatibility scaffolding, but it cannot offset the rate at which modern GPUs, laptop platforms, networking devices, accelerators, and firmware interfaces are being added or revised.
This is the central tension of Linux in 2026: the project can prune and still grow. It can remove museum hardware while adding the future’s peripherals. It can simplify architecture code while expanding driver code. It can kill unsafe APIs while growing the total surface area that needs review.
The public often imagines software cleanup as a visible slimming exercise. Kernel cleanup is more like structural reinforcement in a city that is still adding neighborhoods. Old bridges come down, but new interchanges appear at the edge of town.
The Merge Window Is Where Ambition Becomes Maintenance Debt
Linux’s development cadence makes this growth unusually visible. The merge window opens after a stable release, maintainers send Linus Torvalds the work they have staged for the next cycle, and the first release candidate marks the transition from feature intake to stabilization. Linux 7.2-rc1 therefore matters not because it is something ordinary users should rush to install, but because it freezes the rough outline of what the next stable kernel is likely to become.This is one of Linux’s great strengths. The process is public, fast, and brutally iterative. Hardware enablement does not wait years for a monolithic operating-system release; it flows continuously through subsystem trees, review queues, and release candidates.
It is also one of Linux’s permanent risks. Every merge window turns ambition into maintenance debt. A driver merged today may need security fixes, build fixes, bisectability repairs, documentation updates, and compatibility handling for years. The code enters a social system, not just a repository.
That social system is large, but it is not infinite. Maintainers are people with review bandwidth, vendor priorities, day jobs, and burnout thresholds. The line count is therefore not a vanity metric; it is a proxy for how much coordination the kernel community must sustain.
Windows and Linux Are Converging on the Same Driver Problem
Windows users may be tempted to treat this as a Linux-specific curiosity, but the deeper pattern is cross-platform. Windows hides more of its hardware support behind vendor packages, inbox drivers, Windows Update distribution, and OEM images. Linux exposes more of it in the upstream tree. The engineering problem, however, is shared.A modern Windows installation depends on an enormous driver ecosystem that spans Microsoft, Intel, AMD, Nvidia, Realtek, Qualcomm, MediaTek, Synaptics, and countless smaller vendors. That code may not all live in one public Git tree counted by
cloc, but it still shapes stability, security, power behavior, sleep reliability, display output, and update failures. The difference is not whether the complexity exists; it is where the complexity is visible.Linux’s public tree makes the sprawl easier to quantify. Windows’ model often makes the sprawl easier to underestimate. Anyone who has debugged a bad storage driver, a broken Wi-Fi stack after a feature update, or a GPU driver regression knows that driver complexity is not an open-source problem. It is the cost of general-purpose computing on wildly variable hardware.
This is why the Linux line count should interest Windows administrators. It is a reminder that the operating system is no longer just the thing above the BIOS and below the apps. It is the negotiation layer between silicon vendors, cloud platforms, security researchers, firmware teams, and users who expect a laptop to wake instantly while running workloads that would have sounded absurd a decade ago.
More Code Means More Attack Surface, but Not Always More Danger
Security-minded readers will reasonably ask whether 43 million lines means 43 million opportunities for bugs. The uncomfortable answer is yes and no.More code can mean more attack surface, especially in drivers and subsystems exposed to untrusted input, device firmware, user-space interfaces, file formats, networking paths, and virtualization boundaries. Kernel bugs are especially consequential because the kernel sits at the center of privilege. A vulnerability in obscure driver code may not matter to every machine, but when it matters, it can matter catastrophically.
At the same time, smaller is not automatically safer. A compact kernel with proprietary out-of-tree driver blobs may present less visible source code while hiding equally serious defects from public review. A large upstream driver may be easier to audit, test, fuzz, and fix than a smaller vendor component distributed as an opaque binary.
Linux’s security story has always been a trade between exposure and visibility. The code is there for everyone to inspect, but “everyone” does not mean every line receives equal attention. The more the tree grows, the more important automated testing, static analysis, fuzzing, memory-safe language experiments, and disciplined subsystem ownership become.
This is where the Rust-for-Linux effort, compiler hardening, API removals, and old-code cleanup matter more than the headline count. The long-term security question is not whether Linux can avoid growth. It is whether Linux can make dangerous classes of growth less dangerous.
The strncpy() Cleanup Shows the Difference Between Size and Health
One of the more meaningful Linux 7.2-era cleanups reportedly involves the removal of kernel-side uses of strncpy(), a C string-copying function long regarded as error-prone in kernel contexts. That kind of change does not grab the same broad attention as “43 million lines,” but it is more revealing of kernel health.Line count treats all code as weight. Maintainers treat code as behavior. Removing an unsafe idiom from across subsystems can reduce risk even if the total tree grows during the same merge window. Conversely, adding thousands of lines for a well-isolated new driver may be less concerning than retaining a few dozen lines of tricky legacy code in a hot path.
This is why simplistic bloat arguments often miss the engineering reality. A kernel can become larger and safer at the same time. It can also become smaller and more brittle if cleanup is done carelessly. The direction of the line count tells us something, but not the thing that matters most.
The real question is whether the project is replacing bad complexity with better complexity. Hardware support is complex by nature; the goal is not to pretend otherwise. The goal is to put that complexity in reviewable, testable, maintainable places.
AMDGPU Is the New Kind of Kernel Giant
The reported AMDGPU and AMDKFD scale deserves special attention because it captures the modern role of the GPU. Twenty years ago, many users still thought of graphics support as a display problem. Today, the GPU is a compute device, media engine, AI accelerator, memory-management participant, power-management headache, and gaming performance battleground.That transformation pushes driver stacks into the kernel. Memory sharing between CPU and GPU, scheduling of compute workloads, display timing, hotplug behavior, suspend and resume, firmware loading, and virtualization support all require careful coordination. The result is not a small driver in the old sense; it is a platform inside the platform.
For Linux users, upstream AMDGPU support has been a major success story. It has helped make AMD hardware attractive to desktop Linux users, workstation users, and gaming-focused distributions. It has also reduced the friction that historically came with closed or semi-closed graphics driver models.
But success has mass. A multi-million-line driver subtree becomes a maintenance institution. It needs vendor commitment, community review, regression testing, and distribution integration. It also changes the psychology of the kernel: when a single vendor driver family becomes one of the largest bodies of code in the tree, hardware strategy and kernel strategy become harder to separate.
The Myth of the Small General-Purpose Kernel Keeps Dying
There is a recurring nostalgia in operating-system debates for something smaller, cleaner, and more comprehensible. The wish is understandable. A smaller kernel is easier to reason about, easier to audit, easier to teach, and easier to imagine securing.But general-purpose operating systems keep colliding with general-purpose hardware. The Linux kernel is not merely an abstraction layer for POSIX processes. It is a global compatibility project for servers, phones, routers, embedded boards, laptops, desktops, supercomputers, development kits, industrial devices, and hardware that has not yet reached retail shelves.
A small kernel can exist when the target is narrow. An embedded RTOS, a research microkernel, a hypervisor, or a vendor-controlled appliance can be elegant because it gets to say no. Linux’s superpower is that it says yes more often than most systems can afford to.
That “yes” is not free. It expands the codebase, enlarges the test matrix, and creates awkward dependencies between maintainers and hardware vendors. Yet it is also why Linux became the default substrate for so much of modern infrastructure. The line count is the shadow cast by that victory.
Distribution Users Will Feel This Indirectly, Then All at Once
Most desktop Linux users will not download Linux 7.2-rc1, count files, or care whether the tree has crossed 43 million lines. They will meet Linux 7.2 later through Fedora, Arch, Ubuntu development builds, openSUSE, Debian backports, gaming distributions, or vendor kernels. By then, the number will have become a set of practical effects.Some users will get hardware support that did not exist before. Some will see better suspend behavior, display handling, filesystem fixes, or performance tuning. Others will encounter regressions, because that is what happens when software reaches this scale and runs on machines maintainers cannot physically test.
For administrators, the lesson is not to fear every new kernel. It is to treat kernel adoption as infrastructure change. A kernel update can alter hardware behavior, security posture, virtualization characteristics, filesystem handling, and driver availability. That is not “just another package” in any serious fleet.
Windows administrators already understand this in the form of cumulative updates, driver updates, firmware packages, and feature releases. Linux administrators sometimes benefit from a more modular distribution model, but the underlying risk remains. A new kernel is a new hardware contract.
Counting Lines Is Easy; Counting Responsibility Is Hard
The Phoronix numbers are useful because they are concrete. They give us a way to see growth that would otherwise be hidden behind release notes and Git logs. But they also invite the wrong conclusion if treated as a measure of responsibility.Not every line is equally maintained. Some code is actively developed by vendors with paid engineering teams. Some is cared for by small maintainer groups. Some is effectively dormant until it breaks. Some is generated, repetitive, or hardware-table-heavy. Some sits in drivers for devices that only a small fraction of users will ever encounter.
The burden of the kernel is therefore unevenly distributed. A million lines in a heavily staffed subsystem may be healthier than ten thousand lines in a neglected driver that no one can test. A large comment block may help future maintainers; a small clever function may become a decade-long trap.
This is why the best kernel analysis tends to look past raw scale and toward governance. Who owns the code? Who tests it? Who responds when it breaks? Who has hardware? Who has authority to remove it? Who pays for the engineers whose work everyone else depends on?
The 43-million-line threshold is a reminder that Linux is not only a code project. It is an institution for assigning responsibility across the hardware industry.
The Real Competition Is Not Windows Versus Linux
WindowsForum readers naturally view Linux news through a Windows-adjacent lens: desktop competition, server competition, gaming compatibility, subsystem overlap, developer workflows, and the long cultural rivalry between Microsoft and open source. But the line-count story points toward a different rivalry. The real contest is between operating systems and complexity itself.Windows faces it through WHQL, Windows Update, vendor drivers, kernel-mode restrictions, virtualization-based security, hardware certification, and increasingly strict platform requirements. Linux faces it through upstreaming, maintainer review, distribution kernels, open driver stacks, and a culture that prizes visible development. Both models make trade-offs.
Microsoft can enforce platform rules in ways Linux often cannot. Linux can absorb vendor work into the open in ways Windows generally does not. Microsoft can break with old hardware through support policy and Windows version requirements. Linux can carry old hardware longer, then remove it through public technical argument. Neither approach eliminates complexity; each decides how to govern it.
The result is a strange convergence. Windows is becoming more controlled to preserve security and reliability across a sprawling ecosystem. Linux is becoming more selective because its historical willingness to carry everything has limits. Both are reacting to the same underlying fact: modern hardware platforms are too complex for operating systems to treat every compatibility promise as permanent.
The Number Is Big Because Linux Won
It is worth saying plainly: Linux would not have 43 million lines in the kernel tree if it had failed. Dead platforms shrink, freeze, or become hobbyist museums. Successful platforms accumulate obligations.Cloud providers need Linux to scale across server generations. Chip vendors need Linux support to sell into data centers, embedded systems, AI infrastructure, handhelds, developer boards, and workstations. Distributions need upstream kernels that work broadly enough to avoid carrying endless private patch stacks. Users expect new hardware to function sooner rather than later.
That success creates a gravitational pull. Vendors upstream code because being out-of-tree is painful. Maintainers accept code because hardware support is part of Linux’s value. Users benefit because mainline support reduces fragmentation. Then the tree grows, and everyone argues about bloat.
The argument is healthy, but only if it stays honest. Linux is not growing because maintainers forgot how to delete files. It is growing because the industry keeps asking Linux to be everywhere.
The Cost of Being Everywhere Is That Nothing Is Truly Peripheral
In a smaller operating system, obscure hardware support can feel peripheral. In Linux, peripheral code can become central at surprising moments. A driver for a niche device may matter in an industrial deployment. A filesystem corner case may matter to a recovery tool. A CPU architecture feature may matter to a cloud provider. A GPU path may matter to a gaming handheld that suddenly becomes popular.This is one reason kernel maintainers are cautious about removal. Dropping old code can unlock cleanup and reduce burden, but it can also strand users who have no alternative. The Linux community’s debates over old x86 support show how technical and cultural considerations intertwine. At some point, maintaining ancient compatibility becomes unreasonable; deciding that point is rarely painless.
The same problem exists in Windows, but it is mediated through commercial support lifecycles. Microsoft can declare hardware unsupported, and OEMs can move on. Linux has no single product manager with that authority. Its authority emerges through maintainer consensus, technical argument, and the practical reality of who is willing to keep code alive.
That makes Linux messier, but also more transparent. We can watch the trade-off happen in public.
The 43-Million-Line Kernel Is a Warning Against Lazy Minimalism
There is a fashionable way to talk about software in which all complexity is treated as moral failure. In this view, good software is small, bad software is large, and every line added is a confession. The Linux 7.2 tree complicates that story.Some complexity is accidental and should be removed. Some is defensive and should be celebrated. Some is vendor-driven and deserves scrutiny. Some is the unavoidable cost of supporting the machines people actually own. The art is in distinguishing these categories before reaching for slogans.
Linux’s growth should make users and administrators alert, not cynical. A large kernel needs better testing, clearer subsystem boundaries, more aggressive cleanup, and safer programming practices. It does not need performative nostalgia for a hardware world that no longer exists.
The danger is not that Linux has crossed an arbitrary threshold. The danger is that the industry may keep increasing the kernel’s responsibility faster than the kernel community can increase its review, testing, and maintenance capacity.
The Practical Reading for WindowsForum Regulars
For Windows enthusiasts, the Linux 7.2 milestone is a useful mirror. It shows what hardware support looks like when much of it is exposed in a single public tree, rather than dispersed across vendor packages, inbox drivers, firmware payloads, and update channels. It also shows why operating-system debates that stop at interface design or application support miss the deeper engineering contest.The practical reading is not “Linux is bloated” or “Linux is winning.” It is that operating systems now live under permanent pressure from hardware diversity, security expectations, and vendor acceleration. The kernel is where those pressures stop being marketing slides and become code.
This matters even if you never boot Linux on bare metal. It matters because Linux runs the cloud services Windows clients depend on, the Android devices users sync with, the routers and appliances in homes and offices, and the development environments increasingly used by Windows developers through virtualization and subsystem layers. Linux’s maintenance health is now part of the broader computing commons.
When that commons grows by nearly a million counted lines in a single development cycle, it is worth asking not whether the number is too large, but whether the institutions around it are strong enough.
The 43-Million-Line Moment Leaves Administrators With Five Concrete Lessons
The kernel’s growth is not an emergency, but it is a signal. The useful response is neither panic nor fan applause; it is operational realism.- Linux 7.2’s line-count jump reflects both new enablement and continuing cleanup, so raw size alone does not tell us whether the kernel is getting healthier or riskier.
- Driver code, especially modern GPU support, now accounts for a major share of visible kernel growth because hardware devices have become platform-scale systems in their own right.
- Removing legacy hardware support can simplify development, but it will not stop the kernel from growing while new architectures, accelerators, and devices keep arriving.
- Administrators should treat kernel upgrades as meaningful infrastructure changes, particularly on systems with specialized graphics, storage, networking, virtualization, or power-management requirements.
- Windows and Linux face the same hardware-complexity problem through different governance models, and neither platform can make that complexity disappear.
- The long-term health of Linux depends less on crossing or avoiding symbolic line-count thresholds than on review capacity, automated testing, safer APIs, and maintainers having the authority to delete code that no longer earns its keep.
References
- Primary source: Phoronix
Published: Sun, 28 Jun 2026 10:47:00 GMT
Linux 7.2 Surpasses More Than 43 Million Lines In The Kernel Tree - Phoronix
Today marks the last day of the Linux 7.2 merge window with Linux 7.2-rc1 due out later todaywww.phoronix.com
- Related coverage: winbuzzer.com
Linux 7.2 Removes String-Copying Function Strncpy After Six-Year Cleanup
Linux 7.2 has removed the kernel-side strncpy API after a six-year cleanup, shifting low-level code toward explicit string-copy helpers and reviewable intent.winbuzzer.com - Related coverage: techtimes.com
Linux 7.2 Closes Memory Bug Class With strncpy Removal After Six Years
Linux kernel strncpy removed in Linux 7.2 after 362 patches and six years of coordinated work. The dangerous C string function leaked kernel memory through unterminated buffers and wasted CPU cycleswww.techtimes.com - Related coverage: linux.se
- Related coverage: spinics.net
[git pull] drm for 7.2-rc1 — Linux Kernel
Linux Kernel: [git pull] drm for 7.2-rc1
www.spinics.net
- Related coverage: handwiki.org
Software:Linux kernel version history - HandWiki
This article documents the version history of the Linux kernel, a free, open-source, and Unix-like kernel that is used on many computer systems worldwide.handwiki.org
- Related coverage: hup.hu
- Related coverage: oracore.dev
Linux is finally dropping i486 support | OraCore.dev
Linux 7.1 may drop i486 support, ending a cleanup that began in 2025 and freeing kernel work from 486-era compatibility code.oracore.dev - Related coverage: tomshardware.com
Linux developers want to remove i486 and i586 Pentium CPU support to unburden kernel developers | Tom's Hardware
The i486 series launched in 1989, and the i586 series debuted in 1993.www.tomshardware.com - Related coverage: muylinux.com
El kernel Linux eliminará el soporte de i486 este año
Los responsables de Linux están dispuestos a poner fin al soporte de i486 durante el presente 2026 con el lanzamiento de la versión 7.1 del kernel.www.muylinux.com - Related coverage: releasealert.dev
Releases · torvalds/linux - GitHub | Release Alert
Latest releases for torvalds/linux on GitHub. Latest version: v7.1, last published: June 14, 2026releasealert.dev - Related coverage: pcgamer.com
'We have a new major number purely because I'm easily confused and not good with big numbers' says Linus Torvalds about Linux 7.0 | PC Gamer
Totally relatable, carry on.www.pcgamer.com - Related coverage: techradar.com
We might finally be getting Linux 7.0 at last | TechRadar
The next Linux version will be 7.0www.techradar.com - Related coverage: docs.redhat.com